METHOD, TERMINAL, AND COIN REGISTER FOR TRANSMITTING ELECTRONIC COIN DATA SETS

Abstract

A first security element is for transmitting an electronic coin data set to a second security element. The electronic coin data set is registered in a coin register of a payment system. The method has the steps of: setting a status of the electronic coin data set from the security element to an inactive status; transmitting the electronic coin data set from the first security element to the second security element; checking whether a receipt confirmation from the second security element has been received in the first security element; and deleting the transmitted electronic coin data set if the checking step results in that the receipt confirmation has been obtained by the first security element. The aforementioned relates to a payment system, a coin register, a security element, and a terminal for transmitting electronic coin data sets.

Claims

1.-19. (canceled)

20. A method in a first security element for transmitting an electronic coin data set to a second security element, wherein the electronic coin data set is registered in a coin register of a payment system, comprising the method steps of: setting a status of the electronic coin data set from the first security element to an inactive status, sending the electronic coin data set from the first security element to the second security element, checking whether a receipt confirmation has been received from the second security element in the first security element; and deleting the sent electronic coin data set when the checking step determines that the receipt confirmation was received from the first security element.

21. The method according to claim 20, wherein at least one of said security elements is operationally inserted into a device.

22. The method according to claim 20, wherein the setting of the status occurs immediately before or after the sending step.

23. The method according to claim 20, wherein the electronic coin data set is sent cryptographically secured.

24. The method according to claim 20, wherein a transaction data set relating to the sent electronic coin data set is stored in the first security element.

25. The method according to claim 24, wherein the transaction data set has at least: a transaction number, an identifier or address of the first security element, an identifier or address of the second security element, and an amount of the electronic coin data set.

26. The method according to claim 24, wherein in a transmission error case the electronic coin data set is resent based on the stored transaction data set.

27. The method according to claim 20, wherein after the deleting step a successful transmission is indicated in the first security element.

28. The method according to claim 27, wherein in the indication step the electronic coin data set is evaluated as an input parameter of an application of a terminal containing the first security element.

29. The method according to claim 20, wherein the first security element indicates to the second security element, or the coin register the deletion of the sent coin data set after the deletion step.

30. The method according to claim 20, wherein the second security element sets a status of the electronic coin data set to an active status after the deletion step.

31. The method according to claim 20, wherein in a transmission error case a status of the sent electronic coin data set in the first security element is reset to an active status.

32. The method according to claim 20, wherein in a transmission error case, the first security element queries a status of the sent electronic coin data set from the coin register and: in the event that the sent electronic coin data set is registered to the first security element, resets a status of the sent coin data set in the first security element by the first security element to an active status; and in the event the sent electronic coin data set is not registered to the first security element, reporting a transaction error to the coin register by the first security element.

33. The method according to claim 20, wherein in a transmission error case, the second security element queries a status of the sent electronic coin data set from the coin register and: in the event the sent electronic coin data set is registered to the first security element, deleting the sent coin data set in the second security element by the second security element; and in the event the sent electronic coin data set is not registered to the first security element, reporting a transaction error to the coin register by the second security element.

34. The method according to claim 20, wherein, in the event of not receiving the receipt confirmation, the first security element re-registers the sent coin data set in the coin register.

35. A security element having: a computing unit arranged to transmit electronic coin data sets according to a method of claim 20, means for accessing a data memory, wherein at least one electronic coin data set is stored in the data memory; and an interface arranged to output the at least one electronic coin data set to another security element.

36. A terminal with a security element according to claim 35, wherein the interface is arranged to output the at least one electronic coin data set to the other security element via an interface of the terminal.

37. A payment system having a coin register, at least one terminal according to claim 36 and an issuing entity adapted to create an electronic coin data set for the payment system, wherein the first security element is arranged in the terminal for executing the method.

38. A coin register for a payment system, wherein the coin register is arranged to register electronic coin data sets according to the method of claim 20.

Description

BRIEF SUMMARY OF FIGURES

[0150] In the following, the invention or further embodiments and advantages of the invention will be explained in more detail with reference to figures, wherein the figures only describe 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.

[0151] It is shown:

[0152] FIG. 1a,b an embodiment of a payment system according to the prior art;

[0153] FIG. 2 an embodiment of a method flow diagram of a method according to the invention;

[0154] FIG. 3 an embodiment of a further development of the method flow diagram shown in FIG. 2;

[0155] FIG. 4 an embodiment of a further development of the method flow diagram shown in FIG. 2.

[0156] FIG. 5 an embodiment of a method flow diagram of a method according to the invention in the first security element;

[0157] FIG. 6 an embodiment of a system according to the invention;

[0158] FIG. 7 an embodiment of a payment system, in particular a coin register;

[0159] FIG. 8 an embodiment of a system according to the invention for splitting and switching and directly transmitting electronic coin data sets;

[0160] FIG. 9 an embodiment of a payment system according to the invention for merging electronic coin data sets;

[0161] FIG. 10 an embodiment of a method flow diagram of a method according to the invention and corresponding processing steps of a coin data set;

[0162] FIG. 11 an embodiment of a method flow diagram of a method according to the invention and corresponding processing steps of a coin data set;

[0163] FIG. 12 an embodiment of a security element according to the invention; and

[0164] FIG. 13 a system according to the invention.

FIGURE DESCRIPTION

[0165] FIG. 1a and FIG. 1b show an embodiment of a payment system according to the prior art and already described in the introduction. By way of repetition it is pointed out, that the terminal M8 wishes to register the coin data set C.sub.c as the coin data set C.sub.e at the coin register 4 and the coin register 4 determines that the coin data set C.sub.b is already invalid. As a result, the coin register 4 does not accept either the supposedly valid coin data set C.sub.c or the coin data set C.sub.e to be switched.

[0166] The problem can occur when, for example, an attacker M1 passes the coin data set C.sub.b directly to two subscribers M2 and M3. As soon as M2 registers the coin data set in the coin register 4, the coin data set C.sub.b becomes invalid. An unsuspecting subscriber (terminal) M3 instead passes on the coin data set C.sub.b directly without having it registered. Only the terminal M8 breaks the direct transmission chain, wherein the coin register 4 recognises the invalidity of the coin data set C.sub.b and the double-spending is detected. A central bank (hereinafter synonymous with an issuing entity of the electronic coin data sets) therefore wants, on the one hand, to limit the number of direct transmitting of coin data sets and, on the other hand, in the event of a detected attack, to be able to trace where the attack took place.

