EP3956846A1

EP3956846A1 - Method for directly transmitting electronic coin data sets between terminals and a payment system

Info

Publication number: EP3956846A1
Application number: EP20719977.9A
Authority: EP
Inventors: Florian Gawlas; Tilo FRITZHANNS; Marco Rummer; Wolfram Seidemann; Maria Veleva
Original assignee: Giesecke and Devrient GmbH
Current assignee: Giesecke and Devrient Advance52 GmbH
Priority date: 2019-04-15
Filing date: 2020-04-14
Publication date: 2022-02-23
Also published as: WO2020212337A1; DE102019002732A1; CN113994357A; US20220215355A1

Abstract

The invention relates to a method for directly transmitting an electronic coin data set between a first and a second terminal, said method comprising the following steps performed by the second terminal: receiving the electronic coin data set from the first terminal, the at least one electronic coin data set having a monetary value and a concealment value; generating a modified electronic coin data set using the received electronic coin data set; masking the modified electronic coin data set by applying a homomorphous one-way function to the modified electronic coin data set in order to obtain a masked, modified electronic coin data set; and sending a registration request for the masked, modified electronic coin data set to a monitoring authority. The invention additionally relates to a currency system and a payment system having a decentrally controlled database in the masked electronic coin data sets; and a direct transaction layer with at least two terminals, in which the method can be performed.

Description

PROCEDURE FOR DIRECT TRANSMISSION OF ELECTRONIC

COIN RECORDS BETWEEN TERMINAL DEVICES AND PAYMENT SYSTEM

TECHNICAL FIELD OF THE INVENTION

The invention relates to a method for the direct transmission of electronic coin data sets between terminals. The invention also relates to a payment system between at least two terminals and a monitoring entity.

TECHNICAL BACKGROUND OF THE INVENTION

Security of payment transactions and the associated payment transaction data means protection of the confidentiality of the data exchanged; as well as protecting the integrity of the data exchanged; as well as protection of the availability of the exchanged data.

Conventional blockchain-based payment transactions such as Bitcoin represent a high level of protection of integrity. When electronic coin data records, also known as “coins”, change hands in a blockchain technology, a lot of information is published. Such payment transactions and in particular the data exchanged are therefore not completely confidential. In addition, the payment transactions are very computationally intensive and therefore energy-consuming.

Therefore, instead of the confidential data, only the hash values of the confidential data are conventionally stored in a blockchain ledger. The corresponding plain text data must then be managed outside the blockchain. For electronic coin data records, such concepts are not yet applicable because they do not have basic control functions, in particular (1) the recognition of multiple spending procedures, also called double-spending, and (2) the recognition of uncovered payments. In case (1) someone tries to output the same coin data record several times and in the second case someone tries to output a coin data record even though he has no credit (or no longer).

From DE 10 2009 038 645 A1 and DE 10 2009 034 436 A1, systems for transferring monetary amounts in the form of electronic data records, in which payment with duplicates of the data record is prevented and a high degree of security against manipulation is given, are known complex structures and time-consuming encryption and signing processes are required for the exchange. They turned out to be of little practical use.

In WO 2016/200885 A1 a method for encrypting an amount made in a blockchain ledger is described, whereby the verifiability of the transaction is preserved remains. A concealment amount is added to an input value. Then an output value is generated and encrypted. Both the input value and the output value lie within a value range, with a sum of any two values within the range not exceeding a threshold value. The sum of the encrypted input value and the encrypted output value can be zero. Range tests, so-called range proofs, are assigned to each of the input values and the output value. These range checks prove that the input value and output value fall within the range of values. Each public key can be signed with a ring signature based on a public key of a recipient in the transaction. This process requires blockchain technology, which must be called after receiving a coin data set in order to validate the coin data set.

It is the object of the present invention to create a method and a system in which a payment transaction is designed to be secure but nevertheless simple. In particular, direct payment between end devices such as tokens, smartphones and machines should be created that is anonymous. The coin data records should be able to be used immediately after receipt. Several coin data sets should be able to be combined with one another and / or divided as desired by the user in order to enable flexible exchange. The exchanged coin data sets should on the one hand be confidential to other system participants, but on the other hand allow each system participant to carry out basic accounting checks, in particular the recognition of "multiple spending attempts" and the recognition of attempts to pay with non-existent amounts.

SUMMARY OF THE INVENTION

The tasks set are achieved with the features of the independent patent claims. Further advantageous configurations are described in the dependent claims.

The task is achieved in particular by a method for directly transmitting a

electronic coin data set resolved between a first and a second terminal, performed with the following steps by the second terminal. Receiving the electronic coin data record from the first terminal, wherein the at least one electronic

Coin record has a monetary amount and a disguise amount. Generating a modified electronic coin dataset using the received electronic coin dataset. Masking the modified electronic coin data set by applying a homomorphic one-way function to the modified electronic coin data set to obtain a masked, modified electronic coin data set. Submit a registration request for the masked modified electronic Coin data record to a monitoring instance.

Preferably, the registration request comprises masked ones to be registered

electronic coin data record, the masked modified electronic coin data record and, as already registered masked electronic coin data record, a masked received electronic coin data record for the received electronic coin data record.

In the step of generating

- A modified electronic coin data set to be switched can be generated from the received electronic coin data set, or

- The received electronic coin data set are divided into at least two divided modified electronic coin data sets, or

- The received electronic coin data set are linked as the first electronic coin data set and at least one second electronic coin data set to form the connected, modified electronic coin data set.

The masked, modified electronic coin data record can thus be a masked - either to be switched, divided or connected - electronic coin data record.

A registration request accordingly preferably comprises:

- exactly one masked electronic coin data set to be registered and exactly one registered masked electronic coin data set, or

- at least two masked split modified electronic ones to be registered

Coin records (and the masked electronic coin record received), or

- at least two registered masked electronic coin data sets (one of which is the masked electronic coin data set received and the masked associated electronic coin data set).

The masked electronic coin data record received is advantageously obtained by the second terminal device from the received electronic coin data record by applying the homomorphic one-way function.

In the generation step, the following is carried out particularly advantageously for the various modifications. The modified electronic coin data set to be switched can be generated from the received electronic coin data set, whereby

a concealment amount for the modified electronic coin record using a received concealment amount of the received one

electronic coin data set is generated, and o the received monetary amount of the received electronic coin dataset is used as a monetary amount for the modified electronic coin dataset.

The received electronic coin data record can be converted into at least two electronic

Coin part records are split, with

o the received monetary amount corresponds to the sum of the monetary amounts of the at least two electronic coin part data sets, and

o in particular the sum of the concealment amounts of the at least two electronic coin part data records corresponds to the concealment amount of the received electronic coin data record.

The received electronic coin data set can be linked as a first electronic coin data set and at least one second electronic coin data set to form the modified, linked electronic coin data set

o Compute an obfuscation amount for the modified electronic

Coin data set by forming the sum of the respective obfuscation amounts of the first and second electronic coin data sets, and

o Calculating the monetary amount for the modified electronic coin data set by forming the sum from the respective monetary amounts of the first and the second electronic coin data set.

After the (transmitted) electronic coin data record has been received in the second terminal, the coin data record is switched, divided or connected in this sense. Switching the transmitted electronic coin data set to a further electronic coin data set, namely electronic coin data set to be switched over; or splitting the transmitted electronic coin data set into a further (second) electronic coin data set; or connecting the transmitted electronic coin data record with a further electronic coin data record to form a further electronic coin data record, namely connected electronic coin data record. The further (or modified) electronic coin data record is masked. In embodiments, either only switching or only splitting or connecting can be used in terminals, but the terminal preferably selects from one of the three steps.

The terminal sends the registration request to the monitoring entity, which stores valid, masked electronic coin data records for electronic coin data records. Terminal devices such as the second terminal device can alternatively or additionally (for example, before further use) check the validity of an - in particular the received - electronic coin data record by converting the masked electronic coin data record into a

Sends validity request to the monitoring authority. The monitoring instance answers the Validation request (positive or negative) based on the stored valid masked electronic coin data records.

Sending the registration request (and thus the step of registering in the monitoring entity) is preferably carried out when the terminal is connected to the monitoring entity. In an alternative, the steps described can also initially be carried out without the step of sending the registration request (and of registering in the monitoring instance) being carried out. The steps of receiving the electronic coin record and sending the registration request are independent of one another. The steps of receiving the electronic coin data record and sending the registration request can, in particular, take place independently of one another at different times (e.g. receive now after / register (about) tomorrow).

When switching over the transmitted coin data record, in one embodiment the monetary amount of the transmitted electronic coin data record from the first terminal corresponds to the monetary amount of the further electronic coin data record. When dividing the transmitted electronic coin data record, in one embodiment the monetary amount of the transmitted electronic coin data record corresponds to the monetary total amount of the further electronic coin partial data records created from the transmitted electronic coin data record. When connecting, in one embodiment, the total monetary amount from the transmitted electronic coin data record with the second electronic coin data record corresponds to the monetary amount of the connected electronic coin data record.

An electronic coin dataset is in particular an electronic dataset that represents a monetary amount and is colloquially referred to as “digital coin” or “electronic coin”. In the process, this monetary amount changes from a first terminal to another terminal. In the following, a monetary amount is understood to be a digital amount, e.g. can be credited to an account of a financial institution, or can be exchanged for another means of payment. An electronic coin data record therefore represents cash in electronic form.

The terminal device can have a large number of electronic coin data records, for example the large number of coin data records can be stored in a data memory of the terminal device. The data memory then represents, for example, an electronic wallet. The terminal will usually carry out the steps completely itself, but it can provide a terminal service (an external server instance) that executes at least one (in particular exactly one or exactly two or all three) of the steps generating, masking and sending for the terminal (preferably, generating and masking ⁴ or, masking and sending or sending).

The terminal can, for example, be a passive device, such as. B. a token, a mobile terminal, e.g. be a smartphone, tablet computer, computer, or machine.

A method according to the invention in a monitoring instance which stores valid, masked electronic coin data records which are each formed by applying a homomorphic one-way function to an electronic coin data record, electronic coin data records having a monetary amount and a concealment amount, comprises the following steps:

- Receiving a registration request which comprises at least one masked electronic coin data record to be registered and at least one registered masked electronic coin data record;

- Checking the registration request received, where

o it is checked 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 instance, and

o it is checked whether the masked electronic coin data records of the registration request are monetarily value-neutral overall; and

- Storing the masked electronic coin data set to be registered as a valid masked electronic coin data set, the registered masked electronic coin data set of the registration request that was previously stored as valid is no longer valid.

The checking of the monetary amount neutrality of the registration request (possible due to the homomorphic one-way function used) is preferably done anonymously by forming the difference from the masked electronic coin data sets.

In a preferred method, the monitoring entity receives creation and / or deactivation requests from an issuer entity, which include at least one masked electronic coin dataset created or to be deactivated, in particular for an electronic coin dataset newly issued by the issuer entity or an electronic coin dataset withdrawn from the issuer entity.

