METHOD, TERMINAL, MONITORING ENTITY, AND PAYMENT SYSTEM FOR MANAGING ELECTRONIC COIN DATASETS

Abstract

A method relates to a terminal for managing electronic coin datasets and to a corresponding terminal. The electronic coin datasets are output by a central issuer entity, wherein each electronic coin dataset has a test value, and the test value is incremented when the electronic coin dataset is directly transmitted between two terminals or the test value is invariant in the event of an action carried out by terminals on the electronic coin dataset. In the method, it is determined whether the electronic coin dataset is displayed by the terminal in the payment system or whether the electronic coin dataset is returned to the central issuer entity. A method in a payment system is provided for managing electronic coin datasets, to a corresponding payment system, and to a monitoring entity.

Claims

1.-26. (canceled)

27. A method in a terminal for managing electronic coin data sets of a payment system, wherein the electronic coin data sets are issued by a central issuing entity, wherein each electronic coin data set has a check value, wherein the check value is incremented when the electronic coin data set is directly transmitted between two terminals or wherein the check value is invariant to an action performed by terminals with the electronic coin data set, wherein the method comprises the step of: determining by the terminal, based on the check value of an electronic coin data set, whether this electronic coin data set is displayed by the terminal at the payment system; or determining by the terminal, based on the check value of the electronic coin data set, whether the electronic coin data set is returned to the central issuing entity.

28. The method according to claim 27, wherein the electronic coin data set is returned to the central issuing entity by the payment system as a result of the displaying.

29. The method according to claim 27, wherein the payment system requests modifying of the electronic coin data set from the terminal as a result of the displaying.

30. The method according to claim 27, wherein a counter value in the payment system concerning said electronic coin data set is determined as a result of the displaying by the payment system using the check value of the electronic coin data set.

31. The method according to claim 30, wherein the counter value is incremented with each action concerning the electronic coin data set, wherein for different actions the counter value is incremented with different weighting.

32. The method according to claim 27, wherein each electronic coin data set has a first check value and a second check value, wherein the first check value is incremented when directly transmitting the electronic coin data set between two terminals, and wherein it is determined based on the first check value of the electronic coin data set whether the electronic coin data set is displayed by the terminal at the payment system.

33. The method according to claim 27, wherein each electronic coin data set has a first check value and a second check value, wherein based at least on the second check value of the electronic coin data set it is determined whether the electronic coin data set is returned to the central issuing entity.

34. The method according to claim 33, wherein the second check value is invariant to an action performed by terminals on the electronic coin data set, and wherein the second check value is at least one value from the following list: return date of the electronic coin data set; issuance date of the electronic coin data set; registration date of the electronic coin data set; and identification value of the electronic coin data set.

35. The method according to claim 33, wherein the second check value is variable, and wherein the second check value comprises the first check value to determine whether the electronic coin data set is returned.

36. The method according to claim 27, wherein exceeding a threshold value of the check value of the electronic coin data set is detected by a first terminal and an action is performed on said electronic coin data set, the direct transmitting of this electronic coin data set from the first terminal to a second terminal, is performed only when no other electronic coin data set is present in the first terminal.

37. The method according to claim 27, wherein exceeding a blocking threshold value of the check value of the electronic coin data set is detected by a first terminal and an action is performed with this electronic coin data set, the direct transmitting of this electronic coin data set from the first terminal to a second terminal, is blocked, irrespective of whether or not another electronic coin data set is present in the first terminal.

38. The method according to claim 37, wherein the threshold value of the check value is lower than the blocking threshold value of the check value.

39. A terminal, having: a computing unit arranged to manage electronic coin data sets according to a method of claim 27; means for accessing a data storage, wherein at least one electronic coin data set is stored in the data storage; and an interface arranged to output the at least one electronic coin data set to another terminal and/or for displaying the electronic coin data set to the payment system and/or for directly or indirectly returning the electronic coin data set to a central issuing entity.

40. A method in a payment system, for managing electronic coin data sets, wherein the electronic coin data sets are issued by a central issuing entity, wherein for each electronic coin data set a check value is present, wherein the check value is incremented when the electronic coin data set is directly transmitted between two terminals or wherein the check value is invariant to an action performed by terminals on the electronic coin data set, wherein the method comprises the step of: determining, by the payment system, whether the electronic coin data set is returned based on the check value of the electronic coin data set.

41. The method according to claim 40, wherein only masked electronic coin data sets are managed in the payment system.

42. The method according to claim 40, wherein the electronic coin data set is provided for transmitting between two terminals, wherein the electronic coin data set to be transmitted is returned from the payment system to the issuing entity as a result of the determining, and wherein an electronic coin data set of the payment system or a newly issued electronic coin data set is transmitted instead of the electronic coin data set to be transmitted.

43. The method according to claim 42, wherein the electronic coin data set is provided for transmitting between two terminals, and wherein the payment system is provided for returning the electronic coin data set to be transmitted from a terminal to the issuing entity.

44. The method according to claim 40, wherein by the payment system a counter value in the payment system relating to the electronic coin data set using the check value of the electronic coin data set is determined, wherein if a threshold value of the counter value is exceeded, the electronic coin data set is returned, directly or indirectly, to the central issuing authority.

45. The method according to claim 40, wherein each electronic coin data set has a check value that is invariant in an action performed by terminals with the electronic coin data set, and wherein this check value is stored in the payment system for checking the return by the payment system, and wherein the check value is at least one value from the following list: return date of the electronic coin data set; issuance date of the electronic coin data set; registration date of the electronic coin data set; and identification value of the electronic coin data set.

46. The method according to claim 40, wherein when performing an action on the electronic coin data set by the payment system, the check value of the electronic coin data set incremented during direct transmitting is reset by the payment system.

47. The method according to claim 40, wherein when combining electronic coin data subsets into a combined electronic coin data set, the highest check value of the electronic coin data subsets is determined by the payment system and this highest check value is adopted as the check value of the combined electronic coin data set.

48. The method according to claim 40, wherein, when combining electronic coin data subsets into a combined electronic coin data set by the payment system, a new check value is determined from the sum of all check values of the electronic coin data subsets divided by the product of the number of coin data subsets with a constant correction value and wherein this new check value is adopted as the check value of the combined electronic coin data set, wherein the correction value is greater than or equal to 1 and wherein the correction value depends on a maximum deviation of the individual check values of the electronic coin data subsets or on a maximum check value of one of the electronic coin data subsets, wherein further the correction value is less than or equal to 2.

