Using a distributed-ledger system to control goods deliveries

Abstract

The invention relates to a method for the computer-implemented control of a goods delivery from a goods sender to a goods recipient using an access-restricted DLT system (182). The DLT system (182) comprises a first DLT node allocated to the goods recipient and a second DLT node allocated to the goods sender. Furthermore, the DLT system (182) provides at least one smart contract with program instructions for entering and checking delivery orders (190), order confirmations (191) and goods issue logs during goods deliveries from the goods sender to the goods recipient and for validating the goods delivery. The method comprises, for example, initiating the goods delivery in the DLT system (182), for example logging the goods delivery in the DLT system (182) and / or for example validating the goods delivery in the DLT system (182).

Description

[0001] Use of a distributed ledger system to control deliveries of goods

[0002] Description

[0003] The invention relates to a method for computer-implemented control of a goods delivery from a sender to a recipient using a restricted-access DLT system. Furthermore, the invention relates to the use of a shared data set of a DLT system in the course of computer-implemented control of the goods delivery, a DLT node of the restricted-access DLT system, which is implemented on a DLT server of the DLT system and assigned to the recipient of the goods delivery, a DLT node of the restricted-access DLT system, which is implemented on a DLT server of the DLT system and assigned to the sender of the goods delivery, the restricted-access DLT system for computer-implemented control of the goods delivery, and a computer program for controlling the goods delivery using the restricted-access DLT system.

[0004] From WO 2021 / 18366 A1, a method for adapting a production process is known, wherein a first node of a first party of a blockchain network is configured to publish order transactions in the blockchain network, wherein published order transactions are validated by the blockchain network, wherein the method comprises analyzing validated order transactions in the blockchain network by at least one node of a second party of the blockchain network, wherein the analyzing comprises the following:

[0005] Identifying validated order transactions, extracting order parameters, sending the order parameters to a simulation system to simulate a production process for the ordered product based on the order parameters, receiving a capacity parameter from the simulation system, generating a quote based on the capacity parameter, and if the first-party node accepts the quote, adjusting the production process based on the quote.

[0006] This and other approaches to tracking goods utilize blockchains. However, blockchains have the disadvantage that data once entered into the blockchain cannot be modified. Furthermore, data entered into a blockchain is visible to at least all blockchain servers managing the corresponding blockchain. In the case of a public blockchain, the data entered into the blockchain is even public, meaning it is accessible to everyone.

[0007] The invention is based on the object of creating an improved method which is suitable for checking a delivery of goods and can ensure the security and confidentiality of the data used in the course of this check.

[0008] The object underlying the invention is achieved by the features of the independent patent claims. Embodiments of the invention are specified in the dependent patent claims.

[0009] Embodiments include a method for computer-implemented control of a delivery of goods from a sender to a recipient using a restricted-access DLT system. The DLT system comprises a first DLT node assigned to the recipient and a second DLT node assigned to the sender. Furthermore, the DLT system provides at least one smart contract. The at least one smart contract includes program instructions for entering and verifying delivery orders and order confirmations.

[0010] The process involves initializing the delivery of goods in the DLT system. Initialization includes:

[0011] • Receiving a delivery order from the goods recipient via a first network by the first DLT node for goods to be delivered by the goods sender to the goods recipient, wherein the delivery order specifies one or more physical properties of the goods to be delivered as a first specification, wherein the physical properties of the first specification comprise at least a quantity of goods to be delivered, • Creating a first data set managed by the first DLT node and entries of at least the one or more physical properties of the delivery order by the first DLT node into the first data set using the at least one smart contract, wherein the first data set is a first part of a data set shared between the first DLT node and the second DLT node,

[0012] • Transmitting at least the first data set from the first DLT node to the second DLT node,

[0013] • Creating a second data set managed by the second DLT node, wherein the second data set is a second part of the split data set, and first updating the second data set by the second DLT node based on the first data set, wherein the first updating comprises entering at least one or more of the physical properties of the first specification into the second data set, wherein the at least one or more entered physical properties of the first specification comprise the quantity of goods to be delivered,

[0014] • Receiving an order confirmation from the sender of goods via the first network by the second DLT node, wherein the order confirmation includes a second specification of the one or more physical properties of the goods to be delivered,

[0015] • Checking the second specification for compliance with the first specification using the at least one smart contract,

[0016] • second update of the second data set by the second DLT node using a first check result of checking the second specification,

[0017] • Transmitting at least one first update message from the second DLT node to the first DLT node,

[0018] • first update of the first data record by the first DLT node using the first update message.

[0019] Embodiments include a method that further includes logging the delivery of goods in the DLT system. The at least one smart contract includes program instructions for entering and checking outgoing goods logs during deliveries of goods from the sender of goods to the recipient of goods. The logging includes: • Receiving an outgoing goods log from the sender of goods via the first network by the second DLT node, wherein the outgoing goods log includes one or more first sensor values ​​for the one or more physical properties of the outgoing goods according to the second specification, which are detected by one or more first physical sensors assigned to the sender of goods, wherein the one or more first sensor values ​​include at least one first sensor value that quantifies the quantity of goods delivered,

[0020] • Checking the one or more first sensor values ​​of the goods issue protocol for compliance with the one or more physical properties of the goods to be delivered according to the shared data set within predefined first tolerances using the at least one smart contract, wherein the checked first sensor values ​​comprise at least the first sensor value quantifying the quantity of goods delivered,

[0021] • third updating of the second data set by the second DLT node using a second test result of checking the one or more first sensor values ​​of the goods issue protocol,

[0022] • Transmitting at least a second update message from the second DLT node to the first DLT node,

[0023] • second update of the first data record by the first DLT node using the second update message.

[0024] Embodiments include a method that further comprises validating the delivery of goods in the DLT system. The at least one smart contract comprises program instructions for validating the delivery of goods. The validation includes:

[0025] • Checking parameters of a validation message for validating the delivery of goods by the second DLT node using the at least one smart contract, wherein the parameters comprise at least one quantity of goods to be validated, wherein checking the parameters comprises checking the quantity of goods to be validated for compliance with the first sensor value quantifying the quantity of goods delivered within a predefined second tolerance,

[0026] • if the quantity of goods to be validated matches the first sensor value quantifying the quantity of goods delivered within the predefined second tolerance, fourth update of the second data set by the second DLT node, wherein the fourth update comprises registering the validation message by the second DLT node in the second data set using the at least one smart contract,

[0027] • Transmitting at least a third update message from the second DLT node to the first DLT node,

[0028] • third updating of the first data set by the first DLT node using the third update message, wherein the third updating of the first data set comprises registering the validation message in the first data set.

[0029] During the initialization of the goods delivery, a split data set is generated on two DLT nodes of a restricted-access DLT system. This split data set is a data set comprising a first partial data set on the first DLT node and a second partial data set on the second DLT node. Authorization to edit the first partial data set, i.e., write authorization, can only be held by the first DLT node (or another authorized DLT node), and thus the goods recipient. Authorization to edit the second data set, i.e., write authorization, can only be held by the second DLT node (or another authorized DLT node), and thus the goods sender.Furthermore, as a result of the access restriction of the DLT system, for example, only the recipient of the goods can have read authorization to read the first partial data set via the first DLT node (or the other authorized DLT node) and only the sender of the goods can have read authorization to read the second partial data set via the second DLT node (or the other authorized DLT node).

[0030] The term distributed ledger technology describes a technology used to record transactions or the status of transactions. In contrast to the classic approach, in which a ledger acts as a general ledger, usually managed by a single entity, any number of essentially equal copies of the ledger are maintained in a decentralized manner by different parties. Parties with at least one corresponding node in the DLT system can, for example, be senders of goods, recipients of goods, producers of goods, or suppliers of goods. Parties can also overlap, such as the producer of goods and the supplier of goods forming a single party. Furthermore, a party with at least one node can be a savings bank, a bank, a banking institution, a payment service provider, and / or a credit institution.A regulator with at least one node can also be designated as a party or participant in the DLT system to perform specific functions, such as compliance with regulatory requirements such as anti-money laundering or mandatory sanctions or embargo checks. At least one node in the DLT system can assume the function of a notary to ensure the uniqueness of each transaction and prevent duplicate use of DLT-based monetary units.

[0031] Appropriate measures are taken to ensure that newly added transactions or transaction states are adopted in all copies of the ledger and that an agreement (consensus) is reached on the current state of the ledger.

[0032] For example, the at least one smart contract, which is executed on both DLT nodes, is configured to ensure data consistency between the two sub-datasets of the split dataset. For example, mirror-image, i.e., identical, data can be implemented in both sub-datasets of the split dataset using synchronous data maintenance.

[0033] The present method does not use a blockchain, but is based, for example, on a direct data exchange between the DLT nodes of the parties involved, as well as on direct data validation by the corresponding DLT nodes. The use of a restricted-access DLT system has the advantage over a public blockchain that access to the data managed by the DLT system is restricted. For example, the participants of the DLT system each have access to only one DLT node assigned to them. Data from the shared data sets within the DLT system is transmitted, for example, only between the DLT nodes between which the shared data set is shared. For example, the transmission only takes place between the first DLT node of the recipient of the goods and the second DLT node of the sender of the goods. Unicast is used for transmission, i.e.The transmitted data is always addressed to a single recipient, i.e., a single DLT node. In contrast to broadcast transmission, as is the case with many blockchain solutions, unicast transmission has the advantage that only the sender and receiver are aware of the transmitted data. Since transactions in a blockchain are usually visible to all validating nodes, such as when transactions to be entered within the blockchain network are transmitted via broadcast, this lacks confidentiality. A blockchain typically stores data as transactions in individual blocks, which are linked to one another and managed redundantly in a distributed peer-to-peer network. As a result of this redundant management, a large number of nodes have access to all data stored in the blockchain.In contrast, embodiments of the present invention have the advantage that both data security and the confidentiality of the data stored in the shared data set can be ensured. This is achieved by ensuring that communication regarding the transactions to be mapped, i.e. the data to be stored in a shared data set, takes place within the DLT system only between the affected DLT nodes, i.e. those DLT nodes between which the corresponding data set is shared. These are, for example, only the first DLT node of the goods recipient and the second DLT node of the goods sender. The delivery of goods is controlled by means of one or more smart contracts that are executed on the nodes involved. Storage in a blockchain or other data set visible to all DLT nodes does not take place.

[0034] For this purpose, a data set shared by the participating DLT nodes is used, which comprises a first (partial) data set managed by the DLT node of the goods recipient and a second (partial) data set managed by the DLT node of the goods sender. The two (partial) data sets should correspond to each other and reflect the view of the respective responsible node. Only the responsible DLT node is authorized to change the corresponding part of the data set. The partial data sets and thus the transactions stored in the corresponding partial data sets are each transmitted to the other DLT node. For example, only changes to the corresponding partial data set are transmitted to the other DLT node. For example, the data transmitted to the other DLT node is signed. Using the signature, the other DLT node can verify whether the changes are correct.are authorized by the signing DLT node and thus by the assigned participants.

[0035] Furthermore, it is not necessary for the first and second partial data sets to be identical.

[0036] For example, one partial data set may contain one or more differing data values ​​compared to another partial data set, for example, regarding the delivery of goods, such as the quantity of the corresponding goods to be delivered, or other details. This allows, for example, tolerances to be predefined within which deviations are acceptable. Alternatively or additionally, a semi-automatic or fully automatic handshake can take place between the two DLT nodes managing the two partial data sets until agreement is reached on individual differing data values ​​of the data set, such as the goods to be delivered and their properties, i.e., the deviations have been resolved.

[0037] Embodiments can thus have the advantage of providing an approach for confidentially processing transactions between the two DLT nodes based on the data set distributed across two DLT nodes and / or the additional features described above for comparing the (partial) data sets. Furthermore, this enables the transactions to be secured and data security to be increased between the DLT nodes.

[0038] Communication between the DLT nodes takes place, for example, via transport connections secured by the Transport Layer Security (TLS) protocol. Furthermore, communication with the DLT nodes, for example, when the recipient of the goods accesses the first DLT node with a computer system assigned to the recipient of the goods and / or when the sender of the goods accesses the second DLT node with a computer system assigned to the sender of the goods, takes place via transport connections secured by TLS.

[0039] For example, all transport connections are secured with TLS. The security principle within the DLT system is based, for example, on peer-to-peer communication between the DLT nodes and the need-to-know principle. Peer-to-peer communication is based on computer-to-computer connections between equal computers. The need-to-know principle, or necessity principle, as a security goal for data, requires that access to the corresponding data not only requires basic access authorization, but that the data to be accessed is also directly necessary for the fulfillment of a specific task. Even if a DLT node, for example, has access to data of a certain or a certain security level, the need-to-know principle prohibits access if the corresponding data is not directly required by this DLT node to fulfill a specific task.

[0040] Each DLT node receives only the data that concerns it. Therefore, even a compromised DLT node cannot leak information, as it is not involved in managing shared data sets of other DLT nodes, and data within the DLT system is not publicly accessible or published.

[0041] Embodiments can have the advantage that encryption of the data in the partial data sets of the shared data set is not necessary. Data can be entered and stored in the partial data sets in plain text. The need-to-know principle ensures that relevant data is only exchanged between the participating DLT nodes. This provides effective protection of sensitive information against unauthorized access. The network architecture used in the DLT system thus already ensures effective data security and confidentiality. No data is sent to other DLT nodes that does not directly concern them or the participants assigned to them (need-to-know principle). This contrasts with the approach of a classic blockchain. In order to securely store sensitive data in a blockchain, this data must be entered and stored in encrypted form.Alternatively, only the results of applying a one-way function, such as a hash function, to the corresponding data are entered and stored. Due to the broadcast among all nodes in the system, a blockchain is typically visible to all nodes in the system, so sensitive information in a blockchain must be protected by additional measures. These additional measures, such as encryption or the application of a one-way function, only provide basic protection for the data and information stored in the blockchain.

[0042] If data is encrypted in the subsets of the shared dataset, this results in the security level of the corresponding data being further increased, based on the existing basic protection already provided by the network architecture, and not just serving to implement basic protection, as is the case with a classic blockchain. For example, the data in the subsets of the shared dataset is entered in encrypted form and / or the subsets are stored in encrypted form.

[0043] According to some embodiments, no broadcasting occurs within the DLT system, as would be the case when using a blockchain. For example, communication between DLT nodes is based on unicast or direct communication between the participating DLT nodes, e.g., via a dedicated communication connection.

[0044] Embodiments make it possible, for example, to ensure identical data regarding the transfer of goods on both sides, i.e., at the recipient and the sender, in the form of the first and second data sets. This identical data can also be integrated, for example, into connected enterprise resource planning (ERP) systems on both sides.

[0045] The resulting mirror-image data and synchronous data maintenance are advantageous for the digital integration of ordering, delivery, and financial processes between business partners, such as the goods recipient and the goods sender. For example, consistent data quality can be ensured and mutually measurable, for example, using key performance indicators (KPIs). The implementation of in-process validation ensures the sustainability of previously achieved data quality and thus prevents gradual deterioration. By providing a common location for the data inventory in the form of shared data sets for monitoring goods deliveries using the DLT system, reconciliation efforts are reduced.For example, the effort required for subsequent account reconciliation can be significantly reduced or, ideally, even eliminated entirely for both business partners. This can contribute to improving data quality and process efficiency. For example, the amount of manual work can be reduced.

[0046] First, for example, upon receipt of a delivery order comprising a first specification of the goods to be delivered, one or more physical properties of the goods to be delivered are entered into the first data set managed by the first DLT node, i.e., the first partial data set of the split data set. These one or more physical properties entered according to the first specification comprise at least one quantity of goods to be delivered.

[0047] This first data set, or the one or more physical properties entered in the first data set according to the first specification, are transmitted to the second DLT node of the goods sender. The second DLT node creates the second partial data set of the split data set, in which one or more physical properties are entered according to the first specification. The one or more physical properties entered according to the first specification comprise at least one quantity of goods to be delivered. As a result, both partial data sets of the split data set thus contain, for example, identical data.

[0048] Upon receipt of an order confirmation comprising a second specification of the one or more physical properties of the goods to be delivered, the second DLT node checks the second specification for compliance with the first specification using the at least one smart contract and updates the second data set using the result of checking the second specification.

[0049] If the second specification matches the first specification, updating the second data set using the test result includes, for example, entering a confirmation of the first specification. For example, updating the second data set using the test result includes entering the second specification in addition to the first specification into the second data set.

[0050] If the second specification deviates from the first specification, updating the second data set using the test result includes, for example, replacing or updating the physical properties according to the first specification with the deviating physical properties according to the second specification. For example, during the updating of the second data set, the deviating physical properties according to the second specification are entered into the second data set in addition to the first specification. For example, the second specification is entered into the second data set in addition to the first specification.

[0051] Furthermore, a first update message is transmitted from the second DLT node to the first DLT node. For example, the first update message indicates whether the second specification matches the first specification. If one or more physical properties according to the second specification deviate from the first specification, the first update message identifies, for example, the deviating one or more physical properties according to the second specification. For example, the first update message includes the entire second specification or a copy of the second specification.

[0052] Such a deviation of one or more physical properties according to the second specification from the first specification may occur, for example, because only a certain minimum quantity of goods is available for delivery or the goods are only delivered in certain quantity units, e.g., the size of a tank wagon or a tank truck. Such a deviation of one or more physical properties according to the second specification from the first specification may occur, for example, because the available product properties differ from the ordered product properties.

[0053] The first DLT node updates the first data set, i.e., the first partial data set of the split data set, using the first update message. If the second specification matches the first specification, updating the first data set using the first update message includes, for example, entering a confirmation of the first specification. For example, updating the first data set using the first update message includes entering the second specification in addition to the first specification into the first data set.

[0054] If the second specification deviates from the first specification, updating the first data set using the first update message includes, for example, replacing or updating the physical properties according to the first specification with the deviating physical properties according to the second specification. For example, during the updating of the first data set, the deviating physical properties according to the second specification are entered into the second data set in addition to the first specification. For example, the second specification is entered into the second data set in addition to the first specification.

[0055] If the second specification deviates from the first specification, a “handshake” is performed between the first DLT node and the second DLT node, for example, to compare the first specification with the second specification so that the first and second specifications resulting from the comparison match.

[0056] A handshake, also known as a handshake in German, refers to an automated negotiation process between two participants, in this case the two DLT nodes, through an exchange of data, in this case information on the physical properties of the goods to be delivered. In this case, the handshake can be used to establish the conditions of a goods delivery before the physical delivery of the goods begins. Using at least one smart contract, for example, a handshake protocol is executed between the two DLT nodes, the result of which is an adjustment of one or both specifications until an identical match, i.e., identity, exists between these two specifications.

[0057] If the second specification matches the first specification, a confirmation message is transmitted, for example, from the second DLT node to the sender of the goods via the network. A match between the second specification and the first specification occurs, for example, when the two specifications are identical, i.e., there is an identical match. A match between the second specification and the first specification occurs, for example, when there are no deviations that exceed a predefined tolerance range. The confirmation message indicates to the sender of the goods, for example, that an agreement on the corresponding delivery of goods has been reached between the recipient of the goods and the sender of the goods. Furthermore, the confirmation message contains, for example, the specification of the corresponding delivery of goods. For example, the corresponding confirmation message serves as a trigger for initiating the corresponding delivery of goods.Furthermore, the delivery of goods is logged in the DLT system. Once the physical delivery of goods is carried out, i.e. when the goods to be delivered leave the sender's warehouse, an outgoing goods log is created. The corresponding outgoing goods log comprises one or more sensor values ​​for the one or more physical properties of the outgoing goods according to the second specification, which are recorded using one or more physical sensors assigned to the sender. The outgoing goods log therefore specifies sensor-recorded measured values ​​for one or more physical properties for which target values ​​are specified in the second specification, which reflect the actual condition of the outgoing goods with regard to the corresponding physical properties. The corresponding sensor values ​​comprise at least one sensor value which quantifies the delivered, i.e. outgoing, quantity of goods.

[0058] The second DLT node of the goods sender receives the outgoing goods log from the goods sender via the first network and checks the one or more first sensor values ​​of the outgoing goods log for compliance with the one or more physical properties of the goods to be delivered. This checks whether the one or more sensor values ​​of the outgoing goods log match one or more physical properties according to the shared data set within predefined tolerances. If no such match exists, a warning is sent to the goods sender and / or the goods recipient. Such a warning can, for example, trigger a subsequent delivery by the goods sender if the delivery quantity is too low. Such a warning can, for example, stop the delivery process if a product property does not meet the specifications.In this case, for example, either the recipient of the goods must agree to the deviating specification and delivery will be made, or the order will be canceled. As an alternative to cancellation, the delivery date can be changed to a date on which goods meeting the specifications are available.

[0059] On the part of the goods recipient, the presence of such a warning can, for example, trigger a check of the deviating physical properties upon arrival of the goods. For example, such a warning can require confirmation of the deviating physical properties by the goods recipient for successful final validation of the goods delivery. The second data set is updated by the second DLT node using the result of the check of the one or more first sensor values ​​of the goods issue log. For example, the update comprises an entry of the goods issue log and / or one or more of the sensor values ​​specified by the goods issue log. For example, all sensor values ​​specified by the goods issue log are entered.For example, only those sensor values ​​are entered that differ from the values ​​entered in the second data set for the physical properties of the goods to be delivered. For example, for sensor values ​​in the goods issue log that match the values ​​entered in the second data set for the physical properties of the goods to be delivered, only a confirmation that the corresponding values ​​for the physical properties match the recorded sensor values ​​is entered in the second data set.

