Nothing Special   »   [go: up one dir, main page]

EP4405879A1 - Münzverwaltungseinheit sowie verfahren in einer münzverwaltungseinheit - Google Patents

Münzverwaltungseinheit sowie verfahren in einer münzverwaltungseinheit

Info

Publication number
EP4405879A1
EP4405879A1 EP22757842.4A EP22757842A EP4405879A1 EP 4405879 A1 EP4405879 A1 EP 4405879A1 EP 22757842 A EP22757842 A EP 22757842A EP 4405879 A1 EP4405879 A1 EP 4405879A1
Authority
EP
European Patent Office
Prior art keywords
coin
management unit
transaction
conditional
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP22757842.4A
Other languages
English (en)
French (fr)
Inventor
Klaus ALFERT
Lars HUPEL
Teresa RIEDL
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke and Devrient Advance52 GmbH
Original Assignee
Giesecke and Devrient Advance52 GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from DE102021005040.1A external-priority patent/DE102021005040A1/de
Application filed by Giesecke and Devrient Advance52 GmbH filed Critical Giesecke and Devrient Advance52 GmbH
Publication of EP4405879A1 publication Critical patent/EP4405879A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes

Definitions

  • the invention relates to a coin management unit and a method for managing coin data sets in a coin management unit.
  • CBDC digital currency
  • 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.
  • the digital money or the coin data records are stored in a central or decentralized blockchain of a central bank.
  • 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.
  • the server can, for example, carry out a transaction independently at a specified time.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • condition may be a reception condition.
  • 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.
  • receiving a receive transaction as a condition or receiving a request for the conditional transaction can serve as a condition.
  • the transaction 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.
  • 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).
  • 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.
  • conditional transactions can be stored in the coin management unit.
  • 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:
  • 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 recipient of the at least one coin data set for example if the sender is arbitrary or may belong to a group
  • 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).
  • ID coin management unit identifier
  • 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.
  • 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:
  • 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;
  • the consideration 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.
  • 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.
  • the specification preferably being a specification for conditional transactions.
  • 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.
  • 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
  • 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
  • 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.
  • 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
  • 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).
  • a random value or a cryptographic security value 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.
  • the full restriction is stored as the content of the functional requirement (such as "not allowed” or “no”).
  • storing empty content (“" or “”) or invalid content 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.
  • 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.
  • 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.
  • the first functional constraint can indicate that conditional transactions are not permitted for the first coin depository (full restriction)
  • the second functional constraint can indicate that conditional transactions are possible for the second coin depository either with or without restrictions.
  • 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.
  • the two functional specifications for the coin deposits could restrict the conditioned transaction differently.
  • conditional transactions 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).
  • conditional transaction coded according to standard A or type B or proprietary C 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.
  • 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.
  • system-wide specifications firmly programmed in the secure execution unit and
  • the publisher can only specify its specifications more narrowly than the system specifications.
  • the secure execution unit complies with system specifications and also checks the (functional and other) specifications of the coin depository.
  • URI Uniform Resource Identifier
  • URN Uniform Resource Name
  • UUID Universally Unique IDentifier
  • RFC 4122 a system-wide unique identifier
  • the URI can contain a UUID and/or a URN.
  • 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.
  • a scheme such as URN or UUID
  • a provider such as operator name or domain name of the operator
  • the unique part such as UUID or serial number.
  • 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".
  • a functional specification can be specified.
  • the fact that the coin depot is in a coin depot management unit can be encoded in halfbyte S.
  • 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.
  • 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".
  • 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”.
  • the specification can require a certificate for the attribute "Bookshop” from the publishing group "SchoeneBücher”.
  • 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.
  • 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.
  • 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.
  • 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.
  • the first user has two coin depots in the coin management unit, which have different specifications.
  • 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 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, ).
  • a financial service provider such as a commercial bank
  • a credit card provider such as a credit card provider
  • a payment service provider Payment Service provider
  • 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.
  • 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.
  • 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.
  • 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 comprises the following steps in the coin management unit.
  • the 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.
  • 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:
  • 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.
  • 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).
  • 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.
  • 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.
  • 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:
  • An associated transaction message here with 2 coin data sets, could then be formatted as follows, for example:
  • 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.
  • the coin register which is already subject to particularly high demands in a digital currency system, is not slowed down.
  • FIG. 2 shows a coin management unit with an execution unit and a coin data record
  • FIG. 3 shows a digital central bank currency system with a coin depot management unit
  • FIG. 5 shows a flowchart for a method with a transaction request
  • FIG. 6 shows a flow chart for a method with a coin deposit request
  • FIG. 7 shows a flow chart for a method with a request for a conditional transaction
  • FIG 9 shows an exemplary embodiment of a list with conditional transactions.
  • FIG. 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.
  • 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.
  • 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.
  • 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).
  • a coin management unit 210, 220 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.
  • 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 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.
  • 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 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • conditional transaction is included in the coin depository 310 .
  • a conditional transaction 316 could optionally be created.
  • 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.
  • the arrows again indicate the right.
  • the conditional transaction 336b has nobody write access - according to write permission 337b.
  • the conditional transaction 336a 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.
  • the sender of the coin records contained in the conditional transaction could have write permission.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the coin repository 320 is unrestricted in terms of transmitters and partially restricted in terms of receivers.
  • 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.
  • ID the identifier
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 .
  • 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 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).
  • 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.
  • 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.
  • 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.
  • 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 .
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the method continues (and the transaction is executed).
  • 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.
  • 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.
  • a new coin data set is created, the amount of which corresponds to the requested amount.
  • 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.
  • 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.
  • 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.
  • 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 .
  • 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 .
  • the contents of the transaction request 501 and/or the transaction message 511 can also be transmitted separately from one another.
  • 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.
  • the secure execution unit 31 again checks whether the transaction corresponds to the specifications of the coin depository.
  • 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.
  • 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 .
  • 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.
  • FIG. 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • UUID system-wide unique ID
  • an identifier as a URN has the following format: "münzdirtician: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".
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the secure execution unit 31 receives 607 one or more coin records for the new coin repository.
  • 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.
  • own coin data records of the same amount are generated and registered (switching).
  • a transaction register data record is preferably transmitted to the transaction register 25 in turn.
  • 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
  • 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.
  • 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 .
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the secure execution unit 31 saves the coin deposit record, particularly if the coin deposit data has changed.
  • storing 711 or storing 710 may include encrypting the coin deposit data as previously described.
  • the coin depository data has changed when the coin depository memory 436 is used.
  • 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.
  • the coin record for the conditional transaction could be cached in the conditional transaction itself, particularly if the coin vault memory 436 is used.
  • the coin record for the conditional transaction is only created after the buffering 710 .
  • 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.
  • 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.
  • 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.
  • 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
  • conditional transactions of the coin depot which, for example, meet a specific criterion such as transaction type or transaction partner, or
  • the coin depot data are read 722 and optionally the authentication of the requesting coin management unit 390 is checked 723.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • 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.
  • a constraint for conditional transactions may specify an allowable type or types of condition, such as time condition, collateral value, and/or external event.
  • a conditional transaction specification may include a type of conditional transaction that is allowed for the coin repository.
  • 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.
  • 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.
  • a specific scheme standard 1 or proprietary 2
  • 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).
  • 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.
  • execution limit such as number of executions or period of time that can be executed
  • 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.
  • 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".
  • 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.
  • 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.
  • the user has l did not select a reception preference, but could have selected a restriction of, for example, "The Shop" or "None".
  • conditional transactions 812, 817 the issuer has not separately restricted the user's coin depository or coin management unit with regard to conditional transactions.
  • 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").
  • 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.
  • 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.
  • the send direction the user has selected 50 digital currency units for his coin deposit in default 828 as the maximum send amount.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • the transaction numbers T-1 through T-2 are the actual transaction numbers of the transaction executed later.
  • 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.
  • 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.
  • 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.
  • 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'.
  • the condition is an external event, such as receiving a secret security value, such as a signature or password for the conditional transaction.
  • 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.
  • 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.
  • 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.
  • 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 .
  • 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.
  • 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.
  • the sender 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%').
  • 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 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.
  • all the elements described and/or drawn and/or claimed can be combined with one another as desired.
  • Registration Confirmation 710 Store conditional transaction

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Storage Device Security (AREA)

Abstract

Die Erfindung betrifft eine Münzverwaltungseinheit eines Benutzers, umfassend: eine Ausführungseinheit (31) zur Verwaltung von digitalen Münzdatensätzen (335; 395) eines digitalen Zentralbankwährungssystems, wobei die Ausführungseinheit angepasst ist, in Transaktionen digitale Münzdatensätze (335; 395) mit anderen Münzverwaltungseinheiten auszutauschen und Registrierungsanforderungen an ein Münzregister (20) der Zentralbank zu senden; und zumindest einen digitalen Münzdatensatz (335; 395). Dabei ist die Münzverwaltungseinheit (330,31; 390) angepasst, bedingte Transaktionen (336a, 336b; 396a-c) als Datenelemente zu speichern, wobei eine Transaktion erst ausgeführt wird, wenn eine Bedingung der gespeicherten bedingten Transaktion (336a, 336b; 396a-c) erfüllt ist. Die Münzverwaltungseinheit ist weiter (330,31; 390) angepasst, die bedingten Transaktionen (336a, 336b; 396a-c) mit unterschiedlichen Lese- und/ oder Schreibrechten (337a, 337b, 338a, 338b; 397a-c, 398a-c) zu speichern. Die Erfindung betrifft zudem ein entsprechendes Verfahren und ein digitales Zentralbankwährungssystem.

Description

