METHOD FOR DIRECTLY TRANSMITTING ELECTRONIC COIN DATASETS BETWEEN TERMINALS, PAYMENT SYSTEM, PROTECTION SYSTEM AND MONITORING ENTITY

Abstract

The invention relates to a payment system and a method for directly transmitting electronic coin datasets between terminals, wherein a monitoring entity registers anonymous masked electronic coin datasets. The method has the following steps in a first terminal; receiving an electronic coin dataset, said at least one electronic coin dataset having a monetary value and a concealment value; masking a modified electronic coin dataset or the received electronic coin dataset by applying a one-way function to the electronic coin dataset in order to obtain a masked electronic coin dataset; linking the masked electronic coin dataset to a pseudonym in order to obtain a pseudonymized masked electronic coin dataset, and transmitting the pseudonymized masked electronic coin dataset to the monitoring entity.

Claims

1.-14. (canceled)

15. A method for directly transmitting electronic coin datasets between terminals, wherein a monitoring entity registers anonymous masked electronic coin datasets, comprising the following steps in a first terminal; receiving an electronic coin dataset, the at least one electronic coin dataset having a monetary value and a concealment value; masking a modified electronic coin dataset or the received electronic coin dataset by applying a one-way function to the electronic coin dataset, to its concealment value in order to obtain a masked electronic coin dataset; linking the masked electronic coin dataset to a pseudonym in order to obtain a pseudonymized masked electronic coin dataset; and sending the pseudonymized masked electronic coin dataset to the monitoring entity.

16. The method according to claim 15, wherein the number of range confirmations or range proofs that the monitoring entity requests from the first terminal is reduced by the sending of the pseudonymized masked electronic coin dataset instead of an anonymous masked electronic coin dataset.

17. The method according to claim 15, comprising the further steps in the first terminal: receiving a request for a sum range confirmation or a sum range proof from the monitoring entity; and sending the requested sum range confirmation or the requested sum range proof to the monitoring entity.

18. The method according to claim 15, comprising the further steps in the first terminal: creating an unsolicited sum range confirmation or an unsolicited sum range proof, and sending the unsolicited sum range confirmation or the requested sum range proof to the monitoring entity.

19. The method according to claim 15, wherein the first terminal forms a sum of monetary values of multiple electronic coin datasets, and wherein the first terminal confirms with the sum range confirmation that the formed sum is in a range.

20. The method according to claim 15, wherein the first terminal creates a sum range proof for multiple electronic coin datasets which can be checked by the monitoring entity.

21. The method according to claim 19, wherein the multiple electronic coin datasets comprise only selected electronic coin datasets, including only electronic coin datasets of sent pseudonymized masked electronic coin datasets, or only electronic coin datasets of sent anonymous masked electronic coin datasets or sent pseudonymized masked electronic coin datasets, or only electronic coin datasets of sent anonymous masked electronic coin datasets, sent pseudonymized masked electronic coin datasets and/or masked electronic coin datasets not sent to the monitoring entity.

22. The method according to claim 19, wherein the multiple electronic coin datasets are selected according to at least one of the following criteria: a preselected time period, and/or a list in the first terminal or in the monitoring entity.

23. The method according to claim 15, wherein the monitoring entity requests range confirmations or range proofs from terminals in the context of a sum check, and: applies a first sum check mode for anonymous masked electronic coin datasets, applies a second sum check mode for pseudonymous masked electronic coin datasets.

24. The method according to claim 15, wherein the monitoring entity checks a range proof for the value for each received modified coin dataset.

25. The method according to claim 15, wherein the monitoring entity regularly or quasi-randomly requests range confirmations or range proofs from terminals, and/or only after a number of coin data datasets received for a pseudonym requests a range confirmation or a range verification from the terminal device, wherein the number is dependent on the terminal type and/or the coin value range.

26. A terminal configured for directly transmitting electronic coin datasets between terminals having a computing unit configured for carrying out the terminal steps of the method according to claim 15.

27. A monitoring entity configured for directly transmitting electronic coin datasets between terminals having a computing unit configured for carrying out the method according to claim 15, which in particular registers anonymous masked electronic coin datasets and registers pseudonymously sent masked electronic coin datasets.

28. A payment system for exchanging monetary values, the payment system comprising: a monitoring layer with a database in which anonymous masked electronic coin datasets are stored; and a direct transaction layer, with at least two terminals, in which the method according to claim 15 may be performed.

Description

BRIEF SUMMARY OF THE FIGURES

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

[0140] The figures show:

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

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

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

[0144] FIG. 4 an embodiment of a payment system according to the invention for connecting electronic coin datasets;

[0145] FIG. 5 an embodiment example of a method flow chart of a method according to the invention and corresponding processing steps of a coin dataset;

[0146] FIG. 6 an embodiment example of a method flow chart of a method according to the invention and corresponding processing steps of a coin dataset:

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

[0148] FIG. 8 an embodiment example of a device according to the invention:

[0149] FIG. 9 an embodiment example of a sequence of payment processes according to the invention with monitoring of the monetary values per terminal; and

[0150] FIG. 10 an embodiment example of a sequence of a range confirmation according to the invention.

FIGURE DESCRIPTION

[0151] FIG. 1 shows an embodiment example of a payment system with terminals M1 and M2, an issuer entity 1 and a monitoring entity 2. The terminals M1 and M2 can also be devices.

[0152] In the issuer entity 1, for example a central bank, an electronic coin dataset C.sub.i is generated. A masked electronic coin dataset Z.sub.i is generated for the electronic coin dataset C.sub.i, which is registered in the monitoring entity 2. The monitoring entity 2 includes a register 210 in which the valid masked electronic coin dataset Z.sub.i is stored. The electronic coin dataset C.sub.i represents a monetary value v.sub.i). The electronic coin dataset C.sub.i is issued to a first terminal M1. Electronic coin datasets C.sub.i, preferably for which a masked electronic coin dataset Z.sub.i is registered, can be used for payment. The masked electronic coin dataset Z.sub.i can also be referred to as a value-masked electronic coin dataset since the monetary value v.sub.i is unknown to the monitoring entity 2 (and remains unknown in the further course). A recipient, for example a further terminal, of the electronic coin dataset C.sub.i can check its validity with the help of the monitoring entity 2. The monitoring entity 2 can confirm the validity of the electronic coin dataset C.sub.i using the masked electronic coin dataset Z.sub.i. For the monitoring entity 2, the masked electronic coin dataset Z.sub.i is an anonymous electronic coin dataset, in particular as it does not know an owner of the associated electronic coin dataset C.sub.i.

[0153] The first terminal M1 transmits the electronic coin dataset C.sub.i to a second terminal M2. The receiving second terminal M2 calculates a masked electronic coin dataset Z.sub.i* for the received coin dataset C.sub.1* (or a so-called modified coin dataset derived from it), the validity of which the monitoring entity 2 can confirm on the basis of the registered masked electronic coin datasets.

[0154] FIG. 1 shows that the second terminal M2 sends masked electronic coin datasets Z.sub.i* anonymously to the monitoring entity 2 in an anonymous mode M2a. i.e. in particular only sends the masked electronic coin dataset Z.sub.i*. The monitoring entity 2 processes the anonymously sent masked electronic coin dataset Z.sub.i* in an anonymous mode 2a, in which, for example, the second terminal M2 is only confirmed that the sent masked electronic coin dataset Z.sub.i* is valid.

