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.

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; and transmitting 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, or is 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; and adding 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; 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.

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/or splitting 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/or 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; 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, or wherein 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, and transmitting 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; and registering 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; and a 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; and register 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.

Description

BRIEF SUMMARY OF THE FIGURES

[0199] 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.

[0200] They show:

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

[0202] FIG. 2 an embodiment example of a monitoring entity;

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

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

[0205] 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;

[0206] 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;

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

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

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

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

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

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

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

FIGURE DESCRIPTION

[0214] 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.

[0215] In this case, an electronic coin data set C.sub.i is generated in an issuing entity 1, for example a central bank. A masked electronic coin data set Z.sub.i is generated for the electronic coin data set C.sub.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.sub.i is output to a first terminal M1.

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

C.sub.i={ν.sub.i;r.sub.i}  (1)

[0217] A valid electronic coin data set can be used for payment. The owner of the two values ν.sub.i and r.sub.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.sub.i. The masked electronic coin data set Z.sub.i is obtained by applying a one-way function f(C.sub.i) according to equation (2):

Z.sub.i=ƒ(C.sub.i)  (2)

[0218] For example, the one-way function f(C.sub.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.

[0219] In particular, this function f(C.sub.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.sub.i) is defined according to equation (3) or equation (3a), for example:

Z.sub.i=ν.sub.i.Math.H+r.sub.i.Math.G  (3)

Z.sub.i=r.sub.i.Math.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.Math.H  (4)

the concatenation n must be practically undetectable to prevent the monetary amount ν.sub.i from being manipulated and a valid Z.sub.i could still be calculated. Equation (3) is a “Pederson commitment for ECC” that ensures that the monetary amount ν.sub.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.sub.i is sent (disclosed) to the public and remote monitoring entity 2.

[0220] 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).

[0221] 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.sub.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).

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

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

[0224] Equations (3) and (3a) use one-way functions, meaning that calculating Z.sub.i from C.sub.i is easy because an efficient algorithm exists, whereas calculating C.sub.i starting from Z.sub.i is very hard because no algorithm that can be solved in polynomial time exists.

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

Z.sub.i+Z.sub.j=(ν.sub.i.Math.H+r.sub.i.Math.G)+(ν.sub.j.Math.H+r.sub.j.Math.G)=(ν.sub.i+ν.sub.j).Math.H+(r.sub.i+r.sub.j).Math.G  (5)

[0226] 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.sub.i. The homomorphic property of equation (3) allows monitoring of valid and invalid electronic coin data sets C.sub.i to be conducted based solely on the masked coin data sets Z.sub.i and to ensure that no new monetary amount ν.sub.i has been created.

[0227] This homomorphic property allows the coin data set C.sub.i to be split according to equation (1) into:

C.sub.i=C.sub.j+C.sub.k={ν.sub.j;r.sub.j}+{ν.sub.k;r.sub.k}  (6)

where holds:

ν.sub.i=ν.sub.j+ν.sub.k  (7)

r.sub.i=r.sub.j+r.sub.k  (8)

[0228] For the corresponding masked coin data sets:

Z.sub.i=Z.sub.j+Z.sub.k  (9)

[0229] 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.sub.i, C.sub.j, C.sub.k. In particular, the condition of equation (9) is checked to declare split coin data sets C.sub.j and C.sub.k valid and coin data set C.sub.k invalid. Such a split of an electronic coin data set C.sub.i is shown in FIG. 3.

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

[0231] Additionally, it is important to check whether (not allowed) negative monetary amounts are registered. An owner of an electronic coin data set C.sub.i must be able to prove to the monitoring entity 2 that all monetary amounts ν.sub.i in a processing operation are within a value range of [0, . . . , 2.sup.n−1] without informing the monitoring entity 2 of the monetary amounts ν.sub.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:

ν.sub.i=Σa.sub.j.Math.2.sup.j for 0≤j≤n and a.sub.j “element” {0;1}  (9a)

as well as

r.sub.i=Σb.sub.j.Math.2.sup.j for 0≤j≤n and b.sub.j “element” {0;1}  (9b)

[0232] For each bit, a ring signature is preferably generated with

C.sub.ij=a.sub.j.Math.H+b.sub.j.Math.G  (9c)

and

C.sub.ij−a.sub.j.Math.H  (9d)

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

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