[0167] Thus, in the prior art, an attack (double spending of an electronic coin data set) by M1 is detected much later and a large number of direct transmissions have been carried out in an unauthorised manner. In addition, the large number of transactions of an electronic coin data set and also the advancing lifespan increase the risk of manipulation(s) of the electronic coin data set. It is therefore desirable that when a certain lifetime or number of actions in total on/with the coin data set is exceeded, the coin data set expires.

[0168] The overall system according to the invention comprises an issuing entity (central bank), at least one payment system and a plurality of subscribers represented as security elements (terminals Mx). The payment system comprises, for example, commercial banks and one (or more) central coin registers, which registers the coin data sets and checks and logs the modifications to the coin data set. Another example of an overall system is also shown in FIG. 13.

[0169] FIG. 2 shows an embodiment of a flow chart of a method according to the invention for transmitting 105 an electronic coin data set, hereinafter eMD for short, C from a first security element SE1 to a second security element SE2. The security elements SE are, for example, eUICC or smart cards.

[0170] The SE1 may have received an eMD C from a less trusted entity, such as a terminal or machine or online service, as a subscriber in the payment system. For example, an import function is provided in the SE1 for this purpose. EMDs from such an insecure origin, in particular not directly from another SE, are considered insecure and are checked for validity after receipt in the SE using the coin register 2 of the payment system.

[0171] The SE1 registers the eMD C to itself in optional step 104, as will be explained below. In step 301, the SE1 sets the status of the eMD C to “inactive” to begin transmitting 105 the eMD C to the SE2. Optionally, the changed status is registered in the coin register 4. For example, the status is set in a data memory of the SE1. In addition (not shown), the SE1 optionally creates a transaction data set consisting of a transaction number, a recipient address (here of SE2), a sender address (here of SE1), and a monetary amount of the eMD C and stores it in the SE1. The transaction data set can be used to log the transmit 105 and can be used to reverse (FIG. 4) or retry (FIG. 3) in the event of an error.

[0172] In step 302, the eMD C is sent to the SE2. For this purpose, a secure channel was established between the SE1 and the SE2, in which both SEs authenticated each other. The transmission path between the SE1 and SE2 is not necessarily direct, but can be an Internet or near-field communication path with intermediate entities (terminals, routers, switches, applications), which are summarised in FIG. 2 as the “Internet” cloud. By using SEs as a secure environment, a higher level-of-trust is created, i.e. a trustworthiness is increased. Simultaneously with sending 302, or immediately before or after, a timer is started in optional step 303. The eMD C invalidated in step 301 can no longer be used by the SE1 for actions (as described below). The eMD is thus blocked in the payment system due to a transmission process 105 that has already been triggered (and not yet completed). This prevents double spending after the sending step 302. Invalidating allows easy handling during the transmission process 105.

[0173] When the eMD C is properly received in the SE2, a receipt confirmation is generated by the SE2 and returned to the SE1. The receipt confirmation from the SE2 may be sent as a delete request, because only after the eMD C has been deleted in the SE1 can (may) the eMD C be validated and used in the SE2.

[0174] In step 304, the SE1 checks whether a receipt confirmation has been received from the SE2. According to FIG. 2, a receipt confirmation has been received, so in step 305, the SE1 deletes the eMD C. Deleting an eMD may be moving the eMD to a storage area of the eMD that is considered an archive and represents the history of deleted eMDs as archival storage. Alternatively, the eMD is physically deleted from the data memory. As the eMD has already been successfully sent to the SE2, the monetary amount of the eMD C has not been destroyed but—as desired—transferred (transmitted).

[0175] In step 305a, the deletion of the eMD C from the SE1 can optionally be indicated. In this process, for example, an amount display of the SE1 (or of a terminal ME1 in which the SE1 is logically located) is updated. For example, the monetary amount of the eMD C is subtracted from an amount of the SE1 available for payment transactions. In doing so, this process 300 adopts a controlling role such that the deletion process initiated at step 305 is causal to the updating of a user display, thus controlling the fate of the eMD C of any parent application that may be used.

[0176] In step 306, a deletion confirmation is sent to the SE2. This serves as an acknowledgement that the eMD C is no longer present in the SE1 and can therefore be validated in the SE2. Upon receipt of the deletion confirmation in the SE2, the SE2 will convert the status of the eMD C in the SE2 to an active status, the eMD C is thus validated and can be used for further payment transactions or actions (split, combine, switch) in the SE2 from this point on.

[0177] Optionally, the SE2 sends an activation confirmation to the SE1 in step 307. The transmission process 105 is thus completed and the eMD C has been successfully transmitted from the SE1 to the SE2.

[0178] Optionally, the eMD C of the SE2 is switched to the SE2 in the coin register (see below), whereby the eMD C is registered to the SE2 (step 104).

[0179] FIG. 3 and FIG. 4 each show further developments of the sequence of a transmission process 105 according to FIG. 2. The first steps 104, 301, 302 and 303 of FIG. 3 are identical to steps 104, 301, 302 and 303 of FIG. 2 and are therefore not explained again here. Unlike FIG. 2, the SE2 does not receive the eMD C (see end of arrow of step 302).

[0180] The SE2 does not receive the eMD C on the first sending attempt 302. This indicates a transmission error, the causes of which (as described above) can be manifold. For example, the SE1 may lose an NFC connection to its own terminal M1 C (not shown), the SE2 may lose an NFC connection to its own terminal M2 or to the other terminal M1 (not shown), a device disconnect or a transmission protocol error may occur. In all events, the SE2 will not generate a receipt confirmation.

[0181] The error is detected in the SE1, shown in FIG. 3 and FIG. 4 by checking 304, for example by exceeding a predefined time period, indicated by the timer according to step 303 or by receiving an error message from the SE2 or the terminal M1 or the other terminal M2 (not shown).

[0182] A decision is then made in step 308 as to whether the eMD C should be sent again or whether the transmission should be reversed. This decision may depend on the type of error or the number of retries (e.g. only X number of retries possible) and leads to different procedures according to FIG. 3 or FIG. 4. In FIG. 3, the decision is made to send the eMD C again. For this purpose, transmitting 105 is carried out according to steps 302 to 307 of FIG. 2, which are not retried here due to their identical character to FIG. 2. The transaction data set created for this purpose can help to retry the transaction. However, it is preferred to create a new transaction data set with each transaction attempt in order to also log the failures and to be able to reconstruct or evaluate them later. The transmission process 105 is thus successfully completed with the second attempt and the eMD C has been successfully transmitted from the SE1 to the SE2.

[0183] FIG. 4 shows an alternative procedure to FIG. 3 from checking step 308, namely in the event that the SE1 decides (or has the specification) that no retry is to be performed, but that the procedure is to be rolled back (rollback method). In the event of this, in step 309 the eMD C is reactivated by the SE1 and is again usable/available for transactions or actions in the SE1 from this point on.

[0184] The step 308 may include a checking step. For example, with each resending attempt (RETRY), a counter value can be incremented and, if a maximum permissible number of repetition attempts is exceeded, for example 10 or 5 or 3 times, it is automatically decided in step 308, independently of the error case, that no resending attempt (RETRY) is to be performed, but that the transmission 105 is to be terminated as unsuccessful and the method according to FIG. 4 is to be run.

[0185] The step 308 can alternatively or additionally be decided depending on a detected error case, so that a “fatal error” leads to a rollback of FIG. 4, but a connection error of an NFC communication leads to a repetition according to FIG. 3.

[0186] The step 308 can alternatively or additionally be decided depending on a generated error message.

[0187] The steps of FIG. 3 and FIG. 4 are preferably performed without a query at a coin register, whereby the method does not require a connection to the coin register to perform the transmission 105.

[0188] In an alternative embodiment of the method, step 301 reports the status of the eMD from the SE1 to the coin register 4. The checking step 304 establishes a connection with the coin register 4 and performs a status request to the eMD C. When the coin register 4 furthermore reports an inactive status back to the eMD C (registered to the SE1), no transaction error (manipulation attempt) is assumed and the procedure continues as described. However, when the coin register 4 returns an active status to the eMD C or a registration to another SE, a transaction error (manipulation attempt) is assumed and the payment system is alerted. The transaction data set of the SE1 is used as proof.

[0189] In further alternative embodiment of the method, step 301 reports the status of the eMD from the SE1 to the coin register 4. On the part of SE2, if a deletion confirmation is not received after the receipt confirmation is sent, a connection is established with coin register 4 and a status query is performed on the eMD C. Furthermore, when the coin register 4 reports an inactive status back to the eMD C (registered to the SE1), no transaction error (manipulation attempt) is assumed and a receipt confirmation is sent again and then the method continues as described. However, when the coin register 4 reports an active status to the eMD C or a registration back to the SE1 or another SE, a transaction error (manipulation attempt) is assumed and the payment system is alerted. A transaction data set of the SE2 is used for proof or the transaction data set of the SE1 is requested to the eMD.

[0190] FIG. 5 shows a method flow of a transmission process 105 in an SE1 according to the invention, as already described in FIGS. 2 to 4.

[0191] Optionally, an eMD is invalidated in step 301. In the subsequent step 302, the eMD is sent. In the optional step 303 a timer is started. Optionally, step 303 can be performed before step 302. In a checking step 304, it is checked whether a receipt confirmation was received.

[0192] In the yes event of step 304, the eMD in the SE1 is deleted from the SE1 in the subsequent step 305. Optionally, the deletion is indicated to the subscriber (user) in step 305a. In the subsequent step 306, the SE1 sends a deletion confirmation and receives an activation confirmation in the subsequent step 307. The yes case of step 304 represents a successful transmission 105.

[0193] In the no event of step 304, a decide step 308 (also a checking step) optionally follows to decide whether to retry sending (no event of step 308) or to terminate transmitting 105 as unsuccessful (yes event of step 308). In the yes event of step 308, the eMD is reactivated in the subsequent step 309 and is available for transactions or actions in the SE1. In the no event of step 308, the procedure is retried from step 302. This decide step 308 can also be omitted and always a reversal or always a retry can be defined.

[0194] As explained in FIG. 3 and FIG. 4, a counter value may be queried in step 308 to limit the number of retry attempts to a predefined number.

[0195] The electronic coin data set may be requested in advance from an issuing entity and optionally received by a terminal or the issuing entity or a payment system. Steps 104 and 105 may correspond to steps 104 and 105 of FIG. 10. An action (splitting, merging, switching, transmitting, redeeming, changing) on the eMD may correspond to any of the actions of FIGS. 6 to 12.

[0196] The indication in step 305a can additionally be understood as a report of the eMD to the coin register 4 in order to keep track of the transmission in the coin register.

[0197] In the eMD, a check value can still be kept as a data element. This check value is incremented each time this coin data set is transmitted directly between terminals. In the payment system, a counter value may also be maintained or determined to include the check value, for example as the sum of the previous (registered) counter value and the check value, to determine whether the coin data set is to be returned. Each action with the coin data set increases this counter value. Different action types weight the counter value differently, so that, for example, a direct passing on of the coin data set has a higher weight than a modification (splitting, combining). In this way, the life span and the actions performed in a coin data set are evaluated and criteria for its return are defined according to the actions performed. The checking value and also the counter value represent the life cycle of the coin data set, which is then used to decide on its return.

[0198] FIG. 6 shows an embodiment of a payment system with security elements SE1 and SE2 according to the invention. The SE1 and SE2 can be installed ready for operation in terminals M1 and M2 and can be logically or physically connected.

[0199] 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 is generated for the electronic coin data set C.sub.i, provided with an obfuscation amount and registered in a “masked electronic data set ledger” as a coin register 4. 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.

[0200] For example, a true random number was generated as the obfuscation amount r.sub.i for this purpose. The obfuscation amount r.sub.i is linked to a monetary amount v.sub.i. An i-th electronic coin data set according to the invention could thus read:

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

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

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

[0202] This function f (C.sub.i) is public, i.e. any system subscriber can call and use this function. This function f (C.sub.i) is defined according to equation (3):

Z.sub.i=v.sub.iH+r.sub.iG  (3)

wherein H and G are generator points of a group G in which the discrete logarithm problem is hard, with generators G and H for which the discrete logarithm of the other basis is unknown. For example, G and H are generator points of an elliptic curve encryption, ECC, —that is, private keys of ECC. These generator points G and H must be chosen in such a way that the context of G and H is not publicly known, so that if:

G=n H  (4)

the link n must be practically undetectable to prevent the monetary amount v.sub.i from being manipulated and yet a valid Z.sub.i could be calculated. Equation (3) is a “Pederson commitment for ECC”, which ensures that the monetary amount v.sub.i can be committed to a coin register 4 without revealing it to the coin register 4. The public and remote coin register 4 is therefore only sent (disclosed) the masked coin data set Z.sub.i.

[0203] Even when in the present example an encryption based on elliptic curves is described, another cryptographic method based on a discrete logarithmic method would also be conceivable.

[0204] Due to the entropy of the obfuscation amount r.sub.i, equation (3) makes it possible to obtain a cryptographically strong Z.sub.i even with a small range of values for monetary amounts v.sub.i. Thus, a simple brute force attack by merely estimating monetary amounts v.sub.i is practically impossible.

[0205] Equation (3) is a one-way function, which means that computing Z.sub.i from C.sub.i is easy because an efficient algorithm exists, whereas computing C.sub.i starting from Z.sub.i is very hard because no polynomial-time solvable algorithm exists.

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

Z.sub.i+Z.sub.j=(v.sub.iH+r.sub.iG)+(v.sub.jH+r.sub.jG)=(v.sub.i+v.sub.j)H+(r.sub.i+r.sub.j)G  (5)

[0207] Thus, addition operations and subtraction operations can be performed both in the direct transaction layer 3 and in parallel in the coin register 4 without the coin register 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 based solely on the masked coin data sets Z.sub.i and ensuring that no new monetary amount v.sub.i has been created.

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

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

where:

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

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

[0209] For the corresponding masked coin data sets:

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

[0210] Equation (9) can be used, for example, to easily check a “symmetric or asymmetric splitting” processing or a “symmetric or asymmetric splitting” processing step of a coin data set according to FIG. 8 or 11 without the coin register 4 having knowledge of C.sub.i, C.sub.j, and C.sub.k In particular, the condition of equation (9) is checked to validate split coin data sets C.sub.j and C.sub.k and invalidate coin data set C.sub.i. Such splitting of an electronic coin data set C.sub.i is shown in FIG. 8 or 11.

[0211] In the same way, electronic coin data sets can also be joined (merged), see FIG. 8 or 10 and the explanations thereto.

[0212] In addition, 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 coin register 4 that all monetary amounts v.sub.i in a processing operation are within a value range of [0, . . . , n] without informing the coin register 4 of the monetary amounts v.sub.i. These range proofs are also called “range proofs”. Ring signatures (English ring signatures) are preferably used as range proofs. For the present embodiment, both the monetary amount v 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∈{0;1}  (9a)

as well as

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

[0213] For each bit, preferably a ring signature with

C.sub.ij=a.sub.jH+b.sub.jG  (9c)

and

C.sub.ij+a.sub.jH  (9d)

is performed, wherein in one embodiment it can be provided to perform a ring signature only for certain bits.

[0214] In FIG. 6, an electronic coin data set C.sub.i is generated by the issuing entity 1 and made available to the first security element SEE

[0215] In FIG. 6, the electronic coin data set C.sub.i is calculated by the issuing entity 1 by means of equation (3) a masked electronic coin data set Z.sub.i is calculated by the issuing entity 1 and this is registered in the coin register 4 together with at least the second check value p.sub.i2. The transmission takes place wirelessly via WLAN, NFC or Bluetooth, for example. The transmission can be additionally secured by cryptographic encryption methods, for example by negotiating a session key or applying a PKI infrastructure.

[0216] In the second security element SE2, the transmitted electronic coin data set C.sub.i is received as C.sub.i*. With the receipt of the electronic coin data set C.sub.i*, the SE2 is in possession of the digital money represented by the electronic coin data set C.sub.i*. With the direct transmission, it is available to the SE2 for further action. The procedure presented in FIGS. 2 to 4 is used for transmitting 105.

[0217] Due to the higher trustworthiness when using SEs, both SE1, SE2 can trust each other and in principle no further steps are necessary to finish the transmission 105. However, SE2 does not know whether the electronic coin data set C.sub.i* is actually valid. Further steps may be provided in the procedure to further validate the transmitting, as explained below.

[0218] To check the validity of the received electronic coin data set C.sub.i*, the masked transmitted electronic coin data set Z.sub.i* is calculated in SE2 using the—public—one-way function from equation (3). The masked transmitted electronic coin data set Z.sub.i* is then transmitted to the coin register 4 and searched there. If it matches a registered and valid masked electronic coin data set, the validity of the received coin data set C.sub.i* is indicated to the SE2 and it is valid that the received electronic coin data set C.sub.i* is equal to the registered electronic coin data set C.sub.i. In one embodiment, the validity check can be used to determine that the received 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/action and/or has not been subject to further modification.

[0219] Preferably, a switch of the received electronic coin data set takes place afterwards.

[0220] It applies to the method according to the invention that the sole knowledge of a masked electronic coin data set Z.sub.i does not entitle to spend the digital money. The sole knowledge of the electronic coin data set C.sub.i entitles to pay, i.e. to perform a transaction successfully, in particular when the coin data set C.sub.i is valid, when the electronic coin data set C.sub.i has an active status. The status is—as shown above—preferably only set to an active status when the deletion confirmation of the SE1 is received. There is a one-to-one relationship between the electronic coin data sets C.sub.i and the corresponding masked electronic coin data sets Z.sub.i. The masked electronic coin data sets Z.sub.i are registered in the coin register 4, for example a public decentralised database. This registration first makes it possible to check the validity of the electronic coin data set, for example whether new monetary amounts have been created (illegally).

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

[0222] In order to prevent multiple issuance or to ensure more flexible transmission, the electronic coin data sets can now be processed in the method according to the invention. Table 1 below lists the individual operations, wherein the specified command also executes 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 security element or issuing entity Generate Command or Generate Generate Generate range step signature random number masking proof Create 1 1 1 0 or 1 Return 1 0 1 0 or 1 Split 1 1 3 0 or 1 Merge 1 0 3 1 Switch 1 1 2 1

[0223] Other operations not listed in Table 1 may be required, such as changing the currency or redeeming the monetary amount in an account. Instead of the implementation listed, other implementations are also conceivable that imply other operations. Table 1 shows that for each coin data set, each of the processing operations “Create”, “Return”, “Split”, “Merge” and “Switch” can provide different operations “Create signature”; “Create random number”; “Create masking”; “Range check”, wherein each of the processing operation is registered in the coin register 4 and appended there in invariant form to a list of previous processing operations for masked electronic coin data sets Z.sub.i. The operations of the processing operations “create” and “return” 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 the terminals M1 to M3 or their security elements SE1, SE2, SE3.

[0224] The number of operations for the individual processes is characterised with “0”, “1” or “2” in Table 1. The number “0” indicates that the security element 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 security element 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 security element or issuing entity 1 must be able to perform this operation twice for this processing of the electronic coin data set.

[0225] In principle, it can also be provided in one embodiment that a range check is also performed by the issuing entity 1 during creation and/or deletion.

[0226] Table 2 below lists the operations required for the coin register 4 for the individual processes:

TABLE-US-00002 TABLE 2 Number of operations that can be performed per processing of a coin data set in the coin register. Trace Check homomorphic Check validity of properties of Check signature of masked masked electronic Command signature of security electronic Trace range coin data sets, or step issuer element coin data set proof i.e. add or subtract Create 1 0 0 0 or 1 0 Return 1 0 1 0 or 1 0 Split 0 1 1 2 or more 1 Merge 0 1 2 or more 1 1 Switch 0 1 1 1 0

[0227] 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 coin register 4, which as a trusted entity, for example as a decentralised server, in particular a distributed trusted server, ensures sufficient integrity of the electronic coin data sets.

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

TABLE-US-00003 TABLE 3 Preferred units in the system components Command or step Issuing entity Security element Coin register Random number Yes — — generator (high security) Random number — Yes — generator (deterministic) PKI for signing Yes Yes — PKI for signature — (Yes) Yes check Read access on Yes Yes Yes DLT Write access on Yes Yes Yes DLT Return of electronic Yes Yes — coin data set Transport Yes Yes — encryption Secure memory (Yes) Yes —/Yes Masking unit Yes Yes — Range proof — Yes — Check range proof — — Yes DLT software — — Yes

[0229] Table 3 shows an overview of the preferred components to be used in each system subscriber, i.e. the issuing entity 1, a security element SE1 and the coin register 4. The security element SE1 can be used as a wallet for electronic coin data sets C.sub.i (with their verification value p.sub.i1 p.sub.i2) i.e. adapted as an electronic wallet, i.e. a data memory of the security element SE1, in which a plurality of coin data sets C.sub.i can be stored, and implemented, for example, in the form of an application on a smartphone or IT system of a trader, a commercial bank or another market participant and send or receive an electronic coin data set. Thus, the components in the security element as shown in Table 3 are implemented as software. It is assumed that the coin register 4 is based on a DLT and operated by a number of trusted market participants.

[0230] FIG. 7 shows an embodiment of a coin register 4 of the preceding figures. FIG. 7 shows an exemplary database in the form of a table in which the masked electronic coin data sets Z and, if applicable, their processing are registered. The coin register 4 is preferably assembled locally remote from the terminals M or their security elements SE and is housed, for example, in a server architecture.

[0231] Each processing operation for a processing (create, return, symmetric or asymmetric split, merge and switch) is thereby registered in the coin register 4 and appended there in unchangeable form to a list of previous processing operations for masked electronic coin data sets Z.sub.i. The individual operations and their check results, i.e. the intermediate results of a processing operation, are recorded in coin register 4.

[0232] The processes “create” and “return”, which concern the existence of the monetary amount v.sub.i per se, i.e. mean the creation and destruction of money, require an additional authorisation by the issuing entity 1 to be registered (i.e. logged) in the coin register 4. The other processing operations (splitting, merging, switching) do not require authorisation by issuing entity 1 or by the command initiator (=payer, e.g. the terminal or the security element).

[0233] A registration of the respective processing in the coin register 4 is realised, for example, by corresponding list entries in the database according to FIG. 7. Each list entry has further flags 25 to 28, which document the intermediate results of the respective processing, which must be performed by the coin register 4, and a status display 29, which the coin register 4 logs. Preferably, the flags 25 to 28 are used as an aid and are discarded by the coin register 4 after the commands have been completed. What remains are flags about the validity of the (masked) electronic coin data sets from columns 22a, 22b, 23a and/or 23b. These flags are in state “−” when a processing command is received, for example, and are set to state “1” after all checks have been successfully completed and are set to state “0” if 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 signatures of issuing entity(ies) 1 and signatures of terminals M, 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 23a/b, wherein state “1” indicates that a validity check revealed that the electronic coin data set of column 23a/b is valid and state “0” indicates that a validity check revealed that the electronic coin data set of column 23a/b is invalid and state “−” indicates that a validity check is not yet completed. Column 26 (C flag) shows whether the calculation of the masked electronic coin data set was successful, wherein state “1” indicates that a calculation was successful and state “0” indicates that calculation was unsuccessful and the state “−” indicates that a validity check is not yet completed.

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

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

[0235] Column 27 (R-flag) indicates whether a check of the range proofs or the range proof was successful, wherein state “1” indicates that a validity check showed that the range proofs or range proof could or could not be traced and state “0” indicates that a validity check showed that the range proofs or range proof could or could not be traced and state “-” indicates that a validity check has not yet been completed, was successful.

[0236] Column 28 (S flag) indicates whether a signature of the electronic coin data set matches the signature of column 24, wherein state “1” indicates that a validity check revealed that the signature could be identified as that of issuing entity 1 and state “0” indicates that a validity check revealed that the signature could not be identified as that of the issuing entity and the state “-” indicates that a validity check is not yet completed.

[0237] A change in the flags (also referred to as a “flag”) requires approval by the coin register 4 and must then be stored unalterably in the coin register 4. A processing is final when and only when the required flags 25 to 28 have been validated by the coin register 4, i.e. changed from the “0” state to the “1” state or the “1” state after the appropriate check.

[0238] In order to determine whether a masked electronic coin data set Z is valid, the coin register 4 searches for the last change that concerns the masked electronic coin data set Z. It holds that the masked electronic coin data set Z is valid when and only when the masked electronic coin data set Z is listed for its last processing in one of the successor columns 23a, 23b and that last processing has the corresponding final flag 25 to 28. It also holds that the masked electronic coin data set Z is valid when and only when the masked electronic coin data set Z 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 flags 25 to 28 is set to “0”.

[0239] It also holds that the masked electronic coin data set Z is not valid for all other events, for example, when the masked electronic coin data set Z is not found in the coin register 4 or when the last processing of the masked electronic coin data set Z is listed in one of the successor columns 23a, 23b but this last processing never became final or when the last processing of the masked electronic coin data set Z is in one of the predecessor columns 22a, 22b and this last processing is final.

[0240] The checks by the coin register 4 to see if a processing is final are represented by columns 25 to 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 according to equation (10) is correct. The state in column 27 indicates whether the range checks for the masked electronic coin data set Z could be successfully verified. The state in column 28 indicates whether the signature in column 24 of the masked electronic coin data set Z is a valid signature of issuing entity 1.

[0241] For the modification “splitting”, in the case of symmetrical splitting, it can be provided in column 24 to enter a signature generated by a terminal M1 to M3 or its SE in order to check or document the validity of a masked coin record.

[0242] The status “0” in a column 25 to 28 shows that the check was not successful. The status “1” in a column 25 to 28 shows that the check was successful. The status “-” in a column 25 to 28 shows that no check was carried out. 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.

[0243] Column 29 is provided to record a status of the coin data set when transmitted directly between two SEs. The setting of the status occurs in the SE and is reported to the coin register 2, as shown in FIGS. 2 to 4. The status can have two states, inactive “0” and active “1”, wherein an inactive coin data set is not usable for any transaction or action as it is already part of a transmission process 105.

[0244] As an example, five different processes are defined and explained in detail here. Reference is made to the corresponding list entry in FIG. 7.

[0245] For example, one processing is “create” an electronic coin data set C. Generating in the direct transaction layer 3 by the issuing entity 1 involves selecting a monetary amount v.sub.i, creating an obfuscation amount r.sub.i, as already described with equation (1). As shown in FIG. 7, no entries/flags are required in columns 22a, 22b, 23b and 25 to 27 or 29 during the “create” processing. The masked electronic coin data set Z.sub.i is registered in the successor column 23a. This registration is preferably done before transmitting it to a terminal M1 to M3 or its SE, in particular or already during generating by the issuing entity 1, wherein in both events equation (3) has to be executed for this purpose. The masked electronic coin data set Z.sub.i is signed by the 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 has actually been generated by an issuing entity 1, wherein other procedures are also possible for this. If the signature of a received Z.sub.i matches the signature in column 24, the flag in column 28 is set (from “0” to “1”). The flags in columns 25 to 27 do not require a status change and can be ignored. The range proof is not needed because the coin register 4 trusts that issuing entity 1 will 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 coin register 4. The status in column 29 is set to “active”.

[0246] A processing is for example “Return”. Returning, i.e. destroying money, causes the masked electronic coin data set Z.sub.i to become invalid after successful execution of the return command by issuing entity 1. This means that the returned (masked) electronic coin data set in coin register 4 can no longer be processed. To avoid confusion, the corresponding (non-masked) electronic coin data sets C.sub.i should be deleted in the direct transaction layer 3. When “returning”, 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 at deactivation to ensure that the signature matches the signature according to column 24 to ensure that the electronic coin data set C.sub.i has indeed been created by an issuing entity 1, wherein again other means may be used for this check. If the signed Z.sub.i sent in the return command can be confirmed as signed by issuing entity 1, flag 28 is set (from “0” to “1”). The flags according to columns 26 to 27 do not require a status change and can be ignored. The flags according to column 25 and 28 are set after the corresponding check. The status according to 29 is set to inactive.

[0247] One processing is, for example, “splitting”. Splitting, i.e. dividing an electronic coin data set Z.sub.i into a number n, for example 2, of electronic coin data subsets Z.sub.j and Z.sub.k is first carried out in the direct transaction layer 3, as still shown in FIGS. 8 and 10, wherein the monetary amounts v.sub.i and the obfuscation amount r.sub.j are generated. v.sub.k and r.sub.k are obtained from equations (7) and (8). In the coin register 4, flags 24 to 27 are set, the predecessor column 22a is described by the electronic coin data set 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 24 to 27 are made after the corresponding check by the coin register 4 and document the respective check result. The flag according to column 28 is ignored. Column 24 is used to enter a signature generated by the dividing terminal M1 to M3 or its SE. The status in column 29 is (remains) set to “active”.

[0248] For example, one processing is “merge”. The merging, i.e. the joining of two electronic coin data sets Z.sub.i and Z.sub.j into one electronic coin data set Z.sub.m is first carried out in the direct transaction layer 3, as still shown in FIG. 10, wherein the monetary amount v.sub.m and the obfuscation amount r.sub.m are calculated. In the coin register 4, the flags 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 4 and successor column 23b is described with Z.sub.m. The flags in columns 25 to 27 require status changes and the coin register 2 performs the appropriate checks. A range proof must be made to show that no new money has been generated. The flag according to column 28 is ignored. Column 24 is used to enter a signature generated by the merging terminal M1 to M3 or its SE. The status in column 29 is (remains) set to “active”.

[0249] For example, one processing is “Switching”. Switching is suggested when an electronic coin data set has been transmitted to another terminal Mx or its SEx. Switching, also called “switch”, exchanges the electronic coin data set C.sub.k received from the first terminal M1 or SE1 for a new electronic coin data set C.sub.i with the same monetary amount. The new electronic coin data set C.sub.i is generated by the second terminal M2 or SE2. This switching is another way to invalidate (make invalid) the electronic coin data set C.sub.k received from the first terminal M1 or SE1, thereby avoiding re-issuing the same electronic coin data set C.sub.k. 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 or the SE2 knows. This can also be done in the coin register 4. 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 masked received electronic coin data set Z.sub.k, but the monetary amount has remained the same, and thus equation (11):

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

holds, the second terminal M2 or the SE2 must be able to prove that Z.sub.l-Z.sub.k can be represented as a scalar multiple of G, i.e. as r.sub.add*G. This means that 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.

[0250] The “splitting” and “merging” modifications to an electronic coin data set can also be delegated from a terminal M1 or SE1 to another terminal M2, M3 or SE2, SE3 respectively, for example when a communication link to the coin register 4 is not available.

[0251] FIG. 8 shows an embodiment example of a payment system according to the invention for the actions of “splitting”, “merging” and “switching” electronic coin data sets C. In FIG. 8, the first terminal M1 or SE1 has received the coin data set C.sub.i and now wishes to perform a payment transaction not with the entire monetary amount v.sub.i, but only with a partial amount v.sub.k. For this purpose, the coin data set C.sub.i is divided. To do this, the monetary amount is first divided:

v.sub.i=v.sub.j+v.sub.k  (12).

[0252] Each of the received amounts v.sub.j, v.sub.k must be greater than 0, because negative monetary amounts are not permitted.

[0253] In a preferred embodiment, the monetary amount v.sub.i is divided symmetrically into a number n of equally sized partial monetary amounts v.sub.j.

v.sub.j=v.sub.i/n  (12a)

[0254] The number n is an integer greater than or equal to two. For example, a monetary amount of 10 units can be divided into 2 partial amounts of 5 units (n=2) or into 5 partial amounts of 2 units each (n=5) or 10 partial amounts of one unit each (n=10).

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

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

[0256] When symmetrically split, an individual unique obfuscation amount r.sub.j is formed in the terminal M1 or the SE1 for each partial coin amount, wherein the sum of the number n of obfuscation amounts r.sub.j of the coin data subsets is equal to the obfuscation amount r.sub.i of the split coin data set:

r.sub.i=Σ.sub.k=1.sup.nr.sub.j_k  (13a)

[0257] In particular, the last partial obfuscation amount r.sub.j_n is equal to the difference between the obfuscation amount r.sub.i and the sum of the remaining partial obfuscation amounts:

r.sub.j_n=r.sub.i−Σ.sub.k=1.sup.n-1r.sub.j_k  (13b)

[0258] In this way, the obfuscation amounts r.sub.j_1 to r.sub.j_n-1 can be chosen arbitrarily and the rule of equation (13a) is satisfied by calculating the “last” individual obfuscation amount r.sub.j_n accordingly.

[0259] For asymmetric splitting, 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 the coin register 4. For splitting, the predecessor column 22a is written with coin data set Z.sub.i, the successor column 23a is written with Z.sub.j and the successor column 23b is written with Z.sub.k. Additional information for the range proof (zero-knowledge-proof) is to be generated. The flags in columns 25 to 27 require status change and the coin register 4 performs the corresponding checks. The flags according to column 28 and the status according to column 29 are ignored.

[0260] In the case of symmetrical splitting, a signature is calculated in the respective terminal or SE. For this purpose, the following signature key sig is used for the k-th coin data subset

sig=r.sub.i−n r.sub.j_k  (13c)

[0261] Therein n is the number of symmetrically split coin data subsets. In the case of symmetrical splitting, the signature of the k-th coin data subset C.sub.j_k can be verified according to (13c) with the following verification key Sig:

Sig=Z.sub.i−n Z.sub.j_k  (13d).

[0262] Therein Z.sub.j_k is the masked k-th coin data subset and n is the number of symmetrically split coin data subsets. This simplification results from the relationship with equation (3):

Z.sub.i−n Z.sub.j_k=(v.sub.i−n v.sub.j_k)H+(r.sub.i−n r.sub.j_k)G  (13e)

wherein due to the symmetry properties of the division:

(v.sub.i−n v.sub.j_k)H=0  (13f)

so that equation 13e is simplified to:

Z.sub.i−n Z.sub.j_k=(r.sub.i−n r.sub.j_k)G  (13g)

[0263] The simplification due to equation 13f makes it possible to completely dispense with zero-knowledge proofs, whereby the application of symmetrical splitting saves enormous computing power and data volume.

[0264] Then, a coin data subset, in this case C.sub.k is transmitted from the first terminal M1 or SE1 to the second terminal M2 or SE2. In order to prevent double spending, a switching operation is useful to exchange the electronic coin data set C.sub.k received from the first terminal M1 or SE1 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 or SE2. The monetary amount of the coin data set C.sub.l is adopted and not changed, see equation (11).

[0265] Then, according to equation (14), a new obfuscation amount r.sub.add is added to the obfuscation amount r.sub.k of the received 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. To prove that only a new obfuscation amount r.sub.add has been added to the obfuscation amount r.sub.k of the received electronic coin data set Z.sub.k, but that the monetary amount has remained the same (v.sub.k=v.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 by means of public signature R.sub.add according to equation (15):

R.sub.add=r.sub.addG

=Z.sub.l−Z.sub.k=(v.sub.l−v.sub.k)*H+(r.sub.k+r.sub.add−r.sub.k)*G  (15)

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) to obtain the masked coin data set Z.sub.l. In the coin register 4, the private signature r.sub.add can then be used to sign, for example, the masked electronic coin data set Z.sub.l to be switched, which is considered as a proof that the second terminal M2 or SE2 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.

[0266] The proof is as follows:

Z.sub.k=v.sub.k.Math.H+r.sub.k.Math.G

Z.sub.l=v.sub.l.Math.H+r.sub.l.Math.G=v.sub.k.Math.H+(r.sub.k+r.sub.add).Math.G

Z.sub.l−Z.sub.k=(r.sub.k|r.sub.add−r.sub.k).Math.G

=r.sub.add.Math.G  (16).

[0267] FIG. 9 shows an embodiment of a payment system according to the invention for merging (also called combining) electronic coin data sets. In this case, the two coin data sets C.sub.i and C.sub.j are received in the second terminal M2 or SE2. Similar to the splitting according to FIG. 8, a new coin data set Z.sub.m 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 merged is masked and the masked coin data set Z.sub.m is registered in the coin register 4. Then, the signature of the second terminal M2 or SE2 is entered during the “merging”, as it has received the coin data set C.sub.i and C.sub.j.

[0268] When combined by the payment system 2, the highest of the two individual check values of the respective electronic coin data subsets C.sub.i and C.sub.j is determined. This highest check value is adopted as the check value C.sub.i and C.sub.j of the combined electronic coin data set.

[0269] Alternatively, when combining (=merging) by a payment system 2, a new check value is determined from the sum of all check values of the electronic coin data subsets C.sub.i and C.sub.j divided by the product of the number (here two) of coin data subsets C.sub.i and C.sub.j with a constant correction value. The correction value is constant throughout the payment system. The correction value is greater than or equal to 1. Preferably, the correction value is dependent on a maximum deviation of the individual check values of the electronic coin data subsets C.sub.i and C.sub.j or on a maximum check value of one of the electronic coin data subsets C.sub.i and C.sub.j. Further preferably, the correction value is less than or equal to 2. This new check value is adopted as the check value of the combined electronic coin data set C.sub.m.

[0270] In the following, FIGS. 10 and 11 are described together to explain the actions of “creating”, “transmitting”, “switching”, “merging” and “splitting”. In the optional steps 101 and 102, a coin data set is requested and provided by the issuing entity 1 to the first terminal M1 or SE1 after the electronic coin data set is created. A masked electronic coin data set is sent to the coin register 4. In step 103, masking of the received electronic coin data set C.sub.i is performed according to equation (3). Then, in step 104, the masked electronic coin data set Z.sub.i is registered in the coin register 4. Optionally, the terminal M1 or SE1 can switch the received electronic coin data set. In step 105, the coin data set C.sub.i is transmitted in the direct transaction layer 3 to the second terminal M2 or SE2 according to the method of FIGS. 2 to 4. In the optional steps 106 and 107, a validity check with prior masking is performed, in which, in the good case, the coin register 4 confirms the validity of the coin data set Z.sub.i or C.sub.i.

[0271] In step 108, a received coin data set C.sub.k (of course, the received coin data set C.sub.i could also be switched) is switched to a new coin data set C.sub.l, which invalidates the coin data set C.sub.k and prevents double spending. To do this, the monetary amount v.sub.k of the transmitted coin data set C.sub.k is used as the “new” monetary amount v.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 or SE2. Then the masked coin data set Z.sub.l to be switched is sent to the coin register 4 and the switching from C.sub.k to C.sub.l is instructed.

