EP4405879A1

EP4405879A1 - Coin managing unit, and method in a coin managing unit

Info

Publication number: EP4405879A1
Application number: EP22757842.4A
Authority: EP
Inventors: Klaus ALFERT; Lars HUPEL; Teresa RIEDL
Original assignee: Giesecke and Devrient Advance52 GmbH
Current assignee: Giesecke and Devrient Advance52 GmbH
Priority date: 2021-09-24
Filing date: 2022-07-18
Publication date: 2024-07-31
Also published as: WO2023046317A1

Abstract

The invention relates to a coin managing unit of a user, comprising: an execution unit (31) for managing digital coin data sets (335; 395) of a central bank digital currency system, said execution unit being adapted so as to exchange digital coin data sets (335; 395) with other coin managing units and transmit registration requests to a coin register (20) of the central bank during transactions; and at least one digital coin data set (335; 395). The coin managing unit (330, 31; 390) is adapted so as to store required transactions (336a, 336b; 396a-c) as data elements, wherein a transaction is carried out only when a condition of the stored required transaction (336a, 336b; 396a-c) is satisfied. The coin managing unit (330, 31; 390) is additionally adapted so as to store required transactions (336a, 336b; 396a-c) with different reading and/or writing rights (337a, 337b, 338a, 338b; 397a-c, 398a-c). The invention additionally relates to a corresponding method and a central bank digital currency system.

Description

Coin management unit and method in a coin management unit

The invention relates to a coin management unit and a method for managing coin data sets in a coin management unit.

Various technical solutions are already known for a digital currency (CBDC) issued by a central bank.

According to a first approach, coin data records are only cryptographically secured by a central bank entity and the cryptographically secured coin data records are exchanged directly between the user's coin management units in encrypted form. The coin management units can use the cryptographic security, such as a signature, to check the authenticity of the coin data record and should first check a certificate from the central bank and/or the other coin management unit for validity within the certificate hierarchy.

According to a second approach, the digital money or the coin data records are stored in a central or decentralized blockchain of a central bank. However, when a coin record on a blockchain changes hands as part of a transaction, a lot of information (sender/receiver/amount) is often made public and usually the sender and receiver need access to the blockchain at the time of the transaction. Since the blockchain or its server can access the electronic coin data records, the server can, for example, carry out a transaction independently at a specified time.

According to a third approach, the coin data sets are stored and exchanged directly by the user, for example in a local coin management unit. A coin register stores a record for all valid coin records so that the user can verify the validity of the coin records using the coin register. Because the coin register only includes registration records, it does not have access to the coin records themselves.

WO 2020/212331 A1 uses and extends this third approach, through which the coin data sets can be exchanged directly between users. In WO 2020/212331 A1, a directly exchanged coin data record can also be forwarded to a further recipient without a connection to the coin register being necessary. The recipient or the additional recipient can later generate a new coin data set with the same amount and send a request to the coin register that the registration of the old coin data set in the coin register is replaced by a registration of the new coin data set of the same amount.

Furthermore, WO 2020/212331 A1 describes that a local coin management unit of the user—in addition to the usual administration of the coin data sets including direct exchange of the coin data sets and sending registration requests—coin data sets can be outsourced to a safe module of the user.

It is the object of the present invention to create a method, a coin management unit or a system in which a payment transaction is designed to be secure but nevertheless simple.

This object is achieved with a coin management unit and with a method in such a unit comprising the features of the independent claims. The dependent claims relate to preferred embodiments.

A user's coin management unit, comprising an execution unit for managing digital coin records of a central bank digital currency system, the execution unit being adapted to exchange digital coin records in transactions with other coin management units and to send registration requests to a central bank coin register; and at least one digital coin record.

The coin management unit is now adapted to store conditional transactions as data items, where a transaction is not executed until a condition of the stored conditional transaction is met.

The coin management unit is further adapted to store the conditional transactions with different read and/or write rights.

The combination of stored conditional transactions and different read and/or write permissions creates a very flexible, versatile solution. In the coin management unit, at least one first conditional transaction preferably has first read and/or write rights and at least one second conditional transaction has second, different read and/or write rights. The two read and/or write permissions can differ in the read permissions, the write permissions or the read and the write permissions. The coin management unit can also include other conditional transactions with first, second or third read and/or write rights.

In preferred refinements, the read and/or write rights differ in the write rights for the user and/or in the read and/or write rights for third parties, in particular for the other coin management units.

The condition contained in the stored conditional transaction can include: a time condition, in particular a point in time or a period. The point in time after which the transaction is to be carried out can be specified, for example, as a time, day of the week and/or date. For example, the period can be specified in hours, days, weeks, months and/or years, for example every 2 hours or daily or monthly. The transaction for the saved conditional transaction is then executed periodically (multiple times). It is executed again after the end of the period.

Alternatively, the condition can be a comparative condition, in particular a comparison value, which is compared with an internal parameter of the coin management unit, such as the total amount of the coin data records in the coin management unit or transaction counter or transaction sum in a period of time or ..., or with an external parameter , like stock price, data item in a server or database, ... . The coin management unit can call up the external parameter for comparison, for example, or receive it automatically from an external source.

Further alternatively, the condition may be a reception condition. In particular, the transaction can be executed as soon as a security value, such as a signature, or a code value, such as a password, of the conditional transaction is received. Likewise, receiving a receive transaction as a condition or receiving a request for the conditional transaction can serve as a condition.

Since the transaction will not be executed until the condition contained in the stored conditional transaction is met, the transaction can also be called the indicate the transaction to be executed. As part of the transaction, a coin data record is exchanged (sent or received) with another coin management unit, so that the transaction could also be referred to as an exchange transaction.

The condition can optionally contain an execution limitation, for example comprising an execution number (single, n-times or an unlimited number of times) and/or a time specification (executable up to a point in time).

The coin management unit, preferably its execution unit or a condition checking unit, checks whether the condition of the conditional transaction is fulfilled. The checking can in particular take place continuously, periodically, for example hourly or daily (however adapted to the conditions to be checked), and/or in response to a reception process in the coin management unit.

Different types of conditional transactions can be stored in the coin management unit. In particular, at least two or three different types of conditional transactions are stored. The types can be individually or in combination with each other: guaranteed conditional transaction, callable conditional transaction, periodic conditional transaction and/or consideration conditional transaction. The coin management unit preferably stores:

- at least two conditional transactions of a first type, which have the same or different read and/or write permissions, and/or

- at least two conditional transactions of at least two different types, which have the same or different read and/or write permissions.

In addition to the basic data of the transaction to be executed, recipient, sender and amount, the conditional transaction can already include one or more further data elements of the transaction, in particular the coin data set to be exchanged and/or the transaction number. The conditional transaction can already include all data elements of the transaction to be executed. Such an embodiment is possible in particular for transmission transactions to be executed that can only be read by the user and not by third parties (or reception transactions that can only be read by the sender and not by the user). The conditional transaction preferably does not include one or more of the data elements of the transaction to be executed only when the condition is met, in particular one or more of the following data elements:

- an identifier of the sender of the at least one coin data set, for example if the sender is arbitrary or may belong to a group,

- an identifier of the recipient of the at least one coin data set, for example if the sender is arbitrary or may belong to a group

- a transaction number, especially if the transaction can be executed several times,

- the at least one coin data record of the transaction to be executed, only for example in the case of multiple execution or a previously missing transaction partner.

The coin management unit can be a coin management unit with its own execution unit and can optionally include a number of the user's coin depositories. The coin management unit can, for example, be designed as a security module, chip card, part of a mobile radio device, RFID, USB or Bluetooth token or . . . The coin management unit can be present in a coin depot management unit that comprises a number of coin depots, preferably of different users, and an execution unit that is common to the number of coin depots, the coin management unit being formed by one of the coin depots together with the common execution unit. The coin depot management unit is usually a server that makes the coin depots available to the different users.

Each coin management unit should include a coin management unit identifier (ID) and may optionally include a key, e.g. for authenticating the coin management unit, and/or a certificate associated with the identifier and/or the (public) key (of the key pair).

The coin management unit comprises at least one memory area for conditional transactions of the coin management unit or a coin depot, and also a common memory area for several coin depots - the coin management unit or a coin depot management unit with the coin management unit - in which one or more of the following information is stored:

References to one or more coin depositories with conditional transactions, in particular coin depositories to be time-tested, more preferably with their test interval; and/or the conditions to be checked of conditional transactions of several coin depositories; and or the conditional transactions of the coin management unit readable for any third party.

This refinement is helpful in particular when the conditions for a large number of coin depositories or for coin depositories stored in encrypted form are to be checked.

In particularly preferred variants, conditional transactions are based on the read and / or write rights: readable by at least one other coin management unit of another user of the digital central bank currency system, but only by the user or only jointly by the user and the at least one other coin management unit of the other user of the digital central bank currency system are writable; and/or readable and writable only by the user; and/or readable by at least one other coin management unit of another user of the central bank digital currency system, but writable only by one issuer unit.

The coin management unit can include specifications that are checked for transactions to be executed and/or for conditional transactions to be stored. In particular, it can be set up to check one or more of the following specifications before executing transactions:

- a recipient specification which restricts the coin management unit to exactly one recipient, exactly one recipient group or to several recipients and/or recipient groups, and/or

- a transmitter specification which restricts the coin management unit to exactly one transmitter, exactly one transmitter group or several transmitters and/or transmitter groups, and/or

- A functional specification relating to an executable function of the execution unit, which in particular the executable function for the

Coin management unit, preferably for a coin depot of the coin management unit, completely, partially or not restrict; and or

- a transmission or reception specification, which limits the transmission of coin data records or the reception of coin data records for the coin management unit, preferably for a coin depot of the coin management unit; and or

- A specified amount with a maximum value for the amount of the coin data sets to be sent and/or for the amount of the coin data sets to be received and/or a maximum value or a minimum value for the total amount of the stored data coin records;

- a user-selectable constraint, which in particular is to be chosen by the user to be tighter than a constraint set by the issuer of the coin management unit; and or

- a consideration specification, in response to at least one received coin data set as a service the consideration, in particular in the response data to the transmitter of the received coin data set, is provided.

Alternatively or additionally, the coin management unit can include specifications and be set up to check the specifications before storing a conditional transaction, the specification preferably being a specification for conditional transactions. As a specification for conditional transactions, for example - in addition to the specifications already mentioned for amount, recipient or sender, which can be narrower for conditional transactions than for transactions to be carried out directly, specifications of the issuer of the coin management unit or the user in question, which, for example, the type of conditional transaction and/or the type of condition for the coin management unit.

As already described in part, two coin depots in the coin management unit could be assigned to the same user or assigned to different users in a coin depot management unit.

The secure execution unit for managing the coin data sets is also preferably set up to

- sends trade register data to a trade register, the trade register data comprising in particular a unique transaction identifier, a transaction amount, a coin management unit identifier of the sender, a coin management unit identifier of the recipient and the register reference of the coin data record in the coin register; and or

- sends registration requests to the coin register, which include at least one register reference of a coin data record previously registered in the coin register and a register reference of a coin data record to be registered in the coin register.

In the digital central bank currency system, digital coin data sets can be split (into several coin data sets: 10 => 5.5), switched (amount-neutral exchange: new coin for old coin) or connected to another coin data set (new coin data set: 2 +10 =12 ). For the new coin records or their references are then to be sent corresponding registration requests to the coin register.