For a masked electronic coin data record, the creation and / or deactivation request can include a signature of the issuer on the masked electronic Include coin dataset, the signature of the masked, newly created electronic coin dataset preferably being stored in the monitoring instance.

An electronic coin data set can become invalid in the monitoring instance by marking or deleting the corresponding masked electronic coin data set in the monitoring instance. The corresponding masked electronic coin data record or the corresponding electronic coin data record is particularly preferably deactivated in the issuer instance.

In particular, an electronic coin data record is unique and unambiguous, and this already differs from a conventional data record. It is advantageously used in a security concept that can optionally include, for example, signatures or encryptions. In principle, an electronic coin data record should contain all data that are required for a receiving entity with regard to verification and forwarding to other entities. Additional communication between the end devices when exchanging the electronic coin data records is therefore basically not necessary, but can be used.

According to the invention, an electronic coin dataset used for transmission between two terminals has a monetary amount, that is, a date which represents a monetary value of the electronic coin dataset, and a concealment amount, for example a random number. In addition, the electronic coin data record can have further metadata, for example which currency the monetary amount represents. An electronic coin data set is uniquely represented by these at least two data (monetary amount and concealment amount). Anyone who has access to these two pieces of data from a valid coin data record can use this electronic coin data record for payment. Knowing these two values (monetary amount and obfuscation amount) is synonymous with owning digital money. This electronic coin data record is transmitted directly between two terminals, namely at least between the first and second terminal. In one embodiment of the invention, an electronic coin dataset consists of these two data, so that only the transfer of the monetary amount and the concealment amount is necessary for exchanging digital money.

A corresponding masked electronic coin data record is assigned to each electronic coin data record. Knowledge of a masked electronic coin record does not make it possible to dispense the digital money represented by the electronic coin record. This represents a significant difference between masked electronic coin data records and (unmasked) electronic coin data records and is a core of the present invention. The masked electronic coin data record is unique and can be clearly assigned to an electronic coin data record, i.e. a 1-to-1 relationship. The electronic coin data set is preferably masked by a computing unit of the terminal within the terminal which also has the at least one electronic coin data set. Alternatively, the masking can be done by a computing unit of the terminal that receives the electronic coin data record.

This masked electronic coin data set is obtained by applying a homomorphic one-way function, in particular a homomorphic cryptographic function. This function is a one-way function, i.e. a mathematical function that is “easily” computable in terms of complexity theory, but “difficult” or practically impossible to reverse. Here, a one-way function is also referred to as a function for which no reversal that can be practically carried out in a reasonable time and with reasonable effort is known. The calculation of a masked electronic coin data record from an electronic coin data record is thus comparable to the generation of a public key in an encryption process using a residual class group. Preferably, a one-way function is used which operates on a group in which the discrete logarithm problem is difficult to solve, such as e.g. B. a cryptographic method analogous to an elliptical curve encryption, ECC for short, from a private key of a corresponding cryptography method. The reverse function, i.e. the generation of an electronic coin data record from a masked electronic coin data record, is very time-consuming - equivalent to generating the private key from a public key in an encryption process over a residual class group. When sums and differences or other mathematical operations are mentioned in the present document, the respective operations on the corresponding mathematical group are to be understood in the mathematical sense, for example the group of points on an elliptical curve.

The one-way function is homomorphic, i.e. a cryptographic method that has homomorphic properties. Thus, mathematical operations can be carried out with the masked electronic coin dataset, which can also be carried out in parallel on the (unmasked) electronic coin dataset and can therefore be reproduced. With the help of the homomorphic one-way function, calculations with masked electronic coin data records can be reproduced in the monitoring instance without the corresponding (unmasked) electronic coin data records being known there. Therefore, certain calculations with electronic coin data sets, for example for processing the (unmasked) electronic coin data set (for example splitting or combining), can also be carried out in parallel with the associated masked electronic coin data sets be proven, for example for validation checks or for checking the legality of the respective electronic coin data record. The homomorphism properties apply at least to addition and subtraction operations, so that splitting or combining (= connecting) electronic coin data sets can also be recorded in the monitoring instance by means of the correspondingly masked electronic coin data sets and can be traced back to the requesting end devices and / or the monitoring instance, without knowing the monetary amount and the performing terminal.

The homomorphism property therefore makes it possible to enter valid and invalid electronic coin data records on the basis of their masked electronic coin data records in a monitoring instance without knowledge of the electronic coin data records, even if these electronic coin data records are processed (divided, connected, switched). This ensures that no additional monetary amount has been created or that an identity of the terminal is recorded in the monitoring instance. Masking thus enables a high level of security without giving any insight into the monetary amount or the end device. This results in a two-tier payment system. On the one hand there is the processing layer in which masked electronic data records are checked and on the other hand there is the direct transaction layer in which at least two terminals transmit electronic coin data records.

While the electronic coin data records are used for direct payment between two terminals, the masked coin data records are registered in the monitoring instance.

The step of switching over the transmitted electronic coin data record comprises the following sub-steps:

Generating an electronic coin data set to be switched in the second terminal from the transmitted coin data set, wherein

a concealment amount for the electronic coin data record to be switched is generated in the second terminal using a transmitted concealment amount of the transmitted electronic coin data record; and

the transferred monetary amount of the transferred electronic coin data set is used as the monetary amount for the electronic coin data set to be switched.

When the electronic coin data record is transferred from the first terminal to the second terminal, two terminals are thus aware of the electronic coin data record. In order to prevent the sending first terminal device from also using the electronic coin data record for another (third) terminal device for payment, the transmitted electronic coin data record is switched from the first terminal device to the second terminal device. Switching can preferably take place automatically when receiving an electronic coin data record. In addition, it can also be done on request, for example a command from the first and / or second terminal.

In a preferred embodiment, the generating comprises generating a concealment amount for the electronic coin data set to be switched, preferably using the concealment amount of the transmitted electronic coin data set in conjunction with a new concealment amount, for example a random number. The concealment amount of the electronic coin data record to be switched is preferably obtained as the sum of the concealment amount of the transmitted electronic coin data record and the random number that serves as the new, that is, additional concealment amount. Furthermore, the monetary amount of the transmitted electronic coin dataset is preferably used as the monetary amount for the electronic coin dataset to be switched. This means that no further money is generated, the monetary amounts of both coin data sets are identical.

The registration after the switching step has the result that the electronic coin data set sent by the first terminal becomes invalid and is recognized as correspondingly invalid on a second dispensing attempt by the first terminal. The (further) coin data set generated by the second terminal device becomes valid after the tests have been successfully completed.

When switching, also called “switch”, the electronic coin data record received from the first terminal results in a new electronic coin data record, preferably with the same monetary amount, 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 concealment amount, for example a random number, is generated. The new concealment amount is added, for example, to the concealment amount of the received electronic coin data record so that the sum of both concealment amounts (new and received) serves as the concealment amount of the electronic coin data record to be switched. After switching, the received electronic coin data set and the electronic coin part data set to be switched are preferably masked in the terminal by applying the homomorphic one-way function to the respective electronic coin data set received and the electronic coin part data set to be switched over in order to generate a corresponding one masked received electronic coin data record and a masked electronic coin part data record to be switched. Furthermore, additional information which is required for registering the switching of the masked electronic coin data record in the remote monitoring entity is preferably calculated in the terminal. The additional information preferably contains an area proof of the masked electronic coin data record to be switched over and a region proof of the masked electronic coin data record obtained. The area evidence is evidence that the monetary value of the electronic coin data record is not negative, the electronic coin data record is validly created and / or the monetary value and the concealment amount of the electronic coin data record are known to the creator of the area evidence. In particular, the area verification serves to provide this verification (s) without revealing the monetary value and / or the concealment amount of the masked electronic coin data record. These proofs of range are also called “zero knowledge range proofs”. Ring signatures are preferably used as area evidence. The switching of the masked electronic coin data record is then registered in the remote monitoring entity.

This switching is necessary in order to invalidate (invalidate) the electronic coin data set received from the first terminal in order to avoid double spending. Because, as long as the electronic coin data record has not been switched, the first terminal can pass this received electronic coin data record on to a third device - since the first terminal is aware of the electronic coin data record and is therefore still in its possession. The switching is secured, for example, by adding a new concealment amount to the concealment amount of the electronic coin data record obtained, whereby a concealment amount is obtained that only the second terminal knows. Newly created obfuscation amounts must have a high entropy, since they are used as a dazzle factor for the corresponding masked electronic coin part data records. A random number generator on the terminal is preferably used for this purpose. This protection can be tracked in the monitoring instance.

In the dividing step, the electronic coin data record of the second terminal is divided into the first electronic coin partial data record and the second electronic coin partial data record. The division is preferably done in that on the one hand a monetary partial amount and a partial concealment amount for the first electronic coin dataset is determined (each between 0 and the received monetary amount or concealment amount) and on the other hand the monetary amount of the second electronic coin partial dataset as the difference from the received monetary amount and the monetary partial amount of the first electronic coin part data record, as well as the concealment amount of the second electronic Coin part data set is calculated as the difference between the received concealment amount and the part concealment amount of the first electronic coin part data set. After the division, the electronic coin data set to be divided, the first electronic coin part data set and the second electronic coin part data set are masked in the second terminal by applying the homomorphic one-way function in each case in order to obtain a masked electronic coin data set to be divided, a masked first electronic coin part data set and a masked second electronic coin part data set . Furthermore, additional information that is required for registering the division of the masked electronic coin data record in the remote monitoring entity is calculated in the terminal. The additional information preferably includes an area evidence of the masked electronic coin data record to be split, an area evidence of the masked first electronic coin data record and an area evidence of the masked second electronic coin data record. The area evidence is evidence that the monetary value of the electronic coin data record is not negative, the electronic coin data record is validly created and / or the monetary value and the concealment amount of the electronic coin data record are known to the creator of the area evidence. In particular, the area verification is used to provide this verification (s) without revealing the monetary value and / or the concealment amount of the masked electronic coin data record. These proofs of range are also called “zero knowledge range proofs”. Ring signatures are preferably used as area evidence. Subsequently, the division of the masked electronic coin data set is registered in the remote monitoring entity. In this way, monetary amounts to be transferred can be adapted to the corresponding needs. A terminal owner is not forced to always pass on the entire monetary amount to another terminal.

The splitting and subsequent registration has the advantage that an owner of the at least one electronic coin data record is not forced to always transfer the entire monetary amount at once, but instead to transfer corresponding sub-amounts. The monetary value can be divided without restrictions as long as all electronic coin data sub-records have a positive monetary amount that is less than the monetary amount of the electronic coin data record from which the division is made and the sum of the electronic coin sub-data records is equal to the electronic coin sub-data record to be divided. Alternatively or additionally, fixed denominations can be used. Alternatively, the concealment amount can be generated outside of the terminal and obtained via a (secure) communication channel. A random number generator on the terminal is preferably used for this purpose. In order to keep track of all checks, the checking instance can, for example, show the sub-steps of the Note the monitoring instance, with markings, English flags, being set in order to document intermediate stages. After successfully completing the checks that are relevant for the split command, that is, if the markings are complete, the (masked) first electronic coin part data record and (masked) second electronic coin part data record are preferably marked as valid. The (masked) electronic coin data set to be split automatically becomes invalid. The monitoring instance preferably notifies the result of executing the split command to the “commanding” terminal, ie which of the masked electronic coin data records involved are valid after the split command has been executed.