[0060] Furthermore, a second update message is transmitted from the second DLT node to the first DLT node. The second update message includes, for example, the goods issue log and / or one or more of the sensor values ​​specified by the goods issue log. For example, the second update message includes all sensor values ​​specified by the goods issue log. For example, the second update message includes only those sensor values ​​that differ from the values ​​entered in the second data set for the physical properties of the goods to be delivered.For example, the second update message for sensor values ​​of the goods issue protocol that match the values ​​for the physical properties of the goods to be delivered entered in the second data set only includes a confirmation that the corresponding values ​​for the physical properties according to the split data set match the recorded sensor values.

[0061] The first DLT node updates the first data set, i.e., the first partial data set of the split data set, using the second update message. For example, the update comprises an entry of the goods issue log and / or one or more of the sensor values ​​specified by the goods issue log. For example, all sensor values ​​specified by the goods issue log are entered. For example, only those sensor values ​​are entered that differ from the values ​​entered in the first data set for the physical properties of the goods to be delivered. For example, for sensor values ​​in the goods issue log that match the values ​​entered in the first data set for the physical properties of the goods to be delivered, only a confirmation that the corresponding values ​​for the physical properties match the recorded sensor values ​​is entered in the first data set.

[0062] Finally, the delivery of goods is validated in the DLT system. For this purpose, the second DLT node checks the parameters of a validation message for validating the delivery of goods. The checked parameters of the validation message include at least one specification of the quantity of goods delivered that is to be validated. Checking the corresponding parameters includes checking the quantity of goods to be validated for compliance with the sensor value quantifying the quantity of goods delivered according to the goods issue protocol within a predefined tolerance. If the quantity of goods to be validated matches the sensor value quantifying the quantity of goods delivered within the predefined tolerance, the second DLT node updates the second data set using the validation message. The updating includes registering the validation message by the second DLT node in the second data set.For example, during registration, an identifier of the validation message is entered into the second data record. For example, a check value, such as a hash value, of the validation message is entered into the second data record. For example, one or more parameters of the validation message are entered into the second data record. For example, the validation message is entered into the second data record.

[0063] A hash value is the result of applying a hash function, also called a hash function, to an input, also called a key. A hash function is a mapping that maps a large input set, the keys, to a smaller target set, the hash values. A hash function is therefore generally not injective. For example, the input set can contain elements of different lengths, while the elements of the target set generally have a fixed length.

[0064] For example, validation is triggered by the receipt of a validation message or by the generation of a validation message. For example, the generation of a validation message is triggered by the receipt of an acknowledgment of the delivered goods from the recipient. For example, an acknowledgment of receipt is received in the form of a goods receipt report.

[0065] Furthermore, a third update message is transmitted from the second DLT node to the first DLT node. The third update message includes, for example, the data of the validation message entered into the second data set during the update. The third update message includes, for example, the complete, updated second data set. The third update message includes, for example, the validation message.

[0066] The first DLT node updates the first data record using the third update message. Updating the first data record involves registering the validation message in the first data record. For example, during registration, an identifier of the validation message is entered into the first data record. For example, a check value, such as a hash value, of the validation message is entered into the first data record. For example, one or more parameters of the validation message are entered into the first data record. For example, the validation message is entered into the first data record.

[0067] Processing with respect to the individual participants, i.e., the sender and recipient, takes place on DLT nodes of the DLT system, which are assigned to the respective participants. The DLT system comprises, for example, a plurality of DLT servers. Two or more DLT nodes of two or more participants can be located on one and the same DLT server of the DLT system. For example, the DLT nodes of different participants are located on different DLT servers of the DLT system.

[0068] For example, a single smart contract is used to execute the process for computer-implemented control of the delivery of goods. For example, a plurality of smart contracts are deployed. For example, the individual smart contracts of the plurality of smart contracts are each configured to execute specific sub-processes, such as initialization, logging, and / or validation. A smart contract defines a set of conditions that are recorded in a DLT system and trigger automated, self-executing actions when at least some of these predefined conditions are met. A smart contract comprises program instructions that map agreed-upon rules or corresponding conditions. Such a smart contract, which defines rules for a plurality of participants, cannot be changed unilaterally.Rather, a change requires, for example, a consensus among the majority of participants. Such a consensus may require, for example, the approval of a majority of the majority of participants and / or of all participants of the majority of participants. For example, changes to the smart contract are logged. This provides a complete history of changes to the smart contract.

[0069] The network through which the DLT nodes are accessed is, for example, a TCP / IP network. The DLT nodes can be hosted on one or more servers. The DLT system can establish secure connections between the DLT servers and the DLT nodes hosted therein. However, the DLT nodes can also be implemented locally on computer systems assigned to the participants.

[0070] The one or more first physical sensors of the goods sender comprise one or more physical measuring devices for acquiring measurement data or sensor values. Measurement data is data that quantitatively or qualitatively describe the physical and / or chemical properties of a measurement object. Such properties include, for example, weight, volume, temperature, humidity, pressure, grain size, sound field parameters, brightness, pH value, ionic strength, electrochemical potential, conductivity, viscosity, and / or translucency. Measurement data is acquired using physical or chemical effects and converted into an electrical signal that can be further processed electronically. For example, the corresponding electrical signal containing the acquired measurement data is cryptographically encrypted. Symmetric, asymmetric, or hybrid cryptographic encryption can be used for this purpose.This allows the corresponding measurement data to be protected from unauthorized access, for example. Furthermore, or alternatively, the corresponding electrical signal comprising the acquired measurement data can be digitally signed. This allows, for example, the authenticity of the corresponding measurement data to be verified. Embodiments can have the advantage of being able to implement bidirectional claim settlement. This includes, for example, a 2-way match and / or a 3-way match. Furthermore, fully automated billing is enabled, for example.

[0071] With the 2-way match, a matching declaration of intent regarding delivery conditions for the delivery of goods, such as physical properties of the delivered goods and / or a price of the goods to be delivered, can be implemented using at least one smart contract and documented using the DLT system.

[0072] The "2" in the name 2-Way Match means that the delivery order and order confirmation are validated. During a 2-way match, delivery conditions for the delivery of goods, such as physical properties of the delivered goods and / or a price of the goods to be delivered, are compared according to the delivery order and order confirmation. This ensures that they match, i.e. are identical, or that any deviations do not exceed a predefined tolerance range. This 2-way match is implemented, for example, in the form of the second DLT node checking information according to the order confirmation when entering it into the second data record. For example, the delivery order includes a first price for the goods to be delivered. A price is information from which a price to be paid for the goods to be delivered can be derived. For example, the price is identical to the price to be paid.For example, the price to be paid can be derived or calculated from the price information. If the price information refers to the entire quantity of goods to be delivered, the price information corresponds to the price of the goods to be delivered. For example, the first price information is a price information per delivered quantity of goods. If a price information is per delivered quantity of goods, the actual price to be paid depends on the actual quantity of goods delivered. A price information per delivered quantity of goods, for example per piece, per weight, or per volume, must be multiplied by the quantity of goods delivered to determine the price to be paid for the delivered goods. For example, this first price information is entered into the first data set by the first DLT node according to the delivery order and transmitted to the second DLT node for entry into the second data set.For example, the order confirmation includes a second price for the goods to be delivered, in particular a second price per quantity of goods delivered. For example, this second price is checked by the second DLT node according to the order confirmation for a match with the first price and entered into the second data record during the update of the second data record using the order confirmation. This check can, for example, implement the 2-way match, or the 2-way match includes this check, for example. During a 2-way match, a price for the goods to be delivered can be compared according to the delivery order and the order confirmation. Furthermore, the update message sent to the first DLT node regarding the update of the second data record using the order confirmation includes the second price.For example, the second price information transmitted in this way is entered from the second DLT node into the second.

[0073] If the first price differs from the second price in such a way that they are not identical or the difference exceeds a predefined tolerance range, a handshake is initiated between the first DLT node and the second DLT node to compare the prices. The resulting prices are, for example, identical or have a remaining difference that does not exceed the predefined tolerance range.

[0074] With the 3-way match, delivery conditions resulting from the 2-way match, along with the information in the goods issue log regarding the actually delivered goods, can be compared with the corresponding information in the validation message and documented using the DLT system. One or more delivery conditions for the delivery of goods, such as the price of the goods to be delivered, result from the 2-way match and are not, for example, part of the goods issue log. One or more delivery conditions for the delivery of goods, such as the physical properties of the delivered goods, may differ from the result of the 2-way match. The actual values ​​for these delivery conditions, such as the quantity of goods actually delivered, are therefore recorded using the goods issue log.This makes it possible to check whether there are any deviations from the result of the 2-way match, and these deviations can be taken into account when validating the validation message. The "3" in the name 3-way match means that the corresponding validation is based on the goods issue report and the validation message, in addition to the result of the 2-way match based on the delivery order and the order confirmation. A real order contains information about certain physical properties of the goods to be delivered, which may differ during the actual delivery for efficiency and / or production reasons. For example, a real order also contains information about certain physical properties that may differ during the actual delivery due to naturally occurring variations.Therefore, for example, the physical properties of the goods to be delivered are recorded by the sender of the goods using sensors during delivery and logged in the outgoing goods log. These sensory-recorded physical properties of the delivered goods according to the outgoing goods log are recorded, for example, as physical properties of the actually delivered goods in the shared data set of the DLT system and used as the basis for checking the validation message.

[0075] For example, a real order defines a specific quantity of the ordered goods to be delivered. However, for reasons of efficiency, it can be advantageous to fully fill transport vehicles for transporting the goods to be delivered, for example in the case of bulk goods, so that the actual delivered quantity may differ from the ordered quantity. For example, a larger quantity is delivered than ordered. This actual delivered quantity can be recorded using sensors and logged in the goods issue log. For example, a real order defines certain physical properties of the ordered goods. However, for production reasons, only goods with physical properties that differ from those defined in the order can be produced. In this case, for example, the goods recipient must either agree to the deviating specification and delivery will take place, or the order will be canceled.For example, production of the goods to be delivered with the specified physical properties may be temporarily impossible, perhaps because necessary raw materials and / or raw materials with certain required physical properties are temporarily unavailable for production. Likewise, certain production resources, such as systems or system components, may be temporarily unavailable for production. In this case, as an alternative to cancellation, there is the option of changing the delivery date to a date on which goods meeting the specifications are available or can be produced.For example, in the course of a 3-way match, a price indication of the price of the goods to be delivered, in particular a price indication per quantity of goods resulting from the 2-way match, and an indication of the actually delivered quantity of goods contained in the goods issue protocol are compared with the corresponding information for price and quantity of goods contained in the validation message. Additionally or alternatively, a total price for the delivered goods is determined from a price indication per quantity of goods resulting from the 2-way match and the information for the actually delivered quantity of goods contained in the goods issue protocol and compared with a corresponding information for the total price contained in the validation message.For example, the validation message is created using the smart contract, whereby the 3-way match can ensure that the delivery conditions specified in the validation message are consistent with the delivery conditions agreed upon based on the delivery order and order confirmation, as well as the actual delivery conditions according to the goods issue protocol. Furthermore, for example, a payment of an invoice amount resulting from the validation message can be triggered using the smart contract. A corresponding check of the validation message using the smart contract can thus replace traditional invoice verification.

[0076] The aforementioned approach can be particularly advantageous for deliveries such as mass product deliveries, where delivery conditions of a delivery order and / or order confirmation may deviate, such as the actual final quantity delivered. In this case, the actual delivery conditions can be determined based on the goods issue log. In other cases, the delivery conditions are set as essentially unchangeable. For example, in the case of packaged goods, the quantity of goods to be delivered is determined by the order confirmation or the result of a handshake between the sender and recipient of the goods. The corresponding specified delivery conditions can therefore be adopted, for example, from the order confirmation or the result of the 2-way match. In such a case, the 3-way match serves to check the correspondingly adopted delivery conditions in the validation message using the goods issue log.This allows, for example, errors regarding the actual delivery conditions to be identified during validation, ensuring that these are taken into account in the validation message or that the validation message is based on the actual delivery conditions. In this case, corresponding deviations or errors can trigger the sending of a warning and / or a correction, for example, through a subsequent delivery or the delivery of the correct goods by the sender of the goods.

[0077] The system works in such a way that the signals provided by the sensors in the form of a goods issue log and / or a goods receipt log are evaluated by one of the multiple smart contracts, compared with the status of the order or goods delivery process according to the shared data set, and logged in the shared data set. Furthermore, using one or more smart contracts, a semi- or fully automated transfer of the payment amount between the eWallets or electronic wallets is initiated.

[0078] According to embodiments, the method further comprises the first DLT node signing the data transmitted from the first DLT node to the second DLT node. The at least one smart contract is configured on the second DLT node to verify the signatures of the transmitted data.

[0079] Embodiments can have the advantage that the authenticity of data transmitted by the first DLT node to the second DLT node can be verified using the corresponding signatures. This ensures that the second data set is updated by the second DLT node based on data signed and thus authorized by the first DLT node. To sign the data, the first DLT node uses, for example, a first signature key. This first signature key is, for example, a first private cryptographic key of a first asymmetric cryptographic key pair. This first signature key is stored, for example, in a protected memory area of ​​the first DLT node.For example, the second DLT node and / or the smart contract executed on the second DLT node comprises a first signature verification key for validating signatures created using the first signature key. This first signature verification key is, for example, a first public cryptographic key of the first asymmetric cryptographic key pair. Data security can thus be implemented or enhanced, for example, using cryptographic means such as hashing and / or encryption.

[0080] An asymmetric cryptographic key pair comprises a public cryptographic key, which is shared or made available to third parties, and a private cryptographic key, which is not shared or made available to third parties. The public cryptographic key enables the third party to decrypt data encrypted by the owner of the asymmetric key pair using the private cryptographic key. Furthermore, the public cryptographic key enables the third party to encrypt data, so that only the owner of the asymmetric key pair can decrypt the encrypted data using the private cryptographic key.The private key, on the other hand, allows the owner of the asymmetric key pair to encrypt data so that it can be decrypted by third parties using the public cryptographic key. Furthermore, the private cryptographic key allows the owner of the asymmetric key pair to decrypt data encrypted with the public cryptographic key. Thus, the private cryptographic key allows the owner of the asymmetric key pair to sign data, for example, while the public cryptographic key allows any third party to verify a corresponding signature.

[0081] A digital signature is an asymmetric cryptosystem in which a sender uses a secret signature key (i.e., a private cryptographic key) to calculate a value for a digital message, also called a digital signature. This value allows anyone, using a public signature verification key (i.e., a public cryptographic key), to verify the irrefutable authorship of the owner of the signature key and the integrity of the message.

[0082] The signature can, for example, be an encrypted hash value of the signed data, in particular a hash value encrypted with a private cryptographic key. The private cryptographic key is, for example, assigned to a public cryptographic key, which serves as the signature verification key. The public cryptographic key is provided, for example, as part of a certificate. A "certificate" here is understood to be a digital certificate, which is also referred to as a public key certificate. Such certificates, based on asymmetric key pairs, implement a so-called Public Key Infrastructure (PKI). Such a certificate is structured data that serves to assign a public key of an asymmetric cryptosystem to an entity, such as a person, an organization, a computer system, or a DLT node.For example, a certificate can contain a public key and be signed. For example, the certificate can conform to the X.509 standard or another standard.

[0083] The PKI provides a system for issuing, distributing, and verifying digital certificates. In an asymmetric cryptosystem, a digital certificate serves to confirm or define the authenticity of a public key and its permissible scope of application and validity. The digital certificate itself is protected by a digital signature, the authenticity of which can be verified using the public key of the certificate issuer. To verify the authenticity of the issuer key, a digital certificate is used. In this way, a chain of digital certificates can be established, each of which confirms the authenticity of the public key with which the previous certificate can be verified. Such a chain of certificates forms a so-called validation path or certification path.PKI participants must be able to rely on the authenticity of the last certificate, the so-called root certificate, and the key certified by this certificate without the need for any additional certificates. The root certificate is managed by a so-called root certification authority, whose assumed authenticity underlies the authenticity of all PKI certificates.

[0084] A certificate can be associated with a digital signature if the private cryptographic key associated with the public cryptographic key was used to generate the digital signature to be verified. Making a certificate available to the public in association with a public key enables users of asymmetric cryptosystems to associate the public key with an entity, such as a person, an organization, a computer system, or a DLT node. According to embodiments, the method further comprises the second DLT node signing the data transmitted from the second DLT node to the first DLT node. The at least one smart contract is configured on the first DLT node to verify the signatures of the transmitted data.

[0085] Embodiments can have the advantage that the authenticity of data transmitted by the second DLT node to the first DLT node can be verified using corresponding signatures. This ensures that the first data set is updated by the first DLT node based on data signed and thus authorized by the second DLT node. To sign the data, the second DLT node uses, for example, a second signature key. This second signature key is, for example, a second private cryptographic key of a second asymmetric cryptographic key pair. This second signature key is stored, for example, in a protected memory area of ​​the second DLT node.For example, the second DLT node and / or the smart contract running on the second DLT node comprises a second signature verification key for validating signatures created using the second signature key. This second signature verification key is, for example, a second public cryptographic key of the second asymmetric cryptographic key pair.

[0086] According to embodiments, the data transmission between the first DLT node and the second DLT node takes place via one or more communication connections cryptographically protected by end-to-end encryption.

[0087] Embodiments may have the advantage of ensuring that data transmitted between DLT nodes within the DLT system is effectively protected against man-in-the-middle attacks. The encryption may be, for example, symmetric encryption, asymmetric encryption, or hybrid encryption. For example, encryption is performed using the TLS encryption protocol.

[0088] According to embodiments, establishing the one or more cryptographically protected communication connections comprises mutual authentication of the TI first DLT node and the second DLT node.

[0089] Embodiments may have the advantage that, based on mutual authentication, both DLT nodes can verify with whom they are communicating via the respective communication connections. Thus, the first DLT node of the goods recipient can verify that it is actually communicating with the DLT node associated with the goods sender, i.e., the second DLT node. Furthermore, the second DLT node of the goods sender can verify that it is actually communicating with the DLT node associated with the goods recipient, i.e., the first DLT node.

[0090] According to embodiments, checking the second specification for compliance with the first specification during initialization is a check for identity. Embodiments can have the advantage of ensuring that there is an identity between the first specification according to the delivery order and the second specification according to the order confirmation. Such an identity means that the recipient of the goods and the sender of the goods have agreed on an identical specification for the goods to be delivered. In this case, for example, identical specifications are stored in both partial data sets of the split data set. If the first and second specifications differ from one another, a handshake protocol can be executed between the two DLT nodes, for example using the at least one smart contract, the result of which is an adjustment of one or both specifications until an identity is achieved.

[0091] According to embodiments, if the one or more physical properties according to the second specification entered in the second data set differ from the one or more physical properties according to the first specification from the first data set, the initializing further comprises performing a handshake between the first DLT node and the second DLT node to compare the first specification of the first data set and the second specification of the second data set such that the first and second specifications resulting from the comparison match.

[0092] The handshake can, for example, be an automatic or a semi-automatic handshake. In the case of an automatic handshake, for example, tolerance ranges for the parameters to be negotiated are defined for the recipient of the goods and the sender of the goods. In this case, deviations between parameters can be achieved by adjusting them within the respective tolerance ranges. In the case of a semi-automatic handshake, one of the two participants or a DLT node assigned to the corresponding participant receives a suggestion for a parameter value that deviates from the corresponding participant's own suggestion for the corresponding parameter. This deviating parameter value can be confirmed, for example, by receiving a user input from the corresponding participant.If the corresponding parameter value is confirmed by user input, a confirmation of the proposed parameter value can be sent to the proposing second participant during the handshake. Alternatively, a counter-proposal for the different parameter value can be received by receiving user input from the corresponding participant. During the handshake, this counter-proposal for the different parameter value can be sent to the second participant. The second participant either confirms the counter-proposal by sending a corresponding confirmation during the handshake or makes a new counter-proposal. This process can be continued, for example, until an agreement is reached on the corresponding parameter value or until a predefined termination criterion is met.A corresponding termination criterion can, for example, be a predefined maximum number of suggestions for a parameter value, an expiration of a predefined maximum time period for negotiating a parameter value, or the receipt of a user input that explicitly rejects a current suggestion for the corresponding parameter value.

[0093] The handshake can be executed or at least initiated by one or more smart contracts. Preferably, iterations of the automatic or semi-automatic handshake between the DLT nodes of the negotiating partners can be carried out by entering proposals into the respectively managed part of the shared data set, which is then transmitted to the DLT node of the negotiating partner. All changes thus remain traceable and can be reviewed by the negotiating partners. Transparency thus prevails between the negotiating partners regarding the parameters to be negotiated, since each negotiating partner's own proposal is entered into their own part of the shared data set and the counter-proposal is entered into the other part of the shared data set. Embodiments can have the advantage of providing an effective method for aligning different specifications according to the delivery order and order confirmation, i.e.different proposals for the specification between the recipient of the goods and the sender of the goods can be provided.

[0094] According to embodiments, checking the second specification for compliance with the first specification during initialization is checking for compliance within predefined third tolerances according to the at least one smart contract.

[0095] Embodiments can have the advantage that there is no need for identity between the specifications. Thus, deviations within predefined tolerances are permissible. For example, the sender of goods can adapt the specification of the goods to be delivered, such as the quantity to be delivered, within predefined limits, i.e., the tolerances, to its capabilities for delivering the requested goods.

[0096] According to embodiments, initializing further comprises performing a handshake between the first DLT node and the second DLT node to compare the first specification of the first data set and the second specification of the second data set if one or more deviations between the one or more physical properties according to the second specification entered into the second data set and the one or more physical properties according to the first specification from the first data set are greater than the predefined third tolerances. The handshake causes the first and second specifications resulting from the comparison to match within the predefined third tolerances.