Münzverwaltungseinheit sowie Verfahren in einer Münzverwaltungseinheit
Die Erfindung betrifft eine Münzverwaltungseinheit und ein Verfahren zum Verwalten von Münzdatensätzen in einer Münzverwaltungseinheit.
Für eine von einer Zentralbank herausgegebene Digitalwährung (CBDC) sind bereits unterschiedliche technische Lösungsansätze bekannt.
Gemäß einem ersten Ansatz werden Münzdatensätze von einer Zentralbankinstanz nur kryptografisch gesichert und die kryptografisch gesicherten Münzdatensätze direkt zwischen Münzverwaltungseinheiten der Benutzer in verschlüsselter Form ausgetauscht. Die Münzverwaltungseinheiten können anhand der kryptografischen Sicherung, wie Signatur, des Münzdatensatzes dessen Echtheit überprüfen und sollten vorab ein Zertifikat der Zentralbank und/ oder der anderen Münzverwaltungseinheit auf Gültigkeit innerhalb der Zertifikatshierarchie prüfen.
Gemäß einem zweiten Ansatz wird das digitale Geld bzw. werden die Münzdatensätze in einer zentralen oder dezentralen Blockchain einer Zentralbank gespeichert. Wenn ein Münzdatensatz in einer Blockchain im Rahmen einer Transaktion den Besitzer wechselt, werden jedoch oft viele Informationen (Sender/ Empfänger/ Betrag) veröffentlicht und in der Regel benötigen der Sender und der Empfänger zum Zeitpunkt der Transaktion den Zugang zu der Blockchain. Da die Blockchain bzw. dessen Server auf die elektronischen Münzdatensätze zugreifen kann, kann der Server eine Transaktion beispielsweise zu einem vorgegebenen Zeitpunkt selbständig ausführen.
Gemäß einem dritten Ansatz werden die Münzdatensätze durch den Benutzer, beispielsweise in einer lokalen Münzverwaltungseinheit, gespeichert und direkt ausgetauscht. Ein Münzregister speichert eine Registrierung für alle gültigen Münzdatensätze, so dass der Benutzer die Gültigkeit der Münzdatensätze mit Hilfe des Münzregisters überprüfen kann. Da das Münzregister nur Registrierungsdatensätze umfasst, hat es keinen Zugriff auf die Münzdatensätze selbst.
WO 2020/212331 Al verwendet und erweitert diesen dritten Ansatz, durch welchen die Münzdatensätze direkt zwischen den Benutzern ausgetauscht werden können. In WO 2020/212331 Al kann ein direkt ausgetauschter Münzdatensatz auch an einen weiteren Empfänger weitergegeben werden, ohne dass eine Verbindung zu dem Münzregister nötig wäre. Der Empfänger oder der weitere Empfänger kann später einen neuen Münzdatensatz mit gleichem Betrag erzeugen und eine Anforderung an das Münzregister senden, dass die Registrierung des alten Münzdatensatzes im Münzregister durch eine Registrierung des betragsgleichen neuen Münzdatensatzes ersetzt wird.
Ferner beschreibt die WO 2020/212331 Al, dass eine lokale Münzverwaltungseinheit des Benutzers - neben der üblichen Verwaltung der Münzdatensätze einschließlich direktem Austausch der Münzdatensätze und Senden von Registrierungsanforderungen - Münzdatensätze in ein Tresormodul des Benutzers auslagern kann.
Es ist Aufgabe der vorliegenden Erfindung, ein Verfahren, eine Münzverwaltungseinheit oder ein System zu schaffen, in denen eine Bezahltransaktion sicher aber dennoch einfach ausgestaltet ist.
Diese Aufgabe wird gelöst mit einer Münzverwaltungseinheit sowie mit einem Verfahren in einer solchen Einheit, welche die Merkmale der unabhängigen Ansprüche umfassen. Die abhängigen Ansprüche betreffen bevorzugte Ausgestaltungen.
Eine Münzverwaltungseinheit eines Benutzers, umfasst eine Ausführungseinheit zur Verwaltung von digitalen Münzdatensätzen eines digitalen Zentralbankwährungssystems, wobei die Ausführungseinheit angepasst ist, in Transaktionen digitale Münzdatensätze mit anderen Münzverwaltungseinheiten auszutauschen und Registrierungsanforderungen an ein Münzregister der Zentralbank zu senden; und zumindest einen digitalen Münzdatensatz.
Die Münzverwaltungseinheit ist nun angepasst, bedingte Transaktionen als Datenelemente zu speichern, wobei eine Transaktion erst ausgeführt wird, wenn eine Bedingung der gespeicherten bedingten Transaktion erfüllt ist.
Die Münzverwaltungseinheit ist ferner angepasst, die bedingten Transaktionen mit unterschiedlichen Lese- und/ oder Schreibrechten zu speichern.
Mittels der Kombination aus gespeicherter bedingter Transaktion und unterschiedlichen Lese-und/ oder Schreibrechten entsteht eine sehr flexible, vielseitig einsetzbare Lösung. In der Münzverwaltungseinheit weist vorzugsweise mindestens eine erste bedingte Transaktion erste Lese- und/ oder Schreibrechte und mindestens eine zweite bedingte Transaktion zweite, unterschiedliche Lese- und/ oder Schreibrechte auf. Die beiden Lese- und/ oder Schreibrechte können sich in den Leserechten, den Schreibrechten oder den Lese- und den Schreibrechten unterscheiden. Die Münzverwaltungseinheit kann zudem weitere bedingte Transaktionen mit ersten, zweiten oder dritten Lese- und/ oder Schreibrechten umfassen.
In bevorzugten Ausgestaltungen unterscheiden sich die Lese- und/ oder Schreibrechte in den Schreibrechten für den Benutzer und/ oder in den Lese- und/ oder Schreibrechten für Dritte, insbesondere für die anderen Münzverwaltungseinheiten.
Die in der gespeicherten bedingte Transaktion enthaltene Bedingung kann umfassen: eine zeitliche Bedingung, insbesondere einen Zeitpunkt oder eine Periode. Der Zeitpunkt, nach dessen Erreichen die Transaktion auszuführen ist, kann beispielsweise als Uhrzeit, Wochentag und/ oder Datum angegeben sein. Die Periode kann beispielsweise in Stunden, Tagen, Wochen, Monaten und/ oder Jahren angegeben sein, beispielsweise alle 2 Stunden oder täglich oder monatlich. Die Transaktion für die gespeicherte bedingte Transaktion wird dann periodisch (mehrmals) ausgeführt. Sie wird jeweils erneut nach dem Ablauf der Periode ausgeführt.
Die Bedingung kann alternativ eine vergleichende Bedingung sein, insbesondere einen Vergleichswert umfassen, der für einen Vergleich mit einem internen Parameter der Münzverwaltungseinheit, wie Gesamtbetrag der Münzdatensätze in der Münzverwaltungseinheit oder Transaktionszähler oder Transaktionssumme in Zeitraum oder ..., oder mit einem externen Parameter verglichen wird, wie Aktienkurs, Datenelement in einem Server oder einer Datenbank, ... . Den externen Parameter kann die Münzverwaltungseinheit beispielsweise für den Vergleich abrufen oder von einer externen Quelle automatisch erhalten.
Die Bedingung kann weiter alternativ ein Empfangsbedingung sein. Die Transaktion kann insbesondere ausgeführt werden, sobald ein Sicherungswert, wie Signatur, oder ein Codewert, wie Passwort, der bedingten Transaktion empfangen wird. Ebenso jann ein Empfangen einer Empfangstransaktion als Bedingung oder ein Empfangen einer Anfrage für die bedingte Transaktion als Bedingung dienen.
Da die Transaktion erst ausgeführt wird, wenn die in der gespeicherten bedingten Transaktion enthaltene Bedingung erfüllt ist, kann man die Transaktion auch als die auszuführende Transaktion bezeichnen. Im Rahmen der Transaktion wird mit einer anderen Münzverwaltungseinheit ein Münzdatensatz ausgetauscht (gesendet oder empfangen), so dass man die Transaktion gegebenenfalls auch als Austausch- Transaktion bezeichnen könnte.
Die Bedingung kann optional eine Ausführungsbegrenzung enthalten, beispielsweise umfassend eine Ausführungsanzahl (einfach, n-fach oder unbegrenzt oft) und/ oder eine Zeitangabe (ausführbar bis Zeitpunkt).
Die Münzverwaltungseinheit, vorzugsweise deren Ausführungseinheit oder eine Bedingungs-Prüfeinheit, überprüft, ob die Bedingung der bedingten Transaktion erfüllt ist. Das Überprüfen kann dabei insbesondere kontinuierlich, periodisch, beispielsweise stündlich oder täglich (jedoch angepasst an die zu prüfenden Bedingungen), und/ oder in Antwort auf einen Empfangsvorgang in der Münzverwaltungseinheit erfolgen.
Es können unterschiedliche Typen von bedingten Transaktionen in der Münzverwaltungseinheit gespeichert sein. Insbesondere sind zumindest zwei oder drei unterschiedliche Typen von bedingten Transaktionen gespeichert. Als Typen können einzeln oder in Kombination miteinander vorliegen: garantierte bedingte Transaktion, abrufbare bedingte Transaktion, periodische bedingte Transaktion und/ oder bedingte Gegenleistungstransaktion. Vorzugsweise sind in der Münzverwaltungseinheit gespeichert:
- mindestens zwei bedingten Transaktionen eines ersten Typs, welche gleiche oder unterschiedliche Lese- und/ oder Schreibrechte aufweisen, und/ oder
- mindestens zwei bedingte Transaktionen der zumindest zwei unterschiedlichen Typen, welche gleiche oder unterschiedliche Lese- und/ oder Schreibrechte aufweisen.
Die bedingte Transaktion kann neben den Basisdaten der auszuführenden Transaktion, Empfänger, Sender und Betrag, bereits ein oder mehrere weitere Datenelemente der Transaktion, insbesondere den auszutauschenden Münzdatensatz und/ oder die Transaktionsnummer, umfassen. Die bedingte Transaktion kann bereits alle Datenelemente der auszuführenden Transaktion umfassen. Insbesondere für nur vom Benutzer und nicht von Dritten lesbare auszuführende Sendetransaktionen (oder nur vom Sender und nicht vom Benutzer lesbare Empfangstransaktionen) ist eine solche Ausgestaltung möglich. Bevorzugt umfasst die bedingte Transaktion eines oder mehrere der Datenelemente der erst bei Erfüllung der Bedingung auszuführenden Transaktion nicht, insbesondere eines oder mehrere der folgenden Datenelemente:
- einen Identifikator des Senders des mindestens einen Münzdatensatzes, beispielsweise wenn der Sender beliebig ist oder einer Gruppe angehören darf,
- einen Identifikator des Empfängers des mindestens einen Münzdatensatzes, beispielsweise wenn der Sender beliebig ist oder einer Gruppe angehören darf
- eine Transaktionsnummer, insbesondere wenn die Transaktion mehrfach ausführbar ist,
- den mindestens einen Münzdatensatz der auszuführenden Transaktion, nur beispielsweise bei mehrfacher Ausführbarkeit oder bisher fehlendem Transaktionspartner.
Die Münzverwaltungseinheit kann eine Münzverwaltungseinheit mit eigener Ausführungseinheit sein und optional mehrere Münzdepots des Benutzers umfassen. Die Münzverwaltungseinheit kann beispielsweise als Sicherheitsmodul, Chipkarte, Teil eines Mobilfunkgerätes, RFID-, USB- oder Bluetooth-Token oder ... ausgestaltet sein. Die Münzverwaltungseinheit kann in einer Münzdepotverwaltungseinheit, die mehrere Münzdepots, vorzugsweise unterschiedlicher Benutzer, und eine für die mehreren Münzdepots gemeinsame Ausführungseinheit umfasst, vorliegen, wobei die Münzverwaltungseinheit durch eines der Münzdepots zusammen mit der gemeinsamen Ausführungseinheit gebildet ist. Die Münzdepotverwaltungseinheit ist in der Regel ein Server, der den unterschiedlichen Benutzern die Münzdepots bereitstellt.
Jede Münzverwaltungseinheit sollte einen Identifikator (ID) der Münzverwaltungseinheit umfassen und kann optional einen Schlüssel, beispielsweise zur Authentisierung der Münzverwaltungseinheit, und/ oder ein dem Identifikator und/ oder dem (öffentlichen) Schlüssel (des Schlüsselpaares) zugeordnetes Zertifikat umfassen.
Die Münzverwaltungseinheit umfasst zumindest einen Speicherbereich für bedingte Transaktionen der Münzverwaltungseinheit bzw. eines Münzdepots, und zusätzlich einen gemeinsamen Speicherbereich für mehrere Münzdepots - der Münzverwaltungseinheit oder einer Münzdepotverwaltungseinheit mit der Münzverwaltungseinheit -, in welchem eine oder mehrere der folgenden Informationen gespeichert sind:
Referenzen auf eines oder mehrere Münzdepots mit bedingten Transaktionen, insbesondere zeitlich zu prüfende Münzdepots, mehr bevorzugt mit deren Prüfintervall; und/ oder die zu prüfenden Bedingungen von bedingten Transaktionen mehrerer Münzdepots; und/ oder die für jeden Dritten lesbaren bedingten Transaktionen der Münzverwaltungseinheit.
Insbesondere wenn die Bedingungen für viele Münzdepots oder für verschlüsselt gespeicherte Münzdepots zu prüfen sind, ist diese Ausgestaltung hilfreich.
In besonders bevorzugten Varianten sind bedingte Transaktionen anhand der Lese- und/ oder Schreibrechte: von zumindest einer anderen Münzverwaltungseinheit eines anderen Benutzers des digitalen Zentralbankwährungssystems lesbar, aber nur vom Benutzer oder nur gemeinsam vom Benutzer und der zumindest einen anderen Münzverwaltungseinheit des anderen Benutzers des digitalen Zentralbankwährungssystems schreibbar sind; und/ oder nur vom Benutzer lesbar und schreibbar sind; und/ oder von zumindest einer anderen Münzverwaltungseinheit eines anderen Benutzers des digitalen Zentralbankwährungssystems lesbar, aber nur von einer Herausgebereinheit schreibbar sind.
Die Münzverwaltungseinheit kann Vorgaben umfassen, die für auszuführende Transaktionen und/ oder für zu speichernde bedingte Transaktionen geprüft werden. So kann sie insbesondere eingerichtet sein, eine oder mehrere der folgenden Vorgaben vor dem Ausführen von Transaktionen zu prüfen:
- eine Empfängervorgabe, welche die Münzverwaltungseinheit auf genau einen Empfänger, genau eine Empfängergruppe oder auf mehrere Empfänger und/ oder Empfängergruppen beschränkt, und/ oder
- eine Sendervorgabe, welche die Münzverwaltungseinheit auf genau einen Sender, genau eine Sendergruppe oder mehrere Sender und/ oder Sendergruppen beschränkt, und/ oder
- eine funktionelle Vorgabe, die eine von der Ausführungseinheit ausführbare Funktion betreffen, welche insbesondere die ausführbare Funktion für die
Münzverwaltungseinheit, bevorzugt für ein Münzdepot der Münzverwaltungseinheit, vollständig, teilweise oder nicht beschränken; und/ oder
- eine Sende- oder Empfangs-Vorgabe, welche das Senden von Münzdatensätzen respektive das Empfangen von Münzdatensätzen für die Münzverwaltungseinheit, bevorzugt für ein Münzdepot der Münzverwaltungseinheit, beschränkt; und/ oder
- eine Betragsvorgabe mit einem Maximalwert für den Betrag der zu sendenden und/ oder für den Betrag der zu empfangenden Münzdatensätze und/ oder einen Maximalwert oder einen Minimalwert für den Gesamtbetrag der gespeicherten Münzdatensätze;
- eine vom Benutzer wählbare Vorgabe, welche insbesondere vom Benutzer zu wählen ist, so dass sie enger ist als eine vom Herausgeber der Münzverwaltungseinheit festgelegte Vorgabe; und/ oder
- eine Gegenleistungs-Vorgabe, wobei in Antwort auf mindestens einen empfangenen Münzdatensatz als Leistung die Gegenleistung, insbesondere in den Antwortdaten an den Sender des empfangenen Münzdatensatzes, bereitgestellt wird.
Die Münzverwaltungseinheit kann alternativ oder ergänzend Vorgaben umfassen und eingerichtet sein, vor dem Speichern einer bedingten Transaktion die Vorgaben zu prüfen, wobei die Vorgaben vorzugsweise eine Vorgabe für bedingte Transaktionen ist. Als Vorgabe für bedingte Transaktionen kommen beispielsweise - neben den bereits genannten Vorgaben, für Betrag, Empfänger oder Sender, die für bedingte Transaktionen enger sein können als für direkt auszuführende Transaktionen, Vorgaben des Herausgebers der Münzverwaltungseinheit oder des Benutzers in Frage, welche beispielsweise den Typ der bedingten Transaktion und/ oder die Art der Bedingung für die Münzverwaltungseinheit beschränken.
Zwei Münzdepots in der Münzverwaltungseinheit könnten - wie teils bereits beschrieben - dem gleichen Benutzer zugeordnet oder in einer Münzdepotverwaltungseinheit unterschiedlichen Benutzern zugeordnet sein.
Die sichere Ausführungseinheit zur Verwaltung der Münzdatensätze ist zudem vorzugsweise eingerichtet, um
- Transaktionsregisterdaten an ein Transaktionsregister sendet, wobei die Transaktionsregisterdaten insbesondere einen eindeutigen Transaktions-Identifikator, einen Transaktionsbetrag, eine Münzverwaltungseinheits-Identifikator des Senders, eine Münzverwaltungseinheits-Identifikator des Empfängers und die Registerreferenz des Münzdatensatzes im Münzregister umfassen; und/ oder
- Registrierungsanforderungen an das Münzregister sendet, welche mindestens eine Registerreferenz eines bisher im Münzregister registrierten Münzdatensatzes und eine Registerreferenz eines im Münzregister zu registrierenden Münzdatensatzes umfasst.
In dem digitalen Zentralbank-Währungssystem können digitale Münzdatensätze aufgeteilt (in mehrere Münzdatensätze: 10 => 5,5), umgeschaltet (betragsneutraler Tausch: neue Münze gegen alte Münze) oder mit einem anderen Münzdatensatz verbunden werden (neuer Münzdatensatz: 2 +10 =12). Für die neuen Münzdatensätze bzw. deren Referenzen sind dann entsprechende Registrierungsanforderungen an das Münzregister zu senden.
Es wird darauf hingewiesen, dass die Vorgaben und die bedingten Transaktionen als Datenelemente gespeichert werden, sie sind also nicht durch die Programmierung der Münzverwaltungseinheit (Software) festgelegt sind.
Eine bedingte Transaktion mit Lese- und/ oder Schreibrechten kann für einen Münzdepot der Münzverwaltungseinheit gespeichert sein, insbesondere in einem Zwischenspeicher eines Münzdepots der Münzverwaltungseinheit oder in einem münzdepotübergreifenden Zwischenspeicher der Münzverwaltungseinheit
Insbesondere ein Empfänger der Transaktion oder ein Dritter kann beispielsweise die Transaktion auslösen, wenn er den Sicherungswert kennt und ihn als Auslöser (ggf. zusammen mit der ID der Münzverwaltungseinheit und/ oder einer Transaktionsnummer) sendet. Als Sicherungswert kann beispielsweise eine Zufallswert oder ein kryptographischer Sicherungswert (Hashwert von Daten/ Signatur von Daten/...) dienen.
Funktionelle Vorgaben können für die Prüfung der Vorgaben als positives oder negatives Prüfkriterium vorgesehen sein. Die Funktion darf verwendet werden, wenn ein positives Prüfkriterium erfüllt ist bzw. nicht verwendet werden, wenn ein negatives Prüfkriterium erfüllt ist. Für teilweise beschränkende funktionelle Vorgaben werden bevorzugt positive Prüfkriterien verwendet. So enthält vorzugsweise eine teilweise beschränkende Richtungsvorgabe die zulässigen Sender und/ oder Empfänger (positives Prüfkriterium). Alternativ oder ergänzend denkbar ist es, in der Richtungsvorgabe nicht-zulässige Sender und/ oder Empfänger zu speichern (negatives Prüfkriterium). Auch eine vollständige Beschränkung, wie beispielsweise bei einer Richtungsvorgabe „kein Senden" oder „kein Empfangen", kann in einer funktionellen Vorgabe unterschiedlich gespeichert werden. Bevorzugt ist die vollständige Beschränkung als Inhalt der funktionellen Vorgabe gespeichert (wie „nicht zulässig" oder „nein"). Alternativ könnte das Speichern eines leeren Inhalts („" oder „ ") oder eines ungültigen Inhalts (wie „-" als Zahl, ID oder ...) die vollständige Beschränkung angeben. Es kann vorgesehen sein, eine (oder mehrere) nicht beschränkende funktionelle Vorgabe(n) zu speichern. Ein Beispiel wäre ein Münzdepot, dass an beliebige Empfänger senden darf, aber nur von bestimmten Sendern empfangen darf. In bevorzugten Ausgestaltungen wird die nicht beschränkende funktionelle Vorgabe durch das Fehlen dieser Vorgabe angegeben, im Beispiel: für das Münzdepot gibt es eine Sender-Vorgabe aber keine Empfänger-Vorgabe. Alternativ kann jedoch der Inhalt der funktionellen Vorgabe angeben, dass die funktionelle Vorgabe keine Beschränkung enthält, im Beispiel: Empfänger-Vorgabe mit Inhalt „jeder", „alle", oder Ähnliches.
Eine funktionelle Vorgabe für bedingte Transaktionen kann wiederum eine Voll-, Teiloder Nicht-Beschränkung enthalten. So kann die erste funktionelle Vorgabe angeben, dass für das erste Münzdepot bedingte Transaktionen nicht zulässig sind (Vollbeschränkung), und die zweite funktionelle Vorgabe angeben, dass für das zweite Münzdepot bedingte Transaktionen entweder unbeschränkt oder teilbeschränkt möglich sind. Alternativ könnte die erste funktionelle Vorgabe für das erste Münzdepot eine Teilbeschränkung für bedingte Transaktionen enthalten und die zweite funktionelle Vorgabe für das zweite Münzdepot keine Beschränkung für bedingte Transaktionen enthalten. Weiter alternativ könnten die beiden funktionellen Vorgaben für die Münzdepots bedingte Transaktion unterschiedlich beschränken.
Es kann verschiedene Arten von bedingten Transaktionen geben, die sich in ihrer Komplexität und/ oder in ihrer Kodierung (bedingte Transaktion kodiert gemäß Standard A oder Typ B oder proprietär C ...) unterscheiden. Die verschiedenen Arten bedingter Transaktionen werden durch die sichere Ausführungseinheit unterstützt, vorliegend für Münzdepots durch entsprechende Vorgaben jedoch nur noch selektiv bzw. beschränkt zugelassen.
In bevorzugten Ausgestaltungen unterscheidet sich eine Sendevorgabe (bzw. Empfängervorgabe) eines Münzdepots, also insbesondere auch des ersten und/ oder zweiten Münzdepots, von seiner Empfangsvorgabe (bzw. Sendervorgabe). Die Richtungsvorgaben sind für ein Münzdepot also bevorzugt asymmetrisch ausgestaltet.
Die bedingte Transaktion kann aufweisen eine Sende- oder Empfangs-Vorgabe als Bedingung, welche das Senden von Münzdatensätzen respektive das Empfangen von Münzdatensätzen für die Münzverwaltungseinheit, bevorzugt für ein Münzdepot der Münzverwaltungseinheit, beschränkt.
Eine Benutzer-Vorgabe kann vom Benutzer zu wählen sein. Sie wird vorzugsweis so zu wählen sein, dass sie enger ist als die entsprechende vom Herausgeber festgelegte Vorgabe. Der Benutzer hat also die Möglichkeit eine Vorgabe des Herausgebers weiter zu beschränken. Man kann die Vorgaben als Herausgeber-Vorgaben und Benutzer- Vorgaben bezeichnen. Naturgemäß sind system weit gültige Vorgaben (fest in der sicheren Ausführungseinheit programmiert und) nicht mehr vom Herausgeber festlegbar oder vom Benutzer wählbar. Der Herausgeber kann seine Vorgaben entsprechend ebenfalls nur enger als die Systemvorgaben festlegen. Die sichere Ausführungseinheit hält insofern System vorgaben ein und prüft zudem die (funktionellen und anderen) Vorgaben des Münzdepots.
Als Münzverwaltungseinheits-Identifikator wird vorzugsweise
- ein einheitlicher Ressourcenidentifikator, Uniform Resource Identifier (URI), insbesondere nach RFC 3986,
- ein Uniform Resource Name (URN), insbesondere nach RFC 8141, und/ oder
- ein systemweit eindeutiger Identifikator, Universally Unique IDentifier (UUID), insbesondere nach RFC 4122, verwendet. Die URI kann eine UUID und/ oder eine URN enthalten.
Der URI umfasst als Anteile beispielsweise ein Schema, wie URN oder UUID, einen Anbieter, wie Betreibernamen oder Domainnamen des Betreibers, sowie den eindeutigen Anteil, wie UUID oder Seriennummer. In einem Beispiel: urn:uuid:965ecc78-3182-4d5b-8f6a-le325b336031.
Die URN umfasst als Anteile beispielsweise einen Ressourcentyp (Beispiel: Münzverwaltungseinheit), einen Betreibernamen, in der Regel den Domänennamen des Betreibers (Beispiel: meineBank.com), sowie einen zumindest bei dem Betreiber, aber vorzugsweise systemweit, eindeutigen Anteil (Beispiele: Seriennummer oder UUID). Ein Sender und ein Empfänger einer Transaktion könnten dann beispielsweise wie folgt angegeben sein: Sender-ID: münzverwaltungseinheit:meine-bank.com:dlafujr3jbd" bzw. Empfänger-ID: münzverwaltungseinheit:deine-bank.com:3hbbda903988r".
In einer UUID „xxxxxxxx-xxxx-Mxxx-Nxxx-SVxxxxxxxxxx" wird gemäß RFC 4122 im Halfbyte M die Version und im Halfbyte N die Variante der UUID kodiert. Nun kann in mindestens einem weiteren Anteil der UUID, wie beispielsweise den Halfbytes S und/ oder V (in Version 4, Variante 1), eine funktionelle Vorgabe angegeben werden. So kann im Halfbyte S beispielsweise kodiert sein, dass das Münzdepot in einer Münzdepot-Verwaltungseinheit vorliegt. In einem Anteil der UUID, wie diesem oder einem weiteren Halfbyte, können zumindest kurze funktionelle Vorgaben kodiert sein. Beispielsweise könnte in 3 Bits kodiert werden „keine Richtungsbeschränkung", „kein Senden" oder „kein Empfangen". Ebenso könnte in den 3 Bits oder weiteren 3 Bits eine Vorgabe für bedingte Transaktionen kodiert sein, beispielsweise könnte die Zulässigkeit von drei Arten von Bedingungen oder von drei Arten von bedingten Transaktionen kodiert sein. Der Münzverwaltungseinheits-Identifikator kann zumindest eine (kurze) funktionelle Vorgabe oder einen Anteil der funktionellen Vorgaben umfassen. Ein Zertifikat kann mehr Daten enthalten als ein Identifikator. Entsprechend kann das Münzverwaltungseinheits-Zertifikat eine oder mehrere funktionelle Vorgaben enthalten.
Ein Zertifikat kann eine Münzverwaltungseinheit als Mitglied einer Gruppe aus weisen, beispielsweise als Gruppenzertifikat, wie „ID/ Schlüssel gehört zu Gruppe XY", oder als Attributzertifikat, wie „Attribut YZ erfüllt". In der Vorgabe kann eine Empfängergruppe beispielsweise auch durch die Gruppe und/ oder einen Zertifikatstyp angegeben sein, wie „Zertifikat für Gruppe XY" oder „Zertifikat für Attribut YZ". Beispielsweise kann die Vorgabe ein Zertifikat für das Attribut „Buchladen" aus der Verlagsgruppe „SchöneBücher" fordern. In alternativen oder ergänzenden Ausgestaltungen beschränkt zumindest eine teilbeschränkende Empfangsvorgabe das Empfangen von Münzdatensätzen auf genau einen Sender, genau eine Sendergruppe oder mehrere Sender und/ oder Sendergruppen. Der oder die Sender und/ oder Sendergruppe(n) sind in der Vorgabe enthalten, insbesondere durch Angabe einer Sender-ID, einer Sendergruppen-ID oder eines Sender-ID- Anteils oder einer Zertifikatsgruppe. In der Vorgabe kann eine Sendergruppe beispielsweise jedoch auch durch eine Gruppe und/ oder einen Zertifikatstyp angegeben sein, wie „Zertifikat für Gruppe XY" oder „Zertifikat für Attribut YZ". hn Rahmen einer Transaktion wird zumindest ein Münzdatensatz zwischen zwei Münzverwaltungseinheiten ausgetauscht. Vorzugsweise wird für einen aus dem ausgetauschten Münzdatensatz abgeleiteten Münzdatensatz eine Registrierungsanfrage an das Münzregister gesendet und/ oder ein Transaktionsdatensatz an ein Transaktionsregister gesendet. Der zumindest eine Münzdatensatz ist zunächst bei dem Sender, wie erstes oder zweites Münzdepot, des Münzdatensatzes gespeichert. Der Münzdatensatz (oder ein daraus abgeleiteter Münzdatensatz) ist nach der Transaktion beim Empfänger gespeichert. Bevorzugt wird der Münzdatensatz direkt zwischen Sender und Empfänger übertragen, insbesondere kann der Münzdatensatz direkt an einen weiteren Empfänger weitergegeben werden. WO 2020/212331 Al beschreibt bereits das entsprechende Grundprinzip. Die vorliegende Lösung ist jedoch nicht an die dort beschriebene Maskierung des Betrages der Münzdatensätze oder die konkreten Protokolle der WO 2020/212331 Al gebunden. Bedingte Transaktionen werden bevorzugt genau einmal ausgeführt. Es ist jedoch möglich bedingte Transaktionen vorzusehen, die mehrfach ausgeführt werden, insbesondere auch mit oder ohne Begrenzung der Anzahl der Ausführungen (z.b. alle 2 Wochen oder ereignisbedingt genau viermal). Die bedingte Transaktion kann ausgeführt werden, also beispielsweise mit dem gespeicherten Betrag und Empfänger, oder alternativ kann eine - insbesondere von einem Dritten/ Empfänger - angeforderte Transaktion ausgeführt werden, welche unter die gespeicherte, bedingte Transaktion fällt. Also beispielsweise eine vom Empfänger angeforderte Transaktion mit einem Transaktionsbetrag, der kleiner ist als der gespeicherte Betrag und/ oder einem Empfänger, der zu einer gespeicherten Empfängergruppe gehört.
Münzdepots können einem ersten (dem gleichen) Benutzer zugeordnet sein. Der erste Benutzer hat beispielsweise zwei Münzdepots in der Münzverwaltungseinheit, die unterschiedliche Vorgaben umfassen. Alternativ kann ein erstes Münzdepot einem ersten Benutzer und ein zweites Münzdepot einem zweiten Benutzer zugeordnet sein. Der erste und/ oder der zweite Benutzer kann mehrere Münzdepots in der Münzverwaltungseinheit sowie eine (oder mehrere) lokale Münzverwaltungseinheit(en) haben, beispielsweise in der Form eines Sicherheitsmoduls, wie Chipkarte, SIM-Karte, RFID-Token, NFC-Modul, eingebautes Sicherheitsmodul.
Eine Münzdepotverwaltungseinheit für mehrere Benutzer wird von einem Betreiber bereitgestellt, der beispielsweise ein Finanzdienstleister, wie eine Geschäftsbank, ein Kreditkartenanbieter oder ein Zahlungsdienstleister (Paypal, ...), sein kann. Das Erstellen des Münzdepots wird in der Regel von einem Dritten, dem Herausgeber, beauftragt.
Das Münzdepot kann eine teilweise frei auslesbare Vorgabe umfassen, insbesondere auch die funktionellen Vorgaben. Insbesondere können ein auslesbarer Anteil und ein nicht auslesbarer Anteil der mindestens teilweise frei auslesbaren Vorgabe vorliegen. Die beiden Anteile sind bevorzugt in unterschiedlichen Datenelementen gespeichert, insbesondere einem frei auslesbaren Datenelement, wie dem Münzverwaltungseinheits-Zertifikat oder -Identifikator oder einem nicht-vertraulichen Vorgabedatenelement, und in einem nicht frei auslesbaren Datenelement des Münzdepots, wie einem dedizierten vertraulichen Vorgabendatenelement. Alternativ sind die beiden Anteile in einem gemeinsamen Datenelement nicht frei auslesbar gespeichert und zusätzlich ist der lesbare Anteil in einem separaten lesbaren Datenelement gespeichert, wie dem Münzverwaltungseinheits-Zertifikat oder - Identifikator oder einem nicht- vertraulichen Vorgabedatenelement.
Die sichere Ausführungseinheit kann zur Verwaltung der Münzdatensätze Transaktionsregisterdaten an ein Transaktionsregister senden. Die Transaktionsregisterdaten umfassen insbesondere einen eindeutigen Transaktions- Identifikator, einen Transaktionsbetrag, eine Münzverwaltungseinheits-Identifikator des Senders, eine Münzverwaltungseinheits-Identifikator des Empfängers und die (mindestens eine) Registerreferenz des Münzdatensatzes im Münzregister.
Alternativ oder ergänzend kann die sichere Ausführungseinheit zur Verwaltung der Münzdatensätze Registrierungsanforderungen an das Münzregister senden, welche insbesondere mindestens eine Registerreferenz eines bisher im Münzregister registrierten Münzdatensatzes und eine Registerreferenz eines im Münzregister zu registrierenden Münzdatensatzes umfasst.
Ein Verfahren zur Verwaltung von Münzdatensätzen eines digitalen Zentralbankwährungssystems mit Münzregister in einer Münzverwaltungseinheit, die eine Ausführungseinheit und zumindest einen Münzdatensatz der Zentralbank umfasst, umfasst die folgenden Schritte in der Münzverwaltungseinheit.
Speichern einer ersten bedingten Transaktion, die eine Bedingung für das Ausführen einer Transaktion enthält, wobei die Transaktion den Austausch zumindest eines Münzdatensatzes zwischen der Münzverwaltungseinheit und einer anderen Münzverwaltungseinheit des digitalen Zentralbankwährungssystems umfasst. Die erste bedingte Transaktion wird dabei in der Münzverwaltungseinheit als Datenelement gespeichert und die gespeicherte erste bedingte Transaktion weist Lese- und/ oder Schreibrechte auf, die sich von Lese- und/ oder Schreibrechte einer bereits gespeicherten zweiten bedingten Transaktion unterscheiden.
Prüfen ob die Bedingung erfüllt ist, und Ausführen der Transaktion erst wenn die Bedingung erfüllt ist.
Alle vorherigen Anmerkungen zur Vorrichtung sind in diesem zugehörigen Verfahren analog anwendbar. Das Ausführen der Transaktion umfasst vorzugsweise: ein Senden des Münzdatensatzes an die andere Münzverwaltungseinheit oder ein Empfangen des Münzdatensatzes von der anderen Münzverwaltungseinheit; und/ oder ein Senden einer Registrierungsanforderung an ein Münzregister der Zentralbank, welche insbesondere mindestens eine Registerreferenz eines bisher im Münzregister registrierten Münzdatensatzes und eine Registerreferenz eines im Münzregister zu registrierenden Münzdatensatzes umfasst, und/ oder ein Senden von Transaktionsregisterdaten an ein Transaktionsregister, und/ oder das Bereitstellen einer Gegenleistung, insbesondere nach einem Empfangen des Münzdatensatzes als die Bedingung.
Das Verfahren kann zudem den Lese- und/ oder Schreibvorgang umfassen. Vorzugsweise folgende Schritte können erfolgen:
- Empfangen einer Lese- und/ oder Schreibanfrage eines Anfragenden, insbesondere eines Benutzers der Münzverwaltungseinheit oder einer anderen Münzverwaltungseinheit, für zumindest eine bedingte Transaktion;
- optionales Prüfen einer Authentisierung des Anfragenden;
- Prüfen der Lese- und/ oder Schreibrechte der zumindest einen bedingten Transaktion,
- Beantworten der Lese- und/ oder Schreibanfrage abhängig von den Lese- und/ oder Schreibrechten, insbesondere im Fall einer Leseanfrage durch Bereitstellen der bedingten Transaktion für den Anfragenden oder im Fall einer Schreibanfrage durch Schrieben der bedingten Transaktion.
Das Ausführen der Transaktion kann umfassen: ein Senden oder ein Empfangen eines Münzdatensatzes der Zentralbank, und/ oder ein Senden einer Registrierungsanforderung an ein Münzregister der Zentralbank, welche insbesondere für einen empfangenen bisher registrierten Münzdatensatz die Registrierung eines in der neuen Münzverwaltungseinheit zu speichernden Münzdatensatzes anfordert, und/ oder ein Senden von Transaktionsregisterdaten an ein Transaktionsregister, und/ oder das Bereitstellen einer Gegenleistung, wobei insbesondere die Transaktions- Anforderung einen Münzdatensatz umfasst.
Eine Transaktions- Anfrage umfasst insbesondere einen Transaktionsbetrag, einen Münzverwaltungseinheits-Identifikator des Senders sowie eine Münzverwaltungseinheits-Identifikator des Empfängers. Nur optional umfasst sie ferner einen eindeutigen Transaktions-Identifikator und/ oder einen Transaktions- Bezugstext. Eine Transaktions-Anfrage sendet in der Regel der Benutzer des Münzdepots. In Ausgestaltungen kann die Transaktions- Anfrage auch von einer anderen Münzverwaltungseinheit oder einem Transaktionspartner (Sender oder Empfänger von Münzdatensätzen) an die Münzdepot-Verwaltungseinheit gesendet werden. Der Schritt des Ausführens der Transaktion umfasst das Senden mindestens eines Münzdatensatzes des Münzdepots zu einem Empfänger (oder das Empfangen mindestens eines Münzdatensatzes, der insbesondere in der Transaktions- Anfrage enthalten ist). In dem Schritt des Ausführens der Transaktion kann ein zu übertragender Münzdatensatz erzeugt und beim Münzregister registriert werden, insbesondere wenn der Betrag des zu übertragenden Münzdatensatzes einem Transaktionsbetrag entsprechen soll. Mindestens ein Münzdatensatz, also gegebenenfalls zwei oder mehrere Münzdatensätze, des Münzdepots werden in dem Schritt des Ausführens der Transaktion übertragen. Münzdatensätze können separat oder in Transaktionsnachrichten, beispielsweise zusammen mit einer Transaktions-ID, übertragen werden, insbesondere wenn bereits eine verschlüsselte Verbindung zwischen Sender und Empfänger aufgebaut ist. Alternativ kann jedoch (gerade zwischen Münzdepot-Verwaltungseinheiten) auch eine vollständige Transaktionsnachricht übertragen werden. Eine vollständige Transaktionsnachricht enthält insbesondere die in der Transaktions-Anfrage enthaltenen Datenelemente und den mindestens einen Münzdatensatz.
Transaktions-Anfragen, Münzdatensätze und/ oder vollständige Transaktionsnachrichten können bevorzugt in einer http-Nachricht enthalten sein. Transaktions-Anfragen, Münzdatensätze und/ oder vollständige Transaktionsnachrichten können alternativ oder ergänzend in einem JSON-Format übertragen werden. Das JavaScript Object Notation(JSON)-Format entspricht vorzugsweise RFC 8259 (und/ oder ECMA 404 bzw. ISO/IEC 21778). Eine TransaktionID kann als UUID formatiert sein. Eine Transaktions- Anfrage könnte dann beispielsweise wie folgt formatiert sein:
{
"Sender": "urn:münzverwaltungseinheit:meine-bank.com:dlafujr3jbd",
"Empfänger": "urn:münzverwaltungseinheit:deine-bank.com:3hbbda903988r", „Betrag": „1,60 eCBDC"
"Transaktions-Bezugstext": " Vorgangs nummer 1234898942"
}
Eine zugehörige Transaktions-Nachricht, hier mit 2 Münzdatensätzen, könnte dann beispielsweise wie folgt formatiert sein:
{
"Transaktions-ID": "lcl02b5f-5496-459d-8a67-3bflc348bll3",
"Sender": "urn:münzverwaltungseinheit:meine-bank.com:dlafujr3jbd", "Empfänger": "urn:münzverwaltungseinheit:deine-bank.com:3hbbda903988r",
"Münzdatensätze": [
{
"Betrag": 1000, "... Nummer":„116e782982383e9d0ea2c728f2a5f80d8a6121"
},
{
"Betrag": 60, "... Nummer": „Iaaa77777777777733333c9123812123712814"
}
],
"Transaktions-Bezugstext": "Rechnung 1234898942"
}
Die beschriebenen Verfahren können in einer der zuvor beschriebenen Münzdepot- Verwaltungseinheiten ausgeführt werden. Die unterschiedlichen Verfahren und Ausgestaltungen sind miteinander kombinierbar und können beispielsweise unterschiedliche Münzdepots oder jeweils das erste und/ oder zweite Münzdepot betreffen.
Ein digitales Zentralbank-Währungs-System umfasst eine Münzverwaltungseinheit - in einer der beschriebenen Ausgestaltungen bzw. eingerichtet zur Ausführung eines der beschriebenen Verfahren. Das System umfasst ferner das Münzregister der Zentralbank sowie optional eine Vielzahl von Münzverwaltungseinheiten und/ oder ein Transaktionsregister.
Die vorliegende Lösung ist besonders vorteilhaft, da die hohe Flexibilität in der Münzdepot-Verwaltungseinheit unabhängig von dem Münzregister und/oder dem Transaktionsregister angeboten werden kann. Insbesondere wird das Münzregister, an welches in einem digitalen Währungssystem bereits besonders hohe Anforderungen gestellt werden, nicht verlangsamt.
Nachfolgend wird anhand von Figuren die Erfindung bzw. weitere Ausführungsformen und Vorteile der Erfindung näher erläutert, wobei die Figuren lediglich Ausführungsbeispiele der Erfindung beschreiben. Gleiche Bestandteile in den Figuren werden mit gleichen Bezugszeichen versehen. Die Figuren sind nicht als maßstabsgetreu anzusehen, es können einzelne Elemente der Figuren übertrieben groß bzw. übertrieben vereinfacht dargestellt sein.
Es zeigen: Fig.l ein digitales Zentralbank-Währungs-System mit Münzverwaltungseinheiten sowie einem Münzregister der Zentralbank;
Fig.2 eine Münzverwaltungseinheit mit einer Ausführungseinheit und einem Münzdatensatz;
Fig.3 ein digitales Zentralbank-Währungs-System mit einer Münzdepot- verwaltungs-Einheit;
Fig.4 eine Münzdepot-Verwaltungseinheit;
Fig.5 ein Ablaufdiagramm für ein Verfahren mit einer Transaktions- Anforderung;
Fig.6 ein Ablauf diagramm für ein Verfahren mit einer Münzdepot- Anforderung;
Fig.7 ein Ablauf diagramm für ein Verfahren mit einer Anforderung einer bedingten Transaktion;
Fig. 8 ein Ausführungsbeispiel für Vorgaben eine Münzdepots; und
Fig. 9 ein Ausführungsbeispiel einer Liste mit bedingten Transaktionen.
Fig. 1 zeigt ein digitales Zentralbank-Währungs-System, wie es für sich genommen bereits bekannt ist. Durch gestrichelte Linien ist die Unterteilung des Systems in eine Ausgabeschicht 1, eine Systemverwaltungsschicht 2 und eine Transaktionsschicht 3 dargestellt.
Eine Zentralbankinstanz 10 gibt digitale Münzdatensätze 5 heraus. Die Zentralbankinstanz 10 fordert zudem eine initiale Registrierung des digitalen Münzdatensatzes 5 in einem Münzregister 20 der Zentralbank an. Münzverwaltungseinheiten 210, 220 können digitale Münzdatensätze austauschen und Registrierungsanforderungen an das Münzregister 20 senden.
In einem optionalen Transaktionsregister 25 werden Transaktionsdatensätze 7 gespeichert. Ein Transaktionsdatensatz 7 wird beispielsweise den Transaktionsbetrag, eine Transaktions-ID, Identifikatoren für Sender und Empfänger, hier der Münzverwaltungseinheit 210 als Sender und der Münzverwaltungseinheit 220 als Empfänger, und zumindest die Registerreferenz des übertragenen Münzdatensatzes 5 umfassen.
Das Münzregister 20 speichert zumindest für jeden gültigen digitalen Münzdatensatz 5 einen Registerdatensatz 6. Der Registerdatensatz 6 enthält beispielsweise den Betrag des Münzdatensatzes und eine Registerreferenz. Die Registerreferenz ist aus dem Münzdatensatz 5 ableitbar, erlaubt jedoch nicht die Bestimmung des Münzdatensatzes 5. In Fig. 1 enthält die von der Zentralbankinstanz 10 gesendete initiale Registrierungsanfrage den Registerdatensatz 6. In der Figur dargestellt ist, dass die erste Münzverwaltungseinheit 210 den digitalen Münzdatensatz 5 von der Zentralbankinstanz 10 erhält. Der digitale Münzdatensatz 5 kann jedoch auch mittelbar von der Zentralbank an eine Münzverwaltungseinheit eines Benutzers herausgegeben werden (z.b. über eine Geschäftsbank) oder von einer anderen Münzverwaltungseinheit empfangen worden sein.
Der digitale Münzdatensatz 5 kann von der ersten Münzverwaltungseinheit 210 direkt an die zweite Münzverwaltungseinheit 220 übertragen werden. Die zweite Münzverwaltungseinheit 220 kann die Gültigkeit des Münzdatensatzes 5 mit Hilfe des Münzregisters 20 prüfen. Es kann eine Gültigkeitsanfrage, welche die aus dem Münzdatensatz 5 ableitbare Registerreferenz und optional den Betrag enthält, an das Münzregister 20 senden. Das Münzregister 20 prüft, ob die Registerreferenz vorliegt und bestätigt gegebenenfalls, dass der Münzdatensatz 5 gültig ist. Alternativ erzeugt die Münzverwaltungseinheit 220 einen neuen Münzdatensatz und sendet an das Münzregister 20 eine Registrierungsanfrage, die zumindest die Registerreferenz des bisher gültigen Münzdatensatzes 5 und eine Registerreferenz des neuen Münzdatensatz umfasst. Im Münzregister 20 wird die Registrierungsanfrage geprüft. Im einfachsten Fall wird die Registerreferenz des neuen Münzdatensatzes registriert und die bisher gültige Registerreferenz gelöscht (oder als ungültig markiert).
Wenn eine Münzverwaltungseinheit 210, 220 einen betragsgleichen neuen Münzdatensatz erzeugt und den neuen Münzdatensatz anstelle des bisherigen Münzdatensatzes registriert, wird dies auch als Umschalten bezeichnet.
Münzverwaltungseinheiten 210, 220 können jedoch auch Münzdatensätze aufteilen oder verbinden, also aus mehreren bisher gültigen Münzdatensätzen einen neuen zu registrierenden Münzdatensatz erzeugen bzw. aus einem bisherigen Münzdatensatz mehrere zu registrierende Münzdatensätze erzeugen. Das Münzregister 20 prüft dann insbesondere ob die Registrierungsanforderung (mit den zugehörigen mehreren bisherigen oder neuen Registerreferenzen) betragsneutral ist. WO 2020/212331 Al beschreibt entsprechende Beispiele. Die vorliegende Lösung ist jedoch nicht an die dort beschriebene Maskierung des Betrages der Münzdatensätze oder die konkreten Protokolle der WO 2020/212331 Al gebunden, wie beispielsweise WO 2021/170646 Al zeigt.
Der in Fig.l dargestellte Ansatz ist insbesondere vorteilhaft, da weder das Münzregister 20 noch das Transaktionsregister 25 Münzdatensätze 5 umfassen müssen. DE 102020 004 121 Al beschreibt ein Transaktionsregister und dessen Absicherung näher.
Fig. 2 zeigt eine Münzverwaltungseinheit 210 mit seinen typischen Komponenten. Die Münzverwaltungseinheit 210 umfasst eine Ausführungseinheit 211 und zumindest einen Münzdatensatz 215. Die Ausführungseinheit 211 ist in der Regel als Software ausgestaltet und eingerichtet die gespeicherten Münzdatensätze zu verwalten (Münzdatensätze senden/ empfangen, Registrierungsanforderungen senden).
Weiterhin umfasst die Münzverwaltungseinheit 210 einen Identifikator 217 der Münzverwaltungseinheit 210. Identifikatoren 217 werden im Folgenden teils auch verkürzt als ID bezeichnet, beispielsweise als Sender-ID oder Empfänger-ID. Ein kryptographischer Schlüssel 218, ggf. ein asymmetrisches Schlüsselpaar, sowie ein Zertifikat 219 der Münzverwaltungseinheit 210 sind weitere Datenelemente der Münzverwaltungseinheit 210. Bevorzugt dient der kryptographische Schlüssel zur Authentisierung der Münzverwaltungseinheit 210 und/ oder zur Signatur von Daten, insbesondere im Rahmen einer Transaktion. Das Zertifikat 219 kann den Identifikator 217 und/ oder den Schlüssel 218, in der Regel den öffentlichen Schlüssel eines Schlüsselpaares 218, der Münzverwaltungseinheit 210 betreffen.
In den Fig. 1 bis 4 sind Datenelemente, beispielweise Münzdatensatz oder bedingte Transaktion, mit rechteckigen Kästchen dargestellt. Funktionale Einheiten, beispielsweise die Ausführungseinheit, sind mit abgerundeten Ecken dargestellt. Optionale Datenelemente oder Einheiten sind in der Regel mit gestrichelten Linien dargestellt.
Eine Münzverwaltungseinheit umfasst zumindest einen digitalen Münzdatensatz und eine Ausführungseinheit zur Verwaltung von Münzdatensätzen.
Fig. 3 zeigt eine Münzdepotverwaltungseinheit 30 mit mehreren
Münzverwaltungseinheiten 31, 310; 31, 320; 31, 330, die eine gemeinsame Ausführungseinheit 31 aufweisen, und eine Münzverwaltungseinheit 390 mit eigener Ausführungseinheit 391. Münzdepotverwaltungseinheiten umfassen Münzdepots unterschiedlicher Benutzer. In dem digitalen Zentralbankwährungssystems wird es eine Vielzahl von Münzverwaltungseinheiten geben. Zudem kann es eine Mehrzahl von Münzdepotverwaltungseinheiten geben.
Der Vollständigkeit halber sind in der Sy stem Verwaltungsschicht 2 der Fig. 3 neben einem Münzdatensatz 5, auch das Münzregister 20 der Zentralbank mit Registerdatensätzen 6 und das optionale Transaktionsregister 25 mit einem Transaktionsdatensatz 7 gezeigt.
Die Münzverwaltungseinheit 390 umfasst neben der Ausführungseinheit 391, mindestens einen Münzdatensatz 395, in der Regel mehrere Münzdatensätze, sowie mindestens zwei bedingte Transaktionen 396a, 396b, 396c mit unterschiedlichen Lese- und/ oder Schreibrechten 397a, 398a, 397b, 398b, 397c, 398c. Die Unterschiede sind in der Figur mittels Pfeilen angedeutet. Zwei bedingte Transaktionen können mit gleichen Schreibrechten und unterschiedlichen Leserechten, mit unterschiedlichen Schreibrechten und gleichen Leserechten oder mit unterschiedlichen Lese- und Schreibrechten ausgestaltet sein. Zusätzlich können auch - nicht dargestellte - bedingte Transaktionen vorhanden sein, welche gleiche Schreib- und Leserechte aufweisen.
Optionale Vorgaben 392, 393 könnten die Münzverwaltungseinheit 390 im Hinblick auf Transaktionen beschränken, nur beispielsweise: die Art der Transaktion, den Transaktionsbetrag oder den Transaktionspartner. Wie mit den drei Doppelpfeilen in beide Richtungen angedeutet ist, soll die Münzverwaltungseinheit 390 in diesem Beispiel jedoch zunächst weder durch seine Empfangsvorgabe 392 noch durch seine Sendevorgabe 393 hinsichtlich der Transaktionspartner beschränkt sein. Die Einhaltung der Vorgaben sowohl beim (direkten) Ausführen einer Transaktion als auch beim Erstellen einer bedingten Transaktion wird später - mit Bezug auf Figur 5 und 7 respektive - genauer beschrieben. Auch der Unterschied zwischen normalen, direkt auszuführenden, Transaktionen und den gespeicherten bedingten Transaktion, die erst ausgeführt werden, wenn ihre Bedingung erfüllt ist, kann anhand dieser beiden Figuren besser erkannt werden.
Die erste bedingte Transaktion 396a darf gemäß Leserecht 398a von jedem Dritten (insbesondere jeder Münzverwaltungseinheit oder jeder Münzdepotverwaltungseinheit) und natürlich vom Benutzer der Münzverwaltungseinheit gelesen werden. Dies ist mit drei nach rechts gerichteten Pfeilen angedeutet. Die zweite bedingte Transaktion 396b darf gemäß Leserecht 398b nur vom Benutzer und von einer oder mehreren bestimmten Münzverwaltungseinheiten (oder einer oder mehreren Münzdepotverwaltungseinheiten) gelesen werden. Dies wird mit den zwei nach rechts gerichteten Pfeilen angedeutet. Die dritte bedingte Transaktion 396c darf gemäß Leserecht 398c nur vom Benutzer ausgelesen werden, so dass nur ein nach rechts gerichteter Pfeil dargestellt ist.
Der Benutzer hat nur ein Schreibrecht 397a auf die erste bedingte Transaktion 396a.
Gemäß den Schreibrechten 397b und 397c der zweiten bzw. dritten bedingten Transaktion 396b und 396c darf niemand diese bedingten Transaktionen ändern. Dritte können keine der drei bedingten Transaktionen 396a-c ändern.
Die Münzdepotverwaltungseinheit 30 der Fig. 3 hat mehrere, hier drei, Münzdepots 310, 320 und 330 unterschiedlicher Benutzer und eine Ausführungseinheit 31 zur Verwaltung von Münzdatensätzen 315, 325, 335 der Münzdepots 310, 320, 330 des digitalen Zentralbankwährungssystems. Die Münzdepotverwaltungseinheit 30 wird in der Regel wesentlich mehr als drei, beispielsweise mehr als 100, Münzdepots umfassen.
Die Münzdepots 310, 320, 330 sind Münzdepotdatensätze. Die Münzdepots 310, 320, 330 bestehen aus Datenelementen, wie dem jeweils mindestens einen Münzdatensatz 315, 325, 335 sowie weiteren Datenelementen. Jedes Münzdepot 310, 320, 330 der Fig. 3 umfasst den mindestens einen Münzdatensatz 315, 325, 335. Die Münzdepots 310, 320, 330 können jeweils auch mehrere Münzdatensätze umfassen. Die entsprechenden Bezugszeichen, wie 315, 325, 335 und 395 in der Figur 3, sollen also einen oder mehrere Münzdatensätze der Münzverwaltungseinheit 31,310; 31,320; 31,330 und 390 darstellen.
In dem Münzdepot 310 ist keine bedingte Transkation enthalten. Eine bedingte Transaktion 316 könnte optional angelegt werden. Alternativ könnte eine Vorgabe des Münzdepots 310 jedoch auch ausschließen, dass bedingte Transaktionen in dem Münzdepot 310 gespeichert werden können.
Die Münzdepots 320, 330 enthalten jeweils zwei bedingte Transkation 326a, 326b und 336a, 336b. Die Schreib- und/ oder Leserechte 327a, 328a, 337a, 338a der ersten bedingten Transaktion 326a, 336a unterscheiden sich von den Schreib- und/ oder Leserechten 327b, 328b, 337b, 338b der zweiten bedingten Transaktion 326b, 336b.
Für das Münzdepot 330 mit dem mindestens einen Münzdatensatz 335, deuten die Pfeile wiederum die Rechte an. Auf die gespeicherte bedingte Transaktion 336b hat niemand schreibenden Zugriff - gemäß Schreibrecht 337b. Die bedingte Transaktion 336a kann dagegen geändert werden von genau einem Berechtigten - gemäß Schreibrecht 337a. Dieser Berechtigte ist im Regelfall der Benutzer, kann aber auch der Transaktionspartner sein. Beispielsweise im Fall einer Empfangs-Transaktion für das Münzdepot 330 könnte der Sender der Münzdatensätze, die in der bedingten Transaktion enthalten sind, das Schreibrecht haben. Auf diesem Weg könnte eine Münzverwaltungseinheit, die keine bedingten Transaktionen unterstützt oder - wie das Münzdepot 310 - durch eine Vorgabe keine bedingten Transaktionen speichern darf, dennoch eine bedingte Transaktion zusammen mit einem Transaktionspartner speichern.
Die zweite bedingte Transaktion 336b des Münzdepots kann nur der Benutzer lesen - gemäß Leserecht 338b. Ein Dritter, der bei der Münzdepotverwaltungseinheit 30 die vorhandenen bedingten Transaktionen des Münzdepots 330 anfragt, sieht also nur die erste bedingte Transaktion 336a. Die Leserechte 338a sind so gewählt, dass jede Münzverwaltungseinheit des Zentralbankwährungssystems die erste bedingte Transaktion 336a auslesen kann.
Für das Münzdepot 320 mit dem mindestens einen Münzdatensatz 325 deuten die Doppelpfeile an den Vorgaben 322, 323 an, wie die Vorgaben für die Münzverwaltungseinheiten bzw. Münzdepots in der Münzdepotverwaltungseinheit 30 gewählt sein können. Wie mit den Doppelpfeilen dargestellt, können sich beispielsweise Empfangsvorgaben 322 von Sendevorgaben 323 unterscheiden. Die Vorgaben können dabei Vorgaben des Herausgebers des Münzdepots und/ oder des Benutzers sein. Die Vorgaben können für das Münzdepot beispielsweise die Transaktionstypen, Funktionen der Ausführungseinheit, Empfänger, Sender oder Betragsgrenzen vorgeben. Das Münzdepot 320 kann beispielsweise Münzdatensätze von jeder Münzverwaltungseinheit als Sender empfangen (3 Doppelpfeile), aber nur Münzdatensätze an ausgewählte Empfänger senden (2 Doppelpfeile), die beispielsweise mit ihrer ID oder als Gruppe, in der Sende-Vorgabe 323 enthalten sind. Die Sende-Vorgabe 323 des Münzdepot 320 beschränkt das Münzdepot 323 somit auf das Senden von Münzdatensätzen (Sende-Vorgabe) an bestimmte Empfänger. Das Münzdepot 320 ist also unbeschränkt im Hinblick auf die Sender und teilbeschränkt im Hinblick auf Empfänger.
Zugunsten der Lesbarkeit sind die Vorgaben der weiteren Münzdepots nicht in Figur 3 dargestellt. Die Vorgaben der Münzdepots 310, 320, 330 der
Münzdepotverwaltungseinheit 30 werden sich voneinander unterscheiden, auch wenn einige Münzdepots natürlich einheitliche Vorgaben enthalten können. Die Ausführungseinheit 31 prüft die Vorgabe des jeweiligen Münzdepots 310, 320, 330, bevor es eine Transaktion ausführt, also insbesondere einen Münzdatensatz des jeweiligen Münzdepots 310, 320, 330 sendet oder einen empfangenen Münzdatensatz in dem Münzdepot 310, 320, 330 speichert. Die Vorgaben werden ebenfalls geprüft, bevor die bedingte Transaktion gespeichert wird.
Jedes Münzdepot 310, 320, 330 hat seine eigene ID, also den Identifikator (ID) der Münzverwaltungseinheit, und umfasst optional auch seine Schlüssel und/ oder seine Zertifikate. Alternativ oder ergänzend können, insbesondere geheime, Schlüssel und/ oder Zertifikate auch von der Münzdepotverwaltungseinheit bereitgestellt werden.
Jedes der Münzdepots 310, 320 und 330 ist einem Benutzer zugeordnet. Die Zuordnung des Münzverwaltungseinheiten-ID zu dem Benutzernamen wird jedoch vorzugsweise nicht in dem Münzdepot gespeichert, sondern in einer münzdepot-externen Datenstruktur (welche den ID zusammen mit dem vollständigen Namen des Benutzers enthält, ein sogenanntes Tupel). Die Münzdepotverwaltungseinheit 30 umfasst hier drei Münzdepots 310, 320, 330 von unterschiedlichen Benutzern.
Es ist denkbar dass nicht beschränkende Vorgaben wie die Vorgaben 392, 393 und 322 entweder explizit kodiert werden (beispielsweise durch: oder „alle" für beliebigen IDen) oder entfallen (keine Vorgabe => keine Beschränkung).
Eine Sende- oder eine Empfangs-Vorgabe muss nicht nur genau einen ID, oder mehrere IDen umfassen, sondern kann auch Gruppen von IDen oder Mischungen aus Gruppen und einzelnen IDen umfassen. Eine Gruppe von IDen kann beispielsweise mit einer ID- Maske angegeben werden. Die ID-Maske gibt nur Anteile eines IDs vor, die übereinstimmen müssen, wie beispielsweise „ABC??1311560*". So können beispielsweise alle IDen, die einen bestimmten Anfangsanteil und/ oder Mittelanteil (im Beispiel Anfang „ABC" und Mitte „1311560") aufweisen zulässig sein, unabhängig von den konkreten Werten in weiteren Anteilen (im Beispiel den zwei Zeichen „??" oder einer am Ende des ID folgenden Seriennummer) des jeweiligen ID.
Ein Herausgeber von Münzdepots 310, 320, 330 könnte in einem Beispiel für einen Benutzer ein Münzdepot 330 mit Münzdatensätzen 335 bereitstellen und vorab in einer Sende-Vorgabe des Herausgebers den einzig zulässigen Empfänger oder eine einzige zulässige Empfängergruppe festlegen. Mit Bezug auf Fig. 4 sollen die Komponenten der Münzdepotverwaltungseinheit 30 genauer betrachtet werden. Fig. 4 zeigt eine Münzdepotverwaltungseinheit 30, eine Benutzereinheit 40, eine Herausgeberinstanz 50 sowie eine weitere Münzverwaltungseinheit 390. Die weitere Münzverwaltungseinheit 390 kann der Münzverwaltungseinheit 390 aus Fig. 3 entsprechen, alternativ könnte sie aber auch jede andere Münzverwaltungseinheit, also auch eine Münzverwaltungseinheit einer weiteren Münzdepotverwaltungseinheit, sein.
Die Münzdepotverwaltungseinheit 30 umfasst Münzdepots 410, 420, 430 und die Ausführungseinheit 31. Der Münzdepotdatensatz des Münzdepots 430 ist ausführlicher dargestellt, er enthält genau einen oder mehrere Münzdatensätze 435 sowie optional Vorgaben 432, 433.
In dem Münzdepot 330 enthalten sind als optionale, aber in der Regel vorhandene, Datenelemente beispielsweise ein Identifikator 237, zumindest ein Schlüssel 238 und ein Zertifikat 239 (hier das Zertifikat der Münzverwaltungseinheit, gebildet durch das Münzdepot 430 und die Ausführungseinheit 31 der Münzdepotverwaltungseinheit 30).
Die Vorgaben umfassen Herausgeber-Vorgaben 432 und Benutzer-Vorgaben 433. Die Herausgeber-Vorgaben 432 sind vom Herausgeber des Münzdepots fest vorgegeben. Sie können bereits in einer Münzdepot- Anforderung 402 enthalten sein. Die Benutzer- Vorgaben 433 sind dagegen vom Benutzer frei wählbar, zumindest sofern sie enger sind als eine (möglicherweise vorhandene gleichartige) Herausgeber-Vorgabe 432.
Ausgehend von einer vollbeschränkenden Herausgeber-Vorgabe, wie beispielsweise „kein Senden" oder „kein Empfangen", hat der Benutzer keine Wahlfreiheit mehr. Ausgehend von einer unbeschränkten (ggf. nicht vorhandenen) funktionelle Vorgabe des Herausgebers, wie „Senden an alle" und/ oder „Empfangen von allen", kann der Benutzer eine Benutzer-Vorgabe vollkommen frei wählen. Ausgehend von einer teilbeschränkenden funktionellen Vorgabe des Herausgebers, wie „Senden nur an ID- Gruppe 1 oder an ID-Gruppe 2" kann der Benutzer eine engere Benutzer-Vorgabe wählen, wie „Senden nur an ID1 aus ID-Gruppel oder an ID2 aus ID-Gruppel".
Die Münzdepotverwaltungseinheit 30 kann eine Münzdepot-Erstellungseinheit 32 umfassen, welche eine Münzdepot- Anforderung 402 von der Herausgeber-Einheit 50 verarbeiten kann. Die Münzdepotverwaltungseinheit 30 kann eine Benutzervorgaben-Einheit 33 umfassen, welche eine Konfigurations-Anforderung 403 von der Benutzer-Einheit 40 verarbeiten kann. Ein Benutzer kann von seiner Benutzer-Einheit 40, wie Mobilfunkgerät, PC oder Terminal, die Konfigurations-Anforderung 403 an die Münzdepotverwaltungseinheit 30 senden.
Die Benutzervorgaben-Einheit 33 prüft insbesondere, ob die in der Konfigurations- Anforderung 403 enthaltenen, vom Benutzer gewählten Vorgaben 433 für sein Münzdepot 430 enger sind als die vorhandenen Herausgeber-Vorgaben 432 des Münzdepots 430. In diesem Fall werden die Vorgaben in der Konfigurations- Anforderung 403 als Benutzer-Vorgaben 433 in dem Münzdepot 430 gespeichert. In der Münzdepotverwaltungseinheit 30 kann die Benutzer-Vorgabe 433 stets enger sein als die Herausgeber-Vorgabe 432 und die Beschränkungen der Herausgeber-Vorgabe 432 umfassen. Es ist dann ausreichend, dass die Ausführungseinheit 31 die Benutzer- Vorgabe 433 prüft. Bei Angabe der zulässigen Empfänger und/ oder Sender in der funktionellen Vorgabe 432, 433 ist diese Variante bevorzugt. Andererseits kann die Ausführungseinheit 31, bevorzugt für andere Vorgaben oder Kodierungen, auch eingerichtet sein, stets beide Vorgaben 432, 433 zu prüfen. Die Benutzer-Vorgabe 433 muss dann nicht die eventuell vorhandenen Beschränkungen der Herausgeber-Vorgabe 432 umfassen. Die Verwaltung der Benutzervorgabe(n) 433 kann somit vereinfacht werden.
Das Münzdepot 330 kann als neues Münzdepot auf die Anforderung 402 der Herausgeber-Einheit 50 erstellt werden bzw. worden sein. Die Münzdepot- Anforderung 402 enthält als Datenelement zumindest eine, in der Regel mehrere, Herausgeber-Vorgaben 432 für das neue Münzdepot 330. Ein entsprechendes Verfahren wird später mit Bezug auf Fig. 6 näher beschrieben.
Die Ausführungseinheit 31 ist eingerichtet die Münzdatensätze der Münzdepots 410, 420, 430 in Transaktionen 405, 406 mit anderen Münzverwaltungseinheiten von anderen Benutzern des Zentralbanksystems auszutauschen und (in Fig. 4 nicht dargestellte) Registrierungsanforderungen an das (in Fig. 4 nicht dargestellte) Münzregister 20 zu senden.
Der Benutzer kann von seiner Benutzereinheit 40 eine Transaktions-Anforderung 401 an die Münzdepotverwaltungseinheit 30 senden. Ein entsprechendes Verfahren zur Verarbeitung der Transaktions- Anforderung 401 wird für den Fall des Sendens eines Münzdatensatzes, Sende-Transaktion 405, mit Bezug auf Fig. 5 beschrieben. Die Transaktions-Anforderung 401 ist eine Transaktionsanfrage der Benutzereinheit 40 des Benutzers, welche insbesondere anhand eines Authentisierungs-Datenelements oder einer vorangehenden Authentisierung der Benutzereinheit 40 als Anfrage des Benutzers erkennbar ist. Die Ausführungseinheit 31 prüft die Vorgaben 432, 433 bevor die Sende-Transaktion 405 abhängig vom Prüfungsergebnis ausgeführt wird (oder nicht). Ebenfalls zu Fig. 5 wird die Prüfung der Vorgaben im Falle des Empfangs von Münzdatensätzen (Empfangs-Transaktion 406) beschrieben.
Die Vorgaben 432,433 können nicht nur Richtungsvorgaben (Senden/ Empfangen) sein, sondern beispielsweise auch Vorgaben für bedingte Transaktionen oder Vorgaben für Transaktionen mit Gegenleistung sein.
In dem Münzdepot 430 oder münzdepotübergreifend sind bedingte Transaktionen 436 gespeichert, die sich in ihren Leserechten 438 und/ oder Schreibrechten 437 unterscheiden. Die bedingten Transaktionen werden auf Anfrage gespeichert und später - nachdem die Bedingung erfüllt ist - wird eine Transaktion, die der gespeicherten bedingten Transaktion entspricht, ausgeführt. Ein entsprechendes Verfahren wird genauer beschrieben mit Bezug auf Fig. 7.
Die Münzdepotverwaltungseinheit 30 umfasst eine Benutzerzugriffs-Einheit für bedingte Transaktionen 34 sowie eine Drittzugriffs-Einheit für bedingte Transaktionen 39. Die Einheiten 34, 39 sind separat dargestellt, können jedoch als Zugriffseinheit für bedingte Transaktionen 34, 39 ausgebildet sein oder als Untereinheiten der Ausführungseinheit 31 ausgebildet sein.
Der Benutzer kann eine, mehrere oder alle bedingten Transaktionen 436 auslesen 408. Die Benutzer-Einheit 40 sendet eine entsprechende Leseanfrage des Benutzers und die Benutzerzugriffs-Einheit für bedingte Transaktionen 34 prüft die Zugriffsrechte 438 der auszulesenden bedingten Transaktionen 436. Der Benutzer kann eine bedingte Transaktionen 436 ändern 409. Die Benutzer-Einheit 40 sendet eine entsprechende Änderungsanfrage des Benutzers und die Benutzerzugriffs-Einheit für bedingte Transaktionen 34 prüft die Zugriffsrechte 437 der zu schreibenden (bereits gespeicherten) bedingten Transaktionen 436. Der Benutzer kann beispielsweise alle bedingten Transaktionen 436 auslesen, jedoch nur bestimmte bedingte Transaktionen 436 ändern. Dritte, wie die dargestellte weitere Münzverwaltungseinheit 390, können ebenfalls bedingte Transaktionen auslesen 409. Sie können eine Leseanfrage für eine, mehrere oder alle (für sie lesbaren) bedingten Transaktionen senden. Die Drittzugriffs- Einheit 39 prüft die Leserechte 438 der bedingten Transaktionen 436 für den Dritten. Für den Driten werden nur die bedingten Transaktionen 436 ausgelesen, für welche die entsprechenden Leserechte 438 vorliegen. Es wäre denkbar, dass alle bedingten Transaktionen 436, in denen der Dritte Transaktionspartner ist oder sein könnte (Gruppenangaben), entsprechende Leserechte haben. Bevorzugt darf ein Driter jedoch aus der Gruppe der bedingten Transaktionen 436, in denen er als Transaktionspartner genannt ist (mit seiner ID) oder der Transaktionspartner sein könnte (Gruppenangabe), auch nur bestimmte bedingte Transaktionen 436 lesen.
Ein Schlüsselverwaltungsmodul 38 der Münzdepotverwaltungseinheit 30 ist vorzugsweise ein Hochsicherheitsmodul für kryptographische Schlüssel. Das Schlüsselverwaltungsmodul 38 kann geheime Schlüssel der Münzdepots 410, 420, 430 speichern. Der im Münzdepot 430 gespeicherte Schlüssel 338 der Münzdepotverwaltungseinheit 30 ist beispielsweise ein öffentlicher Schlüssel eines asymmetrischen Schlüsselpaares. Der zugehörige geheime Schlüssel wird in dem Schlüsselverwaltungsmodul 38 gespeichert (und nur in diesem verwendet). Das Schlüsselverwaltungsmodul 38 verschlüsselt, authentisiert oder signiert beispielsweise Daten für die Ausführungseinheit 31 mit dem geheimen Schlüssel des Münzdepots. Für diese unterschiedlichen Zwecke können eigene Schlüsselpaare vorgesehen sein. Das Schlüsselverwaltungsmodul 38 kann ferner abgeleitete Schlüssel, wie Sitzungsschlüssel, erstellen und der Ausführungseinheit 31 bereitstellen.
Neben der Verwaltung der Transaktionsschlüssel (für die Transaktionen benötigte Schlüssel) kann das Schlüsselverwaltungsmodul 38 auch für die verschlüsselte Speicherung der Münzdepotdatensätze verwendet werden.
Die Datensätze der Münzdepots 410, 420, 430 (Münzdepotdatensätze) werden vorzugsweise verschlüsselt in der Münzdepotverwaltungseinheit 30 gespeichert. Bei Bedarf, also beispielsweise bei einer Transaktions- oder Konfigurations-Anforderung für das Münzdepot 430, wird das entsprechende Münzdepot 410, 420, 430 entschlüsselt. Es wird jeweils nur das benötigte Münzdepot 430 entschlüsselt, wobei insbesondere ein für das Münzdepot 430 individueller Schlüssel verwendet werden kann. Das Schlüsselverwaltungsmodul 38 kann beispielsweise das Entschlüsseln (und ein späteres wieder Verschlüsseln) ausführen. Wenn das Schlüsselverwaltungsmodul 38 einen Ableitungsschlüssel (optional gemeinsam für mehrere Münzdepots) enthält, kann es alternativ den abgeleiteten Schlüssel für die Entschlüsselung/ Verschlüsselung des Münzdepots 430 der Ausführungseinheit 31 bereitstellen. Münzdepotverwaltungseinheit 30 prüft für die bedingten Transaktionen der Münzdepots 410, 420, 430, ob die darin enthaltene Bedingung erfüllt ist. Es kann eine Bedingungs-Prüfeinheit 37 in der Münzdepotverwaltungseinheit 30 vorgesehen sein. Die Bedingungs-Prüfungseinheit 37 prüft - insbesondere laufend, in regelmäßigen zeitlichen Abständen oder in Antwort auf ein externes Ereignis, wie ein Auslöser- Ereignis 404 - ob eine Bedingung (wie: Zeitpunkt, Datum, Grenzwert überschritten, externes Ereignis, Anfrage empfangen) der bedingten Transaktion 436 erfüllt ist. Optional kann sie eine Prüfliste 36 verwenden, in welcher zumindest die zu prüfenden Bedingungen der bedingten Transaktionen der Münzdepots 410, 420, 430 der Münzdepotverwaltungseinheit 30 gespeichert sind. Nicht nur wenn die Münzdepotdaten verschlüsselt gespeichert sind, vereinfacht die Prüfliste 36 das Prüfen der Bedingungen. Ist die Bedingung einer bedingten Transaktion erfüllt, wird eine Transaktion ausgeführt, die der bedingten Transaktion entspricht.
Um eine Transaktion mit Gegenleistung ausführen zu können, umfasst die Münzdepotverwaltungseinheit 30 eine (nicht in der Figur dargestellte) Gegenleistungseinheit. Die Gegenleistungseinheit erzeugt beispielsweise Antwortdaten, die als Gegenleistung für einen (oder mehrere) in einer Empfangs- Transaktion 406 empfangenen Münzdatensatz in einer Antwort zu senden sind. Die Gegenleistungseinheit stellt eine Gegenleistung bereit, die beispielsweise in Gegenleistungsdaten des Münzdepots 430 einstellbar ist. Alternativ oder ergänzend soll vorliegend eine Gegenleistung in einer bedingten Transaktion angegeben werden können. Die Gegenleistungsvorgaben könnten die für das Münzdepot 430 zulässigen Gegenleistungsfunktionen beschränken. Ausgehend von den in der Gegenleistungseinheit verfügbaren Gegenleistungsfunktionen, werden also für das Münzdepot 430 selektiv bestimmte Gegenleistungsfunktionen, -kodierungen oder - subtypen ausgeschlossen.
Alle zu Fig. 4 beschriebenen Aspekte, die nicht spezifisch für die Verwaltung von Münzdepots unterschiedlicher Benutzer sind, können auch in einer Münzverwaltungseinheit mit eigener Ausführungseinheit vorliegen (nur beispielsweise die Einheiten 34, 36, 37 und 39 oder mehrere Münzdepots mit eigenen IDen).
Fig. 5 zeigt den Verfahrensablauf 501 bis 518 in der Münzdepotverwaltungseinheit 30 nach Empfang einer Transaktions-Anforderung 501 von einem Benutzer (bzw. dessen Benutzereinheit 40) sowie den Verfahrensablauf 551 bis 568 beim Empfangen von Münzdatensätzen von einer Münzverwaltungseinheit 390. Die Transaktions-Anforderung 501 umfasst einen ID eines Münzdepots 430 in der Münzdepotverwaltungseinheit 30 und fordert das Senden eines Betrages von dieser Sender-ID an eine Empfänger-ID an. Die sichere Ausführungseinheit 31 der Münzdepotverwaltungseinheit 30 liest in Schritt 502 den Münzdepotdatensatz des Münzdepots 430 mit der Sender-ID. Bevorzugt stellte das Schlüsselverwaltungsmodul 38 der Ausführungseinheit 31 entweder den Entschlüsselungsschlüssel, der individuell für das Münzdepot 430 anhand dem ID gewählt ist, bereit oder den bereits entschlüsselten Münzdepotdatensatz bereit. In den Schritte 503, 504, 506 führt die Ausführungseinheit 31 mehrere Prüfungen aus, bevor es die angeforderte Transaktion in den Schritte 507 bis 516 ausführt. Fig. 5 zeigt die bevorzugte Reihenfolge der Prüfungsschritte. Zunächst wird eine Authentisierung geprüft 503, in der Regel die Authentisierung des Benutzers. Ein entsprechender Authentisierungswert kann in der Transaktions-Anforderung 501 enthalten sein oder in Schritt 503 separat angefordert und empfangen werden.
Zumindest eine (der) Vorgabe(n) 432, 433 des Münzdepots 430 mit dem ID wird in Schritt 504 geprüft. Im vorliegenden Beispiel einer einfachen Sende-Transaktion, wird geprüft, ob die Empfänger-ID, eine ID gemäß Sende-Vorgaben in der Herausgeberund/ oder Benutzervorgaben 432, 433 ist. Ist das Münzdepot 330 gemäß Herausgeber- Vorgabe 432 in Empfangsrichtung unbeschränkt oder ist die Herausgeber-Vorgabe 432 in Empfangsrichtung erfüllt, wird die Benutzervorgabe 433, die beispielsweise eine ID- Gruppe und zwei IDs von Empfängern umfasst, geprüft. Entspricht die Empfänger-ID der Transaktions- Anfrage nicht den Vorgaben 432, 433, wird die Transaktions- Anforderung 501 abgelehnt, der Benutzer 40 erhält eine Ablehnungsnachricht 505. Ist die Empfänger-ID dagegen zulässig, weil sie eine ID aus der ID-Gruppe ist oder einer der beiden IDs von Empfängern in der Benutzervorgabe 334a entspricht, wird das Verfahren fortgesetzt (und die Transaktion ausgeführt). In Schritt 506 wird geprüft, ob der Depotbetrag, Betrag des Münzdatensatzes 435 im Münzdepot 430 oder Summe der Beträge der Münzdatensätze 435 im Münzdepot 430, größer ist als der angeforderte Betrag.
Vorzugsweise sendet die Münzdepotverwaltungseinheit 30 in Transaktionen genau einen Münzdatensatz, dessen Betrag dem Transaktionsbetrag entspricht, anstatt den Transaktionsbetrag als Summe von Beträgen mehrerer Münzdatensätze zu senden. Entspricht der angeforderte Betrag dem Betrag eines im Münzdepot vorhandenen Münzdatensatzes, entfallen die nächsten Schritte 507 bis 509. In Schritt 507 wird ein neuer Münzdatensatz erstellt, dessen Betrag dem angeforderten Betrag entspricht. Bevorzugt wird ein vorhandener Münzdatensatz aufgeteilt in den neuen Münzdatensatz und einen weiteren Münzdatensatz (Betrag = Differenz aus Betrag des vorhandenen Münzdatensatzes und Transaktionsbetrag). Alternativ könnten zwei oder mehr vorhandene Münzdatensätze zu dem neuen Münzdatensatz (und optional einem oder mehreren weiteren Münzdatenätzen) verbunden werden. Eine Registrierungsanforderung 508 wird für den neuen Münzdatensatz (bzw. dessen Registerreferenz) an das Münzregister 20 gesendet. Das Münzregister 20 bestätigt 509 die Registrierung.
Die Ausführungseinheit 31 erstellt in Schritt 510 nun eine Transaktionsnachricht 511, die an die Münzverwaltungseinheit 220 mit der Empfänger-ID, insbesondere eines anderen Benutzers des Zentralbanksystems gesendet wird. Die Transaktionsnachricht 511 umfasst eine Transaktions-ID, die ID des Münzdepots 430, die ID der anderen Münzverwaltungseinheit 220 als Empfänger-ID und den neuen Münzdatensatz. Optional enthält die Transaktionsnachricht 511 einen Transaktionsbezugstext, der in der Regel aus der Transaktions- Anfrage 501 stammt, und/oder einen Authentisierungswert, der für die Transaktion mit Hilfe des geheimen Schlüssels des Münzdepots 430 erzeugt ist. Vorzugsweise wird in der Transaktion, insbesondere also in Schritt 511, eine gegenseitige Authentisierung der beiden beteiligten Münzverwaltungseinheiten (430,31; 220) vorgenommen. Der Schritt 510 des Erstellens und Sendens der Transaktionsnachricht 511 kann optional bzw. alternativ in mehreren Teilschritten mit einer Mehrzahl von ausgetauschten Teilnachrichten (nur beispielsweise für die Authentisierung) ablaufen.
Die andere Münzverwaltungseinheit 220 erzeugt optional einen eigenen Münzdatensatz, der insbesondere betragsgleich mit dem empfangenen, neuen Münzdatensatz ist, sendet eine Registrierungsanfrage 512 für seinen eigenen Münzdatensatz an das Münzregister 20 und erhält daraufhin eine Registrierungsbestätigung 513 von dem Münzregister 20. Die Münzverwaltungseinheit 210 sendet eine Transaktionsbestätigung 514 an die Münzdepot-Verwaltungseinheit 30.
In Schritt 515, also vorzugsweise erst nach Erhalt der Transaktionsbestätigung 514, speichert die Ausführungseinheit 31 die geänderten Münzdepotdaten des Münzdepots 430 ab. Eine münzdepotindividuelle Verschlüsselung der Münzdepotdaten kann, wie zuvor beschrieben - wiederum optional mit Hilfe des Schlüsselverwaltungsmoduls 38 - erfolgen. Eine Transaktionsbestätigung 516 kann an den Benutzer 40 gesendet werden. In bevorzugten Varianten wird in Schritt 517 ein Transaktionsregisterdatensatz 518 erstellt und an das Transaktionsregister 25 gesendet.
Vorzugsweise wird für die Transaktions-Anfrage 501 und/ oder die Transaktionsnachricht 511 ein JSON-Format verwendet. Bevorzugt wird für Nachrichten innerhalb der Transaktionsschicht 3 ein erstes, einheitliches Format, insbesondere das JSON-Format, verwendet. Es ist jedoch anzumerken, dass die Inhalte der Transaktions-Anfrage 501 und/ oder die Transaktionsnachricht 511 auch getrennt voneinander übertragen werden können. Beispielsweise kann ein Authentisierungswert erst in Schritt 503 oder eine Empfänger-ID erst in Schritt 504 übertragen werden und/ oder kann zunächst eine Authentisierung der Münzverwaltungseinheit 220 (oder eine gegenseitige Authentisierung) ausgeführt werden, bevor ein Münzdatensatz ausgetauscht wird.
Der zweite in Fig. 5 gezeigte Ablauf wird durch den Empfang einer Transaktionsnachricht 551 bzw. Empfangs-Transaktion von einer Münzverwaltungseinheit 390 ausgelöst. Die Transaktionsnachricht 551 enthält zumindest eine ID eines Münzdepots in der Münzdepot-Verwaltungseinheit 30 sowie mindestens einen Münzdatensatz. Die Münzverwaltungseinheit 390 will also einen Münzdatensatz an das Münzdepot senden. Die sichere Ausführungseinheit 31 prüft jedoch wiederum, ob die Transaktion den Vorgaben des Münzdepots entspricht.
Zunächst werden die Münzdepotdaten des Münzdepots mit der angegebenen ID gelesen 552. Das Fesen 552 der Münzdepotdaten wird - wie zuvor - ein Entschlüsseln umfassen. Optional wird eine Authentisierung der Münzverwaltungseinheit 390 geprüft oder eine gegenseitige Authentisierung ausgeführt. Nun prüft 554 die sichere Ausführungseinheit 31, die Vorgaben des Münzdepots. Ist für das Münzdepot das Empfangen beispielsweise vollständig beschränkt, wird die Transaktionsnachricht 551 abgelehnt. Im Beispiel sei für das Münzdepot das Empfangen jedoch durch eine Sender-Vorgabe des Herausgebers teilbeschränkt. Die sichere Ausführungseinheit 31 prüft also, ob die ID der Münzverwaltungseinheit 390 die Sender-Vorgabe des Herausgebers für das Münzdepot erfüllt. Im Negativfall wird die Transaktion abgelehnt, im Positivfall die Transaktion ausgeführt. Bevorzugt erzeugt die sichere Ausführungseinheit 31 einen eigenen Münzdatensatz unter Verwendung des empfangenen Münzdatensatzes. Sie kann einen eigenen betragsgleichen Münzdatensatz erzeugen 557 und, durch Registrierungsanforderung 558 und Registrierungsbestätigung 559, beim Münzregister registrieren. Die Münzdepotdaten des Münzdepots werden (verschlüsselt) gespeichert 565 und eine Transaktionsbestätigung 566 an die Münzverwaltungseinheit 390 gesendet. Optional kann auch ein Empfänger von Münzdatensätzen in dem digitalen Zentral-Bank- Währungssystem verpflichtet sein, einen Transaktionsregisterdatensatz zu erzeugen 567 und an das Transaktionsregister 25 zu senden 568.
Fig. 6 zeigt den Ablauf eines Verfahrens zur Erstellung eines neuen Münzdepots.
Ein Herausgeber 50 des neuen Münzdepots sendet eine Münzdepotanforderung 601 an die Münzdepot-Verwaltungseinheit 30. Die Münzdepot-Erstellungseinheit 32 der Münzdepot-Verwaltungseinheit 30 verarbeitet die Münzdepotanforderung 601 und legt das neue Münzdepot an. Zunächst wird die Authentisierung des Herausgebers geprüft 602. Scheitert die Prüfung der Authentisierung, beispielsweise weil der Anfragende kein Herausgeber, sondern ein Benutzer ist, wird die Anfrage abgelehnt (bzw. kein neues Münzdepot) erstellt. Die Münzdepot-Verwaltungseinheit 30 umfasst eine Vielzahl von Münzdepots, die unterschiedlichen Benutzern zugeordnet sind. Die Münzdepots umfassen unterschiedliche Vorgaben, insbesondere unterschiedliche funktionelle Vorgaben. Die Vielzahl von Münzdepots ist von einer Mehrzahl von Herausgebern erstellt worden. Die Vielzahl M der Münzdepots liegt in der Größenordnung einer Vielzahl B der Benutzer (M = a*B, beispielsweise mit 1 < a < 9 für 1 bis 9 Münzdepots pro Benutzer). Die Vielzahl der Münzdepots M ist um Größenordnungen größer als die Mehrzahl H der Herausgeber: M » H (beispielsweise: M = b*H mit b> 50, vorzugsweise >100).
In Schritt 603 wird ein Münzdepotdatensatz für das neue Münzdepot erstellt. Die Datenelemente des erstellten Münzdepotdatensatzes sind zunächst leer und/ oder mit einem Standardwert belegt. In dem Schritt des Erstellens 603 des Münzdepotdatensatzes kann der individuelle Verschlüsselungsschlüssel für das Münzdepot bereitgestellt werden, insbesondere von dem Schlüsselverwaltungsmodul 38. Die Datenelemente, wie Vorgaben und Münzdatensätze, oder insbesondere auch Identifikator, Schlüssel und/ oder Zertifikat, werden nun in weiteren Schritten 604 - 608 bereitgestellt oder aus der Münzdepotanforderung 601 übernommen.
Eine (oder mehrere) in der Münzdepotanforderung 601 enthaltene Vorgabe(n) des Herausgebers werden als Herausgeber-Vorgabe(n) in dem Münzdepotdatensatz gespeichert. Zunächst wird ein Identifikator für das neue Münzdepot in der Münzdepot- Verwaltungseinheit 30 erzeugt 604. Das neue Münzdepot bildet zusammen mit der sicheren Ausführungseinheit 31 eine neue Münzverwaltungseinheit. Identifikatoren sind in dem System Münzverwaltungseinheiten zugeordnet. Der Identifikator ist insbesondere als URI, Unified Ressource Identifier, oder URN, Unified Ressource Name, (einheitlicher Ressourcenname) gestaltet und enthält eine systemweit eindeutige ID (UUID). Ein Identifikator als URN hat beispielsweise folgendes Format: „münzverwaltungseinheit:meine-münzdepot-bank.com:UUID". Eine UUID kann als Identifikator oder als Teil einer URN verwendet werden. Die UUID ist gemäß RFC 4122 kodiert. Sie umfasst entsprechend ein Halfbyte M, welches eine Version der UUID angibt, und ein Halfbyte N, welches eine Variante der UUID angibt. Nun werden weitere Bits der UUID verwendet, um eine funktionelle Vorgabe zumindest teilweise zu kodieren. Dabei können beispielsweise Bits der Halfbytes S und/ oder V verwendet werden: „xxxxxxxx-xxxx-Mxxx-Nxxx-SVxxxxxxxxxx", die ansonsten mit Zufallszahlen belegt wären. In einem ersten Bit der UUID wird kodiert, dass das Münzdepot in einer Münzdepot-Verwaltungseinheit vorliegt. In einem zweiten Bit der UUID wird kodiert, ob eine richtungsbezogene funktionelle Vorgabe vorliegt („0": keine Richtungsvorgabe, „1": „Richtungsvorgabe"). In einem dritten Bit der UUID wird kodiert, ob bedingte Transaktionen zulässig sind („0": „keine bedingten Transaktionen" oder „1: bedingte Transaktionen zulässig"). In einem vierten Bit der UUID könnte optional kodiert sein, ob eine Gegenleistung zulässig ist („0": keine Gegenleistung zulässig, „1" Gegenleistung zulässig). Für herkömmliche Münzverwaltungseinheiten könnten die 3 Bits der UUID somit auf „000" gesetzt werden.
Für das neue Münzdepot soll gemäß Münzdepotanforderung 601 das Senden auf zwei verschiedene Empfängergruppen beschränkt sein, eine genannte Variante von bedingten Transaktionen zulässig sein, die eine Gegenleistung umfassen kann. Die drei Bits der UUID sind daher für das neue Münzdepot auf „111" gesetzt. Erwartungsgemäß wird für die Mehrzahl der Münzdepots in der Münzdepot- Verwaltungseinheit 30 nur eine (oder mehrere) Richtungsvorgabe existieren, bedingte Transaktionen oder Gegenleistungen jedoch unzulässig sein. Für die meisten Münzdepots wären also, in ihrer URN bzw. UUID, die drei Bits mit „100" kodiert.
In einem weiteren Schritt wird zumindest ein Schlüssel für das Münzdepot bereitgestellt bzw. erzeugt. Erzeugt wird, vorzugsweise vom Schlüsselverwaltungsmodul, ein Schlüsselpaar, umfassend einen öffentlichen Schlüssel und einen geheimen Schlüssel. Der geheime Schlüssel kann optional in dem Schlüsselverwaltungsmodul verbleiben. Alternativ wird er in verschlüsselter Form in dem (ggf. zusätzlich verschlüsselten) Münzdepot gespeichert. Der öffentliche Schlüssel wird in dem Münzdepot gespeichert. Der Schlüssel bzw. das Schlüsselpaar dient vorzugsweise der Authentisierung der neuen Münzverwaltungseinheit.
In einem weiteren Schritt 606 wird ein Zertifikat für das Münzdepot erstellt. Das Zertifikat umfasst zumindest die ID und/ oder den öffentlichen Schlüssel des Münzdepots. Zertifikate bestätigen für Dritte die Echtheit der enthaltenen Datenelemente. Das Zertifikat ist - ebenso wie die ID oder der öffentliche Schlüssel - ein zur Weitergabe an Dritte, wie andere Münzverwaltungseinheiten, vorgesehenes (öffentliches) Datenelement des Münzdepotdatensatzes. Die funktionellen Vorgaben zu Gegenleistungen sind daher nicht in dem Zertifikat enthalten. Auch die genaue Beschränkung in Sende- und Empfangsrichtung, also hier die beiden zulässigen Empfängergruppen, werden als interne Information behandelt. In dem Zertifikat enthalten ist jedoch ein (weiterer) Teil der funktionellen Vorgaben. Das Zertifikat enthält beispielsweise die Angabe, dass das Münzdepot in Empfangsrichtung unbeschränkt ist („keine Sender-Vorgabe") und in Senderichtung teilbeschränkt ist.
Optional empfängt 607 die sichere Ausführungseinheit 31 einen oder mehrere Münzdatensätze für das neue Münzdepot. Die sichere Ausführungseinheit wird - wie zuvor bereits beschrieben - für den/ die empfangenen Münzdatensatz/ -sätze einen eigenen (oder mehrere eigene) Münzdatensatz (-sätze) erzeugen 608. Sie sendet eine Registrierungsanforderung an das Münzregister 609 und erhält eine Bestätigung 610 für die Registrierung des/ der eigenen Münzdatensatzes/ Münzdatensätze im Münzregister 20. In der Regel werden betragsgleiche eigene Münzdatensätze erzeugt und registriert (umschalten). Nicht figürlich gezeigt ist, dass vorzugsweise wiederum ein Transaktionsregisterdatensatz an das Transaktionsregister 25 übertragen wird.
In Schritt 611 wird der Münzdepotdatensatz, insbesondere einschließlich der genannten erzeugten Datenelemente, der extern bereitgestellten Datenelemente und optional mindestens eines Münzdatensatzes, gespeichert. Er wird vorzugsweise individuell verschlüsselt gespeichert. Die Verschlüsselung kann sich auf den gesamten Münzdepotdatensatz oder auf einzelne Datenelemente (Dl, D2, D3) beziehen (z.b.: „encrypt(Dl,D2,D3 ...)" oder „encrypt(Dl), encrypt(D2), encrypt(D3) ...").
Die Münzdepot-Erstellungseinheit 32 kann nach dem Erstellen des neuen Münzdepots eine Münzdepot-Bestätigung 612 an den Herausgeber 50 senden. Ein Schritt 614 des Registrierens des neuen Münzdepots für einen Benutzer kann zu unterschiedlichen Zeitpunkten erfolgen. Die Zuordnung zwischen einem eindeutigen Benutzernamen, gegebenenfalls inklusive „Vorname, Nachname, Geburtsdatum und/ oder Adresse" oder „Steuernummer mit oder ohne , Vorname, Nachname'" des Benutzers und dem Münzdepot, also der ID des Münzdepots, wird in der Regel in einer externen Datenstruktur gespeichert. Ist der Benutzer bereits in der Münzdepotanforderung 601 genannt, kann die Zuordnung bzw. das Registrieren 614 erfolgen, sobald die ID des Münzdepots feststeht (im Beispiel: ab Schritt 604).
Mit einer separaten Zuordnungs-Anforderung 613, welche sich auf zumindest ein bereits erstelltes, noch keinem Benutzer zugeordnetes Münzdepot bezieht, wird das Registrieren 614 in Fig. 6 ausgelöst. Der Herausgeber 50 könnte somit eine Mehrzahl an neuen Münzdepots erstellen lassen (Schritte 601 bis 612) und erst bedarfsweise (zu einem späteren Zeitpunkt und gegebenenfalls einzeln) einem Benutzer zuordnen (Schritte 613, 614). Es ist denkbar für mehrere Münzdepots gleichzeitig die Zuordnung anzufordern. Die Zuordnungs-Anforderung 613 kann der Herausgeber senden. In der Regel wird der Benutzer danach darüber informiert, dass ein neues Münzdepot für ihn erstellt ist (beispielsweise inkl. Angabe der ID bzw. Zugangsdaten). Alternativ kann der Benutzer oder ein Dritter die Zuordnungs- Anforderung 613 senden. Der Herausgeber teilt dem Benutzer einen Berechtigungscode (z.B. in einer Mail und/ oder als Barcode) mit. Der Benutzer oder ein Dritter, welcher zunächst die Identität des Benutzers verifiziert (z.B. mittels Postident- oder Video Ident-Verfahren), sendet dann den Berechtigungscode mit oder in der Zuordnungs-Anforderung 613.
Vorzugsweise umfasst das Münzdepot zum Zeitpunkt der Registrierung 614 noch keine Münzdatensätze. Somit können - beispielsweise ausgehend vom Transaktionsregister 25 - alle Transaktionen im System Benutzern zugeordnet werden.
Es wird nun erkennbar, dass die zu einzelnen Figuren beschriebenen Aspekte oder Merkmale auch einzeln oder gemeinsam in anderen Figuren verwendbar sind. Das neue Münzdepot gemäß Fig. 6 kann beispielsweise ein Münzdepot nach einer der Figuren 2 bis 9 sein. Zur Vermeidung von Wiederholungen werden nicht alle Details zu jeder Figur erneut wiederholt oder zu Details jeweils alle Alternativen genannt. Das Schlüsselmanagement, die Kommunikation mit dem Münz- und dem Transaktionsregister und insbesondere die unterschiedlich kombinierbaren Vorgaben sind nur einige entsprechende Beispiele. Fig. 7 zeigt den Ablauf eines Verfahrens, wenn eine bedingte Transaktion angefordert wird. Die Anforderung einer bedingten Transaktion 701 vom Benutzer 40 löst zunächst fast die gleichen Schritte 702, 703, 706, 707, 708 aus, wie eine normale, sofort auszuführende Transaktion mit den Schritten 502, 503, 506, 507, 508 in Fig. 5. Da als bedingte Transaktion in Fig. 7 zudem, wie in Fig. 5, eine Sende-Transaktion betrachtet wird, entsprechen die späteren Schritte 750 bis 758 den bekannten Schritten 510 bis 518 respektive. Es wird auf solche bereits beschriebenen Schritte nur verkürzt eingegangen.
Das Lesen der Münzdepotdaten 702 des in der Transaktions-Anforderung 701 mit seiner ID angegebenen Münzdepots und das Prüfen der Benutzer-Authentisierung 703 des Benutzers 40 erfolgen beispielsweise, wie zu Fig. 5 beschrieben.
Ebenfalls analog erfolgt eine Ablehnung 705 der Anforderung 701 falls beim Prüfen 704 der funktionellen Vorgabe(n) des Münzdepots festgestellt wird, dass für das Münzdepot die Transaktion nicht zulässig ist. hn Schritt des Prüfens 704 wird als funktionelle Vorgabe nun (zumindest auch) eine Vorgabe für bedingte Transaktionen geprüft. Wäre das Münzdepot beispielsweise auf einen anderen Typ bedingter Transaktionen und/ oder andere Bedingungen beschränkt, wäre die Anforderung abzulehnen. Neben der funktionellen Vorgabe kann optional beispielsweise eine Richtungsvorgabe und/ oder eine Betragsvorgabe zu prüfen sein, im vorliegenden Beispiel einer Sende-Transaktion die Vorgabe für die Senderichtung und eine eventuell vorhandene Betragsgrenze für das Senden.
Die weiteren Schritte des Prüfens des Depotbetrages 706 sowie des Erstellens 707 und registrieren eines Münzdatensatzes 708, 709 für die Transaktion könnten wiederum analog zu Fig. 5 erfolgen.
Eine bedingte Transaktion wird zunächst gespeichert 710. Es wird also noch nicht die zugehörige Transaktion ausgeführt, sondern erst später ausgeführt, wenn die in der Transaktion enthaltene Bedingung erfüllt ist. Die bedingte Transaktion umfasst die zu prüfende Bedingung und Datenelemente der späteren Transaktion. Wie in Fig. 4 dargestellt, kann das Speichern in einem Speicher für bedingte Transaktionen 436 des Münzdepots 430 oder in einen münzdepotübergreifenden Speicher 36 für bedingte Transaktionen erfolgen. In einer Variante wird in den Speicher 36 als Prüfliste nur die Bedingung zusammen mit einem Verweis auf die bedingte Transaktion gespeichert. Anzumerken ist, dass der dargestellte Ablauf, erst Prüfen 703 bis 705 dann Zwischenspeichern 710, gewährleistet, dass die spätere Transaktion für die bedingte Transaktion tatsächlich ausgeführt werden kann, sobald die Bedingung erfüllt ist.
In einem optionalen Schritt 711 speichert die sichere Ausführungseinheit 31 den Münzdepotdatensatz, insbesondere falls sich die Münzdepotdaten geändert haben. Das Speichern 711 oder das Speichern 710 kann wiederum ein Verschlüsseln der Münzdepotdaten, wie zuvor beschrieben, umfassen. Die Münzdepotdaten haben sich beispielsweise geändert, wenn der Speicher 436 des Münzdepots genutzt wird. Ebenso kann mit den optionalen Schritten 707 bis 709 bereits ein Münzdatensatz für die bedingte Transaktion erzeugt worden sein. Der Münzdatensatz für die bedingte Transaktion kann in den Münzdatensätzen des Münzdepots gespeichert werden. Vorzugsweise ist er dort als für die bedingte Transaktion reservierter bzw. gesperrter Münzdatensatz markiert. In einer Alternative könnte der Münzdatensatz für die bedingte Transaktion in der bedingten Transaktion selbst zwischengespeichert werden, insbesondere wenn der Speicher 436 des Münzdepots genutzt wird. In einer weiteren Alternative wird der Münzdatensatz für die bedingte Transaktion erst nach dem Zwischenspeichern 710 erstellt. Um die Ausführbarkeit der späteren Transaktion für die gespeicherten bedingte Transaktion zu gewährleisten, gibt es verschiedene Möglichkeiten. Der Transaktionsbetrag kann vom verfügbaren Depotbetrag abgezogen werden (für Schritte des Prüfens des Depotbetrags wie Schritt 706 oder 506). Ist der verfügbare Depotbetrag als separates Datenelement des Münzdepots vorgesehen, wird er reduziert. Auch könnte ein für bedingte Transaktionen reservierter Betrag als Datenelement des Münzdepotdatensatzes vorgesehen werden. Eine weitere speicherplatzsparende Möglichkeit wäre es, in Schritten des Prüfens 506, 706 des Depotbetrages nicht nur die verfügbaren Münzdatensätze zu berücksichtigen, sondern ebenso die zwischengespeicherten bedingten Transaktionen des Münzdepots auszulesen.
Mit den drei Punkten nach Schritt 711 und nach Schritt 734 in Fig. 7 ist angedeutet, dass die weiteren Schritte 721 bis 758 bzw. 741 bis 758 erst zu einem späteren Zeitpunkt folgen. Die Bearbeitung der Transaktions-Anfrage 701 für eine bedingte Transaktion ist abgeschlossen.
Die Ausführung einer Transaktion, die der bedingten Transaktion entspricht, erfolgt nur falls und/ oder erst wenn die Bedingung erfüllt ist. In Fig. 7 dargestellt ist ein Schritt des Prüfens der Bedingung 742, welcher beispielsweise in regelmäßigen zeitlichen Abständen ausgeführt wird oder in Antwort auf den Empfang eines Prüf- Auslösers 741 ausgeführt wird. Optional führt die Prüfung die Bedingungs- Prüfungseinheit 37 der Münzdepotverwaltungseinheit 30 aus.
Die gespeicherte bedingte Transaktion kann nun entsprechend ihrer Schreib- und/ oder Leserechte von Dritten oder vom Benutzer gelesen oder geschrieben werden 721-725, 731-735.
Im Beispiel der Fig. 7 sendet eine andere Münzverwaltungseinheit 390, die vorzugsweise einem anderen Benutzer zugeordnet ist, eine Leseanfrage 721 für ein Münzdepot. Die Leseanfrage kann gerichtet sein auf das Auslesen von
- genau einer bedingten Transaktion aus dem Münzdepot, die anhand ihrer Transaktionsnummer oder einer Referenznummer angegeben ist,
- einer Auswahl von bedingten Transaktionen des Münzdepots, die beispielsweise ein bestimmtes Kriterium, wie Transaktionstyp oder Transaktionspartner erfüllen, oder
- aller bedingten Transaktionen des Münzdepots.
Die Münzdepotdaten werden gelesen 722 und optional die Authentisierung der anfragenden Münzverwaltungseinheit 390 geprüft 723. Nach Prüfung der Leserechte 724 wird/werden die bedingte/ n Transaktion/ en der Münzverwaltungseinheit 390 bereitgestellt 725 (ausgelesen). Gegebenenfalls werden mehrere bedingte Transaktionen ausgelesen, wobei aus den bedingten Transaktionen des Münzdepots, insgesamt oder entsprechend der angeforderten Auswahl, jeweils nur die bedingten Transaktionen ausgelesen werden, für welche die Leserechte vorliegen. Prinzipiell könnte eine externe Schreibanfrage analog ablaufen, insbesondere falls die Anfrage zusätzlich zur Authentisierung des Dritten eine Authentisierung des Benutzers umfasst. hn Beispiel der Figur 7 sendet der Benutzer von seiner Benutzereinheit 40 eine Schreiboder Leseanfrage 731 für sein Münzdepot an die Münzdepotverwaltungseinheit 30. Eine Schreibanfrage wird auf genau eine bedingte Transaktion gerichtet sein. Die Leseanfrage kann wiederum genau eine bedingte Transaktion, eine Auswahl der bedingten Transaktionen oder alle bedingten Transaktionen betreffen. Die Münzdepotdaten werden in der Münzdepotverwaltungseinheit 30 gelesen 732, ggf. inklusive der nötigen Entschlüsselungsschritte, und die Authentisierung der Benutzers geprüft 733. Danach werden die Schreib- und/ oder Leserechte geprüft 734. Abhängig vom Vorliegen der Lese- und/ oder Schreibrechte wird die bedingte Transaktion geschrieben (geändert oder gelöscht) bzw. die bedingte(n) Transaktion(en) an die Benutzereinheit 40 gesendet 735 (und somit ausgelesen). Die bedingte Transaktion kann beispielsweise eine zeitliche Bedingung umfassen. Die Sende-Transaktion ist erst an einem bestimmten Datum oder erst zu einem bestimmten Zeitpunkt auszuführen (beispielsweise nach 36 Stunden oder ab 23:00 Uhr oder an einem bestimmten Wochentag).
Ein ggf. erfolgloses Prüfen der Bedingung 742 kann bereits vor den Lese-und/ oder Schreibanforderungen 721, 731 durchgeführt worden sein.
Es gibt bedingte Transaktionen, für die nur einmal eine Transaktion ausgeführt wird, beispielsweise zu einem Zeitpunkt (mit Datum und Uhrzeit) oder einem Auslöser, der in der Bedingung enthalten ist. Für andere bedingte Transaktionen kann mehrfach eine entsprechende Transaktion ausgeführt werden. Wenn beispielsweise eine bedingte Transaktion ein Angebot für eine Transaktion mit Gegenleistung enthält, die an Münzverwaltungseinheiten einer bestimmten Gruppe gerichtet ist, kann beispielsweise das Leserecht für diese Gruppe vergeben werden. Unabhängig davon ob die Münzverwaltungseinheiten die bedinge Transaktion erst durch ein Auslesen der bedingten Transaktion oder anderweitig kennen, könnten nacheinander verschiedene Münzverwaltungseinheiten der Gruppe das Angebot beispielsweise durch Senden eines Münzdatensatzes mit dem geforderten Betrag annehmen und die Gegenleistung zu erhalten. Beispielsweise kann das Münzdepot als Gegenleistung ein digitales Eingangs ticket für eine Veranstaltung an die Münzverwaltungseinheit senden.
Die bedingte Transaktion kann einen Sicherungswert umfassen. Erst oder nur falls der Sicherungswert der sicheren Ausführungseinheit bereitgestellt wird, wird die Transaktion ausgeführt. Der Sicherungswert kann eine Zufallszahl sein oder ein kryptographischer Sicherheitswert sein, der insbesondere aus den Daten der bedingten Transaktion abgeleitet ist (wie ein Hashwert oder eine Signatur, über einen Teil der bedingten Transaktion oder die bedingte Transaktion respektive). Der Sicherungswert kann insbesondere als der oder in dem Prüf- Auslöser 712 empfangen werden.
Die bedingte Transaktion kann ein externes Auslöse-Ereignis umfassen. Der Eintritt des externen Auslöse-Ereignisses wird vorzugsweise in oder mit dem Prüf- Auslöser 712 (von einem Dritten oder dem Transaktionspartner) empfangen. Geprüft wird dann der Inhalt der mit dem Prüf- Auslöser 712 empfangenen Daten. Alternativ kann die sichere Ausführungs-Einheit prüfen, beispielsweise durch Anfrage bei einem externen Server oder bei einer externen Datenstruktur (wie Blockchain oder Datenbank), ob das Auslöse-Ereignis eingetreten ist. Die bedingte Transaktion kann ferner eine zeitliche Begrenzung umfassen (Ausführung vor einem Zeitpunkt oder Datum). Die Bedingung, wie Sicherungswert oder externes Ereignis, muss also vor dem Erreichen der zeitlichen Begrenzung erfüllt sein. Nach Erreichen der zeitlichen Begrenzung wird die bedingte Transaktion nicht mehr ausgeführt. Eine zwischengespeicherte bedingte Transaktion wird nach Ablauf ihrer zeitlichen Begrenzung gelöscht.
Eine bedingte Transaktion wird optional genau einmal oder mehrfach ausgeführt. Die Anzahl der Ausführungen der bedingten Transaktion kann in der bedingten Transaktion angegeben sein.
Eine Vorgabe für bedingte Transaktionen kann beispielsweise eine zulässige Art bzw. die zulässigen Arten der Bedingung angeben, wie zeitliche Bedingung, Sicherungswert und/ oder externes Ereignis. Alternativ oder zusätzlich kann eine Vorgabe für bedingte Transaktionen eine Art der bedingten Transaktion enthalten, welche für das Münzdepot zulässig ist. Beispielsweise kann die Vorgabe angeben, ob eine bedingte Sende-Transaktion zulässig ist, ggf. unbeschränkt oder teilbeschränkt entsprechend einer allgemeinen Sendevorgabe oder entsprechend einer separaten Sendevorgabe für bedingte Transaktionen. Analog kann die Vorgabe angeben, ob eine bedingte Empfangs-Transaktion, eine bedingte Transaktion mit Gegenleistung oder eine bedingte Transaktion nach einem bestimmten Schema (Standard 1 oder proprietär 2) zulässig ist. Solche Vorgaben für bedingte Transaktionen können insbesondere vom Herausgeber vorab für das Münzdepot festgelegt und/ oder vom Benutzer gewählt worden sein. Sie beschränken, wie bereits gesagt, das Münzdepot funktionell auf bestimmte Funktionen aus den verfügbaren Funktionen, welche die sichere Ausführungseinheit bereitstellt.
Die weiteren Schritte des Erstellens 720 der Transaktion(snachricht), des Austauschens mindestens eines Münzdatensatzes 721 bis 724, des Schreibens 725 der Münzdepotdaten, des Bestätigens der Transaktion 726 und des Registrierens der Transaktion im Transaktionsregister 727, 728 sind bereits zu Fig. 5 beschrieben worden.
Ebenso wie ein Münzdepot mehrere Richtungsvorgaben und Betragsvorgaben umfassen kann, kann das Münzdepot alternativ oder zusätzlich auch eine Mehrzahl von Vorgaben für bedingte Transaktionen (wie Vorgaben von Herausgeber und/ oder Benutzer für die verschiedenen Arten und/ oder Richtungen) umfassen. Nicht in Fig. 7 separat dargestellt ist, dass eine bedingte Transaktion automatisch gelöscht wird. Beispielsweise wenn die bedingte Transaktion ihre Ausführungsbegrenzung (wie Anzahl der Ausführungen oder Zeitraum der möglichen Ausführung) erreicht hat oder unerfüllbar geworden ist, wird sie gelöscht. Sie kann also von der Ausführungseinheit 31 (und/oder der Prüfungs-Einheit 37) gelöscht werden, insbesondere wenn eine (oder mehrere) entsprechende Transaktion(en) ausgeführt wird/ worden ist (sind), wenn die Bedingung nicht mehr erfüllbar ist oder nach Ablauf eines Begrenzungszeitraums.
Anzumerken ist, dass das Verfahren gemäß Fig. 7 analog ablaufen würde, wenn man die Rollen der beteiligten Münzverwaltungseinheiten 31, 410 und 390 vertauscht. Die bedingten Transaktionen können also in der Münzverwaltungseinheit 390 gespeichert sein und von einer anderen Münzverwaltungseinheit, ggf. einer anderen Münzdepotverwaltungseinheit 30 ausgelesen oder geschrieben werden. Nur wenige Schritte, wie das Lesen der Münzdepotdaten, vereinfachen sich (keine Entschlüsselung) .
Am Beispiel von Fig. 8 werden verschiedene Aspekte der Vorgaben beschrieben, wie sie grundsätzlich und mit unterschiedlichem Inhalt in jedem der diskutierten Münzdepots bzw. der Münzverwaltungseinheiten vorliegen könnten.
Als Datenelemente sind mehrere Vorgaben 811-828 dargestellt und in den Münzdatensätzen 805 sind zwei Münzdatensätze symbolisch vereinfacht dargestellt (Betrag 13 bzw. 23 mit „dW" als digitale Währungseinheiten der Zentralbank- Währung).
Das Münzdepot bzw. die Münzverwaltungseinheit umfasst einerseits Herausgeber- Vorgaben 810 und Benutzer-Vorgaben 820. Andererseits umfasst es sowohl Empfangsvorgaben 811-814; 821-823 als auch Sendevorgaben 816-819; 826-828. In Anlehnung an die Darstellung in Fig. 3 sind in Fig. 8 die Empfangsvorgaben links von den Münzdatensätzen 805 und die Sende-Vorgaben rechts davon angeordnet.
Schließlich wird für funktionelle Vorgaben unterschieden zwischen Richtungsvorgaben 821, 811, 816, 826, Vorgaben für bedingte Transaktionen 822, 812, 817, 827 und Vorgaben für Transaktionen mit Gegenleistungen 814, 819. Das Münzdepot bzw. die Münzverwaltungseinheit umfasst zudem auch Betragsvorgaben 813, 838, 828. Die Herausgeber-Vorgaben 810 hat der Herausgeber zum Zeitpunkt der Erstellung des Münzdepots bzw. der Münzverwaltungseinheit vorab festgelegt. Die Benutzer- Vorgaben 820 sind vom Benutzer gewählt, jedoch enger gewählt als die gleichartigen Herausgeber-Vorgaben 810 (falls diese vorhanden sind).
Der Herausgeber ist Inhaber eines Geschäftes. Er beschränkt das von ihm für den Benutzer erstellte Münzdepot bzw. Münzverwaltungseinheit, daher in der Sende- Vorgabe 816 auf sein Geschäft „Das Geschäft". Die Sende-Vorgabe 816 enthält in der Praxis also die ID(s) der Münzverwaltungseinheit(en) des Geschäfts und nicht einen Klartextnamen, wie in der Figur dargestellt. Der Benutzer kann somit Münzdatensätze des vom Herausgeber erstellten Münzdepots bzw. Münzverwaltungseinheit nur an das fest vorgegebene Geschäft senden. Der Benutzer darf diese Vorgabe nicht weiter beschränken, deshalb wird ihm nicht angeboten eine Sende-Vorgabe des Benutzers 826 zu wählen. Dies wird in der Fig. 8 durch ein Kästchen mit gepunktetem Rand angezeigt. In Empfangsrichtung hat der Herausgeber in seiner Empfangsvorgabe 811 vorgesehen, dass Münzdatensätze von dem Geschäft oder vom Benutzer empfangen werden dürfen. Der Benutzer kann (optional und daher gestrichelt dargestellt) eine strengere Empfangsvorgabe des Benutzers 821 wählen. Der Benutzer hat im Beispiel keine Empfangsvorgabe ausgewählt, hätte aber beispielsweise eine Beschränkung auf „Das Geschäft" oder „Keiner" wählen können.
Wie in den Herausgeber-Vorgaben zu bedingten Transaktionen 812, 817 erkennbar, hat der Herausgeber das Münzdepot bzw. die Münzverwaltungseinheit des Benutzers hinsichtlich bedingter Transaktionen nicht separat beschränkt. Seine Sende- und Empfangsvorgaben 811, 816 sind jedoch auch für bedingte Transaktionen gültig. Der Benutzer hat sich entschieden bedingte Empfangs-Transaktionen nicht zuzulassen, wie es in der Benutzervorgabe 822 für die Empfangsrichtung von bedingten Transaktionen erkennbar ist („inaktiv"). Weiterhin möchte der Benutzer keine beliebigen bedingten Sende-Transaktionen zulassen, sondern nur die für ihn nützliche Art der Bedingung zulassen, die zeitliche Bedingung, die er für das Geschäft verwenden will. Er hat in seiner Benutzervorgabe 827 „Zeitbedingung" ausgewählt.
Für das Münzdepot bzw. die Münzverwaltungseinheit hat der Herausgeber zudem Betragsvorgaben 813, 818 fest vorgegeben. Das Münzdepot bzw. die Münzverwaltungseinheit darf gemäß Herausgeber-Vorgabe 813 maximal 50 digitale Währungseinheiten in einer Transaktion empfangen und gemäß Herausgeber-Vorgabe 818 maximal 200 digitale Währungseinheiten in einer Transaktion senden. Eine weitere Beschränkung des Betrages wird dem Benutzer in Empfangsrichtung nicht angeboten (gepunktetes Kästchen) für Benutzer-Vorgabe 823. In Senderichtung hat der Benutzer als maximalen Sendebetrag 50 digitale Währungseinheiten für sein Münzdepot in der Vorgabe 828 ausgewählt.
Schließlich hat der Herausgeber die vorhandene Option mit dem Münzdepot Transaktionen mit Gegenleistungen auszuführen ausgeschlossen. Die Herausgeber- Vorgaben für Transaktionen mit Gegenleistungen 814, 819 sind eine vollständige Beschränkung („inaktiv").
Herausgeber-Daten 809 können beispielsweise einen Ablaufzeitpunkt für das Münzdepot (Gültigkeitsgrenze) enthalten. Nicht dargestellt sind, aber natürlich vorhanden sein können, weitere der bereits genannten Datenelemente eines Münzdepots, wie nur beispielsweise die weiteren Datenelemente 237 - 239, 396a-c - 398a-c oder 436 - 438 aus Figur 3 und 4.
Der Benutzer kann mit diesen Vorgaben nun beispielsweise zwei bedingte Transaktion anlegen, die sich in den Schreibrechten und den Leserechten unterscheiden. Eine erste bedingte Transaktion ist nur vom Benutzer lesbar und schreibbar. Von dem Münzdepot sollen an den Empfänger „das Geschäft" mit der Bedingung „wöchentlich immer Sonntag morgens" ein Münzdatensatz mit dem Betrag 3 dW gesendet werden. Die bedingte Transaktion enthält als Transaktionstext für die spätere Transaktion „3 Einheiten liefern". Die bedingte Transaktion enthält jedoch noch keinen Münzdatensatz. Diese bedingte Transaktion kann die Münzverwaltungseinheit des Geschäfts nicht lesen. Eine zweite bedingte Transaktion ist für einen bestimmten Zeitpunkt vorgesehen und enthält bereits einen höherwertigen an das Geschäft zu sendenden Münzdatensatz, beispielsweise mit dem Betrag von 100 dW. Die zweite bedingte Transaktion ist eine garantierte, bedingte Transaktion. Der Benutzer und das Geschäft haben das Leserecht für die bedingte Transaktion, ein Schreibrecht ist jedoch nicht vergeben, so dass die Ausführung der zugehörigen Transaktion zum genannten Zeitpunkt garantiert ist. Abhängig von Implementierungsdetails der Transaktion, ist der Münzdatensatz ohne eine Zusatzinformation sowieso noch nicht verwendbar oder wird ein geheimes Datenelement des Münzdatensatzes abgesichert, beispielsweise erst beim Ausführen der Transaktion entschlüsselt. Die Münzverwaltungseinheit des Geschäftes kann die bedingte Transaktion lesen und weiß dadurch, dass und wann er den Münzdatensatz erhalten wird. Er kann nun beispielsweise eine höherwertige Ware für den Benutzer bestellen. Mit Schreib- und/ oder Leserechten selektiv versehene bedingte Transaktionen stellen, mit oder ohne Vorgaben, einen sehr flexiblen Weg dar, um eine überraschend große Vielfalt an Transaktionstypen zu ermöglichen.
Anhand von Fig. 9 sollen verschiedene bedingte Transaktionen und deren Datenelemente noch einmal genauer beschrieben werden.
Fig. 9 zeigt als Zeileneinträge einer Liste dargestellt, verschiedene bedingte Transaktionen, die anhand der Transaktionsnummer 931 unterscheidbar sind. Die Basisdaten 91 der bedingten Transaktion umfassen Sender 911, Empfänger 912 und Betrag 931. Die Bedingung 92 der bedingten Transaktion umfasst ein Prüfkriterium 921, eine Ausführungsbegrenzung 922 und optional den Typ 923 der bedingten Transaktion. Die Ausführungsbegrenzung 922 kann eine Ausführungsanzahl und/ oder eine Zeitangabe umfassen (wie „nur einmal" und/ oder „nur bis 03.03.2021 09.00 Uhr"). Die unterschiedlichen Lese- und/ oder Schreibrechte 96 sind verkürzt in Spalte 96 gezeigt. Die Erweiterungsdaten 93 umfassen Datenelemente, die optional sind und/ oder gegebenenfalls erst beim Ausführen der Transaktion erzeugt werden. Als Referenz 931 sind die Transaktionsnummern T-l bis T-2 die tatsächlichen Transaktionsnummern der später ausgeführten Transaktion. Dagegen sind die Transaktionsnummern R-l bis R-4 temporäre Referenzen für die bedingten Transaktionen. Münzdatensätze 932 enthalten nur die ersten beiden bedingten Transaktionen. Ein Transaktions-Bezugstext 933 kann vorgesehen sein.
Die ID der Münzverwaltungseinheit des Benutzers ist ID1. Die erste bedingte Transaktion mit der bereits erzeugten Transaktionsnummer T-l ist eine garantierte bedingte Transaktion. Es wird der bereits vorbereitete Münzdatensatz CI mit dem Betrag 913 ,100' vom Sender 911 mit ID1 an den Empfänger 921 mit ID2 in einer Transaktion gesendet, sobald das Prüfkriterium 921 , Datum' erfüllt ist (also an einem bestimmten Tag). Die Ausführungsanzahl 922 ist eins (einmalige Ausführung) und der Typ A, was in dem Beispiel für garantierte bedingte Transaktion stehen soll. Entsprechend hat der Benutzer gemäß den Schreib- und/ oder Leserechten ,T kein Schreibrecht, beide Transaktionspartner 911, 912 aber ein Leserecht. Der Transaktions- Bezugstext 933 enthält eine Information , A789', welche den Transaktionspartnern eine Zuordnung erlaubt, beispielsweise zu einer Rechnung.
Für garantierte bedingte Transaktionen hat der Benutzer kein Schreibrecht, die Lese- und/ oder Schreibrechte Dritter können sich jedoch unterscheiden. Beispielsweise die vierte bedinge Transaktion mit der Referenznummer R2 ist eine weitere garantierte bedingte Transaktion (Typ A). Wenn als Bedingung 921 der Gesamtbetrag der Münzdatensätze in der Münzverwaltungseinheit des Benutzers eine , Schwelle' überschreitet, wird ein Münzdatensatz mit dem Betrag 931 von ,10' von der Münzverwaltungseinheit des Benutzers an den Empfänger 912, die Münzverwaltungseinheit mit der ID4, gesendet. Die vierte bedingte Transaktion wird unbegrenzt oft ausgeführt, da keine Ausführungsbegrenzung 922 enthalten ist. Gemäß den Schreib- und/ oder Leserechten 96 ,IIT, hat der Benutzer kein Schreibrecht aber die Münzverwaltungseinheit mit der ID4 (Leserecht haben dagegen beide). Verschiedene bedingte Transaktionen eines Typs von bedingter Transaktion können die gleichen Schreib- und/ oder Leserechte 96 haben, ihre Schreib- und/ oder Leserechte 96 können sich - wie soeben gezeigt - jedoch auch unterscheiden.
Die zweite bedingte Transaktion mit der Referenznummer R-2 enthält ebenfalls bereits einen Münzdatensatz 932 ,C2'. Die Bedingung ist jedoch ein externes Ereignis, beispielsweise der Empfang eines geheimen Sicherungs wertes, wie Signatur oder Passwort für die bedingte Transaktion. Wenn die Münzverwaltungseinheit des Benutzers den Sicherungswert erhält, wird der Münzdatensatz in einer Sende- Transaktion an den Empfänger 912 ,ID3' gesendet. Die zweite bedingte Transaktion kann als abrufbare bedingte Transaktion bezeichnet werden. Als Typ 923 ist entsprechend ,B' eingetragen. Sie ist - in diesem Beispiel - gemäß Ausführungsanzahl 922 nur einmal abrufbar. Mit den Lese- und/ oder Schreibrechten 96 ,IT wird angegeben, dass nur die beiden Transaktionspartner das Leserecht haben und der Benutzer ein Schreibrecht hat.
Ebenfalls eine abrufbare bedingte Transaktion (Typ B) zeigt die fünfte Zeile. Abrufbare bedingte Transaktion enthalten eine Referenz, also insbesondere eine Transaktionsnummer oder (temporäre) Referenznummer, um eindeutig abrufbar zu sein. Die bedingte Transaktion mit der Referenznummer R-3 ist gemäß Spalte 922 dreimal abrufbar, kann gemäß Spalte 912 von allen Münzverwaltungseinheiten der Gruppe Gl abgerufen werden und kann auf Anfrage einer Münzverwaltungseinheit der Gruppe Gl an die aktuelle Münzverwaltungseinheit mit ID1, also ohne Kenntnis des Sicherungswertes, abgerufen werden. Die zweite und die fünfte bedingte Transaktion haben die gleichen Schreib- und/ oder Leserechte 96. In einer nicht separat dargestellten Variante ist eine abrufbare bedingte Transaktion für einen bestimmten Empfänger - einmalig, mehrmals oder unbegrenzt - durch eine Transaktionsanfrage abrufbar. Auch für diese Variante sind Schreib- und/ oder Leserechte 96 ,IT sinnvoll. Die dritte bedingte Transaktion mit der Referenz 931 ,R-T ist eine periodische bedingte Transaktion (Typ 923 ,C'). Sie wird periodisch ausgeführt, mit der Periode ,Zeit', also beispielsweise täglich, wöchentlich oder alle 2 Stunden, die in dem Prüfkriterium Bedingung 921 angegeben ist. In dieser bedingten Transaktion ist die Münzverwaltungseinheit des Benutzers der Empfänger 912. Sie erhält also periodisch einen (oder mehrere) Münzdatensatz mit dem angegebenen Betrag 913 von der Münzverwaltungseinheit ID4 als Sender 911. Die dritte und die vierte bedingte Transaktion haben die gleichen Schreib- und/ oder Leserechte 96, die Münzverwaltungseinheit ID4 kann diese bedingten Transaktionen schreiben. Anzumerken ist, dass die beiden bedingten Transaktionen aufeinander abgestimmt sind, die dritte bedingte Transaktion fordert periodisch das Senden von Münzdatensätzen von ID4 zu ID1 an und die vierte bedingte Transaktion sendet bei Überschreitung der genannten Schwelle - und solange diese Bedingung erfüllt ist - Münzdatensätze wieder zurück.
Die bedingten Transaktion eines Typs, wie beispielsweise periodische bedingte Transaktion, können Empfangs- oder Sendetransaktionen sein. Die vierte bedingte Transaktion könnte also auch als Sendetransaktion gestaltet sein.
Die sechste Transaktion mit der (optionalen) Referenznummer R-4 ist eine bedingte Gegenleistungstransaktion (Typ 923 ,D'). Die Bedingung 921 ist der Eingang einer Empfangstransaktion (Empfänger 912 ,IDT) mit dem Betrag 912 ,40' als Ereignis. Der Sender 911 muss der Gruppe G2 angehören. Die Gegenleistung GL kann im Transaktions-Bezugstext 933 beschrieben sein. Beispielsweise erhält der Sender ein Zugangsticket für eine Veranstaltung, beispielsweise als QR-Code an seine eMail- Adresse gesandt, die im Transaktions-Bezugstext der Empfangstransaktion angegeben ist. Da die Veranstaltung in dem Beispiel am Dienstag stattfindet, umfasst die sechste bedingte Transaktion eine zeitliche Ausführungsbegrenzung 922, sie ist bis ,Mo' (Montag) begrenzt. Die Schreib- und/ oder Leserechte 96 können unterschiedlich gewählt sein, im Beispiel mit ,IV' soll nur der Benutzer Lese- und Schreibrechte haben. Die Sender müssten über die Existenz der bedingten Transaktion auf anderem Wege, beispielsweise via eMail/ SMS/ Broadcast ... informiert werden. Wählt man dagegen Schreib- und Leserechte 96, welche auch den Münzverwaltungseinheiten der Gruppe G2 das Lesen ermöglichen, kann die separate Information entfallen.
Ohne Bezug zu Figur 9 sollen weitere Optionen für bedingte Transaktionen beschrieben werden, für eine Münzverwaltungseinheit, welche eine Gegenleistung anbietet. Die Gegenleistung könnte in digitaler Form bereitgestellt werden, in vielen Anwendungsfällen wird die Gegenleistung lokal erbracht und soll auch offline (ohne Netzverbindung) möglich sein. Die Gegenleistung kann beispielsweise ein Zugang zu einem Bereich (wie Stadion, Zoo oder Museum), Bereitstellung von Strom oder Betrieb einer Maschine (wie Waschmaschine oder Waschanlage) sein. Die Münzverwaltungseinheit des Benutzers, der die Gegenleistung erbringt, ist vorzugsweise eine lokale Münzverwaltungseinheit mit eigener Ausführungseinheit, die am Ort der Gegenleistung angeordnet ist, insbesondere ist sie ein reversibel einsetzbares oder fest eingebautes Sicherheitsmodul.
Die Münzverwaltungseinheit des Benutzers (Erbringer der Gegenleistung) kann unterschiedliche bedingte Gegenleistungstransaktionen mit zueinander unterschiedlichen (und optional gleichen) Schreib- und/ oder Leserechten umfassen.
Eine bedingte Gegenleistungstransaktion kann eine garantierte bedingte Transaktion sein (die der Benutzer also nicht ändern kann). Die garantierte bedingte Gegenleistungstransaktion wird beispielsweise bei der Herstellung der Münzverwaltungseinheit geschrieben und ist nicht mehr schreibbar, aber von jedermann lesbar. Bei einer Empfangstransaktion mit dem Betrag X, erhält der Sender stets eine Gegenleistung der Art Y und/ oder der Dauer Z, beispielsweise Strom oder Betrieb der Waschmaschine jeweils für 30 Minuten.
Eine weitere bedingte Gegenleistungstransaktion kann temporär abrufbar sein. Sie enthält eine zeitliche Ausführbarkeitsbegrenzung. Diese bedingte Transaktion ist für alle lesbar und vom Benutzer schreibbar. Im Beispiel wird die gleiche Gegenleistung in einem Zeitraum (wie , heute') für einen geringeren Betrag angeboten (wie Betrag: ,X - 10%').
Eine andere bedingte Gegenleistungstransaktion mit einem verringerten Betrag (wie Betrag: X- 5%) oder einer verbesserten Gegenleistung (Dauer: Z*l,2) kann den Empfang eines in der Bedingung oder dem Transaktions-Bezugstext angegebenen Codewertes voraussetzen. Diese bedingte Gegenleistungstransaktion ist für Dritte nicht lesbar (und für den Benutzer schreib- und lesbar). Der Dritte erfährt den Codewort nicht durch Auslesen der bedingten Transaktion. Er könnte den Codewert beispielsweise in der Zeitung, einer App, im Internet oder auf anderen Wegen erhalten. Dann sendet der Dritte den Codewert, insbesondere zusammen mit dem Münzdatensatz (beispielsweise im Transaktions-Bezugstext), an die Münzverwaltungseinheit des Benutzers. Die Bedingung der bedingten Transaktion ist erfüllt und die Gegenleistung wird bereitgestellt. Eine weitere bedingte Gegenleistungstransaktion kann nur für eine bestimmte Gruppe lesbar sein. Die Gegenleistung ist nur für Mitglieder dieser Gruppe, wie Stammkunden oder Firmenmitglieder, für den verringerten Betrag oder mit der verbesserten Gegenleistung (wie längere Dauer oder höhere Intensität der Gegenleistung, z.b.
Stromstärke an Ladesäule) lesbar und somit beispielsweise über die Referenznummer oder mit einem mitgelesenen Codewert abrufbar.
Die Münzverwaltungseinheit kann eine periodische bedingte Transaktion umfassen, welche die (insbesondere alle) empfangenen Münzdatensätze, beispielsweise einmal täglich, an eine Sammel-Münzverwaltungseinheit des Benutzers sendet. Mehrere Münzverwaltungseinheiten des Benutzers können eingerichtet sein, periodisch an die Sammel-Münzverwaltungseinheit zu senden. Falls die Münzverwaltungseinheit keine eigene Internetverbindung hat, werden die empfangenen Münzdatensätze erst zu einem späteren Zeitpunkt im Münzregister registriert und/ oder an die Sammel- Münzverwaltungseinheit des Benutzers übertragen.
Die Kodierung der Vorgaben 811-828 in Fig. 8 und der Datenelemente der bedingten Transaktion in Fig. 9 ist zur besseren Lesbarkeit in der Figur teils als Text dargestellt, kann aber in Länge und Kodierung beliebig (ein oder mehrere Bits, ein oder mehrere Bytes, Bytefolgen ... oder numerisch, hexadezimal, binär, String ... kodiert) sein. Eine Kodierung der Datenelemente des Münzdepots oder der bedingten Transaktion als TLV-Struktur (Tag, Length, Value) ist ebenso denkbar wie eine Kodierung der Transaktionen, der bedingten Transaktionen oder des Münzdepots in einem JSON- Format. hn Rahmen der Erfindung können alle beschriebenen und/oder gezeichneten und/ oder beanspruchten Elemente beliebig miteinander kombiniert werden.
BEZUGSZEICHENLISTE
1 Ausgabeschicht
2 Systemverwaltungsschicht
3 Transaktionsschicht
5 Münzdatensatz
6 Registerdatensatz
7 Transaktionsdatensatz
10 Zentralbankinstanz
20 Münzregister
25 Transaktionsregister
210, 220 Münzverwaltungseinheit
211 Ausführungseinheit
215 Münzdepot
217 Identifikator der Münzverwaltungseinheit
218 Kryptographischer Schlüssel
219 Zertifikat der Münzverwaltungseinheit
30 Münzdepotverwaltungseinheit
31, 391 Ausführungseinheit
310, 320, 330 Münzdepot
315, 325, 335, 395 Münzdatensatz
316 bedingte Transaktion
322, 392 Empf angs-V orgabe
323, 393 Sende-Vorgabe
326a, 336a, 396a erste bedingte Transaktion 326b, 336b, 396b zweite bedingte Transaktion 326c, 336c, 396c dritte bedingte Transaktion 327a, 337a, 397a erste Leserechte 327b, 337b, 397b zweite Leserechte
397c dritte Leserechte
328a, 338a, 398a erste Schreibrechte 328b, 338b, 398b zweite Schreibrechte 398c dritte Schreibrechte
32 Münzdepot-Erstellungseinheit
33 Benutzervorgaben-Einheit 34 Benutzerzugriffs-Einheit für bedingte Transaktionen
36 Prüfliste bedingter Transaktionen
37 Bedingungs-Prüfeinheit
38 Schlüsselverwaltungsmodul
39 Drittzugriffs-Einheit für bedingte Transaktionen
40 Benutzer-Einheit
50 Herausgeber-Einheit
237 Identifikator
238 Schlüssel
239 Zertifikat
401 Transaktions-Anforderung
402 Münzdepot-Anforderung
403 Konfigurations-Anforderung
404 Auslöse-Ereignis
405 Sende-Transaktion
406 Empfangs-Transaktion
407 Schreiben bedingter Transaktion
408, 409 Lesen bedingter Transaktionen
410, 420, 430 Münzdepots
432, 433 Vorgaben
435 Münzdatensatz
436 bedingte Transaktion
437 Schreibrechte bedingte Transaktion
438 Leserechte bedingte Transaktion
501 Transaktions-Anforderung
502 Lesen der Münzdepotdaten
503 Prüfen der Benutzer- Authentisierung
504 Prüfen der Vorgabe
505 Ablehnung der Anforderung
506 Prüfen des Depotbetrages
507 Erstellen und registrieren eines Münzdatensatzes
508. 512 Registrierungsanforderung
509. 513 Registrierungsbestätigung
510 Erstellen der Transaktion
511 Senden der Transaktion
514, 516 Transaktionsbestätigung
515 Schreiben der Münzdepotdaten 517 Erstellen des Transaktions-Registerdatensatzes
518 Transaktionsdaten-Registrierung
551 Transaktions- Anforderung
552 Lesen der Münzdepotdaten
554 Prüfen der funktionellen Vorgabe
557 Umschalten eines Münzdatensatzes
558 Registrierungsanforderung
559 Registrierungsbestätigung
565 Schreiben der Münzdepotdaten
566 Transaktionsbestätigung
567 Erstellen des Transaktions-Registerdatensatzes
568 Transaktionsdaten-Registrierung
601 Münzdepot- Anforderung
602 Prüfen der Herausgeber- Authentisierung
603 Erstellen des neuen Münzdepots
604 Erzeugen eines Identifikators
605 Erzeugen eines Schlüssels
606 Erstellen eines Zertifikats
607 Empfangen eines Münzdatensatzes
608 Erstellen einer Umschaltanforderung
609 Umschaltanforderung
610 Umschaltbestätigung
611 Schreiben der Münzdepotdaten
612 Münzdepot-Bestätigung
613 Zuordnungs-Anforderung
614 Registrieren des Münzdepot für Benutzer
701 Anforderung einer bedingten Transaktion
702, 722, 732 Lesen der Münzdepotdaten
703, 723, 733 Prüfen der Authentisierung
704 Prüfen der funktionellen Vorgabe
705 Ablehnung der Anforderung
706 Prüfen des Depotbetrages
707 Erstellen und registrieren eines Münzdatensatzes
708 Registrierungsanforderung
709 Registrierungsbestätigung 710 Speichern der bedingten Transaktion
711 Schreibe Münzdepotdaten
721, 731 Schreib-/ Leseanfrage für bedingte Transaktion
724, 734 Schreib-/ Leserechte prüfen
741 Prüf-Auslöser
742 Prüfen der Bedingung der Transaktion
750 Erstelle Transaktion
751 Transaktion (mit Münzdatensatz)
752 Registrierungsanforderung für modifizierten Münzdatensatz
753 Registrierungsbestätigung
754, 756 Transaktionsbestätigung
755 Schreiben der Münzdepotdaten
757 Erstellen Transaktions-Registerdatensatz
758 Transaktions-Registrierung
805 Münzdatensätze des Münzdepots
809 Herausgeber-Daten
810 Herausgeber-V orgaben
820 Herausgeber-Einstellungen
811, 821 Sender-Beschränkung
812, 822 Empfangsvorgabe für bedingte Transaktionen
813, 823 Betragsgrenze Empfang 814 Empfangsvorgabe für Gegenleistungen
816, 826 Empfänger-Beschränkung
817, 827 Sendevorgabe für bedingte Transaktionen
818, 828 Betragsgrenze Senden 819 Sendevorgabe für Gegenleistungen
91 Basisdaten der bedingten Transaktion
92 Bedingung der bedingten Transaktion
93 Erweiterungsdaten
911 Sender
912 Empfänger
913 Betrag
921 Prüfkriterium
922 Ausführungsbegrenzung
923 Typ der bedingten Transaktion
96 Schreib- und/ oder Leserechte Transaktionsnummer Münzdatensatz Textfeld/Transaktions-Bezugstext

Claims

54 PATENTANSPRÜCHE
1. Münzverwaltungseinheit (330,31; 390) eines Benutzers, umfassend: eine Ausführungseinheit (31) zur Verwaltung von digitalen Münzdatensätzen ( 335; 395) eines digitalen Zentralbankwährungssystems, wobei die Ausführungseinheit angepasst ist, in Transaktionen digitale Münzdatensätze ( 335; 395) mit anderen Münzverwaltungseinheiten auszutauschen und Registrierungsanforderungen an ein Münzregister (20) der Zentralbank zu senden; und zumindest einen digitalen Münzdatensatz ( 335; 395); dadurch gekennzeichnet, dass die Münzverwaltungseinheit (330,31; 390) angepasst ist, bedingte Transaktionen (336a, 336b; 396a-c) als Datenelemente zu speichern, wobei eine Transaktion erst ausgeführt wird, wenn eine Bedingung der gespeicherten bedingten Transaktion (336a, 336b; 396a- c) erfüllt ist; und die Münzverwaltungseinheit (330,31; 390) angepasst ist, die bedingten Transaktionen (336a, 336b; 396a-c) mit unterschiedlichen Lese- und/ oder Schreibrechten (337a, 337b, 338a, 338b; 397a-c, 398a-c) zu speichern.
2. Münzverwaltungseinheit (330,31; 390) nach Anspruch 1, wobei eine erste bedingte Transaktion (336a, 396a) erste Lese- und/ oder Schreibrechte (337a, 338a; 397a, 398a) und eine zweite bedingte Transaktion (336b, 396b) zweite, unterschiedliche Lese- und/ oder Schreibrechte (337b, 338b; 397b, 398b) aufweist, die sich insbesondere in den Leserechten, den Schreibrechten oder den Lese- und den Schreibrechten unterscheiden.
3. Münzverwaltungseinheit (330,31; 390) nach Anspruch 1 oder 2, wobei die Lese- und/ oder Schreibrechte (337a, 337b, 338a, 338b; 397a-c, 398a-c) sich unterscheiden in Schreibrechten für den Benutzer und/ oder Lese- und/ oder Schreibrechten für Dritte, insbesondere die anderen Münzverwaltungseinheiten.
4. Münzverwaltungseinheit (330,31; 390) nach einem der vorhergehenden Ansprüche, wobei die bedingte Transaktion umfasst
- eine zeitliche Bedingung, insbesondere einen Zeitpunkt oder eine Periode,
- eine vergleichende Bedingung, insbesondere einen Vergleichs wert für einen internen oder externen Parameter,
- ein Empfangsbedingung, insbesondere ein Empfangen eines Sicherungswertes oder 55
Codewertes der bedingten Transaktion, ein Empfangen einer Empfangstransaktion oder ein Empfangen einer Anfrage für die bedingte Transaktion ist.
5. Münzverwaltungseinheit (330,31; 390) nach einem der vorhergehenden Ansprüche, wobei die Münzverwaltungseinheit (330,31; 390), vorzugsweise deren Ausführungseinheit (31) oder eine Bedingungs-Prüfeinheit (37), überprüft, ob die Bedingung der bedingten Transaktion erfüllt ist, wobei das Überprüfen insbesondere kontinuierlich, periodisch und/ oder in Antwort auf einen Empfangs vorgang erfolgt.
6. Münzverwaltungseinheit (330,31; 390) nach einem der vorhergehenden Ansprüche, wobei zumindest zwei unterschiedliche Typen von bedingten Transaktionen gespeichert sind, insbesondere aus den folgenden Typen: garantierte bedingte Transaktion, abrufbare bedingte Transaktion oder bedingte Gegenleistungstransaktion; wobei vorzugsweise in der Münzverwaltungseinheit gespeichert sind:
- mindestens zwei bedingten Transaktionen eines ersten Typs, welche gleiche oder unterschiedliche Lese- und/ oder Schreibrechte aufweisen, und/ oder
- mindestens zwei bedingte Transaktionen der zumindest zwei unterschiedlichen Typen, welche gleiche oder unterschiedliche Lese- und/ oder Schreibrechte aufweisen.
7. Münzverwaltungseinheit (330,31; 390) nach einem der vorhergehenden Ansprüche, wobei die bedingte Transaktion eines oder mehrere der Datenelemente der erst bei Erfüllung der Bedingung auszuführenden Transaktion nicht umfasst, insbesondere eines oder mehrere der folgenden Datenelemente:
- einen Identifikator des Senders (911) des mindestens einen Münzdatensatzes,
- einen Identifikator des Empfängers (912) des mindestens einen Münzdatensatzes,
- eine Transaktionsnummer,
- den mindestens einen Münzdatensatz (932) der auszuführenden Transaktion.
8. Münzverwaltungseinheit (330,31; 390) nach einem der vorhergehenden Ansprüche, wobei die Münzverwaltungseinheit (330,31; 390)
- eine Münzverwaltungseinheit (390) mit eigener Ausführungseinheit (391) ist, oder
- eine Münzverwaltungseinheit (330, 31) in einer Münzdepotverwaltungseinheit (30) mit mehreren Münzdepots (310, 320, 330), vorzugsweise unterschiedlicher Benutzer, ist, welche eines der Münzdepots (330) umfasst und eine für die mehreren Münzdepots (310, 320, 330) gemeinsame Ausführungseinheit (31) aufweist. 56
9. Münzverwaltungseinheit (330, 31; 390) nach einem der vorhergehenden Ansprüche, wobei jede Münzverwaltungseinheit einen Identifikator (237) der Münzverwaltungseinheit und optional einen Schlüssel (238) und/ oder ein dem Identifikator und/ oder dem Schlüssel zugeordnetes Zertifikat (239) umfasst.
10. Münzverwaltungseinheit (330, 31; 390) nach einem der vorhergehenden Ansprüche, wobei die Münzverwaltungseinheit (330, 31; 390) einen Speicherbereich für bedingte Transaktionen der Münzverwaltungseinheit umfasst, und in einem gemeinsamen Speicherbereich für mehrere Münzdepots (310, 320, 330) - der Münzverwaltungseinheit (390) oder einer Münzdepotverwaltungseinheit (30) mit der Münzverwaltungseinheit - eine oder mehrere der folgenden Informationen gespeichert sind:
Referenzen auf eines oder mehrere Münzdepots (310, 320, 330) mit bedingten Transaktionen, insbesondere zeitlich zu prüfende Münzdepots, mehr bevorzugt mit deren Prüfintervall; und/ oder die zu prüfenden Bedingungen von bedingten Transaktionen mehrerer Münzdepots (310, 320, 330); und/ oder die für jeden Dritten lesbaren bedingten Transaktionen der Münzverwaltungseinheit (30; 390).
11. Münzverwaltungseinheit nach einem der vorhergehenden Ansprüche, wobei bedingte Transaktionen anhand der Lese- und/ oder Schreibrechte: von zumindest einer anderen Münzverwaltungseinheit eines anderen Benutzers des digitalen Zentralbankwährungssystems lesbar, aber nur vom Benutzer oder nur gemeinsam vom Benutzer und der zumindest einen anderen Münzverwaltungseinheit des anderen Benutzers des digitalen Zentralbankwährungssystems schreibbar sind; und/ oder nur vom Benutzer lesbar und schreibbar sind; und/ oder von zumindest einer anderen Münzverwaltungseinheit eines anderen Benutzers des digitalen Zentralbankwährungssystems lesbar, aber nur von einer Herausgebereinheit schreibbar sind.
12. Münzverwaltungseinheit nach einem der vorhergehenden Ansprüche, wobei die Münzverwaltungseinheit (330, 31; 390) eingerichtet ist, eine oder mehrere der folgenden Vorgaben vor dem Ausführen von Transaktionen zu prüfen:
- eine Empfängervorgabe, welche die Münzverwaltungseinheit auf genau einen Empfänger, genau eine Empfängergruppe oder auf mehrere Empfänger und/ oder Empfängergruppen beschränkt, und/ oder 57
- eine Sendervorgabe, welche die Münzverwaltungseinheit auf genau einen Sender, genau eine Sendergruppe oder mehrere Sender und/ oder Sendergruppen beschränkt, und/ oder
- eine funktionelle Vorgabe, die eine von der Ausführungseinheit (31) ausführbare Funktion betreffen, welche insbesondere die ausführbare Funktion für die Münzverwaltungseinheit (330, 31; 390), bevorzugt für ein Münzdepot (310; 320; 330) der Münzverwaltungseinheit (330, 31; 390), vollständig, teilweise oder nicht beschränken; und/ oder
- eine Sende- oder Empfangs-Vorgabe, welche das Senden von Münzdatensätzen respektive das Empfangen von Münzdatensätzen für die Münzverwaltungseinheit (330, 31; 390), bevorzugt für ein Münzdepot (310; 320; 330) der Münzverwaltungseinheit, beschränkt; und/ oder
- eine Betragsvorgabe mit einem Maximalwert für den Betrag der zu sendenden und/ oder für den Betrag der zu empfangenden Münzdatensätze und/ oder einen Maximalwert oder einen Minimalwert für den Gesamtbetrag der gespeicherten Münzdatensätze;
- eine vom Benutzer wählbare Vorgabe, welche insbesondere vom Benutzer zu wählen ist, so dass sie enger ist als eine vom Herausgeber der Münzverwaltungseinheit festgelegte Vorgabe; und/ oder
- eine Gegenleistungs-Vorgabe, wobei in Antwort auf mindestens einen empfangenen Münzdatensatz als Leistung die Gegenleistung, insbesondere in den Antwortdaten an den Sender des empfangenen Münzdatensatzes, bereitgestellt wird.
13. Münzverwaltungseinheit nach einem der vorhergehenden Ansprüche, wobei die Münzverwaltungseinheit (330, 31; 390) Vorgaben umfasst und eingerichtet ist, vor dem Speichern einer bedingten Transaktion die Vorgaben zu prüfen, wobei die Vorgaben vorzugsweise eine Vorgabe für bedingte Transaktionen und/ oder eine oder mehrere der Vorgaben nach Anspruch 12 umfassen.
14. Münzverwaltungseinheit (330, 31; 390) nach einem der vorhergehenden Ansprüche, wobei die Münzverwaltungseinheit ein erstes Münzdepot (310) und zumindest ein zweites Münzdepot (320, 330) aufweist; wobei das erste und das zweite Münzdepot (310, 320, 330) dem Benutzer zugeordnet sind; oder wobei in einer Münzdepotverwaltungseinheit (30) das erste Münzdepot (310) dem Benutzer und das zweite Münzdepot einem anderen Benutzer des digitalen Zentralbankwährungssystems zugeordnet ist.
15. Münzverwaltungseinheit (330, 31; 390) nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die sichere Ausführungseinheit zur Verwaltung der Münzdatensätze
- Transaktionsregisterdaten an ein Transaktionsregister sendet, wobei die Transaktionsregisterdaten insbesondere einen eindeutigen Transaktions-Identifikator, einen Transaktionsbetrag, eine Münzverwaltungseinheits-Identifikator des Senders, eine Münzverwaltungseinheits-Identifikator des Empfängers und die Registerreferenz des Münzdatensatzes im Münzregister umfassen; und/ oder
- Registrierungsanforderungen an das Münzregister sendet, welche mindestens eine Registerreferenz eines bisher im Münzregister registrierten Münzdatensatzes und eine Registerreferenz eines im Münzregister zu registrierenden Münzdatensatzes umfasst.
16. Verfahren zur Verwaltung von Münzdatensätzen eines digitalen Zentralbankwährungssystems mit Münzregister in einer Münzverwaltungseinheit, die eine Ausführungseinheit und zumindest einen Münzdatensatz der Zentralbank umfasst, mit den Schritten:
- Speichern (710) einer ersten bedingten Transaktion, die eine Bedingung für das Ausführen einer Transaktion enthält, wobei die Transaktion den Austausch zumindest eines Münzdatensatzes zwischen der Münzverwaltungseinheit und einer anderen Münzverwaltungseinheit des digitalen Zentralbankwährungssystems umfasst, wobei die erste bedingte Transaktion in der Münzverwaltungseinheit als Datenelement gespeichert wird, und wobei die erste bedingte Transaktion Lese- und/ oder Schreibrechte aufweist, die sich von Lese- und/ oder Schreibrechte einer bereits gespeicherten zweiten bedingten Transaktion unterscheiden;
- Prüfen (742) ob die Bedingung erfüllt ist; und
- Ausführen (750-758) der Transaktion erst wenn die Bedingung erfüllt ist.
17. Verfahren nach Anspruch 16, wobei die Münzverwaltungseinheit gemäß einem der Ansprüche 1 bis 15 ausgebildet ist.
18. Verfahren nach Anspruch 16 oder 17, wobei das Ausführen der Transaktion umfasst: ein Senden des Münzdatensatzes an die andere Münzverwaltungseinheit oder ein Empfangen des Münzdatensatzes von der anderen Münzverwaltungseinheit; und/ oder ein Senden einer Registrierungsanforderung an ein Münzregister (20) der Zentralbank, welche insbesondere mindestens eine Registerreferenz eines bisher im Münzregister registrierten Münzdatensatzes und eine Registerreferenz eines im Münzregister zu registrierenden Münzdatensatzes umfasst, und/ oder ein Senden von Transaktionsregisterdaten an ein Transaktionsregister, und/ oder das Bereitstellen einer Gegenleistung, insbesondere nach einem Empfangen des Münzdatensatzes als die Bedingung.
19. Verfahren nach einem der Ansprüche 16 bis 18, umfassend
- Empfangen (721, 731) einer Lese- und/ oder Schreibanfrage eines Anfragenden, insbesondere eines Benutzers der Münzverwaltungseinheit oder einer anderen Münzverwaltungseinheit, für zumindest eine bedingte Transaktion;
- optionales Prüfen (723, 733) einer Authentisierung des Anfragenden;
- Prüfen (724, 725) der Lese- und/ oder Schreibrechte der zumindest einen bedingten Transaktion,
- Beantworten der Lese- und/ oder Schreibanfrage abhängig von den Lese- und/ oder Schreibrechten, insbesondere im Fall einer Leseanfrage durch Bereitstellen der bedingten Transaktion für den Anfragenden oder im Fall einer Schreibanfrage durch Schrieben der bedingten Transaktion.
20. Verfahren nach einem der Ansprüche 16 bis 19, wobei vor dem Schritt des Speicherns (710) einer oder mehrere der folgenden Schritte ausgeführt wird:
- Prüfen (703) einer Authentisierung des Benutzers;
- Prüfen (704) einer Vorgabe für die auszuführende Transaktion und/ oder die bedingte Transaktion.
21. Digitales Zentralbankwährungs-System, umfassend: eine Vielzahl von Münzverwaltungseinheiten, die nach einem der Ansprüche 1 bis 15 ausgestaltet oder zur Ausführung eines Verfahrens nach einem der Ansprüche 16 bis 20 eingerichtet sind, das Münzregister sowie optional eine Mehrzahl von Münzdepot- Verwaltungseinheiten und/ oder ein Transaktionsregister.
EP22757842.4A 2021-09-24 2022-07-18 Münzverwaltungseinheit sowie verfahren in einer münzverwaltungseinheit Pending EP4405879A1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE102021004850 2021-09-24
DE102021005040.1A DE102021005040A1 (de) 2021-09-24 2021-10-07 Münzverwaltungseinheit sowie Verfahren in einer Münzverwaltungseinheit
PCT/EP2022/025335 WO2023046317A1 (de) 2021-09-24 2022-07-18 Münzverwaltungseinheit sowie verfahren in einer münzverwaltungseinheit

Publications (1)

Publication Number Publication Date
EP4405879A1 true EP4405879A1 (de) 2024-07-31

Family

ID=83006079

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22757842.4A Pending EP4405879A1 (de) 2021-09-24 2022-07-18 Münzverwaltungseinheit sowie verfahren in einer münzverwaltungseinheit

Country Status (2)

Country Link
EP (1) EP4405879A1 (de)
WO (1) WO2023046317A1 (de)

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9747586B1 (en) * 2016-06-28 2017-08-29 Cpn Gold B.V. System and method for issuance of electronic currency substantiated by a reserve of assets
US11107156B2 (en) * 2018-03-25 2021-08-31 Gideon Samid Digital finance: cash, credit, and investment instruments in a unified framework (BitMint)
JP6838206B2 (ja) * 2018-08-31 2021-03-03 三井物産株式会社 チケットシステム及びチケット管理装置
DE102019002731A1 (de) 2019-04-15 2020-10-15 Giesecke+Devrient Gesellschaft mit beschränkter Haftung Gerät zum direkten Übertragen von elektronischen Münzdatensätzen an ein anderes Gerät sowie Bezahlsystem
US11354662B2 (en) * 2020-02-10 2022-06-07 Izzi, Inc. System and method for implementing a payment architecture that provides instant, risk-free payment in digital cash
DE102020104906A1 (de) 2020-02-25 2021-08-26 Giesecke+Devrient Gesellschaft mit beschränkter Haftung Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungseinheit
DE102020004121A1 (de) 2020-07-08 2022-01-13 Giesecke+Devrient Gesellschaft mit beschränkter Haftung Verfahren, teilnehmereinheit, transaktionsregister und bezahlsystem zum verwalten von transaktionsdatensätzen

Also Published As

Publication number Publication date
WO2023046317A1 (de) 2023-03-30

Similar Documents

Publication Publication Date Title
DE60221880T2 (de) System und verfahren zur erzeugung eines gesicherten netzes unter verwendung von beglaubigungen von verfahrensgruppen
DE102018122997A1 (de) Blockkettenentität, kettenexterne entität, zertifizierungsvorrichtung für blockkettenoperationen und verfahren zum durchführen einer kooperation zwischen einer blockkettenentität und einer kettenexternen entität
EP3447667A1 (de) Kryptographische sicherung für eine verteilte datenspeicherung
EP1209579A1 (de) System zur automatisierten Abwicklung von Transaktionen durch aktives Identitätsmanagement
DE102021004548A1 (de) Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems
EP4315117A1 (de) Verfahren und vorrichtung zum erzeugen, bereitstellen und weitergeben eines vertrauenswürdigen elektronischen datensatzes oder zertifikates basierend auf einem einen nutzer betreffenden elektronischen dokument
DE102021005040A1 (de) Münzverwaltungseinheit sowie Verfahren in einer Münzverwaltungseinheit
WO2023011759A1 (de) Münzverwaltungseinheit sowie verfahren in einer münzverwaltungseinheit
EP4092958B1 (de) Ausstellen eines digitalen verifizierbaren credentials
EP4381408A1 (de) Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
DE102018009949A1 (de) Übertragungsverfahren zum flexiblen Übertragen von spezifisch teilbaren elektronischen Münzdatensätzen
WO2023046317A1 (de) Münzverwaltungseinheit sowie verfahren in einer münzverwaltungseinheit
EP4254234A1 (de) Ausstellen eines digitalen credentials für eine entität
EP3125464B1 (de) Sperrdienst für ein durch einen id-token erzeugtes zertifikat
WO2023011758A1 (de) Münzdepot-verwaltungseinheit sowie verfahren in einer münzdepot-verwaltungseinheit
DE102021129047B4 (de) Selektiv anonymisierende Überweisung einer Kryptowährung
EP3283999B1 (de) Elektronisches system zur erzeugung eines zertifikats
EP4123960B1 (de) Verfahren und vorrichtung zum bereitstellen eines einem geschützten datenobjekt zugeordneten digitalen nutzergeheimnisses
WO2011147693A1 (de) Verfahren zum bereitstellen von edrm (enterprise digital rights management) geschützten datenobjekten
EP3248356B1 (de) Zertifikats-token zum bereitstellen eines digitalen zertifikats eines nutzers
WO2024012624A1 (de) Verfahren zur sicheren generierung eines herausgebbaren tokens, verfahren zur sicheren vernichtung eines tokens und tokenherausgeber
EP3186741A1 (de) Zugriffsschutz für fremddaten im nichtflüchtigen speicher eines tokens
WO2021228797A1 (de) Konzept zum austausch von verschlüsselten daten
WO2021175805A1 (de) Verfahren zur selektiven bereitstellung von daten
EP3432510A1 (de) Verwalten eines digitalen zertifikats

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240424

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR