Secure register, transaction unit, electronic token transaction system and search service method

Abstract

The present invention relates to a secure register unit within an electronic token transaction system, preferably a lookup service, comprising: an input device configured to receive a hash value based on user information; a storage device configured to store a link between the received hash value and a secure token transaction unit identifier of a secure token transaction unit of the user, where the storage device is configured to store a plurality of said links; and an output device configured to send the secure token transaction unit identifier to the requesting secure token transaction unit in accordance with a request from any secure token transaction unit of the electronic token transaction system. The invention also relates to a secure transaction unit. The invention further relates to an electronic token transaction system, in particular to an electronic payment transaction system. The invention also relates to a method for providing a lookup service.

Description

Technical Field

[0001] The present invention relates to a security register unit. The present invention also relates to a security transaction unit. The present invention also relates to an electronic token transaction system, in particular an electronic payment transaction system. The present invention also relates to a method for providing a search service. Background Art

[0002] Tokens (also called digital assets, electronic coins, coin datasets) can represent any digital assets, in particular digital currencies, preferably central bank digital currencies, CBDCs for short. These tokens are issued and deleted by the issuing unit of the token trading system, such as the issuing institution, central bank unit or commercial bank unit, hereinafter also referred to as security token issuing unit.

[0003] There are different technical methods for exchanging electronic tokens such as digital assets (e.g., digital currencies such as CBDC) issued by a central bank within an electronic token trading system. Summary of the invention

[0004] According to the first method, the tokens are cryptographically protected only by the central bank unit, and the cryptographically protected tokens are exchanged directly between the token exchange units (also called secure wallets and / or secure elements) of the participants in the electronic payment system in an encrypted manner. The exchanged tokens can also be stored in an encrypted manner. The token exchange unit can verify the authenticity of the token based on cryptographic security (such as keys and signatures), and check the validity of certificates from the central bank and / or other token exchange units within the certificate hierarchy, for example, in advance via online access or following the system's offline protocol.

[0005] According to the second approach, tokens are stored in a centralized or decentralized blockchain / distributed ledger of a payment transaction system, organized, for example, by a central bank unit. For payment transactions, the ownership of the token record is changed in the blockchain, for which a large amount of information (sender / receiver / amount) is required and / or even published. The sender and receiver of the token need to access the blockchain online at the time of the transaction.

[0006] According to an advantageous third method, such as described in WO 2020 / 212 331 A1, tokens are stored in a token exchange unit (also called a wallet or a payment application unit or a secure element) for direct exchange between users of an electronic token exchange system. For security, verification and registration purposes, a central token reference register stores the token references of all valid tokens without knowing the tokens themselves. Thus, a user can check the validity of a received token with a dedicated request sent to the token reference register. The token reference register only stores the token reference of the corresponding token. Each user of the token exchange system can further modify the token, for example, the ownership of the token can be switched from one user to another (switch modification), the token can be split into multiple tokens, for example, for obtaining a token with a reduced monetary value (split modification), and / or multiple tokens can be merged into a single token, for example, for obtaining a token with a higher monetary value (merge modification). Digital signatures are used to further enhance security.

[0007] Electronic token transactions and / or the storage of tokens and any associated transaction data and / or stored data in electronic token transaction systems must be secure, and therefore, means must be implemented to protect the confidentiality, privacy, integrity and availability of exchanged and / or stored token data. This is particularly true for electronic payment transactions and associated payment transactions and payment storage devices in which monetary value is linked to each token.

[0008] In one aspect, each token transaction unit may include a unique transaction unit identifier (also referred to as a wallet ID). The transaction unit identifier may need to be known from another transaction unit within a token transaction in an electronic token transaction system, for example, during information or authentication prior to a token transaction; and / or for cryptographically protecting a token transaction; and / or for an anonymous or pseudonymous protocol for a token transaction; and / or for registering a token reference.

[0009] On the other hand, security, anonymity (or pseudonymity) and confidentiality must be ensured at all times to avoid attacks such as double spending of tokens and / or spending tokens with fraudulently generated (not actually existing) monetary value.

[0010] ID directory services (lookup services) are known, where links are stored between known user information (such as an email address or phone number) and internal system IDs (such as a bank account). Each third party can retrieve the system ID by using the known or public user information to retrieve the internal system ID.

[0011] However, such ID directory services are often targeted by attackers to retrieve personal data, and access to such sensitive user information needs to be protected.

[0012] The above objects are solved by the features of the independent patent claims. Further advantageous embodiments are described in the dependent claims.

[0013] In one aspect of the present invention, there is provided a secure register unit within an electronic token transaction system, which is preferably a lookup service.

[0014] The security register unit comprises an input device configured to receive a hash value. A hash value (also called a hash code, hash digest or hash) is the result of a cryptographic hash function or hash algorithm (such as SHA-1, SHA-2, SHA-3, MD5, BLAKE2, BLAKE3, etc.). The hash value is based on user information, which means that the cryptographic hash function takes the user information as input data for the hash value generation. Advantageously, the hash function is a conventional one-way function, which means that if the same hash function is used (e.g., with its parameter settings), the same hash value is always generated based on the user information, but based on the hash value, it is almost impossible or in the best case impossible to generate (return) the user information. If only the hash value (and not the user information) is used in the security register unit, the user information cannot be displayed even if the security register unit is read out.

[0015] A user can be a natural person, a legal entity, an organization and / or a machine, such as an IoT element.

[0016] User information is also referred to as user identification, user number, individual user number and / or customer reference number. User information can be one or more of the following: the user's email address; the user's mobile phone number; an international mobile subscriber identity used to identify the user in a mobile network; the user's bank account number; a consumer's reference / ID number; a tax number used to identify the user at the tax office; a passport number used to identify the user's passport; an ID card number used to identify the user's ID card; a pseudonymous identifier (e.g. a name or number or data set chosen by the user, such as a username or identification number within an Internet account); a driver's license card number used to identify the user's driver's license; a national or international digital identifier that can be assigned to a citizen (user) during the registration process with an official body (such as a resident registry or tax office or vehicle registration body); a hardware number and / or a serial number.

[0017] The security register unit further comprises a storage device configured to store a link between the received hash value and a security token transaction unit identifier of the user's security token transaction unit. The security token transaction unit identifier uniquely assigns the user's transaction unit within the electronic token transaction system. The storage device may be configured to store a plurality of links. The storage device may be constructed in any suitable form, such as by performing a lookup service using a lookup table structure to store one or more links; and / or a database structure.

[0018] The security register unit further comprises an output device configured to send the security token transaction unit identifier to the requesting security token transaction unit upon a request from any security token transaction unit of the electronic token transaction system.

[0019] The request from any security token transaction unit to send a secure transaction unit identifier may be based on a received hash value of the user information (received from the input device).

[0020] With this aspect, it is ensured that no plaintext user information is stored in the secure register unit. Therefore, in the event that the register unit is attacked and read out, only the user's hash value is leaked, not the user information itself, and therefore, there is no possibility of leaking sensitive user information.

[0021] Different user information for the same user (e.g., (1) phone number and (2) bank account number) will result in different hash values. The security register unit ensures that these different hash values ​​point to the same security token transaction unit identifier.

