METHOD FOR DIRECTLY TRANSFERRING ELECTRONIC COIN DATA SETS BETWEEN TERMINALS, PAYMENT SYSTEM, CURRENCY SYSTEM AND MONITORING UNIT

Abstract

A method is provided for directly transmitting electronic coin datasets between terminals in order to make a payment in a payment system. A first terminal has at least one electronic coin dataset, and the at least one electronic coin dataset has a monetary value and a concealment value as coin data set elements. The method has the steps of: masking a first coin dataset element of the electronic coin dataset to the first coin dataset element of the electronic coin dataset, to obtain a masked electronic coin dataset element; adding a second coin dataset element of the electronic coin dataset to the semi-masked electronic coin dataset, in order to obtain a semi-masked electronic coin dataset; and transmitting the semi-masked electronic coin dataset to a monitoring entity in order to register the electronic coin dataset.

Description

TECHNICAL FIELD OF THE INVENTION

The invention relates to a method for directly transferring electronic coin data sets between terminals. Further, the invention relates to a payment system for exchanging monetary amounts and a currency system.

TECHNICAL BACKGROUND OF THE INVENTION

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

Traditional blockchain-based payment transactions, such as Bitcoin, present a high level of integrity protection. When electronic coin data sets, or “coins,” change hands in a blockchain technology, a lot of information is made public. Thus, such payment transactions and especially the exchanged data are not completely confidential. In addition, the payment transactions are very computationally intensive and thus energy-intensive.

Therefore, conventionally, instead of the confidential data, only the hash values of the confidential data are often stored in a blockchain ledger. The corresponding plaintext data must then be managed outside the blockchain. So far, such concepts are not applicable to electronic coin data sets because they do not have basic control functions, in particular (1) the detection of multiple spending methods, also called double spending, and (2) the detection of uncovered payments. In case (1) someone tries to spend the same coin data set multiple times and in the second case someone tries to spend a coin data set although he has no credit (anymore).

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 manipulation security is provided, are known from DE 10 2009 038 645 A1 and DE 10 2009 034436 A1, although complex structures and elaborate encryption and signing processes are required here during exchange. These have proved to be of little practical use.

WO 2016/200885 A1 describes a method for encrypting an amount transacted in a blockchain ledger, while obtaining the verifiability of the transaction. Therein an obfuscation amount is added to an input value. Then an output value is generated and encrypted. Both the input value and the output value are within a range of values, where a sum of any two values within the range does not exceed a threshold. The sum of the encoded input value and the encoded output value can be zero. Range checks, called range proofs, are associated with each of the input values and the output value. These range proofs prove that the input value and the 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. In this method, blockchain technology is required to be called after obtaining a coin data set to validate the coin data set.

It is an object of the present invention to provide a method and a system in which a payment transaction is secure yet simple. In particular, this is to create a direct payment between devices, such as tokens, smartphones but also machines, such as point-of-sale terminals or vending machines, that is anonymous. The coin data sets are to be able to be used immediately after obtaining them in order to enable payment even without a connection to an online entity, such as a DLT. Multiple coin data sets shall be able to be combined and/or split at the user's convenience to allow flexible exchange. The exchanged coin data sets shall on the one hand be confidential towards other system participants, but on the other hand allow each system participant to perform basic monitoring checks, in particular the detection of multiple spending attempts and the detection of attempts to pay with non-existing amounts. In the future, it should be possible to dispense with cash (banknotes and analogue coins) altogether, or at least with analogue coins.

Modification, e.g., splitting, combining or switching of electronic coin data sets, should be carried out without high computing costs and with a minimum of data volume for transferring the coin data sets. The verification of the modification should be able to be done securely without costly proofing of corresponding validity (range proofs), in order to increase the degree of flexibility and thus the user-friendliness.

SUMMARY OF THE INVENTION

The tasks posed are solved with the features of the independent claims. Further advantageous embodiments are described in the dependent claims.

The task is solved in particular by a method for directly transferring electronic coin data sets between terminals for payment in a payment system, wherein a first terminal has at least one electronic coin data set, wherein the at least one electronic coin data set has a monetary amount and an obfuscation amount as coin data set elements, comprising the steps: masking a first coin data set element of the electronic coin data set, preferably in the first terminal, by applying a one-way function, which is for example homomorphic, to the first coin data set element of the electronic coin data set, preferably to its obfuscation amount, to obtain a masked first electronic coin data set element; adding a second coin data set element of the electronic coin data set to the masked first electronic coin data set element, preferably in the first terminal, for obtaining a quasi-masked electronic coin data set; and transmitting the quasi-masked electronic coin data set to a monitoring entity for registering the electronic coin data set.

Thus, in an intermediate result, a masked coin data set element is calculated (obtained) and then expanded with a coin data set element of the coin data set.

The coin data set element to be added is unmasked. It can be taken directly from the corresponding coin data set in one embodiment of the method. It is added to the fully masked coin data set and can be read, extracted and/or interpreted without unmasking the coin data set.

The first coin data set element of the masking step is different from the second coin data set element of the adding step.

This method ensures that the electronic coin data set is not transmitted to the monitoring entity in a disclosed manner, but that verification can still be performed in the monitoring entity with sufficient certainty.

The adding is performed by an appropriate (logical) operation. This operation adds the masked first electronic coin data set element and the second coin data set element of the coin data set together. This creates a new data set, namely the quasi-masked electronic coin data set. Adding is also referred to as concatenation or linkage or appending, for example. A data structure, such as TLV, may also be provided to combine the masked first electronic coin data set element and the second coin data set element of the coin data set to form the quasi-masked electronic coin data set.

In a preferred embodiment, the first coin data set element of the masking step is the obfuscation amount of the electronic coin data set. The obfuscation amount is a secret to the monitoring entity and is only known in a direct transaction layer between those participants that transfer the coin data set to each other.

In a preferred embodiment, the added (second) coin data set element is the monetary amount of the electronic coin data set. Thus, a partial amount masked electronic coin data set is obtained as the quasi-masked electronic coin data set. With such a quasi-masked electronic coin data set, the monetary amount can be read and interpreted immediately without any further decryption or unmasking steps. Thus, parts of the quasi-masked electronic coin data set are transferred and registered openly (amount part open), while other parts are transferred masked and registered. The method thus remains anonymous and secure, but the monetary amounts transferred can be tracked and registered at any time. The payment process thus remains anonymous, although the amount transfers are transparent.

In a preferred embodiment, the added (second) coin data set element is a higher-value amount portion of the monetary amount of the electronic coin data set, which is locally split into the higher-value amount portion and a lower-value amount portion, whereby an electronic coin data set that is only partially amount open with respect to the higher-value amount portion is obtained as the quasi-masked electronic coin data set. With such an electronic coin data set, the higher-value amount portion can be read and interpreted immediately without any further decryption or unmasking steps. Thus, the method remains anonymous and, moreover, it is not openly available which monetary amounts are transferred between the participating units; the monetary amounts transferred can, for all intents and purposes, be tracked and registered at any time. The payment process is thus still anonymous, although the amount transfers are semi-transparent.

Preferably, the quasi-masked electronic coin data set is then masked only with respect to the lower-value amount portion.

The higher-value amount portion represents a portion of the monetary amount that is greater than the portion of the monetary amount that represents the lower-value amount portion. For example, higher-value digits of a (second) coin data set element representing the monetary amount, such as one or more “most-significant bits, MSB”, may be transferred transparently. Remaining lower-value digits of the data element representing the monetary amount are masked.

In a preferred embodiment, the method further comprises: determining a masking mode from at least two masking modes, wherein in a first masking mode the quasi-masked electronic coin data set is transmitted to the monitoring entity for the purpose of registration, and in a second masking mode the electronic coin data set, preferably in the first terminal, is masked by applying a one-way function, for example homomorphic, to the electronic coin data set for obtaining a fully masked electronic coin data set, and the fully masked electronic coin data set is transmitted to the monitoring entity for the purpose of registration. This makes a masking type selectable and configurable. In the payment system, it can thus be determined per transmission process and/or in general with which degree of anonymity the coin data sets are to be registered.

When using the second masking mode, the add step is omitted and no unmasked coin data set element is included or added in the masked coin data set.

In a preferred embodiment, the method comprises a third masking mode comprising: splitting the monetary amount of the electronic coin data set by place value, preferably in the first terminal, into a first monetary amount part and a second monetary amount part, wherein the base of the place value is arbitrary: masking the first monetary amount part of the monetary amount of the electronic coin data set, preferably in the first terminal, by applying the one-way function to the first monetary amount part of the monetary amount of the electronic coin data set to obtain a masked first monetary amount part and adding (only) the second monetary amount part to obtain a partially amount-masked (hereinafter also referred to as partially masked) electronic coin data set. The place value is selected either based on a default value predetermined throughout the process, or randomly, or according to a choice made by the terminal.

In one embodiment of the third masking mode, the one-way function is applied to a concatenation (linkage) of obfuscation amount and first monetary amount part of the electronic coin data set to obtain a masked concatenation of obfuscation amount and first monetary amount part (as masked first coin data set). The second amount part is added to this masked concatenation to obtain the partially amount-masked electronic coin data set.

In a preferred embodiment, depending on the determined masking mode, the step of registering is either registering the fully masked electronic coin data set (for the second masking mode) or the quasi-masked electronic coin data set (for the first masking mode) the partially amount-masked electronic coin data set in the monitoring entity (for the third masking mode).

The determination or selection of the masking mode can be predefined in the method, for example by the monitoring entity or a third-party provider (wallet provider). This would provide a method in which the masking mode is fixed.

Alternatively, the step of determining could be done by selecting the masking mode in the first terminal. This would provide an agile method in which the respective terminal determines or selects the masking mode itself, or provides a user of the terminal with a means to select it. Determining the masking mode would then be possible, for example, per transfer process, so that the transfer is based, for example, on whether or not the recipient of the coin data set is known and validated in the payment system.

In a preferred embodiment, a parameter for determining the masking mode is specified by the monitoring entity or a service provider. Preferably, the terminal then selects the masking mode based on this parameter. Thus, a terminal is set up to decide which masking mode is selected or determined on the basis of the parameter depending on the situation. A parameter for specifying the masking mode could be, for example, a minimum computing power of the terminal or a maximum time period for masking and registering the coin data set or a degree of secrecy for the coin data set. In particular, this may allow another terminal different from the first terminal to select a different masking mode to comply with the default parameter.

In a preferred embodiment, the terminal changes from one (first used) masking mode to a (subsequent) different masking mode for an electronic coin data set. This provides interoperability between a fully masked, a quasi-masked, and a partially amount-masked electronic coin data set, thereby increasing transfer flexibility.

For example, a quasi-masked coin data set can be combined with a fully masked electronic coin data set. This could be done by switching (“switch”) the fully masked coin data set to a quasi-masked coin data set or vice versa.

The steps described here do not have to be performed in the order described. However, the sequence described herein is a preferred embodiment.

An electronic coin data set is an electronic data set represented by coin data set elements. In particular, it is an electronic data record that represents a monetary amount and is also colloquially referred to as a “digital coin” or “electronic coin”. This monetary amount changes in the method from a first terminal to another terminal for payment (of a purchase price or a return money) in the payment system. In the following, a monetary amount as a coin data set element is understood as a digital amount that can be credited to an account of a financial institution, for example, or can be exchanged for another means of payment. An electronic coin data set thus represents cash in electronic form.

The terminal may have a plurality of electronic coin data sets, for example, the plurality of coin data sets may be stored in a data memory of the terminal. The data memory then represents, for example, an electronic wallet. For example, the data memory may be internal, external, or virtual. In one embodiment, when an electronic coin data set is received, “combining” may occur automatically so that preferably only one (or a certain number of) electronic coin data set(s) are stored in the terminal.

For example, the terminal may be a passive device such as a token, a mobile terminal such as a smartphone, a tablet computer, a computer, a server, or a machine.

An electronic coin data set for transferring monetary amounts is substantially different from an electronic data set for exchanging or transferring data, for example, because a traditional data transaction is based on a question-answer principle or on intercommunication between the data transfer parties. An electronic coin data set, on the other hand, is unique and stands in the context of a security concept, which can comprise signatures or encryption, for example. In principle, an electronic coin data set includes all the data required by a receiving entity for verification, authentication and forwarding to other entities. Intercommunication between terminals during exchange is therefore basically not required for this type of data set.

Preferably, the electronic coin data set is transferred from the first terminal to a second terminal as part of a payment process.

According to the invention, an electronic coin data set used for transfer between two terminals has a monetary amount as a coin data set element representing a monetary value of the electronic coin data set and an obfuscation amount, as a coin data set element, for example a random number. In addition, the electronic coin data set may have other coin data set elements, such as metadata, representing, for example, a currency of the monetary amount or an identifier of the coin data set. An electronic coin data set is uniquely represented by these at least two coin data set elements (monetary amount and obfuscation amount). Anyone who has access to these at least two coin data set elements of a valid electronic coin data set can use this electronic coin data set for payment. Thus, knowing these two coin data set elements (monetary amount and obfuscation amount) is equivalent to owning the digital money. This electronic coin data set is transferred directly between two terminals. In one embodiment of the invention, an electronic coin data set consists of these two coin data set elements, thus only the transfer of the monetary amount and the obfuscation amount is required to exchange digital money.

A corresponding masked electronic coin data set and/or masked first coin data set element is associated with each electronic coin data set. This masked electronic coin data set may be a fully masked electronic coin data set (second masking mode) or a quasi-masked electronic coin data set (first masking mode) or a partially amount-masked electronic coin data set (third masking mode).

A fully masked electronic coin data set (second masking mode) is a masked electronic coin data set whose entirety of coin data set elements is masked. In particular, the fully masked electronic coin data set does not comprise any unmasked data set element. No (unmasked) data set element of the electronic coin data set can be directly extracted, read and/or interpreted from the fully masked electronic coin data set.

A quasi-masked electronic coin data set (second masking mode) is a masked electronic coin data set in which at least one (first) coin data set element of the (unmasked) electronic coin data set is included in cryptographically encrypted form. The quasi-masked electronic coin data set is obtained by applying a one-way function, such as a cryptographic encryption function, to at least one of the coin data set elements, preferably the obfuscation amount, and adding an unmasked second coin data set element. Thus, in addition to the encrypted first coin data set element, the quasi-masked electronic coin data set particularly also comprises at least a second unmasked coin data set element, in particular the monetary amount as the second coin data set element. From the quasi-masked electronic coin data set, at least one (unmasked) coin data set element of the electronic coin data set can be extracted directly. The unmasked coin data set element may be added to the masked coin data set element to obtain the quasi-masked coin data set.

A partially amount-masked electronic coin data set (third masking mode) is a masked electronic coin data set in which at least a first monetary amount part of the monetary amount of the electronic coin data set is included in masked, for example cryptographically encrypted, form and a second monetary amount part of the monetary amount of the electronic coin data set is included in open (unmasked) form. The partially amount-masked electronic coin data set therefore also comprises an unmasked coin data set sub-element, in particular the second monetary amount part. The first monetary amount part and the second monetary amount part have been obtained by splitting the monetary amount of the electronic coin data set by place value, see further explanation of place value and basis given below. The second monetary amount part is added unmasked to the masked first monetary amount part of the monetary amount. Accordingly, at least the second monetary amount part of the electronic coin data set can be taken directly from the partially amount-masked electronic coin data set.

In the partially amount-masked electronic coin data set, preferably determining the place value for splitting the monetary amount into the first amount part and the second amount part becomes variable depending on the transaction. Thus, the verification of a received coin data set is dependent on the knowledge of the determined place value. This defined place value is either transferred between the terminals or subscriber units during the transaction or stored in the register.

In the following, the term “masked electronic coin data set” will always be used for simplified purposes if a statement applies equally to both a fully masked electronic coin data set and a quasi-masked electronic coin data set as well as a partially amount-masked electronic coin data set.

Knowledge of a masked electronic coin data set does not authorize the issuance of the digital money represented by the electronic coin data set. This represents a key difference between masked electronic coin data sets and (non-masked) electronic coin data sets and is a core feature of the present invention. The masked electronic coin data set is unique and uniquely associated with an electronic coin data set, thus there is a 1-to-1 relationship between the (non-masked) electronic coin data set and the masked electronic coin data set. Masking of the electronic coin data set is preferably performed by a computing unit of the terminal within the terminal that also has the at least one electronic coin data set. Alternatively, masking may be performed by a computing unit of the terminal receiving the electronic coin data set.

The masked electronic coin data set is obtained by applying a one-way function, such as a homomorphic one-way function, such as a cryptographic function. This function is a one-way function, that is, a mathematical function that is “easy” to compute in terms of complexity theory, but “difficult” to practically impossible to reverse. Here, the term one-way function is also used to describe a function for which no inversion is known that can be practically executed in a reasonable amount of time and with a reasonable amount of effort. Thus, calculating a masked electronic coin data set from an electronic coin data set is comparable to or equivalent to generating a public key in an encryption process via a residue class group. Preferably, a one-way function is used that operates on a group in which the discrete logarithm problem is difficult to solve, such as a cryptographic method analogous to elliptic curve encryption, or ECC, from a private key of a corresponding cryptographic method. The reverse function, i.e. the generation of an electronic coin data set (or the part of the electronic coin data set) from a masked electronic coin data set is thereby—equivalent to the generation of the private key from a public key in an encryption procedure via a residue class group—very time-consuming. When sums and differences or other mathematical operations are referred to in the present document, they are to be understood in the mathematical sense as the respective operations on the corresponding mathematical group, for example the group of points on an elliptic curve.