[0097] Embodiments may have the advantage of providing an effective method for aligning different specifications according to the delivery order and order confirmation, i.e., different specification proposals between the goods recipient and the goods sender. Using the at least one smart contract, for example, a handshake protocol is executed between the two DLT nodes, the result of which is an adjustment of one or both specifications until deviations between the two specifications are only within the corresponding predefined tolerances. According to embodiments, the program instructions comprised by the at least one smart contract are further configured to enter and check goods receipt logs during goods deliveries from the goods sender to the goods recipient. Logging the goods delivery in the DLT system further comprises:

[0098] • Receiving a goods receipt protocol from the goods recipient via the first network by the first DLT node, wherein the goods receipt protocol comprises one or more second sensor values ​​for the one or more physical properties of the incoming goods according to the first specification, which are detected by means of one or more second physical sensors assigned to the goods recipient, wherein the one or more second sensor values ​​comprise at least one second sensor value which quantifies the quantity of goods delivered,

[0099] • Checking the one or more second sensor values ​​of the incoming goods protocol for compliance with the one or more physical properties of the goods to be delivered according to the shared data set as well as with the one or more first sensor values ​​according to the outgoing goods protocol within predefined fourth tolerances using the at least one smart contract, wherein the checked second sensor values ​​comprise at least the second sensor value quantifying the quantity of goods delivered,

[0100] • fourth updating of the first data set by the first DLT node using a third test result of checking the one or more second sensor values ​​of the goods receipt protocol,

[0101] • Transmitting at least a fourth update message from the first DLT node to the second DLT node,

[0102] • fifth update of the second data record by the second DLT node using the fourth update message.

[0103] Embodiments can have the advantage that the logging of the delivery of goods includes not only the sender's outgoing goods log for the goods actually sent but also a recipient's incoming goods log for the goods actually received.

[0104] When the physical delivery of goods is received by the recipient of the goods, i.e. when the goods to be delivered reach the recipient's warehouse, a goods receipt report is created. The corresponding goods receipt report includes one or more sensor values ​​for the one or more physical properties of the incoming goods according to the first specification, which are recorded using one or more physical sensors assigned to the recipient of the goods. The goods receipt report therefore specifies sensor-recorded measured values ​​for one or more physical properties for which target values ​​are specified in the first specification, which reflect the actual condition of the incoming goods with regard to the corresponding physical properties. The corresponding sensor values ​​include at least one sensor value that quantifies the delivered, i.e. incoming, quantity of goods.

[0105] The first DLT node of the goods recipient receives the goods receipt protocol from the goods recipient via the first network and checks the one or more second sensor values ​​of the goods receipt protocol for compliance with the one or more physical properties of the goods to be delivered. This checks whether the one or more sensor values ​​of the goods receipt protocol match one or more physical properties according to the shared data set within predefined tolerances. If no such match exists, a warning is sent to the goods recipient and / or the goods sender, for example. Such a warning can trigger a subsequent delivery by the goods sender, for example, if the delivery quantity is too low.For example, such a warning notice may require confirmation of the deviating physical properties by the recipient of the goods for a successful final validation of the delivery of the goods.

[0106] The first data set is updated by the first DLT node using the result of the check of the one or more first sensor values ​​of the goods receipt log. For example, the update comprises an entry in the goods receipt log and / or one or more of the sensor values ​​specified by the goods receipt log. For example, all sensor values ​​specified by the goods receipt log are entered. For example, only those sensor values ​​that differ from the values ​​entered in the first data set for the physical properties of the goods to be delivered are entered.For example, for sensor values ​​in the goods receipt protocol that match the values ​​for the physical properties of the goods to be delivered entered in the first data set, only a confirmation is entered in the second data set that the corresponding values ​​for the physical properties match the recorded sensor values.

[0107] Furthermore, a fourth update message is transmitted from the first DLT node to the second DLT node. The fourth update message includes, for example, the goods receipt log and / or one or more of the sensor values ​​specified by the goods receipt log. For example, the fourth update message includes all sensor values ​​specified by the goods receipt log. For example, the fourth update message includes only those sensor values ​​that differ from the values ​​entered in the first data set for the physical properties of the goods to be delivered.For example, the fourth update message for sensor values ​​of the goods receipt log that match the values ​​for the physical properties of the goods to be delivered entered in the first data set only includes a confirmation that the corresponding values ​​for the physical properties according to the shared data set match the recorded sensor values.

[0108] The second DLT node updates the second data set, i.e., the second partial data set of the split data set, using the fourth update message. For example, the update includes an entry in the goods receipt log and / or one or more of the sensor values ​​specified by the goods receipt log. For example, all sensor values ​​specified by the goods receipt log are entered. For example, only those sensor values ​​that differ from the values ​​entered in the second data set for the physical properties of the goods to be delivered are entered.For example, for sensor values ​​in the goods receipt protocol that match the values ​​entered in the second data set for the physical properties of the goods to be delivered, only a confirmation is entered in the second data set that the corresponding values ​​for the physical properties match the recorded sensor values.

[0109] The one or more second physical sensors of the goods sender comprise one or more physical measuring devices for recording measurement data or sensor values. Such measurement data is data that quantitatively or qualitatively describe the physical and / or chemical properties of a measurement object. Corresponding properties include, for example, weight, volume, temperature, humidity, pressure, grain size, sound field sizes, brightness, pH value, ionic strength, electrochemical potential, conductivity, viscosity, and / or translucency. Measurement data is recorded using physical or chemical effects and converted into an electrical signal that can be further processed electronically. For example, the corresponding electrical signal containing the recorded measurement data is cryptographically encrypted. For this purpose, symmetric, asymmetric, or hybrid cryptographic encryption can be used, for example.This allows the corresponding measurement data to be protected from unauthorized access, for example. Furthermore, or alternatively, the corresponding electrical signal containing the recorded measurement data can be digitally signed. This allows, for example, the authenticity of the corresponding measurement data to be verified.

[0110] According to some embodiments, the validation message includes an invoice. Some embodiments can have the advantage that an invoice for the delivery of goods is checked during the validation of the validation message. This ensures that the invoice's statements regarding the physical properties of the delivered goods match the actual physical properties of the delivered goods. In particular, it can be ensured that the information underlying the invoice regarding the quantity of the delivered goods matches the actual quantity of goods delivered.

[0111] According to embodiments, the program instructions comprised by the at least one smart contract are further configured to create the invoice. The invoice is created by the second DLT node using the at least one smart contract. The parameters of the validation message can be checked during the invoice creation process.

[0112] Some embodiments can have the advantage of allowing invoice creation to be integrated directly into the validation of the goods delivery. For example, registering the created invoice in the DLT system successfully completes the goods delivery verification process.

[0113] By using one or more smart contracts, additional duties and taxes, such as sales tax, can be calculated and added to the invoice amount during the invoice creation process.

[0114] According to embodiments, the invoice is received by a first ERP system of the sender of goods that creates the invoice. Embodiments can have the advantage that the DLT system can be combined with an ERP system, for example, an existing ERP system, of the sender of goods. The DLT system or the shared data set managed by the DLT system represents a single point of truth for the delivery of goods. For example, validating the invoice requires registration at least in the second data set on the second DLT node. For example, registration includes entering an invoice number of the invoice in the second data set.

[0115] For example, both the sender and the recipient of the goods each have their own independent ERP systems, while the shared data set provided in the DLT system serves as the single point of truth for both parties, i.e. the recipient of the goods as well as the sender.

[0116] An ERP system refers to an application software or IT system, or a multitude of intercommunicating application software or IT systems, used to support a company's resource planning. Complex ERP systems, for example, are divided into subsystems, i.e., application modules, which can be combined as needed. Enterprise Resource Planning (ERP) refers to the corporate task of planning, controlling, and managing personnel and resources such as capital, operating resources, materials, and information and communication technology in a timely and needs-based manner.

[0117] A core function of ERP in manufacturing companies is material requirements planning to ensure that all materials required to manufacture products and / or components are available at the right place, at the right time and in the right quantity.

[0118] For example, the ERP systems of the sender and recipient of goods can be configured to create and / or compile data relevant to the delivery of goods and make it available to the DLT system. For example, the recipient's ERP system creates the delivery order and / or the goods receipt log and sends them to the first DLT node. For example, the sender's ERP system creates the order confirmation, the goods issue log, and / or the validation message and sends them to the second DLT node.

[0119] According to embodiments, the data entered into the shared data set provided in the DLT system during the logging of the goods delivery are mirror-image data of the goods delivery from the first ERP system of the goods sender and / or a second ERP system of the goods recipient. The first and / or second ERP system are configured to control the processing of the goods delivery. By entering the mirror-image data, data consistency between the shared data set and the ERP systems is ensured.

[0120] Embodiments can have the advantage of implementing data consistency between the shared data set and the ERP systems of the sender and / or recipient. The shared data set represents a single point of truth for both participants or their mutually independent ERP systems. For example, the first DLT node receives the delivery order from the recipient's ERP system. For example, the second DLT node receives the delivery order from the sender's ERP system. The data entered in the shared data set reflects the goods delivery data stored in the first and / or second ERP system.

[0121] According to embodiments, the processing of the delivery of goods is controlled by the at least one smart contract, the program instructions of which are further configured to control the processing of the delivery of goods.

[0122] Embodiments can have the advantage that the delivery of goods can be processed by the at least one smart contract. In this case, for example, neither an ERP system is required on the part of the recipient of the goods nor on the part of the sender of the goods to process the delivery of goods. For example, a computer system of the recipient of the goods can send the delivery order directly to the first DLT node via the first network, or the first DLT node can receive the delivery order directly from the recipient's computer system. For example, a computer system of the sender of the goods can send the order confirmation directly to the second DLT node via the first network.

[0123] According to embodiments, the first network is, for example, a public network. For example, the first network is the Internet or another existing wide area network, e.g., a wireless or Ethernet-based network within a company or between participating companies.

[0124] Accordingly, depending on the embodiment, the first network may, for example, be an intranet.

[0125] According to embodiments, a prerequisite for the first DLT node to receive the delivery order from the recipient of goods is successful authentication of the recipient of goods by the first DLT node. Embodiments can have the advantage that, through successful authentication of the recipient of goods, the first DLT node can ensure that the delivery order actually originates from the recipient of goods and is authorized by them. Authentication can be performed, for example, using a first user name and a first password, which the recipient of goods must provide to the first DLT node for successful authentication. Other authentication methods, for example, using cryptographic methods, chip cards, and / or biometric data, can also be provided.

[0126] According to embodiments, a prerequisite for the second DLT node to receive the order confirmation from the goods sender is successful authentication of the goods sender by the second DLT node. Embodiments can have the advantage that the second DLT node can ensure, through successful authentication of the goods sender, that the order confirmation actually originates from the goods sender and is authorized by the sender. Authentication can be performed, for example, using a second user name and a second password, which the goods recipient must provide to the first DLT node for successful authentication. Other authentication methods, for example using cryptographic methods, chip cards, and / or biometric data, can also be provided.

[0127] According to embodiments, a prerequisite for the second DLT node to receive the outgoing goods protocol from the goods sender is successful authentication of the goods sender by the second DLT node. Embodiments can have the advantage that, through successful authentication of the goods sender, the second DLT node can ensure that the outgoing goods protocol actually originates from the goods sender and is authorized by the sender. Authentication can be performed, for example, using a second user name and a second password, which the goods recipient must provide to the first DLT node for successful authentication. Other authentication methods, for example, using cryptographic methods, chip cards, and / or biometric data, can also be provided.

[0128] According to embodiments, a prerequisite for the first DLT node to receive the goods receipt protocol from the goods recipient is successful authentication of the goods recipient by the first DLT node. Embodiments can have the advantage that, through successful authentication of the goods recipient, the first DLT node can ensure that the goods receipt protocol actually originates from the goods recipient and is authorized by the recipient. Authentication can be performed, for example, using a first user name and a first password, which the goods recipient must provide to the first DLT node for successful authentication.

[0129] According to embodiments, a prerequisite for the use of the delivery order of the goods recipient by the first DLT node is a successful signature verification of a signature of the delivery order by the first DLT node.

[0130] Embodiments may have the advantage that the authenticity of the delivery order can be verified based on the signature of the delivery order, i.e., the first DLT node can check whether the received delivery order is actually authorized by the recipient of the goods. To sign the delivery order, the recipient of the goods uses, for example, a third signature key. This third signature key is, for example, a third private cryptographic key of a third asymmetric cryptographic key pair. For example, the first DLT node and / or the smart contract executed on the first DLT node comprises a third signature verification key for validating signatures of the recipient of the goods created using the third signature key.This third signature verification key is, for example, a third public cryptographic key of the third asymmetric cryptographic key pair.

[0131] According to embodiments, a prerequisite for the use of the order confirmation of the goods sender by the second DLT node is a successful signature verification of a signature of the order confirmation by the second DLT node.

[0132] Embodiments may have the advantage that the authenticity of the order confirmation can be verified based on the signature of the order confirmation, i.e., the second DLT node can check whether the received order confirmation is actually authorized by the sender of the goods. For example, the sender of the goods uses a fourth signature key to sign the order confirmation. This fourth signature key is, for example, a fourth private cryptographic key of a fourth asymmetric cryptographic key pair. For example, the second DLT node and / or the smart contract executed on the second DLT node comprises a fourth signature verification key for validating signatures of the sender of the goods created using the fourth signature key.This fourth signature verification key is, for example, a fourth public cryptographic key of the fourth asymmetric cryptographic key pair.

[0133] According to embodiments, a prerequisite for the use of the goods issue protocol of the goods sender by the second DLT node is a successful signature verification of a signature of the goods issue protocol by the second DLT node.

[0134] Embodiments can have the advantage that the signature of the goods issue log can be used to verify the authenticity of the goods issue log, i.e., the second DLT node can verify whether the received goods issue log is actually authorized by the goods sender. For example, to sign the order confirmation, the goods sender uses the fourth signature key, whose signatures the second DLT node can validate with the fourth signature verification key.

[0135] According to embodiments, a prerequisite for the use of the goods receipt protocol of the goods recipient by the first DLT node is a successful signature verification of a signature of the goods receipt protocol by the first DLT node.

[0136] Embodiments can have the advantage that the signature of the goods receipt log can be used to verify the authenticity of the goods receipt log, i.e., the first DLT node can verify whether the received goods receipt log is actually authorized by the goods recipient. To sign the goods receipt log, the goods recipient, for example, uses the third signature key, whose signatures the first DLT node can validate with the signature verification key.

[0137] According to embodiments, the first DLT node and the second DLT node are provided by one or more DLT servers of the DLT system. For example, the first DLT node and the second DLT node are implemented on the same DLT server of the DLT system. For example, the first DLT node and the second DLT node are implemented on two different DLT servers of the DLT system.

[0138] According to embodiments, the one or more DLT servers of the DLT system are located in one or more data centers secured against unauthorized access. Embodiments can have the advantage that unauthorized physical access to the DLT servers and thus to the DLT nodes implemented on the DLT servers can be prevented by the access security. This physical access security can, for example, be implemented in addition to cryptographic access security, which prevents unauthorized access to the DLT servers or the DLT nodes via the first network, for example, the Internet. This cryptographic access security includes, for example, successful authentication as a prerequisite for access to the DLT nodes via the first network.For example, authentication requires the correct specification of a username and password of the participant, such as the sender or recipient of goods, to whom the corresponding DLT node is assigned. For example, successful authentication requires multi-factor authentication, such as two-factor authentication. Access security for the data center includes, for example, controlling access to the data center and using an alarm system to secure the data center premises. The alarm system includes, for example, an intrusion detection system (IAS), i.e., an electronically operated device used for property protection.For example, an intrusion alarm system is configured to prevent burglaries by deterring them, to notify assistance services such as the police and / or a private security company in the event of a burglary, to minimize the time required for burglars to act, to alert the immediate surroundings and any persons present, and / or to reconstruct an actual burglary.

[0139] According to embodiments, data transmission between the DLT nodes takes place via a second network.

[0140] For example, the second network is a different network from the first network. For example, the second network is a network independent of the first network. For example, the second network is the same network as the first network.

[0141] Depending on the embodiment, the second network is a private or a public network. In the case of a private network, the second network is, for example, an intranet. In the case of a public network, the second network is, for example, the Internet.

[0142] According to embodiments, the program instructions comprised by the at least one smart contract are further configured to trigger an electronic payment transaction. The payment transaction is triggered by the smart contract upon registration of the validation message in the DLT system.

[0143] Embodiments may have the advantage that payments and postings can be made in real time. Embodiments may further have the advantage that an electronic payment transaction is triggered by the registration of the validation message in the DLT system, i.e., by a successful validation of the goods delivery in the DLT system. For example, the payment transaction is triggered by the registration of the validation message in the first data record and / or the second data record. For example, the registered validation message specifies the amount to be paid in the electronic payment transaction.

[0144] Payment transactions can be linked to data streams from validation and kept in a closed data loop.

[0145] According to embodiments, the triggered electronic payment transaction is a transfer from a bank account of the recipient of the goods to a bank account of the sender of the goods.

[0146] According to embodiments, the triggered electronic payment transaction is an IBAN transfer from an IBAN account of the recipient of the goods to an IBAN account of the sender of the goods.

[0147] According to embodiments, the triggered electronic payment transaction is a transaction of an amount of programmable money executed using the DLT system.

[0148] Embodiments may have the advantage that the transaction of the amount of programmable money can take place within the DLT system. Thus, the transaction can be triggered by registering the validation message and executed directly in the DLT system, for example, using at least one smart contract.

[0149] Programmable money refers to a digital form of money in which the user can program inherent logic for conditional uses based on attributes of the digital money itself. Examples include triggering a transaction upon the fulfillment of one or more conditions, such as time, location, type of use, etc.

[0150] For example, a payment infrastructure is provided that enables the sender and recipient of goods to jointly use a programmable currency. Furthermore, validation of the delivery of goods and settlement can be carried out in a closed data loop, for example. According to embodiments, the DLT system is configured to transfer the invoice amount to be paid from a programmable money account of the recipient of goods to a programmable money account of the sender of goods. Preferably, the DLT system can be configured to transform a fiat money amount from a fiat money account assigned to the recipient of goods into an amount of programmable money in the recipient of goods' programmable money account.Furthermore, the DLT system can be configured to at least partially transform the invoice amount transferred in the form of programmable money on the goods sender's account for programmable money into a fiat money amount on a fiat money account assigned to the goods sender.

[0151] Embodiments may have the advantage that the transaction can be processed using programmable money. For this purpose, the recipient's fiat money amount can be converted into an amount of programmable money, which is used at least in part to pay for the delivered goods. The invoice amount received from the sender of the goods in the form of programmable money as payment for the delivered goods can then be converted into a fiat money amount. This fiat money amount can be credited to the sender of the goods in a fiat money account assigned to the sender.

[0152] Fiat money refers to a traditional currency, i.e., a state-established means of exchange and payment that is artificially created, unbacked, and unlimited. In other words, it is an economic asset without intrinsic value that serves as a medium of exchange.

[0153] According to embodiments, the payment transaction is logged in the DLT system using the at least one smart contract. Furthermore, electronic account statements regarding the logged payment transaction are issued to the recipient and / or the sender of the goods using the smart contract.

[0154] Embodiments can have the advantage that, in addition to executing the electronic payment transaction, electronic account statements regarding the corresponding payment transaction are also issued to the recipient and / or sender of the goods. The account statements are issued, for example, according to the MT940 standard. MT940 (MT = Message Type) is the SWIFT (Society for Worldwide Interbank Financial Telecommunication) or Banking Communication Standard for the electronic transmission of account statement data.

[0155] Further embodiments include a shared data set of a restricted-access DLT system for computer-implemented control of a goods delivery from a goods sender to a goods recipient using the DLT system. The shared data set comprises a first part. The first part is a first data set managed by a first DLT node assigned to the goods recipient. Furthermore, the shared data set comprises a second part. The second part is a second data set managed by a second DLT node assigned to the goods sender.

[0156] For example, the first data set of the first part comprises information on one or more physical properties of the goods to be delivered from a delivery order as a first specification. The physical properties of the first specification comprise at least a quantity of goods to be delivered. For example, the first data set of the first part comprises information on a second specification of the one or more physical properties of the goods to be delivered according to an order confirmation. For example, the first data set of the first part comprises a test result of a test of the second specification. For example, the first data set of the first part comprises one or more first sensor values ​​for the one or more physical properties of the goods according to an outgoing goods protocol, which are recorded using one or more physical sensors assigned to the goods sender.The one or more first sensor values ​​comprise at least one first sensor value that quantifies the quantity of goods delivered. For example, the first data set of the first part comprises a test result of a test of the first sensor values ​​of the goods issue protocol. For example, the first data set of the first part comprises one or more second sensor values ​​for the one or more physical properties of the goods according to a goods receipt protocol, which are recorded by means of one or more physical sensors assigned to the goods recipient. The one or more second sensor values ​​comprise at least one second sensor value that quantifies the quantity of goods delivered. For example, the first data set of the first part comprises a test result of a test of the second sensor values ​​of the goods issue protocol.For example, the first data record of the first part comprises a registration of a validation message for validating the delivery of goods. For example, the registration comprises information on one or more parameters of the validation message. For example, the parameters comprise at least a quantity of goods to be validated. For example, the first data record of the first part comprises a test result of a check of the parameters of the validation message.

