ISSUING ENTITY AND METHOD FOR ISSUING ELECTRONIC COIN DATA SETS, AND PAYMENT SYSTEM

Abstract

An issuing entity for issuing electronic coin data sets in a payment system, includes a coin generating unit, which is designed to generate an electronic coin data set, and a coin output unit, which is designed to obtain the electronic coin data set generated by the coin generating unit and output the electronic coin data set to a participating unit or to a bank entity of the payment system in electronic form. The issuing entity is designed such that the electronic coin data set is transmitted between the coin generating unit and the coin output unit via an air gap process. An issuing method and a payment system adopt features of the issuing entity.

Claims

1.-33. (canceled)

34. An issuing entity for issuing electronic coin data sets in a payment system, with: a coin generating unit configured for generating an electronic coin data set; and a coin output unit configured for obtaining the electronic coin data set generated by the coin generating unit and for outputting the electronic coin data set to a participating unit or a bank entity of the payment system in electronic form, wherein the issuing entity is configured such that the transmitting of the electronic coin data set between the coin generating unit and the coin output unit occurs via an air gap process.

35. The issuing entity according to claim 34, wherein the air gap process between the coin generating unit and the coin output unit is configured to physically separate the coin generating unit from the coin output unit.

36. The issuing entity according to claim 34, wherein the air gap process comprises a physical transmitting of the electronic coin data set between the coin generating unit and the coin output unit, in particular by means of a portable data carrier, and/or a transmitting by means of a secured transport container.

37. The issuing entity according to claim 34, wherein the transmitting occurs by means of a portable electronic data storage.

38. The issuing entity according to claim 34, wherein for transmitting by air gap process: the coin generating unit is further configured for generating a printout representing the electronic coin data set; and the coin output unit is further configured for obtaining the electronic coin data set generated by the coin generating unit by reading the printout.

39. The issuing entity according to claim 38, wherein the printout has at least one of the following elements: an alphanumeric character string; an opto-electronically readable code, in particular a two-dimensional code; a laser engraving.

40. The issuing entity according to claim 38, wherein the printout occurs on paper substrate or plastic substrate in banknote format.

41. The issuing entity according to claim 38, wherein the printout occurs on paper in DIN A4 format.

42. The issuing entity according to claim 38, wherein multiple coin data sets are arranged on a printout.

43. The issuing entity according to claim 34, wherein the coin output unit has a banknote processing machine.

44. The issuing entity according to claim 34, wherein the coin output unit has a reader for opto-electronically reading the printout.

45. The issuing entity according to claim 34, wherein the coin output unit has a reader for opto-electronically reading a generation request.

46. The issuing entity according to claim 38, wherein the coin output unit has: a checking device for checking the printout, and/or a printout destruction unit for destroying printouts.

47. The issuing entity according to claim 34, wherein the coin generating unit is further configured for generating a signature for the electronic coin data set by signing the electronic coin data set with a private cryptographic key part of the issuing entity, wherein the generated electronic coin data set comprises the signature.

48. The issuing entity according to claim 34, wherein the coin generating unit is further configured for generating issuer security data, and the coin output unit also obtains the generated issuer security data from the coin generating unit via the air gap process.

49. The issuing entity according to claim 34, wherein the coin generating unit is configured for generating a register data set which is intended for storage in a coin register of the payment system, and wherein p the coin output unit also obtains the generated register data set from the coin generating unit via the air gap process.

50. The issuing entity according to claim 49, wherein the coin output unit is configured for registering the electronic coin data set in the coin register by outputting the register data set and the issuer security data to the coin register, wherein either the register data set comprises the issuer security data for storing in the coin register or the issuer security data is outputted in addition to the register data set to be stored.

51. The issuing entity according to claim 48, wherein the register data set has one or more of the following data elements: a masked electronic coin data set, in particular generated by applying a homomorphic one-way function to the electronic coin data set; a signature as issuer security data, in particular as signature of the electronic coin data set, the register data set, and/or a masked electronic coin data set; a range proof of the electronic coin data set; a check value regarding the electronic coin data set; and/or a monetary amount of the electronic coin data set.

52. The issuing entity according to claim 48, wherein the coin generating unit is configured for signing the register data set, in particular of at least one masked electronic coin data set, with a private cryptographic key part of the issuing entity; and/or the coin output entity both authenticates itself to a coin register and outputs the issuer security data to the coin register, in particular as a signature of the register data set and/or of a masked electronic coin data set.

53. The issuing entity according to claim 34, wherein each electronic coin data set has at least a monetary amount as a data element and an obfuscation amount as a data element, wherein the obfuscation amount is secret for a coin register; and further has a check value as a data element which has a value of zero upon generating the electronic coin data set.

Description

BRIEF SUMMARY OF FIGURES

[0169] 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 example embodiments of the invention. Same 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.

[0170] It is shown:

[0171] FIG. 1 an example embodiment of a payment system with an issuing entity according to the invention;

[0172] FIG. 2 a further development of the example embodiment of a payment system of FIG. 1;

[0173] FIG. 3 a further development of the example embodiment of a payment system of FIG. 1;

[0174] FIG. 4 a further development of the example embodiment of a payment system of FIG. 1;

[0175] FIG. 5 an example embodiment of a issuing entity according to the invention;

[0176] FIG. 6 an example embodiment of a method flow diagram of a method according to the invention in an issuing entity;

[0177] FIG. 7 an example embodiment of a data structure in the coin register;

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

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

[0180] FIG. 10 two example embodiments of a method flow diagram of a method according to the invention and corresponding processing steps of a coin data set;

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

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

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

FIGURE DESCRIPTION

[0184] FIG. 1 shows an example embodiment of a payment system BZ according to the invention. The dashed blocks and arrows of the payment system BZ are optional here. The payment system BZ comprises at least two security elements SE1 and SE2. The SE1 and SE2 can be operationally integrated in the respective terminals M1 and M2 and logically or physically connected to the respective terminal M1 and M2.

[0185] Furthermore, the payment system in FIG. 1 contains a issuing entity 1 which generates the electronic coin data set C. A register data set, RDS, e.g. a masked electronic coin data set Z, is generated for the electronic coin data set C and is registered 104 in the coin register 2 of the payment system. The electronic coin data set C is output by the issuing entity 1 to the first terminal M1 in step 102. The register data set RDS, for example the masked electronic coin data set Z, is output to the coin register 2 in step 104, for example by the issuing entity 1 directly or via the first terminal M1. The register data set RDS, for example the masked electronic coin data set Z, is alternatively generated by the first terminal M1 (or the second terminal M2) and sent to the coin register 2 in step 104.