In one embodiment, the one-way function is homomorphic, i.e., a cryptographic method that has homomorphism properties. Thus, mathematical operations can be performed on the masked electronic coin data set that can also be performed in parallel on the (unmasked) electronic coin data set and thus be traced. Using the homomorphic one-way function, calculations with masked electronic coin data sets can be traced in the monitoring entity without the corresponding (unmasked) electronic coin data sets being known there. Therefore, certain calculations with electronic coin data sets, for example for a modification of the (unmasked) electronic coin data set (for example splitting or combining), can also be proven in parallel with the corresponding masked electronic coin data sets, for example for validation checks or for monitoring about the legitimacy of the respective electronic coin data set. The homomorphism properties apply at least to addition and subtraction operations, so that a split or combine (=combine) of electronic coin data sets can also be recorded by means of the corresponding masked electronic coin data sets in the monitoring entity and can be traced by requesting terminals and/or by the monitoring entity without gaining knowledge about the monetary amount and the performing terminal.

The homomorphism property thus allows a record of valid and invalid electronic coin data sets based on their masked electronic coin data sets to be maintained in a monitoring entity without knowledge of the electronic coin data sets, even if those electronic coin data sets are modified (split, combined, switched). This ensures that no additional monetary amount has been created or that an identity of the terminal is held in the monitoring entity. Masking enables a high level of security without providing visibility into the monetary amount or the terminal. This results in a two-layer payment system. On the one hand, there is the processing layer, in which masked electronic data sets are checked, and on the other hand, there is the direct transaction layer, in which at least two terminals transfer electronic coin data sets.

In a further embodiment, the one-way function is a cryptographic encryption function.

Applying the one-way function to the electronic coin data set also comprises applying the one-way function to a portion of the electronic coin data set, in particular to the obfuscation amount and/or an amount portion of the monetary amount, in one embodiment only to the obfuscation amount (quasi-masked), in another embodiment only to the first amount portion of the monetary amount (partially amount-masked), in a combined embodiment to a concatenation of the obfuscation amount and the first amount portion of the monetary amount.

Obtaining the quasi-masked electronic coin data set is performed by applying a cryptographic obfuscation function to a coin data set element (preferably the obfuscation amount) of the (unmasked) electronic coin data set. The obfuscation amount (as a secret element) can be used as a dynamic key for encryption. The obfuscation amount cannot be used as a key for decryption.

When transferring an electronic coin data set from the first terminal to the second terminal, two terminals have knowledge of the electronic coin data set. In order to prevent the first terminal from using the electronic coin data set for payment at another (third) terminal (so-called double spending), it is preferable to perform a switch (“switch”) of the transferred electronic coin data set from the first terminal to the second terminal. The switch can preferably be performed automatically when an electronic coin data set is received in the second terminal. Additionally, it may also occur upon request, such as a command from the first and/or second terminal. Additionally, an electronic coin partial data set may also be split into at least two coin partial data sets (“split”). Additionally, two electronic coin data sets can be combined into one coin data set (“Merge”).

Switching, splitting and combining are different modifications to an electronic coin data set. These modifications require registering the masked coin data set in a monitoring entity. This registering in the course of the modifications causes the electronic coin data set sent by the first terminal to become invalid and to be recognized as correspondingly invalid when the first terminal makes a second output attempt. The coin data set to be registered by the second terminal becomes valid by being registered in the monitoring entity. The specific performance of each modification will be explained later.

Switching is also performed when an electronic coin data set has been modified, for example, split or combined with other electronic coin data sets, in particular to suitably settle a monetary amount to be paid.

For the modification of electronic coin data sets (switching, splitting, combining), the monitoring entity checks whether the (masked) electronic coin data set has a valid range. For this purpose, so-called “zero-knowledge range proofs” are applied as range verification. Range proofs allow, on the one hand, that a changed monetary amount (split, combine) is within a predefined range of valid monetary amounts and, on the other hand, that ownership of the monetary amounts to be changed is proven. One proof is the representation of the monetary amount in binary format and the representation based on it as a ring signature.

This proof management requires a not small volume of data to be exchanged between the terminal and the monitoring entity and a computational effort. It is desirable that such verifications can be performed in a substantially simplified manner.

In the method according to the invention, therefore, an improved masking of the at least one electronic coin data set is provided in order to simplify the range verifications.

According to the invention, a selection of a masking mode is made or a masking mode is determined before the transfer step and/or before the register step. The selection is made, for example, by a user of the first terminal via a corresponding menu control on the terminal. The selection is made, for example, on the basis of a system default in the payment system or a system default by a third-party provider. For example, a performance of the payment system can be optimally utilized in this way, so that an effort of verification based on a current registration request volume in the monitoring entity can be controlled by selecting the masking mode accordingly. The selection can also be selected based on a terminal property. For example, in the absence of support for one of the masking modes, a corresponding preselection can be made.

According to the selection made by the terminal, a range proof is created when registering in the monitoring entity. This also includes the place value representation of the monetary amount to any base, for example to base 2 (binary) or base 3 (ternary), etc.

Different range checking options can be implemented through the different masking modes.

For example, there is no simplification (shortening) of the range verification if this option is not implemented in the system, the monitoring entity or the terminal. Then, the verification is performed over the entire range of the monetary amount.

Alternatively, the range verification simplification according to a fixed default value is mandatory in the system in case of a modification (switching, splitting, combining) of a coin data set.

Alternatively, the area proof simplification is optionally provided with a fixed default value. In this case, the monitoring entity can determine whether a fully masked electronic coin data set or a quasi-masked electronic coin data set or a partially amount-masked electronic coin data set is to be generated and whether a change from one masking type to another masking type is to be made.

Alternatively, the range proof shortening is optional with a variable default value. This allows the user to determine how much of the masked coin data set should be disclosed within the allowed system defaults. The variable default value can be changed again with any modification to the coin data set.

To improve the performance of the method, the third masking mode further abbreviates range verification by applying a ring signature only to the first monetary amount part that corresponds to a default value (system default or terminal selection).

The decision on the extent to which coin data set elements are transferred unmasked, e.g., the extent to which information about the electronic coin data set is transparent to a monitoring entity or remains hidden, could be based on a decision by the terminals transferring the respective coin data sets. To describe this negotiation of the decision, the terms “fully masked coin data set” and “incompletely masked coin data set” introduced above are used.

Associated with the fully masked coin data set is an (unmasked) private electronic coin data set that masks all coin data set elements, in particular the monetary amount, from the monitoring entity. For such private electronic coin data sets, the second masking mode shall be selected.

Associated with the partially amount-masked coin data set (in the third masking mode) is an (unmasked) semi-private electronic coin data set that discloses the second monetary amount part to the verification level (monitoring entity). The third masking mode can be selected for such semi-private electronic coin data sets.

The use of private electronic coin data sets in a modify step together with semi-private electronic coin data sets is not problematic. A corresponding switch of a private electronic coin data set into a semi-private electronic coin data set is enabled with a switch step as described below.

The reverse case, i.e., using semi-private electronic coin data sets in a modify step together with private electronic coin data sets, requires an additional masking step as described in a combine or split step in the second masking mode.

When combining to convert a semi-private to a private electronic coin data set, an additional private electronic coin data set is required. If no additional private electronic coin data set is currently present in the respective terminal, a private zero coin electronic data set is used that has a monetary amount of zero but an obfuscation amount, i.e., does not represent a monetary amount. This private zero coin data set can be created at any time from a single existing private electronic coin data set using a split step. In this particular split step, a first private coin partial data set is generated that has the same monetary amount as the single existing private electronic coin data set, and a second coin partial data set is generated that is a zero coin electronic data set. This split to obtain the private electronic zero coin data set is performed before the semi-private coin data set is transferred to the private electronic coin data set and stored for later use.

For example, for registering in the first or third masking mode, the monetary amount or a monetary amount part is transferred unmasked. However, the corresponding masking modes are not limited to unmasked transfer of the monetary amount (part), any other coin data set element (part) could alternatively or additionally be transferred unmasked. This eliminates the need to transmit additional data packets for complex range verification, or increases performance in the fourth masking mode by using much smaller data packets.

If the monetary amounts (or amount parts) are transferred unmasked or unveiled, the range verification is simplified to only two verification steps, namely (1) whether the monetary amount added to the incompletely masked electronic coin data set belongs to this masked electronic coin data set and (2) whether the ownership of the modified (unmasked) electronic coin data set is proven. In the third masking mode, only an abbreviated range verification needs to be checked.

The adding step in the first or third masking mode is preferably a simple logical operation, such as concatenation (concatenation) or using an extensible data structure, such as a TLV data structure.

These simplifications cause changes in the range checking for the modifications (split, combine, switch), as explained below.

In a preferred embodiment of the method, the further method steps are provided in the second terminal after transfer: switching the electronic coin data set while generating an electronic coin data set to be switched in the terminal from the electronic coin data set, wherein an obfuscation amount for the electronic coin data set to be switched is generated using the obfuscation amount of the electronic coin data set in the second terminal; and the monetary amount of the electronic coin data set is used as a monetary amount for the electronic coin data set to be switched.

Alternatively or additionally provided is: splitting the electronic coin data set into a first electronic coin partial data set and a second electronic coin partial data set in the first terminal, wherein the monetary amount is split into at least a first monetary amount and a second monetary amount.

Alternatively or additionally provided is: combining a first and a second electronic coin data set into a combined electronic coin data set in the first terminal, comprising the steps of: calculating an obfuscation amount for the electronic coin data set to be combined by forming the sum of the respective obfuscation amounts of the first and second electronic coin data sets; and calculating the monetary amount for the electronic coin data set to be combined by forming the sum of the respective monetary amounts of the first and second electronic coin data sets.

In all three described method steps, i.e., switching, splitting, and combining, masking the electronic coin data set in the masking step of the second masking mode comprises masking the coin data set to be switched of the first and/or second coin partial data set and/or the combined coin data set.

When masking the electronic coin data set in the masking step of the first or third masking mode, a coin data set element, for example the obfuscation amount of the respective electronic coin data set, is used as a dynamic private key, but with which no decryption is possible.

Subsequently, for all masking modes, the fully masked electronic coin data set or the quasi-masked electronic coin data set or the partially amount-masked electronic coin data set is transmitted to the monitoring entity for checking the validity of the electronic coin data set by the monitoring entity. Checking the validity is discussed in detail below.

In a preferred embodiment, the method has the further method steps of: generating a signature using the obfuscation amount of the electronic coin data set; adding the signature to the quasi-masked electronic coin data set or the fully masked electronic coin data set, wherein in the monitoring entity the fully masked electronic coin data set or the quasi-masked electronic coin data set is registered with the signature. In this embodiment, the created signature is also registered in the monitoring entity.

In an alternative embodiment, the method has the further method steps of: generating a signature using the obfuscation amount of the electronic coin data set; and transmitting the signature together with the quasi-masked electronic coin data set or the partially amount-masked electronic coin data set, wherein only the partially amount-masked electronic coin data set or the quasi-masked electronic coin data set is registered in the monitoring entity.

In a preferred embodiment of this alternative, the method has the monitoring entity register only partially amount-masked or quasi-masked electronic coin data set and/or only electronic coin data sets that are amount-open for at least an amount portion.

In this alternative embodiment, the created signature is used to transfer the masked coin data set between the terminal and the monitoring entity, but the signature is not registered in the monitoring entity—the signature is not part of the registered masked coin data set. Here, the signature is a transport backup and is discarded after verification to register the masked coin data set without the signature.

Preferably, after the switching step, the registering step in the monitoring entity for the first masking mode comprises: receiving the quasi-masked electronic coin data set to be switched in the monitoring entity; checking the quasi-masked electronic coin data set for validity in the monitoring entity; checking if the monetary amount of the electronic coin data set is equal to the monetary amount of the electronic coin data set to be switched; calculating the difference between the quasi-masked coin data set to be switched and the quasi-masked electronic coin data set; checking by means of an added signature created by generating a public verification key; and registering the quasi-masked electronic coin data set to be switched in the monitoring entity if all checking steps are successful, whereby the electronic coin data set to be switched is considered valid.

Preferably, after the splitting step, the registering step in the monitoring entity for the second and/or third masking mode comprises: receiving the fully masked electronic coin data set or the partially amount-masked electronic coin data set in the monitoring entity; checking the masked electronic coin data set to be switched for validity in the monitoring entity; checking a ring signature added to the partially amount-masked electronic coin data sets using the monetary amount of the electronic coin data set in the monitoring entity; calculating the difference between the sum of the fully masked electronic coin data sets or the sum of the partially amount-masked electronic coin partial data set and the masked coin partial data set to check whether the monetary amount of the electronic coin data set is equal to the sum of the first and second monetary amounts of the respective electronic coin partial data sets—to check whether the monetary amount of the electronic coin data set is equal to the monetary amount of the electronic coin data set to be switched over and registering the masked electronic coin partial data set in the monitoring entity if all checking steps are successful and simplified range verification has been performed, whereby the electronic coin partial data set is considered valid.

Preferably, after the combining step, the registering step in the monitoring entity for the second and/or third masking mode comprises: receiving the partially amount-masked combined electronic coin data set or the fully masked combined electronic coin data set in the monitoring entity; checking the masked first and second electronic coin data sets for validity in the monitoring entity; checking a first ring signature added to the partially amount-masked electronic coin data set or the fully masked electronic coin data set using the first monetary amount of the first electronic coin data set in the monitoring entity; checking a second ring signature added to the partially amount-masked electronic coin data set or the fully masked electronic coin data set using the second monetary amount of the second electronic coin data set in the monitoring entity; calculating the difference between the partially amount-masked linked electronic coin data set or the fully masked linked electronic coin data set and the sum of the masked first electronic coin data set and the masked second electronic coin data set to check whether the monetary amount of the linked electronic coin data set is equal to the sum of the first and second monetary amounts of the first and second electronic coin data sets; registering the masked linked electronic coin data set in the monitoring entity if all checking steps are successful and a simplified range verification has been performed, whereby the linked electronic coin data set is deemed valid.

Preferably, after the combining step, the registering step in the monitoring entity for the first masking mode comprises: Receiving the quasi-masked combined electronic coin data set in the monitoring entity; Checking the masked first and second electronic coin data sets for validity in the monitoring entity; Checking a first signature added to the quasi-masked electronic coin data set by generating a first public verification key in the monitoring entity; checking a second signature added to the quasi-masked electronic coin data set by generating a second public verification key in the monitoring entity; calculating the difference from the monetary amount of the validly to be the difference between the monetary amount of the coin data set to be validated and the sum of the monetary amounts of the first electronic coin data set to be combined and the second electronic coin data set; registering the quasi-masked combined electronic coin data set in the monitoring entity if all checking steps are successful and a simplified range verification has been performed, whereby the combined electronic coin data set is considered valid.

Preferably, the method according to the third masking mode comprises a step of creating a range verification in the first terminal, the range verification comprising information that the monetary amount of the electronic coin data set is positive and known to the creator of the range verification, hereinafter also referred to as simplified range verification, with: splitting the electronic coin partial data set in the first terminal according to a fixed or variable default value, into a first electronic coin partial data set and a second electronic coin partial data set; splitting the second electronic coin partial data set in the first terminal according to a place value, wherein a place value of the split second electronic coin partial data set represents a place value of the second monetary amount of the electronic coin data set and the sum of all obfuscation amounts of the second electronic coin partial data set split according to a place value results in the obfuscation amount of the electronic coin data set, wherein the basis of the place value is arbitrary.

Based on the place value split of the second electronic coin data set, the terminal creates a ring signature that is transmitted to the monitoring unit along with the partially amount-masked electronic coin data set for checking.

Preferably, the base of the place value is two or three. Place value refers to a power of the base of a place value system. Thus, a binary system, is a place value system with a base of 2, a ternary system is a place value system with a base of 3, and a decimal system is a place value system with a base of 10. The value of the base is not determined in this case, in order to enable the most flexible possible place value-based split for a simplified verification check.

For example, the place value-based split is based on a default value. This default value specifies, for example, the point at which the monetary amount is to be split. It then corresponds, for example, to a number of “least significant bits, LSB” if the place value has the base 2. This number of LSB is then added to the partially masked coin data set as the second monetary amount part. The remaining digits of the monetary amount form the first monetary amount part and replace the monetary amount for the masking step.

Alternatively, this default value corresponds to, for example, a number of “most significant bits, MSB” if the place value has a base of 2. This number of MSB is then added to the partially masked coin data set as the second monetary amount part. The remaining digits of the monetary amount form the first monetary amount part and replace the monetary amount for the masking step.

Alternatively, this default value corresponds to a random number of bits, for example, if the place value has a base of 2. This number of bits is then added to the partially masked coin data set as the second monetary amount part. The remaining digits of the monetary amount form the first monetary amount part and replace the monetary amount for the masking step.

Alternatively, this default value corresponds to a concrete selection of bits, for example, if the place value has a base of 2. This selection of bits is then added to the partially masked coin data set as the second monetary amount part. The remaining digits of the monetary amount form the first monetary amount part and replace the monetary amount for the masking step.

The verification is preferably based on ring signatures whose parameters require the generation of random numbers and the derivation of scatter values (hash) in the terminals.

A default value defined for verification can be a system-defined parameter—as described above—or the result of a negotiation between two system participants (terminals or monitoring entity).

The following explanations are given with regard to the first masking mode and the quasi-masked coin data sets created in the process. A prerequisite for selecting the first masking mode could be that there is no need in the system to mask (hide) a coin data set element, for example the monetary amount. This lack of need greatly simplifies the overall payment system and the method of directly exchanging electronic coin data sets between terminals. A quasi-masked electronic coin data set, as described above and comprising at least a monetary amount and an obfuscation amount as data elements, can then be associated with a quasi-masked electronic coin data set consisting of, for example, the unmasked monetary amount and the encrypted obfuscation amount (=masked coin data set element). All modifications (split, switch, combine) can also be applied to these quasi-masked electronic coin data sets and are dealt with in the context of the first masking mode hereafter. The explanations for the first masking mode can represent alternative embodiments to the second or third masking mode, but they can be combined with each other as desired with regard to signature creation, choice of encryptions, choice of verification checks. The general goal even with a combination is to obtain a substantial simplification of the range-proofs.

Preferably—after the switching step—the registering step is performed in the monitoring entity for the first masking mode with: receiving the quasi-masked electronic coin data set to be switched in the monitoring entity; checking the quasi-masked electronic coin data set for validity in the monitoring entity; checking a signature added to the quasi-masked electronic coin data set using the encrypted obfuscation amount (=masked coin data set element) of the electronic coin data set in the monitoring entity; and registering the quasi-masked electronic coin data set to be switched in the monitoring entity if the two checking steps are successful, whereby the electronic coin data set to be switched is considered valid.

Preferably, after the splitting step, the registering step is performed in the monitoring entity for the first masking mode with: Receiving the quasi-masked electronic coin partial data set in the monitoring entity; Checking the quasi-masked electronic coin data set for validity in the monitoring entity; Checking a signature added to the quasi-masked electronic coin data set using the masked obfuscation amount in the monitoring entity; checking that the monetary amount of the electronic coin data set is equal to the sum of the first and second monetary amounts of the electronic coin partial data sets; registering the quasi-masked electronic coin partial data sets in the monitoring entity if the three checking steps are successful, whereby the electronic coin partial data sets are deemed valid and the electronic coin data set to be split is deemed invalid.

Preferably, after the combining step, the registering step occurs in the monitoring entity for the first masking mode with: Receiving the quasi-masked combined electronic coin data set in the monitoring entity; Checking the quasi-masked first and second electronic coin data sets for validity in the monitoring entity; Checking two signatures added to the quasi-masked combined electronic coin data sets to be combined using the masked obfuscation amounts in the monitoring entity; checking whether the monetary amount of the combined electronic coin data set is equal to the sum of the first and second monetary amounts of the first and second electronic coin data sets; registering the quasi-masked combined electronic coin data set in the monitoring entity if the three checking steps are successful, whereby the combined electronic coin data set is considered valid and the two electronic coin data sets to be combined are considered invalid.

The step of checking the quasi-masked coin data sets in the switching, splitting, or combining step is done according to the checking of validity.

Preferably, a signature is created for each quasi-masked electronic coin data set. The private signature key is preferably the (unmasked) obfuscation amount of the (unmasked) coin data set.

The signature is preferably created during the switching step over the quasi-masked electronic coin data set and the encrypted obfuscation amount of the quasi-masked electronic coin data set to be switched.

The signature is preferably created in the split step over the quasi-masked electronic coin partial data set, the quasi-masked first electronic coin partial data set, and the quasi-masked second electronic coin partial data set.

The signature is preferably created during the combining step over the quasi-masked first electronic coin data set, the quasi-masked second electronic coin data set, and the quasi-masked combined electronic coin data set.

To create an unmasked electronic coin data set for the first masking mode, a signature of the issuer is stored in the monitoring entity via the quasi-masked electronic coin data set.

The deletion of a quasi-masked electronic coin data set occurs when the monitoring entity has checked the signature of an issuing entity.

The signature generated in this method replaces any additional information otherwise required to maintain a range verification on the masked electronic coin data set to be split or a range verification on respective masked electronic coin partial data sets.

To generate the signature, an asymmetric cryptosystem is preferred, in which the terminal calculates a value for a coin data set using a secret signature key, hereinafter also referred to as a private signature key or “private key.” This value enables anyone to check the authorship and integrity of the coin data set using a public verification key, the public key.

For example, the signature added in this method for the first masking mode is a first signature and a private signature key used to generate the first signature is the obfuscation amount of the corresponding electronic coin data set. In contrast, only two signatures are used for the second masking mode, namely the central bank signature for generating and deleting (=fix private key) and the signature for switching (obfuscation amount as private key).

For example, the signature added in this method (of all masking modes) is a second signature and a private signature key for generating the second signature is generated from a difference between the obfuscation amount of the electronic coin data set and the obfuscation amount for the electronic coin data set to be switched.

A public verification key for checking the first signature is preferably formed from a difference of the masked electronic coin data set and an applying the cryptographic encryption function to the monetary amount of the electronic coin data set.

A public verification key for checking the second signature is preferably formed from a difference between the masked electronic coin data set to be switched and the masked electronic coin data set.

The method preferably has the further following steps: switching the transferred electronic coin partial data set; and/or combining the transferred electronic coin data set with a second electronic coin data set to form a further electronic coin data set, namely combined electronic coin data set.

Upon switching, the electronic coin partial data set obtained from the first terminal results in a new electronic coin data set, preferably with the same monetary amount, called the electronic coin data set to be switched. The new electronic coin data set is generated by the second terminal, preferably by using the monetary amount of the obtained electronic coin data set as the monetary amount of the electronic coin data set to be switched. In the process, a new obfuscation amount, such as a random number, is generated. The new obfuscation amount is added to the obfuscation amount of the obtained electronic coin data set, for example, so that the sum of both obfuscation amounts (new and obtained) serves as the obfuscation amount of the electronic coin data set to be switched. After switching, the obtained electronic coin partial data set and the electronic coin partial data set to be switched are preferably masked in the terminal by applying the one-way function to each of the obtained electronic coin partial data set and the electronic coin partial data set to be switched to obtain a masked received electronic coin partial data set and a masked electronic coin partial data set to be switched, respectively.

Newly created obfuscation amounts must have high entropy since they are used as a blinding factor for the corresponding masked electronic coin partial data sets. Preferably, a random number generator on the terminal is used for this purpose.

Previously, additional information needed to register the switching of the masked electronic coin data set in the remote monitoring entity was preferably calculated in the terminal as part of the switching process. Preferably, the additional information includes a range verification on the masked electronic coin data set to be switched and a range verification on the masked obtained electronic coin data set. The range verification is a verification that the monetary amount of the electronic coin data set is non-negative, the electronic coin data set is validly created, and/or the monetary amount and obfuscation amount of the electronic coin data set are known to the creator of the range verification. Specifically, the range verification is used to provide such proof(s) without revealing the monetary value and/or obfuscation amount of the masked electronic coin data set. These range verifications are also called “zero-knowledge range proofs.” Preferably, ring signatures are used as range verification. This is followed by registering the switching of the masked electronic coin data set in the remote monitoring entity.

Thus, the switching is secured by adding a new obfuscation amount to the obfuscation amount of the received electronic coin data set, thereby obtaining an obfuscation amount known only to the second terminal. However, newly created obfuscation amounts must have a high entropy since they are used as a blinding factor for the corresponding masked electronic coin partial data sets. Preferably, a random number generator on the terminal is used for this purpose. This safeguarding can be tracked in the monitoring entity.

Furthermore, the method comprises the following steps: Masking the coin partial electronic data set to be switched in the second terminal by applying, for example, the homomorphic one-way function to the coin partial electronic data set to be switched to obtain a masked coin partial electronic data set; and registering the masked coin partial electronic data set in a remote monitoring entity.

The steps described herein need not be performed in the order described. However, the sequence described herein is a preferred embodiment.

Preferably, the step of registering is performed when the second terminal is combined with the monitoring entity. While the electronic coin data sets are used for direct payment between two terminals, the masked coin data sets are registered in the monitoring entity, allowing modifications to the masked electronic coin data sets to be registered in the monitoring entity.

In a further preferred embodiment of the method, for a combining of electronic coin partial data sets, a further electronic coin data set (combined electronic coin data set) is determined from a first and a second electronic coin partial data set. Thereby, the obfuscation amount for the electronic coin data set to be combined is calculated by forming the sum of the respective obfuscation amounts of the first and the second electronic coin data set. Further, preferably, the monetary amount for the combined electronic coin data set is calculated by forming the sum of the respective monetary amounts of the first and second electronic coin data sets.

After combining, the first electronic coin partial data set, the second electronic coin partial data set, as well as the electronic coin partial data set to be combined in the (first and/or second) terminal by applying the, for example, homomorphic one-way function to each of the first electronic coin partial data set, the second electronic coin partial data set, as well as the electronic coin data set to be combined, in order to obtain a masked first electronic coin partial data set, a masked second electronic coin partial data set, as well as a masked electronic coin data set to be combined, respectively. Further, additional information needed to register the combining of the masked electronic coin data sets in the remote monitoring entity is calculated in the terminal. Preferably, the additional information includes a range verification on the masked first electronic coin partial data set and a range verification on the masked second electronic coin partial data set. The range verification is a verification that the monetary amount of the electronic coin data set is non-negative, the electronic coin data set is validly created, and/or the monetary amount and obfuscation amount of the electronic coin data set are known to the creator of the range verification. Specifically, the range verification is used to provide such proof(s) without revealing the monetary value and/or obfuscation amount of the masked electronic coin data set. These range verifications are also called “zero-knowledge range proofs.” Preferably, ring signatures are used as range verification. This is followed by registering the combining of the two masked electronic coin partial data sets in the remote monitoring entity.

With the step of combining, two electronic coin data sets or two electronic coin partial data sets can be combined. In this process, the monetary amounts as well as the obfuscation amounts are added together. Thus, as with splitting, validity of the two original coin data sets can be performed during combining.

In a preferred embodiment, the registering step comprises receiving the masked coin partial electronic data set to be switched in the monitoring entity, checking the masked coin partial electronic data set to be switched for validity; and registering the masked coin partial electronic data set to be switched in the monitoring entity if the checking step is successful, whereby the coin partial electronic data set to be switched is deemed to be checked.

Preferably, the checking step determines whether the difference between the masked electronic coin partial data set and the masked electronic coin partial data set to be switched is equal to a public verification key of the signature. This allows easy checking of the validity of the coin partial data set without complex zero-knowledge proofs. However, the zero-knowledge proof is still required to prove an ownership of the electronic coin data set (except in the first masking mode).

A main distinguishing feature of this invention concept compared to known solutions is that the monitoring entity only (i.e. exclusively) keeps knowledge of the masked electronic coin data set/coin partial data set and a list of processing/modifications to the masked electronic coin data set/coin partial data set. The actual payment transactions with the (unmasked) coin data sets/coin partial data sets are not registered in the monitoring entity 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 direct exchange of (unmasked) electronic coin data sets, and a monitoring layer, which comprises the database, is also provided. In the monitoring entity, the monitoring layer, no payment transactions are recorded, but only masked electronic coin data sets and their processing for the purpose of verifying the validity of (unmasked) electronic coin data sets. This ensures the anonymity of the participants in the payment system. The monitoring entity provides information about valid and invalid electronic coin data sets, for example, to avoid multiple issuances of the same electronic coin data set or to verify the authenticity of the electronic coin data set as validly issued electronic money.

The terminal can thus transfer electronic coin data sets to another terminal in the direct payment transaction layer without a connection to the monitoring entity, especially when the terminal is offline, i.e., there is no communication link to the monitoring entity.

The terminal may have a security element in which the electronic coin data sets are stored securely. A security element is preferably a special computer program product, in particular in the form of a secure runtime environment within an operating system of a terminal, in English Trusted Execution Environments, TEE, stored on a data storage device, for example a mobile 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, in English Trusted Platform Module, TPM, or as an embedded security module, eUICC, eSIM. The security element provides a trusted environment.

The communication between two terminals can be wireless or wired, or e.g. also via optical path, preferably via QR code or barcode, and can be designed as a secured channel. The optical path may comprise, for example, the steps of generating an optical code, in particular a 2D code, preferably a QR code, and reading the optical code. Thus, the exchange of the electronic coin data set is secured, for example, by cryptographic keys, such as a session key negotiated for an electronic coin data set exchange or a symmetric or asymmetric key pair.

By communicating between terminals, for example via their security elements, the exchanged electronic coin data sets are protected from theft or tampering. The security element layer thus complements the security of established blockchain technology.

In a preferred embodiment, the transfer of the coin data sets takes place as APDU commands. For this purpose, the coin data set is preferably stored in an (embedded) UICC as a security element and is managed there. An APDU is a combined command/data block of a connection protocol between the UICC and a device. The structure of the APDU is defined by the ISO-7816-4 standard. APDUs represent an information element of the application layer (layer 7 of the OSI layer model).

In addition, it is advantageous that the electronic coin data sets can be transferred in any format. This implies that they can be communicated in arbitrary channels, i.e. they can be transferred. They do not have to be stored in a fixed format or in a specific program.

In particular, a mobile telecommunications terminal, for example a smartphone, is regarded as a terminal. Alternatively or additionally, the terminal can also be a device, such as a wearable, smart card, machine, tool, vending machine or even container or vehicle. A terminal according to the invention is thus 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 may also be designed to be combined with the Internet and/or other networks by means of access to a mobile network.

In one embodiment, it can be provided that the first and/or second terminal processes the received electronic coin data sets according to their monetary value when several electronic coin data sets are present or received in the method shown. Thus, it can be provided that electronic coin data sets with higher monetary value are processed before electronic coin data sets with lower monetary value. In one embodiment, the first and/or second terminal may be designed, after receiving an electronic coin data set, to combine it with an electronic coin data set already present in the second terminal depending on attached information, for example, a currency or denomination, and to perform a step of combining accordingly. Furthermore, the second terminal may also be configured to perform an automated switching after receiving the electronic coin data set from the first terminal.

In one embodiment, further information, in particular metadata, is transferred from the first terminal to the second terminal during the transfer, for example a currency. In one embodiment, this information may be comprised by the electronic coin data set.

In a preferred embodiment, the method has the following further steps: Masking the transferred electronic coin data set in the second terminal by applying, for example, the homomorphic one-way function to the transferred electronic coin data set; and transmitting the masked transferred electronic coin data set to the remote monitoring entity for checking the validity of the transferred electronic coin data set by the remote monitoring entity. For example, in this case, the entire monetary amount within the electronic coin data set was transferred to the second terminal. Before a payee accepts this electronic coin data set, it verifies its validity, if applicable. To this end, the second terminal generates the masked transferred electronic coin data set, transmits it to the monitoring entity, and in the process queries the monitoring entity about the validity of the electronic coin data set. The monitoring entity now checks whether the masked transferred electronic coin data set exists at all and whether it is still valid, i.e. has not already been consumed by another terminal, in order to avoid double spending.

In one embodiment, a proof is generated in the second terminal. The proof comprises information about the correspondence between the monetary amount of the transferred electronic coin data set and the monetary amount of the electronic coin data set to be switched. Preferably, the verification comprises only information about the match, but not one of the monetary amounts.

Preferably, during the registering step, verification of the electronic coin data set of the first and/or second terminal is performed in or by the monitoring entity. The verification is performed depending on the steps preceding the verification, for example whether a step of switching, combining and/or splitting has taken place. In doing so, the monitoring entity can, for example, check the validity of the (masked) transferred and/or split and/or first and second electronic coin data sets. This makes it possible to determine whether the electronic coin data sets 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 entity), the registration cannot be successfully performed, for example because the terminal tries to output an electronic coin data set multiple times.

In a further preferred embodiment, after executing the switching step, the registering step comprises, for example, sending the switching command prepared by the terminal to the monitoring entity. Preferably, the monitoring entity communicates the result of executing the switching command to the “commanding” terminal, i.e., which of the involved masked electronic coin data sets are valid after executing the switching command.

In a preferred embodiment, the monitoring entity is a remote entity. Thus, for example, establishing a communication link to the monitoring entity is provided for registering the electronic coin data set.

The monitoring entity is designed as a higher-level entity. Accordingly, the monitoring entity is not necessarily arranged in the level or layer of the terminals (direct transaction layer). Preferably, the monitoring entity is provided for the administration and verification of masked electronic coin data sets and is arranged in an issuing layer, in which an issuing entity is also arranged, and/or in a monitoring layer. It is conceivable that the monitoring entity additionally manages and checks transactions between terminals.

The monitoring entity is preferably a database in which the masked electronic coin data sets are registered with corresponding processing of the masked electronic coin data set. The database may be designed as a decentralized controlled database, Distributed Ledger Technology (DLT) in English. In a preferred embodiment, a validity status of the (masked) electronic coin data set can be derived therefrom. Preferably, the validity of the (masked) electronic coin data set is noted in and by the monitoring entity. Registering the processing or processing steps may also involve registering verification results and interim verification results concerning the validity of an electronic coin data set. If a processing is final, this is indicated, for example, by corresponding markings or a derived overall marking Final processing then determines whether an electronic coin data set 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 in a simple way to check coin data sets with regard to their validity and to prevent “double spending”, i.e. multiple spending, without registering or logging the payment transaction itself. The database describes a technique for networked computers to come to an agreement on the order of certain transactions and that these transactions update data. It corresponds to a decentrally managed administrative system or database.

In a further embodiment, the database may be a public database.

Alternatively, the monitoring entity is a centrally managed database, for example in the form of a publicly accessible data repository or as a hybrid of a centralized and decentralized database.

Preferably, the at least one initial electronic coin data set is created exclusively by the issuing entity, although preferably the split electronic coin data sets, in particular electronic coin partial data sets, can also be generated by a terminal. Preferably, creating and selecting a monetary amount also includes selecting a high entropy obfuscation amount. The issuing entity is a computing system, which is preferably remote from the first and/or second terminal. After the new electronic coin data set is created, the new electronic coin data set is masked in the issuing entity by applying the, for example, homomorphic one-way function to the new electronic coin data set to obtain a masked new electronic coin data set accordingly. Furthermore, additional information needed to register the creation of the masked new electronic coin data set in the remote monitoring entity is calculated in the issuing entity. Preferably, this further information is a proof that the (masked) new electronic coin data set originates from the issuing entity, for example by signing the masked new electronic coin data set. In one embodiment, the issuing entity may sign a masked electronic coin data set with its signature when generating the electronic coin data set. The signature of the issuing entity is stored in the monitoring entity for this purpose. The signature of the issuing entity is different from the generated signature of the first terminal.