[0157] For example, the second data set of the second part comprises information on one or more physical properties of the goods to be delivered from a delivery order as a first specification. The physical properties of the first specification comprise at least a quantity of goods to be delivered. For example, the second data set of the second part comprises information on a second specification of the one or more physical properties of the goods to be delivered according to an order confirmation. For example, the second data set of the second part comprises a test result of a test of the second specification. For example, the second data set of the second part comprises one or more first sensor values ​​for the one or more physical properties of the goods according to an outgoing goods protocol, which are recorded using one or more physical sensors assigned to the goods sender.The one or more first sensor values ​​comprise at least one first sensor value that quantifies the quantity of goods delivered. For example, the second data set of the second part comprises a test result of a test of the first sensor values ​​of the goods issue protocol. For example, the second data set of the second part comprises one or more second sensor values ​​for the one or more physical properties of the goods according to a goods receipt protocol, which properties are recorded by means of one or more physical sensors assigned to the goods recipient. The one or more second sensor values ​​comprise at least one second sensor value that quantifies the quantity of goods delivered. For example, the second data set of the second part comprises a test result of a test of the second sensor values ​​of the goods issue protocol.For example, the second data record of the second part comprises a registration of a validation message for validating the delivery of goods. For example, the registration comprises information on one or more parameters of the validation message. For example, the parameters comprise at least a quantity of goods to be validated. For example, the second data record of the second part comprises a test result of a test of the parameters of the validation message. For example, the split data record is the result of executing one or more of the aforementioned method steps of the method for computer-implemented control of the delivery of goods. For example, the split data record is the result of executing each of the aforementioned method steps of the method for computer-implemented control of the delivery of goods.

[0158] The shared dataset, which is distributed across two DLT nodes and includes the two (partial) datasets of the recipient and sender, can have the advantage of providing an effective approach for the confidential processing of transactions between the two DLT nodes. Furthermore, such a shared dataset enables effective transaction security and increases data security between the DLT nodes.

[0159] The shared data set may be used in any method according to one or more embodiments of the present description. Furthermore, the data set may be subject to, and processed and updated by, the aforementioned methods.

[0160] Further embodiments include using a shared data set according to one or more embodiments of the present description to initialize the delivery of goods in the DLT system. The shared data set can be used for initialization in any method according to one or more embodiments of the present description.

[0161] Further embodiments include using a shared data set according to one or more embodiments of the present description to log the delivery of goods in the DLT system. The shared data set can be used for logging in any method according to one or more embodiments of the present description.

[0162] Further embodiments include using a shared data set according to one or more embodiments of the present description to validate the delivery of goods in the DLT system. The shared data set can be used for validation in any method according to one or more embodiments of the present description.

[0163] Further embodiments include a DLT node of a restricted-access DLT system for computer-implemented control of a delivery of goods from a sender of goods to a recipient of goods. The DLT node is implemented on a DLT server of the DLT system and assigned to the recipient of goods. The DLT server comprises a processor and a memory with program instructions. The program instructions provide at least one smart contract on the DLT node. The program instructions providing the at least one smart contract include program instructions for entering and checking delivery orders and order confirmations.

[0164] Execution of the program instructions by the processor causes the processor to control the DLT node so that the DLT node executes the following in the course of initializing the delivery of goods in the DLT system:

[0165] • Receiving a delivery order from the goods recipient for goods to be delivered by the goods sender to the goods recipient by the DLT node via a first network, wherein the delivery order specifies one or more physical properties of the goods to be delivered as a first specification, wherein the physical properties of the first specification comprise at least a quantity of goods to be delivered,

[0166] • Creating a first data set managed by the DLT node and entries of at least one or more physical properties of the delivery order by the DLT node into the first data set using the at least one smart contract, wherein the first data set is a first part of a data set shared between the DLT node and another DLT node of the DLT system assigned to the sender of the goods,

[0167] • Transmitting at least the first data set from the DLT node to the other DLT node,

[0168] • Receiving at least one first update message from the further DLT node about an update of the second data set using a first test result of a test of a second specification of the one or more physical properties of the goods to be delivered according to an order confirmation for compliance with the first specification, first updating of the first data set by the DLT node using the first update message.

[0169] Further embodiments include a DLT node, wherein the program instructions providing the at least one smart contract include program instructions for entering and checking goods delivery logs during goods deliveries from the goods sender to the goods recipient. Execution of the program instructions by the processor of the DLT node causes the processor to further control the DLT node such that the DLT node executes the following during the process of logging the goods delivery in the DLT system:

[0170] • Receiving at least one second update message from the further DLT node about an update of the second data set using a second test result of a test of one or more first sensor values ​​of a goods issue protocol for compliance with the one or more physical properties of the goods to be delivered according to the shared data set within predefined first tolerances, wherein the one or more first sensor values ​​of the goods issue protocol are recorded by means of one or more first physical sensors assigned to the goods sender, wherein the tested first sensor values ​​comprise at least the first sensor value quantifying the quantity of goods delivered,

[0171] • second update of the first record by the DLT node using the second update message.

[0172] Further embodiments include a DLT node, wherein the program instructions providing the at least one smart contract include program instructions for validating the delivery of goods. Execution of the program instructions by the processor of the DLT node causes the processor to further control the DLT node such that, in the course of validating the delivery of goods in the DLT system, the DLT node executes the following:

[0173] • Receiving at least one third update message from the further DLT node about an update of the second data set using a validation message, wherein the update of the second data set using the validation message comprises a registration of the validation message in the second data set, wherein the update of the second data set using the validation message confirms a successful check of parameters of the validation message by the further DLT node, wherein the parameters comprise at least one quantity of goods to be validated, wherein the checking of the parameters comprises checking the quantity of goods to be validated for compliance with the first sensor value quantifying the quantity of goods delivered within a predefined second tolerance,

[0174] • third updating of the first data set by the DLT node using the third update message, wherein the third updating of the first data set comprises registering the validation message in the first data set.

[0175] For example, the DLT node is configured to execute one or more of the aforementioned method steps of the DLT node assigned to the recipient of the goods according to an exemplary embodiment of the method for computer-implemented control of the delivery of goods. For example, the DLT node is configured to execute each of the aforementioned method steps of the DLT node assigned to the recipient of the goods according to an exemplary embodiment of the method for computer-implemented control of the delivery of goods.

[0176] A "processor" is understood here to be a logic circuit used to execute program instructions. The logic circuit can be implemented on one or more discrete components, in particular on one or more chips. In particular, a "processor" is understood to be a microprocessor or a microprocessor system comprising multiple processor cores and / or multiple microprocessors.

[0177] A “program” or “program instructions” is understood here, without limitation, to mean any type of computer program that contains machine-readable instructions for controlling a functionality of the computer.

[0178] The term “memory” refers here to both volatile and non-volatile memory, in particular electronic memory or digital storage media.

[0179] "Non-volatile memory" refers to electronic memory for the permanent storage of data. Non-volatile memory can be configured as non-modifiable memory, also known as read-only memory (ROM), or as modifiable memory, also known as non-volatile memory (NVM). In particular, this can be an EEPROM, such as a Flash EEPROM, also known as Flash. Non-volatile memory is characterized by the fact that the data stored on it is retained even after the power supply is turned off.

[0180] "Volatile memory" is defined here as an electronic memory for the temporary storage of data, characterized by the fact that stored data is lost after the power supply is switched off. In particular, this can be a volatile random access memory (RAM) or a volatile processor memory.

[0181] A "protected memory area" is understood here to be an area of ​​an electronic memory to which access, i.e., read or write access, is only possible via a processor of the corresponding electronic device. According to embodiments, access by the processor coupled to the memory is only possible if a necessary condition is met. This can be, for example, a cryptographic condition, in particular, successful authentication and / or successful authorization verification of an access request.

[0182] A "communication interface" is defined here as an interface through which data can be received and sent. The communication interface can be configured as contact-based or contactless. The communication interface can be an internal or external interface, which is connected to an associated device, for example, via a cable or wirelessly.

[0183] Communication can, for example, take place via a network. A "network" is understood here to mean any transmission medium with a connection for communication, in particular a local connection or a local network, in particular a local area network (LAN), a private network, in particular an intranet, or a virtual private network (VPN). For example, a computer system can have a standard radio interface for connecting to a WLAN. Furthermore, it can be a public network, such as the Internet. Depending on the embodiment, this connection can also be established via a cellular network. A "cellular network" is understood here and below to mean a digital cellular cellular network, which can be structured according to a cellular standard such as GSM, UMTS, LTE, CDMA or another standard.

[0184] Further embodiments include a DLT node of a restricted-access DLT system for computer-implemented control of a delivery of goods from a sender of goods to a recipient of goods. The DLT node is implemented on a DLT server of the DLT system and assigned to the sender of goods. The DLT server comprises a processor and a memory with program instructions. The program instructions provide at least one smart contract on the DLT node. The program instructions providing the at least one smart contract include program instructions for entering and checking delivery orders, order confirmations, and outgoing goods logs during deliveries of goods from the sender of goods to the recipient of goods, as well as for validating the delivery of goods.

[0185] Execution of the program instructions by the processor causes the processor to control the DLT node so that the DLT node executes the following in the course of initializing the delivery of goods in the DLT system:

[0186] • Receiving at least one first data set created by another DLT node of the goods recipient from the other DLT node, wherein the first data set is a first part of a data set shared between the DLT node and the other DLT node, wherein the first data set comprises at least one or more physical properties of the goods to be delivered according to a first specification of a delivery order, wherein the physical properties of the first specification comprise at least a quantity of goods to be delivered,

[0187] • Creating a second data set managed by the DLT node, wherein the second data set is a second part of the split data set, and first updating the second data set by the DLT node based on the first data set, wherein the first updating comprises entering at least one or more of the physical properties of the first specification into the second data set, wherein the at least one or more entered physical properties of the first specification comprise the quantity of goods to be delivered, • Receiving an order confirmation from the goods sender via a first network by the DLT node, wherein the order confirmation comprises a second specification of the one or more physical properties of the goods to be delivered,

[0188] • Checking the second specification for compliance with the first specification using the at least one smart contract,

[0189] • second update of the second data set by the second DLT node using a first check result of checking the second specification,

[0190] • Transmitting at least one first update message from the DLT node to the further DLT node to update the first data record.

[0191] Further embodiments include a DLT node, wherein the program instructions providing the at least one smart contract include program instructions for entering and checking goods delivery logs during goods deliveries from the goods sender to the goods recipient. Execution of the program instructions by the processor of the DLT node causes the processor to further control the DLT node such that the DLT node executes the following during the process of logging the goods delivery in the DLT system:

[0192] • Receiving an outgoing goods protocol from the goods sender via the first network by the DLT node, wherein the outgoing goods protocol comprises one or more first sensor values ​​for the one or more physical properties of the outgoing goods according to the second specification, which are detected by means of one or more first physical sensors assigned to the goods sender, wherein the one or more first sensor values ​​comprise at least one first sensor value which quantifies the quantity of goods delivered,

[0193] • Checking the one or more first sensor values ​​of the goods issue protocol for compliance with the one or more physical properties of the goods to be delivered according to the shared data set within predefined first tolerances using the at least one smart contract, wherein the checked first sensor values ​​comprise at least the first sensor value quantifying the quantity of goods delivered,

[0194] • third updating of the second data set by the DLT node using a second test result of the testing of the one or more first sensor values ​​of the goods issue protocol, transmitting at least one second update message from the DLT node to the further DLT node for updating the first data set.

[0195] Further embodiments include a DLT node, wherein the program instructions providing the at least one smart contract include program instructions for validating the delivery of goods. Execution of the program instructions by the processor of the DLT node causes the processor to further control the DLT node such that, in the course of validating the delivery of goods in the DLT system, the DLT node executes the following:

[0196] • Checking parameters of a validation message for validating the delivery of goods by the DLT node using the at least one smart contract, wherein the parameters comprise at least one quantity of goods to be validated, wherein checking the parameters comprises checking the quantity of goods to be validated for compliance with the first sensor value quantifying the quantity of goods delivered within a predefined second tolerance,

[0197] • if the quantity of goods to be validated matches the first sensor value quantifying the quantity of goods delivered within the predefined second tolerance, fourth update of the second data set by the DLT node, wherein the fourth update comprises registering the validation message by the DLT node in the second data set using the at least one smart contract,

[0198] • Transmitting at least a third update message from the DLT node to the further DLT node to update the first data record.

[0199] For example, the DLT node is configured to execute one or more of the aforementioned method steps of the DLT node assigned to the goods sender according to an exemplary embodiment of the method for computer-implemented control of the delivery of goods. For example, the DLT node is configured to execute each of the aforementioned method steps of the DLT node assigned to the goods sender according to an exemplary embodiment of the method for computer-implemented control of the delivery of goods.

[0200] Further embodiments include a DLT system for computer-implemented control of a delivery of goods from a sender to a recipient, comprising a first DLT node assigned to the recipient and a second DLT node assigned to the sender. The first DLT node and the second DLT node are provided by one or more DLT servers of the DLT system. The DLT system provides at least one smart contract. The at least one smart contract includes program instructions for entering and verifying delivery orders and order confirmations.

[0201] The DLT system is configured to initialize the delivery of goods within the DLT system. Initialization includes:

[0202] • Receiving a delivery order from the goods recipient via a first network by the first DLT node for goods to be delivered by the goods sender to the goods recipient, wherein the delivery order specifies one or more physical properties of the goods to be delivered as a first specification, wherein the physical properties of the first specification comprise at least a quantity of goods to be delivered,

[0203] • Creating a first data set managed by the first DLT node and entering at least one or more physical properties of the delivery order into the first data set by the first DLT node using the at least one smart contract, wherein the first data set is a first part of a data set shared between the first DLT node and the second DLT node,

[0204] • Transmitting at least the first data set from the first DLT node to the second DLT node,

[0205] • Creating a second data set managed by the second DLT node, wherein the second data set is a second part of the split data set, and first updating the second data set by the second DLT node based on the first data set, wherein the first updating comprises entering at least one or more of the physical properties of the first specification into the second data set, wherein the at least one or more entered physical properties of the first specification comprise the quantity of goods to be delivered, • Receiving an order confirmation from the goods sender via the first network by the second DLT node, wherein the order confirmation comprises a second specification of the one or more physical properties of the goods to be delivered,

[0206] • Checking the second specification for compliance with the first specification using the at least one smart contract,

[0207] • second update of the second data set by the second DLT node using a first check result of checking the second specification,

[0208] • Transmitting at least one first update message from the second DLT node to the first DLT node,

[0209] • first update of the first data record by the first DLT node using the first update message.

[0210] Further embodiments include a DLT system that is further configured to perform logging of the goods delivery in the DLT system. The at least one smart contract includes program instructions for entering and checking goods delivery logs during goods deliveries from the sender to the recipient. The logging includes:

[0211] • Receiving an outgoing goods protocol from the goods sender via the first network by the second DLT node, wherein the outgoing goods protocol comprises one or more first sensor values ​​for the one or more physical properties of the outgoing goods according to the second specification, which are detected by means of one or more first physical sensors assigned to the goods sender, wherein the one or more first sensor values ​​comprise at least one first sensor value which quantifies the quantity of goods delivered,

[0212] • Checking the one or more first sensor values ​​of the goods issue protocol for compliance with the one or more physical properties of the goods to be delivered according to the shared data set within predefined first tolerances using the at least one smart contract, wherein the checked first sensor values ​​comprise at least the first sensor value quantifying the quantity of goods delivered, • third updating of the second data set by the second DLT node using a second test result of checking the one or more first sensor values ​​of the goods issue protocol,

[0213] • Transmitting at least a second update message from the second DLT node to the first DLT node,

[0214] • second update of the first data record by the first DLT node using the second update message.

[0215] Further embodiments include a DLT system that is further configured to perform validation of the goods delivery in the DLT system. The at least one smart contract includes program instructions for validating the goods delivery. The validation includes:

[0216] • Checking parameters of a validation message for validating the delivery of goods by the second DLT node using the at least one smart contract, wherein the parameters comprise at least one quantity of goods to be validated, wherein checking the parameters comprises checking the quantity of goods to be validated for compliance with the first sensor value quantifying the quantity of goods delivered within a predefined second tolerance,

[0217] • if the quantity of goods to be validated matches the first sensor value quantifying the quantity of goods delivered within the predefined second tolerance, fourth update of the second data set by the second DLT node, wherein the fourth update comprises registering the validation message by the second DLT node in the second data set using the at least one smart contract,

[0218] • Transmitting at least a third update message from the second DLT node to the first DLT node,

[0219] • third updating of the first data set by the first DLT node using the third update message, wherein the third updating of the first data set comprises registering the validation message in the first data set.

[0220] For example, the DLT system is configured to execute one or more of the aforementioned exemplary embodiments of the method for computer-implemented control of the delivery of goods. For example, the DLT system is configured to execute each of the aforementioned exemplary embodiments of the method for computer-implemented control of the delivery of goods.

[0221] Further embodiments include a computer program for controlling a delivery of goods from a sender to a recipient using a restricted-access DLT system, which comprises a first DLT node assigned to the recipient and a second DLT node assigned to the sender. The computer program provides at least one smart contract. The at least one smart contract includes program instructions for entering and verifying delivery orders and order confirmations.

[0222] The computer program includes program instructions for initializing the delivery of goods in the DLT system. Initialization includes:

[0223] • Receiving a delivery order from the goods recipient via a first network by the first DLT node for goods to be delivered by the goods sender to the goods recipient, wherein the delivery order specifies one or more physical properties of the goods to be delivered as a first specification, wherein the physical properties of the first specification comprise at least a quantity of goods to be delivered,

[0224] • Creating a first data set managed by the first DLT node and entering at least one or more physical properties of the delivery order into the first data set by the first DLT node using the at least one smart contract, wherein the first data set is a first part of a data set shared between the first DLT node and the second DLT node,

[0225] • Transmitting at least the first data set from the first DLT node to the second DLT node,

[0226] • Creating a second data set managed by the second DLT node, wherein the second data set is a second part of the split data set, and first updating the second data set by the second DLT node based on the first data set, wherein the first updating comprises entering at least one or more of the physical properties of the first specification into the second data set, wherein the at least one or more entered physical properties of the first specification comprise the quantity of goods to be delivered,

[0227] • Receiving an order confirmation from the sender of goods via the first network by the second DLT node, wherein the order confirmation includes a second specification of the one or more physical properties of the goods to be delivered,

[0228] • Checking the second specification for compliance with the first specification using the at least one smart contract,

[0229] • second update of the second data set by the second DLT node using a first check result of checking the second specification,

[0230] • Transmitting at least one first update message from the second DLT node to the first DLT node,

[0231] • first update of the first data record by the first DLT node using the first update message.

[0232] Further embodiments include a computer program that further includes program instructions for logging the delivery of goods in the DLT system. The at least one smart contract includes program instructions for entering and checking outgoing goods logs during goods deliveries from the sender to the recipient. The logging includes:

[0233] • Receiving an outgoing goods protocol from the goods sender via the first network by the second DLT node, wherein the outgoing goods protocol comprises one or more first sensor values ​​for the one or more physical properties of the outgoing goods according to the second specification, which are detected by means of one or more first physical sensors assigned to the goods sender, wherein the one or more first sensor values ​​comprise at least one first sensor value which quantifies the quantity of goods delivered,

[0234] • Checking the one or more first sensor values ​​of the goods issue protocol for compliance with the one or more physical properties of the goods to be delivered according to the shared data set within predefined first tolerances using the at least one smart contract, wherein the checked first sensor values ​​comprise at least the first sensor value quantifying the quantity of goods delivered,

[0235] • third updating of the second data set by the second DLT node using a second test result of checking the one or more first sensor values ​​of the goods issue protocol,

[0236] • Transmitting at least a second update message from the second DLT node to the first DLT node,

[0237] • second update of the first data record by the first DLT node using the second update message.

[0238] Further embodiments include a computer program that further includes program instructions for validating the delivery of goods in the DLT system. The at least one smart contract includes program instructions for validating the delivery of goods. The validation includes:

[0239] • Checking parameters of a validation message for validating the delivery of goods by the second DLT node using the at least one smart contract, wherein the parameters comprise at least one quantity of goods to be validated, wherein checking the parameters comprises checking the quantity of goods to be validated for compliance with the first sensor value quantifying the quantity of goods delivered within a predefined second tolerance,

[0240] • if the quantity of goods to be validated matches the first sensor value quantifying the quantity of goods delivered within the predefined second tolerance, fourth update of the second data set by the second DLT node, wherein the fourth update comprises registering the validation message by the second DLT node in the second data set using the at least one smart contract,

[0241] • Transmitting at least a third update message from the second DLT node to the first DLT node,

[0242] • third updating of the first data record by the first DLT node using the third update message, wherein the third updating of the first data record comprises registering the validation message in the first data record. For example, the computer program is configured to execute one or more of the aforementioned exemplary embodiments of the method for computer-implemented control of the delivery of goods. For example, the computer program is configured to execute each of the aforementioned exemplary embodiments of the method for computer-implemented control of the delivery of goods.

[0243] In further embodiments, a computer-readable data carrier or a computer-readable medium is defined which stores program instructions thereon which, when executed by at least one processor (or at least one electronic device), configure the at least one processor (or at least one electronic device) to carry out a method according to any of the preceding embodiments. The program instructions may correspond to the program instructions of the computer program according to embodiments. It should be understood that furthermore, multiple data carriers or media may be provided which configure individual processors or electronic devices for executing the provided methods.

[0244] Embodiments of the invention will be explained in more detail below with reference to the drawings. They show:

[0245] Figure 1A is a schematic flow diagram of a first part of an exemplary method for controlling a delivery of goods,

[0246] Figure 1 B is a schematic flow diagram of a second part of an exemplary method for controlling a delivery of goods,

[0247] Figure 2 is a schematic flow diagram of logging a delivery of goods using a goods receipt protocol,

[0248] Figure 3 is a schematic block diagram of an exemplary DLT system for computer-implemented control of a delivery of goods,

[0249] Figure 4 is a schematic flow diagram of an exemplary method for the computer-implemented control of a delivery of goods, Figure 5 is a schematic flow diagram of an exemplary method for the computer-implemented control of a delivery of goods,

[0250] Figure 6 is a schematic flow diagram of an exemplary method for computer-implemented control of a delivery of goods,

[0251] Figure 7 is a schematic block diagram of an exemplary system for computer-implemented control of a delivery of goods including electronic payment transactions,

[0252] Figure 8A shows a first part of a first exemplary graphical user interface,