It should be noted that the defaults and conditional transactions are stored as data items, so they are not fixed by the programming of the coin management unit (software).

A conditional transaction with read and/or write rights can be stored for a coin depot of the coin management unit, in particular in an intermediate memory of a coin depot of the coin management unit or in an inter-coin depot intermediate memory of the coin management unit

In particular, a recipient of the transaction or a third party can, for example, trigger the transaction if he knows the security value and sends it as a trigger (possibly together with the ID of the coin management unit and/or a transaction number). For example, a random value or a cryptographic security value (hash value of data/signature of data/...) can serve as security value.

Functional specifications can be provided as a positive or negative test criterion for testing the specifications. The function may be used if a positive test criterion is met or may not be used if a negative test criterion is met. Positive test criteria are preferably used for partially restrictive functional specifications. A partially restrictive directional specification preferably contains the permissible transmitters and/or receivers (positive test criterion). Alternatively or additionally, it is conceivable to store impermissible transmitters and/or receivers in the specified direction (negative test criterion). A complete restriction, such as "no transmission" or "no reception" in the case of a direction specification, can also be stored differently in a functional specification. Preferably, the full restriction is stored as the content of the functional requirement (such as "not allowed" or "no"). Alternatively, storing empty content ("" or "") or invalid content (like "-" as a number, ID, or...) could indicate the full constraint. One (or more) non-constraining functional ones may be provided to save default(s). An example would be a coin depot that is allowed to send to any recipient but only receive from certain transmitters. In preferred embodiments, the non-restrictive functional default is indicated by the absence of this default, in the example: for the coin depot is there a sender default but no receiver default. Alternatively, however, the content of the functional specification can indicate that the functional specification contains no restriction, in the example: recipient specification with the content "everyone", "all", or the like.

A functional constraint for conditional transactions may in turn contain a full, partial, or no constraint. Thus, the first functional constraint can indicate that conditional transactions are not permitted for the first coin depository (full restriction), and the second functional constraint can indicate that conditional transactions are possible for the second coin depository either with or without restrictions. Alternatively, the first functional constraint for the first coin repository could include a partial constraint on conditional transactions and the second functional constraint for the second coin repository could include no constraint on conditional transactions. As a further alternative, the two functional specifications for the coin deposits could restrict the conditioned transaction differently.

There can be different types of conditional transactions, which differ in their complexity and/or in their coding (conditional transaction coded according to standard A or type B or proprietary C...). The various types of conditional transactions are supported by the secure execution unit, but are only permitted selectively or to a limited extent in the present case for coin deposits due to corresponding specifications.

In preferred configurations, a transmission default (or receiver default) of a coin depot, ie in particular also of the first and/or second coin depot, differs from its reception default (or transmitter default). The directional specifications are therefore preferably designed asymmetrically for a coin depot.

The conditional transaction can have a send or receive specification as a condition, which restricts the sending of coin data sets or the receiving of coin data sets for the coin management unit, preferably for a coin depot of the coin management unit.

A user default may be user selectable. It will preferably be chosen to be narrower than the corresponding publisher-specified specification. The user therefore has the option of further restricting a specification from the publisher. The defaults can be referred to as publisher defaults and user defaults. Naturally, system-wide specifications (firmly programmed in the secure execution unit and) are no longer issued by the publisher definable or user selectable. Accordingly, the publisher can only specify its specifications more narrowly than the system specifications. In this respect, the secure execution unit complies with system specifications and also checks the (functional and other) specifications of the coin depository.

As the coin management unit identifier, it is preferable

- a uniform resource identifier, Uniform Resource Identifier (URI), in particular according to RFC 3986,

- a Uniform Resource Name (URN), in particular according to RFC 8141, and/or

- a system-wide unique identifier, Universally Unique IDentifier (UUID), in particular according to RFC 4122, is used. The URI can contain a UUID and/or a URN.

As parts, the URI includes, for example, a scheme such as URN or UUID, a provider such as operator name or domain name of the operator, and the unique part such as UUID or serial number. In an example: urn:uuid:965ecc78-3182-4d5b-8f6a-le325b336031.

As parts, the URN includes, for example, a resource type (example: coin management unit), an operator name, usually the domain name of the operator (example: mybank.com), and a part that is unique at least for the operator, but preferably system-wide (examples: serial number or UUID). A sender and a recipient of a transaction could then be specified as follows, for example: Sender ID: coin management unit:my-bank.com:dlafujr3jbd" and recipient ID: coin management unit:your-bank.com:3hbbda903988r".

In a UUID "xxxxxxxx-xxxx-Mxxx-Nxxx-SVxxxxxxxxxx" according to RFC 4122, the version of the UUID is coded in the M halfbyte and the variant of the UUID in the N halfbyte. Now, at least one other part of the UUID, such as the halfbytes S and/ or V (in version 4, variant 1), a functional specification can be specified. For example, the fact that the coin depot is in a coin depot management unit can be encoded in halfbyte S. In a portion of the UUID, such as this or another halfbyte, can at least brief functional specifications can be coded. For example, “no directional restriction”, “no transmission” or “no reception” could be coded in 3 bits. A specification for conditional transactions could also be encoded in the 3 bits or another 3 bits, for example the admissibility of three types of conditions or three types of conditional transactions could be encoded. The coin management unit identifier may include at least a (short) functional default or a portion of the functional defaults. A certificate can contain more data than an identifier. Correspondingly, the coin management unit certificate can contain one or more functional specifications.

A certificate can identify a coin management entity as a member of a group, for example as a group certificate, such as "ID/key belongs to group XY", or as an attribute certificate, such as "attribute YZ met". In the specification, a recipient group can also be specified, for example, by the group and/or a certificate type, such as "Certificate for group XY" or "Certificate for attribute YZ". For example, the specification can require a certificate for the attribute "Bookshop" from the publishing group "SchoeneBücher". In alternative or supplementary configurations, at least one partially restricting reception specification restricts the reception of coin data records to exactly one transmitter, exactly one transmitter group or a plurality of transmitters and/or transmitter groups. The sender(s) and/or sender group(s) are included in the specification, in particular by specifying a sender ID, a sender group ID or a sender ID part or a certificate group. However, in the specification, a sender group can also be specified, for example, by a group and/or a certificate type, such as "Certificate for group XY" or "Certificate for attribute YZ". At least one coin data record is exchanged between two coin management units as part of a transaction. A registration request is preferably sent to the coin register and/or a transaction data record is sent to a transaction register for a coin data record derived from the exchanged coin data record. The at least one coin data record is initially stored at the transmitter of the coin data record, such as the first or second coin depot. The coin data set (or a coin data set derived from it) is stored at the recipient after the transaction. The coin data record is preferably transmitted directly between the transmitter and receiver; in particular, the coin data record can be forwarded directly to a further recipient. WO 2020/212331 A1 already describes the corresponding basic principle. However, the present solution is not tied to the masking of the amount of the coin data sets described there or the specific protocols of WO 2020/212331 A1. Conditional transactions are preferably executed exactly once. However, it is possible to provide for conditional transactions that are executed several times, in particular with or without a limit on the number of executions (e.g. every 2 weeks or exactly four times due to an event). The conditional transaction can be carried out, for example with the stored amount and recipient, or alternatively a transaction requested--in particular by a third party/recipient--can be carried out, which falls under the stored, conditional transaction. For example, a transaction requested by the recipient with a transaction amount that is smaller than the saved amount and/or a recipient who belongs to a saved recipient group.

Coin deposits can be assigned to a first (same) user. For example, the first user has two coin depots in the coin management unit, which have different specifications. Alternatively, a first coin deposit can be assigned to a first user and a second coin deposit to a second user. The first and/or the second user can have several coin depots in the coin management unit as well as one (or more) local coin management unit(s), for example in the form of a security module such as chip card, SIM card, RFID token, NFC module built-in security module.

A multi-user coin depository management unit is provided by an operator, which can be, for example, a financial service provider such as a commercial bank, a credit card provider or a payment service provider (Paypal, ...). The creation of the coin depot is usually commissioned by a third party, the issuer.

The coin deposit can include a partially freely readable default, in particular the functional defaults. In particular, a readable portion and a non-readable portion of the at least partially freely readable specification can be present. The two parts are preferably stored in different data elements, in particular a freely readable data element, such as the coin management unit certificate or identifier or a non-confidential default data element, and in a non-freely readable data element of the coin deposit, such as a dedicated confidential default data element. Alternatively, the two parts are stored in a common data element that is not freely readable, and the readable part is additionally readable in a separate one Data item stored, such as the coin management unit certificate or identifier, or a non-confidential default data item.

The secure execution unit can send trade repository data to a trade repository to manage the coin records. The transaction register data include in particular a unique transaction identifier, a transaction amount, a coin management unit identifier of the sender, a coin management unit identifier of the recipient and the (at least one) register reference of the coin data set in the coin register.

Alternatively or additionally, the secure execution unit can send registration requests to the coin register to manage the coin data sets, which in particular include at least one register reference of a coin data set previously registered in the coin register and a register reference of a coin data set to be registered in the coin register.

A method for managing coin data records of a digital central bank currency system with a coin register in a coin management unit, which comprises an execution unit and at least one coin data record of the central bank, comprises the following steps in the coin management unit.

storing a first conditional transaction containing a condition for executing a transaction, the transaction involving the exchange of at least one coin record between the coin management entity and another coin management entity of the central bank digital currency system. The first conditional transaction is stored in the coin management unit as a data element and the stored first conditional transaction has read and/or write permissions that differ from the read and/or write permissions of a second conditional transaction that has already been stored.

Check whether the condition is met and execute the transaction only when the condition is met.

All previous comments on the device apply analogously in this associated method. Executing the transaction preferably includes: sending the coin record to the other coin management unit or receiving the coin record from the other coin management unit; and/or sending a registration request to a coin register of the central bank, which includes in particular at least one register reference of a coin data set previously registered in the coin register and a register reference of a coin data set to be registered in the coin register, and/or sending trade register data to a trade register, and/or the Providing a consideration, in particular after receiving the coin data set as the condition.

The method can also include the reading and/or writing process. Preferably, the following steps can be taken:

- receiving a read and/or write request from a requester, in particular a user of the coin management unit or another coin management unit, for at least one conditional transaction;

- Optional checking of an authentication of the requester;

- checking the read and/or write permissions of the at least one conditional transaction,

- Answering the read and/or write request depending on the read and/or write rights, in particular in the case of a read request by providing the conditional transaction to the requester or in the case of a write request by writing the conditional transaction.

Executing the transaction can include: sending or receiving a coin data record from the central bank, and/or sending a registration request to a coin register at the central bank, which requests the registration of a coin data record to be stored in the new coin management unit, in particular for a previously registered coin data record that has been received, and/or sending trade repository data to a trade repository, and/or providing a consideration, with the transaction request in particular comprising a coin data record.

A transaction request includes in particular a transaction amount, a coin management unit identifier of the sender and a coin management unit identifier of the recipient. Only optionally, it further includes a unique transaction identifier and/or a transaction reference text. A transaction request is usually sent by the coin depot user. In refinements, the transaction request can also be another coin management unit or a transaction partner (sender or receiver of coin data records) to the coin depot management unit. The step of executing the transaction comprises sending at least one coin data record from the coin depository to a recipient (or receiving at least one coin data record which is contained in particular in the transaction request). In the step of executing the transaction, a coin data record to be transferred can be generated and registered with the coin register, in particular if the amount of the coin data record to be transferred is to correspond to a transaction amount. At least one coin data record, that is to say optionally two or more coin data records, from the coin depository are transmitted in the step of executing the transaction. Coin data sets can be transmitted separately or in transaction messages, for example together with a transaction ID, especially if an encrypted connection has already been established between the sender and receiver. Alternatively, however, a complete transaction message can also be transmitted (particularly between coin depot management units). A complete transaction message contains in particular the data elements contained in the transaction request and the at least one coin data record.