Preferably, the issuing entity can deactivate an electronic coin data set in its possession (i.e., of which it knows the monetary amount and the obfuscation amount) by masking the masked electronic coin data set to be deactivated with, for example, the homomorphic one-way function and preparing a deactivate command for the monitoring entity. Part of the deactivate command is preferably, besides the masked electronic coin data set to be deactivated, also the evidence that the deactivate step was initiated by the issuing entity, for example in the form of the signed masked electronic coin data set to be deactivated. As additional information, range checks for the masked electronic coin data set to be deactivated could be included in the deactivate command. This is followed by registering the deactivation of the masked electronic coin data set in the remote monitoring entity. The deactivate command triggers the deactivate step.

Preferably, the create and deactivate steps occur in secured locations, particularly not in the terminals. In a preferred embodiment, the create and deactivate steps are performed or triggered only by the issuing entity. Preferably, these steps take place in a secure location, for example in a hardware and software architecture designed to process sensitive data material in insecure networks. Deactivating the corresponding masked electronic coin data set has the effect that the corresponding masked electronic coin data set is no longer available for further processing, in particular transactions, as it has been marked as invalid in and by the monitoring entity. However, in one embodiment, it may be provided that the deactivated masked electronic coin data set remains in archival form at the issuing entity. The fact that the deactivated masked electronic coin data set is no longer valid may be indicated, for example, by means of a flag or other coding, or the deactivated masked electronic coin data set may be destroyed and/or deleted. Of course, the deactivated masked electronic coin data set can also be physically removed from the terminal.

The method according to the invention 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, combining and switching) is thereby registered in the monitoring entity and appended there in unchanged form to the list of previous processing operations for the respective masked electronic coin data set. The registration is independent of the payment process between the terminals in terms of both time and location (space). The processing operations “create” and “deactivate”, which concern the existence of the monetary amount per se, i.e. the creation and destruction up to the destruction of money, require an additional approval, for example in the form of a signature, by the issuing entity in order to be registered (i.e. logged) in the monitoring entity. The remaining processing operations (splitting, combining, switching) do not require authorization by the issuing entity or by the command initiator (=payer, e.g. the first terminal).

Processing in the direct transaction layer only concerns the ownership and/or allocation of the coin data sets to terminals of the respective electronic coin data sets. A registration of the respective processing in the monitoring entity is realized, for example, by corresponding list entries in a database, which comprises a number of markings to be performed by the monitoring entity. For example, a possible structure for a list entry comprises column(s) for a predecessor coin data set, column(s) for a successor coin data set, a signature column for the issuing entity, a signature column for coin split operations, and at least one marking column. A change in the status of the marker requires approval by the monitoring entity and must then be stored in an unalterable form. A change is final if and only if the required markers have been validated by the monitoring entity, i.e. changed from status “0” to status “1” after the corresponding check, for example. If a check fails or takes too long, it is changed from status “-” to status “0” instead, for example. Other status values are conceivable and/or the status values mentioned here are interchangeable. Preferably, the validity of the respective (masked) electronic coin data sets is shown summarized from the status values of the markers, each in a column for each masked electronic coin data set involved in registering the processing.

In a further embodiment, at least two preferably three or even all of the aforementioned markers may also be replaced by a single marker that is set when all checks have been successfully completed. Furthermore, the two columns for predecessor data sets and successor data sets can be combined into one column each, in which all coin data sets are listed together. This would make it possible to manage more than two electronic coin data sets per field entry and thus, for example, to split the data into more than two coins.

The checks by the monitoring entity to check whether a processing is final are already described above and are in particular:

Are the masked electronic coin data sets of the predecessor column(s) valid?

Does monitoring yield the correct check value?

Are the range verifications for the masked electronic coin data sets successful?

Is the signature of the masked electronic coin data set a valid signature of the issuing entity?

Preferably, a masked electronic coin data set is also invalid if any of the following checks apply, i.e., if:

• • (1) the masked electronic coin data set is not registered in the monitoring entity;
  • (2) the last processing of the masked electronic coin data set indicates that there are predecessor coin data sets for it, but that 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 that last processing is final;
  • (4) the masked electronic coin data set is not the successor to a valid masked electronic data set unless it is signed by the issuing entity.

In one aspect of the invention, a payment system for exchanging monetary amounts is provided comprising a monitoring layer having a database in which masked electronic coin data sets are stored; and a direct transaction layer having at least two terminals in which the method described above is feasible; and/or an issuing entity for generating an electronic coin data set. In this regard, the issuing entity can prove that the masked generated electronic coin data set was generated by it, preferably the issuing entity can identify itself by signing and the monitoring entity can check the signature of the issuing entity.

In a preferred embodiment, the payment system comprises an issuing entity for generating an electronic coin data set. In doing so, the issuing entity can prove that the masked generated electronic coin data set was generated by the issuing entity, preferably the issuing entity can identify itself by signing and the monitoring entity can check the signature of the issuing entity.

Preferably, the payment system is adapted to perform the above method and/or at least one of the embodiments.

Another aspect of the invention relates to a currency system comprising an issuing entity, a monitoring entity, a first terminal and a second terminal, wherein the issuing entity is adapted to create an electronic coin data set. The masked electronic coin data set is adapted to be detectably created by the issuing entity. The monitoring entity is adapted to perform a registration step as set forth in the above method Preferably, the terminals, i.e., at least the first and second terminals are adapted to perform one of the above methods for transferring.

In a preferred embodiment of the currency system, only the issuing entity is authorized to initially create an electronic coin data set. Processing, for example the step of combining, splitting and/or switching, can be and preferably is performed by a terminal. The processing step of deactivating can preferably only be performed by the issuing entity. Thus, only the issuing entity would be authorized to invalidate the electronic coin data set and/or the masked electronic coin data set.

Preferably, the monitoring entity and the issuing entity are arranged in a server entity or are present as a computer program product on a server and/or a computer.

An electronic coin data set can exist in a variety of different manifestations and thus be exchanged via different communication channels, hereinafter also referred to as interfaces. A very flexible exchange of electronic coin data sets is thus created.

The electronic coin data set can be represented, for example, in the form of a file. A file consists of related data stored on a data carrier, data memory or storage medium. Each file is initially a one-dimensional string of bits, which are normally interpreted as a group of byte blocks. An application program (application) or an operating system itself interprets this bit or byte sequence as, for example, a text, an image or a sound recording. The file format used in this process can vary, for example it can be a plain text file representing the electronic coin data set. In particular, the monetary amount and the blind signature are represented as a file.

For example, the electronic coin data set is a sequence of American Standard Code for Information Interchange, or ASCII, characters. In particular, the monetary amount and the blind signature are mapped as this sequence.

The electronic coin data set can also be converted from one form of representation to another form of representation in a device. For example, the electronic coin data set can be received as a QR code in the device and output as a file or string from the device.

These different representation forms of one and the same electronic coin data set allow a very flexible exchange between devices of different technical equipment using different transmission media (air, paper, wired) and taking into account the technical design of a device. The choice of the presentation form of the electronic coin data sets is preferably made automatically, for example, based on recognized or negotiated transmission media and device components. Additionally, a user of a device may also select the representation form for exchanging (=transferring) an electronic coin data set.

In one aspect of the invention, the problem is solved by a device arranged for direct transfer of electronic coin data sets to another device. The apparatus comprises means for accessing a data memory, the data memory having at least one electronic coin data set stored therein; an interface for at least outputting the at least one electronic coin data set to the other apparatus; and a computing unit arranged for masking the electronic coin data set in the device by applying the, for example, homomorphic (encryption) one-way function to the electronic coin data set for obtaining a masked electronic coin data set for registering the masked electronic coin data set in a monitoring entity; and for outputting the electronic coin data set by means of the interface.

In this regard, a device is a previously described terminal or machine.

In one simple case, the data store is an internal data store of the device. This is where the electronic coin data sets are stored. Easy access to electronic coin data sets is thus ensured.

In particular, the data memory is an external data memory, also called online memory. Thus, the device has only one means of accessing the coin data sets stored externally and thus securely. In particular, if the device is lost or malfunctions, the electronic coin data sets are not lost. Since possession of the (unmasked) electronic coin data sets equals possession of the monetary amount, money can be stored more securely by using external data storage.

If the monitoring entity is a remote monitoring entity, the device preferably interfaces for communication using a common internet communication protocol, such as TCP, IP, UDP, or HTTP. The transfer may include communication over the cellular network.

In a preferred embodiment, the device is arranged to perform the processing operations already described, in particular split, combine and switch, on an electronic coin data set. For this purpose, the computing unit is arranged to mask an electronic coin data set to be switched as the electronic coin data set that the monitoring entity needs as the masked electronic coin data set for registering the switching command or in the switching step. In this way, an electronic coin data set—as described above—can be switched.

Moreover, or alternatively, the computing unit is preferably arranged to mask an electronic coin partial data set split into a number of coin partial data sets to obtain a masked electronic coin data set and, if necessary, masked electronic coin partial data sets that can be registered in the monitoring entity. In this way, an electronic coin data set can be split—as described above.

Furthermore or alternatively, the computing entity is preferably arranged to mask an electronic coin partial data set to be combined from a first and a second electronic coin data set as the electronic coin data set to obtain a masked coin partial data set to be combined as the masked electronic coin data set to be registered in the monitoring entity. In this way, an electronic coin data set—as described above—can be combined.

In a preferred embodiment, the interface for outputting the at least one electronic coin data set is an electronic display unit of the device, which is arranged for displaying the electronic coin data set and thereby (also) for outputting the electronic coin data set in visual form. As has already been described, the electronic coin data set is then interchangeable between devices, for example in the form of an optoelectronically detectable code, an image, etc.

In a preferred embodiment, the interface for outputting the at least one electronic coin data set is a protocol interface for wirelessly transmitting the electronic coin data set to the other device using a wireless communication protocol. In particular, near field communication, for example by means of Bluetooth protocol or NFC protocol or IR protocol is provided, alternatively or additionally WLAN-connections or mobile radio connections are conceivable. The electronic coin data set is then adapted and transferred according to the protocol properties.

In a preferred embodiment, the interface for outputting the at least one electronic coin data set is a data interface for providing the electronic coin data set to the other device by means of an application. In contrast to the protocol interface, the electronic coin data set is transferred by means of an application. This application then transfers the coin data set in an appropriate file format. A file format specific to electronic coin data sets can be used. In its simplest form, the coin data set is transferred as an ASCII string or text message, for example, SMS, MMS, instant messenger message (such as Threema or WhatsApp). In an alternative form, the coin data set is transferred as an APDU string. A wallet application may also be provided. In this case, the exchanging devices preferably ensure that an exchange is possible using the application, i.e., that both devices have the application and are ready to exchange.

In a preferred embodiment, the device further has an interface for receiving electronic coin data sets.

In a preferred embodiment, the interface for receiving the at least one electronic coin data set is an electronic capture module of the device, arranged for capturing an electronic coin data set presented in visual form. The capture module is then, for example, a camera or a barcode or QR code scanner.

In a preferred embodiment, the interface for receiving the at least one electronic coin data set is a protocol interface for wirelessly receiving the electronic coin data set from another device using a communication protocol for wireless communication. In particular, near-field communication, for example by means of Bluetooth protocol or NFC protocol or IR protocol, is provided. Alternatively or additionally, WLAN connections or mobile radio connections are conceivable.

In a preferred embodiment, the interface for receiving the at least one electronic coin data set is a data interface for receiving the electronic coin data set from the other device by means of an application. This application then receives the coin data set in a corresponding file format. A file format specific to coin data sets may be used. In its simplest form, the coin data set is transferred as an ASCII string or as a text message, for example SMS, MMS, Threema or WhatsApp. In an alternative form, the coin data set is transferred as an APDU string. Additionally, the transfer may be performed using a wallet application.

In a preferred embodiment, the interface for receiving the at least one electronic coin data set is also the interface for outputting the electronic coin data set, such that an interface is provided for both transmitting and receiving the coin data set.

In a preferred embodiment, the device comprises at least one security element reader arranged to read a security element; a random number generator; and/or a communication interface to a vault module and/or banking institution with access to a bank account to be authorized.

In a preferred embodiment, the data store is a shared data store accessible by at least one other terminal, each of the terminals having an application, said application being arranged to communicate with the monitoring entity for registering electronic coin partial data sets accordingly.

Thus, what is proposed here is a solution that issues digital money in the form of electronic coin data sets, which is modelled on the use of conventional (analogue) banknotes and/or coins. The digital money is represented here by electronic coin data sets. As with (analogue) banknotes, these electronic coin data sets become usable for all forms of payments, including peer-to-peer payments and/or POS payments. Knowing all the components (especially monetary amount and obfuscation amount) of a valid electronic coin data set is equivalent to owning (possessing) the digital money. It is therefore advisable to keep these valid electronic coin data sets confidential, e.g., to store them in a security element/vault module of a terminal and process them there. In order to decide on the authenticity of an electronic coin data set and to prevent duplicate issues, masked electronic coin data sets are kept in the monitoring entity as a unique corresponding public representation of the electronic coin data set. Knowledge or possession of a masked electronic coin data set does not constitute possession of money. Rather, it is akin to verifying the authenticity of the analogue currency.

The monitoring entity also includes markers about performed and planned processings of the masked electronic coin data set. A status of the respective masked electronic coin data set is derived from the markers about the processings, indicating whether the corresponding (unmasked) electronic coin data set is valid, i.e. ready for payment. Therefore, a recipient of an electronic coin data set will first generate a masked electronic coin data set and have the monitoring entity authenticate the validity of the masked electronic coin data set. A major advantage of this solution according to the invention is that the digital money is distributed to terminals, merchants, banks and other users of the system, but no digital money or other metadata is stored at the monitoring entity—i.e. a common entity.

The proposed solution can be integrated with existing payment systems and infrastructures. In particular, there can be a combination of analogue payment transactions with banknotes and coins and digital payment transactions according to the present solution. For example, a payment transaction can be made with banknotes and/or coins, but the change or change back is available as an electronic coin data set. For the transaction, for example, ATMs with a corresponding configuration, in particular with a suitable communication interface, and/or mobile terminals can be provided. It is also conceivable to exchange electronic coin data sets for banknotes or coins.

The steps of creating, switching, splitting, combining and deactivating listed above are each triggered by a corresponding create, switch, split, combine or deactivate command.

The task is further solved by a monitoring unit arranged to receive a masked electronic coin data set and to register the masked electronic coin data set. The masked electronic coin data set is masked in a first masking mode or a second masking mode or a third masking mode. Preferably, the masked electronic coin data set is masked according to a masking step from the method described previously. The monitoring unit is further adapted to register a modification of a coin data set according to the method previously described.

BRIEF SUMMARY OF THE FIGURES

In the following, the invention or further embodiments and advantages of the invention will be explained in more detail with reference to figures, the figures merely describing embodiments of the invention. Identical components in the figures are given the same reference signs. The figures are not to be regarded as true to scale, and individual elements of the figures may be shown in exaggeratedly large or exaggeratedly simplified form.

They show:

FIG. 1 an embodiment example of a payment system according to the invention;

FIG. 2 an embodiment example of a monitoring entity;

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

FIG. 4 an embodiment example of a payment system according to the invention for combining electronic coin data sets;

FIG. 5 an embodiment example of a method flow chart of a method according to the invention and corresponding processing steps of a coin data set;

FIG. 6 an embodiment of a method flow chart of a method according to the invention and corresponding processing steps of a coin data set;

FIG. 7 a further embodiment example of a method flow chart of a method according to the invention;

FIG. 8 an embodiment example of an apparatus according to the invention;

FIG. 9 another embodiment example of a process flow diagram of a method according to the invention according to a fourth masking mode;

FIG. 10 a schematic representation of the method according to FIG. 9;

FIG. 11 a further embodiment example of a process flow diagram of a method according to the invention;

FIG. 12 a further embodiment of a method according to the invention; and

FIG. 13 a process flow diagram of the method according to the invention shown in FIG. 12.

FIGURE DESCRIPTION

FIG. 1 shows an embodiment example of a payment system with terminals M1 and M2 according to the invention. The terminals M1 and M2 may be devices.

In this case, an electronic coin data set C_i is generated in an issuing entity 1, for example a central bank. A masked electronic coin data set Z_i is generated for the electronic coin data set C_i and registered in an “obfuscated electronic coin data set ledger”. In the context of the present invention, a ledger is understood to be a list, a directory, preferably a database structure. The electronic coin data set C_i is output to a first terminal M1.

For example, a true random number has been generated as obfuscation amount r_i for this purpose. This obfuscation amount r_i is linked to a monetary amount ν_i and then forms an i-th electronic coin data set according to the invention:

C _i={ν_i;r_i}  (1)

A valid electronic coin data set can be used for payment. The owner of the two values ν_i and r_i is therefore in possession of the digital money. However, the digital money is defined by a pair consisting of a valid electronic coin data set and a corresponding masked electronic coin data set Z_i. The masked electronic coin data set Z_i is obtained by applying a one-way function f(C_i) according to equation (2):

Z _i=ƒ(C_i)  (2)

For example, the one-way function f(C_i) is homomorphic. The masked electronic coin data set is, for example, a fully electronic masked coin data set, a quasi-masked electronic coin data set, or a partially amount-masked electronic coin data set, as will be further detailed with respect to FIG. 9 and following.

In particular, this function f(C_i) is public for a fully masked electronic coin data set an incompletely masked electronic coin data set and a partially masked electronic coin data set, i.e., any system participant in the payment system can invoke and use this function. This function f(C_i) is defined according to equation (3) or equation (3a), for example:

Z _i=ν_i·H+r_i·G  (3)

Z _i =r _i ·G  (3a)

where H and G are generator points of a group in which the discrete logarithm problem is hard, with the generators G and H for which the discrete logarithm of the other basis is unknown. For example, G (equation (3), (3a)) as well as H (equation (3)) are each a generator point of an elliptic curve encryption, ECC, —that is, private keys of the ECC. In the case of equation (3), these generator points G and H must be chosen in such a way that the context of G and H is not publicly known, so that if:

G=n·H  (4)

the concatenation n must be practically undetectable to prevent the monetary amount ν_i from being manipulated and a valid Z_i could still be calculated. Equation (3) is a “Pederson commitment for ECC” that ensures that the monetary amount ν_i can be conceded, i.e., “committed,” to a monitoring entity 2 without revealing it to the monitoring entity 2. Therefore, only the masked coin data set Z_i is sent (disclosed) to the public and remote monitoring entity 2.

Even though in the present example an encryption based on elliptic curves is or will be described, another cryptographic method would also be conceivable, which is based on a discrete logarithmic method and is based on equation (3a).

When equation (3a) is applied, a one-way function is applied to only a portion of the coin data set C, in this case the obfuscation amount r_i (for a quasi-masked coin data set) or a first monetary amount portion of the monetary amount (for a partially amount-masked coin data set).

The masked obfuscation amount may also be referred to as R.

Equation (3), through the entropy of the obfuscation amount r_i, allows a cryptographically strong Z_i to be obtained even when the range of values for monetary amounts ν_i is small. Thus, a simple brute-force attack by merely estimating monetary amounts ν_i is practically impossible.

Equations (3) and (3a) use one-way functions, meaning that calculating Z_i from C_i is easy because an efficient algorithm exists, whereas calculating C_i starting from Z_i is very hard because no algorithm that can be solved in polynomial time exists.

Moreover, equation (3) is homomorphic for addition and subtraction, that is:

Z _i +Z _j=(ν_i·H+r_i·G)+(ν_j·H+r_j·G)=(ν_i+ν_j)·H+(r_i+r_j)·G  (5)

Thus, addition operations and subtraction operations can be performed both in the direct transaction layer 3 and in parallel in the monitoring layer 4 without the monitoring layer 4 having knowledge of the electronic coin data sets C_i. The homomorphic property of equation (3) allows monitoring of valid and invalid electronic coin data sets C_i to be conducted based solely on the masked coin data sets Z_i and to ensure that no new monetary amount ν_i has been created.

This homomorphic property allows the coin data set C_i to be split according to equation (1) into:

C _i =C _j +C _k={ν_j;r_j}+{ν_k;r_k}  (6)

where holds:

ν_i=ν_j+ν_k  (7)

r _i =r _j +r _k  (8)

For the corresponding masked coin data sets:

Z _i =Z _j +Z _k  (9)

Equation (9), for example, can be used to easily check a “split” processing or a “split” processing step of a coin data set according to FIG. 3 without the monitoring entity 2 having knowledge of C_i, C_j, C_k. In particular, the condition of equation (9) is checked to declare split coin data sets C_j and C_k valid and coin data set C_k invalid. Such a split of an electronic coin data set C_i is shown in FIG. 3.

In the same way, electronic coin data sets can also be combined (joined), see FIG. 4 and the explanations thereto.

Additionally, it is important 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 entity 2 that all monetary amounts ν_i in a processing operation are within a value range of [0, . . . , 2ⁿ−1] without informing the monitoring entity 2 of the monetary amounts ν_i. These range verifications are also called “range proofs”. Preferably, ring signatures are used as range verifications. For the present embodiment example, both the monetary amount and the obfuscation amount r of an electronic coin data set C are resolved in bit representation. It holds:

ν_i=Σa_j·2^j for 0≤j≤n and a_j “element” {0;1}  (9a)

as well as

r _i =Σb _j·2^j for 0≤j≤n and b_j “element” {0;1}  (9b)

For each bit, a ring signature is preferably generated with

C _ij =a _j ·H+b _j ·G  (9c)

and

C _ij −a _j ·H  (9d)

whereby, in one embodiment, provision can be made to perform a ring signature only for certain bits.

In FIG. 1, an electronic coin data set C is generated by the issuing entity 1 and a masked electronic coin data set Z_i is calculated by the issuing entity 1 using equation (3) or equation (3a) and this is registered in the monitoring entity 2.

Subsequently, the first terminal M1, which can transfer the electronic coin data set C_i to a second terminal M2 or perform one of the processing steps (switching, combining, splitting), transfers. The transfer is performed, for example, wirelessly via WLAN, NFC or Bluetooth. The transfer may be further secured by cryptographic encryption methods, for example by negotiating a session key or applying a PKI infrastructure.

In the second terminal M2, the transferred electronic coin data set C_i is obtained as C_i*. Upon obtaining 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 required to complete the method. However, the terminal M2 does not know whether the electronic coin data set C_i* is actually valid. Moreover, the terminal M1 could still transfer the electronic coin data set C_i to a third terminal (not shown). To prevent this, further preferred steps in the method are provided.

To check the validity of the obtained electronic coin data set C_i*, the masked transferred electronic coin data set Z_i* is calculated in the second terminal M2 using the—public—one-way function from equation (3) or equation (3a). The masked transferred electronic coin data set Z_i* is then transferred to the monitoring entity 2 for searching. If it matches a registered and valid masked electronic coin data set, the validity of the obtained coin data set C_i* is indicated to the second terminal M2 and it is valid that the obtained electronic coin data set C_i* is equal to the registered electronic coin data set C_i. With the check for validity, in one embodiment, it can be determined that the obtained electronic coin data set C_i* is still valid, i.e., that it has not already been used by another processing step or in another transaction and/or has been subject to further modification.

Preferably, a switching of the obtained electronic coin data set takes place thereafter.

It is valid for the method according to the invention that the sole knowledge of a (completely, incompletely, quasi or partially) masked electronic coin data set does not entitle to spend the digital money. However, the sole knowledge of the electronic coin data set C_i entitles to pay, i.e. to perform a transaction successfully, especially if the coin data set C_i is valid. There is a one-to-one relationship between the electronic coin data sets C_i and the corresponding masked electronic coin data sets. The masked electronic coin data sets are registered in the monitoring entity 2, for example a public decentralized database. This registration first makes it possible to check the validity of the electronic coin data set C_i, for example whether new monetary amounts have been created (illegally).

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

To prevent multiple issuance or to ensure more flexible transfer, the electronic coin data sets can now be processed in the method according to the invention. Table 1 below lists the individual operations, with the specified command also executing a corresponding processing step:

TABLE 1
number of operations that can be performed per processing of a coin data set in the terminal or
Issuing entity can be performed;
		create random		create range
command or step	create signature	number	create masking	verification
generate	1	1	0 or 1
deactivate	1	0	1	0 or 1
split	0	1	3	0 or 1
combine	0	0	3	1
switch	0	1	2	1

Other operations not listed in table 1 may be required. Instead of the listed implementation, other implementations are also conceivable that imply other operations. Table 1 shows that for each coin data set, each of the processing operations “create”, “deactivate”, “split”, “combine” and “switch” may provide different operations “create signature”; “create random number”; “create masking”; “range check”, each of the processing operation being registered in the monitoring entity 2 and appended there in invariant form to a list of previous processing operations for masked electronic coin data sets. The operations of the processing operations “creating” and “deactivating” an electronic coin data set are performed only at secure locations and/or only by selected entities, for example, issuing entity 1, while the operations of all other processing operations can be performed on terminals M1 to M3.

The number of operations for each processing is indicated by “0”, “1” or “2” in table 1. The number “0” indicates that the terminal or issuing entity 1 does not have to perform this operation for this processing of the electronic coin data set. The number “1” indicates that the terminal or issuing entity 1 must be able to perform this operation once for this processing of the electronic coin data set. The number “2” indicates that the terminal or issuing entity 1 must be able to perform this operation twice for this processing of the electronic coin data set.

In principle, in one embodiment, it can also be provided that an area check is also performed by the issuing entity 1 when generating and/or deleting.

Table 2 below lists the operations required for the monitoring entity 2 for the individual processing operations:

TABLE 2
number of operations that can be performed per processing of a coin data set in the monitoring entity;
				trace homomorphic
		check validity of		properties of masked
	check signature	masked electronic	trace range	electronic coin data sets,
command or step	from issuer	coin data set	verification	i.e., add or subtract
generate	1	0	0 or 1	0
deactivate	1	1	0 or 1	0
split	0	1	2 or more	1
combine	0	2 or more	1	1
switch	0	1	1	0

Other operations not listed in table 2 may be required. Instead of the listed implementation, other implementations are conceivable that imply other operations. All operations of table 2 can be performed in the monitoring entity 2, which is a trusted entity, for example a decentralized server, in particular a distributed trusted server, that ensures sufficient integrity of the electronic coin data sets.

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

TABLE 3
preferred units in system components.
command or step	issuing entity	terminal	monitoring entity
random generator (high security)	Yes	—	—
random generator (deterministic)	—	Yes	—
PKI for signing	Yes	—	—
PIK for signature verification	—	(Yes)	Yes
read access to database	Yes	Yes	Yes
write access to database	Yes	Yes	Yes
deactivation of electronic coin data set	Yes	Yes	—
transport encryption	Yes	Yes	—
secure storage	(Yes)	Yes	—/Yes
masking unit	Yes	Yes	—
range verification	—	Yes	—
check range verification	—	—	Yes
database software	—	—	Yes

Table 3 shows an overview of the preferred components to be used in each system participant, i.e. the issuing entity 1, a terminal M1 and the monitoring entity 2. The terminal M1 can be used as a wallet for electronic coin data sets C_i, i.e. as an electronic purse, i.e. a data storage of the terminal M1, in which a plurality of coin data sets C_i may be stored, and may be implemented, for example, in the form of an application on a smartphone or IT system of a merchant, a commercial bank or another market participant and transmit or receive an electronic coin data set. Thus, the components are implemented as software in the terminal as shown in Table 3. It is understood that the monitoring entity 2 is a database operated by a set of trusted market participants. In one embodiment, the monitoring entity 2 is a DLT.

FIG. 2 shows an embodiment of a monitoring entity 2 of FIG. 1. FIG. 2 shows an exemplary database in the form of a table in which the masked electronic coin data sets (here, for simplicity, the fully masked electronic coin data sets Z_i) and, if applicable, their processing operations are registered. The monitoring entity 2 is preferably located locally remote from the terminals M1 to M3 and is housed, for example, in a server architecture.

Each processing operation for a processing (creating, deactivating, splitting, combining and switching) is thereby registered in the monitoring entity 2 and appended there in unchangeable form to a list of previous processing operations for masked electronic coin data sets. The individual operations or their check results, i.e. the intermediate results of a processing operation, are recorded in monitoring entity 2.

The processing operations “create” and “deactivate”, which concern the existence of the monetary amount ν_i, per se, i.e., imply the creation and destruction of money, require additional authorization by the issuing entity 1 to be registered (i.e., logged) in the monitoring entity 2. The remaining processing operations (split, combine, switch) do not require authorization by issuing entity 1 or by the command initiator (=payer, e.g. the first terminal M1).

A registration of the respective processing in the monitoring entity 2 is realized, for example, by corresponding list entries in the database according to FIG. 2. Each list entry has further markers 25 to 28 documenting the intermediate results of the respective processing to be performed by the monitoring entity 2. Preferably, the markers 25 to 28 are used as an aid and are discarded by the monitoring entity after completion of the commands What remains are markers 29 through 32 about the validity of the (masked) electronic coin data sets from columns 22a, 22b, 23a and/or 23b. These markers are in state “-” when a processing command is received, for example, and are set to state “1” when all checks have been successfully completed and are set to state “0” when at least one check has failed. A possible structure for a list entry of a coin data set comprises, for example, two columns 22a, 22b for a predecessor coin data set (O1, O2), two columns 23a, 23b for a successor coin data set (S1, S2), a signature column 24 for issuing entity/entities 1, and four flag 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 was successful with respect to an electronic coin data set in column 22a1b, where state “1” indicates that a validity check revealed that the electronic coin data set of column 22a1b is valid and state “0” indicates that a validity check revealed that the electronic coin data set of column 22a1b is invalid and state indicates that a validity check has not yet been completed. Column 26 (C flag) indicates whether the calculation of the masked electronic coin data set was successful, where state “1” indicates that a calculation was successful and state “0” indicates that calculation was unsuccessful and the state indicates that a validity check has not yet been completed.

For example, the calculation to be performed in column 26 for fully masked coin data sets based on equation (3) is:

(Z_O1+Z_O2)−(Z_S1+Z_S2)==0  (10)

Column 27 (R flag) indicates whether a check of the range evidence or range proof was successful, where state “1” indicates that a validity check showed that the range evidence or range proof could or is traceable and state “0” indicates that a validity check showed that the range evidence or range proof could not or could not be traced and state “-” indicates that a validity check not yet completed was successful.

Column 28 (S flag) indicates whether a signature of the electronic coin record matches the signature of column 24, where state “1” indicates that a validity check revealed that the signature could be identified as that of the issuer and state “0” indicates that a validity check revealed that the signature could not be identified as that of the issuer and state “-” indicates that a validity check has not yet been completed.

A change in the state of any of the flags (also referred to as a “flag”) requires approval by the monitoring entity 2 and must then be stored immutably in the monitoring entity 2. A processing is final if and only if the required flags 25 to 28 have been validated by monitoring entity 2, i.e., changed from state “0” to state “1” or state “1” after the appropriate check.

To determine whether a masked electronic coin data set is valid, the monitoring entity 2 searches for the last change affecting the masked electronic coin data set. It holds that the masked electronic coin data set is valid if and only if the masked electronic coin data set for its last processing is listed in one of the successor columns 23a, 23b and that last processing has the corresponding final marker 25 to 28. It also holds that the masked electronic coin data set is valid if and only if the masked electronic coin data set is listed for its last processing in one of the predecessor columns 22a, 22b and this last processing has failed, i.e. at least one of the corresponding required states of the markers 25 to 28 is set to “0”.

It also holds that the masked electronic coin data set is not valid for all other cases, for example, if the masked electronic coin data set is not found in the monitoring entity 2 or if the last processing of the masked electronic coin data set 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 is in one of the predecessor columns 22a, 22b and this last processing is final.

The checks by monitoring entity 2 to verify that a processing is final are represented by columns 25 through 28: The state in column 25 indicates whether the masked electronic coin data set(s) according to predecessor columns 22a, 22b are valid. The state in column 26 indicates whether the calculation of the masked electronic coin data set is correct according to equation (10). The state in column 27 indicates whether the range verifications for the masked electronic coin data set could be successfully checked. The state in column 28 indicates whether the signature in column 24 of the masked electronic coin data set is a valid signature of issuing entity 1.

The state “0” in a column 25 to 28 indicates that the verification was not successful. The state “1” in a column 25 to 28 indicates that the verification was successful. The state “-” in a column 25 to 28 indicates that no check was performed. The states can also have a different value, as long as a clear distinction can be made between success/failure of a check and it is evident whether a particular check was performed.

As an example, five different processing operations are defined, which are explained in detail here. Reference is made to the corresponding list entry in FIG. 2.

For example, one processing is “generating” an electronic coin data set C_i. Generating in the direct transaction layer 3 by the issuing entity 1 includes selecting a monetary amount ν_i and generating an obfuscation amount r_i, as described earlier with equation (1). As shown in FIG. 2, the “generate” processing does not require any entries/markers in columns 22a, 22b, 23b and 25 to 27. In the successor column 23a, the masked electronic coin data set Z_i is registered. This registration is preferably performed before transfer to a terminal M1 to M3, in particular or already during generation by the issuing entity 1. In both cases, equation (3) or equation (3a) must be executed for this purpose. The masked electronic coin data set Z_i is signed by issuing entity 1 when it is generated, this signature is entered in column 24 to ensure that the electronic coin data set C_i was actually generated by issuing entity 1, although other methods may also be used for this purpose. If the signature of a obtained C_i matches the signature in column 24, the marker in column 28 is set (from “0” to “1”). The markers according to columns 25 to 27 do not require a status change and can be ignored. The range verification is not needed because the monitoring entity 2 trusts that the issuing entity 1 does not issue negative monetary amounts. However, in an alternative embodiment, it can be sent by issuing entity 1 in the create command and checked by monitoring entity 2.

For example, one processing is “deactivate.” Deactivating, i.e. destroying money (DESTROY), causes the masked electronic coin data set Z_i to become invalid after the issuing entity 1 has successfully executed the deactivate command Thus, one can no longer process the (masked) electronic coin data set to be deactivated in monitoring layer 4. To avoid confusion, the corresponding (unmasked) electronic coin data sets C_i should also be deactivated in direct transaction layer 3. When “deactivating”, the predecessor column 22a is written to with the electronic coin data set Z_i, but no successor column 23a, 23b is occupied. The masked electronic coin data set Z_i shall be checked during deactivation to ensure that the signature matches the signature as specified in column 24 to ensure that the electronic coin data set C_i was actually created by an issuing entity 1, although again other means may be used for this check. If the signed C_i sent along in the deactivate command can be confirmed as signed by issuing entity 1 or confirmed as validly signed, marker 28 is set (from “0” to “1”). The markers according to columns 26 to 27 do not require a status change and can be ignored. The markers according to columns 25 and 28 are set after appropriate verification.

One processing is, for example, “split”. The splitting, i.e. the splitting of an electronic coin data record Z_i into a number n, for example 2, of electronic coin data records Z_j and Z_k is first carried out in the direct transaction layer 3, as shown in FIGS. 3, 5 to 7 and also FIGS. 9 to 11, whereby the monetary amounts ν_j and the obfuscation amount r_j are generated. v_k and r_k result from equations (7) and (8). In monitoring instance 2, markers 25 to 27 are set, predecessor column 22a is described by electronic coin record Z_i, successor column 23a is described by Z_j and successor column 23b is described by Z_k. The status changes required according to columns 25 to 27 are made after the corresponding check by supervisor 2 and document the respective check result. The marking according to column 28 is ignored. In column 24, a signature of the split coin record—masked with equation (3a)—can be entered.

One processing is for example “combine”. The combining, i.e., the merging of two electronic coin data sets Z_i and Z_j into one electronic coin data set Z_m is first performed in the direct transaction layer 3, as will be shown in FIG. 4, where the monetary amount ν_m and the obfuscation amount r_i are calculated. In the monitoring entity 2, the markers 25 to 27 are set, the predecessor column 22a is described with the electronic coin data set Z_i, predecessor column 22b is described with Z_j and successor column 23b is described with Z_m. The markers in columns 25 to 27 require status changes and the monitoring entity 2 performs the appropriate checks. A range verification must be performed to show that no new money has been generated. The marker according to column 28 is ignored. A first signature and a second signature of the coin data sets to be combined—masked with equation (3a)—can be entered in column 24.

For example, one processing is “switching”. Switching is necessary when an electronic coin data set has been transferred to another terminal and re-issuing by the transferring terminal (in this case M1) is to be excluded. When switching, also called “switching”, the electronic coin data set C_k obtained from the first terminal M1 is exchanged for a new electronic coin data set C_l with the same monetary amount. The new electronic coin data set C_l is generated by the second terminal M2. This switching is necessary to invalidate (make invalid) the electronic coin data set C_k obtained from the first terminal M1, thus avoiding reissuing the same electronic coin data set C_k. This is because, as long as the electronic coin data set C_k is not switched, since the first terminal M1 is aware of the electronic coin data set C_k, the first terminal M1 can pass this electronic coin data set C_k to a third terminal M3. The switching is done, for example, by adding a new obfuscation amount r_add to the obfuscation amount r_k of the received electronic coin data set C_k, thereby obtaining an obfuscation amount r_i that only the second terminal M2 knows. This can also be done in the monitoring entity 2. To prove that a new obfuscation amount r_add has been added to the obfuscation amount r_k of the masked obtained electronic coin data set Z_k, but the monetary amount has remained the same, and thus equation (11):

ν_k=ν_l  (11)

holds, then the second terminal M2 must be able to prove that Z_i−Z_k can be represented as a scalar multiple of G i.e., as r_add*G. That is, only one obfuscation amount r_add has been generated and the monetary amount of Z_l is equal to the monetary amount of Z_k, i.e., Z_l=Z_k+r_add*G. This is done by generating a signature with the public key Z_l−Z_k=r_add*G. This signature is used in monitoring layer 4 to confirm the validity of the electronic coin data set to be switched.

The “split” and “combine” modifications to an electronic coin data set can also be delegated from one terminal M1 to another terminal M2, M3, for example, when a communication link to the monitoring entity 2 is not available.

FIG. 3 shows an embodiment example of a payment system according to the invention for “splitting”, “combining” and “switching” electronic coin data sets C. In FIG. 3, the first terminal M1 has obtained the coin data set C_i and now wishes to perform a payment transaction not with the entire monetary amount ν_i, but only with a partial amount ν_k. For this purpose, the coin data set C_i is split. To do this, the monetary amount is first split:

ν_l=ν_j−ν_k  (12)

Here, each of the obtained amounts ν_j, ν_k, must be greater than 0, because negative monetary amounts are not allowed.

In addition, new obfuscation amounts are derived:

r _i =r _j +r _k  (13)

When split, masked coin data sets Z_j and Z_k are obtained from the coin data sets C_j and C_k according to equation (3) and registered in monitoring entity 2. For splitting, the predecessor column 22a is written with coin data set Z_i, the successor column 23a is written with 4, and the successor column 23b is written with Z_k. Additional information for range verification (zero-knowledge-proof) is to be generated. The markers in columns 25 to 27 require status change and the monitoring entity 2 performs the corresponding checks. The marker according to column 28 is ignored.

Then a coin partial data set, here C_k, is transferred from the first terminal M1 to the second terminal M2. To prevent double output, a switch operation is useful to exchange the electronic coin data set C_k obtained from the first terminal M1 for a new electronic coin data set C_l with the same monetary amount. The new electronic coin data set C_l is generated by the second terminal M2. In this process, the monetary amount of the coin data set C_l 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 set C_k,

r _l =r _k +r _add  (14)

thereby obtaining an obfuscation amount r_l known only to the second terminal M2. In order to prove that only a new obfuscation amount r_add has been added to the obfuscation amount r_k of the obtained electronic coin data set Z_k, but that the monetary amount has remained the same (ν_k=ν_l), the second terminal M2 must be able to prove that Z_l−Z_k can be represented as a multiple of G. This is done using public signature R_add according to equation (15):

$\begin{array}{cc}{R}_{\mathrm{add}}=r_{\mathrm{add}}·G& \left(15\right)\end{array}$ $=Z_l-Z_k=\left(v_l-v_k\right)\star H+\left(r_k+r_{\mathrm{add}}-r_k\right)\star G$

where G is the generator point of the ECC. Then, the coin data set C_l to be switched is masked using equation (3) or equation (3a) to obtain the masked coin data set Z_l. In the monitoring entity 2, the private signature r_add can then be used to sign, for example, the masked switchable electronic coin data set Z_l, which is considered as a proof that the second terminal M2 has only added an obfuscation amount r_add to the masked electronic coin data set and no additional monetary value, i.e. v_l=v_k.

The proof for masking using equation (3) is as follows:

$\begin{array}{cc}{Z}_k-v_k·H+r_k·G& \left(16\right)\end{array}$ $Z_l=v_l·H+r_l·G=v_k·H-\left(r_k+r_{\mathrm{add}}\right)·G$ $Z_l-Z_k=\left(r_k+r_{\mathrm{add}}-r_k\right)·G$ $=r_{\mathrm{add}}·G$

For masking using equation (3a), a signature is generated over the monetary amount ν_k, the obfuscation amount r_k and the masked coin data set element (e.g., the masked obfuscation amount R or the masked first amount part). Thus, the signature can be validated by recalculating the masking in the monitoring entity 4 to be able to prove the authenticity and existence/possession of the coin data set C.

FIG. 4 shows an embodiment example of a payment system according to the invention for combining electronic coin data sets. In this case, the two coin data sets C_i and C_j are obtained in the second terminal M2. Following the splitting according to FIG. 3, a new coin data set Zm is now obtained by adding both the monetary amounts and the obfuscation amount of the two coin data sets C_i and C_j. Then, the obtained coin data set C_m to be combined is masked using equation (3) or equation (3a) and the masked coin data set Z_m is registered in the monitoring entity.

For masking using equation (3a), a first signature is generated over the monetary amount ν_i, the obfuscation amount r_i, and the masked coin data set, and a second signature is generated over the monetary amount ν_j, the obfuscation amount r_j, and the masked coin data set Z_j. Both signatures can be validated by recalculating the masking in the monitoring entity 4, respectively, to be able to prove the authenticity and existence/possession of the coin data set C. The first signature may also be associated with the second signature to form a common signature.

FIGS. 5 to 7 are each an embodiment of a method flowchart of a method 100 according to the invention. FIGS. 5 to 7 are explained together below. In optional steps 101 and 102, a coin data set is requested and provided on the part of the issuing entity 1 to the first terminal M1 after the electronic coin data set is created. A signed masked electronic coin data set is transmitted to the monitoring entity 2 in step 103. In step 103, masking of the obtained electronic coin data set C_i is performed according to 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 entity 2. Optionally, M1 can switch the obtained electronic coin data set. In step 105, the coin data set C_i is transferred in the direct transaction layer 3 to the second terminal M2. In optional steps 106 and 107, a validity check with prior masking is performed, in which, in the good case, the monitoring entity 2 confirms the validity of the coin data set Z_i and C_i, respectively.

In step 108, switching of a obtained coin data set C_k (of course, the obtained coin data set C_i could also be switched) to a new coin data set C_l takes place, whereby the coin data set C_k becomes invalid and double spending is prevented. To do this, the monetary amount vu of the transferred coin data set C_k is used as the “new” monetary amount ν_l. In addition, as already explained with equations (14) to (17), the obfuscation amount r_l is created. The additional obfuscation 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_l to be switched is transmitted to the monitoring entity 2 and the switching from C_k to C_l is instructed.

In step 108′, the corresponding check is carried out in monitoring entity 2, with Z_k being entered in column 22a according to the table in FIG. 2 and the coin data set Z_l to be switched being entered in column 23b. A check is then carried out in monitoring entity 2 to determine 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 has not been further split or deactivated or combined) and whether a check for the last processing has failed. In addition, Z_l is entered in column 23b and the markers in columns 25, 26, 27 are initially set to “0”. Now a check is made to see if Z_l is valid, using the check according to equations (16) and (17). In the good case, the marker in column 25 is set to “1”, otherwise to “0”. Now a check is made, the calculation according to equation (10) shows that Z_k and Z_l are valid and accordingly the marker in column 26 is set. Further it is checked whether the ranges are conclusive, then the marker in column 27 is set. If all three checks were successful, and this was recorded accordingly unchangeably in the monitoring entity 2, the coin data set is considered switched. This means that the coin data set C_k is no longer valid and the coin data set C_l is valid from now on. Double issuance is no longer possible when a third terminal M3 inquires about the validity of the (double issued) coin data set at the monitoring entity 2.

In step 109, a combining of two coin data sets C_k and C_i onto a new coin data set C_m is performed, making the coin data sets C_k, C_i invalid and preventing double spending. To do this, the monetary amount nm is formed from the two monetary amounts ν_k and ν_i. For this purpose, the obfuscation amount r_m is formed from the two obfuscation amounts r_k and r_i. In addition, using equation (3), the masked coin data set to be combined is obtained and this is transmitted (together with other information) to the monitoring entity 2 and combining is requested as processing.

In step 109′, the corresponding check is performed in monitoring entity 2, with Z_m being entered in column 23b according to the table in FIG. 2, which also equals a paraphrase. A check is then made in monitoring entity 2 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 the columns 23a/b (as proof that Z_k and Z_i have not been further split or deactivated or combined) and whether a check for the last processing has failed. In addition, the markers in columns 25, 26, 27 are initially set to “0”. Now a check is made whether Z_m is valid, whereby the check according to equations (16) and (17) can be used. In the good case the marker in column 25 is set to “1”, otherwise to “0”. Now a check is made, the calculation according to equation (10) shows that Z_i plus Z_k equals Z_m and accordingly the marker in column 26 is set. Further it is checked whether the ranges are conclusive, then the marker is set in column 27.

In step 110′, the corresponding check is performed in monitoring entity 2, where Z_j and Z_k are entered in columns 23a/b according to the table in FIG. 2. A check is then made in monitoring entity 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_i has not been further split or deactivated or combined) and whether a check for the last processing has failed. In addition, the markers in columns 25, 26, 27 are initially set to “0”. Now a check is carried out whether Z_j and Z_k are valid, whereby the check according to equations (16) and (17) can be used. In the good case, the marking in column 25 is set to “1”. Now a check is made, the calculation according to equation (10) shows that Z_i is equal to Z_k plus Z_j and accordingly the marker in column 26 is set. Further it is checked whether the ranges are conclusive, then the marker is set in column 27.

In FIG. 8, an embodiment example of a device M1 according to the invention is shown. The device M1 can store electronic coin data sets C_i in a data memory 10, 10′. In this regard, the electronic coin data sets C_i may reside on the data memory 10 of the device M1 or may be available in an external data memory 10′. When using an external data storage 10′, the electronic coin data sets C_i could be stored in an online storage, for example a data storage 10′ of a digital wallet provider. Additionally, private data storage, for example a network attached storage, NAS on a private network could also be used.

In one case, the electronic coin data set C_i is shown as a hard copy printout. In this case, the electronic coin data set may be represented by a QR code, an image of a QR code, or may be a file or a string (ASCII).

The device M1 has at least one interface 12 available as a communication channel for outputting the coin data set C_i. This interface 12 is for example an optical interface, for example for displaying the coin data set C_i on a display unit (display), or a printer for printing the electronic coin data set C_i as a paper printout. This interface 12 can also be a digital communication interface, for example for near-field communication, such as NFC, Bluetooth, or an internet-capable interface, such as TCP, IP, UDP, HTTP, or an access to a smart card as a security element. For example, this interface 12 is a data interface such that the coin data set C_i is transferred between devices via an application, such as an instant messenger service, or as a file or string.

Moreover, the interface 12 or another interface (not shown) of the device M1 is arranged to interact with the monitoring entity 2 as described in FIGS. 1 to 6. The device M1 is preferably online-capable for this purpose.

Furthermore, the device M1 may also have an interface for receiving electronic coin data sets. This interface is set up to receive visually presented coin data sets, for example by means of an acquisition module such as a camera or scanner, or digitally presented coin data sets, received via NFC, Bluetooth, TCP, IP, UDP, HTTP, or coin data sets presented by means of an application.

The device M1 also comprises a computing unit 13 capable of performing the method described above for masking coin data sets and the processing operations on coin data sets.

The device M1 is capable of being online and can preferably detect when it is combined with a WLAN by means of a location detection module 15. Optionally, a specific WLAN network can be marked as preferred (=location zone), so that the device M1 executes special functions only if it is logged into this WLAN network. Alternatively, the location detection module 15 detects when the device M1 is in predefined GPS coordinates including a defined radius and performs the special functions according to the location zone thus defined. This location zone can be introduced into the device M1 either manually or via other units/modules. The special functions performed by the device M1 when the location zone is detected are, in particular, the transfer of electronic coin data sets from/to the external data memory 10 from/to a vault module 14 and, if necessary, the transfer of masked coin data sets Z to the monitoring entity 2, for example as part of the above-mentioned processing operations on a coin data set.

In the simplest case, all coin data sets C_I are automatically combined into one coin data set in the terminal M1 upon obtaining (see connect processing or connect step). That is, as soon as a new electronic coin data set is received, a combine or switch command is transmitted to the monitoring entity 2. The device M1 can also prepare electronic coin data sets in algorithmically defined denominations and hold them in the data memory 10, 10′ so that a payment process is possible even without a data connection to the monitoring entity 2.

FIGS. 9 and 10 each show an embodiment of a method flow diagram of a method 200 according to the invention. In the following, FIGS. 9 and 10 are explained together. explained. The statements made previously from the method 100 and the individual method steps 101 to 110 also apply to this method 200, unless other statements are made here.

In the optional steps 101 and 102, a coin data set is requested and provided on the part of the issuing entity 1 to the first terminal M1 after the electronic coin data set has been created, see also FIG. 5 to 7. The first terminal M1 transfers the coin C to the second terminal in step 105. Although the method steps 201 to 208 shown here are explained with respect to the second terminal M2, they could also be performed in the first terminal M1. In step 105, the first terminal M1 transfers the coin C_k to the second terminal.

In step 201, selecting a masking mode is performed. To prevent double issuance, a switch operation is provided to exchange the electronic coin data set C_k obtained from the first terminal M1 for a new electronic coin data set C_l having the same monetary amount. The new electronic coin data set C_l is generated by the second terminal M2. The monetary amount ν_k of the coin data set C_k is taken over and is not changed to the new monetary amount ν_l, 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 set C_k, obtaining an obfuscation amount r_l that only the second terminal M2 knows.

The masking mode is selected, for example, by a user of the first terminal M1 via a corresponding menu control on the terminal M1. The selection is made, for example, on the basis of a system default x in the payment system. For example, in this way, a performance of the payment system can be optimally utilized so that an effort of the verification check (step 207) can be controlled based on a current registration request volume in the monitoring entity 2 by selecting the masking mode accordingly. The selection can also be selected based on a terminal property, for example, if one of the masking modes is not supported, a corresponding preselection can be made.

Now, according to FIG. 9, in order to avoid having to perform the time-consuming proof of equations (15) and (16), the fourth masking mode is selected in the optional step 201. the electronic coin data set C_i can be masked in step 202 according to equation (3) to obtain the fully masked electronic coin data set Z_i according to second masking mode.

In step 203, a first signature is optionally created using the obfuscation amount r_k as the signature key according to equation (17):

[Z_k]sig(r_k)  (17)

In addition, in step 203, a second signature is optionally created with the difference of the obfuscation amounts r_i and r_l as signature key according to equation (18):

[Z_k]sig(r_l−r_k)  (18)

In step 203, the monetary amount ν_k of the received electronic coin data set C_k can be added to the first signature, here as an example logically linked according to equation (19) or as concatenation according to equation (19a):

ν_k∥sig(r_k)  (19)

ν_k∘sig(r_k)  (19a)