[0234] Subsequently, the first terminal M1, which can transfer the electronic coin data set C.sub.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.

[0235] In the second terminal M2, the transferred electronic coin data set C.sub.i is obtained as C.sub.i*. Upon obtaining the electronic coin data set C.sub.i*, the second terminal M2 is in possession of the digital money represented by the electronic coin data set C.sub.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.sub.i* is actually valid. Moreover, the terminal M1 could still transfer the electronic coin data set C.sub.i to a third terminal (not shown). To prevent this, further preferred steps in the method are provided.

[0236] To check the validity of the obtained electronic coin data set C.sub.i*, the masked transferred electronic coin data set Z.sub.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.sub.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.sub.i* is indicated to the second terminal M2 and it is valid that the obtained electronic coin data set C.sub.i* is equal to the registered electronic coin data set C.sub.i. With the check for validity, in one embodiment, it can be determined that the obtained electronic coin data set C.sub.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.

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

[0238] 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.sub.i entitles to pay, i.e. to perform a transaction successfully, especially if the coin data set C.sub.i is valid. There is a one-to-one relationship between the electronic coin data sets C.sub.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.sub.i, for example whether new monetary amounts have been created (illegally).

[0239] 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).

[0240] 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-US-00001 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

[0241] 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.

[0242] 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.

[0243] 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.

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

TABLE-US-00002 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

[0245] 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.

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

TABLE-US-00003 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

[0247] 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.sub.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.sub.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.

[0248] 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.sub.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.

[0249] 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.

[0250] The processing operations “create” and “deactivate”, which concern the existence of the monetary amount ν.sub.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).

[0251] 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.

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

(Z.sub.O1+Z.sub.O2)−(Z.sub.S1+Z.sub.S2)==0  (10)

[0253] 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.

[0254] 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.

[0255] 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.

[0256] 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”.

[0257] 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.

[0258] 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.

[0259] 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.

[0260] 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.

[0261] For example, one processing is “generating” an electronic coin data set C.sub.i. Generating in the direct transaction layer 3 by the issuing entity 1 includes selecting a monetary amount ν.sub.i and generating an obfuscation amount r.sub.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.sub.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.sub.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.sub.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.sub.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.

[0262] For example, one processing is “deactivate.” Deactivating, i.e. destroying money (DESTROY), causes the masked electronic coin data set Z.sub.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.sub.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.sub.i, but no successor column 23a, 23b is occupied. The masked electronic coin data set Z.sub.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.sub.i was actually created by an issuing entity 1, although again other means may be used for this check. If the signed C.sub.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.

[0263] One processing is, for example, “split”. The splitting, i.e. the splitting of an electronic coin data record Z.sub.i into a number n, for example 2, of electronic coin data records Z.sub.j and Z.sub.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 ν.sub.j and the obfuscation amount r.sub.j are generated. v.sub.k and r.sub.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.sub.i, successor column 23a is described by Z.sub.j and successor column 23b is described by Z.sub.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.

[0264] One processing is for example “combine”. The combining, i.e., the merging of two electronic coin data sets Z.sub.i and Z.sub.j into one electronic coin data set Z.sub.m is first performed in the direct transaction layer 3, as will be shown in FIG. 4, where the monetary amount ν.sub.m and the obfuscation amount r.sub.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.sub.i, predecessor column 22b is described with Z.sub.j and successor column 23b is described with Z.sub.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.

[0265] 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.sub.k obtained from the first terminal M1 is exchanged for a new electronic coin data set C.sub.l with the same monetary amount. The new electronic coin data set C.sub.l is generated by the second terminal M2. This switching is necessary to invalidate (make invalid) the electronic coin data set C.sub.k obtained from the first terminal M1, thus avoiding reissuing the same electronic coin data set C.sub.k. This is because, as long as the electronic coin data set C.sub.k is not switched, since the first terminal M1 is aware of the electronic coin data set C.sub.k, the first terminal M1 can pass this electronic coin data set C.sub.k to a third terminal M3. The switching is done, for example, by adding a new obfuscation amount r.sub.add to the obfuscation amount r.sub.k of the received electronic coin data set C.sub.k, thereby obtaining an obfuscation amount r.sub.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.sub.add has been added to the obfuscation amount r.sub.k of the masked obtained electronic coin data set Z.sub.k, but the monetary amount has remained the same, and thus equation (11):

ν.sub.k=ν.sub.l  (11)

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

[0266] 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.

[0267] 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.sub.i and now wishes to perform a payment transaction not with the entire monetary amount ν.sub.i, but only with a partial amount ν.sub.k. For this purpose, the coin data set C.sub.i is split. To do this, the monetary amount is first split:

ν.sub.l=ν.sub.j−ν.sub.k  (12)

[0268] Here, each of the obtained amounts ν.sub.j, ν.sub.k, must be greater than 0, because negative monetary amounts are not allowed.

[0269] In addition, new obfuscation amounts are derived:

r.sub.i=r.sub.j+r.sub.k  (13)

[0270] When split, masked coin data sets Z.sub.j and Z.sub.k are obtained from the coin data sets C.sub.j and C.sub.k according to equation (3) and registered in monitoring entity 2. For splitting, the predecessor column 22a is written with coin data set Z.sub.i, the successor column 23a is written with 4, and the successor column 23b is written with Z.sub.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.

[0271] Then a coin partial data set, here C.sub.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.sub.k obtained from the first terminal M1 for a new electronic coin data set C.sub.l with the same monetary amount. The new electronic coin data set C.sub.l is generated by the second terminal M2. In this process, the monetary amount of the coin data set C.sub.l is adopted and not changed, see equation (11).

[0272] Then, according to equation (14), a new obfuscation amount r.sub.add is added to the obfuscation amount r.sub.k of the obtained electronic coin data set C.sub.k,

r.sub.l=r.sub.k+r.sub.add  (14)

thereby obtaining an obfuscation amount r.sub.l known only to the second terminal M2. In order to prove that only a new obfuscation amount r.sub.add has been added to the obfuscation amount r.sub.k of the obtained electronic coin data set Z.sub.k, but that the monetary amount has remained the same (ν.sub.k=ν.sub.l), the second terminal M2 must be able to prove that Z.sub.l−Z.sub.k can be represented as a multiple of G. This is done using public signature R.sub.add according to equation (15):

[00001]$\begin{array}{cc}{R}_{\mathrm{add}}=r_{\mathrm{add}}.Math.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.sub.l to be switched is masked using equation (3) or equation (3a) to obtain the masked coin data set Z.sub.l. In the monitoring entity 2, the private signature r.sub.add can then be used to sign, for example, the masked switchable electronic coin data set Z.sub.l, which is considered as a proof that the second terminal M2 has only added an obfuscation amount r.sub.add to the masked electronic coin data set and no additional monetary value, i.e. v.sub.l=v.sub.k.

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

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

[0274] For masking using equation (3a), a signature is generated over the monetary amount ν.sub.k, the obfuscation amount r.sub.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.

[0275] 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.sub.i and C.sub.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.sub.i and C.sub.j. Then, the obtained coin data set C.sub.m to be combined is masked using equation (3) or equation (3a) and the masked coin data set Z.sub.m is registered in the monitoring entity.

[0276] For masking using equation (3a), a first signature is generated over the monetary amount ν.sub.i, the obfuscation amount r.sub.i, and the masked coin data set, and a second signature is generated over the monetary amount ν.sub.j, the obfuscation amount r.sub.j, and the masked coin data set Z.sub.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.

[0277] 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.sub.i is performed according to equation (3) and as explained in FIG. 1. Then, in step 104, the masked electronic coin data set Z.sub.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.sub.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.sub.i and C.sub.i, respectively.

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

[0279] In step 108′, the corresponding check is carried out in monitoring entity 2, with Z.sub.k being entered in column 22a according to the table in FIG. 2 and the coin data set Z.sub.l to be switched being entered in column 23b. A check is then carried out in monitoring entity 2 to determine whether Z.sub.k is (still) valid, i.e. whether the last processing of Z.sub.k is entered in one of the columns 23a/b (as proof that Z.sub.k has not been further split or deactivated or combined) and whether a check for the last processing has failed. In addition, Z.sub.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.sub.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.sub.k and Z.sub.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.sub.k is no longer valid and the coin data set C.sub.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.

[0280] In step 109, a combining of two coin data sets C.sub.k and C.sub.i onto a new coin data set C.sub.m is performed, making the coin data sets C.sub.k, C.sub.i invalid and preventing double spending. To do this, the monetary amount nm is formed from the two monetary amounts ν.sub.k and ν.sub.i. For this purpose, the obfuscation amount r.sub.m is formed from the two obfuscation amounts r.sub.k and r.sub.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.

[0281] In step 109′, the corresponding check is performed in monitoring entity 2, with Z.sub.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.sub.k and Z.sub.i are (still) valid, i.e. whether the last processing of Z.sub.k or Z.sub.i is entered in one of the columns 23a/b (as proof that Z.sub.k and Z.sub.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.sub.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.sub.i plus Z.sub.k equals Z.sub.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.

[0282] In step 110′, the corresponding check is performed in monitoring entity 2, where Z.sub.j and Z.sub.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.sub.i is (still) valid, i.e. whether the last processing of Z.sub.i is entered in one of the columns 23a/b (as proof that Z.sub.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.sub.j and Z.sub.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.sub.i is equal to Z.sub.k plus Z.sub.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.

[0283] 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.sub.i in a data memory 10, 10′. In this regard, the electronic coin data sets C.sub.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.sub.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.

[0284] In one case, the electronic coin data set C.sub.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).

[0285] The device M1 has at least one interface 12 available as a communication channel for outputting the coin data set C.sub.i. This interface 12 is for example an optical interface, for example for displaying the coin data set C.sub.i on a display unit (display), or a printer for printing the electronic coin data set C.sub.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.sub.i is transferred between devices via an application, such as an instant messenger service, or as a file or string.

[0286] 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.

[0287] 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.

[0288] 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.

[0289] 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.

[0290] In the simplest case, all coin data sets C.sub.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.

[0291] 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.

[0292] 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.sub.k to the second terminal.

[0293] 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.sub.k obtained from the first terminal M1 for a new electronic coin data set C.sub.l having the same monetary amount. The new electronic coin data set C.sub.l is generated by the second terminal M2. The monetary amount ν.sub.k of the coin data set C.sub.k is taken over and is not changed to the new monetary amount ν.sub.l, see equation (11). Then, according to equation (14), a new obfuscation amount r.sub.add is added to the obfuscation amount r.sub.k of the obtained electronic coin data set C.sub.k, obtaining an obfuscation amount r.sub.l that only the second terminal M2 knows.

[0294] 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.

[0295] 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.sub.i can be masked in step 202 according to equation (3) to obtain the fully masked electronic coin data set Z.sub.i according to second masking mode.

[0296] In step 203, a first signature is optionally created using the obfuscation amount r.sub.k as the signature key according to equation (17):

[Z.sub.k]sig(r.sub.k)  (17)

[0297] In addition, in step 203, a second signature is optionally created with the difference of the obfuscation amounts r.sub.i and r.sub.l as signature key according to equation (18):

[Z.sub.k]sig(r.sub.l−r.sub.k)  (18)

[0298] In step 203, the monetary amount ν.sub.k of the received electronic coin data set C.sub.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):

ν.sub.k∥sig(r.sub.k)  (19)

ν.sub.k∘sig(r.sub.k)  (19a)

[0299] 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:

ν.sub.k∥sig(r.sub.k);sig(r.sub.l−r.sub.k);Z.sub.l  (20)

ν.sub.k∥sig(r.sub.k)∘sig(r.sub.l−r.sub.k)∘Z.sub.l  (20a)

[0300] If no signature is created in step 203, the unmasked coin data set element—here the monetary amount ν.sub.k or the identical monetary amount ν.sub.l is added to the fully masked electronic coin data set Z.sub.l according to equation (20b):

ν.sub.k∘Z.sub.lbzw.Math.ν.sub.l∘Z.sub.l  (20b)

[0301] 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.

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

Z.sub.k′=Z.sub.k−ν.sub.k*H  (21)

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

Z.sub.k′=sig(r.sub.k)  (22)

[0304] If the second verification is successful, it is proven that the monetary amount ν.sub.k belongs to the masked coin data set Z.sub.k and that the second terminal M2 knows the obfuscation amount r.sub.k.

[0305] 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.sub.l to be switched and the masked obtained coin data set Z.sub.k:

Z.sub.l−Z.sub.k=sig(r.sub.lr.sub.k)  (23)

[0306] 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 ν.sub.k ν.sub.l equals zero, thus proving that no new/additional money has been generated.

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

ν.sub.min≤ν.sub.k≤ν.sub.max  (24)

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

[0309] 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.sub.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.sub.k. In step 203, three separate first signatures can then optionally be created over the obfuscation amounts r.sub.i, r.sub.j and r.sub.k according to equation (17). In addition, each of the monetary amounts ν.sub.i ν.sub.j ν.sub.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:

ν.sub.i∥sig(r.sub.i)  (19b)

ν.sub.j∥sig(r.sub.j)  (19c)

ν.sub.k∥sig(r.sub.k)  (19d)

[0310] The splitting (modifying) is preferably done before the transmitting step 204. The corresponding incomplete masked electronic coin partial data sets Z.sub.k Z.sub.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):

ν.sub.k∥sig(r.sub.k);ν.sub.i∥sig(r.sub.i);ν.sub.j∥sig(r.sub.j);Z.sub.j;Z.sub.k  (25)

[0311] If no signature is created in step 203, the respective unmasked coin data set element—here the monetary amounts ν.sub.i ν.sub.j ν.sub.k are added to the corresponding fully masked electronic coin data set Z.sub.i Z.sub.j Z.sub.k according to equation (25a):

ν.sub.i∘Z.sub.iν.sub.j∘Z.sub.jν.sub.k∘Z.sub.k  (25a)

[0312] 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.

[0313] The optional second check according to step 206 is to verify the (optional) first signature over the obfuscation amount r.sub.i of the unsplit coin data set C.sub.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 ν.sub.i, belongs to the masked coin data set Z.sub.i and that the second terminal M2 knows the obfuscation amount r.sub.i.

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

(Z.sub.j∥Z.sub.k)−Z.sub.i==0  (26)

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

Z.sub.j′=Z.sub.j−ν.sub.j*H  (27)

Z.sub.k′=Z.sub.k−ν.sub.k*H  (28)

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

Z.sub.k′−sig(r.sub.k)  (29)

Z.sub.j′=sig(r.sub.j)  (30)

[0317] If the optional fourth check is successful, it is verified that the monetary amount ν.sub.k belongs to the masked coin data set Z.sub.k, that the monetary amount ν.sub.j belongs to the masked coin data set Z.sub.j, and that the second terminal M2 knows the obfuscation amounts r.sub.k and r.sub.j. Finally, a very simple range check can be performed analogous to equation (24).

[0318] Checking the combining (as modifying) of two coin data sets C.sub.i and C.sub.j to one combined coin data set C.sub.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.sub.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)

[0319] The combining (modifying) is preferably done before the transmitting step 204. The corresponding incomplete masked combined electronic coin data set Z.sub.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):

ν.sub.k∥sig(r.sub.k);ν.sub.i∥sig(r.sub.i);ν.sub.j∥sig(r.sub.j);Z.sub.m  (31)

[0320] If no signature is created in step 203, the respective unmasked coin data set element—here the monetary amounts ν.sub.m ν.sub.j ν.sub.k are added to the corresponding fully masked electronic coin data set Z.sub.m Z.sub.j Z.sub.k according to equation (31a):

ν.sub.m∘Z.sub.mν.sub.j∘Z.sub.jν.sub.k∘Z.sub.k  (31a)

[0321] 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.

[0322] The optional second check is to verify the (optional) first signature over the obfuscation amount r.sub.i of the unsplit coin data set C.sub.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 ν.sub.i belongs to the masked coin data set Z.sub.i and the second terminal M2 knows the obfuscation amount r.sub.i.

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

[0324] 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).

[0325] 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.

[0326] The second terminal M2 is in possession of the electronic coin data set C.sub.i, for example by transferring it in step 105. The second terminal can now process the coin data set C.sub.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:

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

Z.sub.i−Z.sub.j+Z.sub.k−(ν.sub.j*H)+(ν.sub.k*2.sup.y*H+r.sub.k*G)  (32)

[0328] Where ν.sub.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.

[0329] A bitwise representation of x, assuming that

x=2.sup.y  (33)

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

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

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

[00004]$\begin{array}{cc}r=\underset{d=y}{\overset{n-1}{.Math.}}{r}_d& \left(35\right)\end{array}$

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

[0331] The bitwise representation of the monetary amount ν.sub.j is then 110 (as ν.sub.j=6) and Z.sub.j=6*H, the right y-th bits of the monetary amount ν.sub.i are considered.

