METHOD FOR DIRECTLY TRANSMITTING ELECTRONIC COIN DATA RECORDS BETWEEN TERMINALS AND PAYMENT SYSTEM

Abstract

A method for directly transmitting an electronic coin data record between first and second terminals, with the following steps carried out by the second terminal: receiving the electronic coin data record from the first terminal, wherein the at least one electronic coin data record includes a monetary amount and a concealment amount; generating a modified electronic coin data record using the received electronic coin data record; masking the modified electronic coin record by applying a homomorphic one-way function to the modified electronic coin record in order to obtain a masked modified electronic coin record; sending a registration request for the masked modified electronic coin data record to a monitoring entity. A currency system and a payment system includes a decentrally controlled database in which masked electronic coin data records are stored; and a direct transaction layer including at least two terminals in which the method can be carried out.

Claims

1.-22. (canceled)

23. A method for directly transmitting an electronic coin data record between a first and a second terminal, comprising the following steps by the second terminal: receiving the electronic coin data record from the first terminal, the at least one electronic coin data record including a monetary amount and a concealment amount; generating a modified electronic coin data record using the received electronic coin data record; masking the modified electronic coin data record by applying a homomorphic one-way function to the modified electronic coin data record in order to obtain a masked modified electronic coin data record; and sending a registration request for the masked modified electronic coin data record to a monitoring entity.

24. The method according to claim 23, wherein said registration request includes the masked modified electronic coin data record as a masked electronic coin data record to be registered and a masked received electronic coin data record as a registered masked electronic coin data record for the received electronic coin data record, and is in a registration request for switching, splitting or joining masked electronic coin data records.

25. The method according to claim 23, wherein in the step of generating the modified electronic coin data record to be switched is generated from the received electronic coin data record, or the received electronic coin data record is split into at least two split modified electronic coin data records, or the received electronic coin data record as a first electronic coin data record and at least one second electronic coin data record are joined to form the joined modified electronic coin data record; and said registration request accordingly includes: exactly one masked electronic coin data record to be registered and exactly one registered masked electronic coin data record, or at least two masked split modified electronic coin data records to be registered, or at least two registered masked electronic coin data records.

26. The method according to claim 23, wherein in the step of generating: the received electronic coin data record is switched to the modified electronic coin data record, wherein a concealment amount for the modified electronic coin data record is generated using a received concealment amount of the received electronic coin data record, and the received monetary amount of the received electronic coin data record is used as a monetary amount for the modified electronic coin data record; or the received electronic coin data record is split into at least two electronic coin part data records, wherein the received monetary amount corresponds to the sum of the monetary amounts of the at least two electronic coin part data records, and the sum of the concealment amounts of the at least two electronic coin part data records correspond to the concealment amount of the received electronic coin data record; or the received electronic coin data record as a first electronic coin data record and at least one second electronic coin data record are joined to form the modified joined electronic coin data record by calculating a concealment amount for the modified electronic coin data record by forming the sum of the respective concealment amounts of the first and second electronic coin data records, and calculating the monetary amount for the modified electronic coin data record by forming the sum of the respective monetary amounts of the first and second electronic coin data records.

27. The method according to claim 22, comprising masking the received electronic coin data record by applying the homomorphic one-way function to the received electronic coin data record in order to obtain the masked received electronic coin data record.

28. The method according to claim 23, wherein the monitoring entity stores valid masked electronic coin data records for electronic coin data records so that the second terminal can check the validity of a received electronic coin data record by sending the masked received electronic coin data record to the monitoring entity.

29. The method according to claim 23, further comprising a step of creating a proof that the monetary amount of the received electronic coin data record is equal to the monetary amount of the electronic coin data record to be switched.

30. A method in a monitoring entity which stores valid masked electronic coin data records formed by applying a homomorphic one-way function to an electronic coin data record, electronic coin data records including a monetary amount and a concealment amount, said method comprising the steps of: receiving a registration request comprising at least one masked electronic coin data record to be registered and at least one registered masked electronic coin data record; checking the registration request received, wherein it is checked whether the registered masked electronic coin data record of the registration request is stored as a valid masked electronic coin data record in the monitoring entity, and it is checked whether the masked electronic coin data records of the registration request are monetarily amount-neutral overall; storing the masked electronic coin data record to be registered as a valid masked electronic coin data record, wherein the registered masked electronic coin data record of the registration request that was previously stored as valid is no longer valid.

31. The method according to claim 30, wherein checking the monetary amount neutrality of the registration request—due to the homomorphic one-way function used—is carried out without knowledge of the amount by forming the difference between the masked electronic coin data records.

32. The method according to claim 30, wherein the monitoring entity receives creation and/or deactivation requests from an issuer entity, for an electronic coin data record newly issued by said issuer entity and/or for an electronic coin data record withdrawn by said issuer entity, respectively.

33. The method according to claim 32, wherein the creation and/or deactivation request for a masked electronic coin data record comprises a signature of the issuer for the masked electronic coin data record, wherein the signature of the masked newly created electronic coin data record is stored in the monitoring entity.

34. The method according to claim 23, wherein an electronic coin data record becomes invalid by marking or deleting the corresponding masked electronic coin data record in the monitoring entity, wherein the corresponding masked electronic coin data record or the corresponding electronic coin data record is also deactivated in said issuer entity.

35. The method according to claim 23, wherein the monitoring entity is a decentrally controlled database, called Distributed Ledger Technology, DLT, in which the masked electronic coin data records are registered with corresponding processing information of the masked electronic coin data record.

36. A payment system for the exchange of monetary amounts, in which a method according to claim 23 is carried out, said payment system comprising: a monitoring layer including a database, which is controlled in a decentralized manner and in which valid masked electronic coin data records for electronic coin data records are stored; and a direct transaction layer including at least two terminals which exchange electronic coin data records.

37. A currency system, comprising an issuer entity, a monitoring entity, a first terminal and a second terminal, said issuer entity being configured to create an electronic coin data record, wherein the monitoring entity is configured to carry out a method according to claim 30 and/or the first and second terminals reconfigured to carry out a method for directly transmitting an electronic coin data record between a first and a second terminal, comprising the following steps by the second terminal: receiving the electronic coin data record from the first terminal, the at least one electronic coin data record including a monetary amount and a concealment amount; generating a modified electronic coin data record using the received electronic coin data record; masking the modified electronic coin data record by applying a homomorphic one-way function to the modified electronic coin data record in order to obtain a masked modified electronic coin data record; and sending a registration request for the masked modified electronic coin data record to a monitoring entity.

38. The currency system according to claim 37, wherein only said issuer entity is authorized to create an electronic coin data record to be newly issued, wherein said issuer entity provides a masked created electronic coin data record with a signature and sends the masked created electronic coin data record and the signature to the monitoring entity.

39. The currency system according to claim 37, wherein the monitoring entity executes creation and/or deactivation requests of said issuer entity for masked electronic coin data records and registration requests for masked modified electronic coin data records of other entities such as the two terminals.

40. The currency system according to one of claim 37, wherein the currency system comprises further coin owner entities, in server entities, which transmit electronic coin data records directly, among each other or from/to terminals, and which send registration requests for masked modified electronic coin data records to the monitoring entity.

41. The currency system according to claim 37, wherein steps are carried out by the second terminal by the steps being carried out in the terminal or by the terminal calling a terminal service which executes in the steps of generating, masking and/or sending for the terminal.

42. The currency system according to claim 37, wherein, in the checking entity, the masked electronic coin data record is recognized as valid when the masked electronic coin data record or its predecessor originates from said issuer entity, wherein the issuer signature of created masked electronic coin data records is stored in the monitoring entity.

43. The currency system according to claim 37, wherein the checking entity and the issuer entity are implemented as a server entity, as a computer program product on a server and/or a computer.

44. The currency system according to claim 37, wherein the first and/or second terminal is configured as a mobile terminal, as a smartphone, a tablet computer, a computer, a machine, and/or as a passive terminal, as a smart card or wearable.

Description

BRIEF DESCRIPTION OF THE FIGURES

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

[0106] In the figures:

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

[0108] FIG. 2 shows an embodiment of a monitoring entity;

[0109] FIG. 3 shows an embodiment of a payment system according to the invention for splitting and switching electronic coin data records;

[0110] FIG. 4 shows an embodiment of a payment system according to the invention for joining electronic coin data records;

[0111] FIG. 5 shows an exemplary embodiment of a method flow diagram of a method according to the invention and corresponding processing steps of a coin data record;

[0112] FIG. 6 shows an embodiment of a method flow diagram of a method according to the invention and corresponding processing steps of a coin data record;

[0113] FIG. 7 shows a further exemplary embodiment of a method flow diagram of a method according to the invention.

DESCRIPTION OF FIGURES

[0114] FIG. 1 shows an embodiment of a payment system including terminals M1 and M2 according to the invention.

[0115] Here, an electronic coin data record C.sub.i is generated in an issuer entity 1, for example a central bank. For the electronic coin data record C.sub.i, which includes a concealment amount, a masked electronic coin data record Z.sub.i is generated and registered in a database as a monitoring entity, which may be referred to as a “concealed electronic data record ledger” here. In the context of this invention, a ledger is understood to be a list, a directory, preferably a database structure. The electronic coin data record C.sub.i is output to a first terminal M1.

[0116] For example, a true random number was generated for this purpose as the concealment amount r.sub.i. This concealment amount r.sub.i is linked to a monetary amount and then forms an i-th electronic coin data record according to the invention:

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

[0117] A valid electronic coin data record can be used for payment. The owner of the two values ν.sub.i and r.sub.i is therefore already in possession of the digital money since the owner can use it for payment. However, the digital money is defined in the system by a pair consisting of a valid electronic coin data record and a corresponding masked electronic coin data record Z.sub.i. The masked electronic coin data record Z.sub.i is obtained by applying a homomorphic one-way function f(C.sub.i) according to Equation (2):

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

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

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

where H and G are generator points of a group G, in which the discrete logarithm problem is hard, with the generators G and H, for which the discrete logarithm of the respective other base is unknown. For example, G and H are generator points of elliptical curve cryptography, ECC—that is, private keys of the ECC. These generator points G and H must be chosen in such a way that the relationship between G and H is not publicly known, so that with:

G=n.Math.H  (4)

the link n must be practically impossible to find in order to prevent the monetary amount ν.sub.i from being manipulated while a valid Z.sub.i can still be calculated. Equation (3) is a “Pederson commitment for ECC” ensuring that the monetary amount ν.sub.i can be passed, i.e. “committed”, to a monitoring entity 2 without revealing it to the monitoring entity 2. Therefore, only the masked coin data record Z.sub.i is sent (revealed) to the public and remote monitoring entity 2.

[0119] Even if encryption based on elliptical curves is or is described in the present example, another cryptographic method based on a discrete logarithmic method would also be conceivable.

[0120] Due to the entropy of the concealment amount r.sub.i, Equation (3) allows for a cryptographically strong Z.sub.i to be obtained even with a small range of values for monetary amounts ν.sub.i. This means that a simple brute force attack by simply estimating monetary amounts ν.sub.i is practically impossible.

[0121] Equation (3) is a one-way function, which means that the computation of Z.sub.i from C.sub.i is easy because an efficient algorithm exists, whereas the computation of C.sub.i from Z.sub.i is very difficult because there is no algorithm that can be solved in polynomial time.

[0122] In addition, Equation (3) is homomorphic for addition and subtraction, i.e. the following applies:

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

[0123] Thus, addition operations and subtraction operations can be carried out both in the direct transaction layer 3 and also in parallel in the accounting layer 4 without the accounting layer 4 having knowledge of the electronic coin data records C.sub.i. The homomorphic property of Equation (3) allows for accounting of valid and invalid electronic coin data records C.sub.i on the sole basis of the masked coin data records Z.sub.i and ensuring that no new monetary amount ν.sub.j has been created.

[0124] Due to this homomorphic property, the coin data record C.sub.i can be split according to Equation (1) into:

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

where:

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

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

[0125] The following applies to the corresponding masked coin data records:

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

[0126] With Equation (9), for example, a “split” processing or a “split” processing step of a coin data record according to FIG. 3 may be checked in a simple manner without the monitoring entity 2 having knowledge of C.sub.i, C.sub.j, C.sub.k. Specifically, the condition of Equation (9) is checked to validate split coin records C.sub.j and C.sub.k and invalidate coin record C.sub.i. Such a split of an electronic coin data record C.sub.i is shown in FIG. 3.

[0127] In the same way, electronic coin data records can also be put together (joined), see FIG. 4 and the explanations therefor.

[0128] In addition, it is necessary to check whether (not allowed) negative monetary amounts are registered. An owner of an electronic coin data record C.sub.i must be able to prove to the monitoring entity 2 that all monetary amounts ν.sub.i in a processing operation are within a value range of [0, . . . , n] without informing the monitoring entity 2 about the monetary amounts ν.sub.i. These proofs of range are also called “range proofs”. Ring signatures are preferably used as range proofs. For the present exemplary embodiment, both the monetary value and the concealment amount of an electronic coin data record are resolved in bit representation, i.e. ν.sub.i=Σa.sub.j*2.sup.j for 0≤j≤n and a.sub.j “element” {0; 1} and r.sub.i=Σb.sub.j*2.sup.j for 0≤j≤n and b.sub.j “element” {0; 1}. A ring signature with C.sub.ij=a.sub.j.Math.H+b.sub.j.Math.G and C.sub.ij−a.sub.j.Math.H is preferably carried out for each bit, wherein, in one embodiment, it is possible to carry out a ring signature only for certain bits.

[0129] What is not shown in FIG. 1 and will only be explained later is that new electronic coin data records C.sub.i are preferably not output directly to terminals, but rather initially to commercial bank, for example.

[0130] In FIG. 1, an electronic coin data record C.sub.i is generated by the issuer entity 1 and a masked electronic coin data record Z.sub.i is calculated by the issuer entity 1 using Equation (3) and registered in the monitoring entity 2. The first terminal M1 subsequently transmits the electronic coin data record C.sub.i to a second terminal M2. Before that, the terminal may optionally carry out one of the processing steps (switching, joining, splitting). The transmission takes place wirelessly via WLAN, NFC or Bluetooth, for example. The transmission may be additionally secured by cryptographic encryption methods, for example by negotiating a session key or using a PKI infrastructure.

[0131] The transmitted electronic coin data record C.sub.i is received as C.sub.i* in the second terminal M2. When the electronic coin data record C.sub.i* is received, the second terminal M2 is in possession of the digital money represented by the electronic coin data record C.sub.i*. If both terminals trust each other, no further steps are necessary to end the process. However, the terminal M2 does not know whether the electronic coin data record C.sub.i* is actually valid. In addition, the terminal M1 could also transmit the electronic coin data record C.sub.i to a third terminal (not shown). In order to prevent this, further preferred steps are provided in the method.

[0132] In order to check the validity of the received electronic coin data record C.sub.i*, the masked transmitted electronic coin data record Z.sub.i* is calculated in the second terminal M2 with the—public—one-way function from Equation (3). The masked transmitted electronic coin data record Z.sub.i*is then transmitted to the monitoring entity 2 and searched there. If there is a match with a registered and valid masked electronic coin data record, the validity of the received coin data record C.sub.i* is indicated to the second terminal M2 and it is determined that the received electronic coin data record C.sub.i* is equal to the registered electronic coin data record C.sub.i. With the check for validity, it may be determined, in one embodiment, that the received electronic coin data record C.sub.i* is still valid, i.e. that it has not already been used by another processing step or in another transaction and/or was subject to another change.

[0133] Preferably, the electronic coin data record obtained is then switched by the second terminal.

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

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

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

TABLE-US-00001 TABLE 1 Number of operations to be carried out per processing of a coin data record in the terminal or issuer entity; further operations not listed here are required; instead of the implementation listed, other implementations implying other operations are conceivable Command or Create Create random Create Create range step signature number mask proof Create 1 1 1 0 or 1 Deactivate 1 0 1 0 or 1 Split 0 1 3 0 or 1 Join 0 0 3 1 Switch 0 1 2 1

[0137] Table 1 above shows that, for each coin data record and each of the processing operations “create”, “deactivate”, “split”, “join” and “switch”, different operations “create signature”; “create random number”; “create mask”; “range proof” may be provided, each of the processing operations being registered in the monitoring entity 2. It may be appended there in unchangeable form to a list of previous processing operations for masked electronic coin data records Z.sub.i. The processing operations of “create” and “deactivate” on an electronic coin data record are only carried out in secure locations and/or only by selected entities, for example the issuer entity 1, while the operations of all other processing operations can be carried out on terminals M1 to M3.

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

[0139] In principle, it may also be planned, in one embodiment, that a range proof is also carried out by the issuer entity 1 during creation and/or deactivation.

[0140] The operations required for the monitoring entity 2 for the individual processing operations are listed in the Table 2 below:

TABLE-US-00002 TABLE 2 Number of operations to be carried out per processing of a coin data record in the monitoring entity; further operations not listed here are required; instead of the implementation listed, other implementations implying other operations are conceivable Checking Checking the Checking homo- the validity of the morphic properties signature masked Checking of the masked Command of electronic range electronic coin data or step the issuer data record proof records, i.e. adding Create 1 0 0 or 1 0 Deactivate 1 1 0 or 1 0 Split 0 1 2 or more 1 Join 0 2 or more 1 1 Switch 0 1 1 0

[0141] All operations of Table 2 can be carried out in the monitoring entity 2, which, as a trusted entity, for example as a decentralized server, in particular a distributed trusted server, ensures sufficient integrity of the electronic coin data records.

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

TABLE-US-00003 TABLE 3 Preferred units in the system components Issuer Monitoring Command or step entity Terminal entity Random number generator Yes — — (high security) Random number generator — Yes — (deterministic) PKI for signing Yes — — PKI for checking signature — (Yes) Yes Read access on DLT Yes Yes Yes Write access on DLT Yes Yes Yes Deactivating the electronic coin Yes Yes — data record Transport encryption Yes Yes — Safe storage (Yes) Yes —/Yes Masking unit Yes Yes — Range proof — Yes — Checking range proof — — Yes DLT software — — Yes

[0143] Table 3 shows an overview of the components to be preferably used in each system participant, i.e. the issuer entity 1, a terminal M1 and the monitoring entity 2. The terminal M1 may be configured as a wallet for electronic coin data records, i.e. as an electronic purse, i.e. a data storage for the terminal in which a large number of coin data records can be stored, and may be implemented, for example, in the form of an application on a smartphone or IT system of a retailer, a commercial bank or another market participant, and send or receive an electronic coin data record. Thus, the components in the terminal as shown in Table 3 are implemented as software. It is assumed that the monitoring entity 2 is based on a DLT and is operated by a number of trusted market participants.

[0144] FIG. 2 shows an exemplary embodiment of a monitoring entity 2 from FIG. 1. In FIG. 2, an exemplary database is shown in the form of a table in which the masked electronic coin data records Z.sub.i and possibly—as shown here—processing thereof are registered. In the simplest embodiment of the database, on the other hand, only the currently valid masked coin data records Z.sub.i would be stored. The monitoring entity 2 is preferably arranged remote from the terminals M1 to M3 locally and is accommodated, for example, in a server architecture.

[0145] Each processing operation for a processing (creating, deactivating, splitting, joining and switching) is registered in the monitoring entity 2 and appended there in unchangeable form to a list of previous processing operations for masked electronic coin data records Z.sub.i. The individual operations or their check results, that is to say the intermediate results of processing, are recorded in the monitoring entity 2.

[0146] The processing of “creating” and “deactivating”, which concerns the existence of the monetary amount ν.sub.i per se, that is, the creation and destruction of money, require additional approval by the issuer entity 1 in order to be registered (and logged) in the monitoring entity 2. The other processing operations (splitting, joining, switching) do not require any authorization by the issuer entity 1 or by the command initiator (=payer, for example the first terminal M1).

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

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

[0149] Column 27 (R flag) indicates whether a check of the range proof(s) was successful, where status “1” means that a validity check showed that the range proof(s) are confirmable and status “0” indicates that a validity check showed that the range proof(s) could not be reproduced and status “−” indicates that a validity check has not yet been completed. Column 28 (S flag) shows the successful verification of the signature. Status “1” means that a validity check showed that the signature could be identified as that of the issuer entity and status “0” indicates that a validity check showed that the signature could not be identified as that of the issuer entity and status “−” indicates that this validity check has not yet been completed.

[0150] A change in the status of one of the markings (also referred to as “flags”) requires approval by the monitoring entity 2 and must then be stored in the monitoring entity 2 in an unchangeable manner. Processing is final if and only if the required markings 25 to 28 have been validated by the monitoring entity 2, i.e. have changed from state “0” to state “1” or state “1” after the corresponding check.

[0151] In order to determine whether a masked electronic coin data record Z is valid, the monitoring entity 2 searches—in the present variant—for the last change that affects the masked electronic coin data record. It is essential that the masked electronic coin data record Z is valid if and only if the masked electronic coin data record Z is listed for its last processing in one of the successor columns 23a, 23b and this last processing has the corresponding final marking 25 to 28. It is also essential that the masked electronic coin data record Z is valid if and only if the masked electronic coin data record Z is listed for its last processing in one of the predecessor columns 22a, 22b and this last processing failed, i.e. at least one of the correspondingly requested states of the markings 25 to 28 is set to “0”.

[0152] It is also essential that the masked electronic coin data record Z is not valid for all other cases, for example if the masked electronic coin data record Z is not found in the monitoring entity 2; or if the last processing of the masked electronic coin data record Z is listed in one of the successor columns 23a, 23b, but this last processing never became final; or if the last processing of the masked electronic coin data record Z is in one of the predecessor columns 22a, 22b and this last processing is final.

[0153] The checks by the monitoring entity 2 to check whether processing is final are shown in columns 25 to 28: The status in column 25 indicates whether the masked electronic coin data record(s) are valid according to predecessor columns 22a, 22b. The status in column 26 indicates whether the calculation for amount neutrality, for example according to Equation (10), is correct. The status in column 27 indicates whether the range proof for the masked electronic coin data records Z could be checked successfully. The status in column 28 indicates whether the signature in column 24 of the masked electronic coin data record Z is a valid signature of the issuer entity 1.

[0154] The status “0” in one of columns 25 to 28 indicates that the check was not successful. The status “1” in one of columns 25 to 28 indicates that the check was successful. The status “−” in one of columns 25 to 28 indicates that no check has been carried out. The status may also have a different value, as long as it is possible to clearly differentiate between success/failure of a check and it is clear whether a certain check was carried out.

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

