WO2022233454A1 - Procédé d'enregistrement d'un ensemble de données de pièces électroniques dans un registre de pièces ; registre de pièces ; unité d'abonné et produit de programme d'ordinateur - Google Patents

Procédé d'enregistrement d'un ensemble de données de pièces électroniques dans un registre de pièces ; registre de pièces ; unité d'abonné et produit de programme d'ordinateur Download PDF

Info

Publication number
WO2022233454A1
WO2022233454A1 PCT/EP2022/025198 EP2022025198W WO2022233454A1 WO 2022233454 A1 WO2022233454 A1 WO 2022233454A1 EP 2022025198 W EP2022025198 W EP 2022025198W WO 2022233454 A1 WO2022233454 A1 WO 2022233454A1
Authority
WO
WIPO (PCT)
Prior art keywords
coin
register
subscriber unit
electronic coin
data set
Prior art date
Application number
PCT/EP2022/025198
Other languages
German (de)
English (en)
Other versions
WO2022233454A8 (fr
Inventor
Matthias Fasching
Original Assignee
Giesecke+Devrient Advance52 Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to EP22725994.2A priority Critical patent/EP4334872A1/fr
Application filed by Giesecke+Devrient Advance52 Gmbh filed Critical Giesecke+Devrient Advance52 Gmbh
Publication of WO2022233454A1 publication Critical patent/WO2022233454A1/fr
Publication of WO2022233454A8 publication Critical patent/WO2022233454A8/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3678—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes e-cash details, e.g. blinded, divisible or detecting double spending
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/383—Anonymous user system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/008—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving homomorphic encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • the invention relates to a method for registering an electronic coin data set in a coin register of an electronic payment system. Registering the electronic coin record is preferably part of an atomic exchange process. In this case, an exchange request is sent in order to see an electronic coin data record of the payment system, in particular a CBDC-based payment system, against a data record from a system other than the payment system.
  • the invention also relates to a coin register, a subscriber unit and a computer program product.
  • Security of payment transactions and the associated payment transaction data means protecting the confidentiality of the data exchanged; as well as protection of the integrity of the exchanged data; as well as protection of the availability of the exchanged data.
  • An electronic asset system is described in US Pat. No. 5,872,844 A.
  • Electronic assets are issued in the system by an institution.
  • the electronic assets are transferred from a payer's wallet to a payee's wallet.
  • the payee's wallet routinely submits the transferred assets for possible scrutiny.
  • a fraud detection system takes samples from those submitted for review assets to uncover “bad” assets that have been used in a fraudulent manner. Upon such detection, the fraud detection system will identify the electronic wallet that used the bad asset and flag it as a "bad wallet”.
  • the fraud detection system compiles a list of such bad e-wallets and distributes the list to warn other wallets about the bad e-wallets. If a bad wallet subsequently attempts to spend assets (whether fraudulently or not), the intended recipient will check the list of bad wallets and refuse to do business with the bad wallet.
  • the issued assets must contain a signature chain, which means that the storage requirement of the asset per payment transaction increases, ie the electronic coin data record grows. Wallets that are not trusted will not be allowed on the system at all.
  • An exemplary payment system is in the patent applications WO 2020/212337 A1 and WO 2020/212331 A1. Reference is made here to the configurations described therein, in particular the modification (switching, connecting, splitting) of electronic coin data sets, the masking of electronic coin data sets, the registration of the masked electronic coin data sets, and the checking of their validity.
  • An exchange with non-access-based data records such as value-based data records, for example the electronic coin data records of a digital central bank currency (CBDC - Central Bank Digital Currency), is initially not possible, among other things because corresponding random value checks for verification and unlocking of the HTLCs are not in can be mapped to these value-based data sets.
  • CBDC digital central bank currency
  • direct and anonymous payment should be created between the participants in the payment system.
  • the exchanged electronic coin records should be confidential to other system participants, but allow each system participant to perform basic checks on the electronic coin record, namely (1) detecting multiple dispensing attempts; (2) recognizing attempts to pay with non-existent monetary amounts; and (3) recognizing return criteria for already dispensed coin records, for example that an electronic coin record should expire.
  • the object is achieved with a method for registering an electronic coin data set in a coin register of an electronic payment system.
  • the procedure comprises the following procedural steps:
  • the generated electronic coin record by applying a one-way function, e.g. homomorphic, to at least one data element of the electronic coin record to obtain a masked generated electronic coin record.
  • a one-way function e.g. homomorphic
  • the coin register receives a time-secured masked electronic coin that can be switched (only) within the time period. If there is no switchover within this time, the original state is restored, i.e. the switchover to the second subscriber unit fails. This original state can take place automatically after the time has elapsed - as will be described below - or it can be forced by the first subscriber unit by means of a switchover modification.
  • the basic principle of switching as a modification of an electronic coin data set has already been adequately described in patent applications WO 2020/212337 A1 and WO 2020/212331 A1 and reference is made thereto.
  • the obfuscation value may be an obfuscation amount, where the one-way function is applied at least to the monetary amount, preferably to the monetary amount and the obfuscation amount.
  • the result of applying the one-way function preferably forms the masked electronic coin record.
  • the one-way function is applied in particular to the two data elements mentioned (or all) of the electronic coin data set.
  • a masked spoof value may be generated from the spoof value in the masking step, wherein the masked electronic coin record includes the monetary amount and the masked spoof value as data elements.
  • Atomic barter transactions require two subscriber units to acknowledge receipt of records within a specified time frame. If either subscriber unit does not acknowledge the transaction within the time period, the entire transaction is voided and no records are exchanged. This prevents a scenario in which a subscriber unit receives a data record but then wants to renegotiate to send its own data record and may have both data records.
  • atomic refers to the fact that this exchange either takes place completely or does not take place at all. If one of the subscriber units gives up or does not (in a timely manner) do what is required of it according to the computer protocol, the exchange transaction fails and the records are automatically returned to their previous owners (subscriber units), an original state is restored, i.e. a state as the barter would never have started.
  • a period of time is a period of time between the sending of the registration request and the desired end of the possibility for the other subscriber unit to take possession of the record. Starting from the transmission time, the end of the period of time is in the future and is preferably a few days, for example 3 days.
  • the registration method described here may be part of an atomic exchange method. It provides the core, namely the registration process required for an "atomic swap" with the coin register of a payment system intended for the exchange of value-based coin data sets (such as CBDC coin data sets).
  • a time lock also referred to as a "time lock” or “time lock” or “time blockade”, is preferably a cryptographic primitive. This time-out defines a period of time during which the first subscriber unit cannot have the electronic coin record registered to it and/or a period of time within which the second subscriber unit can have the electronic coin record registered to it. Accordingly, this time lock is a function that ensures that electronic coin data sets can only change their owner within a predetermined period of time, ie can be switched over (coined).
  • time locks can be part of Hash Timelock Contracts, HTLC. They can also be used to block registration of the generated electronic coin record for the period defined with the time period. This time assurance represented a clear intention on the part of the first subscriber unit to transmit the generated electronic coin data set to a second subscriber unit.
  • the registration request may be a swap request (SWAP command) to exchange the generated electronic coin record from the first subscriber unit for a record from a system other than the payment system from the second subscriber unit.
  • Another system is, for example, another system for exchanging data records (value-based or access-based), it is preferably an access-based system in which, for example, cryptocurrencies or smart contracts are exchanged as part of blockchain transactions.
  • the data record of this system is preferably a blockchain-based data record, ie an access-based data record.
  • These data sets are characterized by the fact that they do not contain any monetary data (such as amounts, etc.), but only provide access data in order to be able to access this monetary data - for example a blockchain or a network data storage device.
  • the other system is also a system for the exchange of value-based records or a system for the exchange of access-based records. It is crucial that the data record is transmitted as a system in an architecture or platform that is different from the existing payment system.
  • Exchange means a mutual transfer of values, such as monetary amounts or items to be negotiated (for smart contracts).
  • the first subscriber unit can transmit the generated electronic coin record directly to the second subscriber unit when the first subscriber unit has received a registration confirmation from the coin register.
  • the coin register of the first subscriber unit indicates that a Verification of the registration request was successful, in particular that the electronic coin data record is time-secured in the coin register.
  • the coin register Before sending the registration confirmation to the first subscriber unit, the coin register may preferably verify that the masked generated electronic coin record is not yet registered in the coin register and that the coin register securely registers the masked generated coin record, with the time protection being automatically canceled when the period of time has expired .
  • the coin register can still check value range proofs to ensure that no new money has been generated.
  • the coin register can verify that the end of the period is in the future.
  • the coin register can verify that the coin data set received, on the basis of which the generated coin data set was generated, is valid and is registered in the coin register—ideally on the first subscriber unit.
  • a delayed switching request is preferably transmitted from the first subscriber unit to the coin register, on the basis of which the coin register automatically switches the masked generated coin data set to the first subscriber unit when the coin register determines that the time period has expired. This means that no further steps are required by the first subscriber unit in order to restore the original state if the exchange method fails.
  • the registration request is reinterpreted as a delayed toggle request in the coin register when the coin register determines that the time period has expired, whereupon the coin register automatically toggles (back) the masked generated coin record to the first subscriber unit.
  • the determination of the end of the time period in the coin register can be implemented using electronic counters or timers.
  • the delayed switching request reduces the system complexity, since the generation and registration of a further masked coin data record can be dispensed with.
  • the first subscriber unit Before sending the registration request, the first subscriber unit preferably receives a scatter value from a data record of the other system.
  • the scatter value from the data set of the other system is preferred.
  • the masked generated electronic coin data record is secured by the first subscriber unit (now also) with the scatter value, so that the coin register registers the masked generated coin data record with scatter value secured.
  • the hashlock prevents the record from being redeemed by the first subscriber unit unless the original image record is revealed.
  • the hash lock prevents the generated electronic coin data record from being switched over to the second subscriber unit if the second subscriber unit does not have the original image data record or if the latter does not disclose the original image data record.
  • Hash Timelock Contract HTLC
  • An HTLC is a piece of computer protocol and is based on two key functions: a "hashlock” and a "timelock”. Consequently, the use of HTLCs obviates the need for trust since they define a specific set of rules that prevent partial atomic swaps from being executed.
  • the first subscriber unit Before sending the registration request, the first subscriber unit preferably receives a period of time from the data record of the other system, the period of time from the data record specifying a period of time up to which the first subscriber unit can redeem the data record from the system other than the payment system.
  • the second subscriber unit has thus secured the data record of the other system in terms of time and when this period of time has elapsed, the second subscriber unit can redeem this data record for itself again.
  • the first subscriber unit preferably selects the time period for the registration request in such a way that it expires before the time period from the data record expires, with the time period for the registration request preferably being approximately half the time period between receipt of the time period from the data record and the expiry of the time period from the data record is. This presupposes that the period of time from the data set is also in the future, ie has not yet expired at the time of receipt by the first subscriber unit. This is useful if the validity of the electronic coin data set is to be checked first before the data set can be received at the first subscriber unit.
  • the second subscriber unit preferably receives the generated electronic coin data record directly from the first subscriber unit, the second subscriber unit checking whether the masked generated electronic coin data record is secured in the coin register with the spread value spread value. After receiving, the second subscriber unit preferably checks whether the monetary amount in the received generated electronic coin data record corresponds to the negotiated conditions.
  • the method preferably comprises the further steps: generating, by the second subscriber unit, an electronic coin data record comprising the monetary amount and an obfuscation amount, wherein the monetary amount of the generated electronic coin data record corresponds to the monetary amount of the electronic coin data record received from the first subscriber unit; masking, by the second subscriber unit, the generated electronic coin record by applying the homomorphic one-way function to the electronic coin record to obtain the masked generated electronic coin record; The second subscriber unit sends a switch request (here also "redeem" command) for the masked generated electronic coin data set to the coin register together with a primordial image data set, where the primordial image data set also forms the basis for the spread value in the data set other than the payment system, the sending being done within the time period of the time security.
  • a switch request here also "redeem" command
  • the archetype record is a secret of the second subscriber unit to which a hash function is applied to obtain the above hash value for saving the other system's record.
  • the secret must be communicated to the first subscriber unit in the course of the atomic exchange procedure. If the second subscriber unit finds the electronic coin record received from the first subscriber unit to be correct and now wants to switch it over to itself (which can be done by creating a new coin record, masking and registering), it must in turn publish the archetype record in order to do so the first subscriber unit can redeem the record on itself.
  • the coin register preferably registers the masked generated electronic coin data record of the second subscriber unit on the second subscriber unit if a scatter value via the original image data record matches the masked electronic coin data record of the coin register secured with the scatter value and if the duration of the time protection of the masked electronic coin data record generated is still valid has not expired.
  • the masked generated electronic coin data set becomes the first Participant unit invalid. The transmission of the electronic coin data record from the first subscriber unit to the second subscriber unit is thus successfully completed.
  • the first subscriber unit can now also redeem the data set for itself, it queries the original image data set (which is published and stored in the coin register so that it can be called up) from the coin register. With the archetype record, the first subscriber unit can redeem the record from the other system on itself.
  • the sending of the registration request can include a plurality of masked generated electronic coin data records from the first subscriber unit, with the same time security, preferably also the same spread value from a data record from a system other than the payment system, being used for each of the masked generated electronic coin data records.
  • the coin register registers each masked electronic coin record as a register record.
  • the following steps are preferably performed: receiving the electronic coin record from an issuer entity and/or another subscriber unit; and retrieving a register record from the coin register for the received electronic coin record.
  • the first subscriber unit thus ensures that the coin data record to be transmitted is present and valid.
  • the method according to the previous type is carried out only when a register data set for this electronic coin data set is available. Thus, it becomes a system requirement that the register data set must be present for an atomic exchange.
  • the length of time in the registration request is preferably only a few days, preferably 3 days, with the length of time in the data record preferably being 7 days. These are assumed to be sufficient periods of time to be able to perform the atomic replacement procedure.
  • the spread value can be calculated using a spread value function in the second subscriber unit, with a secret original image data record being generated in the second subscriber unit as the basis.
  • various functions can be used as the scatter value function.
  • a spread value function is preferably chosen which is already available in both systems (access-based/non-access-based).
  • Scattered value functions of the SHA2 type, in particular SHA256 can in principle also be used with other widespread scatter value functions such as SHA3, RIPEMD-160, MD5 or Haval.
  • the object is achieved by a coin register for registering register data records, in particular masked electronic coin data records, in an electronic payment system.
  • the coin register includes a data interface set up to receive registration requests and to send register statuses regarding register data records of the payment system according to the type described above.
  • the coin register is preferably set up to receive a prototype data record from a subscriber unit; applying a hash function to the archetype data set to generate a hash value; comparing the generated hash value to a previously received hash value; and registering a register data set secured by means of the scatter value in the coin register.
  • the coin register preferably also has a checking unit for checking the validity of the electronic coin data sets corresponding to the register data sets.
  • a payment system for paying with electronic coin data sets comprises a coin register set up to register the generated electronic coin data sets according to the type described above and subscriber units set up to carry out payment transactions by transmitting the electronic coin data sets and for sending status and/or registration requests relating to the electronic coin data sets according to the above described and executing transactions by transferring data records in a system other than the payment system according to one of the preceding method claims.
  • the coin register of the payment system is preferably set up to register the electronic coin data record as part of an atomic exchange process, with a registration request being an exchange request to exchange the generated electronic coin data record from the first subscriber unit against a data record from a system other than the payment system from the second Exchange subscriber unit.
  • a subscriber unit is provided.
  • This subscriber unit is set up to transmit electronic coin data records directly to another subscriber unit in an electronic payment system and set up to carry out payment transactions by transmitting electronic coin data records and for sending status and/or registration requests regarding the electronic coin data records to a coin register.
  • the subscriber unit has a means for accessing a data memory, with at least one electronic coin data set being stored in the data memory; an interface for outputting the at least one electronic coin data set to the other subscriber unit for transmitting status and/or register requests relating to the electronic coin data sets to the coin register and a processing unit set up to carry out the method steps of the method described above.
  • a computer program product is executably installed on a subscriber unit and has means for performing the method steps of the method.
  • the electronic coin record is typically issued by a central bank.
  • the electronic coin record may be referred to as a central bank digital currency (CBDC) electronic coin record.
  • CBDC central bank digital currency
  • this monetary amount can change from a first terminal to another terminal.
  • a monetary amount (asset) is understood to mean a digital amount that can be credited to an account at a financial institution, for example, or exchanged for another means of payment.
  • An electronic coin record thus represents cash in electronic form.
  • An electronic coin data record for transferring monetary amounts differs significantly from the electronic data record for data exchange or data transfer, for example a register data record, since a classic data transaction is based on a Question-answer principle or on an intercommunication between the data transfer partners, for example the subscriber unit and a coin register (sometimes referred to here as a monitoring authority, monitoring register, transaction register, verifier).
  • a coin register sometimes referred to here as a monitoring authority, monitoring register, transaction register, verifier.
  • identification or identification data can be exchanged, which can provide conclusions about a subscriber ID and/or an identification number of a natural person as a user (participant) of the payment system. This means that anonymous payment is not possible.
  • An electronic coin data set is anonymous, unique, unambiguous and is part of a security concept.
  • an electronic coin data record contains all data elements that are required for a receiving entity in order to receive the amount of money to be transmitted.
  • a valid electronic coin data record should only exist once in the payment system. This system requirement must be observed in particular when transferring electronic coin data records.
  • An electronic coin data set can be present in a large number of different forms and can thus be exchanged via different communication channels, communication protocols, communication layers, summarized below as interfaces. This creates a very flexible exchange of electronic coin data sets.
  • the electronic coin data set can be presented in the form of a file, for example.
  • a file consists of data that is related in terms of content and is stored on a data carrier, data storage device or storage medium. Each file is initially a one-dimensional sequence of bits, which are usually interpreted in groups of bytes. An application program or an operating system of a security element and/or a subscriber unit interprets this bit or byte sequence as text, an image or a sound recording, for example.
  • the file format used can be different, for example it can be a pure text file that represents the electronic coin data record. In particular, the monetary amount and a blind signature are displayed as a file.
  • the electronic coin data record is, for example, a sequence of American Standard Code for Information Interchange, or ASCII for short, characters.
  • ASCII American Standard Code for Information Interchange
  • the monetary amount and a blind signature are shown as this sequence.
  • the electronic coin record can also be converted from one representation form to another representation form in a subscriber unit.
  • the electronic coin data record can be recorded as a QR code in a subscriber unit and output as a file or character string by the subscriber unit.
  • the electronic coin data record has a monetary amount as a data element, ie a date that represents a monetary value of the electronic coin data record, and an obfuscation amount, for example a random number, as a data element.
  • the amount of concealment is not known to the coin register.
  • the obfuscation amount is - except in the first layer (direct transaction layer) - a secret data element.
  • An electronic coin data set is uniquely represented by these at least two data elements (monetary amount, concealment amount).
  • Teen who has access to these data elements of an electronic coin record can use this electronic coin record to pay in a payment transaction. Knowledge of these two data elements (monetary amount, concealment amount) is therefore equivalent to possession of the digital money.
  • the electronic coin data record can have further data elements, in particular which currency the monetary amount represents or by which issuing authority it was generated.
  • the electronic coin data record can include a signature of an issuer entity, in particular in order to increase security (although with reduced flexibility).
  • a subscriber unit of the payment system can be, for example, a mobile terminal such as a smartphone, a tablet computer, a computer, a server or a machine.
  • the subscriber unit can also be a device such as a wearable, smart card, machine, tool, vending machine or even a container or vehicle.
  • a subscriber unit is therefore either stationary or mobile.
  • the subscriber unit is preferably designed to use the Internet and/or other public or private networks in order to transmit electronic coin data records and/or register data records or queries relating thereto.
  • the subscriber unit uses a suitable connection technology, for example Bluetooth, LoRa, NFC and/or WiFi, and has at least one corresponding interface.
  • the subscriber unit can also be designed to be connected to the Internet and/or other networks by means of access to a mobile radio network.
  • An application brought ready for operation (installed) on the subscriber unit can initiate and control a transmission of a coin data set to another subscriber unit by using input and/or output means of the respective subscriber unit. For example, amounts of electronic coin data records can be displayed and the transmission process can be monitored using the application.
  • This or another ready-to-operate application can initiate and control the transmission of a register data record to a coin register of the payment system by using input and/or output means of the respective subscriber unit.
  • the checking of electronic coin data sets can be initiated by means of the application, for example by generating register data sets and/or sending checking requests to the coin register.
  • the subscriber unit has an interface for issuing electronic coin data records.
  • a communication protocol for wireless communication for wireless communication.
  • near-field communication is provided, for example by means of a Bluetooth protocol or NFC protocol or IR protocol; WLAN connections or mobile radio connections are conceivable as an alternative or in addition.
  • the electronic coin data set is then adapted according to the protocol properties or integrated into the protocol and transmitted.
  • An interface for outputting the at least one electronic coin data record is, for example, a data interface for providing the electronic coin data record to the other subscriber unit using an application.
  • the electronic coin data set is transmitted here using an application.
  • This application then transfers the electronic coin data record in an appropriate file format.
  • a specific file format for electronic coin data records can then be used, for example an ASCII character string or a text message, E.g. SMS, MMS, instant messenger message, an APDU string.
  • the transmission takes place via the previously mentioned application of the subscriber unit and/or the security element.
  • the subscriber unit also has an interface for receiving electronic coin data sets.
  • the interface for receiving the at least one electronic coin data record is an electronic detection module of the security element or terminal device, set up to detect an electronic coin data record presented in visual form.
  • the detection module is then, for example, a camera or a barcode or QR code scanner.
  • the interface for receiving the at least one electronic coin data record is a protocol interface for wirelessly receiving the electronic coin data record from another security element or end device using a communication protocol for wireless communication.
  • a communication protocol for wireless communication In particular, this involves near-field communication, for example using the Bluetooth protocol or NFC protocol or IR protocol.
  • WLAN connections or mobile radio connections are conceivable.
  • the subscriber unit comprises at least one security element reader, set up to read a security element; a random number generator; and/or a communication interface to a vault module and/or bank institution with access to a bank account to be authorized.
  • a subscriber unit of the payment system can have a security element or itself be a security element in that at least one electronic coin data record is securely stored.
  • Electronic coin data records can be transmitted with the aid of terminal devices as subscriber units, which may be logically and/or physically connected to the security elements.
  • the application(s) installed ready for operation on the subscriber unit can control or at least initiate at least parts of the transmission method and/or parts of the registration method and/or parts of the checking method.
  • a security element is installed ready for operation in a subscriber unit. This ensures that electronic coin data sets are transmitted and/or register data sets are generated and encrypted without manipulation and, if necessary, also be sent.
  • the register data set is created in the security element and then sent to the coin register by the subscriber unit.
  • a security element is a technical resource-limited facility.
  • a security element is, for example, a special computer program product, in particular in the form of a secure runtime environment within an operating system of a terminal, English Trusted Execution Environments, TEE, or eSIM software, stored on a data memory, for example a subscriber unit, such as (mobile) terminal, a machine or an ATM.
  • the security element is designed, for example, as special hardware, in particular in the form of a secure hardware platform module, English Trusted Platform Module, TPM or as a chip card, UICC or an embedded security module, eUICC, iUICC, eSIM.
  • the security element provides a trustworthy environment and thus has a higher level of trust than a terminal device in which the security element is possibly integrated ready for operation.
  • an electronic coin data record can preferably not be generated by a subscriber unit or a security element or the coin register.
  • the generation of an electronic coin data record (and also its destruction or deletion) is carried out by the issuer of the payment system, preferably exclusively by the issuer of the payment system.
  • One or more electronic coin data records can be stored securely in a subscriber unit or a security element, for example a large number of electronic coin data records can be stored securely in a data memory exclusively assigned to a subscriber unit or a security element.
  • the data memory then represents an electronic purse application, for example.
  • This data memory can, for example, be internal, external or virtual to the security element.
  • the data store is an internal data store of the subscriber unit or the security element.
  • the electronic coin data sets are stored here. This ensures easy access to electronic coin data sets.
  • the data memory is, for example, a data memory that is physically remote from the subscriber unit or the security element, ie external, also called online memory.
  • the security element or the subscriber unit has only one means of access to the electronic coin data records that are stored externally and thus securely.
  • the security element or subscriber unit is lost or if the security element or subscriber unit malfunctions, the electronic coin data records are not lost. Because possession of the (unmasked) electronic coin records equals possession corresponds to the monetary amount, money can be stored and managed more securely by using external data storage.
  • the data memory is a shared data memory that at least one other subscriber unit can access, each of which has an application, with this application being set up to communicate with the coin register for corresponding registration of electronic coin part data records.
  • the security element could also have received electronic coin data records from less trustworthy units, such as subscriber units, ie a terminal or a machine, for example via an import/export function of the security element. Electronic coin records obtained in this way that are not obtained directly from another security element are considered less trustworthy. It could be a requirement of the payment system to have to check the validity of such electronic coin data records using the coin register or, through an action (modification) by the receiving security element, to transfer the electronic coin data record to the receiving security element before it can be passed on.
  • less trustworthy units such as subscriber units, ie a terminal or a machine
  • the communication between two subscriber units and/or the coin register, if necessary by means of the respective security elements, can be wireless or wired, or e.g. also optical, preferably via QR code or barcode, and can be used as a secure channel, e.g. between applications of the Subscriber units be trained.
  • the optical path can include, for example, the steps of generating an optical code, in particular a 2D code, preferably a QR code, and reading in the optical code.
  • the electronic coin data sets can be transmitted in any format. This implies that it communicates, i.e. can be transmitted, on any channel. They do not have to be saved in a fixed format or in a specific program.
  • two subscriber units set up a local wireless communication connection via the protocol of which the transmission between the two security elements located therein is then introduced.
  • the transmission of the electronic coin data record is secured, for example, by cryptographic keys, for example a session key negotiated for an electronic coin data record exchange or a symmetric or asymmetric key pair.
  • cryptographic keys for example a session key negotiated for an electronic coin data record exchange or a symmetric or asymmetric key pair.
  • the coin data records are transmitted as APDU commands.
  • the coin data record is preferably stored in an (embedded or integrated) UICC as a security element and is managed there.
  • An APDU is a combined command/data block of a connection protocol between the UICC and a terminal.
  • the structure of the APDU is defined by the ISO-7816-4 standard.
  • APDUs represent an information element of the application layer (layer 7 of the OSI layer model).
  • Transmission of an electronic coin record is preferably between two security elements to create a trusted environment.
  • the logical transmission of the electronic coin data record is direct, whereas a physical transmission may involve one or more intermediary entities, for example one or more subscriber units for preparing the operational readiness of the security element(s) and/or a remote data storage service in which a wallet application with electronic Coin records are physically stored.
  • Security elements can transfer electronic coin data sets among one another and then continue to use them directly - without register check(s), especially if the payment system requires that electronic coin data sets of security elements are to be regarded as valid per se.
  • Transmission of the electronic coin data set between the first and the second security element can be integrated in a transmission protocol between two subscriber units and/or integrated in a secure channel between two applications of the respective subscriber unit.
  • the transmission can include an Internet data connection to an external data store, for example an online store.
  • the electronic coin data records are managed by the respective subscriber units, for example by security elements integrated there, and also transmitted by them.
  • the security element is introduced into the subscriber unit ready for operation.
  • the electronic coin data record is transmitted from the security element of a first subscriber unit to the (second) security element of another subscriber unit, for example.
  • a subscriber unit-to-subscriber unit transmission link can be set up, via which, for example, a secure channel is set up between the two security elements, via which the electronic coin data record is then transmitted.
  • the electronic coin data record (to be transferred or modified) is registered in a coin register of the payment system.
  • a coin register of the payment system For example, the establishment of a communication link to the coin register is provided for registering the electronic coin data set. This communication connection does not necessarily have to be present during the transmission process (payment process).
  • the coin register is preferably provided for the administration and checking of masked electronic coin data sets. The coin register can also manage and check other (non-payment) transactions between subscriber units.
  • the coin register is, for example, a database in which a register data record is generated and/or stored.
  • a register record is a record that allows the validity, status, history and/or whereabouts of an electronic coin record to be known and/or verified.
  • a register data record is preferably uniquely assigned to an electronic coin data record. The register record is for verification only and cannot be used to replace the electronic coin record for payment transactions.
  • the coin register can be a decentralized public database.
  • This database makes it easy to check electronic coin data records for their validity and to prevent "double spending", i.e. multiple issues, without the transmission itself being registered or logged.
  • the database for example a distributed ledger technology, DLT, describes a technique for networked computers that come to an agreement about the sequence of certain transactions and that these transactions update data. It corresponds to a decentralized management system or a decentralized database.
  • the coin register is a centrally managed database, for example in the form of a publicly accessible data store or as a hybrid of a central and decentralized database.
  • the coin register and a separate monitoring register are designed as a service server of the payment system.
  • the coin register is a remote entity
  • the subscriber unit and also the issuer entity preferably have an interface for communication using a standard internet communication protocol, for example TCP, IP, UDP or HTTP.
  • the transmission may include communication over the cellular network.
  • the coin register provides a register data record.
  • the register data set has, for example, a masked electronic coin data set corresponding to an electronic coin data set as a data element.
  • the masked electronic coin record was provided by a subscriber unit or an issuing entity. Possession of a masked electronic coin data record does not permit disclosure of data elements of the (corresponding) electronic coin data record, whereby such a register data record with (only) masked coin data records is anonymous with regard to a subscriber identification and/or also anonymous with regard to a monetary amount of the electronic coin data record. The masking will be explained later.
  • a register data set has one or more of the following data elements: a signature of the electronic coin data set; an area evidencing of an electronic coin record; a check value of the electronic coin record; a check value related to the electronic coin record; a counter value relating to the electronic coin record; a subscriber identifier of a subscriber unit sending the register data record; a masked electronic coin record; and/or a monetary amount of the electronic coin record. All of these data elements and their function are defined in the appropriate places.
  • the register data record has, for example, as data elements, a masked electronic coin data record and an amount category relating to a monetary amount of the electronic coin data record corresponding to the masked electronic coin data record.
  • a register data record with a masked coin data record is anonymous in terms of identity and pseudonymous in terms of amount.
  • the register data record has, for example, as data elements, a coin identifier of an electronic coin data record, a check value of the electronic coin data record and a pseudonym of the subscriber identifier.
  • a register data record is pseudonymous in identity and anonymous in terms of amount.
  • masked electronic coin records are provided as a data element in the register record or as the register record. These masked electronic coin data sets are registered with their corresponding processing in the coin register. That Masking is described in the applications WO 2020/212337 A1 and WO 2020/212331 A1 and reference is made thereto. In a preferred embodiment, a validity status of the (masked) electronic coin data record can be derived from this. The validity of the (masked) electronic coin data records is preferably noted (registered) in the coin register. In addition, modifications such as switching, dividing or combining are registered for the individual electronic coin data sets in the coin register. The creation, testing and registration of these modifications is described in the applications WO 2020/212337 A1 and WO 2020/212331 A1 and reference is made to them in this regard.
  • the step of registering a register data set is described in the applications WO 2020/212337 A1 and WO 2020/212331 A1 and reference is made thereto.
  • a registration of the processing or the processing steps for a respective modification in the coin register can also relate to the registration of test results and intermediate test results relating to the validity of an electronic coin data record in the coin register, in particular the determination of test values and counter values of corresponding electronic coin data records total mark displayed in the coin register
  • Final processing decides whether an electronic coin record is valid or invalid
  • the registering step is preferably performed w when the subscriber unit and/or the security element is connected to the coin register.
  • the at least one initial electronic coin data record is preferably created by the issuing entity, it being possible for the divided electronic coin data records, in particular electronic partial coin data records, to also be generated by a subscriber unit.
  • Creating and choosing a monetary amount preferably also includes choosing a high entropy obfuscation amount.
  • the issuer instance is therefore also referred to as a privileged instance or privileged node, since only this can create new money in the form of electronic coin data records and can destroy money by deactivating electronic coin data records.
  • the issuing authority can therefore create and destroy monetary amounts for the payment system, and correspondingly control the total monetary amount circulating in the payment system.
  • the publishing entity is a computing system, which is preferably remote from the first and/or second subscriber unit.
  • the new electronic coin record is masked in the issuer instance by applying the homomorphic one-way function to the new electronic coin record to correspondingly obtain a masked new electronic coin record.
  • additional information needed to register the creation of the masked new electronic coin record in the remote coin register is computed in the issuer entity.
  • This additional information is preferably proof that the (masked) new electronic coin data record originates from the issuing authority, for example by signing the masked new electronic coin data record.
  • the issuing entity signs a masked electronic coin data record with its signature when the electronic coin data record is generated.
  • the signature of the issuing authority is stored in the coin register.
  • the signature of the issuing authority is different from the signature generated by a subscriber unit or a security element.
  • the issuing entity is preferably a computer entity of a central bank.
  • the coin register and the issuer entity are preferably arranged in a common server entity or are present as a computer program product on a server and/or a computer.
  • the publishing instance is preferably accessed via an http protocol.
  • the process is not limited to one currency.
  • the payment system can be set up to manage different currencies from different publishers.
  • the method also enables the electronic coin data record to be converted into book money, ie for example the monetary amount can be redeemed in an account of the participant in the payment system.
  • This repositioning is also a modification.
  • the electronic coin record becomes invalid and is deemed to have been returned.
  • a “Freeze” modification to an electronic coin data set can be provided in order to cause the electronic coin data set to be temporarily deactivated, or better yet, the monetary value of the electronic coin data set.
  • the electronic coin data record is set in a deactivated state without being destroyed, the electronic coin data record is quasi “frozen”. This "Freeze” modification or action differs from the "Deactivate” modification or action of an electronic coin record.
  • This "Freeze” modification cannot be carried out by a subscriber unit, i.e. not by the owner of the electronic coin data set.
  • This "Freeze” modification can only be initiated and carried out by a privileged authority, for example an issuing authority or a monitoring authority (not the coin register).
  • This privileged authority can be, for example, an authorized authority, for example a criminal prosecution authority, or a combination of several trustworthy authorities. In this way, a sum of money's worth can be confiscated from a suspect without the money being immediately destroyed.
  • a modification or action complementary to the “Freeze” modification or action is the “Unfreeze”.
  • the coin data sets deactivated by a "Freeze” action are reactivated (i.e. reactivated).
  • This "Unfreeze" modification can only be initiated and carried out by a privileged authority, for example an issuing authority or a monitoring authority (not the coin register).
  • This privileged authority can be, for example, an authorized authority, for example a criminal prosecution authority, or a combination of several trustworthy authorities. In this way, a monetary amount of a suspect can be released again, for example after the suspect has been proven innocent.
  • the actions "Freeze” and “Unfreeze” for a respective electronic coin data set are registered in a coin register by entries for a corresponding masked electronic coin data set. These actions are assumed here to be known per se.
  • a "Freeze” action for example, for a corresponding masked electronic coin data record no successor coins are specified (or the entered ones are deleted), which means that the electronic coin data record is invalid for all validity checks.
  • new successor coins are specified for a corresponding masked electronic coin data set, which means that the electronic coin data set is valid again during a validity check.
  • FIG. 1 shows an embodiment of a payment system according to the invention
  • FIG. 2 shows a further development of the exemplary embodiment of a payment system from FIG. 1;
  • FIG. 3 shows a further development of the exemplary embodiment of a payment system from FIG. 1;
  • FIG. 4 shows an exemplary embodiment of a method flow chart of a method in a publishing entity
  • FIG. 5 shows an exemplary embodiment of a data structure in the coin register
  • FIG. 7 shows an exemplary embodiment of a method flow chart of a method according to the invention and corresponding processing steps of a coin data record
  • FIG. 8 shows an exemplary embodiment of a method flow chart of a method according to the invention and corresponding processing steps of a coin data set
  • FIG. 9 shows an exemplary embodiment of a method flow chart of a method according to the invention and corresponding processing steps of a coin data set; 10 shows an exemplary embodiment of a method flow diagram of a method for registering a coin data set within an atomic exchange procedure; and
  • FIG. 11 shows an exemplary embodiment of a method flow chart of a method according to the invention and corresponding processing steps of a coin data set.
  • the payment system BZ includes at least two security elements, SE, SEI and SE2 for short.
  • SE, SEI and SE2 can be placed ready for operation in respective terminals M1 and M2 and logically or physically connected to the respective terminal M1 and M2.
  • M1 and M2 can also be subscriber units TE1, TE2.
  • the publishing entity 1 is, for example, a server entity of a central bank la.
  • a register data record RDS for example a masked electronic coin data record Z, is generated for the electronic coin data record C and registered 104 in a coin register 2 of the payment system BZ.
  • the register data record RDS for example the masked electronic coin data record Z, is in step 104, for example, by the issuing authority
  • the register data set RDS for example the masked electronic coin data set Z, is alternatively generated by the first terminal M1 (or second terminal M2) and sent to the coin register
  • a request 210 from a central bank or a subscriber unit TE or a commercial bank for the generation of an electronic coin data set is received by the issuing entity 1 .
  • the issuing entity 1 has, for example, a coin generation unit 11 and a coin dispensing unit 12.
  • the two units 11, 12 are separate from one another and have an air gap 14.
  • the air gap 14 serves to ensure that the highly sensitive, security-relevant data and units of the payment system BZ in the issuing authority 1, in particular a private key PK and a random number generator, cannot be read via a network attack on the issuing authority 1 and used to manipulate the payment system BZ.
  • the coin generation Unit 11 can be completely isolated.
  • the coin generation unit 11 has no interface to a network such as TCP/IP, the Internet, the mobile network, etc.
  • the air gap process 14 is not explained further here.
  • the data transmission from and to the publishing entity preferably takes place using an http protocol.
  • the electronic coin data record also abbreviated as eMDS below, C can be requested in advance from the issuer entity 1 and optionally received by a terminal M (or an SE) or the issuer entity 1 or another payment system.
  • the request 210 may have been generated by a central bank la.
  • a subscriber unit TE requests the electronic coin data record C.
  • Steps 104 and 105 may correspond to steps 104 and 105 of FIG.
  • An action or modification (dividing, connecting, switching, transmitting, deactivating, exchanging, alarming) on the eMDS C can correspond to one of the actions in FIGS. 7 to 11. These modifications are also described by way of example in patent applications WO 2020/212337 A1 and WO 2020/212331 A1.
  • a genuine random number is generated as the concealment value n , which is preferably a concealment amount.
  • the obfuscation value n is known in the direct transaction layer 3 and for newly issued eMDS also in the issuer instance 1, it is secret for the other instances of the payment system BZ, ie also for the coin register 2.
  • the concealment value n is, for example, a 32-byte positive random number. The generation takes place, for example, by means of a real random number generator.
  • ECDSA Elliptic Curve Digital Signature Algorithm
  • the concealment value n is linked to a monetary amount Di.
  • the monetary amount Di is, for example, an integer value, preferably of the 32-bit unsigned integer value data type.
  • the monetary amount Di for example, only has a limited value range of powers of two. A value of zero (“0”) as a monetary amount Di could be invalid.
  • An i-th electronic coin data set according to the invention which was generated by the coin generation unit 1, could therefore read:
  • Ci ⁇ ; nj (1)
  • a valid electronic coin record C can be used for payment.
  • the owner of the two values Di and n therefore owns the digital money.
  • the digital money is defined by a pair consisting of a valid electronic coin data set Ci and a corresponding register data set RDSi, for example a masked electronic coin data set Zi.
  • Zi preferably represents a point in an elliptic curve-based cryptographic method, for example an Elliptic Curve Digital Signature Algorithm , ECDSA for short, preferably of the secp256rl.
  • Zi may be encoded in an uncompressed form as specified in Standards for Efficient Cryptography, Elliptic Curve Cryptography; Section 2.3.3 is given as an example.
  • a masked electronic coin data set Zi is obtained as a register data set RDS by applying a homomorphic one-way function f(Ci) according to equation (2):
  • This function f(Ci) is public, i.e. every system participant can call up and use this function.
  • This function f(Ci) is defined according to equation (3):
  • H and G are generator points of a group G in which the discrete logarithm problem is hard, with generators G and H for which the discrete logarithm of the other base is unknown.
  • G and H are generator points of an elliptic curve encryption, ECC, - ie private keys of the ECC are.
  • n H n H (4) the link n must be practically untraceable in order to prevent the monetary amount Di from being manipulated and a valid Zi being able to be calculated nonetheless. For example is:
  • Equation (3) is a "Pederson commitment for ECC” that ensures that the monetary amount u can be granted to a coin register 2, i.e. "committed", without revealing it to the coin register 2.
  • the obfuscation value n is referred to as the obfuscation amount because it at least masks the monetary amount of the eMDS.
  • a register data record RDS also abbreviated to some extent below as RDS, is then equated with a masked coin data record Z.
  • step 104 register, registration request
  • the registration request comprising the register record.
  • the RDS can be provided by the issuing authority 1 for the coin register 2 .
  • the RDS is preferably generated in the coin generator 11, but can also be generated in the coin dispensing unit 12.
  • Equations (3) and (3-1) make it possible through the entropy of the amount of concealment n to obtain a cryptographically strong Zi even with a small value range for monetary amounts Ui. Thus, a simple brute force attack by merely estimating monetary amounts Ui is practically impossible.
  • Equation (3) is a one-way function, which means that computing Zi from Ci is easy because an efficient algorithm exists, whereas computing Ci from Zi is very difficult because there is no polynomial-time solvable algorithm.
  • equation (3) is homomorphic for addition and subtraction, which means that:
  • the coin data set Ci can be divided according to equation (1) into:
  • Equation (9) for example, a symmetrical or asymmetrical splitting as a modification or a "symmetrical or asymmetrical splitting" processing step 110 of a coin data set C according to FIG , Ck has.
  • the condition of equation (9) is checked to validate split coin data sets C j and C k and to invalidate coin data set Ci.
  • Such a splitting 110 of an electronic coin record Ci is shown in FIG.
  • Electronic coin data records C can also be combined (connected) 109 in the same way, see FIG. 7 and the explanations relating thereto.
  • a ring signature is preferably used for each bit
  • Cij aj H + bj G (9c)
  • Cij - aj - H (9d) it being possible in one embodiment to carry out a ring signature only for specific bits.
  • the embodiment of the payment system BZ shown in FIG. 1 shows in particular the generation of an electronic coin data record C for direct issue to a subscriber unit TE1 (step 102).
  • the issuance to the subscriber unit TE1 takes place indirectly via a bank entity 4 through steps 102' (providing the eMDS C to the bank 4) and in the subsequent step 102" (providing the eMDS C to the TE1).
  • the generation of the RDS by the publishing entity 1 is only optional here and can also be carried out by the subscriber units TE1, TE2.
  • FIG. 2 shows a further development of the payment system BZ shown in FIG. Reference is hereby made to the explanations of FIG. 1 in order to avoid repetition.
  • the deactivation of a coin data record C is described in FIG.
  • a participant unit TE1 decides to deactivate and return the coin data set C and sends a deactivation request in step 111.
  • This step 111 can be the mapping of a participant's request, namely to credit a monetary amount of a coin data set to an account of the participant, or can be based on an evaluation of a test value pi, in which it was determined that the coin data set meets the criteria for a return, e.g.
  • Step 111 is displayed directly to the coin dispensing unit 12 .
  • the display can also take place indirectly via the rank instance 4 (similar to obtaining the coin data record), which is illustrated in FIG. 2 by steps 111' and 111''.
  • the monetary amount is credited to an account of the participant or cash is issued at an output compartment of the unit 12 in the following step (not shown).
  • a deactivation command is sent to the coin register 2 in order to delete the register data set RDS from the coin register 2 or to switch it there to invalid.
  • the RDS of the deactivated (credited) coin data record is deleted from coin register 2 (RDS crossed out).
  • the coin issuing unit 12 of the issuer entity 1 of FIG. 1 has a receiving unit 15 (not shown in FIG. not shown) arrive.
  • the receiving unit 15 transmits the request 210 to the coin generation unit 11 by means of an air gap process 14'.
  • the same mechanisms as in the previously mentioned air gap process 14 can be applied and the same interfaces can be used.
  • the coin generation unit 11 generates the coin data set C and also the register data set RDS.
  • the coin generation unit 11 signs the generated register data record RDS with a private key PK of the issuing authority 1.
  • the combination of electronic coin data record C, register data record RDS and signed register data record [RDS]Sig(PK) is Expression Ai, represented for example as a QR code.
  • This expression Ai is provided to the coin dispensing unit 12 via the air gap process 14 .
  • the expression Ai is read in by means of a reading unit 16, for example a QR code scanner, in order to obtain the electronic coin data record C.
  • the coin generation unit 11 generates metadata MC, which is added to the expression Ai or made available to the coin dispensing unit 12 as an independent transmission.
  • the unit 16 checks the uniqueness of the coin data record Ci, for example by comparing the metadata MCi with metadata of the coin data records C existing in the payment system BZ. For example, a serial number or a coin identifier is used for this check. If the uniqueness of the coin data record Ci is confirmed, it is stored in the coin store 17 of the issuer entity 1 and (time-uncorrelated) is output to a subscriber unit TE in step 102 . Providing the RDS to the Coin register 2 can already take place after checking for uniqueness or only when a coin data set Ci is requested by a TE or the rank instance 4 .
  • the provision of the RDS in step 102 to the coin register 2 enables the coin data set Ci to be registered in the payment system BZ.
  • the RDS and the signed [RDS]Sig(PK) are provided.
  • the signature of the signed [RDS]Sig(PK) can be checked in the coin register 2 and if the check is successful, the RDS is registered as valid in the coin register 2.
  • the coin register 2 only receives the signed register data record [RDS]Sig(PK).
  • the signature can be checked in the coin register 2 with the public key of the issuing authority 1 and if the check was successful be registered as valid in coin register 2 by the RDS.
  • the transmitted electronic coin data record Ci is received as Ci * in TE2.
  • the TE2 With the receipt of the electronic coin dataset Ci * , the TE2 is in possession of the digital money that the electronic coin dataset Ci * represents. With the direct transfer 105 it is available to the TE2 for further actions.
  • SEI Due to the higher degree of trustworthiness when using SEs, SEI, SE2 can trust one another and, in principle, no further steps are necessary for the transmission 105 . However, the SE2 does not know whether the electronic coin data record Ci * is actually valid. To further secure the transmission 105, further steps can be provided in the method, as will be explained below.
  • another RDS for example the masked transmitted electronic coin data record Zi *
  • the RDS ie, for example, the masked, transmitted electronic coin data record Zi *
  • the RDS is then transmitted to the coin register 2 in step 104 and searched for there. If both RDSs match with regard to the same coin data set C, i.e. for example a match with a registered and valid masked electronic coin data set Zi, the validity of the received coin data set Ci * is displayed to the SE2 and it applies that the received electronic coin data set Ci * is equal to the registered electronic Coin record Ci is.
  • the validity check can be used to determine that the received electronic coin data set Ci * is still valid, ie that it has not already been used by another processing step or in another transaction/action and/or has undergone further modification was.
  • the electronic coin data record Ci authorizes payment, i.e. to carry out a transaction successfully, in particular if the coin data record Ci is valid, for example if the electronic coin data record Ci has an active status.
  • the status is preferably only set to an active status upon receipt of the deletion confirmation from the SEI.
  • the masked electronic coin records Zi are registered in the coin register 2, such as a public database. This registration 104 first makes it possible to check the validity of the electronic coin data set Ci, for example whether new monetary amounts were (illegally) created.
  • the masked electronic coin data sets Zi are stored in the coin register 2. All processing of the electronic coin data record Zi is registered there, whereas the actual transmission of the digital money takes place in a (secret, i.e. not known to the public) direct transaction layer 3 of the payment system BZ. In addition, monitoring of the coin data record C and the subscriber unit TE can be recorded in a coin register 2 in this payment system BZ.
  • the electronic coin data sets C can be modified to prevent multiple spending or to ensure more flexible transmission 105 .
  • Examples of operations are listed in Table 1 below, whereby a corresponding processing step is also carried out with the specified command:
  • Table 1 Number of operations that can be carried out per processing of a C in the TE or the publisher instance Other operations not listed in Table 1 may be required, such as changing currency or cashing the monetary amount into an account. Instead of the implementation listed, other implementations are also conceivable which imply other operations.
  • Table 1 shows that for each coin data set, each of the processing (modification) “Create”, “Return”, “Split”, “Connect” and “Switch” different operations “Create Signature”; “Create random number”; “Create Mask”; “Range check” can be provided, with each of the processing operations being registered in the coin register 2 and appended there in unchangeable form to a list of previous processing operations for masked electronic coin data sets Zi.
  • the processing operations "Create” and “Return” of an electronic coin data record C are only executed in secure locations and/or only by selected entities, for example the issuer entity 1, as privileged entities, while the operations of all other processing operations are carried out on the subscriber units TE, i.e the terminals M or their security elements SE can be performed.
  • the subscriber units TE can be designed using an e-wallet for electronic coin data records Ci (with the test value p, pup ⁇ ), i.e. as an electronic purse with a memory area in which a large number of coin data records Ci can be stored, and thus, for example, in the form of an application be implemented on a smartphone or IT system of a retailer, a commercial bank or another market participant.
  • the components in the subscriber unit TE as shown in Table 3 are implemented in software. It is assumed that the coin register 2, a transaction register (not shown) and/or a monitoring register (not shown) is based on a server or on a DLT and is operated by a number of trusted market participants.
  • an RDS relating to the electronic coin data record C can be replaced by an RDS relating to the electronic coin data record C or a modified electronic coin data record C to be registered. This means that (only) current coin data records C that exist in the payment system BZ are maintained as RDS in the coin register 2.
  • FIG. 4 shows a process flow chart of a process 200 for generating and issuing an electronic coin data record C in an issuing entity 1 .
  • a coin request is received in the issuing entity 1, for example the receiving unit 150.
  • the request 101 can be made by a central bank or by a subscriber unit TE or a commercial bank 4 of the payment system BZ.
  • this request is made using an air gap Process 14' to the coin generation unit 11 of the issuer entity 1.
  • step 101 a coin request is received in the issuing entity 1, for example the receiving unit 150.
  • the request 101 can be made by a central bank or by a subscriber unit TE or a commercial bank 4 of the payment system BZ.
  • this request is made using an air gap Process 14' to the coin generation unit 11 of the issuer entity 1.
  • an electronic coin data record is generated.
  • an RDS and a signed RDS can be generated in optional steps 203 and 204.
  • metadata is generated.
  • the electronic coin data record C is sent to the coin dispensing unit of the issuer instance 1 by means of the air gap process 14, optionally with the RDS and the signed RDS.
  • An expression A is preferably generated for this purpose.
  • the expression A is passed to the coin dispensing unit 12 in a dog-like manner.
  • a secured transport box (container) is used to transfer the printout (or printouts). The printout is brought to a reading section of the coin dispensing unit 12 to be read.
  • a banknote production infrastructure is preferably used.
  • the RDS and the signed RDS can be generated if this is not already the case in steps
  • step 209 the generated electronic coin data record C is output to a requesting (step 101) subscriber unit TE or a bank entity 4.
  • step 104 the coin data record C is registered in the coin register 2, for example by transmitting the RDS and/or the signed RDS.
  • Figure 5 shows a data structure for a coin register 2 of the previous figures. 5 shows data from the coin register 2 for illustration purposes; the masked electronic coin data sets Zi and, if applicable, their processing are registered here.
  • the coin register 2 can be accommodated in a server instance. Register 2 is preferably arranged locally at a distance from the subscriber units TE and is housed in a server architecture, for example.
  • Each processing operation for processing (creating, deactivating, dividing, connecting and switching over) is registered in the coin register 2 and appended there, for example in unchangeable form, to a list of previous processing operations for masked electronic coin data sets Zi.
  • the individual operations or their test results that is to say the intermediate results of processing, are recorded in the coin register 2 .
  • this data structure can also be cleaned up or compressed, if necessary according to predetermined rules, or be provided separately in a cleaned up or compressed form.
  • Fig. 5 also shows the entry in the coin register 2 for the modification "Freeze”, also known as "blocking", on an electronic coin data set C, in which a temporary deactivation of the electronic coin data set C, better the monetary value Amount of the electronic coin data record C, is caused without removing the monetary amount from the payment system (to destroy).
  • an electronic coin data record is blocked (frozen), ie the monetary amount is still available, but cannot be used by any participant—in the context of a payment transaction—to see monetary amounts from stau.
  • This "freezing" modification cannot be carried out by a subscriber unit TE, ie not by the owner of the electronic coin data set C.
  • This "freezing" modification can only be initiated and carried out by a privileged authority, for example an issuer authority 1 or a monitoring authority (not the coin register 2).
  • This privileged authority can be, for example, an authorized authority, for example a criminal prosecution authority, or a combination of several trustworthy authorities. In this way, a sum of monetary value from a suspect can be confiscated without the money being destroyed in the BZ payment system.
  • the coin data sets C deactivated by a "freeze” action are reactivated (i.e. reactivated).
  • This "reactivation" modification can only be initiated and carried out by a privileged authority, for example an issuer authority 1 or a monitoring authority (not the coin register 2).
  • This privileged authority can be, for example, an authorized authority, for example a criminal prosecution authority, or a combination of several trustworthy authorities. In this way, a monetary amount of a suspect can be released again, for example after the suspect has been proven innocent.
  • a request 210 from a central bank 1a is used in the issuing entity 1 in order to generate an eMDS C.
  • the procedure is in accordance with the steps from the process flow diagram of the process 200 according to FIG. 6 .
  • the eMDS C is generated and provided as a printout A to the coin dispensing unit 12 in the air gap process 206 .
  • Unit 12 receives the eMDS C and optionally creates the RDS and the signed RDS in steps 207 and 208.
  • the RDS is registered with coin register 2.
  • the query 101 provides the eMDS C in step 209 (102) to the TE1.
  • the request 210 of a central bank 1a is used in the issuing entity 1 in order to generate an eMDS C.
  • the request is routed to the unit 11 in step 201, preferably as an air gap process.
  • the procedure is in accordance with the steps from the process flow diagram of the process 200 according to FIG. 6 .
  • steps 202, 203, 204 the eMDS C, the RDS and the signed RDS are generated and made available as a printout A to the coin dispensing unit 12 in the air gap process 206.
  • the unit 12 receives the eMDS C, the RDS and the signed RDS.
  • step 104 the RDS and the signed RDS are registered with the coin register 2.
  • the query 101 provides the eMDS C in step 209 (102) to the TE1.
  • the signed RDS is provided by the unit 12 to the coin register 2 and the RDS is generated in the TE1 and then sent to the coin register 2 (shown in dashed lines).
  • FIG. 7 once again shows, by way of example, the known steps possible for each subscriber unit of the value-based system. Some of the area verifications to be provided in the case of the use of equation (3) are not shown.
  • a newly issued, signed, masked electronic coin data set Zi is sent to the coin register 2 in step 1015 and the masked electronic coin data set Zi is registered there.
  • the subscriber unit TE1 receives the associated electronic coin data set Ci.
  • steps 103, 104 which are only optional, the subscriber unit TE1 checks whether a masked, electronic coin data record is registered for the coin data record Ci received.
  • step 103 the subscriber unit TE1 masks the received electronic coin data set Ci, in particular according to equation (3) or (3-1) and sends a status request to the coin register for the masked electronic coin data set Zi*.
  • the subscriber unit TE1 can switch the received electronic coin data set.
  • step 105 the coin data record Ci is transmitted in the direct transaction layer 3 to the second subscriber unit TE2.
  • steps 106 and 107 there is again a validity check with prior masking, in which case the coin register 2 confirms the validity of the coin data set Zi or Ci.
  • a received coin data set C k is switched over (of course, the received coin data set Ci could also be switched over) to a new one Coin record Ci, which invalidates coin record C k and prevents double-spend.
  • the monetary amount V k of the transmitted coin data record C k is used as the "new" monetary amount.
  • a concealment amount n is created.
  • the additional obfuscation amount r add is used to prove that no new money (in the form of a higher monetary amount) was generated by the second subscriber unit TE2. Then the masked coin data records Zi and Z k are sent to the coin register 2 in a switchover request and the switchover from C k to Ci is thus instructed.
  • TE2 can generate an EVP according to Equations 9e through 9g to indicate that TE2 owns two coins Ci and Ck and both monetary amounts are equal. TE2 can then send Zi, Zk and the EVP to coin register 2 for verification and validation.
  • step 108 ' the corresponding check is carried out in the coin register 2.
  • the coin register 2 checks whether the masked coin data set Z k to be switched is a registered masked coin data set, in particular whether its status is valid, checks whether the changeover request is amount-neutral and registers - if both checks have been positive - the new masked coin data record Zi as a valid masked coin data record.
  • Z k is entered in column 22a and in column 23b the coin data record Zi to be rewritten according to the table in FIG.
  • a check is then carried out in the coin register 2 to determine whether Z k is (still) valid, i.e. whether the last processing of Z k is entered in one of the columns 23a/b (as proof that Z k is not further divided or deactivated or connected) and whether a check for the last processing failed.
  • Zi is entered in column 23b and the markings in columns 25, 26, 27 are initially set to "0". A check is now made as to whether Zi is valid. If it is good, the mark in column 25 is set to “1”, otherwise to “0”.
  • the optional step 109 two coin data records C k and Ci are connected to a new coin data record C m , as a result of which the coin data records C k , Ci become invalid and double dispensing is prevented.
  • the monetary amount n m is calculated from the two monetary amounts U k and ni formed.
  • the concealment amount r m is formed from the two concealment amounts r k and n.
  • the masked coin data set Z m to be connected is obtained by means of equation (3) and this (together with other information) is sent to the coin register 2 and connection is requested as processing.
  • a signature S k and a signature Si are generated and communicated to the monitoring register 6 and/or the coin register 2 .
  • TE2 may generate an EVP according to Equations 9e through 9g to indicate that TE2 owns the two coins Ci and Ck and no new monetary amounts have been generated. TE can then send Z m and Zi or Z m and Z k as well as the EVP to coin register 2 for checking and validation.
  • step 109' the corresponding check takes place in the coin register 2.
  • the markings in columns 25, 26, 27 are initially set to "0". A check is now made as to whether Z m is valid. If it is good, the mark in column 25 is set to “1”, otherwise to “0”. A check is now made that Zi plus Z k is equal to Z m and the marking in column 26 is set accordingly. Furthermore, it is checked whether the areas are conclusive, then the marking is set in column 27.
  • the coin register 2 can check the EVP using Equations 9h and 9i and then mark Z m as valid and mark Z k and Zi as invalid.
  • a coin data set Ci is asymmetrically divided into two partial coin data sets C k and Q, whereby the coin data set Ci is invalidated and the two asymmetrically divided partial coin data sets C k and Q are to be validated.
  • the monetary amount Ui is divided into monetary partial amounts Uk and Uj of different sizes .
  • the concealment amount n is divided into the two concealment amounts rk and h.
  • the masked coin part data sets Z k and Z j are obtained by means of equation (3) and sent to the coin register 2 with further information, for example the range checks (zero-knowledge proofs), and the splitting is requested as processing.
  • a signature Si is created and sent to the coin register 2 .
  • TE2 can generate an EVP according to Equations 9e through 9g to indicate that TE2 is in possession of the two coins Ci, Q and Ck and none new monetary amounts were generated.
  • TE can then send Zi and Zj or Zi and Zk as well as the EVP to coin register 2 for verification and validation.
  • step 110' the corresponding check takes place in the coin register 2.
  • the markings in columns 25, 26, 27 are initially set to "0". A check is now made as to whether Zj and Zk are valid, in which case the check according to equations (16) and (17) can be used. If it is good, the marking in column 25 is set to "1". A check is now carried out, the calculation according to equation (10) shows that Zi is equal to Zk plus Zj and the marking in column 26 is set accordingly. Furthermore, it is checked whether the areas are conclusive, then the marking is set in column 27. When checking the signature, it can be checked whether the second subscriber unit TE2 has exceeded a limit value for monetary amounts. The check is carried out with regard to a unit of time, for example a daily limit value could be monitored with it. Alternatively or additionally, the coin register 2 can check the EVP using equations 9h and 9i and then mark Zi and Zj as valid and mark Zk as invalid.
  • FIG. 9 An exemplary deactivation is shown in FIG. 9 .
  • a deactivation request 111 is sent to the coin dispensing unit 12 by the TE1.
  • the coin dispensing unit 12 creates a delete request 212 and sends it to the coin register 2 in order to delete the RDS for the eMDS C to be deactivated.
  • the monetary amount of the eMDS C is credited to the participant's account.
  • FIG. 10 shows an embodiment of a method flow diagram of a method 400 for registering 104 a coin data record within an atomic exchange procedure between the different systems. The steps of FIG. 10 are also shown in FIG. 11 and will be described together with FIG.
  • Method 400 depicts an atomic exchange method between TE1 and TE2, in which TE2 would like to exchange a data record from a system other than the payment system BZ with an eMDS C of TE2's BZ.
  • the BZ payment system is value-based System, in particular of the type described so far.
  • the other system Sys2 is another payment system and supports - preferably as an access-based system - smart contracts, for example it can be a system for exchanging a cryptocurrency such as BitCoin, Lightning, LiteCoin etc.
  • the other system is a bitcoin blockchain system.
  • TE2 wants to send Bitcoins to TE1 and receive a C from TE1 in return.
  • TE2 has a BitCoin wallet with one Bitcoin and would like to receive the eMDS C from TE1 in its CBDC data storage. Accordingly, TE1 and TE2 are both set up to carry out transactions in both systems Sys2, BZ.
  • TE1 has C and would like Bitcoin from TE1 in return. For the sake of simplicity, it is assumed that TE1 has (only) one C and TE2 (only) one bitcoin to be exchanged with each other.
  • one or both subscriber units has a plurality of eMDS C and/or data sets (such as BitCoin) and exchanges a plurality of eMDS C of the payment system and/or data sets of the other system as part of the atomic swap.
  • eMDS C and/or data sets such as BitCoin
  • a new electronic coin data set (the eMD of TE1) is registered 104 in the coin register 2. This can also be referred to as the registration phase and is primarily part of this application.
  • the setup is first carried out by TE2 and then the registration by TE1. Reversing the order of "setup” and “registration” is not completely impossible, so that TE1 can also initiate the atomic exchange. However, the order shown increases the security of the solution.
  • the exchange (including SWAP) is carried out in steps 410 to 418, the eMD changes ownership from TE1 to TE2 in step 410, after various checks, TE2 places the original image data record in step 414 to unlock the HTLC-secured data record Coin register 2 open. TE1 can then unlock the HTLC-secured data record and credit it (redeem).
  • Steps 401 to 418 are linked to defined periods of time TI and T2.
  • TE2 In step 401, TE2 generates a secret for this purpose, also referred to as a pre-image.
  • This secret is initially unknown to TE1 and is a database for a scatter value calculation via the original image by TE2.
  • the scatter value H is calculated using the scatter value function sha256 over the original image, for example.
  • TE2 defines a time period TI.
  • the scatter value H and the time span TI form the basis for a Hash Timelock contract, HTLC for short.
  • the TE2 In step 402, the TE2 generates a Bitcoin transaction - also referred to below as a data record.
  • the HTLC secures the data set in such a way that a recipient of the data set needs the original image of the scatter value H in order to be able to use the data set as intended.
  • the time period TI is provided so that TE2 can use the data set again as intended if within the time period TI there is no unlocking by means of an original image from another TE, i.e. the data set has not been redeemed using an original image.
  • step 403 the data set created (bitcoin, smart contracts, cryptocurrency) is introduced into a system Sys2, a system that is not the BZ payment system.
  • Sys2 is a blockchain architecture
  • the record is committed in one node, Sys2-Node.
  • the HTLC added to the data record means that TE1 must know the secret (original image) in order to unlock the data record in Sys2 and to be able to credit the data record to itself (“redeem”).
  • the hash value H and the time duration TI of the HTLC of the data record of Sys2 are queried or received by TE1 at Sys2.
  • a request-response scheme can be used that is additionally secured by authentication and, if necessary, encrypted transmission.
  • TE1 creates a first electronic coin data set C k and a second electronic coin data set Q from an existing coin data set Ci.
  • the alternative with two generated electronic coin data records C k and Q is to be pursued further in FIG. The following three conditions apply to Ci, C k and Q:
  • step 406 the optional EVP jk and EVPik are calculated according to equations (9e) to (9g) and a time duration T2 is defined.
  • the time period T2 is, for example, a few days, preferably 3 days.
  • Zi if not already present
  • Z k and Z j are calculated.
  • a new registration request is sent.
  • This request can also be referred to as a SWAP command in the BZ system.
  • the coin register 2 receives the following elements: Zi, Z j optionally with EVPi- j and duration T2, and Z k optionally with EVPi- k and the hash value H from the HTLC of Sys2.
  • Z j is secured with the time duration T2 (time lock) and Z k is secured with the hash value H (hash lock), so that a registration request with HTLC is transmitted to the coin register 2 as a result.
  • the masked coin data set Z j is secured with the scatter value H (hashlock) in step 407 and the registration request is interpreted as a time-delayed changeover command (by the time span T2).
  • Either TE2 releases the hash lock at Z j by disclosing the original image data set to coin register 2, or coin register 2 switches back from Z j back to Zi for TE1, delayed by time span T2, because time span T2 has expired .
  • a SWAP is executed or an original state is restored.
  • EVPi- j is verified from Zi and Zj (optional),
  • SWAP The actual exchange
  • TE1 transmits the coin data record Q to TE2 in step 410.
  • TE2 checks the correctness of the monetary amount of Q .
  • TE2 queries coin register 2 for the availability of Z k and checks whether the hash H of Z k matches the hash H from the data set. In addition, TE2 checks whether the end of the time period T2 is still in the future.
  • a Z m is calculated and optionally in step 413 the EVP km is calculated according to equations (9e) to (9g).
  • TE2 sends a registration request (also referred to as REDEEM) to coin register 2 with Z m , (possibly EVP km ) and the original image data set from step 401.
  • REDEEM a registration request
  • step 415 If all up to three verifications in step 415 have been successfully performed, then:
  • step 415 If one of the up to three verifications in step 415 is not successful, then an error message is sent to TE2 and the atomic swap is aborted. After the time period T2 has elapsed, Z j is switched over to TE1 (or to a SWITCH command from TE1). After the period TI has expired, the data record in Sys2 is written back to TE2.
  • the TE1 queries the original image data record from the coin register 2.
  • the query can be further secured by authentication or encryption.
  • step 417 the TE1 uses the original image data set to unlock the HTLC-secured data set of the third-party system Sys2 and have the bitcoin credited to it.
  • TE2 refuses to disclose the original image data record from step 401.
  • the atomic swap has therefore failed.
  • TE1 sends a switch command in step 420 to switch Z j to TE2, whereupon Z k is automatically invalidated.
  • Z k cannot be validated.
  • an automatic switch is made to Zi in the coin register 2 in order to restore the original state.
  • TE2 can have the bitcoin from Sys2 credited to it again in step 421.
  • Coin data record n m monetary amount of an electric to be connected/connected.
  • Coin record pi coin record aging counter value k random number for EVP n obfuscation amount random number r 0 parent obfuscation amount random number of parent coin record h, i j obfuscation amount of a split electronic coin record r m obfuscation amount of an electronic coin record to be connected

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Strategic Management (AREA)
  • Signal Processing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Cash Registers Or Receiving Machines (AREA)

Abstract

L'invention concerne un procédé (400) pour l'enregistrement (104) d'un ensemble de données de pièces électroniques (C) dans un registre de pièces (2) d'un système de paiement électronique (BZ), ledit procédé comprenant les étapes consistant à : générer (405) un ensemble de données de pièces électroniques (Cj), qui a une valeur monétaire (vj) et une valeur d'obfuscation (rj), au moyen d'une première unité d'abonné (TE1) du système de paiement (BZ), ladite valeur monétaire (vj) de l'ensemble de données de pièces électroniques (Cj) généré correspondant à la valeur monétaire (m) d'un ensemble de données de pièces électroniques (Ci) présent dans la première unité d'abonné (TE1) ; masquer (406) l'ensemble de données de pièces électroniques (Cj) généré au moyen de la première unité d'abonné (TE1) par application d'une fonction unidirectionnelle (f(C)) à au moins un élément de données de l'ensemble de données de pièces électroniques (Cj) afin d'obtenir un ensemble de données de pièces électroniques (Zj) généré masqué ; transmettre une demande d'enregistrement (407) pour l'ensemble de données de pièces électroniques (Zj) généré masqué conjointement avec une serrure horaire de la première unité d'abonné (TE1) au registre de pièces (2), la serrure horaire spécifiant une période de temps (T2) jusqu'à ce que l'ensemble de données de pièces électroniques (Cj) généré puisse être basculé sur une seconde unité d'abonné (TE2) du système de paiement (BZ) dans le registre de pièces (2). L'invention concerne en outre un registre de pièces (2), un système de paiement (BZ), une unité d'abonné (TE) et un produit de programme d'ordinateur.
PCT/EP2022/025198 2021-05-03 2022-05-03 Procédé d'enregistrement d'un ensemble de données de pièces électroniques dans un registre de pièces ; registre de pièces ; unité d'abonné et produit de programme d'ordinateur WO2022233454A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP22725994.2A EP4334872A1 (fr) 2021-05-03 2022-05-02 Procédé d'enregistrement d'un ensemble de données de pièces électroniques dans un registre de pièces; registre de pièces; unité d'abonné et produit de programme d'ordinateur

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021002329.3 2021-05-03
DE102021002329.3A DE102021002329A1 (de) 2021-05-03 2021-05-03 Verfahren zum registrieren eines elektronischen münzdatensatzes in einem münzregister; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt

Publications (2)

Publication Number Publication Date
WO2022233454A1 true WO2022233454A1 (fr) 2022-11-10
WO2022233454A8 WO2022233454A8 (fr) 2024-05-23

Family

ID=81850682

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/025198 WO2022233454A1 (fr) 2021-05-03 2022-05-03 Procédé d'enregistrement d'un ensemble de données de pièces électroniques dans un registre de pièces ; registre de pièces ; unité d'abonné et produit de programme d'ordinateur

Country Status (3)

Country Link
EP (1) EP4334872A1 (fr)
DE (1) DE102021002329A1 (fr)
WO (1) WO2022233454A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5872844A (en) 1996-11-18 1999-02-16 Microsoft Corporation System and method for detecting fraudulent expenditure of transferable electronic assets
DE102019002731A1 (de) * 2019-04-15 2020-10-15 Giesecke+Devrient Gesellschaft mit beschränkter Haftung Gerät zum direkten Übertragen von elektronischen Münzdatensätzen an ein anderes Gerät sowie Bezahlsystem
WO2020212337A1 (fr) 2019-04-15 2020-10-22 Giesecke+Devrient Gmbh Procédé pour le transfert direct de jeux de données électroniques de monnaie entre des terminaux ainsi que système de paiement
US20210073913A1 (en) * 2019-09-06 2021-03-11 Bosonic, Inc. System and method of providing a block chain-based recordation process

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5872844A (en) 1996-11-18 1999-02-16 Microsoft Corporation System and method for detecting fraudulent expenditure of transferable electronic assets
DE102019002731A1 (de) * 2019-04-15 2020-10-15 Giesecke+Devrient Gesellschaft mit beschränkter Haftung Gerät zum direkten Übertragen von elektronischen Münzdatensätzen an ein anderes Gerät sowie Bezahlsystem
WO2020212331A1 (fr) 2019-04-15 2020-10-22 Giesecke+Devrient Gmbh Dispositif pour le transfert direct d'ensembles de données de pièces de monnaie électroniques vers un autre dispositif et système de paiement
WO2020212337A1 (fr) 2019-04-15 2020-10-22 Giesecke+Devrient Gmbh Procédé pour le transfert direct de jeux de données électroniques de monnaie entre des terminaux ainsi que système de paiement
US20210073913A1 (en) * 2019-09-06 2021-03-11 Bosonic, Inc. System and method of providing a block chain-based recordation process

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
MAURICE HERLIHY: "Atomic Cross-Chain Swaps", PROCEEDINGS OF THE 2018 ACM SYMPOSIUM ON PRINCIPLES OF DISTRIBUTED COMPUTING , PODC '18, 21 May 2018 (2018-05-21), New York, New York, USA, pages 245 - 254, XP055538164, ISBN: 978-1-4503-5795-1, DOI: 10.1145/3212734.3212736 *
OPARE EDWIN AYISI ET AL: "A Compendium of Practices for Central Bank Digital Currencies for Multinational Financial Infrastructures", IEEE ACCESS, IEEE, USA, vol. 8, 11 June 2020 (2020-06-11), pages 110810 - 110847, XP011795271, DOI: 10.1109/ACCESS.2020.3001970 *
RAFAEL BELCHIOR ET AL: "A Survey on Blockchain Interoperability: Past, Present, and Future Trends", ARXIV.ORG, CORNELL UNIVERSITY LIBRARY, 201 OLIN LIBRARY CORNELL UNIVERSITY ITHACA, NY 14853, 22 March 2021 (2021-03-22), XP081896050 *

Also Published As

Publication number Publication date
EP4334872A1 (fr) 2024-03-13
DE102021002329A1 (de) 2022-11-03
WO2022233454A8 (fr) 2024-05-23

Similar Documents

Publication Publication Date Title
EP3956845A1 (fr) Dispositif pour le transfert direct d'ensembles de données de pièces de monnaie électroniques vers un autre dispositif et système de paiement
DE102019002732A1 (de) Verfahren zum direkten Übertragen von elektronischen Münzdatensätzen zwischen Endgeräten sowie Bezahlsystem
EP4111348B1 (fr) Procédé de transmission directe de jeux de données de pièces de monnaie électroniques entre terminaux, système de paiement, système de protection et unité de surveillance
DE102009038645A1 (de) Verfahren und tragbarer Datenträger zum Übertragen eines geldwerten Betrages in Form eines elektronischen Datensatzes zwischen einer ersten nichtzentralen Instanz und einer zweiten nichtzentralen Instanz
WO2022008322A1 (fr) Procédé, unité participante, registre de transaction et système de paiement pour gérer des ensembles de données de transaction
EP4111399B1 (fr) Procédé, terminal, entité de surveillance et système de paiement pour gérer des ensembles de données électroniques de pièces de monnaie
WO2023036458A1 (fr) Procédé et système de transaction pour transmettre des jetons dans un système de transaction électronique
WO2023011761A1 (fr) Élément de sécurité, procédé d'enregistrement de jetons et registre de référence de jeton
EP4179488A1 (fr) Entité d'émission et procédé d'émission d'ensembles de données électroniques de pièces de monnaie, et système de paiement
WO2022233454A1 (fr) Procédé d'enregistrement d'un ensemble de données de pièces électroniques dans un registre de pièces ; registre de pièces ; unité d'abonné et produit de programme d'ordinateur
EP4111347B1 (fr) Procédé de transmission directe d'ensembles de données de pièce de monnaie électronique entre terminaux, système de paiement, système de protection et entité de surveillance
DE102020104902A1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungsinstanz
DE102021000570A1 (de) Verfahren zum bereitstellen eines nachweisdatensatzes; verfahren zum prüfen eines nachweisdatensatzes; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt
EP4179486A1 (fr) Système de paiement, registre de pièces de monnaie, unité d'abonnés, registre de transaction, registre de contrôle et procédé de paiement avec des ensembles de données de pièces de monnaie électroniques
WO2023011756A1 (fr) Élément sécurisé, procédé d'enregistrement de jetons et registre de référence de jeton
WO2022008321A1 (fr) Procédé, terminal et registre de pièces pour transmettre des jeux de données de pièces électroniques
WO2024012624A1 (fr) Procédé de génération sécurisée d'un jeton pouvant être émis, procédé de destruction sécurisée d'un jeton et émetteur de jeton
WO2023202836A1 (fr) Dispositifs, système et procédé de paiement électronique scriptural
WO2024027869A1 (fr) Élément sécurisé, procédé d'enregistrement de jetons et registre de référence de jeton
DE102009035412A1 (de) Verfahren und System zum Übertragen von geldwerten Beträgen in Form elektronischer Datensätze

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22725994

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2022725994

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2022725994

Country of ref document: EP

Effective date: 20231204