[0022] In a preferred embodiment, the hash value is based on the user information and the additional information. Here, the additional information may serve different purposes and / or may be used to protect the link between the user information and the security token transaction unit identifier and / or may help avoid possible collisions of hash values ​​in the security register unit when different user information results in the same hash value, which may avoid unique resolution of the link to receive the correct security token transaction unit identifier. Alternatively and / or additionally, the additional information is used to further individualize and / or categorize the hash value.

[0023] In a preferred embodiment, the additional information is a type indicator. The type indicator is configured to indicate the type of user information on which the hash value is based. Thus, it is indicated which type of user information is used, and this is used to avoid conflicts.

[0024] User information of different users may result in the same hash value. Type indicators would be an appropriate tool to avoid generating the same hash value, thus avoiding hash value collisions.

[0025] The first type indicator may indicate user information generated by a communication service provider unit. The user information may be a user's phone number, international mobile subscriber number, or email address. This type indicator may strengthen the user information because it is generated by a communication system that needs to have a unique identifier. Therefore, the uniqueness and validity have a higher level than other types.

[0026] The second type indicator may indicate user information generated by the financial service provider unit. The user information may be a bank account number or a customer reference number of a user of the financial service provider unit. The type indicator may be used to distinguish between different security token transaction units used by the same user for different financial service providers (one wallet per bank per user).

[0027] The third type of indicator may indicate user information generated by a government service provider unit. The user information may be a user's tax number, passport number, ID card number, registration number, or driver's license card number. This type of indicator may reinforce the user information because it is generated by a government agency, and therefore, its origin, uniqueness, and validity may have a higher level than other indicator types.

[0028] A fourth type of indicator may indicate user information generated by a private service provider unit such as an app store, media (audio, video, book) service. The user information may be a customer reference number of the user. The origin, uniqueness, and validity of this type of indicator may be of a lower level than other indicator types.

[0029] The fifth type indicator may indicate user information generated by a manufacturer unit (e.g., a manufacturer of a secure element or user device). The user information may be a serial number or a hardware number. This type indicator may be used for an Internet of Things (IoT) or a Machine-to-Machine (M2M) device, which may be a user within a security token trading system.

[0030] The sixth type indicator may indicate user information generated by a private company unit or an enterprise unit or a social club unit. Such a unit may be a unit of the user's employer. Here, the user information may be a unique employee identification number. This type indicator may be used to enable an employer to transfer tokens to an employee (user) without the employer knowing the security token transaction unit identifier. As another example, such a unit may be a unit of a sports club unit of the user. Here, the user information may be a member identification number. This type indicator may be used for a sports club to transfer tokens to club members (users) without the sports club knowing the security token transaction unit identifier.

[0031] In a preferred embodiment, the additional information is a special tag. The tag is additional data used to further individualize the hash value within the electronic token transaction system.

[0032] The special tag may be a time tag to indicate the time frame in which the hash value was generated. The time frame may be a year, a quarter of a year, a month, a week, or a day in which the hash value was generated. Therefore, the extension of the time frame change will cause the user information to expire. This ensures the automatic expiration of the user information and ensures privacy by designing that for each time frame (such as a year, a quarter of a year, a month, a week, a day), the user of the security token trading system must actively decide to update the user information. Shorter time frames (e.g., months, weeks, or days) can be used for short-term occasions, such as vacations, hospitalizations, etc.

[0033] The special tag can be a secret tag, also called a salted tag, to obfuscate the user information. It can be a random data set, which is also stored in the security register unit (known only to the operator of the security register unit). If some parts of the security register unit are inadvertently leaked, a much higher amount of computational operations is required to calculate (return) the user information. By using a secret tag, the attacker can no longer form a value in the hash value to find the mapping by trial and error.

[0034] The special tag can be configured to indicate additional service-specific data. Due to the addition of the service-specific data, in the event that the register unit is leaked, it is still not possible for an attacker to easily obtain user information without using the specific data within the service.

[0035] The special tag may be a service provider indicator for indicating the service provider. The indicator may be unique within the token transaction system.

[0036] The special tag may be a tag known to the user of the security token transaction unit and configured to be issued to the requesting security token transaction unit for insertion into the request to the security register unit. Such a tag may be a secret selected by or provided to the user, such as a personal identification number (PIN). This PIN is provided to the requesting security token transaction before issuing the request token transaction unit identifier. Thus, a brute force attack in which all user information is used to retrieve the hash value will fail, as the attacker will also need the special tag (PIN) to calculate the hash value registered in the security register unit.

[0037] In a variant, the special tag is a one-time identification, such as or comparable to a transaction number TAN, on which basis the link between the hash value (based on the user information and the special tag as a one-time identification) and the security transaction unit identifier is deleted by the security register unit upon successful request by another security token transaction unit (received at the output device).

[0038] In a preferred embodiment, the security token transaction unit identifier is encrypted before storage, and the encrypted transaction unit identifier is stored in the secure register unit. Therefore, even if the operator of the register unit wanted to for some reason, the register unit (lookup service) cannot disclose the security token transaction unit identifier.

[0039] In a preferred embodiment, the stored link comprises an encrypted security token transaction unit identifier and a trusted service provider unit identifier. The encrypted security token transaction unit identifier may carry information about the trusted service provider unit for decryption purposes.

[0040] The trusted service provider unit may be a financial service provider unit.

[0041] The encryption may be performed by the trusted service provider unit, or may be performed by the secure register unit based on a cryptographic key received from the trusted service provider unit. The trusted service provider unit does not have to perform the encryption, or may not be informed of the encryption, and only provide the cryptographic key. The encrypted security token transaction unit identifier may then carry information about the trusted service provider unit for decryption purposes. In any case, the trusted service provider unit may never know which encrypted security token transaction unit identifier hash value was selected.

[0042] Upon request from any security token transaction unit of the electronic token transaction system, the output device may send the encrypted security token transaction unit identifier to the trusted service provider unit corresponding to the trusted service provider unit identifier for decrypting the encrypted security token transaction unit identifier.

[0043] In a preferred embodiment, the storage means comprises at least a first storage means hosted by a first service provider unit, the first service provider unit being configured to store a link between the received hash value and the first part of the security token transaction unit identifier. The storage means also comprises a second storage means hosted by a second service provider unit, the second service provider unit being configured to store a link between the received hash value and the second part of the security token transaction unit identifier. Thus, the register unit is at least partially operated by a service provider unit, preferably a financial service provider unit, such as a service provider unit that issues or manages the security token transaction unit. The term "at least" in this embodiment means that the number of storage means for storing the parts of the security token transaction unit identifier is not limited to two. The number of storage means for storing the parts of the security token transaction unit identifier may be two, three, four, five, six, ten or even more than ten. The number of storage means for storing the parts of the security token transaction unit identifier may be arbitrary and may be higher.

[0044] In a preferred embodiment, the output means comprises a first output means hosted by a first service provider unit and a second output means hosted by a second service provider unit. Thus, the register unit is at least partially operated by a service provider unit, preferably a financial service provider unit, such as a service provider unit that issues or manages a security token transaction unit.