49. The method according to claim 40, wherein returning of the electronic coin data set from the payment system to the issuing entity is performed when the terminal initiates redeeming a monetary amount of the electronic coin data set to an account of the payment system and/or when the terminal requests a change of the monetary amount of the electronic coin data set to another currency system of the payment system.

50. A payment system comprising a monitoring entity, a first terminal and at least a second terminal, wherein an issuing entity is adapted to create an electronic coin data set for the payment system , wherein the payment system is adapted to perform the method for managing electronic coin data sets according to claim 40.

51. The payment system according to claim 50, wherein the payment system is arranged to manage electronic coin data sets for managing electronic coin data sets from further issuing entities and/or monetary amounts as book money.

52. A monitoring entity arranged to manage an electronic coin data set, wherein the electronic coin data set has been issued by a central issuing entity, wherein for each electronic coin data set there is a check value present, wherein the check value is incremented when the electronic coin data set is directly transmitted between two terminals or wherein the check value is invariant in an action performed by terminals on the electronic coin data set, wherein the monitoring entity is arranged to: determine, based on the check value of the electronic coin data set, whether the electronic coin data set is returned; and/or mark the coin data set, wherein the check value and/or the coin data set has been sent for the purpose of a displaying.

Description

BRIEF SUMMARY OF THE FIGURES

[0137] In the following, the invention or further embodiments and advantages of the invention are explained in more detail based on figures, wherein the figures describe only embodiments of the invention. Identical components in the figures are given the same reference signs. The figures are not to be regarded as true to scale, and individual elements of the figures may be shown in exaggeratedly large or exaggeratedly simplified form.

[0138] It shows:

[0139] FIGS. 1a,b an embodiment example of a payment system according to the prior art;

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

[0141] FIG. 3 an embodiment example of a further development of the process flow diagram shown in FIG. 2;

[0142] FIG. 4 an embodiment of a further development of the process flow diagram shown in FIG. 2;

[0143] FIG. 5 an embodiment example of a process flow diagram of a method according to the invention;

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

[0145] FIG. 7 an embodiment example of a payment system, in particular a monitoring entity;

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

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

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

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

[0150] FIG. 12 an embodiment example of an apparatus according to the invention;

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

FIGURE DESCRIPTION

[0152] FIG. 1a and FIG. 1b show an embodiment example of a payment system according to the prior art and have already been briefly described in the introduction. Repeating, the terminal M7 wants to register the received coin data set C.sub.1 as its coin data set C.sub.7 at the entity 4 and the entity 4 detects that the coin data set C.sub.1 is already invalid. As a result, entity 4 does not accept either the supposedly valid coin data set C.sub.1 or the coin data set C.sub.7 to be switched.

[0153] The problem can occur when, for example, an attacker M1 directly passes the coin data set C.sub.1 to two participants M2 and M3. Once M2 registers the received coin data set in the monitoring entity 4, the coin data set C.sub.1 becomes invalid. In the example shown, the coin data set C.sub.1 becomes invalid as the sharing is communicated to the monitoring entity. An unsuspecting subscriber (terminal) M3 passes on the coin data set C.sub.1 directly without having it registered. Only the terminal M7 breaks the direct transmission chain, wherein the monitoring entity 4 recognizes the invalidity from the coin data set C.sub.1 and thus the double sharing is detected. A central bank (hereafter synonymous with an issuing entity of the electronic coin data sets) might now, on the one hand, want to limit the number of direct transmissions of coin data sets and, on the other hand, want to be able to trace where the attack took place in case of a detected attack.

[0154] Thus, in the prior art, an attack (double issuance of an electronic coin data set from M1) is detected relatively late and a large number of direct transmissions are performed in an unauthorized manner. Whether the attacker M1 is subsequently identifiable depends on implementation details of the overall system. For example, the terminals for the monitoring entity may be anonymous, pseudonymous, or identity-bound. In addition, the large number of transactions of an electronic coin data set and also its advancing lifetime increase the risk of tamper(s) with the electronic coin data set. It is thus desirable that when a certain lifetime or number of actions in total on/with the coin data set is exceeded, the coin data set expires.

[0155] The overall system according to the invention comprises an issuing entity (central bank), at least one payment system and a plurality of participants represented as terminals Mx. The payment system comprises, for example, commercial banks and one (or more) central monitoring entity that performs the registration of the coin data sets and checks and logs the modifications to the coin data set. The overall system (system) is shown in FIG. 13.

[0156] FIG. 2 shows an embodiment of a process flow diagram of a method 300 according to the invention in a terminal. After an optional step 302 and a possibly upstream step 301, a coin data set is present at the terminal.

[0157] Thereby, an electronic coin data set is requested in the optional step 301—for example at an issuing entity 1—and received in the optional step 302 from a terminal, from the issuing entity or from a payment system. The step 302 could optionally also correspond to a send command from another terminal. Thus, another terminal sends a coin data set to the terminal with the send command and has—for example immediately or at some point—previously received the coin data set itself. Steps 301 and 302 may correspond to steps 101 and 102 of FIGS. 10 and 11, respectively.

[0158] In step 303, the terminal determines, based on a check value of the electronic coin data set, whether that electronic coin data set is to be displayed and/or returned, or used normally. The result of the check in step 303 may be that a step 304, 305 is performed for the coin data set or that—now or later—any action (splitting, merging, switching, transmitting, redeeming, changing) may be (is) performed on the coin data set in step 306. In step 304, the checked coin data set is displayed by the terminal at the payment system. In step 305, the checked coin data set is returned, for example directly or indirectly to the central issuing entity or to a monitoring entity or to the payment system, which in turn return the coin data set (to the central issuing entity). The determining (or checking) 303 is performed before a use of the coin data set, in particular at least once for each coin data set received and/or before each use. The possible process flow 300 may comprise only one of or both of steps 304, 305. Accordingly, only one or both of steps 304, 305 are checked to be performed in step 303.

[0159] Displaying in step 304 may be understood as reporting the coin data set to the monitoring entity (for the terminal). Thus, after a certain number of direct transfers of the coin data set, automatic registration of the coin data set in the payment system occurs, thus registration is systematically enforced. It should be noted that the terminal can be anonymous, pseudonymous or identity-known to the monitoring entity when registering. For the checked coin data set, the displaying terminal is assigned as a new owner, preferably—as explained in more detail later—a modified coin data set for the displaying terminal is created from the checked coin data set.

