Monitoring cargo delivery using distributed ledger system

Abstract

The invention relates to a method for computer-implemented monitoring of the delivery of goods from a goods sender to a goods receiver using a limited access DLT system (182). The DLT system (182) includes a first DLT node assigned to a cargo recipient and a second DLT node assigned to a cargo sender. Furthermore, the DLT system (182) provides at least one smart contract with program instructions for inputting and checking delivery orders (190), order confirmation (191) and shipping records during delivery of the cargo from the cargo sender to the cargo recipient and program instructions for verifying the delivery of the cargo. The method includes initializing a cargo delivery, for example in a DLT system (182), recording a cargo delivery, for example in a DLT system (182), and / or verifying a cargo delivery, for example in a DLT system (182).

Description

Technical Field

[0001] The present invention relates to a method for computer-implemented monitoring of a delivery of goods from a sender of goods to a receiver of goods using a limited-access DLT system. The present invention also relates to the use of a shared data set of a DLT system in the process of computer-implemented monitoring of a delivery of goods, a DLT node of the limited-access DLT system implemented on a DLT server of the DLT system and assigned to a receiver of the delivery of goods, a DLT node of the limited-access DLT system implemented on a DLT server of the DLT system and assigned to a sender of the delivery of goods, a limited-access DLT system for computer-implemented monitoring of a delivery of goods, and a computer program for monitoring a delivery of goods using a limited-access DLT system. Background Art

[0002] A method for adapting a production process is known from WO 2021 / 18366 A1, wherein a first node of a first party of a blockchain network is designed to publish an ordering transaction in the blockchain network, wherein the published ordering transaction is verified by the blockchain network, wherein the method comprises analyzing the verified finalized transaction in the blockchain network by at least one node of a second party of the blockchain network, the analysis comprising:

[0003] Identify a verified order transaction, extract order parameters, send the order parameters to a simulation system to simulate a production process for the ordered product based on the order parameters, receive capacity parameters from the simulation system, generate a quotation based on the capacity parameters, and if a node of the first supplier accepts the quotation, adapt the production process based on the quotation.

[0004] This or other means of tracking goods use blockchain. However, a disadvantage of blockchain is that once data has been entered into the blockchain, it can no longer be adapted. Furthermore, the data entered into the blockchain are visible at least to all blockchain servers that manage the corresponding blockchain. In the case of a public blockchain, the data entered into the blockchain are even public, i.e. accessible to everyone. Summary of the invention

[0005] The object of the present invention is to create an improved method which is suitable for monitoring the delivery of goods and which ensures the security and confidentiality of the data used in the monitoring process.

[0006] The object of the present invention is achieved by the features of the following technical solutions. The implementation methods of the present invention are given in the following technical solutions.

[0007] Embodiments include a method for computer-implemented monitoring of a delivery of goods from a goods sender to a goods recipient using a limited-access DLT system. The DLT system includes a first DLT node assigned to the goods recipient and a second DLT node assigned to the goods sender. The DLT system also provides at least one smart contract. The at least one smart contract includes program instructions for entering and checking delivery orders and order confirmations.

[0008] The method includes initiating the delivery of goods in the DLT system. The initialization includes:

[0009] receiving, by the first DLT node via the first network, a delivery order from a goods recipient for goods to be delivered from a goods sender to the goods recipient, wherein the delivery order identifies one or more physical characteristics of the goods to be delivered as a first specification, wherein the physical characteristics of the first specification include at least one quantity of the goods to be delivered,

[0010] creating a first dataset managed by a first DLT node and entering at least one or more physical characteristics of the delivery order into the first dataset by the first DLT node using at least one smart contract, wherein the first dataset is a first part of a shared dataset between the first DLT node and a second DLT node,

[0011] transmitting at least the first data set from the first DLT node to the second DLT node,

[0012] creating a second data set managed by a second DLT node, wherein the second data set is a second portion of the shared data set, and updating the second data set for a first time based on the first data set by the second DLT node, wherein the first updating includes inputting at least one or more of the physical characteristics of the first specification into the second data set, wherein the at least one or more input physical characteristics of the first specification include the quantity of goods to be delivered,

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

[0014] checking whether the second specification complies with the first specification using at least one smart contract,

[0015] updating the second data set a second time by the second DLT node using the result of the first check of the second specification,

[0016] transmitting at least one first update message from the second DLT node to the first DLT node,

[0017] • Updating the first data set for the first time by the first DLT node using a first update message.

[0018] Embodiments include a method, the method further comprising recording a delivery of goods in a DLT system. At least one smart contract includes program instructions for entering and checking a shipment record during the delivery of goods from a goods sender to a goods receiver. The record includes:

[0019] receiving, by the second DLT node, a shipment record from a sender of the goods via the first network, wherein the shipment record comprises one or more first sensor values ​​of one or more physical properties of the shipped goods according to the second specification, the first sensor values ​​being detected by means of one or more first physical sensors assigned to the sender of the goods, wherein the one or more first sensor values ​​comprise at least one first sensor value quantifying a quantity of the delivered goods,

[0020] checking, using at least one smart contract, whether one or more first sensor values ​​of the shipment record correspond within a predetermined first tolerance to one or more physical properties of the goods to be delivered according to the shared data set, wherein the checked first sensor values ​​include at least a first sensor value quantifying the amount of the goods delivered,

[0021] updating the second data set for a third time by the second DLT node using the second check result of the one or more first sensor values ​​of the check shipment record,

[0022] transmitting at least one second update message from the second DLT node to the first DLT node,

[0023] Updating the first data set a second time by the first DLT node using a second update message.

[0024] Embodiments include a method further comprising verifying delivery of goods in a DLT system. At least one smart contract includes program instructions for verifying delivery of goods. Verification includes:

[0025] checking, by a second DLT node, parameters of a verification message for verifying the delivery of goods using at least one smart contract, wherein the parameters include at least one quantity of goods to be verified, wherein the checking of the parameters includes checking whether the quantity of goods to be verified corresponds within a predetermined second tolerance to a first sensor value quantifying the delivered quantity of goods,

[0026] updating the second data set for a fourth time by the second DLT node when the quantity of goods to be verified corresponds to the first sensor value quantifying the delivered quantity of goods within a predetermined second tolerance, wherein the fourth updating comprises registering a verification message in the second data set by the second DLT node using at least one smart contract,

[0027] transmitting at least one third update message from the second DLT node to the first DLT node,

[0028] Updating the first data set for a third time by the first DLT node using a third update message, wherein the third updating of the first data set comprises registering the verification message in the first data set.

[0029] In the process of initializing the delivery of goods, a shared data set is generated on two DLT nodes of the DLT system with limited access. The shared data set is a data set that includes a first sub-data set on the first DLT node and a second sub-data set on the second DLT node. Only the first DLT node (or another DLT node authorized for this) and thus the goods recipient have the authorization to edit the first sub-data set, i.e., the write authorization, and for the second data set, only the second DLT node (or another DLT node authorized for this) and thus the goods sender have the authorization to edit, i.e., the write authorization. In addition, due to the access restrictions of the DLT system, for example, only the goods recipient has the read authorization to read the first sub-data set via the first DLT node (or another DLT node authorized for this), and only the goods sender has the read authorization to read the second sub-data set via the second DLT node (or another DLT node authorized for this).

[0030] The term distributed ledger technology describes a technology for recording transactions or the status of transactions. Unlike conventional means in which the ledger as a general ledger is usually managed by only one entity, here any number of identical copies of the ledger are maintained in a decentralized manner by different parties. The party with at least one corresponding node in the DLT system can be, for example, a sender of goods, a receiver of goods, a producer of goods, or a supplier of goods, wherein the parties can also overlap, such as a producer of goods and a supplier of goods as a single party. In addition, the 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. As a party or user in the DLT system, a regulator with at least one node can also be set to implement specific functions, such as compliance with regulatory provisions, such as preventing money laundering or prescribed 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 the double use of DLT-based monetary assets (Geleinheiten).

[0031] Appropriate measures are taken to ensure that new transactions or transaction status to be added are incorporated into all copies of the ledger and that agreement (consensus or agreement) is reached on the corresponding current state of the ledger.

[0032] For example, at least one smart contract implemented on the two DLT nodes is configured to ensure data consistency between the two sub-datasets of the shared data set. For example, mirrored, i.e., identical data can be achieved in the two sub-datasets of the shared data set by means of synchronized data maintenance.

[0033] The present method does not use blockchain, but is based on, for example, direct data exchange between the DLT nodes of the participating parties and direct data verification by the corresponding DLT nodes. The advantage of using a DLT system with limited access over a public blockchain is that access to data managed by the DLT system is limited. For example, a user of a DLT system has only the right to call a DLT node assigned to it accordingly. For example, data from a shared data set within a DLT system is transmitted only between DLT nodes that share the shared data set. For example, data is transmitted only between a first DLT node of a goods recipient and a second DLT node of a goods sender. For example, unicast is used for delivery, i.e., the transmitted data is addressed to a single recipient, i.e., a single DLT node, respectively. Unlike transmission by broadcast, such as in the case of many blockchain solutions, transmission by unicast has the advantage that only the sender and the receiver can obtain the content of the transmitted data.

[0034] When transactions to be entered are transmitted within a blockchain network by means of broadcasting, there is a lack of confidentiality because transactions in the blockchain are usually visible to all verified nodes. Blockchains usually store data as transactions in separate blocks linked to each other and manage them redundantly in a distributed peer-to-peer network. Due to redundant management, a large number of nodes can have call rights to all data stored in the blockchain. In contrast, embodiments of the present invention have the advantage that data security and confidentiality of data stored in a shared data set can be ensured. This is achieved in the following way, that is, the communication with the transactions to be mapped, that is, the data to be stored in the shared data set, occurs only between the DLT nodes involved in the DLT system, that is, between those DLT nodes that share the corresponding data set. For example, these nodes are only the first DLT node of the goods recipient and the second DLT node of the goods sender. The delivery of goods is monitored by means of one or more smart contracts implemented on the participating nodes. It is not stored in the blockchain or in the remaining data sets visible to all DLT nodes.

[0035] For this purpose, a data set shared by the participating DLT nodes is used, which has a first (sub) data set managed by the DLT node of the goods recipient and a second (sub) data set managed by the DLT node of the goods sender. The two (sub) data sets should correspond to each other and reflect the perspective of the corresponding responsible nodes. Only the responsible DLT node is authorized to change the corresponding part of the data set. The sub-data sets and the transactions stored in the corresponding sub-data sets are transmitted to another DLT node respectively. For example, only the changes of the corresponding sub-data sets are transmitted to another DLT node. For example, the data transmitted to other DLT nodes is signed. Another DLT node can verify whether the change is correct or authenticated by the signed DLT node and therefore by the assigned user based on the signature.

[0036] Furthermore, the first sub-dataset and the second sub-dataset do not have to be identical. For example, a sub-dataset may include one or more different data values ​​relative to other sub-datasets, for example different data values ​​in terms of the delivery of goods, for example in terms of the amount of the corresponding goods to be delivered or other factors. For example, a tolerance can be predetermined, within which differences are acceptable. Alternatively or additionally, a semi-automatic or fully-automatic handshake can be performed between the two DLT nodes managing the two sub-datasets until an agreement is reached on the individual data values ​​of the data sets that differ from each other, for example on the goods to be delivered and their characteristics, i.e. the differences have been eliminated.

[0037] Thus, embodiments may have the advantage of providing means for confidentiality of transactions between two DLT nodes based on the data sets distributed on the two DLT nodes and / or the other features described above for aligning the (sub)data sets. Furthermore, transactions may be secured and data security between the DLT nodes may be improved.

[0038] The communication between the DLT nodes is performed, for example, via a transport connection secured by the Transport Layer Security Protocol (TLS). In addition, such as when the goods recipient calls the first DLT node using a computer system assigned to the goods recipient and / or when the goods sender calls the second DLT node using a computer system assigned to the goods sender, the communication with the DLT node is performed via a transport connection secured by TLS.

[0039] For example, all transmission connections are secured with TLS. The security principles within the DLT system are based on, for example, peer-to-peer communication between DLT nodes and the need-to-know principle. Peer-to-peer communication is based on computer-to-computer connections between computers with the same authorization. The need-to-know principle or the necessity principle as a security goal for data requires that not only the basic call authorization is necessary for calling the corresponding data, but also that the data to be called is directly necessary for completing a specific task. Even if a DLT node can, for example, call data of a certain or limited security level, the need-to-know principle prohibits the call if the corresponding data is not directly needed to complete the specific task of the DLT node.

[0040] Each DLT node only obtains data that also concerns that DLT node. Therefore, even a compromised DLT node cannot leak information because it does not participate in managing the shared data set of other DLT nodes, and the data is not publicly accessible or published within the DLT system.

[0041] The embodiment may have the advantage that it is possible to omit the addition of keys to the data in the sub-datasets of the shared data set. The data may be input and stored in the sub-datasets in plain text. The need-to-know principle ensures that the relevant data is only exchanged between the participating DLT nodes. This provides effective protection for sensitive information to prevent unauthorized calls. Therefore, effective data security and confidentiality have been ensured by the network architecture used by the DLT system. Here, no data is sent to other DLT nodes because these data do not directly involve them or their corresponding users (need-to-know principle). This is different from the means of conventional blockchains. In order to make sensitive data also securely stored in the blockchain, these data must be input and saved in a key-added manner. Alternatively, only the result of applying a one-way function, such as a hash function, is input into the corresponding data and saved. Due to the broadcast between all nodes of the system, the blockchain is usually also visible to all nodes of the system, so the sensitive information in the blockchain must be protected by additional measures. These additional measures, such as adding keys or applying one-way functions, can only achieve basic protection of data and information stored in the blockchain.

[0042] If the data are keyed in a sub-dataset of a shared data set, this allows the security level of the corresponding data to be increased additionally based on the already existing basic protection that is already provided by the network architecture and is not only used to implement basic protection such as in the case of a conventional blockchain. For example, the data in the sub-dataset of a shared data set are entered in a keyed manner and / or the sub-dataset is stored in a keyed manner.

[0043] According to an embodiment, no broadcasting is performed within the DLT system, such as in the case of using a blockchain. Rather, the communication between DLT nodes, for example, is based on unicast or direct communication between the participating DLT nodes, for example via a dedicated communication connection.

[0044] Embodiments can be realized, for example, in the form of a first data set and a second data set to ensure the same data about the goods transfer at both parties, i.e. at the goods recipient and the goods sender. For example, the same data can also be integrated into a linked enterprise resource planning (ERP) system at both parties.

[0045] The mirrored data and synchronized data maintenance thus provided are advantageous for the digital integration of ordering, delivery and financial processes between business partners, such as goods recipients and goods senders. For example, constant data quality can be ensured, and constant data quality can be measured mutually, such as by using performance indicators, such as key performance indicators (KPIs). The implementation of validation in the process ensures the sustainability of the data quality that has been achieved, and thus prevents gradual deterioration. By providing a public location for a database in the form of a shared data set with the aid of a DLT system for monitoring goods delivery, for example, reconciliation work is reduced. Therefore, for example, the work of later account reconciliations by both parties of business partners can be significantly reduced or even permanently and comprehensively cancelled. Therefore, it can help to improve data quality and processing efficiency. Therefore, for example, the scope of manual work can be reduced.

[0046] First, for example, due to receiving a delivery order including a first specification of goods to be delivered, one or more physical characteristics of the goods to be delivered according to the first specification are input into a first data set managed by a first DLT node, i.e., a first sub-data set of a shared data set. The input one or more physical characteristics according to the first specification include at least one quantity of goods to be delivered.

[0047] The first data set or the one or more physical characteristics according to the first specification entered into the first data set is transmitted to a second DLT node of the sender of the goods. The second DLT node creates a second sub-data set of the shared data set, into which the one or more physical characteristics according to the first specification are entered. Here, the one or more physical characteristics according to the first specification entered include at least one quantity of goods to be delivered. As a result, the two sub-data sets of the shared data set thus include, for example, the same data.

[0048] Upon receiving an order confirmation including a second specification of one or more physical characteristics of the goods to be delivered, checking whether the second specification is consistent with the first specification via a second DLT node using at least one smart contract, and updating the second data set using the result of checking the second specification.

[0049] When the second specification matches the first specification, updating the second data set using the inspection result includes, for example, inputting a confirmation of the first specification. For example, updating the second data set using the inspection result includes inputting the second specification supplementing the first specification into the second data set.

[0050] When the second specification is different from the first specification, updating the second data set using the inspection result includes, for example, replacing or updating the physical characteristics according to the first specification by different physical characteristics according to the second specification. For example, in the process of updating the second data set, different physical characteristics according to the second specification in addition to the first specification are input into the second data set. For example, the second specification that supplements the first specification is input into the second data set.

[0051] In addition, 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 complies with the first specification. If one or more physical characteristics according to the second specification are different from the first specification, the first update message, for example, identifies the different one or more physical characteristics 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 difference in one or more physical properties according to the second specification from the first specification may occur, for example, for the following reasons: only a certain minimum quantity of goods is deliverable within the scope of, for example, a tanker or tank truck, or only a certain quantity unit of goods is delivered. Such a difference in one or more physical properties according to the second specification from the first specification may occur, for example, for the following reasons: the characteristics of the delivered product differ from the characteristics of the ordered product.

[0053] The first DLT node updates the first dataset, i.e., the first subset of the shared dataset, using the first update message. When the second specification is consistent with the first specification, updating the first dataset using the first update message includes, for example, inputting a confirmation of the first specification. For example, updating the first dataset using the first update message includes inputting the second specification that supplements the first specification into the first dataset.

[0054] When the second specification is different from the first specification, updating the first data set using the first update message includes, for example, replacing or updating the physical characteristics according to the first specification by different physical characteristics according to the second specification. For example, in the process of updating the first data set, different physical characteristics according to the second specification in addition to the first specification are input into the second data set. For example, the second specification that supplements the first specification is input into the second data set.

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

[0056] A handshake, also known in German as "Handschlag", refers to an automated negotiation process between two users, in this case two DLT nodes, through the exchange of data, in this case the exchange of instructions about the physical characteristics of the goods to be delivered. In the present case, a handshake can be used to establish the terms of the delivery of goods before the physical delivery of the goods begins. In the case of using at least one smart contract, a handshake protocol is implemented, for example between two DLT nodes, with the result that one or both specifications are adapted until the same correspondence, i.e. agreement, is achieved between the two specifications.

[0057] If the second specification is consistent with the first specification, a confirmation message is transmitted from the second DLT node to the goods sender, for example via the network. The compliance between the second specification and the first specification is achieved, for example, when the two specifications are consistent, i.e., identically consistent. If no differences occur beyond a predetermined tolerance range, the second specification is achieved, for example. The confirmation message shows, for example, the goods sender that an agreement has been reached between the goods recipient and the goods sender regarding the corresponding goods delivery. In addition, the confirmation message includes, for example, the specifications of the delivery of the corresponding goods. For example, the corresponding confirmation message is used as a trigger to initiate the corresponding goods delivery.

[0058] In addition, the delivery of goods is recorded in the DLT system. If a physical delivery of goods is implemented, that is, if the goods to be delivered leave the warehouse of the goods sender, a shipping record is created. The corresponding shipping record includes one or more sensor values ​​for one or more physical properties of the shipped goods according to the second specification, and the sensor values ​​are detected by means of one or more physical sensors assigned to the goods sender. Therefore, the shipping record indicates the measured values ​​detected by sensor technology for one or more physical properties, respectively, for which target values ​​are indicated in the second specification, and these measured values ​​reflect the actual conditions of the shipped goods in terms of the corresponding physical properties. The corresponding sensor value here includes at least one sensor value that quantifies the amount of delivered, i.e. shipped goods.

[0059] The second DLT node of the goods sender receives the shipping record from the goods sender via the first network, and checks whether one or more first sensor values ​​of the shipping record are consistent with one or more physical characteristics of the goods to be delivered. Here, check whether one or more sensor values ​​of the shipping record are consistent with one or more physical characteristics according to the shared data set within a predetermined tolerance. If such consistency is not achieved, a warning prompt is transmitted to the goods sender and / or the goods recipient, for example. Such a warning prompt can, for example, trigger a subsequent delivery from the goods sender when the delivery volume is too small. Such a warning prompt can, for example, mean that if, for example, the product features do not meet the specifications, the delivery process will be stopped. In this case, for example, the goods recipient must agree to different specifications and make the delivery, or cancel the order. As an alternative to cancellation, for example, the delivery date can be changed to a date on which goods that meet the specifications are available.

[0060] On the part of the consignee, the presence of such a warning prompt can, for example, trigger a check of different physical characteristics when the consignment arrives. For example, such a warning prompt may require confirmation of different physical characteristics from the consignee in order to successfully and finally confirm the consignment delivery.