[0045] Upon request from any security token transaction unit to the first output device, the first output device is configured to send a first portion of the security token transaction unit identifier to the security token transaction unit that issued the request, wherein the first portion includes address information about a second portion of the security token transaction unit identifier. Thus, when it is intended to identify a user based on known user information, the security token transaction unit requests at the first service provider unit to receive the first portion of the security token transaction unit identifier and address information from which the remaining portion of the security token transaction unit identifier can be obtained. Thus, several different instances need to be addressed to collect a complete security token transaction unit identifier.

[0046] Upon request from any security token transaction unit to the second output device, the second output device is configured to send the second part of the security token transaction unit identifier to the security token transaction unit that issued the request, wherein the second part includes address information about the first part of the security token transaction unit identifier. Thus, when it is intended to identify a user based on known user information, the security token transaction unit requests at the second service provider unit to receive the second part of the security token transaction unit identifier and the address information from which the remaining part of the security token transaction unit identifier can be obtained. Therefore, it is necessary to address several different instances to collect the complete security token transaction unit identifier.

[0047] Here, the security token transaction unit identifier is split (divided) into two parts. However, the number of parts into which the security token transaction unit identifier is split is not limited herein. However, the number of parts should not exceed a certain number, such as five, so as not to reduce the convenience of the user when trying to receive the security token transaction unit identifier.

[0048] Therefore, by providing only partial information to the requesting transaction unit (third party), the link (mapping) between the hash value and the security token transaction unit can be further protected.

[0049] In another aspect of the present invention, a security token transaction unit for managing token transactions in an electronic payment transaction system is provided. The security token transaction unit includes means for transmitting a request for receiving a security token transaction unit identifier of another security token transaction unit of the electronic token transaction system to the security register unit as described above, the request including user information of the other security token transaction unit, wherein the security token transaction unit identifier uniquely assigns the other security token transaction unit to another user within the electronic token transaction system.

[0050] Preferably, the security token transaction unit further comprises a control device configured to generate a first level hash value, wherein the first level hash value is based on user information. Thus, the user may perform a first level hash to create a hash value and may include additional information as described above. Thus, the user information is not leaked to the register unit or the hash unit that performs the hash to receive the hash value of the register unit.

[0051] Alternatively, when the user information is generated, a hash value is also generated and provided to the user. This ensures the validity of the hashed user information within the unit storage device of the register.

[0052] Preferably, the security token transaction unit further comprises means for exchanging one or more tokens with other security token transaction units in the electronic token transaction system. Thus, the security transaction unit is able to receive tokens from another security transaction unit in the system and / or transmit tokens to another security transaction unit in the system.

[0053] Preferably, the security token transaction unit further comprises means for transmitting a registration request to a token reference register of the electronic transaction system to register the token in the electronic payment transaction system.

[0054] The control device of the security transaction unit is further configured to generate one or more token references, in particular according to the security transaction unit is processing a modification command (replacement request), the modification command is preferably one or more of a switch command, a merge command and a split command, wherein the modification command is only executed for tokens with the same token type information. For further details related to these modification commands, reference is made to WO 2020 / 212 331 A1 and WO 2020 / 212 331 A1. This enables the security token transaction unit to participate in the advantageous third method as described above.

[0055] A security token transaction unit (as described herein), also referred to as a security wallet, a security token management unit; a token wallet; and / or a wallet may be used to locally manage tokens in the security element itself and / or modify tokens and register tokens in an electronic token transaction system. Tokens may be stored in a token storage device that is also managed by a token wallet.

[0056] Alternatively or additionally, the security token transaction unit may be a security account wallet of the second or third method described above, which is also referred to as a security account management unit. Such a security account wallet is used to manage tokens not in the security element itself, but in a decentralized ledger (such as a blockchain) or a centralized ledger (such as a database that stores tokens centrally in an electronic token transaction system). The management, modification and / or registration of tokens in the electronic transaction system is initiated by the security account-wallet, however, token transactions or token storage are performed away from the security element or service provider unit.

[0057] Each security token transaction unit includes a security token transaction unit identifier, also known as a wallet ID or wallet identification data. The security token transaction unit identifier is assigned to a specific security token transaction unit and is used to uniquely identify the security token transaction unit in the electronic token transaction system. The security token transaction unit identifier is preferably stored in a specific secure wallet.

[0058] The security token transaction unit identifier may be generated at a unit issuing the security token transaction unit, such as a financial service provider unit or a central entity in the transaction system. The generation may include encoding data by a control device of the issuing unit. In this case, the service provider unit may encode the security token transaction unit identifier. The encoding is performed to assign the security token transaction unit identifier to the security token transaction unit to be issued. Each token transaction conducted by the security token transaction unit and / or each token managed (e.g. stored) by the security token transaction unit may be a local protocol, and the protocol may be checked in the event of a suspicious transaction or fraud pattern being identified.

[0059] Alternatively, the security token transaction unit identifier may be generated by an official body, a security token issuing unit (e.g. a central bank unit). In this case, the security token transaction unit identifier may be received by a control device of a security token transaction unit issuing unit or a security register unit.

[0060] In a preferred embodiment, the security token transaction unit identifier is a mandatory data transmitted between individual users in an electronic transaction system for direct exchange of tokens. This may be a system requirement to ensure a high standard of security, and in this case, the security token transaction unit identifier is used not only to uniquely identify the security token transaction unit, but also to identify the "real" user by parsing the user information using the security register unit.

[0061] In another embodiment, the security token transaction unit identifier includes a plurality of data fields. One or more other data fields of the plurality of data fields may include a version value expressing the current version of the security token transaction unit identifier format used.

[0062] One or more other data fields of the multiple data fields of the security token transaction unit identifier may include a token issuing unit identifier expressing a token issuing unit within the electronic token transaction system. With such data fields, multi-currency token transactions or type-related token transactions can be implemented. The first identifier can be used to identify a first token issuing unit that issues a first currency or a first type of token, such as a first central bank or a first financial service provider unit, and the second identifier can be used to identify a second token issuing unit that issues a token of a second currency, such as a second central bank or a second financial service provider unit. For greater clarity: an electronic token transaction system may include more than one token issuer instance. For example, a first financial service provider unit (such as commercial bank A) may issue token-A, and a second financial service provider unit (such as commercial bank B) may issue token-B. Token A always represents a liability relative to the first financial service provider unit, even if the token A is managed by the second financial service provider unit for any reason. Token B always represents a liability relative to the second financial service provider unit, even if the token B is managed by the first financial service provider unit for any reason.

[0063] One or more other data fields of the multiple data fields of the security token transaction unit identifier may include an identifier of a service provider unit and / or a smart card producer and / or a card manufacturer and / or a card issuer to identify the service provider unit and / or a smart card producer and / or a card manufacturer and / or a card issuer or other stakeholders in the token transaction system.

[0064] Preferably, the security token transaction unit identifier further comprises a data element for a type value configured to identify the type of the digital identification data.

[0065] Preferably, the security token transaction unit identifier further comprises a data element for a count value configured to identify the number of security token transaction units issued by the security service provider unit.

[0066] Preferably, the security token transaction unit identifier is inserted into the subject name data field of a cryptographic certificate used within a token transaction or within the storage of a token within an electronic token transaction system. Since the certificate can be used to clearly identify the user in a token transaction / storage, no additional data set is required to derive the user in the case of suspicious transactions and / or suspiciously stored tokens.