[0332] The bitwise representation of the monetary amount ν.sub.k is then 10000 (as ν.sub.k=16) and Z.sub.j=6*H, when the y-th bits of the monetary amount of ν.sub.i are set equal to zero. The second masked coin partial data set Z.sub.k is then:

[00005]$$\begin{gathered} \begin{array}{cc}{Z}_k=16^{*}H64\star G \\ =\left(0\star 2^3\star H+20\star G\right)+\left(1\star 2^4\star H+44\star G\right) \\ -Z_{k,3}+Z_{k,4}& \left(36\right)\end{array} \end{gathered}$$

[0333] The proof check is then as follows:

[0334] The second terminal M2 sends the monetary amount ν.sub.k and the list of Z.sub.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:

[00006]$\begin{array}{cc}{Z}_i=\underset{d=y}{\overset{n-1}{.Math.}}{Z}_{k,d}+{\upsilon }_j*H& \left(37\right)\end{array}$

[0335] If the check fails, the command is rejected. If the check is successful, the monitoring entity 2 proves that there is a corresponding a.sub.d with “0” or “1” for each Z.sub.k,d without disclosing the values. A range check is successful if there is a value of “0” or “1” for each a.sub.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:

[0336] Scenario 1: Let it hold:

Z.sub.k,d=r.sub.d*G  (38)

Z.sub.k,d′:=−H+r.sub.d*G  (39)

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

e.sub.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.sub.1 and calculates:

e.sub.0:=h(p.sub.1*G−e.sub.1*Z.sub.k,d)  (41)

p.sub.0:=w+e.sub.0*r.sub.d  (42)

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

e.sub.1=h(p.sub.0*G−e.sub.0*Z.sub.k,d)  (43)

[0338] Substituting equation (39) for p.sub.0 and (38) for Z.sub.k,d yields equation (44):

e.sub.1=h((w+e.sub.0*r.sub.d)*G−e.sub.0*r.sub.d*G)=h(w*G),  (44)

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

e.sub.0′=h(p*G−e.sub.1*Z.sub.k,d′)  (45)

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

Z.sub.k,d′=x*H+r.sub.d*G and x not equal 0  (46)

holds:

e.sub.1=h(p.sub.0*G−e.sub.0*Z.sub.k,d)=h(w*G−e.sub.0*x*H)  (47)

which establishes that the second terminal M2 pi with e.sub.0=h(s.sub.1*G−e.sub.1*Z.sub.k,d′).

[0339] Scenario 2:

Z.sub.k,d=H+r.sub.d*G  (48)

Z.sub.k,d′:=r.sub.d*G  (49)

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

e.sub.2:=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.sub.0 and calculates:

e.sub.1:=h(p.sub.0*G−e.sub.2*Z.sub.k,d)  (51)

p.sub.1:=w+e.sub.1*r.sub.d  (52)

[0341] The terminal M2 also calculates in step 307:

e.sub.0=h(p.sub.1*G−e.sub.1*Z.sub.k,d)  (53)

[0342] This results in

e.sub.0=h((w+e.sub.1*r.sub.d)*G−e.sub.1*r.sub.d*G)=h(w*G)=e.sub.2  (54)

[0343] The terminal M2 transmits the ring signature {e.sub.0, p.sub.0, p.sub.1} to the monitoring entity 2 in step 308. The monitoring entity 2 calculates in step 309:

e.sub.1=h(p.sub.0*G−e.sub.1*Z.sub.k,d)

e.sub.0′=h(p.sub.1*G−e.sub.1*Z.sub.k,d)  (55)

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

Z.sub.k,d′=x*H+r.sub.d*G with x not equal 0  (56)

holds:

[00007]$$\begin{gathered} \begin{array}{cc}{e}_0=h\left(p_1\star G-e_1\star Z_{k,d}\right) \\ =h\left(w+e_1\star r_d\right)\star G-e_1\star r_d\star G-e_1\star x\star H) \\ =h\left(k\star G-e_{1^{*}}x\star H\right)=e_2& \left(57\right)\end{array} \end{gathered}$$

[0344] which establishes that the second terminal M2 p.sub.0 with

[00008]$\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.

[0345] 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:

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

x=b.sup.y  (59)

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

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

[0347] Where a.sub.j∈{0, . . . , b}. The obfuscation amount r is chosen with:

[00010]$\begin{array}{cc}r=\underset{d=y}{\overset{n-1}{.Math.}}{r}_d& \left(61\right)\end{array}$

[0348] Example 2: For example, the masked obtained electronic coin data set is again Z.sub.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 ν.sub.i is 2 1 1 with =2.

[0349] The ternary representation of the monetary amount ν.sub.j is then 0 1 1 (as ν.sub.j=4) and Z.sub.j=4*H, the right y-th bits of the monetary amount ν.sub.i are considered.

[0350] The ternary representation of the monetary amount ν.sub.k is then 200 (as ν.sub.k=18) when the y-th digits of the monetary amount of ν.sub.i are set equal to zero. The second masked coin partial data set Z.sub.k is then:

[00011]$$\begin{gathered} \begin{array}{cc}{Z}_k=18\star H+64\star G \\ -\left(2\star 3^2\star H+64\star G\right) \\ =Z_{k,2}& \left(62\right)\end{array} \end{gathered}$$

[0351] The verification check is then as follows. The second terminal M2 sends (in analogy to step 302) the monetary amount ν.sub.k and the list of Z.sub.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).

[0352] If the check fails, the command is rejected. If the check is successful, monitoring entity 2 proves that for each Z.sub.k,d there is a corresponding a.sub.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.sub.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.pdf
and it is recommended for creating and applying and checking ring signatures to the entire disclosure in MAXWELL et. al. “Borromean Ring Signatures.”

[0353] 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.

[0354] 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.sub.i has, for example, the structure according to equation (1). The issuing entity 1 calculates a quasi-masked coin data set Z.sub.i for the electronic coin data set C.sub.i according to equation (3a), which has the structure according to equation (63):

Z.sub.i={ν.sub.i;R.sub.i}  (63),

where the value R.sub.i is defined according to equation (64):

R.sub.i=r.sub.i.Math.G  (64)

[0355] 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.sub.i using a private signature key PK.sub.i of issuing entity 1:

[ν.sub.i;R.sub.i]sig(PK.sub.1)  (65)

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

[0357] The following procedure is used to switch a coin data set C.sub.k. The first terminal M1 transfers the coin C.sub.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.

[0358] 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.sub.k obtained from the first terminal M1 for a new electronic coin data set C.sub.l having the same monetary amount. The new electronic coin data set C.sub.l is generated by the second terminal M2. The monetary amount ν.sub.k of the coin data set C.sub.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.sub.add is added to the obfuscation amount r.sub.k of the obtained electronic coin data set C.sub.k, obtaining an obfuscation amount r.sub.l known only by the second terminal M2.

[0359] 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.

[0360] 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.sub.k is masked according to equations (63), (64) to obtain the quasi-masked electronic coin data set Z.sub.k. In addition, the obfuscation amount is encrypted according to equation (64).

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

[Z.sub.k;R.sub.l]sig(r.sub.k)  (66)

[0362] This first signature is generated using the quasi-masked electronic coin data set Z.sub.k created in step 402 and the encrypted obfuscation amount R.sub.l created in step 402 with the obfuscation amount r.sub.l as the signature key of the first signature.

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

[0364] 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.

[0365] The second check according to step 406 is to verify the first signature. For this purpose, the encrypted obfuscation amount R.sub.l of the quasi-masked coin data set Z.sub.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.sub.l is considered valid and a registration by the monitoring entity 2 takes place in step 407.

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

[0367] 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.sub.i is split according to equations (6) and (7) to obtain a first coin partial data set C.sub.j and a second coin partial data set C.sub.k. In addition, the obfuscation amounts r.sub.i, r.sub.k, r.sub.l are encoded into R.sub.i, R.sub.k, and R.sub.l using equation (64).

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

[Z.sub.i;Z.sub.k;Z.sub.l]sig(r.sub.i)  (67)

[0369] The splitting (modifying) is preferably done before the transmitting step 404. The quasi-masked electronic coin partial data sets Z.sub.k Z.sub.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.sub.i;Z.sub.k;Z.sub.l]sig(r.sub.i);Z.sub.j;Z.sub.k  (68)

[0370] 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.

[0371] The second check according to step 406 is to verify the first signature. For this purpose, the encrypted obfuscation amount R.sub.i of the quasi-masked coin data set Z.sub.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).

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