[0061] The second data set is updated by the second DLT node using the result of checking one or more first sensor values ​​of the shipping record. For example, the update includes inputting the shipping record and / or one or more of the sensor values ​​indicated by the shipping record. For example, all sensor values ​​indicated by the shipping record are input. For example, only such sensor values ​​that are different from the values ​​of the physical characteristics of the goods to be delivered entered in the second data set are input. For example, for the sensor values ​​of the shipping record that match the values ​​of the physical characteristics of the goods to be delivered entered in the second data set, only a confirmation that the corresponding value for the physical characteristic matches the detected sensor value is entered in the second data set.

[0062] In addition, a second update message is transmitted from the second DLT node to the first DLT node. The second update message, for example, includes one or more of the shipping record and / or the sensor values ​​indicated by the shipping record. For example, the second update message includes all sensor values ​​indicated by the shipping record. For example, the second update message only includes such sensor values ​​that are different from the values ​​of the physical characteristics of the goods to be delivered entered in the second data set. For example, for the sensor values ​​of the shipping record that match the values ​​of the physical characteristics of the goods to be delivered entered in the second data set, the second update message only includes a confirmation that the corresponding values ​​of the physical characteristics according to the shared data set match the detected sensor values.

[0063] The first DLT node updates the first data set, i.e., the first sub-data set of the shared data set, using the second update message. For example, the update includes inputting one or more of the shipping record and / or the sensor values ​​indicated by the shipping record. For example, all sensor values ​​indicated by the shipping record are input. For example, only such sensor values ​​that are different from the values ​​of the physical characteristics of the goods to be delivered entered in the first data set are input. For example, for the sensor values ​​of the shipping record that match the values ​​of the physical characteristics of the goods to be delivered entered in the first data set, only a confirmation that the corresponding value for the physical characteristic matches the detected sensor value is entered in the first data set.

[0064] Finally, verification of the delivery of goods is implemented in the DLT system. To this end, the parameters of the verification message for verifying the delivery of goods are checked by the second DLT node. The checked parameters of the verification message include at least one indication of the amount of goods delivered to be verified. Checking the corresponding parameters includes checking whether the amount of goods to be verified is consistent with the sensor value of the quantitative amount of goods delivered according to the shipment record within a predetermined tolerance. When the amount of goods to be verified is consistent with the sensor value of the quantitative amount of goods delivered within a predetermined tolerance, the second data set is updated by the second DLT node using the verification message. The update includes registering the verification message in the second data set by the second DLT node. For example, during the registration process, an identifier of the verification message is entered into the second data set. For example, a check value of the verification message, such as a hash value, is entered into the second data set. For example, one or more parameters of the verification message are entered into the second data set. For example, the verification message is entered into the second data set.

[0065] A hash value is the result of applying a hash function, also called a variance function, to an input, also called a key. A hash function is a mapping that maps a large input quantity, i.e., a key, to a smaller target quantity, i.e., a hash value. Therefore, a hash function is usually not one-to-one. For example, the input quantity can contain elements of different lengths, while the elements of the target quantity usually have a fixed length.

[0066] For example, verification is triggered by receiving a verification message or by generating a verification message. For example, generation of a verification message is triggered by receiving a receipt confirmation of delivered goods from a goods recipient. For example, a receipt confirmation is received in the form of an incoming goods record.

[0067] Furthermore, a third update message is transmitted from the second DLT node to the first DLT node. The third update message comprises, for example, data of the verification message that was input into the second data set during the update process. The third update message comprises, for example, the complete updated second data set. The third update message comprises, for example, the verification message.

[0068] The first DLT node updates the first data set using the third update message. Here, updating the first data set includes registering the verification message in the first data set. For example, an identifier of the verification message is entered into the first data set during the registration process. For example, a check value of the verification message, such as a hash value, is entered into the first data set. For example, one or more parameters of the verification message are entered into the first data set. For example, the verification message is entered into the first data set.

[0069] The processing related to each user, i.e. the sender of goods and the receiver of goods, occurs on the DLT node of the DLT system, which is correspondingly assigned to the corresponding user. The DLT system includes, for example, a plurality of DLT servers. Here, two or more DLT nodes of two or more users can be arranged on the same DLT server of the DLT system, for example. For example, the DLT nodes of different users are arranged on different DLT servers of the DLT system.

[0070] For example, a single smart contract is used to implement a method for computer-implemented monitoring of a delivery of goods. For example, multiple smart contracts are used. For example, each smart contract of the multiple smart contracts is respectively configured to implement a determined portion of the method, such as initialization, recording, and / or verification.

[0071] A smart contract defines a set of terms recorded in a DLT system, and when at least some of these predetermined terms are met, the set of conditions triggers automatic, self-executing actions. A smart contract includes program instructions that map agreed-upon rules or corresponding terms. Such a smart contract that defines rules for multiple users cannot be changed unilaterally. More specifically, changes require, for example, a consensus of multiple users. The premise of such consensus can be, for example, the consent of a majority of the multiple users and / or all of the multiple users. For example, changes to the smart contract are recorded. For example, a complete history of changes to the smart contract is provided.

[0072] The network via which the DLT node is called is, for example, a TCP / IP network. For example, the DLT node may be hosted on one or more servers. The DLT system may establish a protected connection between the DLT server and the DLT node hosted therein. For example, the DLT node may also be implemented locally on a computer system assigned to a user.

[0073] The one or more first physical sensors of the goods sender include one or more physical measuring devices for detecting measurement data or sensor values. Measurement data are data that quantitatively or qualitatively describe the physical and / or chemical properties of the measurement object. The corresponding characteristics include, for example, weight, volume, temperature, humidity, pressure, particle size, sound field size, brightness, pH value, ionic strength, electrochemical potential, conductivity, viscosity and / or light transmittance. The measurement data is detected by means of physical or chemical effects and converted into an electrical signal that can be further processed electronically. For example, a key is added to the corresponding electrical signal in an encrypted manner, and the electrical signal includes the detected measurement data. For example, a symmetric, asymmetric or mixed encryption method can be applied to add a key for this purpose. Therefore, for example, the corresponding measurement data can be protected from unauthorized calls. In addition or alternatively, the corresponding electrical signal including the detected measurement data can be digitally signed. Therefore, for example, the authenticity of the corresponding measurement data can be proved.

[0074] The embodiment may have the advantage that two-way settlement can be realized. This includes, for example, two-way matching and / or three-way matching. In addition, for example, fully automatic billing can be realized.

[0075] By means of two-party matching, a declaration of intent that matches the delivery conditions for the delivery of goods, such as the physical characteristics of the delivered goods and / or the price of the goods to be delivered, can be achieved using at least one smart contract and recorded with the aid of a DLT system.

[0076] The "2" in the name two-way matching indicates that the delivery order and the order confirmation are verified. In the process of two-way matching, the delivery conditions for the delivery of goods, such as the physical characteristics of the delivered goods and / or the price of the goods to be delivered, are adjusted according to the delivery order and the order confirmation. It is therefore ensured that this match is the same or the difference that occurs does not exceed the predetermined tolerance range. The two-way matching is achieved by the second DLT node in the following manner, that is, for example, the indication is checked according to the order confirmation during the process of entering the order confirmation into the second data set. For example, the delivery order includes a first price indication for the price of the goods to be delivered. The price indication is an indication of the price to be paid for the goods to be delivered. For example, the price indication is the same as the price to be paid. For example, the price to be paid can be derived or calculated from the price indication. If the price indication involves the entire amount of goods to be delivered, the price indication is consistent with the price of the goods to be delivered. For example, the first price indication is a price indication for the amount of goods delivered each time. In the case of a price indication for the amount of goods delivered each time, the actual price to be paid depends on the actual amount of goods delivered. A price indication for each quantity of goods delivered, such as a price indication for each piece, each weight, or each volume multiplied by the quantity of goods delivered, in order to determine the price to be paid for the delivered goods. For example, the first price indication according to the delivery order is entered into the first data set by the first DLT node and is transmitted to the second DLT node to be entered into the second data set. For example, the order confirmation includes a second price indication for the price of the goods to be delivered, especially a second price indication for the quantity of goods delivered each time. For example, the second price indication according to the order confirmation is checked by the second DLT node to see if it matches the first price indication, and is entered into the second data set in the process of updating the second data set in the case of using the order confirmation. For example, two-party matching can be achieved by this check, or the two-party matching includes this check, for example. Therefore, in the process of two-party matching, the price for the goods to be delivered can be adjusted according to the delivery order and the order confirmation. In addition, the update message sent to the first DLT node about updating the second data set in the case of using the order confirmation includes the second price indication. For example, the second price indication transmitted thereby is entered into the second data set by the second DLT node.

[0077] If the first price indication differs from the second price indication in such a way that they are not identical or differ by more than a predetermined tolerance range, a handshake is initiated, for example, between the first DLT node and the second DLT node to align the price indications. For example, the price indications resulting from the alignment are identical or have a residual difference that does not exceed a predetermined tolerance range.

[0078] With three-way matching, the delivery conditions resulting from the two-way matching can be aligned with the corresponding instructions in the verification message together with the indication of the shipping record of the goods actually delivered, and recorded with the help of the DLT system. One or more delivery conditions for the delivery of goods, such as the price of the goods to be delivered, are derived from the two-way matching and are not, for example, the subject of the shipping record. One or more delivery conditions for the delivery of goods, such as the physical properties of the delivered goods, may be different from the result of the two-way matching. Therefore, the actual value for the delivery condition, such as the actual amount of goods delivered, is detected with the help of the shipping record. Therefore, it can be checked whether it is different from the result of the two-way matching, and these differences can be taken into account when verifying the verification message. The "3" in the name three-way matching means that the corresponding verification is based on the shipping record and the verification message in addition to the result of the two-way matching based on the delivery order and the order confirmation.

[0079] The real order includes an indication of determined physical properties of the goods to be delivered, which may be different in the actual delivery, for example due to efficiency and / or production reasons. For example, the real order also includes an indication of determined physical properties, which may be different in the actual delivery due to naturally occurring changes. Thus, for example, the physical properties of the goods to be delivered are detected by sensor technology when they are handed over by the sender of the goods and recorded in the shipping record. These physical properties of the goods handed over according to the shipping record, detected by sensor technology, are recorded in the shared data set of the DLT system, for example as the physical properties of the goods actually delivered, and are used as the basis for checking the verification message.

[0080] For example, the real order defines the quantity to be delivered of the ordered goods. However, for reasons of efficiency, it may be advantageous to fill the transport vehicle for transporting the goods to be delivered, for example, in the case of bulk goods, so that the real amount delivered may be different from the ordered amount. For example, the delivered amount is greater than the ordered amount. The real amount delivered can be detected by means of a sensor mechanism and recorded in the shipping record, for example. For example, the real order defines the determined physical properties of the ordered goods. However, due to production reasons, for example, only goods with physical properties different from those defined at the time of ordering can be produced. In this case, the goods recipient must, for example, agree to different specifications and deliver, or cancel the order. For example, it is temporarily impossible to produce goods to be delivered with determined physical properties, such as because the necessary shipment products and / or the shipment products with the determined necessary physical properties are temporarily unavailable for production. Determined means of production, such as equipment or parts of equipment, may also be temporarily unavailable for production. In this case, alternative to cancellation, for example, the delivery date can be changed to a date when goods that meet the specifications are available or can be produced.

[0081] For example, in the process of three-party matching, the price indication of the price of the goods to be delivered, in particular the price indication of each quantity of goods obtained by the two-party matching, and the indication of the actual quantity of goods delivered included in the shipping record are adjusted with the corresponding indications for price and quantity of goods included in the verification message. Additionally or alternatively, the total price for the delivered goods is determined by the price indication of each quantity of goods obtained from the two-party matching and the indication of the actual quantity of goods delivered included in the shipping record, and is adjusted with the corresponding indication for the total price included in the verification message. For example, a verification message is created when using a smart contract, wherein in the process of three-party matching, it can be ensured that the indication of the delivery conditions in the verification message is consistent with the delivery conditions agreed upon based on the delivery order and the order confirmation and the actual delivery conditions according to the shipping record. In addition, for example, when using a smart contract, payment of the bill amount obtained by the verification message can be triggered. Therefore, the corresponding check of the verification message when using a smart contract can replace the conventional bill check.

[0082] In particular, the above means are advantageous for delivery, such as batch product delivery, in which the delivery conditions of the delivery order and / or order confirmation, such as the final quantity actually delivered, may be different. In this case, the actual delivery conditions can be determined according to the shipping record. In other cases, the delivery conditions are specified as being virtually unchangeable. In the case of packaged goods, for example, the quantity of goods to be delivered is determined by the result of the handshake between the order confirmation or the goods sender and the goods receiver. Therefore, the corresponding prescribed delivery conditions can be taken from the result of the order confirmation or the two-party matching, for example. In this case, the three-party matching is used to check the corresponding adopted delivery conditions in the verification message when using the shipping record. Therefore, during verification, for example, errors about the actual delivery conditions can be identified, and it can be ensured that these errors are taken into account in the verification message, or the verification message is based on the actual delivery conditions. In this case, the corresponding difference or error can trigger the sending and / or correction of a warning prompt according to the verification message, such as the correction made by the subsequent delivery of the goods sender or the delivery of the correct goods.

[0083] The system operates in the following manner, that is, the signal provided by the sensor in the form of a shipping record and / or an incoming goods record is evaluated by one of a plurality of smart contracts, coordinated with the state of the ordering or goods delivery process according to a shared data set, and recorded in the shared data set. In addition, when using one or more smart contracts, the payment amount is transferred semi-automatically or fully automatically between e-wallets or electronic wallets.

[0084] According to an embodiment, the method further comprises signing, by the first DLT node, the data transmitted from the first DLT node to the second DLT node. At least one smart contract is configured on the second DLT node to verify the signature of the transmitted data.

[0085] Embodiments may have the advantage that the authenticity of data transmitted from a first DLT node to a second DLT node may be checked based on a corresponding signature. It may therefore be ensured that the second data set is updated by the second DLT node based on data signed and thereby authorized by the first DLT node. For example, the first DLT node signs the data using a first signature key. The first signature key is, for example, a first private encryption key of a first asymmetric encryption key pair. The first signature key is, for example, stored in a protected memory area of ​​the first DLT node. For example, the second DLT node and / or a smart contract implemented on the second DLT node includes a first signature check key for verifying a signature created using the first signature key. The first signature check key is, for example, a first public encryption key of a first asymmetric encryption key pair.

[0086] For example, cryptographic techniques, such as hashing and / or adding keys, may be used to achieve or increase data security.

[0087] Asymmetric encryption key pairs include public encryption keys and private encryption keys, the public encryption keys are shared with or available to third parties, and the private encryption keys are not shared with or available to third parties. The public encryption key enables a third party to decrypt data that is keyed by the owner of the asymmetric key pair with the private encryption key. In addition, the public encryption key enables a third party to add keys to data, so that only the owner of the asymmetric key pair can decrypt the keyed data with the private encryption key. In contrast, the private key is used by the owner of the asymmetric key pair to add keys to data, so that the data can be decrypted by a third party when using the public encryption key. In addition, the private encryption key is used by the owner of the asymmetric key pair to decrypt the data that is keyed with the public encryption key that is determined for it. Therefore, the private encryption key enables the owner of the asymmetric key pair to, for example, sign data, and the public encryption key enables any third party to verify the corresponding signature.

[0088] A digital signature is an asymmetric encryption system in which the sender uses a secret signature key, i.e. a private encryption key, to calculate a value about a digital message, which is also called a digital signature. This value enables anyone to use a public signature check key, i.e. a public encryption key, to check the undeniable identity of the owner of the signature key and the integrity of the message.

[0089] The signature can be, for example, a cryptographically added hash value of the signed data, in particular a keyed hash value with a private encryption key. The private encryption key is, for example, assigned to a public encryption key, which serves as a signature check key. The public encryption key is, for example, provided as a component of a certificate.

[0090] A "certificate" is understood here to mean a digital certificate, which is also called a public key certificate. With such certificates, a so-called public key infrastructure (PKI) is implemented based on an asymmetric key pair. Such a certificate is structured data for assigning a public key of an asymmetric encryption system 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, a certificate can comply with the X.509 standard or other standards.

[0091] PKI provides a system for issuing, distributing and checking digital certificates. In asymmetric encryption systems, digital certificates are used to confirm or limit the authenticity of public keys and their permitted scope of application and scope of applicability. The digital certificate itself is protected by a digital signature, and the authenticity of the digital signature can be checked with the public key of the issuer of the certificate. The digital certificate is used again to check the authenticity of the issuer's key. In this way, a string of digital certificates can be established, which respectively confirm the authenticity of the public key used to check the previous certificate. This string of certificates forms a so-called verification path or certification path. Users of PKI must be able to trust the authenticity of the last certificate, the so-called root certificate and the key certified by the certificate, without the need for other certificates. The root certificate is managed by the so-called root certification authority, and the authenticity of all certificates of PKI is based on its assumed reliable authenticity.

[0092] When a private encryption key belonging to a public encryption key is used to generate a digital signature to be checked, a certificate can be assigned to the digital signature. By making the certificate associated with the public key available to the public, users of the asymmetric encryption system are able to assign the public key to an entity, such as an individual, organization, computer system, or DLT node.

[0093] According to an embodiment, the method further comprises signing, by the second DLT node, the data transmitted from the second DLT node to the first DLT node. At least one smart contract is configured on the first DLT node to verify the signature of the transmitted data.

[0094] Embodiments may have the advantage that the authenticity of the data transmitted from the second DLT node to the first DLT node can be checked based on the corresponding signature. It can therefore be ensured that the first data set is updated by the first DLT node based on data signed and authorized thereby by the second DLT node. For example, the second DLT node signs the data using a second signature key. The second signature key is, for example, a second private encryption key of a second asymmetric encryption key pair. The second signature key is, for example, stored in a protected memory area of ​​the second DLT node. For example, the second DLT node and / or the smart contract implemented on the second DLT node includes a second signature check key for verifying a signature created using the second signature key. The second signature check key is, for example, a second public encryption key of a second asymmetric encryption key pair.

[0095] According to an embodiment, data transmission between the first DLT node and the second DLT node is achieved via one or more cryptographically protected communication connections by means of end-to-end encryption.

[0096] Embodiments may have the advantage of ensuring that data transmitted between DLT nodes within a DLT system is effectively protected from man-in-the-middle attacks. The key addition is, for example, a symmetric key addition, an asymmetric key addition, or a hybrid key addition. For example, the key addition is performed using the TLS key addition protocol.

[0097] According to an embodiment, establishing the one or more cryptographically protected communication connections comprises mutual authentication of the first DLT node and the second DLT node, respectively.

[0098] Embodiments may have the advantage that based on mutual authentication, the two DLT nodes can ensure with whom they are communicating via the corresponding communication connection, respectively. Thus, the first DLT node of the goods recipient can ensure that it is actually communicating with the DLT node assigned to the goods sender, i.e. the second DLT node. Furthermore, the second DLT node of the goods sender can ensure that it is actually communicating with the DLT node assigned to the goods recipient, i.e. the first DLT node.

[0099] According to an embodiment, checking whether the second specification is consistent with the first specification during the initialization process is a consistency check. The embodiment can have the advantage that consistency is ensured between the first specification according to the delivery order and the second specification according to the order confirmation. This consistency means that the goods recipient and the goods sender have agreed on the same specifications of the goods to be delivered. In this case, for example, the same specifications are stored in two sub-datasets of the shared data set, for example. If the first specification and the second specification are different from each other, a handshake protocol can be implemented between the two DLT nodes, for example, using at least one smart contract, as a result of which one or both specifications are adapted until consistency is achieved.

[0100] According to an embodiment, the initialization also includes, if one or more physical characteristics according to the second specification in the input second data set are different from one or more physical characteristics according to the first specification from the first data set, performing a handshake between the first DLT node and the second DLT node to align the first specification of the first data set and the second specification of the second data set, so that the first specification and the second specification obtained by the alignment are consistent.

[0101] The handshake may be, for example, an automatic or semi-automatic handshake. In the case of an automatic handshake, for example, a tolerance range for the parameter to be negotiated is defined for the goods recipient and the goods sender. In this case, the difference between the parameters can be obtained by adjusting within the corresponding tolerance range. In the case of a semi-automatic handshake, a suggestion for a parameter value is obtained from one of the two users or from a DLT node assigned to the corresponding user, which is different from the suggestion for the corresponding parameter of the corresponding user itself. The different parameter values ​​can be confirmed, for example, by receiving user input from the corresponding user. If the corresponding parameter value is confirmed by the user input, the confirmation of the suggested parameter value can also be sent to the second participant of the suggestion during the handshake. Alternatively, a reverse suggestion for a different parameter value can be received by receiving user input from the corresponding user. During the handshake, such a reverse suggestion for a different parameter value can be sent to the second user. The second user confirms the reverse suggestion by sending the corresponding confirmation during the handshake, or it proposes a new reverse suggestion. The method may, for example, continue until an agreement is reached on the corresponding parameter value or until a predetermined termination criterion is met. The corresponding termination criterion may be, for example, a predetermined maximum number of suggestions for parameter values, expiration of a predetermined maximum time period for negotiating parameter values, or receipt of a user input explicitly rejecting the current suggestion for the corresponding parameter value.

[0102] The handshake may be implemented 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 negotiation partners may be implemented by inputting the proposals into the correspondingly managed part of the shared dataset, which is then transmitted to the DLT nodes of the negotiation partners. Thus, all changes remain traceable and can be verified by the negotiation partners. Thus, there is transparency between the negotiation partners regarding the parameters to be negotiated, since the own proposals are input into their own part of the shared dataset, while the counter-proposals are input into the corresponding other part of the shared dataset.

[0103] Embodiments may have the advantage that an efficient method may be provided for adjusting different specifications according to a delivery order and an order confirmation, ie, different proposals for specifications between a goods receiver and a goods sender.

[0104] According to an embodiment, checking whether the second specification is consistent with the first specification during the initialization process is checking whether it is consistent within a third tolerance predetermined according to at least one smart contract.

[0105] Embodiments may have the advantage that no agreement between specifications is necessarily achieved. Thus, differences are permitted within predetermined tolerances. For example, a goods sender may adapt the specifications of the goods to be delivered, such as the quantity of goods to be delivered, to its capabilities for delivering the requested goods within predetermined limits, i.e. tolerances.

[0106] According to an embodiment, the initialization further comprises, if one or more differences between the one or more physical characteristics according to the second specification in the input second data set and the one or more physical characteristics according to the first specification from the first data set are greater than a predetermined third tolerance, performing a handshake between the first DLT node and the second DLT node to align the first specification of the first data set and the second specification of the second data set. The handshake causes the first specification and the second specification resulting from the alignment to match within the predetermined third tolerance.

[0107] Embodiments may have the advantage that an efficient method may be provided for adjusting different specifications, i.e. different proposals for specifications between a goods recipient and a goods sender, based on a delivery order and an order confirmation. Using at least one smart contract, for example a handshake protocol is implemented between two DLT nodes, with the result that one or both specifications are adapted until the remaining differences between the two specifications are only within a corresponding predetermined tolerance.

[0108] According to an embodiment, the program instructions included in at least one smart contract are further configured to input and check incoming cargo records during the delivery of cargo from the cargo sender to the cargo receiver. Recording cargo delivery in the DLT system also includes:

[0109] receiving an incoming shipment record from a goods recipient via the first network through the first DLT node, wherein the incoming shipment record comprises one or more second sensor values ​​for one or more physical properties of the incoming goods according to the first specification, the second sensor values ​​being 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 quantifying a delivered quantity of the goods,

[0110] checking, using at least one smart contract, whether one or more second sensor values ​​of the incoming goods record correspond within a predetermined fourth tolerance to one or more physical properties of the goods to be delivered according to the shared data set and to one or more first sensor values ​​of the outgoing goods record, wherein the checked second sensor values ​​include at least a second sensor value quantifying the amount of the delivered goods,

[0111] updating the first data set a fourth time by the first DLT node using the result of a third check of the one or more second sensor values ​​of the check incoming goods record,

[0112] transmitting at least one fourth update message from the first DLT node to the second DLT node,

[0113] Updating the second data set for a fifth time by the second DLT node using the fourth update message.

[0114] The embodiment may have the advantage that the record of cargo delivery also includes the cargo receiver's incoming cargo record regarding the cargo actually received, in addition to the cargo sender's outgoing cargo record regarding the cargo actually sent.

[0115] If the physical delivery of goods is received by the goods recipient, i.e., if the goods to be delivered arrive at the warehouse of the goods recipient, an incoming goods record is created. The corresponding incoming goods record comprises one or more sensor values ​​for one or more physical properties of the incoming goods according to the first specification, which are detected by means of one or more physical sensors assigned to the goods recipient. Thus, the incoming goods record indicates measured values ​​respectively detected by sensor technology for one or more physical properties, for which target values ​​are indicated in the first specification, which reflect the actual condition of the incoming goods in terms of the corresponding physical properties. The corresponding sensor values ​​here comprise at least one sensor value that quantifies the amount of delivered, i.e., incoming goods.

[0116] The first DLT node of the goods recipient receives the incoming cargo record from the goods recipient via the first network and checks whether one or more second sensor values ​​of the incoming cargo record are consistent with one or more physical characteristics of the goods to be delivered. Here, it is checked whether one or more sensor values ​​of the incoming cargo record are consistent with one or more physical characteristics according to the shared data set within a predetermined tolerance. If such consistency is not achieved, a warning prompt is transmitted to the goods recipient and / or the goods sender, for example. Such a warning prompt can, for example, trigger a subsequent delivery from the goods sender when the delivery volume is too small. On the goods recipient side, for example, such a warning prompt may require confirmation of different physical characteristics on the part of the goods recipient in order to successfully complete the final verification of the goods delivery.

[0117] The first data set is updated by the first DLT node using the result of checking one or more first sensor values ​​of the incoming shipment record. For example, the update includes inputting the incoming shipment record and / or one or more of the sensor values ​​indicated by the incoming shipment record. For example, all sensor values ​​indicated by the incoming shipment record are input. For example, only such sensor values ​​that are different from the values ​​entered in the first data set for the physical characteristic of the goods to be delivered are input. For example, for sensor values ​​of the incoming shipment record that match the values ​​entered in the first data set for the physical characteristic of the goods to be delivered, only a confirmation that the corresponding value for the physical characteristic matches the detected sensor value is input in the second data set.

[0118] In addition, a fourth update message is transmitted from the first DLT node to the second DLT node. The fourth update message, for example, includes one or more of the incoming shipment record and / or the sensor values ​​indicated by the incoming shipment record. For example, the fourth update message includes all sensor values ​​indicated by the incoming shipment record. For example, the fourth update message only includes such sensor values ​​that are different from the values ​​of the physical characteristics of the goods to be delivered entered in the first data set. For example, for sensor values ​​of the incoming shipment record that match the values ​​of the physical characteristics of the goods to be delivered entered in the first data set, the fourth update message only includes a confirmation that the corresponding values ​​of the physical characteristics according to the shared data set match the detected sensor values.

[0119] The second DLT node updates the second data set, i.e., the second sub-data set of the shared data set, using the fourth update message. For example, the update includes inputting one or more of the incoming goods record and / or the sensor values ​​indicated by the incoming goods record. For example, all sensor values ​​indicated in the incoming goods record are input. For example, only such sensor values ​​that are different from the values ​​entered in the second data set for the physical characteristics of the goods to be delivered are input. For sensor values ​​of the incoming goods record that match the values ​​entered in the second data set for the physical characteristics of the goods to be delivered, only a confirmation that the corresponding value for the physical characteristic matches the detected sensor value is entered in the second data set.

[0120] The one or more second physical sensors of the goods sender include one or more physical measuring devices for detecting measurement data or sensor values. Such measurement data are data that quantitatively or qualitatively describe the physical and / or chemical properties of the measurement object. The corresponding characteristics include, for example, weight, volume, temperature, humidity, pressure, particle size, sound field size, brightness, pH value, ionic strength, electrochemical potential, conductivity, viscosity and / or light transmittance. The measurement data is detected by means of physical or chemical effects and converted into an electrical signal that can be further processed electronically. For example, a key is added to the corresponding electrical signal in an encrypted manner, and the electrical signal includes the detected measurement data. For example, a symmetric, asymmetric or mixed encryption method can be applied to add a key for this purpose. Therefore, for example, the corresponding measurement data can be protected from unauthorized calls. In addition or alternatively, the corresponding electrical signal including the detected measurement data can be digitally signed. Therefore, for example, the authenticity of the corresponding measurement data can be proved.

[0121] According to an embodiment, the verification message includes the bill. This embodiment can have the advantage that the bill for the delivery of the goods is checked during the verification message. It can thus be ensured that the indications of the bill regarding the physical properties of the delivered goods correspond to the actual physical properties of the delivered goods. In particular, it can be ensured that the indications regarding the quantity of the delivered goods, on which the bill is based, correspond to the actual quantity of the delivered goods.

[0122] According to an embodiment, the program instructions included in the at least one smart contract are further configured to create a bill for the bill. The bill creation is performed by the second DLT node using the at least one smart contract. The parameters of the verification message are checked during the bill creation process.

[0123] Embodiments may have the advantage that bill creation may be directly integrated in the process of verifying the delivery of goods. For example, monitoring of the delivery of goods is successfully completed with the bill created being registered in the DLT system.

[0124] Using one or more smart contracts, additional charges and taxes, such as sales tax, can be calculated for the bill amount and added when the bill is created.

[0125] According to an embodiment, the bill is received by a first ERP system of the sender of the goods, which creates the bill. The embodiment may have the advantage that the DLT system can be combined with an ERP system of the sender of the goods, for example an existing ERP system. Here, the DLT system or a shared data set managed by the DLT system represents a single point of fact for the delivery of the goods. For example, in order to verify the bill, it is necessary to register at least in a second data set on a second DLT node. For example, the registration includes entering the bill number of the bill into the second data set.

[0126] For example, a cargo sender and a cargo receiver each have independent ERP systems, whereas a shared data set provided in a DLT system serves as a single point of truth for both parties involved, ie, the cargo receiver and the cargo sender.

[0127] An ERP system is an application software or IT system or multiple communicating applications software or IT systems that are used to support the resource planning of an enterprise. For example, complex ERP systems are divided into subsystems, i.e. application modules, which can be combined with each other as needed. Enterprise Resource Planning (ERP) is the enterprise task of planning, controlling and managing people and resources such as funds, operating resources, materials and information and communication technology in a timely and demand-based manner.

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

[0129] For example, the ERP systems of the goods sender and the goods receiver can be configured to create and / or compile data related to the goods delivery and make it available to the DLT system. For example, the ERP system of the goods receiver creates a delivery order and / or an incoming shipment record and sends it to the first DLT node. For example, the ERP system of the goods sender creates an order confirmation, an outgoing shipment record and / or a verification message and sends it to the second DLT node.

[0130] According to an embodiment, the data entered in the shared data set provided in the DLT system during the process of recording the delivery of goods is the mirror image of the data of the goods delivery from the first ERP system of the goods sender and / or the second ERP system of the goods receiver. The first ERP system and / or the second ERP system are configured to control the processing of the goods delivery. Data consistency between the shared data set and the ERP system is ensured by entering the mirror image of the same data.

[0131] Embodiments may have the advantage that data consistency may be achieved between the shared dataset and the ERP system of the goods sender and / or the goods recipient. Here, the shared dataset represents a single point of fact for two users or their ERP systems that are independent of each other. For example, a first DLT node receives a delivery order from an ERP system of a goods recipient. For example, a second DLT node receives a delivery order from an ERP system of a goods sender. Here, the data entered in the shared dataset reflects the data stored in the first ERP system and / or the second ERP system for the goods delivery.

[0132] According to an embodiment, the processing of the delivery of goods is controlled by at least one smart contract, and the program instructions of the at least one smart contract are also configured to control the processing of the delivery of goods.

[0133] Embodiments may have the advantage that the delivery of goods may be processed by at least one smart contract. In this case, for example, no ERP system is required on the side of the goods recipient and the side of the goods sender to process the delivery of goods. For example, the computer system of the goods recipient may send the delivery order directly to the first DLT node via the first network, or the first DLT node may receive the delivery order directly from the computer system of the goods recipient. For example, the computer system of the goods sender may send the order confirmation directly to the second DLT node via the first network.

[0134] According to an embodiment, the first network is, for example, a public network. For example, the first network is the Internet or another existing wide area network, such as a radio or Ethernet-based network within an enterprise or between participating enterprises.

[0135] Correspondingly, according to an embodiment, the first network may be, for example, an intranet.

[0136] According to an embodiment, a prerequisite for receiving the delivery order of the goods recipient by the first DLT node is a successful authentication of the goods recipient by the first DLT node. Embodiments can have the advantage that the first DLT node can ensure, by means of a successful authentication of the goods recipient, that the delivery order actually comes from the goods recipient and is authorized by the goods recipient. For example, the authentication can be performed using a first user name and a first password, which the goods recipient must indicate to the first DLT node in order to successfully authenticate. Other authentication methods can also be provided, for example by means of encryption methods, chip cards and / or biometric data.

[0137] According to an embodiment, a prerequisite for receiving the order confirmation of the sender of the goods by the second DLT node is a successful authentication of the sender of the goods by the second DLT node. Embodiments can have the advantage that the second DLT node can ensure, by means of a successful authentication of the sender of the goods, that the delivery order actually comes from the sender of the goods and is authorized by the sender of the goods. For example, the authentication can be performed using a second user name and a second password, and the recipient of the goods must indicate the second user name and the second password to the first DLT node in order to successfully authenticate. Other authentication methods can also be provided, for example by means of encryption methods, chip cards and / or biometric data.

[0138] According to an embodiment, a prerequisite for receiving the shipment record from the sender of the goods by the second DLT node is a successful authentication of the sender of the goods by the second DLT node. Embodiments can have the advantage that the second DLT node can ensure, by means of a successful authentication of the sender of the goods, that the shipment record actually comes from the sender of the goods and is authorized by the sender of the goods. For example, the authentication can be performed using a second user name and a second password, and the receiver of the goods must indicate the second user name and the second password to the first DLT node in order to successfully authenticate. Other authentication methods can also be provided, for example by means of encryption methods, chip cards and / or biometric data.

[0139] According to an embodiment, a prerequisite for receiving the incoming shipment record from the goods recipient via the first DLT node is a successful authentication of the goods recipient via the first DLT node. The embodiment may have the advantage that the first DLT node may ensure, by means of a successful authentication of the goods recipient, that the incoming shipment record actually comes from the goods recipient and is authorized by the goods recipient. For example, the authentication may be performed using a first user name and a first password, which the goods recipient must indicate to the first DLT node in order to successfully authenticate.

[0140] According to an embodiment, a prerequisite for sending the delivery order of the goods recipient through the first DLT node is a successful signature check of the signature of the delivery order through the first DLT node.

[0141] Embodiments may have the advantage that the authenticity of a delivery order may be checked based on the signature of the delivery order, i.e., the first DLT node may check whether the received delivery order is actually authorized by the recipient of the goods. For example, the recipient of the goods signs the delivery order using a third signature key. The third signature key is, for example, a third private encryption key of a third asymmetric encryption key pair. For example, the first DLT node and / or a smart contract implemented on the first DLT node includes a third signature check key for verifying the signature of the recipient of the goods created using the third signature key. The third signature check key is, for example, a third public encryption key of a third asymmetric encryption key pair.

[0142] According to an embodiment, a prerequisite for using the order confirmation of the sender of the goods by the second DLT node is a successful signature check of the signature of the order confirmation by the second DLT node.

[0143] Embodiments may have the advantage that the authenticity of the order confirmation may be checked based on the signature of the order confirmation, i.e., the second DLT node may check whether the received order confirmation is actually authorized by the sender of the goods. For example, the sender of the goods signs the order confirmation using a fourth signature key. The fourth signature key is, for example, a fourth private encryption key of a fourth asymmetric encryption key pair. For example, the second DLT node and / or the smart contract implemented on the second DLT node includes a fourth signature check key for verifying the signature created by the sender of the goods using the fourth signature key. The fourth signature check key is, for example, a fourth public encryption key of a fourth asymmetric encryption key pair.

[0144] According to an embodiment, the use of the shipment record of the goods sender by the second DLT node is premised on a successful signature check of the signature of the shipment record by the second DLT node.

[0145] The embodiment may have the advantage that the authenticity of the shipping record may be checked based on the signature of the shipping record, i.e., the second DLT node may check whether the received shipping record is actually authorized by the sender of the goods. For example, the sender of the goods signs the order confirmation using the fourth signature key, and the second DLT node may verify its signature using the fourth signature check key.

[0146] According to an embodiment, the use of the incoming shipment record of the goods recipient by the first DLT node is premised on a successful signature check of the signature of the incoming shipment record by the first DLT node.

[0147] The embodiment may have the advantage that the authenticity of the incoming shipment record may be checked based on the signature of the incoming shipment record, i.e., the first DLT node may check whether the received incoming shipment record is actually authorized by the goods recipient. For example, the goods recipient signs the incoming shipment record using the third signature key, and the first DLT node may verify its signature using the signature check key.

[0148] According to an embodiment, 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.

[0149] According to an embodiment, one or more DLT servers of a DLT system are arranged in one or more computing centers, which are protected from unauthorized access. The embodiment may have the advantage that unauthorized entity calls to a DLT server can be prevented by access protection, and thus unauthorized entity calls to a DLT node implemented on a DLT server can be prevented. For example, in addition to encrypted call protection, access protection or call protection of such an entity can also be implemented, which prevents unauthorized calls to a DLT server or a DLT node via a first network, such as the Internet. Such encrypted call protection, for example, includes a successful authentication as a prerequisite for calling a DLT node via the first network. For example, authentication requires the correct input of the user's username and password, such as the sender of the goods or the receiver of the goods, and the corresponding DLT node is assigned to the user. For example, the prerequisite for successful authentication is multi-factor authentication, such as two-factor authentication.

[0150] Access protection for a computing center includes, for example, monitoring access to the computing center and protecting rooms in the computing center using alarm systems. Alarm systems include, for example, intrusion alarm systems (EMA), i.e., electronically operated mechanisms for protecting property. Intrusion alarm systems are configured, for example, to prevent intrusions by deterrence, and to notify assisting services, such as the police and / or private security services, in the event of an intrusion, to minimize the time for the intruder to act, to warn the surroundings and participating on-site personnel, and / or to reconstruct an actual intrusion.

[0151] According to an embodiment, data transfer between DLT nodes is performed via the second network.

[0152] For example, the second network is a network different 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.

[0153] According to an embodiment, the second network is a private network 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.

[0154] According to an embodiment, the program instructions included in the at least one smart contract are further configured to trigger an electronic payment transaction. The payment transaction is triggered by the smart contract when the verification message is registered in the DLT system.

[0155] Embodiments may have the advantage that payments and reservations may be made in real time. Embodiments may also have the advantage that the electronic payment transaction is triggered by registering a verification message in the DLT system, i.e. successfully verifying the delivery of goods in the DLT system. For example, the payment transaction is triggered by registering a verification message in the first data set and / or in the second data set. Here, for example, the registered verification message determines the amount to be paid for the electronic payment transaction.

[0156] Payment transactions can be linked to data flows from verification and kept in a closed data loop.

[0157] According to an embodiment, the triggered electronic payment transaction is a money transfer from a bank account of the goods recipient to a bank account of the goods sender.

[0158] According to an embodiment, the triggered electronic payment transaction is an IBAN transfer from the IBAN account of the goods receiver to the IBAN account of the goods sender.

[0159] According to an embodiment, a triggered electronic payment transaction is a transaction of a certain amount of programmable currency implemented using a DLT system.

[0160] Embodiments may have the advantage that certain amounts of programmable money may be traded within a DLT system. Thus, a transaction may be triggered by registering a verification message and implemented directly in the DLT system, for example using at least one smart contract.

[0161] Programmable money refers to a digital form of money in which users can program inherent logic for conditional use based on the properties of the digital currency itself. An example in this regard is triggering a transaction after one or more conditions are met, such as time, location, type of use, etc.

[0162] For example, a payment infrastructure is provided that enables a sender of goods and a receiver of goods to jointly use programmable money. Thus, for example, a delivery of goods can also be verified and invoiced in a closed data loop.

[0163] According to an embodiment, the DLT system is configured to transfer the bill amount to be paid from the account of the goods recipient for programmable currency to the account of the goods sender for programmable currency. Preferably, the DLT system can be configured to convert the legal tender amount of the legal tender account assigned to the goods recipient into the amount of programmable currency in the account of the goods recipient for programmable currency. In addition, the DLT system can be configured to at least partially convert the bill amount transferred in the form of programmable currency from the account of the goods sender for programmable currency into the legal tender amount in the legal tender account assigned to the goods sender.

[0164] Embodiments may have the advantage that transactions may be processed with the aid of programmable money. To this end, a legal tender amount of the goods recipient may be converted into an amount of programmable money, which is used at least in part to pay for the delivered goods. Subsequently, a bill amount in the form of programmable money received by the goods sender as payment for the delivered goods may be converted into an amount of legal tender. The legal tender amount may be credited to a legal tender account of the goods sender allocated to the goods sender.

[0165] Legal tender refers to conventional currency, i.e., a medium of exchange and payment regulated by the government, which is artificially created, undisclosed, and unrestricted. In other words, it is an economic object with no intrinsic value that serves as a medium of exchange.

[0166] According to an embodiment, the payment transaction is recorded in the DLT system using at least one smart contract. In the case of using a smart contract, an electronic account statement about the recorded payment transaction is also issued to the goods recipient and / or the goods sender.

[0167] Embodiments may have the advantage that, in addition to carrying out electronic payment transactions, electronic account statements are issued for the goods recipient and / or the goods sender regarding the corresponding payment transactions. For example, the account statements are issued according to the MT940 standard. MT940 (MT=message type) is a SWIFT standard (Society for Worldwide Interbank Financial Telecommunication) or a banking communication standard for the electronic transmission of account statement data.