[0155] The monitoring entity 2 stores in the register 210 anonymous (value)-masked coin datasets Z.sub.i associated with newly generated electronic coin datasets C.sub.i of the issuer entity 1 or modified electronic coin datasets of the terminals.

[0156] FIG. 1 further shows that the second terminal M2 can now, according to the present solution, send masked electronic coin datasets S.sub.i* to the monitoring entity 2 also in a pseudonymized mode M2p. For example, the second terminal M2 links the masked electronic coin dataset Z.sub.i* to a pseudonym P.sub.M2 and sends the pseudonymized masked electronic coin dataset S.sub.i* to the monitoring entity 2. The second terminal M2 could generate a pseudonymized masked electronic coin dataset S.sub.i* by appending the pseudonym P.sub.M2 to the masked electronic coin dataset Z.sub.i*. In the embodiment shown, the second terminal M2 creates a signature over the masked electronic coin dataset Z.sub.i* and adds the signature to the coin dataset Z.sub.i*. For example, the public key of the signature key pair can serve as the pseudonym P.sub.M2. Alternatively, however, a terminal number, such as IMEI, IMSI . . . , or a number derived from it can also be used as pseudonym P.sub.M2.

[0157] The monitoring entity 2 processes the pseudonymously transmitted masked electronic coin dataset S.sub.i* in a pseudonymous mode 2p, in which it is also confirmed to the second terminal M2 that the transmitted masked electronic coin dataset Z.sub.i* is valid. However, the association of the masked electronic coin dataset Z.sub.i with the pseudonym P.sub.M2 is additionally stored in a data structure 220 of the monitoring entity 2. As will become clear in the further embodiments, the data structure 220 may be used as a register for masked electronic coin datasets Z.sub.i yet to be checked. In pseudonymous mode 2p, the monitoring entity 2 in particular postpones or skips a checking step (more frequently or always) performed in anonymous mode 2a. The checking step preferably checks—further in ignorance of the monetary value v.sub.i—whether the monetary value v.sub.i of the masked electronic coin dataset Z.sub.i is in an range.

[0158] Further details of a preferred embodiment are now described for FIG. 1. The aspects described subsequently for FIGS. 2 to 7 are based at least in part on details of this embodiment. The more complex pseudonymous mode 2p or M2p is primarily described there, since the simpler anonymous mode 2a or M2a runs without a pseudonym (or signature). In contrast, FIGS. 9 and 10 describe embodiments that can only optionally be combined with the details of the other embodiments.

[0159] The monitoring entity may be an “concealed electronic dataset ledger”. In the context of the present invention, a ledger is understood to be a list, a directory, preferably a database structure.

[0160] For example, a true random number has been generated as an concealment value r.sub.i. This concealment value r.sub.i is linked to a monetary value v.sub.i and then forms an i-th electronic coin dataset according to the invention:

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

[0161] A valid electronic coin dataset can be used for payment. The possessor of the two values v.sub.i and r.sub.i is therefore in possession of the digital money. The digital money is represented in the overall system by a pair consisting of a valid electronic coin dataset C.sub.i and a corresponding masked electronic coin dataset Z.sub.i. A masked electronic coin dataset Z.sub.i is obtained by applying a one-way function f(S.sub.i) according to equation (2):

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

[0162] For example, the one-way function f(C.sub.i) is homomorphic. The 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.i.Math.H+r.sub.i.Math.G (3)

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

where H and G are generator points of a group 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 cipher, ECC, —that is, private keys of the ECC. In the case of equation (3), these generator points G and H must be chosen in such a way that the context of G and H is not publicly known, so that if:

G=n.Math.H (4)

the linking n must be practically undetectable in order to prevent the monetary value v.sub.i from being manipulated and yet a valid Z.sub.i could be calculated. Equation (3) is a “Pederson commitment for ECC”, which ensures that the monetary value 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 dataset Z.sub.i is sent (disclosed) to the public and remote monitoring entity 2.

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

[0164] When equation (3a) is applied, a one-way function is applied only to a part of the coin dataset C, in this case the concealment value r.sub.i this partially masked coin dataset can also be denoted as R.

[0165] Equation (3), through the entropy of the concealment value r.sub.i, allows a cryptographically strong Z.sub.i to be obtained even with a smaller range of values for monetary values v.sub.i. Thus, a simple brute-force attack by merely estimating monetary values v.sub.i is practically impossible.

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

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

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

[0168] 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 datasets C.sub.i. The homomorphic property of equation (3) allows monitoring of valid and invalid electronic coin datasets C.sub.i to be performed on the basis of the masked coin datasets Z.sub.i alone and to ensure that no new monetary value v.sub.i has been created.

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

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

wherein:

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

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

[0170] For the corresponding masked coin datasets:

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

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

[0172] In the same way, electronic coin datasets can also be merged (connected), see FIG. 4 and the explanations thereto.

[0173] In the present case, the coin dataset is signed after masking in order to link a pseudonym of a terminal with the masked coin dataset. The signing is done in particular with a private signature key SK of a PKI key of the respective terminal M.sub.x. The public part of the signature key can serve as the pseudonym P.sub.M2. This signature is added to the masked coin dataset Z.sub.i, see equation (3a):

S.sub.i=Z.sub.i; [Z.sub.i]sig(SK.sub.Mx) (3a)

[0174] In addition, it is necessary to check whether non-allowed high or negative monetary values are registered. A possessor of an electronic coin dataset C.sub.i shall be able to prove to the monitoring entity 2 that all monetary values v.sub.i in a processing operation are within a value range [0, . . . , n] without informing the monitoring entity 2 of the monetary values v.sub.i. These range proofs are also called “Range-Proofs”. Ring signatures are preferably used as range proofs. For the present embodiment example, both the monetary value v and the concealment value r of an electronic coin dataset C are resolved in bit representation. It holds:

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

as well as

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

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

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

and

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

whereby in one embodiment it can be provided that a ring signature is only performed for certain bits.

[0176] The monitoring entity 2 can request each terminal M.sub.x to provide a range proof. This does not necessarily relate to a single transaction, as shown in equations 9a to 9d, but can comprise multiple transactions, for example by adding a “time unit” dimension. It would then have to be checked whether the sum of all transactions per time unit, here per day, exceeds a threshold value, see equation (9e):

v.sub.day=Σv.sub.i∈[0;v.sub.day]≤v.sub.threshold value? (9e)

[0177] In FIG. 1, an electronic coin dataset C.sub.i is generated by the issuer entity 1 and a masked electronic coin dataset Z.sub.i is calculated by the issuer entity 1 by means of equation (3) or equation (3a) and this is registered in the monitoring entity 2. Subsequently, the first terminal M1 transmits the electronic coin dataset C.sub.i to a second terminal M2 or carries out one of the processing steps (switching, connecting, splitting). The transmission occurs wirelessly via WLAN, NFC or Bluetooth, for example. The transmission can be additionally secured by cryptographic encryption methods, for example by negotiating a session key or applying a PKI infrastructure.

[0178] In the second terminal M2, the transmitted electronic coin dataset C.sub.i is received as C.sub.i*. Upon receiving the electronic coin dataset C.sub.i*, the second terminal M2 is in possession of the digital money represented by the electronic coin dataset C.sub.i*. If both terminals trust each other, no further steps are necessary to complete the method. However, the terminal M2 does not know whether the electronic coin dataset C.sub.i* is actually valid. Moreover, the terminal M1 could still transmit the electronic coin dataset C.sub.i to a third terminal (not shown). To prevent this, further preferred steps in the method are provided.