The switching (modification) preferably takes place before the transmitting step 204. The corresponding incompletely masked electronic coin data set sent to the monitoring entity 2 in step 204 is transmitted together with at least also the unmasked coin data set element from equation (19) or equation (19a) and, if applicable, the second signature from equation (18) according to equation (20) by merely arranging them one behind the other (“;” or as concatenation “∘” according to equation 20a:

ν_k∥sig(r_k);sig(r_l−r_k);Z_l  (20)

ν_k∥sig(r_k)∘sig(r_l−r_k)∘Z_l  (20a)

If no signature is created in step 203, the unmasked coin data set element—here the monetary amount ν_k or the identical monetary amount ν_l is added to the fully masked electronic coin data set Z_l according to equation (20b):

ν_k∘Z_lbzw·ν_l∘Z_l  (20b)

In the monitoring entity, a simplified range check can be performed by selecting the first masking mode. This comprises, for example, four checks (if the signatures are generated in step 203). The first check is to check the validity of the incompletely masked coin data set to be switched. This is done according to the previous described way.

The optional second check according to step 206 is to verify the (optional) first signature. For this purpose, the unmasked monetary amount ν_k is used to create the public verification key of the first signature, with:

Z _k ′=Z _k−ν_k*H  (21)

The public verification key generated in equation (21) is used to check the first signature:

Z _k′=sig(r_k)  (22)

If the second verification is successful, it is proven that the monetary amount ν_k belongs to the masked coin data set Z_k and that the second terminal M2 knows the obfuscation amount r_k.

The optional third check according to step 207 is used to verify the (optional) second signature. For this purpose, the difference is formed from the masked electronic coin data set Z_l to be switched and the masked obtained coin data set Z_k:

Z _l −Z _k=sig(r_lr_k)  (23)

The public verification key generated in equation (23) is used to check the second signature. If the third verification is successful, it is proven that the difference in monetary amounts ν_k ν_l equals zero, thus proving that no new/additional money has been generated.

The fourth check is then a very simple range check by monitoring entity 2:

ν_min≤ν_k≤ν_max  (24)

Checking the splitting (as modifying) of a coin data set C_i is done in a comparable way as switching. For example, in step 105, the first terminal M1 transfers the coin C_i to the second terminal M2.

In optional step 201, the masking mode is selected. For example, according to FIG. 9, in step 201, the fourth masking mode is selected so as not to have to perform the time-consuming verifications of equations (15) and (16). Then, in step 202, the electronic coin data set C_i is split according to equations (6) and (7) to obtain a first coin partial data set Cj and a second coin partial data set C_k. In step 203, three separate first signatures can then optionally be created over the obfuscation amounts r_i, r_j and r_k according to equation (17). In addition, each of the monetary amounts ν_i ν_j ν_k can be added to the corresponding first signature, for example logically linked according to equation (19) or as concatenation according to equation (19a), so that the following three first signatures are obtained:

ν_i∥sig(r_i)  (19b)

ν_j∥sig(r_j)  (19c)

ν_k∥sig(r_k)  (19d)

The splitting (modifying) is preferably done before the transmitting step 204. The corresponding incomplete masked electronic coin partial data sets Z_k Z_j transmitted to the monitoring entity 2 in step 204 are sent together with the unmasked coin data set elements from equations (19b), (19c), (19d) or corresponding concatenation according to equation (19a):

ν_k∥sig(r_k);ν_i∥sig(r_i);ν_j∥sig(r_j);Z_j;Z_k  (25)

If no signature is created in step 203, the respective unmasked coin data set element—here the monetary amounts ν_i ν_j ν_k are added to the corresponding fully masked electronic coin data set Z_i Z_j Z_k according to equation (25a):

ν_i∘Z_iν_j∘Z_jν_k∘Z_k  (25a)

In the monitoring entity 2, a simplified range check can be performed by selecting the fourth masking mode. This also comprises here, for example, four checks. The first check is to check the validity of the incompletely masked coin data set to be switched. This is done according to the previous described type.

The optional second check according to step 206 is to verify the (optional) first signature over the obfuscation amount r_i of the unsplit coin data set C_i. The second verification is performed according to equations (21) and (22). If the second check is successful, it is verified that the monetary amount ν_i, belongs to the masked coin data set Z_i and that the second terminal M2 knows the obfuscation amount r_i.

The third check according to equation (26) is used to prove that no additional money was generated with:

(Z_j∥Z_k)−Z_i==0  (26)

The optional fourth check is then a calculation of the respective public verification keys to check the remaining first signatures with:

Z _j ′=Z _j−ν_j*H  (27)

Z _k ′=Z _k−ν_k*H  (28)

The public verification keys generated in equations (27) and (28) are used to check the respective first signatures:

Z _k′−sig(r_k)  (29)

Z _j′=sig(r_j)  (30)

If the optional fourth check is successful, it is verified that the monetary amount ν_k belongs to the masked coin data set Z_k, that the monetary amount ν_j belongs to the masked coin data set Z_j, and that the second terminal M2 knows the obfuscation amounts r_k and r_j. Finally, a very simple range check can be performed analogous to equation (24).

Checking the combining (as modifying) of two coin data sets C_i and C_j to one combined coin data set C_m is done in a similar way. In optional step 201, selecting the masking mode is performed. According to FIG. 9, in step 201, the second masking mode can be selected in order to avoid having to perform the time-consuming verifications of equations (15) and (16). Then, in step 202, the combined electronic coin data set C_m is formed according to equations (6) and (7). Then, in step 203, the three separate first ones are again formed according to equations (19a) to (19c)

The combining (modifying) is preferably done before the transmitting step 204. The corresponding incomplete masked combined electronic coin data set Z_m transmitted to the monitoring entity 2 in step 204 is sent together with the unmasked data elements from equations (19b), (19c), (19d) or corresponding concatenation according to equation (19a):

ν_k∥sig(r_k);ν_i∥sig(r_i);ν_j∥sig(r_j);Z_m  (31)

If no signature is created in step 203, the respective unmasked coin data set element—here the monetary amounts ν_m ν_j ν_k are added to the corresponding fully masked electronic coin data set Z_m Z_j Z_k according to equation (31a):

ν_m∘Z_mν_j∘Z_jν_k∘Z_k  (31a)

In monitoring entity 2, a simplified range check can be performed by selecting the second masking mode. This also comprises here, for example, four checks. The first check is to check the validity of the incompletely masked coin data set to be switched. This is done in the same way as described above.

The optional second check is to verify the (optional) first signature over the obfuscation amount r_i of the unsplit coin data set C_i. The second verification is performed according to equations (21) and (22). If the second check is successful, it is verified that the monetary amount ν_i belongs to the masked coin data set Z_i and the second terminal M2 knows the obfuscation amount r_i.

The third check is analogous to equation (26) and serves as proof that no additional money was generated.

The optional fourth check is then a calculation of the respective public verification keys for checking the remaining optional first signatures analogous to equations (27) to (30). Finally, a very simple range check can be performed analogous to equation (24).

FIG. 11 shows another embodiment of a method flowchart of a method 300 according to the invention. The method presented in FIG. 11 can be fully applied to any of the previously described methods. It is applicable to all masking modes in the context of simplified verification testing.

The second terminal M2 is in possession of the electronic coin data set C_i, for example by transferring it in step 105. The second terminal can now process the coin data set C_i according to one of the modification steps, split, combine, switch, described previously. To facilitate a range check for a monitoring entity 1, the following steps are performed:

In the terminal M2, after the masking step (of the type described previously), the masked electronic coin data set is split into:

Z _i −Z _j +Z _k−(ν_j*H)+(ν_k*2^y*H+r_k*G)  (32)

Where ν_j is less than a default value x. For example, the default value x is predetermined by the system or is obtained by a negotiation between two participants in the payment system. The default value x can be fixed as a payment system parameter or variable, for example, negotiated between terminals.

A bitwise representation of x, assuming that

x=2^y  (33)

is made as an example of a place value-based split of the masked coin subset Z_k into Z_k,d with base 2 with:

$\begin{array}{cc}{Z}_k=\sum _{d=y}^{n-1}{Z}_{k,d}=\sum _{d=y}^{n-1}\left(v_{k,d}*2^y*H+r_{k,d}*G\right)=\sum _{d=y}^{n-1}\left(a_k{2}^d*H+r_k*G\right)& \left(34\right)\end{array}$

where a_j∈{0,1}. The obfuscation amount r is chosen with:

$\begin{array}{cc}r=\sum _{d=y}^{n-1}{r}_d& \left(35\right)\end{array}$

Example 1: For example, the masked obtained electronic coin data set Z_i=22*H+64*G and the default value x is eight. A bitwise representation of the monetary amount ν_i is 1 0 1 1 0 with y=3, see step 301 in FIG. 11.

The bitwise representation of the monetary amount ν_j is then 110 (as ν_j=6) and Z_j=6*H, the right y-th bits of the monetary amount ν_i are considered.

The bitwise representation of the monetary amount ν_k is then 10000 (as ν_k=16) and Z_j=6*H, when the y-th bits of the monetary amount of ν_i are set equal to zero. The second masked coin partial data set Z_k is then:

$$\begin{gathered} \begin{array}{cc}{Z}_k=16^{*}H64\star G\text{ \\ =(0⋆23⋆H+20⋆G)+(1⋆24⋆H+44⋆G)⁢ \\ -Zk,3+Zk,4}& \left(36\right)\end{array} \end{gathered}$$

The proof check is then as follows:

The second terminal M2 sends the monetary amount ν_k and the list of Z_k,d from equation (34) for y≤d≤n to the monitoring entity 2 in step 302. The monitoring entity 2 checks in step 303 whether:

$\begin{array}{cc}{Z}_i=\sum _{d=y}^{n-1}{Z}_{k,d}+{\upsilon }_j*H& \left(37\right)\end{array}$

If the check fails, the command is rejected. If the check is successful, the monitoring entity 2 proves that there is a corresponding a_d with “0” or “1” for each Z_k,d without disclosing the values. A range check is successful if there is a value of “0” or “1” for each a_d. A ring signature is used for this purpose. With a ring signature, anyone can prove for two or more public keys that the corresponding private keys are known, namely:

Scenario 1: Let it hold:

Z _k,d =r _d *G  (38)

Z _k,d ′:=−H+r _d *G  (39)

For this purpose, a random number w is created in the second terminal M2 in step 304 and calculated from it:

e _l :=h(w*G)  (40)

where h is a hash function and G is the generator point of the ECC curve. Next, the terminal M2 creates a second random number p₁ and calculates:

e ₀ :=h(p₁*G−e₁*Z_k,d)  (41)

p ₀ :=w+e ₀ *r _d  (42)

and transmits the ring signature {e₀, p₀, p₀} to the monitoring entity 2 in step 305. The monitoring entity 2 calculates:

e ₁ =h(p₀*G−e₀*Z_k,d)  (43)

Substituting equation (39) for p₀ and (38) for Z_k,d yields equation (44):

e ₁ =h((w+e₀*r_d)*G−e₀*r_d*G)=h(w*G),  (44)

which corresponds to the original e₁ as defined in the second terminal M2. The monitoring entity 2 calculates:

e ₀ ′=h(p*G−e₁*Z_k,d′)  (45)

and checks whether e₀′=e₀ is correct. Under the assumption that

Z _k,d ′=x*H+r _d *G and x not equal 0  (46)

holds:

e ₁ =h(p₀*G−e₀*Z_k,d)=h(w*G−e₀*x*H)  (47)

which establishes that the second terminal M2 pi with e₀=h(s₁*G−e₁*Z_k,d′).

Scenario 2:

Z _k,d =H+r _d *G  (48)

Z _k,d ′:=r _d *G  (49)

For this, a random number w is created and calculated in the second terminal M2 in step 307:

e ₂ :=h(w*G)  (50)

where h is a hash function and G is the generator point of the ECC curve. Next, the terminal M2 creates a second random number p₀ and calculates:

e ₁ :=h(p₀*G−e₂*Z_k,d)  (51)

p ₁ :=w+e ₁ *r _d  (52)

The terminal M2 also calculates in step 307:

e ₀ =h(p₁*G−e₁*Z_k,d)  (53)

This results in

e ₀ =h((w+e₁*r_d)*G−e₁*r_d*G)=h(w*G)=e₂  (54)

The terminal M2 transmits the ring signature {e₀, p₀, p₁} to the monitoring entity 2 in step 308. The monitoring entity 2 calculates in step 309:

e ₁ =h(p₀*G−e₁*Z_k,d)

e ₀ ′=h(p₁*G−e₁*Z_k,d)  (55)

and checks whether e₀′=e₀ is true. Under the assumption that

Z _k,d ′=x*H+r _d *G with x not equal 0  (56)

holds:

$$\begin{gathered} \begin{array}{cc}{e}_0=h\left(p_1\star G-e_1\star Z_{k,d}\right)\text{ \\ =h⁡(w+e1⋆rd)⋆G-e1⋆rd⋆G-e1⋆x⋆H})\text{ \\ =h⁡(k⋆G-e1*⁢x⋆H)=e2}& \left(57\right)\end{array} \end{gathered}$$

which establishes that the second terminal M2 p₀ with

$\begin{array}{cc}\begin{array}{c}{e}_1=h\left(p_0\star G-e_2\star Z_{k,d}\right)\\ =h\left(p_0-e_2\star r_d\right)\star G-e_2\star \mathrm{II})\end{array}& \left(58\right)\end{array}$

must be found.

Example 2 is not shown figuratively and exemplifies an example in which the place value has an arbitrary base, i.e., contrary to Example 1, it has no base 2. Under the assumption of equation (34) then holds:

A stellar value-wise representation of x, assuming that b is an arbitrary basis

x=b ^y  (59)

occurs as an example of a place value-based split of the masked coin subset Z_k into Z_k,d with:

$\begin{array}{cc}{Z}_k=\sum _{d=y}^{n-1}{Z}_{k,d}=\sum _{d=y}^{n-1}\left(v_{2,d}*b^y*H+r_{2,d}*G\right)=\sum _{d=y}^{n-1}\left(a_d{b}^d*H+r_d*G\right)& \left(60\right)\end{array}$

Where a_j∈{0, . . . , b}. The obfuscation amount r is chosen with:

$\begin{array}{cc}r=\sum _{d=y}^{n-1}{r}_d& \left(61\right)\end{array}$

Example 2: For example, the masked obtained electronic coin data set is again Z_i=22*H+64*G (in analogy to step 301), but here the default value is x=9. A ternary representation of the monetary amount ν_i is 2 1 1 with =2.

The ternary representation of the monetary amount ν_j is then 0 1 1 (as ν_j=4) and Z_j=4*H, the right y-th bits of the monetary amount ν_i are considered.

The ternary representation of the monetary amount ν_k is then 200 (as ν_k=18) when the y-th digits of the monetary amount of ν_i are set equal to zero. The second masked coin partial data set Z_k is then:

$$\begin{gathered} \begin{array}{cc}{Z}_k=18\star H+64\star G\text{ \\ -(2⋆32⋆H+64⋆G)⁢ \\ =Zk,2}& \left(62\right)\end{array} \end{gathered}$$

The verification check is then as follows. The second terminal M2 sends (in analogy to step 302) the monetary amount ν_k and the list of Z_k,d from equation (34) for y≤d<n to the monitoring entity 2. The monitoring entity 2 checks (in analogy to step 303) according to equation (37).

If the check fails, the command is rejected. If the check is successful, monitoring entity 2 proves that for each Z_k,d there is a corresponding a_d with “0 or n” in the range “0<n<b” without disclosing the values. A range check is successful if there is a value of 0<n<b for each a_d. A ring signature is used for this purpose. With a ring signature, anyone can prove for two or more public keys that one of the corresponding private keys are known, namely. Ring signatures are described in MAXWELL et. al. “Borromean Ring Signatures,” Jun. 14, 2015, available at:

https://github.com/Blockstream/borromean_paper/raw/master/borromean_draft_0.01_8c3f9e7.pdfand it is recommended for creating and applying and checking ring signatures to the entire disclosure in MAXWELL et. al. “Borromean Ring Signatures.”

FIGS. 12 and 13 show another embodiment of a method 400 according to the invention, relating to the first masking mode. FIGS. 12 and 13 are described together. The statements previously made from the method 100, 200 and 300 and the individual method steps also apply to this method 400, unless other statements are made herein.

First, the creation of a coin data set for the method 400 is described. In steps 101 and 102, a coin data set is requested and provided on the part of the issuing entity 1 to the first terminal M1 after the electronic coin data set has been created, see also FIGS. 5 to 7. The electronic coin data set C_i has, for example, the structure according to equation (1). The issuing entity 1 calculates a quasi-masked coin data set Z_i for the electronic coin data set C_i according to equation (3a), which has the structure according to equation (63):

Z _i={ν_i;R_i}  (63),

where the value R_i is defined according to equation (64):

R _i =r _i ·G  (64)

G is—like G of equation (3)—a generator point of an elliptic curve cipher, ECC,—i.e., a private key of the ECC. According to equation (65), issuing entity 1 signs the quasi-masked coin data set Z_i using a private signature key PK_i of issuing entity 1:

[ν_i;R_i]sig(PK₁)  (65)

The signed quasi-masked electronic coin data set is transmitted to the monitoring entity 2 in step 103.

The following procedure is used to switch a coin data set C_k. The first terminal M1 transfers the coin C_k to the second terminal M2 in step 105. Although the method steps 401 to 407 shown here are explained with respect to the second terminal M2, they could also be performed in the first terminal M1.

In step 401, which corresponds to step 201 of the method 200, selection of a masking mode is (optionally) performed. To prevent double spending, a switch operation is provided to exchange the electronic coin data set C_k obtained from the first terminal M1 for a new electronic coin data set C_l having the same monetary amount. The new electronic coin data set C_l is generated by the second terminal M2. The monetary amount ν_k of the coin data set C_k is taken over and is not changed to the new monetary amount vi, see also 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 set C_k, obtaining an obfuscation amount r_l known only by the second terminal M2.