[0168] Other embodiments include a shared data set of a limited-access DLT system for computer-implemented monitoring of a delivery of goods from a goods sender to a goods recipient using a DLT system. The shared data set includes a first portion. The first portion is a first data set managed by a first DLT node assigned to the goods recipient. In addition, the shared data set includes a second portion. The second portion is a second data set managed by a second DLT node assigned to the goods sender.

[0169] For example, the first data set of the first part includes an indication of one or more physical characteristics of the goods to be delivered as a first specification from the delivery order. The physical characteristics of the first specification include at least one quantity of goods to be delivered. For example, the first data set of the first part includes an indication of a second specification of one or more physical characteristics of the goods to be delivered according to the order confirmation. For example, the first data set of the first part includes a check result of checking the second specification. For example, the first data set of the first part includes one or more first sensor values ​​for one or more physical characteristics of the goods according to the shipping record, which are detected by means of one or more physical sensors assigned to the sender of the goods. The one or more first sensor values ​​include at least one first sensor value that quantifies the quantity of goods delivered. For example, the first data set of the first part includes a check result of checking the first sensor value of the shipping record. For example, the first data set of the first part includes one or more second sensor values ​​for one or more physical characteristics of the goods according to the incoming record, which are detected by means of one or more physical sensors assigned to the receiver of the goods. The one or more second sensor values ​​include at least one second sensor value that quantifies the quantity of goods delivered. For example, the first data set of the first part includes a check result of checking the second sensor value of the shipping record. For example, the first data set of the first part includes a verification message registered for verifying the delivery of goods. For example, the registration includes an indication of one or more parameters of the verification message. For example, the parameters include at least one quantity of goods to be verified. For example, the first data set of the first part includes a check result of checking the parameters of the verification message.

[0170] For example, the second data set of the second part includes an indication of one or more physical characteristics of the goods to be delivered as a first specification from the delivery order. The physical characteristics of the first specification include at least one quantity of goods to be delivered. For example, the second data set of the second part includes an indication of a second specification of one or more physical characteristics of the goods to be delivered according to the order confirmation. For example, the second data set of the second part includes a check result of checking the second specification. For example, the second data set of the second part includes one or more first sensor values ​​for one or more physical characteristics of the goods according to the shipping record, which are detected by means of one or more physical sensors assigned to the sender of the goods. The one or more first sensor values ​​include at least one first sensor value that quantifies the quantity of goods delivered. For example, the second data set of the second part includes a check result of checking the first sensor value of the shipping record. For example, the second data set of the second part includes one or more second sensor values ​​for one or more physical characteristics of the goods according to the incoming record, which are detected by means of one or more physical sensors assigned to the receiver of the goods. The one or more second sensor values ​​include at least one second sensor value that quantifies the quantity of goods delivered. For example, the second data set of the second part includes a check result of checking the second sensor value of the shipping record. For example, the second data set of the second part includes a verification message registered for verifying the delivery of goods. For example, the registration includes an indication of one or more parameters of the verification message. For example, the parameters include at least one quantity of goods to be verified. For example, the second data set of the second part includes a check result of checking the parameters of the verification message.

[0171] For example, the shared data set is the result of implementing one or more of the aforementioned method steps of the method for computer-implemented monitoring of cargo delivery. For example, the shared data set is the result of implementing each of the aforementioned method steps of the method for computer-implemented monitoring of cargo delivery.

[0172] A shared dataset distributed on two DLT nodes and including two (sub) datasets of a goods recipient and a goods sender can have the advantage of providing an effective means for confidentiality of transactions between the two DLT nodes. In addition, such a shared dataset can achieve effective protection of transactions and improve data security between DLT nodes.

[0173] The shared dataset can be used in any method according to one or more embodiments of the present specification. In addition, the dataset can be the subject of the aforementioned method and can be edited and updated by it.

[0174] Other embodiments include using a shared dataset according to one or more embodiments of this specification for initializing the delivery of goods in a DLT system. The shared dataset can be used for initialization in any method according to one or more embodiments of this specification.

[0175] Other embodiments include using a shared dataset according to one or more embodiments of this specification for recording the delivery of goods in a DLT system. The shared dataset can be used for recording in any method according to one or more embodiments of this specification.

[0176] Other embodiments include using a shared dataset according to one or more embodiments of this specification for verifying the delivery of goods in a DLT system. The shared dataset can be used for verification in any method according to one or more embodiments of this specification.

[0177] Other embodiments include a DLT node of a limited-access DLT system for computer-implemented monitoring of a delivery of goods from a goods sender to a goods recipient. The DLT node is implemented on a DLT server of the DLT system and is assigned to a goods recipient. The DLT server includes a processor and a memory with program instructions. At least one smart contract is provided on the DLT node by the program instructions. The program instructions for providing at least one smart contract include program instructions for entering and checking delivery orders and order confirmations.

[0178] The execution of the program instructions by the processor causes the processor to control the DLT node in the following manner, that is, the DLT node implements the following in the process of initiating the delivery of goods in the DLT system:

[0179] receiving, via the first network, a delivery order from a goods recipient for goods to be delivered from a goods sender to the goods recipient by means of a DLT node, wherein the delivery order identifies one or more physical characteristics of the goods to be delivered as a first specification, wherein the physical characteristics of the first specification include at least one quantity of the goods to be delivered,

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

[0181] transmitting at least the first data set from the DLT node to another DLT node,

[0182] receiving at least one first update message from another DLT node via an update of the second data set using a first check result of checking whether the second specification of one or more physical characteristics of the goods to be delivered according to the order confirmation corresponds to the first specification,

[0183] The first data set is updated for the first time by the DLT node using a first update message.

[0184] Other embodiments include a DLT node, wherein the program instructions for providing at least one smart contract include program instructions for inputting and checking shipment records during the delivery of goods from a goods sender to a goods receiver. Execution of the program instructions by a processor of the DLT node causes the processor to further control the DLT node in the following manner, namely, the DLT node implements the following during the process of recording the delivery of goods in the DLT system:

[0185] receiving at least one second update message from another DLT node via an update of the second data set using a second check result, the second check result being the result of a check whether one or more first sensor values ​​of the shipment record correspond within a predetermined first tolerance to one or more physical properties of the goods to be delivered according to the shared data set, wherein the one or more first sensor values ​​of the shipment record are detected by means of one or more first physical sensors assigned to the sender of the goods, wherein the checked first sensor values ​​include at least first sensor values ​​quantifying the delivered goods quantity,

[0186] Updating the first data set a second time by the DLT node using a second update message.

[0187] Other embodiments include a DLT node, wherein the program instructions for providing at least one smart contract include program instructions for verifying delivery of goods. Execution of the program instructions by a processor of the DLT node causes the processor to further control the DLT node in the following manner, namely, the DLT node implements the following in the process of verifying delivery of goods in the DLT system:

[0188] receiving at least one third update message from the other DLT node via the updating of the second data set using the verification message, wherein the updating of the second data set using the verification message comprises registering the verification message in the second data set, wherein the updating of the second data set using the verification message confirms a successful check of parameters of the verification message by the other DLT node, wherein the parameters comprise at least one quantity of goods to be verified, wherein the checking of the parameters comprises checking whether the quantity of goods to be verified corresponds within a predetermined second tolerance to a first sensor value quantifying the delivered quantity of goods,

[0189] Updating the first data set for a third time by the DLT node using a third update message, wherein the third updating of the first data set comprises registering the verification message in the first data set.

[0190] For example, the DLT node is configured to implement one or more of the aforementioned method steps of the DLT node assigned to the cargo recipient according to an exemplary embodiment of the method for computer-implemented monitoring of cargo delivery. For example, the DLT node is configured to implement each of the aforementioned method steps of the DLT node assigned to the cargo recipient according to an exemplary embodiment of the method for computer-implemented monitoring of cargo delivery.

[0191] A "processor" is understood here as a logic circuit for executing 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 as a microprocessor or a microprocessor system composed of multiple processor cores and / or multiple microprocessors.

[0192] “Program” or “program instructions” are understood here in a non-limiting manner as any type of computer program comprising machine-readable instructions for controlling the functions of a computer.

[0193] “Memory” is understood here to mean both volatile and non-volatile memory, in particular electronic memory or digital storage media.

[0194] "Non-volatile memory" is understood here to mean an electronic memory for permanent storage of data. Non-volatile memory can be configured as a non-volatile memory, which is also referred to as read-only memory (ROM), or as a variable memory, which is also referred to as non-volatile memory (NVM). In particular, this can be an EEPROM, for example a flash EEPROM, also referred to as flash memory. Non-volatile memory is characterized in that the data stored thereon are retained even after the power supply is switched off.

[0195] "Volatile memory" is understood here to mean an electronic memory for temporary storage of data, which is characterized in that the stored data are lost after a power failure. In particular, this can be a volatile direct access memory, which is also called random access memory (RAM), or a volatile main memory of a processor.

[0196] A "protected memory area" is understood here to mean an area of ​​an electronic memory that can only be accessed, i.e. read or written, via a processor of the corresponding electronic device. Depending on the embodiment, access from a processor connected to the memory is only possible if the conditions required for this are met. These can be, for example, cryptographic conditions, in particular successful authentication of the access request and / or a successful authorization check.

[0197] A "communication interface" is understood here to be an interface via which data can be received and sent, wherein the communication interface can be configured as contact or contactless. The communication interface can be an internal interface or an external interface, which is connected to an associated device, for example by means of a cable or wirelessly.

[0198] For example, communication can take place via a network. A "network" is understood here to mean any transmission medium that has a link 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 (virtual private network - VPN). For example, a computer system can have a standard radio interface for linking to a WLAN. In addition, it can be a public network, such as the Internet. Depending on the embodiment, such a connection can also be established via a mobile radio network.

[0199] Here and hereinafter, a “mobile radio network” is understood to mean a digital cellular mobile radio network which can be constructed according to a mobile radio standard such as GSM, UMTS, LTE, CDMA or another standard.

[0200] Other embodiments include a DLT node of a limited-access DLT system for computer-implemented monitoring of the delivery of goods from a goods sender to a goods recipient. The DLT node is implemented on a DLT server of the DLT system and is assigned to the goods recipient. The DLT server includes a processor and a memory with program instructions. At least one smart contract is provided on the DLT node by the program instructions. The program instructions for providing at least one smart contract include program instructions for entering and checking delivery orders, order confirmations and shipping records during the delivery of goods from the goods sender to the goods recipient and for verifying the delivery of goods.

[0201] The execution of the program instructions by the processor causes the processor to control the DLT node in the following manner, that is, the DLT node implements the following in the process of initiating the delivery of goods in the DLT system:

[0202] receiving from another DLT node at least one first data set created by the another DLT node of a receiver of the goods, wherein the first data set is a first part of a shared data set between the DLT node and the another DLT node, wherein the first data set comprises at least one or more physical characteristics of the goods to be delivered according to a first specification of the delivery order, wherein the physical characteristics of the first specification comprise at least one quantity of the goods to be delivered,

[0203] creating a second data set managed by the DLT node, wherein the second data set is a second portion of the shared data set, and updating the second data set for a first time based on the first data set by the DLT node, wherein the first updating includes inputting at least one or more of the physical characteristics of the first specification into the second data set, wherein the at least one or more input physical characteristics of the first specification include the quantity of goods to be delivered,

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

[0205] checking whether the second specification complies with the first specification using at least one smart contract,

[0206] updating the second data set a second time by the second DLT node using the result of the first check of the second specification,

[0207] • Transmitting at least a first update message from the DLT node to another DLT node to update the first data set.

[0208] Other embodiments include a DLT node, wherein the program instructions for providing at least one smart contract include program instructions for inputting and checking shipment records during the delivery of goods from a goods sender to a goods receiver. Execution of the program instructions by a processor causes the processor to further control the DLT node in the following manner, namely, the DLT node implements the following during the process of recording the delivery of goods in the DLT system:

[0209] receiving, by the DLT node via the first network, a shipment record from a goods sender, wherein the shipment record comprises one or more first sensor values ​​for one or more physical properties of the shipped goods according to the second specification, the first sensor values ​​being 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 quantifying a delivered quantity of goods,

[0210] checking, using at least one smart contract, whether one or more first sensor values ​​of the shipment record correspond within a predetermined first tolerance to one or more physical properties of the goods to be delivered according to the shared data set, wherein the checked first sensor values ​​include at least a first sensor value quantifying the amount of the goods delivered,

[0211] updating the second data set for a third time by the DLT node using the second check result of the one or more first sensor values ​​of the check shipment record,

[0212] • Transmitting at least one second update message from the DLT node to another DLT node to update the first data set.

[0213] Other embodiments include a DLT node, wherein the program instructions for providing at least one smart contract include program instructions for verifying delivery of goods. Execution of the program instructions by a processor causes the processor to further control the DLT node in the following manner, namely, the DLT node implements the following in the process of verifying delivery of goods in the DLT system:

[0214] checking, by the DLT node, parameters of a verification message for verifying a delivery of goods using at least one smart contract, wherein the parameters include at least one quantity of goods to be verified, wherein the checking of the parameters includes checking whether the quantity of goods to be verified corresponds within a predetermined second tolerance to a first sensor value quantifying the delivered quantity of goods,

[0215] updating the second data set for a fourth time by the DLT node when the quantity of goods to be verified corresponds to the first sensor value quantifying the delivered quantity of goods within a predetermined second tolerance, wherein the fourth updating comprises registering a verification message in the second data set by the DLT node using at least one smart contract,

[0216] • Transmitting at least one third update message from the DLT node to another DLT node to update the first data set.

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

[0218] Other embodiments include a DLT system for computer-implemented monitoring of a delivery of goods from a goods sender to a goods recipient, the DLT system comprising a first DLT node assigned to the goods recipient and a second DLT node assigned to the goods 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 checking delivery orders and order confirmations.

[0219] The DLT system is configured to implement the initialization of the delivery of goods in the DLT system. The initialization includes:

[0220] receiving, by the first DLT node via the first network, a delivery order from a goods recipient for goods to be delivered from a goods sender to the goods recipient, wherein the delivery order identifies one or more physical characteristics of the goods to be delivered as a first specification, wherein the physical characteristics of the first specification include at least one quantity of the goods to be delivered,

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

[0222] transmitting at least the first data set from the first DLT node to the second DLT node,

[0223] creating a second data set managed by a second DLT node, wherein the second data set is a second portion of the shared data set, and updating the second data set for a first time based on the first data set by the second DLT node, wherein the first updating includes inputting at least one or more of the physical characteristics of the first specification into the second data set, wherein the at least one or more input physical characteristics of the first specification include the quantity of goods to be delivered,

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

[0225] checking whether the second specification complies with the first specification using at least one smart contract,

[0226] updating the second data set a second time by the second DLT node using the result of the first check of the second specification,

[0227] transmitting at least one first update message from the second DLT node to the first DLT node,

[0228] • Updating the first data set for the first time by the first DLT node using a first update message.

[0229] Other embodiments include a DLT system further configured to implement a record of a delivery of goods in the DLT system. At least one smart contract includes program instructions for inputting and checking a shipment record during the delivery of goods from a goods sender to a goods receiver. The record includes:

[0230] receiving, by the second DLT node, a shipment record from a sender of the goods via the first network, wherein the shipment record comprises one or more first sensor values ​​of one or more physical properties of the shipped goods according to the second specification, the first sensor values ​​being detected by means of one or more first physical sensors assigned to the sender of the goods, wherein the one or more first sensor values ​​comprise at least one first sensor value quantifying a quantity of the delivered goods,

[0231] checking, using at least one smart contract, whether one or more first sensor values ​​of the shipment record correspond within a predetermined first tolerance to one or more physical properties of the goods to be delivered according to the shared data set, wherein the checked first sensor values ​​include at least a first sensor value quantifying the amount of the goods delivered,

[0232] updating the second data set for a third time by the second DLT node using the second check result of the one or more first sensor values ​​of the check shipment record,

[0233] transmitting at least one second update message from the second DLT node to the first DLT node,

[0234] Updating the first data set a second time by the first DLT node using a second update message.

[0235] Other embodiments include a DLT system further configured to implement verification of the delivery of goods in the DLT system. At least one smart contract includes program instructions for verifying the delivery of goods. Verification includes:

[0236] checking, by a second DLT node, parameters of a verification message for verifying the delivery of goods using at least one smart contract, wherein the parameters include at least one quantity of goods to be verified, wherein the checking of the parameters includes checking whether the quantity of goods to be verified corresponds within a predetermined second tolerance to a first sensor value quantifying the delivered quantity of goods,

[0237] updating the second data set for a fourth time by the second DLT node when the quantity of goods to be verified corresponds to the first sensor value quantifying the delivered quantity of goods within a predetermined second tolerance, wherein the fourth updating comprises registering a verification message in the second data set by the second DLT node using at least one smart contract,

[0238] transmitting at least one third update message from the second DLT node to the first DLT node,

[0239] Updating the first data set for a third time by the first DLT node using a third update message, wherein the third updating of the first data set comprises registering the verification message in the first data set.

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

[0241] Other embodiments include a computer program for monitoring the delivery of goods from a goods sender to a goods recipient using a limited-access DLT system, the DLT system comprising a first DLT node assigned to the goods recipient and a second DLT node assigned to the goods sender. The computer program provides at least one smart contract. The at least one smart contract includes program instructions for entering and checking delivery orders and order confirmations.

[0242] The computer program includes program instructions for initiating the delivery of goods in the DLT system. The initialization includes:

[0243] receiving, by the first DLT node via the first network, a delivery order from a goods recipient for goods to be delivered from a goods sender to the goods recipient, wherein the delivery order identifies one or more physical characteristics of the goods to be delivered as a first specification, wherein the physical characteristics of the first specification include at least one quantity of the goods to be delivered,

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

[0245] transmitting at least the first data set from the first DLT node to the second DLT node,

[0246] creating a second data set managed by a second DLT node, wherein the second data set is a second portion of the shared data set, and updating the second data set for a first time based on the first data set by the second DLT node, wherein the first updating includes inputting at least one or more of the physical characteristics of the first specification into the second data set, wherein the at least one or more input physical characteristics of the first specification include the quantity of goods to be delivered,

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

[0248] checking whether the second specification complies with the first specification using at least one smart contract,

[0249] updating the second data set a second time by the second DLT node using the result of the first check of the second specification,

[0250] transmitting at least one first update message from the second DLT node to the first DLT node,

[0251] • Updating the first data set for the first time by the first DLT node using a first update message.

[0252] Other embodiments include a computer program that further includes program instructions for recording a delivery of goods in a DLT system. At least one smart contract includes program instructions for entering and checking a shipment record during the delivery of goods from a goods sender to a goods receiver. The record includes:

[0253] receiving, by the second DLT node, a shipment record from a sender of the goods via the first network, wherein the shipment record comprises one or more first sensor values ​​of one or more physical properties of the shipped goods according to the second specification, the first sensor values ​​being detected by means of one or more first physical sensors assigned to the sender of the goods, wherein the one or more first sensor values ​​comprise at least one first sensor value quantifying a quantity of the delivered goods,

[0254] checking, using at least one smart contract, whether one or more first sensor values ​​of the shipment record correspond within a predetermined first tolerance to one or more physical properties of the goods to be delivered according to the shared data set, wherein the checked first sensor values ​​include at least a first sensor value quantifying the amount of the goods delivered,

[0255] updating the second data set for a third time by the second DLT node using the second check result of the one or more first sensor values ​​of the check shipment record,

[0256] transmitting at least one second update message from the second DLT node to the first DLT node,

[0257] Updating the first data set a second time by the first DLT node using a second update message.

[0258] Other embodiments include a computer program further comprising program instructions for verifying delivery of goods in a DLT system. At least one smart contract includes program instructions for verifying delivery of goods. Verification includes:

[0259] checking, by a second DLT node, parameters of a verification message for verifying the delivery of goods using at least one smart contract, wherein the parameters include at least one quantity of goods to be verified, wherein the checking of the parameters includes checking whether the quantity of goods to be verified corresponds within a predetermined second tolerance to a first sensor value quantifying the delivered quantity of goods,

[0260] updating the second data set for a fourth time by the second DLT node when the quantity of goods to be verified corresponds to the first sensor value quantifying the delivered quantity of goods within a predetermined second tolerance, wherein the fourth updating comprises registering a verification message in the second data set by the second DLT node using at least one smart contract,

[0261] transmitting at least one third update message from the second DLT node to the first DLT node,

[0262] Updating the first data set for a third time by the first DLT node using a third update message, wherein the third updating of the first data set comprises registering the verification message in the first data set.

[0263] For example, the computer program is configured to implement one or more of the aforementioned exemplary embodiments of the method for computer-implemented monitoring of cargo delivery. For example, the computer program is configured to implement each of the aforementioned exemplary embodiments of the method for computer-implemented monitoring of cargo delivery.

[0264] In other embodiments, a computer-readable data carrier or a computer-readable medium is defined, on which program instructions are stored, which, when implemented by at least one processor (or at least one electronic device), configure at least one processor (or at least one electronic device) to implement a method according to one of the above-mentioned embodiments. The program instructions may correspond here to the program instructions of a computer program according to an embodiment. It should be understood that multiple data carriers or media may also be provided, which are configured on separate processors or electronic devices for implementing the provided method. BRIEF DESCRIPTION OF THE DRAWINGS

[0265] In the following, embodiments of the present invention are explained in more detail with reference to the accompanying drawings. In the accompanying drawings:

[0266] Figure 1A A schematic flow chart showing a first portion of an exemplary method for monitoring delivery of goods,

[0267] FIG. 1B shows a schematic flow chart of a second part of an exemplary method for monitoring cargo delivery,

[0268] Figure 2 is a schematic flow chart for recording the delivery of goods using an incoming goods record.

[0269] Figure 3 A schematic block diagram of an exemplary DLT system for computer-implemented monitoring of cargo delivery is shown,

[0270] Figure 4 A schematic flow chart of an exemplary method for computer-implemented monitoring of cargo delivery is shown,

[0271] Figure 5 A schematic flow chart of an exemplary method for computer-implemented monitoring of cargo delivery is shown,

[0272] Figure 6 A schematic flow chart of an exemplary method for computer-implemented monitoring of cargo delivery is shown,

[0273] Figure 7 A schematic block diagram of an exemplary system for computer-implemented monitoring of a delivery of goods including an electronic payment transaction is shown,

[0274] Fig. 8A showing a first portion of a first exemplary graphical user interface,

[0275] FIG8B shows a second portion of the first exemplary graphical user interface, and

[0276] Fig. 9 A second exemplary graphical user interface is shown.

[0277] Elements of the following embodiments that correspond to each other are marked with the same reference numerals. DETAILED DESCRIPTION

[0278] Figure 1A1B shows an exemplary method for computer-implemented monitoring of the delivery of goods from a goods sender to a goods recipient using a limited-access DLT system. The DLT system includes a first DLT node assigned to the goods recipient and a second DLT node assigned to the goods sender. In addition, the DLT system provides at least one smart contract including program instructions for entering and checking delivery orders, order confirmations and / or shipping records during the delivery of goods from the goods sender to the goods recipient and / or for verifying the delivery of goods.

[0279] The method includes initializing delivery of goods in the DLT system, recording delivery of goods in the DLT system, and verifying delivery of goods in the DLT system. Figure 1A As shown, the recording and verification are shown in Figure 1B.

[0280] In block 200, a delivery order of a goods recipient is received via a first network by a first DLT node. The delivery order relates to a delivery order of goods to be delivered from a goods sender to a goods recipient. The delivery order identifies one or more physical characteristics of the goods to be delivered as a first specification, which includes at least one quantity of goods to be delivered.

[0281] In box 202, a first data set managed by a first DLT node is created, for example due to receipt of a delivery order. The first data set relates to a first sub-data set of a shared data set. The corresponding shared data set relates to a data set comprising a first sub-data set on the first DLT node and a second sub-data set on the second DLT node. Only the first DLT node and thus also the recipient of the goods have the authorization to edit the first sub-data set, i.e., the write authorization, while for the second data set, only the second DLT node and thus also the sender of the goods have the authorization to edit, i.e., the write authorization. In addition, due to the access restrictions of the DLT system, for example, only the recipient of the goods also has the read authorization to read the first sub-data set via the first DLT node, while only the sender of the goods has the read authorization to read the second sub-data set via the second DLT node.

[0282] In the process of creating the first data set, at least one or more physical characteristics of the delivery order are further input into the first data set through the first DLT node using at least one smart contract. The input one or more physical characteristics include at least one quantity of goods to be delivered.

[0283] In block 204, the first data set or one or more physical characteristics entered in the first data set is transmitted to a second DLT node of the sender of the goods according to the first specification of the delivery order. In block 206, the second DLT node creates a second sub-data set of the shared data set, in which one or more physical characteristics are entered according to the first specification. Here, the one or more physical characteristics entered include at least one quantity of goods to be delivered according to the first specification. As a result, the two sub-data sets of the shared data set thus include, for example, the same data, as long as an agreement is reached between the sender of the goods and the receiver of the goods on the various parameters of the specification, as described below.

[0284] In block 208, the second DLT node receives an order confirmation from the sender of the goods via the first network, the order confirmation including a second specification of one or more physical characteristics of the goods to be delivered. Upon receiving the order confirmation, in block 210, the second specification is checked by the second DLT node using at least one smart contract to see if it complies with the first specification, and in block 212, the second data set is updated using the result of checking the second specification.

[0285] When the second specification matches the first specification, updating the second data set using the inspection result includes, for example, inputting a confirmation of the first specification. For example, updating the second data set using the inspection result includes inputting the second specification supplementing the first specification into the second data set.

[0286] When the second specification is different from the first specification, updating the second data set using the inspection result includes, for example, replacing or updating the physical characteristics according to the first specification by different physical characteristics according to the second specification. For example, in the process of updating the second data set, different physical characteristics according to the second specification in addition to the first specification are input into the second data set. For example, the second specification that supplements the first specification is input into the second data set.

[0287] In addition, 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 complies with the first specification. If one or more physical characteristics according to the second specification are different from the first specification, the first update message, for example, identifies the different one or more physical characteristics according to the second specification. For example, the first update message includes the entire second specification or a copy of the second specification.

[0288] In block 216, the first DLT node updates the first dataset, i.e., the first subset of the shared dataset, using the first update message. When the second specification is consistent with the first specification, updating the first dataset using the first update message includes, for example, inputting a confirmation of the first specification. For example, updating the first dataset using the first update message includes inputting the second specification that supplements the first specification into the first dataset.

[0289] When the second specification is different from the first specification, updating the first data set using the first update message includes, for example, replacing or updating the physical characteristics according to the first specification by different physical characteristics according to the second specification. For example, in the process of updating the first data set, different physical characteristics according to the second specification in addition to the first specification are input into the second data set. For example, the second specification that supplements the first specification is input into the second data set.

[0290] If the second specification is different from the first specification, a handshake is performed, for example, between the first DLT node and the second DLT node to align the first specification and the second specification so that the first specification and the second specification resulting from the alignment match.

[0291] If the second specification is consistent with the first specification, a confirmation message is transmitted from the second DLT node to the sender of the goods, for example via the network. For example, the second specification is considered to be consistent with the first specification when it is consistent. If there is no difference beyond a predetermined tolerance range, for example, the second specification is consistent with the first specification. The confirmation message, for example, shows the sender of the goods that an agreement has been reached between the receiver of the goods and the sender of the goods on the corresponding delivery of the goods. In addition, the confirmation message, for example, includes the specifications of the delivery of the corresponding goods. For example, the corresponding confirmation message is used as a trigger to initiate the corresponding delivery of the goods.

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

[0293] Figure 1AThe method is preferably continued in FIG. 1B , wherein the delivery of goods is recorded in the DLT system. If a physical delivery of goods is implemented, i.e., if the goods to be delivered leave the warehouse of the goods sender, a shipping record is created. The corresponding shipping record includes one or more sensor values ​​for one or more physical properties of the shipped goods according to the second specification, which are detected by means of one or more physical sensors assigned to the goods sender. Therefore, the shipping record indicates measured values ​​for one or more physical properties, respectively detected by sensor technology, for which target values ​​are indicated in the second specification, and these measured values ​​reflect the actual condition of the shipped goods in terms of the corresponding physical properties. The corresponding sensor values ​​here include at least one sensor value that quantifies the amount of delivered, i.e., shipped goods.

[0294] In box 220, the second DLT node of the goods sender receives the shipping record from the goods sender via the first network, and checks in box 222 whether one or more first sensor values ​​of the shipping record are consistent with one or more physical characteristics of the goods to be delivered. It is checked here whether one or more sensor values ​​of the shipping record are consistent with one or more physical characteristics according to the shared data set within a predetermined tolerance. If such consistency is not achieved, a warning prompt is transmitted to the goods sender and / or the goods recipient, for example. Such a warning prompt can, for example, trigger a subsequent delivery on the part of the goods sender when the delivery amount is too small. On the part of the goods recipient, such a warning prompt can, for example, trigger a check of different physical characteristics when the goods arrive. For example, such a warning prompt may require confirmation of different physical characteristics on the part of the goods recipient in order to successfully complete the final verification of the delivery of the goods.

[0295] In block 224, the second data set is updated by the second DLT node using the result of checking the one or more first sensor values ​​of the shipping record. For example, the update includes inputting the shipping record and / or one or more of the sensor values ​​indicated by the shipping record. For example, all sensor values ​​indicated by the shipping record are input. For example, only such sensor values ​​that are different from the values ​​entered in the second data set for the physical characteristics of the goods to be delivered are input. For example, for the sensor values ​​of the shipping record that match the values ​​entered in the second data set for the physical characteristics of the goods to be delivered, only a confirmation that the corresponding value for the physical characteristic matches the detected sensor value is entered in the second data set.

[0296] In block 226, a second update message is transmitted from the second DLT node to the first DLT node. The second update message, for example, includes one or more of the shipping record and / or the sensor values ​​indicated by the shipping record. For example, the second update message includes all sensor values ​​indicated by the shipping record. For example, the second update message only includes such sensor values ​​that are different from the values ​​of the physical characteristics of the goods to be delivered entered in the second data set. For example, for sensor values ​​of the shipping record that match the values ​​of the physical characteristics of the goods to be delivered entered in the second data set, the second update message only includes a confirmation that the corresponding values ​​of the physical characteristics according to the shared data set match the detected sensor values.

[0297] In block 228, the first DLT node updates the first dataset, i.e., the first sub-dataset of the shared dataset, using the second update message. For example, the update includes inputting one or more of the shipping record and / or the sensor values ​​indicated by the shipping record. For example, all sensor values ​​indicated in the shipping record are input. For example, only such sensor values ​​that are different from the values ​​entered in the first dataset for the physical characteristics of the goods to be delivered are input. For sensor values ​​of the shipping record that match the values ​​entered in the first dataset for the physical characteristics of the goods to be delivered, only a confirmation that the corresponding value for the physical characteristic matches the detected sensor value is entered in the first dataset.

[0298] Finally, verification of the delivery of goods is implemented in the DLT system. To this end, in box 240, the parameters of the verification message for verifying the delivery of goods are checked by the second DLT node. The checked parameters of the verification message include at least one indication of the amount of goods delivered to be verified. Checking the corresponding parameters includes checking whether the amount of goods to be verified is consistent with the sensor value of the quantitative amount of goods delivered according to the shipment record within a predetermined tolerance. When the amount of goods to be verified is consistent with the sensor value of the quantitative amount of goods delivered within a predetermined tolerance, the second data set is updated by the second DLT node in box 242 using the verification message. The update includes registering the verification message in the second data set by the second DLT node. For example, during the registration process, an identifier of the verification message is entered into the second data set. For example, a check value of the verification message, such as a hash value, is entered into the second data set. For example, one or more parameters of the verification message are entered into the second data set. For example, the verification message is entered into the second data set.

[0299] For example, verification is triggered by receiving a verification message or by generating a verification message. For example, generation of a verification message is triggered by receiving a receipt confirmation of delivered goods from a goods recipient. For example, a receipt confirmation is received in the form of an incoming goods record.

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

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

[0302] Each of steps 220 to 246 of the method according to FIG. 1B may be optional. In addition, steps 220 to 246 may be arbitrarily combined with steps 220 to 246 of the method according to FIG. Figure 1A One or more of steps 200 to 216 may be combined in any order.

[0303] Figure 2 An exemplary record of a cargo delivery using a cargo entry record is shown. To this end, the program instructions included in at least one smart contract are also configured to input and check the cargo entry record during the cargo delivery process from the cargo sender to the cargo receiver.

[0304] If a physical delivery of goods is accepted by the goods recipient, i.e., if the goods to be delivered arrive at the warehouse of the goods recipient, an incoming goods record is created. The corresponding incoming goods record includes one or more sensor values ​​for one or more physical properties of the incoming goods according to the first specification, which are detected by means of one or more physical sensors assigned to the goods recipient. Therefore, the incoming goods record indicates, for one or more physical properties, respectively, measured values ​​detected by sensor technology (target values ​​are indicated for the physical properties in the first specification), which reflect the actual condition of the incoming goods in terms of the corresponding physical properties. The corresponding sensor values ​​here include at least one sensor value that quantifies the amount of delivered, i.e., incoming goods.

[0305] In this case, box 230 includes recording the delivery of goods in the DLT system according to Figure 1B. In box 230, the first DLT node receives an incoming shipment record from the goods recipient via the first network. In addition, the first DLT node checks whether one or more second sensor values ​​of the incoming shipment record are consistent with one or more physical characteristics of the goods to be delivered. It is checked here whether one or more sensor values ​​of the incoming shipment record are consistent with one or more physical characteristics according to the shared data set within a predetermined tolerance. If such consistency is not achieved, a warning prompt is transmitted to the goods recipient and / or the goods sender, for example. Such a warning prompt can, for example, trigger a subsequent delivery from the goods sender when the delivery volume is too small. On the goods recipient side, for example, such a warning prompt may require confirmation of different physical characteristics on the part of the goods recipient in order to successfully complete the final verification of the delivery of the goods.

[0306] In block 232, the first data set is updated by the first DLT node using the result of checking the one or more first sensor values ​​of the incoming shipment record. For example, the update includes inputting the incoming shipment record and / or one or more of the sensor values ​​indicated by the incoming shipment record. For example, all sensor values ​​indicated by the incoming shipment record are input. For example, only such sensor values ​​that are different from the values ​​entered in the first data set for the physical characteristic of the goods to be delivered are input. For example, for sensor values ​​of the incoming shipment record that match the values ​​entered in the first data set for the physical characteristic of the goods to be delivered, only a confirmation that the corresponding value for the physical characteristic matches the detected sensor value is entered in the second data set.

[0307] In addition, in block 234, a fourth update message is transmitted from the first DLT node to the second DLT node. The fourth update message, for example, includes one or more of the incoming shipment record and / or the sensor values ​​indicated by the incoming shipment record. For example, the fourth update message includes all sensor values ​​indicated by the incoming shipment record. For example, the fourth update message only includes such sensor values ​​that are different from the values ​​of the physical characteristics of the goods to be delivered entered in the first data set. For example, for sensor values ​​of the incoming shipment record that match the values ​​of the physical characteristics of the goods to be delivered entered in the first data set, the fourth update message only includes a confirmation that the corresponding values ​​of the physical characteristics according to the shared data set match the detected sensor values.

[0308] Finally, in box 236, the second DLT node updates the second dataset, i.e., the second subset of the shared dataset, using the fourth update message. For example, the update includes inputting one or more of the incoming shipment record and / or the sensor values ​​indicated by the incoming shipment record. For example, all sensor values ​​indicated in the incoming shipment record are input. For example, only such sensor values ​​that are different from the values ​​entered in the second dataset for the physical characteristics of the goods to be delivered are input. For sensor values ​​of the incoming shipment record that match the values ​​entered in the second dataset for the physical characteristics of the goods to be delivered, only a confirmation that the corresponding value for the physical characteristic matches the detected sensor value is entered in the second dataset.

[0309] according to Figure 2 Each of steps 230 to 236 of the method may be optional. In addition, steps 230 to 236 may be arbitrarily combined with the steps according to Figure 1A One or more of steps 200 to 216 of FIG. 1B or one or more of steps 220 to 246 according to FIG. 1B may be combined in any order.

[0310] Figure 3 An exemplary DLT system 182 for computer-implemented monitoring of the delivery of goods from a goods sender to a goods recipient is shown. The DLT system 182 includes a plurality of DLT servers 140, 160. Here, the DLT system 182 includes a first DLT node assigned to the goods recipient, which node is provided by the first DLT server 140 of the DLT system 182. In addition, the DLT system 182 includes a second DLT node assigned to the goods sender, which node is provided by the second DLT server 160 of the DLT system 182. However, it should be understood that the DLT node may also be provided on a single DLT server, such as the DLT server 140 or the DLT server 160, and the present description is not limited to the provision of the DLT node on a separate DLT server.

[0311] The first DLT server 140 includes a processor 142 configured to execute program instructions 144. The first DLT node of the cargo recipient is implemented on the first DLT server 140 by the program instructions 144. Here, the program instructions 144 implement one or more smart contracts for implementation by the first DLT node on the first DLT server 140. The program instructions 144 for implementing one or more smart contracts include instructions for implementing a method, for example, according to Figure 1A1B or a portion thereof, to computer-implement monitoring of the delivery of goods from a goods sender to a goods recipient using a limited-access DLT system 182. The method may include, in any combination, entering and checking delivery orders, order confirmations and / or shipping records and / or verifying the delivery of goods during the delivery of goods from the goods sender to the goods recipient.

[0312] 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, for example, with the computer system 120 of the goods recipient via a network 184. The network 184 is, for example, the Internet. Furthermore, the communication interface 156 is used, for example, to communicate with other DLT servers of the DLT system via the DLT network 180, such as 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.

[0313] For example, a private encryption key 154 of an asymmetric key pair assigned to a first DLT node of a goods recipient is stored in a protected memory area 152 of a memory 146 of a first DLT server 140. The private encryption key 154 is used, for example, as a signature key for creating an electronic signature of the first DLT node. The corresponding signature can be checked with a public encryption key 150 of the corresponding asymmetric key pair. For example, the public encryption key 150 is provided as a component of a certificate. The first DLT node of the goods recipient uses the public encryption key 150 or a certificate including the public encryption key 150 as a signature check key for other DLT nodes of the goods sender, such as a second DLT node.

[0314] The second DLT server 160 includes a processor 162 configured to implement program instructions 164. The second DLT node of the sender of the goods is implemented on the second DLT server 160 by the program instructions 164. Here, the program instructions 164 also implement one or more smart contracts for implementation by the second DLT node on the second DLT server 160. The smart contract on the second DLT node can correspond to the smart contract on the first DLT node, thereby ensuring that both DLT nodes define corresponding behaviors. The program instructions 164 for implementing one or more smart contracts include instructions for implementing methods, such as according to Figure 1A1B or a portion thereof, to computer-implement monitoring of the delivery of goods from a goods sender to a goods recipient using a limited-access DLT system 182. The method may include, in any combination, entering and checking delivery orders, order confirmations and / or shipping records and / or verifying the delivery of goods during the delivery of goods from the goods sender to the goods recipient.

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

[0316] For example, a private encryption key 174 of an asymmetric key pair assigned to a second DLT node of the sender of the goods is stored in a protected memory area 172 of the memory 166 of the second DLT server 160. The private encryption key 174 is used, for example, as a signature key for creating an electronic signature of the second DLT node. The corresponding signature can be checked with the public encryption key 170 of the corresponding asymmetric key pair. For example, the public encryption key 170 is provided as a component of a certificate. The first DLT node of the sender of the goods uses the public encryption key 170 or a certificate including the public encryption key 170 as a signature check key for other DLT nodes of the receiver of the goods, such as the first DLT node.

[0317] In the process of initializing the delivery of goods, a shared data set is generated on the two DLT nodes, which includes a first sub-data set 148 on the first DLT node and a second sub-data set 168 on the second DLT node. The first sub-data set 148 is stored in the memory 146 of the first DLT server 140. The second sub-data set 168 is stored in the memory 166 of the second DLT server 160.

[0318] Only the first DLT node and therefore also the goods recipient has the authorization to edit the first sub-data set, i.e., the write authorization, while for the second data set, only the second DLT node and therefore also the goods sender has the authorization to edit, i.e., the write authorization. In addition, due to the access restrictions of the DLT system, for example, only the goods recipient has the read authorization to read the first sub-data set via the first DLT node implemented on the first DLT server 140, while only the goods sender has the read authorization to read the second sub-data set via the second DLT node implemented on the second DLT server 160.

[0319] Execution of the program instructions 144 by the processor 142 causes the processor 142 to control the first DLT server 140 in such a manner that the first DLT node implemented on the first DLT server 140 receives a delivery order for goods to be delivered from the goods sender to the goods recipient from the goods recipient during the process of initializing the delivery of goods in the DLT system 182. The first DLT node receives the delivery order from the computer system 120 of the goods recipient, for example, via the network 184. The delivery order determines one or more physical characteristics of the goods to be delivered as a first specification. Here, the physical characteristics of the first specification include at least one quantity of goods to be delivered.

[0320] The computer system 120 of the goods recipient includes a processor 130 configured to implement program instructions 132. The computer system 120 is caused to communicate with the first DLT server 140 or a first DLT node of the goods recipient implemented on the first DLT server 140, for example, via the network 184 by the program instructions 132. For example, the computer system 120 of the goods recipient sends the delivery order to the first DLT node. For this purpose, the computer system 120 includes a communication interface 136 for communicating via the network 184.