Transaction requests, coin data records and/or complete transaction messages can preferably be contained in an http message. Alternatively or additionally, transaction requests, coin data records and/or complete transaction messages can be transmitted in a JSON format. The JavaScript Object Notation (JSON) format preferably corresponds to RFC 8259 (and/or ECMA 404 or ISO/IEC 21778). A TransactionID can be formatted as a UUID. A transaction request could then be formatted as follows, for example:

{

"Sender": "urn:coin management unit:meine-bank.com:dlafujr3jbd",

"Recipient": "urn:coin management unit:your-bank.com:3hbbda903988r", "Amount": "1.60 eCBDC"

"Transaction reference text": "Transaction number 1234898942"

}

An associated transaction message, here with 2 coin data sets, could then be formatted as follows, for example:

{

"Transaction ID": "lcl02b5f-5496-459d-8a67-3bflc348bll3",

"Sender": "urn:coin management unit:meine-bank.com:dlafujr3jbd", "Recipient": "urn:coin management unit:your-bank.com:3hbbda903988r",

"Coin Records": [

{

"amount": 1000, "...number":"116e782982383e9d0ea2c728f2a5f80d8a6121"

},

{

"Amount": 60, "...Number": "Iaaa77777777777733333c9123812123712814"

}

],

"Transaction reference text": "Invoice 1234898942"

}

The methods described can be carried out in one of the coin depot management units described above. The different methods and configurations can be combined with one another and can, for example, relate to different coin depositories or to the first and/or second coin depository.

A digital central bank currency system includes a coin management unit—in one of the configurations described or set up to execute one of the methods described. The system also includes the central bank's coin register and, optionally, a number of coin management units and/or a trade register.

The present solution is particularly advantageous since the high degree of flexibility in the coin depot management unit can be offered independently of the coin register and/or the transaction register. In particular, the coin register, which is already subject to particularly high demands in a digital currency system, is not slowed down.

The invention and further embodiments and advantages of the invention are explained in more detail below with reference to figures, with the figures merely describing exemplary embodiments of the invention. Identical components in the figures are provided with the same reference symbols. The figures are not to be regarded as true to scale; individual elements of the figures may be exaggerated in size or exaggeratedly simplified.

Show it: 1 shows a central bank digital currency system with coin management units and a central bank coin register;

2 shows a coin management unit with an execution unit and a coin data record;

3 shows a digital central bank currency system with a coin depot management unit;

4 shows a coin deposit management unit;

5 shows a flowchart for a method with a transaction request;

6 shows a flow chart for a method with a coin deposit request;

7 shows a flow chart for a method with a request for a conditional transaction;

8 shows an exemplary embodiment for specifications for a coin deposit; and

9 shows an exemplary embodiment of a list with conditional transactions.

1 shows a digital central bank currency system as is already known per se. The subdivision of the system into an output layer 1, a system management layer 2 and a transaction layer 3 is represented by dashed lines.

A central bank entity 10 issues digital coin records 5 . The central bank authority 10 also requests an initial registration of the digital coin data set 5 in a coin register 20 of the central bank. Coin management units 210, 220 can exchange digital coin records and send registration requests to the coin register 20.

Transaction records 7 are stored in an optional transaction register 25 . A transaction data record 7 is, for example, the transaction amount, a transaction ID, identifiers for the sender and receiver, here the coin management unit 210 as the sender and the coin management unit 220 as the Receiver, and include at least the register reference of the transmitted coin data set 5.

The coin register 20 stores at least one register data set 6 for each valid digital coin data set 5. The register data set 6 contains, for example, the amount of the coin data set and a register reference. The register reference can be derived from coin data record 5, but does not allow coin data record 5 to be determined. In Fig. 1, the initial registration request sent by central bank entity 10 contains register data record 6. The figure shows that first coin management unit 210 received digital coin data record 5 received from the central bank authority 10. However, the digital coin data set 5 can also be issued indirectly by the central bank to a user's coin management unit (e.g. via a commercial bank) or have been received from another coin management unit.

The digital coin data record 5 can be transmitted directly from the first coin management unit 210 to the second coin management unit 220 . The second coin management unit 220 can check the validity of the coin data record 5 using the coin register 20 . It can send a validity query to the coin register 20, which contains the register reference that can be derived from the coin data record 5 and optionally the amount. The coin register 20 checks whether the register reference is present and, if necessary, confirms that the coin data set 5 is valid. Alternatively, the coin management unit 220 generates a new coin data set and sends a registration request to the coin register 20, which includes at least the register reference of the previously valid coin data set 5 and a register reference of the new coin data set. In the coin register 20 the registration request is checked. In the simplest case, the register reference of the new coin data set is registered and the previously valid register reference is deleted (or marked as invalid).

If a coin management unit 210, 220 generates a new coin data set with the same amount and registers the new coin data set instead of the previous coin data set, this is also referred to as switching.

However, coin management units 210, 220 can also divide or combine coin data records, ie generate a new coin data record to be registered from several previously valid coin data records or generate several coin data records to be registered from a previous coin data record. The coin register 20 then checks in particular whether the registration request (with the associated multiple previous or new register references) is amount-neutral. WO 2020/212331 A1 describes corresponding examples. However, the present solution is not tied to the masking of the amount of the coin data sets described there or to the specific protocols of WO 2020/212331 A1, as WO 2021/170646 A1 shows, for example.

The approach shown in FIG. 1 is particularly advantageous since neither the coin register 20 nor the transaction register 25 have to include coin data records 5. DE 102020 004 121 A1 describes a trade register and its security in more detail.

2 shows a coin management unit 210 with its typical components. The coin management unit 210 includes an execution unit 211 and at least one coin data record 215. The execution unit 211 is generally designed as software and set up to manage the stored coin data records (send/receive coin data records, send registration requests).

Furthermore, the coin management unit 210 includes an identifier 217 of the coin management unit 210. Identifiers 217 are sometimes also abbreviated as ID in the following, for example as transmitter ID or receiver ID. A cryptographic key 218, possibly an asymmetric key pair, and a certificate 219 of the coin management unit 210 are further data elements of the coin management unit 210. The cryptographic key is preferably used to authenticate the coin management unit 210 and/or to sign data, in particular as part of a transaction. The certificate 219 can relate to the identifier 217 and/or the key 218, generally the public key of a key pair 218, of the coin management unit 210.

In Figures 1 through 4, data items such as a coin record or conditional transaction are represented by rectangular boxes. Functional units, such as the execution unit, are shown with rounded corners. Optional data items or units are usually shown with dashed lines.

A coin management unit comprises at least one digital coin data record and an execution unit for managing coin data records.

3 shows a coin deposit management unit 30 with several

coin management units 31, 310; 31, 320; 31, 330, which is a common Have execution unit 31, and a coin management unit 390 with its own execution unit 391. Coin depot management units include coin depots of different users. There will be a variety of coin management units in the central bank digital currency system. In addition, there can be a plurality of coin deposit management units.

For the sake of completeness, the system administration layer 2 in FIG.

In addition to the execution unit 391, the coin management unit 390 includes at least one coin data record 395, usually several coin data records, and at least two conditional transactions 396a, 396b, 396c with different read and/or write authorizations 397a, 398a, 397b, 398b, 397c, 398c. The differences are indicated in the figure by means of arrows. Two conditional transactions can be configured with the same write permissions and different read permissions, with different write permissions and the same read permissions, or with different read and write permissions. In addition, there can also be conditional transactions--not shown--which have the same write and read rights.

Optional specifications 392, 393 could limit the coin management unit 390 with regard to transactions, just for example: the type of transaction, the transaction amount or the transaction partner. However, as indicated by the three double-headed arrows in both directions, the coin management unit 390 in this example should initially not be restricted either by its reception specification 392 or by its transmission specification 393 with regard to the transaction partner. Compliance with the specifications both when (directly) executing a transaction and when creating a conditional transaction will be described later—with reference to FIGS. 5 and 7 respectively—in more detail. The difference between normal transactions to be executed directly and the stored conditional transactions, which are only executed when their condition is met, can be better recognized using these two figures.

According to read permission 398a, the first conditional transaction 396a may be read by any third party (in particular any coin management unit or any coin depository management unit) and naturally by the user of the coin management unit. This is indicated by three arrows pointing to the right. The second conditional Transaction 396b may only be read by the user and by one or more specified coin management units (or one or more coin depository management units) according to read right 398b. This is indicated by the two arrows pointing to the right. According to read permission 398c, the third conditional transaction 396c may only be read out by the user, so that only an arrow pointing to the right is shown.

The user only has write access 397a to the first conditional transaction 396a.

According to the write permissions 397b and 397c of the second and third conditional transactions 396b and 396c, respectively, no one may modify these conditional transactions. Third parties cannot change any of the three conditional transactions 396a-c.

The coin depot management unit 30 of FIG. 3 has several, here three, coin depots 310, 320 and 330 of different users and an execution unit 31 for managing coin data records 315, 325, 335 of the coin depots 310, 320, 330 of the digital central bank currency system. The coin depot management unit 30 will generally include significantly more than three, for example more than 100, coin depots.

Coin depositories 310, 320, 330 are coin depository records. The coin depots 310, 320, 330 consist of data elements, such as the respective at least one coin data record 315, 325, 335 and other data elements. Each coin depot 310, 320, 330 of FIG. 3 includes at least one coin data set 315, 325, 335. The coin depots 310, 320, 330 can each also include multiple coin data sets. The corresponding reference symbols, such as 315, 325, 335 and 395 in FIG. 3, are intended to indicate one or more coin data records of the coin management unit 31, 310; 31,320; 31, 330 and 390 represent.

No conditional transaction is included in the coin depository 310 . A conditional transaction 316 could optionally be created. Alternatively, however, a specification by the coin depository 310 could also preclude conditional transactions from being able to be stored in the coin depository 310 .

Coin depositories 320, 330 each contain two conditional transactions 326a, 326b and 336a, 336b. The writing and/or reading rights 327a, 328a, 337a, 338a of the first conditional transaction 326a, 336a differ from the writing and/or reading rights 327b, 328b, 337b, 338b of the second conditional transaction 326b, 336b.

For the coin depot 330 with the at least one coin data set 335, the arrows again indicate the right. On the stored conditional transaction 336b has nobody write access - according to write permission 337b. The conditional transaction 336a, on the other hand, can be changed by exactly one authorized person - according to write authorization 337a. This authorized person is usually the user, but can also be the transaction partner. For example, in the case of a receive transaction for the coin repository 330, the sender of the coin records contained in the conditional transaction could have write permission. In this way, a coin management unit that does not support conditional transactions or, like coin repository 310, is not allowed to store conditional transactions by default, could still store a conditional transaction along with a transaction partner.

The second conditional transaction 336b of the coin deposit can only be read by the user - according to read permission 338b. A third party who asks the coin depot management unit 30 about the existing conditional transactions of the coin depot 330 only sees the first conditional transaction 336a. The read rights 338a are chosen so that each coin management unit of the central bank currency system can read the first conditional transaction 336a.