[0067] Each combination as mentioned herein may refer to a cascade, which is a logical combination used in information technology.

[0068] In one embodiment, the security token transaction unit is a secure element operably connected to an electronic device of a participant in an electronic payment system.

[0069] In one embodiment, the security token transaction unit is a secure wallet hosted at the service provider unit.

[0070] The control device may be configured to access a token memory, preferably a token memory of the secure transaction unit.

[0071] The secure transaction unit may include a token storage as a physical entity. The secure token transaction unit may be configured to access the token storage. The token storage may be a token store of the secure transaction unit. Each secure transaction unit in the transaction system may include its own token storage.

[0072] From such a token store accessible to the security token trading unit, each token may be transferred to any other security token trading unit, for example a security token trading unit owned by a client of the security token trading unit.

[0073] The security token transaction unit may be a secure wallet, which may be a hardware security module built into hardware or software to achieve tamper-proof and secure access to the tokens.

[0074] On the other hand, an electronic token transaction system is provided, which includes a plurality of security token transaction units as described above; one or more security register units as described above, each preferably being a lookup service within the electronic token transaction system, wherein each storage device is configured to store a plurality of links between a received hash value and a security token transaction unit identifier of a user's security token transaction unit, wherein the security token transaction unit identifier uniquely assigns a security token transaction unit of a user within the electronic token transaction system.

[0075] Preferably, the electronic token trading system also includes a security token issuing unit, which has a minting unit, which is configured to generate new tokens to be issued in the electronic token trading system; and a melting unit, which is configured to delete the tokens to be deleted from the electronic trading system; one or more security token reference register units, used to register tokens of the electronic trading system.

[0076] For registration of a token in a token reference register, a token reference of the token may be generated. Each token reference includes a public value, such as a public key of an asymmetric cryptographic key pair, wherein the private value of the token is the private key of the asymmetric cryptographic key pair. In this embodiment, the private value and the public value are considered to be a token element pair. The token reference may also include a monetary value. Upon a registration request (also referred to as a replacement request), the token reference may be sent to a token register and stored in the token register. Thus, the token is registered as a valid token in the token trading system and may be used for further online or offline electronic payment transactions.

[0077] The electronic token trading system may further comprise one or more hashing units configured to generate a hash value based on user information received by receiving a request for a security token trading unit identifier from the security token trading unit, preferably wherein the hash value is also based on additional information as described above, more preferably, the additional information is a type indicator as described above or a special tag as described above.

[0078] The electronic token transaction system may also include one or more trusted service providers configured to encrypt the security token transaction unit identifier before storing it in the storage device of the security register unit, or provide an encryption key to the security register unit; and / or receive the encrypted security token transaction unit identifier from the output device of the security register unit upon a request from any security token transaction unit, and decrypt the encrypted security token transaction unit identifier.

[0079] On the other hand, a method for providing a lookup service is provided, the method comprising the following steps: receiving a hash value by means of a security register unit, wherein the hash value is based on user information; storing a link between the received hash value and a security token transaction unit identifier of the user's security token transaction unit by means of the security register unit, wherein the security token transaction unit identifier uniquely assigns the security token transaction unit of the user within an electronic token transaction system, preferably, wherein the storage device is configured to store multiple links; and sending the security token transaction unit identifier to the security token transaction unit that issues the request via the security register unit in response to a request from any security token transaction unit of the electronic token transaction system. BRIEF DESCRIPTION OF THE DRAWINGS

[0080] In the following, the invention or other embodiments and advantages of the invention are explained in more detail based on the accompanying drawings, wherein the accompanying drawings only describe embodiments of the invention. The same components in the drawings are given the same reference numerals. Elements drawn with dashed lines are considered optional elements.

[0081] The drawings should not be regarded as being drawn truly to scale, but rather individual elements of the drawings may be shown in exaggeratedly enlarged or exaggeratedly simplified form.

[0082] Figure 1 A secure electronic payment transaction system for token transactions with a prior art secure transaction unit is shown.

[0083] Figure 2 An exemplary embodiment of a secure electronic token transaction system with a secure register unit according to the present invention is shown.

[0084] Figure 3 Another exemplary embodiment of a secure electronic token transaction system with a secure register unit according to the present invention is shown.

[0085] Figure 4 Another exemplary embodiment of a secure electronic payment transaction system with a secure register unit according to the present invention is shown.

[0086] Figure 5 Another exemplary embodiment of a secure electronic token transaction system with a secure register unit according to the present invention is shown.

[0087] Figure 6 Another exemplary embodiment of a secure electronic token transaction system with a secure register unit according to the present invention is shown. DETAILED DESCRIPTION

[0088] Figure 1 An example of a secure electronic token transaction system TS with a secure transaction unit TU according to the prior art is shown. Figure 1 The secure electronic token transaction system TS (e.g., a payment transaction system) corresponds to the third method described above. The transaction system TS includes a register layer T-REG-LAY, in which a token reference register T-REG is arranged. TS also includes a direct transaction layer TU-LAY, in which a plurality of transaction units TU can be provided, as an example, Figure 1 Two transaction units TU1 and TU2 are shown in FIG. TU1 and TU2 have control means configured to generate a registration request RR including a modification command CO regarding the modification of a token, here the token being the T of the secure transaction unit TU1. a and secure transaction unit TU2 c .