[0160] In embodiments of the system, a return to the central bank is not necessary and may be nonsensical. This is especially true when an issued coin data set in the payment system becomes modified coin data sets rather quickly one after the other. Then the coin data set only needs to be displayed (reported) again in the payment system when a number of direct transfers between terminals is exceeded, so that this coin data set is registered in the payment system (for the terminal). For example, the coin data set will be modified, such as switched, after the display step 304. The coin data set to be switched is then considered to be taken back. Thus, a portion of the normal actions 306 that are permitted when the check result is positive may also serve as the display step 304.

[0161] In the electronic coin data set, a check value is presently maintained as a data element. This check value is incremented each time this coin data set is transmitted directly between terminals. In the payment system, a counter value can also be maintained or determined that incorporates the check value, for example as the sum of the previous (registered) counter value and the check value, to determine whether the coin data set is to be returned. Each action on the coin data set increments this counter value. Different action types weight the counter value differently, so that, for example, a direct transfer of the coin data set has a higher weight than a modification (splitting, combining). In this way, the lifetime and the actions it has in a coin data set are evaluated and criteria for its return are defined according to the actions it has. The check value and also the counter value represent the life cycle of the coin data set, based on which a decision is then made about its return.

[0162] FIG. 3 shows an embodiment example 330 of a further development of the process flow diagram shown in FIG. 2. In FIG. 3, step 303 of the method of FIG. 2 is shown in more detail with two sub-steps 307, 308. For this purpose, a coin data set has two check values. For a coin data set, i.e., for example, after the receive step 302 or the send command, it is determined 307 based on a first check value of the coin data set whether the coin data set must be displayed in the payment system, i.e., whether the coin data set is reported to force registration in the payment system. In particular, in step 307, the number of direct transfers is checked and, if a threshold value is exceeded, display to the payment system is forced in accordance with step 304.

[0163] A second check value in the coin data set is used in step 308 to determine whether to return the coin data set to the central issuing entity. The second check value is action invariant and continues unchanged during actions of the coin data set. For example, this second check value is a return date. This return date is integrated as a data element into the coin data set by the issuing entity during the creation of the coin data set. If the check in step 308 detects that the return date has been reached or exceeded, the coin data set is returned to the issuing entity by the terminal.

[0164] The second check value may be an issuance date, for example. This issuance date is integrated as a data element into the coin data set by the issuing entity during the generation of the coin data set. If it is detected during the check in step 308 that the

[0165] issuance date is before a predefined reference issuance date, for example a fixed period of time, such as a year or a month, the coin data set is returned by the terminal to the issuing entity.

[0166] The second check value may be an identification value, for example. The identification value is not coin data set specific and only allows to infer a group of coin data sets. This identification value is integrated as a data element into the coin data set by the issuing entity during the generation of the coin data set. If the check in step 308 detects that the identification value matches a predefined identification value, the coin data set is returned by the terminal to the issuing entity.

[0167] The second check value may be, for example, a registration date of the electronic coin data set, i.e., a date when the coin data set was last registered in the payment system. This registration date is integrated into the coin data set as a data element when the coin data set is registered in the payment system. If the check in step 308 detects that the registration date is before a fixed period of time, for example one year or one month before the current date, the coin data set is returned by the terminal to the issuing entity.

[0168] Thus, the terminal knows the threshold value(s) for the second check value for the check in step 308. If the check in step 308 indicates that there is no need to return the coin data set, an action is initiated on the coin data set in step 308, or normal use with the coin data set is permitted.

[0169] In FIG. 4, another embodiment example 340 of a further development of the process flow diagram shown in FIG. 2 is shown. FIG. 3 also shows in more detail the step 303 of the method of FIG. 2. The methods of FIGS. 3 and 4 can be combined with each other. In FIG. 4, in step 309, a check value (for example, the first check value and/or the second check value of FIG. 3) is compared with a predefined threshold value.

[0170] If the check value is less than the threshold value, in step 306 the (planned) action is performed on/with the coin data set.

[0171] If the check value is greater than (the threshold value) or equal to the threshold value, a check is made in step 310 to see if another coin data set is present in the terminal. If another coin data set is present in the terminal, for example in a data storage to which the terminal has access, then the (checked) coin data set is blocked in step 311.

[0172] Blocking in this context means, in particular, that the coin data set is not passed on to another terminal. For this purpose, the coin data set is transferred to a secure data storage, for example, to which only a return process or a display process of the terminal has access. The coin data set can no longer be used for actions when blocked. It must be returned to the issuing entity or displayed to the payment system (mandatory registration). The further (other) coin data set is a coin data set of the payment system and generated by the same issuing entity. The checking in step 310 can be performed as a function of a monetary amount, such that the monetary amount of all available coin data sets must be less than the amount to be paid (i.e., the monetary amount of the coin data set to be checked). This step 310 allows, for example, payment operations to be performed even though the coin data set already meets the criteria for a return or display, to make the method user-friendly and suitable for everyday use.

[0173] In an alternative embodiment of the method 340 of FIG. 4, shown in dashed lines, after detecting that the check value is greater than or equal to the threshold value (step 309), a second check is performed at step 312 comparing the check value to a blocking threshold value. In any case, if the check value is greater than or equal to the blocking threshold value, the coin data set is blocked in step 311. This blocking occurs regardless of the presence of other (different) coin data sets (step 310). The method 340 then uses two different threshold values for the same check value (threshold value is not equal to blocking threshold value). An action with the coin data set is only possible when the threshold value is exceeded when no other (further) coin data set is available in the terminal. If the check value also exceeds a blocking threshold value (second threshold value), an action with the coin data set, but in particular the direct transmission of the coin data set, is blocked in order to guarantee a minimum level of security. The blocking threshold value can be a multiple of the threshold value in order not to block the terminal prematurely. For example, the threshold value of the check value is a number of 10 or 5 or 3 direct transmissions of the coin data set. The blocking threshold value is, for example, 30 or 15 or 10 direct transmissions of the coin data set.

[0174] In FIG. 5, an embodiment example of a process flow diagram of a method 200 according to the invention in a payment system is shown. Here, a coin data set 201 is displayed by a terminal in the payment system. The displaying is performed, for example, by a method 300, 330, 340 shown in FIG. 2 to FIG. 4. In step 202, the payment system, in particular the monitoring entity of the payment system, checks a check value. For this purpose, the check value has been provided to the payment system. Alternatively, a counter value in the payment system is checked using the check value. Alternatively, the display of a coin data set without transmitting the check value, in particular when the displaying across the payment system means a check value has a certain minimum value.

[0175] In one embodiment of the method, the payment system also stores the check value (second check value, see FIG. 3). In the payment system, a check for time, for example, when the check value is a date value, or a check for a threshold value, when the check value is an identification value, is then performed in step 202. The check in step 202 can be based on lookup tables, LUT, from the issuing entity, or a time lapse.