For the coin depository 320 with the at least one coin data set 325, the double arrows on the defaults 322, 323 indicate how the defaults for the coin management units or coin depots in the coin depot management unit 30 can be selected. As shown by the double arrows, reception specifications 322 can differ from transmission specifications 323, for example. The defaults can be defaults of the issuer of the coin depository and/or the user. For example, the specifications can specify the transaction types, functions of the execution unit, receiver, transmitter or amount limits for the coin deposit. The coin depot 320 can, for example, receive coin data sets from each coin management unit as a sender (3 double arrows), but only send coin data sets to selected recipients (2 double arrows), which are contained in the send specification 323, for example with their ID or as a group. The transmission default 323 of the coin depot 320 thus restricts the coin depot 323 to the transmission of coin data records (transmission default) to specific recipients. Thus, the coin repository 320 is unrestricted in terms of transmitters and partially restricted in terms of receivers.

For the sake of legibility, the specifications for the other coin depositories are not shown in FIG. The specifications of the coin depots 310, 320, 330 of the

Coin deposit management unit 30 will differ from each other, although some coin depots can of course contain uniform specifications. The execution unit 31 checks the specification of the respective coin depot 310, 320, 330 before it executes a transaction, i.e. in particular sending a coin data record of the respective coin depot 310, 320, 330 or storing a received coin data record in the coin depot 310, 320, 330. The defaults are also checked before the conditional transaction is saved.

Each coin depository 310, 320, 330 has its own ID, ie the identifier (ID) of the coin management unit, and optionally also includes its keys and/or its certificates. Alternatively or additionally, in particular secret keys and/or certificates can also be provided by the coin depository management unit.

Each of the coin depositories 310, 320 and 330 is associated with a user. However, the assignment of the coin management unit ID to the user name is preferably not stored in the coin depot, but in a coin depot-external data structure (which contains the ID together with the full name of the user, a so-called tuple). The coin depot management unit 30 here includes three coin depots 310, 320, 330 from different users.

It is conceivable that non-restrictive specifications such as specifications 392, 393 and 322 are either explicitly coded (e.g. by: or "all" for any ID) or are omitted (no specification => no restriction).

A send or receive specification must not only include exactly one ID or multiple IDs, but can also include groups of IDs or mixtures of groups and individual IDs. For example, a group of IDs can be specified with an ID mask. The ID mask only specifies parts of an ID that must match, such as "ABC??1311560*". For example, all IDs that have a certain beginning and/or middle part (in the example beginning "ABC" and middle "1311560 ") may be permitted, regardless of the concrete values in other parts (in the example the two characters "??" or a serial number following at the end of the ID) of the respective ID.

In one example, an issuer of coin depositories 310, 320, 330 could provide a user with a coin depository 330 with coin data records 335 and specify the only permitted recipient or a single permitted recipient group in advance in a transmission specification from the issuer. With reference to FIG. 4, the components of the coin deposit management unit 30 shall be considered in more detail. Fig. 4 shows a coin depot management unit 30, a user unit 40, an issuer entity 50 and a further coin management unit 390. The further coin management unit 390 can correspond to the coin management unit 390 from Fig. 3, but alternatively it could also be any other coin management unit, i.e. also a coin management unit of another coin depot management unit.

The coin depot management unit 30 includes coin depots 410, 420, 430 and the execution unit 31. The coin depot data record of the coin depot 430 is shown in more detail, it contains exactly one or more coin data records 435 and optional specifications 432, 433.

The coin depot 330 contains, for example, an identifier 237, at least one key 238 and a certificate 239 (here the certificate of the coin management unit, formed by the coin depot 430 and the execution unit 31 of the coin depot management unit 30) as optional but usually present data elements.

The defaults include publisher defaults 432 and user defaults 433. The publisher defaults 432 are fixed by the issuer of the coin depository. They may already be included in a 402 coin deposit request. The user specifications 433, on the other hand, can be freely selected by the user, at least insofar as they are narrower than a (possibly existing similar) publisher specification 432.

Based on a fully restrictive publisher specification, such as "no sending" or "no receiving", the user no longer has any freedom of choice. Based on an unrestricted (possibly non-existent) functional specification of the publisher, such as "send to all" and/or "receive from all", the user can choose a user specification completely freely. Based on a partially restrictive functional specification of the publisher, such as "send only to ID group 1 or to ID group 2", the user can select a narrower user specification, such as "send only to ID1 from ID group 1 or to ID2 from ID -Group".

The coin deposit management unit 30 may include a coin deposit creation unit 32 which may process a coin deposit request 402 from the issuer unit 50 . The coin deposit management unit 30 can comprise a user default unit 33 which can process a configuration request 403 from the user unit 40 . A user can send the configuration request 403 to the coin depot management unit 30 from his user unit 40, such as a mobile radio device, PC or terminal.

The user defaults unit 33 checks in particular whether the defaults 433 selected by the user and contained in the configuration request 403 for his coin depot 430 are narrower than the existing publisher defaults 432 of the coin depot 430. In this case, the defaults in the configuration Request 403 stored as user defaults 433 in coin repository 430. In the coin deposit management unit 30, the user's default 433 can always be tighter than the issuer's default 432 and include the limitations of the issuer's default 432. It is then sufficient that the execution unit 31 checks the user specification 433 . If the permissible recipients and/or transmitters are specified in the functional specification 432, 433, this variant is preferred. On the other hand, the execution unit 31 can also be set up, preferably for other specifications or codings, to always check both specifications 432, 433. The User Default 433 need not then include the Publisher Default 432 restrictions, if any. Management of the user preference(s) 433 can thus be simplified.

The coin depository 330 can be or have been created as a new coin depository at the request 402 of the issuer unit 50 . The coin depot request 402 contains at least one, usually several, publisher specifications 432 for the new coin depot 330 as a data element. A corresponding method will be described in more detail later with reference to FIG.

The execution unit 31 is set up to exchange the coin data records of the coin depots 410, 420, 430 in transactions 405, 406 with other coin management units from other users of the central bank system and (not shown in Fig. 4) to make registration requests to the coin register 20 (not shown in Fig. 4). to send.

The user can send a transaction request 401 to the coin deposit management unit 30 from his user unit 40 . A corresponding method for processing the transaction request 401 for the case of sending a coin data set, send transaction 405, is described with reference to FIG. The Transaction request 401 is a transaction request from the user's user unit 40, which is recognizable as a request from the user, in particular based on an authentication data element or a previous authentication of the user unit 40. The execution unit 31 checks the specifications 432, 433 before the send transaction 405 is executed (or not) depending on the result of the check. The checking of the defaults in the case of the receipt of coin data records (receive transaction 406) is also described in relation to FIG.

The specifications 432, 433 can be not only directional specifications (sending/receiving), but also, for example, specifications for conditional transactions or specifications for transactions with consideration.

Conditional transactions 436 that differ in their reading rights 438 and/or writing rights 437 are stored in the coin depot 430 or across coin depots. The conditional transactions are saved on request and later - after the condition is met - a transaction corresponding to the saved conditional transaction is executed. A corresponding method is described in more detail with reference to FIG. 7.

The coin deposit management unit 30 comprises a user access unit for conditional transactions 34 and a third-party access unit for conditional transactions 39. The units 34, 39 are shown separately, but can be designed as an access unit for conditional transactions 34, 39 or as sub-units of the execution unit 31 be.

The user can read out one, several or all conditional transactions 436 408. The user unit 40 sends a corresponding read request from the user and the user access unit for conditional transactions 34 checks the access rights 438 of the conditional transactions 436 to be read out. The user can read out a conditional transaction 436 change 409. The user unit 40 sends a corresponding change request from the user and the user access unit for conditional transactions 34 checks the access rights 437 of the conditional transactions 436 to be written (already saved). The user can, for example, read out all conditional transactions 436, however change only certain conditional transactions 436. Third parties, such as the illustrated further coin management unit 390, can also read conditional transactions 409. They can send a read request for one, several or all (readable for them) conditional transactions. The third party access unit 39 checks the read rights 438 of the conditional transactions 436 for the third party. Only the conditional transactions 436 for which the corresponding reading rights 438 are present are read out for the third party. It would be conceivable that all conditional transactions 436 in which the third party is or could be a transaction partner (group information) have corresponding read rights. However, a third party may preferably only read specific conditional transactions 436 from the group of conditional transactions 436 in which he is named as a transaction partner (with his ID) or could be the transaction partner (group specification).

A key management module 38 of the coin depot management unit 30 is preferably a high-security module for cryptographic keys. The key management module 38 can store secret keys of the coin depositories 410,420,430. The key 338 of the coin depot management unit 30 stored in the coin depot 430 is, for example, a public key of an asymmetric key pair. The associated secret key is stored in (and used only in) the key management module 38 . The key management module 38 encrypts, authenticates or signs, for example, data for the execution unit 31 with the secret key of the coin depository. Separate key pairs can be provided for these different purposes. The key management module 38 can also create derived keys, such as session keys, and provide them to the execution unit 31 .

In addition to managing the transaction keys (keys required for the transactions), the key management module 38 can also be used for the encrypted storage of the coin deposit data records.

The data records of the coin depositories 410, 420, 430 (coin depository data records) are preferably stored in encrypted form in the coin depository management unit 30. If necessary, ie for example in the case of a transaction or configuration request for the coin depository 430, the corresponding coin depository 410, 420, 430 is decrypted. In each case, only the required coin depot 430 is decrypted, it being possible in particular for an individual key for the coin depot 430 to be used. For example, the key management module 38 can perform the decryption (and later re-encryption). If the key management module 38 contains a derivation key (optionally common to several coin depositories), it can alternatively provide the derived key for the decryption/encryption of the coin depository 430 to the execution unit 31 . Coin depot management unit 30 checks for the conditional transactions of the coin depots 410, 420, 430 whether the condition contained therein is met. A condition checking unit 37 may be provided in the coin deposit management unit 30 . The condition checking unit 37 checks - in particular continuously, at regular time intervals or in response to an external event, such as a trigger event 404 - whether a condition (such as time, date, limit value exceeded, external event, request received) of the conditional Transaction 436 is fulfilled. Optionally, it can use a checklist 36 in which at least the conditions to be checked for the conditional transactions of the coin depositories 410, 420, 430 of the coin depository management unit 30 are stored. The checklist 36 simplifies the checking of the conditions not only when the coin deposit data is stored in encrypted form. If the condition of a conditional transaction is met, a transaction that matches the conditional transaction is executed.

In order to be able to execute a return transaction, the coin depository management unit 30 includes a return unit (not shown in the figure). The quid pro quo unit generates, for example, response data to be sent in a response as quid pro quo for one (or more) coin data records received in a receive transaction 406 . The quid pro quo unit provides a quid pro quo that can be set in quid pro quo data of the coin depository 430 , for example. As an alternative or in addition, it should be possible to state a consideration in a conditional transaction. The quid pro quo requirements could limit the quid pro quo functions allowed for the coin repository 430 . Based on the quid pro quo functions available in the quid pro quo unit, certain quid pro quo functions, codings or subtypes are selectively excluded for the coin depository 430 .

All aspects described for FIG. 4 that are not specific to the management of coin deposits of different users can also be present in a coin management unit with its own execution unit (only for example the units 34, 36, 37 and 39 or several coin deposits with their own IDs).