[0253] Figure 8B shows a second part of a first exemplary graphical user interface, and

[0254] Figure 9 shows a second exemplary graphical user interface.

[0255] Elements of the following embodiments that correspond to one another are identified by the same reference numerals.

[0256] Figures 1A and 1B show an exemplary method for computer-implemented control of a goods delivery from a sender to a recipient using a restricted-access DLT system. The DLT system comprises a first DLT node assigned to the recipient and a second DLT node assigned to the sender. Furthermore, the DLT system provides at least one smart contract, which includes program instructions for entering and checking delivery orders, order confirmations, and / or goods issue logs during goods deliveries from the sender to the recipient and / or for validating the goods deliveries.

[0257] The method includes initializing the goods delivery in the DLT system, logging the goods delivery in the DLT system, and validating the goods delivery in the DLT system. The initialization is shown in Figure 1A, and the logging and validation are shown in Figure 1B.

[0258] In block 200, a delivery order from the goods recipient is received by the first DLT node via a first network. The delivery order is a delivery order for goods to be delivered by the goods sender to the goods recipient. The delivery order specifies one or more physical properties of the goods to be delivered as a first specification, which include at least a quantity of goods to be delivered.

[0259] In block 202, for example, as a result of receipt of the delivery order, the first data record managed by the first DLT node is created. This first data record is a first partial data record of a split data record. The corresponding split data record is a data record comprising the first partial data record on the first DLT node and a second partial data record on the second DLT node. Authorization to edit the first partial data record, i.e., write authorization, is held exclusively by the first DLT node, and thus by the goods recipient, while authorization to edit the second data record, i.e., write authorization, is held exclusively by the second DLT node, and thus by the goods sender.Furthermore, due to the access restriction of the DLT system, for example, only the recipient of the goods has read authorization to read the first partial data set via the first DLT node and only the sender of the goods has read authorization to read the second partial data set via the second DLT node.

[0260] In the course of creating the first data set, the first DLT node also enters at least one or more physical properties of the delivery order into the first data set using the at least one smart contract. These entered one or more physical properties include at least one quantity of goods to be delivered.

[0261] In block 204, this first data set, or the one or more physical properties entered in the first data set, are transmitted to the second DLT node of the sender of goods according to the first specification of the delivery order. In block 206, the second DLT node creates the second partial data set of the split data set, in which one or more physical properties are entered according to the first specification. The one or more physical properties entered according to the first specification comprise at least one quantity of goods to be delivered. As a result, both partial data sets of the split data set thus comprise, for example, identical data, provided that there is agreement on the individual parameters of the specification between the sender of goods and the recipient of goods, as explained below.

[0262] In block 208, the second DLT node receives an order confirmation from the goods sender via the first network, which includes a second specification of the one or more physical properties of the goods to be delivered. Upon receipt of an order confirmation, the second DLT node checks the second specification for compliance with the first specification in block 210 using the at least one smart contract, and in block 212 updates the second data set using the result of checking the second specification.

[0263] If the second specification matches the first specification, updating the second data set using the test result includes, for example, entering a confirmation of the first specification. For example, updating the second data set using the test result includes entering the second specification in addition to the first specification into the second data set.

[0264] If the second specification deviates from the first specification, updating the second data set using the test result includes, for example, replacing or updating the physical properties according to the first specification with the deviating physical properties according to the second specification. For example, during the updating of the second data set, the deviating physical properties according to the second specification are entered into the second data set in addition to the first specification. For example, the second specification is entered into the second data set in addition to the first specification.

[0265] Furthermore, in block 214, a first update message is transmitted from the second DLT node to the first DLT node. For example, the first update message indicates whether the second specification matches the first specification. If one or more physical properties according to the second specification deviate from the first specification, the first update message identifies, for example, the deviating one or more physical properties according to the second specification. For example, the first update message includes the entire second specification or a copy of the second specification.

[0266] In block 216, the first DLT node updates the first data set, i.e., the first partial data set of the split data set, using the first update message. If the second specification matches the first specification, updating the first data set using the first update message includes, for example, entering a confirmation of the first specification. For example, updating the first data set using the first update message includes entering the second specification in addition to the first specification into the first data set.

[0267] If the second specification deviates from the first specification, updating the first data set using the first update message includes, for example, replacing or updating the physical properties according to the first specification with the deviating physical properties according to the second specification. For example, during the updating of the first data set, the deviating physical properties according to the second specification are entered into the second data set in addition to the first specification. For example, the second specification is entered into the second data set in addition to the first specification.

[0268] If the second specification deviates from the first specification, for example, a handshake is performed between the first DLT node and the second DLT node to compare the first specification and the second specification so that the first and second specifications resulting from the comparison match.

[0269] If the second specification matches the first specification, a confirmation message is transmitted from the second DLT node to the sender of the goods via the network, for example. A match between the second specification and the first specification occurs, for example, when there is an identity. A match between the second specification and the first specification occurs, for example, when there are no deviations that exceed a predefined tolerance range. The confirmation message indicates to the sender of the goods, for example, that an agreement on the corresponding delivery of goods has been reached between the recipient of the goods and the sender of the goods. Furthermore, the confirmation message includes, for example, the specification of the corresponding delivery of goods. For example, the corresponding confirmation message serves as a trigger for initiating the corresponding delivery of goods.

[0270] Each of steps 200 to 216 of the method of Figure 1A may be optional.

[0271] The method from Figure 1A is preferably continued in Figure 1B with logging the delivery of goods in the DLT system. When the physical delivery of goods is carried out, i.e. when the goods to be delivered leave a warehouse of the sender, a goods issue log is created. The corresponding goods issue log comprises one or more sensor values ​​for the one or more physical properties of the outgoing goods according to the second specification, which are recorded using one or more physical sensors assigned to the sender. The goods issue log therefore specifies sensor-recorded measured values ​​for one or more physical properties for which target values ​​are specified in the second specification, which reflect the actual condition of the outgoing goods with regard to the corresponding physical properties.The corresponding sensor values ​​include at least one sensor value which quantifies the delivered, i.e. outgoing, quantity of goods.

[0272] In block 220, the second DLT node of the goods sender receives the outgoing goods protocol from the goods sender via the first network and, in block 222, checks the one or more first sensor values ​​of the outgoing goods protocol for compliance with the one or more physical properties of the goods to be delivered. This check determines whether the one or more sensor values ​​of the outgoing goods protocol match one or more physical properties according to the shared data set within predefined tolerances. If no such match exists, a warning is sent, for example, to the goods sender and / or the goods recipient. Such a warning can, for example, trigger a subsequent delivery by the goods sender if the delivery quantity is too low. On the part of the goods recipient, such a warning can, for example, trigger a review of the deviating physical properties upon arrival of the goods.For example, such a warning may require confirmation of the deviating physical properties by the recipient of the goods for successful final validation of the delivery of goods.

[0273] In block 224, the second data set is updated by the second DLT node using the result of the check of the one or more first sensor values ​​of the goods issue log. For example, the update comprises an entry in the goods issue log and / or one or more of the sensor values ​​specified by the goods issue log. For example, all sensor values ​​specified by the goods issue log are entered. For example, only those sensor values ​​that differ from the values ​​entered in the second data set for the physical properties of the goods to be delivered are entered.For example, for sensor values ​​in the goods issue protocol that match the values ​​entered in the second data set for the physical properties of the goods to be delivered, only a confirmation is entered in the second data set that the corresponding values ​​for the physical properties match the recorded sensor values.

[0274] In block 226, a second update message is transmitted from the second DLT node to the first DLT node. The second update message includes, for example, the goods issue log and / or one or more of the sensor values ​​specified by the goods issue log. For example, the second update message includes all sensor values ​​specified by the goods issue log. For example, the second update message includes only those sensor values ​​that differ from the values ​​entered in the second data set for the physical properties of the goods to be delivered.For example, the second update message for sensor values ​​of the goods issue log that match the values ​​for the physical properties of the goods to be delivered entered in the second data set only includes a confirmation that the corresponding values ​​for the physical properties according to the split data set match the recorded sensor values. In block 228, the first DLT node updates the first data set, i.e., the first partial data set of the split data set, using the second update message. For example, the update includes an entry of the goods issue log and / or one or more of the sensor values ​​specified by the goods issue log. For example, all sensor values ​​specified by the goods issue log are entered.For example, only those sensor values ​​are entered that differ from the values ​​entered in the first data set for the physical properties of the goods to be delivered. For example, for sensor values ​​in the goods issue log that match the values ​​entered in the first data set for the physical properties of the goods to be delivered, only a confirmation that the corresponding values ​​for the physical properties match the recorded sensor values ​​is entered in the first data set.

[0275] Finally, the delivery of goods is validated in the DLT system. For this purpose, in block 240, parameters of a validation message for validating the delivery of goods are checked by the second DLT node. The checked parameters of the validation message include at least one specification of the quantity of goods delivered that is to be validated. Checking the corresponding parameters includes checking the quantity of goods to be validated for compliance with the sensor value quantifying the quantity of goods delivered according to the goods issue protocol within a predefined tolerance. If the quantity of goods to be validated matches the sensor value quantifying the quantity of goods delivered within the predefined tolerance, the second data set is updated by the second DLT node in block 242 using the validation message.Updating involves registering the validation message by the second DLT node in the second data set. For example, during registration, an identifier of the validation message is entered into the second data set. For example, a check value, such as a hash value, of the validation message is entered into the second data set. For example, one or more parameters of the validation message are entered into the second data set. For example, the validation message is entered into the second data set.

[0276] For example, validation is triggered by the receipt of a validation message or by the generation of a validation message. For example, the generation of a validation message is triggered by the receipt of an acknowledgment of the delivered goods from the recipient. For example, an acknowledgment of receipt is received in the form of a goods receipt report.

[0277] In block 244, a third update message is transmitted from the second DLT node to the first DLT node. The third update message includes, for example, the data of the validation message entered into the second data set during the update. The third update message includes, for example, the complete, updated second data set. The third update message includes, for example, the validation message.

[0278] In block 246, the first DLT node updates the first data record using the third update message of the second data record. Updating the first data record includes registering the validation message in the first data record. For example, during registration, an identifier of the validation message is entered into the first data record. For example, a check value, such as a hash value, of the validation message is entered into the first data record. For example, one or more parameters of the validation message are entered into the first data record. For example, the validation message is entered into the first data record.

[0279] Each of steps 220 to 246 of the method according to Figure 1B may be optional. Furthermore, steps 220 to 246 may be combined with one or more of steps 200 to 216 according to Figure 1A and in any order.

[0280] Figure 2 shows an example of logging a goods delivery using a goods receipt log. For this purpose, the program instructions contained in the at least one smart contract are further configured to enter and check goods receipt logs during goods deliveries from the sender to the recipient.

[0281] When the physical delivery of goods is received by the recipient of the goods, i.e. when the goods to be delivered reach the recipient's warehouse, a goods receipt report is created. The corresponding goods receipt report includes one or more sensor values ​​for the one or more physical properties of the incoming goods according to the first specification, which are recorded using one or more physical sensors assigned to the recipient of the goods. The goods receipt report therefore specifies sensor-recorded measured values ​​for one or more physical properties for which target values ​​are specified in the first specification, which reflect the actual condition of the incoming goods with regard to the corresponding physical properties. The corresponding sensor values ​​include at least one sensor value that quantifies the delivered, i.e. incoming, quantity of goods.

[0282] In this case, logging the goods delivery in the DLT system according to Figure 1B comprises block 230. In block 230, the first DLT node receives a goods receipt log from the goods recipient via the first network. Furthermore, the first DLT node checks the one or more second sensor values ​​of the goods receipt log for compliance with the one or more physical properties of the goods to be delivered. This check determines whether the one or more sensor values ​​of the goods receipt log match one or more physical properties according to the shared data set within predefined tolerances. If no such match exists, a warning is transmitted, for example, to the goods recipient and / or the goods sender. Such a warning can, for example, trigger a subsequent delivery by the goods sender if the delivery quantity is too low.For example, such a warning notice may require confirmation of the deviating physical properties by the recipient of the goods for a successful final validation of the delivery of the goods.

[0283] In block 232, the first data set is updated by the first DLT node using the result of the check of the one or more first sensor values ​​of the goods receipt log. For example, the update comprises an entry in the goods receipt log and / or one or more of the sensor values ​​specified by the goods receipt log. For example, all sensor values ​​specified by the goods receipt log are entered. For example, only those sensor values ​​that differ from the values ​​entered in the first data set for the physical properties of the goods to be delivered are entered.For example, for sensor values ​​in the goods receipt protocol that match the values ​​for the physical properties of the goods to be delivered entered in the first data set, only a confirmation is entered in the second data set that the corresponding values ​​for the physical properties match the recorded sensor values.

[0284] Furthermore, in block 234, a fourth update message is transmitted from the first DLT node to the second DLT node. The fourth update message includes, for example, the goods receipt log and / or one or more of the sensor values ​​specified by the goods receipt log. For example, the fourth update message includes all sensor values ​​specified by the goods receipt log. For example, the fourth update message includes only those sensor values ​​that differ from the values ​​entered in the first data set for the physical properties of the goods to be delivered.For example, the fourth update message for sensor values ​​of the goods receipt log that match the values ​​for the physical properties of the goods to be delivered entered in the first data set only includes a confirmation that the corresponding values ​​for the physical properties according to the shared data set match the recorded sensor values.

[0285] Finally, in block 236, the second DLT node updates the second data set, i.e., the second partial data set of the split data set, using the fourth update message. For example, the update includes an entry in the goods receipt log and / or one or more of the sensor values ​​specified by the goods receipt log. For example, all sensor values ​​specified by the goods receipt log are entered. For example, only those sensor values ​​that differ from the values ​​entered in the second data set for the physical properties of the goods to be delivered are entered.For example, for sensor values ​​in the goods receipt protocol that match the values ​​entered in the second data set for the physical properties of the goods to be delivered, only a confirmation is entered in the second data set that the corresponding values ​​for the physical properties match the recorded sensor values.

[0286] Each of steps 230 to 236 of the method according to Figure 2 can be optional. Furthermore, steps 230 to 236 can be combined as desired with one or more of steps 200 to 216 according to Figure 1A and / or one or more of steps 220 to 246 according to Figure 1B, and in any order. Figure 3 shows an exemplary DLT system 182 for the computer-implemented control of a goods delivery from a goods sender to a goods recipient. The DLT system 182 comprises a plurality of DLT servers 140, 160. The DLT system 182 comprises a first DLT node assigned to the goods recipient, which is provided by a first DLT server 140 of the DLT system 182. In addition, the DLT system 182 includes a second DLT node assigned to the sender of goods, which is provided by a second DLT server 160 of the DLT system 182. However, it should be understood that the DLT nodes can also be located on a single DLT server, e.g.DLT server 140 or DLT server 160, and the present description is not limited to deploying DLT nodes on separate DLT servers.

[0287] The first DLT server 140 includes a processor 142 configured to execute program instructions 144. The program instructions 144 implement the first DLT node of the goods recipient on the first DLT server 140. The program instructions 144 implement one or more smart contracts for execution by the first DLT node on the first DLT server 140. The program instructions 144 implementing the one or more smart contracts include program instructions for executing a method, for example, the method according to Figures 1A and / or 1B or parts thereof, for the computer-implemented control of a goods delivery from a goods sender to a goods recipient using the access-restricted DLT system 182.The process may include entering and checking delivery orders, order confirmations and / or goods issue records in the course of deliveries of goods from the sender of goods to the recipient of goods and / or validating the deliveries of goods, in any combination.

[0288] Furthermore, the first DLT server 140 has a memory 146 and a communication interface 156. The communication interface 156 is configured so that the first DLT server 140 can communicate via a network 184, for example, with a computer system 120 of the goods recipient. The network 184 is, for example, the Internet. Furthermore, the communication interface 156 is, for example, for communication via a DLT network 180 with other DLT servers of the DLT system, for example with the second DLT server 160 on which the DLT node of the goods sender is implemented. The DLT network 180 can, for example, be included in the network 184. For example, the DLT network 180 is an independent network, such as an intranet.

[0289] For example, a private cryptographic key 154 of an asymmetric key pair assigned to the first DLT node of the goods recipient is stored in a protected storage area 152 of the memory 146 of the first DLT server 140. This private cryptographic key 154 serves, for example, as a signature key for creating electronic signatures of the first DLT node. Corresponding signatures can be verified with a public cryptographic key 150 of the corresponding asymmetric key pair. For example, the public cryptographic key 150 is provided as part of a certificate. The first DLT node of the goods recipient makes this public cryptographic key 150, or the certificate comprising the public cryptographic key 150, available to other DLT nodes, such as the second DLT node of the goods sender, as a signature verification key.

[0290] The second DLT server 160 includes a processor 162 configured to execute program instructions 164. The program instructions 164 implement the second DLT node of the goods sender on the second DLT server 160. The program instructions 164 also implement one or more smart contracts on the second DLT server 160 for execution by the second DLT node. The smart contracts on the second DLT node can correspond to the smart contracts on the first DLT node, ensuring that both DLT nodes define corresponding behavior.The program instructions 164 implementing the one or more smart contracts comprise program instructions for executing a method, for example the method according to Figures 1A and / or 1B or parts thereof, for the computer-implemented control of a delivery of goods from a sender of goods to a recipient of goods using the access-restricted DLT system 182. The method may comprise entering and checking delivery orders, order confirmations and / or outgoing goods protocols in the course of deliveries of goods from the sender of goods to the recipient of goods and / or validating the deliveries of goods, in any combination.

[0291] Furthermore, the second DLT server 160 has a memory 166 and a communication interface 176. The communication interface 176 is configured to enable the first DLT server 160 to communicate, for example, with a computer system 100 of the goods sender via the network 184. Furthermore, the communication interface 176 is configured, for example, to communicate via the DLT network 180 with other DLT servers of the DLT system, such as with the first DLT server 140 on which the goods sender's DLT node is implemented.

[0292] For example, a private cryptographic key 174 of an asymmetric key pair assigned to the second DLT node of the sender of goods is stored in a protected storage area 172 of the memory 166 of the second DLT server 160. This private cryptographic key 174 serves, for example, as a signature key for creating electronic signatures of the second DLT node. Corresponding signatures can be verified with a public cryptographic key 170 of the corresponding asymmetric key pair. For example, the public cryptographic key 170 is provided as part of a certificate. The first DLT node of the sender of goods makes this public cryptographic key 170, or the certificate comprising the public cryptographic key 170, available to other DLT nodes, such as the first DLT node of the recipient of goods, as a signature verification key.

[0293] During the initialization of the goods delivery, a split data set is generated on the two DLT nodes, comprising a first partial data set 148 on the first DLT node and a second partial data set 168 on the second DLT node. The first partial data set 148 is stored in the memory 146 of the first DLT server 140. The second partial data set 168 is stored in the memory 166 of the second DLT server 160.

[0294] Authorization to edit the first partial data set, i.e., write authorization, is exclusively held by the first DLT node, and thus the goods recipient, while authorization to edit the second data set, i.e., write authorization, is exclusively held by the second DLT node, and thus the goods sender. Furthermore, due to the access restriction of the DLT system, for example, only the goods recipient has read authorization to read the first partial data set via the first DLT node implemented on the first DLT server 140, and only the goods sender has read authorization to read the second partial data set via the second DLT node implemented on the second DLT server 160.Execution of the program instructions 144 by the processor 142 causes the processor 142 to control the first DLT server 140 such that the first DLT node implemented on the first DLT server 140 receives a delivery order from the goods recipient for goods to be delivered by the goods sender to the goods recipient during the initialization of the goods delivery in the DLT system 182. The first DLT node receives the delivery order, for example, via the network 184 from a computer system 120 of the goods recipient. The delivery order specifies one or more physical properties of the goods to be delivered as a first specification. The physical properties of the first specification comprise at least a quantity of goods to be delivered.

[0295] The recipient's computer system 120 includes a processor 130 configured to execute program instructions 132. The program instructions 132 cause the recipient's computer system 120 to communicate, for example, via the network 184 with the recipient's first DLT server 140 or the recipient's first DLT node implemented on the recipient's first DLT server 140. For example, the recipient's computer system 120 sends the delivery order to the first DLT node. For this purpose, the recipient's computer system 120 includes a communication interface 136 for communicating via the network 184.

[0296] Furthermore, the computer system 120 has a memory 122. For example, a private cryptographic key 128 of an asymmetric key pair assigned to the recipient of the goods is stored in a protected memory area 126 of the memory 122 of the computer system 120. This private cryptographic key 128 serves, for example, as a signature key for creating electronic signatures of the recipient of the goods. Corresponding signatures can be verified with a public cryptographic key 124 of the corresponding asymmetric key pair. For example, the public cryptographic key 124 is provided as part of a certificate. This public cryptographic key 124 orThe computer system 120 makes the certificate containing the public cryptographic key 124 available to other parties, such as the first DLT node of the goods recipient implemented on the first DLT server 140, as a signature verification key. The first node creates the data set 148 managed by the DLT node and enters at least one or more physical properties of the delivery order into the first data set 148 using the at least one smart contract.

[0297] Furthermore, at least the first data set 148 is sent from the first DLT node or the first DLT server 140 via the DLT network 180 to the second DLT node implemented on the second DLT server 160. The first DLT node receives at least one first update message about an update of the second data set 168 on the second DLT server from the second DLT node or the second DLT server 160 via the DLT network 180. The update was performed using a first test result of a check of a second specification of the one or more physical properties of the goods to be delivered according to an order confirmation from the goods sender for compliance with the first specification according to the goods recipient's delivery order. The first data set 148 is then updated by the first DLT node using the first update message.