[0089] The trading units TU of the trading system TS are arranged to exchange 15 tokens T directly with each other. Figure 1 In the case of T 旧 , T a and T cis a payment token, also known as a digital coin, preferably a CBDC. Each token T in TS is issued by a specific token issuer ( Figure 1 Transaction unit TU-1 is generated (not shown).

[0090] Each token T can be modified (such as split, merged or switched) by applying a modification command CO by each transaction unit TU.

[0091] Each token T can be generated by the transaction unit TUI of the token issuer and can also be deleted. The transaction unit TU-1 of the token issuer is, for example, a commercial bank or a financial service provider unit FSP.

[0092] The modification command complies with the third method described above and avoids repeating the modifications again. Each modification can be registered in T-Reg by a replacement request (=registration request) RR.

[0093] A token T is uniquely represented by a monetary value v and a random number r. Therefore, each token T in the TS has at least two token elements.

[0094] The monetary value v as the first mandatory token element can be from 1 to 2 31 -1. The random number r can be 0 to 2. 256 A number in the range -1, i.e. the order of the elliptic curve, e.g. secp256r1. For example, the token value v is a 32-bit token element of type integer.

[0095] The random number r as the second mandatory token element is the private key of the token-individual 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. For example, the random number r is a 32-byte token element of integer type.

[0096] The transaction unit TU has exclusive access to the storage unit (vault) or the transaction unit TU's data storage includes token memory.

[0097] For each token T, a token reference TR may be stored in a token reference register T-Reg. The token reference TR comprises a monetary value v (of the token T) and a public key R corresponding to a private key r of a token-individual key pair. The token reference TR of a token T may be viewed at any time in the register T-Reg of the trading system TS.

[0098] TU1 has a monetary value of V a and the random number r 旧 T 旧 TU1 modifies T 旧 Switch to Ta . T a Included (The T 旧 The monetary value of a and the newly generated random number r a In step 21, TU1 generates a unique allocation to T a TR a .

[0099] The token references TR a A registration request RR may be sent 31 by TU1 to the token reference register T-Reg (generated in step 22), if necessary together with a command CO.

[0100] In addition, the registration request RR uses the private key r 旧 Signature. The signature makes it possible to verify that TU1 owns / knows token T 旧 , further enhancing the security of the trading system TS.

[0101] Figure 1 The registration request RR generated in TU1 22 related to the handover modification includes the modification command CO, the token T to be registered a Output tokens refer to TR a and the token T to be removed from the token reference register T-Reg 旧 Input token reference TR 旧 The registration request RR also includes a signed registration request RR. sig_旧 , which uses tokens T 旧 The private part of 旧 Signed RR.

[0102] This RR may be sent to T-Reg in step 31 to register TR in T-Reg a TS receives token T from TU1 a Each TU of T can now verify a Is it a valid token T in TS?

[0103] Token T a (and can also be TR a and / or RR, e.g. as evidence) can be transmitted 15 from TU1 to TU2, e.g. when performing a token transaction (such as a payment transaction). TU2 now performs a switch-modification to transfer the token T a Switching from TU1 to TU2 token T c Therefore, in step 16, a new random number r is generated at TU2 c However, v a In the new T cThe same token elements are also maintained in . In step 21, TU2 c Generate tokens reference TR c . Due to v a No changes were made, so no money was created or deleted.

[0104] The token references TR c The command CO may be sent 31 by TU2 to T-Reg as another registration request RR (generated in step 22).

[0105] In addition, RR uses the private key r a Signature. The signature makes it possible to verify that TU2 is the owner of the (old) token T a This further enhances the security in TS.

[0106] The registration request RR related to the handover modification generated 22 in TU2 includes the handover modification command CO, the token to be registered T c An output token reference TR c and the token T to be removed from the token reference register T-Reg a An input token reference TR a Registration Request RR s Also includes the signed registration request RR sig_a , which uses tokens T a The private part of a Signed RR.

[0107] In cases where no data connection to the T-Reg is available or not needed, such as in offline token transactions, each TU can store RRs as so-called proofs.

[0108] Send RR to T-Reg 31. Receive RR in T-Reg. After T-Reg has checked RR, remove TR from T-Reg in step 41. a And TR c Stored in T-Reg. TR c Replace TR a , so this RR can also be called a replacement request. c In the case of c Registered in TS.

[0109] Each TR is uniquely assigned to T in TS, and the TR is used to register T in TS. Therefore, TR is a public representation of T from the direct transaction layer TU-LAY. Knowing or possessing TR alone does not allow T to transfer, and is not equivalent to TU owning T. This TR is used to prevent multiple spending attempts and check whether the token value v has been generated in an inappropriate way. Therefore, TR and (if applicable) the history (evidence) of tokens T and RR from TU are stored in T-Reg.

[0110] T can be stored as TU in, for example, a secure wallet. These wallets are, for example, software applications within a terminal device in which the TU is operably embedded. The wallet can be set up as an application on a smart phone, smart card or payment terminal. The wallet is used to securely manage the token T of the TU, generate a token reference TR, modify the token T and / or exchange the token T. The wallet is used to communicate with the token reference register T-Reg, generate a registration request RR for the token reference register T-Reg, modify the token T (switch, merge, split) and / or perform a transaction of the token T to another TU.

[0111] As mentioned above, transactions within TU-Lay do not require a communication link to TS's T-Reg. TS is set up to perform transactions offline, i.e., without a communication link to T-Reg. Therefore, the registration corresponding to token T can be downstream in time of the transfer of token T to TU.

[0112] T-Reg is a unit within the trading system TS and is a central register or database of the trading system TS, or a decentralized register or database (DLT) of the trading system TS.

[0113] The public part R of the token's individual key pair (as part of TR) is generated by applying a cryptographic function to the private part r of the token's individual key pair. This function is difficult to reverse and therefore provides the required security for the trading system TS. It holds that R=r*G, where G can be, for example, a global parameter of the trading system TS, such as a generator point of an elliptic curve (here, the secp256r1 curve). Any other suitable cryptographic function can also be applied to receive the R value.

[0114] Hardware TU (smart card) and managed TU (in the service provider unit ( Figure 1 The subject name (not shown) may be a TU-ID. The TU-ID may need to meet some or all of the following criteria:

[0115] The TU-ID may need to convey whether it is a wallet certificate or a CA certificate or a management CA-side entity certificate. The TU-ID may need to be small to transfer and store in a hardware wallet (e.g., a smart card). The TU-ID may need to fit in the subject field of the certificate, for example, it should not exceed 16 bytes in length. The TU-ID may need to remain stable between various changes to the certificate. The TU-ID may need to contain information about the SPU (e.g., the Financial Service Provider Unit FSP that issued the TU) so that the token transaction processor can use it to route data to other token transaction processors, for example, to find the IP address of the token transaction processor.

[0116] The TU-ID shall contain the central bank's identifier ( Figure 1 ), to allow cross-currency transfers (= multi-currency transactions or multi-currency transaction systems). The TU-ID may need to contain an identifier within the FSP.

[0117] TU1 includes a security token transaction unit identifier TU1-ID. TU1-ID uniquely allocates TU1 of the user within the TS. TU2 includes a security token transaction unit identifier TU2-ID. TU2-ID uniquely allocates TU2 of the user within the TS.

[0118] Figure 2 An exemplary embodiment of a TS with a security register unit ID-REG according to the present invention is shown. Figure 2 As shown and referenced in Figure 2 All components described are Figure 1 The corresponding elements with the same reference numerals are the same. For these identical elements, further description is omitted.

[0119] The general object of the invention is to implement a lookup service in the form of a secure register unit ID-Reg, wherein the link between a user information and the TU-ID of the user is more secure. To this end, a TS-central lookup service for the TU-ID is part of the TS. User 2 at TU2 sends 33 user information (request 33) related to user 1 with TU1, such as an email address or a phone number, and user 2 receives 34 the TU1-ID of TU1 of user 1.

[0120] according to Figure 2, TU1 sends 32 a TU-ID generation request to the hash unit HU in the TS. The request of step 32 includes the user information User-1-ID. The user information may be one or more of the above information or identifications, such as an email address, a mobile number, an IBAN, a tax number, a serial number, etc. In step 42, the HU generates a user ID hash (User-ID-hash) by applying a hash function to the user information received from TU1. The User-ID-hash is provided 43 to the input device of the ID-Reg. The ID-reg also receives 44 the TU-ID. The storage device of the ID-Reg stores 45 the User-ID-hash and the TU-ID as a link. The ID-Reg is a lookup service and therefore stores multiple such Hash-TU-ID links.

[0121] The TU-ID received in step 44 may already belong to the User-ID-hash provided in step 43. Both the TU-ID and the User-ID-hash may be provided by the same HU. However, the TU-ID generator unit may be used as a separate entity independent of the HU, and therefore the relationship of the User-ID-hash and the TU-ID is built in the ID-Reg. However, the TU-ID generator unit may be a part of the ID-Reg or any other entity of the TS.

[0122] The same applies to TU2 and user information of user 2.

[0123] All hashes within the TS are stored in the same ID-Reg (Lookup Table, LUT). Therefore, no one can tell if the hash originated from a phone number or some other number.

[0124] exist Figure 2 In the example, User-ID-hash is generated by HU 42, so the knowledge of the link between User-ID and User-ID-hash has ID-Reg but no TU.

[0125] Alternatively ( Figure 1 (not shown in the figure), User-ID-hash can be created by TU itself or by ID-Reg itself or by the trusted service provider unit TSP.

[0126] exist Figure 1It is not directly shown in the figure, but it is also possible to store multiple user information (such as email address and phone number) for the same user in the ID-Reg. Each user information will result in a separate entry in the ID-Reg, however, the same TU-ID will be used twice (once for each User-ID-hash). The ID-Reg can (but does not need to) internally interlink (point to) two User-ID-hash-TU-ID pairs, see the LUT table stored in the ID-Reg below:

[0127]

[0128] For token transactions, TU1 may provide User-1-ID to TU2 in step 17.

[0129] If User 2 of TU2 has User-1-ID of User 1, but needs TU1-ID for the reasons given above, he sends a request 33 including the user information User-1-ID to HU. In HU, the User-1-ID is hashed in step 42 and the User-ID-Hash is provided to ID-Reg. ID-Reg identifies User-ID-hash and transmits TU-1-ID of TU1 to TU2 as a lookup service.

[0130] The same applies to TU1, which may seek a TU2-ID or its own TU1-ID.

[0131] exist Figure 2 In , T-Reg is also shown as a register external to ID-Reg. Figure 2 In a variant of TS, the ID-Reg functionality (lookup service) is included in the T-Reg architecture. This can reduce the work in terms of authentication or identification between different central entities of the TS.

[0132] As indicated by the dashed line, the HU may add additional information info before generating the User-ID-hash. This information may be a type identifier indicating the type of the User-ID used to reduce the risk of hash collisions. Additionally or alternatively, a year tag or a salt tag may be used to reduce the risk that the revealed data may be used to parse the hash value to obtain user information.

[0133] The generation of TU-ID 44 is shown as an external entity to ID-Reg, for example, received from FSP or central bank. TU-ID may be generated 44 by ID-Reg. TU-ID may be generated 44 by the respective TU.

[0134] Figure 3Another exemplary embodiment of a TS with a security register unit ID-REG according to the present invention is shown. Unless otherwise specified, if the same reference numerals are used, Figure 3 As shown and referenced in Figure 3 All components described are Figure 1 and Figure 2 For these identical elements, further description is omitted.

[0135] from Figure 3 As can be seen in FIG, TU1 is used to generate the first-level hash value User-ID-Hash-1 in step 23. Therefore, ID-Reg does not obtain any knowledge of the plaintext User-ID at all, which increases data privacy. As an input value of the corresponding hash function, User-1-ID is used, and the type indicator type is additionally used. When TU1-ID is requested, the obtained User-ID-Hash-1 is provided to ID-Reg in step 32.

[0136] exist Figure 3 HU is included in ID-Reg. HU receives User-ID-Hash-1 from TU1 and adds a tag as additional information.

[0137] The tag added by the HU can be a time frame tag. Here the year tag is used as an example. An extension that changes every year is used to expire old information. This ensures automatic expiration of the User-ID-Hash-1 (or User-ID, in the case that the TU does not have a hash generator), and ensures privacy by designing that the user of the system must actively decide to update the information every year. ID-Reg stores the User-ID-Hash-TU-ID pair associated with the year tag, see the two LUT tables stored in ID-Reg below:

[0138]

[0139] The tag added by the HU can be a secret (salted) tag. The salt phrase is used to obfuscate the user ID (User-ID). It is a set of random data that is only known to the ID-Reg (e.g., the operator of the database system) and is stored in the tag register Tag-Reg. If part of the ID-Reg is leaked, it becomes more difficult to calculate the User-ID.

[0140] As can be seen from TU2, a hash generator in a TU is mandatory and a TU can participate in a TS with or without such a hash generator.

[0141] For example, in the case of a short-term token trading system (such as used in vacations, hospital stays, etc.), the year label is replaced with a time frame label, and a quarter year label or a week label or a month label can also be used.

[0142] Figure 4 Another exemplary embodiment of a TS with a security register unit ID-REG according to the present invention is shown. Unless otherwise specified, if the same reference numerals are used, Figure 4 As shown and referenced in Figure 4 All components described are Figure 1 and Figure 2 and Figure 3 For these identical elements, further description is omitted.

[0143] When requesting TU-ID in step 32, a hash value is generated from User-ID and / or additional information Info, tag, type and Figure 2 and Figure 3 The same as described in and cited as reference. In step 451, User-ID-Hash is stored in ID-reg.

[0144] TU-ID generation 44 Figure 4 Here, the trusted service provider unit TSP is used to encrypt the TU-ID in step 441 to obtain encTU-ID. In the case where the TSP only provides the appropriate key (e.g., the public key of the key pair) to ID-Reg, the encryption 441 can be performed inside ID-Reg. In step 452, encTU-ID is stored in ID-Reg. Preferably, the identifier TSP-ID of the TSP is added to the LUT entry.

[0145] exist Figure 4 In the embodiment of the present invention, the TU-ID is encrypted with a key from the TSP before being placed into the LUT of the ID-Reg in step 441. If the TSP provides a public key, the encryption does not need to be notified to the TSP. The encTU-ID will carry information about the TSP as the TSP-ID.

[0146] When a request to retrieve a TU-ID is initiated by TU2 based on User-1-ID in step 33, the encTU-ID is sent to the TSP using the TSP-ID (e.g., address information based thereon) in step 341. The encTU-ID is decrypted in the TSP in step 442. The decrypted TU-ID is sent from the TSP to TU2 in step 342. In this case, the TSP has the plaintext TU-ID for the first time.

[0147] according to Figure 4 , ID-Reg cannot disclose TU-ID even if it wants to. TSP will never know about User-ID-Hash-1 or User-ID-Hash-1 chosen by encTU-ID.

[0148] The TU-ID may be extended by a random information set to avoid the same encTU-ID.

[0149] exist Figure 4 In, FSP encrypted output is possible.

[0150] Figure 5 Another exemplary embodiment of a TS with a security register unit ID-REG according to the present invention is shown. Unless otherwise specified, if the same reference numerals are used, Figure 5 As shown and referenced in Figure 5 All components described are Figure 1 and Figure 2 as well as Figure 3 and Figure 4 For these identical elements, further description is omitted.

[0151] Here, different parts of ID-Reg are hosted by different FSPs, and each of them stores only a part of the TU-ID.

[0152] TU-ID generation 44 Figure 5 TU-ID is different in ID-Reg. Before storing it in ID-Reg, it is split (divided) into a reasonable number of parts TU-ID-1 and TU-ID-2. Each part is stored 452 in a different ID-Reg, that is, TU-ID-1 is stored 452 in ID-Reg_SP1 and TU-ID-2 is stored 452 in ID-Reg_SP2, so it is sent to different lookup services and entered into different tables respectively.

[0153] When requesting TU-ID in step 32, a hash value is generated from User-ID and / or additional information Info, tag, type and Figure 2 , 3 Almost the same as described in 4, which is incorporated by reference. However, in step 451, User-ID-hash is stored in each of ID-Reg_SP1 and ID-Reg_SP2.

[0154] According to a request 33 from TU2 to retrieve TU1-ID from TU1 at one of ID-Reg_SP1 and ID-Reg_SP2, each part TU1-ID-1 and TU1-ID-2 of TU1-ID is organized by the FSP that first receives the request 33. Each part TU1-ID-1 and TU1-ID-2 may have address information for indicating the location of the corresponding other parts. The number of parts should not exceed 5 to avoid increased work. TU1-ID-1 and TU1-ID-2 are received and merged 444 in one of the FSPs (preferably the FSP that receives the request 33). According to the merge 444, TU1-ID is received at TU2.

[0155] In case of data leakage from one of the SPs, only an incomplete LUT or an incomplete TU-ID is retrieved from this one leak source. When the intention is to identify a person based on User-ID, the requesting TU must connect to several different FSPs to collect the complete information, or the first FSP receiving the request 33 to organize the other parts.

[0156] Rather than just splitting the TU-ID, mathematical operations such as summing and / or modulo the highest possible value may also be applied to make it more difficult to guess the missing part TU-ID-x of the TU-ID.

[0157] pass Figure 5 , partial TU-ID output is possible, or only FSP-info may be output, such as if FSP1 resolves User-ID to TU1-ID, then FSP1 is provided instead of TU1-ID-1.

[0158] Figure 6 Another exemplary embodiment of a secure electronic token transaction system with a secure register unit ID-Reg according to the present invention is shown. Here, ID-Reg is included in T-Reg to reduce the number of central instances (entities) within TS.

[0159] exist Figure 6 In the example, there are multiple FSPs, here FSP-A and FSP-B, which can all be obtained from the root token issuer TU-I 根 (e.g. a central bank) receives the root token. Token T can be newly issued or deleted.

[0160] These new tokens T can be issued to FSPs, also called intermediate token issuers, such as commercial banks FSP-A, FSP-B. Here, token type information may or may not be added to tokens T, and these tokens T can be used for direct token exchanges 15.

[0161] exist Figure 6In FIG. 1 , it is shown that multiple ID-Regs hosted by the FSP but residing in the T-Reg can be provided in the token reference register T-Reg to speed up the lookup service or use of the ID-Reg, such as Figure 5 Here, it is also indicated that multiple HUs can be provided in the token reference register T-Reg.

[0162] Reference numerals

[0163] TS Electronic (Payment) Transaction System

[0164] Transaction unit in TU TS, wallet

[0165] HU Hash Unit

[0166] ID-Reg TU-ID-Register

[0167] ID-Reg_SPx TU-ID-Register of service provider unit x

[0168] User-ID User information, user ID, individual number

[0169] User-ID-Hash User ID hash

[0170] User-ID-Hash_1 User ID first level hash

[0171] User-ID-Hash_2 User ID second level hash

[0172] TU-ID TU's logo, wallet ID

[0173] TU-ID_1 The first part of the TU identifier, the first part of the wallet ID

[0174] TU-ID_2 The second part of the TU identifier, the second part of the wallet ID

[0175] encTU-ID Encrypted TU-ID

[0176] Info Additional information

[0177] TYPE type indicator

[0178] TAG Special label, vintage label, secret label

[0179] TSP Trusted Service Provider Unit

[0180] TSP-ID TSP identifier

[0181] FSP Financial Service Provider Unit

[0182] TU-I 根 Root Token Issuer Unit

[0183] T-Reg Token Reference Register

[0184] 1 Storage unit

[0185] 2. Verification Unit

[0186] 3 Evaluating the v-Summation Unit

[0187] 4 New register units

[0188] T-Reg-LAY Token Registry Layer

[0189] TU-LAY Token Transfer Layer

[0190] RR Registration Request, Replacement Request

[0191] T Token

[0192] TR Token Reference

[0193] v Monetary value of T

[0194] r Token-Secret private key of the individual key pair

[0195] R Token-Public key of individual key pair

[0196] CO Command

[0197] sig signature

[0198] 15 Token Transfer

[0199] 16 Modify Tokens

[0200] 17 Receive User-ID

[0201] 21 Generate Token Reference

[0202] 22 Generate RR

[0203] 23 Generate User-ID-HASH_1

[0204] 31 Registration Request

[0205] 32 TU-ID generation request

[0206] 33 Request TU-ID based on User-ID

[0207] 34 Transfer TU ID based on User-ID

[0208] 341 Transfer encrypted TU-ID

[0209] 342 Transfer decrypted TU-ID

[0210] 41 Replace TR by removing TR and storing TR

[0211] 42 Generate User-ID-HASH

[0212] 43 Transfer User-ID-HASH

[0213] 44 Generate TU-ID

[0214] 441 Encrypted TU-ID

[0215] 442 Decrypted TU-ID

[0216] 443 Split TU-ID

[0217] 444 Merge TU-ID

[0218] 45 Store User-ID-HASH and TU-ID

[0219] 451 Store User-ID-HASH

[0220] 452 Store encTU-ID

Claims

1. A security register unit (ID-Reg) in an electronic token transaction system (TS), preferably a lookup service, the security register unit comprising: • an input device configured to receive (43) a hash value (User-ID-Hash), wherein the hash value (User-ID-Hash) is based on user information (User-Info); • a storage device configured to store a link between the received hash value (User-ID-Hash) and a security token transaction unit identifier (TU-ID) of the security token transaction unit (TU) of the user, wherein the security token transaction unit identifier (TU-ID) uniquely assigns the security token transaction unit (TU) of the user within the electronic token transaction system (TS), preferably, wherein the storage device is configured to store a plurality of said links; • An output device configured to send the security token transaction unit identifier (TU-ID) to the requesting security token transaction unit (TU) upon a request from any security token transaction unit (TU) of the electronic token transaction system (TS).

2. The security register unit (ID-Reg) according to claim 1, wherein: The hash value (User-ID-Hash) is based on the user information (User-ID) and additional information (info).

3. The security register unit (ID-Reg) according to claim 2, wherein: The additional information (Info) is a type indicator (type), wherein the type indicator (type) is configured to indicate the type of user information (User-ID) on which the hash value (User-ID-Hash) is based, wherein preferably: • the first type indicator is configured to indicate user information (User-ID) generated by a communication service provider unit, wherein the user information (User-ID) is more preferably a telephone number or an email address of the user; and / or • the second type indicator is configured to indicate user information (User-ID) generated by a financial service provider unit, the user information (User-ID) being more preferably a bank account number or a customer reference number of the user; and / or • a third type indicator is configured to indicate user information (User-ID) generated by a government service provider unit, the user information (User-ID) more preferably being the user's tax number, passport number, ID card number, registration number or driver's license card number; • a fourth type indicator is configured to indicate user information (User-ID) generated by a private service provider unit, said user information (User-ID) being a customer reference number of said user; • a fifth type indicator is configured to indicate user information (User-ID) generated by a manufacturer unit, the user information (User-ID) being a serial number or a hardware number; and / or • The sixth type indicator is configured to indicate user information (User-ID) generated by a private company unit or an enterprise unit or a social club unit.

4. The security register unit (ID-Reg) according to claim 2 or 3, wherein: The additional information (info) is a special tag (tag), wherein the special tag (tag) is configured to further individualize the hash value (User-ID-Hash) within the electronic token transaction system (TS), wherein preferably: • the special tag is a time tag configured to indicate the time frame in which the hash value was generated; and / or • the special tag is a secret tag configured to obscure the user information (User-ID); • the special tag is a tag configured to indicate additional service specific data; • the special tag is a service provider indicator configured to indicate the service provider; and / or •The special tag is a tag known to the user of the security token transaction unit (TU) and is configured to be issued to the requesting security token transaction unit (TU) for insertion into the request to the security register unit (ID-Reg), wherein more preferably, the special tag is a one-time password, wherein the link between the hash value and the security transaction unit identifier is deleted by the security register unit (ID-Reg) immediately after being successfully requested by another security token transaction unit.

5. The security register unit (ID-Reg) according to any one of the preceding claims, wherein: The security token transaction unit identifier (TU-ID) is encrypted before storage, and the encrypted transaction unit identifier (TU-ID) is stored in the security register unit (ID-Reg).

6. The security register unit (ID-Reg) according to claim 5, wherein: The link as stored includes the encrypted security token transaction unit identifier (TU-ID) and trusted service provider unit identifier (TSP-ID).

7. The security register unit (ID-Reg) according to any one of the preceding claims 5 and 6, wherein: The encryption is performed by a trusted service provider unit (TSP), or the encryption is performed by the security register unit (ID-Reg) according to an encryption key received from the trusted service provider unit (TSP).

8. The security register unit (ID-Reg) according to any one of the preceding claims 5 to 7, wherein: Upon request from any security token transaction unit (TU) of the electronic token transaction system (TS), the output device is configured to send the encrypted security token transaction unit identifier (encTU-ID) to a trusted service provider unit (TSP) corresponding to the trusted service provider unit identifier (TSP-ID) for decrypting the encrypted security token transaction unit identifier (encTU-ID).

9. The security register unit (ID-Reg) according to any one of the preceding claims, wherein: The storage device at least comprises: • a first storage device hosted by a first service provider unit, the first storage device being configured to store a link between the received hash value (User-ID-Hash) and the first part (TU-ID-1) of the security token transaction unit identifier (TU-ID), and • A second storage device hosted by a second service provider unit, the second storage device being configured to store a link between the received hash value (User-ID-Hash) and the second part (TU-ID-2) of the security token transaction unit identifier (TU-ID).

10. The security register unit (ID-Reg) according to claim 9, wherein: The output device comprises: • a first output device hosted by said first service provider unit, and • a second output device hosted by the second service provider unit, and • wherein, upon a request from any security token transaction unit (TU) to the first output device, the first output device is configured to send the first part (TU-ID-1) of the security token transaction unit identifier (TU-ID) to the security token transaction unit (TU) that issued the request, wherein the first part (TU-ID-1) includes address information about the second part (TU-ID-2) of the security token transaction unit identifier (TU-ID); or •Wherein, upon a request from any security token transaction unit (TU) to the second output device, the second output device is configured to send the second part (TU-ID-2) of the security token transaction unit identifier (TU-ID) to the security token transaction unit (TU) that issued the request, wherein the second part (TU-ID-2) includes address information about the first part (TU-ID-1) of the security token transaction unit identifier (TU-ID).

11. A security token transaction unit (TU) for managing token transactions in an electronic payment transaction system (TS), the security token transaction unit (TU) comprising: • means for transmitting (33) to a security register unit (ID-Reg) according to any of the preceding claims a request for receiving (34) a security token trading unit identifier (TU-ID) of another security token trading unit (TU) of the electronic token trading system (TS), the request comprising user information (User-ID) of the other security token trading unit (TU), wherein the security token trading unit identifier (TU-ID) uniquely assigns the other security token trading unit (TU) to another user within the electronic token trading system (TS), • Preferably also includes: o a control device configured to generate (23) a first level hash value (User-ID-Hash_1), wherein the first level hash value (User-ID-Hash_1) is based on user information (User-ID); o means for exchanging one or more tokens (T) with other security token trading units (TU) in said electronic token trading system (TS); and o Means for transmitting a registration request (RR) to a token reference register (T-Reg) of said electronic transaction system (TS) for registering said token (T) in said electronic payment transaction system (TS).

12. An electronic token trading system (TS), comprising: • a plurality of security token transaction units (TU) according to claim 11; • one or more security register units (ID-Reg) according to any of the preceding claims 1 to 10, each security register unit being a lookup service within the electronic token transaction system (TS), wherein each storage means is configured to store a plurality of links between the received hash value (User-ID-Hash) and a security token transaction unit identifier (TU-ID) of a security token transaction unit (TU) of the user, wherein the security token transaction unit identifier (TU-ID) uniquely assigns the security token transaction unit (TU) of the user within the electronic token transaction system (TS); • Preferably also includes: o Security Token Issuance Unit (CB), including: • a minting unit configured to generate new tokens to be issued in said electronic token trading system (TS); and • a melting unit, the melting unit being configured to remove tokens to be deleted from the electronic transaction system (TS); o One or more security token reference register units (T-Reg) for registering tokens (T) of said electronic transaction system (TS).

13. The electronic token trading system (TS) according to claim 12, further comprising one or more hashing units (HU), the one or more hashing units (HU) being configured to generate (23) a hash value (User-ID-Hash) based on user information (User-ID) received by a request from a security token trading unit (TU) for receiving (34) a security token trading unit identifier (TU-ID), preferably wherein, The hash value (User-ID-Hash) is also based on additional information (info), and more preferably, the additional information (info) is a type indicator or a special tag (tag).

14. The electronic token transaction system (TS) according to claim 12 or 13, further comprising one or more trusted service providers (TSPs), wherein the one or more trusted service providers (TSPs) are configured to: • encrypting the security token transaction unit identifier (TU-ID) before storing it in the storage device of the security register unit (ID-Reg), or providing an encryption key to the security register unit (ID-Reg); and / or • Receive an encrypted security token transaction unit identifier (encTU-ID) from the output device of the security register unit (ID-Reg) upon request from any security token transaction unit (TU), and decrypt the encrypted security token transaction unit identifier (encTU-ID).

15. A method for providing a search service, the method comprising the following steps: • receiving ( 43 ) a hash value (User-ID-Hash) by means of a security register unit (ID-Reg), wherein the hash value (User-ID-Hash) is based on the user information (User-ID); • storing, by means of said security register unit (ID-Reg), a link between the received hash value (User-ID-Hash) and a security token transaction unit identifier (TU-ID) of said user's security token transaction unit (TU), wherein said security token transaction unit identifier (TU-ID) uniquely assigns said security token transaction unit (TU) of said user within said electronic token transaction system (TS), preferably wherein said storage means is configured to store a plurality of said links; •Upon request from any security token transaction unit (TU) of the electronic token transaction system (TS), the security token transaction unit identifier (TU-ID) is sent to the requesting security token transaction unit (TU) with the aid of a security register unit (ID-Reg).

Images