[0179] To check the validity of the received electronic coin dataset C.sub.i*, the masked transmitted electronic coin dataset Z.sub.i* is calculated in the second terminal M2 using the—public—one-way function from equation (3) or equation (3a). In addition—only in pseudonymous mode—a signature is calculated and appended according to equation (3a). The pseudonymized masked transmitted electronic coin dataset S.sub.i* is then transmitted to the monitoring entity 2. If the masked transmitted electronic coin dataset Z.sub.i* matches a registered and valid masked electronic coin dataset, the validity of the received coin dataset C.sub.i* is displayed to the second terminal M2 and it is deemed that the received electronic coin dataset C.sub.i* is equal to the registered electronic coin dataset C.sub.i. In one embodiment, the check for validity can be used to determine that the received electronic coin dataset 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 not been subject to a further modification.

[0180] Preferably, a switching of the received electronic coin dataset occurs thereafter.

[0181] It holds for the method according to the invention that the sole knowledge of a masked electronic coin dataset Z.sub.i or signed masked electronic coin dataset S.sub.i does not entitle to spend the digital money. However, the sole knowledge of the electronic coin dataset C.sub.i entitles to pay, i.e. to perform a transaction successfully, in particular if the coin dataset C.sub.i is valid. There is a one-to-one relationship between the electronic coin datasets C.sub.i and the corresponding masked electronic coin datasets Z.sub.i. The masked electronic coin datasets Z.sub.i or the signed masked electronic coin datasets S.sub.i, are registered in the monitoring entity 2, for example a public decentral database. In the embodiment according to FIG. 1, both anonymous and pseudonymously obtained masked electronic coin datasets Z.sub.i are stored in the data structure 210. The pseudonymously masked electronic coin dataset S.sub.i (or with association to the coin dataset Z.sub.i, the pseudonym or signature) is stored in the data structure 220. This registration first makes it possible to check the validity of the electronic coin dataset Z.sub.i, for example whether new monetary values have been created (illegally). Furthermore, together with pseudonymization of the masked coin dataset, it becomes possible to associate a transaction to a pseudonym of a terminal M.sub.x.

[0182] A main distinguishing feature compared to conventional solutions is that the masked electronic coin dataset Z.sub.i or the signed masked electronic coin dataset S.sub.i is stored in a monitoring layer 4 and all processing on the electronic coin dataset S.sub.i, Z.sub.i 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.

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

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

[0184] Further operations not listed in table 1 may be required. Instead of the listed implementation, other implementations are also conceivable that imply other operations. Table 1 shows that, for each coin dataset, each of the operations “Create”. “Deactivate”. “Split”, “Connect” and “Switch”, different operations “Create signature”; “Create random number”; “Create masking”; “Range check” may be provided, each of the processing operation being registered in the monitoring entity 2 and appended there in invariant form to a list of previous processing operations for masked electronic coin datasets Z.sub.i. The operations of creating and deactivating an electronic coin dataset are carried out only at 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 the terminals M1 to M3.

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

[0186] In principle, it can also be provided in one embodiment that a range check is also performed by the issuer instance 1 upon creating and/or deleting.

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

TABLE-US-00002 TABLE 2 Number of operations that can be performed per processing of a coin dataset in the monitoring entire; Comprehend homomorphous properties of the Check validity masked electronic Check of the masked coin datasets, i.e. Command or Check signature signature of electronic coin Comprehend adding or step of issuer terminal dataset range proof substracting Generate 1 0 0 0 or 1 0 Deactivate 1 0 1 0 or 1 0 Split 0 1 1 2 or more 1 Connect 0 1 2 or more 1 1 Switch 0 1 1 1 0

[0188] Further operations not listed in table 2 may be required. Instead of the listed implementation, other implementations are conceivable that imply other operations. All operations of table 2 can be performed in the monitoring entity 2, which is a trusted entity, for example a decentral server, in particular a distributed trusted server, that ensures sufficient integrity of the electronic coin datasets. The monitoring entity 2 has a public verification key to check the signature of the signed masked coin dataset S. The public verification key may serve as a pseudonym or be associated with a pseudonym. The pseudonymized masked coin dataset S comprises at least the coin dataset Z and directly or indirectly the pseudonym, indirectly for example as part of the signature.

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

TABLE-US-00003 TABLE 3 Preferred units in the system components. Command or step Issuer entity Terminal Monitoring entity Random number generator Yes — — (high security) Random number generator — Yes — (deterministic) PKI for signing Yes Yes — PKI for signature verification — (Yes) Yes Read access to DLT Yes Yes Yes Write access to DLT Yes Yes Yes Disabling the electronic Yes Yes — coin dataset Transport encryption Yes Yes — Secure memory (Yes) Yes —/Yes Masking unit Yes Yes — Range proof — Yes — Check range proof — — Yes DLT software — — Yes

[0190] Table 3 shows an overview of the preferred components to be used in each system participant. i.e. the issuer entity 1, a terminal M1 and the monitoring entity 2. The terminal M1 can be used as a wallet for electronic coin datasets C.sub.i, i.e. designed as an electronic wallet, thus a data memory of the terminal M1, in which a plurality of coin datasets 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 trader, a commercial bank or another market participant and send or receive an electronic coin dataset. 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 number of trusted market participants.

[0191] FIG. 2 shows an embodiment example of a monitoring entity 2 that could also be used in FIG. 1. FIG. 2 shows an exemplary database in the form of a table in which the masked electronic coin datasets Z.sub.i and, if applicable, their processings are registered. The monitoring entity 2 is preferably arranged locally remote from the terminals M1 to M3 and is accommodated, for example, in a server architecture.

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

[0193] The processings “create” and “deactivate”, which concern the existence of the monetary value v.sub.i, per se, thus imply the creation and destruction of money, require an additional authorization by the issuer entity 1 in order to be registered (thus logged) in the monitoring entity 2. The other processing operations (splitting, connecting, switching) do not require authorization by issuer instance 1 or by the command initiator (=payer, e.g. the first terminal M1). However, the other processing operations must be checked with regard to various check criteria.

[0194] A registration of the respective processing in the monitoring entity 2 is realized, for example, by corresponding list entries in the database according to FIG. 2. Each list entry has further markings 25 to 28 which document the intermediate results of the respective processing which must be performed by the monitoring entity 2. Preferably, the markings 25 to 28 are used as an aid and are discarded by the monitoring entity after completion of the commands. For anonymous coin datasets, all checks must always be carried out so that all markings 25-28 could also be discarded. For pseudonymized coin datasets, on the other hand, a check can be omitted or carried out later. In FIG. 2, for example, the checks corresponding to the markings 27b and 27c are not necessary for pseudonymized coin datasets because they are performed later in a different form. The checking steps of the markings 25, 26, 27a and 28, on the other hand, are necessary. In the following, we will refer in part to necessary or validity-relevant checking steps and to verifiable or validity-independent checking steps, since they are performed directly or indirectly at a later time. A coin dataset can be treated as valid if the necessary checks have been carried out.

[0195] The data in columns 24, 28 and 29 highlighted in bold in FIG. 2 are only relevant for coin datasets received pseudonymized.

[0196] An optional marking 29 can, for example, indicate the completion of the processing. Markings 29 are in “-” state when a processing command is received, for example, and are set to “1” state after all checks have been successfully completed (to markings 25-28) and are set to “0” state if at least one check has failed. A (completion) marking 29 with the value “2” could, for example, indicate that only the necessary examinations were completed and that examinations that could be caught up were omitted. If checks for one or a plurality of entries are caught up by the terminal with the pseudonym, the marking can be set to the value “1”. Instead of using the completion marking 29 in this way, the markings 27b and 27c of the checks to be caught up could of course also be used and/or a separate pseudonym marking could be used.

[0197] For example, a possible structure for a list entry of a coin dataset comprises two columns 22a, 22b for a predecessor coin dataset (O1, O2), two columns 23a. 23b for a successor coin dataset (S1, S2), a signature column 24 for signatures of issuer entity/entities 1 and signatures of terminals M, and six marking columns 25, 26, 27a, 27b and 27c and 28. Each of the entries in columns 25 to 28 has three alternative states, “-”, “1” or “0”.

[0198] Column 25 (O-Flag) indicates whether a validity check was successful with regard to a predecessor electronic coin dataset in column 22a/b. The “1” state indicates that a validity check revealed that the column 22a/b electronic coin dataset is valid and the “0” state indicates that a validity check revealed that the column 22a/b electronic coin dataset is invalid and the “-” state indicates that a validity check has not yet been completed. For multiple predecessor coin datasets, it is preferred to use a combined O-Flag (both valid) rather than two separate O-Flags. Column 26 (C-Flag) indicates whether an initial check calculation was successful for the masked electronic coin datasets. The first check calculation checks in particular whether the command is value-neutral, i.e. primarily that the sum of the monetary values involved is zero. The “I” state means that a calculation was successful and the “0” state indicates that calculation was not successful and the “-” state indicates that a calculation has not yet been completed.

[0199] For example, the calculation to be performed in column 26 based on equation (3) is:

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

[0200] Column 27a (R1-Flag) indicates whether a first check of a range proof or of the range proof was successful. The same applies to the further columns 27b (R2-Flag) and 27c (R3-Flag). The “1” state means that a validity check showed that the range proofs or the range proof could or is comprehensible and the “0” state indicates that a validity check showed that the range proofs or the range proof could not be comprehended and the “-” state indicates that a validity check is not yet completed, was not successful. The first range proof of column 27a is always necessary for the coin dataset(s) to be considered valid. A typical example of a necessary check is the check that the monetary value is not negative (or none of the monetary values are negative). The second and third range proofs do not affect the validity of the coin dataset and can be performed later for pseudonymized masked coin datasets, for example in a later transaction of the pseudonym. The range proof of column 27b is used to check whether the monetary value of the masked coin dataset (or each coin dataset) is below a maximum value. The maximum value can be predetermined system-wide or for specific terminal types. For example, the range check of column 27c is used to compare a sum of monetary values (sent or) received by the terminal in a specific time period—such as 24 hours—against a sum limit value, or to check, for example, a transaction count per time unit for the terminal, such as a maximum of 5 per minute or 100 per day. The limit values can be predefined by the payment system system-wide or defined for specific terminal device types (thus terminal device-specific) (e.g.: Type X coffee machine can only dispense 4 portions of hot drinks per minute due to the device and accordingly only 4 transactions per minute are permitted).

[0201] Column 28 (S-Flag) indicates whether a signature of the electronic coin dataset matches the signature of column 24, where the “1” state indicates that a validity check revealed that the signature could be identified as that of the issuer entity and the “0” state indicates that a validity check revealed that the signature could not be identified as that of the issuer entity and “-” state indicates that a validity check is not yet completed.

[0202] A change in the status of one of the markings (also referred to as a “flag”) requires approval by the monitoring entity 2 and must then be stored unchangeably in the data structure. A processing is final in anonymous mode (or for an anonymous masked coin dataset) if and only if the required flags 25 to 28 have been validated by monitoring entity 2, i.e. changed from “0” state to “1” state or “1” state after the appropriate check. Processing is completed in pseudonymous mode (or for a pseudonymized masked coin dataset) when the checks for the markings 25 to 27a and 28 have been performed.

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

[0204] If the masked electronic coin dataset Z is not found in the monitoring entity 2, it is invalid. It also holds that the anonymous masked electronic coin dataset Z is not valid for all other cases. For example, if the last processing of the masked electronic coin dataset 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 dataset Z is in one of the predecessor columns 22a, 22b and this last processing is final.

[0205] The checks performed by the monitoring entity 2 in order to determine whether a processing is final are represented by columns 25 to 28: The state in column 25 indicates whether the masked electronic coin dataset(s) are valid according to predecessor columns 22a, 22b. The state in column 26 indicates whether the calculation of the masked electronic coin dataset is correct according to equation (10). The state in column 27a indicates whether the range checks for the masked electronic coin dataset Z could be successfully checked. The state in column 28 indicates whether the signature in column 24 of the masked electronic coin dataset Z is a valid signature of issuer entity 1.

[0206] The “0” status in a column 25 to 28 indicates that the check was not successful. The “1” status in a column 25 to 28 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 certain check was performed.

[0207] As an example, five different processes are defined, which are explained in detail here. Reference is made in this case to the corresponding list entry in FIG. 2.

[0208] One processing is, for example, “generating” an electronic coin dataset C.sub.i. Generating in the direct transaction layer 3 by the issuer entity 1 involves selecting a monetary value v.sub.i and creating an concealment value r.sub.i, as described earlier with equation (1). As shown in FIG. 2, no entries/markings are required in columns 22a, 22b, 23b and 25 to 27 during the “Generate” processing. The masked electronic coin dataset Z.sub.i is registered in the successor column 23a. This registration is preferably done before transmitting it to a terminal M1 to M3, in particular or already at the time of generation by the issuer entity 1, and in both cases equation (3) or equation (3a) must be executed for this purpose. The masked electronic coin dataset Z.sub.i is signed by the issuer entity 1 when it is created, this signature is entered in column 24 in order to ensure that the electronic coin dataset C.sub.i has actually been created by an issuer entity 1, although other processes may also be used for this purpose. If the signature of a received C.sub.i matches the signature in column 24, the marking in column 28 is set (from “0” to “1”). The markings according to columns 25 to 27 do not require a status change and can be ignored. The range proof is not required because monitoring entity 2 trusts that issuer entity 1 will not issue negative monetary values. However, in an alternative execution, it can be sent by issuer entity 1 in the create command and checked by monitoring entity 2.

[0209] One processing is, for example, “deactivate”. Deactivating, thus destroying money (DESTROY), causes the masked electronic coin dataset Z.sub.i to become invalid after successful execution of the deactivate command by issuer instance 1. One can therefore no longer process the (masked) electronic coin dataset to be deactivated in monitoring layer 4. To avoid confusion, the corresponding (non-masked) electronic coin datasets C.sub.i should also be deactivated in the direct transaction layer 3. Upon “deactivating”, the predecessor column 22a is written to with the electronic coin dataset Z.sub.i, but no successor column 23a, 23b is occupied. The masked electronic coin dataset Z.sub.i shall be checked during deactivation whether the signature matches the signature according to column 24 in order to ensure that the electronic coin dataset C.sub.i has indeed been created by an issuer entity 1, wherein again other means may be used for this check. If the signed Z.sub.i sent in the deactivate command can be confirmed as signed by issuer instance 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 check.

[0210] One processing is, for example, “splitting”. The splitting, thus dividing of an electronic coin dataset Z.sub.i into a number n, for example 2, of electronic coin subdatasets Z.sub.j and Z.sub.k is first carried out in the direct transaction layer 3, as still shown in FIGS. 3, 5 to 7 and also FIGS. 9 to 11, whereby the monetary values v.sub.j and the concealment value r.sub.j are generated, v.sub.k and r.sub.i result from equations (7) and (8). In monitoring entity 2, markings 24 to 27 are set, predecessor column 22a is described by electronic coin dataset 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 performed after the corresponding check by monitoring entity 2 and document the respective check result. The marking according to column 28 is ignored in particular in anonymous mode. A first range proof R1 according to column 27a must be provided, for example, to show that no monetary value is negative. A second range proof R2 in column 27b is not necessary because the successor monetary subvalues are always smaller than the initial monetary value of the predecessor. A sum range proof R3 in column 27c is also usually not necessary (no new monetary values). Column 24 is used to enter a signature generated by the splitting terminal M1 to M3.

[0211] For example, one processing is “connecting”. The connecting, thus merging of two electronic coin datasets Z.sub.i and Z.sub.j into one electronic coin dataset Z.sub.m is first performed in the direct transaction layer 3, as still shown in FIG. 4, where the monetary value v.sub.m and the concealment value r.sub.m are calculated. In the monitoring entity 2, the markings 25 to 28 are set, the predecessor column 22a is described with the electronic coin dataset Z.sub.i, predecessor column 22b is described with Z.sub.j and successor column 23b is described with Z.sub.m. The markings in columns 25 to 28 require status changes and the monitoring entity 2 performs the corresponding checks. A first range proof R1 according to column 27a must be provided to show that no new money has been generated. A second range check R2 in column 27b is useful because the new monetary value of the successor could be greater than a maximum value. A sum range proof R3 in column 27c is also usually useful, as the terminal could be using newly received predecessors. The marking according to column 28 can be ignored. Column 24 is used to enter a signature generated by the connecting terminal M1 to M3.

[0212] A further processing is, for example, “switching”. Switching is necessary when an electronic coin dataset has been transmitted to another terminal and double spending by the transmitting terminal (here M1) is to be excluded. Upon switching, the electronic coin dataset C.sub.k received from the first terminal M1 is replaced by a new electronic coin dataset C.sub.i with the same monetary value. The new electronic coin dataset C.sub.i is generated by the second terminal M2. This switching is necessary to invalidate (make invalid) the electronic coin dataset C.sub.k received from the first terminal M1, which avoids double spending of the same electronic coin dataset C.sub.k. This is because, as long as the electronic coin dataset C.sub.k is not switched, and since the first terminal M1 is aware of the electronic coin dataset C.sub.k, the first terminal M1 can pass this electronic coin dataset C.sub.k to a third terminal M3. The switching is done, for example, by adding a new concealment value r.sub.add to the concealment value r.sub.k of the received electronic coin dataset C.sub.k, thereby obtaining an concealment value r.sub.i that only the second terminal M2 knows. This can also be done in the monitoring entity 2. To prove that only a new concealment value r.sub.add has been added to the concealment value rt of the masked received electronic coin dataset Z.sub.k, but the monetary value has remained the same, and thus equation (11):

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

holds, so that 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, thus as r.sub.add*G. This means that only a concealment value r.sub.add has been generated and the monetary value of Z.sub.i is equal to the monetary value 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 dataset to be switched.

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

[0214] FIG. 3 shows an embodiment example of a payment system according to the invention for “splitting”, “connecting” and “switching” electronic coin datasets C. In FIG. 3, the first terminal M1 has received the coin dataset C.sub.i and now wishes to perform a payment transaction not with the entire monetary value v.sub.i, but only with a partial value v.sub.k. For this purpose, the coin dataset C.sub.i is split. To do this, the monetary value is split first:

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

[0215] For this, each of the received values v.sub.j, v.sub.k, must be greater than 0, because negative monetary values are not allowed.

[0216] In addition, new concealment values are derived:

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

[0217] Upon splitting, masked coin datasets Z.sub.j and Z.sub.k are obtained from the coin datasets C.sub.j and C.sub.k according to equation (3) and registered in monitoring entity 2. For splitting, the predecessor column 22a is described with coin dataset Z.sub.i, the successor column 23a with Z.sub.j and the successor column 23b with Z.sub.k. Additional information for the range proof R1 (zero-knowledge-proof) is to be generated. The markings in columns 25 to 27c require status change and the monitoring entity 2 performs the corresponding checks. The marking according to column 28 is ignored.

[0218] Then, a coin subdataset, here C.sub.k, is transmitted from the first terminal M1 to the second terminal M2. To prevent double spending, a switching operation is useful to exchange the electronic coin dataset C.sub.k received from the first terminal M1 for a new electronic coin dataset C.sub.i with the same monetary value. The new electronic coin dataset C.sub.i is generated by the second terminal M2. The monetary value of the coin dataset C.sub.k is taken over and not changed, see equation (11).

[0219] Then, according to equation (14), a new concealment value r.sub.add is added to the concealment value r.sub.k of the received electronic coin dataset C.sub.k.

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

thereby obtaining a concealment value r.sub.i known only to the second terminal M2. To prove that only a new concealment value r.sub.add has been added to the concealment value r.sub.k of the received electronic coin dataset Z.sub.k, but that the monetary value has remained the same (v.sub.k=v.sub.l), the second terminal M2 must be able to prove that Z.sub.l-Z.sub.k can be represented as a multiple of G. This is done by means of the (public) signature R.sub.add according to equation (15):

R.sub.add=r.sub.add.Math.G=Z.sub.i−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 dataset C.sub.i to be switched is masked by equation (3) or equation (3a) to obtain the masked coin dataset Z.sub.1. Then the masked coin dataset Z.sub.i is signed by equation (3a) in order to obtain the signed coin dataset S.sub.i. In the monitoring entity 2, the private signature r.sub.add can then be used, for example, to sign the masked electronic coin record Z.sub.i to be switched, which is considered proof that the second terminal M2 has only added an concealment value r.sub.add to the masked electronic coin dataset and not an additional monetary value, i.e. v.sub.i=v.sub.k.

[0220] The signature is entered in the field of column 24. Here, as an example, it was assumed that the pseudonyms of the receiving terminals M.sub.x are kept track of in monitoring entity 2. Then, upon “splitting”, the signature of the first terminal M1 is entered, since it has received the coin dataset C.sub.i. Then, upon “switching”, the signature of the second terminal M2 is entered, since it has received the coin dataset C.sub.k. Alternatively, the pseudonyms of the sending terminals M.sub.x could also be entered. Then the coin dataset C.sub.l to be switched is masked by equation (3) in order to obtain the masked coin dataset Z.sub.1. Then the masked coin dataset Z.sub.l is signed by equation (3a) to obtain the signed coin dataset S.sub.l.

[0221] The proof for masking by means of equation (3) is as follows:

[00001] $\begin{matrix} Z_{k} = v_{k} .Math. H + r_{k} .Math. G Z_{l} = v_{l} .Math. H + r_{l} .Math. G = v_{k} .Math. H + (r_{k} + r_{add}) .Math. G Z_{l} - Z_{k} = (r_{k} + r_{add} - r_{k}) .Math. G = r_{add} .Math. G & (16) \end{matrix}$

[0222] For masking by equation (3a), a signature is generated over the monetary value v.sub.k, the masking value r.sub.k and the masked coin dataset 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 dataset C.

[0223] FIG. 4 shows an embodiment example of a payment system according to the invention for connecting electronic coin datasets. Here, the two coin datasets C.sub.i and C.sub.j are obtained in the second terminal M2. Following the splitting according to FIG. 3, a new coin dataset Z.sub.m is now obtained by adding both the monetary values and the concealment value of the two coin datasets C.sub.i and C.sub.j. Then the obtained coin dataset C.sub.m to be connected is masked by equation (3) or equation (3a) and the masked coin dataset Z.sub.m is registered in the monitoring entity. Then, when “connecting”, the signature of the second terminal M2 is entered, as it has received the coin datasets C.sub.i and C.sub.3.

[0224] For masking by means of equation (3a), a first signature can be generated by the monetary value v.sub.i, the concealment value r.sub.i, and the masked coin dataset Z.sub.i, and a second signature can be generated by the monetary value v.sub.j, the concealment value r.sub.j, and the masked coin dataset Z.sub.j. Both signatures can be validated by recalculating the masking in the monitoring entity 4, respectively, in order to be able to prove the authenticity and the existence/possession of the coin dataset C. The first signature may also be linked with the second signature in order to form a common signature.

[0225] FIGS. 5 to 7 are each an embodiment example of a method flow diagram of a method 100. In the following, FIGS. 5 to 7 are explained in combination. In optional steps 101 and 102, a coin dataset is requested and provided by the issuer entity 1 to the first terminal M1 after creating the electronic coin dataset. A signed masked electronic coin dataset is sent to the monitoring entity 2 in step 103. In step 103, the obtained electronic coin dataset C.sub.i is masked according to equation (3) and signed in step 103p according to equation (3a) as explained in FIG. 1. Then, in step 104, the masked electronic coin dataset Z.sub.i is registered in the monitoring entity 2. Optionally, M1 can switch the received electronic coin dataset, then a signature S.sub.i would be registered in the monitoring entity 2. In step 105, the coin dataset 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 with prior masking is performed, in which, in the good case, the monitoring entity 2 confirms the validity of the coin dataset Z.sub.i or C.sub.i.

[0226] In the optional step 108, a received coin dataset C.sub.k is then switched (of course, the received coin dataset C.sub.i could also be switched) to a new coin dataset C.sub.l, whereby the coin dataset C.sub.k becomes invalid and double spending is prevented. For this purpose, the monetary value v.sub.k of the transmitted coin dataset C.sub.k is used as the “new” monetary value v.sub.l. In addition, as already explained with equations (14) to (17), the concealment value r.sub.l is created. The additional concealment value r.sub.add is used to prove that no new money (in the form of a higher monetary value) was generated by the second terminal M2. Then the masked coin dataset is signed and the signed masked coin dataset Z.sub.i to be switched is sent to the monitoring entity 2 and the switching from C.sub.k to C.sub.l is instructed. In addition, a signature S.sub.k is created by the first or second terminal M1, M2 and stored in the monitoring entity 2. In addition or alternatively, a signature S.sub.l could also be created and deposited in the monitoring entity 2 if sending terminals M.sub.x were registered instead of receiving terminals M.sub.x.

[0227] In step 108′, the corresponding check is carried out in monitoring entity 2. Here, Z.sub.k is entered in column 22a according to the table in FIG. 2 and the coin dataset Z.sub.l to be transferred is entered in column 23b. A check is then carried out in monitoring entity 2 as to whether Z.sub.k is (still) valid, thus whether the last processing of Z.sub.k is entered in one of the columns 23a/b (as proof that Z.sub.k has not been further split or deactivated or connected) 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, whereby the check according to equations (16) and (17) can be used. In the good case, the marking in column 25 is set to “1”, 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 regions are conclusive, then the marking is set in column 27. Then the signature S.sub.l is verified with the corresponding public verification key available in the monitoring entity 2 and logged accordingly. If all checks have been successful and this has been recorded accordingly in the monitoring entity 2, the coin dataset is considered to have been switched. Thus, the coin dataset C.sub.k is no longer valid and from now on the coin dataset C.sub.l is valid. Double spending is no longer possible if a third terminal M3 inquires about the validity of the (double-spent) coin dataset at the monitoring entity 2. When checking the signature, it can be checked in pseudonymous mode whether the terminal M2 has exceeded a limit for monetary values. The check is carried out with regard to a time unit, for example a daily limit value could be monitored with it. If the limit value is exceeded, the monitoring entity 2 first refuses to switch the coin dataset C.sub.l and requests the terminal M2 to de-anonymize. Depending on the system, de-anonymized switching may be permitted.

[0228] In optional step 109, a connecting of two coin datasets C.sub.k and C.sub.i to a new coin dataset C.sub.m is performed, invalidating the coin datasets C.sub.k, C.sub.i and preventing double spending. To do this, the monetary value v.sub.m is formed from the two monetary values v.sub.k and v.sub.i. For this purpose, the concealment value r.sub.m is formed from the two concealment values r.sub.k and r.sub.i. In addition, the masked coin dataset Z.sub.m to be connected is obtained by equation (3) and this is sent (together with other information) to the monitoring entity 2 and the connecting 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.

[0229] In step 109′, the corresponding check is carried out in the monitoring entity 2. In the process, Z.sub.m is entered in column 23b according to the table in FIG. 2, which also corresponds to a transfer. A check is then made in 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.sub.i have not been further split or deactivated or connected) 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, whereby the check according to equations (16) and (17) can be used. In the good case, the marking in column 25 is set to “I”, 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. When checking the signature, it can be checked whether the terminal M2 has exceeded a limit value for monetary values. The check is carried out with regard to a time unit, for example, a daily limit value could be monitored with it. If the limit value is exceeded, the monitoring entity 2 first refuses to connect the coin dataset C.sub.m and requests the terminal M2 to de-anonymize. A de-anonymized connecting may then be permitted.

[0230] In optional step 110, an asymmetric splitting of a coin dataset C.sub.i into two coin datasets C.sub.k and C.sub.j is performed, whereby the coin dataset C.sub.i is invalidated and the two asymmetrically split coin datasets C.sub.k and C.sub.j are to be validated. In an asymmetric split, the monetary value v.sub.i is split into monetary subvalues v.sub.k and v.sub.j of different sizes. For this purpose, the concealment value r.sub.i is divided into the two concealment values r.sub.k and r.sub.j. In addition, by means of equation (3), the masked coin subdatasets Z.sub.k and Z.sub.j are obtained and sent to the monitoring entity 2 with further information, for example the range checks (zero-knowledge-proofs), and the splitting is requested as processing. In addition, a signature S.sub.i is created and sent to the monitoring entity 2.

[0231] In step 110′, the corresponding check is carried out 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 split or deactivated or connected) 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, whereby the check according to equations (16) and (17) can be used. In the good case, the marking in column 25 is set to “1”. Now a check is made, the calculation according to equation (10) shows that Z.sub.i is equal to Z.sub.k plus Z.sub.j and accordingly the marking in column 26 is set. Furthermore, it is checked whether the ranges are conclusive, then the marking is set in column 27. When checking the signature, it can be checked whether the terminal M2 has exceeded a limit value for monetary values. The check is carried out with regard to a time unit, for example, a daily limit value could be monitored with it. If the limit is exceeded, the monitoring entity 2 first refuses to split the coin dataset C.sub.i and requests the terminal M2 to de-anonymize. A de-anonymized splitting may then be permitted.

[0232] FIG. 8 shows an embodiment example of a device M1 according to the invention. The device M1 can store electronic coin datasets C.sub.i in a data memory 10, 10′. Thereby the electronic coin datasets C.sub.i are stored in the data memory 10 of the device M1 or are available in an external data memory 10′. When using an external data memory 10′, the electronic coin datasets C.sub.i could be stored in an online memory, for example a data memory 10′ of a digital wallet provider. Additionally, private data storage, for example a network attached storage, NAS, in a private network could also be used.

[0233] In one case, the electronic coin dataset C.sub.i is represented as a printout on paper. In this case, the electronic coin dataset may be represented by a QR code, an image of a QR code, or may be a file or a string (ASCII).

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

[0235] Furthermore, the interface 12 or a further interface (not shown) of the device M1 is configured to interact with the monitoring entity 2 according to the description in FIGS. 1 to 6. The device M1 is preferably online-capable for this purpose.

[0236] Furthermore, the device M1 may also have an interface for receiving electronic coin datasets. This interface is configured to receive visually presented coin datasets, for example by means of a capture module such as a camera or scanner, or digitally presented coin datasets, received via NFC, Bluetooth, TCP, IP, UDP, HTTP or coin datasets presented by means of an application.

[0237] The device M1 also comprises a computing unit 13 capable of performing the method described above for masking coin datasets and the processing on coin datasets.

[0238] The device M1 is online-capable and can preferably detect when it is connected to a WLAN by means of a location detection module 15. Optionally, a specific WLAN network can be marked as preferred (=location zone) so that the device M1 only performs special functions if it is logged into this WLAN network. Alternatively, the location detection module 15 detects when the device M1 is within 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 unit M1 or via other units/modules into the unit M1. The special functions performed by the device M1 when the location zone is detected are in particular the transmitting of electronic coin datasets from/to the external data memory 10 from/to a vault module 14 and, if applicable, the transmitting of masked coin datasets Z to the monitoring entity 2, for example as part of the above-mentioned processing operations on a coin dataset.

[0239] In the simplest case, all coin datasets C.sub.i are automatically connected to a coin dataset in the terminal M1 after receipt (see connect-processing or connect-step). That is, as soon as a new electronic coin dataset is received, a connect or switch command is sent to the monitoring entity 2. The device M1 can also prepare electronic coin datasets in algorithmically defined denominations and hold them in the data memory 10, 10′ so that a payment method is possible even without a data connection to the monitoring entity 2.

[0240] FIG. 9 shows a flow chart of a method, with which, for example, compliance with a limit value for monetary values per time unit is made possible.

[0241] In the upper part of the figure, the payment system consisting of three terminals M1, M2, M3 is shown. In the lower part of the figure, two data structures 910, 920 of the monitoring entity 2 are shown. In the data structure 910, the valid masked coin datasets Z.sub.i are stored. The data structure 920 comprises the association of pseudonymously sent masked coin datasets with the pseudonym and can be regarded as a register of pseudonymously sent coin datasets still to be checked. On the basis of the data in data structure 920, monitoring entity 2 can decide whether a range proof is requested for a pseudonym.

[0242] The following transactions were performed: [0243] 1. The first terminal M1 has split a coin 901. Thus, the monitoring entity 2 knows that the coin C1 is a result of this split and stores the masked coin dataset Z1 in the data structure 910. the first terminal M1 could send the split to the monitoring entity 2 anonymously or pseudonymously. In the illustration, it is assumed that the terminals M1 and M3 send their masked coin datasets anonymously to the monitoring entity 2. [0244] 2. The first terminal M1 sends the coin C1 directly to the second terminal M2 in a direct transmission step 902. The monitoring entity 2 does not receive any information about this. [0245] 3. The second terminal M2 converts (switches) the coin C1 to the coin C2 903. The new masked coin dataset Z2 is stored in the data structure 910 and the old masked coin dataset Z1 is deleted (or marked as invalid). The second terminal M2 sends its masked (or at least the represented) coin dataset pseudonymized to the monitoring entity 2. Thus, the monitoring entity 2 also receives the information that the second terminal M2 with the pseudonym P.sub.M2 has received the coin C1 (and now possesses coin C2) and stores accordingly in the data structure 920 Z2 (and/or Z1) for P.sub.M2. [0246] In addition, the monitoring entity 2 will skip at least one checking step, such as a range proof for the coin dataset Z2 or a sum range proof for the terminal M2. [0247] 4. The second terminal M2 sends the coin C2 to the third terminal M3 in a further direct transmission step 902. Monitoring entity 2 does not receive any information about this. [0248] 5. The third terminal M3 connects the received coin C2 to the connected coin C3 in step 904 and sends this information with anonymous masked coin datasets to the monitoring entity 2. The monitoring entity 2 therefore first performs all checking steps, thus in particular all range proofs for the masked coin datasets involved Z2 . . . and Z3 or also a sum range proof for the third terminal M3. The monitoring entity 2 only then deletes the masked coin dataset Z2 (as well as the other coin datasets of the operation) from the data structure 910 and stores the new masked coin dataset Z3 as a valid masked coin dataset. [0249] 6. In step 902, the third terminal M3 sends the coin C3 directly to the second terminal M2. Again, the monitoring entity 2 does not receive any information about this. [0250] 7. In a further step 903, the second terminal M2 converts (switches) the coin C3 into the coin C4 and sends a masked coin dataset Z4 together with its pseudonym to the monitoring entity 2. The monitoring entity 2 receives the information and carries out the necessary checks. Using the data structure 920, the monitoring entity 2 determines whether one or multiple checks should now be caught up for the pseudonym of the terminal M2. If the criterion for a catch-up, such as time lapse or number of transactions for a pseudonym, is not yet fulfilled, only the further masked coin dataset Z4 for the pseudonym is noted in the data structure 920. The monitoring entity 2 stores the masked coin dataset Z4 in the data structure 910 and deletes the masked coin dataset Z3 there. If, on the other hand, a criterion for a checking step which can be caught up is fulfilled, it first performs the checking step which can be caught up (or its equivalent).

[0251] In the particular example, monitoring entity 2 has the information that the second terminal M2 had coin C2 (see step 3). Since the sum of the monetary values of coin C2 and coin C4 could exceed a coin threshold value, monitoring entity 2 requests a sum range proof (or sum range confirmation) from the second terminal M2. The sum range proof shows that the sum of the monetary values of the coins C2 and C4 does not yet exceed the—for example daily—limit of transactions for the second terminal M2. The monitoring entity 2 can also monitor a limit for a time-independent number of transactions (range proof after 3/5/10/ . . . transactions). Alternatively or in addition to a sum check of multiple coin datasets, the monitoring entity 2 can catch up a range check for the individual coin datasets linked to the pseudonym P.sub.M2 in the data structure 920 (Is the monetary value of each coin dataset Z2 and Z4 smaller than X?). If checks have been successfully caught up, the corresponding datasets in the data structure 920 can also be deleted.

