METHOD AND TRANSACTION SYSTEM FOR TRANSFERRING TOKENS IN AN ELECTRONIC TRANSACTION SYSTEM

Description

[0001] The invention relates to methods for transferring tokens, for example, electronic coin records, in an electronic transaction system, for example, in an electronic payment system. The invention also relates to a transaction system.

[0002] The invention uses a method for transmitting tokens between subscriber units.

[0003] The invention relates in particular to the transfer of central bank-issued digital currency (CBDC) as a token. TECHNICAL BACKGROUND OF THE INVENTION

[0004] Security of transactions and the associated transaction data for transferring monetary amounts means protecting the confidentiality of the exchanged data as well as protecting the integrity of the exchanged data and protecting the availability of the exchanged data.

[0005] DE 10 2009 038 645 A1 and DE 10 2009 034 436 A1 disclose systems for transferring monetary amounts in the form of electronic data records. These systems prevent payment with duplicate data records and provide a high degree of security against manipulation. However, these require complex structures and complex encryption and signing processes for the transactions. These are not very practical.

[0006] WO 2016 / 200885 A1 describes a method for encrypting an amount transferred via a blockchain ledger while maintaining the verifiability of the transaction. An obfuscation amount is added to an input value. Then, an output value is generated and encrypted. Both the input value and the output value lie within a range of values, with the sum of any two values ​​within the range not exceeding a threshold. Complex range checks are assigned to each of the input values ​​and the output value. These range checks are intended to prove that the input value and the output value fall within the assigned range of values. Each public key can be signed with a ring signature based on a public key of a recipient in the transaction.This process requires blockchain technology, which must be invoked after receiving an electronic coin record in order to validate the electronic coin record.

[0007] WO 2020 / 212331 A1 and WO 2020 / 212337 A1 each propose a system for the direct transmission of electronic coin data records (eMDs) in a payment method. A decentralized or centralized monitoring layer is provided to anonymously but securely register eMDs and their modifications. Participants in this method can verify the authenticity of the coin data records using masked eMDs that are uniquely assigned to an eMD. This method is computationally intensive and complex due to the centralized or decentralized monitoring instance and the necessary masking of the coin data records. The transmission of the eMD always requires the transmission of a monetary amount and a masking amount.

[0008] DE 10 2019 002 732 A1 discloses the preamble of claim 1. SUMMARY OF THE INVENTION

[0009] The invention is based on the object of creating a method for transferring tokens of a transaction system in which a transaction from the token is secure, yet simpler and less computationally intensive. In particular, a transaction between participating units is to be created. This transaction should be anonymous to third parties. The token should be immediately reusable after receipt in a participating unit, in order to enable a transaction even without a connection to a remote unit, for example, a token reference register or a decentralized ledger. A received token should, on the one hand, be secret from participating units not involved in the transaction.Each participant unit in the transaction system should be able to verify a received token. In particular, multiple spend attempts and attempts to transfer nonexistent token values ​​should be detectable by a participant unit or generally within the transaction system. It should be possible to register a transfer even if a participant unit does not have a communication connection to a token reference register.

[0010] The stated object is achieved by the features described in the independent patent claims. Further advantageous embodiments are described in the respective dependent patent claims.

[0011] In a first aspect, the problem is solved in particular by a method for transmitting tokens in an electronic transaction system. The method comprises the following steps: receiving transmission information from a first subscriber unit in a second subscriber unit; generating a token-specific cryptographic key pair for a token to be transmitted, wherein a public part of the token-specific cryptographic key pair is obtained by applying a cryptographic one-way function to a generated private part of the token-specific key pair, wherein the private part is a token element of the token to be transmitted; sending the generated public part of the token-specific key pair from the second subscriber unit to the first subscriber unit;Generating a registration request for a token reference register of the transaction system, comprising at least one token reference uniquely assigned to the token to be transferred as a token reference to be registered, wherein the token reference has at least one token value of the token and the generated public part of the token-specific key pair as token reference elements, and a token reference assigned to a token of the first subscriber unit as an already registered token reference; Sending from the first subscriber unit to the second subscriber unit a registration confirmation from the token reference register for a successful registration of the token reference to be registered or the registration request for registering the token reference to be registered in the token reference register.

[0012] A transaction system, such as a digital currency system or a digital central bank system, is a system in which at least two, preferably a plurality of, participating units can directly exchange (transfer) digital central bank money in the form of tokens among themselves. The transaction system is thus, for example, a payment transaction system for exchanging monetary amounts in the form of payment tokens.

[0013] A token is a record of a transaction system that is directly exchangeable between participating entities. Upon registration of the token reference in the token reference register, the token is considered transferred, and from that point on, a receiving participating entity is in possession of the token value represented by the token. With the transfer process, the token therefore automatically changes ownership. A token—a record that is transferable independently of a transaction topology, such as blockchain topologies such as Bitcoin, Ethereum, or Neo—can be transferred directly between participating entities without any intermediaries.

[0014] In contrast to the embodiments in WO 2020 / 212331 A1 and WO 2020 / 212337 A1, in this aspect the token is transferred only indirectly by registering it in the token reference register. This eliminates the need to reregister the token after transfer.

[0015] This means that it is no longer necessary for both participant units to have a communication connection to the token reference register.

[0016] The transfer information can be information for initiating a transaction. The transfer information can be a request to settle a monetary claim (purchase price information) by transferring tokens with the corresponding token value.

[0017] The transmission information may be token information.

[0018] The transfer information or token information can be a declaration of intent to transfer the token to be transferred from the first subscriber unit to the second subscriber unit. The token information therefore serves to inform the second subscriber unit that a transfer of a token—for example, to settle a monetary claim against the second subscriber unit—is bindingly intended, without the token itself being transferred.

[0019] The transmission information or token information can be the token value of the token to be transmitted. This informs the second subscriber unit that the first subscriber unit intends to transmit a token with the corresponding token value. At this point, the token has not yet been transmitted.

[0020] In one embodiment of this aspect, the token-specific key pair can be generated in the second subscriber unit. Furthermore, the token reference can be sent from the second subscriber unit to the first subscriber unit before the registration request is sent. In response to the token information, the second subscriber unit generates part of the token, in this case the private part of the key pair, and also generates part of the token reference, in this case the public part of the key pair. The token reference of a token that has not yet been transmitted at that time is provided to the first subscriber unit, so that both subscriber units involved in the transmission know the same part of the token reference.

[0021] In this embodiment of the aspect, the registration request can be sent from the first participant unit to the token reference register. The registration request contains all the information necessary to register the token reference in the token reference register. From the moment of registration, the token is considered transferred. The token, comprising the token value and the private key portion, can be used by the second participant unit to conduct further transactions.

[0022] In this embodiment of the aspect, a registration confirmation can be sent from the token reference register to the first subscriber unit. This notifies the first subscriber unit of the successful registration.

[0023] In this embodiment of the aspect, the first subscriber unit can forward a registration confirmation to the second subscriber unit after the registration step. From this point on, the token is considered transferred, provided all token elements (in particular, the token value) are known to the second subscriber unit.

[0024] Alternatively, after the registration step - preferably after receiving the registration confirmation from the token reference register - the first subscriber unit can directly transfer the token comprising the token value and the public part of the token-specific key pair to the second subscriber unit (TE2).

[0025] In one embodiment of the aspect, the registration request can be sent to the token reference register either from the first subscriber unit or from the second subscriber unit, depending on the presence of a communication connection to the token reference register. Preferably, a registration confirmation is sent from the token reference register to the subscriber unit sending the registration request to the token reference register.

[0026] The first subscriber unit can provide a communication connection between the second subscriber unit and the token reference register if the registration request is to be sent from the second subscriber unit to the token reference register, but the second subscriber unit does not have a communication connection to the token reference register. Or, the second subscriber unit can provide a communication connection between the first subscriber unit and the token reference register if the registration request is to be sent from the first subscriber unit to the token reference register, but the first subscriber unit does not have a communication connection to the token reference register.

[0027] This ensures that not every participant unit necessarily needs a communication connection to the token reference register to transfer and register a token. The communication connection can be tunneled, for example.

[0028] In an alternative embodiment of this aspect, the token-specific key pair can be generated in the first subscriber unit, wherein the token reference is sent from the first subscriber unit to the second subscriber unit before the sending step.

[0029] The token information can be received indirectly by transmitting a token with a token value greater than the required token value. For example, the first subscriber unit transmits a token with a token value greater than the required (to be settled) token value. This is detected in the second subscriber unit, and the difference between the received token value and the required token value is then received as token information (token value of the token to be transmitted).

[0030] In this alternative embodiment of the aspect, the registration request can be sent from the second subscriber unit to the token reference register, wherein the registration request preferably also includes the requested token value and wherein a registration confirmation is preferably sent from the token reference register to the second subscriber unit.

[0031] After the registration step, preferably after receiving the registration confirmation, the token containing the token value and the public part of the token-specific key pair can be considered transferred from the second subscriber unit to the first subscriber unit. Registration in the token reference register is therefore sufficient to transfer the token.

[0032] This aspect design can be used, for example, for the transfer of change in response to an excessive token value. The excessive token value is transferred to the second participant unit with a token, and the change is transferred indirectly only as a token reference.

[0033] In one embodiment, the token is an electronic coin record or payment token for exchanging monetary amounts between participating units. Such a payment token is also colloquially referred to as a "digital coin" or "electronic coin" and represents cash in electronic form.

[0034] Each token in the transaction system is a data record comprising at least two token elements.

[0035] A first token element of each token of the transaction system is a token value, e.g. an asset, a property, a commodity and / or a monetary amount.

[0036] A second token element of each token in the transaction system is a private part of a token-specific key pair. This private part is a secret within the transaction system and is not published and may not be used multiple times. The generation of the private part must be unpredictable. This private part can be a random number. Preferably, the random number is the result of a truly random number generator.

[0037] The token is formed from the token value (first token element) and the private part. This formation preferably involves concatenating these two token elements. Any other type of linking of these two token elements is not excluded by the invention and includes, for example, concatenating them, incorporating them into a TLV data structure, and / or logical linking.

[0038] A token differs from a data record for traditional data exchange or data transfer, as a traditional data exchange, for example, is based on a question-and-answer principle or on intercommunication between the partners in the data exchange. A token, in contrast, is unique and unambiguous within the transaction system. The token is part of a security concept that includes, for example, signatures or cryptographic encryption. A token contains all the data elements required by a receiving participant unit for verification, authentication, and forwarding the token to another participant unit. Intercommunication between the participant units transmitting a token is therefore fundamentally unnecessary with a token.

[0039] Anyone in possession of a token or with unrestricted access to the token and its token elements can exchange (=transfer) this token with another participating entity. Ownership of the token and its at least two token elements (token value and the private part of the token-specific key pair) is therefore equivalent to ownership of the value represented by the token. Here, the token can also be transferred indirectly by registering a token reference.

[0040] Each token in the transaction system is assigned a token reference. This assignment is unique, meaning that each token is assigned exactly one token reference, and each token reference is assigned exactly one token. The token reference is a public record that is verifiably stored in a storage unit of the transaction system's token reference register for each participating unit.

[0041] Both the token and the token reference are unique. This unique mapping creates a one-to-one relationship between the token and the token reference.

[0042] Each token reference in the transaction system is a data record comprising at least two token reference elements.

[0043] The first token reference element of each token reference is the token value of the token uniquely assigned to the token reference. The token value of the token is thus identical to the token value of the associated token reference. For example, the token value of the token reference is a copy of the token value of the associated token.

[0044] A second token element of each token reference in the transaction system is a public part of the token-specific key pair. This public part of the token reference, together with the private part of the token, forms the token-specific key pair. The public part is obtained by applying a cryptographic function to the private part.

[0045] This cryptographic function is a one-way function. This cryptographic function is therefore a mathematical function that is "easy" to compute in terms of complexity theory, but "difficult" or practically impossible to reverse. A one-way function also refers to a function for which no practical inversion is known that can be performed within a reasonable time and with reasonable effort. Preferably, a one-way function is used that operates on a group in which the discrete logarithm problem is difficult to solve, such as a cryptographic method analogous to elliptic curve encryption (ECC for short), using a private key of a corresponding cryptography method. The reverse function, i.e., generating a token (or part of the electronic coin record) from a token reference, is very time-consuming.

[0046] The (mere) knowledge or possession of a token reference does not authorize the use / transfer / issuance of the token value (token reference element). This represents a fundamental difference between the token reference and the token and is a core of the present invention.

[0047] After applying the cryptographic function to the private part of the token-specific key pair, the public part of the token-specific key pair is obtained as the second token reference element.

[0048] The token reference is formed from the token value (first token reference element) and the public part. This formation is preferably the concatenation of these two token reference elements. Any other type of linking of these two token reference elements is not excluded according to the invention and includes, for example, concatenation, insertion into a TLV data structure, and / or logical linking.

[0049] A token reference can preferably be generated by a subscriber unit's electronic wallet. The use of a token reference is not comparable to the use of subscriber unit addresses in a blockchain-based transaction system, since the token reference register according to the invention does not use subscriber unit addresses to prevent traceability of the tokens.

[0050] The registration method includes a receiving step for receiving a token reference in a token reference register as part of a registration request. For example, the registration request is sent by a participant unit of the transaction system.

[0051] The token reference register is a unit of the transaction register that stores the token references, which registers the associated tokens. This register can be a centralized database or storage unit. This register can be a decentralized ledger, for example, in a blockchain topology. The token reference register can maintain a history of the token references and / or registration requests.

[0052] The received registration request is verified by a verification unit in the token reference register. This verifies whether at least one token reference of the received registration request is already stored in the token reference register.

[0053] A token reference is stored only once in the token reference register. Since a token reference for a token exists only once in the transaction system, the verification step can determine whether multiple attempts have been made to spend a token.

[0054] In one embodiment, in the verification step, the verification unit of the token reference register also determines whether the token reference in the received registration request can be assigned to a token. For this purpose, the token reference or a derivative of the token reference or a history of the token reference must be stored in the token reference register, which can be assigned to the token reference of the received registration request.

[0055] In one embodiment, the verification step determines whether the received registration request is syntactically correct. This checks, for example, whether the registration request is plausible, whether a command type was correctly specified in the registration request, whether the token uniquely assigned to the token reference actually exists (can exist), and / or whether a subtraction of token values ​​in the registration request matches a command type specified in the registration request.

[0056] In one embodiment, the verification step determines whether a signature of the registration request is correct.

[0057] In one embodiment, the verification step also determines whether the sum of token values ​​of all token references within the registration request is zero. This involves summing the input and output token values ​​of the registration request. For registration requests originating from subscriber units, the sum of all token values ​​of the registration request must be zero. If the sum is not zero, an additional token value was illegally created in the transaction system, or a token value was destroyed from the transaction system. This makes it easier to detect fraud attempts using nonexistent or illegally generated tokens. Previously, complex zero-knowledge proofs (ZKP) were necessary, which can be eliminated with this procedure.

[0058] The received token reference is stored in a storage unit of the token reference register. Saving the token uniquely assigned to the received token reference is registered in the transaction system. Saving only occurs if the verification step determines that at least one token reference of the received register request is not stored in the token reference register.

[0059] The basic principle of registering a token is that a received registration request is verified to determine whether the token reference assigned to the token is already known in the token reference register. If the token reference is already known, it is not saved again. If the token reference is unknown, it is entered (saved) in the token reference register to be available for future verification and checking steps in the transaction system.

[0060] In one embodiment, the received registration request is signed with the private part of the token-specific key pair in order to check or verify the association of the token reference with the token. If the verification step is successful, i.e., the signature can be verified, then the sender of the registration request must be in possession of the token or have knowledge of the token. This allows for the detection of attempted fraud using nonexistent or illegally generated tokens.

[0061] In one embodiment, the token reference register has a checking unit for checking a sum of token values ​​relating to the received registration request. This checking unit compares the received registration request with a data set in the storage unit and, in particular, checks a total sum of all token values ​​for changes due to the registration request. This allows the validity of the token value to be checked to determine whether a new token value was generated unauthorized. This could also be used to check old registration requests and their success; this registration request history could be used to process duplicate registration requests without burdening the memory unit of the token reference register.

[0062] In one embodiment, the token to be transmitted can have been obtained by a splitting step of a token contained in the first subscriber unit, wherein the following method steps are carried out to split the contained token in the first subscriber unit: splitting the token value of the contained token into a first token partial value and a second token partial value, wherein the sum of the first token partial value and the second token partial value corresponds to the token value of the token to be split; receiving the token reference for the token to be transmitted from the second subscriber unit, comprising the generated public part of the token-specific key pair of the token to be transmitted; generating a token reference in the first subscriber unit for a split token, comprising the second token partial value and a generated public part of a token-specific key pair of the second split token;and generating the registration request comprising the token reference of the contained token of the first subscriber unit, the token reference for the token to be transferred and the token reference for the split token;

[0063] The division can be symmetrical, so that the divided token values ​​are equal. The division can be asymmetrical, so that the divided token values ​​are unequal.

[0064] In one embodiment, the token to be transmitted can be obtained by a switching step of a token contained in the first subscriber unit, wherein the following method steps are performed to switch the contained token in the first subscriber unit: receiving the token reference for the token to be transmitted from the second subscriber unit, comprising the generated public part of the token-specific key pair of the token to be transmitted; generating the registration request comprising the token reference of the contained token and the token reference for the token to be transmitted.

[0065] Switching the token is another modification option. The token references contained in the registration request can be concatenated. If a token is transferred directly from one subscriber unit to another, for example, if a monetary amount is to be transferred as a token value as part of a payment transaction, the sending subscriber unit can now have the token value re-registered to itself. This registers the switch in the token reference register.

[0066] When a token is transferred between two subscriber units, both subscriber units simultaneously have knowledge of the token. To prevent the sending subscriber unit from also using the token on another (third) subscriber unit (so-called multiple token distribution), the transmitted token is preferably switched from the first subscriber unit to the second subscriber unit.

[0067] The token value of the token being switched corresponds to the token value of the token being transferred. Therefore, during the switchover, a token with the same token value but a new private part is registered in the token reference register.

[0068] In a further aspect of the invention, a method for transferring tokens in an electronic transaction system is provided, comprising the following method steps: receiving token information for a token to be transferred from a first subscriber unit in a second subscriber unit; generating a token-specific cryptographic key pair for the token to be transferred in the second subscriber unit, wherein a public part of the token-specific cryptographic key pair is obtained by applying a cryptographic one-way function to a generated private part of the token-specific key pair, wherein the private part is a token element of the token to be transferred;Sending, to the first subscriber unit, a token reference uniquely assigned to the token to be transmitted, wherein the token reference has at least one token value of the token and the generated public part of the token-specific key pair as token reference elements; and switching a token contained in the first subscriber unit to the token to be transmitted or splitting a token contained in the first subscriber unit to obtain the token to be transmitted; sending, from the first subscriber unit to the second subscriber unit, a proof data set comprising the assigned token reference and a token reference of the token to be switched or split, whereupon the token to be transmitted is deemed to have been transmitted from the first subscriber unit to the second subscriber unit.

[0069] This aspect also allows for only indirect transfer of tokens between participating units, and furthermore, the transfer is a purely "offline" transaction without a token reference register. This is because, with this aspect, there is no registration in the token reference register, and the tokens are still not transferred directly between the participating units. By agreement in the token reference register, instead of submitting a registration request to the transaction system, only one evidence record is generated by the first participating unit and exchanged directly between the two participating units. Based on this evidence record, the second participating unit (recipient) can verify the existence and legal possession of the token and can forgo registration in the token reference register. The structure or layout of the evidence record can correspond to the structure or layout of the registration request.Thus, in this aspect, a token can be transferred with reduced effort (no registration in the registry).

[0070] The token is stored in a subscriber unit. The subscriber unit can have a plurality of tokens; for example, the plurality of tokens can be stored in a data storage of the subscriber unit. The data storage can be internal, external, or virtual, for example. In one embodiment, a "connection" can occur automatically upon receipt of a token, so that preferably only one (or a specific number) of tokens is stored in the subscriber unit.

[0071] Preferably, only one token is present in the subscriber unit, so that a splitting step takes place immediately before a token is sent as part of a payment transaction and a connecting step takes place immediately after a token is received as part of a payment transaction.

[0072] The subscriber unit can be, for example, a mobile device such as a smartphone, a tablet computer, a computer, a server, or a machine. The subscriber unit can be a smart card that is inserted into a terminal device in a ready-to-use state.

[0073] The data storage is, for example, the wallet memory of an electronic wallet. The electronic wallet is, for example, a software application stored in an executable manner on a subscriber unit. The electronic wallet can enable the subscriber unit to participate in the transaction system. The electronic wallet can generate a registration request to register a token in a token reference register. Furthermore, the electronic wallet can make modifications (switching, connecting, splitting) to a token and generate any necessary registration requests and send them to the token reference register. Furthermore, the electronic wallet can transfer tokens to another wallet (in another subscriber unit).

[0074] The transfer of the token in the transaction system is preferably atomic.

[0075] The token reference register therefore has knowledge of token references of tokens in the transaction system and also performs the processing or modification of the tokens (token history). Transactions with the tokens are not recorded in the token reference register and take place in a direct transaction layer of the transaction system directly between participating units of the transaction system.

[0076] According to the invention, a token reference register is provided for a transaction system which is configured to carry out the method steps according to the method described above.

[0077] In a further aspect, a transaction system is provided that has a plurality of subscriber units, each configured to directly transfer tokens according to the methods described above.

[0078] The transaction system may comprise: a first subscriber unit configured to send transmission information for a token to be transferred to a second subscriber unit. The first subscriber unit or a second subscriber unit is configured to generate a token-specific cryptographic key pair for the token to be transferred, wherein a public part of the token-specific cryptographic key pair is obtained by applying a cryptographic one-way function to a generated private part of the token-specific key pair, wherein the private part is a token element of the token to be transferred. The transaction system further comprises a token reference register configured to receive a registration request sent by the first subscriber unit or the second subscriber unit.The registration request comprises at least one token reference uniquely assigned to the token to be transferred as a token reference to be registered, wherein the token reference has at least one token value of the token and the generated public part of the token-specific key pair as token reference elements and a token reference assigned to a token of the first subscriber unit as an already registered token reference.

[0079] The transaction system may alternatively comprise: a first subscriber unit configured to send token information for a token to be transferred to a second subscriber unit; a second subscriber unit configured to generate a token-specific cryptographic key pair for the token to be transferred in the second subscriber unit, wherein a public part of the token-specific cryptographic key pair is obtained by applying a cryptographic one-way function to a generated private part of the token-specific key pair, wherein the private part is a token element of the token to be transferred.The second subscriber unit is also configured to send to the first subscriber unit a token reference uniquely assigned to the token to be transmitted, wherein the token reference comprises at least one token value of the token and the generated public part of the token-specific key pair as token reference elements. The first subscriber unit is further configured to switch a token contained in the first subscriber unit to the token to be transmitted, or the first subscriber unit is further configured to split a token contained in the first subscriber unit to obtain the token to be transmitted.The first subscriber unit is then further configured to send, to the second subscriber unit, an evidence data set comprising the associated token reference and a token reference of the token to be switched or split, whereupon the token to be transmitted is deemed to have been transmitted from the first subscriber unit to the second subscriber unit.

[0080] The token reference registry can be an instance of a central currency system and each token can be a central bank digital currency.

[0081] A transaction system can be provided that comprises: a register layer with the token reference register of the type described above for registering token references; and a direct transaction layer with a plurality of participant units, configured for the direct exchange of tokens with one another according to the type described above. No transactions would be logged in the register layer; instead, only token references would be stored, and modifications to tokens would be stored via appropriately adapted token references for the purpose of verifying the validity of tokens. This ensures the anonymity of the participants in the transaction system. The token reference register provides information on request about the token references that are uniquely assigned to the tokens of the transaction system, for example, to prevent multiple issuance of the same token or to verify the authenticity of the token.

[0082] The token reference register's storage unit preferably stores only token references of tokens actually present in the transaction system. As soon as a token is modified and a corresponding (modified) token reference is to be registered, the (old) token references become invalid, and (only) the modified token references are stored in the storage unit.

[0083] The transaction system can send transaction registry data to a transaction registry to manage the tokens. The transaction registry data includes, in particular, a unique transaction identifier, a transaction amount, an identifier of the first participant unit, an identifier of the second participant unit, and the (at least one) token reference of the token in the token reference registry.

[0084] A digital currency system as the transaction system comprises a plurality of the described participant units, the token reference register and optionally a plurality of coin deposit management units and / or a transaction register.

[0085] This solution is particularly advantageous because the high degree of flexibility in the participant units can be offered independently of the token reference register and / or the transaction register. In particular, the token reference register, which already has particularly high demands in a digital currency system, is not slowed down.

[0086] In this case, a subscriber unit can be a secure element that has secure access to one or more tokens in a token memory. The secure element is, for example, integrated into a terminal device in a ready-to-use state. The secure element and / or the terminal device have a special computer program product (electronic wallet), in particular in the form of a secured runtime environment within a terminal device's operating system, a Trusted Execution Environment (TEE), stored on a data storage device, for example, a mobile device, a machine, or an ATM. Alternatively, the secure element is embodied, for example, as special hardware, in particular in the form of a secured hardware platform module, a Trusted Platform Module (TPM), or as an embedded security module, eUICC, eSIM. The secure element provides a trusted environment. SHORT DESCRIPTION OF THE CHARACTERS

[0087] The invention and further embodiments and advantages of the invention are explained in more detail below with reference to figures, whereby the figures merely describe exemplary embodiments of the invention. Identical components in the figures are provided with the same reference numerals. The figures are not to be considered to scale; individual elements of the figures may be exaggeratedly large or oversimplified. Fig. 1 shows an embodiment of a transaction system TS; Fig. 2a shows an overview of inventive commands for tokens; Fig. 2b shows an overview of inventive signed registration requests for the inventive commands; Fig. 3 shows an embodiment of a flowchart of a method according to the invention for transmitting a token based on switching a token; Fig. 4shows an embodiment of a flowchart of a method according to the invention for transmitting a token based on splitting a token; Fig. 5 shows an embodiment of a flowchart of a method according to the invention for transferring a token based on a change transaction; Fig. 6 shows an embodiment of a flowchart of a method according to the invention for transmitting a token without registering the token on the basis of switching a token; and Fig. 7 shows an embodiment of a flowchart of a method according to the invention for transferring a token without registering the token on the basis of splitting a token. DETAILED DESCRIPTION OF EMBODIMENTS

[0088] Fig. 1shows an embodiment of a transaction system TS. The transaction system TS can be a digital central bank currency system. A token issuer (not shown) issues tokens T as digital coin records. The token issuer also requests an initial registration of the tokens T in a token reference register TRR of the transaction system TS (= the central bank).

[0089] The transaction system TS comprises a register layer (TRR layer), in which a token reference register (TRR) is located. The TS also comprises a direct transaction layer (TE layer), in which a plurality of participant units (TE) can be provided. Two participant units (TE1, TE2) are shown as representative units.

[0090] The participant units TE of the transaction system TS are set up to exchange tokens T directly among each other. Fig. 1The tokens are payment tokens, also referred to as digital coins. Each token T can be generated by a token issuer (not shown). Each token T can be split, linked, or switched by any participating unit TE (not shown) and can be generated and deleted by the token issuer TH (not shown). A token issuer TH, for example, is a central bank.

[0091] Transaction records TAD are stored in an optional transaction register TAR. A transaction record TAD will, for example, include the transaction amount, a transaction ID, identifiers for TE1 and TE2, and at least the token reference TR of a token T to be transferred. It can be generated by the subscriber units TE themselves.

[0092] A token T is uniquely represented in the transaction system TS by a token value v and a random number r as token elements. The token value v can be specified in a range from 1 to 2 31 < -1. The random number r can be a number in the range from 0 to 2 256 < -1, i.e., the order of an elliptic curve, for example, secp256r1.

[0093] The random number r is a private part of a token-specific key pair. The random number r is unique and secret in the transaction system TS and may not be published or reused. The generation of the random number r must be unpredictable.

[0094] For example, the token value v is a 32-bit token element of type integer. For example, the random number r is a 32-byte token element of type integer. A subscriber unit TE has exclusive access to this token memory or includes this token memory in a data memory of the subscriber unit TE.

[0095] A token can be stored as a TLV-encoded data record in a token store and then has a unique tag and length information, for example in the following format. name Day (hex) length Token value v Random number r TLV-encoded 42 1 byte 4 bytes 32 bytes Token

[0096] An example of a TLV-encoded token in hexadecimal form is shown below: 42 24 00 00 40 00 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F and is interpreted as follows: "42" is the tag for identifying the TLV-encoded token T; "24" indicates the length, in this case that it is a 36-byte data record; "00 00 40 00" is the token value (integer) v = 16384 and is therefore € 163.84; "00 01 02 03 04 05 06 07 08 09 ... 1D 1E 1F" is the random number r as an integer.

[0097] For each token T, a token reference TR can be stored in the token reference register TRR. The token reference TR comprises the token value v of the associated token T and a public part R of the token-specific key pair. The token reference TR of the token T can be viewed at any time in the register TRR of the transaction system TS. Thus, the token value v of a token T is disclosed by the token reference register TRR.

[0098] The public part R of the token-specific key pair is generated by applying a cryptographic function to the private part r of the token-specific key pair. This function is difficult to reverse and thus provides the transaction system TS with the required security. R = r * G, where G can be, for example, a global parameter of the transaction system TS, e.g., a generator point of an elliptic curve, in this case the secp256r1 curve.

[0099] The token reference TR is then formed by the token value v of the token T and the public part R of the key pair. The token reference TR is thus the link or concatenation of the token value v and the public part R.

[0100] This token reference TR can be sent as a registration request RA, possibly together with a command (see overview in Figures 3a and 3b) regarding the token T to the token reference register TRR.

[0101] Additionally, the registration request RA can be signed with the private part r of the token-specific key pair. Signing makes it possible to verify whether the sender of the token reference TR was in possession of the token T, further increasing the security of the transaction system TS.

[0102] In the subscriber unit TE, the signed registration request RA sig is stored as a so-called proof data record, PR (for Proof), for example in the following format: type Day (hex) length Data PR 4A N bytes

[0103] An example of a PR (=RA sig ) in hexadecimal form is shown below: 4A 81 8F 03 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 30 46 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 and is interpreted as follows (see also Fig. 3 or Fig. 6): "4A" is the tag to identify the TLV proof RA sig_Th ; "81 8F" indicates the length; "03" indicates that it is a switch (=SWITCH) registration request; "11 12 13 14" is the token value va ; "15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35" is the public part R a ; "36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56" is the public part R h ; "30 46 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56" is the signature as an X690 sequence.

[0104] This registration request RA can be sent to the token reference register TRR. This registration request RA is received in the token reference register TRR. After the registration request RA is verified by the token reference register TRR, the token reference TR is stored in the token reference register TRR, thereby registering the token T in the transaction system TS.

[0105] This token reference TR is uniquely assigned to token T and serves to register token T in the transaction system TS. The token reference TR is therefore the public representation of token T from the direct transaction layer (TE layer). The sole knowledge or possession of the token reference TR does not allow the transfer of token T and is not synonymous with the TE being in possession of token T. The token reference TR serves to prevent multiple issuance attempts and checks whether token values ​​v have been generated improperly. Therefore, the token reference TR and, if applicable, the history of token T and the corresponding registration requests RA from subscriber units (TE) are stored in the token reference register (TRR).

[0106] The tokens T are stored, for example, in electronic wallets of a TE. These wallets are, for example, software applications within the subscriber units (TE) or a terminal device in which the TE is integrated and ready for use. A wallet can be set up as an application on a smartphone, a smart card, or a payment terminal. The wallet is used to securely manage the TE's tokens T, generate token references (TR), modify tokens T, and / or exchange tokens T. Wallets are used to communicate with the token reference register (TRR), generate registration requests (RA) to the token reference register (TRR), and / or perform transactions from tokens T to a subscriber unit (TE).

[0107] For a transaction with a participant unit (TE), it is not necessary to have a communication connection to the token reference register (TRR) of the transaction system (TS). The transaction system (TS) is configured to execute a transaction "offline," i.e., without a communication connection to the token reference register (TRR). A corresponding registration of token T can therefore be performed after the transfer of token T to a participant unit (TE).

[0108] The Token Reference Register TRR is a unit of the Transaction System TS and is either a central register or a central database of the Transaction System TS or a decentralized register or a decentralized database (DLT) of the Transaction System TS.

[0109] For example, a token reference TR is transmitted from an electronic wallet as an APDU command(s) to a terminal device (smartphone) as a subscriber unit (TE). An APDU is a combined command / data block of a connection protocol between the secure element and the terminal device. The structure of the APDU is defined by the ISO-7816-4 standard. The terminal device unpacks the APDU command(s) and transmits the data in API calls to the token reference register (TRR), where it is converted into HTTP code.

[0110] The token reference register TRR specifically manages the storage location for the token references TR, shown here as database 1 as an example of a storage unit in the token reference register TRR. The TR for the token T of the subscriber unit TE1 is entered in database 1 as a representative.

[0111] In addition, the token reference register TRR can include at least one verification unit 2. The verification unit 2 of the token reference register TRR verifies registration requests RA. Syntactical correctness or the correct specification of a command in the registration request RA can be verified. A history of old (past) registration requests RA regarding a token T can also be verified. Separating this verification unit 2 from the database 1 distributes the storage and checking tasks and increases the speed of the token reference register TRR.

[0112] In addition, the token reference register TRR can include a verification unit (not explicitly shown) that checks whether the token value v of a received token reference TR changes a total token value Σ in the transaction system TS. If this is the case, then a new token value v has been created or an existing token value v has been destroyed. This is permitted only by privileged entities, such as an issuing entity TH, in the transaction system TS. If such a change to the total sum of token values ​​by a token reference TR of a subscriber unit TE is detected, then fraud can be assumed. This makes it very easy to detect and prevent the illegal generation of token values ​​v.

[0113] The verification of the total token value by the verification unit represents another security concept in the TS transaction system.

[0114] A registration request RA is preferably signed with the private part r. The signature allows the recipient (TRR or TE) to easily verify the syntactical authenticity of the command. This verification is preferably performed in database 1 or verification unit 2. Furthermore, a registration request RA can be syntactically validated, for example, by checking the signature and / or the token reference TR.

[0115] Even if a signature can be verified in a subscriber unit (TE), this does not guarantee that multiple issuance of the same token (T) has not been attempted. Therefore, registration in the token reference register (TRR) is required. Furthermore, the subscriber units (TE) maintain a secure hardware platform. With an available connection to the token reference register (TRR), the token references (TR) are transmitted, and the multiple issuance attempt can be detected in the token reference register (TRR).

[0116] If a token reference TR is not yet known in the token reference register TRR, it is added.

[0117] In Fig. 2a An overview of CO commands that can be performed on a token T is shown. The CO commands can be modifications to an existing token T, for example, "Switch," "Split," or "Merge." The CO commands can also create a token T or destroy an existing token T. Fig. 2a Example command codes are given (0x01 to 0x05), which can then be part of a registration request RA.

[0118] In Fig. 2b An overview of CO commands and their signed registration request syntax RA is shown. Input tokens T and input token references TR are "consumed" for each CO command. Output token references TR are "generated" for each CO command.

[0119] A command CO has the basic structure of the following three elements: command type, input token reference(s), output token reference(s).

[0120] It should be noted that for the CO "Split," "Switch," and "Join" commands, the difference between the token values ​​v of all participating tokens T or token references TR must be zero. In other words, these CO "Split," "Switch," and "Join" commands do not create any token values ​​v and do not destroy any token values ​​v. This can be verified by the CO command type itself or by the verification unit of the token reference register TRR and can be a verification criterion for a registration request RA.