[0298] The second DLT server 160 receives the corresponding order confirmation, for example, via the network 184 from a computer system 100 of the goods sender. The computer system 160 of the goods recipient comprises a processor 110 configured to execute program instructions 112. The program instructions 112 cause the computer system 100 to communicate, for example, via the network 184, with the second DLT server 160 or the second DLT node of the goods sender implemented on the second DLT server 160. For example, the computer system 100 of the goods sender sends the order confirmation to the second DLT node. For this purpose, the computer system 100 comprises a communication interface 116 for communication via the network 184.

[0299] Furthermore, the computer system 100 has a memory 102. For example, a private cryptographic key 108 of an asymmetric key pair assigned to the goods recipient is stored in a protected memory area 106 of the memory 102 of the computer system 100. This private cryptographic key 108 serves, for example, as a signature key for creating electronic signatures of the goods sender. Corresponding signatures can be verified with a public cryptographic key 104 of the corresponding asymmetric key pair. For example, the public cryptographic key 104 is provided as part of a certificate. This public cryptographic key 104 orThe computer system 100 makes the certificate comprising the public cryptographic key 104 available to other parties, such as the second DLT node of the sender of goods implemented on the second DLT server 160, as a signature verification key.

[0300] Furthermore, execution of the program instructions by processor 142 causes processor 142 to control the first DLT node such that, in the course of logging the goods delivery in DLT system 182, the DLT node receives at least one second update message from the second DLT node concerning an update of second data set 168. This second update is an update using a second test result of a test of one or more first sensor values ​​of an outgoing goods log for compliance with the one or more physical properties of the goods to be delivered according to the shared data set within predefined first tolerances. This one or more first sensor values ​​of the outgoing goods log are recorded by one or more physical sensors 113 assigned to the goods sender.The checked first sensor values ​​include at least the first sensor value quantifying the quantity of goods delivered. The first data set 148 is then updated by the DLT node using the second update message.

[0301] Finally, execution of program instructions 144 by processor 142 causes processor 142 to control the first DLT node such that, in the course of validating the delivery of goods in DLT system 182, the first DLT node receives at least a third update message from the second DLT node concerning an update of the second data set 168 using a validation message. Updating the second data set 168 using the validation message includes registering the validation message in the second data set 168. Updating the second data set 168 using the validation message confirms a successful check of parameters of the validation message by the second DLT node. These parameters include at least a quantity of goods to be validated.Checking the parameters includes checking the quantity of goods to be validated for compliance with the first sensor value quantifying the delivered quantity of goods within a predefined second tolerance. Finally, the first DLT node updates the first data set 148 using the third update message. Updating the first data set 148 includes registering the validation message in the first data set 148.

[0302] Execution of the program instructions 164 by the processor 162 causes the processor 162 to control the second DLT server 160 such that the second DLT node implemented on the second DLT server 160 receives, during the initialization of the goods delivery in the DLT system 182, at least the first data set 148 created by the first DLT node of the goods recipient, which includes at least one or more physical properties of the goods to be delivered according to the first specification of the delivery order. The second DLT node then creates the second data set 168 managed by the DLT node. Furthermore, the second DLT node updates the created second data set 168.The updating comprises entering at least one or more physical properties of the first specification into the second data set 168, which at least one or more entered physical properties of the first specification comprise the quantity of goods to be delivered.

[0303] Furthermore, the second DLT node receives the order confirmation from the goods sender's computer system 100 via the network 184. The order confirmation includes the second specification of the one or more physical properties of the goods to be delivered. The second DLT node checks the second specification for compliance with the first specification using the one or more smart contracts and updates the second data set 168 using the resulting check result. Finally, the second DLT node transmits at least the first update message to the first DLT node to update the first data set 148.

[0304] Execution of program instructions 164 by processor 162 further causes processor 162 to control the second DLT node such that, in the course of logging the goods delivery in DLT system 182, the second DLT node receives the outgoing goods log from the goods sender via the first network 184. For example, the second DLT node receives the outgoing goods log from the goods sender's computer system 100. The outgoing goods log includes one or more first sensor values ​​for the one or more physical properties of the outgoing goods according to the second specification, which are detected by one or more physical sensors 114 assigned to the goods sender.

[0305] The second DLT node checks the one or more first sensor values ​​of the goods issue protocol for compliance with the one or more physical properties of the goods to be delivered according to the split data set or the second partial data set 168 of the split data set within predefined first tolerances. To do so, the second DLT node uses one of the one or more smart contracts. The checked first sensor values ​​include at least the first sensor value quantifying the quantity of goods delivered. The second DLT node updates the second data set 168 using the check result. Furthermore, the second DLT node transmits at least the second update message to the first DLT node to update the first data set 148.

[0306] Finally, execution of the program instructions 164 by the processor 162 causes the processor 162 to control the second DLT node such that, in the course of validating the delivery of goods in the DLT system 182, the second DLT node checks the parameters of the validation message for validating the delivery of goods using the one or more smart contracts. The checked parameters include at least the quantity of goods to be validated. Checking the parameters includes checking the quantity of goods to be validated for compliance with the first sensor value quantifying the delivered quantity of goods within the predefined tolerance. If the quantity of goods to be validated matches the first sensor value quantifying the delivered quantity of goods within the predefined tolerance, the second DLT node updates the second data set 168.This updating includes the second DLT node registering the validation message in the second data set 168 using at least one of the one or more smart contracts. Furthermore, the second DLT node transmits the corresponding update message for registering the validation message to the first DLT node for updating the first data set 148.

[0307] According to alternative embodiments, the first DLT node and the second DLT node can also be implemented on a common DLT server of the DLT system 180. According to alternative embodiments, the first DLT node can also be implemented, for example, on the computer system 120 of the goods recipient and / or the second DLT node can be implemented on the computer system 100 of the goods sender.

[0308] Figure 4 shows a schematic flow diagram of an exemplary method for computer-implemented control of a goods delivery from a goods sender to a goods recipient. In step 300, the goods recipient sends a delivery order 190 to a DLT node assigned to it in the DLT system 182. This delivery order 190 specifies, for example, an order number and a product number, as a physical property of the corresponding goods, for example, a quantity of the goods to be delivered. This sending of the delivery order 190 results in a first partial data record of a split data record being generated in the DLT system 182 using the delivery order 190. The data of the delivery order 190 is also transmitted to the goods sender. The status of the goods delivery is "proposed" at this stage. In step 302, the goods sender sends an order confirmation 191 to a DLT node assigned to it in the DLT system 182.This order confirmation 191 specifies, for example, the quantity of the goods to be delivered, in addition to the order number and the product number, as a physical property of the corresponding goods. This confirmation is entered, for example, into a second partial data record of the split data record on the DLT node of the goods sender in the DLT system 182. If the quantity specified in the order confirmation 191 matches the quantity specified in the delivery order 190, the delivery of goods assumes the status "confirmed" in the DLT system 182. The data of the order confirmation 191 or an update of the second partial data record is also transmitted to the goods recipient.

[0309] In addition, in step 304, for example, the goods recipient can send an update 192 to the delivery order 190 with a new quantity specification to the DLT system 182 or the first DLT node assigned to it in the DLT system 182. The first DLT node enters this update to the specification of the goods delivery, for example, in the first partial data record and also transmits it to the goods sender or the second DLT node assigned to the goods sender. In this case, the status of the goods delivery in the DLT system 182 changes to “updated,” for example. In step 306, the goods sender sends an update 193 to the order confirmation 191 with the new quantity specification to the DLT system 182 or the second DLT node assigned to it in the DLT system 182. The second DLT node enters this update to the confirmation of the specification of the goods delivery, for example, in the second partial data record and also transmits it to the goods recipient orthe first DLT node assigned to the goods recipient. In this case, the status of the goods delivery in the DLT system 182 changes back to "confirmed," for example. Once the goods delivery has been completed, the goods sender sends a validation message, such as an invoice, to the DLT system in step 194 for validation or to update the shared data set using the validation message 194. Validation includes, for example, checking the details of the validation message with the specifications of the goods delivery stored in the shared data set. If these match, the validation message is registered in the shared data set in the DLT system 182. For example, an invoice number of the validation message is stored in the shared data set. The status of the goods delivery in the DLT system 182 changes in this case, for example, to "completed."

[0310] Figure 5 shows a further schematic flow diagram of an exemplary method for computer-implemented control of a goods delivery from a goods sender to a goods recipient. A first DLT node of the goods recipient and a second DLT node of the goods sender perform the following steps using one or more smart contracts: In step 320, the first DLT node creates a first partial data set of a shared data set and updates it with data from a delivery order of the goods recipient. This first partial data set is sent to the second DLT node of the goods sender. The second DLT node creates a second partial data set of the shared data set with the data from the delivery order. The status of the goods delivery is "proposed" at this stage. In step 322, the second DLT node updates the second partial data set with data from an order confirmation of the goods sender.Furthermore, an update message about the update of the second partial data set is sent to the first DLT node of the goods recipient using the order confirmation. The first DLT node updates the first partial data set accordingly. Subsequently, one or more update steps and / or a cancellation can occur, for example.

[0311] In step 324, for example, the first DLT node updates the first partial data record based on an update to the delivery order. For example, the quantity, delivery date, price, etc. of the goods to be delivered are updated. This update is transmitted to the second DLT node. The second DLT node notes this update, for example, in the second partial data record. The status of the goods delivery thus changes to "updated." In step 326, the second DLT node confirms the proposed update, for example, based on an updated order confirmation, and enters this confirmation in the second partial data record. This confirmation of the update is transmitted to the first DLT node. The first DLT node notes this confirmation, for example, in the first partial data record. The status of the goods delivery thus changes back to "confirmed."

[0312] An update to the delivery conditions can also originate from the goods sender. In step 328, for example, the second DLT node updates the second partial data record based on an update to the order confirmation. For example, the quantity, delivery date, price, etc. of the goods to be delivered are updated. This update is transmitted to the first DLT node. The first DLT node notes this update, for example, in the first partial data record. The status of the goods delivery thus changes to "updated." In step 330, the first DLT node confirms the proposed update, for example, based on an updated delivery order, and enters this confirmation in the first partial data record. This confirmation of the update is transmitted to the second DLT node. The second DLT node notes this confirmation, for example, in the second partial data record. The status of the goods delivery thus changes back to "confirmed."

[0313] Likewise, the delivery of goods can also be canceled by the sender or recipient of the goods. In step 332, the first or second DLT node enters a cancellation in the first or second partial data set, for example, based on a received cancellation notification. Furthermore, a cancellation notification is transmitted to the second or first DLT node. The second or first DLT node notes the corresponding cancellation in the second or first partial data set. In this case, the status of the delivery of goods changes to "cancelled," and the process is terminated.

[0314] If no cancellation occurs, the second DLT node updates the second partial data record in step 334 based on a validation message check, for example, for a completed delivery of goods. If the check is successful, the validation message is registered in the second partial data record; for example, an identifier of the validation message, such as an invoice number, is entered into the second partial data record. This update is transmitted to the first DLT node. The first DLT node notes this update in the first partial data record, for example, by also registering the validation message. The status of the goods delivery thus changes to "completed."

[0315] Both the first and the second DLT nodes according to Figure 5 can have one or more features of the DLT nodes according to Figure 3 implemented on the first and second DLT servers 140, 160. Furthermore, the DLT nodes according to Figure 5 can be configured to at least partially execute the method according to Figures 1A and / or 1B or parts thereof.

[0316] Figure 6 shows a further schematic flow diagram of an exemplary method for computer-implemented control of a goods delivery from a goods sender to a goods recipient using a DLT system 182. In step 350, the goods recipient or a computer system 120 of the goods recipient sends a delivery order to a first DLT node assigned to the goods recipient in the DLT system 182. In step 352, the goods sender or a computer system 100 of the goods sender sends an order confirmation to a second DLT node assigned to the goods sender in the DLT system 182. Based on the delivery order and the order confirmation, conditions of the goods delivery are entered into two partial data records of a split data record and compared with each other in a 2-way match. This ensures that the conditions according to the delivery order and the order confirmation match each other.In the course of executing the delivery of the goods to be delivered, the goods sender or a computer system 100 of the goods sender sends an outgoing goods report to the second DLT node in the DLT system 182 in step 354. The outgoing goods report includes sensor values ​​for physical properties of the outgoing goods, which were recorded using physical sensors of the goods sender and include at least one sensor value that quantifies the quantity of goods delivered. Furthermore, the goods sender or a computer system 100 of the goods sender sends a validation message to the second DLT node in the DLT system 182 in step 356. Based on the result of the 2-way match, the outgoing goods report, and the validation message, a 3-way match is used to check whether the condition of the actually delivered goods and the conditions according to the 2-way match match the information in the validation message.This ensures that the information in the validation message is correct. If the validation message passes, it is registered in the shared data set.

[0317] Figure 7 shows another schematic block diagram of an exemplary system for computer-implemented control of a goods delivery from a goods sender to a goods recipient, including an electronic payment transaction. The system may include a DLT system 182, for example, the DLT system according to embodiments of Figures 3 or 4. The payment transactions can be coupled with data streams from the control of the goods delivery and maintained in a closed data loop.

[0318] To prepare electronic payments, participants, for example, user A, can transfer fiat money, for example euros, to a pool account of a bank in step 360, which handles the payment transactions. This takes place within a banking system or using a bank computer system 186. In step 362, the bank or a DLT node assigned to the bank in the DLT system 182 records the receipt of fiat money, for example via an API of the bank or another suitable programming or communication interface of the bank in the DLT system 182. An API (Application Programming Interface) is a programming interface or a program component that is made available by a software system to other programs for connection to the corresponding system. In step 364, the bank automatically allocates e-money, i.e., electronic money, to a DLT account of user A.The amount of e-money received into User A's DLT account corresponds to the amount of fiat money transferred. Any participant, e.g., User B, can execute a corresponding procedure to deposit e-money into an associated DLT account in DLT system 182. The DLT accounts can be located on the participants' respective DLT nodes in DLT system 182.

[0319] User A, as the goods recipient, can place an order with a goods sender, e.g., user B, using an ERP system, for example. The order is transmitted, for example, as a delivery order to a DLT node of user A in step 366. The delivery order can contain ERP data from the goods recipient's ERP system. For this purpose, user A can, for example, use a computer system of the goods recipient, which can be connected to the associated DLT node in the DLT system 182 via an API or any other programming or communication interface. The DLT node of user A initializes the delivery of goods, as explained above, e.g., with regard to the embodiment according to Figure 1A. This transmits an order specification to a DLT node of the goods sender, which can transmit the order specification to a computer system of the goods sender in step 368.User B can, for example, confirm the order using an ERP system on the sender's computer system. The order specification and confirmation can, for example, contain ERP data from the sender's ERP system. The sender's computer system can be connected to the associated DLT node in the DLT system 182 via an API or any other programming or communication interface.

[0320] The ordering process is handled by the DLT system 182 between the DLT nodes of the sender and the recipient using one or more smart contracts, which is illustrated by way of example in step 370. For example, one of the exemplary methods described in the preceding figures for controlling a delivery of goods from a sender to a recipient using the access-restricted DLT system 182 is used for this purpose. Any necessary handshake can be performed (semi-)automatically between the participating DLT nodes. If further data is required or parameters need to be confirmed, the participating DLT nodes can communicate with the associated computer systems of the sender or recipient to receive inputs, e.g., via the respective ERP systems, which are then transferred to the DLT system 182.Accordingly, the ordering process and the delivery of goods can be carried out via the DLT system 182. Delivery of goods and, if applicable, sending of an invoice, which must be carried out outside the DLT system 182 due to requirements, can be performed in step 372.

[0321] Upon registration of a validation message for the delivery of goods, for example, by issuing an invoice, in the DLT system 182, an electronic payment transaction can be triggered from the DLT account of user A to a DLT account of user B. Analogous to the issuance of e-money to DLT accounts in the DLT system, a participant, for example, user B, can instruct, in step 374, at least a portion of the e-money received in the course of one or more electronic payment transactions to be paid out. This can be done via the DLT node assigned to the bank, which can communicate with the bank's computer system. In step 376, the bank converts the issued e-money into fiat money and transfers the corresponding fiat money via the pool account to an account of user B. Any participant, for example, user A, can execute a corresponding procedure to pay out e-money as fiat money to an associated bank account.It should be understood that the delivery of goods does not necessarily result in the disbursement of e-money as fiat money. Rather, the e-money can remain in DLT accounts to conduct further electronic payment transactions.

[0322] The DLT system 182 can also be configured to record and review all DLT payment transactions in the DLT system 182, for example, for AML (Anti-Money Laundering) reasons, i.e., to prevent money laundering. For example, the bank's anti-money laundering software is used to review the recorded DLT transactions. For example, customer data is analyzed to identify suspicious transactions. To this end, the customer data is filtered, classified according to the level of trust, and examined for anomalies. Once the anti-money laundering software has collected sufficient data and suspicious transactions have been flagged, a report is generated, for example. Furthermore, payments can be authorized or blocked.

[0323] For example, regulatory-compliant processing of all payment transactions is also ensured by the DLT system 182: For example, using the at least one smart contract, a regulator 378 is implemented, which records all transactions for compliance purposes. Furthermore, using the at least one smart contract, a notary node 380, also known as a notary node, is implemented, which prevents the multiple use or multiple issuance of the same units of e-money.

[0324] Figures 8A and 8B as well as Figure 9 show exemplary graphical user interfaces (GUIs) for executing the method for computer-implemented control of a delivery of goods from a sender to a recipient using a restricted-access DLT system. Figure 8A shows a first part of a first exemplary graphical user interface. Figure 8A includes an exemplary representation of the data of a first partial data set 148 of a split data set, which represents a delivery order from a recipient of goods (“buyer”). Furthermore, Figure 8B shows a second part of the first exemplary graphical user interface. Figure 8B includes an exemplary representation of the data of a second partial data set 168 of the split data set, which represents a proposal for changed delivery conditions from the sender of goods (“sealer”).

[0325] The graphical user interface shown in Figures 8A and 8B includes a menu for selecting various areas. These include a "dashboard," i.e., a graphical user interface for visualizing data, an area with "orders," a "wallet," i.e., a digital wallet, a "reports" area, and a "settings" area. Furthermore, a current user is specified ("Logged In As"). A selection element for creating a new order ("Create new order") is also shown. Furthermore, search parameters can be entered ("Search and filter"). Figures 8A and 8B show an example of an area with "orders." In a submenu, the following areas can be selected: “Open”, “Confirmed”, “Paid” and “Rejected”.These areas list open, confirmed, paid, or rejected orders. The graphical user interface includes a "Buyer" area for a recipient of goods and a "Seller" area for a sender of goods.

[0326] The representation of the first partial data record 148 of the goods recipient in Figure 8A shows what the goods recipient sees, i.e. “Buyer - Their View”, and indicates, for example: a time of a last update “Last update”, a status “UPDATED”, a “Transaction ID”, an “Order number”, a “Delivery date”, a “Product ID buyer”, a “Product name buyer”, a “Product ID seller”, a “Product name seller”, a “Line Item ID”, a “Settlement (In days)” indication, an “Invoice number”, an “Invoice date”, a “Tax ID” (“Tax ID”), a “Tax” (“Tax”), a “Description” (“Description”), a “Reason for the update” (“Update reason”),a "Quantity," a "Units" specification, a "Price per Unit," a "Unit of Price per Unit," a "Total Price," and a "Currency." Furthermore, an "Accept All" selection element is provided for the sender of goods to accept all information or specifications according to the first partial data set 148 of the recipient of goods.

[0327] The representation of the second partial data set 168 of the goods sender in Figure 8B shows what the goods sender sees, i.e., “Seller - My View” (“Seiler - My View”), if the user is logged in as a goods sender, and indicates, for example: a time of a last update (“Last update”), a status “UPDATED”, a “Transaction ID”, an “Order number”, a “Delivery date”, a “Product ID buyer”, a “Product name buyer”, a “Product ID seller”, a “Product name seller”, a “Line Item ID”, a “Settlement (In days)” indication, an “Invoice number”, an “Invoice date” (“Invoice date”), a “Tax ID”, a “Tax” information (“Tax”), a “Description”,an “Update reason,” a “Quantity,” an indication of “Units,” a “Price per unit,” a “Unit of price per Unit,” a “Total price,” and a “Currency.” This information can be changed by the sender of the goods, with the exception of the “Last update,” the status “UPDATED,” the “Transaction ID,” the “Order number,” the “Product ID buyer,” and the “Product name buyer.” Furthermore, a selection element "Cancel", "Send" and "Confirm" is provided for canceling, sending or confirming the information or the updates to the information.

[0328] Figure 9 shows an example dashboard of a DLT node of a goods sender with an overview of current orders and payments. The graphical user interface shown in Figure 9 includes a menu for selecting various areas. These include a "dashboard", i.e. a graphical user interface for visualizing data, an area with "orders", a "wallet", i.e. a digital wallet, a "reports" area, and a "settings" area. Furthermore, there is information about who is currently logged in ("Logged In As"). Figure 9 shows an example of the "dashboard". The dashboard includes information on "Cash available now", "Cash available tomorrow", and "Cash available the day after tomorrow".The dashboard also includes an “Overview,” a list of “Most recent orders,” “Most recent updates,” and “Paid on time.” The “Overview” includes a graphical representation, e.g., in the form of a histogram, of various details for today. This information includes a “Wallet balance,” details of incoming payments (“Incoming”), outgoing payments (“Outgoing”), and rejected payments or delivery orders (“Rejected”). The “Most recent orders” list lists current orders and indicates, for example, how many current orders are still outstanding.The “Most recent updates” list shows current updates and indicates, for example, when an update was last made (“Last updated”). This was, for example, “4 minutes ago”. Finally, the “Paid on time” list shows what percentage of incoming goods (“Incoming”) and what percentage of outgoing goods (“Outgoing”) have been paid on time. Finally, the dashboard includes information on the number of “Transactions” (“Transactions”), which are pending (“Pending”), which are to be done (“To dos”), which are paid (“Paid”), and which are rejected (“Rejected”).