Fig. 5 shows the process flow 501 to 518 in the coin deposit management unit 30 after receiving a transaction request 501 from a user (or his user unit 40) and the process flow 551 to 568 when receiving coin data records from a coin management unit 390. The transaction request 501 includes an ID of a coin depository 430 in the coin depository management unit 30 and requests an amount to be sent from this sender ID to a receiver ID. In step 502, the secure execution unit 31 of the coin depository management unit 30 reads the coin depository record of the coin depository 430 with the sender ID. The key management module 38 preferably provides the execution unit 31 with either the decryption key that is selected individually for the coin depository 430 based on the ID, or the already decrypted coin depository data record. In steps 503, 504, 506 the execution unit 31 performs several checks before executing the requested transaction in steps 507-516. Figure 5 shows the preferred order of testing steps. First, an authentication is checked 503, usually the authentication of the user. A corresponding authentication value can be included in the transaction request 501 or requested and received separately in step 503 .

At least one (of) default(s) 432, 433 of the coin depository 430 with the ID is checked in step 504. In the present example of a simple send transaction, it is checked whether the recipient ID is an ID according to the send specifications in the publisher and/or user specifications 432, 433. If the coin depository 330 is unrestricted in the receiving direction according to the issuer's specification 432, or if the issuer's specification 432 is fulfilled in the receiving direction, the user specification 433, which comprises, for example, an ID group and two IDs of recipients, is checked. If the recipient ID of the transaction request does not correspond to the specifications 432, 433, the transaction request 501 is rejected, the user 40 receives a rejection message 505. If the recipient ID, on the other hand, is permissible because it is an ID from the ID group or one of the two IDs of recipients in the user preference 334a, the method continues (and the transaction is executed). In step 506 it is checked whether the depot amount, amount of the coin data record 435 in the coin depot 430 or sum of the amounts of the coin data records 435 in the coin depot 430 is greater than the requested amount.

In transactions, the coin deposit management unit 30 preferably sends exactly one coin data record, the amount of which corresponds to the transaction amount, instead of sending the transaction amount as the sum of amounts of a plurality of coin data records. If the requested amount corresponds to the amount of a coin data set present in the coin depot, the next steps 507 to 509 are omitted. In step 507 a new coin data set is created, the amount of which corresponds to the requested amount. An existing coin data set is preferably divided into the new one Coin data set and another coin data set (amount = difference between the amount of the existing coin data set and the transaction amount). Alternatively, two or more existing coin records could be merged into the new coin record (and optionally one or more other coin records). A registration request 508 is sent to the coin register 20 for the new coin record (or its register reference). The coin register 20 confirms 509 the registration.

In step 510, the execution unit 31 now creates a transaction message 511, which is sent to the coin management unit 220 with the recipient ID, in particular of another user of the central bank system. The transaction message 511 includes a transaction ID, the ID of the coin depository 430, the ID of the other coin management unit 220 as the recipient ID, and the new coin data set. Optionally, the transaction message 511 contains a transaction reference text, which usually comes from the transaction request 501, and/or an authentication value that is generated for the transaction using the secret key of the coin depository 430. A mutual authentication of the two coin management units (430, 31; 220) involved is preferably carried out in the transaction, in particular in step 511. The step 510 of creating and sending the transaction message 511 can optionally or alternatively take place in a number of partial steps with a plurality of partial messages exchanged (just for example for authentication).

The other coin management unit 220 optionally generates its own coin data set, which in particular has the same amount as the new coin data set received, sends a registration request 512 for its own coin data set to the coin register 20 and then receives a registration confirmation 513 from the coin register 20. The coin management unit 210 sends a transaction confirmation 514 to the coin depot management unit 30.

In step 515, ie preferably only after receipt of the transaction confirmation 514, the execution unit 31 saves the changed coin depository data of the coin depository 430. Coin depot-specific encryption of the coin depot data can take place, as previously described—again optionally with the aid of the key management module 38 . A transaction confirmation 516 can be sent to the user 40 . In preferred variants, a trade register data record 518 is created in step 517 and sent to the trade register 25 .

A JSON format is preferably used for the transaction request 501 and/or the transaction message 511 . A first, uniform format, in particular the JSON format, is preferably used for messages within the transaction layer 3 . However, it should be noted that the contents of the transaction request 501 and/or the transaction message 511 can also be transmitted separately from one another. For example, an authentication value can only be transmitted in step 503 or a recipient ID only in step 504 and/or authentication of the coin management unit 220 (or mutual authentication) can be carried out before a coin data set is exchanged.

The second sequence shown in FIG. 5 is triggered by the receipt of a transaction message 551 or receive transaction from a coin management unit 390 . The transaction message 551 contains at least one ID of a coin deposit in the coin deposit management unit 30 and at least one coin data record. The coin management unit 390 therefore wants to send a coin data record to the coin depository. However, the secure execution unit 31 again checks whether the transaction corresponds to the specifications of the coin depository.

First, the coin vault data of the coin vault with the specified ID is read 552. Reading 552 the coin vault data will, as before, involve decryption. Optionally, authentication of the coin management unit 390 is checked or mutual authentication is performed. The secure execution unit 31 now checks 554 the specifications of the coin depository. For example, if the coin depository is fully restricted from receiving, the transaction message 551 will be rejected. In the example, however, receiving is partially restricted for the coin depot by a transmitter specification from the issuer. The secure execution unit 31 thus checks whether the ID of the coin management unit 390 satisfies the issuer's sender specification for the coin depot. In the negative case, the transaction is rejected, in the positive case, the transaction is executed. Preferably, the secure execution unit 31 generates its own coin record using the received coin record. It can generate its own coin data set of the same amount 557 and, by means of a registration request 558 and a registration confirmation 559, register it with the coin register. The coin deposit data of the coin depot are stored (encrypted) 565 and a transaction confirmation 566 is sent to the coin management unit 390 . Optionally, a recipient of coin records in the central bank digital currency system may also be required to generate 567 and send 568 a trade register record to the trade register 25.

6 shows the course of a method for creating a new coin depot.

An issuer 50 of the new coin vault sends a coin vault request 601 to the coin vault management unit 30. The coin vault making unit 32 of the coin vault management unit 30 processes the coin vault request 601 and creates the new coin vault. First, the authentication of the issuer is checked 602. If the authentication fails, for example because the requester is not an issuer but a user, the request is rejected (or no new coin depot is created). The coin depository management unit 30 includes a plurality of coin depositories assigned to different users. The coin depots include different specifications, in particular different functional specifications. The large number of coin depots has been created by a large number of publishers. The number M of coin deposits is of the order of magnitude of a number B of users (M=a*B, for example with 1<a<9 for 1 to 9 coin deposits per user). The number of coin depots M is orders of magnitude greater than the number H of issuers: M >> H (for example: M=b*H with b>50, preferably>100).

In step 603, a coin vault record is created for the new coin vault. The data elements of the created coin deposit data record are initially empty and/or assigned a default value. In the step of creating 603 the coin depot data record, the individual encryption key for the coin depot can be provided, in particular by the key management module 38. The data elements, such as specifications and coin data records, or in particular also identifier, key and/or certificate, are now in further steps 604 - 608 provided or taken from the coin deposit request 601.

One (or more) issuer default(s) included in the coin deposit request 601 are stored as issuer default(s) in the coin deposit record. First, an identifier for the new coin depository is generated 604 in the coin depository management unit 30 . The new coin depository together with the secure execution unit 31 forms a new coin management unit. Identifiers are associated with coin management units in the system. The identifier is designed in particular as a URI, Unified Resource Identifier, or URN, Unified Resource Name, (uniform resource name) and contains a system-wide unique ID (UUID). For example, an identifier as a URN has the following format: "münzverwaltungeinheit:meine-münzdepot-bank.com:UUID". A UUID can be used as an identifier or as part of a URN. The UUID is encoded according to RFC 4122. It accordingly comprises a halfbyte M , which specifies a version of the UUID, and a halfbyte N, which specifies a variant of the UUID. Now further bits of the UUID are used to at least partially encode a functional specification. Bits of the halfbytes S and/or V can be used, for example : "xxxxxxxx-xxxx-Mxxx-Nxxx-SVxxxxxxxxxx", which would otherwise be assigned random numbers. A first bit of the UUID encodes that the coin depot is in a coin depot management unit. A second bit of the UUID encodes whether there is a direction-related functional specification ("0": no directional specification, "1": "directional specification"). A third bit of the UUID encodes whether conditional transactions are permitted ("0" : "no conditional transactions" or "1: conditional transactions allowed"). A fourth bit of the UUID could optionally encode whether a consideration is permissible (“0”: no consideration permissible, “1” consideration permissible). For conventional coin management units, the 3 bits of the UUID could thus be set to "000".

For the new coin depository, according to coin depository requirement 601, sending should be restricted to two different groups of recipients, a named variant of conditional transactions that can include a consideration. The three bits of the UUID are therefore set to "111" for the new coin depository. As expected, for the majority of coin depositories in the coin depository management unit 30 there will only be one (or more) direction specification, but conditional transactions or consideration will be prohibited. For most Coin depots would therefore, in their URN or UUID, encode the three bits with "100".

In a further step, at least one key for the coin depot is provided or generated. A key pair comprising a public key and a secret key is generated, preferably by the key management module. The secret key can optionally remain in the key management module. Alternatively, it is stored in encrypted form in the (possibly additionally encrypted) coin depot. The public key is stored in the coin depository. The key or the pair of keys preferably serves to authenticate the new coin management unit.

In a further step 606, a certificate for the coin deposit is created. The certificate includes at least the ID and/or the public key of the coin depository. Certificates confirm the authenticity of the contained data elements for third parties. Like the ID or the public key, the certificate is a (public) data element of the coin depository data set that is intended to be passed on to third parties, such as other coin management units. The functional requirements for consideration are therefore not included in the certificate. The exact restrictions in the sending and receiving direction, i.e. the two permissible groups of recipients in this case, are also treated as internal information. However, the certificate contains a (further) part of the functional specifications. For example, the certificate contains the information that the coin depot is unrestricted in the receiving direction ("no sender specification") and partially restricted in the sending direction.

Optionally, the secure execution unit 31 receives 607 one or more coin records for the new coin repository. As previously described, the secure execution unit will generate 608 its own (or several) coin data set(s) for the coin data set(s) received. It sends a registration request to the coin register 609 and receives an acknowledgment 610 for the registration of the own coin data record(s) in the coin register 20. Normally, own coin data records of the same amount are generated and registered (switching). What is not shown in the figures is that a transaction register data record is preferably transmitted to the transaction register 25 in turn.

In step 611, the coin depot data set, in particular including the aforementioned generated data elements, the externally provided data elements and optionally at least one coin data set, is stored. It is preferably stored individually encrypted. The encryption can relate to the entire coin deposit data set or to individual data elements (Dl, D2, D3) (e.g.: "encrypt(Dl,D2,D3 ...)" or "encrypt(Dl), encrypt(D2), encrypt( D3) ...").

The coin deposit creation unit 32 may send a coin deposit confirmation 612 to the issuer 50 after the creation of the new coin deposit. A step 614 of registering the new coin deposit for a user can occur at different times. The assignment between a unique user name, possibly including "first name, last name, date of birth and/or address" or "tax number with or without 'first name, last name'" of the user and the coin depot, i.e. the ID of the coin depot, is usually made in a external data structure stored. If the user has already been named in the coin deposit request 601, the allocation or registration 614 can take place as soon as the ID of the coin deposit is fixed (in the example: from step 604).