[0156] One processing operation is, for example, “creating” an electronic coin data record C.sub.i. The creation in the direct transaction layer 3 by the issuer entity 1 includes choosing a monetary amount ν.sub.i and creating a concealment amount r.sub.i, as has already been described with Equation (1). As shown in FIG. 2, no entries/markings are required in columns 22a, 22b, 23b and 25 to 27 during the “create” processing. The masked electronic coin data record Z is registered in the successor column 23a. This registration is preferably carried out before the transmission to a terminal M1 to M3, in particular or already during creation by the issuer entity 1, wherein Equation (3) must be executed in both cases. The masked electronic coin data record Z.sub.i is signed by the issuer entity 1 when it is created; this signature is entered in column 24 to ensure that the electronic coin data record C.sub.i was actually created by an issuer entity 1, although other methods may also be used for this purpose. If the signature of a received Z.sub.i matches the signature in column 24, the marking is set in column 28 (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 required since the monitoring entity 2 trusts in the issuer entity 1 not issuing any negative monetary amounts. In an alternative embodiment, however, it may be sent by the issuer entity 1 in the create command and checked by the monitoring entity 2.

[0157] A processing operation is, for example, “deactivating”. The deactivation, that is to say the destruction of money, has the effect that the masked electronic coin data record Z.sub.i becomes invalid after the issuer entity 1 has successfully executed the deactivate command. The (masked) electronic coin data record to be deactivated can therefore no longer be processed further in the accounting layer 4. In order to avoid confusion, the corresponding (unmasked) electronic coin data records C.sub.i should also be deactivated in the direct transaction layer 3. When “deactivating”, the predecessor column 22a is written with the electronic coin data record Z.sub.i, but no subsequent column 23a, 23b is used. When deactivating, the masked electronic coin data record Z.sub.i must be checked to see whether the signature matches the signature according to column 24 in order to ensure that the electronic coin data record C.sub.i was actually created by an issuer entity 1, although other means may be used for this check. If the signed Z.sub.i, which is sent with the deactivate command, can be confirmed as signed by the issuer 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 appropriate checking.

[0158] A processing operation is, for example, “splitting”. Splitting, that is dividing an electronic coin data record Z.sub.i into two electronic partial coin data records Z.sub.j and Z.sub.k, is initially carried out in the direct transaction layer 3, as shown in FIG. 3, wherein the monetary amounts ν.sub.j and the concealment amount r.sub.j are generated. ν.sub.k and r.sub.k result from Equations (7) and (8). In the monitoring entity 2, the markings 25 to 27 are set, the previous column 22a is written with the electronic coin data record Z.sub.i, the next column 23a is written with Z.sub.j and the next column 23b is written with Z.sub.k. The status change required according to columns 25 to 27 takes place after the corresponding check by the monitoring entity 2 and document the respective check result. The marking according to column 28 is ignored.

[0159] One processing operation is, for example, “joining”. Joining, i.e. merging two electronic coin data records Z.sub.i and Z.sub.j to form one electronic coin data record Z.sub.m, is initially carried out in the direct transaction layer 3, as shown in FIG. 4, wherein the monetary amount ν.sub.m and the concealment amount r.sub.m are calculated. In the monitoring entity 2, the markings 25 to 27 are set, the previous column 22a is written with the electronic coin data record Z.sub.i, the previous column 22b is written with Z.sub.j and the next column 23b is written with Z.sub.m. The markings in columns 25 to 27 require status changes and monitoring entity 2 carries out the corresponding checks. A range proof must be provided to show that no new money has been created. The marking according to column 28 is ignored.

[0160] One processing operation is, for example, “switching”. Switching is necessary if an electronic coin data record has been transmitted to another terminal and a renewed issue by the transmitting terminal (here M1) is to be excluded. When switching, also called “switch”, the electronic coin data record C.sub.k received from the first terminal M1 is exchanged for a new electronic coin data record C.sub.l with the same monetary amount. The new electronic coin data record C.sub.l is generated by the second terminal M2. This switch is necessary in order to invalidate (make invalid) the electronic coin data record C.sub.k received from the first terminal M1, thereby preventing the same electronic coin data record C.sub.k from being output again. This is because, as long as the electronic coin data record C.sub.k has not been switched, the first terminal M1 can pass this electronic coin data record C.sub.k to a third terminal M3 since the first terminal M1 has knowledge of the electronic coin data record C.sub.k. Switching is carried out, for example, by adding a new concealment amount r.sub.add to the concealment amount r.sub.k of the obtained electronic coin data record C.sub.k, whereby a concealment amount r.sub.i is obtained which only the second terminal M2 knows. This may also carried out in the monitoring entity 2. To prove that only a new concealment amount r.sub.add was added to the concealment amount r.sub.k of the masked received electronic coin data record Z.sub.k, but the monetary amount remained the same, so that Equation (11):

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

is valid, the second terminal M2 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 a concealment amount r.sub.add was 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.

[0161] In FIG. 3, an embodiment of a payment system according to the invention for splitting and switching of electronic coin data records is shown. In FIG. 3, the first terminal M1 has received the coin data record C.sub.i and would now like to carry out a payment transaction not with the entire monetary amount ν.sub.i, but only with a part v.sub.k thereof. For this purpose, the coin data record C.sub.i is split. To do this, the monetary amount is split first:

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

[0162] Here, each of the received amounts ν.sub.j, ν.sub.k must be greater than 0 because negative monetary amounts are not permitted. In addition, new concealment amounts are derived:

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

[0163] The masked coin data records Z.sub.j and Z.sub.k are then obtained from the coin data records C.sub.j and C.sub.k in accordance with Equation (3) and are registered in the monitoring entity 2. For the split, the predecessor column 22a is described with the coin data record Z.sub.i, the successor column 23a with Z.sub.j and the successor column 23b with Z.sub.k. The markings in columns 25 to 27 require a status change and the monitoring entity 2 carries out the corresponding checks. The marking according to column 28 is ignored.

[0164] Then a coin data record, here C.sub.k, is transmitted from the first terminal M1 to the second terminal M2. In order to prevent double spending, a switch operation is useful in order to exchange the electronic coin data record C.sub.k received from the first terminal M1 for a new electronic coin data record C.sub.l with the same monetary amount. The new electronic coin data record C.sub.l is generated by the second terminal M2. The monetary amount of the coin data record C.sub.l is adopted and not changed, see Equation (11). Then, according to Equation (14), a new concealment amount r.sub.add is added to the concealment amount r.sub.k of the received electronic coin record C.sub.k,

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

whereby a concealment amount r.sub.l which only the second terminal M2 knows is obtained. In order to prove that only a new concealment amount r.sub.add was added to the concealment amount r.sub.k of the received electronic coin data record Z.sub.k, but the monetary amount remained the same (ν.sub.k=ν.sub.l), the second terminal M2 must be able to prove that Z.sub.l−Z.sub.k can be represented as a multiple of G. This is done using the public signature R.sub.add according to Equation (15):

R.sub.add=r.sub.add.Math.G

=Z.sub.l−Z.sub.k=(ν.sub.l−ν.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 record C.sub.l to be switched is masked by means of Equation (3) in order to obtain the masked coin data record Z.sub.l. The private signature r.sub.add may then be used in the monitoring entity 2 in order, for example, to sign the masked electronic coin data record Z.sub.l to be switched, which is valid as proof that the second terminal M2 has only added a concealment amount r.sub.add to the masked electronic coin data record and no additional monetary value, i.e., v.sub.l=v.sub.k.

[0165] The proof is as follows:

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

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

[0166] FIG. 4 shows an exemplary embodiment of a payment system according to the invention for joining electronic coin data records. The two-coin data records C.sub.i and C.sub.j are received in the second terminal M2. Similar to the split according to FIG. 3, a new coin data record Z.sub.m is now obtained by adding both the monetary amounts and the concealment amount of the two-coin data records C.sub.i and C.sub.j. Then, the received coin data record C.sub.m to be joined is masked and the masked coin data record Z.sub.m is registered in the monitoring entity.

[0167] In FIGS. 3 and 4, the variant of a database of the monitoring entity 2 which contains a list of processing operations of the masked coin data records is shown again. Other variants of a database, for example masked coin data records with status or only valid masked coin data records, may also be used—as already mentioned with respect to FIG. 2.

[0168] FIGS. 5 to 7 are each exemplary embodiments of a method flow chart of a method 100 according to the invention. Both FIGS. 5 and 6 are explained together below.

[0169] Steps 101 to 104 are optional for the further method and are described using the example of the terminal M1. In the optional steps 101 and 102, a coin data record is requested and provided by the issuer entity 1—in this case to the first terminal M1—after the electronic coin data record has been created. A signed masked electronic coin data record is sent to the monitoring entity 2 in step 103. In step 103, the received electronic coin data record C.sub.i is masked in accordance with Equation (3) and as explained in FIG. 1. Then, in step 104, the masked electronic coin data record Z.sub.i is registered in the monitoring entity 2. It could be envisioned that masked electronic coin data records are only valid in the monitoring entity when they are registered by a participant such as a terminal device or server. Alternatively, as explained in relation to FIG. 1, the masked electronic coin data record Z.sub.i may already be registered in the monitoring entity 2 as a valid masked electronic coin data record after step 102. Optionally, the terminal M1 may switch the received electronic coin data record with step 104, as will be described in more detail in step 108.

[0170] In step 105, the coin data record C.sub.i is transmitted in the direct transaction layer 3 to the second terminal M2. In the optional steps 106 and 107, a validity check is carried out with previous masking, wherein the monitoring entity 2 confirms the validity of the coin data record Z.sub.i or C.sub.i in case of success.

[0171] In step 108, a received coin data record C.sub.k is switched (the received coin data record C.sub.i could of course also be switched) to a new coin data record C.sub.l, whereby the coin data record C.sub.k becomes invalid and double spending is prevented. For this purpose, the monetary amount ν.sub.k of the transmitted coin data record C.sub.k is used as the “new” monetary amount ν.sub.l. In addition, as already explained with Equations (14) to (17), the concealment amount r.sub.l is created. The additional concealment amount r.sub.am is used to prove that no new money (in the form of a higher monetary amount) was generated by the second terminal M2. Then, among other things, the masked coin data record Z.sub.l to be switched is sent to the monitoring entity 2 and the switch from C.sub.k to C.sub.l is instructed.

[0172] The corresponding check is carried out in the monitoring entity 2 in step 108′. Z.sub.k is entered in column 22a according to the table in FIG. 2 and the coin data record Z.sub.l to be rewritten is entered in column 23b. Then, a check in the monitoring entity 2 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 was not further split or deactivated or joined) and whether a check for the last processing failed. In addition, Z.sub.l is entered in column 23b and the markings in columns 25, 26, 27 are initially set to “0”. A check is now carried out as to whether Z.sub.l is valid, in which case the check according to Equations (16) and (17) may be used. In case of success, the marking in column 25 is set to “1”, otherwise to “0”. A check is now carried out, and the calculation according to Equation (10) shows that Z.sub.k and Z.sub.l are valid and the marking in column 26 is set accordingly. It is also checked whether the ranges are coherent, and then the marking in column 27 is set. If all three checks were successful and this was accordingly committed in the monitoring entity 2, the coin data record is considered to be switched. This means that the coin data record C.sub.k is no longer valid and the coin data record C.sub.l is valid from now on. Double spending is no longer possible if a third terminal M3 asks the monitoring entity 2 about the validity of the (doubly dispensed) coin data record.

[0173] In general—different from the illustration in FIG. 5—the electronic coin data records C.sub.i created by the issuer entity are transmitted (issued) to an entity (such as server, computer, . . . ) of a commercial bank. The (server) entity of the commercial bank provides the electronic coin data records for terminals. The terminal M1 requests and then receives the electronic coin data record from the entity of the commercial bank in steps 101 and 102. In particular, when the terminal M1 requests and receives the electronic coin data record C.sub.i from a server of a commercial bank, already switching in step 104 is useful.

[0174] In step 109, two-coin data records C.sub.k and C.sub.i are joined to form a new coin data record C.sub.m, as a result of which the coin data records C.sub.k, C.sub.i become invalid and double spending is prevented. For this purpose, the monetary amount Urn is formed from the two monetary amounts ν.sub.k and ν.sub.i. For this purpose, the concealment amount r.sub.m is formed from the two concealment amounts r.sub.k and r.sub.i. In addition, the masked coin data record to be joined is obtained by means of Equation (3) and it (together with other information) is sent to the monitoring entity 2 and the joining is requested as processing.

[0175] In step 109′ the corresponding check is carried out in the monitoring entity 2. In this case, Z.sub.m is entered in column 23b according to the table in FIG. 2. The monitoring entity 2 then checks 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 are not further split or deactivated or joined) and whether a check for the last processing failed. In addition, the markings in columns 25, 26, 27 are initially set to “0”. A check is now made as to whether Z.sub.m is valid, in which case the check according to Equations (16) and (17) may be used. In case of success, the marking in column 25 is set to “1”, otherwise to “0”. A check is now carried out, and the calculation according to Equation (10) shows that Z.sub.i plus Z.sub.k is equal to Z.sub.m and the marking in column 26 is set accordingly. It is also checked whether the ranges are consistent, and then the marking in column 27 is set.

[0176] In step 110, a coin data record C.sub.i is split into two partial coin data records C.sub.k and C.sub.j, whereby the coin data record C.sub.i is made invalid and the two split partial coin data records are to be made valid. For this purpose, the monetary amount ν.sub.i is split into the two monetary amounts ν.sub.k and ν.sub.j. For this purpose, the concealment amount r is split into the two concealment amounts r.sub.k and r.sub.j. In addition, the masked partial coin data records Z.sub.k and Z.sub.j are obtained by means of Equation (3) and these are sent with additional information, for example the range proofs, to the monitoring entity 2 and the splitting is requested as processing.

[0177] In step 110′, the corresponding check is carried out in the monitoring entity 2. Z.sub.j and Z.sub.k are entered in the columns 23a/b according to the table in FIG. The monitoring entity 2 then checks 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 joined) and whether a check for the last processing failed. In addition, the markings in columns 25, 26, 27 are initially set to “0”. A check now takes place as to whether Z.sub.j and Z.sub.k are valid, in which case the check according to Equations (16) and (17) may be used. n case of success, the marking in column 25 is set to “1”. A check is now carried out, and the calculation according to Equation (10) shows that Z.sub.i is equal to Z.sub.k plus Z.sub.j and the marking in column 26 is set accordingly. It is also checked whether the ranges are consistent, and then the marking in column 27 is set.

[0178] FIG. 7 once again shows an overview of the method steps 101-110′ in one sequence. From the point of view of the second terminal M2, an electronic coin data record which was registered 104 by the terminal M1 is received 105. With this electronic coin data record, a further (modified) electronic coin data record for switching, joining or splitting is generated and masked 108-110. The corresponding registration request is sent to the monitoring entity, which receives and processes it 108′-110′. Implementations of these steps and the steps shown in dashed lines, which are optional in the various variants, have already been adequately described

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