[0329] The invention has been described above with reference to specific embodiments by way of example. The present invention may be further described, without limitation and purely by way of example, by the following embodiments. The following embodiments may include preferred embodiments. Accordingly, the term "combination of features" as used therein may refer to such a "preferred embodiment."

[0330] 1. A method for computer-implemented control of a delivery of goods from a sender of goods to a recipient of goods using a restricted-access DLT system comprising a first DLT node assigned to the recipient of goods and a second DLT node assigned to the sender of goods, wherein the DLT system provides at least one smart contract, wherein the at least one smart contract comprises program instructions for entering and checking delivery orders and order confirmations, wherein the method comprises initializing the delivery of goods in the DLT system, wherein the initialization comprises:

[0331] • Receiving a delivery order from the goods recipient via a first network by the first DLT node for goods to be delivered by the goods sender to the goods recipient, wherein the delivery order specifies one or more physical properties of the goods to be delivered as a first specification, wherein the physical properties of the first specification comprise at least a quantity of goods to be delivered,

[0332] • Creating a first data set managed by the first DLT node and entering at least one or more physical properties of the delivery order into the first data set by the first DLT node using the at least one smart contract, wherein the first data set is a first part of a data set shared between the first DLT node and the second DLT node,

[0333] • Transmitting at least the first data set from the first DLT node to the second DLT node,

[0334] • Creating a second data set managed by the second DLT node, wherein the second data set is a second part of the split data set, and first updating the second data set by the second DLT node based on the first data set, wherein the first updating comprises entering at least one or more of the physical properties of the first specification into the second data set, wherein the at least one or more entered physical properties of the first specification comprise the quantity of goods to be delivered,

[0335] • Receiving an order confirmation from the sender of goods via the first network by the second DLT node, wherein the order confirmation includes a second specification of the one or more physical properties of the goods to be delivered,

[0336] • Checking the second specification for compliance with the first specification using the at least one smart contract, • Second update of the second data set by the second DLT node using a first test result of checking the second specification,

[0337] • Transmitting at least one first update message from the second DLT node to the first DLT node,

[0338] • first update of the first data record by the first DLT node using the first update message.

[0339] 2. Method according to feature combination 1, wherein the at least one smart contract comprises program instructions for entering and checking outgoing goods logs in the course of deliveries of goods from the sender of goods to the recipient of goods, wherein the method further comprises logging the delivery of goods in the DLT system, wherein the logging comprises:

[0340] • Receiving an outgoing goods protocol from the goods sender via the first network by the second DLT node, wherein the outgoing goods protocol comprises one or more first sensor values ​​for the one or more physical properties of the outgoing goods according to the second specification, which are detected by means of one or more first physical sensors assigned to the goods sender, wherein the one or more first sensor values ​​comprise at least one first sensor value which quantifies the quantity of goods delivered,

[0341] • Checking the one or more first sensor values ​​of the goods issue protocol for compliance with the one or more physical properties of the goods to be delivered according to the shared data set within predefined first tolerances using the at least one smart contract, wherein the checked first sensor values ​​comprise at least the first sensor value quantifying the quantity of goods delivered,

[0342] • third updating of the second data set by the second DLT node using a second test result of checking the one or more first sensor values ​​of the goods issue protocol,

[0343] • Transmitting at least a second update message from the second DLT node to the first DLT node,

[0344] • second update of the first data record by the first DLT node using the second update message, 3. Method according to one of the feature combinations 1 or 2, wherein the at least one smart contract comprises program instructions for validating the deliveries of goods, wherein the method further comprises validating the delivery of goods in the DLT system, wherein the validation comprises:

[0345] • Checking parameters of a validation message for validating the delivery of goods by the second DLT node using the at least one smart contract, wherein the parameters comprise at least one quantity of goods to be validated, wherein checking the parameters comprises checking the quantity of goods to be validated for compliance with the first sensor value quantifying the quantity of goods delivered within a predefined second tolerance,

[0346] • if the quantity of goods to be validated matches the first sensor value quantifying the quantity of goods delivered within the predefined second tolerance, fourth update of the second data set by the second DLT node, wherein the fourth update comprises registering the validation message by the second DLT node in the second data set using the at least one smart contract,

[0347] • Transmitting at least a third update message from the second DLT node to the first DLT node,

[0348] • third updating of the first data set by the first DLT node using the third update message, wherein the third updating of the first data set comprises registering the validation message in the first data set.

[0349] 4. Method according to one of the preceding combinations of features, further comprising signing the data transmitted from the first DLT node to the second DLT node by the first DLT node, wherein the at least one smart contract on the second DLT node is configured to verify the signatures of the transmitted data.

[0350] 5. The method according to any one of the preceding feature combinations, further comprising signing the data transmitted from the second DLT node to the first DLT node by the second DLT node, wherein the at least one smart contract on the first DLT node is configured to verify the signatures of the transmitted data. 6. The method according to any one of the preceding feature combinations, wherein the data transmission between the first DLT node and the second DLT node takes place via one or more communication connections cryptographically protected by end-to-end encryption.

[0351] 7. Method according to feature combination 6, wherein establishing the one or more cryptographically protected communication connections comprises mutual authentication of the first DLT node and the second DLT node.

[0352] 8. Method according to one of the preceding combinations of features, wherein the checking of the second specification for conformity with the first specification during initialization is a check for identity.

[0353] 9. The method according to feature combination 8, wherein the initializing further comprises: if the one or more physical properties according to the second specification entered in the second data set differ from the one or more physical properties according to the first specification from the first data set, performing a handshake between the first DLT node and the second DLT node to compare the first specification of the first data set and the second specification of the second data set such that the first and second specifications resulting from the comparison match.

[0354] 10. Method according to one of the feature combinations 1 to 7, wherein the checking of the second specification for conformity with the first specification during the initialization is a check for conformity within predefined third tolerances according to the at least one smart contract.

[0355] 11. The method according to feature combination 10, wherein the initializing further comprises: if one or more deviations between the one or more physical properties according to the second specification entered in the second data set and the one or more physical properties according to the first specification from the first data set are greater than the predefined third tolerances, performing a handshake between the first DLT node and the second DLT node to compare the first specification of the first data set and the second specification of the second data set such that the first and second specifications resulting from the comparison agree within the predefined third tolerances.

[0356] 12. Method according to one of the preceding combinations of features, wherein the program instructions comprised by the at least one smart contract are further configured to enter and check goods receipt logs in the course of goods deliveries from the goods sender to the goods recipient, wherein the logging of the goods delivery in the DLT system further comprises:

[0357] • Receiving a goods receipt protocol from the goods recipient via the first network by the first DLT node, wherein the goods receipt protocol comprises one or more second sensor values ​​for the one or more physical properties of the incoming goods according to the first specification, which are detected by means of one or more second physical sensors assigned to the goods recipient, wherein the one or more second sensor values ​​comprise at least one second sensor value which quantifies the quantity of goods delivered,

[0358] • Checking the one or more second sensor values ​​of the incoming goods protocol for compliance with the one or more physical properties of the goods to be delivered according to the shared data set as well as with the one or more first sensor values ​​according to the outgoing goods protocol within predefined fourth tolerances using the at least one smart contract, wherein the checked second sensor values ​​comprise at least the second sensor value quantifying the quantity of goods delivered,

[0359] • fourth updating of the first data set by the first DLT node using a third test result of checking the one or more second sensor values ​​of the goods receipt protocol,

[0360] • Transmitting at least a fourth update message from the first DLT node to the second DLT node,

[0361] • fifth update of the second data record by the second DLT node using the fourth update message.

[0362] 13. Method according to one of the preceding combinations of features, wherein the validation message comprises an invoice and the program instructions comprised by the at least one smart contract are further configured to create the invoice, wherein the invoice is created by the second DLT node using the at least one smart contract, wherein the parameters of the validation message are checked during the invoice creation process.

[0363] 14. Method according to one of the combinations of features 1 to 12, wherein an invoice is received by a first ERP system of the sender of the goods which creates the invoice.

[0364] 15. Method according to one of the preceding combinations of features, wherein the data entered in the split data set provided in the DLT system during the logging of the delivery of goods are mirror-identical data of the delivery of goods from the first ERP system of the sender of the goods and / or a second ERP system of the recipient of the goods, wherein the first and / or second ERP system are configured to control the processing of the delivery of goods, wherein data consistency between the split data set and the ERP systems is ensured by entering the mirror-identical data.

[0365] 16. Method according to one of the combinations of features 1 to 14, wherein the processing of the delivery of goods is controlled by the at least one smart contract, the program instructions of which are further configured to control the processing of the delivery of goods.

[0366] 17. Method according to one of the preceding combinations of features, wherein the first network is a public network.

[0367] 18. Method according to one of the preceding combinations of features, wherein a prerequisite for receiving the delivery order from the goods recipient by the first DLT node is successful authentication of the goods recipient by the first DLT node, and / or wherein a prerequisite for receiving the order confirmation from the goods sender by the second DLT node is successful authentication of the goods sender by the second DLT node, and / or wherein a prerequisite for receiving the goods issue protocol from the goods sender by the second DLT node is successful authentication of the goods sender by the second DLT node, and / or wherein a prerequisite for receiving the goods receipt protocol from the goods recipient by the first DLT node is successful authentication of the goods recipient by the first DLT node.

[0368] 19. Method according to one of the preceding combinations of features, wherein a prerequisite for the use of the delivery order of the goods recipient by the first DLT node is a successful signature verification of a signature of the delivery order by the first DLT node, and / or wherein a prerequisite for the use of the order confirmation of the goods sender by the second DLT node is a successful signature verification of a signature of the order confirmation by the second DLT node, and / or wherein a prerequisite for the use of the goods issue log of the goods sender by the second DLT node is a successful signature verification of a signature of the goods issue log by the second DLT node, and / or wherein a prerequisite for the use of the goods receipt log of the goods recipient by the first DLT node is a successful signature verification of a signature of the goods receipt log by the first DLT node.

[0369] 20. Method according to one of the preceding combinations of features, wherein the first DLT node and the second DLT node are provided by one or more DLT servers of the DLT system.

[0370] 21. Method according to feature combination 20, wherein the one or more DLT servers of the DLT system are arranged in one or more data centers secured against unauthorized access.

[0371] 22. Method according to one of the preceding combinations of features, wherein the data transmission between the DLT nodes takes place via a second network.

[0372] 23. The method according to feature combination 22, wherein the second network is a private or a public network. 24. The method according to any one of the preceding feature combinations, wherein the program instructions comprised by the at least one smart contract are further configured to trigger an electronic payment transaction, wherein the payment transaction is triggered by the smart contract upon registration of the validation message in the DLT system.

[0373] 25. Method according to feature combination 24, wherein the triggered electronic payment transaction is an IBAN transfer from an IBAN account of the recipient of the goods to an IBAN account of the sender of the goods.

[0374] 26. The method according to feature combination 24, wherein the triggered electronic payment transaction is a transaction of an amount of programmable money executed using the DLT system.

[0375] 27. The method according to feature combination 26, wherein the DLT system is configured to transfer the invoice amount to be paid from a programmable money account of the goods recipient to a programmable money account of the goods sender, wherein the DLT system is further configured, for example, to transform a fiat money amount of a fiat money account assigned to the goods recipient into an amount of programmable money in the programmable money account of the goods recipient.

[0376] 28. Method according to one of the combinations of features 26 or 27, wherein the payment transaction is logged in the DLT system using the at least one smart contract, wherein electronic account statements about the logged payment transaction are further issued for the recipient of the goods and / or the sender of the goods using the smart contract.

[0377] 29. A shared data set of a restricted-access DLT system for computer-implemented control of a delivery of goods from a sender of goods to a recipient of goods using the DLT system, wherein the shared data set comprises a first part, the first part being a first data set managed by a first DLT node associated with the recipient of goods, the shared data set further comprising a second part, the second part being a second data set managed by a second DLT node associated with the sender of goods.

[0378] 30. Use of a split data set according to feature combination 29 to initialize the delivery of goods in the DLT system.

[0379] 31 . Use of the split data set according to feature combination 29 to log the delivery of goods in the DLT system.

[0380] 32. Use of the split data set according to feature combination 29 to validate the delivery of goods in the DLT system.

[0381] 33. A DLT node of a restricted-access DLT system for computer-implemented control of a delivery of goods from a sender of goods to a recipient of goods, wherein the DLT node is implemented on a DLT server of the DLT system and is assigned to the recipient of goods, wherein the DLT server comprises a processor and a memory with program instructions, wherein at least one smart contract is provided by the program instructions on the DLT node, wherein the program instructions providing the at least one smart contract comprise program instructions for entering and checking delivery orders and order confirmations, wherein execution of the program instructions by the processor causes the processor to control the DLT node such that the DLT node executes the following in the course of initializing the delivery of goods in the DLT system:

[0382] • Receiving a delivery order from the goods recipient for goods to be delivered by the goods sender to the goods recipient by the DLT node via a first network, wherein the delivery order specifies one or more physical properties of the goods to be delivered as a first specification, wherein the physical properties of the first specification comprise at least a quantity of goods to be delivered,

[0383] • Creating a first data set managed by the DLT node and entries of at least one or more physical properties of the delivery order by the DLT node into the first data set using the at least one smart contract, wherein the first data set is a first part of a data set shared between the DLT node and another DLT node of the DLT system assigned to the sender of the goods,

[0384] • Transmitting at least the first data set from the DLT node to the other DLT node,

[0385] • Receiving at least one first update message from the further DLT node about an update of the second data set using a first test result of a test of a second specification of the one or more physical properties of the goods to be delivered according to an order confirmation for compliance with the first specification,

[0386] • first update of the first record by the DLT node using the first update message.

[0387] 34. DLT node according to feature combination 33, wherein the program instructions providing the at least one smart contract comprise program instructions for entering and checking outgoing goods logs in the course of goods deliveries from the sender of goods to the recipient of goods, wherein the execution of the program instructions by the processor causes the processor to further control the DLT node such that the DLT node executes the following in the course of logging the delivery of goods in the DLT system:

[0388] • Receiving at least one second update message from the further DLT node about an update of the second data set using a second test result of a test of one or more first sensor values ​​of a goods issue protocol for compliance with the one or more physical properties of the goods to be delivered according to the shared data set within predefined first tolerances, wherein the one or more first sensor values ​​of the goods issue protocol are recorded by means of one or more first physical sensors assigned to the goods sender, wherein the tested first sensor values ​​comprise at least the first sensor value quantifying the quantity of goods delivered,

[0389] • second update of the first record by the DLT node using the second update message.

[0390] 35. DLT node according to one of the feature combinations 33 or 34, wherein the program instructions providing the at least one smart contract comprise program instructions for validating the deliveries of goods, wherein the execution of the program instructions by the processor causes the processor to further control the DLT node such that the DLT node executes the following in the course of validating the delivery of goods in the DLT system:

[0391] • Receiving at least one third update message from the further DLT node about an update of the second data set using a validation message, wherein the update of the second data set using the validation message comprises a registration of the validation message in the second data set, wherein the update of the second data set using the validation message confirms a successful check of parameters of the validation message by the further DLT node, wherein the parameters comprise at least one quantity of goods to be validated, wherein the checking of the parameters comprises checking the quantity of goods to be validated for compliance with the first sensor value quantifying the quantity of goods delivered within a predefined second tolerance,

[0392] • third updating of the first data set by the DLT node using the third update message, wherein the third updating of the first data set comprises registering the validation message in the first data set.

[0393] 36. DLT node according to one of the feature combinations 33 to 35, wherein the execution of the program instructions by the processor further causes the processor to control the DLT node such that the DLT node executes the method steps of the first DLT node of the method according to one of the feature combinations 4 to 28.

[0394] 37. A DLT node of a restricted-access DLT system for computer-implemented control of a delivery of goods from a sender of goods to a recipient of goods, wherein the DLT node is implemented on a DLT server of the DLT system and is assigned to the sender of goods, wherein the DLT server comprises a processor and a memory with program instructions, wherein at least one smart contract is provided by the program instructions on the DLT node, wherein the program instructions providing the at least one smart contract comprise program instructions for entering and checking delivery orders and order confirmations, wherein execution of the program instructions by the processor causes the processor to control the DLT node such that the DLT node executes the following in the course of initializing the delivery of goods in the DLT system:

[0395] • Receiving at least one first data set created by another DLT node of the goods recipient from the other DLT node, wherein the first data set is a first part of a data set shared between the DLT node and the other DLT node, wherein the first data set comprises at least one or more physical properties of the goods to be delivered according to a first specification of a delivery order, wherein the physical properties of the first specification comprise at least a quantity of goods to be delivered,

[0396] • Creating a second data set managed by the DLT node, wherein the second data set is a second part of the split data set, and first updating the second data set by the DLT node based on the first data set, wherein the first updating comprises entering at least one or more of the physical properties of the first specification into the second data set, wherein the at least one or more entered physical properties of the first specification comprise the quantity of goods to be delivered,

[0397] • Receiving an order confirmation from the sender of goods via a first network by the DLT node, wherein the order confirmation includes a second specification of the one or more physical properties of the goods to be delivered,

[0398] • Checking the second specification for compliance with the first specification using the at least one smart contract,

[0399] • second update of the second data set by the second DLT node using a first check result of checking the second specification,

[0400] • Transmitting at least one first update message from the DLT node to the further DLT node to update the first data record.

[0401] 38. DLT node according to feature combination 37, wherein the program instructions providing the at least one smart contract comprise program instructions for entering and checking outgoing goods logs in the course of goods deliveries from the sender of goods to the recipient of goods, wherein the execution of the program instructions by the processor causes the processor to further control the DLT node such that the DLT node executes the following in the course of logging the delivery of goods in the DLT system:

[0402] • Receiving an outgoing goods protocol from the goods sender via the first network by the DLT node, wherein the outgoing goods protocol comprises one or more first sensor values ​​for the one or more physical properties of the outgoing goods according to the second specification, which are detected by means of one or more first physical sensors assigned to the goods sender, wherein the one or more first sensor values ​​comprise at least one first sensor value which quantifies the quantity of goods delivered,

[0403] • Checking the one or more first sensor values ​​of the goods issue protocol for compliance with the one or more physical properties of the goods to be delivered according to the shared data set within predefined first tolerances using the at least one smart contract, wherein the checked first sensor values ​​comprise at least the first sensor value quantifying the quantity of goods delivered,

[0404] • third updating of the second data set by the DLT node using a second test result of checking the one or more first sensor values ​​of the goods issue protocol,

[0405] • Transmitting at least a second update message from the DLT node to the further DLT node to update the first data record.

[0406] 39. DLT node according to one of the feature combinations 37 or 38, wherein the program instructions providing the at least one smart contract comprise program instructions for validating the deliveries of goods, wherein the execution of the program instructions by the processor causes the processor to further control the DLT node such that the DLT node, in the course of validating the delivery of goods in the DLT system, executes the following:

[0407] • Checking parameters of a validation message for validating the delivery of goods by the DLT node using the at least one smart contract, wherein the parameters comprise at least one quantity of goods to be validated, wherein checking the parameters comprises checking the quantity of goods to be validated for compliance with the first sensor value quantifying the quantity of goods delivered within a predefined second tolerance,

[0408] • if the quantity of goods to be validated matches the first sensor value quantifying the quantity of goods delivered within the predefined second tolerance, fourth update of the second data set by the DLT node, wherein the fourth update comprises registering the validation message by the DLT node in the second data set using the at least one smart contract,

[0409] • Transmitting at least a third update message from the DLT node to the further DLT node to update the first data record.

[0410] 40. DLT node according to one of the feature combinations 37 to 39, wherein the execution of the program instructions by the processor further causes the processor to control the DLT node such that the DLT node executes the method steps of the second DLT node of the method according to one of the feature combinations 4 to 28.

[0411] 41. DLT system for computer-implemented control of a delivery of goods from a sender to a recipient, comprising a first DLT node assigned to the recipient and a second DLT node assigned to the sender, wherein the first DLT node and the second DLT node are provided by one or more DLT servers of the DLT system, wherein the DLT system provides at least one smart contract, wherein the at least one smart contract comprises program instructions for entering and checking delivery orders and order confirmations, wherein the DLT system is configured to execute an initialization of the delivery of goods in the DLT system, wherein the initialization comprises:

[0412] • Receiving a delivery order from the goods recipient via a first network by the first DLT node for goods to be delivered by the goods sender to the goods recipient, wherein the delivery order specifies one or more physical properties of the goods to be delivered as a first specification, wherein the physical properties of the first specification comprise at least a quantity of goods to be delivered,

[0413] • Creating a first data set managed by the first DLT node and entering at least one or more physical properties of the delivery order into the first data set by the first DLT node using the at least one smart contract, wherein the first data set is a first part of a data set shared between the first DLT node and the second DLT node,

[0414] • Transmitting at least the first data set from the first DLT node to the second DLT node,

[0415] • Creating a second data set managed by the second DLT node, wherein the second data set is a second part of the split data set, and first updating the second data set by the second DLT node based on the first data set, wherein the first updating comprises entering at least one or more of the physical properties of the first specification into the second data set, wherein the at least one or more entered physical properties of the first specification comprise the quantity of goods to be delivered,

[0416] • Receiving an order confirmation from the sender of goods via the first network by the second DLT node, wherein the order confirmation includes a second specification of the one or more physical properties of the goods to be delivered,

[0417] • Checking the second specification for compliance with the first specification using the at least one smart contract,

[0418] • second update of the second data set by the second DLT node using a first check result of checking the second specification,

[0419] • Transmitting at least one first update message from the second DLT node to the first DLT node,

[0420] • first update of the first data record by the first DLT node using the first update message.

[0421] 42. DLT system according to feature combination 41, wherein the at least one smart contract comprises program instructions for entering and checking goods issue logs in the course of goods deliveries from the goods sender to the goods recipient, wherein the DLT system is further configured to carry out logging of the goods delivery in the DLT system, wherein the logging comprises:

[0422] • Receiving an outgoing goods protocol from the goods sender via the first network by the second DLT node, wherein the outgoing goods protocol comprises one or more first sensor values ​​for the one or more physical properties of the outgoing goods according to the second specification, which are detected by means of one or more first physical sensors assigned to the goods sender, wherein the one or more first sensor values ​​comprise at least one first sensor value which quantifies the quantity of goods delivered,

[0423] • Checking the one or more first sensor values ​​of the goods issue protocol for compliance with the one or more physical properties of the goods to be delivered according to the shared data set within predefined first tolerances using the at least one smart contract, wherein the checked first sensor values ​​comprise at least the first sensor value quantifying the quantity of goods delivered,

[0424] • third updating of the second data set by the second DLT node using a second test result of checking the one or more first sensor values ​​of the goods issue protocol,

[0425] • Transmitting at least a second update message from the second DLT node to the first DLT node,

[0426] • second update of the first data record by the first DLT node using the second update message.

[0427] 43. DLT system according to one of the feature combinations 41 or 42, wherein the at least one smart contract comprises program instructions for validating the deliveries of goods, wherein the DLT system is further configured to carry out a validation of the delivery of goods in the DLT system, wherein the validation comprises:

[0428] • Checking parameters of a validation message for validating the delivery of goods by the second DLT node using the at least one smart contract, wherein the parameters comprise at least one quantity of goods to be validated, wherein checking the parameters comprises checking the quantity of goods to be validated for compliance with the first sensor value quantifying the quantity of goods delivered within a predefined second tolerance,

[0429] • if the quantity of goods to be validated matches the first sensor value quantifying the quantity of goods delivered within the predefined second tolerance, fourth update of the second data set by the second DLT node, wherein the fourth update comprises registering the validation message by the second DLT node in the second data set using the at least one smart contract, • transmitting at least one third update message from the second DLT node to the first DLT node,

[0430] • third updating of the first data set by the first DLT node using the third update message, wherein the third updating of the first data set comprises registering the validation message in the first data set.

[0431] 44. DLT system according to one of the feature combinations 41 to 43, wherein the DLT system is further configured to carry out the method according to one of the feature combinations 4 to 28.

[0432] 45. A computer program for controlling a delivery of goods from a sender of goods to a recipient of goods using a restricted-access DLT system, which comprises a first DLT node assigned to the recipient of goods and a second DLT node assigned to the sender of goods, wherein the computer program provides at least one smart contract, wherein the at least one smart contract comprises program instructions for entering and checking delivery orders and order confirmations, wherein the computer program comprises program instructions for initializing the delivery of goods in the DLT system, wherein the initialization comprises:

[0433] • Receiving a delivery order from the goods recipient via a first network by the first DLT node for goods to be delivered by the goods sender to the goods recipient, wherein the delivery order specifies one or more physical properties of the goods to be delivered as a first specification, wherein the physical properties of the first specification comprise at least a quantity of goods to be delivered,

[0434] • Creating a first data set managed by the first DLT node and entering at least one or more physical properties of the delivery order into the first data set by the first DLT node using the at least one smart contract, wherein the first data set is a first part of a data set shared between the first DLT node and the second DLT node, • Transmitting at least the first data set from the first DLT node to the second DLT node,

[0435] • Creating a second data set managed by the second DLT node, wherein the second data set is a second part of the split data set, and first updating the second data set by the second DLT node based on the first data set, wherein the first updating comprises entering at least one or more of the physical properties of the first specification into the second data set, wherein the at least one or more entered physical properties of the first specification comprise the quantity of goods to be delivered,

[0436] • Receiving an order confirmation from the sender of goods via the first network by the second DLT node, wherein the order confirmation includes a second specification of the one or more physical properties of the goods to be delivered,

[0437] • Checking the second specification for compliance with the first specification using the at least one smart contract,

[0438] • second update of the second data set by the second DLT node using a first check result of checking the second specification,

[0439] • Transmitting at least one first update message from the second DLT node to the first DLT node,

[0440] • first update of the first data record by the first DLT node using the first update message.

[0441] 46. ​​Computer program according to feature combination 45, wherein the at least one smart contract comprises program instructions for entering and checking outgoing goods logs in the course of goods deliveries from the sender of goods to the recipient of goods, wherein the computer program further comprises program instructions for logging the delivery of goods in the DLT system, wherein the logging comprises:

[0442] • Receiving an outgoing goods protocol from the goods sender via the first network by the second DLT node, wherein the outgoing goods protocol comprises one or more first sensor values ​​for the one or more physical properties of the outgoing goods according to the second specification, which are detected by means of one or more first physical sensors assigned to the goods sender, wherein the one or more first sensor values ​​comprise at least one first sensor value which quantifies the quantity of goods delivered,

[0443] • Checking the one or more first sensor values ​​of the goods issue protocol for compliance with the one or more physical properties of the goods to be delivered according to the shared data set within predefined first tolerances using the at least one smart contract, wherein the checked first sensor values ​​comprise at least the first sensor value quantifying the quantity of goods delivered,

[0444] • third updating of the second data set by the second DLT node using a second test result of checking the one or more first sensor values ​​of the goods issue protocol,

[0445] • Transmitting at least a second update message from the second DLT node to the first DLT node,

[0446] • second update of the first data record by the first DLT node using the second update message.

[0447] 47. Computer program according to one of the feature combinations 45 or 46, wherein the at least one smart contract comprises program instructions for validating the deliveries of goods, wherein the computer program further comprises program instructions for validating the delivery of goods in the DLT system, wherein the validation comprises:

[0448] • Checking parameters of a validation message for validating the delivery of goods by the second DLT node using the at least one smart contract, wherein the parameters comprise at least one quantity of goods to be validated, wherein checking the parameters comprises checking the quantity of goods to be validated for compliance with the first sensor value quantifying the quantity of goods delivered within a predefined second tolerance,

[0449] • if the quantity of goods to be validated matches the first sensor value quantifying the quantity of goods delivered within the predefined second tolerance, fourth update of the second data set by the second DLT node, wherein the fourth update comprises registering the validation message by the second DLT node in the second data set using the at least one smart contract, • transmitting at least one third update message from the second DLT node to the first DLT node,

[0450] • third updating of the first data set by the first DLT node using the third update message, wherein the third updating of the first data set comprises registering the validation message in the first data set.

[0451] 48. Computer program according to one of the feature combinations 45 to 47, wherein the computer program further comprises program instructions for carrying out the method according to one of the feature combinations 4 to 28.

[0452] List of reference symbols

[0453] 100 goods sender computer system

[0454] 102 memory

[0455] 104 public keys

[0456] 106 protected memory area

[0457] 108 private keys

[0458] 110 processor

[0459] 112 Program instruction

[0460] 114 Sensor

[0461] 116 Communication interface

[0462] 120 Goods recipient computer system

[0463] 122 memory

[0464] 124 public keys

[0465] 126 protected memory area

[0466] 128 private keys

[0467] 130 processor

[0468] 132 program instruction

[0469] 134 Sensor

[0470] 136 Communication interface

[0471] 140 DLT servers

[0472] 142 processor

[0473] 144 program instructions

[0474] 146 memory

[0475] 148 first record of the split dataset

[0476] 150 public keys

[0477] 152 protected memory area

[0478] 154 private keys

[0479] 156 Communication interface

[0480] 160 DLT servers

[0481] 162 processor

[0482] 164 program instructions

[0483] 166 Memory 168 second record of the split record

[0484] 170 public keys

[0485] 172 protected memory area

[0486] 174 private key 176 communication interface

[0487] 180 D LT network

[0488] 182 DLT system

[0489] 184 Network

[0490] 186 Banking computer system 190 Delivery order

[0491] 191 Order confirmation

[0492] 192 updated delivery order

[0493] 193 updated order confirmation

[0494] 194 Validation message

Claims

Patent claims 1. A method for computer-implemented control of a delivery of goods from a sender of goods to a recipient of goods using a restricted-access DLT system (182) comprising a first DLT node assigned to the recipient of goods and a second DLT node assigned to the sender of goods, wherein the DLT system (182) provides at least one smart contract, wherein the at least one smart contract comprises program instructions for entering and checking delivery orders (190) and order confirmations (191), wherein the method comprises initializing the delivery of goods in the DLT system (182), wherein the initialization comprises: • Receiving a delivery order (190) from the goods recipient via a first network (184) by the first DLT node for goods to be delivered by the goods sender to the goods recipient, wherein the delivery order (190) specifies one or more physical properties of the goods to be delivered as a first specification, wherein the physical properties of the first specification comprise at least a quantity of goods to be delivered, • Creating a first data set (148) managed by the first DLT node and entering at least one or more physical properties of the delivery order (190) into the first data set (148) by the first DLT node using the at least one smart contract, wherein the first data set (148) is a first part of a data set shared between the first DLT node and the second DLT node, • Transmitting at least the first data set (148) from the first DLT node to the second DLT node, • Creating a second data set (168) managed by the second DLT node, wherein the second data set (168) is a second part of the split data set, and first updating the second data set (168) by the second DLT node based on the first data set (148), wherein the first updating comprises entering at least one or more of the physical properties of the first specification into the second data set (168), wherein the at least one or more entered physical properties of the first specification comprise the quantity of goods to be delivered, Ill • Receiving an order confirmation (191) from the goods sender via the first network (184) by the second DLT node, wherein the order confirmation (191) comprises a second specification of the one or more physical properties of the goods to be delivered, • Checking the second specification for compliance with the first specification using the at least one smart contract, • second updating of the second data set (168) by the second DLT node using a first test result of checking the second specification, • Transmitting at least one first update message from the second DLT node to the first DLT node, • first updating of the first data record (148) by the first DLT node using the first update message.

2. The method according to claim 1, wherein the DLT system (182) is based on a direct data exchange between the DLT nodes of the parties involved and on a direct data validation by the corresponding DLT nodes.

3. Method in particular according to claim 1 or 2, wherein the at least one smart contract comprises program instructions for entering and checking goods issue protocols in the course of goods deliveries from the goods sender to the goods recipient, wherein the method comprises logging the goods delivery in the DLT system (182), wherein the logging comprises: • Receiving an outgoing goods protocol from the goods sender via the first network (184) by the second DLT node, wherein the outgoing goods protocol comprises one or more first sensor values ​​for the one or more physical properties of the outgoing goods according to the second specification, which are detected by means of one or more first physical sensors (114) assigned to the goods sender, wherein the one or more first sensor values ​​comprise at least one first sensor value which quantifies the quantity of goods delivered, • Checking the one or more first sensor values ​​of the goods issue protocol for compliance with the one or more physical properties of the goods to be delivered according to the shared data set within predefined first tolerances using the at least one smart contract, wherein the checked first sensor values ​​comprise at least the first sensor value quantifying the quantity of goods delivered, • third updating of the second data set (168) by the second DLT node using a second test result of checking the one or more first sensor values ​​of the goods issue protocol, • Transmitting at least a second update message from the second DLT node to the first DLT node, • second updating of the first data record (148) by the first DLT node using the second update message, 4. Method in particular according to one of claims 1 to 3, wherein the method comprises validating the delivery of goods in the DLT system (182), wherein the at least one smart contract comprises program instructions for validating the delivery of goods, wherein the validation comprises: • Checking parameters of a validation message (194) for validating the delivery of goods by the second DLT node using the at least one smart contract, wherein the parameters comprise at least one quantity of goods to be validated, wherein checking the parameters comprises checking the quantity of goods to be validated for compliance with the first sensor value quantifying the quantity of goods delivered within a predefined second tolerance, • if the quantity of goods to be validated matches the first sensor value quantifying the quantity of goods delivered within the predefined second tolerance, fourth update of the second data set (168) by the second DLT node, wherein the fourth update comprises registering the validation message (194) by the second DLT node in the second data set (168) using the at least one smart contract, • Transmitting at least a third update message from the second DLT node to the first DLT node, • third updating of the first data set (148) by the first DLT node using the third update message, wherein the third updating of the first data set (148) comprises registering the validation message (194) in the first data set (148).

5. The method according to any one of the preceding claims, further comprising signing the data transmitted from the first DLT node to the second DLT node by the first DLT node, wherein the at least one smart contract on the second DLT node is configured to verify the signatures of the transmitted data, and / or further comprising signing the data transmitted from the second DLT node to the first DLT node by the second DLT node, wherein the at least one smart contract on the first DLT node is configured to verify the signatures of the transmitted data, and / or wherein the data transmission between the first DLT node and the second DLT node takes place via one or more communication connections cryptographically protected by end-to-end encryption,wherein establishing the one or more cryptographically protected communication connections comprises, for example, mutual authentication of the first DLT node and the second DLT node.

6. The method according to any one of the preceding claims, wherein checking the second specification for compliance with the first specification during initialization is a check for identity, wherein the initialization further comprises, for example: if the one or more physical properties according to the second specification entered in the second data set (168) differ from the one or more physical properties according to the first specification from the first data set (148), performing a handshake between the first DLT node and the second DLT node to compare the first specification of the first data set (148) and the second specification of the second data set (168) so that the first and second specifications resulting from the comparison match,or wherein checking the second specification for compliance with the first specification during initialization is checking for compliance within predefined third tolerances according to the at least one smart contract, wherein the initialization further comprises, for example: if one or more deviations between the one or more physical properties according to the second specification entered in the second data set (168) and the one or more physical properties according to the first specification from the first data set (148) are greater than the predefined third tolerances, performing a handshake between the first DLT node and the second DLT node to compare the first specification of the first data set (148) and the second specification of the second data set (168) such that the first and second specifications resulting from the comparison agree within the predefined third tolerances.

7. The method according to any one of the preceding claims, wherein the program instructions comprised by the at least one smart contract are further configured to enter and check goods receipt logs in the course of goods deliveries from the goods sender to the goods recipient, wherein the logging of the goods delivery in the DLT system (182) further comprises: • Receiving a goods receipt protocol from the goods recipient via the first network (184) by the first DLT node, wherein the goods receipt protocol comprises one or more second sensor values ​​for the one or more physical properties of the incoming goods according to the first specification, which are detected by means of one or more second physical sensors (134) assigned to the goods recipient, wherein the one or more second sensor values ​​comprise at least one second sensor value which quantifies the quantity of goods delivered, • Checking the one or more second sensor values ​​of the incoming goods protocol for compliance with the one or more physical properties of the goods to be delivered according to the shared data set as well as with the one or more first sensor values ​​according to the outgoing goods protocol within predefined fourth tolerances using the at least one smart contract, wherein the checked second sensor values ​​comprise at least the second sensor value quantifying the quantity of goods delivered, • fourth updating of the first data set (148) by the first DLT node using a third test result of checking the one or more second sensor values ​​of the goods receipt protocol, • Transmitting at least a fourth update message from the first DLT node to the second DLT node, • fifth updating of the second data set (168) by the second DLT node using the fourth update message.

8. The method according to any one of the preceding claims, wherein the validation message (194) comprises an invoice and the program instructions comprised by the at least one smart contract are further configured to create the invoice, wherein the invoice is created by the second DLT node using the at least one smart contract, wherein the parameters of the validation message (194) are checked during the invoice creation, or wherein an invoice is received from a first ERP system of the goods sender creating the invoice.

9. The method according to one of the preceding claims, wherein the data entered in the split data set provided in the DLT system (182) during the logging of the delivery of goods are mirror-image data of the delivery of goods from the first ERP system of the sender of the goods and / or a second ERP system of the recipient of the goods, wherein the first and / or second ERP system are configured to control the processing of the delivery of goods, wherein data consistency between the split data set and the ERP systems is ensured by entering the mirror-image data, or wherein the processing of the delivery of goods is controlled by the at least one smart contract, the program instructions of which are further configured to control the processing of the delivery of goods.

10. The method according to any one of the preceding claims, wherein the first network (184) is a public network, and / or wherein a prerequisite for receiving the delivery order (190) of the goods recipient by the first DLT node is a successful authentication of the goods recipient by the first DLT node, and / or wherein a prerequisite for receiving the order confirmation (191) from the goods sender by the second DLT node is a successful authentication of the goods sender by the second DLT node, and / or wherein a prerequisite for receiving the goods issue protocol from the goods sender by the second DLT node is a successful authentication of the goods sender by the second DLT node, and / or wherein a prerequisite for receiving the goods receipt protocol from the goods recipient by the first DLT node is a successful authentication of the goods recipient by the first DLT node, and / or wherein a prerequisite for using the delivery order (190) from the goods recipient by the first DLT node is a successful signature verification of a signature of the delivery order (190) by the first DLT node,and / or wherein a prerequisite for the use of the order confirmation (191) of the goods sender by the second DLT node is a successful signature verification of a signature of the order confirmation (191) by the second DLT node, and / or wherein a prerequisite for the use of the goods issue protocol of the goods sender by the second DLT node is a successful signature verification of a signature of the goods issue protocol by the second DLT node, and / or wherein a prerequisite for the use of the goods receipt protocol of the goods recipient by the first DLT node is a successful signature verification of a signature of the goods receipt protocol by the first DLT node, and / or wherein the first DLT node and the second DLT node are provided by one or more DLT servers (140, 160) of the DLT system (182), wherein the one or more DLT servers (140,160) of the DLT system (182) are arranged, for example, in one or more data centers secured against unauthorized access, and / or wherein the data transmission between the DLT nodes takes place via a second network (180). The second network (180) is, for example, a private or a public network.

11. The method according to any one of the preceding claims, wherein the program instructions comprised by the at least one smart contract are further configured to trigger an electronic payment transaction, wherein the triggering of the payment transaction by the smart contract occurs upon registration of the validation message (194) in the DLT system (182), wherein the triggered electronic payment transaction is, for example, an IBAN transfer from an IBAN account of the goods recipient to an IBAN account of the goods sender, or wherein the triggered electronic payment transaction is, for example, a transaction of an amount of programmable money executed using the DLT system (182), wherein the DLT system (182) is, for example, configured toto transfer the invoice amount to be paid from a programmable money account of the goods recipient to a programmable money account of the goods sender, wherein the DLT system (182) is further configured, for example, to transform a fiat money amount of a fiat money account assigned to the goods recipient into an amount of programmable money in the goods recipient's programmable money account, and / or wherein the payment transaction is logged, for example, using the at least one smart contract in the DLT system (182), wherein, for example, electronic account statements about the logged payment transaction are issued for the goods recipient and / or the goods sender using the smart contract.

12. Use of a shared data set of a restricted-access DLT system (182) in the course of a computer-implemented control of a delivery of goods from a sender of goods to a recipient of goods for initializing the delivery of goods in the DLT system (182) and / or for logging the delivery of goods in the DLT system (182) and / or for validating the delivery of goods in the DLT system (182), wherein the shared data set comprises a first part, wherein the first part is a first data set (148) managed by a first DLT node assigned to the recipient of goods, wherein the split data set further comprises a second part, wherein the second part is a second data set (168) managed by a second DLT node associated with the sender of goods 13. DLT node of an access-restricted DLT system (182) for the computer-implemented control of a delivery of goods from a sender of goods to a recipient of goods, wherein the DLT node is implemented on a DLT server (140) of the DLT system (182) and is assigned to the recipient of goods, wherein the DLT server (140) comprises a processor (142) and a memory with program instructions (144), wherein at least one smart contract is provided by the program instructions (144) on the DLT node, wherein the program instructions (144) providing the at least one smart contract comprise program instructions for entering and checking delivery orders (190), order confirmations (191) and / or goods issue protocols in the course of deliveries of goods from the sender of goods to the recipient of goods and / or for validating the deliveries of goods, wherein an execution of the Program instructions by the processor cause the processor to control the DLT node in such a way thatthat the DLT node carries out the method steps of the first DLT node of the method according to one of claims 1 to 11., 14. A DLT node of a restricted-access DLT system (182) for the computer-implemented control of a delivery of goods from a sender of goods to a recipient of goods, wherein the DLT node is implemented on a DLT server (160) of the DLT system (182) and is assigned to the sender of goods, wherein the DLT server (160) comprises a processor (162) and a memory (166) with program instructions (164), wherein at least one smart contract is provided by the program instructions (164) on the DLT node, wherein the program instructions (164) providing the at least one smart contract comprise program instructions for entering and checking delivery orders (190), order confirmations (191) and / or goods issue protocols in the course of deliveries of goods from the sender of goods to the recipient of goods and / or for validating the deliveries of goods, wherein execution of the program instructions by the processor causes the processor to control the DLT node such that the DLT node executes the method steps of the second DLT node of the method according to one of claims 1 to 11.

15. A DLT system (182) for the computer-implemented control of a delivery of goods from a sender of goods to a recipient of goods, comprising a first DLT node assigned to the recipient of goods and a second DLT node assigned to the sender of goods, wherein the first DLT node and the second DLT node are provided by one or more DLT servers (140, 160) of the DLT system (182), wherein the DLT system (182) provides at least one smart contract, wherein the at least one smart contract comprises program instructions for entering and checking delivery orders (190), order confirmations (191) and / or goods issue protocols in the course of deliveries of goods from the sender of goods to the recipient of goods and / or for validating the deliveries of goods, wherein the DLT system (182) is configured to carry out the method according to one of claims 1 to 11.

16. A computer program for controlling a delivery of goods from a sender of goods to a recipient of goods using a restricted-access DLT system (182) comprising a first DLT node assigned to the recipient of goods and a second DLT node assigned to the sender of goods, wherein the computer program provides at least one smart contract, wherein the at least one smart contract comprises program instructions for entering and checking delivery orders (190), order confirmations (191) and / or outgoing goods protocols in the course of deliveries of goods from the sender of goods to the recipient of goods and / or for validating the deliveries of goods, wherein the computer program comprises program instructions for carrying out the method according to one of claims 1 to 11.