[0272] In step 108′, the corresponding check is made in coin register 4. Z.sub.k is entered in column 22a according to the table in FIG. 2 and the coin data set Z.sub.l to be switched is entered in column 23b. A check is then made in coin register 4 as to 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 returned or merged) and whether a check for the last processing has failed. In addition, Z.sub.i is entered in column 23b and the flags in columns 25, 26, 27 are initially set to “0”. Now a check is made whether Z.sub.l is valid, wherein the check according to equations (16) and (17) can be used. In a good case, the flag 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 the flag in column 26 is set accordingly. Furthermore, it is checked whether the ranges are conclusive, then the flag is set in column 27. When all checks have been successful and this has been unalterably recorded in the coin register 4, the coin data set is considered to be switched. I.e. the coin data set C.sub.k is no longer valid and from now on the coin data set C.sub.i is valid.

[0273] In step 109, two coin data sets C.sub.k and C.sub.i are merged to a new coin data set C.sub.m, whereby the coin data sets C.sub.k, C.sub.l become invalid and double spending is prevented. For this purpose, the monetary amount v.sub.m is formed from the two monetary amounts v.sub.k and v.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, by means of equation (3), the masked coin data set Z.sub.m to be connected is obtained and this is sent (together with other information) to the coin register 2 and the merging is requested as processing. In addition, a signature S.sub.k and a signature S.sub.i are generated and communicated to the coin register 2.

[0274] In step 109′ the corresponding check is made in the coin register 4. Therein Z.sub.m is entered in column 23b according to the table in FIG. 2, which is also the same as a switching. A check is then made in coin register 4 as to 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 merged) and whether a check for the last processing has failed. In addition, the flags in columns 25, 26, 27 are initially set to “0”. Now a check is made whether Z.sub.m is valid, wherein the check according to equations (16) and (17) can be used. In the good case, the flag 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 flag in column 26 is set. Furthermore, it is checked whether the ranges are conclusive, then the flag is set in column 27.

[0275] In step 110, a coin data set C.sub.i is split asymmetrically into two coin data subsets C.sub.k and C.sub.j, whereby the coin data set C.sub.i is invalidated and the two asymmetrically split coin data subsets C.sub.k and C.sub.j are to be validated. In an asymmetric split, the monetary amount v.sub.i is split into partial monetary amounts v.sub.k and v.sub.j of different sizes. For this purpose, the obfuscation amount r.sub.i, is divided into the two obfuscation amounts r.sub.k and r.sub.j. In addition, by means of equation (3), the masked coin data subsets Z.sub.k and Z.sub.j are obtained and sent to the coin register 4 with further information, for example the range checks (zero-knowledge-proofs), and the splitting is requested as processing.

[0276] In step 110′, the corresponding check is carried out in coin register 4. 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 coin register 4 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 merged) and whether a check for the last processing has failed. In addition, the flags in columns 25, 26, 27 are initially set to “0”. Now a check is made whether Z.sub.j and Z.sub.k are valid, wherein the check according to equations (16) and (17) can be used. In a good case, the flag 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 flag in column 26 is set. Furthermore, it is checked whether the ranges are conclusive, then the flag is set in column 27.

[0277] FIG. 12 is an embodiment of a device M1 according to the invention in which the SE1 is inserted. 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 memory 10′, the electronic coin data sets C.sub.i could be stored in an online memory, for example a data memory 10′ of a digital wallet provider. Additionally, private data memory, for example a network attached storage, NAS in a private network could also be used.

[0278] In one event, 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 of characters (ASCII).

[0279] 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 out 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-enabled 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 so that the coin data set C.sub.i is transmitted between devices via an application, such as an instant messenger service, or as a file or string.

[0280] Furthermore, the interface 12 or another interface (not shown) of the device M1 is arranged to interact with the coin register 4. The device M1 is preferably online capable for this purpose.

[0281] Furthermore, the device M1 may also have an interface for the receipt of electronic coin data sets. This interface is arranged to receive visually presented coin data sets, for example by means of a capture 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.

[0282] The device M1 also comprises a computing unit 13 capable of performing the coin data set masking method and coin data set processing described above.

[0283] The device M1 is online capable and can preferably detect when it is connected to a network, such as WLAN, by means of a location detection module 15. Optionally, a specific network can be flagged as preferred (=location zone) so that the device M1 only performs special functions when it is logged into this 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 either manually into the device M1 or via other units/modules into the device M1. The special functions that the device M1 performs when the location zone is detected are, in particular, the transmitting of electronic coin data sets from/to the external data memory 10 from/to a vault module 14 and, if applicable, the transmitting of masked coin data sets Z to the coin register 4, for example as part of the above-mentioned processing on a coin data set.

[0284] In the simplest case, all coin data sets C.sub.i are automatically connected to a coin data set in the terminal M1 after receipt (see merging-processing or connect-step). That is, as soon as a new electronic coin data set is received, a connect or switch command is sent to the coin register 4. The device M1 can also prepare electronic coin data sets in algorithmically defined denominations and store them in the data memory 10, 10′ so that a payment process is possible even without a data connection to the coin register 4.

[0285] FIG. 13 shows an overall system for better understanding. The overall system according to the invention comprises an issuing entity (central bank) 1a. In addition, further issuing entities 1b, 1c may be provided, for example issuing electronic coin data sets in another currency. In addition, at least one payment system 2 is shown in which at least one coin register 4 is provided as the central manager of the payment system. Moreover, a plurality of subscribers represented as terminals Mx (with respective SEx) is provided. The payment system 2 comprises, for example, commercial banks and one (or more) central coin register 4, which performs the registration of the coin data sets C.sub.i and checks and logs the modifications to the coin data set C.sub.i.

[0286] The terminals M1 to M6 can directly exchange coin data sets C.sub.i in the direct transaction layer 3. For example, terminal M5 transmits a coin data set to terminal M4. For example, terminal M4 transmits the coin data set to terminal M3. For example, terminal M6 transmits a coin data set to terminal M1. In each sending terminal Mx or each receiving terminal Mx, the check value of the coin data set to be sent or received is used to check whether the coin data set is indicated to the payment system and/or whether the coin data set is to be returned to the issuing entity 1a, see FIGS. 2 to 4. For example, the payment system 2 uses the check value or a counter value derived from the check value for each coin data set to check whether the coin data set is to be returned or not, see FIG. 5 for further details.

[0287] In FIG. 13, a coin data set is transmitted from the terminal M1 to the terminal M2 via the payment system 2 (indirect passing on), as described in FIGS. 2 to 4 (step 105).

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