Apparatus and payment system for sending electronic coin data records directly to another device

Abstract

This invention relates to an apparatus for directly sending electronic currency data records to another device. The apparatus includes: means for accessing a data storage device, wherein the data storage device stores at least one electronic currency data record; an interface for outputting at least one electronic currency data record to another device; and a computing unit configured to mask the electronic currency data record in the device by applying a homomorphic one-way function to the electronic currency data record to obtain the masked electronic currency data record for the purpose of recording the masked electronic currency data record at a monitoring entity; and to output the electronic currency data record through the interface, wherein at least one electronic currency data record is configured as described above, i.e., including a total currency amount and a hidden total amount. The invention also relates to a payment system having a monitoring layer having a database storing the masked electronic currency data records; and a direct transaction layer having at least two devices in which the method can be executed.

Description

Technical Field

[0001] This invention relates to a device for directly sending electronic currency data records to another device. The invention also relates to a payment system for exchanging monetary amounts. Background Technology

[0002] The security of payment transactions and associated payment transaction data means protecting the confidentiality of the exchanged data; protecting the integrity of the exchanged data; and protecting the availability of the exchanged data.

[0003] Traditional blockchain-based payment transactions (such as Bitcoin) represent a high degree of protection for integrity. However, when electronic currency data records (also known as "coins") are transferred within the blockchain technology, much information is published. Therefore, such payment transactions, especially the data exchanged, are not entirely confidential. Furthermore, payment transactions are computationally intensive and therefore energy-intensive.

[0004] Therefore, instead of confidential data, only the hash value of the confidential data is conventionally stored in the blockchain ledger. The corresponding plain text data must be managed outside the blockchain. This concept has not yet applied to electronic currency data records because they lack basic control functions, particularly (1) methods for identifying multiple expenditures (also known as secondary expenditures) and (2) identification of uncovered payments. In case (1), someone attempts to issue the same currency data record multiple times, while in case (2), someone attempts to issue a currency data record even if he or she has no credit (no longer has credit).

[0005] Systems for sending monetary amounts in the form of electronic data records are known, according to DE 10 2009 038 645 A1 and German patent DE 10 2009 034 436 A1, which prevent payment by copying the data records and provide a high degree of security against manipulation, while the exchange requires a complex structure and complex encryption and signature processes. These systems have proven to have little practical use.

[0006] WO 2016 / 200885 A1 describes a method for encrypting the amount of a transaction in a blockchain ledger, where the verifiability of the transaction is preserved. A hidden amount is added to the input values. The output value is then generated and encrypted. Both the input and output values ​​are within a range of values, where the sum of any two values ​​does not exceed a threshold. The sum of the encrypted input and output values ​​can be zero. Range checks (so-called range proofs) are associated with each input and output value. These range checks prove that both the input and output values ​​are within the range of values. Each public key can be used to sign the transaction using a ring signature based on the public key of the recipient in the transaction. This process requires blockchain technology, which must be invoked after receiving the coin data record to verify the coin data record.

[0007] The object of this invention is to provide a method and system in which payment transactions are configured to be secure yet simple. Specifically, anonymous direct payments will be provided between devices such as token machines, smartphones, and machines such as point-of-sale terminals or vending machines. Coin data records will be available immediately upon receipt, for example, payments can be made even without an internet connection. It is intended that multiple coin data records can be combined and / or divided according to the user's needs to enable flexible exchange. The exchanged coin data records should be kept confidential from other system participants on the one hand, but on the other hand, allow each system participant to perform basic checks, particularly identifying multiple spending attempts and attempts to pay with non-existent amounts. Summary of the Invention

[0008] The objective is achieved through the features of the independent claim. Further advantageous developments are described in the dependent claims.

[0009] This objective is achieved in particular by a method for directly transmitting electronic currency data records between terminals (wherein, a first terminal and a second terminal), wherein the first terminal has at least one electronic currency data record, the method comprising the following steps:

[0010] Electronic currency data records are sent from a first terminal to a second terminal, and at least one electronic currency data record includes at least the monetary amount and the hidden amount;

[0011] Receive electronic currency data records from the first terminal as electronic currency data records sent in the second terminal; and

[0012] Use the sent electronic currency data record to generate another electronic currency data record.

[0013] The generation of additional electronic currency data records is preferably performed in the following manner.

[0014] - Switch the sent electronic currency data record to another electronic currency data record, i.e., the electronic currency data record to be switched to; and / or

[0015] - Divide the transmitted electronic currency data record into at least two additional electronic currency data records; and / or

[0016] - Combine the sent electronic currency data record with at least one second electronic currency data record to form another electronic currency data record, i.e., a combined electronic currency data record.

[0017] The method also includes the following steps:

[0018] - Obtain the masked electronic currency data record by applying a homomorphic one-way function to another electronic currency data record in a second terminal; and

[0019] - Register concealed (additional) electronic currency data records in remote monitoring entities.

[0020] The steps described herein need not be performed in the order described. However, the order described herein is a preferred embodiment.

[0021] The registration step is preferably performed when the device is connected to the monitoring entity. Alternatively, the described steps can also be performed without performing the registration step on the monitoring entity.

[0022] When switching the transmitted currency data record, in one embodiment, the currency amount of the transmitted electronic currency data record from the first terminal corresponds to the currency amount of another electronic currency data record. When splitting the transmitted electronic currency data record, in one embodiment, the currency amount of the transmitted electronic currency data record corresponds to the total currency amount of another electronic currency partial data record created based on the transmitted electronic currency data record. When combining, in one embodiment, the total currency amount of the transmitted electronic currency data record and the second electronic currency data record corresponds to the currency amount of the combined electronic currency data record.

[0023] Therefore, the registration request (such as a switching, combining, or splitting command) transmitted from the terminal to the monitoring entity preferably includes:

[0024] - exactly one hidden electronic currency data record to be registered and exactly one hidden electronic currency data record already registered, or

[0025] - At least two records of the masked modified electronic currency data to be registered (and the masked received electronic currency data record), or

[0026] - At least two registered masked electronic currency records (one of which is a masked received electronic currency record and a masked combined electronic currency record).

[0027] The terminal sends a registration request to a monitoring entity, which stores valid masked electronic currency data records. The terminal may alternatively or additionally (e.g., before further use) check the validity of the electronic currency data records by sending the masked electronic currency data records to the monitoring entity in a validity request, particularly the validity of received electronic currency data records. The monitoring entity responds to the validity request (affirmative or negative) based on the stored valid masked electronic currency data records.

[0028] Electronic currency data records are specifically electronic data records representing the value (= monetary amount) of currency, and are commonly referred to as "digital currency" or "electronic currency." In this method, the monetary amount is switched from one terminal to another. In the following text, the monetary amount is understood as, for example, a digital amount that can be credited to a financial institution's account, or that can be exchanged for another form of payment. Therefore, electronic currency data records represent cash in electronic form.

[0029] The terminal may have multiple electronic currency data records; for example, multiple currency data records may be stored in the terminal's data storage device. The data storage device represents, for example, an electronic wallet. For example, the data storage device may be internal, external, or virtual. In one embodiment, when an electronic data record is received, a "binding" may be performed automatically, so preferably, there is only one (or a certain number of) electronic data records in the terminal.

[0030] For example, the terminal can be a passive device, such as a token machine, mobile device (such as a smartphone), tablet computer, computer, server, or machine.

[0031] Electronic currency data records used to send monetary amounts differ significantly from electronic data records used for data exchange or data transfer because, for example, classic data transactions are performed based on question-and-answer principles or mutual communication between data transfer partners. On the other hand, electronic currency data records are unique, explicit, and exist within a context that may include security concepts such as signatures or encryption. In principle, electronic currency data records contain all the data required by the receiving entity for verification, authentication, and forwarding to other entities. Therefore, for this type of data record, mutual communication between terminals during the exchange is essentially unnecessary.

[0032] According to the present invention, the electronic currency data record used for transmission between two terminals includes a monetary amount and a hidden amount (e.g., a random number), where the monetary amount is data representing the monetary value of the electronic currency data record. Additionally, the electronic currency data record may further include metadata, such as which currency the monetary amount represents. The electronic currency data record is uniquely represented by these at least two pieces of data (the monetary amount and the hidden amount). Anyone who has access to these two pieces of data of the valid currency data record can use the electronic currency data record for payment. Therefore, knowing these two values ​​(the monetary amount and the hidden amount) is equivalent to possessing digital currency. The electronic currency data record is transmitted directly between the two terminals. In one embodiment of the invention, the electronic currency data record includes these two pieces of data, such that exchanging digital currency only requires the transmission of the monetary amount and the hidden amount.

[0033] A corresponding masked electronic currency data record is associated with each electronic currency data record. Knowledge of the masked electronic currency data record prevents anyone from distributing the digital currency represented by that record. This represents the essential difference between masked and (unmasked) electronic currency data records and is the essence of the invention. The masked electronic currency data record is unique and can be clearly associated with each other, i.e., in a one-to-one relationship. The electronic currency data record is preferably masked by a terminal computing unit within a terminal that also has at least one electronic currency data record. Alternatively, masking can be performed by the computing unit of the terminal receiving the electronic currency data record.

[0034] The masked cryptocurrency data record is obtained by applying a homomorphic one-way function, particularly a homomorphic cryptographic function. This function is one-way, meaning that from a complexity theory perspective, this mathematical function is "easy" to compute, but "difficult" to reverse in practice. Here, a one-way function is also referred to as a function that is known to be practically impossible to reverse with reasonable effort within a reasonable timeframe. Therefore, computing the masked cryptocurrency data record from the cryptocurrency data record is equivalent to generating a public key using an encryption method with a set of remaining categories. Preferably, a one-way function is used that operates on a set of discrete logarithms that is difficult to solve with the private key of the corresponding cryptographic method, such as a cryptographic method similar to elliptic curve cryptography (ECC). The inverse function, i.e., generating the cryptocurrency data record from the masked cryptocurrency data record, is very time-consuming—equivalent to generating a private key from a public key using an encryption method with a set of remaining categories. When sums, differences, or other mathematical operations are mentioned in this document, these should be understood mathematically as corresponding operations on the corresponding mathematical sets (e.g., sets of points on an elliptic curve).

[0035] One-way functions are homomorphic, meaning they are cryptographic methods with homomorphic properties. Therefore, mathematical operations can be performed on both masked and unmasked currency data records, allowing for reproducibility. With the aid of homomorphic one-way functions, calculations on masked currency data records can be reproduced within a monitoring entity without needing to know the corresponding unmasked currency data record. Thus, certain calculations on currency data records (e.g., for processing unmasked currency data records (e.g., splitting or combining)) can also be verified in parallel with the associated masked currency data records, for example, to verify or check the legitimacy of the corresponding currency data record. The homomorphic property applies at least to addition and subtraction operations, allowing splitting or combining (= combining) currency data records to be recorded in the monitoring entity using correspondingly masked currency data records, and to be reproduced by the requesting terminal device and / or by the monitoring entity without knowing the currency amount or the operating terminal.

[0036] Therefore, the homomorphic property allows the monitoring entity to record valid and invalid electronic currency data records based on their masked electronic currency data records, even without knowing the electronic currency data records themselves, even if these electronic currency data records are processed (segmented, combined, switched). This ensures that no additional currency amounts are created, or the terminal's identity is recorded in the monitoring entity. Thus, masking allows for a high level of security without knowing the currency amount or the terminal. This results in a two-layer payment system. On one hand, there is a processing layer that checks the masked electronic currency data records; on the other hand, there is a direct transaction layer where at least two terminals send electronic currency data records.

[0037] When electronic currency data records are used for direct payments between two terminals, the concealed currency data records are registered in the monitoring entity.

[0038] The steps for switching the transmitted electronic currency data record include the following sub-steps:

[0039] -Based on the sent currency data record, the electronic currency data record to be switched is generated in the second terminal, whereby...

[0040] - Using the hidden amount sent from the electronic currency data record, generate the hidden amount of the electronic currency data record to be switched in the second terminal; and

[0041] - The amount of currency sent in the electronic currency data record is used as the amount of currency in the electronic currency data record to be switched.

[0042] When the electronic currency data record is sent from the first terminal to the second terminal, both terminals become aware of the electronic currency data record. To prevent the first terminal, which is currently making a transfer, from also using the electronic currency data record for payment at another (third) terminal, the sent electronic currency data record is switched from the first terminal to the second terminal. Preferably, the switching can be performed automatically when the electronic currency data record is received. Alternatively, it can be done upon request, for example, based on a command from the first and / or second terminal.

[0043] In a preferred embodiment, generating a hidden amount for the electronic currency data record to be switched is preferably done by combining the hidden amount of the sent electronic currency data record with a new hidden amount (e.g., a random number). Preferably, the hidden amount for the electronic currency data record to be switched is obtained as the sum of the hidden amount of the sent electronic currency data record and the random number used as the new (i.e., additional) hidden amount. Furthermore, the currency amount of the sent electronic currency data record is preferably used as the currency amount of the electronic currency data record to be switched. Therefore, no further money is generated, and the currency amounts of the two currency data records are the same.

[0044] The registration following the switching step invalidates the electronic currency data record transmitted by the first terminal, and therefore it is identified as invalid in the second spending attempt by the first terminal. The (additional) currency data record generated by the second terminal becomes valid after successfully completing the check.

[0045] During switching (also known as a "switch"), a new electronic currency data record is generated from the electronic currency data record received from the first terminal, preferably having the same currency amount, known as the electronic currency data record to be switched. This new electronic currency data record is generated by the second terminal, preferably by using the currency amount of the received electronic currency data record as the currency amount of the electronic currency data record to be switched. A new hidden amount is generated, for example, a random number. After the switch, the received electronic currency data record and the electronic currency data record to be switched are preferably masked in the terminal by applying a homomorphic one-way function to them, so that the masked received electronic currency data record and the masked electronic currency data record to be switched are obtained accordingly. Furthermore, the additional information required for registering the switching of the masked electronic currency data record in the remote monitoring entity is preferably calculated in the terminal. This additional information preferably includes a range proof of the masked electronic currency data record to be switched and a range proof of the masked received electronic currency record. Range proofs are used to prove that the monetary value of a cryptocurrency data record is not negative, that the cryptocurrency data record was validly created, and / or that the monetary value and hidden amount of the cryptocurrency data record are known to the creator of the range proof. Specifically, range proofs are used to provide the stated proof(s) without revealing the monetary value and / or hidden amount of the concealed cryptocurrency data record. These range proofs are also known as "zero-knowledge range proofs." Ring signatures are preferably used as range proofs. The concealed cryptocurrency data record is then switched and registered with a remote monitoring entity.