ν.sub.i==ν.sub.k+ν.sub.l  (69)

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

ν.sub.min≤ν.sub.k≤ν.sub.max  (70)

ν.sub.min≤ν.sub.l≤ν.sub.max  (71)

[0374] If all four checks are successful, the quasi-masked coin data set Z becomes invalid and the coin partial data sets Z.sub.k and Z.sub.l become valid and correspondingly registered in the monitoring entity.

[0375] Checking the combining (as modifying) of two coin data sets C.sub.i and C.sub.j into one combined coin data set C.sub.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.sub.i, r.sub.j, r.sub.m are scrambled to R.sub.1, R.sub.j, and R.sub.m using equation (64) to obtain Z.sub.i, Z.sub.j, and Z.sub.m. Then, in step 403, a first signature is created according to equation (72):

[Z.sub.i,Z.sub.j;Z.sub.m]sig(r.sub.i)  (72)

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

[[Z.sub.i;Z.sub.j;Z.sub.m]sig(r.sub.i)]sig(r.sub.j)  (73)

[0377] The combining (modifying) is preferably done before the transmitting step 404. The quasi-masked electronic coin partial data set Z.sub.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.sub.i;Z.sub.j;Z.sub.m]sig(r.sub.i)]sig(r.sub.j);Z.sub.m  (74)

[0378] 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.

[0379] 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.sub.i of the quasi-masked coin data set Z.sub.i or the encrypted obfuscation amount R.sub.j of the quasi-masked coin data set Z.sub.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.

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

ν.sub.m==ν.sub.i+ν.sub.j  (75)

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

ν.sub.min≤ν.sub.m≤ν.sub.max  (76)

[0382] If all four checks are successful, quasi-masked coin data sets Z.sub.i and Z.sub.j become invalid and coin data set Z.sub.m becomes valid and correspondingly registered in monitoring entity 2.

[0383] 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.

[0384] 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

[0385] 1 issuing entity or bank [0386] 2 monitoring entity [0387] 21 command entry [0388] 22a, b entry of an electronic coin data set to be processed (predecessor) [0389] 23a, b entry of a processed electronic coin data set (successor) [0390] 24 signature entry [0391] 25 validation check marker [0392] 26 calculation check marker [0393] 27 area verification check marker [0394] 28 the signature check marker [0395] 3 direct transaction layer [0396] 4 monitoring layer [0397] 5 common wallet application [0398] 10, 10′ data storage [0399] 11 display [0400] 12 interface [0401] 13 computing unit [0402] 14 vault module [0403] 15 location detection module [0404] M1 first terminal [0405] M2 second terminal [0406] M3 third terminal [0407] C.sub.i electronic coin data set [0408] C.sub.j, C.sub.k split coin electronic data set, [0409] C.sub.i electronic coin data set to be switched [0410] C.sub.m electronic coin data set to be combined/combined [0411] Z.sub.i masked electronic coin data set [0412] Z.sub.j, Z.sub.k masked split electronic coin partial data set [0413] Z.sub.i masked electronic coin data set to be switched [0414] Z.sub.m masked electronic coin data set to be combined [0415] ν.sub.i, monetary amount [0416] ν.sub.j, ν.sub.j split monetary amount [0417] ν.sub.l, monetary amount of an electronic coin data set to be switched [0418] ν.sub.m, monetary amount of an electronic coin data set to be combined [0419] r.sub.i obfuscation amount, Random number [0420] r.sub.j, r.sub.j obfuscation amount of a split electronic coin data set [0421] r.sub.m obfuscation amount of an electronic coin data set to be combined/combined [0422] C.sub.i* transferred electronic coin data set [0423] C.sub.j*, C.sub.k* transferred coin partial electronic data set, [0424] Z.sub.i* masked transferred electronic coin data set [0425] Z.sub.i*, Z.sub.k* masked transferred split electronic coin data set [0426] R masked obfuscation amount [0427] f(C) (homomorphic) one-way function [0428] [Z.sub.i]Sig signature of issuing entity [0429] Sig public verification key of the signature [0430] sig private signature key of the signature [0431] w random number [0432] e, p element of the ring signature [0433] x Default value [0434] 101-108 Method steps according to an embodiment example [0435] 201-208 Process steps according to an embodiment example [0436] 301-309 Method steps according to an embodiment example [0437] 401-407 Method steps according to an embodiment example