[0186] To generate an electronic coin data set, eMDS, C the following method is proposed. A request 210 from a central bank or a participating unit TE or a commercial bank for generating an electronic coin data set is obtained by the issuing entity 1. The issuing entity 1 has a coin generating unit 11 and a coin output unit 12. Both units 11, 12 are separated from each other and have an air gap 13. The air gap 13 serves to ensure that the highly sensitive security-relevant data of the payment system BZ present in the issuing entity 1, in particular one or more private keys PK and a random number generator, cannot be read out via a network attack on the issuing entity 1 and used for manipulations of the payment system BZ. In this regard, the coin generating unit 11 should be completely isolated. For example, the coin generating unit 11 is designed without an interface to a network, such as TCP/IP, the Internet, the mobile network, etc., and without an interface to other terminals, such as NFC or Bluetooth. The air gap process 13 is explained in detail in FIG. 5.

[0187] The electronic coin data set C to be generated is requested at the issuing entity 1 in step 210. The request 210 may have been generated by a central bank. As an alternative, the participating unit TE requests the electronic coin data set C. Steps 104 and 105 may correspond to steps 104 and 105 of FIG. 11. An action (splitting, merging, switching, transmitting, redeeming, exchanging) on the eMD C may correspond to any of the actions of FIGS. 8 to 12.

[0188] In the coin generating unit 1, for example, a true random number is generated as the obfuscation amount r.sub.i by means of a random number generator. The obfuscation amount r.sub.i is known in the direct transaction layer 3 and also in the issuing entity 1, but it is secret for the remaining entities of the payment system BZ, thus also for the coin register 2. The obfuscation amount r.sub.i is being linked to a monetary amount v.sub.i. Accordingly, an i-th electronic coin data set generated by the coin generating unit 1 according to the invention could read:

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

[0189] In addition to these data elements, the electronic coin data set C can comprise at least one check value p. For example, the check value p represents the return condition mentioned above.

[0190] In addition to these data elements, the electronic coin data set C may comprise a coin identifier. For example, the coin identifier is a unambiguous number that only exists once in the payment system BZ. For example, the coin identifier M-ID is a random number generated by the issuing entity 1 or a serial number. A valid electronic coin data set C can be employed for payment. The owner of the two values v.sub.i and r.sub.i is therefore in possession of the digital money. The digital money is defined by a pair consisting of a valid electronic coin data set C.sub.i and a corresponding register data set RDS.sub.i, for example a masked electronic coin data set Z.sub.i. For example, a masked electronic coin data set Z.sub.i as RDS, is obtained by applying a homomorphic one-way function f (C.sub.i) according to equation (2):

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

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

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

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

G=n.Math.H  (4)

the linking 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 conceded, i.e. “committed”, to a coin register 2 without revealing it to the coin register 2.

[0192] Alternatively, the RDS may comprise an amount category in addition to the masked coin data set Z.sub.i. The amount category is a pseudonymized form of the monetary amount v.sub.i of the electronic coin data set C. For example, the amount category is a range (from to) in which the monetary amount v.sub.i lies. For example, the amount category is a range threshold value (greater than; smaller than) above or below which the monetary amount v.sub.i lies. For example, the amount category is a rounded-down value of the monetary amount v.sub.i. For example, the amount category is a rounded-up value of the monetary amount v.sub.i. This makes the RDS amount-pseudonymous and identity-anonymous.

[0193] Alternatively, the RDS may comprise a coin identifier M-ID in addition to or instead of the masked coin data set Z.sub.i. Thus, in the RDS, a unambiguous reference to the electronic coin data set C is created.

[0194] Alternatively, the RDS may comprise a pseudonym P of the participating unit. The pseudonym can be managed in the pseudonym association 7. This makes the RDS amount anonymous and identity-pseudonymous. In this embodiment, the RDS may comprise a check value p of the coin data set as well.

[0195] In the following, for simplicity, an RDS may be equated with a masked coin data set Z, as this is a very preferred embodiment.

[0196] The RDS, for example the masked coin data set Z.sub.i, is sent (revealed) to the coin register 2, which is depicted in FIG. 1 as step 104 (registering, registration request).

[0197] The RDS can here be provided by the issuing entity 1 for the coin register 2. The RDS is preferably generated in the coin generating unit 11, but can also be generated in the coin output unit 12.

[0198] Even though 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.

[0199] Equation (3) allows, through the entropy of the obfuscation amount r.sub.i, to obtain a cryptographically strong Z.sub.i even with a smaller 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.

[0200] Equation (3) is a one-way function, which means 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 difficult because no algorithm exists that can be solved in polynomial time.

[0201] Moreover, equation (3) is homomorphic for addition and subtraction, which means:

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

[0202] Thus, addition operations and subtraction operations can be performed both in the direct transaction layer 3 and in parallel in the coin register 2 without the coin register 2 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 on the basis of the electronic coin data set Z.sub.i alone and ensuring that no new monetary amount v.sub.j has been created. This homomorphic property allows the coin data set C.sub.i to be split into, according to equation (1):

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

wherein:

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

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

[0203] For the corresponding masked coin data sets holds:

Z.sub.l=Z.sub.j|Z.sub.k  (9)

For example, equation (9) can be used to easily check a “symmetrically or asymmetrically splitting” processing or a “symmetrically or asymmetrically splitting” processing step 110 of a coin data set according to FIG. 8 or 12 without the coin register 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 as valid and declare coin data set C.sub.i as invalid. Such a splitting 110 of an electronic coin data set C.sub.i is shown in FIG. 8 or 12.

[0204] In the same way, electronic coin data sets C can also be joined (merged) 109 together, see FIG. 9 or 11 and the explanations thereto.

[0205] In addition, it is necessary 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 2 and/or a monitoring register 6 that all monetary amounts v.sub.i in a processing operation lie within a value range of [0, . . . , n] without informing the coin register 2 of the monetary amounts v.sub.i. These range proofs are also called “range-proofs”. Preferably, ring signatures are used as range proofs. For the present example, both the monetary amount v and the obfuscation amount r of an electronic coin data set C are resolved in bit representation. It holds:

v.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)

For each bit, a ring signature is preferably performed 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)

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

[0206] The embodiment of the payment system BZ shown in FIG. 1 shows in particular the generation of an electronic coin data set C for direct issuing to a participating unit TE1 (step 102). Alternatively, the issuing to the participating unit TE1 occurs indirectly via a bank entity 4 by the steps 102′ (providing the eMDS C to the bank 4) and in the subsequent step 102″ (providing the eMDS C to the TE1).