[0046] This switching is necessary to invalidate the electronic currency data record received from the first terminal, thereby preventing double spending. This is because, as long as the electronic currency data record is not switched, the first terminal can pass it to a third device, since the first terminal knows the electronic currency data record and therefore still possesses it. For example, by adding a new hidden amount to the hidden amount in the received electronic currency data record, a hidden amount known only to the second terminal is obtained, making the switching secure. The newly created hidden amounts must have high entropy, as they are used as a dazzle factor for the corresponding masked electronic currency data record. Preferably, a random number generator on the terminal is used for this purpose. This protection can be tracked in the monitoring entity.

[0047] In another preferred embodiment of the method, at least one electronic currency data record is intended to be segmented into a first electronic partial currency data record and a second electronic partial currency data record. Preferably, the segmentation is performed on the one hand by determining a portion of the currency amount and a portion of the hidden amount (each between 0 and the received currency amount or the hidden amount) of the first electronic currency data record, and on the other hand by calculating the currency amount of the second electronic partial currency data record as the difference between the received currency amount and the portion of the currency amount of the first electronic partial currency data record, and calculating the hidden amount of the second electronic partial currency data record as the difference between the received hidden amount and the portion of the hidden amount of the first electronic partial currency data record. After segmentation, the electronic currency data record to be segmented, the first electronic partial currency data record, and the second electronic partial currency data record are masked in a first and / or second terminal by applying homomorphic one-way functions respectively, so as to obtain the masked electronic currency data record to be segmented, the masked first electronic partial currency data record, and the masked second electronic partial currency data record accordingly. In addition, additional information required for the segmentation of the masked electronic currency data record to be registered in the remote monitoring entity is calculated in the terminal. The additional information preferably includes range proofs for the masked electronic currency data records to be segmented, range proofs for the first masked electronic currency data record, and range proofs for the second masked electronic currency data record. The range proof demonstrates that the monetary value of the electronic currency data record is not negative, that the electronic currency data record has been validly created, and / or that the monetary value and hidden amount of the electronic currency data record are known to the creator of the range proof. Specifically, the range proof is used to provide the stated proofs without revealing the monetary value and / or hidden amount of the masked electronic currency data record. These range proofs are also referred to as "zero-knowledge range proofs." Preferably, a ring signature is used as the range proof. The segmentation of the masked electronic currency data record is then registered in a remote monitoring entity. In this way, the amount of currency to be sent can be adapted to corresponding needs. The terminal owner does not always have to transfer the entire amount of currency to another terminal.

[0048] The advantage of splitting and subsequently registering is that the owner of at least one electronic currency data record does not always have to send the entire amount of currency at once, but rather the corresponding partial amount. As long as all electronic partial currency data records have a positive currency amount less than the amount of the electronic currency data record from which the split occurs, and the sum of the electronic partial currency data records equals the electronic partial currency data record to be split, the currency value can be split without restriction. Alternatively or additionally, a fixed denomination can be used. Alternatively, the hidden amount can be generated outside the terminal and obtained via a (secure) communication channel. Preferably, a random number generator on the terminal is used for this purpose. To track all checks, the monitoring entity can, for example, observe partial steps taken by the monitoring entity in appropriate places, and for this purpose, markers (called flags) are also set to record intermediate stages. After the checks associated with the split command are successfully completed, that is, if the flag is properly completed, the (masked) first electronic partial currency data record and the (masked) second electronic partial currency data record are preferably marked as valid. The (masked) electronic currency data record to be split automatically becomes invalid. Preferably, the monitoring entity transmits the result of executing the split command to the "command" terminal, that is, which of the concealed electronic currency data records involved are valid after the split command is executed.

[0049] In another preferred embodiment of the method, in the step of combining electronic currency data records, an additional electronic currency data record (the combined electronic currency data record) is determined from the first and second electronic currency data records. The hidden amount of the electronic currency data record to be combined is calculated by summing the respective hidden amounts of the first and second electronic currency data records. Furthermore, preferably, the monetary amount of the linked electronic currency data record is calculated by summing the respective monetary amounts of the first and second electronic currency data records.

[0050] After the combination, by applying a homomorphic one-way function to the first electronic currency data record, the second electronic currency data record, and the electronic currency data record to be combined, the first electronic currency data record, the second electronic currency data record, and the electronic currency data record to be combined are masked in the (first and / or second) terminals, so that the masked first electronic currency data record, the masked second electronic currency data record, and the masked electronic currency data record to be combined are obtained accordingly. Furthermore, additional information required for registering the combination of the masked electronic currency data record in the remote monitoring entity is calculated in the terminal. Preferably, the additional information includes a range proof for the masked first electronic currency data record and a range proof for the masked second electronic currency data record. A range proof is proof that the monetary value of the electronic currency data record is not negative, that the electronic currency data record has been validly created, and / or that the monetary value and hidden amount of the electronic currency data record are known to the creator of the range proof. In particular, the range proof is used to provide the (multiple) proofs without revealing the monetary value and / or hidden amount of the masked electronic currency data record. These range proofs are also referred to as "zero-knowledge range proofs." Preferably, a ring signature is used as the range proof. Then, the combination of two concealed electronic currency data records is registered in the remote monitoring entity.

[0051] By combining the two electronic currency data records, the monetary amount and the hidden amount are added together. Similar to splitting, combining also validates the two original currency data records.

[0052] The key difference between this invention and known solutions lies in the fact that the monitoring entity maintains (i.e., exclusively) a list of the hidden electronic currency data records and the operations or changes made to those records. The actual payment transactions are not registered with the monitoring entity but occur directly at the direct transaction layer between terminals.

[0053] A method for storing validly masked electronic currency data records in a monitoring entity, wherein each validly masked electronic currency data record is formed by applying a homomorphic one-way function to the electronic currency data record, wherein the electronic currency data record includes a monetary amount and a hidden amount, the method specifically includes the following steps:

[0054] - Receive a registration request, which includes at least one hidden electronic currency data record to be registered and at least one already registered hidden electronic currency data record;

[0055] - Inspect the received registration request, where

[0056] o Check whether the registered masked currency data record in the registration request is stored as a valid masked currency data record for transmission in the monitoring entity, and

[0057] o Check whether the overall electronic currency data records masked by the registration request are monetaryly amount-neutral; and

[0058] - Store the masked cryptocurrency data record to be registered as a valid masked cryptocurrency data record, where previously stored registered masked cryptocurrency data records that were valid registration requests are no longer valid.

[0059] Preferably, by forming differences between masked electronic currency data records, the neutrality of the currency amount in the registration request is checked without knowing the amount (this is possible due to the use of homomorphic one-way functions).

[0060] In a preferred method, the entity monitoring the currency amount of the issuer entity receives a creation and / or deactivation request, which includes creating or deactivating at least one masked electronic currency data record, particularly for electronic currency data records newly issued by the issuer entity or electronic currency data records retrieved by the issuer entity.

[0061] Requests to create and / or deactivate concealed cryptocurrency data records may include the signature of the issuer of the concealed cryptocurrency data record, wherein the signature of the newly created concealed cryptocurrency data record is preferably stored in the monitoring entity.

[0062] By marking or deleting the corresponding masked electronic currency data record in the monitoring entity, the electronic currency data record may become invalid in the monitoring entity. Particularly preferably, the corresponding masked electronic currency data record or the corresponding electronic currency data record is also deactivated in the issuer entity.

[0063] According to the present invention, a two-tier payment system is provided, comprising a direct payment transaction layer for the direct exchange of (unmasked) electronic currency data records and a monitoring layer, which may also be referred to as a "hidden electronic data record ledger." Payment transactions are not recorded in the monitoring entity of the inspection layer, but only in masked electronic currency data records and operations thereof for the purpose of verifying the validity of the (unmasked) electronic currency data records. This ensures the anonymity of participants in the payment system. The monitoring entity provides information about valid and invalid electronic currency data records, for example, to avoid multiple expenditures of the same electronic currency data record or to verify the authenticity of the electronic currency data record as validly issued electronic currency.

[0064] Therefore, a terminal can send electronic currency data records to another terminal in the direct payment transaction layer without connecting to an inspection entity, especially when the terminal is offline.

[0065] Here, the terminal may have a secure element in which electronic currency data records are securely stored. The secure element is preferably a special computer program product, particularly in the form of a secure runtime environment within the terminal's operating system, called a Trusted Execution Environment (TEE), stored on data storage, such as a mobile terminal, machine, preferably an ATM. Alternatively, the secure element may be formed, for example, as special hardware, particularly in the form of a secure hardware platform module called a Trusted Platform Module (TPM), or as an embedded secure module (eUICC, eSIM). The secure element provides a trusted environment.

[0066] Communication between the two terminals can be wireless or wired, or, for example, optical, preferably via QR codes or barcodes, and can be configured as a secure channel. The optical method may include, for example, generating optical codes, particularly 2D codes, preferably QR codes, and the step of reading from the optical codes. Thus, the exchange of electronic currency data records is protected, for example, by a key (e.g., a session key or a symmetric or asymmetric key pair negotiated for the exchange of electronic currency data records).

[0067] Through communication between terminals (e.g., via their security elements), the exchanged electronic currency data records are protected from theft or manipulation. Therefore, the security element level complements the security of existing blockchain technology.

[0068] Furthermore, an advantage is that electronic currency data records can be sent in any format. This means they can be transmitted (i.e., sent) over any channel. They do not need to be stored in a specific format or through a specific procedure.

[0069] Specifically, a mobile telecommunications terminal (e.g., a smartphone) is considered a terminal. Alternatively or additionally, a terminal may also be a device such as a wearable device, smart card, machine, tool, vending machine, container, or vehicle. Therefore, the terminal according to the invention is either fixed or mobile. The terminal is preferably configured to use the Internet and / or other public or private networks. For this purpose, the terminal uses suitable connectivity technologies, such as Bluetooth, LoRa, NFC, and / or WiFi, and includes at least one corresponding interface. The terminal may also be configured to connect to the Internet and / or other networks via access to a cellular network.

[0070] In one embodiment, when multiple electronic currency data records are present or have been received, the first and / or second terminals in the illustrated method process the received electronic currency data records according to their monetary values. Therefore, it is intended to process electronic currency data records with higher monetary values ​​before those with lower monetary values. In one embodiment, the first and / or second terminal devices can be configured, upon receiving an electronic currency data record, to combine it with an electronic currency data record already present in the second terminal device, depending on the attached information (e.g., currency or denomination), and perform a combination step accordingly. Furthermore, the second terminal can also be configured to automatically perform a switching operation after receiving an electronic currency data record from the first terminal.

[0071] In one embodiment, additional information, particularly metadata (e.g., currency), is transmitted from the first terminal to the second terminal during transmission. In one embodiment, this information may be included in the electronic currency data record.

[0072] In a preferred embodiment, the method further includes the steps of: masking the sent electronic currency data record in a second terminal by applying a homomorphic one-way function to the sent electronic currency data record; and transmitting the masked sent electronic currency data record to a remote monitoring entity for verification of the validity of the sent electronic currency data record by the remote monitoring entity. In this case, for example, the entire amount of currency is transferred to the second terminal as part of the electronic currency data record. Before the recipient accepts the electronic currency data record, the recipient checks its validity (if applicable). To this end, the second terminal generates the masked sent electronic currency data record, transmits it to the monitoring entity, and in doing so, queries the monitoring entity for the validity of the electronic currency data record. The monitoring entity then checks whether the masked sent electronic currency data record exists and whether it is still valid, i.e., it has not been used by another terminal, to avoid double spending.

[0073] In one embodiment, a certificate is created in the second terminal. This certificate includes information regarding the correspondence between the currency amount of the sent electronic currency data record and the currency amount of the electronic currency data record to be switched. Preferably, the certificate includes only information about the correspondence and not information about the currency amount.

[0074] Preferably, the electronic currency data records of the first and / or second terminals are in the monitoring entity or verified by the monitoring entity during the registration step. Checks are performed according to the steps preceding verification, such as checking whether switching, combining, and / or splitting steps have occurred. Here, the monitoring entity can check, for example, the validity of the (masked) electronic currency data records sent and / or to be split and / or the first and second. This makes it possible to determine whether the electronic currency record is being processed for the first time. If the (masked) electronic currency data records are invalid (i.e., especially if they do not exist in the monitoring entity), registration cannot be successfully performed, for example, because the terminal attempts to output the electronic currency data record several times.

[0075] In another preferred embodiment, after the switching step has been performed, the registration step includes, for example, transmitting a switching command prepared by the terminal to a monitoring entity. The switching command preferably includes a masked received electronic currency data record, a masked electronic currency data record to be switched, and preferably includes additional information required for inspection by the monitoring entity. Preferably, through zero-knowledge proofs, the additional information is used to prove to the "commanding" terminal that it knows the monetary amount and hidden amount of the received electronic currency data record without conveying numerical values. The inspection entity checks the traceability of the zero-knowledge proof, the validity of the masked received electronic currency data record, and that the monetary amount of the received electronic currency data record is equal to the monetary amount of the electronic currency data record to be switched. To prove that only the new hidden amount is added to the hidden amount of the received electronic currency data record, but the monetary amount remains unchanged, the second terminal can preferably prove that the difference between the masked received currency data record and the masked electronic currency data record to be switched has a special representation, i.e., a public key representation. This is accomplished by generating a signature for the masked electronic currency data record to be switched with the added hidden amount. Then, the generated signature of the masked electronic currency data record to be switched can be checked in the monitoring entity. This is considered proof that the second terminal knew about the increased hidden amount. After the checks associated with the switching command are successfully completed, that is, if the marking is done properly, the (masked) electronic currency data record to be switched is preferably marked as valid. The (masked) received electronic currency data record automatically becomes invalid. The monitoring entity preferably communicates the execution result of the switching command to the "command" terminal, that is, which of the masked electronic currency data records involved are valid after the switching command has been executed.

[0076] In another preferred embodiment, after the segmentation step, the registration step includes a segmentation command prepared by the terminal, which is transmitted to the monitoring entity and includes a masked electronic currency data record to be segmented, a masked first electronic currency data record, a masked second electronic currency data record, and preferably additional information required for inspection by the monitoring entity. The additional information serves as proof to the "command" terminal, preferably through zero-knowledge proof, demonstrating that the monetary amount and hidden amount of the electronic currency data record to be segmented are known without conveying numerical values. The inspection entity checks the verifiability of the zero-knowledge proof, the validity of the masked electronic currency data record to be segmented, and whether the sum of the monetary amounts of the first and second electronic currency data records equals the monetary amount of the electronic currency data record to be segmented. This is preferably accomplished by the monitoring entity comparing the sum of the masked first and second electronic currency data records with the masked partial currency data record to be segmented.