[0176] The result of the check results in either a return of the coin data set 203 to the issuing entity or, alternatively, a modification of the coin data set by the payment system. The return in step 203 may also be a request to the displaying terminal to return the coin data set to the issuing entity. Alternatively, the payment system requests the return by the terminal. In step 204, as a result of the return, a new coin data set having an identical monetary amount to the returned coin data set is then generated and provided by the issuing entity. Alternatively, the monetary amount of the returned coin data set is credited as book money to an account of the subscriber (terminal owner).

[0177] For example, a counter value is determined based on the first check value p.sub.i1. Different action types can be weighted differently. For example, the direct forwarding action type is weighted by a constant A. The constant A may be highest because this action type represents the greatest uncertainty for payment system 2. Indirect forwarding (i.e., forwarding that are backed up with a switch command), for example, are weighted by a constant B, wherein A is greater than B. Other action types (splitting, merging, etc.) are weighted with a low weight C, since the uncertainty for the payment system is the lowest. In particular, the criterion of weight for an action type is the security that this action type brings, wherein the weight is inversely proportional to the security.

[0178] When the action is a split, an increased value is adopted for all split coin data sets after checking the check value or counter value. When the action is a merging, a new check value is determined considering all old check values.

[0179] FIG. 6 shows an embodiment example of a payment system with terminals M1 and M2. The terminals M1 and M2 may be apparatuses.

[0180] In this case, an electronic coin data set C.sub.i is generated in an issuing entity 1, for example a central bank. A masked electronic coin data set Z.sub.i, is generated for the electronic coin data set C.sub.i, provided with an obfuscation amount and registered in an “obfuscated electronic data set ledger” as a payment system 2. In the context of the present invention, a ledger is understood to be a list, a directory, preferably a database structure. The electronic coin data set C.sub.i is issued to a first terminal M1.

[0181] For example, a true random number has been generated as an obfuscation amount n for this purpose. The obfuscation amount r.sub.i is associated with a monetary amount v.sub.i. The i-th electronic coin data set C.sub.i is also assigned a first check value p.sub.i1 described above and a second check value p.sub.i2. Accordingly, an i-th electronic coin data set according to the invention could be:

C.sub.i={v.sub.i; r.sub.i}, p.sub.i1, p.sub.i2   (1)

[0182] A valid electronic coin data set can be used for payment. The owner of the two values v.sub.i and r.sub.i is therefore in possession of the digital money. However, the digital money is defined by a pair consisting of a valid electronic coin data set and a corresponding masked electronic coin data set Z.sub.i. A masked electronic coin data set Z.sub.i is obtained by applying a one-way function f (C.sub.i) according to equation (2):

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

[0183] For example, the one-way function f(C.sub.i) is homomorphic. This function f(C.sub.i) is public, i.e., any system participant can invoke and use this function. This function f(C.sub.i) is defined according to equation (3) or equation (3a), for example:

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

Z.sub.i=r.sub.i G   (3a)

wherein 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 other basis is unknown. For example, G (equation (3), (3a)) as well as H (equation (3)) are each a generator point of an elliptic curve encryption, ECC,—that is, private keys of the ECC. In the case of equation (3), these generator points G and H must be chosen in such a way that the connection between G and H is not publicly known, so that if:

G=n H   (4)

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

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

[0185] When equation (3a) is applied, a one-way function is applied to only a portion of the coin data set C, in this case the obfuscation amount r, this partially masked coin data set may also be referred to as R.

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

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

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

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

[0189] Thus, addition operations and subtraction operations can be performed both in the direct transaction layer 3 and in parallel in the monitoring layer 4 without the monitoring layer 4 having knowledge of the electronic coin data sets C.sub.i. The homomorphic property of equation (3) allows monitoring of valid and invalid electronic coin data sets C.sub.i based solely on the masked coin data sets Z.sub.i and to ensure that no new monetary amount v.sub.j has been created.

[0190] Through this homomorphic property, the coin data set C.sub.i can be divided according to equation (1) into:

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

[0191] where:

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

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

[0192] For the corresponding masked coin data sets:

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

[0193] Equation (9) can be used, for example, to easily check a processing step of a split coin data set—for example, according to FIG. 8—without the monitoring entity 2 having knowledge of C.sub.i, C.sub.j, C.sub.k. In particular, the condition of equation (9) is checked to validate split coin data sets C.sub.j and C.sub.k and invalidate coin data set C.sub.i. Such splitting of an electronic coin data set C.sub.i is shown in FIG. 8.

[0194] In the same way, electronic coin data sets can also be assembled (merged), see FIG. 9 and the explanations.

[0195] In addition, it is important to check whether (not allowed) negative monetary amounts are registered. An owner of an electronic coin data set C.sub.i must be able to prove to the monitoring entity 2 that all monetary amounts v.sub.i in a processing operation are within a value range of [0, . . . , n] without informing the monitoring entity 2 about the monetary amounts v.sub.i. These range proofs are also called “range proofs”. Ring signatures (English ring signature) are preferably used as range proofs. For the present embodiment 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Σ=r.sub.j.Math.2.sup.j for 0≤j<n (and optionally r.sub.j ∈ {0; 1})   (9b).

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

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

and

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

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

[0197] In FIG. 6, an electronic coin data set C.sub.i is generated by the issuing entity 1 and made available to the first terminal M1 with its first check value p.sub.i1 and its second check value p.sub.2i. The first check value p.sub.i1 is incremented with each direct transfer between terminals Mx and is initially “0” when generated. The second check value p.sub.i2 is action invariant and is either an issuance date, a return date, or a group ID of the coin data set C.sub.i. Alternatively, the second check value p.sub.i2 is a registration date that is updated by the payment system 2 with each registration.

[0198] In FIG. 6, the electronic coin data set C.sub.i is calculated by the issuing entity 1 using equation (3) or equation (3a) a masked electronic coin data set Z.sub.i is calculated by the issuing entity 1 and this is registered together with at least the second check value p.sub.i2 in the payment system 2 or the monitoring entity 4. The first check value p.sub.i1 can also be registered (not shown). Subsequently, the first terminal M1 transmits the electronic coin data set C.sub.i and the check values p.sub.i1, p.sub.i2 to a second terminal M2 or performs modifications (switching, merging, 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 applying a PKI infrastructure.

[0199] In the second terminal M2, the transmitted electronic coin data set C.sub.i is received as C.sub.i*. With the receipt of the electronic coin data set C.sub.i*, the second terminal M2 is in possession of the digital money represented by the electronic coin data set C.sub.i*. With direct transmission, the check value p.sub.i1 is incremented by the sending terminal M1 (not shown) or the receiving terminal M2. The sending terminal M1 (not shown) or the receiving terminal M2 now checks the check value p.sub.i1 or the two check values p.sub.i1, p.sub.i2, respectively, according to the embodiments of FIG. 2 to FIG. 4. According to the result of the check, the coin data set C.sub.i is displayed or returned or is available in the terminal M2 for further action.

[0200] When both terminals M1, M2 trust each other and the check values are below the defined threshold values or check criteria, no further steps are necessary to terminate the method. However, the terminal M2 does not know whether the electronic coin data set C.sub.i* is actually valid. Moreover, the terminal M1 could still transmit the electronic coin data set C.sub.i to a third terminal (not shown). To prevent this, further preferred steps are provided in the method.

[0201] To check the validity of the received electronic coin data set C.sub.i*, the masked transmitted electronic coin data set Z.sub.i* is calculated in the second terminal M2 using the—public—one-way function from equation (3) or equation (3a). The masked transmitted electronic coin data set Z.sub.i* is then transmitted to and searched for by the monitoring entity 2. If there is a match with a registered and valid masked electronic coin data set, the validity of the received coin data set C.sub.i* is displayed to the second terminal M2 and it is valid that the received electronic coin data set C.sub.i* is equal to the registered electronic coin data set C.sub.i. In one embodiment, the validity check can be used to detect that the received electronic coin data set C.sub.i* is still valid, i.e. that it has not already been used by another processing step or in another transaction and/or has been subject to further modification.

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

[0203] It is valid for the method according to the invention that the sole knowledge of a masked electronic coin data set Z.sub.i does not authorize to issue the digital money. However, the sole knowledge of the electronic coin data set C.sub.i entitles to pay, i.e. to perform a transaction successfully, especially when the coin data set C.sub.i is valid. There is a one-to-one relationship between the electronic coin data sets C.sub.i and the corresponding masked electronic coin data sets Z.sub.i. The masked electronic coin data sets Z.sub.i are registered in the monitoring entity 4 of the payment system 2, for example a public decentralized database. This registration first makes it possible to check the validity of the electronic coin data set, for example whether new monetary amounts have been created (illegally).

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

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

TABLE-US-00001 TABLE 1 Number of operations that can be performed per processing of a coin data set in the terminal or issuing entity; Command or Create Create random Create Create range step signature number masking proof Generate 1 1 1 0 or 1 Return 1 0 1 0 or 1 Split 1 1 3 0 or 1 Merge 1 0 3 1 Switch 1 1 2 1

[0206] Other 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 that imply other operations are also conceivable. Table 1 shows that for each coin data set, each of the processing operations “Create”, “Return”, “Split”, “Merge” and “Switch” can provide different operations “Create signature”; “Create random number”; “Create masking”; “Range check”, wherein each of the processing operation is registered in the monitoring entity 4, where it is appended in invariant form to a list of previous processing operations for masked electronic coin data sets Z.sub.i. The operations of the “create” and “return” processing operations of an electronic coin data set are performed only at secure locations and/or only by selected entities, such as issuing entity 1, while the operations of all other processing operations can be performed on terminals M1 through M3.

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

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

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

TABLE-US-00002 TABLE 2 Number of operations that can be performed per processing of a coin data set in the monitoring entity; Track homomorphic Check validity properties of the Check Check of the masked masked electronic Command signature signature electronic coin Track range coin data sets; i.e. or step of issuer of terminal data set proof add or subtract Generate 1 0 0 0 or 1 0 Return 1 0 1 0 or 1 0 Split 0 1 1 2 or more 1 Merge 0 1 2 or more 1 1 Switch 0 1 1 1 0

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

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

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

[0212] Table 3 shows an overview of the preferred components to be used in each system participant, i.e., the issuing entity 1, a terminal M1 and the monitoring entity 2. The terminal M1 can be used as a wallet for electronic coin data sets C.sub.i (with their check value p.sub.i1 p.sub.i2) i.e. adapted as an electronic wallet, i.e., a data storage of the terminal M1, in which a plurality of coin data sets C.sub.i may be stored, and may be implemented, for example, in the form of an application on a smartphone or IT system of a merchant, commercial bank, or other market participant, and send or receive an electronic coin data set. Thus, the components are implemented as software in the terminal as shown in Table 3. It is assumed that the monitoring entity 2 is based on a DLT and operated by a set of trusted market participants.

[0213] FIG. 7 shows an embodiment example of a payment system 2 (or a monitoring entity 4) of FIG. 6. In FIG. 7, an exemplary database is shown in the form of a table in which the masked electronic coin data sets Z.sub.i and, if applicable, their processing are registered. The monitoring entity 2 is preferably assembled locally remote from the terminals M1 to M3 and is housed, for example, in a server architecture.

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

[0215] The processing operations “create” and “return”, which concern the existence of the monetary amount v.sub.i per se, i.e. imply the creation and destruction of money, require additional authorization by the issuing entity 1 to be registered (i.e. logged) in the monitoring entity 4. The remaining processing operations (splitting, merging, switching) do not require authorization by issuing entity 1 or by the command initiator (=payer, e.g. the first terminal M1).

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

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

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

[0218] Column 27 (R flag) indicates whether a check of range proofs or a range proof was successful, wherein state “1” indicates that a validity check revealed that the range proofs or the range proof are or is traceable, and state “0” indicates that a validity check revealed that the range proofs or the range proof are not or is not traceable, and state “-” indicates that a validity check has not yet been completed, was successful.

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

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

[0221] To detect whether a masked electronic coin data set Z is valid, the monitoring entity 4 searches for the last change that concerns the masked electronic coin data set Z. It is true that the masked electronic coin data set Z is valid if and only if the masked electronic coin data set Z is listed for its last processing in one of the successor columns 23a, 23b and that last processing has the corresponding final marking 25 to 28. It is also true that the masked electronic coin data set Z is valid if and only if the masked electronic coin data set Z is listed for its last processing in one of the predecessor columns 22a, 22b and this last processing has failed, that is, at least one of the corresponding required states of the markings 25 to 28 is set to “0”.

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

[0223] The checks by the monitoring entity 4 to determine whether a processing is final are represented by columns 25 through 28: The state in column 25 shows whether the masked electronic coin data set(s) 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 27 indicates whether the range proofs for the masked electronic coin data set Z were successful 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.

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

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

[0226] For example, one processing is “generating” an electronic coin data set C.sub.i. Generating in the direct transaction layer 3 by the issuing entity 1 includes selecting a monetary amount v.sub.i, creating an obfuscation amount r.sub.i, and generating the check value(s) p.sub.i1 (and p.sub.i2) as described earlier with equation (1) and FIGS. 2 to 4. As shown in FIG. 7, the “generate” processing does not require any entries/markings in columns 22a, 22b, 23b, and 25 to 27. The masked electronic coin data set Z.sub.i is registered in the successor column 23a. This registration is preferably performed before transmitting to a terminal M1 to M3, in particular or already during generation by the issuing entity 1, wherein in both cases equation (3) or equation (3a) must be performed for this purpose. The masked electronic coin data set Z.sub.i is signed by the issuing entity 1 when it is generated, this signature is entered in column 24 to ensure that the electronic coin data set C.sub.i was actually generated by an issuing entity 1, wherein 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 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 monitoring entity 4 trusts that the issuing entity 1 does not issue negative monetary amounts. However, in an alternative embodiment, it can be sent by issuing entity 1 in the create command and checked by monitoring entity 4. In addition, in the monitoring entity, the check value(s) p.sub.i1 (and p.sub.i2) is stored and logged. In addition, as shown in FIG. 5, a counter value may be stored and logged.

[0227] For example, one processing is “return.” Returning, i.e., destroying money (DESTROY), causes the masked electronic coin data set Z.sub.i to become invalid after the issuing entity 1 successfully executes the return command. Thus, one can no longer process the (masked) electronic coin data set to be returned in monitoring layer 4. To avoid confusion, the corresponding (non-masked) electronic coin data sets C.sub.i should be deleted in the direct transaction layer 3. When “returning”, the predecessor column 22a is written to with the electronic coin data set Z.sub.i, but no successor column 23a, 23b is populated. The masked electronic coin data set Z.sub.i shall be checked upon deactivation to see if the signature matches the signature as specified in column 24 to ensure that the electronic coin data set C.sub.i was indeed created by an issuing entity 1, wherein again other means may be used for this check. If the signed Z.sub.i included in the return command can be confirmed as signed by issuing entity 1 or confirmed as validly signed, 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 verification.

[0228] A processing is for example the “splitting”. Splitting, i.e. dividing an electronic coin data set Z.sub.i into a number n, for example 2, of electronic coin data subsets Z.sub.j and Z.sub.k is first performed in the direct transaction layer 3, as still shown in FIGS. 8 and 10, wherein the monetary amounts v.sub.j and the obfuscation amount r.sub.j are generated. v.sub.k and r.sub.k are obtained by equations (7) and (8). In monitoring entity 4, markings 24 to 27 are set, predecessor column 22a is described by electronic coin data set Z.sub.i, successor column 23a is described by Z.sub.j, and successor column 23b is described by Z.sub.k. The status changes required according to columns 24 to 27 are made after the corresponding check by the monitoring entity 4 and document the respective check result. The marking according to column 28 is ignored. Column 24 is used to enter a signature generated by the splitting terminal M1 to M3.

[0229] For example, one processing is “merging”. The merging, i.e., the assembling of two electronic coin data sets Z.sub.i and Z.sub.j to form an electronic coin data set Z.sub.m, is first performed in the direct transaction layer 3, as still shown in FIG. 10, wherein the monetary amount v.sub.m and the obfuscation amount r.sub.m are calculated. In the monitoring entity 2, markings 25 to 27 are set, predecessor column 22a is described by electronic coin data set Z.sub.i, predecessor column 22b is described by Z.sub.j, and successor column 23b is described by Z.sub.m. The markings in columns 25 to 27 require status changes and the monitoring entity 2 performs the appropriate checks. A range proof must be performed to show that no new money has been generated. The marking according to column 28 is ignored. Column 24 is used to enter a signature generated by the connecting terminal M1 to M3.

[0230] For example, one processing is “switching”. Switching is necessary when an electronic coin data set has been transmitted to another terminal Mx and re-issuing by the transmitting terminal (here M1) is to be excluded. When switching, also called “switch”, the electronic coin data set C.sub.k received from the first terminal M1 is exchanged for a new electronic coin data set C.sub.l with the same monetary amount. The new electronic coin data set C.sub.l is generated by the second terminal M2. This switching is necessary to invalidate (make invalid) the electronic coin data set C.sub.k received from the first terminal M1, thus avoiding issuing the same electronic coin data set C.sub.k again. This is because, as long as the electronic coin data set C.sub.k is not switched, and since the first terminal M1 is aware of the electronic coin data set C.sub.k, the first terminal M1 can pass this electronic coin data set C.sub.k to a third terminal M3. The switching is done, for example, by adding a new obfuscation amount r.sub.add to the obfuscation amount r.sub.k of the received electronic coin data set C.sub.k, thereby obtaining an obfuscation amount r.sub.l that only the second terminal M2 knows. This can also be done in the monitoring entity 4. To 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 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. That is, only one obfuscation amount r.sub.add has been generated and the monetary amount of Z.sub.l is equal to the monetary amount of Z.sub.k, i.e., Z.sub.l=Z.sub.k+r.sub.add*G. This is done by generating a signature with the public key Z.sub.l−Z.sub.k=r.sub.add*G. This signature is used in monitoring layer 4 to confirm the validity of the electronic coin data set to be switched.

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

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

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

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

[0234] When splitting, the check values p.sub.i1, p.sub.i2 of the coin data set to be split are adopted unchanged into the split coin data sets.

[0235] Then a coin data subset, in this case C.sub.k, together with the check values p.sub.i1, p.sub.i2, is transmitted from the first terminal M1 to the second terminal M2. To prevent double issuance, a switching operation is useful to exchange the electronic coin data set C.sub.k received from the first terminal M1 for a new electronic coin data set C.sub.l with the same monetary amount. The new electronic coin data set C.sub.l is generated by the second terminal M2. In this process, the monetary amount of the coin data set C.sub.l is adopted and not changed, see equation (11).

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

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

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

R.sub.add=r.sub.add 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)

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

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

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

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

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

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

[0238] For masking using equation (3a), a signature is generated over the monetary amount v.sub.k, the obfuscation amount r.sub.k, and the masked coin data set Z (also referred to as R). Thus, the signature can be validated by recalculating the masking in the monitoring entity 4 to be able to prove the authenticity and existence/possession of the coin data set C.

[0239] FIG. 9 shows an embodiment example of a payment system according to the invention for merging (also called combining) electronic coin data sets. Here, the two coin data sets C.sub.i and C.sub.j are obtained in the second terminal M2. Each coin data set C.sub.i and C.sub.j thereby comprises the check values p.sub.i1, p.sub.i2, respectively. Following the splitting according to FIG. 8, a new coin data set Z.sub.m is now obtained by adding both the monetary amounts and the obfuscation amount of the two coin data sets C.sub.i and C.sub.j. Then, the obtained coin data set C.sub.m to be merged is masked using equation (3) or equation (3a), and the masked coin data set Z.sub.m is registered in the monitoring entity. Then, when “merging”, the signature of the second terminal M2 is registered, since it has received the coin data sets C.sub.i and C.sub.j.

[0240] For masking using equation (3a), a first signature can be generated using the monetary amount v.sub.i, the obfuscation amount r.sub.i, and the masked coin data set Z.sub.i, and a second signature can be generated using the monetary amount v.sub.j, the obfuscation amount r.sub.j, and the masked coin data set Z.sub.j. Both signatures can be validated by recalculating the masking in the monitoring entity 4, respectively, to be able to prove the authenticity and existence/possession of the coin data set C. The first signature may also be combined with the second signature to form a common signature.

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

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

[0243] In the following, FIGS. 10 and 11 are described together to explain the actions of “creating”, “transmitting”, “switching”, “merging” and “splitting”. In optional steps 101 and 102, a coin data set is requested and provided on the part of the issuing entity 1 to the first terminal M1 after the electronic coin data set is created. A masked electronic coin data set is sent to the monitoring entity 4. In step 103, masking of the obtained electronic coin data set C.sub.i is performed according to equation (3). Then, in step 104, the masked electronic coin data set Z.sub.i is registered in the monitoring entity 4. Optionally, the terminal M1 can switch the received electronic coin data set. In step 105, the coin data set C.sub.i is transmitted in the direct transaction layer 3 to the second terminal M2. In optional steps 106 and 107, a validity check with prior masking is performed, in which, in the good case, the monitoring entity 2 confirms the validity of the coin data set Z.sub.i or C.sub.i. In addition, the check value is checked according to the method 300 of FIGS. 2 to 4 to determine whether the coin data set is to be displayed to the monitoring entity 4 when a number of direct transfers of the coin data set has already been exceeded. In addition, it can be checked whether the coin data set is to be returned.

[0244] In step 108, switching of a received coin data set C.sub.k (of course, the received coin data set C.sub.i could also be switched) to a new coin data set C.sub.l is performed, thereby invalidating the coin data set C.sub.k and preventing double spending. To do this, the monetary amount v.sub.k of the transmitted coin data set C.sub.k is used as the “new” monetary amount v.sub.l. In addition, as already explained with equations (14) to (17), the obfuscation amount r.sub.l is created. The additional obfuscation amount r.sub.add is used to prove that no new money (in the form of a higher monetary amount) was generated by the second terminal M2. Then the masked coin data set Z.sub.l to be switched is sent to the monitoring entity 2 and the switching from C.sub.k to C.sub.l is instructed.

[0245] In step 108′, the corresponding check is made in monitoring entity 2, with Z.sub.k being entered in column 22a according to the table in FIG. 2 and the coin data set to be switched Z.sub.l being entered in column 23b. A check is then made in monitoring entity 2 to determine whether Z.sub.k is (still) valid, i.e. whether the last processing of Z.sub.k is entered in one of the columns 23a/b (as proof that Z.sub.k has not been further divided or returned or merged) and whether a check for the last processing has failed. In addition, Z.sub.l is entered in column 23b and the markings in columns 25, 26, 27 are initially set to “0”. Now a check is made whether Z.sub.l is valid, wherein the check according to equations (16) and (17) can be used. In the good case, the marking in column 25 is set to “1”, otherwise to “0”. Now a check is made, the calculation according to equation (10) shows that Z.sub.k and Z.sub.l are valid and accordingly the marking in column 26 is set. Furthermore it is checked whether the ranges are conclusive, then the marking is set in column 27. When all checks have been successful, and this has been recorded accordingly invariantly in the monitoring entity 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.l is valid. The first check value of the coin data set C.sub.l is initialized by the payment system 2 with “0”, since no direct transfer has taken place yet.

[0246] In step 109, two coin data sets C.sub.k and C.sub.i are merged to a new coin data set C.sub.m, which invalidates the coin data sets C.sub.k, C.sub.i and prevents double spending. To do this, the monetary amount v.sub.m is formed from the two monetary amounts v.sub.k and v.sub.i. For this purpose, the obfuscation amount r.sub.m is formed from the two obfuscation amounts r.sub.k and r.sub.i. Moreover, using equation (3), the masked coin data set Z.sub.m to be merged is obtained and it is sent (together with other information) to the monitoring entity 2 and 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 entity 2.