[0207] Generating the RDS by the issuing entity 1 is initially only optional here and can also be performed by the participating units TE1, TE2.

[0208] FIG. 2 shows a further development of the payment system BZ shown in FIG. 1. The explanations in FIG. 1 are referred to here in order to avoid repetitions. FIG. 2 describes the deactivating of a coin data set C. A participating unit TE1 decides to deactivate and return the coin data set C and sends a deactivating request in step 111. This step 111 may be the manifestation of a participant request, namely to credit a monetary amount of a coin data set to a participant's account, or may be based on the evaluation of a check value p.sub.i, which has determined that the coin data set meets the criteria for return, for example, expiration of a validity period, reaching a return time, reaching an “age” (number of transmissions and modifications), or reaching a threshold value when the coin data set C is not used. Step 111 is displayed directly to the coin output unit 12. The notificating may also be indirect via the bank entity 4 (similar to obtaining the coin data set), which is depicted in FIG. 2 by steps 111′ and 111″. Following step 111, the crediting of the monetary amount to an account of the participant or by outputting cash at a dispensing tray of the unit 12 is initiated in the subsequent step (not depicted). In the depicted subsequent step 212, a disabling command is sent to the coin register 2 to clear the register data set RDS from the coin register 2 or to invalidate it therein. As a result, the RDS of the deactivated (credited) coin data set is deleted from coin register 2 (crossed-out RDS).

[0209] FIG. 3 shows a further development of the payment system BZ shown in FIG. 1. The explanations in FIG. 1 are referred to here in order to avoid repetitions. The coin output unit 12 of the issuing entity 1 of FIG. 3 has a receiving unit 150 at which coin generating requests arrive from a participating unit TE or a central bank (not depicted). The receiving unit 150 transmits this request 210 to the coin generating unit 11 by means of an air gap process 14. Thereby, the same mechanisms regarding the air gap process 13 as mentioned above and discussed in more detail in FIG. 5 may be applied and the same interfaces may be used. The coin generating unit 11 generates the coin data set C and also the register data set RDS.

[0210] To mark the register data set RDS as trustworthy, the coin generating unit 11 signs the generated register data set RDS with a private key PK of the issuing entity 1. The combination of electronic coin data set C, register data set RDS and signed register data set [RDS]Sig(PK) is represented by a printout A.sub.i, for example as a QR code. This printout A1 is provided to the coin output unit 12 via the air gap process 13. There, the printout A1 is read by means of a reading unit 160, for example a QR code scanner, to obtain the electronic coin data set C. Furthermore, the coin generating unit 11 creates metadata MC which are appended to the printout A1 or provided as a stand-alone transmission to the coin output unit 13.

[0211] The unit 160 checks the uniqueness of the coin data set C.sub.i by, for example, matching the metadata MC.sub.i with metadata of the coin data sets C existing in the payment system BZ. For example, a serial number or a coin identifier is employed for this check. If the uniqueness of the coin data set C.sub.i is confirmed, it is stored in the coin storage 170 of the issuing entity 1 and output (uncorrelated in time) to a participating unit TE in step 102. Providing the RDS to the coin register 2 can already occur after checking for uniqueness or can only occur when a coin data set C.sub.i is requested by a TE or the bank entity 4.

[0212] Providing the RDS to the coin register 2 in step 102 enables registering the coin data set C.sub.i in the payment system BZ. In one embodiment, the RDS and the signed [RDS]Sig(PK) are provided for this purpose. By means of the public key of the issuing entity 1, the signature of the signed [RDS]Sig(PK) may be checked in the coin register 2 and if the check is successful, the RDS is registered as valid in the coin register 2. In another embodiment, the coin register 2 only receives the signed register data set [RDS]Sig(PK). As soon as a participating unit TE provides the register data set RDS directly to the coin register 2 (thus only after the coin data set C has been issued to the TE1 in step 102), the signature can be checked in the coin register 2 with the public key of the issuing entity 1 and, if the check is successful, the RDS is registered as valid in the coin register 2.

[0213] According to FIG. 4—a further development of the payment system BZ of FIG. 1 or 3, at least one check value p, (also called counter value) can additionally be kept in the electronic coin data set C as a further data element. In the payment system BZ, this counter value pi can be kept to determine whether the coin data set C is to be returned. Each action with coin data set C increases this counter value pi. Different action types weight the counter value pi differently, so that, for example, a direct transfer of the coin data set C has a higher weight than a modification (splitting, combining, switching). In this way, the lifetime and the actions maintained in it of a coin data set C are evaluated and criteria for its return are defined according to the actions maintained. The check value pi1 and also the counter value p.sub.i map the life cycle of the coin data set C on the basis of which a decision is then made about its return.

[0214] In FIG. 4, an RDS.sub.i, for example a masked electronic coin data set Z.sub.i, for example in SE1, is calculated from the electronic coin data set C.sub.i by equation (3) and this RDS.sub.i is registered in the coin register 2 together with the check value p.sub.i.

[0215] In FIG. 5, an example embodiment of a issuing entity 1 of FIGS. 1 to 4 is depicted. The explanations in these figures are omitted to avoid repetition. The receiving unit 150 of the coin output unit 12 provides the request 210 of the coin generating unit 11 via the air gap process 14. An opto-electronic interface may be used for this purpose. The reading unit 120 of the coin generating unit 11 causes the coin generator 140 to generate the electronic coin data set and, optionally, the RDS and the signed RDS. The output unit 130 of the coin generating unit 11 creates a printout representing the coin data set C.

[0216] The coin generating unit 11 preferably does not have a network interface or direct data transmission connection to another terminal or an exchange (router, switch, hub) to ensure that the random number generator RND comprised in the coin generator 140 and the private key PK.sub.l of the issuing entity 1 used for signing cannot be compromised by network attack.

[0217] The printout A.sub.i has, for example, an alphanumeric character string. The printout alternatively or additionally has at least one opto-electronically readable code, for example a two-dimensional code such as a QR code or a one-dimensional code such as a barcode. The printout alternatively or additionally has at least one laser engraving, watermark and/or embossing. These techniques used in the value documents production increase the security of the air-gap-based transmission of the electronic coin data sets.

[0218] For example, the printout A is printed on a paper substrate, preferably on a security element-free substrate, for example white plain paper, in banknote format. Thus, the coin generating unit 11 can be part of a classic cash production machine, for example a banknote production machine. Alternatively, the printout A occurs on paper in DIN A4 format. Then a conventional printer can be used in the coin generating unit 11.

[0219] For example, multiple different electronic coin data sets are arranged on a printout, for example on an A4 page. Thus, in a practical way, multiple coin data sets C can be transmitted simultaneously via the air gap process 13 so that the transmission is much more efficient.