The registration 614 in FIG. 6 is triggered with a separate assignment request 613, which relates to at least one coin depot that has already been created and has not yet been assigned to a user. The issuer 50 could thus have a plurality of new coin depositories created (steps 601 to 612) and only assign them to a user (steps 613, 614) as required (at a later point in time and possibly individually). It is conceivable to request the assignment for several coin depots at the same time. The association request 613 can be sent by the publisher. As a rule, the user is then informed that a new coin depot has been created for him (e.g. including the ID or access data). Alternatively, the user or a third party can send the association request 613 . The publisher provides the user with an authorization code (e.g. in an email and/or as a barcode). The user or a third party who first verifies the user's identity (e.g. using the Postident or Video Ident method) then sends the authorization code with or in the assignment request 613.

Preferably, the coin depot at the time of registration 614 does not yet include any coin data sets. All transactions in the system can thus be assigned to users--for example starting from the transaction register 25.

It is now apparent that the aspects or features described for individual figures can also be used individually or together in other figures. The new coin depot according to FIG. 6 can be a coin depot according to one of FIGS. 2 to 9, for example. To avoid repetition, not all details of each figure are repeated or all alternatives are given for details. Key management, communication with the coin and transaction register, and in particular the specifications that can be combined in different ways are just a few relevant examples. 7 shows the flow of a method when a conditional transaction is requested. The request for a conditional transaction 701 from user 40 initially triggers almost the same steps 702, 703, 706, 707, 708 as a normal transaction to be executed immediately with steps 502, 503, 506, 507, 508 in Fig. 5. Since a send transaction is also considered as a conditional transaction in FIG. 7, as in FIG. 5, the subsequent steps 750 to 758 correspond to the known steps 510 to 518, respectively. Steps that have already been described will only be briefly discussed.

The reading of the coin deposit data 702 of the coin deposit specified in the transaction request 701 with its ID and the checking of the user authentication 703 of the user 40 take place, for example, as described in relation to FIG. 5 .

Similarly, a rejection 705 of the request 701 takes place if it is determined during the check 704 of the functional specification(s) of the coin deposit that the transaction is not permitted for the coin deposit. In the checking step 704, a specification for conditional transactions is now (at least also) checked as a functional specification. For example, if the coin deposit were restricted to a different type of conditional transaction and/or different conditions, the request would be denied. In addition to the functional specification, a direction specification and/or an amount specification, for example, can optionally be checked, in the present example of a send transaction the specification for the transmission direction and any amount limit for the transmission that may be present.

The further steps of checking the deposit amount 706 and creating 707 and registering a coin data record 708, 709 for the transaction could again be carried out analogously to FIG.

A conditional transaction is first saved 710. The associated transaction is therefore not yet executed, but only executed later when the condition contained in the transaction is fulfilled. The conditional transaction includes the condition to be checked and data elements of the later transaction. As illustrated in FIG. 4 , the storage may be in a conditional transaction memory 436 of the coin vault 430 or in a conditional transaction memory 36 across coin vaults. In a variant, only the condition together with a reference to the conditional transaction is stored in the memory 36 as a checklist. It should be noted that the flow shown, first check 703 to 705 then Caching 710 ensures that the later transaction for the conditional transaction can actually be executed once the condition is met.

In an optional step 711, the secure execution unit 31 saves the coin deposit record, particularly if the coin deposit data has changed. Again, storing 711 or storing 710 may include encrypting the coin deposit data as previously described. For example, the coin depository data has changed when the coin depository memory 436 is used. Likewise, with optional steps 707 through 709, a coin record for the conditional transaction may already have been generated. The coin record for the conditional transaction may be stored in the coin depository's coin records. It is preferably marked there as a coin data set reserved or blocked for the conditional transaction. In an alternative, the coin record for the conditional transaction could be cached in the conditional transaction itself, particularly if the coin vault memory 436 is used. In a further alternative, the coin record for the conditional transaction is only created after the buffering 710 . There are various options for ensuring that the later transaction can be executed for the stored conditional transaction. The transaction amount may be deducted from the available deposit amount (for deposit amount checking steps such as step 706 or 506). If the available deposit amount is provided as a separate data element of the coin deposit, it will be reduced. An amount reserved for conditional transactions could also be provided as a data element of the coin deposit record. Another option that saves storage space would be to not only take into account the available coin data sets in steps of checking 506, 706 the deposit amount, but also to read out the temporarily stored conditional transactions of the coin deposit.

The three points after step 711 and after step 734 in FIG. 7 indicate that the further steps 721 to 758 or 741 to 758 only follow at a later point in time. Processing of transaction request 701 for a conditional transaction is complete.

A transaction that corresponds to the conditional transaction is executed only if and/or only when the condition is met. Shown in FIG. 7 is a step of checking the condition 742, which is carried out, for example, at regular time intervals or in response to the receipt of a checking trigger 741 is executed. Optionally, the condition checking unit 37 of the coin deposit management unit 30 carries out the check.

The saved conditional transaction can now be read or written 721-725, 731-735 by third parties or by the user according to their write and/or read rights.

In the example of FIG. 7, another coin management unit 390, which is preferably assigned to another user, sends a read request 721 for a coin deposit. The read request can be aimed at reading out

- Exactly one conditional transaction from the coin depository, which is indicated by its transaction number or a reference number,

- A selection of conditional transactions of the coin depot, which, for example, meet a specific criterion such as transaction type or transaction partner, or

- all conditional transactions of the coin deposit.

The coin depot data are read 722 and optionally the authentication of the requesting coin management unit 390 is checked 723. After checking the reading rights 724, the conditional transaction(s) is/are made available 725 to the coin management unit 390 (read). If necessary, several conditional transactions are read, with only the conditional transactions for which the reading rights are present being read from the conditional transactions of the coin depot, in total or according to the requested selection. In principle, an external write request could proceed in the same way, especially if the request includes authentication of the user in addition to authentication of the third party. In the example of FIG. 7, the user sends a write or read request 731 for his coin deposit to the coin deposit management unit 30 from his user unit 40. A write request is directed to exactly one conditional transaction. The read request can in turn relate to exactly one conditional transaction, a selection of the conditional transactions or all conditional transactions. The coin depot data are read 732 in the coin depot management unit 30, including the necessary decryption steps if necessary, and the authentication of the user is checked 733. The write and/or read rights are then checked 734. Depending on the existence of the read and/or write rights, the conditional Transaction written (changed or deleted) or the conditional transaction(s) sent 735 to the user unit 40 (and thus read out). The conditional transaction may include a time condition, for example. The send transaction is only to be executed on a specific date or at a specific time (e.g. after 36 hours or from 11:00 p.m. or on a specific day of the week).

A possibly unsuccessful check of the condition 742 can already have been carried out before the read and/or write requests 721, 731.

There are conditional transactions for which a transaction is executed only once, for example at a point in time (with date and time) or a trigger that is included in the condition. For other conditional transactions, a corresponding transaction can be executed multiple times. For example, if a conditional transaction includes an offer for a consideration transaction addressed to coin management units of a particular group, read permission may be granted for that group, for example. Irrespective of whether the coin management units first know the conditional transaction by reading out the conditional transaction or otherwise, different coin management units of the group could successively accept the offer, for example by sending a coin data record with the requested amount and receive the consideration. For example, the coin depot can send a digital entry ticket for an event to the coin management unit in return.

The conditional transaction may include collateral value. The transaction is executed only or only if the security value is provided to the secure execution unit. The security value can be a random number or a cryptographic security value, which is derived in particular from the data of the conditional transaction (such as a hash value or a signature, over a part of the conditional transaction or the conditional transaction, respectively). In particular, the security value may be received as or in the test trigger 712 .

The conditional transaction may include an external trigger event. The occurrence of the external trigger event is preferably received in or with the check trigger 712 (from a third party or the transaction partner). The content of the data received with the test trigger 712 is then checked. Alternatively, the secure execution unit can check whether the triggering event has occurred, for example by querying an external server or an external data structure (such as a blockchain or database). The conditional transaction may also include a time limit (executed before a time or date). The condition, such as security value or external event, must therefore be met before the time limit is reached. After the time limit has been reached, the conditional transaction will no longer be executed. A cached conditional transaction is deleted after its time limit expires.

A conditional transaction is optionally executed exactly once or more than once. The number of executions of the conditional transaction may be specified in the conditional transaction.

For example, a constraint for conditional transactions may specify an allowable type or types of condition, such as time condition, collateral value, and/or external event. Alternatively or additionally, a conditional transaction specification may include a type of conditional transaction that is allowed for the coin repository. For example, the policy may indicate whether a conditional send transaction is allowed, possibly unrestricted or partially restricted according to a general send policy or according to a separate send policy for conditional transactions. Similarly, the policy may specify whether a conditional receive transaction, a conditional return transaction, or a conditional transaction according to a specific scheme (standard 1 or proprietary 2) is allowed. Such specifications for conditional transactions can be specified in advance for the coin depository by the issuer and/or selected by the user. As already mentioned, they functionally limit the coin depot to specific functions from the available functions that the secure execution unit provides.

The further steps of creating 720 the transaction (message), exchanging at least one coin data set 721 to 724, writing 725 the coin deposit data, confirming the transaction 726 and registering the transaction in the transaction register 727, 728 have already been described in relation to FIG .

Just as a coin deposit may include multiple direction specifications and amount specifications, the coin deposit may alternatively or additionally also include a plurality of specifications for conditional transactions (such as issuer and/or user specifications for the various types and/or directions). It is not shown separately in FIG. 7 that a conditional transaction is automatically deleted. For example, if the conditional transaction has reached its execution limit (such as number of executions or period of time that can be executed) or has become unfulfillable, it is discarded. It can therefore be deleted by the execution unit 31 (and/or the checking unit 37), in particular when one (or more) corresponding transaction(s) is/has been executed, when the condition can no longer be fulfilled or after expiry of a limitation period.

It should be noted that the method according to FIG. 7 would run analogously if the roles of the coin management units 31, 410 and 390 involved were reversed. The conditional transactions can therefore be stored in the coin management unit 390 and read out or written by another coin management unit, possibly another coin depot management unit 30 . Few steps, like reading the coin deposit data, simplify (no decryption) .

Various aspects of the defaults are described using the example of FIG.

Several specifications 811-828 are shown as data elements and two coin data records are shown in symbolically simplified form in the coin data records 805 (amount 13 or 23 with "dW" as digital currency units of the central bank currency).

The coin depot or the coin management unit includes, on the one hand, publisher specifications 810 and user specifications 820. On the other hand, it includes both receipt specifications 811-814; 821-823 as well as sending preferences 816-819; 826-828. Based on the illustration in FIG. 3, in FIG. 8 the reception specifications are arranged to the left of the coin data records 805 and the transmission specifications to the right of them.

Finally, for functional specifications, a distinction is made between directional specifications 821, 811, 816, 826, specifications for conditional transactions 822, 812, 817, 827 and specifications for transactions with consideration 814, 819. The coin deposit or the coin management unit also includes amount specifications 813, 838 , 828. The issuer specified the issuer specifications 810 in advance at the time the coin depot or the coin management unit was created. User Defaults 820 are user-chosen, but narrower than peer Publisher Defaults 810 (if any).