[0077] In another preferred embodiment, after the combining step has been executed, the registration step includes a combining command prepared by the terminal device, which is transmitted to the monitoring entity and includes a first masked electronic currency data record, a second masked electronic currency data record, and a masked partial currency data record to be combined, and preferably includes additional information required for inspection by the monitoring entity. The additional information serves as proof to the "command" terminal, preferably through zero-knowledge proof, demonstrating knowledge of the monetary amounts and hidden amounts of the first and second electronic currency data records. The inspection entity checks the verifiability of the zero-knowledge proof, the validity of the masked first electronic currency data record, the validity of the masked second electronic currency data record, and that the sum of the monetary amounts of the first and second electronic currency data records equals the monetary amount of the electronic currency data record to be combined. This is preferably accomplished by the monitoring entity comparing the sum of the masked first and second electronic currency data records with the masked partial currency data record to be combined. After the inspection associated with the combining command has been successfully completed, i.e., after proper marking has been completed, the (masked) electronic currency data record to be combined is preferably marked as valid. Here, the (masked) first electronic currency data record and the (masked) second electronic currency data record automatically become invalid. The monitoring entity preferably transmits the execution result of the combination command to the "command" terminal, that is, which of the involved masked electronic currency data records are valid after the combination command has been executed.

[0078] In one embodiment, the sent electronic currency data record is masked and inspected before it is registered in the monitoring entity.

[0079] In a preferred embodiment, the monitoring entity is a remote entity. Therefore, for example, it is intended to establish a communication connection to the monitoring entity for registering electronic currency data records.

[0080] The monitoring entity is configured as a higher-level entity. Therefore, the monitoring entity does not necessarily need to be deployed at the terminal level or terminal layer (direct transaction layer). The monitoring entity is preferably provided for managing and inspecting concealed electronic currency data records and is deployed at the issuance layer and / or monitoring layer, with the issuance entity also deployed at the issuance layer. It is conceivable that the monitoring entity also manages and inspects transactions between terminals.

[0081] The monitoring entity is preferably a database, more preferably a decentralized database, referred to as Distributed Ledger Technology (DLT), in which masked currency data records are registered together with their corresponding processing. In a preferred embodiment, the validity status of the (masked) currency data records can be derived from this database. The validity of the (masked) currency data records is preferably marked in and by the checking entity. The registration of processing or processing steps may also involve registering check results and intermediate check results related to the validity of the currency data records. If the processing is final, this is indicated, for example, by appropriate flags or derived overall flags. The final processing then determines whether the currency data record is valid or invalid.

[0082] Furthermore, this database is preferably a non-public database, but it can also be implemented as a public database. This database makes it possible to easily check the validity of coin data records and prevent "double-spending," i.e., multiple spending, without registering or logging into the payment transaction itself. DLT describes a technology for networked computers that agrees on the order of certain transactions and the updating of data for these transactions. It corresponds to a decentralized management system or decentralized database.

[0083] In another embodiment, the database can also be configured as a public database.

[0084] Alternatively, the monitoring entity is a centrally managed database, for example, in the form of a publicly accessible data storage device or as a hybrid of central and decentralized databases.

[0085] At least one initial electronic currency data record is preferably created specifically by the issuing entity, wherein segmented electronic currency data records, particularly electronic partial currency data records, may also be generated by the terminal. The creation and selection of the currency amount preferably also includes selecting a hidden amount with high entropy. The issuing entity is preferably a computing system located remotely from the first and / or second terminal. After creating a new electronic currency data record, the new electronic currency data record is masked in the issuing entity by applying a homomorphic one-way function to the new electronic currency data record in order to obtain the masked new electronic currency data record accordingly. Furthermore, additional information required for the creation of the masked new electronic currency data record is calculated in the issuing entity for registration in the remote monitoring entity. This additional information is preferably, for example, proof that the (masked) new electronic currency data record originates from the issuing entity by signing the masked new electronic currency data record. In one embodiment, it may be intended that the issuing entity can sign the masked electronic currency data record with its signature when the electronic currency data record is generated. For this purpose, the issuing entity's signature is stored in the monitoring entity.

[0086] The issuing entity can preferably deactivate the electronic currency data record it owns (i.e., it knows its currency amount and hidden amount) by masking the electronic currency data record to be deactivated using a homomorphic one-way function and preparing a deactivation command for the monitoring entity. In addition to the masked electronic currency data record to be deactivated, proof of the deactivation step initiated by the issuing entity, for example in the form of a signed masked electronic currency data record to be deactivated, is preferably also part of the deactivation command. As additional information, the deactivation command may include a range proof of the masked electronic currency data record to be deactivated. The deactivation of the masked electronic currency data record is then registered in the remote monitoring entity. The deactivation step is triggered by the deactivation command.

[0087] In another preferred embodiment, after the deactivation step is executed, the registration step includes a deactivation command prepared for the issuer entity, which is transmitted to the monitoring entity and includes the masked cryptocurrency data record to be deactivated, and preferably includes additional information required for verification by the monitoring entity. The additional information serves to prove that the deactivation command was initiated by the issuer entity, preferably through the signed masked cryptocurrency data record to be deactivated. The verification entity verifies the validity of the signature, the masked cryptocurrency data record to be deactivated, and optionally, proof of the scope of the masked cryptocurrency data record to be deactivated. After successfully completing the verification associated with the deactivation command, that is, if the marking is properly performed, the (masked) cryptocurrency data record to be deactivated is preferably marked as invalid. The monitoring entity preferably communicates the result of executing the deactivation command to the issuer entity, i.e., that the (masked) cryptocurrency data record to be deactivated is invalid after the deactivation command has been executed.

[0088] The creation and deactivation steps are preferably performed in a secure location, particularly not on the terminal. In a preferred embodiment, the creation and deactivation steps are performed or initiated solely by the issuing entity. These steps are preferably performed in a secure location, for example, in a hardware and software architecture developed for processing sensitive data materials in an insecure network. Deactivating the corresponding masked currency data record has the effect that the corresponding masked currency data record is no longer usable for further processing, particularly transactions, because it has been marked invalid by the monitoring entity. However, in one embodiment, it may be stipulated that the deactivated masked currency data record is kept on file by the issuing entity. The fact that the deactivated masked currency data record is no longer valid can be identified, for example, using a flag or some other encoding, or the deactivated masked currency data record can be destroyed and / or deleted. Of course, the deactivated masked currency data record can also be physically removed from the terminal.

[0089] The method according to the invention implements various processing operations on electronic currency data records and corresponding masked electronic currency data records. Each processing operation (specifically creation, deactivation, splitting, combining, and switching) is registered in the monitoring entity and appended in an immutable form to the list of previous processing operations for each masked electronic currency data record. The processing operations "creation" and "deactivation" involve the existence of the currency amount itself; that is, creating, deleting, or even destroying currency requires additional approval from the issuing entity, for example, in the form of a signature, in order to register (i.e., log in) with the monitoring entity. Other processing operations (splitting, combining, switching) do not require any authorization from the issuing entity or the command initiator (= the payer, e.g., the first terminal).

[0090] The switching, splitting, or combining (registration modification) and creation and deactivation (initial registration and final deregistration) steps listed here are all triggered in the monitoring entity by the corresponding request (or command), such as the corresponding creation, switching, splitting, combining, or deactivation command.

[0091] The processing in the direct transaction layer only affects the ownership structure and / or the association between the coin data record and the terminal of the corresponding electronic coin data record. The corresponding processing is registered in the monitoring entity, for example, through corresponding list entries in a database containing several flags that the monitoring entity must execute. One possible structure of the list entries includes, for example, columns(s) of the preceding coin data record, columns(s) of the following coin data record, a signature column of the issuer entity, and at least one flag column. Changes to flag states require approval from the monitoring entity and must be immutably preserved. A change is final if and only if the required flag has been verified by the monitoring entity, i.e., for example, after a corresponding check, if state "0" has changed to state "1". If the check fails or takes too long, a change is made instead, for example, from state "-" to state "0". Other state values ​​and / or the state values ​​mentioned herein are conceivable to be interchangeable. Preferably, the validity of each (masked) electronic coin data record is represented by a summary of the flag state values ​​in the columns of each masked electronic coin data record involved in the registration process.

[0092] In another exemplary embodiment, at least two, preferably three, or even all of the aforementioned markers can be replaced by a single marker, which is set when all checks have been successfully completed. Furthermore, the two columns of preceding and following data records can each be combined into one column, in which all coin data records are listed together. In this way, more than two electronic coin data records can be managed by field entries; therefore, for example, it is possible to implement a system splitting the coin into more than two types.

[0093] The checks performed by the inspection entity to determine whether the inspection process is final have been described above, in particular:

[0094] - Are the masked electronic currency data records in the preceding (multiple) columns valid?

[0095] - Check if the correct check value was obtained?

[0096] - Does the scope of the concealed electronic currency data record prove success?

[0097] - Is the signature on the masked electronic currency data record a valid signature of the issuing entity?

[0098] Preferably, the concealed electronic currency data record is invalid when one of the following checks is triggered:

[0099] (1) The concealed electronic currency data records were not registered with the monitoring entity;

[0100] (2) The final processing of a concealed electronic currency data record indicates that it has a preceding currency data record, but this final processing is not final; or

[0101] (3) The final processing of the concealed electronic currency data record indicates that there are subsequent currency data records, and that the final processing is final.

[0102] (4) A concealed electronic currency record is not a record following a validly concealed electronic record unless it is signed by the issuing entity.

[0103] In one aspect of the invention, a payment system for exchanging monetary amounts is provided with a monitoring layer comprising: a database, preferably a distributed ledger technology (DLT) database with decentralized control, storing masked electronic currency data records; a direct transaction layer comprising at least two terminals in which the above-described method can be executed; and / or an issuer entity for generating the electronic currency data records. Here, the issuer entity can prove that the masked generated electronic currency data records were generated by it, and the issuer entity can preferably identify itself by a signature, and the monitoring entity can verify the issuer entity's signature.

[0104] In a preferred embodiment, the payment system includes an issuer entity for generating electronic currency data records. Here, the issuer entity can prove that the masked electronic currency data records were generated by it, and the issuer entity can preferably identify itself by a signature, and the monitoring entity can check the issuer entity's signature.

[0105] The payment system is preferably configured to perform the above-described methods and / or at least one variant of the embodiments.

[0106] Another aspect of the invention relates to a monetary system comprising an issuer entity, a monitoring entity, a first terminal, and a second terminal. The issuer entity is configured to create an electronic currency data record. The masked electronic currency data is formed such that it has been veribly created by the issuing entity. The monitoring entity is configured to perform a registration step as performed in the method described above. Preferably, the terminals (i.e., at least the first and second terminals) are adapted to perform one of the methods described above for sending.

[0107] In a preferred embodiment of the monetary system, only the issuing entity is authorized to initially create the electronic currency data record. Processing (e.g., combining, splitting, and / or switching steps) can and preferably is performed by the terminal. Preferably, the deactivation processing step can be performed solely by the issuing entity. Therefore, only the issuing entity will be authorized to invalidate the electronic currency data record and / or the masked electronic currency data record.

[0108] The inspection entity and the issuing entity are preferably located in a server entity, or can be used as computer program products on a server and / or computer.

[0109] Electronic currency data records can be provided in a wide variety of different formats, and therefore can be exchanged via various communication channels (hereinafter also referred to as interfaces). This creates a very flexible exchange of electronic currency data records.

[0110] Electronic currency data records are represented as photodetectable codes, such as barcodes or QR codes, and are therefore one-dimensional or two-dimensional encoded data records. They can be displayed in this visual form, for example, via an electronic display unit (display, monitor) or as a printed output on paper. Thus, they can be presented visually. In this visual form, electronic currency data records can also be acquired by electronic acquisition units, such as scanners (barcode scanners, QR code scanners) or cameras. Specifically, the currency value and blind signature are mapped to photodetectable codes.

[0111] For example, electronic currency data records can be represented as files. Files include related data stored on a data carrier, data storage medium, or storage medium. Each file is initially a one-dimensional sequence of bits, typically interpreted as blocks of bytes. The application (application) or operating system itself interprets this bit or byte sequence as, for example, text, an image, or a recording. The file format used here can vary; for example, it can be a plain text file representing electronic currency data records. In particular, currency value and blind signatures are mapped to files.

[0112] Electronic currency data records are, for example, sequences of characters in the U.S. Standard Code for Information Interchange (ASCII). Specifically, currency value and blind signatures are mapped to this sequence.

[0113] Electronic currency data records can also be converted from one representation to another within the device. For example, electronic currency data records can be received as QR codes within the device and output as files or strings by the device.

[0114] These different representations of the same electronic currency data record allow for highly flexible exchange between devices with different technical equipment using different transmission media (air, paper, wired), while taking into account the technical configuration of the devices. The representation of the electronic currency data record is preferably selected automatically, for example, based on identified or negotiated transmission media and device components. Alternatively, the user of the device can also select the representation used to exchange (i.e., send) the electronic currency data record.

[0115] In one aspect of the invention, this objective is achieved by a device configured to directly send electronic currency data records to another device. The device includes: means for accessing a data storage device, wherein at least one electronic currency data record is stored in the data storage device; an interface for outputting at least one electronic currency data record to another device; and a computing unit configured to mask the electronic currency data record in the device by applying a homomorphic encryption function to the electronic currency data record to obtain the masked electronic currency data record, for registering the masked electronic currency data record in a monitoring entity; and to output the electronic currency data record through the interface, wherein at least one electronic currency data record is constructed as described above, i.e., including a currency amount and a blind signature.

[0116] Here, the device is the terminal or machine described earlier.

[0117] In simple cases, the data storage device is the device's internal data storage device. Electronic currency data records are stored here. This ensures easy access to the electronic currency data records.

[0118] Data storage devices, particularly external data storage devices, are also known as online storage devices. Therefore, this device has only one method of accessing and thus securely storing currency data records on external storage. Specifically, if the device is lost or malfunctions, the electronic currency data records will not be lost. Since possessing (unmasked) electronic currency data records corresponds to possessing a monetary amount, currency can be stored more securely by using an external data storage device.

[0119] When the monitored entity is a remotely monitored entity, the device preferably includes an interface for communicating via conventional Internet communication protocols, such as TCP, IP, UDP, or HTTP. Transmission may include communication via a cellular network.