In the step of connecting electronic coin data sets, a further electronic coin data set (connected electronic coin data set) is determined from a first and a second electronic coin data set. The concealment amount for the electronic coin data set to be linked is calculated by forming the sum from the respective concealment amounts of the first and second electronic coin data sets. Furthermore, the monetary amount for the connected electronic coin dataset is preferably calculated by forming the sum from the respective monetary amounts of the first and the second electronic coin dataset.

After connecting, the first electronic coin data set, the second electronic coin data set and the electronic coin data set to be connected are saved in the (first and / or second) terminal by applying the homomorphic one-way function to the first electronic coin data set, the second electronic coin data set and the one to be connected electronic coin data record masked in order to obtain a masked first electronic coin data record, a masked second electronic coin data record, and a masked electronic coin data record to be connected accordingly. Furthermore, additional information that is required for registering the connection of the masked electronic coin data records in the remote monitoring entity is calculated in the terminal. The additional information preferably includes an area evidence of the masked first electronic coin data record and an area evidence of the masked second electronic coin data record. The area evidence is evidence that the monetary value of the electronic coin data record is not negative, the electronic coin data record is validly created and / or the monetary value and the concealment amount of the electronic coin data record are known to the creator of the area evidence. In particular, the area verification is used to provide this verification (s) without revealing the monetary value and / or the concealment amount of the masked electronic coin data record. These proofs of range are also called “zero knowledge range proofs”. To be favoured ring signatures used as proof of range. The connection of the two masked electronic coin data records is then registered in the remote monitoring entity.

With the command or step of connecting two electronic coin data sets can be combined. The monetary amounts as well as the obfuscation amounts are added up. As with dividing, the two original coin data records can also be validated when combining.

A main distinguishing feature of this inventive concept compared to known solutions is that the monitoring entity only (that is, exclusively) maintains knowledge of the masked electronic coin data records and optionally a list of processing or changes to the masked electronic coin data record. The actual payment transactions are not registered in the monitoring instance and take place in a direct transaction layer directly between terminals.

According to the invention, a two-layer payment system consisting of a direct payment transaction layer for the direct exchange of (unmasked) electronic coin data records and a monitoring layer, which can also be referred to as a “veiled electronic data record ledger”, is provided. In the monitoring instance of the verification layer, no payment transactions are recorded, only masked electronic coin data records and their processing for the purpose of verifying the validity of (unmasked) electronic coin data records. This guarantees the anonymity of the participants in the payment system. The monitoring instance provides information about valid and invalid electronic coin data sets, for example to avoid multiple output of the same electronic coin data set or to verify the authenticity of the electronic coin data set as validly issued electronic money.

The first and / or second terminal can thus transmit electronic coin data records to another terminal in the direct payment transaction layer without a connection to the checking entity, in particular when the terminal is offline.

In the present case, the first and / or second terminal can have a security element in which the electronic coin data records are securely stored. A security element is preferably a special computer program product, in particular in the form of a secured runtime environment within an operating system of a terminal, English Trusted Execution Environments, TEE, stored on a data memory, for example a mobile one Terminal, a machine, preferably an ATM. Alternatively, the security element is designed, for example, as special hardware, in particular in the form of a secured hardware platform module, English Trusted Platform Module, TPM or as an embedded security module, eUICC, eSIM. The security element provides a trustworthy environment.

The communication between two terminals can be wireless or wired, or e.g. also take place optically, preferably via QR code or barcode, and can be designed as a secure channel. The optical path can include, for example, the steps of generating an optical coding, in particular a 2D coding, preferably a QR code, and reading in the optical coding. The exchange of the electronic coin data record is thus secured, for example, by cryptographic keys, for example a session key negotiated for an electronic coin data record exchange or a symmetrical or asymmetrical key pair.

By communicating between end devices, for example via their security elements, the exchanged electronic coin data sets are protected against theft or manipulation. The security element level thus complements the security of established blockchain technology.

In addition, it is advantageous that the electronic coin data records can be transmitted in any format. This implies that it communicates on any channel, i.e. that it can be transmitted. They do not need to be saved in a specific format or in a specific program.

In particular, a mobile telecommunication terminal, for example a smartphone, is regarded as a terminal. As an alternative or in addition, the terminal can also be a device such as a wearable, smart card, machine, tool, machine or container or vehicle. A terminal according to the invention is therefore either stationary or mobile.

The terminal is preferably designed to use the Internet and / or other public or private networks. For this purpose, the terminal uses a suitable connection technology, for example Bluetooth, Lora, NFC and / or WiFi and has at least one corresponding interface. The terminal can also be designed to be connected to the Internet and / or other networks by means of access to a cellular network.

In one embodiment, it can be provided that the first and / or second terminal in the method shown, the received electronic coin data records when present or Receipt of several electronic coin data sets processes them according to their monetary value. It can thus be provided that electronic coin data sets with a higher monetary value are processed before electronic coin data sets with a lower monetary value. In one embodiment, the first and / or second terminal device can be designed to connect the electronic coin data record already present in the second terminal device to the electronic coin data record already present in the second terminal device, depending on the attached information, for example a currency or denomination, and to carry out a connection step accordingly. Furthermore, the second terminal can also be designed to automatically carry out a switchover after receiving the electronic coin data record from the first terminal.

In one embodiment, additional information, in particular metadata, is transmitted from the first terminal to the second terminal during transmission, for example a currency. In one embodiment, this information can be included in the electronic coin data record.

In a preferred embodiment, the method has the following further steps: masking the transmitted electronic coin data record in the second terminal by applying the homomorphic one-way function to the transmitted electronic coin data record; and sending the masked transmitted electronic coin data set to the remote monitoring entity for the remote monitoring entity to check the validity of the transmitted electronic coin data set. In this case, for example, the entire monetary amount was transferred to the second terminal as part of the electronic coin data record. Before a payee accepts this electronic coin data record, he / she checks its validity if necessary. For this purpose, the second terminal generates the masked, transmitted electronic coin data record, sends it to the monitoring entity and in doing so asks the monitoring entity about the validity of the electronic coin data record. The monitoring instance now checks whether the masked, transmitted electronic coin data record is even present and whether it is still valid, i.e. has not already been used by another terminal, in order to avoid double spending.

In one embodiment, evidence is created in the second terminal. The evidence includes information about the correspondence of the monetary amount of the transmitted electronic coin data set with the monetary amount of the electronic coin data set to be switched. The proof preferably only includes information about the match, but not one of the monetary amounts. The electronic coin data records of the first and / or second terminal are preferably checked during the registration in the monitoring instance. The check takes place as a function of the steps preceding the check, for example whether a step of switching, connecting and / or dividing has taken place. The monitoring instance can for example check the validity of the (masked) transmitted and / or to be divided and / or first and second electronic coin data records. This makes it possible to determine whether the electronic coin records are being processed for the first time. If the (masked) electronic coin data sets are not valid (i.e. in particular if they are not present in the monitoring instance) the registration cannot be carried out successfully, for example because the terminal tries to issue an electronic coin data set several times.

In a further preferred embodiment, after the switching step has been carried out in the terminal, the switching command prepared by the terminal is sent (as a registration request) to the monitoring entity, for example. The switchover command preferably contains the masked electronic coin data record received, the masked electronic coin data record to be switched and preferably contains further information which is needed for checks in the monitoring instance. The additional information is used to prove to the “ordering” terminal that it knows the monetary amount and the concealment amount of the electronic coin data record received without communicating the values, preferably by means of zero knowledge proof. The checking instance checks the traceability of the unknowledgeable evidence, the validity of the masked electronic coin data record received and that the monetary amount of the electronic coin data record received is equivalent to the monetary amount of the electronic coin data record to be switched. In order to prove that only a new concealment amount has been added to the concealment amount of the electronic coin data record received, but the monetary amount has remained the same, the second terminal device can preferably prove that the difference between the masked coin data record received and the masked coin data record to be switched has a special representation, namely that of a public key. This is done by generating a signature for the masked electronic coin data set to be switched with the added concealment amount. This generated signature of the masked electronic coin data record to be switched over can then be checked in the monitoring instance, which is considered to be proof that the second terminal is aware of the added concealment amount. Preferably, after the tests that are relevant for the switchover command have been successfully completed, that is to say with the corresponding completeness of the markings, the (masked) electronic coin data set to be switched is marked as valid. In this case, the masked, previously registered electronic coin data record may automatically become invalid. Alternatively the masked, previously registered electronic coin data set is marked as invalid or deleted. The monitoring instance preferably notifies the result of executing the switchover command to the “commanding” terminal, ie which of the masked electronic coin data records involved are valid after the switchover command has been carried out.

In a further preferred embodiment, for registration, after the end device has performed the splitting step, a splitting command prepared by the terminal device (as a registration request) is sent to the monitoring entity. It contains the masked electronic coin data record to be divided, the masked first electronic coin part data record, the masked second electronic coin part data record and preferably further information that is needed for checks in the monitoring instance. The additional information is used to prove to the “ordering” terminal that it knows the monetary amount and the concealment amount of the electronic coin data set to be divided up without communicating the values, preferably by means of zero knowledge proof. The verification instance checks the traceability of the unknowledgeable evidence, the validity of the masked electronic coin dataset to be split and that the sum of the monetary amount of the first electronic coin dataset and the monetary amount of the second electronic coin dataset is equivalent to the monetary amount of the electronic coin dataset to be split (amount neutrality). This is preferably done in that the monitoring instance compares the sum of the masked first electronic coin part data set and the masked second electronic coin part data set with the masked coin part data set to be divided.

In a further preferred embodiment, for registration, after the connection step of the terminal device has been carried out, a connection command prepared by the terminal device (as a registration request) is sent to the monitoring instance. It contains the first masked electronic coin data record, the second masked electronic coin data record and the masked coin part data record to be connected and preferably further information that is needed for checks in the monitoring instance. The additional information is used to prove to the “ordering” terminal that it knows the monetary amounts and the concealment amounts of the first and second electronic coin data records without communicating the values, preferably by means of zero knowledge proof. The reviewing instance checks the traceability of the unaware evidence, 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 amount of the first electronic coin data record and the monetary amount of the second electronic coin data record is equivalent to the monetary amount of the to connecting electronic coin data set is (amount neutrality). This is preferably done by the monitoring entity comparing the sum of the masked first electronic coin data record and the masked second electronic coin data record with the masked partial coin data record to be connected. Preferably, after successfully completing the checks that are relevant for the connect command, that is, if the markings are complete, the (masked) electronic coin data set to be connected is marked as valid. The (masked) first electronic coin data record and the (masked) second electronic coin data record automatically become invalid. Alternatively, the masked, previously registered electronic coin data records are actively marked as invalid or deleted. The monitoring instance preferably notifies the result of the deployment of the connect command to the “commanding” terminal, ie which of the masked electronic coin data records involved are valid after the connect command has been executed.

In one embodiment, the masking of the transmitted electronic coin data record and its validity check are carried out before the transmitted electronic coin data record is registered in the monitoring instance. The second terminal first sends a validity request for the masked electronic coin data record received and only uses the received electronic coin data record if it is valid. For example, the registration request can then be sent or the received electronic coin data record (unmodified) can be passed on, in particular to another terminal or to another system participant, such as a server instance of a commercial bank.

In a preferred embodiment, the monitoring entity is a remote entity. Thus, for example, the establishment of a communication connection to the monitoring entity is provided for registering the electronic coin data record.

The monitoring instance is designed as a superordinate instance. The monitoring instance is therefore not necessarily arranged in the level or in the layer of the terminals (direct transaction layer). The monitoring entity is preferably provided for managing and checking masked electronic coin data records. It is arranged in an issuer layer, in which an issuer instance is also arranged, and / or in an independent monitoring layer. It is conceivable that the monitoring instance also manages and checks transactions between the first and second terminals.

The monitoring instance is preferably a decentrally controlled database, English Distributed Ledger Technology, DLT, in which the masked electronic coin data sets are registered with corresponding processing of the masked electronic coin data set. In In a preferred embodiment, a validity status of the (masked) electronic coin data record can be derived from this. The validity of the (masked) electronic coin data records is preferably noted in and by the checking entity. The registration of the processing or the processing steps can also relate to the registration of test results and intermediate test results relating to the validity of an electronic coin data record. If processing is final, this is indicated, for example, by corresponding markings or a derived overall marking. Final processing then decides whether an electronic coin dataset is valid or invalid.

This database is further preferably a non-public database, but can also be implemented as a public database. This database makes it possible to check coin data records for their validity in a simple manner and to prevent “double-spending”, ie multiple spending, without the payment transaction itself being registered or logged. The DLT describes a technique for networked computers that come to an agreement about the sequence of certain transactions and that these transactions update data. It corresponds to a decentralized management system or a decentralized database.

In a further embodiment, the database can also be designed as a public database.

Alternatively, the monitoring instance is a centrally managed database, for example in the form of a publicly accessible data memory or as a mixed form of a central and decentralized database.

Initial electronic coin data records are preferably created exclusively by the issuer. Preferably, however, switched, divided or connected electronic coin data records, in particular electronic coin part data records, can also be generated by a terminal. The creation and selection of a monetary amount preferably also includes the selection of a concealment amount with high entropy.

The issuing entity is a computing system which is preferably remote from the first and / or second terminal. The issuing authority is particularly preferably assigned to a central bank. After the creation of the new electronic coin data record, the new electronic coin data record is masked in the issuer instance by applying the homomorphic one-way function to the new electronic coin data record in order to obtain a masked new electronic coin data record accordingly. Furthermore, additional Information required for registering the creation of the masked new electronic coin data record in the remote monitoring entity is calculated in the issuing entity. This additional information is preferably evidence that the (masked) new electronic coin data record originates from the issuer, for example by signing the masked new electronic coin data record. In one embodiment, it can be provided that the issuer instance signs a masked electronic coin data record with its signature when generating the electronic coin data record. The signature of the issuing authority is preferably stored in the monitoring authority. In one embodiment, it can be provided that the issuer instance also sends a proof of the area of the electronic coin data set generated in order to prove possession of the electronic coin data set.

Preferably, the issuer can deactivate an electronic coin data record that is in its possession (i.e. of which it knows the monetary amount and the concealment amount) by masking the electronic coin data record to be deactivated with the homomorphic one-way function and a deactivation command or a Deactivation request prepared for the monitoring instance. In addition to the masked electronic coin data record to be deactivated, part of the deactivation command is preferably also the proof that the deactivation step was initiated by the issuer, for example in the form of the signed, masked electronic coin data record to be deactivated. As additional information, the deactivation command could contain area checks for the masked electronic coin data record to be deactivated. The deactivation of the masked electronic coin data record is then registered in the remote monitoring entity. The deactivation step is triggered with the deactivate command.

In a further preferred embodiment, a deactivation command (or a deactivation request) is prepared in the issuing entity and is sent to the monitoring entity. The deactivation command contains the masked electronic coin data record to be deactivated and, preferably, further information that is needed for checks in the monitoring instance. The additional information serves to prove that the deactivation command was initiated by the issuer, preferably by means of the signed, masked electronic coin data record to be deactivated. The checking entity checks the signature, the validity of the masked electronic coin data set to be deactivated and optionally the area evidence of the masked electronic coin data set to be deactivated. After successfully completing the tests that are relevant for the deactivation command, that is to say in particular with the corresponding completeness of the markings, the (masked) one to be deactivated is preferred Electronic coin record marked as invalid (or deleted). The monitoring entity preferably notifies the issuer entity of the result of executing the deactivation command, ie that the (masked) electronic coin data set to be deactivated is invalid after the deactivation command has been executed.

The creation and deactivation steps are preferably carried out in secure locations, in particular not in the terminals. In a preferred embodiment, the creation and deactivation steps are only carried out or initiated by the issuing entity. These steps preferably take place in a secure location, for example in a hardware and software architecture that was developed for processing sensitive data material in insecure networks. The deactivation of 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, in particular transactions, since it has been marked as invalid in and by the monitoring entity. However, in one embodiment it can be provided that the deactivated, masked electronic coin data record remains archived at the issuer. The fact that the deactivated, masked electronic coin data record is no longer valid can be identified, for example, with the aid of a flag or some other coding, 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.

The fiction, contemporary method enables various processing operations for the electronic coin data sets and the corresponding masked electronic coin data sets. Each of the processing operations (in particular creating, deactivating, splitting, connecting and switching) is registered in the monitoring instance. The processing operations can be appended there in unchangeable form to the list of previous processing operations for the respective masked electronic coin data record. The processing operations "create" and "deactivate", which concern the existence of the monetary amount per se, that is, the creation and destruction or even the destruction of money, require additional approval, for example in the form of a signature, by the issuing authority to be registered in the monitoring instance. The other processing operations (splitting, connecting, switching) do not require any authorization by the issuing authority or by the requestor / command initiator (= payer, e.g. the first terminal).

Processing in the direct transaction layer only affects the ownership structure and / or the assignment of the coin data records to the terminals of the respective electronic coin data records. The respective processing results are registered in the Supervisor. The database of valid masked coin data records is adapted accordingly. For example, by adding and deleting masked coin data records. However, it is preferably implemented by means of corresponding list entries in a database which comprises a series of markings that are used by the

Monitoring instance must be set. A possible structure for a list entry includes, for example, column (s) for a previous coin data record, column (s) for a successor coin data record, a signature column for the issuer instance, and at least one marking column. A change in the status of the marking requires the approval of the monitoring authority and must then be saved unchangeably. A change is final if and only if the necessary markings by the

Monitoring authority have been validated, i.e. after the corresponding check, for example, the status "0" was changed to the status "1". If a test fails or takes too long, it is instead changed, for example, from status to status "0". Further status values are conceivable and / or the status values mentioned here are interchangeable. Preferably, the validity of the respective (masked) electronic coin data records from the status values of the markings is summarized in a column for each masked electronic coin data record that is involved in registering the processing.

In a further exemplary embodiment, at least two, preferably three or even all of the aforementioned markings can also be replaced by a single mark, which is set when all tests have been successfully completed. Furthermore, the two columns for predecessor data sets and successor data sets can be combined into one each, in which all coin data sets are listed together. As a result, more than two electronic coin data records could be managed per field entry, and thus e.g. a split into more than two coins can be realized.

The checks by the supervisory authority to check whether processing is final are already described above and are in particular:

- Are the masked electronic coin data records of the previous column (s) valid?

- Does a check yield the correct test value?

- Are the proofs of area for the masked electronic coin data records successful?

- Is the signature of the masked electronic coin data record a valid signature of the issuing authority?

It is also preferred that a masked electronic coin data record is invalid if one of the following checks applies, i.e. if:

(1) the masked electronic coin data record is not registered in the monitoring entity; (2) the last processing of the masked electronic coin data record indicates that it has predecessor coin data records, but this last processing is not final; or

(3) the last processing of the masked electronic coin data set indicates that there are successor coin data sets for it and this last processing is final.

(4) the masked electronic coin record is not the successor to a valid masked electronic record unless it is signed by the issuer

The steps listed here of switching, splitting or connecting (registering modifications) and creating and deactivating (initial registration and final deregistration) are triggered in the monitoring instance by corresponding requests (or commands), for example a corresponding creation, switchover , Split, connect or deactivate command.

In one aspect of the invention, a payment system for exchanging monetary amounts is provided with an accounting layer with a database (preferably decentralized controlled database, English Distributed Ledger Technology, DLT) in which masked electronic coin data records are stored; and a direct transaction layer with at least two terminals in which the method described above can be carried out; and / or an issuer instance for the initial generation or creation of an electronic coin data record. The issuer entity can prove that the masked electronic coin data record was generated by it, the issuer entity can preferably identify itself by signing and the monitoring entity can check the signature of the issuer entity. In one embodiment, it can be provided that the issuer instance also sends a proof of the area of the electronic coin data set generated in order to prove possession of the electronic coin data set.

In a preferred embodiment, the payment system comprises an issuer instance for generating an electronic coin data record. The issuer entity can prove that the masked electronic coin data record was generated by it, the issuer entity can preferably identify itself by signing and the monitoring entity can check the signature of the issuer entity. In one embodiment, it can be provided that the issuer instance also sends a proof of the area of the electronic coin data set generated in order to prove possession of the electronic coin data set.

The payment system is preferably designed to carry out the above-mentioned method and / or at least one of the embodiment variants. Another aspect of the invention relates to a currency system comprising an issuer entity, a monitoring entity, a first terminal and a second terminal, the issuer entity being designed to create an electronic coin data record. The masked electronic coin data record is designed to be verifiably created by the issuing entity. The monitoring instance is designed to carry out one of the above-mentioned methods, that is to say in particular the processing of registration requests. The terminals, that is to say at least the first and second terminals, are preferably suitable for executing one of the above-mentioned methods for transmitting coin data sets.

In a preferred embodiment of the currency system, only the issuer is authorized to initially create an electronic coin data record. Processing, for example the step of connecting, splitting and / or switching, can and is preferably carried out by a terminal. The processing step of deactivation can preferably only be carried out by the issuing entity. Thus, only the issuing entity would be entitled to invalidate the electronic coin data record and / or the masked electronic coin data record.

The checking instance and the issuing instance are preferably each arranged in a server instance or are available as a computer program product on a server and / or a computer.

The currency system can include further coin owner entities, in particular server entities or computer entities. Like the terminals, the coin owner entities can transmit electronic coin data records, in particular to each other or from or to terminals, and send registration requests to the monitoring entity for masked modified electronic coin data records. Further coin owner instances can be assigned to commercial banks, online shops or service providers, for example.