The publisher is a business owner. He restricts the coin depot or coin management unit created by him for the user, therefore in the transmission specification 816 to his business "The business". In practice, the transmission specification 816 therefore contains the ID(s) of the coin management unit(s) of the business and not a plain text name, as shown in the figure. The user can thus only send coin data records from the coin depot or coin management unit created by the issuer to the specified business. The user must not further restrict this specification, which is why he is not offered a transmission default of the user 826. This is indicated by a box with a dotted border in Fig. 8. In the receiving direction, the issuer has provided in its receipt default 811 that coin data records may be received from the shop or from the user. The user can (optionally and therefore represented by dashed lines) select a stricter reception specification of the user 821. In the example, the user has l did not select a reception preference, but could have selected a restriction of, for example, "The Shop" or "None".

As can be seen in the issuer's policy on conditional transactions 812, 817, the issuer has not separately restricted the user's coin depository or coin management unit with regard to conditional transactions. However, its send and receive specifications 811, 816 are also valid for conditional transactions. The user has chosen not to allow conditional receive transactions, as reflected in the user preference 822 for the receive direction of conditional transactions ("inactive"). Furthermore, the user does not want to allow any conditional send transactions, only those useful to him Allow constraint type, the time constraint he wants to use for the deal. He selected "time constraint" in his user preference 827.

In addition, the issuer has specified fixed amounts 813, 818 for the coin depot or the coin management unit. The coin depot or the coin management unit may receive a maximum of 50 digital currency units in one transaction according to issuer specification 813 and send a maximum of 200 digital currency units in one transaction according to issuer specification 818. A further limit on the amount is not offered to the user in the receive direction (dotted box) for user default 823. In the send direction, the user has selected 50 digital currency units for his coin deposit in default 828 as the maximum send amount.

Finally, the issuer has ruled out the existing option to conduct transactions with consideration with the coin depot. The issuer policy for transactions with consideration 814, 819 is a full constraint ("inactive").

Issuer Data 809 may include, for example, a coin deposit expiration time (validity limit). Other data elements of a coin deposit already mentioned are not shown, but can of course be present, such as the other data elements 237-239, 396a-c-398a-c or 436-438 from FIGS. 3 and 4.

With these specifications, the user can now, for example, create two conditional transactions that differ in terms of write and read rights. A first conditional transaction is readable and writable only by the user. A coin data record with the amount 3 dW is to be sent from the coin depot to the recipient "the shop" with the condition "every Sunday morning every week". The conditional transaction contains "Supply 3 units" as the transaction text for the later transaction. However, the conditional transaction does not yet contain a coin record. This conditional transaction cannot be read by the store's coin management unit. A second conditional transaction is scheduled for a specific point in time and already contains one higher value coin record to be sent to the store, for example with the amount of 100 dW.The second conditional transaction is a guaranteed conditional transaction.The user and the store have read permission for the conditional transaction, but write permission is not granted, so that the Execution of the associated transaction is guaranteed at the specified time Depending on the implementation details of the transaction, the coin data record cannot be used anyway without additional information or a secret data element of the coin data record is secured, for example only when the transaction is executed action decrypted. The shop's coin management unit can read the conditional transaction and thereby knows that and when it will receive the coin record. He can now, for example, order higher-value goods for the user. Conditional transactions, selectively read-write and/or read-only, with or without defaults, provide a very flexible way to accommodate a surprisingly wide variety of transaction types.

Various conditional transactions and their data elements are to be described again in more detail with reference to FIG.

9 shows various conditional transactions, represented as line entries in a list, which can be distinguished using the transaction number 931. The conditional transaction base data 91 includes sender 911 , recipient 912 , and amount 931 . The conditional transaction condition 92 includes a test criterion 921 , an execution limit 922 , and optionally the type 923 of the conditional transaction. The execution limit 922 may include an execution count and/or a time specification (such as “only once” and/or “only until 03/03/2021 9:00 am”). The different reading and/or writing rights 96 are shown in abbreviated form in column 96. The extension data 93 includes data elements that are optional and/or are only generated when the transaction is executed. For reference 931, the transaction numbers T-1 through T-2 are the actual transaction numbers of the transaction executed later. On the other hand, the transaction numbers R-1 to R-4 are temporary references for the conditional transactions. Coin records 932 contain only the first two conditional transactions. A transaction reference text 933 may be provided.

The ID of the user's coin management unit is ID1. The first conditional transaction with transaction number T-1 already generated is a guaranteed conditional transaction. The already prepared coin data record CI with the amount 913 '100' is sent from the sender 911 with ID1 to the receiver 921 with ID2 in one transaction as soon as the check criterion 921 'date' is met (ie on a specific day). Execution count 922 is one (one time execution) and type A, which in the example is meant to be guaranteed conditional transaction. Correspondingly, according to the write and/or read rights T, the user has no write rights, but both transaction partners 911, 912 have read rights. The transaction reference text 933 contains information 'A789' which allows the transaction partners to be assigned, for example to an invoice.

For guaranteed conditional transactions, the user has no write permission, but the read and/or write permissions of third parties may differ. For example, the fourth conditional transaction with reference number R2 is another guaranteed one conditional transaction (type A). If, as condition 921, the total amount of coin records in the user's coin management unit exceeds a 'threshold', a coin record with the amount 931 of '10' is sent from the user's coin management unit to the recipient 912, the coin management unit with ID4. The fourth conditional transaction executes an unlimited number of times since no execution limit 922 is included. According to the write and/or read rights 96, IIT, the user does not have write rights, but the coin management unit with ID4 does (both have read rights). Different conditional transactions of a type of conditional transaction can have the same write and/or read rights 96, but their write and/or read rights 96 can also differ, as just shown.

The second conditional transaction referenced R-2 also already contains a coin record 932 'C2'. However, the condition is an external event, such as receiving a secret security value, such as a signature or password for the conditional transaction. When the user's coin management unit receives the backup value, the coin record is sent to receiver 912 'ID3' in a send transaction. The second conditional transaction may be referred to as a callable conditional transaction. Accordingly, 'B' is entered as type 923. It can only be called up once - in this example - according to the number of executions 922. The read and/or write rights 96,IT indicate that only the two transaction partners have read rights and the user has write rights.

The fifth line also shows a callable conditional transaction (type B). Retrievable conditional transactions contain a reference, i.e. in particular a transaction number or (temporary) reference number, in order to be clearly retrievable. The conditional transaction with the reference number R-3 can be called up three times according to column 922, can be called up according to column 912 by all coin management units of group Gl and can be sent to the current coin management unit with ID1, i.e. without knowledge of the security value, on request of a coin management unit of group Gl. be retrieved. The second and the fifth conditional transaction have the same write and/or read rights 96. In a variant that is not shown separately, a conditional transaction that can be called up can be called up for a specific recipient—once, several times, or indefinitely—by means of a transaction request. Write and/or read rights 96 ,IT are also useful for this variant. The third conditional transaction with reference 931 'RT' is a periodic conditional transaction (type 923 'C'). It is carried out periodically, with the period 'time', for example daily, weekly or every 2 hours, which is specified in the test criterion condition 921. In this conditional transaction, the user's coin management unit is the recipient 912. It therefore periodically receives one (or more) coin data records with the specified amount 913 from the coin management unit ID4 as the sender 911. The third and fourth conditional transactions have the same writing and/or or read rights 96, the coin management unit ID4 can write these conditional transactions. It should be noted that the two conditional transactions are coordinated, the third conditional transaction periodically requests the sending of coin records from ID4 to ID1 and the fourth conditional transaction sends coin records back again when the mentioned threshold is exceeded - and as long as this condition is met.

The conditional transactions of a type such as periodic conditional transactions can be receive or send transactions. The fourth conditional transaction could also be designed as a send transaction.

The sixth transaction with (optional) reference number R-4 is a conditional consideration transaction (type 923 'D'). The condition 921 is the receipt of a receive transaction (recipient 912 'IDT) with the amount 912 '40' as an event. The transmitter 911 must belong to group G2. The consideration GL can be described in the transaction reference text 933 . For example, the sender receives an access ticket for an event, for example as a QR code, sent to his e-mail address that is specified in the transaction reference text of the receipt transaction. Since the event in the example takes place on Tuesday, the sixth conditional transaction includes an execution time limit 922, it is limited to 'Mo' (Monday). The writing and/or reading rights 96 can be selected differently, in the example with 'IV' only the user should have reading and writing rights. The sender would have to be informed about the existence of the conditional transaction by other means, for example via e-mail/SMS/Broadcast... If, on the other hand, one selects write and read rights 96, which also enable the coin management units of group G2 to read, the separate information can be omitted.

Without reference to Figure 9 further options for conditional transactions shall be described for a coin management unit which offers a consideration. The consideration could be provided in digital form, in many Use cases, the consideration is provided locally and should also be possible offline (without a network connection). The consideration can be, for example, access to an area (such as a stadium, zoo or museum), provision of electricity or operation of a machine (such as a washing machine or car wash). The coin management unit of the user who provides the service in return is preferably a local coin management unit with its own execution unit, which is arranged at the location of the service in return, in particular it is a reversible or built-in security module.

The user's (return-provider's) coin management entity may comprise different conditional return transactions with mutually different (and optionally the same) write and/or read rights.

A contingent consideration transaction can be a guaranteed contingent transaction (that is, which the user cannot change). The guaranteed conditional consideration transaction is written, for example, when the coin management unit is manufactured and is no longer writable, but can be read by anyone. In the case of a receipt transaction with the amount X, the sender always receives a consideration of the type Y and/or the duration Z, for example electricity or operation of the washing machine for 30 minutes each.

Another contingent consideration transaction may be temporarily callable. It contains a time limit on executability. This conditional transaction is readable by everyone and writable by the user. In the example, the same consideration is offered in a period (like 'today') for a lower amount (like amount: 'X - 10%').

Another conditional consideration transaction with a reduced amount (such as Amount: X-5%) or enhanced consideration (Duration: Z*1,2) may require receipt of a code value specified in the condition or transaction header. This conditional consideration transaction is unreadable by third parties (and writable and readable by the user). The third party does not learn the code word by reading the conditional transaction. For example, he could get the code value in the newspaper, an app, on the Internet or in other ways. Then the third party sends the code value, in particular together with the coin record (e.g. in the transaction header) to the user's coin management unit. The condition of the contingent transaction is met and the consideration is provided. Another conditional consideration transaction can only be readable for a specific group. The consideration is only for members of this group, such as regular customers or company members, for the reduced amount or with the improved consideration (such as longer duration or higher intensity of the consideration, e.g

amperage at the charging station) and can therefore be called up, for example, via the reference number or with a code value that has been read along.

The coin management unit may comprise a periodic conditional transaction which sends the (in particular all) received coin records, for example once a day, to a user's collective coin management unit. Several of the user's coin management units may be set up to send periodically to the collective coin management unit. If the coin management unit does not have its own Internet connection, the received coin data sets are only registered in the coin register at a later point in time and/or transmitted to the user's collective coin management unit.

The coding of specifications 811-828 in Fig. 8 and the data elements of the conditional transaction in Fig. 9 is partly shown as text in the figure for better readability, but can be of any length and coding (one or more bits, one or more bytes , byte sequences ... or numeric, hexadecimal, binary, string ... encoded). A coding of the data elements of the coin deposit or the conditional transaction as a TLV structure (tag, length, value) is just as conceivable as a coding of the transactions, the conditional transactions or the coin deposit in a JSON format. Within the scope of the invention, all the elements described and/or drawn and/or claimed can be combined with one another as desired.

REFERENCE LIST

1 output layer

2 Systems Management Layer

3 transaction layer

5 coin record

6 register record

7 transaction record

10 Central Banking Authority

20 coin registers