[0252] FIG. 10 shows a further embodiment example of an operation in a payment system with masked coin datasets. A first terminal M1 sends anonymous masked coin datasets to the monitoring entity 2 in steps 151, whereas a second terminal M2 sends pseudonymized masked coin datasets to the monitoring entity 2 in steps 161.

[0253] The monitoring entity 2 responds to each of the anonymous sending steps 151 of the first terminal M1 (in its anonymous mode) with a check (which can be caught up) for the masked coin dataset or the first terminal M1. The additional necessary checks, if any, are not shown in FIG. 10. In step 152, for each masked coin dataset, the monitoring entity 2 requests a range proof that the monetary value of the masked coin dataset from step 151 is below a maximum value (or a corresponding range confirmation).

[0254] Alternatively or additionally, at step 152, the monitoring entity requests a sum range proof (or confirmation) from the first terminal M1. The requested proof (or proofs) shall be created by the first terminal M1 in step 153 and sent in step 154 in order for the (at least one) masked coin dataset of step 151 to be treated as valid in the monitoring entity 2.

[0255] The monitoring entity 2 responds to the first sending step 161 of the second terminal M2 (in its pseudonymous mode) by skipping a check (which can be caught up) for the masked coin dataset or the second terminal M2. The pseudonymously sent masked coin dataset is registered as valid. For example, necessary checks not shown here are performed but do not require further communication with the second terminal M2. As previously described in other examples, the monitoring entity 2 stores an association between the pseudonym and the pseudonymously sent masked coin dataset(s). In the example shown, the monitoring entity 2 also responds analogously to a second (or further) sending step 161 of the second terminal M2. In each case, it checks for the pseudonym whether a catch-up criterion is fulfilled.

[0256] Only in the third step 161 shown does the monitoring entity 2 determine that a check is to be caught up for the pseudonym. It sends a request 162 to the second terminal M2 to create, for example, range proofs for multiple coin datasets or a sum range proof. In step 163, the second terminal M2 creates multiple range proofs, a sum range proof, or a sum range confirmation and sends them to the monitoring entity 2 in step 164. In step 163, for example, a plurality of coin datasets of the second terminal M2 are selected and a sum is formed over their monetary values. These coin datasets concern either only pseudonymized coin datasets or anonymous and pseudonymized coin datasets (in this case, the masked coin datasets that have already been sent are used and the sum is formed from the monetary values of the corresponding unmasked coin datasets). The selecting can be done on the basis of criteria that are either known by the system or transmitted by the monitoring entity 2 in step 162. The criteria are, for example, a time period, in particular a predefined time period in which a sum of all monetary values should/must not exceed a certain range, for example a monetary value x euros per time unit y. The criterion can alternatively or additionally be a list in the first terminal M1 or the monitoring entity 2. This makes a certain randomization of the range possible with which the system is further secured. The formed sum is then matched with the range (and, if applicable, applying the criterion). In step 164, the requested sum range confirmation (or sum range proof) is transmitted from the second terminal M2 to the monitoring entity 2.

[0257] Since a payment transaction (transmitting coin datasets) of a large monetary value can also be split into multiple payment transactions of smaller monetary values, each of which could be below a range, the method defines the range (=limit value) on a terminal-specific and time period-dependent basis, if applicable. The range generally relates to a sum of all transactions within a certain time unit that are received and/or sent by a terminal. Therefore, a mechanism is provided to determine what the sum of all monetary values sent or received by a terminal is within a specific time unit.

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

LIST OF REFERENCE SIGNS

[0259] 1 issuer entity or bank [0260] 2 monitoring entity [0261] 21 command entry [0262] 22a, b entry of a processed electronic coin dataset (predecessor) [0263] 23a, b entry of a processed electronic coin dataset (successor) [0264] 24 signature entry [0265] 25 marking of the validity check [0266] 26 marking of the calculation check [0267] 27a, 27b, 27c marking of the range proof check [0268] 28 marking of the signature check [0269] 29 completion marking [0270] 3 direct transaction layer [0271] 4 monitoring layer [0272] 5 application common wallet [0273] 10, 10′ data memory [0274] 11 display [0275] 12 interface [0276] 13 computing unit [0277] 14 vault module [0278] 15 location detection module [0279] M1 first terminal [0280] M2 second terminal [0281] M3 third terminal [0282] C.sub.i electronic coin dataset [0283] C.sub.j, C.sub.k split electronic coin dataset [0284] C.sub.l electronic coin dataset to be connected [0285] C.sub.m electronic coin dataset to be connected [0286] Z.sub.i masked electronic coin dataset [0287] Z.sub.j, Z.sub.k masked split electronic coin dataset [0288] Z.sub.l masked split coin electronic dataset [0289] Z.sub.m masked coin electronic dataset to be connected [0290] S signed masked electronic coin dataset [0291] v.sub.i monetary value [0292] v.sub.j, v.sub.k divided monetary value [0293] v.sub.l monetary value of an electronic coin dataset to be switched [0294] v.sub.m monetary value of an electronic coin dataset to be connected [0295] r.sub.i concealment value, random number [0296] r.sub.j, r.sub.j concealment value of a split electronic coin dataset [0297] r.sub.m concealment value of a linked electronic coin dataset to be linked [0298] C.sub.i* transmitted electronic coin dataset [0299] C.sub.j*, C.sub.k* transmitted split electronic coin dataset [0300] Z.sub.i* masked transmitted electronic coin dataset [0301] Z.sub.j*, Z.sub.k* masked transmitted split electronic coin dataset [0302] f(C) (homomorphous) one-way function [0303] [Z.sub.i]Sig(SK.sub.1) signature of the issuer entity [0304] [Z.sub.i]Sig(SK.sub.Mx) signature of the terminal [0305] 151-154, 161-164 method steps according to an embodiment example [0306] 901-904 method steps according to an embodiment example [0307] 210, 910 register of the monitoring entity [0308] 220, 920 additional data structure of the monitoring entity

METHOD FOR DIRECTLY TRANSMITTING ELECTRONIC COIN DATASETS BETWEEN TERMINALS, PAYMENT SYSTEM, PROTECTION SYSTEM AND MONITORING ENTITY

Inventors

Cpc classification

Classification Explorer

G06Q20/383

PHYSICS

Classification Explorer

G06Q20/3678

PHYSICS

Classification Explorer

G06Q2220/00

PHYSICS

Classification Explorer

G06Q20/3825

PHYSICS

Classification Explorer

G06Q20/065

PHYSICS

Classification Explorer

G06F21/64

PHYSICS

Classification Explorer

G06Q20/327

PHYSICS

Classification Explorer

G06Q20/3827

PHYSICS

Classification Explorer

G06Q20/02

PHYSICS

Classification Explorer

G06Q20/0655

PHYSICS

Classification Explorer

G06Q20/3823

PHYSICS

Classification Explorer

G06Q20/10

PHYSICS

International classification

Classification Explorer

G06Q20/10

PHYSICS

Classification Explorer

G06F21/64

PHYSICS

Classification Explorer

G06Q20/06

PHYSICS

Classification Explorer

G06Q20/38

PHYSICS

Abstract

Claims

Description