[0247] In step 109′, the corresponding check is performed in the monitoring entity 2. Here, Z.sub.m is entered in column 23b according to the table in FIG. 2, which is also equal to a re-writing. A check is then made in the monitoring entity 2 as to whether Z.sub.k and Z.sub.i are (still) valid, i.e. whether the last processing of Z.sub.k or Z.sub.i is entered in one of the columns 23a/b (as proof that Z.sub.k and Z.sup.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 is made whether Z.sub.m is valid, wherein the check according to equations (16) and (17) can be used. In the good case the mark in column 25 is set to “1”, otherwise to “0”. Now a check is made, the calculation according to equation (10) shows that Z.sub.i plus Z.sub.k equals Z.sub.m and accordingly the marking in column 26 is set. Furthermore it is checked whether the ranges are conclusive, then the marking is set in column 27.

[0248] In step 110, a split of a coin data set C.sub.i into two coin data subsets C.sub.k and C.sub.j is performed, whereby the coin data set C.sub.i is invalidated and the two split coin data subsets C.sub.k and C.sub.j are to be made valid. In a split, the monetary amount v.sub.i is split into monetary partial amounts v.sub.k and v.sub.j. For this purpose, the obfuscation amount r.sub.i is divided into the two obfuscation amounts r.sub.k and r.sub.j. In addition, by means of equation (3), the masked coin data subsets Z.sub.k and Z.sub.j are obtained and sent to the monitoring entity 2 with further information, such as the range proofs (zero-knowledge-proofs), and the splitting is requested as processing.

[0249] In step 110′, the corresponding check is performed in monitoring entity 2, with Z.sub.j and Z.sub.k being entered in columns 23a/b according to the table in FIG. 2. A check is then made in monitoring entity 2 as to whether Z.sub.i is (still) valid, i.e. whether the last processing of Z.sub.i is entered in one of the columns 23a/b (as proof that Z.sub.i has not been further divided 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 is made whether Z.sub.j and Z.sub.k are valid, wherein the check according to equations (16) and (17) can be used. In the good case, the marking in column 25 is set to “1”. Now a check is made, the calculation according to equation (10) shows that Z.sub.i is equal to Z.sub.k plus Z.sub.j and accordingly the marking in column 26 is set. Furthermore, it is checked whether the ranges are conclusive, then the marking is set in column 27.

[0250] FIG. 12 shows an embodiment example of an apparatus M1 according to the invention. The apparatus M1 can store electronic coin data sets C.sub.i in a data storage 10, 10′. In this regard, the electronic coin data sets C.sub.i may reside on the data storage 10 of the apparatus M1 or may be available in an external data storage 10′. When using an external data storage 10′, the electronic coin data sets C.sub.i could be stored in an online storage, for example a data storage 10′ of a digital wallet provider. Additionally, private data storage, for example a network attached storage, NAS on a private network could also be used.

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

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

[0253] Moreover, the interface 12 or another interface (not shown) of the apparatus M1 is arranged to interact with the monitoring entity 2 as described in FIGS. 1 to 6. The apparatus M1 is preferably online capable for this purpose. Furthermore, the apparatus M1 may also have an interface for receiving electronic coin data sets. This interface is arranged to receive visually presented coin data sets, for example by means of a capture module such as a camera or scanner, or digitally presented coin data sets, received via NFC, Bluetooth, TCP, IP, UDP, HTTP or coin data sets presented by means of an application. The apparatus M1 also comprises a computing unit 13 capable of performing the coin data set masking method and coin data set processing operations described above.

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

[0255] In the simplest case, in the terminal M1, all coin data sets C.sub.i are automatically merged into one coin data set upon receipt (see merging-processing or join-step). That is, as soon as a new electronic coin data set is received, a merge or switch command is sent to the monitoring entity 2. The apparatus M1 can also prepare electronic coin data sets in algorithmically defined denominations and hold them in the data storage 10, 10′ so that a payment process is possible even without a data connection to the monitoring entity 2.

[0256] FIG. 13 shows an overall system for better understanding. The overall system according to the invention comprises an issuing entity (central bank) 1a. In addition, further issuing entities 1b, 1c can be provided, which issue electronic coin data sets in a different currency, for example. In addition, at least one payment system 2 is shown in which at least one monitoring entity 4 is provided as a central manager of the payment system. In addition, a plurality of participants, shown as terminals Mx, is provided. For example, the payment system 2 comprises commercial banks and one (or more) central monitoring entity(ies) 4 that performs the registration of the coin data sets C.sub.i and checks and logs the modifications to the coin data set C.sub.i.

[0257] Terminals M1 to M6 can directly exchange coin data sets C.sub.i and the corresponding check values p.sub.i1, p.sub.i2 in the direct transaction layer 3. For example, terminal M5 transmits a coin data set to terminal M4. For example, terminal M4 transmits the coin data set to terminal M3. For example, terminal M6 transmits a coin data set to terminal M1. In each sending terminal Mx or each receiving terminal Mx, the check value of the coin data set to be sent or received is used to check whether the coin data set is displayed at the payment system and/or whether the coin data set is to be returned to the issuing entity la, see FIGS. 2 to 4. For example, the payment system 2 checks whether the coin data set is to be returned or not based on the check value or a counter value derived from the check value for each coin data set, see FIG. 5 for more details.

[0258] When registration (switching) is to be performed as an action in the monitoring entity 4, the check value incremented in case of direct transmission is transferred from the coin data set to be switched to the switched coin data set is not adopted, but reset. Registered transfer between terminals is the rule, while direct transfer, such as between terminals M4 and M5, is more likely not. FIG. 13 shows as another example that a coin data set is transmitted from terminal M1 to terminal M2 via payment system 2 (indirect transfer). Also in this case, the payment system checks the counter value.

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

REFERENCE LIST

[0260] 1, 1a-c issuing entity or bank [0261] 2 payment system [0262] 21 command entry [0263] 22a, b entry of an electronic coin data set to be processed (predecessor) [0264] 23a, b entry of a processed electronic coin data set (successor) [0265] 24 Signature entry [0266] 25 marking of validity check [0267] 26 marking of calculation check [0268] 27 marking of the range proof check [0269] 28 marking of signature check [0270] 3 direct transaction layer [0271] 4, 4′, 4″ monitoring layer, monitoring entity [0272] 5 Application common purse [0273] 10, 10′ data storage [0274] 11 Display [0275] 12 interface [0276] 13 computing unit [0277] 14 vault module [0278] 15 location detection module [0279] Mx x-th terminal [0280] C.sub.i electronic coin data set [0281] C.sub.j, C.sub.k split electronic coin data subset, [0282] C.sub.j_k k-th split electronic coin data subset in case of symmetrical splitting [0283] C.sub.l electronic coin data set to be switched [0284] C.sub.m electronic coin data set to be merged [0285] Z.sub.i masked electronic coin data set [0286] Z.sub.j, Z.sub.k masked split electronic coin data subset [0287] Z.sub.l masked electronic coin data set to be switched [0288] Z.sub.m masked coin electronic data set to be merged [0289] S signed masked electronic coin data set [0290] p.sub.i1 first check value [0291] p.sub.i2 second check value [0292] v.sub.i monetary amount [0293] v.sub.j, v.sub.j split monetary amount [0294] v.sub.l monetary amount of a switched electr. coin data set/an electr. coin data set to be switched [0295] v.sub.m monetary amount of a merged electr. coin data set/an electr. coin data set to be merged [0296] n number of symmetrically split coin data subsets [0297] r.sub.i obfuscation amount, random number [0298] r.sub.j, r.sub.j obfuscation amount of a split electronic coin data set [0299] r.sub.m obfuscation amount of a merged electronic coin data set/an electronic coin data set to be merged [0300] C.sub.i* transmitted electronic coin data set [0301] C.sub.j*, C.sub.k* transmitted split electronic coin data subset, [0302] Z.sub.i* masked transmitted electronic coin data set [0303] Z.sub.j*, Z.sub.k* masked transmitted split electronic coin data set [0304] f(C) homomorphic one-way function [0305] [Z.sub.i]Sig(PK.sub.1) signature of issuing entity [0306] 301-312 method steps in the terminal according to an embodiment example [0307] 201-204 method steps in the payment system according to an embodiment example