[0321] Furthermore, the computer system 120 has a memory 122. For example, a private encryption key 128 of an asymmetric key pair assigned to a recipient of the goods is stored in a protected memory area 126 of the memory 122 of the computer system 120. This private encryption key 128 is used, for example, as a signature key for creating an electronic signature of the recipient of the goods. The corresponding signature can be checked with a public encryption key 124 of the corresponding asymmetric key pair. For example, the public encryption key 124 is provided as a component of a certificate. The computer system 120 uses this public encryption key 124 or a certificate including the public encryption key 124 as a signature check key for other participants, such as a first DLT node implemented on a first DLT server 140 of the recipient of the goods.

[0322] The first node creates a data set 148 that is managed by the DLT node, and uses at least one smart contract to input at least one or more physical characteristics of the delivery order into the first data set 148.

[0323] Furthermore, at least the first data set 148 is sent from the first DLT node or the first DLT server 140 to a second DLT node implemented on the second DLT server 160 via the DLT network 180. The first DLT node receives at least one first update message regarding the 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 is performed using a first check result of checking whether the second specification according to the order confirmation of the goods sender of one or more physical characteristics of the goods to be delivered is consistent with the first specification according to the delivery order of the goods recipient. The first data set 148 is then updated by the first DLT node using the first update message.

[0324] The second DLT server 160 receives the corresponding order confirmation from the computer system 100 of the goods sender, for example, via the network 184. The computer system 160 of the goods recipient includes a processor 110 configured to implement program instructions 112. The computer system 100 is caused by the program instructions 112 to communicate with the second DLT server 160 or a second DLT node implemented on the second DLT server 160 of the goods sender, for example, via the network 184. 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 includes a communication interface 116 for communicating via the network 184.

[0325] Furthermore, the computer system 100 has a memory 102. For example, a private encryption key 108 of an asymmetric key pair assigned to a goods recipient is stored in a protected memory area 106 of the memory 102 of the computer system 100. This private encryption key 108 is used, for example, as a signature key for creating an electronic signature of the goods sender. The corresponding signature can be checked with a public encryption key 104 of the corresponding asymmetric key pair. For example, the public encryption key 104 is provided as a component of a certificate. The computer system 100 uses this public encryption key 104 or a certificate including the public encryption key 104 as a signature check key for other participants, such as a second DLT node implemented on a second DLT server 160 of the goods sender.

[0326] In addition, the program instructions are implemented by the processor 142 so that the processor 142 controls the first DLT node in the following manner, that is, the DLT node receives at least one second update message from the second DLT node via the update of the second data set 168 during the process of recording the delivery of goods in the DLT system 182. The second update is an update under the condition of using the second check result of checking whether one or more first sensor values ​​of the shipping record are consistent with one or more physical characteristics of the goods to be delivered according to the shared data set within a predetermined first tolerance. The one or more first sensor values ​​of the shipping record are detected by means of one or more physical sensors 113 assigned to the sender of the goods. Here, the first sensor value checked includes at least a first sensor value that quantifies the amount of goods delivered. Then, the first data set 148 is updated by the DLT node under the condition of using the second update message.

[0327] Finally, the execution of the program instructions 144 by the processor 142 causes the processor 142 to control the first DLT node in such a way that the first DLT node receives at least one third update message from the second DLT node via the updating of the second data set 168 using the verification message during the verification of the delivery of goods in the DLT system 182. Updating the second data set 168 using the verification message includes registering the verification message in the second data set 168. Here, the updating of the second data set 168 using the verification message confirms the successful checking of the parameters of the verification message by the second DLT node. These parameters include at least one quantity of goods to be verified. Here, the checking of the parameters includes checking whether the quantity of goods to be verified corresponds to the first sensor value quantifying the quantity of goods delivered within a predetermined second tolerance. Finally, the first DLT node updates the first data set 148 by the DLT node using the third update message. Updating the first data set 148 here includes registering the verification message in the first data set 148.

[0328] The program instructions 164 are implemented by the processor 162 so that the processor 162 controls the second DLT server 160 in the following manner, that is, during the process of initializing the delivery of goods in the DLT system 182, the second DLT node implemented on the second DLT server 160 receives 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 characteristics of the goods to be delivered according to the first specification of the delivery order. Then, the second DLT node creates a second data set 168 managed by the DLT node. In addition, the second DLT node updates the created second data set 168. The update includes inputting at least one or more physical characteristics of the first specification into the second data set 168, and the at least one or more input physical characteristics of the first specification include the quantity of goods to be delivered.

[0329] In addition, the second DLT node receives an order confirmation from the goods sender from the computer system 100 of the goods sender via the network 184. The order confirmation includes a second specification of one or more physical characteristics of the goods to be delivered. The second DLT node checks whether the second specification is consistent with the first specification using one or more smart contracts, and updates the second data set 168 using the obtained check results. Finally, the second DLT node transmits at least a first update message to the first DLT node to update the first data set 148.

[0330] Execution of the program instructions 164 by the processor 162 further causes the processor 162 to control the second DLT node in the following manner, that is, the second DLT node receives a shipment record from the sender of the goods via the first network 184 during the process of recording the delivery of the goods in the DLT system 182. For example, the second DLT node receives the shipment record from the computer system 100 of the sender of the goods. The shipment record includes one or more first sensor values ​​of one or more physical properties of the goods for the shipment according to the second specification, and the sensor values ​​are detected by means of one or more physical sensors 114 assigned to the sender of the goods.

[0331] The second DLT node checks whether one or more first sensor values ​​of the shipment record match one or more physical characteristics of the goods to be delivered according to the shared data set or the second sub-data set 168 of the shared data set within a predetermined first tolerance. To this end, the second DLT node uses one of the one or more smart contracts. The checked first sensor values ​​here at least include first sensor values ​​quantifying the amount of goods delivered. The second data set 168 is updated by the second DLT node using the check result. In addition, the second DLT node transmits at least a second update message to the first DLT node to update the first data set 148.

[0332] Finally, the execution of the program instructions 164 by the processor 162 causes the processor 162 to control the second DLT node in such a way that the second DLT node checks the parameters of the verification message during the verification of the delivery of goods in the DLT system 182 to verify the delivery of goods using one or more smart contracts. The checked parameters include at least the quantity of goods to be verified. Checking the parameters here includes checking whether the quantity of goods to be verified matches the first sensor value quantifying the quantity of goods delivered within a predetermined tolerance. When the quantity of goods to be verified matches the first sensor value quantifying the quantity of goods delivered within a predetermined tolerance, the second DLT node updates the second data set 168. The updating includes registering the verification message in the second data set 168 by the second DLT node using at least one of the one or more smart contracts. In addition, the second DLT node transmits a corresponding update message for registering the verification message to the first DLT node to update the first data set 148.

[0333] According to an alternative embodiment, the first DLT node and the second DLT node may also be implemented on a public DLT server of the DLT system 180. According to an alternative embodiment, for example, the first DLT node may also be implemented on the computer system 120 of the goods receiver and / or the second DLT node may be implemented on the computer system 100 of the goods sender.

[0334] Figure 4 A schematic flow chart of an exemplary method for computer-implemented monitoring of the delivery of goods from a goods sender to a goods recipient is shown. In step 300, the goods recipient sends a delivery order 190 to a DLT node assigned to the goods recipient in a DLT system 182. In addition to an order number and a product number, the delivery order 190 indicates, for example, the quantity of goods to be delivered as a physical characteristic of the corresponding goods. This sending of the delivery order 190 causes a first sub-dataset of a shared data set to be generated in the DLT system 182 using the delivery order 190. The data of the delivery order 190 are also transmitted to the goods sender. At this stage, the status of the goods delivery is "proposed". In step 302, the goods sender sends an order confirmation 191 to a DLT node assigned to the goods sender in a DLT system 182. In addition to an order number and a product number, the order confirmation 191 indicates, for example, the quantity of goods to be delivered as a physical characteristic of the corresponding goods. The confirmation is, for example, entered in the DLT system 182 into a second sub-dataset of the shared data set on the DLT node of the goods sender. If the quantity indicated in the order confirmation 191 matches the quantity indicated in the delivery order 190, the goods delivery assumes the status of "confirmed" in the DLT system 182. In addition, the order confirmation 191 or the updated data of the second sub-data set is transmitted to the goods recipient.

[0335] Additionally, for example, in step 304, the goods recipient can send an update 192 of the delivery order 190 with an indication of the new quantity to the DLT system 182 or to a first DLT node assigned to the goods recipient in the DLT system 182. The first DLT node enters this update of the specifications of the goods delivery, for example, into the first sub-data set, and also transmits it to the goods sender or to a second DLT node assigned to the goods sender. In this case, the status of the goods delivery in the DLT system 182 changes to, for example, "updated". In step 306, the goods sender sends an update 193 of the order confirmation 191 with an indication of the new quantity to the DLT system 182 or to a second DLT node assigned to the goods sender in the DLT system 182. The second DLT node enters this update of the confirmation of the specifications of the goods delivery, for example, into the second sub-data set, and also transmits it to the goods recipient or to the 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" again, for example. If the goods delivery is made, the goods sender sends, for example, a verification message, such as a bill, to the DLT system in step 194 for verification or updating the shared data set using the verification message 194. Verification includes, for example, checking the verification message for indications with the specifications of the goods delivery stored in the shared data set. If these match, the verification message is registered in the shared data set in the DLT system 182. For example, the bill number of the verification message is stored in the shared data set. In this case, the status of the goods delivery in the DLT system 182 becomes, for example, "completed".

[0336] Figure 5 Other schematic flow charts of an exemplary method for computer-implemented monitoring of the delivery of goods from a goods sender to a goods recipient are shown. Here, 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 sub-dataset of a shared data set and updates it with data from the delivery order of the goods recipient. The first sub-dataset is sent to the second DLT node of the goods sender. The second DLT node creates a second sub-dataset of the shared data set with data from the delivery order. At this stage, the status of the goods delivery is "proposed". In step 322, the second DLT node updates the second sub-dataset with data from the order confirmation of the goods sender. In addition, an update message about updating the second sub-dataset in the case of using the order confirmation is sent to the first DLT node of the goods recipient. The first DLT node updates the first sub-dataset accordingly. Subsequently, for example, one or more update steps and / or cancellations may also be performed.

[0337] In step 324, the first DLT node updates the first sub-data set, for example, based on the update of the delivery order. For example, the quantity of the goods to be delivered, the delivery date, the price, etc. are updated. The update is transmitted to the second DLT node. The second DLT node marks the update, for example, in the second sub-data set. The status of the delivery of the goods is thus changed to "updated". In step 326, the second DLT node confirms the proposed update, for example, based on the updated order confirmation, and enters the confirmation into the second sub-data set. The confirmation of the update is transmitted to the first DLT node. The first DLT node marks the confirmation, for example, in the first sub-data set. The status of the delivery of the goods is thus changed back to "confirmed".

[0338] The update of delivery conditions can also come from the sender of the goods. In step 328, the second DLT node updates the second sub-data set, for example, based on the update of the order confirmation. For example, the quantity, delivery date, price, etc. of the goods to be delivered are updated. The update is transmitted to the first DLT node. The first DLT node, for example, marks the update in the first sub-data set. The status of the delivery of the goods is thus changed to "updated". In step 330, the first DLT node confirms the proposed update, for example, based on the updated delivery order, and enters the confirmation into the first sub-data set. The confirmation of the update is transmitted to the second DLT node. The second DLT node, for example, marks the confirmation in the second sub-data set. The status of the delivery of the goods is thus changed back to "confirmed".

[0339] The delivery of goods may also be canceled from the side of the goods sender or the goods receiver. In step 332, the first DLT node or the second DLT node enters the cancellation into the first sub-data set or the second sub-data set, for example based on the received cancellation notice. In addition, the cancellation message is transmitted to the second DLT node or the first DLT node. The second DLT node or the first DLT node marks the corresponding cancellation in the second sub-data set or the first sub-data set. In this case, the status of the delivery of goods becomes "canceled" and the method ends.

[0340] If no cancellation has occurred, the second DLT node updates the second subdata set in step 334, for example in the case of a completed goods delivery, based on the check of the verification message. If the check is successful, the verification message is registered in the second subdata set, for example an identifier of the verification message, such as a bill number, is entered in the second subdata set. The update is transmitted to the first DLT node. The first DLT node marks the update, for example by also registering the verification message in the first subdata set. The status of the goods delivery thus becomes "completed".

[0341] according to Figure 5 The first DLT node and the second DLT node can both have a DLT server 140 and a DLT server 160 implemented according to Figure 3One or more characteristics of a DLT node. In addition, Figure 5 The DLT node may be configured to, at least in part, implement Figure 1A and / or the method of Figure 1B or portions thereof.

[0342] Figure 6 A further schematic flow chart of an exemplary method for computer-implemented monitoring of the delivery of goods from a goods sender to a goods recipient using a DLT system 182 is shown. In step 350, the goods recipient or the goods recipient's computer system 120 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 the goods sender's computer system 100 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, the conditions for the delivery of the goods are entered into two sub-data sets of the shared data set and are aligned with each other in the process of matching the two parties. It can therefore be ensured that the conditions according to the delivery order and the order confirmation are consistent with each other. In the process of implementing the delivery of the goods to be delivered, the goods sender or the goods sender's computer system 100 sends a shipping record to the second DLT node in the DLT system 182 in step 354. The shipping record includes sensor values ​​for physical properties of the goods shipped, which are detected by means of physical sensors of the goods sender, and includes at least one sensor value quantifying the amount of goods delivered. In addition, in step 356, the goods sender or the goods sender's computer system 100 sends a verification message to the second DLT node in the DLT system 182. Based on the results of the two-party matching, the shipping record and the verification message, it is checked in the three-party matching process whether the status of the actually delivered goods and the conditions according to the two-party matching are consistent with the indication of the verification message. Therefore, it can be ensured that the indication of the verification message is correct. If the verification message is successfully checked, it is registered in the shared data set.

[0343] Figure 7 Another schematic block diagram of an exemplary system for computer-implemented monitoring of a delivery of goods from a goods sender to a goods receiver including an electronic payment transaction is shown. The system may include a DLT system 182, for example, based on Figure 3 or Figure 4 Payment transactions can be linked to data flows from monitoring of goods deliveries and maintained in a closed data loop.

[0344] In order to prepare an electronic payment, a user, such as user A, can remit legal tender, such as euros, to a pool account of a bank that handles payment transactions in step 360. This is done within the banking system or using the bank computer system 186. In step 362, the bank or a DLT node assigned to the bank in the DLT system 182 detects the entry of legal tender, such as via the bank's API or other suitable programming or communication interface of the bank in the DLT system 182. An API (application programming interface) is a programming interface or program part that can be provided by a software system to other programs for linking to a corresponding system. In step 364, the bank automatically allocates E-currency, i.e., electronic currency, to the DLT account of user A. The amount of E-currency credited to the DLT account of user A corresponds to the amount of legal tender remitted. Any user, such as user B, can implement a corresponding method to allocate E-currency to an associated DLT account in the DLT system 182. A DLT account can be set up on the corresponding DLT node of the user in the DLT system 182.

[0345] User A, as the receiver of the goods, can place an order, for example, on an ERP system, from a sender of the goods, for example, user B. In step 366, the order is transmitted, for example, as a delivery order, to the DLT node of user A. The delivery order can have ERP data from the ERP system of the receiver of the goods. To this end, user A can, for example, use a computer system of the receiver of the goods, which can be connected to an associated DLT node in the DLT system 182 via an API or any other programming or communication interface. The DLT node of user A initiates the delivery of the goods, as described above, for example, according to Figure 1A As described in the aspects of the embodiment of . Thus, the order specifications are transmitted to the DLT node of the goods sender, which can transmit the order specifications to the computer system of the goods sender in step 368. For example, user B can confirm the order using the ERP system on the sender's computer system. The order specifications and confirmation can, for example, have ERP data of the ERP system of the goods sender. The computer system of the goods sender can be connected to the associated DLT node in the DLT system 182 via an API or any other programming or communication interface.

[0346] The ordering process is handled by the DLT system 182 between the DLT nodes of the goods sender and the goods receiver using one or more smart contracts, which is shown exemplarily in step 370. For example, one of the exemplary methods described in the previous figures is applied for this purpose to monitor the delivery of goods from the goods sender to the goods receiver using the DLT system 182 with limited access. A handshake that may be required can be performed (semi-)automatically between the participating DLT nodes. If further data is required or parameters must be confirmed, the participating DLT nodes can communicate with the associated computer system of the goods sender or the goods receiver to obtain input content, for example, via the corresponding ERP system, which is then incorporated into the DLT system 182. Correspondingly, the ordering process and the delivery of goods can be implemented via the DLT system 182. The delivery of goods that must be carried out due to requirements outside the DLT system 182 and the sending of bills if necessary can be performed in step 372.

[0347] When a verification message registers the delivery of goods in the DLT system 182, such as by issuing a bill, an electronic payment transaction from the DLT account of user A to the DLT account of user B may be triggered.

[0348] Similar to issuing E-currency on a DLT account in a DLT system, a user, such as user B, can remit at least partially the E-currency obtained in one or more electronic payment transactions for reimbursement in step 374. This can be done via a DLT node assigned to a bank, which can communicate with a bank computer system. In step 376, the bank converts the paid E-currency into legal tender and remits the corresponding legal tender to the account of user B via a pool account. Any user, such as user A, can implement a corresponding method to pay E-currency as legal tender to an associated bank account. It should be understood that the delivery of goods does not necessarily require the withdrawal of E-currency as legal tender. More precisely, the E-currency can remain in the DLT account to perform further electronic payment transactions.

[0349] The DLT system 182 can additionally be configured to record and check all DLT payment transactions in the DLT system 182, such as for the bank's AML (anti-money laundering) reasons, i.e. to prevent money laundering. For example, the bank's anti-money laundering software is used to check the recorded DLT transactions. For example, customer data is analyzed to identify suspicious transactions. To this end, customer data is filtered, classified according to trust level and anomalies are investigated. Once the anti-money laundering software has collected enough data and flagged suspicious processes, for example, a report is generated. In addition, payments can be released or prohibited.

[0350] For example, the DLT system 182 also ensures the regulatory compliance of all payment transactions: for example, in the case of using at least one smart contract, a regulator 378 is implemented, which detects all transactions for compliance purposes. In addition, in the case of using at least one smart contract, for example, a notary (node) 380, also known as a notary node, is implemented, which prevents multiple use or multiple payment of the same unit of E-currency.

[0351] Fig. 8A and Figure 8B and Fig. 9 An exemplary graphical user interface (GUI) is shown for implementing a method for computer-implemented monitoring of a delivery of freight from a freight sender to a freight receiver using a restricted-access DLT system. Fig. 8A A first portion of a first exemplary graphical user interface is shown. Here, Fig. 8A 8B shows a second portion of the first exemplary graphical user interface. Here, FIG. 8B includes an exemplary illustration of data of a second sub-dataset 168 of the shared dataset, which reflects a proposal for changed delivery conditions on the part of the sender of the goods (“seller”).

[0352] Fig. 8A The graphical user interface shown in FIG. 8B includes menus 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, an area with "Reports", and an area with "Settings". The current user is also indicated ("Logged In As"). A selection element for creating a new order is also shown ("Create new order"). Search parameters can also be entered ("Search and filter"). Fig. 8A 8B shows an example of an area with "Orders". The following areas can be selected in the submenu: "Open", "Confirmed", "Paid" and "Rejected". These areas list the orders that are open, confirmed, paid or rejected, respectively. The graphical user interface includes an area for the purchaser ("buyer") of the goods recipient and an area for the "seller" ("seller") of the goods sender.

[0353] Fig. 8A The illustration of the first sub-dataset 148 of the goods recipient in shows what the goods recipient sees, namely the “Buyer-Their View” and indicates, for example: the time point of the last update “Last update”, the status “UPDATED”, the “Transaction ID”, the “Order number”, the “Delivery date”, the “Product ID buyer”, the “Product name buyer”, the “Product ID seller”, the “Product name seller”, the “Line Item ID”, the “Settlement (In days)” indication (“Settlement (In days)”), the “Invoice number”, the “Invoice date”, the “Tax ID”, the “Tax” indication (“Tax”), the “Description”, the “Update reason”, the “Reason for the update ... In addition, a selection element "Accept all" is provided for the goods sender to accept all instructions or regulations according to the first sub-data set 148 of the goods receiver.

[0354] The illustration of the second sub-dataset 168 of the goods sender in FIG8B shows that if the user logs in as the goods sender, the content that the goods sender sees, namely, “Seller-My View”, and indicates, for example: the time point of the last update “Last update”, the status “UPDATED”, the “Transaction ID”, the “Order number”, the “Delivery date”, the “Product ID buyer”, the “Product name Buyer”, the “Product ID seller”, the “Product name seller”, the “Line Item ID”, the “Settlement (In days)” indication, the “Invoice number”, the “Invoice date”, the “Tax ID”, the “Tax” indication (“Tax”), the “Description”, the “Update reason”, the “Reason for the update”, the “Description”, the “Reason for the update ... The indications include “reason”, “quantity”, “units”, “price per unit”, “unit of price per Unit”, “total price”, and “currency”. These indications can be changed by the sender of the goods except for the indication about the time point of the last update “Last update”, the status “UPDATED”, the “Transaction ID”, the “Order number”, the “Product ID buyer”, and the “Product name Buyer”. In addition, the selection elements “Cancel”, “Send” and “Confirm” are provided for canceling, sending or confirming the indication or the update of the indication.