[0121] It should also be noted that only for the commands CO "Create" and "Delete" a difference between the token values ​​v of the involved token T or token references TR is allowed, but only up to the amount of the token value v of the token T and not beyond.

[0122] Each registration request RA can be signed to verify that the sender of the token reference TR also possesses the corresponding token T. An ECDSA scheme can be used as the signature. The registration request RA is preferably signed with the private part r of the token T. For signed registration requests RA sig of the command types CO "Create" and "Delete," an additional signature from a token issuer can be required to ensure that these commands were generated by a privileged unit of the transaction system TS.

[0123] In Fig. 3 An exemplary embodiment of a flowchart of a method according to the invention for transferring a token T between a TE1 and a TE2 based on a switch command of an existing token T a is shown. The required signed registration request RA sig_Ta and a registration confirmation RB with command structure are also shown.

[0124] A token T a is present in TE1. The token T a has a token value va and the private part r of the token-specific key pair. The corresponding token reference TR a is registered in the token reference register TRR for TE1. A token T b with the token value vb is to be transferred between TE1 and TE2.

[0125] To do so, TE1 sends a transmission information Ü or a token information (for example, the token value vb itself) to TE2. This token information can be a declaration of intent from TE1 to TE2 to transfer the token T b - for example, as part of a payment transaction. TE2 then generates a new random number rb , which serves as the private part (the secret) of a new cryptographic token-specific key pair. By applying a cryptographic one-way function (see Fig. 1 ) the public part R b of the key pair is generated in the TE2.

[0126] TE2 then sends the public part R b of the key pair back to TE1. If TE2 already knows the token value v b (e.g., the token value expected in the payment transaction or the token information provided by TE1 is the token value v b ), TE2 can also send the token reference TR b to TE1.

[0127] In the TE1, the token T a is now switched to the token T b to be transmitted. A registration request RA sigTa is then created and sent from the TE1 to the TRR. The registration request RA then contains the command "SWITCH" or a corresponding command code according to Fig. 2a, the input token reference TR a and the public part R b or the output token reference TR 3 . This registration request RA is signed with the random number ra of the token T a. The signed registration request RA sig_Ta is sent from the subscriber unit TE1 to the token reference register TRR. There, the signature is verified. In addition, the token value va is compared with the token value vb. If va = vb and the signature verification is successful, the token reference TR a is deleted from the token reference register TRR or marked as deleted, and the token reference TR b is entered into the token reference register TRR. From this point on, the token T b is registered on the TE2.

[0128] The TRR notifies the TE1 of the successful registration as a registration confirmation (RB). This registration confirmation includes the token reference TR b . To secure the process, this registration confirmation can be signed by the TRR.

[0129] The registration confirmation RB can be sent from TE1 to TE2 to inform TE2 of the successful registration. TE2 can then validate the registration confirmation RB again. This means that the token T b with the token value vb and the private part rb is transferred from TE1 to TE2 without the token having to be transferred from TE1 to TE2 with both token elements.

[0130] The generated public part R b is then transferred to TE1. TE1 takes over the registration with a "SWITCH" command. A confirmation RB is returned, possibly with a signature of the TRR Sig (vb , R b ) for the generated public part R b and the token value vb. A final switchover in TE2 is thus unnecessary, making the process less complex.

[0131] In the Fig. 4An embodiment of a flowchart of a method according to the invention for transmitting a token T b based on splitting a token T a is shown. Also shown are the required signed registration request RA sig_Ta and a registration confirmation RB with command structure.

[0132] A token T a is present in TE1. The token T a has a token value va and the private part r of the token-specific key pair. The corresponding token reference TR a is registered in the token reference register TRR for TE1. A token T b with the token value vb is to be transferred between TE1 and TE2.

[0133] In TE1, the token value va is divided into a first token subvalue vb (the token value to be transferred to TE2) and a further token subvalue vc. The sum of the token value vb and the token value vc must equal the token value va. This ensures that no new token value v is created or destroyed.

[0134] To transfer the token T b , TE1 sends token information (for example, the token value vb itself) to TE2. This token information is a declaration of intent from TE1 to TE2 to transfer the token T b - for example, as part of a payment transaction. TE2 then generates a new random number rb , which serves as the private part (the secret) of a new cryptographic token-specific key pair. By applying a cryptographic one-way function (see Fig. 1 ) the public part R b of the key pair is generated in the TE2.

[0135] TE2 then sends the public part R b of the key pair back to TE1. If TE2 already knows the token value v b (e.g., the token value expected in the payment transaction or the token information provided by TE1 is the token value v b ), TE2 can also send the token reference TR b to TE1.

[0136] In TE1, a new random number rc is generated in parallel, afterward, or before, which serves as the private part (the secret) of another cryptographic token-specific key pair. By applying a cryptographic one-way function (see Fig. 1 ) the public part R c of the key pair is generated in the TE1.

[0137] Now, a registration request RA is created and sent from TE1 to the TRR. For this purpose, TE1 uses the token references TR b and TR c. The registration request RA then contains the "SPLIT" command or the corresponding Fig. 2ashown command code, the input token reference TR a and the output token references TR b and TR c . This registration request RA is signed with the random number ra of the token T a . The signed registration request RA sig_Ta is sent from TE1 to the token reference register TRR. There, the signature is verified and the sum of vb and vc is calculated and compared with the token value va. If va = vb + vc and the signature verification is successful, the token reference TR a is deleted from the token reference register TRR or marked as deleted, and the token references TR b and TR c are entered into the token reference register TRR.

[0138] In one embodiment, the token value difference between the input token reference TR a and the output token references TR b and TR c is calculated in the verification unit 2 of the TRR, and a check is made to determine whether this difference is zero. If the difference is not zero, a token value v was generated or destroyed in an unauthorized manner. Furthermore, a total token value of the transaction system TS can also be checked in the verification unit of the token reference register TRR before or after the registration of the token references TR b and TR c. The total token value in the verification unit must not have changed and must correspond to the value before the registration request was processed in the token reference register TRR.

[0139] From this point on, the token T b is registered to the TE2 and the token T c is registered to the TE1.

[0140] The TRR notifies the TE1 of the successful registration as a registration confirmation (RB). The registration confirmation includes the token references TR b and TR c . To secure the process, this registration confirmation can be signed by the TRR.

[0141] The registration confirmation RB can be sent from TE1 to TE2 to inform TE2 of the successful registration. TE2 can then validate the registration confirmation RB again. This means that the token T b with the token value vb and the private part rb is transferred from TE1 to TE2 without the token having to be transferred from TE1 to TE2 with both token elements.

[0142] Here, too, only the generated public part R b is transferred from TE2 to TE1. TE1 takes over the registration using a split command "SPLIT." A confirmation RB is returned, possibly with a signature of the TRR Sig (vb , R b ) for the generated public part R b and the token value vb. A final switchover in TE2 is thus unnecessary, making the process less complex.

[0143] Not shown in the figure is the additional possibility that in the TE1 an existing token T a is connected to another token T d and the connected token is registered in the TRR as the token T b to be transferred.

[0144] In a TE2, after receiving the token information, the random number rb is generated. Based on this, a public part Rb is then generated. The public part Rb or the token reference TRb is sent from TE2 to TE1. In TE1, the token values ​​va and vd are summed to form the token value vb based on the input tokens Ta and Td. A registration request RA then contains the command "MERGE" or the Fig. 2alisted command code, the two input token references TR a and TR d as well as the output token reference TR 3 . This registration request RA is signed once with the random number ra of the token T a to obtain a first signed registration request RA sig_Ta. This registration request is also signed with the random number rd of the token T d to obtain a second signed registration request RA sig_Td. Both signed registration requests RA sig_Ta and RA sig_Td are sent by the subscriber unit TE1 to the token reference register TRR. There, the signatures of the registration requests RA sig_Ta and RA sig_Td are checked. In addition, the sum of the token values ​​va and vd is calculated and compared with the token value vb. If vb = va + vd and both signature checks are successful, then TR a and TR d are deleted or marked as deleted in the token reference register TRR and the token reference TR b is entered in the token reference register TRR.From this point on, the token T b is registered to the TE2 and the token T a and the token T d of the TE1 are invalid.

[0145] Also not depicted in the figure is the possibility that TE1 does not necessarily have to submit the RA registration request to the TRR. Thus, in the absence of a communication connection between TE1 and the TRR, TE2 can also establish a communication connection with the TRR and forward the communication, for example, within the framework of a VPN or other tunnel communication.

[0146] In the Fig. 5 An exemplary embodiment of a flowchart of a method according to the invention for transferring a token based on a change transaction is shown. Furthermore, the required signed registration request RA sig_Ta and a registration confirmation RB with command structure are shown. The example is based on a switch command (according to Fig. 3 ) is explained.

[0147] A token T a is present in TE2. The token T a has a token value va and the private part r of the token-specific key pair. The corresponding token reference TR a is registered in the token reference register TRR for TE2. A token T demanded with the token value v demanded is to be transferred between TE2 and TE1. The token value v demanded is smaller than the token value va .

[0148] TE2 generates a new random number r back , which serves as the private part (the secret) of a new cryptographic token-specific key pair. By applying a cryptographic one-way function (see Fig. 1 ) the public part R of the key pair is generated in the TE2.

[0149] Instead of splitting the token T a, according to Fig. 5 the token T a and the public part R are sent back to the TE1.

[0150] In TE1, based on the token value va and the knowledge of the requested token value v demanded (as token information), the amount of a token value v back as change can be determined by simple subtraction. Alternatively, TE2 provides the information about the token value v back directly to TE1.

[0151] In TE1 the token reference TR back is then formed by concatenating v back with R back .

[0152] Subsequently, a registration request RA sigTa is created and sent from the TE1 to the TRR. The registration request RA then contains the command "SWITCH" or a corresponding command code according to Fig. 2a, the input token reference TR a , the public part R b or the output token reference TR b and the token value v requested . This registration request RA is signed with the random number ra of the token T a. The signed registration request RA sig_Ta is sent from the subscriber unit TE2 to the token reference register TRR. There the signature is verified. In addition, the token value v back is compared with the sum of va and v back. If v back = va - v requested and the signature verification is successful, then the token reference TR a is re-registered in the token reference register TRR from TE2 to TE1 and the token reference TR back is entered in the token reference register TRR. From this point on, the token T back is registered on the TE2.

[0153] The successful registration is indicated by the TRR to the TE1 as a registration confirmation (RB). This registration confirmation includes the token reference TR. To secure the process, this registration confirmation can be signed by the TRR.

[0154] The registration confirmation RB can be sent from TE1 to TE2 to inform TE2 of the successful registration. TE2 can then validate the registration confirmation RB again. This means that the token T back with the token value v back and the private part r back is valid and transferred from TE1 to TE2 without the token T back having to be transferred with both token elements from TE1 to TE2.

[0155] The generated public part R is then transferred back to TE1. TE1 takes over the registration with a switch command "SWITCH." A confirmation RB is sent back, possibly with a signature of the TRR Sig (v back, R back) for the generated public part R back and the token value v back. A final switchover in TE2 is thus unnecessary, making the process less complex.

[0156] Thus, according to the invention, a combination of payment and change can be executed with a single switching command. The change is registered immediately by TE1, eliminating the need for additional registration by TE2.

[0157] The Fig. 6 shows an embodiment of a flowchart of an inventive method for transferring a token without registering the token based on a token switch. The method is largely similar to the method in Fig. 3, the description of the identical process steps is therefore omitted. The difference to Fig. 3 is that in the Fig. 6 No TRR is required to register the token to be transferred. Instead of a registration request RA (see Fig. 3 ) the TE1 generates an evidence data set PR (see also Fig. 1 with explanations). The evidence data set PR corresponds in structure and layout to the registration request RA. It is missing in the process of Fig. 6 This means that the TRR verifies the switch command, but due to the transaction system requirement, TE2 no longer needs to execute a switch command. This reduces the overhead of the process.

[0158] The Fig. 7 shows an embodiment of a flowchart of an inventive method for transferring a token without registering the token based on splitting a token. The method is largely similar to the method in Fig. 4, the description of the identical process steps is therefore omitted. The difference to Fig. 4 is that in the Fig. 7 No TRR is required to register the token to be transferred. Instead of a registration request RA (see Fig. 4 ) the TE1 generates an evidence data set PR (see also Fig. 1 with explanations). The evidence data set PR corresponds in structure and layout to the registration request RA. It is missing in the process of Fig. 7 This means that the TRR verifies the switch command, but due to the transaction system requirement, TE1 no longer needs to execute a split command. This reduces the overhead of the process. LIST OF REFERENCE SYMBOLS

[0159] CO Command PKey TH public part of the token issuer key pair pKey TH private part of the token issuer key pair R public part of the token-specific key pair r private part of the token-specific key pair RA Registration request PR Evidence data set RA sig_T Registration request signed with private part of the token-specific key pair RA sig_TH Registration request signed with private part of the token issuer key pair PR sig_T Evidence data set signed with private part of the token-specific key pair T Token TE Subscriber unit TE layer Direct transaction layer TRR layer Register layer TR Token reference TRR Token reference register 1 Database, storage unit 2 Verification unit TS Transaction system TW Token value ai Indices for various tokens and token references v Token value Ü Transmission information

Claims

1. Method for transmitting tokens (Tb; Tback) in an electronic transaction system (TS), comprising the following method steps: - receiving transmission information (Ü) from a first subscriber unit (TE1) in a second subscriber unit (TE2); - creating a token-specific cryptographic key pair (rb, Rb; rback, Rback) for a token (T) to be transmitted, wherein a public part (Rb; Rback) of the token-specific cryptographic key pair (rb, Rb; rback, Rback) is obtained by applying a one-way cryptographic function to a generated private part (rb; rback) of the token-specific key pair (rb, Rb; rback, Rback), the private part (rb; rback) being a token element of the token (Tb; Tback) to be transmitted; - creating a registration request (RA) in the first subscriber unit (TE1) for a token reference register (TRR) of the transaction system (TS) at least comprising a token reference (TRb; TRback) uniquely assigned to the token to be transmitted (Tb; Tback) as a token reference to be registered and a token reference (TRa; TRc) assigned to a token (Ta; Tc) of the first subscriber unit (TE1) as a previously registered token reference (TRa; TRc); characterized in that the token-specific cryptographic key pair is created in the second subscriber unit (TE2); - sending the generated public part (Rb; Rback) of the token-specific key pair (rb, Rb; rback, Rback) from the second subscriber unit (TE2) to the first subscriber unit (TE1); the token reference (TRb; TRback) uniquely assigned to the token (Tb; Tback) to be transmitted comprises at least one token value (vb; vback) of the token (Tb; Tback) and the generated public part (Rb; Rback) of the token-specific key pair (rb, Rb; rback, Rback) as token reference elements; and - sending from the first subscriber unit (TE1) to the second subscriber unit (TE2), a registration confirmation (RB) of the token reference register (TRR) for the successful registration of the token reference (TRb; TRback) to be registered, or the registration request (RA) to register the token reference (TRb; TRback) to be registered in the token reference register (TRR).

2. Method according to Claim 1, wherein the transmission information (Ü) is a token-transmission declaration of intent to transmit the token (Tb; Tback) to be transmitted from the first subscriber unit (TE1) to the second subscriber unit (TE2).

3. Method according to Claim 1 or 2, wherein the transmission information (Ü) is the token value (vb; vback) of the token (Tb; Tback) to be transmitted.

4. Method according to any one of the preceding claims, wherein, before the sending of the registration confirmation (RB), the registration request (RA) is sent from the first subscriber unit (TE1) to the token reference register (TRR) and wherein the registration confirmation (RB) is preferably sent from the token reference register (TRR) to the first subscriber unit (TE1).

5. Method according to any one of the preceding claims, wherein the first subscriber unit (TE1), after obtaining the registration confirmation (RB), transmits the token (Tb) comprising the token value (vb) and the public part (Rb) of the token-specific key pair (rb, Rb) to the second subscriber unit (TE2).

6. Method according to any one of the preceding Claims 1 to 3, wherein, depending on the presence of a communication link to the token reference register (TRR), the registration request (RA) is sent to the token reference register (TRR) either from the first subscriber unit (TE1) or from the second subscriber unit (TE2), and wherein a registration confirmation (RB) is preferably sent from the token reference register (TRR) to the subscriber unit (TE1, TE2) sending the registration request (RA) to the token reference register (TRR).

7. Method according to Claim 6, wherein the first subscriber unit (TE1) provides a communication link between the second subscriber unit (TE2) and the token reference register (TRR) if the registration request (RA) is to be sent from the second subscriber unit (TE2) to the token reference register (TRR), but the second subscriber unit (TE2) has no communication link to the token reference register (TRR); or wherein the second subscriber unit (TE2) provides a communication link between the first subscriber unit (TE1) and the token reference register (TRR) if the registration request (RA) is to be sent from the first subscriber unit (TE1) to the token reference register (TRR), but the first subscriber unit (TE1) has no communication link to the token reference register (TRR).

8. Method according to any one of the preceding Claims 1, 2 or 3, wherein the transmission information is received indirectly by a transmission of the token (Ta) of the first subscriber unit (TE1) with a token value (va) greater than a claimed token value (vclaimed).

9. Method according to any one of the preceding Claims 1, 2, 3 or 8, wherein the registration request (RA) is sent from the second subscriber unit (TE2) to the token reference register (TRR), wherein the registration request (RA) also comprises the claimed token value (vclaimed) and wherein the registration confirmation (RB) is preferably sent from the token reference register (TRR) to the second subscriber unit (TE2).

10. Method according to any one of the preceding Claims 1, 2, 3, 8 or 9, wherein, after the registration confirmation (RB) has been obtained, the token (Tback) comprising the token value (vback) and the public part (Rback) of the token-specific key pair (rback, Rback) is deemed to have been transmitted from the second subscriber unit (TE2) to the first subscriber unit (TE1).

11. Method according to any one of the preceding claims, wherein, for the purpose of registering in the token reference register (TRR), it is verified whether the at least one token reference (TRb) of the received registration request (RA) is stored in the token reference register (TRR), and storing the at least one token reference (TRb) in a storage unit of the token reference register (TRR) for the purpose of registering the token (Tb) uniquely assigned to this token reference (TRb) in the transaction system (TS), if it is determined in the verification step that the at least one token reference (TRb) of the received registration request (RA) is not stored in the token reference register (TRR).

12. Method according to any one of the preceding claims, wherein the token (Tb) to be transmitted is obtained by a splitting step of the token (Ta) of the first subscriber unit (TE1), wherein, in order to split the token (Ta) of the first subscriber unit (TE1), the following method steps are carried out: - splitting the token value (va) of the token (Ta) of the first subscriber unit (TE1) into a first token subvalue (vb) and a second token subvalue (vc), wherein the sum of the first token subvalue (vb) and the second token subvalue (vc) corresponds to the token value (va) of the token (Ta) to be split; - receiving the token reference (TRb) for the token (Tb) to be transmitted from the second subscriber unit (TE2) having the generated public part (Rb) of the token-specific key pair (rb, Rb) of the token (Tb) to be transmitted; - creating a token reference (TRc) for a split token (Tc) in the first subscriber unit (TE1) having the second token subvalue (vc) and a created public part (Rc) of a token-specific key pair (rc, Rc) of the second split token (Tc); and - creating the registration request (RA) comprising the token reference (TRa) of the token (Ta) of the first subscriber unit (TE1), the token reference (TRb) for the token (Tb) to be transmitted and the token reference (TRc) for the split token (Tc).

13. Method according to any one of the preceding Claims 1 to 11, wherein the token (Tb) to be transmitted is obtained by a switching step of the token (Ta) of the first subscriber unit (TE1), wherein, in order to split the token (Ta) of the first subscriber unit (TE1), the following method steps are carried out: - receiving the token reference (TRb) for the token (Tb) to be transmitted from the second subscriber unit (TE2) having the generated public part (Rb) of the token-specific key pair (rb, Rb) of the token (Tb) to be transmitted; - creating the registration request (RA) comprising the token reference (TRa) of the token (Ta) of the first subscriber unit (TE1) and the token reference (TRb) for the token (Tb) to be transmitted.

14. Transaction system (TS) comprising a plurality of subscriber units (TE1, TE2), each configured for the direct transmission of tokens (T) according to any one of the preceding claims.

15. Transaction system (TS) according to Claim 14, comprising: - a first subscriber unit (TE1), configured for sending transmission information (Ü) for a token to be transmitted (Tb; Tback) to a second subscriber unit (TE2); - a second subscriber unit (TE2), configured for creating a token-specific cryptographic key pair (rb, Rb; rback, Rback) for the token (T) to be transmitted, wherein a public part (Rb; Rback) of the token-specific cryptographic key pair (rb, Rb; rback, Rback) is obtained by applying a one-way cryptographic function to a generated private part (rb; rback) of the token-specific key pair (rb, Rb; rback, Rback), the private part (rb; rback) being a token element of the token (Tb; Tback) to be transmitted; - a token reference register (TRR), configured for receiving, from the first subscriber unit (TE1) or the second subscriber unit (TE2), a registration request (RA) comprising at least one token reference (TRb; TRback) uniquely assigned to the token (Tb; Tback) to be transmitted as a token reference (TR) to be registered, wherein the token reference (TRb; TRback) comprises at least one token value (vb; vback) of the token (Tb; Tback) and the generated public part (Rb; Rback) of the token-specific key pair (rb, Rb; rback, Rback) as token reference elements and a token reference (TRa; TRc) assigned to a token (Ta; Tc) of the first subscriber unit (TE1) as a previously registered token reference (TRa; TRc).

16. Transaction system (TS) according to either one of Claims 14 and 15, wherein the token reference register is an instance of a central currency system and each token is a digital central bank currency.