25 trade repository

210, 220 coin management unit

211 execution unit

215 Coin Depot

217 Identifier of the coin management unit

218 Cryptographic key

219 Coin Management Unit Certificate

30 coin deposit management unit

31, 391 execution unit

310, 320, 330 coin deposit

315, 325, 335, 395 coin record

316 conditional transaction

322, 392 Receive Default

323, 393 send preference

326a, 336a, 396a first conditional transaction 326b, 336b, 396b second conditional transaction 326c, 336c, 396c third conditional transaction 327a, 337a, 397a first read rights 327b, 337b, 397b second read rights

397c third read rights

328a, 338a, 398a first write permissions 328b, 338b, 398b second write permissions 398c third write permissions

32 Coin Depository Creation Unit

33 User Default Unit 34 User Access Unit for Conditional Transactions

36 Checklist of conditional transactions

37 condition check unit

38 key management module

39 Third party access unit for conditional transactions

40 user unit

50 publisher unit

237 identifier

238 keys

239 certificate

401 transaction request

402 coin deposit request

403 configuration request

404 trigger event

405 send transaction

406 receive transaction

407 write conditional transaction

408, 409 read conditional transactions

410, 420, 430 coin depositories

432, 433 defaults

435 coin record

436 conditional transaction

437 writable transaction

438 read-only conditional transaction

501 transaction request

502 Reading of the coin depository data

503 Verification of user authentication

504 Checking the default

505 Rejection of the request

506 Checking the deposit amount

507 Creating and registering a coin record

508. 512 Registration Request

509. 513 Registration Confirmation

510 Creating the transaction

511 Send transaction

514, 516 transaction confirmation

515 Writing the coin depository data 517 Creating the transaction register record

518 transaction data registration

551 transaction request

552 Reading of coin deposit data

554 Checking the functional default

557 Switching a coin data set

558 Registration Request

559 registration confirmation

565 writing of the coin depository data

566 transaction confirmation

567 Creating the transaction register record

568 transaction data registration

601 Coin Deposit Request

602 Verifying publisher authentication

603 Creation of the new coin depository

604 Generating an identifier

605 Generate a key

606 Creating a Certificate

607 Receiving a coin record

608 Creating a switching request

609 Switch request

610 Switch Confirmation

611 Writing the coin depository data

612 coin deposit confirmation

613 Association Request

614 Registering the coin deposit for users

701 Request for a conditional transaction

702, 722, 732 Read the coin deposit data

703, 723, 733 Check authentication

704 Functional constraint check

705 Rejection of request

706 Checking the deposit amount

707 Creating and registering a coin record

708 Registration Request

709 Registration Confirmation 710 Store conditional transaction

711 Write coin deposit data

721, 731 Read/write request for conditional transaction

724, 734 Check read/write permissions

741 test trigger

742 Checking the condition of the transaction

750 Create transaction

751 transaction (with coin record)

752 Modified Coin Record Registration Request

753 registration confirmation

754, 756 transaction confirmation

755 Writing the coin deposit data

757 Create transaction register record

758 transaction registration

805 coin data records of the coin depot

809 Publisher Data

810 Publisher Defaults

820 Publisher Settings

811, 821 Channel Restriction

812, 822 Receive preference for conditional transactions

813, 823 Amount limit receipt 814 Receipt specification for consideration

816, 826 Recipient Restriction

817, 827 send preference for conditional transactions

818, 828 Amount limit sending 819 Sending specification for consideration

91 Basic data of the conditional transaction

92 condition of the conditional transaction

93 expansion dates

911 channels

912 recipients

913 amount

921 test criterion

922 execution limit

923 Type of conditional transaction

96 write and/or read permissions Transaction Number Coin Record Text Field/Transaction Reference Text

Claims

54 CLAIMS

A user's coin management unit (330,31; 390) comprising: an execution unit (31) for managing digital coin records (335; 395) of a central bank digital currency system, the execution unit being adapted to transact digital coin records (335; 395) with exchange other coin management units and send registration requests to a central bank coin register (20); and at least one digital coin record (335; 395); characterized in that the coin management unit (330,31; 390) is adapted to store conditional transactions (336a, 336b; 396a-c) as data items, a transaction not being executed until a condition of the stored conditional transaction (336a, 336b ; 396a-c) is fulfilled; and the coin management unit (330, 31; 390) is adapted, the conditional transactions (336a, 336b; 396a-c) with different read and/or write permissions (337a, 337b, 338a, 338b; 397a-c, 398a-c) save.

2. Coin management unit (330,31; 390) according to claim 1, wherein a first conditional transaction (336a, 396a) first read and/or write rights (337a, 338a; 397a, 398a) and a second conditional transaction (336b, 396b) second, different reading and/or writing rights (337b, 338b; 397b, 398b), which differ in particular in terms of reading rights, writing rights or reading and writing rights.

3. Coin management unit (330, 31; 390) according to claim 1 or 2, wherein the read and/or write permissions (337a, 337b, 338a, 338b; 397a-c, 398a-c) differ in write permissions for the user and/or or read and/or write rights for third parties, in particular the other coin management units.

The coin management unit (330,31; 390) of any preceding claim, wherein the conditional transaction comprises

- a temporal condition, in particular a point in time or a period,

- a comparative condition, in particular a comparative value for an internal or external parameter,

- a receipt condition, in particular receipt of a security value or 55

conditional transaction code value, receiving a receive transaction, or receiving a request for the conditional transaction.

5. Coin management unit (330,31; 390) according to one of the preceding claims, wherein the coin management unit (330,31; 390), preferably its execution unit (31) or a condition checking unit (37), checks whether the condition of the conditional transaction is met, the checking being carried out in particular continuously, periodically and/or in response to a reception process.

6. Coin management unit (330,31; 390) according to one of the preceding claims, wherein at least two different types of conditional transactions are stored, in particular from the following types: guaranteed conditional transaction, retrievable conditional transaction or conditional return transaction; preferably stored in the coin management unit:

7. Coin management unit (330, 31; 390) according to any one of the preceding claims, wherein the conditional transaction does not include one or more of the data elements of the transaction to be executed only when the condition is met, in particular one or more of the following data elements:

- an identifier of the transmitter (911) of the at least one coin data set,

- an identifier of the recipient (912) of the at least one coin data set,

- a transaction number,

- the at least one coin record (932) of the transaction to be executed.

A coin management unit (330,31; 390) as claimed in any preceding claim, wherein the coin management unit (330,31; 390)

- a coin management unit (390) with its own execution unit (391), or

- a coin management unit (330, 31) in a coin depot management unit (30) with a plurality of coin depots (310, 320, 330), preferably different users, which includes one of the coin depots (330) and one for the plurality of coin depots (310, 320, 330) has a common execution unit (31). 56

The coin management unit (330, 31; 390) of any preceding claim, wherein each coin management unit comprises a coin management unit identifier (237) and optionally a key (238) and/or a certificate (239) associated with the identifier and/or the key .

10. Coin management unit (330, 31; 390) according to one of the preceding claims, wherein the coin management unit (330, 31; 390) comprises a memory area for conditional transactions of the coin management unit, and in a common memory area for several coin depositories (310, 320, 330) - the coin management unit (390) or a coin depot management unit (30) with the coin management unit - one or more of the following information is stored:

References to one or more coin depositories (310, 320, 330) with conditional transactions, in particular coin depositories to be checked in terms of time, more preferably with their check interval; and/or the conditions to be checked of conditional transactions of several coin depositories (310, 320, 330); and/or the conditional transactions of the coin management unit (30; 390) readable by any third party.

11. Coin management unit according to one of the preceding claims, wherein conditional transactions based on the read and/or write rights: readable by at least one other coin management unit of another user of the central bank digital currency system, but only by the user or only jointly by the user and the at least one other coin management unit of writable by other users of the Central Bank Digital Currency System; and/or readable and writable only by the user; and/or readable by at least one other coin management unit of another user of the central bank digital currency system, but writable only by one issuer unit.

12. Coin management unit according to one of the preceding claims, wherein the coin management unit (330, 31; 390) is set up to check one or more of the following specifications before executing transactions:

- a recipient specification which restricts the coin management unit to exactly one recipient, exactly one recipient group or to several recipients and/or recipient groups, and/or 57

- a functional specification relating to a function that can be executed by the execution unit (31), which in particular is the executable function for the coin management unit (330, 31; 390), preferably for a coin depot (310; 320; 330) of the coin management unit (330, 31 ; 390), in whole, in part, or not restrict; and or

- a transmission or reception specification, which limits the transmission of coin data records or the reception of coin data records for the coin management unit (330, 31; 390), preferably for a coin depot (310; 320; 330) of the coin management unit; and or

- an amount specification with a maximum value for the amount of the coin data sets to be sent and/or for the amount of the coin data sets to be received and/or a maximum value or a minimum value for the total amount of the stored coin data sets;

13. Coin management unit according to one of the preceding claims, wherein the coin management unit (330, 31; 390) includes specifications and is set up to check the specifications before storing a conditional transaction, the specifications preferably being a specification for conditional transactions and/or a or comprise a plurality of specifications according to claim 12.

14. Coin management unit (330, 31; 390) according to any one of the preceding claims, wherein the coin management unit comprises a first coin depository (310) and at least one second coin depository (320, 330); wherein the first and second coin depositories (310, 320, 330) are associated with the user; or wherein in a coin deposit management unit (30) the first coin deposit (310) is assigned to the user and the second coin deposit to another user of the digital central bank currency system.

15. Coin management unit (330, 31; 390) according to one of the preceding claims, characterized in that the secure execution unit for managing the coin data sets

16. A method for managing coin data records of a digital central bank currency system with a coin register in a coin management unit that includes an execution unit and at least one coin data record of the central bank, with the steps:

- storing (710) a first conditional transaction containing a condition for executing a transaction, the transaction comprising the exchange of at least one coin record between the coin management unit and another coin management unit of the central bank digital currency system, the first conditional transaction in the coin management unit as a data element is saved, and wherein the first conditional transaction has read and/or write permissions that differ from read and/or write permissions of an already saved second conditional transaction;

- checking (742) whether the condition is met; and

- Execute (750-758) the transaction only when the condition is met.

17. The method according to claim 16, wherein the coin management unit is designed according to any one of claims 1 to 15.

The method of claim 16 or 17, wherein performing the transaction comprises: sending the coin record to the other coin management unit or receiving the coin record from the other coin management unit; and/or sending a registration request to a coin register (20) of the central bank, which in particular includes at least one register reference of a coin data set previously registered in the coin register and a register reference of a coin register registering coin data set, and/or sending transaction register data to a transaction register, and/or providing a consideration, in particular after receiving the coin data set as the condition.

19. The method according to any one of claims 16 to 18, comprising

- receiving (721, 731) a read and/or write request from a requester, in particular a user of the coin management unit or another coin management unit, for at least one conditional transaction;

- Optional checking (723, 733) of an authentication of the requester;

- checking (724, 725) the read and/or write permissions of the at least one conditional transaction,

20. The method according to any one of claims 16 to 19, wherein before the step of storing (710) one or more of the following steps is performed:

- checking (703) an authentication of the user;

- checking (704) a default for the transaction to be executed and/or the conditional transaction.

21. Digital central bank currency system, comprising: a multiplicity of coin management units, which are designed according to one of claims 1 to 15 or set up to carry out a method according to one of claims 16 to 20, the coin register and optionally a multiplicity of coin depot management units and/or or a trade repository.