[0220] The coin output unit 11 here is a banknote processing machine. This allows the use of readers provided with banknote processing machines, such as scanners, 160 for reading the printouts A. A data check in the unit 160 recognizes duplicate coin data sets C in the payment system BZ and immediately carries out a destruction of the printout (shredding or sorting-out). A destruction unit 180 is provided in the coin output unit 12 for this purpose.

[0221] This printout destruction unit 180 for destroying invalid printouts A may destroy invalid printouts A, such as for example unreadable printouts or detected duplicate electronic coin data sets (represented by the printouts). Thus, no unchecked electronic coin data set C leaves the coin output unit 12. A check may be performed, for example, on the basis of metadata MC or register data of a database of the payment system BZ to which the coin output unit 12 has access. For example, serial numbers, a coin identifier, or similar data elements may be checked for double presence in the payment system BZ. A destruction unit 150 is, for example, a mechanical fragmentation device (shredder) that physically fragments the printouts and destroys them as a result. Alternatively, the destruction unit 150 is a sorting-out compartment in which the invalid printouts are deposited. Such destruction units 150 could be destruction units of banknote processing machines.

[0222] According to FIGS. 1, 3 and 4, the transmitted electronic coin data set C.sub.i is obtained as C.sub.i* in TE2. With obtaining the electronic coin data set C.sub.i*, the TE2 is in possession of the digital money represented by the electronic coin data set C.sub.i*. With the direct transmission 105, it is available to the TE2 for further actions.

[0223] Due to the higher trustworthiness when using SEs, SE1, SE2 can trust each other and in principle no further steps are necessary for transmitting 105. However, SE2 does not know whether the electronic coin data set C.sub.i* is actually valid. To further secure the transmitting 105, further steps can be provided in the method, as explained below

[0224] For checking the validity of the obtained electronic coin data set C.sub.i*, a further RDS, for example the masked transmitted electronic coin data set Z.sub.i*, can be calculated in SE2 using the—public—one-way function from equation (3). The RDS, thus for example the masked transmitted electronic coin data set Z.sub.i*, is then transmitted to the coin register 2 in step 104 and searched for there. If both RDSs match with respect to the same coin data set C, for example a match with a registered and valid masked electronic coin data set Z.sub.i, the validity of the obtained coin data set C.sub.i* is displayed to the SE2 and it holds that the obtained 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 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/action and/or has not been subject to a further modification.

[0225] Preferably, a switching of the received electronic coin data set occurs afterwards.

[0226] The sole knowledge of an RDS, thus for example of a masked electronic coin data set Z.sub.i, does not authorise to spend the digital money of the corresponding electronic coin data set C.sub.i.

[0227] 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, for example when the electronic coin data set C.sub.i has an active status. The status is preferably set to an active status only upon obtaining the acknowledgement of deletion from the SE1. There is a bijective 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 2, for example a public database. This registering 104 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).

[0228] The masked electronic coin data sets Z.sub.i are stored in the coin register 2. All processing on the electronic coin data set Z.sub.i is registered there, whereas the actual transmission of the digital money occurs in a (secret, i.e. not known to the public) direct transaction layer 3 of the payment system BZ. Furthermore, in this payment system BZ, monitoring the coin data set C and the participating unit TE can be accommodated in a monitoring register 6.

[0229] In order to prevent multiple spending or to ensure more flexible transmitting 105, the electronic coin data sets C can be modified. The following table 1 lists exemplary operations, whereby a corresponding processing step is also executed with the specified command:

TABLE-US-00001 TABLE 1 Number of operations that can be performed per processing of a C in the TE or the issuing entity Command Create Create random Create Create range or step signature number masking proof Generating 1 1 1 0 or 1 Returning 1 0 1 0 or 1 Splitting 1 1 3 0 or 1 Merging 1 0 3 1 Splitting 1 1 2 1

[0230] Further operations not listed in table 1 may be required, for example changing the currency or redeeming the monetary amount on an account. 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 processings (modifications) “generating”, “returning”, “splitting”, “merging” and “switching” can provide different operations “create signature”; “create random number”; “create masking”; “range check”, each of the processing operations being registered in the coin register 2 and appended there in an invariable form to a list of previous processing operations for masked electronic coin data sets Z.sub.i. The operations of the processings “generating” and “returning” an electronic coin data set C are executed only in secure locations and/or only by selected entities, for example the issuing entity 1, while the operations of all other processing operations can be executed on the participating units TE, i.e. the terminals M or their security elements SE.

[0231] The number of operations for each processing is marked “0”, “1”, or “2” in table 1. The number “0” here indicates that the participating unit TE or the issuing entity 1 does not need to perform this operation for this processing of the electronic coin data set C. The number “1” here indicates that the participating unit TE or the issuing entity 1 must be able to perform this operation once for this processing of the electronic coin data set C. The number “2” here indicates that the TE or the issuing entity 1 must be able to perform this operation twice for this processing of the electronic coin data set.

[0232] In addition, in one embodiment, it can also be provided that a range check is performed by the issuing entity 1 during generating and/or deleting.

[0233] Table 2 below lists the operations required for the coin register 2 and/or the monitoring register 6 for the individual processings:

TABLE-US-00002 TABLE 2 Number of operations that can be performed per processing of a C in the coin register Retrace homomorphic Check Check validity properties of the Check signature of masked masked electronic Command signature of security electronic Retrace coin data sets, i.e. or step of issuer element coin data set range proof adding or subtracting Generating 1 0 0 0 or 1 0 Returning 1 0 1 0 or 1 0 Splitting 0 1 1 2 or more 1 Merging 0 1 2 or more 1 1 Switching 0 1 1 1 0

[0234] Further 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 2, which as a trusted entity, for example as a server entity, for example as a distributed trusted server, ensures sufficient integrity of the electronic coin data sets C.

[0235] 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 the system components Issuing Participating Coin Command or step entity unit register Random number generator Yes — — (high security) Randomised generator — Yes —/—/Yes (deterministic) PKI for signing Yes Yes —/—/Yes PKI for signature check — (Yes) Yes Read access Yes Yes Yes Write access Yes Yes Yes Returning the electronic Yes Yes — coin data set Transport encryption Yes Yes —/—/Yes Secure storage (Yes) Yes —/—/Yes Masking unit Yes Yes — Range proof — Yes — Check range proof — — Yes/Yes/—

[0236] Table 3 shows an overview of the preferred components to be used in each system participant, thus the issuing entity 1, a participant unit TE, and the coin register 2.

[0237] The participating units TE can be arranged by means of an e-wallet for electronic coin data sets C.sub.i (with the check value p, p.sub.i1 p.sub.i2), i.e. as an electronic purse with a memory area in which a plurality of coin data sets C.sub.i can be stored, and thus 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. Thus, the components in the participating unit TE, as shown in Table 3, are implemented as software. It is assumed that the coin register 2, the transaction register 4, and/or the monitoring register 6 are based on a server or on a DLT and are operated by a number of trusted market participants.

[0238] In the coin register 2, an RDS regarding the electronic coin data set C can be replaced by an RDS to be registered regarding the electronic coin data set C or of a modified electronic coin data set C. Thus, (only) current coin data sets C—existing in the payment system BZ—are maintained as RDS in coin register 2.

[0239] FIG. 6 shows a method flow diagram of a method 200 for generating and issuing an electronic coin data set C in an issuing entity 1. In the optional step 101, a coin request is received in the issuing entity 1, for example the receiving unit 150. The request 101 may have been made by a central bank or also by a participating unit TE or a commercial bank 4 of the payment system BZ. In optional step 201, this request is sent to the coin generating unit 11 of the issuing entity 1 by means of an air gap process 14. In step 202, an electronic coin data set is generated (for example, in the coin generator 140). In addition, an RDS and a signed RDS may be generated in optional steps 203 and 204. In optional step 205, metadata is generated. In step 206, the electronic coin data set C is sent to the coin output unit of the issuing entity 1 by means of an air gap process 13, optionally with the RDS and the signed RDS. Preferably, a printout A is generated for this purpose. The printout A is transported to the coin output unit 12. Alternatively, a secured transport box (container with optical, mechanical or digital seal or mechanical or digital lock) is used to transmit the printout (or printouts). The printout is brought to a reading region of the coin output unit 12 to be read. Preferably, a banknote production infrastructure is used. In the optional step 207, the RDS may be generated, should it not have already been generated and transmitted along in step 203. Not shown is an intermediate storing of the coin data set C in the coin storage 170 of the issuing entity 1. In step 209, the generated electronic coin data set C is output to a requesting (step 101) participating unit TE or a bank entity 4. In optional step 104, the coin data set C is registered in the coin register 2, for example by transmission of the RDS and/or the signed RDS. FIG. 7 shows a data structure for a coin register 2 of the preceding figures.

[0240] FIG. 7 depicts data of the coin register 2 for illustrative purposes, here the masked electronic coin data sets Z.sub.i and their processing, if any, are registered. The coin register 2 may be accommodated in a server entity. The register 2 is preferably arranged locally remote from the participating units TE and accommodated for example in a server architecture.

[0241] Each processing operation for a processing (creating, deactivating, splitting, merging, and switching) here is registered in the coin register 2 and appended to a list of previous processing operations for masked electronic coin data sets Z.sub.i, for example, in an unchangeable form. The individual operations or their check results, thus the intermediate results of a processing, are kept in the coin register 2. Although a continuous list is assumed in the following, this data structure can also be cleaned or compressed, if necessary according to predetermined rules, or provided separately in a cleaned or compressed form.

[0242] The processings “generating” and “deactivating”, which regard the existence of the monetary amount v.sub.i per se, i.e. the creation and destruction of money, require additional authorisation by the issuing entity 1 in order to be registered (thus logged) in the coin register 2. The other processing operations (splitting, merging, switching) do not require authorisation by the issuing entity 1 or by the command initiator (=payer, e.g. the first terminal M1). However, the other processing operations are to be checked with regard to various check criteria.

[0243] A registration of the respective processing is realised, for example, by corresponding list entries in the database according to FIG. 7. These list entries are the RDS. Each list entry has further markings 25 to 28 which document the intermediate results of the respective processing which must be performed by the coin register 2. Preferably, the markings 25 to 28 are used as an aid and are discarded by the coin register 2 after the commands have been completed.

[0244] A coin data set can be treated as valid when the necessary checks have occurred. For example, an optional marking 29 can indicate the completion of the processing. Markings 29 are in the “-” state when a processing command is received, for example, and are set to the “1” state after all checks have been successfully completed (to markings 25-28) and are set to the “0” state if at least one check has failed. A (completion) marking 29 with the value “2” could, for example, indicate that only the necessary checks were completed and that checks that could be made up for were omitted.

[0245] 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/entities 1 and signatures of terminals M, and six marking columns 25, 26, 27a, 27b and 27c, and 28. Each of the entries in columns 25 to 28 has three alternative states “-”, “1”, or “O”.

[0246] Column 25 (O-flag) indicates whether a validity check regarding a predecessor electronic coin data set in column 22a/b was successful. The “1” state indicates that a validity check revealed that the electronic coin data set of column 22a/b is valid and the “0” state indicates that a validity check revealed that the electronic coin data set of column 22a/b is invalid and the “-” state indicates that a validity check has not yet been completed. For multiple predecessor coin data sets, it is preferred to use a combined 0-flag (both valid) rather than two separate O-flags. The column 26 (C-flag) indicates whether a first check calculation for the masked electronic coin data sets was successful. The first check calculation checks in particular whether the command is amount-neutral, thus primarily that the sum of the monetary amounts involved is zero. The “1” state means that a calculation was successful and the “0” state indicates that the calculation was not successful and the “-” state indicates that a calculation has not yet been completed.

[0247] 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)

[0248] Column 27a (R1-flag) indicates whether a first check of a range proof or of the range proof was successful. The same holds for the further columns 27b (R2-flag) and 27c (R3-flag). The “1” state means that a validity check showed that the range proofs or the range proof are or is retraceable and the “0” state indicates that a validity check resulted in that the range proofs or the range proof could not be retraced and the “-” state indicates that a validity check is not yet completed, was not successful. The first range proof of column 27a is always necessary for the coin data set(s) to be considered valid. A typical example of a necessary check is the check that the monetary amount is not negative (or none of the monetary amounts are negative). The second and third range proofs do not affect the validity of the coin data set. The range proof in column 27b is used to check whether the monetary amount of the masked coin data set (or each coin data set) is below a maximum amount. The maximum amount can be predetermined system-wide or for specific terminal types. For example, the range proof of column 27c is used to compare a sum of monetary amounts (sent or) received by the participating unit TE in a specified time period, such as 24 hours, against a sum limit value, or to check, for example, a transaction count per time unit for the participating unit TE, such as a maximum of 5 per minute or 100 per day. The limit values can be predefined by the payment system BZ system-wide or defined for certain types of participating units (thus participating unit-specific). For example, a coffee machine of type X can only dispense four portions of hot drinks per minute due to the appliance and accordingly only four coin transactions per minute are permitted.

[0249] Column 28 (S-flag) indicates whether a signature of the electronic coin data set matches the signature of column 24, wherein “1” state indicates that a validity check resulted in that the signature could be identified as that of the issuer and “0” state 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.

[0250] A change in the status of one of the markings (also referred to as a “flag”) requires approval by the coin register 2 and must then be stored unchangeably in the data structure of FIG. 7. Processing is final in anonymous mode (or for an anonymous masked coin data set) when and only when the required flags 25 to 28 have been validated by the coin register 6, i.e. changed from “0” state to “1” state or “1” state after the corresponding check.

[0251] In the following, a data structure without completion markings 29 is assumed and the validity of anonymous coin data sets is considered first. In order to determine whether a masked electronic coin data set Z is valid, the coin register 2 searches for the last change that regards the masked electronic coin data set Z. It holds that the masked electronic coin data set Z is valid if the masked electronic coin data set Z is listed for its last processing in one of the successor columns 23a, 23b, when and only when that last processing has the corresponding final marking 25 to 28. It also holds that the masked electronic coin data set Z is valid, if the masked electronic coin data set Z is listed for its last processing in one of the predecessor columns 22a, 22b, when and only when this last processing has failed, thus at least one of the corresponding required states of the markings 25 to 28 is set to “0”.

[0252] When the masked electronic coin data set Z is not found in the coin register 2, it is invalid. It also holds that the anonymous masked electronic coin data set Z is not valid for all other cases. For example, 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.

[0253] The checks occurring by the coin register 2 and/or monitoring register 6 to determine whether 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) is/are valid according to predecessor columns 22a, 22b. 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 27a indicates whether the range proofs for the masked electronic coin data set Z could be successfully checked. 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.

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

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

[0256] One processing is, for example, “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 v.sub.i and creating an obfuscation amount r.sub.i, as described earlier with equation (1). As shown in FIG. 7, no entries/markings are required in columns 22a, 22b, 23b and 25 to 27 during the “generating” processing. The masked electronic coin data set Z.sub.i is registered in the successor column 23a. This registration preferably occurs before transmitting 105 to a participating unit TE, in particular or already at the time of generating by the issuing entity 1, and in both cases equation (3) must be performed for this purpose. The masked electronic coin data set Z.sub.i is signed by the issuing entity 1 upon creating, this signature is entered into column 24 to ensure that the electronic coin data set C.sub.i has indeed been created by an issuing entity 1, although other methods may also be used for this purpose. If the signature of a received C.sub.i matches the signature in column 24, the marking in column 28 is set (from “0” to “1”). The markings according to columns 25 to 27 do not require a status change and can be ignored. The range proof is not needed because the coin register 2 can trust that the issuing entity 1 does not issue negative monetary amounts. In an alternative embodiment, however, it can be sent by the issuing entity 1 together in the creating command and checked by coin register 2.

[0257] For example, one processing is “deactivating”. Deactivating 111, thus destroying money, causes the masked electronic coin data set Z.sub.i to become invalid after successful execution of the deactivating command by the issuing entity 1, see also FIG. 13. One can therefore no longer process the (masked) electronic coin data set to be deactivated in the coin register 2. To avoid confusion, the corresponding (non-masked) electronic coin data sets C.sub.i should also be deactivated in the direct transaction layer 3. When “deactivating” 111, 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 deactivating 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 C.sub.i sent along in the deactivating command can be confirmed as signed by the issuing entity 1, the marking 28 is set (from “0” to “1”). The markings according to columns 26 to 27 do not require a status change and can be ignored. The markings according to columns 25 and 28 are set after corresponding check.

[0258] A processing (modification) is, for example, “splitting”. Splitting 110, i.e. dividing an electronic coin data set Z.sub.i into a number n, for example 2, of electronic coin data sets Z.sub.j and Z.sub.k is first performed in the direct transaction layer 3, as still shown in FIGS. 8 and 12, whereby the monetary amounts v.sub.j and of the obfuscation amount r.sub.j are generated. v.sub.k and r.sub.k result from the equations (7) and (8). In the coin register 2, the markings 24 to 27 are set, the predecessor column 22a is written with electronic 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. The status changes required according to columns 24 to 27 are made after the corresponding check by the coin register 2 and document the respective check result. The marking according to column 28 is ignored in particular in anonymous mode. A first range proof R1 according to column 27a must be provided, for example, to show that no monetary amount is negative. A second range proof R2 in column 27b is not necessary because the monetary sub-amounts of the successor are always smaller than the initial monetary amount of the predecessor. A sum range proof R3 in column 27c is also usually not necessary (no new monetary amounts). The column 24 is used for entering a signature which was generated by a participating unit TE splitting the coin data set.

[0259] For example, one processing is “merging”. Merging 109, thus 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 FIGS. 9 and 11, whereby the monetary amount vm and the obfuscation amount rm are calculated. In the coin register 2, the markings 25 to 28 are set, the predecessor column 22a is written with the electronic coin data set Z.sub.i, the predecessor column 22b is written with Z.sub.j, and the successor column 23b is written with Z.sub.m. The markings in columns 25 to 28 require status changes and the coin register 2 performs the corresponding checks. A first range proof R1 according to column 27a must be provided to show that no new money has been generated. A second range proof R2 in column 27b is useful because the new monetary amount of the successor could be greater than a maximum value. A sum range proof R3 in column 27c is also usually useful, as the terminal could be employing newly received predecessors. The marking according to column 28 can be ignored. The column 24 is used for entering a signature generated by a participating unit TE merging the coin data sets.

[0260] A further processing is, for example, “switching”. Switching 108 is necessary when an electronic coin data set has been transmitted to another participating unit TE and a repeated outputting by the transmitting participating unit TE is to be prevented. When switching, the electronic coin data set C.sub.k obtained from the first participating unit TE1 is exchanged 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 participating unit TE2. This switching is necessary to invalidate (make invalid) the electronic coin data set C.sub.k obtained from the first participating unit TE2, thus preventing the same electronic coin data set C.sub.k being output repeatedly. This is because, as long as the electronic coin data set C.sub.k is not switched, and since the first participating unit TE1 has knowledge about the electronic coin data set C.sub.k, the first participating unit TE1 can pass on this electronic coin data set C.sub.k to a third participating unit TE. The switching occurs, for example, by adding a new obfuscation amount r.sub.add to the obfuscation amount r.sub.k of the obtained electronic coin data set C.sub.k, thereby obtaining an obfuscation amount r.sub.i that is known only by the second participating unit TE2. This can also occur in the coin register 2. 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, then the second participating unit TE2 must be able to prove that Z.sub.i−Z.sub.k can be represented as a scalar multiple of G, thus 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.i is equal to the monetary amount of Z.sub.k, thus Z.sub.i=Z.sub.k+r.sub.add*G. This occurs by generating a signature with the public key Z.sub.j−Z.sub.k−r.sub.add*G.

[0261] The “splitting” and “merging” modifications to an electronic coin data set can also be delegated from one participating unit TE1 to another participating unit TE, for example when a communication link to the coin register 2 is not available.

[0262] FIG. 8 shows an example embodiment of a payment system BZ according to the invention regarding the “splitting”, “merging” and “switching” of electronic coin data sets C. In FIG. 8, the first participating unit TE1 obtained the coin data set C.sub.i and now seeks to perform a payment transaction not with the whole monetary amount, but only with a sub-amount v.sub.k. For this purpose, the coin data set C.sub.i is split. First, the monetary amount is divided:

v.sub.iv.sub.j+v.sub.k  (12)

[0263] Each of the obtained values v.sub.j, v.sub.k, here must be greater than 0, because negative monetary amounts are not permitted.

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

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

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

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

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

[0267] When split symmetrically, an individual unique obfuscation amount r.sub.j is formed in the participating unit TE1 for each coin sub-amount, wherein the sum of the number n of obfuscation amounts r.sub.j of the coin data sets is equal to the obfuscation amount r.sub.i of the split coin data set:

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

[0268] In particular, it holds that the last obfuscation sub-amount r.sub.j_n is equal to the difference of the obfuscation amount r.sub.i and the sum of the remaining obfuscation sub-amounts:

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

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

[0270] For asymmetric splitting, masked coin data sets Z.sub.j and Z.sub.k are obtained from the coin data sets and C.sub.k according to equation (3) and registered in the coin register 2 and/or the monitoring register 6. For the 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 markings in columns 25 to 27 require status change and the coin register 2 and/or the monitoring register 6 performs the corresponding checks. The marking according to column 28 and the status according to column 29 are ignored.

[0271] In the case of symmetrical splitting, a signature is calculated in the respective participating unit TE. For this purpose, the following signature key sig is used for the k-th coin sub data set C.sub.j_k:

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

[0272] Here, n is the number of symmetrically split coin data subsets. In case of symmetrically splitting, the signature of the k-th coin data subset k can be checked according to (13c) with the following verification key Sig:

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

[0273] Here, 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 connection with equation (3):

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

wherein by the symmetry properties of the split holds:

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

so that equation 13e is simplified to:

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

[0274] The simplification due to equation 13f allows to completely dispense with zero-knowledge-proofs, whereby the application of a symmetrical distribution saves enormous computing power and data volume.

[0275] Then a coin data subset, here C.sub.k, is transmitted from the first participating unit TE1 to the second participating unit TE2. To prevent double spending, a switching operation is useful to exchange the electronic coin data set C.sub.k obtained from the first participating unit TE1 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 participating unit TE2. In this process, the monetary amount of the coin data set C.sub.i is adopted and not changed, see equation (11).

[0276] 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)

obtaining an obfuscation amount n that is known only by the second participating unit TE2. 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 (v.sub.k=v.sub.l), the second participating unit TE2 must be able to prove that Z.sub.l−Z.sub.k can be represented as a multiple of G. This is done by public signature r.sub.add according to equation (15):

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

wherein G is the generator point of the ECC. Then the coin data set C.sub.i to be switched is masked by means of equation (3) to obtain the masked coin data set Z.sub.l. In the coin register 2 and/or the monitoring register 6, the private signature r.sub.add can then be used to sign, for example, the masked coin data set to be switched Z.sub.l, which is considered as proof that the second participating unit TE2 has only added an obfuscation amount r.sub.add to the masked coin data set and no additional monetary amount, i.e. v.sub.l=v.sub.k.

[0277] The proof is as follows:

Z.sub.k=v.sub.k.Math.H+r.sub.k.Math.G Z.sub.l=v.sub.i.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)

[0278] FIG. 9 shows an example embodiment of a payment system according to the invention for merging (also called combining) electronic coin data sets. The two coin data sets C.sub.i and C.sub.j are obtained in the second participating unit TE2. Following the splitting according to FIG. 8, a new coin data set Z.sub.m is 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 2. Then, upon “merging”, the signature of the second participating unit TE2, as it has obtained the coin data sets C.sub.i and C.sub.j, is entered.

[0279] Upon combining by the payment system BZ, 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 of the combined electronic coin data set.

[0280] Alternatively, when combining (=merging) by a payment system BZ, a new check value is determined from the sum of all check values of the electronic coin data subsets C.sub.i and divided by the product of the number (here two) of coin data subsets C.sub.i and 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 smaller 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.

[0281] FIGS. 10 to 14 each show an example embodiment of a method flow diagram of a method 100. FIGS. 10 to 14 are explained in combination below. In the optional steps 101 and 102, a coin data set C is requested and provided by the issuing entity 1 to the first participating unit TE1 after creating the electronic coin data set in step 102.

[0282] In a first embodiment of FIG. 10 (above the dashed dividing line), a request 210 of a central bank 1a in the issuing entity 1 is used to generate an eMDS C. This is done according to the steps in the method flow diagram of method 200 according to FIG. 6. In step 202, the eMDS C is generated and provided as a printout A to the coin output unit 12 in the air gap process 206. The unit 12 obtains the eMDS C and the signature of the issuer (as an issuance security value) and optionally creates the RDS in step 207. Finally, the RDS is registered with the coin register 2 in step 104, if the signature is valid. By request 101, the eMDS C is provided to the TE1 at step 209 (102).

[0283] In a second embodiment of FIG. 10 (below the dashed dividing line), the request 210 of a central bank 1a in the issuing entity 1 is used to generate an eMDS C. For this purpose, the request is directed to the unit 11 in step 201, preferably as an air gap process. This is done according to the steps in the method flow diagram of method 200 according to FIG. 6. In steps 202, 203, 204, the eMDS C, the RDS and the signed RDS are generated and provided as a printout A to the coin output unit 12 in the air gap process 206. The unit 12 obtains the eMDS C, the RDS, and the signed RDS. In addition, metadata MC is generated in step 205 and provided to unit 12 in step 206a.

[0284] Finally, the RDS and the signed RDS are registered at the coin register 2 at step 104. By the request 101, the eMDS C is provided to the TE1 at step 209 (102). Alternatively, only the signed RDS is provided by the unit 12 to the coin register 2 and the RDS is generated in the TE1 and then sent to the coin register 2 (depicted dashed).

[0285] According to FIG. 11, a signed masked electronic coin data set is sent to the coin register 2 in step 103. In step 103, a masking of the obtained electronic coin data set C.sub.i according to equation (3) and a signing in step 103p according to equation (3a) occurs. Then, in step 104, the masked electronic coin data set Z.sub.i is registered in the coin register 2. Optionally, the participating unit TE1 can switch the obtained electronic coin data set, and in that case, a signature Si would be entered into the coin register 2. In step 105, the transmitting of the coin data set C.sub.i in the direct transaction layer 3 to the second participating unit TE2 occurs. In the optional steps 106 and 107, a validity check with prior masking occurs, in which the coin register 2 confirms the validity of the coin data set Z.sub.i or C.sub.i in a good case.

[0286] In optional step 108, the switching of an 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.i occurs, which invalidates the coin data set C.sub.k and prevents double spending. For this purpose, the monetary amount v.sub.k of the transmitted coin data set C.sub.k is used as the “new” monetary amount v.sub.i. In addition, as already explained with equations (14) to (17), the obfuscation amount r.sub.i 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) has been generated by the second participant unit TE2. Then the masked coin data set is signed and the signed masked coin data set Z.sub.i to be switched is sent to the coin register 2 and the switching from C.sub.k to C.sub.i is ordered. In addition, a signature Sk is created by the first participating unit TE1 or the second participating unit TE2 and stored in the coin register 2. Additionally or alternatively, a signature Si could be created and stored in the coin register 2 when sending participating units TE were registered instead of receiving participating units TE.

[0287] In step 108′, the corresponding check occurs in coin register 2. In this process, Z.sub.k is entered in column 22a according to the table in FIG. 7 and the coin data set Z.sub.i to be rewritten is entered in column 23b. A check is then made in coin register 2 as to whether Z.sub.k is (still) valid, thus 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 merged) and whether a check for the last processing has failed. In addition, Z.sub.i is entered into column 23b and the markings in columns 25, 26, 27 are initially set to “0”. Now a check occurs whether Z.sub.i is valid, wherein the check according to equations (16) and (17) can be used. In a good case, the marking in column 25 is set to “1”, otherwise to “0”. Now a check occurs, the calculation according to equation (10) results in that Z.sub.k and Z.sub.i are valid and accordingly the marking in column 26 is set. Furthermore, it is checked whether the ranges are conclusive, then the marking is set in column 27. Then the signature Si is verified with the corresponding public verification key present in the coin register 2 and logged accordingly. If all checks have been successful and this has been recorded unchangeable accordingly in the coin register 2, the coin data set is considered to have been 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. Double-spending is no longer possible when a third participating unit TE inquires about the validity of the (double-output) coin data set at the coin register 2 and/or the monitoring register 6. When checking the signature, it can be checked in pseudonymous mode whether the second participating unit TE2 has exceeded a monetary amount limit value. The check is performed with respect to a time unit, for example a daily limit value could be monitored with it. If the limit value is exceeded, the coin register 2 first refuses the switching of the coin data set C.sub.i and requests the second participating unit TE2 to deanonymise. Due to the system, de-anonymised switching may possibly be permitted.

[0288] In optional step 109, two coin data sets C.sub.k and C.sub.i are merged into a new coin data set C.sub.m, which invalidates the coin data sets C.sub.k, C.sub.i and prevents double spending. For this purpose, the monetary amount vm is formed from the two monetary amounts v.sub.k and v.sub.i. For this purpose, the obfuscation amount rm is formed from the two obfuscation amounts r.sub.k and r.sub.i. In addition, the masked coin data set Z.sub.m to be merged is obtained by means of equation (3) 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 monitoring register 6 and/or the coin register 2.

[0289] In step 109′, the corresponding check occurs in the coin register 2. Z.sub.m is entered into column 23b according to the table in FIG. 7, which also corresponds to a rewriting. A check then occurs in the coin register 2 as to whether Z.sub.k and Z.sub.i are (still) valid, thus 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 markings in columns 25, 26, 27 are initially set to “0”. Now a check occurs whether Z.sub.m is valid, wherein the check according to equations (16) and (17) can be used. In a good case, the marking in column 25 is set to “1”, otherwise to “0”. Now a check occurs, the calculation according to equation (10) results in that Z.sub.i plus Z.sub.k equals Z.sub.m and accordingly the marking in column 26 is set. Furthermore, it is checked whether the ranges are conclusive, then the marking is set in column 27. Upon checking the signature, it can be checked whether the second participating unit TE2 has exceeded a limit value for monetary amounts. The check occurs with regard to a time unit, for example a daily limit value could be monitored with it.

[0290] In optional step 110, an asymmetric splitting of a coin data set C.sub.i into two coin data sets C.sub.k and C.sub.j occurs, whereby the coin data set C.sub.i is invalidated and the two asymmetrically split coin data sets C.sub.k and C.sub.j are to be validated. Upon asymmetric splitting, the monetary amount v.sub.i is split into monetary sub-values v.sub.k and v.sub.l of different sizes. For this purpose, the obfuscation amount r.sub.i is split into the two obfuscation amounts r.sub.k and r.sub.l. 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 2 with further information, for example, the range proofs (zero-knowledge-proofs), and the splitting is requested as processing. In addition, a signature Si is created and sent to the coin register 2.

[0291] In step 110′, the corresponding check occurs in the coin register 2 and/or the monitoring register 6. In this process, Z.sub.j and Z.sub.k are entered into columns 23a/b according to the table in FIG. 7. A check then occurs in the coin register 2 as to whether Z.sub.i is (still) valid, thus 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 markings in columns 25, 26, 27 are initially set to “0”. Now a check occurs whether Z.sub.j and Z.sub.k are valid, wherein 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 occurs, the calculation according to equation (10) results in that Z.sub.i is equal to Z.sub.k plus Z.sub.j and accordingly the marking in column 26 is set. Furthermore, it is checked whether the ranges are conclusive, then the marking is set in column 27. Upon checking the signature, it can be checked whether the second participating unit TE2 has exceeded a limit value for monetary amounts. The check occurs regarding a time unit, for example a daily limit value could be monitored with it.

[0292] FIG. 13 shows an exemplary deactivating according to the invention. In this case, a deactivating request 111 is sent from the TE1 to the coin output unit 12. The coin output unit 12 creates a deletion request 212 and sends it to the coin register 2 to delete the RDS to the eMDS C to be deactivated. The monetary amount of the eMDS C is credited to an account of the participant.

[0293] Within the scope of the invention, all elements described and/or drawn and/or claimed may be combined with one another in any desired manner.