[0120] In a preferred embodiment, the device is configured to perform the described processes on the electronic currency data record. To this end, the computing unit is configured to mask the electronic currency data record to be switched as a required electronic currency data record for the monitoring entity, or as a masked electronic currency data record used for registering a switching command or during a switching step. Thus, as described above, the electronic currency data record can be switched.

[0121] Additionally or alternatively, the computing unit is preferably configured to mask the electronic currency data record, which is segmented into a first electronic currency data record and a second electronic currency data record, in order to obtain the masked first electronic currency data record and the masked second electronic currency data record to be registered in the monitoring entity. Thus, as described above, the electronic currency data record can be segmented.

[0122] Additionally or alternatively, the computing unit is preferably configured to mask the electronic portion of the currency data record to be combined from the first electronic currency data record and the second electronic currency data record as a currency data record, so as to obtain the masked currency data record to be combined as a masked electronic currency data record registered in the monitoring entity. In this way, as described above, the electronic currency data records can be combined.

[0123] In a preferred embodiment, the interface for outputting at least one electronic currency data record is the device's electronic display unit, which is configured to display the electronic currency data record, thereby outputting the electronic currency data record in a visual form. As already described, the electronic currency data record can then be exchanged between devices, for example, in the form of photodetectable codes, images, etc.

[0124] In a preferred embodiment, the interface for outputting at least one electronic currency data record is a protocol interface for wirelessly transmitting the electronic currency data record to another device via a communication protocol for wireless communication. Specifically, near-field communication is provided, for example, using Bluetooth, NFC, or IR protocols; alternatively or additionally, WLAN or mobile radio connections are conceivable. The electronic currency data record is then adapted and transmitted according to the protocol attributes.

[0125] In a preferred embodiment, the interface for outputting at least one coin data record is a data interface for providing the coin data record to another device via an application. Unlike a protocol interface, the coin data record is sent via the application. The application then sends the coin data record in a corresponding file format. A file format specific to the coin data record can be used. In its simplest form, the coin data record is sent as an ASCII string or text message, such as SMS, MMS, or instant messaging (such as Threema or WhatsApp). A wallet application can also be provided. Here, the exchanging device preferably ensures that exchange via the application is possible; that is, both devices have the application and are ready to exchange.

[0126] In a preferred embodiment, the device further includes an interface for receiving electronic currency data records.

[0127] In a preferred embodiment, the interface for receiving at least one electronic currency data record is an electronic acquisition module of the device, configured to acquire the electronic currency data record in a visual form. The acquisition module is, for example, a camera or a barcode or QR code scanner.

[0128] In a preferred embodiment, the interface for receiving at least one electronic currency data record is a protocol interface for wirelessly receiving electronic currency data records from another device via a communication protocol for wireless communication. Specifically, near-field communication is provided, for example, using Bluetooth, NFC, or IR protocols. Alternatively or additionally, WLAN or cellular connectivity is conceivable.

[0129] In a preferred embodiment, the interface for receiving at least one electronic currency data record is a data interface for receiving electronic currency data records from another device via an application. The application then receives the currency data record in a corresponding file format. A file format specific to the currency data record can be used. In its simplest form, the currency data record is transmitted as an ASCII string or text message, such as SMS, MMS, or instant messaging (such as Threema or WhatsApp). Alternatively, a wallet application can be used to perform the sending.

[0130] In a preferred embodiment, the interface for receiving at least one electronic coin data record is also an interface for outputting electronic coin data records, so as to provide an interface for transmitting and receiving coin data records.

[0131] In a preferred embodiment, the device further includes means for accessing an electronic security module configured to securely store at least one electronic currency data record, preferably stored in an online storage device. The device is preferably a terminal, such as a smartphone, laptop, smartwatch, smart card, etc. The security module, also known as a "vault," can be a data storage device for electronic currency data records that can only be accessed by the user after additional (successful) authentication, such as via biometrics, PIN, or password. The security module can be located on the device and then protected by additional security features. For example, the security module is a secure runtime environment (TEE) or a secure element, such as an eUICC. Alternatively, the security module is located externally to the device, for example, as a trusted server acting as a trusted third party providing the functionality of the security module.

[0132] Here, the security module can also initiate the processing of data records, particularly segmentation, combination, and switching, and for these purposes, it can connect to the monitoring entity for communication purposes. In this form, the security module is the computing unit of the device and is configured to mask and output electronic currency data records. This processing is also preferably performed only after successful authentication.

[0133] Unmasked currency data records can be automatically loaded into the security module. For example, the user can define specifications, such as thresholds, within the device. These thresholds represent, for example, the maximum amount of currency or the maximum number of electronic currency data records. The calculation unit automatically detects when the defined threshold is exceeded in the device (e.g., after a payment from another device). Then, the unmasked electronic currency data records are automatically loaded into the security module, and only currency data records that meet the defined threshold are retained on the device or in a less secure or insecure data storage device.

[0134] The security module can also be a standalone device. In addition to secure storage, the security module includes communication devices for input and output, as well as devices for querying user authentication. The security module can initially be customized. Alternatively, the security module can be connected to a device to exchange coin data records using its interface.

[0135] In a preferred embodiment, the device includes a module configured to identify a predetermined location area. For example, the location area is understood as a home zone or home area. The location area can be a coverage area of ​​a WLAN area, for example, defined by the WLAN's name (SSID). The module is, for example, a WLAN module. The device detects active WLANs and can then connect to a predefined WLAN to access the Internet. The device does not perform certain special functions until it identifies itself as being within a predefined location area. Specific WLANs can be selectively defined. Additionally or alternatively, the module can be a Global Positioning System (GPS) module used to identify that the device is within predefined GPS coordinates. The device performs special functions only within the predefined location area. The location area is defined directly on the device or module.

[0136] Specific functions performed when a location area is identified include, for example, the automatic transmission (i.e., sending and receiving) of electronic currency data records, such as sending them to a security module and / or an external data storage device and / or transmitting masked currency data records for use in switching corresponding currency data records in the monitored entity. The location identification module and the security module can preferably interact such that the security module is populated with currency data records, or (only) based on defined thresholds and when a location area is identified, removes currency data records from the security module. This allows for automatic loading and sending, as well as debiting, based on location and defined thresholds.

[0137] Depending on the specifications of the electronic currency data records stored in the terminal, particularly the threshold for the monetary amount of the electronic currency data records stored in the terminal, the maximum number of electronic currency data records, and / or the denomination specifications of the electronic currency data records stored in the terminal's electronic currency data records, the device may be particularly preferably configured to automatically send or receive at least one electronic currency data record from or into the device to comply with the specifications. For example, to comply with the specifications, the electronic currency data record is sent from the device to a security module or from a security module to the device. Alternatively or additionally, the device may be optionally configured to send or receive electronic currency data records from an issuer entity to the device or from the device to an issuer entity to comply with the specifications.

[0138] To enhance security, it is conceivable that the issuing entity may issue electronic currency data records only to the security module of the device and / or retrieve electronic currency data records only from the security module of the device. Multiple devices are configured to exchange electronic currency data records with other devices via an interface, and preferably exchange (particularly request or return) electronic currency data records with the issuing entity only through the security module.

[0139] In a preferred embodiment, the computing unit is configured to detect the difference between the monetary amount to be sent and the monetary amount in the electronic currency data record; request an electronic currency data record with a monetary amount equal to the detected difference at the issuer entity; and receive the requested electronic currency data record. Preferably, the received electronic currency data record is combined with a stored electronic currency data record, and the electronic currency data record to be combined is masked for registration with the monitoring entity. The combined electronic currency data record is then sent. In an alternative embodiment, the received electronic currency data record is switched at the monitoring entity. The switched and existing electronic currency data records are then sent. Thus, the device can provide the desired payment amount entirely automatically in the electronic currency data record and instruct the issuer entity for this purpose. This is also optionally one of the device's special functions, namely, it can be performed only in the location area and when below a predetermined threshold.

[0140] In a preferred embodiment, the calculation unit is configured to detect a surplus in the received monetary amount and a threshold for the monetary amount of the stored electronic currency data records; and to obtain a first electronic partial currency data record corresponding to the threshold and a second electronic partial currency data record corresponding to the surplus by segmenting the electronic currency data records, and to mask the first and second partial currency data records to obtain masked first and second electronic currency data records for segmentation at the monitoring entity, to transfer the surplus (e.g., by crediting the surplus to a bank account or sending it to a security module). Therefore, for example, the device can automatically credit the surplus amount to a bank account, thereby keeping the quantity and value of the currency data records on the device low (in terms of the threshold). This is also one of the device's special functions, namely, that it can be performed only in the location area and when a predetermined threshold is exceeded.

[0141] In a preferred embodiment, the device (particularly the first and / or second terminal) includes a banknote module for inputting and / or distributing banknotes. In this case, the device is preferably a machine or automaton, such as a self-service terminal or a component of a registration system of a retailer or banking entity.

[0142] In a preferred embodiment, the device is a registration terminal and / or automaton, and is configured to output a portion of the monetary amount as banknotes using a banknote module, and a portion of the monetary amount as electronic currency data records using an interface output. In this case, the device allows for the complete elimination of analog coins. A portion of the monetary amount to be sent is given in the form of banknotes, rounded to the nearest denomination, and the remainder is given in the form of electronic currency records. This replaces the distribution of currency in the form of analog coins.

[0143] Electronic currency data records (as part of the payment) can be transmitted in (photoelectric) form, or they can be printed output received by the user from the register component.

[0144] The portion of currency amount output as the electronic currency data record is preferably the first electronic currency data record that divides the electronic currency data records.

[0145] In a preferred embodiment, the device is a registration terminal and / or automaton, and is configured to output a monetary amount in the form of banknotes via a banknote module, wherein the device receives a portion of the monetary amount in the form of electronic currency data records from another device. To this end, the device can inform the other device what monetary value it expects; that is, it can request an electronic currency data record of a certain monetary value. In this case, sending analog currency can also be omitted. A portion of the monetary amount to be sent is in the form of banknotes, rounded to the nearest denomination, and the remainder is received from the terminal as an electronic currency data record, which can be considered a negative change.

[0146] Electronic currency data records (as part of the payment) can be sent in (optoelectronic) electronic form, or they can be printed out and received by the registration component.

[0147] Preferably, the currency amount received as the electronic currency data record is a first electronic portion of the electronic currency data record (segmented by the user). Here, another device (i.e., the user's device) can automatically contact a monitoring entity for segmentation, or the device can be used as a trusted entity to communicate with the monitoring entity. In a preferred embodiment, in this case, the other device will transmit the electronic currency data record to the device, requesting that it be segmented into, for example, a first predefined electronic portion of the electronic currency data record and a second predefined electronic portion of the electronic currency data record.

[0148] In a preferred embodiment, the device includes: at least one security element reading device configured to read security elements; a random number generator; and / or a security module with authorized access to a bank account and / or a communication interface of the bank.

[0149] In a preferred embodiment, the data storage device is a shared data storage device accessible by at least one other device, and each terminal includes an application configured to communicate with the monitoring entity for corresponding registration of electronic currency data records.

[0150] In one aspect of the invention, a payment system for exchanging monetary amounts is provided, the payment system comprising: a monitoring layer including a database, preferably a decentralized controlled database (DLT), in which concealed electronic currency data records are stored; a direct transaction layer including at least one device of one of the aforementioned types and another device (preferably of one of the aforementioned types); and / or an issuer entity for generating electronic currency data records and signatures, the signatures being stored in the decentralized controlled database.

[0151] This paper proposes a solution for issuing digital currency in the form of electronic currency data records, similar to the use of traditional (analog) banknotes and / or coins. The digital currency is represented by electronic currency data records. Like (analog) banknotes, these electronic currency data records can be used for all forms of payment, including peer-to-peer payments and / or POS payments. Knowing all components of a valid electronic currency data record (particularly the monetary amount and hidden amount) is equivalent to owning (ownership) the digital currency. Therefore, it is recommended that these valid electronic currency data records be kept confidential, for example, by storing and processing them within a secure element / module of a terminal. To verify the authenticity of the electronic currency data records and prevent double-spending, the hidden electronic currency data record is stored in a monitoring entity as the unique public representation of the electronic currency data record. Knowing or possessing the hidden electronic currency data record does not equate to owning money. Rather, it is equivalent to verifying the authenticity of a simulated payment method.

[0152] The monitoring entity also includes flags indicating the execution and planned processing of the concealed currency data record. The status of the corresponding concealed currency data record is derived from the processing-related flags, indicating whether the corresponding (unconcealed) currency data record is valid, i.e., ready for payment. Therefore, the recipient of the currency data record will first generate the concealed currency data record, and will have the validity of the concealed currency data record authenticated by the monitoring entity. A significant advantage of this solution according to the invention is that digital currency is distributed to terminals, retailers, banks, and other users of the system, but no digital currency or other metadata is stored in the monitoring entity, i.e., in the sharing entity.

[0153] The proposed solution can be integrated into existing payment systems and infrastructure. Specifically, according to this solution, a combination of analog and digital payment processes utilizing banknotes and coins is possible. The payment process can utilize banknotes and / or coins, but change or drawbacks can be recorded as electronic currency data. For example, ATMs and / or mobile terminals with appropriate configurations (especially suitable communication interfaces) can be provided for transactions. Exchanging banknotes or coins with electronic currency data records is also conceivable.

[0154] The creation, switching, splitting, combining, and deactivation steps listed here are all triggered by the corresponding creation, switching, splitting, combining, or deactivation commands. Attached Figure Description

[0155] The invention, along with other embodiments and advantages thereof, will now be explained in more detail with reference to the accompanying drawings, which illustrate exemplary embodiments of the invention only. Like components in the drawings have like reference numerals. These figures should not be considered to be true scale; individual elements in the figures may be enlarged or simplified.

[0156] In the diagram:

[0157] Figure 1 An embodiment of the payment system according to the present invention is shown;

[0158] Figure 2 An example of a monitoring entity is shown;

[0159] Figure 3 An embodiment of a payment system for splitting and switching electronic currency data records according to the present invention is shown;

[0160] Figure 4 An embodiment of a payment system for incorporating electronic currency data recording according to the present invention is shown;

[0161] Figure 5 An exemplary embodiment of the method flowchart and corresponding processing steps for coin data records according to the present invention is shown;

[0162] Figure 6 An embodiment of the method flowchart and corresponding processing steps for coin data records according to the present invention is shown;

[0163] Figure 7 Another exemplary embodiment of the method flowchart according to the present invention is shown.

[0164] Figure 8 An embodiment of the device according to the invention is shown;

[0165] Figure 9 Another exemplary embodiment of the method flowchart according to the present invention is shown;

[0166] Figure 10 Another exemplary embodiment of the method flowchart according to the present invention is shown;

[0167] Figure 11 Another exemplary embodiment of the method flowchart according to the present invention is shown;

[0168] Figure 12 Another embodiment of the device according to the invention and another device is shown; and

[0169] Figure 13 Another exemplary embodiment of the method flowchart according to the present invention is shown. Detailed Implementation

[0170] Figure 1 An embodiment of a payment system according to the present invention, including terminals M1 and M2, is shown. Terminals M1 and M2 may also be devices.

[0171] Here, electronic currency data record C is generated in issuer entity 1 (e.g., the central bank). i C. This pertains to electronic currency data records, including those with hidden amounts. i Generate concealed electronic currency data records Z i The data is then registered in a database, which can be configured here as a "hidden electronic data record ledger." In the context of this invention, the ledger is understood as a list, directory, and preferably a database structure. The electronic currency data record C1 is output to the first terminal M1.

[0172] For example, to generate a real random number as the hidden amount r for this purpose. i The hidden amount r i With monetary amount υ i Link them together, and then form the i-th electronic currency data record according to the present invention:

[0173] C i ={υ i , r i} (1)

[0174] Valid electronic currency data records can be used for payments. Therefore, the two values ​​υ i and r i The owner possesses the digital currency. However, digital currency in the system consists of valid electronic currency data records and corresponding masked electronic currency data records Z. i Defined by the pairs formed. By applying the homomorphic one-way function f(C) according to equation (2). i Obtain the concealed electronic currency data record Z i :

[0175] Z i =f(C i (2)

[0176] This function f(C) i The function f(C) is public, meaning that every system participant can call and use this function. i According to the definition in equation (3):

[0177] Z i =υ i ·H+r i ·G (3)

[0178] Here, H and G are generator points of group G, where the discrete logarithm problem is difficult, and the generator points G and H are unknown for the discrete logarithms of their respective bases. For example, G and H are generator points in elliptic curve cryptography (ECC), i.e., the private keys of ECC. These generator points G and H must be chosen in a way that the relationship between G and H is not publicly known; therefore:

[0179] G = n·H (4)

[0180] Link n must be practically impossible to find to prevent monetary amounts υ from being found. i Manipulated yet still able to calculate valid Z i Equation (3) is the “Pederson commitment for the ECC”, which guarantees the monetary amount υ i It can be passed (i.e., "promised") to monitoring entity 2 without being disclosed to it. Therefore, only the concealed coin data record Zi is sent (disclosed) to the public and remote monitoring entity 2.

[0181] Even though elliptic curve-based encryption is mentioned or described in this example, another encryption method based on discrete logarithms can be conceived.

[0182] Due to the hidden amount r i The entropy, equation (3) allows even in monetary amounts υ i A strong Z can be obtained even within a small range of values. i This means that a simple brute-force attack based on a mere estimation of monetary value is practically impossible.

[0183] Equation (3) is a one-way function, which means that from C i Calculate Z i It is easy because there are efficient algorithms, and from Z... i Calculate C i It is very difficult because there is no algorithm that can solve it in polynomial time.

[0184] Furthermore, equation (3) is homomorphic for addition and subtraction, that is, the following applies:

[0185] Z i +Z j =(υ i ·H+r i ·G)+(υ j ·H+r j ·G)=(υ i +υ j )·H+(r i +r j )·G (5)

[0186] Therefore, addition and subtraction operations can be performed either in the direct transaction layer 3 or in parallel in the monitoring layer 4, while the monitoring layer 4 is unaware of the electronic currency data record C. i The homomorphic property of equation (3) makes it possible to base solely on the masked coin data record Z. i To manage valid and invalid electronic currency data records C i And ensure that no new currency amount υ i Created.

[0187] Due to this homomorphic property, the coin data record C i It can be divided into the following according to equation (1):

[0188] C i =C j +C k ={υ j , r j}+{υ k , r k} (6)

[0189] in:

[0190] υ i =υ j +υ k (7)

[0191] r i =r j +r k (8)

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

[0193] Z i =Z j +Z k (9)

[0194] For example, using equation (9), one can easily check the following: Figure 3 The "splitting" or "splitting" process of the currency data records, which monitoring entity 2 is unaware of, is not C. i C j C k Specifically, examine the conditions of equation (9) to verify the segmented coin record C. j and C k And make monetary records C i invalid. Figure 3 The electronic currency data record C is shown in the figure. i This kind of division.

[0195] Similarly, electronic currency data records can also be stored together (combined), see... Figure 4 And its explanation.

[0196] Additionally, it is necessary to check whether (disallowed) negative currency amounts have been registered. Electronic currency data record C i The owner must be able to prove to monitoring entity 2 all monetary amounts in the processing operation. i All are within the value range [0, ..., n] without needing to notify the monitoring entity. 2. Currency amount υ i These proofs of range are also referred to as "range proofs." Ring signatures are preferably used as range proofs. For this exemplary embodiment, the monetary value and hidden amount of the electronic currency data record are parsed in bit representation, i.e., for 0≤j≤n and a j "Element" {0; 1}, υ i =∑a j *2 j And for 0≤j≤n and b j "Element" {0; 1}, r i =∑b j *2 j Preferably, C is performed for each bit. ij =a j ·H+b j ·G and C ij -a j • Ring signature of H, wherein, in one embodiment, it is possible to perform a ring signature only on certain bits.

[0197] Figure 1 Not shown in the image and will be explained later, for example, the new electronic currency data record C i Preferably, the output is not directly sent to the terminal, but is initially sent to the server entity of the commercial bank.

[0198] exist Figure 1 In the process, electronic currency data record C is generated by issuer entity 1. i And the concealed electronic currency data record Z is calculated by issuer entity 1 using equation (3). i And register it in monitoring entity 2. The first terminal M1 can record electronic currency data C i The data can be sent to a second terminal M2, or one of the processing steps (switching, combining, splitting) can be performed before transmission. For example, it can be transmitted wirelessly via WLAN, NFC, or Bluetooth. Transmission can also be protected by cryptographic encryption methods, such as negotiating a session key or using PKI infrastructure.

[0199] The electronic currency data record C sent i As C i*Received on the second terminal M2. When electronic currency data record C is received... i At that time, the second terminal M2 possesses electronic currency data records C i The asterisk (*) represents the digital currency. If the two terminals trust each other, no further steps are needed to complete the process. However, terminal M2 is unaware of the electronic currency data record C. i *Whether it is actually effective. Additionally, terminal M1 can also record electronic currency data C. i It is sent to a third terminal (not shown). To prevent this, a further preferred step is provided in the method.

[0200] In order to check the received electronic currency data record C i The effectiveness of * is determined by calculating the masked electronic currency data record Z in the second terminal M2 using the common one-way function of equation (3). i *. Then, the concealed electronic currency data record Z. i *The data is sent to monitoring entity 2 and searched there. If it matches a registered and validly masked electronic currency data record, the received currency data record C is considered valid. i The validity of * is indicated to the second terminal M2, and the received electronic currency data record C is confirmed. i *Equals the registered electronic currency data record C i Through a validity check, in one embodiment, the received electronic currency data record C can be determined. i *It remains valid, meaning it has not been used by another processing step or another transaction and / or undergone another change.

[0201] Preferably, the obtained electronic currency data record is then switched.

[0202] For the method according to the invention, it is important to know only the concealed electronic currency data record Z. i It does not authorize holders to make payments with digital currency. However, only the electronic currency data record C is known. i Authorized payment, that is, authorization to successfully complete a transaction, especially if the currency data record C i It is valid. In the electronic currency data record C i And the corresponding concealed electronic currency data record Z i There is a one-to-one relationship between them. The concealed electronic currency data record Z i It is registered with monitoring entity 2, for example, a public distributed database. This registration makes it possible to check the validity of data records, for example, to check whether a new monetary amount has been created (illegally).

[0203] A key differentiating feature compared to traditional solutions is the concealed electronic currency data recording Z.i It is stored in monitoring layer 4, and the electronic currency data is recorded in Z. i All processing operations are registered there, while the actual transfer of digital currency occurs in (secretly, i.e., unknown to the public) direct transaction layer 3.

[0204] To prevent multiple expenditures or ensure more flexible transfers, electronic currency data records can now be processed using the method according to the present invention. Table 1 below lists the various operations, and the specified commands also execute the corresponding processing steps:

[0205] Commands or steps Create a signature Create random numbers Create a cover Create range proof create 1 l 1 0 or 1 Deactivate 1 0 1 0 or 1 segmentation 0 1 3 0 or 1 Combination 0 0 3 1 Switch 0 1 2 1

[0206] Table 1 - Number of operations to be performed per coin of data processed in the terminal or issuing entity; further operations not listed here are required; alternative implementations to the listed implementations are implied to be conceivable.

[0207] Table 1 above shows that for each coin data record and each processing operation "Create", "Deactivate", "Split", "Combine", and "Switch", different operations can be provided: "Create Signature"; "Create Random Number"; "Create Mask"; and "Range Proof". Each processing operation is registered in monitoring entity 2 and attached to the masked coin data record Z in an immutable form. i The "create" and "deactivate" operations for electronic currency data records are performed only in a secure location and / or only by selected entities, such as issuer entity 1, while all other processing operations can be performed on terminals M1 through M3.

[0208] The number of operations for each process is marked in Table 1 as "0", "1", or "2". The number "0" indicates that terminal or issuing entity 1 does not need to perform this operation for the electronic currency data recording process. The number "1" indicates that terminal or issuing entity 1 must be able to perform the operation once for the electronic currency data recording process. The number "2" indicates that terminal or issuing entity 1 must be able to perform the operation twice for the electronic currency data recording process.

[0209] In principle, in one embodiment, it may also be planned that the issuer entity 1 performs a scope proof during creation and / or deletion.

[0210] The operations required by monitoring entity 2 for each processing operation are listed in Table 2 below:

[0211]

[0212] Table 2 - Number of operations to be performed per coin of data processed in the monitoring entity; further operations not listed here are required; alternative implementations to the listed implementations are implied to be other implementations that are also conceivable.

[0213] All operations in Table 2 can be performed in monitoring entity 2, which acts as a trusted entity, such as a distributed server, particularly a distributed trusted server, to ensure sufficient integrity of the electronic currency data records.

[0214] Table 3 shows the preferred options. Figure 1 Components installed by system participants in the payment system:

[0215] Commands or steps Issuer Entity terminal Monitoring Entities Random number generator (high security) yes - - Random number generator (deterministic) - yes - PKI for signing yes - - PKI used for signature verification - (yes) yes Read access on DLT yes yes yes Write access on DLT yes yes yes Activate electronic currency data record yes yes - Encrypted transmission yes yes - Secure storage device (yes) yes - / yes Covering unit yes yes - Range proof - yes - Inspection Scope Certificate - - yes DLT software - - yes

[0216] Table 3 - Preferred Units in System Components

[0217] Table 3 illustrates an overview of the components preferably used in each system participant (i.e., issuer entity 1, terminal M1, and monitoring entity 2). Terminal M1 can be configured as a wallet for recording electronic currency data, i.e., an electronic wallet, i.e., a data storage device for the terminal, in which a large amount of currency data records can be stored, and can be implemented in the form of an application, for example, on a retailer's, commercial bank's, or another market participant's smartphone or IT system, and transmit or receive electronic currency data records. Therefore, the components in the terminal as shown in Table 3 are implemented as software. It is assumed that monitoring entity 2 is based on DLT and is operated by multiple trusted market participants.

[0218] Figure 2 Showing from Figure 1 An exemplary embodiment of monitoring entity 2. In Figure 2 The example database is shown in tabular form, containing Z records of registered, concealed electronic currency data. i And its possible processing (as shown here). On the other hand, in the simplest embodiment of the database, only the currently valid masked coin data record Z will be stored. i The monitoring entity 2 is preferably located locally away from terminals M1 to M3 and is housed, for example, in a server architecture.

[0219] Each processing operation (create, deactivate, split, combine, and switch) is registered in monitoring entity 2 and immutably attached to the masked electronic currency data record Z. i The list of previously processed operations is used. Each operation or its check results (that is, intermediate results of processing) are recorded in monitoring entity 2.

[0220] The processes of "creating" and "deactivating" involve monetary amounts. iThe existence of the currency itself, namely the creation and destruction of the currency, requires additional approval from issuing entity 1 in order to register (i.e., log in) with monitoring entity 2. Other processing operations (splitting, combining, switching) do not require any authorization from issuing entity 1 or the order initiator (= the payer, e.g., the first terminal M1).

[0221] For example, by according to Figure 2 The corresponding list entries in the database are used to register the corresponding processing in monitoring entity 2. Each list entry has additional markers 25 to 28, which record the intermediate results of the corresponding processing that must be performed by monitoring entity 2. Markers 25 to 28 are preferably used as auxiliary and are discarded by the checking entity after the command is completed. Then, what remains are markers (not shown) regarding the validity of the (masked) electronic currency data records from columns 22a, 22b, 23a and / or 23b. When a processing command is received, these markers are, for example, in a "-" state, and are set to a "1" state after all checks are successful, and are set to a "0" state if at least one check fails. Possible structures for the list entries of currency data records include, for example, two columns 22a and 22b for the preceding currency data records (O1, O2), two columns 23a and 23b for the subsequent currency data records (S1, S2), a signature column 24 for the issuer entity (multiple issuer entities) 1, and four marker columns 25 to 28. Each entry in columns 25 through 28 has three selectable states: "-", "1", or "0". Column 25 (O flag) indicates whether the validity check of the electronic currency data record in columns 23a / b was successful. A state "1" means the validity check shows the electronic currency data record in column 23a / b is valid, a state "0" indicates the validity check shows the electronic currency data record in column 23a / b is invalid, and a state "-" indicates the validity check has not yet been completed. Column 26 (C flag) indicates whether the calculation of the amount neutrality of the masked electronic currency data record of the check command was successful. A state "1" means the calculation was successful, a state "0" indicates the calculation was unsuccessful, and a state "-" indicates the validity check has not yet been completed.

[0222] For example, the calculation to be performed in column 26 is:

[0223] (Z O1 +Z O2 )-(Z S1 +Z S2 )==0 (10)

[0224] Column 27 (R flag) indicates whether the validity check of (multiple) range proofs was successful, where a state "1" indicates that the validity check showed (multiple) range proofs were verifiable, a state "0" indicates that the validity check showed (multiple) range proofs could not be reproduced, and a state "-" indicates that the validity check has not yet been completed. Column 28 (S flag) indicates that signature verification was successful. A state "1" indicates that the validity check showed the signature could be identified as the signature of the issuing entity, a state "0" indicates that the validity check showed the signature could not be identified as the signature of the issuing entity, and a state "-" indicates that the validity check has not yet been completed.

[0225] A change in the state of one of the tags (also called "flags") requires approval from monitoring entity 2 and must then be stored in monitoring entity 2 in an immutable manner. Processing is final if and only if the requested tags 25 to 28 have been verified by monitoring entity 2, that is, have changed from state "0" to state "1" or state "1" after the corresponding check.

[0226] To determine whether the masked currency data record Z is valid, monitoring entity 2 (in the current variant) searches for the last changes affecting the masked currency data record. Importantly, the masked currency data record Z is valid if and only if it is listed in one of the following columns 23a and 23b for its final processing and that final processing has a corresponding final flag 25 to 28. Equally important, the masked currency data record Z is valid if and only if it is listed in one of the preceding columns 22a and 22b for its final processing and that final processing fails, i.e., at least one of the corresponding requested states of flags 25 to 28 is set to "0".

[0227] Equally important, the masked electronic currency data record Z is invalid for all other cases, such as if the masked electronic currency data record Z is not found in monitoring entity 2; or if the last processing of the masked electronic currency data record Z is listed in one of the following columns 23a and 23b, but that last processing never becomes the final processing; or if the last processing of the masked electronic currency data record Z is in one of the preceding columns 22a and 22b, and that last processing is final.

[0228] The final check by monitoring entity 2 is shown in columns 25 to 28: the status in column 25 indicates, according to the preceding columns 22a and 22b, whether the masked electronic currency data record is valid. The status in column 26 indicates, for example, whether the amount-neutral calculation according to equation (10) is correct. The status in column 27 indicates whether the range proof of the masked electronic currency data record Z can be successfully checked. The status in column 28 indicates whether the signature in column 24 of the masked electronic currency data record Z is a valid signature of issuer entity 1.

[0229] A status "0" in any of columns 25 to 28 indicates that the check failed. A status "1" in any of columns 25 to 28 indicates that the check succeeded. A status "-" in any of columns 25 to 28 indicates that the check has not been performed. This status can also have different values, as long as it is clear whether the check succeeded or failed and whether a check was performed.

[0230] As an example, five different processing operations are defined, and will be explained in detail here. (Reference) Figure 2 The corresponding list item.

[0231] For example, one processing operation is to "create" an electronic currency data record C. i The creation by issuer entity 1 in the direct transaction layer 3 includes selecting the currency amount υ. i and creating hidden amount r i As already described by equation (1). Figure 2 As shown, during the "Creation" process, no entries / tags are required in columns 22a, 22b, 23b, and 25 through 27. Masked electronic currency data record Z i It is registered in column 23a. This registration is preferably performed before being sent to terminals M1 to M3, and in particular, or has already been performed during creation by issuer entity 1, wherein equation (3) must be performed in both cases. Masked electronic currency data record Z i It is signed by issuer entity 1 when it is created; this signature is entered into column 24 to ensure the electronic currency data record C. i It is actually created by issuer entity 1, although other methods can also be used for this purpose. If the received Z i If the signature matches the signature in column 24, a flag (from "0" to "1") is set in column 28. The flags in columns 25 through 27 do not require a state change and can be ignored. No range proof is needed because monitoring entity 2 believes that issuing entity 1 does not issue any negative monetary amounts. However, in an alternative embodiment, it can be transmitted by issuing entity 1 in the creation command and checked by monitoring entity 2.

[0232] For example, the processing operation is "deactivation". Deactivation (that is, the destruction of currency) has a hidden electronic currency data record Z after the issuer entity 1 has successfully executed the deactivation command. i The effect becomes invalid. Therefore, the (masked) electronic currency data record to be deactivated can no longer be processed further in monitoring layer 4. To avoid confusion, the corresponding (unmasked) electronic currency data record C i It should also be deactivated in direct transaction layer 3. When "deactivated," the preceding column 22a is written into the electronic currency data record Z. iHowever, columns 23a and 23b are not used. When deactivated, the masked electronic currency data record Z must be checked. i To check if the signature matches the signature according to column 24, in order to ensure that the electronic currency data record C i It was actually created by issuer entity 1, although other methods could also be used to perform this check. If the signature Z transmitted along with the deactivation command... i If it can be confirmed that the issuer entity 1 has signed, then flag 28 is set (from "0" to "1"). Flags according to columns 26 and 27 do not require a state change and can be ignored. Flags according to columns 25 and 28 are set after appropriate checks.

[0233] For example, the processing operation is "splitting". Splitting (i.e., dividing the electronic currency data record Z) i Divided into two electronic parts, the currency data record Z j and Z k Initially executed in direct transaction layer 3, such as Figure 3 As shown, the generated currency amount υ j and hidden amount r j 。υ k and r k This is derived from equations (7) and (8). In monitoring entity 2, markers 25 to 27 are set, and the electronic currency data record Z is written in the previous column 22a. i Next column 23a is written to Z. j Next column 23b is written to Z. k According to columns 25 to 27, the required state changes occur after the corresponding check by monitoring entity 2, and the corresponding check results are recorded. The markers in column 28 are ignored.

[0234] For example, one processing operation is "merge". Merge (i.e., combine two electronic currency data records Z). i and Z j To form an electronic currency data record Z m Initially executed in direct transaction layer 3, such as Figure 4 As shown, the monetary amount υ is calculated. m and hidden amount r m In monitoring entity 2, set markers 25 to 27, and write the electronic currency data record Z in the first column 22a. i Write Z in the previous column 22b. j Next column 23b is written to Z. m The markers in columns 25 to 27 require a state change, and monitoring entity 2 must perform the corresponding check. A range proof must be provided to demonstrate that no new currency was created. The marker in column 28 is ignored.

[0235] For example, one processing operation is "switching". Switching is necessary if the electronic currency data record has already been sent to another terminal and is excluded from the update issuance by the sending terminal (here, M1). During switching (also called "conversion"), the electronic currency data record C received from the first terminal M1... k The data is exchanged for a new electronic currency data record C1 with the same monetary amount. The new electronic currency data record C1 is generated by the second terminal M2. This switching is necessary so that the electronic currency data record C1 received from the first terminal M1... k Invalidate (make it invalid), thereby preventing the same electronic currency data record Ck from being output again. This is because as long as the electronic currency data record Ck... k Without being switched, the first terminal M1 can record the electronic currency data C. k The data is transmitted to the third terminal M3 because the first terminal M1 already knows the electronic currency data record C. k For example, by inputting the obtained electronic currency data record C k Hidden amount r k Add new hidden amount r add To perform the switch, thereby obtaining the hidden amount r1 known only to the second terminal M2. This can also be performed in monitoring entity 2. To prove that only the new hidden amount r... add The received electronic currency data record Z was added to the masked k Hidden amount r k However, the monetary amount remains unchanged, therefore equation (11) holds true:

[0236] υ k =υ l (11)

[0237] It is valid; the second terminal M2 must be able to prove Z1-Z. k It can be expressed as a scalar multiple of G, that is, denoted as r. add *G. This means that only the hidden amount r is generated. add And the monetary amount of Z1 is equal to Z. k The monetary amount, i.e., Z l =Z k +r add *G. This is done using the public key Z. l -Z k =r add *G generates the signature to accomplish this.

[0238] exist Figure 3 The image shows an embodiment of a payment system according to the present invention for splitting and switching electronic currency data records. Figure 3In the middle, the first terminal M1 has received the coin data record C. i And now we hope not to use the full amount of currency. i Instead, only a portion of v is used. k Execute the payment transaction. For this, the currency data record C... i It is to be divided. Therefore, the monetary amount is first divided:

[0239] υ i =υ j +υ k (12)

[0240] Here, each received amount υ j υ k It must be greater than 0 because negative monetary amounts are not allowed. Additionally, a new hidden amount is derived:

[0241] r i =r j +r k (13)

[0242] Then, according to equation (3), record C from the coin data. j and C k Obtain the hidden coin data record Z j and Z k And register it in monitoring entity 2. For the split, record Z using currency data. i Describe the preceding column 22a using Z. j Describe column 23a using Z. k See column 23b for a description. The markers in columns 25 to 27 require a state change, and monitoring entity 2 must perform the corresponding check. The marker in column 28 is ignored.

[0243] Then, the coin data record (C here) k The electronic currency data received from the first terminal M1 is sent to the second terminal M2. To prevent double spending, a switching operation is useful so that the electronic currency data received from the first terminal M1 is recorded as C. k The exchange is performed on a new electronic currency data record C1 with the same monetary amount. The new electronic currency data record C1 is generated by the second terminal M2. The monetary amount of currency data record C1 is adopted and remains unchanged, as shown in equation (11). Then, according to equation (14), the new hidden amount r... add Added to received electronic currency record C k Hidden amount r k ,

[0244] r l =r k +r add (14)

[0245] This yields the hidden amount r1, known only to the second terminal M2. To prove that only the new hidden amount r... add Added to received electronic currency data record Z k The hidden amount rk, but the monetary amount remains unchanged (υ). k =υ1), the second terminal M2 must be able to prove Z1-Z k It can be represented as a multiple of G. This is based on equation (15) using the public signature R. add To be completed:

[0246] R add =r add ·G (15)

[0247] =Z l -Z k =(v l -v k )*H+(r k +r add -r k )*G

[0248] Where G is the point where the elliptic curve is generated. Then, the coin data record C1 to be switched is masked by equation (3) in order to obtain the masked coin data record Z1. Then, the private signature r add It can be used in monitoring entity 2 to, for example, sign the masked electronic currency data record Z1 to be switched, which is valid as the second terminal M2 has already added only the hidden amount r to the masked electronic currency data record. add And there is no proof of attached monetary value, that is, v1 = v k .

[0249] The proof is as follows:

[0250] Z k =υ k ·H+r k ·G (16)

[0251] Z l =υ l ·H+r l ·G=υ k ·H+(r k +r add )·G

[0252] Z l -Z k =(r k +r add -r k )·G

[0253] =r add·G

[0254] Figure 4 An exemplary embodiment of a payment system according to the present invention for combining electronic currency data records is shown. Two currency data records C i and C j Received at the second terminal M2. Similar to... Figure 3 The split, now done by recording the two coin data records C i and C j The new currency data record Z is obtained by adding the currency amount and the hidden amount. m Then, the received coin data record G will be combined. m The data of the concealed currency, Z, is hidden. m It is registered in the monitoring entity.

[0255] exist Figure 3 and Figure 4 The diagram again illustrates a variant of the database for monitoring entity 2, containing a list of processing operations for masked coin data records. Other variants of the database can also be used, such as masked coin data records with status or only valid masked coin data records, as already referenced. Figure 2 As mentioned.

[0256] Figures 5 to 7 These are exemplary embodiments of the method flowchart of method 100 according to the present invention. They will be explained together below. Figure 5 and Figure 6 .

[0257] Steps 101 to 104 are optional for further methods and are described using the example of terminal M1. In optional steps 101 and 102, after creating the electronic currency data record, the issuer entity 1 requests the currency data record and provides it to the first terminal M1. In step 103, the signed, masked electronic currency data record is transmitted to the monitoring entity 2. In step 103, the received electronic currency data record C... i According to equation (3), it is masked, such as Figure 1 As explained in [the document]. Then, in step 104, the concealed electronic currency data record Z... i Registered in monitoring entity 2. It is conceivable that the concealed electronic currency data record is only valid in the monitoring entity upon registration by a participant (such as a terminal device or server). Alternatively, as per [the relevant regulations]... Figure 1 As explained, after step 102, the masked electronic currency data record Z i The electronic currency data record may already be registered as a valid mask in monitoring entity 2. Optionally, terminal M1 may switch the received electronic currency data record in step 104, as will be described in more detail in step 108.

[0258] In step 105, the coin data record C i It is sent to the second terminal M2 in the direct transaction layer 3. In optional steps 106 and 107, the validity of the previous masking is checked, in which case the monitoring entity 2 confirms the coin data record Z if successful. i Or C i The effectiveness.

[0259] In step 108, the received coin data record C k Switched (received coin data record C) i (Of course, it can also be switched to a new coin data record C) i This currency data record C k It became invalid and prevented double spending. For this purpose, the sent currency data record C... k Currency amount υ k The amount υ1 is used as the "new" currency. Additionally, as explained in equations (14) to (17), a hidden amount r1 is created. The hidden amount r is then appended. add It was used to prove that the second terminal M2 did not generate new currency (in the form of a higher currency amount). Then, among other things, the masked currency data record Z1 to be switched was transmitted to monitoring entity 2, and from C... k The switch to C1 was indicated.

[0260] In step 108', the corresponding check is performed in monitoring entity 2. According to Figure 2 The table in Z k The data is input into column 22a, and the coin data record Z1 to be rewritten is input into column 23b. Then, the monitoring entity 2 regarding Z... k Whether it is still valid, i.e., Z k Whether the final processing is input into one of column 23a / b (as Z) k (Proof that no further splitting, deactivation, or combination has been performed) and a check for failure in the final processing. Additionally, Z1 is input into column 23b, and the markers in columns 25, 26, and 27 are initially set to "0". Now, execution is performed regarding Z... l The validity check can be performed using the checks according to equations (16) and (17). If successful, the flag in column 25 is set to "1", otherwise it is set to "0". Now, the check is performed, and the calculation according to equation (10) indicates that Z k Z1 is valid, and the flag in column 26 is set accordingly. Range consistency is also checked, and then the flag in column 27 is set. If all three checks are successful, and this is acknowledged accordingly in monitoring entity 2, the coin data record is considered switched. This means that coin data record C...k It is no longer valid, and the coin data record C1 is now valid. If the third terminal M3 queries the monitoring entity 2 about the validity of the (redistributed) coin data record, then secondary spending is no longer possible.

[0261] Generally speaking - with Figure 5 The illustrations in the text are slightly different - electronic currency data records created by the issuing entity C i The electronic currency data record is sent (issued) to an entity within a commercial bank (such as a server, computer, etc.). The commercial bank's (server) entity provides the electronic currency data record to the terminal. In steps 101 and 102, terminal M1 requests and then receives the electronic currency data record from the commercial bank's entity. Specifically, when terminal M1 requests and receives the electronic currency data record C from the commercial bank's server... i At that time, it is useful to switch in step 104.

[0262] In step 109, the two coin data records C k and C i Combined to form a new coin data record G m The result is the currency data record C. k C i It becomes ineffective and prevents secondary expenditure. Therefore, the monetary amount υ m Composed of two monetary amounts υ k and υ i Formed. Therefore, the hidden amount r m Two hidden amounts r k and r i Formation. In addition, the masked coin data record to be combined is obtained through equation (3), and it (along with other information) is transmitted to monitoring entity 2, and combined as processing is requested.

[0263] In step 109', the corresponding check is performed in monitoring entity 2. In this case, according to Figure 2 The table in Z m It is input into column 23b. Then, monitoring entity 2 checks Z. k and Z i Is it still valid, i.e., Z? k or Z i Whether the final processing is input into one of column 23a / b (as Z) k and Z i (Proof that it has not been further split, deactivated, or combined), and whether the final processing check failed. Additionally, the markers in columns 25, 26, and 27 were initially set to "0". Now check Z. mWhether it is valid can be determined using the checks according to equations (16) and (17). If successful, the flag in column 25 is set to "1", otherwise to "0". Now, the check is performed, and the calculation of Z according to equation (10) is used. i Add Z k Equal to Z m And accordingly set the markers in column 26. Also check if the ranges are consistent, and then set the markers in column 27.

[0264] In step 110, the coin data record Ci is split into two parts, coin data record C. k and C j This makes the currency data record C i Invalid, and will make the two split partial currency data records valid. Therefore, the currency amount υ i Divided into two monetary amounts υ k and υ j Therefore, the amount r is hidden. i Divided into two hidden amounts r k and r j Additionally, the partially masked coin data record Z is obtained through equation (3). k and Z j They are then transmitted to monitoring entity 2 along with additional information (e.g., range proof), and the segments are processed as requested.

[0265] In step 110', the corresponding check is performed in monitoring entity 2. According to the table in the figure, Z... j and Z k This is input into column 23a / b. Then, monitoring entity 2 checks Z. i Is it still valid, i.e., Z? i Whether the final processing is input into one of column 23a / b (as Z) i (Proof that it has not been further split, deactivated, or combined), and whether the final processing check failed. Additionally, the markers in columns 25, 26, and 27 were initially set to "0". Now check Z. j and Z k Whether it is valid can be determined using the checks according to equations (16) and (17). In the case of success, the marker in column 25 is set to "1". Now, the check is performed, and the calculation of Z according to equation (10) is used. i Equal to Z k Add Z j And accordingly set the markers in column 26. Also check if the ranges are consistent, and then set the markers in column 27.

[0266] exist Figure 8The image shows an embodiment of the device M1 according to the present invention. Device M1 can record electronic currency data C i Stored in data storage devices 10 and 10'. Electronic currency data record C i The data can be obtained on the data storage device 10 of device M1, or on the external data storage device 10'. When using the external data storage device 10', the electronic currency data record C i It can be stored in an online storage device, such as a data storage device 10' from a digital wallet provider. Alternatively, dedicated data storage media, such as a network-connected storage device, can also be used in a dedicated network.

[0267] In one scenario, electronic currency record C i It is shown as a printed output on paper. Electronic currency data records can be represented by QR codes, QR code images, or they can be files or strings (ASCII).

[0268] Device M1 has at least one interface 12, which can be used for outputting coin data records C. i The communication channel. This interface 12 is, for example, used to display coin data records C on a display unit (display). i The optical interface, or the one used to record electronic currency data. i Printing is done via a printer that prints output onto paper. Interface 12 can also be a digital communication interface, for example, for near-field communication (such as NFC, Bluetooth), or an internet-compatible interface (such as TCP, IP, UDP, HTTP, or chip card access as a security element). Interface 12 can also be a data interface, for example, enabling the recording of currency data C. i Send between devices via an application (e.g., an instant messaging service) or as a file or string.

[0269] Furthermore, interface 12 or another interface (not shown) of device M1 is configured according to Figures 1 to 6 The description in the document interacts with monitoring entity 2. Therefore, device M1 is preferably online.

[0270] Additionally, device M1 may have an interface for receiving electronic currency data records. This interface is configured to receive, for example, visually presented currency data records via an acquisition module such as a camera or scanner, or digitally presented currency data records received via NFC, Bluetooth, TCP, IP, UDP, or HTTP, or currency data records presented through an application.

[0271] The device M1 also includes a computing unit 13, which can perform the above-described method for masking coin data records and processing of coin data records.

[0272] Device M1 is online and can preferably identify when it is connected to a WLAN via location identification module 15. Optionally, a specific WLAN can be marked as preferred (= location area), such that device M1 performs special functions only when registered in that WLAN. Alternatively, location identification module 15 identifies when device M1 is in a predefined GPS coordinate system including a defined radius and performs special functions based on the location area thus defined. This location area can be manually entered into device M1 or introduced into device M1 via other units / modules. When a location area is identified, the special functions performed by device M1 include sending electronic currency data records from security module 14 to external data storage 10 / from external data storage 10 to security module 14, and, if necessary, sending masked currency data records Z to monitoring entity 2, for example, in the context of the above-described processing of currency data records.

[0273] In the simplest case, all coin data records C i Upon receipt, the data is automatically combined at terminal M1 to form a currency data record (see Combining Process or Combining Steps). That is, once a new electronic currency data record is received, a combining or switching command is transmitted to monitoring entity 2. Device M1 can also prepare electronic currency data records with denominations determined by an algorithm and store them in data storage devices 10, 10', making the payment process possible even without a data connection to monitoring entity 2.

[0274] Figure 9 An exemplary embodiment of the method flowchart of the method 200 according to the present invention is shown. Coin data record C i The following management is implemented in device M1.

[0275] As described above, in step 201, device M1 can identify a predefined location area via location identification module 15. Within this location area, terminal M1 can then be automatically charged or discharged to record electronic currency data C. i monetary amount in form υ i A predetermined threshold, namely, a fixed limit X. For this purpose, device M1 is personalized. Therefore, bank details (bank account data) or security module and threshold X are specified via an interface. The user may need to verify themselves in the bank account or security module in order to withdraw monetary amounts from the bank account via direct debit, transfer them to the bank account, receive monetary data records from the security module, or transmit them to the security module.

[0276] The goal of Method 200 is to always make the threshold X available as a currency amount in the device, either in a single (combined) electronic currency data record or in all electronic currency data records.

[0277] In terminal M1, after receiving the coin data record, all coin data records C... i These can be automatically combined to form a single currency data record (see the combining steps). For example, a currency amount υ greater than a threshold X. i (Here abbreviated as Y) coin data record C i This can be achieved through combination. If the specifications are no longer met, for example in... Figure 9 If step 202 is not true, then device M1 will split the coin data record C in step 203. i This results in the acquisition of a first electronic partial currency data record with a monetary amount X and a second electronic (partial) currency data record C with a monetary amount M = YX. Both partial currency data records are also registered in monitoring entity 2. In step 204, the second (partial) currency data record C is returned to the issuing entity. The issuing entity credits the monetary amount M to the user's bank account; this can be done, for example, by deposit or transfer. If an electronic currency data record with (exact or approximate) monetary amount M already exists in the device, step 203 can be omitted, and the currency data record can be directly returned in step 204.

[0278] In another variant not shown in the diagram, a transfer is triggered, using which the difference between the monetary amount Y and a threshold X (for the monetary amount) is credited to a pre-personalized bank account. Simultaneously, the split-combined monetary C... i (Segmentation step), and transmit the corresponding partially concealed coin data record to monitoring entity 2 so that the partially recorded coin data record (YX) can be sent to the security module or transfer party.

[0279] Based on the "yes" condition in step 202, if there are currency data records C with a currency amount less than the threshold X... i The data stored in device M1 (e.g., if the payment is in the amount XY) is used to request a direct debit in step 205, using the direct debit threshold X and the stored currency data record C retrieved from the bank account. i The difference between the monetary amount Y. Meanwhile, as described above, in step 205, device M1 receives a new currency data record from issuer entity 1, see the creation step.

[0280] Alternatively, or in addition to the threshold as a specification, there can be a denomination specification. The denomination specification defines how many electronic currency data records of which denomination (i.e., which currency amount) should be available in the device. The sequence of method 200 can be essentially similar. Simply put, it requests and receives lost electronic currency data records, or returns excess electronic currency data records. In an optional preliminary step, electronic currency data records can be generated according to the denomination specification through segmentation and combination.

[0281] The steps of method 300 are also included. Figure 9 As shown in the diagram, access to the security module 14 of device M1 is provided. If the condition is "No" in step 301, the amount YX is written to the security module 14 in step 302. If the condition is "Yes" in step 301, the amount YX is loaded from the security module 14 in step 303. For this purpose, user authentication is required.

[0282] Here, security module 14 is a data storage device that can be accessed after successful additional authentication. Security module 14 can be within device M1, for example, in an area protected by additional security features, or it can be external to device M1, for example, on a server provided by a trusted third party. Security module 14 can process coin data records and register them with monitoring entity 2.

[0283] Figure 10 Another exemplary embodiment of the method flowchart of method 400 according to the present invention is shown. Device M1 includes a data storage device 10 and a security module 14. In step 401, another device M2 requests payment amount Y. In step 402, device M1 identifies that it does not have amount Y in the data storage device 10 because it is greater than a predetermined threshold X. Therefore, in step 403, M1 automatically requests amount YX (or Y) from security module 14. If amount YX (or Y) exists in security module 14 (not shown here), the amount is sent from device M1 to device M2, either through a previous transfer of the amount from security module 14 to device M1 or through a direct transfer from security module 14 to the other device M2. In addition to the currency data record of security module with amount YX, device M1 will also send currency data record with amount X.

[0284] according to Figure 10 Security module 14 does not have an inventory of amount YX (or Y). Therefore, the amount X in security module 14 is less than the requested amount YX (or Y). Therefore, in step 404, the security module requests a currency data record C with a currency difference YX from issuing entity 1 or (not shown) from another liquidity provider. Issuing entity 1 generates the corresponding currency data record C with the difference YX in step 405 and sends it to security module 14 in step 406. In addition, the signed, masked electronic currency data record is transmitted to monitoring entity 2, see step 407 (see details). Figures 1 to 7 The issuer entity preferably maintains a large number of already generated and registered currency data records, thus omitting step 407 and generation. The liquidity provider processes requests for electronic currency data records of currency value YX. Figure 10(Not shown in the image). Perform the following steps: After the splitting step, register with monitoring entity 2 to generate an electronic currency data record of the desired currency value; and transmit the requested electronic currency data record to security module 14. Security module 14 combines currency data record X with currency data record YX to obtain the amount Y as the new currency data record, see step 408 (details also see...). Figures 1 to 7 In step 409, the combined coin data record Y is sent directly from security module 14 or via device M1 to another device M2. Figure 10 The flowchart above the dashed line also corresponds to, for example Figure 9 Method steps 202, 203, 204 or 301, 302 and 303.

[0285] Figure 10 The flowchart below the dashed line also corresponds to, for example Figure 9 Method steps 202, 205, 206 or 301, 303, and 304. Here, in step 410, another device M2 sends a payment of amount Y to device M1. In step 411, device M1 identifies that the amount Y exceeds the threshold X. Therefore, in step 412, device M1 initiates the transfer of the corresponding surplus, here a transfer of monetary amount XY. For this purpose, in step 413, security module 14 automatically initiates a transfer to bank 1 (in... Figure 10 In this context, the bank is also the issuing entity 1; however, the ideas of this invention are not limited thereto. The segmentation step is performed by the security module 14 and registered in the monitoring entity 2, see step 414 (details also see...). Figures 1 to 7 The splitting step 414 can be performed in parallel or before the transfer step 413. In particular, returning or sending the split coin data record to the issuer entity can trigger the transfer.

[0286] Figure 11 Another exemplary embodiment of the method flowchart of the method 500 according to the present invention is shown. Device M1 includes a method for recording electronic currency data C. i The data storage device 10. A portion of this storage device 10 can be synchronized with other devices M3 via an application 5 installed on and running on each of the terminals M3 and M1, see step 501. This means that different users of these synchronized devices M1 and M3 can simultaneously access the electronic currency data record C. i They share the electronic currency data record C stored in this part of the data storage device 10. i .

[0287] In addition to electronic currency data records C i In addition, the identification data of devices M1 and M3 to be synchronized are also stored in the shared part of the data storage device 10.

[0288] For synchronization, each device M3 and M1 has application 5—essentially a shared digital wallet. Application 5 ensures that information is transmitted to devices M3 and M1. See step 502; application 5 also communicates with monitoring entity 2.

[0289] According to Figure 11 In the system, for security reasons, electronic currency data records C i Instead of being centrally stored in Application 5, the data is stored locally on each of devices M3 and M1. Device M1 can now access the shared electronic currency data record C via Application 5 (i.e., the shared digital wallet) through monitoring entity 2. i One of the processing steps is executed. Based on the request in step 502, application 5 contacts monitoring entity 2 in step 503 as part of the segmentation step (see details). Figures 1 to 7 ), so that the original electronic currency data record C i Deactivate (=declare invalid), and in order to record the correspondingly segmented or newly created masked coin data records in monitoring entity 2 and declare them valid. Then, in step 505, application 5 resynchronizes devices M3 and M1.

[0290] Figure 12 An exemplary embodiment of a device M1 according to the present invention is shown, which is communicatively connected to another device M2 for sending monetary amounts in the form of currency data records. Regarding device M1, see reference... Figure 8 The description. Another device M2 indicates, for example, that can directly receive and send electronic currency data records C. i The machine. Additionally, it can calculate the masked electronic currency data record, that is, perform a masking step on the electronic currency data record. Another device M2 can communicate with monitoring entity 2 (not shown). The other device M2 is, for example, a self-service terminal—similar to an ATM—or a service system consisting of multiple components, such as a registration system. The other device M2 includes, for example, a card reader to be able to read secure elements (chip cards, eUICC) through which the user can be explicitly identified. Additionally, for example, the other device M2 includes a keyboard. Additionally, the other device includes, for example, an interface 12 for outputting currency data records, which may correspond exactly to interface 12 or the interface of device M1. Therefore, any information regarding device M1 is referenced here. For example, interface 12 of the other device M2 is an output interface for photoelectrically detectable currency data records, such as a screen or monitor; or a digital (protocol or data) interface, such as NFC, Bluetooth, TCP, IP, UDP, HTTP, or an interface for sending data records using an application (such as a text file, ASCII string, instant messaging service) or according to wallet application 5.

[0291] In addition, another device M2 has one or more interfaces for receiving coin data records corresponding to the corresponding interfaces of device M1, such as optical interface 11 (scanner or camera) or digital interface, possibly combined with a digital interface for outputting coin data records Ci.

[0292] In addition, another device includes one or more interfaces for communicating with monitoring entity 2, for example, for sending masked coin data records Z. i .

[0293] In addition, device M2 includes, for example, an input and / or output module 16 for banknotes and / or a random number generator or an interface for receiving random numbers. The registration module 17 of another device M2 can be used, for example, to access the account system of one (or more) commercial banks, thereby ensuring that the user can also access his / her bank account. A key for signing the deactivation process may also optionally be available in another device M2. The other device M2 also includes a data storage device 10 or means for accessing an external data storage device 10'. Device M2 receives data from the data storage device 10 or via a record C that manages the electronic currency data in the external data storage device 10. i The machine operator's interface or the exchange obtains valid electronic currency data records C i .

[0294] When paying with cash (e.g., at a registration terminal), the user of device M1 can receive data records as banknotes and electronic currency. i Change is given in combination.

[0295] In one scenario, the user receives banknotes as change, rounded to the next denomination, and as electronic currency data record C. i The second part of the change. (Multiple) electronic coin data records C i It can receive or print out electronically. For this purpose, the register module 17 of another device M2 notifies the computing unit 13 of another device M2 how much to pay as electronic currency data record C. i The change is then given. Then, the calculation unit 13 of another device M2 performs the splitting step and accordingly notifies the monitoring entity 2 to register the split portion of the coin data record. Optionally, device M1 can confirm to the user, for example, through vibration or light signals, that the second portion of the change has been recorded as electronic coin data C. i Received.

[0296] In an alternative scenario, the user of device M1 receives change from another device M2, rounded to the next denomination. Device M1 then records C with one or more electronic coin data. iThe "negative" change is sent to another device M2 in the form of a [missing information]. The (multiple) electronic coin data records can be output electronically or printed. For example, a user has a [missing information]... Invoice, and with one Payment was made in banknotes. The user of device M1 received a banknote as cash. The banknote (= the next largest denomination). Device M1 records C electronically as banknote data. i The form of monetary amount The change is transferred to device M2 as "negative change". Here, the register module 17 of another device M2 records the electronic coin data C. i The system notifies the computing unit 13 of another device M2 of the amount of currency υ to be requested from device M1. This request is received in device M1. Negative change is received in the other device M2 via a split command and related registration at monitoring entity 2. Device M2 executes a switching command. Optionally, device M1 may indicate transaction confirmation to the user via, for example, vibration or light signals.

[0297] Figure 13 Another exemplary embodiment of the method flowchart of the method 600 according to the present invention is shown. A method for paying cash in another device M2 is shown above the dashed line. In this case, the other device M2 must have an output component 16 for cash and can generate or obtain a hidden amount, that is, a random number r.

[0298] In step 601, device M1 saves the electronic currency data record C. i And wanting to convert it into cash. Therefore, if it's a self-service terminal, the user of device M1 selects the "Pay Cash" function on another device M2. In step 602, device M1 records the electronic currency data C. i The data is sent to device M2. Another device M2 receives the electronic currency data record C. i Another device, M2, generates a new entropy factor, which is a random number r. j And use it to form new electronic currency data records C j As part of the switching step according to step 603, such as Figures 1 to 7 As described in detail. Then, another device M2, according to f(C) i ) and f(C j Calculate the mask Z i and Z j And record the electronic currency data in C i Switch to C j Therefore, the concealed currency data record Z i and Z jThe request is sent to monitoring entity 2, see step 604. If monitoring entity 2 does not perform the switch (e.g., because the check required for the switch fails, see above), another device M2 rejects the user's request from device M1 (not shown here). If monitoring entity 2 can register the switch (check successful), then in step 605, the electronic currency data record C... j It was rewritten to another device M2, and C i The switch becomes invalid. In step 606, monitoring entity 2 confirms the switch. Then, another device M2 outputs the currency amount as cash, see step 607. Electronic currency data record C j The data is either stored locally in another device M2 or transmitted to the operator of device M2. Alternatively, the other device M2 (if authorized to do so) can transmit the data via a concealed electronic currency record Z. i Register the deactivation step in monitoring entity 2. Method 600 for issuing cash can be used with... Figure 12 The issuance changes described herein, combined with the existing ones, allow another device M2 to issue a portion of the currency amount υ from the banknote module 16 as a banknote (rounded up or down to the next denomination), while the remainder is recorded as electronic currency data C. This saves device M1 the segmentation step.

[0299] Figure 13 Below the dashed line is data record C of electronic currency withdrawal from a bank account. i The method. In this case, either the cash is deposited into another device M2 via the banknote module 16 (step 608), or simply a request is made to C. j The value (step 609). In this case, another device M2 allows the user of device M1 to access his / her bank account at bank 1 (which is also the issuing entity, without limiting the concept of the invention).

[0300] The user of device M1 selects the function "Retrieve Electronic Currency Data Record" on device M2 and authenticates and / or identifies using his / her secure element (bank card, eUICC, etc.). This allows for transfers, direct debits, credit card transactions, etc. Here, in step 610, the funds in the bank account of the user of the first device M1 are queried and confirmed if necessary.

[0301] After the transaction has been successfully executed, device M2 receives electronic currency data record C from issuer entity 1. i (See details) Figures 1 to 7 Issuer entity 1 may specifically create currency data records, or, for example (as a commercial bank), may maintain prepared currency data records created by another entity (the central bank). Alternatively, an electronic currency data record C is generated to represent the requested value of the transaction. iTo this end, the desired currency value υ and a random number are linked together to form a hidden amount r (generated by a random number generator). In step 611, a signed, masked electronic currency data record bearing the signature of the device M2 (or issuer entity 1) is sent to monitoring entity 2.

[0302] In step 612, it will record the generated electronic currency data C i (Optical ground, electronic ground) are sent to device M1.

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

[0304] Reference Symbol List

[0305] 1. Issuing entity or bank

[0306] 2. Monitoring Entities

[0307] 21 Command Input

[0308] 22a, b Input of the (previous) electronic currency data records to be processed

[0309] 23a, b Input of processed (subsequent) electronic currency data records

[0310] 24 signature entries

[0311] 25. Markings for validity checks

[0312] 26. Calculate the marks for inspection.

[0313] 27. Markings for scope proof checks

[0314] 28 Signature check markers

[0315] 3. Direct Trading Layer

[0316] 4. Monitoring layer

[0317] 5. Application-Shared Wallets

[0318] 10' 10' Data storage device

[0319] 11 Monitors

[0320] 12 interfaces

[0321] 13 Calculation Units

[0322] 14 Security Module

[0323] 15. Location recognition module

[0324] 16. Banknote Module

[0325] 17 Register Module

[0326] M1 First Equipment

[0327] M2 Second Equipment

[0328] M3 Third Equipment

[0329] C i Electronic currency data records

[0330] C j C k Segmented electronic currency data records

[0331] C1 Electronic currency data record to be switched

[0332] C m Electronic currency data records to be combined

[0333] Z i Covert electronic currency data records

[0334] Z j Z k Concealed segmented electronic currency data records

[0335] Z1 conceals the electronic currency data record to be switched.

[0336] Z m The concealed electronic currency data records to be combined

[0337] υ i Currency Amount

[0338] υ i υ j Split currency amount

[0339] υ1 The monetary amount recorded in the electronic currency data.

[0340] υ m Currency amounts recorded by electronic currency data that have been or will be integrated

[0341] r i Hidden amount, random number

[0342] r j r j Hidden Amounts in Segmented Electronic Currency Data Records

[0343] r m Hidden amounts in electronic currency data records that have been or will be integrated

[0344] C i * Records of sent electronic currency data

[0345] C j *、C k * Record of split electronic currency data sent

[0346] Z i * Covertly recorded electronic currency data.

[0347] Z j *、Z k * The concealed transmission of fragmented electronic currency data records

[0348] f(C) Homomorphic one-way function

[0349] [Z i Sig I Signature of the issuer entity

[0350] 101-108 Method steps according to exemplary embodiments

[0351] 201-205 Method steps according to exemplary embodiments

[0352] 301-302 Method steps according to exemplary embodiments

[0353] 401-414 Method steps according to exemplary embodiments

[0354] 501-505 Method steps according to exemplary embodiments

[0355] 601-612 Method steps according to exemplary embodiments

Claims

1. A device configured to directly send electronic currency data records to another device, comprising: – A computing unit, communicatively connected to a data storage device, wherein at least one electronic currency data record is stored in the data storage device, and the at least one electronic currency data record includes a monetary amount and a hidden amount; – An interface, at least for outputting the at least one electronic coin data record to the other device; and –The computing unit is configured as follows: – Switch the stored electronic currency data record of the first currency amount to a new electronic currency data record of the first currency amount, wherein the monitoring entity includes a database that stores the masked electronic currency data record and registers the masked electronic currency data record of the stored electronic currency data record in the database. –The new electronic currency data record is masked by applying a homomorphic one-way function to the new electronic currency data record to obtain the masked new electronic currency data record, which is then used to register the masked new electronic currency data record in the monitoring entity. as well as – The electronic currency data record is output through the interface, and after the electronic currency data record is output to the other device, further transmission in conjunction with the device is invalidated; The device is configured to send the new electronic currency data record directly to the other device without using a network connection, and the new electronic currency data record can be used by the other device immediately for subsequent transactions after receiving the new electronic currency data record from the device. The validity status of the masked new electronic currency data record is derived from the database without recording the transmission of the new electronic currency data record from the device to the other device, thus keeping the device and the other device anonymous in the monitoring entity.

2. The device according to claim 1 further includes an interface for receiving electronic currency data records, said interface being one of the following: - The device's electronic detection module is configured to photoelectrically detect electronic currency data records represented in a visual form; – Protocol interface for wirelessly receiving electronic currency data records from another device via a communication protocol for wireless communication; – Data interface for receiving electronic currency data records from another device via an application; and / or – The interface is also configured to output electronic currency data records.

3. The device of claim 1, further comprising means for accessing a security module, wherein the security module is configured to securely store at least one electronic currency data record.

4. The device according to claim 3, wherein, The computing unit is also configured to automatically send at least one electronic currency data record from or to the device to conform to the specifications of the electronic currency data record stored in the device, including a threshold for the monetary amount of the electronic currency data record stored in the device and / or the denomination specifications of the electronic currency data record stored in the device.

5. The apparatus of claim 4, wherein, To comply with the specifications, the computing unit is also configured as follows: – Send electronic currency data records from the device to the security module or from the security module to the device; or – The electronic currency data record is sent from the issuer entity to the device or from the device to the issuer entity.

6. The device according to claim 3, wherein The computing unit is configured to exchange electronic currency data records with other devices through the interface, and only with the issuer entity through the security module, including receiving or returning electronic currency data records; and / or wherein, The issuer entity issues electronic currency data records only to the device's security module and / or retrieves electronic currency data records only from the device's security module.

7. The device according to claim 1, further comprising a location identification module, the location identification module being configured to identify a predetermined location area, wherein, The computing unit is also configured to perform special functions only in the predetermined location area, including automatic transmission of electronic currency data records related to specifications, exchange of electronic currency data records with security modules or issuer entities, or registration of concealed electronic currency data records.

8. The apparatus of any of the preceding claims, wherein, The computing unit is further configured to: - Detect the difference between the amount of currency to be sent and the amount of currency recorded in the stored electronic currency data record; – Request an electronic currency data record with a monetary amount equal to the detected difference; - Receive the requested electronic currency data record.

9. The device according to claim 8, wherein, The computing unit is further configured to: – Combine the received electronic currency data records with the stored electronic currency data records, and mask the combined electronic currency data records for registration with the monitoring entity, and – Send the combined electronic currency data record, wherein the currency amount in the combined electronic currency data record corresponds to the currency amount to be sent; or – Send stored and received electronic currency data records, the total currency amount of the stored and received electronic currency data records corresponds to the currency amount to be sent, wherein the received electronic currency data records are pre-switched.

10. The apparatus of claim 1, wherein, The computing unit is further configured to: - Detect surplus from a threshold of the amount of currency received and the amount of currency recorded in the stored electronic currency data. – By segmenting the stored electronic currency data records to obtain a first electronic currency data record and a second electronic currency data record, and masking the first electronic currency data record and the second electronic currency data record to obtain a masked first electronic currency data record and a second electronic currency data record, the surplus is registered with the monitoring entity so that it is credited to the bank account.

11. The device of claim 1, further comprising a banknote module configured for inputting and / or outputting banknotes.

12. The apparatus of claim 11, wherein, The device is a registration terminal and / or an automated machine, and is configured to output a portion of the monetary amount as banknotes through the banknote module, and to output a portion of the monetary amount as electronic currency data records through the interface.

13. The apparatus of claim 12, wherein, The portion of the currency amount that is output as the electronic currency data record is the first electronic part of the segmented electronic currency data record.

14. The apparatus of claim 11, wherein, The device is a registration terminal and / or an automaton, and is configured to output a monetary amount in the form of banknotes via a banknote module, wherein the device receives a portion of the monetary amount in the form of an electronic currency data record from another device for this purpose.

15. The device according to claim 1, further comprising at least one of the following: – A security element reading device, configured to read security elements; and / or - Random number generator; and / or – An interface to the bank, authorized to access bank accounts.

16. The device according to claim 1, wherein, The data storage device is a shared data storage device accessible by at least one other device, wherein each of the device and the at least one other device has an application configured to: – Communicate with the monitoring entity to register electronic partial currency data records accordingly, the electronic partial currency data records being segmented electronic currency data records.

17. A method for use with the device according to any one of claims 1 to 16, the method comprising at least the steps of accessing, masking, and outputting; wherein The access steps include accessing a security module, wherein the security module is configured to securely store at least one electronic currency data record.

18. A payment system for exchanging monetary amounts, the payment system comprising: –The monitoring layer includes a database, which is a decentralized database that stores concealed electronic currency data records. as well as – Direct transaction layer, including the device according to any one of claims 1 to 16 and another device.

19. The payment system of claim 18, wherein, The device is a registration terminal and / or automaton according to any one of claims 12 to 14, and the other device is a user terminal, which is a device according to any one of claims 1 to 10, 15 or 16.

20. The payment system of claim 18, further comprising an issuer entity configured to: - generating an electronic coin data record, wherein, The issuer entity provides a signature for the masked generated electronic currency data record and transmits the masked generated electronic currency data record and the signature to the monitoring entity; and / or – Outputting or retrieving generated electronic currency data records to or from the device includes debiting or crediting the currency amount of the output or retrieved electronic currency data records from or to the device's bank account.

Images