What is proposed here is a solution that issues digital money in the form of electronic coin data records that are based on the use of conventional (analog) banknotes and / or coins. The digital money is represented by electronic coin data records. As with (analog) banknotes, these electronic coin data sets can also be used for all forms of payments, including peer-to-peer payments and / or POS payments. The knowledge of all components (in particular the monetary amount and the concealment amount) of a valid electronic coin data record is equivalent to the possession (ownership) of the digital money. It is therefore advisable to use this to treat valid electronic coin data records confidentially, for example to keep them in a security element / safe module of a terminal and to process them there. In order to decide on the authenticity of an electronic coin data set and to prevent double spending, masked electronic coin data sets are held in the monitoring instance as a unique, corresponding public representation of the electronic coin data set. The knowledge or the possession of a masked electronic coin data record does not represent the possession of money. Rather, this is like checking the authenticity of the analog means of payment.

The monitoring instance stores the valid masked electronic coin data records. Therefore, a recipient of an electronic coin data set will first generate a masked received electronic coin data set and have the validity of the masked electronic coin data set confirmed by the monitoring entity. A great advantage of this solution according to the invention is that the digital money is distributed to terminals, dealers, banks and other users of the system, but no digital money or other metadata is stored in the monitoring instance - that is, a common instance. In this case, the monitoring instance can preferably also store a validity status of the masked electronic coin data sets and / or contain markings about executed and planned processing of the masked electronic coin data set. A status of the respective masked electronic coin data record can be derived from the markings relating to the processing, which indicates whether the corresponding (unmasked) electronic coin data record is valid, i.e. is ready to pay.

The proposed solution can be integrated into existing payment systems and infrastructures. In particular, there can be a combination of analog payment processes with banknotes and coins and digital payment processes according to the present solution. A payment process can take place with banknotes and / or coins, but the change or change is available as an electronic coin data record. For example, ATMs with a corresponding configuration, in particular with a suitable communication interface, and / or mobile terminals can be provided for the transaction. An exchange of electronic coin data sets for bank notes or coins is also conceivable.

BRIEF SUMMARY OF THE FIGURES

The invention and further embodiments and advantages of the invention are explained in more detail below with reference to figures, the figures merely describing exemplary embodiments of the invention. The same components in the figures are given the same reference symbols Mistake. The figures are not to be regarded as true to scale; individual elements of the figures can be shown exaggeratedly large or exaggeratedly simplified.

Show it:

Fig.l shows an embodiment of a payment system according to the invention;

2 shows an embodiment of a monitoring instance;

3 shows an embodiment of a payment system according to the invention for splitting and switching over electronic coin data sets;

4 shows an embodiment of a payment system according to the invention for connecting electronic coin data sets;

5 shows an embodiment of a process flow diagram of a method according to the invention and corresponding processing steps of a coin data set;

6 shows an exemplary embodiment of a process flow diagram of a method according to the invention and corresponding processing steps of a coin data set;

7 shows a further exemplary embodiment of a method flow diagram of a method according to the invention.

FIGURE DESCRIPTION

Fig.l shows an embodiment of a payment system with terminals Ml and M2 according to the invention.

An electronic coin data record C _{i is} generated in an issuer instance 1, for example a central bank. For the electronic coin data record C _i , which includes a concealment amount, a masked electronic coin data record Z _{i is} generated and registered in a database 2 as a monitoring instance, which is referred to here as the “concealed electronic data record ledger”. In the context of this invention, a ledger is understood to be a list, a directory, preferably a database structure. The electronic coin data record C _i is output to a first terminal Ml. For example, a true random number was generated as the concealment amount n. This concealment amount n is linked to a monetary amount Ui and then forms an i-th electronic coin data record according to the invention:

Ci = (Vi, ri} (1)

A valid electronic coin data record can be used for payment. The owner of the two values u, · and n is therefore already in possession of the digital money because he can use it for payment. In the system, however, the digital money is defined by a pair consisting of a valid electronic coin data record and a corresponding masked electronic coin data record Z _i . The masked electronic coin data set Z _i is obtained by applying a homomorphic one-way function f (C _i ) according to equation (2):

Z _i = f (Ci) (2)

This function f (C _i ) is public, ie every system participant can call up and use this function. This function f (C _i ) is defined according to equation (3):

Z _i Vi H + TG (3) where H and G are generator points of a group G, in which the discrete logarithm problem is difficult, with the generators G and H, for which the discrete logarithm of the other base is unknown. For example, G and H are generator points of an elliptical curve encryption, ECC - that is, private keys of the ECC. These generator points G and FI must be selected in such a way that the relationship between G and H is not publicly known, so that:

G = h · H (4) the link n must be practically impossible to find in order to prevent the monetary amount u; is manipulated and still a valid Z; could be calculated. Equation (3) is a “Pederson Commitment for ECC”, which ensures that the monetary amount n _t can be granted, ie “committed”, to a monitoring instance 2 without disclosing it to the monitoring instance 2. The public and remote monitoring instance 2 is therefore only sent (disclosed) the masked coin data set Z _i .

Even if encryption based on elliptical curves is or is described in the present example, another cryptographic method would also be conceivable, which is based on a discrete logarithmic method. Equation (3) enables, through the entropy of the concealment amount n, that even with a small value range for monetary amounts u; a cryptographically strong Z _{i is} obtained. A simple brute force attack simply by estimating monetary amounts v _i is therefore practically impossible.

Equation (3) is a one-way function, which means that the computation of Z _i from C _{i is} easy, since an efficient algorithm exists, whereas the computation of C _i from Z _{i is} very difficult, since none is solvable in polynomial time Algorithm exists.

In addition, equation (3) is homomorphic for addition and subtraction, which means that:

Thus, addition operations and subtraction operations can be carried out both in the direct transaction layer 3 and also in parallel in the accounting layer 4 without the accounting layer 4 having knowledge of the electronic coin data records C _i . The homomorphic property of equation (3) enables valid and invalid electronic coin data sets C _i to be kept on the basis of the masked coin data sets Z _i alone and to ensure that no new monetary amount v _{j has been} created.

Due to this homomorphic property, the coin data set C _{i can be divided} according to equation (1) into:

where:

The following applies to the corresponding masked coin data records:

With equation (9), for example, a “dividing” processing or a “dividing” processing step of a coin data set according to FIG. 3 can be checked in a simple manner without the monitoring instance 2 having knowledge of C _i , C _j , C _k . In particular, the condition of equation (9) is checked to validate divided coin records Cj and C _k and to declare the coin data set C _i invalid. Such a division of an electronic coin data set C _i is shown in FIG.

In the same way, electronic coin data records can also be combined (connected), see FIG. 4 and the explanations for this.

In addition, it is necessary to check whether (not allowed) negative monetary amounts are registered. An owner of an electronic coin data set C _i must be able to prove to the monitoring instance 2 that all monetary amounts Ui in a processing operation lie within a value range of [0, ..., n] without informing the monitoring instance 2 of the monetary amounts Ui . These proofs of range are also called "range proofs". Ring signatures are preferred as evidence of areas. For the present exemplary embodiment, both the monetary value and the concealment amount of an electronic coin data set are resolved in bit representation, ie U = Sa _j * 2 for 0 £ j £ n and a _j “element” {0; 1} and r _i = åb _j * 2 ^J for 0 £ j £ n and b _j “element” {0; 1}. For each bit, a ring signature with C _ij = a _j -H + b _j -G and C _ij -a _j H is preferably carried out, it being possible in one embodiment to carry out a ring signature only for certain bits.

It is not shown in FIG. 1 and will only be explained later that new electronic coin data sets C _{i are} preferably not output directly to terminals, but rather initially to a commercial bank, for example.

In FIG. 1, an electronic coin data set C _{i is} generated by the meter issuer instance 1 and, by means of equation (3), a masked electronic coin data set Z; calculated by the issuing authority 1 and this registered in the monitoring authority 2. The first terminal M1 then transmits the electronic coin data record C _i to a second terminal M2. Before this, the terminal could optionally carry out one of the processing steps (switching, connecting, dividing). The transmission takes place wirelessly via WLAN, NFC or Bluetooth, for example. The transmission can be additionally secured by cryptographic encryption methods, for example by negotiating a session key or using a PKI infrastructure.

The transmitted electronic coin data set C _{i is received} as C _i ^{* in the} second terminal M2. Upon receipt of the electronic coin data set C _i ^* , the second terminal M2 is in possession of the digital money represented by the electronic coin data set C _i ^* . If both terminals trust each other, no further steps are necessary to end the process. However, the terminal M2 does not know whether the electronic coin data record C _i ^* is actually valid. In addition, the terminal Ml could also transmit the electronic coin data set C _i to a third terminal (not shown). To prevent this, further preferred steps are provided in the method.

To check the validity of the received electronic coin data set C _i ^* , the masked, transmitted electronic coin data set Z _i ^{* is} calculated in the second terminal M2 with the - public - one-way function from equation (3). The masked, transmitted electronic coin data set Z _i ^* is then transmitted to the monitoring instance 2 and searched there. If there is a match with a registered and valid masked electronic coin data set, the validity of the received coin data set C _i ^* is displayed to the second terminal M2 and it applies that the received electronic coin data set C _i ^{* is} equal to the registered electronic coin data set C _i . With the check for validity it can be established in one embodiment that the received electronic coin data record C _i ^{* is} still valid, ie that it has not already been used by another processing step or in another transaction and / or was subject to a further change .

The electronic coin data record obtained is then preferably switched over by the second terminal.

It applies to the method according to the invention that the sole knowledge of a masked electronic coin data set Z _i does not entitle the holder to spend the digital money. The sole knowledge of the electronic coin data set C _i authorizes payment, ie to successfully carry out a transaction, in particular if the coin data set C _{i is} valid. There is a 1-to-1 relationship between the electronic coin data records C _i and the corresponding masked electronic coin data records Z ;. The masked electronic coin data records Z _i are registered in the monitoring instance 2, for example a public decentralized database. This registration first makes it possible to check the validity of the data record, for example whether new monetary amounts have been created (illegally).

A main differentiating feature compared to conventional solutions is that the masked electronic coin data sets Z _i are stored in a monitoring layer 4 and all processing operations on the electronic coin data set Z _i are registered there, whereas the actual transfer of the digital money in a (secret, i.e. not public known) direct transaction layer 3 takes place.

In order to prevent multiple spending or to ensure more flexible transmission, the electronic coin data records can now be used in the Procedure to be processed. The following table 1 lists the individual operations, with the specified command also executing a corresponding processing step:

Table 1 - Number of operations per processing of a coin data record in the terminal or

The issuing authority must be carried out; Further operations that are not listed here are required; Instead of the implementation mentioned, other implementations are conceivable which imply other operations

Table 1 above shows that for each coin data set, each of the processing operations “Create”, “Deactivate”, “Split”, “Connect” and “Switch” different operations “Create signature”; "Create random number";"CreateMask"; “Area checking” can be provided, each of the processing operations being registered in the monitoring instance 2. There it can be attached in unchangeable form to a list of previous processing operations for masked electronic coin data records Z _i . The operations of the processing “creating” and “deactivating” an electronic coin data set are only carried out in secure locations and / or only by selected entities, for example the issuer entity 1, while the operations of all other processing operations can be carried out on the terminals M1 to M3.

The number of operations for the individual processing is marked in table 1 with "0", "1" or "2". The number “0” indicates that the terminal or issuer instance 1 does not have to carry out this operation for this processing of the electronic coin data record. The number “1” indicates that the terminal or issuer instance 1 must be able to carry out this operation once for this processing of the electronic coin data record. The number “2” indicates that the terminal or issuer instance 1 must be able to carry out this operation twice for this processing of the electronic coin data record.

In principle, it can also be provided in one embodiment that an area check is also carried out by the issuer instance 1 during creation and / or deactivation. In the following table 2 the operations required for the monitoring instance 2 are listed for the individual processing:

Table 2 - Number of operations to be carried out per processing of a coin data set in the monitoring instance; Further operations that are not listed here are required; Instead of the listed

Implementation, other implementations are conceivable that imply other operations

All operations of table 2 can be carried out in the monitoring instance 2, which as a trustworthy instance, for example as a decentralized server, in particular a distributed trusted server, ensures sufficient integrity of the electronic coin data records.

Table 3 shows the components to be preferably installed for the system subscribers in the payment system of FIG. 1:

Table 3— Preferred units in the system components Table 3 shows an overview of the components to be preferably used in each system subscriber, that is to say the issuer instance 1, a terminal Ml and the monitoring instance 2. The terminal Ml can be used as a wallet for electronic coin data records, ie as an electronic purse, i.e. a data storage device for the terminal in which a large number of coin data records can be stored and implemented, for example in the form of an application on a smartphone or IT system of a retailer, a commercial bank or another market participant, and sending or receiving an electronic coin data record. Thus, the components in the terminal as shown in Table 3 are implemented as software. It is assumed that the monitoring instance 2 is based on a DLT and is operated by a number of trustworthy market participants.

FIG. 2 shows an exemplary embodiment of a monitoring instance 2 from FIG. 1. In FIG. 2, an exemplary database is shown in the form of a table in which the masked electronic coin data records Z _i and possibly - as shown here - their processing are registered. In the simplest embodiment of the database, however, only the currently valid masked coin data sets Z _{i would be} stored. The monitoring instance 2 is preferably arranged locally remotely from the terminals M1 to M3 and is accommodated, for example, in a server architecture.

Any processing operation _. for processing (creating, deactivating, splitting, connecting and switching) is registered in the monitoring instance 2 and appended there in unchangeable form to a list of previous processing operations for masked electronic coin data records Z _i . The individual operations or their test results, that is to say the intermediate results of processing, as it were, are recorded in the monitoring instance 2.

The processing operations "create" and "deactivate", which concern the existence of the monetary amount ty per se, i.e. the creation and destruction of money, require additional approval from the issuing authority 1 in order to be registered (and logged) in the monitoring authority 2 to become. The remaining processing operations (splitting, connecting, switching) do not require any authorization by the issuing instance 1 or by the command initiator (= payer, for example the first terminal M1).

A registration of the respective processing in the monitoring instance 2 is implemented, for example, by corresponding list entries in the database according to FIG. 2. Each list entry has further markings 25 to 28, which document the intermediate results of the respective processing carried out by the monitoring instance 2 have to. The markings 25 to 28 are preferably used as an aid and are discarded by the checking entity after the commands have been completed. What remains then are markings (not shown) about the validity of the (masked) electronic coin data records from columns 22a, 22b, 23a and / or 23b. When a processing command is received, the markings are in the state, for example and are set to the status "1" after all tests have been successfully completed and to the status "0" if at least one test has failed. A possible structure for a list entry of a coin data record includes, for example, two columns 22a, 22b for a previous coin data record (Ol, 02), two columns 23a, 23b for a successor coin data record (S1, S2), a signature column 24 for the issuer instance ( en) 1, and four marking columns 25 to 28. Each of the entries in columns 25 to 28 has three alternative states "1" or "0". Column 25 (O flag) indicates whether a validity check with regard to an electronic coin data record in column 23a / b was successful. The status “1” means that a validity check showed that the electronic coin data set in column 23a / b is valid and the status “0” indicates that a validity check showed that the electronic coin data set in column 23a / b is invalid and the status indicates that a validity check has not yet been completed. Column 26 (C flag) shows whether one calculation for checking the amount neutrality of the masked electronic coin data records was successful. The status "1" means that a calculation was successful and the status "0" indicates that the calculation was unsuccessful and the status indicates that the calculation is not yet completed.

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

Column 27 (R-Flag) shows whether a check of the area evidence or the area evidence was successful, where status "1" means that a validity check showed that the area evidence or the area evidence is or is traceable and the status " 0 "indicates that a validity check showed that the area evidence or the area evidence could not or could not be reproduced and the status" - "indicates that a validity check has not yet been completed. Column 28 (S flag) shows the successful verification of the signature. The status "1" means that a validity check showed that the signature could be identified as that of the publisher instance and the status "0" indicates that a validity check showed that the signature could not be identified as that of the publisher instance and the status indicates that this validity check has not yet been completed. A change in the status of one of the markings (also referred to as “flag”) requires approval by the monitoring instance 2 and must then be stored in the monitoring instance 2 in an unchangeable manner. Processing is final if and only if the required markings 25 to 28 have been validated by the monitoring instance 2, ie have changed from state “0” to state “1” or state “1” after the corresponding check.

In order to determine whether a masked electronic coin data set Z is valid, the monitoring instance 2 searches in the present variant for the last change which concerns the masked electronic coin data set. It applies that the masked electronic coin data set Z is valid if and only if the masked electronic coin data set Z for its last processing is listed in one of the successor columns 23a, 23b and this last processing has the corresponding final marking 25 to 28. It is also true that the masked electronic coin data set Z is valid if and only if the masked electronic coin data set Z is listed for its last processing in one of the preceding columns 22a, 22b and this last processing failed, i.e. at least one of the correspondingly requested States of the markings 25 to 28 is set to "0".

It also applies that the masked electronic coin data set Z is not valid for all other cases, for example if the masked electronic coin data set Z is not found in the monitoring instance 2; or if the last processing of the masked electronic coin data set Z is listed in one of the successor columns 23a, 23b, but this last processing never became final; or if the last processing of the masked electronic coin data set Z is in one of the preceding columns 22a, 22b and this last processing is final.

The checks by the monitoring entity 2 to check whether processing is final are shown in columns 25 to 28: The status in column 25 indicates whether the masked electronic coin data record (s) according to previous columns 22a, 22b are valid are. The status in column 26 indicates whether the calculation for amount neutrality, for example according to equation (10), is correct. The status in column 27 indicates whether the area evidence for the masked electronic coin data records Z could be checked successfully. 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 the issuer instance 1.

The status "0" in a column 25 to 28 indicates that the test was not successful. The status "1" in a column 25 to 28 indicates that the test was successful. The status in a column 25 to 28 indicates that no test has taken place. The conditions can also have a different value as long as it is possible to clearly differentiate between success / failure of a test and it is clear whether a certain test was carried out.

By way of example, five different processing operations are defined, which are explained in detail here. Reference is made to the corresponding list entry in FIG.

Processing is, for example, “generating” an electronic coin data record C _i . The generation in the direct transaction layer 3 by the issuer instance 1 includes the selection of a monetary amount v _i and the creation of a concealment amount n, as has already been described with equation (1). As shown in FIG. 2, no entries / markings are required in columns 22a, 22b, 23b and 25 to 27 during the “create” processing. The masked electronic coin data set Z _{i is} registered in the successor column 23a. This registration is preferably carried out before the transmission to a terminal M1 to M3, in particular or already during generation by the issuing entity 1, in which case equation (3) must be carried out in both cases. The masked electronic coin dataset Z _i is signed by the issuer instance 1 when it is created; this signature is entered in column 24 to ensure that the electronic coin dataset C _{i was} actually created by an issuer instance 1, although other methods are also possible. If the signature of a received Z _i matches the signature in column 24, the marking in column 28 is set (from “0” to “1”). The markings in columns 25 to 27 do not require a status change and can be ignored. The proof of area is not required, since the monitoring instance 2 trusts that the issuing instance 1 does not issue any negative monetary amounts. In an alternative embodiment, however, it can be sent by the issuer instance 1 in the create command and checked by the monitoring instance 2.

Processing is, for example, “deactivate”. The deactivation, that is to say the destruction of the money, causes the masked electronic coin data set Z; becomes invalid after the issuer instance 1 has successfully executed the deactivation command. The (masked) electronic coin data record to be deactivated can therefore no longer be processed in the accounting layer 4. In order to avoid confusion, the corresponding (unmasked) electronic coin data records C _{i should} also be deactivated in the direct transaction layer 3. When “deactivating”, the preceding column 22a is written with the electronic coin data set Z _i , but no subsequent column 23a, 23b is used. When deactivated, the masked electronic coin data set Z _i must then be checked whether the signature matches the signature according to column 24 in order to ensure that the electronic coin data set C _{i was} actually created by an issuer instance 1, again other means can be used for this test. If the signed Z _i , which is also sent in the deactivation command, can be confirmed as signed by the issuing instance 1, the marker 28 is set (from “0” to “1”). The markings according to columns 26 to 27 do not require a status change and can be ignored. The markings according to columns 25 and 28 are set after appropriate testing.

One processing is, for example, “splitting”. The division, that is, the splitting of an electronic coin data set Z _i into two electronic coin part data sets Z _j and Z _k is initially carried out in the direct transaction layer 3, as shown in FIG. 3, with the monetary amounts U _j and the concealment amount r _{j being} generated will. V _k and r _k result from equations (7) and (8). In the monitoring instance 2, the markings 25 to 27 are set, the preceding column 22a is written with the electronic coin data set Z _i , the next column 23a is written with Z _j and the next column 23b is written with Z _k . The status changes required in accordance with columns 25 to 27 take place after the corresponding check by the monitoring instance 2 and document the respective check result. The marking according to column 28 is ignored.

One processing is, for example, “Connect”. The connection, that is, the merging of two electronic coin data sets Z _i and Z _j to form an electronic coin data set Z _m, is initially carried out in the direct transaction layer 3, as shown in FIG. 4, the monetary amount v _m and. the concealment amount r _m can be calculated. The markings 25 to 27 are set in the monitoring instance 2, the preceding column 22a is written with the electronic coin data set Z _i , the preceding column 22b is written with Z _j and the succeeding column 23b is written with Z _m . The markings in columns 25 to 27 require status changes and monitoring instance 2 carries out the corresponding checks. Proof of area must be provided to show that no new money has been generated. The marking according to column 28 is ignored.

One processing is, for example, “toggle”. Switching is necessary when an electronic coin data record has been transmitted to another terminal and a renewed issue by the transmitting terminal (here Ml) is to be excluded. When switching, also called “switch”, the electronic coin data record C _{k received} from the first terminal Ml is exchanged for a new electronic coin data record C _i with the same monetary amount. The new electronic coin data record C _i is generated by the second terminal M2. This switching is necessary in order to invalidate (invalidate) the electronic coin data set C _{k received} from the first terminal Ml, which prevents the same electronic coin data set C _{k from being} output again. Because, as long as the electronic coin data record C _{k is} not switched, - since the first terminal Ml in Knowledge of the electronic coin data record C _k is - the first terminal Ml forward this electronic coin data record C _k to a third terminal M3. Switching takes place, for example, by adding a new concealment amount r _add to the concealment amount r _{k of} the electronic coin data record C _{k obtained} , as a result of which a concealment amount n is obtained which only the second terminal M2 knows. This can also take place in the monitoring instance 2. In order to prove that only a new concealment amount r _{add was added} to the concealment amount r _{k of} the masked electronic coin data set Z _{k obtained} , but the monetary amount remained the same, and thus equation (11):

V _k = VI (11) applies, then the second terminal M2 must be able to prove that Z ₁ -Z _{k can be represented} as a scalar multiple of G, i.e. as r _add * G. This means that only one concealment amount r _{add was} generated and the monetary amount of Z _{1 is} equal to the monetary amount of Z _k , i.e. Z _i = Z _k + r _add * G. This is done by generating a signature with the public key Z _i - Z _k = r _add * G.

In Fig. 3 an embodiment of a payment system according to the invention for splitting and switching of electronic coin data sets is shown. In Fig. 3, the first terminal Ml has received the coin data record C _i and would like to. Now carry out a payment transaction not with the entire monetary amount Ui, but only with a part V _{k of} it. For this purpose, the coin data set C _{i is} divided. To do this, the monetary amount is first divided:

Vi = Vj + Vk (12)

Each of the received amounts n _j , v _k , must be greater than 0, because negative monetary amounts are not permitted. In addition, new concealment amounts are derived: r _i - = r _j + r _k (13)

The masked coin data sets Z _j and Z _{k are then obtained} from the coin data sets Cj and C _{k in} accordance with equation (3) and are registered in the monitoring instance 2. For the division, the preceding column 22a is described with the coin data set Z _i , the successor column 23a with Z _j and the successor column 23b with Z _k . The markings in columns 25 to 27 require a status change and monitoring instance 2 carries out the corresponding checks. The marking according to column 28 is ignored. Then a coin data record, here C _k , is transmitted from the first terminal Ml to the second terminal M2. In order to prevent double spending, a switchover operation is useful in order to exchange the electronic coin data record C _{k received} from the first terminal M1 for a new electronic coin data record C _i with the same monetary amount. The new electronic coin data record C _i is generated by the second terminal M2. The monetary amount of the coin data set C _{i is} adopted and not changed, see equation (11). Then, according to equation (14), a new obfuscation amount r _{add is added} to the obfuscation amount r _{k of} the obtained electronic coin data record C _k ,

whereby a concealment amount n which only the second terminal M2 knows is obtained. In order to prove that only a new concealment amount r _{add was added} to the concealment amount r _{k of} the received electronic coin data record Z _k , but the monetary amount remained the same (v _k = v ₁ ), the second terminal M2 must be able to prove that Z ₁ -Z _{k can be represented} as a multiple of G. This is done by means of a public signature R _add according to equation (15):

where G is the generator point of the ECC. Then the coin data set C _{i to be switched is} masked by means of equation (3) in order to obtain the masked coin data set Z _i . In the monitoring instance 2, the private signature r _add can then be used, for example, to sign the masked electronic coin data set Z _i to be switched, which is proof that the second terminal M2 has only added a concealment amount r _add to the masked electronic coin data set and no additional ones monetary value, ie vi = Vk.

The proof is as follows:

Fig. 4 shows an embodiment of a payment system according to the invention for connecting electronic coin data sets. The two coin data sets C _i and C _j are received in the second terminal M2. Based on the division according to FIG. 3, a New coin data set Z _m obtained by adding both the monetary amounts and the concealment amount of the two coin data sets C _i and C _j . Then the received coin data set C _{m to be connected is} masked and the masked coin data set Z _m is registered in the monitoring instance.

In FIGS. 3 and 4, the variant of a database of the monitoring instance 2 is again shown, which contains a list of processing operations of the masked coin data records. Other variants of a database, for example masked coin data records with status or only valid masked coin data records, can also be used - as already mentioned in connection with FIG. 2.

FIGS. 5 to 7 each show an exemplary embodiment of a process flow diagram of a method 100 according to the invention. The two FIGS. 5 and 6 are explained together below.

Steps 101 to 104 are optional for the further method and are described using the example of the terminal M1. In the optional steps 101 and 102, a coin data record is requested and provided by the issuer instance 1 - here the first terminal M1 - after the electronic coin data record has been created. A signed, masked electronic coin data record is sent to the monitoring instance 2 in step 103. In step 103, the electronic coin data set C _i obtained is masked _in accordance with equation (3) and as explained in FIG. 1. Then in step 104 _. the masked electronic coin data set Z _{i is registered} in the monitoring instance 2. It could be provided that masked electronic coin data records are only valid in the monitoring instance when they are registered by a subscriber, such as a terminal or server. Alternatively, as explained in connection with FIG. 1, the masked electronic coin data set Z _{i can be registered} in the monitoring instance 2 as a valid masked electronic coin data set after step 102. Optionally, the terminal M1 can switch the received electronic coin data record with step 104, as will be described in more detail only in step 108.

In step 105, the coin data record C _i is transmitted in the direct transaction layer 3 to the second terminal M2. In the optional steps 106 and 107, a validity check is carried out with prior masking, in which case the monitoring instance 2 verifies the validity of the coin data set Z; or C _{i is} confirmed.

In step 108 a received coin data set C _k is switched over (the received coin data set C _i could of course also be switched over) to a new coin data set C _i , whereby the coin data set C _k becomes invalid and double dispensing is prevented. For this purpose, the monetary amount Ok of the transferred coin data set C _{k is used} as a “new” monetary amount DI used. In addition, as already explained with equations (14) to (17), the concealment amount n is created. The additional concealment amount r _add is used to prove that no new money (in the form of a higher monetary amount) was generated by the second terminal M2. Then, among other things, the masked coin data set Z _i to be switched is sent to the monitoring instance 2 and the switching from C _k to C _{i is} instructed.

In step 108 'the corresponding check is carried out in the monitoring instance 2. Z _{k is} entered in column 22a according to the table in FIG. 2 and the coin data set Z _{i to be} rewritten is entered in column 23b. A check then takes place in the monitoring instance 2 as to whether Z _{k is} (still) valid, i.e. whether the last processing of Z _{k is} entered in one of the columns 23a / b (as proof that Z _{k is} not further divided or deactivated or connected) and whether a check for the last processing failed. In addition, Z _{i is} entered in column 23b and the markings in columns 25, 26, 27 are initially set to “0”. A check now takes place as to whether Z _{i is} valid, in which case the check according to equations (16) and (17) can be used. If the case is good, the marking in column 25 is set to “1”, otherwise to “0”. A check now takes place, the calculation according to equation (10) shows that Z _k and Z _{i are} valid and the marking in column 26 is set accordingly. It is also checked whether the areas are conclusive, then the marking in column 27 is set. If all three checks were successful, and this was accordingly fixed in the monitoring instance 2, the coin data set is considered to be switched. In other words, the coin data set C _k is no longer valid and the coin data set C _{i is} valid from now on. A double dispensing is no longer possible if a third terminal M3 asks the monitoring instance 2 about the validity of the (doubly dispensed) coin data record.

As a rule - in contrast to the illustration in FIG. 5 - the electronic coin data records C _i created by the issuer instance are transmitted (issued) to an instance (such as server, computer ...) of a commercial bank. The (server) instance of the commercial bank provides the electronic coin data records for end devices. The terminal M1 requests and then receives the electronic coin data record from the entity of the commercial bank in steps 101 and 102. In particular, when the terminal M1 requests and receives the electronic coin data record C _i from a server of a commercial bank, switching already in step 104 makes sense.

In step 109, two coin data sets C _k and C _{i are} linked to form a new coin data set C _m , whereby the coin data sets C _k , C _{i become} invalid and double dispensing is prevented. For this purpose, the monetary amount v _{m is formed} from the two monetary amounts v _k and v _i . For this purpose, the concealment amount r _{m is} derived from the two Concealment amounts r _k and formed. In addition, the masked coin data set to be connected is obtained by means of equation (3) and this (together with other information) is sent to the monitoring instance 2 and the connection is requested as processing.

In step 109 ', the corresponding check takes place in the monitoring instance 2. Z _{m is} entered in column 23b according to the table in FIG. The monitoring instance 2 then checks whether Z _k and Z _{i are} (still) valid, i.e. whether the last processing of Z _k or Z _{i is} entered in one of columns 23a / b (as evidence that Z _k and Z _{i have} not been further split or deactivated or connected) and whether a check for the last processing failed. In addition, the markings in columns 25, 26, 27 are initially set to "0". A check now takes place as to whether Z _{m is} valid, in which case the check according to equations (16) and (17) can be used. If the case is good, the marking in column 25 is set to “1”, otherwise to “0”. A check is now carried out, the calculation according to equation (10) shows that Z _i plus Z _{k is} equal to Z _m and the marking in column 26 is set accordingly. It is also checked whether the areas are conclusive, then the marking in column 27 is set.

In step 110, a coin data set C _{i is divided} into two coin part data sets C _k and C _j , whereby the coin data set C _{i is made} invalid and the two divided coin part data sets are to be made valid. For this purpose, the monetary amount v _{i is divided} into the two monetary amounts v _k and v _j . For this purpose, the concealment amount r _{i is divided} into the two concealment amounts r _k and r _j . In addition, the masked partial coin data sets Z _k and Z _j are obtained by means of equation (3) and these are sent with further information, for example the area checks, to the monitoring instance 2 and the division is requested as processing.

In step 110 ′, the corresponding check takes place in the monitoring instance 2. In this case, Z _j and Z _{k are} entered in columns 23a / b according to the table in FIG. A check then takes place in the monitoring instance 2 as to whether Z _{i is} (still) valid, i.e. whether the last processing of Z _{i is} entered in one of the columns 23a / b (as proof that Z; is not further divided or deactivated or connected) and whether a check for the last processing failed. In addition, the markings in columns 25, 26, 27 are initially set to "0". A check now takes place as to whether Z _j and Z _{k are} valid, in which case the check according to equations (16) and (17) can be used. If the case is good, the marking in column 25 is set to "1". A check is now carried out, the calculation according to equation (10) shows that Z _{i is} equal to Z _k plus Z _j and the marking in column 26 is set accordingly. It is also checked whether the areas are conclusive, then the marking in column 27 is set. 7 shows an overview once again of the method steps 101-110 'in one sequence. From the point of view of the second terminal M2, an electronic coin data set is received 105, which was registered 104 by the terminal Ml. With this electronic coin data set, another (modified) electronic coin data set is generated and masked 108-110 for switching, connecting or dividing. The corresponding registration request is sent to the monitoring instance, which receives it and processes it 108'-110 '. Refinements for these steps and for the steps shown in dashed lines that are optional in the various variants have already been adequately described. Within the scope of the invention, all elements described and / or drawn and / or claimed can be combined with one another as desired.

REFERENCE LIST

Claims

PATENT CLAIMS

1. Method (100) for the direct transmission of an electronic coin data set (C _i , C _j ,

C _k , C _m , C _i ) between a first and a second terminal (Ml, M2), with the steps through the second terminal (M2):

- Receiving the electronic coin data set (C _i ; C _j ; C _k ) from the first terminal (Ml), the at least one electronic coin data set (C _i ; C _j ; C _k ) having a monetary amount (v _i , v _j , v _k ) and has a concealment amount (r _i , r _j , r _k );

- generating a modified electronic coin data set (C _j , C _k ; C _m ; C ₁ ) using the received electronic coin data set (C _i ; C _i , C _j ; C _k );

- Masking of the modified electronic coin data set (C _j , C _k ; C _m ; C _i )

Applying a homomorphic one-way function (f (C)) to the modified one

electronic coin data set (C _j , C _k ; C _m ; C _i ) for obtaining a masked, modified electronic coin data set (Z _j , Z _k ; Z _m ; Z _i ); and

- Sending a registration request for the masked modified electronic coin data set (Z _j , Z _k ; Z _m ; Z _i ) to a monitoring entity (2).

2. The method (100) according to claim 1, wherein the registration request as to

registering masked electronic coin data record the masked modified electronic coin data record (Z _j , Z _k ; Z _m ; Z _i ) and as a registered masked electronic coin data record a masked received electronic coin data record (Z _i ^* , Z _j ^* , Z _k ^* ) for the received electronic Coin data record (C _i ; C _j ; C _k ) comprises, and in particular a registration request for switching, splitting or connecting masked

electronic coin data records is.

3. The method (100) according to claim 1 or 2, wherein in the step of generating

- the modified electronic coin data set (C _j , C _k ; C _m ; C _i ) to be switched is generated from the received electronic coin data set (C _i ; C _i , C _j ; C _k ), or

- the received electronic coin data set (C _i ) is divided into at least two divided modified electronic coin data sets (C _j ; C _k ), or

- the received electronic coin data set (C _i ) as a first electronic coin data set and at least one second electronic coin data set (C _j ) to the connected, modified one electronic coin data set (C _m ) are connected; and

the registration requirement includes in particular:

- at least two masked split modified electronic ones to be registered

Coin data sets, or

- at least two registered masked electronic coin data sets.

4. The method (100) according to any one of claims 1 to 3, wherein in the step of generating:

- The received electronic coin data set (C _k *) is switched to the modified electronic coin data set (C ₁ ), wherein

o a concealment amount (n) for the modified electronic coin data set (C ₁ ) is generated using a received concealment amount (r _k ^* ) of the received electronic coin data set (C _k ^* ), and

o the received monetary amount (n _k ^* ) of the received electronic

Coin data set (C _k ^* ) as a monetary amount (ui) for the modified

electronic coin data set (C _i ) is used; or

- The received electronic coin data set (C _i ^* ) in at least two electronic

Coin part data sets (C _j , C _k ) is divided, where

o the monetary amount received corresponds to the sum of the monetary amounts (n _j , v _k ) of the at least two electronic coin part data sets (C _j , C _k ), and

o in particular the sum of the concealment amounts (r _j r _k ) of the at least two electronic coin part data sets (C _j , C _k ) corresponds to the concealment amount (r, ^* ) of the received electronic coin data set (C _i ^* ); or

- The received electronic coin data set (C _i ^* ) are linked as a first electronic coin data set and at least one second electronic coin data set (C _i ; C _j ) to form the modified, linked electronic coin data set (C _m )

o Compute a concealment amount (r _m ) for the modified electronic

Coin data set (C _m ) by forming the sum of the respective

Obfuscation amounts (n ^* , r _j ^* ) of the first and second electronic

Coin data set, and

o Calculate the monetary amount (v _m ) for the modified electronic

Coin data set (C _m ) by forming the sum of the respective monetary amounts (v _i ^* , v _j *) of the first and second electronic coin data sets (C _i ^* ; C _j ^* ).

5. The method (100) according to any one of claims 1 to 4, with masking (106) the received electronic coin data set (C _i ^* , C _j ^* , C _k ^* , C _i ^* , C _m ^* ) by applying the homomorphic one-way function ( f (C)) on the received electronic coin data set (C _i ^* , C _j ^* , C _k ^* , C _i ^* , C _m ^* ) to obtain the masked received electronic coin data set (Z ^* , Z _j ^* , Z _k ^* , Z ₁ *, Z _m *).

6. The method (100) according to any one of claims 1 to 5, wherein the monitoring entity (2) stores valid, masked electronic coin data sets (Z _i , Z _k ; Z _k ) for electronic coin data sets (C _i ; C _j ; C _k ), so that the second terminal has the validity of a received

electronic coin data set (C _i ^* , C _j ^* , C _k ^* , C ₁ ^* , C _m ^* ) by using the masked received electronic coin data set (Z _i ^* , Z _j ^* , Z _k ^* , Z ₁ , Z _m ^* ) to the monitoring instance (2).

7. The method (100) according to any one of the preceding claims, further comprising a step of creating evidence that the monetary amount (v _i ^* , Vj *, Vk *) of the received electronic coin data set (C _i ^* , Cj ^* , C _k ^* , C _i ^* , C _m ^* ) is equal to the monetary amount (vi) of the electronic coin data set to be switched.

8. Method in a monitoring instance (2) which stores valid, masked electronic coin data sets (Z _i , Z _k ; Z _k ) which are obtained by applying a homomorphic one-way function (f (C)) to an electronic coin data set (C _i ; C _j ; C _k ) are formed, electronic coin data sets (C _i ; C _j ; C _k ) having a monetary amount (v _i , v _j , n _k ) and a concealment amount (r _i , r _j , r _k ) with which Steps:

- Receiving a registration request which comprises at least one masked electronic coin data set to be registered (Z _j , Z _k ; Z _m ; Z _i ) and at least one registered masked electronic coin data set (Z _i , Z _j ; Z _k );

- Checking the registration request received, where

o it is checked whether the registered masked electronic coin data set (Z _i , Z _j ; Z _k ) of the registration request is stored as a valid masked electronic coin data set (Z _i , Z _k ; Z _k ) in the monitoring instance, and

o it is checked whether the masked electronic coin data sets (Z _j , Z _k ; Z _m ; Z _i ) of the registration request are monetarily value-neutral overall;

9. The method according to claim 8, wherein the checking of the monetary amount neutrality of the registration request - due to the homomorphic one-way function used - takes place anonymously by forming the difference from the masked electronic coin data records.

10. The method according to claim 8 or 9, wherein the monitoring entity (2) receives creation and / or deactivation requests from an issuing entity (1), in particular for an electronic coin dataset (C _i ) newly issued by the issuing authority (1) or one by the issuing authority (1)

withdrawn electronic coin data record (C _i ).

11. Y experience (100) according to claim 10, wherein the creation and / or

Deactivation request for a masked electronic coin data record (Zf) one

Signature ([ZJSigi) of the issuer on the masked electronic coin data set (Z _i ), preferably the signature ([ZJSigr) of the masked, newly created

electronic coin data set (Z _i ) is stored in the monitoring instance (2).

12. The method (100) according to any one of the preceding claims, wherein an electronic coin data record (C _i ) by marking or deleting the corresponding masked

electronic coin data set (Z _i ) in the monitoring instance (2) becomes invalid, whereby preferably the corresponding masked electronic coin data set (Z _i ) or the corresponding electronic coin data set (C _i ) is deactivated in the issuing instance (1).

13. The method (100) according to any one of the preceding claims, wherein the

Monitoring instance (2) is a decentrally controlled database, English Distributed Ledger Technology, DLT, in which the masked electronic coin data sets (Z _i , Z _j , Z _k , Z _m , Z _i ) with corresponding processing information of the masked electronic coin data set (Z _i , Z _j , Z _k , Z _m , Z _i ) are registered.

14. Payment system for the exchange of monetary amounts, in which a method according to one of the preceding claims 1 to 13 is carried out, the payment system comprising:

- A monitoring layer (4) with a database, which is preferably controlled in a decentralized manner, in which valid masked electronic coin data records (Z _i ) for electronic coin data records (C _i ) are stored; and

- A direct transaction layer (3) with at least two terminals (Ml, M2, M3) which exchange electronic coin data sets (C _i ).

15. Currency system, comprising an issuer entity (1), a monitoring entity (2), a first terminal (Ml) and a second terminal (M2, M3), the issuer entity being designed to create an electronic coin data record (C _i ), wherein the monitoring instance (2) is designed to carry out a method according to one of claims 8 to 14 and / or the first and second terminals (Ml, M2, M3) are designed to carry out a method according to one of claims 1 to 7.

16. The currency system according to claim 15, wherein only the issuing authority (1) is authorized to create a new electronic coin data set (C _i ) to be issued, the issuer instance (1) preferably providing a masked created electronic coin data set (Z _i ) with a signature ([Z _i ] Sigi) and the monitoring instance (2) providing the masked one created electronic coin data set (Z _i ) and the signature ([Z _i JSigi) sends.

17. The currency system according to claim 15 or 16, wherein the monitoring entity (2) for masked electronic coin data records executes creation and / or deactivation requests of the issuer entity (1) and registration requests for masked modified electronic coin data records of other entities, such as the two terminals.

18. Currency system according to one of claims 15 to 17, wherein the currency system comprises further coin owner instances, in particular server instances, which transmit electronic coin data sets (C _i ) directly, in particular among each other or from / to end devices, and which are used for masked modified electronic coin data sets (Z _i ) Send registration requests to the monitoring authority (2).

19. Currency system according to one of claims 15 to 18, wherein steps are carried out by the second terminal in that the steps are carried out in the terminal or in that the terminal calls a terminal service, which in particular the steps of generating, masking and / or sending for the Device executes.

20. Currency system according to one of claims 15 to 19, wherein in the checking instance (2) the masked electronic coin data record (Z _j , Z _k , Z _m , Z _i ) is recognized as valid when the masked electronic coin data record (Zj, Z _k , Z _m , Z _i ) or its predecessor originates from the issuing authority (1), in particular the issuer signature ([Z _i JSigi) created masked electronic coin data records being stored in the monitoring authority (2).

21. Currency system according to one of claims 15 to 20, wherein the checking instance (2) and the issuing instance (1) are implemented as a server instance, in particular as a computer program product on a server and / or a computer.

22. Currency system according to one of claims 15 to 21, wherein the first and / or second terminal (Ml, M2, M3) as a mobile terminal, in particular as a smartphone, a tablet computer, a computer, a machine, and / or as passive terminal, in particular smart card or wearable, are formed.