The selection according to step 401 is made, for example, by a user of the first terminal M1 via a corresponding menu control on the terminal M1. The selection is made, for example, on the basis of a system default value x in the payment system BZ. For example, a performance of the payment system BZ can be optimally utilized in this way, so that an effort of the verification check (see also step 207) can be controlled based on a current registering request volume in the monitoring entity 2 by selecting the masking mode accordingly. The selection can also be selected based on a terminal property, for example, if one of the masking modes is not supported, a corresponding preselection can be made.

Now, according to FIG. 12, in order to avoid having to perform the time-consuming verification of equations (15) and (16), the third masking mode for obtaining a quasi-masked electronic coin data set is selected in step 401. Then, in step 402, the electronic coin data set C_k is masked according to equations (63), (64) to obtain the quasi-masked electronic coin data set Z_k. In addition, the obfuscation amount is encrypted according to equation (64).

Then, in step 403, a first signature is created according to equation (66):

[Z_k;R_l]sig(r_k)  (66)

This first signature is generated using the quasi-masked electronic coin data set Z_k created in step 402 and the encrypted obfuscation amount R_l created in step 402 with the obfuscation amount r_l as the signature key of the first signature.

The switching (as modifying) is preferably performed before the transmitting step 204. The quasi-masked electronic coin data set Z_l generated in step 404 to the monitoring entity 2 is transmitted together with the signature generated in equation (66).

A simplified range check can be performed in monitoring entity 2. This comprises two checks. The first check according to step 405 is to check the validity (validity) of the quasi-masked coin data set to be switched. This is done according to the previous described type.

The second check according to step 406 is to verify the first signature. For this purpose, the encrypted obfuscation amount R_l of the quasi-masked coin data set Z_l is used as the public verification key of the first signature and it is checked whether the first signature transferred along in step 404 is valid according to equation (66). If both checks are successful, the coin data set C_l is considered valid and a registration by the monitoring entity 2 takes place in step 407.

Checking the splitting (as modifying) of a coin data set C_i is done in a similar way as switching. For example, the first terminal M1 transfers the coin C_i to the second terminal M2 in step 105.

In step 401, the masking mode is selected. In order not to have to perform the elaborate verifications of equations (15) and (16), the third masking mode is now selected in step 401. Then, in step 402, the electronic coin data set C_i is split according to equations (6) and (7) to obtain a first coin partial data set C_j and a second coin partial data set C_k. In addition, the obfuscation amounts r_i, r_k, r_l are encoded into R_i, R_k, and R_l using equation (64).

Then, in step 403, a first signature is created according to equation (67):

[Z_i;Z_k;Z_l]sig(r_i)  (67)

The splitting (modifying) is preferably done before the transmitting step 404. The quasi-masked electronic coin partial data sets Z_k Z_j sent to the monitoring entity 2 in step 404 are sent together with the first signature from equation (67) or corresponding concatenation (cf. equation (19a)):

[Z_i;Z_k;Z_l]sig(r_i);Z_j;Z_k  (68)

In monitoring entity 2, a simplified range check can now be performed. This comprises here four checks. The first check is to check the validity of the incompletely masked coin data set to be switched. This is done according to the previous described type.

The second check according to step 406 is to verify the first signature. For this purpose, the encrypted obfuscation amount R_i of the quasi-masked coin data set Z_i is used as the public verification key of the first signature and it is checked whether the first signature transferred along in step 404 is valid according to equation (67).

The third verification according to equation (69) is used to prove that no additional money was generated with:

ν_i==ν_k+ν_l  (69)

The fourth check is then a range check in monitoring entity 2 with:

ν_min≤ν_k≤ν_max  (70)

ν_min≤ν_l≤ν_max  (71)

If all four checks are successful, the quasi-masked coin data set Z becomes invalid and the coin partial data sets Z_k and Z_l become valid and correspondingly registered in the monitoring entity.

Checking the combining (as modifying) of two coin data sets C_i and C_j into one combined coin data set C_m is done in a similar way. In step 401, the masking mode is selected. In order not to have to perform the elaborate proofs of equations (15) and (16), the third masking mode is selected in step 401. According to equations (63), (64), the obfuscation amounts r_i, r_j, r_m are scrambled to R₁, R_j, and R_m using equation (64) to obtain Z_i, Z_j, and Z_m. Then, in step 403, a first signature is created according to equation (72):

[Z_i,Z_j;Z_m]sig(r_i)  (72)

Then, in step 403, the first signature is re-signed according to equation (72):

[[Z_i;Z_j;Z_m]sig(r_i)]sig(r_j)  (73)

The combining (modifying) is preferably done before the transmitting step 404. The quasi-masked electronic coin partial data set Z_m transmitted to the monitoring entity 2 in step 404 is sent together with the signature from equation (74) or corresponding concatenation (cf. equation (19a)):

[[Z_i;Z_j;Z_m]sig(r_i)]sig(r_j);Z_m  (74)

In the monitoring entity 2, a simplified range check can now be performed. This comprises four checks. The first check is to check the validity of the incompletely masked coin data set to be switched. This is done according to the previous described type.

The second check according to step 406 is to verify the signature from equation (73) and the first signature from equation (72). For this purpose, the encrypted obfuscation amount R_i of the quasi-masked coin data set Z_i or the encrypted obfuscation amount R_j of the quasi-masked coin data set Z_j is used as a public verification key, respectively, and it is checked whether the signature(s) transferred along in step 404 according to equations (72) and (73) are valid.

The third check according to equation (75) is used to verify that no additional money was generated with:

ν_m==ν_i+ν_j  (75)

The fourth test is then a range test in monitoring entity 2 with:

ν_min≤ν_m≤ν_max  (76)

If all four checks are successful, quasi-masked coin data sets Z_i and Z_j become invalid and coin data set Z_m becomes valid and correspondingly registered in monitoring entity 2.

Deletion of a coin data set in method 400 is not shown in FIGS. 12 and 13. For deletion, the terminal transmits a corresponding deletion command to the monitoring entity 2. In the monitoring entity 2, the signature of the issuing entity 1 created according to equation (65) is checked, and if it matches, invalidation occurs in the monitoring entity 2.

Within the scope of the invention, all elements described and/or drawn and/or claimed may be combined in any way.

LIST OF REFERENCE SIGNS

• 1 issuing entity or bank
• 2 monitoring entity
• 21 command entry
• 22 a, b entry of an electronic coin data set to be processed (predecessor)
• 23 a, b entry of a processed electronic coin data set (successor)
• 24 signature entry
• 25 validation check marker
• 26 calculation check marker
• 27 area verification check marker
• 28 the signature check marker
• 3 direct transaction layer
• 4 monitoring layer
• 5 common wallet application
• 10, 10′ data storage
• 11 display
• 12 interface
• 13 computing unit
• 14 vault module
• 15 location detection module
• M1 first terminal
• M2 second terminal
• M3 third terminal
• C_i electronic coin data set
• C_j, C_k split coin electronic data set,
• C_i electronic coin data set to be switched
• C_m electronic coin data set to be combined/combined
• Z_i masked electronic coin data set
• Z_j, Z_k masked split electronic coin partial data set
• Z_i masked electronic coin data set to be switched
• Z_m masked electronic coin data set to be combined
• ν_i, monetary amount
• ν_j, ν_j split monetary amount
• ν_l, monetary amount of an electronic coin data set to be switched
• ν_m, monetary amount of an electronic coin data set to be combined
• r_i obfuscation amount, Random number
• r_j, r_j obfuscation amount of a split electronic coin data set
• r_m obfuscation amount of an electronic coin data set to be combined/combined
• C_i* transferred electronic coin data set
• C_j*, C_k* transferred coin partial electronic data set,
• Z_i* masked transferred electronic coin data set
• Z_i*, Z_k* masked transferred split electronic coin data set
• R masked obfuscation amount
• f(C) (homomorphic) one-way function
• [Z_i]Sig signature of issuing entity
• Sig public verification key of the signature
• sig private signature key of the signature
• w random number
• e, p element of the ring signature
• x Default value
• 101-108 Method steps according to an embodiment example
• 201-208 Process steps according to an embodiment example
• 301-309 Method steps according to an embodiment example
• 401-407 Method steps according to an embodiment example

Claims

1.-27. (canceled)

28. A method for directly transferring electronic coin data sets between terminals for payment in a payment system, wherein a first terminal has at least one electronic coin data set, the at least one electronic coin data set having a monetary amount and an obfuscation amount as coin data set elements, comprising the steps of:masking a first coin data set element of the electronic coin data set in the first terminal, by applying a one-way function to the first coin data set element of the electronic coin data set to obtain a masked first electronic coin data set element;adding a second coin data set element of the electronic coin data set to the masked first electronic coin data set element in the first terminal, for obtaining a quasi-masked electronic coin data set; andtransmitting the quasi-masked electronic coin data set to a monitoring entity for registering the electronic coin data set.

29. The method according to claim 28, wherein the first coin data set element is the obfuscation amount of the electronic coin data set.

30. The method according to claim 28, wherein the second coin data set element: is the monetary amount of the electronic coin data set,wherein a partial amount masked electronic coin data set is obtained as the quasi-masked electronic coin data set, oris a higher-value amount portion of the monetary amount of the electronic coin data set locally split into the higher-value and a lower-value amount portion,wherein an electronic coin data set which is only partially amount-open with respect to the higher-value amount portion is obtained as the quasi-masked electronic coin data set.

31. The method according to claim 28, wherein the method further comprises: determining a masking mode from at least two masking modes,wherein in a first masking mode the quasi-masked electronic coin data set is transmitted and wherein in a second masking mode the electronic coin data set in the first terminal, is masked by applying a one-way function, to the electronic coin data set for obtaining a fully masked electronic coin data set and the fully masked electronic coin data set is transmitted.

32. The method of claim 31, wherein: a third masking mode comprises:splitting by place value the monetary amount of the electronic coin data set in the first terminal, into a first monetary amount part and a second monetary amount part,wherein the base of the place value is arbitrary;masking the first monetary amount part of the monetary amount of the electronic coin data set in the first terminal, by applying the one-way function to the first monetary amount part of the monetary amount of the electronic coin data set to obtain a masked first monetary amount part, and adding the second monetary amount part to the masked first monetary amount part to obtain a partially amount-masked electronic coin data set.

33. The method according to claim 31, wherein the step of registering is either registering the fully masked electronic coin data set or the quasi-masked electronic coin data set or the partially amount-masked electronic coin data set in the monitoring entity, depending on the determined masking mode.

34. The method according to claim 31, wherein the step of determining is performed by selecting the masking mode in the first terminal, wherein a parameter for determining the masking mode is predetermined by the monitoring entity or a service provider and the terminal selects the masking mode based on this parameter.

35. The method according to claim 31, wherein the step of determining is performed by selecting the masking mode in the monitoring entity or by a service provider.

36. The method according to claim 28, wherein the masking mode for an electronic coin data set is changed.

37. The method according to claim 28, comprising the further method steps: generating a signature using the obfuscation amount of the electronic coin data set; andadding the signature to the quasi-masked electronic coin data set or to the fully masked electronic coin data set or to the partially amount-masked electronic coin data set,wherein in the monitoring entity the fully masked electronic coin data set or the partially amount-masked electronic coin data set or the quasi-masked electronic coin data set is registered with the signature.

38. The method according to claim 28, comprising the further method steps: generating a signature using the obfuscation amount of the electronic coin data set; andtransmitting the signature together with the quasi-masked electronic coin data set or the partially amount-masked electronic coin data set,wherein only the partially amount-masked electronic coin data set or the quasi-masked electronic coin data set is registered in the monitoring entity.

39. The method according to claim 28, wherein the monitoring entity registers only partially amount-masked or quasi-masked electronic coin data set; and/or registers only electronic coin data sets that are amount-open for at least an amount portion.

40. The method according to claim 28, comprising the further method steps: switching the electronic coin data set while generating an electronic coin data set to be switched in the first terminal, from the electronic coin data set,wherein an obfuscation amount for the electronic coin data set to be switched is generated using the obfuscation amount of the electronic coin data set in the first terminal and the monetary amount of the electronic coin data set is used as a monetary amount for the electronic coin data set to be switched; and/orsplitting the electronic coin partial data set into a first electronic coin partial data set and a second electronic coin partial data set,wherein the monetary amount is split into at least a first monetary amount and a second monetary amount; and/orcombining a first and a second electronic coin data set into a combined electronic coin data set in the first terminal, comprising the steps of:calculating an obfuscation amount for the electronic coin data set to be combined by forming the sum of the respective obfuscation amounts of the first and second electronic coin data sets; andcalculating the monetary amount for the electronic coin data set to be combined by forming the sum of the respective monetary amounts of the first and second electronic coin data sets;wherein masking the electronic coin data set in the masking step of the first, second or third masking mode comprises masking the coin data set to be switched, the first and/or second coin partial data set and/or the linked coin data set, orwherein masking the data set element of the electronic coin data set, masking the data record element of the coin partial data set to be switched, the data record element, of the first and/or the data record element, of the second coin partial data set and/or the data record element, of the linked coin data set, andtransmitting the fully masked electronic coin data set or the quasi-masked electronic coin data set or the partially amount-masked electronic coin data set to the monitoring entity from the first terminal, to the monitoring entity for checking the validity of the electronic coin data set by the monitoring entity.

41. The method according to claim 40, wherein after said switching step, said registering step comprises, in said monitoring entity for said first masking mode: receiving the quasi-masked electronic coin data set to be switched in the monitoring entity;checking the quasi-masked electronic coin data set for validity in the monitoring entity;checking a signature added to the quasi-masked electronic coin data set using the encrypted obfuscation amount of the electronic coin data set in the monitoring entity; andregistering the quasi-masked electronic coin data set to be switched in the monitoring entity if the two checking steps are successful,wherein the electronic coin data set to be switched is considered valid.

42. The method according to claim 40, wherein after the splitting step, the registering step in the monitoring entity for the first masking mode comprises: receiving the quasi-masked electronic coin partial data set in the monitoring entity;checking the quasi-masked electronic coin data set for validity in the monitoring entity;checking a signature added to the quasi-masked electronic coin partial data set using the masked obfuscation amount in the monitoring entity;checking that the monetary amount of the electronic coin partial data set is equal to the sum of the first and second monetary amounts of the electronic coin partial data sets;registering the quasi-masked electronic coin partial data sets in the monitoring entity if the three checking steps are successful,wherein the electronic coin partial data sets are considered valid and the electronic coin data set to be split is considered invalid.

43. The method according to claim 40, wherein after the combining step, the registering step in the monitoring entity for the first masking mode comprises: receiving the quasi-masked combined electronic coin data set in the monitoring entity;checking the quasi-masked first and second electronic coin data sets for validity in the monitoring entity;checking two signatures added to the quasi-masked combined electronic coin data sets to be combined using the respective masked coin data set elements the masked obfuscation amounts in the monitoring entity;checking whether the monetary amount of the linked electronic coin data set is equal to the sum of the first and second monetary amounts of the first and second electronic coin data sets;registering the quasi-masked combined electronic coin data set in the monitoring entity if the three checking steps are successful,wherein the combined electronic coin data set is considered valid and the two electronic coin data sets to be combined are considered invalid.

44. The method according to claim 37, wherein the added signature is a first signature and a private signature key for generating the first signature is the obfuscation amount of the electronic coin data set.

45. The method according to claim 37, wherein the added signature is a second signature and a private signature key for generating the second signature is formed from a difference of the obfuscation amount of the electronic coin data set and the obfuscation amount for the electronic coin data set to be switched.

46. The method according to claim 43, wherein a public verification key for checking the first signature is formed from a difference of the masked electronic coin data set and applying the cryptographic encryption function to the monetary amount of the electronic coin data set.

47. The method according to claim 43, wherein a public verification key for checking the second signature is formed from a difference between the incompletely masked electronic coin data set and the masked electronic coin data set.

48. The method according to claim 28, wherein the at least one electronic coin data set has been generated by an issuing entity, wherein the issuing entity signs a fully masked or partially amount-masked or quasi-masked electronic coin data set with its signature, and wherein this signature is deposited in the monitoring entity.

49. A payment system for exchanging monetary amounts, the payment system comprising: a monitoring layer having a database in which fully masked electronic coin data sets or partially amount-masked electronic coin data sets or quasi-masked electronic coin data sets are stored; anda direct transaction layer with at least two terminals, in which the method according to claim 28 can be performed; and/or an issuing entity for generating an electronic coin data set and a signature, the signature being stored in the database.

50. A currency system comprising an issuing entity, a monitoring entity, a first terminal and a second terminal, wherein an issuing entity is adapted to create an electronic coin data set,wherein a fully masked electronic coin data set or a partially amount-masked electronic coin data set or a quasi-masked electronic coin data set is adapted to be verifiably created by the issuing entity,wherein the monitoring entity is adapted to perform a registration step according to claim 28.

51. The currency system according to claim 50, wherein the first and second terminals are adapted to perform the method for directly transferring electronic coin data sets between terminals for payment in a payment system.

52. The currency system according to claim 50, wherein the verifying entity and the issuing entity are implemented as a server entity, in particular as a computer program product on a server and/or a computer.

53. The currency system according to claim 50, wherein the first and/or second terminal is designed as a mobile terminal, in particular as a smartphone, a tablet computer, a computer, a server or a machine, and/or as a passive terminal, in particular smart card or as a wearable.

54. A monitoring unit set up to: receive a masked electronic coin data set; andregister the masked electronic coin data set,wherein the masked electronic coin data set is masked in a first masking mode or a second masking mode, according to masking steps from the method of claim 28.