[0355] Fig. 9 An exemplary dashboard of a goods sender's DLT node is shown with an overview of current orders and payments. Fig. 9The graphical user interface shown includes menus for selecting different 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, an area with "Reports" and an area with "Settings". There is also an "Logged In As" indicating who is currently logged in. Fig. 9 An example of a "dashboard" is shown. The dashboard includes indications for "Cash available now", "Cash available tomorrow", and "Cash available the day after tomorrow". The dashboard also includes lists of "Overview", "Most recent orders", "Most recent updates", and "Paid on time". The "Overview" includes a graphical representation, for example in the form of a histogram, of various indications for the "Today" period. The indications include "Wallet saldo", an indication of incoming payments "Incoming", an indication of outgoing payments "Outgoing", and an indication of rejected payment or delivery orders "Rejected". The list "Most recent orders" lists current orders and indicates, for example, how many current orders that are not listed still exist. The list “Most recent updates” lists the current updates and indicates, for example, the time when the last update “Last updated” occurred. For example, this occurred “4 minutes ago”. Finally, the list “Paid on time” indicates what percentage of incoming goods, “Incoming”, and what percentage of outgoing goods, “Outgoing”, are paid on time. Finally, the dashboard includes indications about a number of “Transactions”, which of these transactions are pending, “Pending”, which are to be done, “To dos”, which are paid, “Paid”, and which are rejected, “Rejected”.

[0356] The present invention has been described above in exemplary form with reference to specific embodiments. The present invention can be further described in an unrestricted and purely exemplary manner by the following embodiments. The following embodiments may include preferred embodiments. Correspondingly, the term "feature combination" as used herein may refer to such "preferred embodiments".

[0357] 1. A method for computer-implemented monitoring of a delivery of goods from a goods sender to a goods recipient using a restricted-access DLT system, the DLT system comprising a first DLT node assigned to the goods recipient and a second DLT node assigned to the goods sender, 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,

[0358] Wherein the method comprises initiating delivery of goods in the DLT system, wherein the initiation comprises:

[0359] receiving, by the first DLT node via the first network, a delivery order from a goods recipient for goods to be delivered from a goods sender to the goods recipient, wherein the delivery order identifies one or more physical characteristics of the goods to be delivered as a first specification, wherein the physical characteristics of the first specification include at least one quantity of the goods to be delivered,

[0360] creating a first dataset managed by a first DLT node and entering at least one or more physical characteristics of the delivery order into the first dataset by the first DLT node using at least one smart contract, wherein the first dataset is a first part of a shared dataset between the first DLT node and a second DLT node,

[0361] transmitting at least the first data set from the first DLT node to the second DLT node,

[0362] creating a second data set managed by a second DLT node, wherein the second data set is a second portion of the shared data set, and updating the second data set for a first time based on the first data set by the second DLT node, wherein the first updating includes inputting at least one or more of the physical characteristics of the first specification into the second data set, wherein the at least one or more input physical characteristics of the first specification include the quantity of goods to be delivered,

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

[0364] checking whether the second specification complies with the first specification using at least one smart contract,

[0365] updating the second data set a second time by the second DLT node using the result of the first check of the second specification,

[0366] transmitting at least one first update message from the second DLT node to the first DLT node,

[0367] • Updating the first data set for the first time by the first DLT node using a first update message.

[0368] 2. A method according to feature combination 1, wherein at least one smart contract includes program instructions for entering and checking shipment records during the delivery of goods from the goods sender to the goods receiver, wherein the method further includes recording the goods delivery in the DLT system, wherein the record includes:

[0369] receiving, by the second DLT node, a shipment record from a sender of the goods via the first network, wherein the shipment record comprises one or more first sensor values ​​for one or more physical properties of the shipped goods according to the second specification, the one or more first sensor values ​​being detected by means of one or more first physical sensors assigned to the sender of the goods, wherein the one or more first sensor values ​​comprise at least one first sensor value quantifying a quantity of the delivered goods,

[0370] checking, using at least one smart contract, whether one or more first sensor values ​​of the shipment record correspond within a predetermined first tolerance to one or more physical properties of the goods to be delivered according to the shared data set, wherein the checked first sensor values ​​include at least a first sensor value quantifying the amount of the goods delivered,

[0371] updating the second data set for a third time by the second DLT node using the second check result of the one or more first sensor values ​​of the check shipment record,

[0372] transmitting at least one second update message from the second DLT node to the first DLT node,

[0373] Updating the first data set a second time by the first DLT node using a second update message.

[0374] 3. A method according to feature combination 1 or 2, wherein at least one smart contract includes program instructions for verifying the delivery of goods, wherein the method also includes verifying the delivery of goods in the DLT system, wherein the verification includes:

[0375] checking, by a second DLT node, parameters of a verification message for verifying the delivery of goods using at least one smart contract, wherein the parameters include at least one quantity of goods to be verified, wherein the checking of the parameters includes checking whether the quantity of goods to be verified corresponds within a predetermined second tolerance to a first sensor value quantifying the delivered quantity of goods,

[0376] updating the second data set for a fourth time by the second DLT node when the quantity of goods to be verified corresponds to the first sensor value quantifying the delivered quantity of goods within a predetermined second tolerance, wherein the fourth updating comprises registering a verification message in the second data set by the second DLT node using at least one smart contract,

[0377] transmitting at least one third update message from the second DLT node to the first DLT node,

[0378] Updating the first data set for a third time by the first DLT node using a third update message, wherein the third updating of the first data set comprises registering the verification message in the first data set.

[0379] 4. The method according to any one of the preceding feature combinations further comprises signing data transmitted from the first DLT node to the second DLT node via the first DLT node, wherein at least one smart contract on the second DLT node is configured to verify the signature of the transmitted data.

[0380] 5. The method according to any one of the preceding feature combinations further comprises signing data transmitted from the second DLT node to the first DLT node via the second DLT node, wherein at least one smart contract on the first DLT node is configured to verify the signature of the transmitted data.

[0381] 6. A method according to any of the preceding feature combinations, wherein data transmission between the first DLT node and the second DLT node is achieved via one or more cryptographically protected communication connections performed by means of end-to-end encryption.

[0382] 7. The method according to feature combination 6, wherein establishing one or more cryptographically protected communication connections respectively includes mutual authentication of the first DLT node and the second DLT node.

[0383] 8. The method according to any one of the preceding feature combinations, wherein during the initialization process, checking whether the second specification matches the first specification is a consistency check.

[0384] 9. A method according to feature combination 8, wherein initialization also includes: if one or more physical characteristics according to the second specification in the input second data set are different from one or more physical characteristics according to the first specification from the first data set, a handshake is performed between the first DLT node and the second DLT node to align the first specification of the first data set and the second specification of the second data set so that the first specification and the second specification obtained by the alignment are consistent.

[0385] 10. A method according to any one of feature combinations 1 to 7, wherein during the initialization process, checking whether the second specification is consistent with the first specification is performed based on at least one smart contract to check whether they are consistent within a predetermined third tolerance.

[0386] 11. A method according to feature combination 10, wherein initialization also includes: if one or more differences between one or more physical characteristics according to the second specification input into the second data set and one or more physical characteristics according to the first specification from the first data set are greater than a predetermined third tolerance, a handshake is performed between the first DLT node and the second DLT node to align the first specification of the first data set and the second specification of the second data set so that the first specification and the second specification obtained by the alignment are consistent within the predetermined third tolerance.

[0387] 12. The method according to any one of the preceding feature combinations, wherein the program instructions included in at least one smart contract are further configured to input and check incoming cargo records during the delivery of cargo from the cargo sender to the cargo receiver, wherein recording the cargo delivery in the DLT system further comprises:

[0388] receiving, by the first DLT node, an incoming shipment record from a goods recipient via the first network, wherein the incoming shipment record comprises one or more second sensor values ​​for one or more physical properties of the incoming goods according to the first specification, the one or more second sensor values ​​being 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 quantifying a delivered quantity of the goods,

[0389] checking, using at least one smart contract, whether one or more second sensor values ​​of the incoming goods record correspond within a predetermined fourth tolerance to one or more physical properties of the goods to be delivered according to the shared data set and to one or more first sensor values ​​of the outgoing goods record, wherein the checked second sensor values ​​include at least a second sensor value quantifying the amount of the delivered goods,

[0390] updating the first data set a fourth time by the first DLT node using the result of a third check of the one or more second sensor values ​​of the check incoming goods record,

[0391] transmitting at least one fourth update message from the first DLT node to the second DLT node,

[0392] Updating the second data set for a fifth time by the second DLT node using the fourth update message.

[0393] 13. A method according to any one of the preceding feature combinations, wherein the verification message includes a bill, and the program instructions included in at least one smart contract are also configured for bill creation for the bill, wherein the bill creation is performed via a second DLT node using at least one smart contract, and wherein the parameters of the verification message are checked during the bill creation process.

[0394] 14. The method according to any one of the feature combinations 1 to 12, wherein the invoice is received by a first ERP system of the goods sender that creates the invoice.

[0395] 15. A method according to any one of the preceding feature combinations, wherein the data entered into the shared dataset provided in the DLT system during the process of recording the delivery of goods is mirrored identical data of the goods delivery from a first ERP system of the goods sender and / or a second ERP system of the goods recipient, wherein the first ERP system and / or the second ERP system is configured to control the processing of the goods delivery, wherein data consistency between the shared dataset and the ERP system is ensured by entering mirrored identical data.

[0396] 16. A method according to any one of feature combinations 1 to 14, wherein the processing of the delivery of goods is controlled by at least one smart contract, and the program instructions of at least one smart contract are also configured to control the processing of the delivery of goods.

[0397] 17. The method according to any of the preceding feature combinations, wherein the first network is a public network.

[0398] 18. A method according to any one of the preceding feature combinations, wherein receiving a delivery order from a goods recipient through a first DLT node is premised on successful authentication of the goods recipient through the first DLT node, and / or wherein receiving an order confirmation from a goods sender through a second DLT node is premised on successful authentication of the goods sender through the second DLT node, and / or wherein receiving a shipment record from a goods sender through a second DLT node is premised on successful authentication of the goods sender through the second DLT node, and / or wherein receiving an incoming shipment record from a goods recipient through a first DLT node is premised on successful authentication of the goods recipient through the first DLT node.

[0399] 19. A method according to any one of the preceding feature combinations, wherein the use of a delivery order of a goods recipient through a first DLT node is premised on a successful signature check of the signature of the delivery order through the first DLT node, and / or wherein the use of an order confirmation of a goods sender through a second DLT node is premised on a successful signature check of the signature of the order confirmation through the second DLT node, and / or wherein the use of a shipping record of a goods sender through a second DLT node is premised on a successful signature check of the signature of the shipping record through the second DLT node, and / or wherein the use of an incoming shipment record of a goods recipient through a first DLT node is premised on a successful signature check of the signature of the incoming shipment record through the first DLT node.

[0400] 20. The method according to any of the preceding feature combinations, wherein the first DLT node and the second DLT node are provided by one or more DLT servers of the DLT system.

[0401] 21. The method according to feature combination 20, wherein one or more DLT servers of the DLT system are arranged in one or more computing centers which are protected against unauthorized access.

[0402] 22. A method according to any of the preceding feature combinations, wherein data transfer between DLT nodes is performed via a second network.

[0403] 23. A method according to feature combination 22, wherein the second network is a private network or a public network.

[0404] 24. A method according to any one of the preceding feature combinations, wherein the program instructions included in at least one smart contract are also configured to trigger an electronic payment transaction, wherein the payment transaction via the smart contract is triggered when the verification message is registered in the DLT system.

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

[0406] 26. A method according to feature combination 24, wherein the triggered electronic payment transaction is a transaction of a certain amount of programmable currency implemented using a DLT system.

[0407] 27. A method according to feature combination 26, wherein the DLT system is configured to transfer the bill amount to be paid from the goods recipient's account for programmable currency to the goods sender's account for programmable currency, wherein the DLT system is also configured, for example, to convert the fiat currency amount of the fiat currency account assigned to the goods recipient into the programmable currency amount in the goods recipient's account for programmable currency.

[0408] 28. A method according to feature combination 26 or 27, wherein payment transactions are recorded in a DLT system using at least one smart contract, wherein when using a smart contract, an electronic account statement regarding the recorded payment transactions is also issued to the goods recipient and / or the goods sender.

[0409] 29. A shared dataset of a limited-access DLT system for computer-implemented monitoring of the delivery of goods from a goods sender to a goods recipient using the DLT system, wherein the shared dataset comprises a first part, wherein the first part is a first dataset managed by a first DLT node assigned to the goods recipient, wherein the shared dataset also comprises a second part, wherein the second part is a second dataset managed by a second DLT node assigned to the goods sender.

[0410] 30. Use of a shared dataset according to feature combination 29 for initiating a delivery of goods in a DLT system.

[0411] 31. Use of a shared dataset according to feature combination 29 for recording the delivery of goods in a DLT system.

[0412] 32. Use of a shared dataset according to feature combination 29 for verifying the delivery of goods in a DLT system.

[0413] 33. A DLT node of a restricted access DLT system for computer-implemented monitoring of a delivery of goods from a goods sender to a goods recipient, wherein the DLT node is implemented on a DLT server of the DLT system and is assigned to a goods recipient, wherein the DLT server comprises a processor and a memory with program instructions, wherein at least one smart contract is provided on the DLT node by the program instructions, wherein the program instructions for providing the at least one smart contract include program instructions for entering and checking a delivery order and an order confirmation, wherein execution of the program instructions by the processor causes the processor to control the DLT node in such a way that the DLT node performs the following during the process of initiating a delivery of goods in the DLT system:

[0414] receiving, via the first network, a delivery order from a goods recipient for goods to be delivered from a goods sender to the goods recipient by means of a DLT node, wherein the delivery order identifies one or more physical characteristics of the goods to be delivered as a first specification, wherein the physical characteristics of the first specification include at least one quantity of the goods to be delivered,

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

[0416] transmitting at least the first data set from the DLT node to another DLT node,

[0417] receiving at least one first update message from another DLT node via an update of the second data set using a first check result of checking whether a second specification of one or more physical characteristics of the goods to be delivered according to the order confirmation corresponds to the first specification,

[0418] The first data set is updated for the first time by the DLT node using a first update message.

[0419] 34. A DLT node according to feature combination 33, wherein the program instructions for providing at least one smart contract include program instructions for inputting and checking shipping records during the process of goods delivery from a goods sender to a goods receiver, wherein the program instructions are executed by a processor so that the processor further controls the DLT node in the following manner, that is, the DLT node implements the following in the process of recording the goods delivery in the DLT system:

[0420] receiving at least one second update message from another DLT node via the updating of the second data set using a second check result of checking whether one or more first sensor values ​​of the shipment record correspond within a predetermined first tolerance to one or more physical properties of the goods to be delivered according to the shared data set, wherein the one or more first sensor values ​​of the shipment record are detected by means of one or more first physical sensors assigned to the sender of the goods, wherein the checked first sensor values ​​include at least first sensor values ​​quantifying the delivered goods quantity,

[0421] Updating the first data set a second time by the DLT node using a second update message.

[0422] 35. A DLT node according to feature combination 33 or 34, wherein the program instructions for providing at least one smart contract include program instructions for verifying the delivery of goods, wherein the program instructions are executed by the processor so that the processor further controls the DLT node in the following manner, that is, the DLT node implements the following in the process of verifying the delivery of goods in the DLT system:

[0423] receiving at least one third update message from the other DLT node via the updating of the second data set using the verification message, wherein the updating of the second data set using the verification message comprises registering the verification message in the second data set, wherein the updating of the second data set using the verification message confirms a successful check of parameters of the verification message by the other DLT node, wherein the parameters comprise at least one quantity of goods to be verified, wherein the checking of the parameters comprises checking whether the quantity of goods to be verified corresponds within a predetermined second tolerance to a first sensor value quantifying the delivered quantity of goods,

[0424] Updating the first data set for a third time by the DLT node using a third update message, wherein the third updating of the first data set includes registering the verification message in the first data set.

[0425] 36. A DLT node according to any one of feature combinations 33 to 35, wherein the processor further controls the DLT node in the following manner by executing program instructions, namely, the DLT node implements the method steps of the first DLT node of the method according to any one of feature combinations 4 to 28.

[0426] 37. A DLT node of a restricted access DLT system for computer-implemented monitoring of a delivery of goods from a goods sender to a goods receiver, wherein the DLT node is implemented on a DLT server of the DLT system and is assigned to the goods sender, wherein the DLT server comprises a processor and a memory with program instructions, wherein at least one smart contract is provided on the DLT node by the program instructions, wherein the program instructions for providing the at least one smart contract comprise program instructions for inputting and checking a delivery order and an order confirmation, wherein execution of the program instructions by the processor causes the processor to control the DLT node in such a way that the DLT node performs the following during the process of initiating a delivery of goods in the DLT system:

[0427] receiving from another DLT node at least one first data set created by the another DLT node of a receiver of the goods, wherein the first data set is a first part of a shared data set between the DLT node and the another DLT node, wherein the first data set comprises at least one or more physical characteristics of the goods to be delivered according to a first specification of the delivery order, wherein the physical characteristics of the first specification comprise at least one quantity of the goods to be delivered,

[0428] creating a second data set managed by the DLT node, wherein the second data set is a second portion of the shared data set, and updating the second data set for a first time based on the first data set by the DLT node, wherein the first updating includes inputting at least one or more of the physical characteristics of the first specification into the second data set, wherein the at least one or more input physical characteristics of the first specification include the quantity of goods to be delivered,

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

[0430] checking whether the second specification complies with the first specification using at least one smart contract,

[0431] updating the second data set a second time by the second DLT node using the result of the first check of the second specification,

[0432] • Transmitting at least one first update message from the DLT node to another DLT node to update the first data set.

[0433] 38. A DLT node according to feature combination 37, wherein the program instructions for providing at least one smart contract include program instructions for inputting and checking shipping records during the process of goods delivery from a goods sender to a goods receiver, wherein the program instructions are executed by a processor so that the processor further controls the DLT node in the following manner, that is, the DLT node implements the following in the process of recording the goods delivery in the DLT system:

[0434] receiving, by the DLT node via the first network, a shipment record from a goods sender, wherein the shipment record comprises one or more first sensor values ​​for one or more physical properties of the shipped goods according to the second specification, the first sensor values ​​being 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 quantifying a delivered quantity of goods,

[0435] checking, using at least one smart contract, whether one or more first sensor values ​​of the shipment record correspond within a predetermined first tolerance to one or more physical properties of the goods to be delivered according to the shared data set, wherein the checked first sensor values ​​include at least a first sensor value quantifying the amount of the goods delivered,

[0436] updating the second data set for a third time by the DLT node using the second check result of the one or more first sensor values ​​of the check shipment record,

[0437] • Transmitting at least one second update message from the DLT node to another DLT node to update the first data set.

[0438] 39. A DLT node according to feature combination 37 or 38, wherein the program instructions for providing at least one smart contract include program instructions for verifying the delivery of goods, wherein the program instructions are executed by the processor so that the processor further controls the DLT node in the following manner, that is, the DLT node implements the following in the process of verifying the delivery of goods in the DLT system:

[0439] checking, by the DLT node, parameters of a verification message for verifying a delivery of goods using at least one smart contract, wherein the parameters include at least one quantity of goods to be verified, wherein the checking of the parameters includes checking whether the quantity of goods to be verified corresponds within a predetermined second tolerance to a first sensor value quantifying the delivered quantity of goods,

[0440] updating the second data set for a fourth time by the DLT node when the quantity of goods to be verified corresponds to the first sensor value quantifying the delivered quantity of goods within a predetermined second tolerance, wherein the fourth updating comprises registering a verification message in the second data set by the DLT node using at least one smart contract,

[0441] • Transmitting at least one third update message from the DLT node to another DLT node to update the first data set.

[0442] 40. A DLT node according to any one of feature combinations 37 to 39, wherein program instructions are executed by a processor so that the processor controls the DLT node in the following manner, namely, the DLT node implements the method steps of a second DLT node according to any one of feature combinations 4 to 28.

[0443] 41. A DLT system for computer-implemented monitoring of a delivery of goods from a goods sender to a goods recipient, the DLT system comprising a first DLT node assigned to the goods recipient and a second DLT node assigned to the goods 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 implement initialization of a delivery of goods in the DLT system, wherein the initialization comprises:

[0444] receiving, by the first DLT node via the first network, a delivery order from a goods recipient for goods to be delivered from a goods sender to the goods recipient, wherein the delivery order identifies one or more physical characteristics of the goods to be delivered as a first specification, wherein the physical characteristics of the first specification include at least one quantity of the goods to be delivered,

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

[0446] transmitting at least the first data set from the first DLT node to the second DLT node,

[0447] creating a second data set managed by a second DLT node, wherein the second data set is a second portion of the shared data set, and updating the second data set for a first time based on the first data set by the second DLT node, wherein the first updating includes inputting at least one or more of the physical characteristics of the first specification into the second data set, wherein the at least one or more input physical characteristics of the first specification include the quantity of goods to be delivered,

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

[0449] checking whether the second specification complies with the first specification using at least one smart contract,

[0450] updating the second data set a second time by the second DLT node using the result of the first check of the second specification,

[0451] transmitting at least one first update message from the second DLT node to the first DLT node,

[0452] • Updating the first data set for the first time by the first DLT node using a first update message.

[0453] 42. A DLT system according to feature combination 41, wherein at least one smart contract includes program instructions for inputting and checking shipment records during the delivery of goods from a goods sender to a goods receiver, wherein the DLT system is further configured to record the goods delivery in the DLT system, wherein the record includes:

[0454] receiving, by the second DLT node, a shipment record from a sender of the goods via the first network, wherein the shipment record comprises one or more first sensor values ​​of one or more physical properties of the shipped goods according to the second specification, the first sensor values ​​being detected by means of one or more first physical sensors assigned to the sender of the goods, wherein the one or more first sensor values ​​comprise at least one first sensor value quantifying a quantity of the delivered goods,

[0455] checking, using at least one smart contract, whether one or more first sensor values ​​of the shipment record correspond within a predetermined first tolerance to one or more physical properties of the goods to be delivered according to the shared data set, wherein the checked first sensor values ​​include at least a first sensor value quantifying the amount of the goods delivered,

[0456] updating the second data set for a third time by the second DLT node using the second check result of the one or more first sensor values ​​of the check shipment record,

[0457] transmitting at least one second update message from the second DLT node to the first DLT node,

[0458] Updating the first data set a second time by the first DLT node using a second update message.

[0459] 43. A DLT system according to feature combination 41 or 42, wherein at least one smart contract includes program instructions for verifying the delivery of goods, wherein the DLT system is further configured to verify the delivery of goods in the DLT system, wherein the verification includes:

[0460] checking, by a second DLT node, parameters of a verification message for verifying the delivery of goods using at least one smart contract, wherein the parameters include at least one quantity of goods to be verified, wherein the checking of the parameters includes checking whether the quantity of goods to be verified corresponds within a predetermined second tolerance to a first sensor value quantifying the delivered quantity of goods,

[0461] updating the second data set for a fourth time by the second DLT node when the quantity of goods to be verified corresponds to the first sensor value quantifying the delivered quantity of goods within a predetermined second tolerance, wherein the fourth updating comprises registering a verification message in the second data set by the second DLT node using at least one smart contract,

[0462] transmitting at least one third update message from the second DLT node to the first DLT node,

[0463] Updating the first data set for a third time by the first DLT node using a third update message, wherein the third updating of the first data set comprises registering the verification message in the first data set.

[0464] 44. A DLT system according to any one of feature combinations 41 to 43, wherein the DLT system is further configured to implement a method according to any one of feature combinations 4 to 28.

[0465] 45. A computer program for monitoring the delivery of goods from a goods sender to a goods recipient using a restricted access DLT system, the DLT system comprising a first DLT node assigned to the goods recipient and a second DLT node assigned to the goods sender, 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,

[0466] The computer program includes program instructions for initiating delivery of goods in the DLT system, wherein the initiation includes:

[0467] receiving, by the first DLT node via the first network, a delivery order from a goods recipient for goods to be delivered from a goods sender to the goods recipient, wherein the delivery order identifies one or more physical characteristics of the goods to be delivered as a first specification, wherein the physical characteristics of the first specification include at least one quantity of the goods to be delivered,

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

[0469] transmitting at least the first data set from the first DLT node to the second DLT node,

[0470] creating a second data set managed by a second DLT node, wherein the second data set is a second portion of the shared data set, and updating the second data set for a first time based on the first data set by the second DLT node, wherein the first updating includes inputting at least one or more of the physical characteristics of the first specification into the second data set, wherein the at least one or more input physical characteristics of the first specification include the quantity of goods to be delivered,

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

[0472] checking whether the second specification complies with the first specification using at least one smart contract,

[0473] updating the second data set a second time by the second DLT node using the result of the first check of the second specification,

[0474] transmitting at least one first update message from the second DLT node to the first DLT node,

[0475] • Updating the first data set for the first time by the first DLT node using a first update message.

[0476] 46. ​​A computer program according to feature combination 45, wherein at least one smart contract includes program instructions for entering and checking a shipment record during the delivery of goods from a goods sender to a goods receiver, wherein the computer program further includes recording the goods delivery in a DLT system, wherein the record includes:

[0477] receiving, by the second DLT node, a shipment record from a sender of the goods via the first network, wherein the shipment record comprises one or more first sensor values ​​of one or more physical properties of the shipped goods according to the second specification, the first sensor values ​​being detected by means of one or more first physical sensors assigned to the sender of the goods, wherein the one or more first sensor values ​​comprise at least one first sensor value quantifying a quantity of the delivered goods,

[0478] checking, using at least one smart contract, whether one or more first sensor values ​​of the shipment record correspond within a predetermined first tolerance to one or more physical properties of the goods to be delivered according to the shared data set, wherein the checked first sensor values ​​include at least a first sensor value quantifying the amount of the goods delivered,

[0479] updating the second data set for a third time by the second DLT node using the second check result of the one or more first sensor values ​​of the check shipment record,

[0480] transmitting at least one second update message from the second DLT node to the first DLT node,

[0481] Updating the first data set a second time by the first DLT node using a second update message.

[0482] 47. A computer program according to feature combination 45 or 46, wherein at least one smart contract comprises program instructions for verifying the delivery of goods, wherein the computer program further comprises program instructions for verifying the delivery of goods in a DLT system, wherein the verification comprises:

[0483] checking, by a second DLT node, parameters of a verification message for verifying the delivery of goods using at least one smart contract, wherein the parameters include at least one quantity of goods to be verified, wherein the checking of the parameters includes checking whether the quantity of goods to be verified corresponds within a predetermined second tolerance to a first sensor value quantifying the delivered quantity of goods,

[0484] updating the second data set for a fourth time by the second DLT node when the quantity of goods to be verified corresponds to the first sensor value quantifying the delivered quantity of goods within a predetermined second tolerance, wherein the fourth updating comprises registering a verification message in the second data set by the second DLT node using at least one smart contract,

[0485] transmitting at least one third update message from the second DLT node to the first DLT node,

[0486] Updating the first data set for a third time by the first DLT node using a third update message, wherein the third updating of the first data set comprises registering the verification message in the first data set.

[0487] 48. The computer program according to any one of the feature combinations 45 to 47, wherein the computer program further comprises program instructions for implementing the method according to any one of the feature combinations 4 to 28.

[0488] Description of Reference Numerals

[0489] 100 Computer systems of consignors

[0490] 102 Memory

[0491] 104 Public Key

[0492] 106 Protected memory area

[0493] 108 Private Key

[0494] 110 Processor

[0495] 112 Program instructions

[0496] 114 Sensors

[0497] 116 Communication Interface

[0498] 120 Computer system of the cargo receiver

[0499] 122 Memory

[0500] 124 Public Key

[0501] 126 Protected memory area

[0502] 128 Private Key

[0503] 130 processors

[0504] 132 Program instructions

[0505] 134 Sensors

[0506] 136 Communication Interface

[0507] 140 DLT servers

[0508] 142 Processor

[0509] 144 Program instructions

[0510] 146 Memory

[0511] The first dataset of 148 shared datasets

[0512] 150 Public Key

[0513] 152 Protected memory area

[0514] 154 Private Key

[0515] 156 Communication Interface

[0516] 160 DLT servers

[0517] 162 Processors

[0518] 164 Program instructions

[0519] 166 Memory

[0520] The second dataset of 168 shared datasets

[0521] 170 Public Key

[0522] 172 Protected memory area

[0523] 174 Private Key

[0524] 176 Communication Interface

[0525] 180 DLT Network

[0526] 182 DLT system

[0527] 184 Network

[0528] 186 Bank's Computer System

[0529] 190 Delivery Order

[0530] 191 Order confirmation

[0531] 192 Updated Delivery Orders

[0532] 193 Updated order confirmation

[0533] 194 Verification Message

Claims

1. A method for computer-implemented monitoring of a delivery of goods from a goods sender to a goods recipient using a restricted access DLT system (182), the DLT system comprising a first DLT node assigned to the goods recipient and a second DLT node assigned to the goods sender, 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), The method comprises initiating delivery of goods in the DLT system (182), wherein the initiation comprises: receiving, by the first DLT node via a first network (184), a delivery order (190) from the goods recipient for goods to be delivered from the goods sender to the goods recipient, wherein the delivery order (190) identifies one or more physical characteristics of the goods to be delivered as a first specification, wherein the physical characteristics of the first specification include at least one quantity of the goods to be delivered, creating a first data set (148) managed by the first DLT node and inputting at least one or more physical characteristics 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 shared data set 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 portion of the shared data set, and updating the second data set (168) for a first time based on the first data set (148) by the second DLT node, wherein the first updating includes inputting at least one or more of the physical characteristics of the first specification into the second data set (168), wherein the at least one or more input physical characteristics of the first specification include a quantity of goods to be delivered, receiving, by the second DLT node via the first network (184), an order confirmation (191) from the sender of the goods, wherein the order confirmation (191) includes a second specification of one or more physical characteristics of the goods to be delivered, checking whether the second specification complies with the first specification using the at least one smart contract, updating the second data set a second time by the second DLT node using the result of the first check of the second specification (168), transmitting at least one first update message from said second DLT node to said first DLT node, • Updating the first data set for the first time by the first DLT node using the first update message (148).

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

3. A method, in particular according to claim 1 or 2, wherein the at least one smart contract comprises program instructions for inputting and checking a shipment record during the delivery of goods from the goods sender to the goods receiver, wherein the method comprises recording the goods delivery in the DLT system (182), wherein the record comprises: receiving, by the second DLT node, a shipment record from the goods sender via the first network (184), wherein the shipment record comprises one or more first sensor values ​​of one or more physical characteristics of the shipped goods according to the second specification, the one or more first sensor values ​​being 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 quantifying a quantity of the delivered goods, checking, using the at least one smart contract, whether the one or more first sensor values ​​of the shipment record correspond within a predetermined first tolerance to one or more physical characteristics of the goods to be delivered according to the shared dataset, wherein the checked first sensor values ​​include at least the first sensor values ​​quantifying the amount of the goods delivered, updating the second data set for a third time by the second DLT node using the result of the second check of the one or more first sensor values ​​of the shipment record (168), transmitting at least one second update message from said second DLT node to said first DLT node, Updating the first data set a second time by the first DLT node using the second update message (148).

4. A method, in particular according to any one of claims 1 to 3, wherein the method comprises verifying the delivery of goods in the DLT system (182), wherein the at least one smart contract comprises program instructions for verifying the delivery of goods, wherein the verification comprises: checking, by the second DLT node, parameters of a verification message (194) for verifying the delivery of the goods using the at least one smart contract, wherein the parameters include at least one quantity of goods to be verified, wherein the checking of the parameters includes checking whether the quantity of goods to be verified corresponds within a predetermined second tolerance to the first sensor value quantifying the delivered quantity of goods, updating the second data set (168) for a fourth time by the second DLT node when the quantity of goods to be verified corresponds to the first sensor value quantifying the delivered quantity of goods within the predetermined second tolerance, wherein the fourth updating comprises registering the verification message (194) in the second data set (168) by the second DLT node using the at least one smart contract, transmitting at least one third update message from said second DLT node to said first DLT node, Updating the first data set (148) for a third time by the first DLT node using the third update message, wherein the third updating of the first data set (148) comprises registering the verification message (194) in the first data set (148).

5. The method according to any of the preceding claims, further comprising signing, by the first DLT node, data transmitted from the first DLT node to the second DLT node, wherein the at least one smart contract on the second DLT node is configured to verify the signature of the transmitted data, and / or further comprising signing, by the second DLT node, data transmitted from the second DLT node to the first DLT node, wherein the at least one smart contract on the first DLT node is configured to verify the signature of the transmitted data, and / or wherein data transmission between the first DLT node and the second DLT node is effected via one or more cryptographically protected communication connections by means of end-to-end encryption, The establishment of 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 during the initialization, checking whether the second specification corresponds to the first specification is a consistency check, The initialization may also include: If one or more physical characteristics according to the second specification in the input second data set (168) are different from one or more physical characteristics 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 align the first specification of the first data set (148) and the second specification of the second data set (168) such that the first specification and the second specification resulting from the alignment match, or wherein checking whether the second specification is consistent with the first specification during the initialization process is checking whether they are consistent within a predetermined third tolerance according to the at least one smart contract, The initialization may also include: If one or more differences between one or more physical characteristics according to the second specification input into the second data set (168) and one or more physical characteristics according to the first specification from the first data set (148) are greater than the predetermined third tolerance, a handshake is performed between the first DLT node and the second DLT node to align the first specification of the first data set (148) and the second specification of the second data set (168) so that the first specification and the second specification resulting from the alignment are consistent within the predetermined third tolerance.

7. The method of any one of the preceding claims, wherein the program instructions included in the at least one smart contract are further configured to input and check incoming cargo records during the delivery of cargo from the cargo sender to the cargo recipient, wherein recording the cargo delivery in the DLT system (182) further comprises: receiving, by the first DLT node, an incoming shipment record from the goods recipient via the first network (184), wherein the incoming shipment record comprises one or more second sensor values ​​for one or more physical characteristics of the incoming goods according to the first specification, the one or more second sensor values ​​being 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 quantifying the delivered goods quantity, checking, using the at least one smart contract, whether the one or more second sensor values ​​of the incoming shipment record correspond within a predetermined fourth tolerance with one or more physical characteristics of the goods to be delivered according to the shared data set and with the one or more first sensor values ​​of the outgoing shipment record, wherein the checked second sensor values ​​include at least a second sensor value quantifying the amount of the goods delivered, updating the first data set a fourth time by the first DLT node using the result of a third check of one or more second sensor values ​​of the incoming goods record (148), transmitting at least one fourth update message from said first DLT node to said second DLT node, Updating the second data set for a fifth time by the second DLT node using the fourth update message (168).

8. The method according to any of the preceding claims, wherein the verification message (194) comprises a bill, and the program instructions comprised in the at least one smart contract are further configured for bill creation of the bill, wherein the bill creation is performed by the second DLT node using the at least one smart contract, wherein during the bill creation a parameter of the verification message (194) is checked, or The bill is received by a first ERP system of the freight sender that creates the bill.

9. The method according to any of the preceding claims, wherein the data entered in the shared dataset provided in the DLT system (182) during the process of recording the goods delivery is mirror-identical data of the goods delivery from the first ERP system of the goods sender and / or the second ERP system of the goods recipient, wherein the first ERP system and / or the second ERP system are configured to control the processing of the goods delivery, wherein data consistency between the shared dataset and the ERP systems is ensured by entering the mirror-identical data, or The processing of the delivery of the goods is controlled by the at least one smart contract, and the program instructions of the at least one smart contract are also configured to control the processing of the delivery of the goods.

10. The method according to any of the preceding claims, wherein the first network (184) is a public network, and / or wherein receiving the delivery order (190) of the goods recipient through the first DLT node is premised on successful authentication of the goods recipient through the first DLT node, and / or wherein receiving the order confirmation (191) from the goods sender via the second DLT node is premised on successful authentication of the goods sender via the second DLT node, and / or The prerequisite for receiving the shipment record from the goods sender through the second DLT node is successful authentication of the goods sender through the second DLT node, and / or wherein receiving the incoming shipment record from the cargo recipient through the first DLT node is premised on successful authentication of the cargo recipient through the first DLT node, and / or wherein the use of the delivery order (190) of the goods recipient by the first DLT node is subject to a successful signature check of the signature of the delivery order (190) by the first DLT node, and / or wherein the use of the order confirmation (191) of the goods sender by the second DLT node is premised on a successful signature check of the signature of the order confirmation (191) by the second DLT node, and / or wherein the use of the shipment record of the goods sender by the second DLT node is premised on a successful signature check of the signature of the shipment record by the second DLT node, and / or wherein the use of the incoming shipment record of the goods recipient by the first DLT node is premised on a successful signature check of the signature of the incoming shipment record 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 one or more of said DLT servers (140, 160) of said DLT system (182) are arranged in one or more computing centers, said computing centers being protected from unauthorized access, and / or wherein data is transferred between the DLT nodes via the second network (180), The second network (180) is, for example, a private network or a public network.

11. The method according to any of the preceding claims, wherein the program instructions included in the at least one smart contract are further configured to trigger an electronic payment transaction, wherein the payment transaction through the smart contract is triggered when the verification message (194) is registered in the DLT system (182), The triggered electronic payment transaction is, for example, an IBAN remittance from the IBAN account of the goods recipient to the IBAN account of the goods sender, or The triggered electronic payment transaction is, for example, a transaction of a certain amount of programmable currency implemented using the DLT system (182), wherein the DLT system (182) is configured, for example, to transfer the bill amount to be paid from the programmable currency account of the goods recipient to the programmable currency account of the goods sender, wherein the DLT system (182) is also configured, for example, to convert the legal tender amount of the legal tender account assigned to the goods recipient into the programmable currency amount in the programmable currency account of the goods recipient, and / or Wherein, when using the at least one smart contract, the payment transaction is recorded, for example, in the DLT system (182), wherein when using the smart contract, for example, an electronic account statement regarding the recorded payment transaction is also issued to the goods recipient and / or the goods sender.

12. A shared data set of a restricted-access DLT system (182) used in computer-implemented monitoring of a delivery of goods from a goods sender to a goods recipient, for initializing the delivery of the goods in the DLT system (182), and / or recording the delivery of the goods in the DLT system (182), and / or verifying the delivery of the goods in the DLT system (182), wherein the shared data set includes a first part, wherein the first part is a first data set (148) managed by a first DLT node assigned to the goods recipient, and wherein the shared data set also includes a second part, wherein the second part is a second data set (168) managed by a second DLT node assigned to the goods sender.

13. A DLT node of a limited-access DLT system (182) for computer-implemented monitoring of a delivery of goods from a goods sender to a goods recipient, wherein the DLT node is implemented on a DLT server (140) of the DLT system (182) and is assigned to the goods recipient, wherein the DLT server (140) comprises a processor (142) and a memory with program instructions (144), wherein at least one smart contract is provided on the DLT node by the program instructions (144), wherein the program instructions (144) providing the at least one smart contract comprise program instructions for entering and checking a delivery order (190), an order confirmation (191) and / or a shipping record during the delivery of goods from the goods sender to the goods recipient and / or program instructions for verifying the delivery of the goods, The execution of the program instructions by the processor causes the processor to control the DLT node in such a way that the DLT node implements the method steps of the first DLT node of the method according to any one of claims 1 to 11.

14. A DLT node of a limited-access DLT system (182) for computer-implemented monitoring of a delivery of goods from a goods sender to a goods recipient, wherein the DLT node is implemented on a DLT server (160) of the DLT system (182) and is assigned to the goods sender, wherein the DLT server (160) comprises a processor (162) and a memory (166) having program instructions (164), wherein at least one smart contract is provided on the DLT node by the program instructions (164), wherein the program instructions (164) providing the at least one smart contract comprise program instructions for entering and checking a delivery order (190), an order confirmation (191) and / or a shipping record during the delivery of goods from the goods sender to the goods recipient and / or program instructions for verifying the delivery of the goods, The execution of the program instructions by the processor causes the processor to control the DLT node in such a way that the DLT node implements the method steps of the second DLT node of the method according to any one of claims 1 to 11.

15. A DLT system (182) for computer-implemented monitoring of the delivery of goods from a goods sender to a goods recipient, the DLT system comprising a first DLT node assigned to the goods recipient and a second DLT node assigned to the goods sender, 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 shipping records during the delivery of goods from the goods sender to the goods recipient and / or program instructions for verifying the delivery of the goods, The DLT system (182) is configured to implement the method according to any one of claims 1 to 11.

16. A computer program for monitoring the delivery of goods from a goods sender to a goods recipient using a restricted access DLT system (182), the DLT system comprising a first DLT node assigned to the goods recipient and a second DLT node assigned to the goods sender, wherein the computer program provides at least one smart contract, wherein the at least one smart contract comprises program instructions for entering and checking a delivery order (190), an order confirmation (191) and / or a shipping record during the delivery of goods from the goods sender to the goods recipient and / or program instructions for verifying the delivery of the goods, The computer program comprises program instructions for implementing the method according to any one of claims 1 to 11.

Images