Using a distributed ledger system to control the delivery of goods

Abstract

The present invention relates to a method for computer-implemented control of item delivery from an item sender to an item recipient using a limited-access DLT system (182). The DLT system (182) includes a first DLT node assigned to the item recipient and a second DLT node assigned to the item sender. The DLT system (182) provides at least one smart contract with program instructions for entering and checking a delivery order (190), an order confirmation (191), and an item delivery log during item delivery from the item sender to the item recipient, and for verifying the item delivery. The method includes initiating the item delivery, e.g., in the DLT system (182), logging the item delivery, e.g., in the DLT system (182), and / or verifying the item delivery, e.g., in the DLT system (182).

Description

[Technical Field]

[0001] The present invention relates to a method for computer-implemented monitoring of goods delivery from a seller to a buyer using a limited-access DLT system, the invention also relates to the use of a shared dataset of the DLT system in the course of computer-implemented monitoring of the goods delivery, a DLT node of the limited-access DLT system implemented on a DLT server of the DLT system and assigned to a buyer, a DLT node of the limited-access DLT system implemented on a DLT server of the DLT system and assigned to a seller of goods delivery, a limited-access DLT system for computer-implemented monitoring of goods delivery, and a computer program for monitoring goods delivery using the limited-access DLT system. [Background technology]

[0002] Patent document 1 discloses a method for coordinating a production process, in which a first node of a first party in a blockchain network is designed to publish an order transaction in the blockchain network, and the published order transaction is verified by the blockchain network, the method including analyzing the verified order transaction in the blockchain network by at least one node of a second party in the blockchain network, the analysis including: Identify the 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 an offer based on the capacity parameters, and if the first vendor node accepts the offer, adjust the production process based on the offer. [Patent Document 1] International Publication No. 2021 / 18366

[0003] These and other methods of tracking items use blockchains. However, blockchains have the drawback that once data is entered into the blockchain, it can no longer be changed. Furthermore, data entered into a blockchain is visible to at least all blockchain servers that manage the corresponding blockchain. In the case of a public blockchain, data entered into the blockchain is publicly accessible, i.e., to anyone. Summary of the Invention [Problem to be solved by the invention]

[0004] The object of the present invention is to create an improved method suitable for monitoring goods deliveries and capable of guaranteeing the security and confidentiality of the data used in the course of said monitoring. [Means for solving the problem]

[0005] The problem addressed by the invention is solved by the features of the independent claims. Embodiments of the invention are set out in the dependent claims.

[0006] An embodiment relates to a method for computer-implemented monitoring of delivery of goods from a seller to a buyer by using a limited-access DLT system. The DLT system includes a first DLT node assigned to the buyer and a second DLT node assigned to the seller. 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.

[0007] The method includes initializing an item delivery in a DLT system. The initialization includes: receiving, by a first DLT node, a delivery order from the buyer via a first network for goods to be delivered from the seller to the buyer, the delivery order defining, as first specifications, one or more physical characteristics of the goods to be delivered, the physical characteristics of the first specification including at least one quantity of the goods to be delivered; creating a first dataset managed by a first DLT node and inputting at least the one or more physical characteristics of the delivery order into the first dataset by the first DLT node using the at least one smart contract, the first dataset being a first portion of a dataset shared between the first DLT node and the second DLT node; transferring at least said first data set from said first DLT node to said second DLT node; creating a second dataset managed by the second DLT node, the second dataset being a second part of the shared dataset, and performing a first update of the second dataset by the second DLT node based on the first dataset, the first update comprising entering at least one or more of the physical characteristics of the first item into the second dataset, the at least one or more entered physical characteristics of the first item comprising the quantity of goods to be delivered; receiving, by the second DLT node, via the first network, an order confirmation from the seller, the order confirmation including a second description of the one or more physical characteristics of the goods to be delivered; checking the second specification for consistency with the first specification by using the at least one smart contract; performing a second update of the second dataset by the second DLT node by using the first result of the check of the second details; forwarding at least a first update message from said second DLT node to said first DLT node; performing a first update of said first dataset by said first DLT node by using said first update message;

[0008] Embodiments include a method further comprising logging the delivery of goods in a DLT system, wherein the at least one smart contract includes program instructions for entering and checking a shipment goods log during the delivery of goods from a seller to a buyer. receiving, by the second DLT node, a shipping goods log from the seller via the first network, the shipping goods log including one or more first sensor values ​​for the one or more physical characteristics of the shipping goods according to the second specification detected by one or more first physical sensors assigned to the seller, the one or more first sensor values ​​including at least one first sensor value quantifying the amount of goods delivered; checking, by using the at least one smart contract, the one or more first sensor values ​​of the shipped item log for consistency with the one or more physical characteristics of the items to be delivered according to the shared dataset within a predetermined first tolerance, wherein the checked first sensor values ​​include at least the first sensor value quantifying the amount of items to be delivered; performing, by the second DLT node, a third update of the second dataset by using a second result of checking the one or more first sensor values ​​of the shipping goods log; the second DLT node sending at least a second update message to the first DLT node; performing a second update of the first dataset by the first DLT node by using the second update message; Includes.

[0009] Embodiments include a method further comprising verifying delivery of goods in a DLT system, wherein the at least one smart contract comprises program instructions for verifying delivery of goods. checking parameters of a validation message for validating the goods delivery by the second DLT node by using the at least one smart contract, wherein the parameters include at least one quantity of goods to be validated, and wherein checking the parameters includes checking the quantity of goods to be validated for consistency with the first sensor value quantifying the quantity of goods to be delivered within a second predetermined tolerance; performing a fourth update of the second dataset by the second DLT node if the quantity of goods to be verified matches the first sensor value quantifying the quantity of goods to be delivered within the second predetermined tolerance, the fourth update comprising registering the validation message in the second dataset by the second DLT node using the at least one smart contract; sending at least a third update message from the second DLT node to the first DLT node; performing a third update of the first dataset by the first DLT node by using the third update message, wherein the third update of the first dataset includes registering the validation message in the first dataset; Includes.

[0010] During the process of initializing a product delivery, a shared dataset is generated on two DLT nodes of a DLT system with limited access. This shared dataset is a dataset that includes a first partial dataset on a first DLT node and a second partial dataset on a second DLT node. Only the first DLT node (or another DLT node authorized for this purpose) and thereby the buyer can have permission to edit, i.e., write permission, for the first partial dataset, while only the second DLT node (or another DLT node authorized for this purpose) and thereby the seller can have permission to edit, i.e., write permission, for the second dataset. Furthermore, as a result of the access restrictions of the DLT system, for example, only the buyer can have read permission to read the first partial dataset via the first DLT node (or a further authorized DLT node), and only the seller can have read permission to read the second partial dataset via the second DLT node (or a further authorized DLT node).

[0011] The term distributed ledger technology refers to a technology used to log transactions or transaction states. In contrast to traditional approaches in which ledgers are typically managed as a unified ledger by only one entity, here any number of copies of the ledger, each of which is essentially equally valid, are maintained by various parties in a decentralized manner. For example, a party with at least one corresponding node in a DLT system may be a goods seller, a goods buyer, a goods manufacturer, or a goods supplier, or parties may overlap, such as a single party that is both a goods producer and a goods supplier. Furthermore, a party with at least one node may be a savings bank, a bank, a financial institution, a payment service provider, and / or a credit institution. Regulators with at least one node may be designated as parties or subscribers in a DLT system to perform special functions, such as preventing money laundering or complying with regulatory requirements, such as checking prescribed sanctions and embargoes. At least one node in a DLT system can assume the function of a notary to ensure the uniqueness of each transaction and prevent double spending of DLT-based monetary assets.

[0012] Appropriate steps are taken to ensure that any new transactions or transaction states being added are incorporated into all copies of the ledger and that a consensus is reached on the current state of the ledger.

[0013] For example, the at least one smart contract implemented on both DLT nodes may be configured to ensure data consistency between the two sub-datasets of the shared data set, e.g., mirrored or identical data may be implemented in both sub-datasets of the shared data set by synchronous data maintenance.

[0014] The method does not use a blockchain but is based, for example, on direct data exchange between the DLT nodes of the parties involved and direct data verification by the corresponding DLT nodes. The use of a limited-access DLT system has the advantage over a public blockchain in that access to the data managed by the DLT system is limited. For example, subscribers to a DLT system can only access one DLT node assigned to them at a time. For example, data from a shared dataset in a DLT system is only transferred between the DLT nodes where the dataset is shared. For example, transmissions are only made between the first DLT node of the buyer and the second DLT node of the seller. For example, unicast transmissions are used, i.e., the transferred data is addressed in each case to a single recipient, i.e., a single DLT node. In contrast to broadcast transmissions, as in many blockchain solutions, unicast transmissions have the advantage that only the sender and receiver have knowledge of the transferred data.

[0015] Because transactions in a blockchain are typically visible to all validating nodes, this approach lacks confidentiality when transmitting transactions entered into a blockchain network via broadcast. Blockchains typically store data as transactions in individual blocks that are chained together and managed redundantly in a distributed peer-to-peer network. Due to this redundant management, many nodes have access to all data stored in the blockchain. On the other hand, embodiments of the present invention have the advantage that both data security and confidentiality of data stored in a shared dataset can be guaranteed. This is achieved by the fact that communication regarding mapped transactions, i.e., data stored in a shared dataset, occurs only between participating DLT nodes within the DLT system, i.e., between DLT nodes that share the corresponding dataset. For example, these are only the first DLT node of the buyer and the second DLT node of the seller. Delivery of goods in this case is monitored by the one or more smart contracts implemented on the participating nodes. No storage occurs in the blockchain or any other dataset that can be viewed by all DLT nodes.

[0016] For this purpose, a dataset shared by the participating DLT nodes is used, consisting of a first (partial) dataset managed by the buyer's DLT node and a second (partial) dataset managed by the seller's DLT node. The two (partial) datasets should be identical to each other and reflect the perspective of the node responsible for each. Only the responsible DLT node is authorized to modify the corresponding part of the dataset. The partial datasets, and therefore the transactions stored in the corresponding partial datasets, are transferred to the other DLT node, respectively. For example, only changes to the corresponding partial datasets are transferred to the other DLT node at a time. For example, the data transferred to the other DLT node is signed. The signature allows the other DLT node to verify that the changes are correct or authorized by the signing DLT node and thus by the associated subscriber.

[0017] Furthermore, the first and second partial sets need not be identical. For example, a partial data set may contain one or more data values ​​that differ from the data values ​​in the other partial data set, e.g., regarding goods delivery, e.g., regarding the quantity of corresponding goods delivered or other factors. This may, for example, allow a tolerance range within which deviations are acceptable to be predefined. Alternatively or additionally, a semi-automated or fully automatic handshake may be performed between the two DLT nodes managing the two partial data sets until agreement is reached regarding the individual data values ​​of the different data sets, e.g., the goods to be delivered and their characteristics, i.e., until there are no more differences.

[0018] Thus, embodiments may have the advantage that, based on the above further features for matching data sets distributed across two DLT nodes and / or (sub)data sets thereof, an approach is provided for confidential handling of transactions between two DLT nodes, which also allows transactions to be secured and increases data security between DLT nodes.

[0019] For example, communication between DLT nodes occurs over a transport connection secured by the Transport Layer Security Protocol (TLS), and communication with DLT nodes occurs, for example, when a buyer accesses a first DLT node using a computer system assigned to the buyer and / or when a seller accesses a second DLT node using a computer system assigned to the seller over a TLS-secured transport connection.

[0020] For example, all transport connections are secured with TLS. Security principles within DLT systems are based, for example, on 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 equal permissions. The need-to-know principle, or necessity principle, dictates as a security goal for data that not only requires basic permissions for access to the corresponding data, but also requires that the data accessed be directly necessary for the fulfillment of a specific task. For example, even if a DLT node has access to data on a specific or defined security layer, the need-to-know principle dictates that access is prohibited if the corresponding data is not directly needed by that DLT node to perform a specific task.

[0021] Each DLT node receives only the data that affects it. As a result, since a compromised DLT node is not involved in managing the shared data sets of other DLT nodes, information cannot flow through the compromised DLT node and data within the DLT system is not publicly accessible or published.

[0022] Embodiments may have the advantage of being able to omit encryption of data in partial datasets of a shared dataset. Data can be entered and stored in the partial dataset in plaintext. The need-to-know principle ensures that relevant data is exchanged only between participating DLT nodes. This provides effective protection against unauthorized access of sensitive information. The network architecture used in DLT systems already guarantees effective data security and confidentiality. Data is not transmitted to other DLT nodes at all unless it directly affects other DLT nodes or their assigned subscribers (the need-to-know principle). This contrasts with the classical blockchain approach. To securely store sensitive data in a blockchain, this data must be entered and stored in encrypted form. Alternatively, only the result of applying a one-way function, such as a hash function, to the corresponding data is entered and stored. As a result of being broadcast among all nodes in the system, the blockchain is typically also visible to all nodes in the system, and therefore sensitive information in the blockchain must be protected by additional measures. These additional measures, such as encryption or the application of one-way functions, only allow basic protection of the data and information stored in the blockchain.

[0023] If data in a sub-dataset of a shared dataset is encrypted, this provides an additional level of security for the corresponding data beyond the existing basic level of protection already provided by the network architecture, and is not used solely to enforce basic protection as in the case of classical blockchains, for example, data in a sub-dataset of a shared dataset may be entered in encrypted form and / or the sub-dataset may be stored in encrypted form.

[0024] According to embodiments, there is no broadcasting in a DLT system, as would be the case if, for example, a blockchain were used: for example, communication between DLT nodes is actually based on unicast or direct communication between the involved DLT nodes, for example via dedicated communication links.

[0025] Embodiments allow, for example, mirrored data regarding the transfer of goods to be secured on both sides, i.e., on the buyer side and the seller side, in the form of first and second data sets, which may also be integrated, for example, into connected enterprise resource planning (ERP) systems on both sides.

[0026] The maintenance of mirrored and synchronized data provided in this way is advantageous, for example, for the digital integration of ordering, delivery, and financial processes between business partners, e.g., buyers and sellers. For example, this can ensure consistent data quality, measurable by both parties using performance indicators, e.g., key performance indicators (KPIs). Implementing in-process validation ensures the sustainability of already achieved data quality, thus preventing gradual deterioration. By using a DLT system to provide a common database location, e.g., in the form of a shared dataset for monitoring goods deliveries, the required reconciliation effort will be lower. For example, the effort required for subsequent account reconciliation can be significantly reduced and, ideally, even completely eliminated for both business partners in the long term. This can help improve data quality and process efficiency. For example, the scope of manual activities can be reduced.

[0027] Initially, for example as a result of receiving a delivery order including a first specification of goods to be delivered, one or more physical characteristics of the goods to be delivered are entered in accordance with the first specification into a first dataset managed by a first DLT node, i.e., a first sub-dataset of a shared dataset, where the one or more physical characteristics entered in accordance with the first specification include at least the quantity of goods to be delivered.

[0028] This first dataset, or one or more physical characteristics entered into the first dataset according to the first specification, is transferred to the seller's second DLT node. The second DLT node creates a second partial dataset of the shared dataset in which one or more physical characteristics are entered according to the first specification. In this case, the one or more physical characteristics entered according to the first specification include at least the quantity of goods to be delivered. As a result, for example, both partial datasets of the shared dataset contain the same data.

[0029] Upon receiving an order confirmation including a second description of one or more physical characteristics of the goods to be delivered, the second description is checked for consistency with the first description by the second DLT node using said at least one smart contract, and the second data set is updated using the results of the check of the second description.

[0030] If the second details match the first details, updating the second data set with the test results may include, for example, entering a confirmation of the first details. For example, updating the second data set with the test results may include entering the second details into the second data set in addition to the first details.

[0031] If the second specification differs from the first specification, updating the second data set using the test results may include, for example, replacing or updating a physical characteristic according to the first specification with a different physical characteristic according to the second specification. For example, in the process of updating the second data set, the divergent physical characteristic according to the second specification is entered into the second data set in addition to the first specification. For example, the second specification is entered into the second data set in addition to the first specification.

[0032] Further, a first update message is forwarded from the second DLT node to the first DLT node. For example, the first update message indicates whether the second specification is consistent with the first specification. For example, if one or more physical characteristics according to the second specification differ from the first specification, the first update message identifies the one or more divergent 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.

[0033] Such deviations of one or more physical characteristics according to the second specification from the first specification may occur, for example, because only a certain minimum quantity of the goods is available or because the goods can only be delivered in certain units, for example, within the limits of a tanker wagon or tanker truck. Such deviations of one or more physical characteristics according to the second specification from the first specification may occur, for example, because the available product characteristics differ from the ordered product characteristics.

[0034] The first DLT node uses the first update message to update the first dataset, i.e., the first partial dataset of the shared dataset. If the second details are consistent with the first details, updating the first dataset using the first update message may include, for example, entering a confirmation of the first details. For example, updating the first dataset using the first update message may include entering the second details into the first dataset in addition to the first details.

[0035] If the second specification differs from the first specification, updating the second data set using the first update message may, for example, include replacing or updating the physical characteristics according to the first specification with different physical characteristics according to the second specification. For example, in the process of updating the first data set, the different physical characteristics according to the second specification are entered into the second data set in addition to the first specification. For example, the second specification is entered into the second data set in addition to the first specification.

[0036] If the second details differ from the first details, for example, a "handshake" is performed between the first DLT node and the second DLT node to match the first details with the second details, so that the first and second details resulting from the matching are identical.

[0037] A handshake refers to an automated negotiation process between two parties, in this case two DLT nodes, through the exchange of data, in this case information about the physical characteristics of the goods to be delivered. In this case, a handshake may be used to set the terms of goods delivery before physical delivery of the goods begins. For example, using the at least one smart contract, a handshake protocol is executed between two DLT nodes, resulting in the adjustment of one or both details until an identical match, or identity, exists between these two details.

[0038] If the second details match the first details, for example, a confirmation message from the second DLT node is sent to the seller over the network. For example, the second details match the first details if the two details are identical, i.e., a perfect match. For example, the second details match the first details if there are no deviations beyond a predetermined tolerance. For example, the confirmation message indicates to the seller that an agreement has been reached between the buyer and seller regarding the corresponding goods delivery. The confirmation message also includes, for example, details of the corresponding goods delivery. For example, the corresponding confirmation message acts as a trigger for initiating the corresponding goods delivery.

[0039] Furthermore, the goods delivery is logged in the DLT system. When a physical goods delivery is performed, i.e., when the goods to be delivered leave the seller's warehouse, a shipped goods log is created. The corresponding shipped goods log 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 one or more physical sensors assigned to the seller. Thus, the shipped goods log specifies, for one or more physical properties for which target values ​​are specified in the second specification, the measured values ​​detected by the sensors in each case, which values ​​reflect the actual state of the shipped goods with respect to the corresponding physical properties. The corresponding sensor values ​​include at least one sensor value quantifying the amount of delivered, i.e., shipped goods.

[0040] The seller's second DLT node receives the shipping goods log from the seller via the first network and checks one or more first sensor values ​​in the shipping goods log for consistency with one or more physical characteristics of the goods to be delivered. This process checks whether one or more sensor values ​​in the shipping goods log match one or more physical characteristics according to the shared dataset within a predetermined tolerance. If such consistency does not exist, for example, a warning message is sent to the seller and / or the buyer. Such a warning can trigger a re-delivery by the seller, for example, if the delivery quantity is too small. For example, such a warning message may stop the delivery process if, for example, the product characteristics do not meet the specifications. In this case, for example, the delivery must be made with the buyer agreeing to the deviating specifications, or the order is canceled. As an alternative to cancellation, for example, the delivery date can be changed to a date on which goods meeting the specifications are available.

[0041] On the part of the purchaser, the presence of such a warning message can trigger a review of the deviating physical characteristics, for example, upon arrival of the goods. For example, such a warning message may require confirmation of the deviating physical characteristics by the purchaser for successful final verification of the goods delivery.

[0042] The second dataset is updated by the second DLT node using the results of checking one or more first sensor values ​​in the outgoing item log. For example, the update includes inputting the outgoing item log and / or one or more of the sensor values ​​specified by the outgoing item log. For example, all sensor values ​​specified by the outgoing item log are input. For example, only sensor values ​​that deviate from values ​​input into the second dataset for physical characteristics of the items to be delivered are input. For example, for sensor values ​​in the outgoing item log that match values ​​input into the second dataset for physical characteristics of the items to be delivered, only a confirmation that the corresponding value for the physical characteristic matches the obtained sensor value is input into the second dataset.

[0043] Also, a second update message is forwarded from the second DLT node to the first DLT node. For example, the second update message includes the shipping item log and / or one or more of the sensor values ​​indicated by the shipping item log. For example, the second update message includes all sensor values ​​indicated by the shipping item log. For example, the second update message includes only sensor values ​​that deviate from values ​​entered in the second dataset for physical characteristics of the items to be delivered. For example, for sensor values ​​in the shipping item log that match values ​​entered in the second dataset for physical characteristics of the items to be delivered, the second update message includes only a confirmation that the corresponding value for the physical characteristic according to the shared dataset matches the detected sensor value.

[0044] The first DLT node uses the second update message to update the first dataset, i.e., the first partial dataset of the shared dataset. For example, the update includes inputting the shipping item log and / or one or more of the sensor values ​​indicated by the shipping item log. For example, all sensor values ​​specified by the shipping item log are input. For example, only sensor values ​​for physical characteristics of the delivered items that deviate from values ​​input into the first dataset are input. For example, for sensor values ​​in the shipping item log that match values ​​for physical characteristics of the delivered items input into the first dataset, only confirmation that the corresponding value for the physical characteristic matches the obtained sensor value is input into the second dataset.

[0045] Finally, verification of the delivery of goods in the DLT system is performed. For this purpose, parameters of a 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 quantity of delivered goods to be verified. Checking the corresponding parameters includes checking the quantity of goods to be verified for consistency, within a predetermined tolerance, with a sensor value quantifying the delivery quantity according to the shipping goods log. If the quantity of goods to be verified matches the sensor value quantifying the delivery quantity of goods within a predetermined tolerance, the second dataset is updated by the second DLT node using the verification message. Updating includes registering the verification message in the second dataset by the second DLT node. For example, during the registration process, an identifier of the verification message is entered into the second dataset. For example, a check value, such as a hash value of the verification message, is entered into the second dataset. For example, one or more parameters of the verification message are entered into the second dataset. For example, the verification message is entered into the second dataset.

[0046] A hash value is the result of applying a hash function, also known as a distribution function, to an input, also known as a key. A hash function is a representation that maps a large input set, the keys, to a smaller target set, the hash values. Therefore, hash functions are generally not one-to-one. For example, the input set can contain elements of different lengths, while the elements of the target set typically have a fixed length.

[0047] For example, validation may be triggered by receipt of a validation message or by generation of a validation message. For example, generation of a validation message may be triggered by receiving confirmation of receipt of delivered goods from a purchaser. For example, the confirmation of receipt may be received in the form of an incoming goods log.

[0048] Additionally, the second DLT node transmits a third update message to the first DLT node. For example, the third update message includes verification message data entered into the second data set during the update. For example, the third update message includes the complete updated second data set. For example, the third update message includes a verification message.

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

[0050] Transactions relating to individual participants, i.e., sellers and buyers, are performed on DLT nodes of the DLT system assigned to each participant. For example, the DLT system may include multiple DLT servers. For example, two or more DLT nodes of two or more participants may be located on the same DLT server of the DLT system. For example, DLT nodes of different participants may be located on different DLT servers of the DLT system.

[0051] For example, a single smart contract may be used to implement a method for computer-implemented monitoring of goods delivery, or multiple smart contracts may be used, each of which may be configured to perform a particular sub-procedure, such as initialization, logging, and / or validation.

[0052] A smart contract defines a set of conditions that are recorded in a DLT system and triggers automated, self-executing actions when at least some of these predefined conditions are met. A smart contract contains program instructions that represent agreed-upon rules or corresponding conditions. Such smart contracts, which define rules for multiple participants, cannot be changed unilaterally. Rather, changes require, for example, consensus among the multiple participants. Such consensus may require, for example, the consent of a majority of the multiple participants and / or all of the multiple participants. For example, changes to a smart contract are logged. This provides, for example, a complete history of changes to the smart contract.

[0053] For example, the network used to access DLT nodes may be a TCP / IP network. For example, DLT nodes may be hosted on one or more servers. The DLT system may establish a secure connection between the DLT server and the DLT nodes hosted thereon. For example, DLT nodes may be implemented locally by participants on computer systems assigned to the participants.

[0054] The merchant's one or more first physical sensors include one or more physical measurement devices for detecting measurement data or sensor values. The measurement data is data that quantitatively or qualitatively describes a physical and / or chemical property of the object being measured. Suitable properties include weight, volume, temperature, humidity, pressure, particle size, sound field variables, luminance, pH value, ionic strength, electrochemical potential, conductivity, viscosity, and / or translucency. The measurement data is obtained by physical or chemical effects and converted into an electronically processable electrical signal. For example, the corresponding electrical signal containing the obtained measurement data can be cryptographically encrypted. For example, symmetric, asymmetric, or hybrid cryptographic encryption can be used. This means that the corresponding measurement data can be protected, for example, against unauthorized access. Additionally or alternatively, the corresponding electrical signal containing the obtained data can be digitally signed. This allows, for example, to prove the authenticity of the corresponding measurement data.

[0055] Embodiments may have the advantage of being able to implement two-way settlement of accounts, including, for example, two-way and / or three-way matches, and may also enable, for example, fully automated invoicing.

[0056] A two-way match may be used to implement a unanimous declaration of intent regarding delivery terms for the delivery of goods, such as the physical characteristics of the goods to be delivered and / or the price of the goods to be delivered, using at least one smart contract and documenting it using a DLT system.

[0057] The "2" in the name "two-way match" refers to the verification of the delivery order and the order confirmation. During the two-way match, the delivery terms for the delivery of goods, such as the physical characteristics of the goods to be delivered and / or the price of the goods to be delivered, are verified according to the delivery order and the order confirmation. This ensures that they match, i.e., are identical, or that any deviations do not exceed a predetermined tolerance. This two-way match is performed by the second DLT node, for example, by checking the information against the order confirmation as it is entered into the second dataset. For example, the delivery order includes a first price instruction for the price of the goods to be delivered. The price instruction is the instruction from which payment for the goods to be delivered is derived. For example, the price instruction is the same as the price to be paid. For example, the price to be paid can be derived or calculated from the price instruction. If the price instruction is for the total quantity of goods to be delivered, the price instruction matches the price of the goods to be delivered. For example, the first price instruction is a price instruction per quantity of goods to be delivered. If a price instruction is given per quantity of goods to be delivered, the actual price to be paid depends on the quantity of goods actually delivered. A price instruction per quantity of goods to be delivered, e.g., per unit, per weight, or per volume, is multiplied by the quantity of goods to be delivered to determine the price to be paid for the goods to be delivered. For example, this first price according to a delivery order is entered into a first dataset by a first DLT node and forwarded to a second DLT node for entry into a second dataset. For example, an order confirmation includes a second price instruction for the goods to be delivered, specifically a second price instruction per quantity of goods to be delivered. For example, this second price instruction according to the order confirmation is checked by the second DLT node for consistency with the first price instruction and entered into the second dataset during the update of the second dataset using the order confirmation. For example, this check can be performed using a two-way match, or, for example, a two-way match includes this check.In the two-way match process, prices for the goods to be delivered can be matched according to the delivery order and the order confirmation. Additionally, an update message sent to the first DLT node for updating the second dataset using the order confirmation includes a second price instruction. For example, the second price instruction thus transferred is entered into the second dataset by the second DLT node.

[0058] If the first price indication differs from the second price indication such that they are not identical or the difference exceeds a predetermined tolerance, for example, a handshake is initiated between the first DLT node and the second DLT node to match the price indications, e.g., the price indications resulting from the matching are identical or have a residual difference that does not exceed a predetermined tolerance.

[0059] In a three-way match, the delivery terms resulting from the two-way match are compared with the corresponding information in the verification message, along with information in the shipping goods log about the actual delivered goods, and can be documented using a DLT system. One or more delivery terms for the delivery of goods, such as the price of the delivered goods, result from the two-way match and are not covered by the shipping goods log. One or more delivery terms for the delivery of goods, such as the physical characteristics of the delivered goods, may differ from the results of the two-way match. Therefore, the actual values ​​for these delivery terms, such as the quantity of goods actually delivered, are captured using the shipping goods log. Thus, deviations from the results of the two-way match can be checked, and these deviations can be taken into account in the validation of the verification message. The "3" in the name three-way match means that in addition to the results of the two-way match based on the delivery order and order confirmation, the basis for the corresponding validation are both the shipping goods log and the verification message.

[0060] The actual order includes information about certain physical characteristics of the goods to be delivered, which may differ in the actual delivery for efficiency and / or production reasons. For example, the actual order also includes information about certain physical characteristics that may differ in the actual delivery due to naturally occurring variations. To this end, for example, the physical characteristics of the goods to be delivered are acquired using sensors during delivery by the seller and logged in a goods shipment log. These physical characteristics of the delivered goods acquired using sensors according to the shipped goods log are recorded in a shared dataset of the DLT system, for example as physical characteristics of the goods actually delivered, and taken as a basis for checking the validation message.

[0061] For example, a real order defines a specific quantity of ordered items to be delivered. However, for efficiency reasons, for example in the case of bulk items, it may be advantageous to fully fill a transport vehicle for transporting the delivered items, so the actual delivered quantity may deviate from the ordered quantity. For example, a quantity greater than ordered is delivered. This actual delivered quantity is detected, for example using a sensor, and logged in a shipped item log. For example, a real order defines certain physical characteristics of the ordered items. However, due to production conditions, for example, only items with physical characteristics that deviate from the characteristics defined in the order can be produced. In this case, for example, the purchaser agrees to the deviating specifications and the delivery is made, or the order is canceled. For example, production of an item to be delivered with certain physical characteristics may not be temporarily possible because the required initial product and / or an initial starting product with certain required physical characteristics is temporarily unavailable for production. Also, certain production means, such as a plant or part of a plant, may be temporarily unavailable for production. In this case, an alternative to cancellation is the option to reschedule the delivery date to a date when goods meeting the specifications are available or can be produced, for example.

[0062] For example, during the three-way match, price indications for the price of the delivered goods, particularly price indications per quantity of goods resulting from the two-way match, and indications of the actual quantity of delivered goods contained in the shipped goods log are compared with corresponding indications of the price and quantity of goods contained in the verification message. Additionally or alternatively, the total price of the delivered goods is determined from the price indications per quantity of goods resulting from the two-way match and indications of the actual quantity of delivered goods contained in the shipped goods log, and this total price is compared with the corresponding indication of the total price contained in the verification message. For example, the verification message can be created using a smart contract to ensure that the delivery terms specified in the verification message during the three-way match are consistent with the delivery terms agreed upon in the delivery order and order confirmation, as well as the actual delivery terms according to the shipped goods log. Furthermore, payment of the invoice amount resulting from the verification message can be triggered, for example, using a smart contract. Thus, a corresponding check of the verification message using a smart contract can replace a classical invoice check.

[0063] The above-described approach may be particularly advantageous for deliveries, such as bulk product deliveries, where the delivery terms of the delivery order and / or order confirmation may differ, such as the final quantity actually delivered. In this case, the actual delivery terms may be determined based on the shipped goods log. In other cases, the delivery terms may be set as immutable. For example, in the case of packaged goods, the quantity of goods delivered is determined by the order confirmation or the handshake between the seller and the buyer. Therefore, the corresponding defined delivery terms may be obtained, for example, from the order confirmation or the results of a two-way match. In such cases, a three-way match is used to check the corresponding adopted delivery terms in the validation message by using the shipped goods log. For example, during validation, errors regarding the actual delivery terms may be identified, and it may be ensured that these are taken into account in the validation message or that the validation message is based on the actual delivery terms. In this case, the corresponding deviations or errors may trigger the sending of a warning message and / or a corrective action based on the validation message, such as redelivery or delivery of the correct goods by the seller.

[0064] The system functions in such a way that signals provided by sensors in the form of outgoing goods logs and / or incoming goods logs are evaluated by said one or more smart contracts, compared with the status of the order or goods delivery process according to a shared dataset and logged in the shared dataset. Additionally, transfers of payment amounts between eWallets or electronic wallets are initiated using said one or more smart contracts, either semi-automatically or fully automatically.

[0065] According to an embodiment, the method further comprises signing, by the first DLT node, data transferred from the first DLT node to a second DLT node, wherein the at least one smart contract is configured on the second DLT node to verify the signature of the transferred data.

[0066] Embodiments may have an advantage in that the first DLT node may verify the authenticity of data transferred to the second DLT node by using the corresponding signature. This ensures that the second data set is updated by the second DLT node based on data signed and thus authorized by the first DLT node. For example, the first DLT node signs the data using a first signing key. For example, the first signing key may be a first private cryptographic key of a first asymmetric cryptographic key pair. For example, the first signing key may be stored in a protected memory area of ​​the first DLT node. For example, the second DLT node and / or a smart contract executed on the second DLT node may include a first signature verification key for verifying signatures created using the first signing key. For example, the first signature verification key may be a first public cryptographic key of the first asymmetric cryptographic key pair.

[0067] Data protection can be implemented or increased using cryptographic means, for example, hashing and / or encryption.

[0068] An asymmetric cryptographic key pair includes a public cryptographic key that is shared or disclosed to a third party and a private cryptographic key that is not shared or disclosed to a third party. The public cryptographic key allows a third party to decrypt data encrypted by the owner of the asymmetric key pair with the private cryptographic key. Furthermore, the public cryptographic key allows a third party to encrypt data so that only the owner of the asymmetric key pair can decrypt the encrypted data using the private cryptographic key. On the other hand, the private key is used by the owner of the asymmetric key pair to encrypt data so that it can be decrypted by a third party using the public cryptographic key. Furthermore, the private cryptographic key is used by the owner of the asymmetric key pair data to decrypt data intended for that owner that was encrypted with the public cryptographic key. Thus, for example, the private cryptographic key allows the owner of the asymmetric key pair to sign data, while the public cryptographic key allows any third party to verify the corresponding signature.

[0069] A digital signature is an asymmetric cryptographic system in which the sender uses a private signing key, i.e., a private encryption key, to calculate a value associated with a digital message, also called a digital signature, that allows anyone, using a public signature verification key, i.e., a public encryption key, to check the undeniable authorship of the signing key owner and the integrity of the message.

[0070] For example, the signature may be an encrypted hash value of the signed data, specifically a hash value encrypted with a private encryption key, e.g., the private encryption key is associated with a public encryption key that serves as the signature verification key, e.g., the public encryption key is provided as part of a certificate.

[0071] Here, a certificate refers to a digital certificate, also known as a public key certificate. Such certificates, based on asymmetric key pairs, implement a so-called public key infrastructure (PKI). Such certificates involve structured data used to assign public keys of an asymmetric cryptographic system to entities such as people, organizations, computer systems, or DLT nodes. For example, a certificate contains a public key and may be signed. For example, a certificate may comply with the X.509 standard or some other standard.

[0072] A PKI provides a system for issuing, distributing, and verifying digital certificates. In asymmetric cryptography systems, digital certificates are used to verify or define the authenticity of a public key, its acceptable scope of application, and its validity. The digital certificate itself is protected by a digital signature, the authenticity of which can be verified using the certificate issuer's public key. Digital certificates are then used to verify the authenticity of the issuer's key. This allows the establishment of a chain of digital certificates, each of which confirms the authenticity of the public key used to verify the previous certificate. Such a chain of certificates forms a so-called verification path or certification path. Participants in a PKI must be able to trust the authenticity of the last certificate, the so-called root certificate, and the key it attests to, without the need for another certificate. Root certificates are managed by so-called root certification authorities, and their authenticity is assumed to be assured and is the basis for the authenticity of all PKI certificates.

[0073] If a private cryptographic key belonging to a public cryptographic key is used to generate a digital signature to be verified, a certificate can be assigned to the digital signature. By providing the public with a certificate associated with the public key, users of an asymmetric cryptographic system are allowed to map the public key to an entity such as a person, organization, computer system, or DLT node.

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

[0075] Embodiments may have the advantage that the second DLT node can verify the authenticity of data transferred to the first DLT node by using the corresponding signature. This ensures that the first data set is updated by the first DLT node based on data signed and thus authorized by the second DLT node. For example, the second DLT node signs the data using a second signing key. For example, the second signing key is a second private cryptographic key of a second asymmetric cryptographic key pair. For example, the second signing key is stored in a protected memory area of ​​the second DLT node. For example, the second DLT node and / or a smart contract running on the second DLT node includes a second signature verification key for verifying signatures created using the second signing key. For example, the second signature verification key is a second public cryptographic key of the second asymmetric cryptographic key pair.

[0076] According to an embodiment, data transfer between the first DLT node and the second DLT node is performed over one or more communication links that are cryptographically secured using end-to-end encryption.

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

[0078] According to an embodiment, establishing one or more cryptographically secured communication connections includes, for example, mutual authentication of the first DLT node and the second DLT node.

[0079] Embodiments may have the advantage that, based on mutual authentication, both DLT nodes can be sure of who they are communicating with over the corresponding communication link, thereby ensuring that the buyer's first DLT node is actually communicating with the DLT node assigned to the seller, i.e., the second DLT node, and that the seller's second DLT node is actually communicating with the buyer's assigned DLT node, i.e., the first DLT node.

[0080] According to an embodiment, checking the second specification for consistency with the first specification during the initialization process is an identity check. An embodiment may have the advantage of being able to ensure that identity exists between the first specification according to the delivery order and the second specification according to the order confirmation. Such identity means that the buyer and seller agreed on the same specification of the goods to be delivered. In this case, for example, both partial records of the shared dataset store the same specification. If the first specification and the second specification differ from each other, for example, a handshake protocol can be executed between the two DLT nodes by using the at least one smart contract, resulting in an adjustment of one or both specifications until identity exists.

[0081] According to an embodiment, the initialization further includes, if one or more physical characteristics according to the second specification entered in the second dataset differ from one or more physical characteristics according to the first specification from the first dataset, performing a handshake between the first DLT node and the second DLT node to match the first specification of the first dataset with the second specification of the second dataset, so that the first specification and the second specification resulting from the match are the same.

[0082] The handshake may be, for example, automatic or semi-automatic. For example, in the case of an automatic handshake, tolerances for the negotiated parameters are defined for the buyer and seller. In this case, deviations between the parameters can be achieved by matching them within their respective tolerances. In the case of a semi-automatic handshake, a proposal for a parameter value is received from one of the two subscribers or from a DLT node assigned to the corresponding subscriber, and this proposal differs from a separate proposal by the corresponding subscriber for the corresponding parameter. This different parameter value can be confirmed, for example, by receiving user input from the corresponding subscriber. If the corresponding parameter value is confirmed by user input, confirmation of the proposed parameter value can also be sent to the proposing second subscriber during the handshake. Alternatively, a counterproposal for a different parameter value can be received by receiving user input from the corresponding subscriber. During the handshake, this counterproposal for the different parameter value can be sent to the second subscriber. The second subscriber confirms the counterproposal by sending a corresponding confirmation during the handshake or makes a new counterproposal. This procedure may continue, for example, until agreement is reached on the corresponding parameter value or until a predefined termination criterion is met, which may be, for example, a predefined maximum number of proposals for the parameter value, expiration of a predefined maximum time period for negotiating the parameter value, or receipt of user input that explicitly rejects the current proposal for the corresponding parameter value.

[0083] The handshake may be executed, or at least initiated, by said one or more smart contracts. Preferably, successive iterations of automated or semi-automated handshakes between the DLT nodes of the negotiators may be performed by entering proposals into respective controlled portions of the shared dataset, which are then forwarded to the DLT nodes of the negotiators. In this way, all changes remain traceable and can be vetted by the negotiators. Thus, there is transparency between the negotiators about the parameters being negotiated, as distinct proposals are entered into distinct portions of the shared dataset and counterproposals are entered into other portions of the shared dataset.

[0084] Embodiments may have the advantage that an efficient way may be provided for matching different items, i.e., different offers for items, according to delivery orders and order confirmations, between buyers and sellers.

[0085] According to an embodiment, checking the second specification for consistency with the first specification during initialization is checking for consistency within a predefined third tolerance in accordance with the at least one smart contract.

[0086] Embodiments may have the advantage that the specifications do not need to be identical. This allows for deviations within a predefined tolerance. For example, a merchant may adjust the specifications of the goods to be delivered, such as the quantity of goods to be delivered, within predefined limits or tolerances to match their ability to deliver the requested goods.

[0087] According to an embodiment, the initialization further includes performing a handshake between the first DLT node and the second DLT node to match the first specification of the first data set with the second specification of the second data set if one or more deviations between the one or more physical characteristics according to the second specification entered in the second data set and the one or more physical characteristics according to the first specification from the first data set are greater than a third predefined tolerance, the handshake causing the first and second specifications resulting from the matching to match each other within the third predefined tolerance.

[0088] Embodiments may have the advantage that an effective way may be provided for matching different details, i.e. different offers for details, according to delivery orders and order confirmations between a buyer and a seller, for example, using said at least one contract a handshake protocol may be implemented between two DLT nodes, resulting in adjustment of one or both details until the deviation between the two details is only within a corresponding predefined tolerance.

[0089] According to an embodiment, the program instructions included in the at least one smart contract are further configured to input and check an incoming goods log during the course of goods delivery from the seller to the buyer. The goods delivery log in the DLT system also includes: receiving, by the first DLT node, an incoming goods log from the purchaser via the first network, the incoming goods log including one or more second sensor values ​​for the one or more physical characteristics of the incoming goods according to the first specification, acquired by one or more second physical sensors assigned to the purchaser, the one or more second sensor values ​​including at least one second sensor value quantifying the amount of goods delivered; checking, by using the at least one smart contract, the one or more second sensor values ​​of the incoming goods log for consistency with the one or more physical characteristics of the goods to be delivered according to the shared dataset and with the one or more first sensor values ​​according to the outgoing goods log, within a fourth predefined tolerance, wherein the checked second sensor values ​​include at least the second sensor values ​​quantifying the amount of goods to be delivered; performing a fourth update of the first dataset by the first DLT node by using a third result of checking the one or more second sensor values ​​in the incoming log; forwarding at least one fourth update message from the first DLT node to the second DLT node; performing a fifth update of the second data set by the second DLT node by using the fourth update message.

[0090] An embodiment may have the advantage that the logging of goods deliveries includes the goods seller's outgoing goods log for goods actually sent, as well as the buyer's incoming goods log for goods actually received.

[0091] When a physical item delivery is received by the purchaser, i.e., when the items to be delivered arrive at the purchaser's warehouse, an incoming item log is created. The corresponding incoming item log includes one or more sensor values ​​for one or more physical properties of the incoming item according to the first specification, which are acquired by one or more physical sensors assigned to the purchaser. Thus, the incoming item log specifies, for one or more physical properties for which target values ​​are specified in the first specification, the measurement values ​​acquired by the sensors in each case, which reflect the actual state of the incoming item with respect to the corresponding physical property. The corresponding sensor value includes at least one sensor value that quantifies the amount of delivered, i.e., incoming, item.

[0092] The first DLT node of the seller receives an incoming goods log from the seller via the first network and checks one or more first sensor values ​​of the incoming goods log for consistency with one or more physical characteristics of the goods to be delivered. This process checks whether one or more sensor values ​​of the incoming goods log match one or more physical characteristics according to the shared dataset within a predefined tolerance. If such consistency does not exist, for example, a warning message is sent to the buyer and / or the seller. Such a warning message can trigger a re-delivery by the seller, for example, if the delivery amount is too small. On the buyer's side, for example, such a warning message can require confirmation by the buyer of the deviating physical characteristics for final successful verification of the goods delivery.

[0093] The first dataset is updated by the first DLT node using the results of checking one or more first sensor values ​​in the incoming goods log. For example, the update includes inputting the incoming goods log and / or one or more of the sensor values ​​indicated by the incoming goods log. For example, all sensor values ​​specified in the incoming goods log are input. For example, only sensor values ​​that deviate from values ​​input into the first dataset for physical characteristics of the delivered goods are input. For example, for sensor values ​​in the incoming goods log that match values ​​for physical characteristics of the delivered goods input into the first dataset, only a confirmation to the effect that the corresponding value for the physical characteristic matches the obtained sensor value is input into the second dataset.

[0094] Further, a fourth update message is forwarded from the first DLT node to the second DLT node. For example, the fourth update message includes the incoming item log and / or one or more of the sensor values ​​specified by the incoming item log. For example, the fourth update message includes all sensor values ​​specified by the incoming item log. For example, the fourth update message includes only sensor values ​​that deviate from values ​​entered in the first dataset for physical characteristics of the items being delivered. For example, for sensor values ​​in the incoming item log that match values ​​entered in the first dataset for physical characteristics of the items being delivered, the fourth update message includes only a confirmation to the effect that the corresponding value for the physical characteristic according to the shared dataset matches the detected sensor value.

[0095] The second DLT node uses the fourth update message to update the second dataset, which is a second partial dataset of the shared dataset. For example, the update includes inputting the incoming goods log and / or one or more of the sensor values ​​indicated by the incoming goods log. For example, all sensor values ​​specified by the incoming goods log are input. For example, only sensor values ​​for physical characteristics of the delivered goods that deviate from values ​​input into the second dataset are input. For example, for sensor values ​​in the incoming goods log that match values ​​for physical characteristics of the delivered goods input into the second dataset, only a confirmation to the effect that the corresponding value for the physical characteristic matches the obtained sensor value is input into the second dataset.

[0096] The merchant's one or more second physical sensors include one or more physical measurement devices for acquiring measurement data or sensor values. The measurement data is data quantitatively or qualitatively describing a physical and / or chemical property of the object being measured. Suitable properties include weight, volume, temperature, humidity, pressure, particle size, sound field variables, luminance, pH value, ionic strength, electrochemical potential, conductivity, viscosity, and / or optical transparency. The measurement data is acquired by physical or chemical effects and converted into an electronically processable electrical signal. For example, the corresponding electrical signal containing the acquired measurement data is cryptographically encrypted. For example, symmetric, asymmetric, or hybrid cryptographic encryption can be used. This means that the corresponding measurement data can be protected, for example, against unauthorized access. Additionally or alternatively, the corresponding electrical signal containing the acquired data can be digitally signed. This allows, for example, the authenticity of the corresponding measurement data to be verified.

[0097] According to an embodiment, the validation message includes an invoice. An embodiment may have the advantage that in the process of checking the validation message, the invoice for the goods delivery is checked. This ensures that the invoice's details about the physical characteristics of the goods to be delivered correspond to the actual physical characteristics of the goods to be delivered. In particular, in this way it can be ensured that the details about the quantity of goods to be delivered, which is the basis of the invoice, match the quantity of goods actually delivered.

[0098] According to an embodiment, the program instructions included in the at least one smart contract are also configured to generate an invoice. A second DLT node generates the invoice using the at least one smart contract. A validation message parameter can be checked during the generation of the invoice.

[0099] Embodiments may have the advantage that invoice generation may be directly integrated in the process of goods delivery verification, e.g., once the generated invoice is registered in the DLT system, goods delivery monitoring is successfully completed.

[0100] Using the one or more smart contracts, additional fees and taxes, such as VAT, can be calculated on the invoice amount and added thereto during the invoice processing process.

[0101] According to an embodiment, an invoice is received from a first ERP system of a seller that generates the invoice. An embodiment may have the advantage that the DLT system can be combined with the seller's ERP system, e.g., an existing ERP system. The DLT system or a shared dataset managed by the DLT system represents a single point of truth for goods delivery. For example, to validate the invoice, registration in at least a second dataset on a second DLT node is required. For example, registration involves entering the invoice number of the invoice into the second dataset.

[0102] For example, both the seller and the buyer have their own independent ERP systems, whereas the shared data set provided in the DLT system acts as a single point of truth for both parties involved, i.e., the buyer and the seller.

[0103] An ERP system refers to an application software or IT system or multiple intercommunicating application software or IT systems used to support resource planning for a business. Complex ERP systems, for example, are integrated into subsystems, or application modules, that can be combined as needed. Enterprise Resource Planning (ERP) refers to the business task of planning, controlling, and managing resources, such as capital, equipment, materials, and information and communication technology, and people, in a timely and demand-responsive manner.

[0104] A core function of ERP in a manufacturing company is material requirements planning to ensure that all materials needed to manufacture a product and / or component are available in the right place, at the right time, and in the right quantity.

[0105] For example, the seller's and buyer's ERP systems may be configured to create and / or collect relevant data for item delivery and make this data available to the DLT system. For example, the buyer's ERP system may create a delivery order and / or an incoming item log and send it to a first DLT node. For example, the seller's ERP system may create an order confirmation, a shipped item log, and / or a validation message and send it to a second DLT node.

[0106] According to an embodiment, the data entered into the shared dataset provided in the DLT system in the process of logging the item delivery is mirrored data of the item delivery from a first ERP system of the seller and / or a second ERP system of the buyer, where the first and / or second ERP systems are configured to control the processing of the item delivery. Entering the mirrored data ensures data consistency between the shared dataset and the ERP systems.

[0107] Embodiments may have the advantage that data consistency can be achieved between the shared dataset and the seller's and / or buyer's ERP systems. Thus, the shared dataset represents a single point of truth for both participants or their mutually independent ERP systems. For example, a first DLT node receives a delivery order from the buyer's ERP system. For example, a second DLT node receives a delivery order from the seller's ERP system. Data entered into the shared dataset reflects data for item delivery stored in the first and / or second ERP systems.

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

[0109] Embodiments may have the advantage that goods delivery may be processed by the at least one smart contract. In this case, for example, neither a buyer nor a seller of goods needs an ERP system to process goods delivery. For example, a buyer's computer system may send a delivery order directly to a first DLT node via a first network, or the first DLT node may receive a delivery order directly from a buyer's computer system. For example, a seller's computer system may send an order confirmation directly to a second DLT node via a first network.

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

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

[0112] According to an embodiment, a prerequisite for receiving the buyer's delivery order by the first DLT node is successful authentication of the buyer by the first DLT node. The embodiment may have the advantage that the first DLT node can ensure that the delivery order actually originates from and is authorized by the buyer by successful authentication of the buyer. For example, authentication may be performed using a first username and a first password that the buyer must specify in order to successfully authenticate to the first DLT node. Further authentication methods may also be provided, for example by cryptographic methods, chip cards, and / or biometric data.

[0113] According to an embodiment, a prerequisite for receiving the seller's order confirmation by the second DLT node is successful authentication of the seller by the second DLT node. An embodiment may have the advantage that successful authentication of the seller allows the second DLT node to ensure that the order confirmation actually originates from and is authorized by the seller. For example, authentication may be performed using a second username and a second password that the buyer must specify in order to successfully authenticate to the first DLT node. Further authentication methods may also be provided, for example by cryptographic methods, chip cards, and / or biometric data.

[0114] According to an embodiment, a prerequisite for receiving the seller's shipping goods log by the second DLT node is successful authentication of the seller by the second DLT node. An embodiment may have the advantage that successful authentication of the seller allows the second DLT node to ensure that the shipping goods log actually originates from and is authorized by the seller. For example, authentication may be performed using a second username and a second password that the buyer must specify in order to successfully authenticate to the first DLT node. Additional authentication methods may also be provided, for example by cryptographic methods, chip cards, and / or biometric data.

[0115] According to an embodiment, a prerequisite for receiving the buyer's incoming goods log by the first DLT node is successful authentication of the buyer by the first DLT node. Embodiments may have the advantage that successful authentication of the buyer enables the first DLT node to ensure that the incoming goods log actually originates from and is authorized by the buyer. For example, authentication may be performed using a first username and a first password that the buyer must specify in order to successfully authenticate to the first DLT node.

[0116] According to an embodiment, a prerequisite for the first DLT node's use of the buyer's delivery order is a successful signature check of the delivery order signature by the first DLT node.

[0117] Embodiments may have the advantage that the signature of the delivery order can be used to check the authenticity of the delivery order, i.e., the first DLT node can check whether the received delivery order is actually authorized by the buyer. For example, the buyer uses a third signing key to sign the delivery order. For example, this third signing key is a third private cryptographic key of a third asymmetric cryptographic key pair. For example, the first DLT node and / or a smart contract running on the first DLT node includes a third signature verification key to verify the buyer's signature created using the third signing key. For example, this third signature verification key is a third public cryptographic key of the third asymmetric cryptographic key pair.

[0118] According to an embodiment, a prerequisite for the use of the buyer's order confirmation by the second DLT node is a successful signature check of the order confirmation signature by the second DLT node.

[0119] Embodiments may have the advantage that the signature of the order confirmation can be used to check the authenticity of the order confirmation, i.e., the second DLT node can check whether the received order confirmation is actually authorized by the merchant. For example, to sign the order confirmation, the merchant uses a fourth signing key. For example, this fourth signing key is a fourth private cryptographic key of a fourth asymmetric cryptographic key pair. For example, the second DLT node and / or a smart contract running on the second DLT node includes a fourth signature verification key for verifying the merchant's signature created using the fourth signing key. For example, this fourth signing key is a fourth public cryptographic key of a fourth asymmetric cryptographic key pair.

[0120] According to an embodiment, a prerequisite for the use of the merchant's shipping goods log by the second DLT node is a successful signature check of the signature of the shipping goods log by the second DLT node.

[0121] Embodiments may have the advantage that the signature of the shipping goods log can be used to check the authenticity of the shipping goods log, i.e. the second DLT node can check whether the received shipping goods log is indeed authorized by the seller. For example, to sign the order confirmation the seller uses a fourth signing key and the signature can be verified by the second DLT node using a fourth signature verification key.

[0122] According to an embodiment, a prerequisite for the use of the buyer's incoming goods log by the first DLT node is a successful signature check of the signature of the incoming goods log by the first DLT node.

[0123] The embodiment has the advantage that the authenticity of the incoming goods log can be checked using the signature of the incoming goods log, i.e. the first DLT node can check whether the received incoming goods log is actually authorized by the purchaser, for example, the purchaser uses a third signing key to sign the incoming goods log, and the signature can be verified by the first DLT node using the signature verification key.

[0124] 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, or for example, the first DLT node and the second DLT node are implemented on two different DLT servers of the DLT system.

[0125] According to an embodiment, one or more DLT servers of a DLT system are located in one or more data centers protected against unauthorized access. An embodiment may have the advantage that unauthorized physical access to a DLT server, and thus to a DLT node implemented thereon, may be prevented by access security. This physical access or access protection may be implemented in addition to cryptographic access protection that prevents unauthorized access to a DLT server or DLT node via a first network, such as the Internet. For example, this cryptographic access protection may include successful authentication as a prerequisite for accessing a DLT node through the first network. For example, authentication may require correct entry of a username and password for a subscriber, such as a seller or buyer, to whom a corresponding DLT node is assigned. For example, successful authentication may require multi-factor authentication, such as two-factor authentication.

[0126] Data center access security includes, for example, monitoring access to a data center and using alarm systems to secure the data center premises. Alarm systems include, for example, intrusion alarm systems (EMA), i.e., electronically operated devices that serve to protect objects. Intrusion alarm systems are designed, for example, to prevent intrusions by deterrence, notify services that provide assistance in the event of an intrusion, such as police and / or private security services, minimize an intruder's time to act, alert the immediate environment and bystanders involved, and / or recreate an actual intrusion.

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

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

[0129] According to an embodiment, the second network is a private network or a public network. For example, if it is a private network, the second network is an intranet. For example, if it is a public network, the second network is the Internet.

[0130] 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 smart contract payment transaction being triggered upon registration of the validation message in the DLT system.

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

[0132] The payment transaction can be combined with the data stream from the verification and kept in a closed data circuit.

[0133] According to an embodiment, the triggered electronic payment transaction is a transfer / transfer from a buyer's bank account to a seller's bank account.

[0134] According to an embodiment, the triggered electronic payment transaction is an IBAN transfer from the buyer's IBAN account to the seller's IBAN account.

[0135] According to an embodiment, the triggered electronic payment transaction is a programmable amount transaction executed using a DLT system.

[0136] Embodiments may have the advantage that transactions of programmable amounts may be made within the DLT system, whereby transactions may be triggered by registering a validation message and executed directly in the DLT system, for example using said at least one smart contract.

[0137] Programmable money refers to a digital form of currency that users can program with inherent logic for conditional use based on attributes of the digital currency itself. Examples of this include triggering a transaction after one or more conditions, such as time, location, or type of use, are met.

[0138] For example, a payment infrastructure is provided that allows sellers and buyers to share a programmable currency. Furthermore, for example, validation and invoicing of goods deliveries can be performed in closed data circuits.

[0139] According to an embodiment, the DLT system is configured to transfer the invoice amount due from the buyer's account for the programmable currency to the seller's account for the programmable currency. Preferably, the DLT system may be configured to convert a fiat amount in the fiat account assigned to the buyer into a programmable currency amount on the buyer's account for the programmable currency. Furthermore, the DLT system may be configured to convert, at least in part, the invoice amount transferred in the form of programmable currency on the seller's account for the programmable currency into a fiat amount on the fiat account assigned to the seller.

[0140] Embodiments may have the advantage that transactions may be processed in programmable currency. To this end, a fiat amount of the buyer may be converted into a programmable currency amount, which is used, at least in part, to pay for the delivered goods. An invoice amount received by the seller as payment for the delivered goods in the form of programmable currency may then be converted into a fiat amount. This fiat amount may be credited to the seller in a fiat account assigned to the seller.

[0141] Fiat money is classical currency: an artificially created, unbacked, open-ended, state-defined means of exchange and payment. In other words, it is an economic instrument without any inherent value that functions as a medium of exchange.

[0142] According to an embodiment, payment transactions are logged in the DLT system using the at least one smart contract, and electronic account statements relating to the logged payment transactions are also issued to buyers and / or sellers of goods using the smart contract.

[0143] Embodiments may have the advantage that, in addition to effecting an electronic payment transaction, an electronic account statement relating to the corresponding payment transaction is also issued to the buyer and / or seller of the goods. For example, bank statements are issued in accordance with the MT940 standard. MT940 (MT = Message Type) is a SWIFT® standard (Society for Worldwide Interbank Financial Telecommunication) or banking communication standard for the electronic transfer of account statement data.

[0144] A further embodiment includes a shared dataset of a limited-access DLT system for computer-implemented monitoring of delivery of goods from a seller to a buyer by using the DLT system. The shared dataset includes a first portion, the first portion being a first dataset managed by a first DLT node assigned to the buyer. The shared dataset also includes a second portion, the second portion being a second dataset managed by a second DLT node assigned to the seller.

[0145] For example, the first data set of the first portion includes, as a first detail, information regarding one or more physical characteristics of the items to be delivered from the delivery order. The physical characteristics of the first detail include at least one quantity of the items to be delivered. For example, the first data set of the first portion includes information regarding second details of one or more physical characteristics of the items to be delivered pursuant to the order confirmation. For example, the first data set of the first portion includes a check result of checking the second detail. For example, the first data set of the first portion includes one or more first sensor values ​​for one or more physical characteristics of the items according to a shipping item log, which are acquired by one or more physical sensors assigned to the seller. The one or more first sensor values ​​include at least one first sensor value quantifying the quantity of the items delivered. For example, the first data set of the first portion includes a check result of checking the first sensor values ​​of the shipping item log. For example, the first data set of the first portion includes one or more second sensor values ​​for one or more physical characteristics of the items according to the shipping item log, which are acquired by one or more physical sensors assigned to the buyer. The one or more second sensor values ​​include at least one second sensor value quantifying a quantity of delivered goods. For example, the first data set of the first portion includes a check result of checking the second sensor value of a shipped goods log. For example, the first data set of the first portion includes a registration of a verification message for verifying the goods delivery. For example, the registration includes information regarding one or more parameters of the verification message. For example, the parameters include at least one quantity of the goods to be verified. For example, the first data set of the first portion includes a check result of checking the parameters of the verification message.

[0146] For example, the second data set of the second portion includes information regarding one or more physical characteristics of the items to be delivered from the delivery order as a first detail. The physical characteristics of the first detail include at least one quantity of the items to be delivered. For example, the second data set of the second portion includes information regarding second details of one or more physical characteristics of the items to be delivered according to the order confirmation. For example, the second data set of the second portion includes check test results of checking the second details. For example, the second data set of the second portion includes one or more first sensor values ​​for one or more physical characteristics of the items according to the shipped item log, detected by one or more physical sensors assigned to the seller. The one or more first sensor values ​​include at least one first sensor value quantifying the amount of the items delivered. For example, the second data set of the second portion includes check results of checking the first sensor values ​​of the shipped item log. For example, the second data set of the second portion includes one or more second sensor values ​​for one or more physical characteristics of the items according to the incoming item log, detected by one or more physical sensors assigned to the buyer. The one or more second sensor values ​​include at least one second sensor value quantifying a quantity of delivered goods. For example, the second data set of the second portion includes a check result of checking the second sensor values ​​of a shipped goods log. For example, the second data set of the second portion includes a registration of a verification message for verifying the goods delivery. For example, the registration includes information regarding one or more parameters of the verification message. For example, the parameter includes at least one quantity of the goods to be verified. For example, the second data set of the second portion includes a check result of checking the parameters of the verification message.

[0147] For example, the shared data set is a result of performing one or more of the above-described method steps of the method for computer-implemented monitoring of item delivery. For example, the shared data set is a result of performing each of the above-described method steps of the method for computer-implemented monitoring of item delivery.

[0148] A shared dataset distributed across two DLT nodes and containing two (partial) datasets of buyers and sellers may have the advantage of providing an effective approach to the confidential processing of transactions between the two DLT nodes. In addition, such a shared dataset allows for effective transaction protection and increases data security between the DLT nodes.

[0149] The shared dataset may be used in any method according to one or more embodiments herein. Furthermore, the dataset may be subject to, processed by, and updated by the methods described above.

[0150] Further embodiments include the use of a shared dataset according to one or more embodiments herein to initialize item delivery in a DLT system. The shared dataset may be used for initialization in any manner according to one or more embodiments herein.

[0151] Further embodiments include the use of a shared dataset according to one or more embodiments herein for logging item deliveries in a DLT system. The shared dataset may be used for the logging process in any manner according to one or more embodiments herein.

[0152] Further embodiments include the use of a shared dataset according to one or more embodiments herein to verify item delivery in a DLT system. The shared dataset may be used for the verification process in any manner according to one or more embodiments herein.

[0153] A further embodiment includes a DLT node of a limited-access DLT system for computer-implemented monitoring of delivery of goods from a seller to a buyer. The DLT node is implemented on a DLT server of the DLT system and assigned to the buyer. The DLT server comprises a processor and a memory having program instructions. The program instructions provide at least one smart contract on the DLT node. The program instructions providing the at least one smart contract include program instructions for entering and checking delivery orders and order confirmations.

[0154] Execution of the program instructions by the processor causes the processor to control the DLT node such that, in the process of initiating a delivery of an item in the DLT system, the DLT node: receiving, by a first DLT node, a buyer's delivery order for goods to be delivered from a seller to a buyer over a first network, said delivery order defining one or more physical characteristics of said goods to be delivered as first specifications, said physical characteristics of said first specifications including at least one quantity of the goods to be delivered; creating a first dataset managed by the DLT node and entering at least the one or more physical attributes of the delivery order into the first dataset by the DLT node using the at least one smart contract, the first dataset being a first portion of a dataset shared between the first DLT node and a further DLT node assigned to the seller in the DLT system; - transferring at least said first data set from said DLT node to said further DLT node; receiving at least one first update message from the further DLT node via an update of the second data set using a result of a first check of a second specification of the one or more physical characteristics of the goods to be delivered according to an order confirmation for consistency with the first specification; performing a first update of said first dataset by said DLT node by using said first update message;

[0155] A further embodiment includes a DLT node, wherein the program instructions providing the at least one smart contract include program instructions for entering and checking a shipment goods log during delivery of goods from a seller to a buyer, wherein execution of the program instructions by a processor of the DLT node causes the processor to control the DLT node such that during logging of goods delivery in the DLT system, the DLT node: receiving at least one second update message from the further DLT node via an update of the second dataset using a second check result of checking one or more first sensor values ​​of a shipping goods log for consistency with the one or more physical characteristics of the delivered goods according to the shared dataset within a first predefined tolerance range, the one or more first sensor values ​​of the shipping goods log being acquired by one or more first physical sensors assigned to the seller, and the checked first sensor values ​​including at least the first sensor value quantifying the quantity of delivered goods; performing a second update of the first data set by the DLT node by using the second update message.

[0156] A further embodiment includes a DLT node, wherein the program instructions providing the at least one smart contract include program instructions for verifying delivery of an item, wherein execution of the program instructions by a processor of the DLT node causes the processor to control the DLT node such that, in the process of verifying delivery of an item in the DLT system, the DLT node: receiving at least a third update message from the further DLT node via an update of the second dataset using a verification message, wherein the update of the second dataset using the verification message comprises registering the verification message in the second dataset, and wherein the update of the second dataset using the verification message confirms a successful check of parameters of the verification message by the further DLT node, the parameters comprising at least one quantity of goods to be verified, and wherein the checking of the parameters comprises checking the quantity of goods to be verified for consistency within a second predefined tolerance range with the first sensor value quantifying the quantity of goods delivered; performing a third update of the first dataset by the DLT node by using the third update message, wherein the third update of the first dataset includes registering the validation message in the first dataset.

[0157] For example, the DLT node is configured to perform one or more of the above-described method steps of the DLT node assigned to the purchaser according to an exemplary embodiment of the method for computer-implemented monitoring of goods delivery. For example, the DLT node is configured to perform each of the above-described method steps of the DLT node assigned to the purchaser according to an exemplary embodiment of the method for computer-implemented monitoring of goods delivery.

[0158] Here, a "processor" is a logic circuit used to execute program instructions. The logic circuit may be implemented on one or more discrete components, particularly one or more chips. In particular, "processor" refers to a microprocessor or a microprocessor system consisting of multiple processor cores and / or microprocessors.

[0159] As used herein, "program" or "program instructions" means, without limitation, any type of computer program containing machine-readable instructions for controlling the functions of a computer.

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

[0161] "Non-volatile memory" here means an electronic memory for the permanent storage of data. Non-volatile memory can be configured as a non-alterable memory, also known as a read-only memory (ROM), or as an alterable memory, also known as a non-volatile memory (NVM). In particular, it can be an EEPROM, for example a flash EEPROM (simply called flash). Non-volatile memory is characterized by the fact that the data stored on it is retained even after the power supply is turned off.

[0162] "Volatile memory" is understood here to mean an electronic memory for temporary storage of data, characterized by the fact that the stored data is lost after the power supply is turned off. In particular, this may refer to a volatile direct access memory, also known as random access memory (RAM), or to the volatile working memory of a processor.

[0163] Here, a "protected memory area" refers to an area of ​​an electronic memory that can only be accessed, i.e., read or write, via the processor of the corresponding electronic device. According to an embodiment, access from the processor coupled to the memory is only possible if the conditions required for that purpose are met. This may be, for example, cryptographic conditions, in particular successful authentication of the access request and / or successful authorization checks.

[0164] By "communication interface" here is meant an interface through which data can be received and transmitted, which can be configured in a contact or contactless manner. The communication interface may be an internal or external interface that is connected to an associated device, for example by a cable or wirelessly.

[0165] For example, the communication may take place over a network. "Network" is understood here to mean any transmission medium having a connection for communication, in particular a local connection or local network, in particular a local area network (LAN), a private network, in particular an intranet, or a virtual private network (VPN). For example, the computer system may have a standard wireless interface for connecting to a WLAN. It may also be a public network such as the Internet. Depending on the embodiment, this connection may also be established via a mobile wireless network.

[0166] "Mobile radio network" is understood here and below to mean a digital cellular mobile radio network that may be built according to a mobile communication standard such as GSM, UMTS, LTE, CDMA or other standard.

[0167] A further embodiment includes a DLT node of a limited-access DLT system for computer-implemented monitoring of delivery of goods from a seller to a buyer. The DLT node is implemented on a DLT server of the DLT system and assigned to the seller. The DLT server includes a processor and a memory having program instructions. The program instructions provide at least one smart contract on the DLT node. Further, the program instructions providing the at least one smart contract include program instructions for entering and checking delivery orders, order confirmations, and shipped goods logs during the delivery of goods from the seller to the buyer to verify the delivery of goods.

[0168] Execution of the program instructions by the processor causes the processor to control the DLT node such that, in the process of initiating a delivery of an item in the DLT system, the DLT node: receiving at least one first dataset from a further DLT node of the buyer, created by the further DLT node, the first dataset being a first portion of a dataset shared between the DLT node and the further DLT node, the first dataset including at least one or more physical characteristics of goods to be delivered according to a first specification of a delivery order, the physical characteristics of the first specification including at least one quantity of the goods to be delivered; creating a second dataset, the second dataset being a second part of the shared dataset and managed by the DLT node, and performing a first update of the second dataset by the DLT node based on the first dataset, the first update comprising entering at least one or more of the physical characteristics of the first item into the second dataset, the at least one or more entered physical characteristics of the first item comprising a quantity of goods to be delivered; receiving, by said DLT node, via a first network, a seller order confirmation, said order confirmation including a second specification of said one or more physical characteristics of the goods to be delivered; checking the second specification for consistency with the first specification by using the at least one smart contract; performing a second update of said second dataset by said second DLT node by using the first result of the check of said second details; · forwarding at least one third update message from said DLT node to said further DLT node for updating said first data set;

[0169] A further embodiment includes a DLT node, wherein the program instructions providing the at least one smart contract include program instructions for entering and checking a shipment goods log during delivery of goods from a seller to a buyer, wherein execution of the program instructions by a processor of the DLT node causes the processor to control the DLT node such that during logging of goods delivery in the DLT system, the DLT node: receiving, by said DLT node, a shipping goods log from the seller via said first network, said shipping goods log including one or more first sensor values ​​of said one or more physical characteristics of the shipped goods according to said second specification detected by one or more first physical sensors assigned to the seller, said one or more first sensor values ​​including at least one first sensor value quantifying the amount of goods delivered; checking, by using the at least one smart contract, the one or more first sensor values ​​of a shipping goods log for consistency within a predefined first tolerance with the one or more physical characteristics of goods to be delivered according to the shared dataset, wherein the checked first sensor values ​​include at least the first sensor value quantifying a quantity of goods to be delivered; performing, by the DLT node, a third update of the second data set by using a second result of checking the one or more first sensor values ​​of the shipping goods log; · forwarding at least one second update message from said DLT node to said further DLT node for updating said first data set;

[0170] A further embodiment includes a DLT node, wherein the program instructions providing the at least one smart contract include program instructions for verifying delivery of an item, wherein execution of the program instructions by a processor of the DLT node causes the processor to control the DLT node such that, in the process of verifying delivery of an item in a DLT system, the DLT node: checking parameters of a validation message for validating the delivery of goods by the DLT node by using the at least one smart contract, the parameters including at least one quantity of goods to be validated, and the checking of the parameters including checking the quantity of goods to be validated for consistency within a predefined second tolerance with the first sensor value quantifying the quantity of a previous item to be delivered; performing a fourth update of the second dataset by the DLT node if the quantity of goods to be verified matches the first sensor value quantifying the quantity of goods delivered within a second predefined tolerance, the fourth update comprising registering the validation message in the second dataset by the DLT node by using the at least one smart contract; · forwarding at least one third update message from said DLT node to said further DLT node for updating said first data set;

[0171] For example, the DLT node is configured to perform one or more of the above-described method steps of a DLT node assigned to a seller according to an exemplary embodiment of a method for computer-implemented monitoring of goods delivery.For example, the DLT node is configured to perform each of the above-described method steps of a DLT node assigned to a seller according to an exemplary embodiment of a method for computer-implemented monitoring of goods delivery.

[0172] A further embodiment includes a DLT system for computer-implemented monitoring of delivery of goods from a seller to a buyer. The DLT system includes a first DLT node assigned to the buyer and a second DLT node assigned to the seller. 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.

[0173] The DLT system is configured to perform an initialization of the delivery of goods in the DLT system, the initialization including: receiving, by the first DLT node, a delivery order from the buyer via a first network for goods to be delivered from a seller to a buyer, the delivery order defining one or more physical characteristics of the goods to be delivered as first details, the physical characteristics of the first details including at least one quantity of the goods to be delivered; creating a first dataset managed by the first DLT node and entering at least the one or more physical characteristics of the delivery order into the first dataset by the first DLT node by using the at least one smart contract, the first dataset being a first portion of a dataset shared between the first DLT node and the second DLT node; transferring at least said first data set from said first DLT node to said second DLT node; creating a second dataset, the second dataset being a second part of the shared dataset and managed by the second DLT node, and performing a first update of the second dataset by the second DLT node based on the first dataset, the first update including entering at least one or more of the physical characteristics of the first item into the second dataset, the at least one or more entered physical characteristics of the first item including a quantity of goods to be delivered; receiving, by the second DLT node, via the first network, a seller order confirmation, the order confirmation including a second description of the one or more physical characteristics of the goods to be delivered; checking the second specification for consistency with the first specification by using the at least one smart contract; performing a second update of the second dataset by the second DLT node by using the first result of the check of the second details; forwarding at least one first update message from the second DLT node to the first DLT node; performing a first update of said first dataset by said first DLT node by using said first update message;

[0174] A further embodiment includes a DLT system further configured to perform logging of item deliveries in the DLT system, wherein the at least one smart contract includes program instructions for entering and checking a shipped item log during the course of delivering the item from the seller to the buyer, the logging including: receiving, by the second DLT node, a shipping goods log from the seller via the first network, the shipping goods log including one or more first sensor values ​​for the one or more physical characteristics of the shipped goods according to the second specification detected by one or more first physical sensors assigned to the seller, the one or more first sensor values ​​including at least one first sensor value quantifying the quantity of the delivered goods; checking, by using the at least one smart contract, the one or more first sensor values ​​of the shipping goods log for conformance within a first predefined tolerance with the one or more physical characteristics of goods to be delivered according to the shared dataset, wherein the checked first sensor values ​​include at least the first sensor value quantifying a quantity of goods to be delivered; performing, by the second DLT node, a third update of the second dataset using a second result of checking the one or more first sensor values ​​of the shipping goods log; sending at least a second update message from the second DLT node to the first DLT node; performing a second update of the first dataset by the first DLT node by using the second update message;

[0175] A further embodiment includes a DLT system further configured to perform a verification of item delivery in the DLT system, wherein the at least one smart contract includes program instructions for verifying item delivery. The verification includes: checking parameters of a validation message for validating the delivery of goods by the second DLT node by using the at least one smart contract, the parameters including at least one quantity of goods to be validated, and the checking of the parameters including checking the quantity of goods to be validated for consistency with the first sensor value quantifying the quantity of goods delivered within a second predefined tolerance; performing a fourth update of the second dataset by the DLT node if the quantity of goods to be verified matches the first sensor value quantifying the quantity of goods delivered within a second predefined tolerance, the fourth update comprising registering the validation message in the second dataset by the second DLT node by using the at least one smart contract; forwarding at least a third update message from the second DLT node to the first DLT node; performing a third update of the first dataset by the first DLT node by using the third update message, wherein the third update of the first dataset includes registering the validation message in the first dataset.

[0176] For example, the DLT system may be configured to implement one or more of the aforementioned exemplary embodiments of a method for computer-implemented monitoring of item delivery. For example, the DLT system may be configured to perform each of the aforementioned exemplary embodiments of a method for computer-implemented monitoring of item delivery.

[0177] A further embodiment includes a computer program for monitoring delivery of goods from a seller to a buyer using a limited-access DLT system including a first DLT node assigned to the buyer and a second DLT node assigned to the seller, the computer program providing at least one smart contract, the at least one smart contract including program instructions for entering and checking delivery orders and order confirmations.

[0178] The computer program includes program instructions for initializing the delivery of goods in a DLT system. The initialization includes: receiving, by the first DLT node, a delivery order from a buyer via a first network for goods to be delivered from a seller to a buyer, the delivery order defining one or more physical characteristics of the goods to be delivered as a first specification, the physical characteristics of the first specification including at least one quantity of the goods to be delivered; creating a first dataset managed by the 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 by using the at least one smart contract, the first dataset being a first portion of a dataset shared between the first DLT node and the second DLT node; transferring at least said first data set from said first DLT node to said second DLT node; creating a second dataset, the second dataset being a second part of the shared dataset and managed by the second DLT node, and performing a first update of the second dataset by the second DLT node based on the first dataset, the first update including entering at least one or more of the physical characteristics of the first item into the second dataset, the at least one or more entered physical characteristics of the first item including a quantity of goods to be delivered; receiving, by the second DLT node, a seller order confirmation via the first network, the order confirmation including a second specification of the one or more physical characteristics of the goods to be delivered; checking the second specification for consistency with the first specification by using the at least one smart contract; performing a second update of the second dataset by the second DLT node by using the first result of the check of the second details; forwarding at least one first update message from the second DLT node to the first DLT node; performing a first update of said first dataset by said first DLT node by using said first update message;

[0179] A further embodiment includes a computer program product further comprising program instructions for logging item deliveries in a DLT system, wherein the at least one smart contract comprises program instructions for entering and checking a shipped item log during the course of delivering items from a seller to a buyer. The log includes: receiving, by the second DLT node, a shipping goods log from the seller via the first network, the shipping goods log including one or more first sensor values ​​of the one or more physical characteristics of the shipped goods according to the second specification detected by one or more of the first physical sensors assigned to the seller, the one or more first sensor values ​​including at least one first sensor value quantifying the amount of goods delivered; checking, by using the at least one smart contract, the one or more first sensor values ​​of the shipped item log for consistency with the one or more physical characteristics of the items to be delivered according to the shared dataset within a first predefined tolerance, wherein the checked first sensor values ​​include at least the first sensor value quantifying the amount of items to be delivered; performing, by the second DLT node, a third update of the second dataset by using a second result of checking the one or more first sensor values ​​of the shipping goods log; sending at least a second update message from the second DLT node to the first DLT node; performing a second update of the first dataset by the first DLT node by using the second update message;

[0180] A further embodiment includes a computer program product further comprising program instructions for verifying delivery of goods in a DLT system, wherein the at least one smart contract comprises program instructions for verifying delivery of goods. The verification includes: checking parameters of a validation message for validating the goods delivery by the second DLT node by using the at least one smart contract, wherein the parameters include at least one quantity of goods to be validated, and wherein checking the parameters includes checking the quantity of goods to be validated for conformance with the first sensor value quantifying the quantity of goods to be delivered within a second predefined tolerance; performing a fourth update of the second dataset by the second DLT node if the quantity of goods to be verified matches the first sensor value quantifying the quantity of goods to be delivered within the second predefined tolerance range, the fourth update comprising registering the validation message in the second dataset by the second DLT node by using the at least one smart contract; forwarding at least one third update message from the second DLT node to the first DLT node; performing a third update of the first dataset by the first DLT node by using the third update message, wherein the third update of the first dataset includes registering the validation message in the first dataset.

[0181] For example, the computer program may be configured to perform one or more of the above-described exemplary embodiments of the method for computer-implemented monitoring of item delivery. For example, the computer program may be configured to perform each of the above-described exemplary embodiments of the method for computer-implemented monitoring of item delivery.

[0182] In a further embodiment, a computer-readable data carrier or computer-readable medium is defined having stored thereon program instructions which, when executed by at least one processor (or at least one electronic device), configure the at least one processor (or at least one electronic device) to perform a method according to any one of the preceding embodiments. In this case, the program instructions may correspond to program instructions of a computer program according to an embodiment. It is understood that several data carriers or media may be provided which can be installed on individual processors or electronic devices for performing the provided methods. [Brief explanation of the drawings]

[0183] Hereinafter, embodiments of the present invention will be described in more detail with reference to the drawings. [Figure 1A] 1 shows a schematic flow diagram of a first portion of an exemplary method for monitoring item delivery. [Figure 1B] 10 shows a schematic flow diagram of a second portion of an exemplary method for monitoring item delivery. [Figure 2] FIG. 1 shows a schematic flow diagram of logging item deliveries using an incoming item log. [Figure 3] 1 shows a schematic block diagram of an exemplary DLT system for computer-implemented monitoring of goods delivery. [Figure 4] 1 shows a schematic flow diagram of an exemplary method for computer-implemented monitoring of item delivery. [Figure 5] 1 shows a schematic flow diagram of an exemplary method for computer-implemented monitoring of item delivery. [Figure 6] 1 illustrates a schematic flow diagram of an exemplary method for computer-implemented monitoring of item delivery. [Figure 7] 1 shows a schematic block diagram of an exemplary system for computer-implemented monitoring of goods deliveries including electronic payment transactions. [Figure 8A]1 illustrates a first portion of a first exemplary graphical user interface. [Figure 8B] 1 illustrates a second portion of the first exemplary graphical user interface. [Figure 9] 1 illustrates a second exemplary graphical user interface. DETAILED DESCRIPTION OF THE INVENTION

[0184] Corresponding elements in the following embodiments are identified by the same reference numerals.

[0185] 1A and 1B illustrate an exemplary method for computer-implemented monitoring of a delivery of goods from a seller to a buyer using a limited-access DLT system. The DLT system includes a first DLT node assigned to the buyer and a second DLT node assigned to the seller. The DLT system further provides at least one smart contract including program instructions for entering and checking delivery orders, order confirmations, and / or shipped goods logs during the delivery of goods from the seller to the buyer, and / or for verifying the delivery of goods.

[0186] The method includes initializing an item delivery in a DLT system, logging the item delivery in the DLT system, and verifying the item delivery in the DLT system. Initialization is shown in Figure 1A, and logging and verification are shown in Figure 1B.

[0187] In block 200, via a first network, a first DLT node receives a delivery order from a buyer. The delivery order is a delivery order for goods to be delivered by a seller to a buyer. The delivery order defines one or more physical characteristics of the goods to be delivered as first specifications, and the first specifications include at least one quantity of the goods to be delivered.

[0188] In block 202, a first dataset managed by a first DLT node is created, e.g., as a result of receiving a delivery order. This first dataset is a first partial dataset of a shared dataset. The corresponding shared dataset is a dataset that includes the first partial dataset on the first DLT node and a second partial dataset on a second DLT node. Only the first DLT node, and thus the buyer, has permission to edit the first partial dataset, i.e., write permission, while only the second DLT node, and thus the seller, has permission to edit the second dataset, i.e., write permission. Furthermore, as a result of access restrictions in the DLT system, e.g., only the buyer via the first DLT node has read permission to read the first partial dataset, and only the seller has read permission to read the second partial dataset via the second DLT node.

[0189] In the process of creating the first dataset, the one or more physical characteristics of at least the delivery order are also entered into the first dataset by the first DLT node using the at least one smart contract, the one or more physical characteristics entered including at least the quantity of goods to be delivered.

[0190] In block 204, this first data set according to the first specification of the delivery order, or one or more physical characteristics entered in the first data set, is transferred to the second DLT node of the seller. In block 206, the second DLT node creates a second partial data set of the shared data set, into which the one or more physical characteristics entered according to the first specification are entered. In this case, the one or more entered physical characteristics according to the first specification include at least the quantity of the goods to be delivered. As a result, both partial data sets of the shared data set contain identical data, provided, for example, that the seller and buyer agree on the individual parameters of the specification, as described below.

[0191] At block 208, the second DLT node receives an order confirmation from the seller via the first network, the order confirmation including second details of the one or more physical characteristics of the goods to be delivered. Upon receiving the order confirmation, at block 210, the second details are checked for consistency with the first details by the second DLT node using the at least one smart contract, and at block 212, a second data set is updated using the results of the second details check.

[0192] If the second details match the first details, updating the second data set with the test results may include, for example, entering a confirmation of the first details. For example, updating the second data set with the test results may include entering the second details into the second data set in addition to the first details.

[0193] If the second specification differs from the first specification, updating the second data set using the test results may include, for example, replacing or updating the physical characteristic according to the first specification with a different physical characteristic according to the second specification. For example, in the process of updating the second data set, the divergent physical characteristic according to the second specification is entered into the second data set in addition to the first specification. For example, the second specification is entered into the second data set in addition to the first specification.

[0194] Also, in step 214, a first update message is forwarded from the second DLT node to the first DLT node. For example, the first update message indicates whether the second specification is consistent with the first specification. For example, if one or more physical characteristics according to the second specification differ from the first specification, the first update message identifies the one or more divergent 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.

[0195] In step 216, the first DLT node updates the first dataset, i.e., the first partial dataset of the shared dataset, using the first update message. If the second details match the first details, updating the first dataset using the first update message may include, for example, entering a confirmation of the first details. For example, updating the first dataset using the first update message may include entering the second details into the first dataset in addition to the first details.

[0196] If the second specification differs from the first specification, updating the first data set using the first update message may include, for example, replacing or updating the physical characteristics according to the first specification with different physical characteristics according to the second specification. For example, in the process of updating the first data set, the physical characteristics according to the second specification are entered into the second data set in addition to the first specification. For example, the second specification is entered into the second data set in addition to the first specification.

[0197] If the second details are different from the first details, for example, a handshake is performed between the first DLT node and the second DLT node to match the first details with the second details, and the first details and the second details resulting from the match are identical.

[0198] If the second details match the first details, for example, a confirmation message is sent from the second DLT node to the seller over the network. For example, the second details match the first details if identity exists. For example, the second details match the first details if there is no deviation beyond a predefined tolerance. For example, the confirmation message indicates to the seller that an agreement has been reached between the buyer and seller regarding the corresponding goods delivery. The confirmation message also includes, for example, details of the corresponding goods delivery. For example, the corresponding confirmation message acts as a trigger to initiate the corresponding goods delivery.

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

[0200] The method of FIG. 1A preferably continues in FIG. 1B with the logging of goods delivery in the DLT system. When a physical goods delivery is performed, i.e., when the goods to be delivered leave the seller's warehouse, a shipped goods log is created. The corresponding shipped goods log includes one or more sensor values ​​for said one or more physical properties of the shipped goods according to the second specification, which are detected by one or more physical sensors assigned to the seller. Thus, for one or more physical properties for which target values ​​are specified in the second specification, the shipped goods log specifies, in each case, the measured values ​​detected by the sensors, which reflect the actual state of the shipped goods with respect to the corresponding physical property. The corresponding sensor values ​​include at least one sensor value that quantifies the amount of goods delivered, i.e., leaving, delivered goods.

[0201] In block 220, the second DLT node of the seller receives the shipping goods log from the seller via the first network and, in block 222, checks one or more first sensor values ​​of the shipping goods log for consistency with the one or more physical characteristics of the delivered goods. This process checks whether the one or more sensor values ​​of the incoming goods log match one or more physical characteristics according to the shared dataset within a predefined tolerance. If such consistency does not exist, for example, a warning message is sent to the seller and / or the buyer. Such a warning message can trigger a re-delivery by the seller, for example, if the delivery quantity is too low. On the buyer's side, such a warning message can trigger a review of the deviating physical characteristics, for example, upon arrival of the goods. For example, such a warning message can require confirmation of the deviating physical characteristics on the buyer's side for final verification of the goods delivery to be successful.

[0202] In block 224, the second data set is updated by the second DLT node using the results of checking the one or more first sensor values ​​in the shipping item log. For example, the updating may include inputting one or more of the shipping item log and / or sensor values ​​indicated by the shipping item log. For example, all sensor values ​​specified by the shipping item log may be input. For example, only sensor values ​​that deviate from values ​​input into the second data set for physical characteristics of the items to be delivered may be input. For example, for sensor values ​​in the shipping item log that match values ​​input into the second data set for physical characteristics of the items to be delivered, only a confirmation to the effect that the corresponding value for the physical characteristic matches the obtained sensor value may be input into the second data set.

[0203] In block 226, a second update message is sent from the second DLT node to the first DLT node. For example, the second update message includes one or more of the shipped item log and / or sensor values ​​indicated by the shipped item log. For example, the second update message includes all sensor values ​​indicated by the shipped item log. For example, the second update message includes only sensor values ​​that deviate from values ​​entered in the second dataset for physical characteristics of the items to be delivered. For example, for sensor values ​​in the shipped item log that match values ​​entered in the second dataset for physical characteristics of the items to be delivered, the second update message includes only a confirmation to the effect that the corresponding value for the physical characteristic according to the shared dataset matches the detected sensor value.

[0204] In step 228, the first DLT node updates the first dataset, i.e., the first partial dataset of the shared dataset, using the second update message. For example, the update may include inputting one or more of the shipped item log and / or sensor values ​​indicated by the shipped item log. For example, all sensor values ​​specified by the shipped item log may be input. For example, only sensor values ​​for physical characteristics of the delivered items that deviate from values ​​input into the first dataset may be input. For example, for sensor values ​​in the shipped item log that match values ​​of physical characteristics of the delivered items input into the first dataset, only a confirmation to the effect that the corresponding value of the physical characteristic matches the obtained sensor value may be input into the first dataset.

[0205] Finally, verification of the delivery of goods in the DLT system is performed. For this purpose, in block 240, parameters of a 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 quantity of delivered goods to be verified. Checking the corresponding parameters involves checking the quantity of goods to be verified for consistency with a sensor value quantifying the delivered quantity according to the shipping goods log within a predefined tolerance range. If the quantity of goods to be verified matches the sensor value quantifying the delivered quantity of goods within a predefined tolerance range, in block 242, the second data set is updated by the second DLT node with the verification message. The updating involves 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, such as a hash value of the verification message, 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.

[0206] For example, validation may be triggered by receipt of a validation message or by generation of a validation message. For example, generation of a validation message may be triggered by receiving confirmation of receipt of delivered goods from the purchaser. For example, confirmation of receipt may be received in the form of an incoming goods log.

[0207] In step 244, the second DLT node sends a third update message to the first DLT node. For example, the third update message includes the verification message data entered into the second data set during the update. For example, the third update message includes the complete updated second data set. For example, the third update message includes the verification message.

[0208] In step 246, the first DLT node updates the first dataset with the third update message of the second dataset. Updating the first dataset involves registering the validation message in the first dataset. For example, during the registration process, an identifier of the validation message is entered into the first dataset, and a check value, such as a hash value of the validation message, is entered into the first dataset. For example, one or more parameters of the validation message are entered into the first dataset. For example, the validation message is entered into the first dataset.

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

[0210] 2 illustrates an exemplary logging process for goods delivery using a goods receipt log. To this end, the program instructions included in the at least one smart contract are further configured to input and check an incoming goods log during the course of goods delivery from the seller to the buyer.

[0211] Once a physical item delivery is accepted by the purchaser, i.e., once the delivered items arrive at the purchaser's warehouse, an incoming item log is created. The corresponding incoming item log includes one or more sensor values ​​for one or more physical properties of the incoming item according to the first specification, which are acquired by one or more physical sensors assigned to the purchaser. Thus, for one or more physical properties for which target values ​​are specified in the first specification, the incoming item log specifies the measurement values ​​acquired by the sensor in each case, which reflect the actual state of the incoming item with respect to the corresponding physical property. The corresponding sensor values ​​include at least one sensor value that quantifies the amount of delivered, i.e., incoming, item.

[0212] Logging of item delivery in the DLT system according to FIG. 1B in this case includes block 230. In block 230, a first DLT node receives an incoming item log from a buyer via a first network. In addition, the first DLT node checks one or more second sensor values ​​of the incoming item log for consistency with one or more physical characteristics of the item to be delivered. This process checks whether the one or more sensor values ​​of the incoming item log match one or more physical characteristics according to the shared dataset within a predefined tolerance range. If such consistency does not exist, for example, a warning message is sent to the buyer and / or seller. Such a warning message can trigger a re-delivery by the seller, for example, if the delivery amount is too small. On the buyer's side, for example, such a warning message can require the buyer to confirm the deviating physical characteristics in order to successfully finalize the delivery of the item.

[0213] In block 232, the first dataset is updated by the first DLT node using the results of checking one or more first sensor values ​​in the incoming goods log. For example, the update includes inputting one or more of the incoming goods log and / or sensor values ​​indicated by the incoming goods log. For example, all sensor values ​​specified by the incoming goods log are input. For example, only sensor values ​​that deviate from values ​​input into the first dataset for physical characteristics of the delivered goods are input. For example, for sensor values ​​in the incoming goods log that match values ​​for physical characteristics of the delivered goods input into the first dataset, only a confirmation to the effect that the corresponding value for the physical characteristic matches the obtained sensor value is input into the second dataset.

[0214] Also, in step 234, a fourth update message is forwarded from the first DLT node to the second DLT node. For example, the fourth update message includes one or more of the incoming item log and / or the sensor values ​​specified by the incoming item log. For example, the fourth update message includes all sensor values ​​specified by the incoming item log. For example, the fourth update message includes only sensor values ​​that deviate from values ​​entered in the first dataset for physical characteristics of the items to be delivered. For example, for sensor values ​​in the incoming item log that match values ​​entered in the first dataset for physical characteristics of the items to be delivered, the fourth update message includes only a confirmation to the effect that the corresponding value for the physical characteristic according to the shared dataset matches the detected sensor value.

[0215] Finally, in block 236, the second DLT node updates the second dataset, i.e., the second partial dataset of the shared dataset, by using the fourth update message. For example, the update may include inputting one or more of the incoming goods log and / or sensor values ​​indicated by the incoming goods log. For example, all sensor values ​​specified by the incoming goods log are input. For example, only sensor values ​​for physical characteristics of the delivered goods that deviate from values ​​input into the second dataset are input. For example, for sensor values ​​in the incoming goods log that match values ​​for physical characteristics of the delivered goods input into the second dataset, only a confirmation that the corresponding value for the physical characteristic matches the obtained sensor value is input into the second dataset.

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

[0217] 3 illustrates an exemplary DLT system 182 for computer-implemented monitoring of goods delivery from a seller to a buyer. The DLT system 182 includes multiple DLT servers 140, 160. The DLT system 182 includes a first DLT node assigned to the buyer, which is provided by a first DLT server 140 of the DLT system 182. Additionally, the DLT system 182 includes a second DLT node assigned to the seller, which is provided by a second DLT server 160 of the DLT system 182. However, it should be apparent that the DLT nodes may be deployed on a single DLT server, e.g., DLT server 140 or DLT server 160, and this document is not limited to deploying the DLT nodes on separate DLT servers.

[0218] The first DLT server 140 comprises a processor 142 configured to execute program instructions 144. The program instructions 144 implement a buyer's first DLT node on the first DLT server 140. The program instructions 144 implement one or more smart contracts for execution by the first DLT node on the first DLT server 140. The program instructions 144 implementing the one or more smart contracts include program instructions for performing a method for computer-implemented monitoring of goods delivery from a seller to a buyer using a limited-access DLT system 182, such as a method according to FIG. 1A and / or FIG. 1B or portions thereof. The method may include, in any combination, entering and checking a delivery order, order confirmation, and / or a shipped goods log, and / or verifying goods delivery during the course of goods delivery from the seller to the buyer.

[0219] The first DLT server 140 also includes a memory 146 and a communications interface 156. The communications interface 156 is configured to enable the first DLT server 140 to communicate with the buyer's computer system 120, for example, via a network 184. The network 184 may be, for example, the Internet. The communications interface 156 is further designed to communicate with other DLT servers of the DLT system, for example, the second DLT server 160, on which the seller's DLT node is implemented, via a DLT network 180. For example, the DLT network 180 may be part of the network 184. For example, the DLT network 180 may be a standalone network, such as an intranet.

[0220] For example, the protected memory area 152 of the memory 146 of the first DLT server 140 stores the private encryption key 154 of the asymmetric key pair assigned to the buyer's first DLT node. For example, this private encryption key 154 is used as a signing key to generate a digital signature for the first DLT node. The corresponding signature can be checked using the public encryption key 150 of the corresponding asymmetric key pair. For example, the public encryption key 150 is provided as part of a certificate. The buyer's first DLT node makes this public encryption key 150, or a certificate containing the public encryption key 150, available to other DLT nodes, such as the seller's second DLT node, as a signature verification key.

[0221] The second DLT server 160 comprises a processor 162 configured to execute program instructions 164. The program instructions 164 implement a second DLT node of the buyer on the second DLT server 160. The program instructions 164 also implement one or more smart contracts on the second DLT server 160 for execution by the second DLT node. The smart contract on the second DLT node can correspond to the smart contract on the first DLT node and ensure that both DLT nodes define corresponding behavior. The program instructions 164 implementing the one or more smart contracts include program instructions for performing a method for computer-implemented monitoring of goods delivery from a seller to a buyer using a limited-access DLT system 182, such as a method according to FIG. 1A and / or FIG. 1B, or portions thereof. The method may include, in any combination, entering and checking a delivery order, order confirmation, and / or a shipped goods log, and / or verifying goods delivery during the delivery of goods from the seller to the buyer.

[0222] The second DLT server 160 also has a memory 166 and a communications interface 176. The communications interface 176 is configured to allow the first DLT server 160 to communicate with, for example, the seller's computer system 100 via a network 184. The communications interface 176 is further designed to communicate with, for example, other DLT servers of the DLT system, such as the first DLT server 140 on which the seller's DLT node is implemented, via a DLT network 180.

[0223] For example, a protected memory area 172 in the memory 166 of the second DLT server 160 stores a private encryption key 174 of an asymmetric key pair assigned to the seller's second DLT node. For example, this private encryption key 174 is used as a signing key to create a digital signature for the second DLT node. The corresponding signature can be checked using the public encryption key 170 of the corresponding asymmetric key pair. For example, the public encryption key 170 is provided as part of a certificate. The seller's first DLT node makes this public encryption key 170, or a certificate containing the public encryption key 170, available to other DLT nodes, such as the buyer's first DLT node, as a signature verification key.

[0224] During the process of initializing the item delivery, a shared data set is created on the two DLT nodes, the shared data set including a first partial data set 148 on the first DLT node and a second partial data set 168 on the second DLT node. The first partial data set 148 is stored in memory 146 of the first DLT server 140. The second partial data set 168 is stored in memory 166 of the second DLT server 160.

[0225] Only the first DLT node, and therefore the buyer, has the authority to edit the first partial data set, i.e., write permission, while only the second DLT node, and therefore the seller, has the authority to edit the second data set, i.e., write permission. Also, as a result of the access restrictions of the DLT system, for example, only the buyer has read permission to read the first partial data set via the first DLT node implemented in the first DLT server 140, and only the seller has read permission to read the second partial data set via the second DLT node implemented in the second DLT server 160.

[0226] By executing the program instructions 144 by the processor 142, the processor 142 controls the first DLT server 140 such that the first DLT node implemented on the first DLT server 140 receives a delivery order from a buyer for goods to be delivered from a seller to a buyer in the process of initializing a goods delivery in the DLT system 182. For example, the first DLT node receives the delivery order from the buyer's computer system 120 via the network 184. The delivery order defines one or more physical characteristics of the goods to be delivered as a first specification. The physical characteristics of the first specification include at least one quantity of the goods to be delivered.

[0227] The buyer's computer system 120 comprises a processor 130 configured to execute program instructions 132. The program instructions 132 cause the computer system 120 to communicate, for example, via a network 184, with the first DLT server 140 or a buyer's first DLT node implemented on the first DLT server 140. For example, the buyer's computer system 120 transmits a delivery order to the first DLT node. To this end, the computer system 120 comprises a communication interface 136 for communication over the network 184.

[0228] The computer system 120 also includes a memory 122. For example, a protected memory area 126 of the memory 122 of the computer system 120 stores a private encryption key 128 of an asymmetric key pair assigned to the purchaser. For example, the private encryption key 128 is used as a signing key to create a digital signature for the purchaser. The corresponding signature can be checked using the public encryption key 124 of the corresponding asymmetric key pair. For example, the public encryption key 124 is provided as part of a certificate. The computer system 120 makes the public encryption key 124, or a certificate including the public encryption key 124, available to other involved parties, such as the purchaser's first DLT node implemented on the first DLT server, as a signature verification key.

[0229] The first node creates a dataset 148 managed by the DLT node and uses the at least one smart contract to enter at least the one or more physical characteristics of the delivery order into the first dataset 148.

[0230] Furthermore, at least the first data set 148 is transmitted from the first DLT node or DLT server 140 via the DLT network 180 to a second DLT node implemented on the second DLT server 160. The first DLT node receives at least one first update message from the second DLT node or second DLT server 160 via the DLT network 180 regarding an update of the second data set 168 on the second DLT server. The update is performed using the results of a first check that checks second details of the one or more physical characteristics of the goods to be delivered according to the seller's order confirmation for consistency with the first details according to the buyer's delivery order. The first data set 148 is then updated by the first DLT node using the first update message.

[0231] A corresponding order confirmation is received by the second DLT server 160 from the seller's computer system 100, e.g., via the network 184. The buyer's computer system 160 comprises a processor 110 configured to execute program instructions 112. The program instructions 112 cause the computer system 100 to communicate, e.g., via the network 184, with the second DLT server 160 or a second DLT node of the seller implemented on the second DLT server 160. For example, the seller's computer system 100 transmits the order confirmation to the second DLT node. To this end, the computer system 100 comprises a communication interface 116 for communication over the network 184.

[0232] The computer system 100 also includes a memory 102. For example, a protected memory area 106 of the memory 102 of the computer system 100 stores a private encryption key 108 of an asymmetric key pair assigned to the buyer. For example, the private encryption key 108 is used as a signing key to create a digital signature for the seller. The corresponding signature can be checked using the public encryption key 104 of the corresponding asymmetric key pair. For example, the public encryption key 104 is provided as part of a certificate. The computer system 100 makes the public encryption key 104, or a certificate containing the public encryption key 104, available to other involved parties, such as the seller's second DLT node implemented on a second DLT server, as a signature verification key.

[0233] Further, execution of the program instructions by the processor 142 causes the processor 142 to control the first DLT node, in the process of logging item deliveries in the DLT system 182, to receive at least one second update message from the second DLT node via an update of the second dataset 168. This second update is an update using a second check result that checks one or more first sensor values ​​of the shipped item log for consistency, within a first predefined tolerance, with one or more physical characteristics of the delivered items according to the shared dataset. These one or more first sensor values ​​of the shipped item log are acquired by one or more physical sensors 113 assigned to the seller. The checked first sensor values ​​include at least a first sensor value that quantifies the amount of delivered items. The first dataset 148 is then updated by the DLT node using the second update message.

[0234] Finally, execution of the program instructions 144 by the processor 142 causes the processor 142 to control the first DLT node, thereby causing the DLT node to receive at least one third update message from the second DLT node for updating the second dataset 168 using the verification message in the course of verifying delivery of an item in the DLT system 182. Updating the second dataset 168 using the verification message involves registering the verification message in the second dataset 168. In doing so, updating the second dataset 168 using the verification message confirms that the second DLT node has successfully checked parameters of the verification message. These parameters include at least one quantity of the item to be verified. Checking the parameters includes checking the quantity of the item to be verified for consistency within a second predefined tolerance with a first sensor value quantifying the amount to be delivered. Finally, the first DLT node updates the first dataset 148 through the DLT node using the third update message. Updating the first data set 148 includes registering the validation message in the first data set 148 .

[0235] By executing the program instructions 164 by the processor 162, the processor 162 controls the second DLT server 160 such that the second DLT node implemented on the second DLT server 160 receives at least a first data set 148 created by the buyer's first DLT node in the course of initializing a delivery of goods in the DLT system 182, the data set including at least one or more physical characteristics of goods to be delivered according to a first specification of the delivery order. The second DLT node then creates a second data set 168 managed by the DLT node. The second DLT node also updates the created second data set 168. The updating includes inputting at least one or more physical characteristics of the first specification into the second data set 168, the inputted at least one or more physical characteristics of the first specification including the quantity of goods to be delivered.

[0236] Additionally, the second DLT node receives a seller order confirmation from the seller's computer system 100 via the network 184. The order confirmation includes a second description of one or more physical characteristics of the goods to be delivered. The second DLT node checks the second description for consistency with the first description using the one or more smart contracts and updates the second dataset 168 using the resulting check results. Finally, the second DLT node sends at least a first update message to the first DLT node to update the first dataset 148.

[0237] Execution of the program instructions 164 by the processor 162 causes the processor 162 to control the second DLT node, which in turn receives a shipping item log from a sender via the first network 184 in the course of logging item deliveries in the DLT system 182. For example, the second DLT node receives a shipping item log from the seller's computer system 100. The shipping item log includes one or more first sensor values ​​for one or more physical characteristics of the shipping items according to the second specification, which are acquired by one or more physical sensors 114 assigned to the seller.

[0238] The second DLT node checks one or more first sensor values ​​of the shipped goods log for consistency, within a first predefined tolerance, with one or more physical characteristics of the delivered goods according to the shared data set or a second partial data set 168 of the shared data set. To do this, the second DLT node uses one of the one or more smart contracts. The checked first sensor values ​​include at least a first sensor value that quantifies the amount of the delivered goods. The second data set 168 is updated by the second DLT node using the check results. Furthermore, the second DLT node sends at least a second update message to the first DLT node to update the first data set 148.

[0239] Finally, execution of the program instructions 164 by the processor 162 causes the processor 162 to control the second DLT node to check parameters of a verification message for verifying the delivery of goods using one or more smart contracts in the process of the second DLT node verifying the delivery of goods in the DLT system 182. The checked parameters include at least the quantity of goods to be verified. Checking the parameters includes checking the quantity of goods to be verified for consistency within a predefined tolerance with a first sensor value quantifying the delivered quantity of goods. If the quantity of goods to be verified matches the first sensor value quantifying the delivered quantity of goods within a predefined tolerance, the second DLT node updates the second dataset 168. This update includes registering the verification message in the second dataset 168 by the second DLT node using at least one of the one or more smart contracts. Furthermore, the second DLT node sends a corresponding update message for registering the verification message to the first DLT node to update the first dataset 148.

[0240] According to an alternative embodiment, the first DLT node and the second DLT node may be implemented on a common DLT server of the DLT system 180. According to an alternative embodiment, the first DLT node may be implemented, for example, on the buyer's computer system 120 and / or the second DLT node may be implemented on the seller's computer system 100.

[0241] FIG. 4 shows a schematic flow diagram of an exemplary method for computer-implemented monitoring of item delivery from a seller to a buyer. In step 300, the buyer submits a delivery order 190 to a DLT node associated with the buyer in the DLT system 182. In addition to an order number and a product number, the delivery order 190 specifies, for example, the quantity of the item to be delivered as a physical characteristic of the item. As a result of submitting the delivery order 190, a first partial dataset of a shared dataset is generated in the DLT system 182 using the delivery order 190. The data of the delivery order 190 is also transferred to the seller. At this stage, the status of the item delivery is "Proposed." In step 302, the seller submits an order confirmation 191 to a DLT node assigned to the seller in the DLT system 182. In addition to the order number and product number, the order confirmation 191 specifies, for example, the quantity of the item to be delivered as a physical characteristic of the corresponding item. For example, the confirmation is entered into a second partial dataset of the shared dataset on the seller's DLT node in the DLT system 182. If the quantity specified in the order confirmation 191 matches the quantity specified in the delivery order 190, the goods delivery takes on a "confirmed" status in the DLT system 182. Any updates to the data in the order confirmation 191 or the second partial data set are also forwarded to the purchaser.

[0242] Further, for example, in step 304, the buyer can send an update 192 of the delivery order 190 with a new quantity specification to the DLT system 182 or to a first DLT node assigned to the buyer in the DLT system 182. For example, the first DLT node enters this update of the item delivery details into a first partial data set and also forwards it to the seller or a second DLT node assigned to the seller. In this case, the status of the item delivery in the DLT system 182 changes, for example, to "updated." In step 306, the seller sends an update 193 of the order confirmation 191 with a new quantity specification to the DLT system 182 or to a first DLT node assigned to the seller in the DLT system 182. The second DLT node enters this update of the confirmation of the item delivery details into a second partial data set and also forwards it to the buyer or the first DLT node assigned to the buyer. In this case, the status of the item delivery in the DLT system 182 returns to, for example, "confirmed." If the goods have been delivered, in step 194, the seller sends a verification message, such as an invoice, to the DLT system for verification or to update the shared dataset using the verification message 194. For example, verification may involve checking the verification message information against the goods delivery details stored in the shared dataset. If they match, the verification message is registered in the shared dataset in DLT system 182. For example, the invoice number in the verification message is stored in the shared dataset. In this case, the status of the goods delivery in DLT system 182 changes, for example, to "completed."

[0243] FIG. 5 shows a further schematic flow diagram of an exemplary method for computer-implemented monitoring of goods delivery from a seller to a buyer. In this case, using one or more smart contracts, the buyer's first DLT node and the seller's second DLT node perform the following steps: In step 320, the first DLT node creates a first partial dataset of a shared dataset and updates it with data from the buyer's delivery order. This first partial dataset is sent to the seller's second DLT node. The second DLT node creates a second partial dataset of the shared dataset with data from the delivery order. The status of the goods delivery at this stage is "Proposed." In step 322, the second DLT node updates the second partial dataset with data from the order confirmation from the seller. In addition, an update message regarding the update of the second partial dataset using the order confirmation is sent to the buyer's first DLT node. The first DLT node updates the first partial dataset accordingly. Thereafter, for example, one or more further update steps and / or cancellations may be performed.

[0244] For example, in step 324, the first DLT node updates the first partial data set based on the delivery order update. For example, the quantity of goods to be delivered, delivery date, price, etc. are updated. This update is sent to the second DLT node. The second DLT node records this update in the second partial data set. The status of the goods delivery then changes to "updated." In step 326, the second DLT node confirms the proposed update, for example, based on the updated order confirmation, and enters this confirmation into the second partial data set. This confirmation of the update is sent to the first DLT node. The first DLT node records this confirmation, for example, in the first partial data set. The status of the goods delivery then returns to "confirmed."

[0245] Updates to delivery terms can also be initiated by the seller. For example, in step 328, the second DLT node updates the second partial data set based on updates to the order confirmation. For example, the quantity of goods to be delivered, the delivery date, the price, etc. are updated. This update is sent to the first DLT node. The first DLT node records this update, for example, in the first partial data set. The status of the goods delivery then changes to "updated." In step 330, the first DLT node confirms the proposed update, for example, based on the updated delivery order, and enters this confirmation into the first partial data set. This confirmation of the update is sent to the second DLT node. The second DLT node records this confirmation in the second partial data set. The status of the goods delivery then returns to "confirmed."

[0246] Similarly, a product delivery can be canceled by the seller or the buyer. For example, in step 332, the first or second DLT node enters a cancellation in the first or second partial data set based on the received cancellation notification. A cancellation message is also sent to the second or first DLT node. The second or first DLT node records the corresponding cancellation in the second or first partial data set. In this case, the status of the product delivery changes to "canceled," and the method is completed.

[0247] If cancellation is not performed, in step 334, the second DLT node updates the second partial data set based on checking the verification message, e.g., when the goods delivery is completed. If the check is successful, the verification message is registered in the second partial data set, e.g., by entering an identifier of the verification message, such as an invoice number, in the second partial data set. This update is sent to the first DLT node. The first DLT node records this update in the first partial data set, e.g., by also registering the verification message. The status of the goods delivery then changes to "completed."

[0248] Both the first DLT node and the second DLT node according to Figure 5 may have one or more features of the DLT node according to Figure 3 implemented on the first DLT server 140 and the second DLT server 160. Furthermore, the DLT node according to Figure 5 may be configured, at least in part, to perform the method according to Figure 1A and / or Figure 1B or parts thereof.

[0249] FIG. 6 shows a further schematic flow diagram of an exemplary method for computer-implemented monitoring of goods delivery from a seller to a buyer using the DLT system 182. In step 350, the buyer, or the buyer's computer system 120, sends a delivery order to a first DLT node assigned to the buyer in the DLT system 182. In step 352, the seller, or the seller's computer system 100, sends an order confirmation to a second DLT node assigned to the seller in the DLT system 182. Based on the delivery order and the order confirmation, the terms of the goods delivery are entered into two partial datasets of the shared dataset and matched with each other in a two-way match process. This ensures that the terms of the delivery order and the order confirmation are consistent. In the process of executing the delivery of the goods to be delivered, in step 354, the seller, or the seller's computer system 100, sends a goods shipment log to the second DLT node in the DLT system 182. The shipped item log includes sensor values ​​for the physical characteristics of the shipped items acquired by the seller's physical sensors, including at least one sensor value quantifying the amount of the delivered items. Furthermore, in step 356, the seller or the seller's computer system 100 sends a verification message to a second DLT node in the DLT system 182. Based on the results of the two-way match, the shipped item log, and the verification message, a three-way match is performed to check whether the conditions of the actually delivered items and the conditions from the two-way match are consistent with the information in the verification message. This ensures that the information in the verification message is correct. If the verification message is successfully checked, it is registered in the shared dataset.

[0250] 7 shows a further schematic block diagram of an exemplary system for computer-implemented monitoring of goods delivery from a seller to a buyer, including electronic transactions. The system may include a DLT system 182, such as a DLT system according to the embodiment of FIG. 3 or FIG. 4. Payment transactions may be combined with data flows from the monitoring of goods delivery and maintained in a closed data circuit.

[0251] To prepare an electronic payment, in step 360, a subscriber, such as User A, can transfer fiat currency, e.g., euros, to a pooled account at a bank that handles payment transactions. This can be done within the banking system or by using the bank computer system 186. In step 362, a bank or a DLT node associated with the bank in the DLT system 182 records the receipt of the fiat currency in the DLT system 182, e.g., via the bank's banking API or another suitable programming or communication interface. An API (Application Programming Interface) is a programming interface or part of a program that a software system makes available to other programs for integration into the corresponding system. In step 364, the bank automatically allocates e-money, i.e., electronic money, to User A's DLT account. The amount of e-money received in User A's DLT account is equal to the amount of fiat currency transferred. Each subscriber, e.g., User B, can execute a corresponding method to allocate electronic money to their associated DLT account in the DLT system 182. A DLT account can be provided to each DLT node of a subscriber in the DLT system 182.

[0252] User A, as a buyer, can place an order with a seller, e.g., User B, on the ERP system. For example, the order is submitted as a delivery order to User A's DLT node in step 366. For this purpose, User A can use the buyer's computer system, which can be connected to an associated DLT node in DLT system 182 via, for example, an API or any other programming or communication interface. User A's DLT node initiates a goods delivery, e.g., as described above with respect to the embodiment according to FIG. 1A. This sends an order detail to the seller's DLT node, which can forward the order detail to the seller's computer system in step 368. User B can confirm the order, for example, using an ERP system on the seller's computer system. For example, the order detail and confirmation may include ERP data from the seller's ERP system. The seller's computer system can be connected to an associated DLT node in DLT system 182 via an API or any other programming or communication interface.

[0253] The order process is handled by the DLT system 182 between the seller's DLT node and the buyer's DLT node using one or more smart contracts, an example of which is shown in step 370. This is performed, for example, using one of the exemplary methods described in the previous figures for monitoring goods delivery from a seller to a buyer using a limited-access DLT system 182. If a handshake is required, this can be performed (semi-)automatically between the participating DLT nodes. If additional data is required or parameters need to be verified, the participating DLT nodes can communicate with the seller's or buyer's associated computer system to receive input, for example, via their respective ERP systems. The input is then entered into the DLT system 182. Thus, the order process and goods delivery can be performed via the DLT system 182. Goods delivery, and, if necessary, invoice dispatch (which must be performed due to requirements external to the DLT system 182), can be performed in step 372.

[0254] Registering a goods delivery verification message in DLT system 182, for example by issuing an invoice, may trigger an electronic payment transaction from User A's DLT account to User B's DLT account.

[0255] Similar to the issuance of electronic money on a DLT account in a DLT system, in step 374, a subscriber, e.g., User B, can at least partially spend electronic money received in the course of one or more electronic payment transactions via bank transfer. This can be performed via a DLT node assigned to the bank and capable of communicating with the bank's computer system. In step 376, the bank converts the spent electronic money into fiat money and transfers the corresponding fiat money to User B's account via a pool account. Each subscriber, e.g., User A, can execute a corresponding method to spend the electronic money as fiat money to the associated bank account. It should be clear that delivery of goods does not necessarily require spending electronic money as fiat money. Instead, the electronic money can remain in the DLT account for further electronic payment transactions.

[0256] The DLT system 182 may be configured by a bank to record and verify all DLT payment transactions in the DLT system 182, e.g., for AML (Anti-Money Laundering) reasons, i.e., to prevent money laundering. For example, anti-money laundering software belonging to the bank is used to verify the recorded DLT transactions. For example, customer data is analyzed to detect suspicious transactions. To do this, customer data is filtered, categorized according to levels of trust, and checked for anomalies. For example, once the anti-money laundering software has collected enough data and suspicious cases are flagged, a report is generated. Payments can be released or blocked.

[0257] For example, the DLT system 182 also ensures that all payment transactions are processed in a regulatory compliant manner. For example, the at least one smart contract may be used to implement a regulator 378, which collects all transactions for compliance purposes. Further, the at least one smart contract may be used to implement a notary node 380, also known as a notary node, which prevents multiple spending or multiple issuance of the same unit of electronic money.

[0258] 8A and 8B and 9 illustrate exemplary graphical user interfaces (GUIs) for implementing a method for computer-implemented monitoring of goods delivery from a seller to a buyer by using a limited-access DLT system. FIG. 8A illustrates a first portion of a first exemplary graphical user interface. FIG. 8A includes an exemplary representation of data from a first partial dataset 148 of a shared dataset, which reproduces a delivery order of a goods recipient ("buyer"). Further, FIG. 8B illustrates a second portion of the first exemplary graphical user interface. FIG. 8B includes an exemplary representation of data from a second partial dataset 168 of a shared dataset, which reproduces a proposed revised delivery terms on the part of a goods supplier ("seller").

[0259] The graphical user interface shown in FIGS. 8A and 8B includes menus for selecting various fields. These include a "Dashboard," i.e., a graphical user interface for visualizing data, an "Orders" field, a "Wallet," i.e., a digital wallet, a field for "Reports," and a field for "Settings." The current user is also shown ("Logged in as..."). A selection button for creating a new order ("Create a new order") is also shown. Search parameters can also be entered ("Search and Filter"). FIGS. 8A and 8B show an example of a field showing "Orders." In a submenu, the fields "Pending," "Confirmed," "Paid," and "Rejected" can be selected. Each of these fields lists orders that are pending, confirmed, paid, or rejected. The graphical user interface includes a buyer field for the goods recipient and a seller field for the goods supplier.

[0260] 8A shows what the buyer sees, i.e., the "buyer-partner view," showing, for example, the last update time "Last Updated," the status "Updated," "Transaction ID," "Order Number," "Delivery Date," "Product ID Buyer," "Product Name Buyer," "Product ID Seller," "Product Name Seller," "Line Item ID," "Settlement (Days)" item, "Invoice Number," "Invoice Date," "Tax ID," "Tax" item, "Description," the reason for the update "Reason for Update," "Quantity," "Unit" indication, "Price Per Unit" [unit price], "Price Per Unit Unit" [unit price unit], "Total Price," and "Currency." Additionally, an "Accept All" selection element is provided for the seller to accept all information or details according to the buyer's first partial dataset 148.

[0261] The representation of the seller's second partial dataset 168 in FIG. 8B shows what the seller sees when the user is logged in as the seller of the item, i.e., "Seller - My View," showing, for example, the time of the last update "Last Update," the status "Updated," "Transaction ID," "Order Number," "Delivery Date," "Product ID Buyer," "Product Name Buyer," "Product ID Seller," "Product Name Seller," "Line Item ID," "Settlement (Days)" item, "Invoice Number," "Invoice Date," "Tax ID," "Tax" item, "Description," "Reason for Update," "Quantity," "Units" item, "Price Per Unit," "Price Per Unit Unit," "Total Price," and "Currency." This information can be changed by the seller, except for the time of the last update "Last Update," the status "Updated," "Transaction ID," "Order Number," "Product ID Buyer," and "Product Name Buyer." Additionally, options "Cancel," "Submit," and "Confirm" are provided to cancel, submit, or confirm the information or updates to the information, respectively.

[0262] FIG. 9 shows an example dashboard for a merchant's DLT node with an overview of current orders and payments. The graphical user interface shown in FIG. 9 includes menus for selecting different fields. These include a "Dashboard" (i.e., a graphical user interface for visualizing data), an "Orders" field, a "Wallet" (i.e., a digital wallet), a field for "Reports," and a field for "Settings." Additionally, there is an indication of who is currently logged in ("Logged in as..."). FIG. 9 shows an example dashboard. The dashboard includes information about "Currently Available Cash," "Cash Available Tomorrow," and "Cash Available the Day After Tomorrow." The dashboard also includes "Summary," "Latest Orders," "Latest Updates," and a list of "Payments Over Time" payments. The overview field includes a graphical representation, e.g., in the form of a histogram, of various information about the current date, "Today." This information includes "Wallet Balance," details of inbound payments ("Deposits"), outbound payments ("Withdrawals"), and rejected payments and / or delivery orders under "Rejections." The "Recent Orders" list includes a list of current orders and, for example, specifies how many current orders remain unlisted. The "Recent Updates" list contains the most recent updates and indicates, for example, when the most recent update occurred ("Last Updated"). For example, this occurred "4 minutes ago". Finally, the "On Time Payments" list indicates the percentage of incoming goods "Incoming" and outgoing goods "Outgoing" that were paid on time. Finally, the dashboard contains information about the number of "Transactions" that are in progress ("Pending"), incomplete ("Scheduled"), paid ("Paid"), and rejected ("Rejected").

[0263] The present invention has been described above in an illustrative manner with reference to specific embodiments. The present invention may be further described, purely by way of example and without limitation, by the following embodiments. The following embodiments may include preferred embodiments. Thus, the term "feature collection" as used herein may refer to such "preferred embodiments."

[0264] 1. A computer-implemented method for monitoring delivery of goods from a seller to a buyer using a limited-access DLT system, the DLT system including a first DLT node assigned to the buyer and a second DLT node assigned to the seller, the DLT system providing at least one smart contract including program instructions for entering and checking delivery orders and order confirmations; The method includes initializing the item delivery in the DLT system, the initialization comprising: receiving, by the first DLT node, via a first network, a delivery order from the buyer for goods to be delivered by the seller to the buyer, the delivery order defining, as first specifications, one or more physical characteristics of the goods to be delivered, the physical characteristics of the first specifications including at least one quantity of the goods to be delivered; creating, by the first DLT node by using the at least one smart contract, a first dataset managed by the first DLT node and inputting at least the one or more physical characteristics of the delivery order into the first dataset, the first dataset being a first portion of a dataset shared between the first DLT node and the second DLT node; transferring at least said first data set from said first DLT node to said second DLT node; creating a second dataset managed by the second DLT node, which is a second part of the shared dataset, and performing a first update of the second dataset by the second DLT node based on the first dataset, the first update including entering at least one or more of the physical characteristics of the first item into the second dataset, the at least one or more entered physical characteristics of the first item including the quantity of goods to be delivered; receiving, by the second DLT node, an order confirmation from the seller via the first network, the order confirmation including a second description of one or more physical characteristics of the goods to be delivered; checking the second specification for consistency with the first specification by using the at least one smart contract; performing a second update of the second dataset by the second DLT node by using the first result of the check of the second details; forwarding at least a first update message from said second DLT node to said first DLT node; performing a first update of the first dataset by the first DLT node by using the first update message; A method comprising: 2. The at least one smart contract includes program instructions for entering and checking a shipping goods log during the delivery of goods from the seller to the buyer, the method also including logging the delivery of goods in the DLT system, wherein the logging includes: receiving, by the second DLT node, a shipping goods log from the seller via the first network, the shipping goods log including one or more first sensor values ​​for the one or more physical characteristics of the shipping goods according to the second specification detected by one or more first physical sensors assigned to the seller, the one or more first sensor values ​​including at least one first sensor value quantifying the amount of goods delivered; checking, by using the at least one smart contract, the one or more first sensor values ​​of the shipped goods log for conformance with the one or more physical characteristics of the goods to be delivered according to the shared dataset within a first predefined tolerance, wherein the checked first sensor values ​​include at least the first sensor value quantifying the quantity of goods to be delivered; performing, by the second DLT node, a third update of the second dataset using a second result of checking the one or more first sensor values ​​of the shipping goods log; sending at least a second update message from the second DLT node to the first DLT node; performing a second update of the first dataset by the first DLT node by using the second update message; The method according to Feature Set 1, comprising: 3. The at least one smart contract includes program instructions for verifying the delivery of the goods, and the method further includes verifying the delivery of the goods in the DLT system, the verification including: checking parameters of a validation message for validating the goods delivery by the second DLT node by using the at least one smart contract, the parameters including at least one quantity of goods to be validated, and the checking of the parameters including checking the quantity of goods to be validated for conformance with the first sensor value quantifying the quantity of goods delivered within a second predefined tolerance; performing a fourth update of the second dataset by the second DLT node if the quantity of goods to be verified matches the first sensor value quantifying the quantity of goods delivered within the second predefined tolerance, the fourth update comprising registering the validation message in the second dataset by the second DLT node using the at least one smart contract; forwarding at least a third update message from the second DLT node to the first DLT node; performing a third update of the first dataset by the first DLT node by using the third update message, wherein the third update of the first dataset includes registering the validation message in the first dataset; The method of Feature Set 1 or 2, comprising: 4. The method of any one of feature sets 1 to 3, further comprising a step of signing, by the first DLT node, the data transferred from the first DLT node to the second DLT node, and wherein the at least one smart contract on the second DLT node is configured to check the signature of the transferred data. 5. The method of any one of feature sets 1 to 4, further comprising a step of signing, by the second DLT node, the data transferred from the second DLT node to the first DLT node, and wherein the at least one smart contract on the second DLT node is configured to check the signature of the transferred data. 6. The method of any one of feature sets 1 to 5, wherein data transfer between the first DLT node and the second DLT node is performed over one or more communication links that are cryptographically secured using end-to-end encryption. 7. The method of feature set 6, wherein establishing the one or more cryptographically protected communication connections includes, in each case, mutual authentication of the first DLT node and the second DLT node. 8. A method according to any one of feature sets 1 to 7, wherein the check of the second specification for consistency with the first specification during the initialization is an identity check. 9. The initialization further comprises: and if the one or more physical characteristics according to the second specification entered in the second dataset differ from the one or more physical characteristics according to the first specification from the first dataset, performing a handshake between the first DLT node and the second DLT node to match the first specification of the first dataset with the second specification of the second dataset, such that the resulting first specification and the second specification are identical. The method according to feature set 8. 10. A method according to any one of feature sets 1 to 7, wherein the checking of the second specifications for consistency with the first specifications during the initialization is a check for consistency within a third predefined tolerance in accordance with the at least one smart contract. 11. The initialization is: and if one or more deviations between the one or more physical characteristics according to the second specification entered in the second dataset and the one or more physical characteristics according to the first specification from the first dataset are greater than the predefined third tolerance, performing a handshake between the first DLT node and the second DLT node to match the first specification of the first dataset with the second specification of the second dataset, such that the resulting first and second specifications are identical within the predefined third tolerance. The method according to feature collection 10. 12. The program instructions included in the at least one smart contract are further configured to input and check an incoming goods log during the course of goods delivery from the seller to the buyer, wherein the log record of the goods delivery in the DLT system comprises: receiving, by the first DLT node, an incoming goods log from the purchaser via the first network, the incoming goods log including one or more second sensor values ​​for the one or more physical characteristics of the incoming goods according to the first specification detected by one or more of the second physical sensors assigned to the purchaser, the one or more second sensor values ​​including at least one second sensor value quantifying the amount of goods delivered; checking, by using the at least one smart contract, the one or more second sensor values ​​of the incoming goods log for consistency with the one or more physical characteristics of the goods to be delivered according to the shared dataset and with the one or more first sensor values ​​according to the outgoing goods log, within a fourth predefined tolerance, wherein the checked second sensor values ​​include at least the second sensor value quantifying the amount of goods delivered; performing a fourth update of the first dataset by the first DLT node by using a third result of checking the one or more second sensor values ​​of the incoming goods log; forwarding at least a fourth update message from the first DLT node to the second DLT node; performing a fifth update of the second data set by the second DLT node by using the fourth update message; 12. A method according to any one of feature sets 1 to 11, comprising: 13. The method of any one of feature sets 1 to 12, wherein the validation message includes an invoice, the program instructions included in the at least one smart contract are further configured to create the invoice, the creation of the invoice is performed by the second DLT node using the at least one smart contract, and the validation message parameters are checked during the creation of the invoice. 14. The method of any one of feature sets 1 to 12, wherein the invoice is received from a first ERP system of the seller that creates the invoice. 15. The method of any one of feature sets 1 to 14, wherein in the process of logging the item delivery, the data entered into the shared dataset provided in the DLT system is mirrored data of the item delivery from the first ERP system of the seller and / or the second ERP system of the buyer, the first and / or second ERP system being configured to control the processing of the item delivery, and data consistency between the shared dataset and the ERP systems is ensured by entering mirrored data. 16. The method of any one of feature sets 1 to 14, wherein the processing of the item delivery is controlled by the at least one smart contract, and program instructions of the at least one smart contract are also configured to control the processing of the item delivery. 17. The method of any one of feature sets 1 to 16, wherein the first network is a public network. 18. A prerequisite for receiving the delivery order of the buyer by the first DLT node is successful authentication of the buyer by the first DLT node; and / or a prerequisite for receiving the order confirmation of the seller by the second DLT node is successful authentication of the seller by the second DLT node; and / or a prerequisite for receiving the shipment goods log from the seller by the second DLT node is successful authentication of the seller by the second DLT node; and / or A prerequisite for receiving the incoming goods log from the purchaser by the first DLT node is successful authentication of the purchaser by the first DLT node; 18. A method according to any one of feature sets 1 to 17. 19. A prerequisite for the first DLT node to use the delivery order of the buyer is a successful signature check of the buyer's signature by the first DLT node; and / or a prerequisite for the second DLT node to use the order confirmation of the merchant is a successful signature check of the order confirmation signature by the second DLT node; and / or a prerequisite for the second DLT node to use the shipping goods log from the seller is a successful signature check of the signature of the shipping goods log by the second DLT node; and / or A prerequisite for the first DLT node to use the incoming goods log of the purchaser is a successful signature check of the signature of the incoming goods log by the first DLT node; 19. A method according to any one of feature sets 1 to 18. 20. The method of any one of feature sets 1 to 19, wherein the first DLT node and the second DLT node are provided by one or more DLT servers of the DLT system. 21. The method of feature collection 20, wherein the one or more DLT servers of the DLT system are located in one or more data centers protected against unauthorized access. 22. The method of any one of feature sets 1 to 21, wherein data transmission between the DLT nodes occurs via a second network. 23. The method of feature set 22, wherein the second network is a private network or a public network. 24. The method of any one of feature sets 1 to 23, wherein the program instructions included in the at least one smart contract are further configured to trigger an electronic payment transaction, and the payment transaction by the smart contract is triggered when the validation message is registered in the DLT system. 25. The method of feature set 24, wherein the triggered electronic payment transaction is an IBAN transfer from the buyer's IBA account to the seller's IBAN account. 26. The method of feature set 24, wherein the triggered electronic payment transaction is a programmable amount transaction executed using the DLT system. 27. The method of feature set 26, wherein the DLT system is configured to transfer the invoice amount due from an account belonging to the buyer for programmable currency to an account belonging to the seller for programmable currency, and the DLT system is further configured, for example, to convert a fiat amount in a fiat account assigned to the buyer into a programmable currency amount in an account belonging to the buyer for programmable currency. 28. The method of one of feature sets 26 or 27, wherein the payment transaction is logged in the DLT system using the at least one smart contract, and by using the smart contract, for example, electronic account statements relating to the logged payment transaction are also issued for the buyer and / or the seller. 29. A shared dataset of a limited-access DLT system for computer-implemented monitoring of delivery of goods from a seller to a buyer using the limited-access DLT system, the shared dataset including a first portion, the first portion being a first dataset managed by a first DLT node assigned to the buyer, and the shared dataset further including a second portion, the second portion being a second dataset managed by a second DLT node assigned to the seller. 30. Use of the shared data set described in feature set 29 to initialize the item delivery in the DLT system. 31. Use of a shared dataset according to feature collection 29 for logging the item delivery in the DLT system. 32. Use of a shared dataset described in feature collection 29 to verify the delivery of the item in the DLT system. 33. A DLT node of a limited-access DLT system for computer-implemented monitoring of delivery of goods from a seller to a buyer, the DLT node being implemented on a DLT server of the DLT system and assigned to the buyer, the DLT server having a processor and a memory having program instructions, at least one smart contract being provisioned on the DLT node by the program instructions, the program instructions providing the at least one smart contract including program instructions for entering and checking delivery orders and order confirmations. Execution of the program instructions by the processor causes the processor to control the DLT node, thereby causing the DLT node to: receiving, by the first DLT node, via a first network, a delivery order from the buyer for goods to be delivered by the seller to the buyer, the delivery order defining, as first specifications, one or more physical characteristics of the goods to be delivered, the physical characteristics of the first specifications including at least one quantity of the goods to be delivered; creating, by the DLT node by using the at least one smart contract, a first dataset managed by the DLT node and inputting at least the one or more physical characteristics of the delivery order into the first dataset, the first dataset being a first portion of a dataset shared between the first DLT node and a further DLT node in the DLT system assigned to the seller; - transferring at least said first data set from said DLT node to said further DLT node; receiving at least one first update message from the further DLT node via an update of the second data set using a result of a first check that checks a second specification of the one or more physical characteristics of the goods to be delivered according to an order confirmation for consistency with the first specification; performing a first update of the first dataset by the DLT node by using the first update message; and run the DLT node. 34. The program instructions providing the at least one smart contract include program instructions for entering and checking a shipment goods log in the course of delivery of goods from the seller to the buyer, and execution of the program instructions by the processor further causes the processor to control the DLT node, whereby in the course of logging the delivery of goods to the DLT system, the DLT node: receiving at least one second update message from the further DLT node via an update of the second dataset using a second check result of checking one or more first sensor values ​​of a shipped goods log for consistency, within a first predefined tolerance, with the one or more physical characteristics of the goods to be delivered according to the shared dataset, wherein the one or more first sensor values ​​of the shipped goods log are detected by one or more first physical sensors assigned to the seller, and the checked first sensor values ​​include at least the first sensor value quantifying the quantity of the goods delivered; performing a second update of the first dataset by the first DLT node by using the second update message; A DLT node according to feature collection 33, which executes: 35. The program instructions providing the at least one smart contract include program instructions for verifying the delivery of the item, and execution of the program instructions by the processor causes the processor to further control the DLT node, such that in the process of verifying the delivery of the item in the DLT system, the DLT node: receiving at least a third update message from the further DLT node via an update of the second dataset using a verification message, wherein the update of the second dataset using the verification message comprises registering the verification message in the second dataset, and wherein the update of the second dataset using the verification message confirms a successful check of parameters of the verification message by the further DLT node, the parameters comprising at least one quantity of goods to be verified, and the checking of the parameters comprises checking the quantity of goods to be verified for consistency with the first sensor value quantifying the delivered quantity of goods within a second predefined tolerance range; performing a third update of the first dataset by the DLT node by using the third update message, wherein the third update of the first dataset includes registering the validation message in the first dataset; A DLT node according to feature collection 33 or 34, which executes 36. A DLT node described in any one of feature collections 33 to 35, wherein execution of the program instructions by the processor causes the processor to control the DLT node such that the DLT node performs the method steps of the first DLT node of the methods described in any one of feature collections 4 to 28. 37. A DLT node of a limited-access DLT system for computer-implemented monitoring of delivery of goods from a seller to a buyer, the DLT node being implemented on a DLT server of the DLT system and assigned to the seller, the DLT server having a processor and a memory having program instructions, at least one smart contract being provisioned on the DLT node by the program instructions, the program instructions providing the at least one smart contract including program instructions for entering and checking delivery orders and order confirmations; Execution of the program instructions by the processor causes the processor to control the DLT node such that, in the process of initiating the item delivery in the DLT system, the DLT node: receiving at least one first dataset created by a further DLT node of the purchaser from the other DLT node, the first dataset being a first portion of a dataset shared between the DLT node and the further DLT node, the first dataset comprising at least one or more physical characteristics of the goods to be delivered according to a first specification of a delivery order, the physical characteristics of the first specification comprising at least one quantity of the goods to be delivered; creating a second dataset, which is a second part of the shared dataset, managed by the DLT node, and performing a first update of the second dataset by the DLT node based on the first dataset, the first update including entering at least one or more physical characteristics of the first item into the second dataset, the at least one or more entered physical characteristics of the first item including a quantity of goods to be delivered; receiving, by the DLT node, via a first network, an order confirmation from the seller, the order confirmation including a second description of the one or more physical characteristics of the goods to be delivered; checking the second specification for consistency with the first specification by using the at least one smart contract; performing a second update of the second dataset by the second DLT node by using the first result of the check of the second details; forwarding at least one third update message from said DLT node to said further DLT node for updating said first data set; A DLT node that runs 38. The program instructions providing the at least one smart contract include program instructions for entering and checking a shipment goods log during the course of delivery of goods from the seller to the buyer, and execution of the program instructions by the processor further causes the processor to control the DLT system, whereby during the course of logging the goods delivery in the DLT system, the DLT node: receiving, by the DLT node, a shipping goods log from the sender via the first network, the shipping goods log including one or more first sensor values ​​for the one or more physical characteristics of the shipping goods according to the second specification detected by one or more of the first physical sensors assigned to the seller, the one or more first sensor values ​​including at least one first sensor value quantifying the quantity of the delivered goods; checking, by using the at least one smart contract, the one or more first sensor values ​​of the shipped goods log for conformance within a first predefined tolerance with the 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 value quantifying a quantity of goods delivered; performing, by the DLT node, a third update of the second data set using a second result of checking the one or more first sensor values ​​of the shipping goods log; forwarding at least one second update message from said DLT node to said further DLT node for updating said first data set; A DLT node according to feature collection 37, which executes: 39. The program instructions providing the at least one smart contract include program instructions for verifying the delivery of the item, and execution of the program instructions by the processor causes the processor to control the DLT system such that, in the process of verifying the delivery of the item in the DLT system, the DLT node: checking parameters of a validation message for validating the goods delivery by the DLT node by using the at least one smart contract, the parameters including at least one quantity of goods to be validated, and the checking of the parameters including checking the quantity of goods to be validated for conformance with the first sensor value quantifying the quantity of goods delivered within a second predefined tolerance; performing a fourth update of the second dataset by the DLT node if the quantity of goods to be verified matches the first sensor value quantifying the quantity of the delivered goods within the second predefined tolerance range, the fourth update comprising registering the validation message in the second dataset by the DLT node by using the at least one smart contract; forwarding at least one third update message from said DLT node to said further DLT node for updating said first data set; A DLT node according to feature collection 37 or 38, which executes 40. A DLT node described in any one of feature collections 37 to 39, wherein execution of the program instructions by the processor causes the processor to control the DLT node such that the DLT node performs the method steps of the second DLT node of the method described in any one of feature collections 4 to 28. 41. A DLT system for computer-implemented monitoring of delivery of goods from a seller to a buyer, the DLT system including a first DLT node assigned to the buyer and a second DLT node assigned to the seller, the first DLT node and the second DLT node being provided by one or more DLT servers of the DLT system, the DLT system providing at least one smart contract including program instructions for entering and checking delivery orders and order confirmations; The DLT system is configured to initialize the item delivery in the DLT system, the initialization comprising: receiving, by the first DLT node, via a first network, a delivery order from the buyer for goods to be delivered by the seller to the buyer, the delivery order defining, as first specifications, one or more physical characteristics of the goods to be delivered, the physical characteristics of the first specifications including at least one quantity of the goods to be delivered; creating, by the first DLT node by using the at least one smart contract, a first dataset managed by the first DLT node and inputting at least the one or more physical characteristics of the delivery order into the first dataset, the first dataset being a first portion of a dataset shared between the first DLT node and the second DLT node; transferring at least said first data set from said first DLT node to said second DLT node; creating a second dataset managed by the second DLT node, which is a second part of the shared dataset, and performing a first update of the second dataset by the second DLT node based on the first dataset, the first update including entering at least one or more of the physical characteristics of the first item into the second dataset, the at least one or more entered physical characteristics of the first item including the quantity of goods to be delivered; receiving, by the second DLT node, an order confirmation from the seller via the first network, the order confirmation including a second description of one or more physical characteristics of the goods to be delivered; checking the second specification for consistency with the first specification by using the at least one smart contract; performing a second update of the second dataset by the second DLT node by using the first result of the check of the second details; forwarding at least a first update message from said second DLT node to said first DLT node; performing a first update of the first dataset by the first DLT node by using the first update message; Including, DLT system. 42. The at least one smart contract includes program instructions for entering and checking a shipping goods log during the course of goods delivery from the seller to the buyer, and the DLT system is further configured to perform logging of the goods delivery in the DLT system, wherein the logging includes: receiving, by the second DLT node, a shipping goods log from the sender via the first network, the shipping goods log including one or more first sensor values ​​for the one or more physical characteristics of the shipping goods according to the second specification detected by one or more first physical sensors of the first physical sensors assigned to the seller, the one or more first sensor values ​​including at least one first sensor value quantifying the amount of goods delivered; checking, by using the at least one smart contract, the one or more first sensor values ​​of the shipped goods log for consistency with the one or more physical characteristics of the goods delivered according to the split data set within a first predefined tolerance, wherein the checked first sensor values ​​include at least the first sensor value quantifying the amount of goods delivered; performing, by the second DLT node, a third update of the second dataset using a second result of checking the one or more first sensor values ​​of the shipping goods log; sending at least a second update message from the second DLT node to the first DLT node; performing a second update of the first dataset by the first DLT node by using the second update message; Feature collection 41. The DLT system of claim 41, comprising: 43. The at least one smart contract includes program instructions for verifying the delivery of the goods, and the DLT system is further configured to perform a verification of the delivery of the goods in the DLT system, the verification comprising: checking parameters of a validation message for validating the goods delivery by the second DLT node by using the at least one smart contract, the parameters including at least one quantity of goods to be validated, and the checking of the parameters including checking the quantity of goods to be validated for conformance with the first sensor value quantifying the quantity of goods delivered within a second predefined tolerance; performing a fourth update of the second dataset by the second DLT node if the quantity of goods to be verified matches the first sensor value quantifying the quantity of goods delivered within the second predefined tolerance, the fourth update comprising registering the validation message in the second dataset by the second DLT node using the at least one smart contract; forwarding at least a third update message from the second DLT node to the first DLT node; performing a third update of the first dataset by the first DLT node by using the third update message, wherein the third update of the first dataset includes registering the validation message in the first dataset; 43. The DLT system of feature collection 41 or 42, comprising: 44. A DLT system according to any one of feature collections 41 to 43, further configured to perform a method according to any one of feature collections 4 to 28. 45. A computer program for monitoring delivery of goods from a seller to a buyer using a limited-access DLT system, the DLT system including a first DLT node assigned to the buyer and a second DLT node assigned to the seller, the computer program providing at least one smart contract including program instructions for entering and checking delivery orders and order confirmations; The computer program includes program instructions for initializing the item delivery in the DLT system, the initialization comprising: receiving, by the first DLT node via a first network, a delivery order from the buyer for goods to be delivered from the seller to the buyer, the delivery order defining, as first specifications, one or more physical characteristics of the goods to be delivered, the physical characteristics of the first specifications including at least one quantity of the goods to be delivered; creating, by the first DLT node by using the at least one smart contract, a first dataset managed by the first DLT node and inputting at least the one or more physical characteristics of the delivery order into the first dataset, the first dataset being a first portion of a dataset shared between the first DLT node and the second DLT node; transferring at least said first data set from said first DLT node to said second DLT node; creating a second dataset managed by the second DLT node, which is a second part of the shared dataset, and performing a first update of the second dataset by the second DLT node based on the first dataset, the first update including entering at least one or more of the physical characteristics of the first item into the second dataset, the at least one or more entered physical characteristics of the first item including the quantity of goods to be delivered; receiving, by the second DLT node, an order confirmation from the seller via the first network, the order confirmation including a second description of the one or more physical characteristics of the goods to be delivered; checking the second specification for consistency with the first specification by using the at least one smart contract; performing a second update of the second dataset by the second DLT node by using the first result of the check of the second details; forwarding at least a first update message from said second DLT node to said first DLT node; performing a first update of the first dataset by the first DLT node by using the first update message; Including, Computer programs. 46. ​​The at least one smart contract includes program instructions for entering and checking a shipping goods log during the delivery of goods from the seller to the buyer, the computer program further including program instructions for logging the goods delivery in the DLT system, wherein the logging includes: receiving, by the second DLT node, a shipping goods log from the sender via the first network, the shipping goods log including one or more first sensor values ​​for the one or more physical characteristics of the shipping goods according to the second specification detected by one or more first physical sensors of the first physical sensors assigned to the seller, the one or more first sensor values ​​including at least one first sensor value quantifying the amount of goods delivered; checking, by using the at least one smart contract, the one or more first sensor values ​​of the shipped goods log for consistency with the one or more physical characteristics of the goods delivered according to the split data set within a first predefined tolerance, wherein the checked first sensor values ​​include at least the first sensor value quantifying the amount of goods delivered; performing, by the second DLT node, a third update of the second dataset using a second result of checking the one or more first sensor values ​​of the shipping goods log; sending at least a second update message from the second DLT node to the first DLT node; performing a second update of the first dataset by the first DLT node by using the second update message; Feature collection 45. The DLT system of claim 45, comprising: 47. The at least one smart contract includes program instructions for verifying the delivery of the item, the program instructions further including program instructions for verifying the delivery of the item in the DLT system, the verification comprising: checking parameters of a validation message for validating the goods delivery by the second DLT node by using the at least one smart contract, the parameters including at least one quantity of goods to be validated, and the checking of the parameters including checking the quantity of goods to be validated for conformance with the first sensor value quantifying the quantity of goods delivered within a second predefined tolerance; performing a fourth update of the second dataset by the second DLT node if the quantity of goods to be verified matches the first sensor value quantifying the quantity of goods delivered within the second predefined tolerance, the fourth update comprising registering the validation message in the second dataset by the second DLT node using the at least one smart contract; forwarding at least a third update message from the second DLT node to the first DLT node; performing a third update of the first dataset by the first DLT node by using the third update message, wherein the third update of the first dataset includes registering the validation message in the first dataset; 47. The computer program of claim 45 or 46, comprising: 48. A computer program according to any one of feature collections 45 to 47, further comprising program instructions for carrying out a method according to any one of feature collections 4 to 28. [Explanation of symbols]

[0265] 100 Seller Computer Systems 102 memory 104 Public Key 106 Protected Memory Areas 108 Private key 110 processors 112 Program Instructions 114 Sensors 116 Communication Interface 120 Buyer Computer Systems 122 memory 124 public key 126 Protected Memory Regions 128 private key 130 processors 132 program instructions 134 Sensors 136 Communication Interface 140 DLT servers 142 processors 144 Program Instructions 146 memory 148 First Dataset of Shared Datasets 150 public keys 152 Protected Memory Areas 154 Private key 156 Communication Interface 160 DLT servers 162 processors 164 program instructions 166 memory 168 Second Dataset of a Shared Dataset 170 Public Keys 172 Protected Memory Areas 174 Private key 176 Communication Interface 180 DLT Network 182 DLT Systems 184 Network 186 Banking Computer Systems 190 Delivery Orders 191 Order Confirmation 192 Updated Shipping Orders 193 Updated Order Confirmation 194 Validation Message

Claims

1. A computer-implemented method for monitoring delivery of goods from a seller to a buyer using a limited-access DLT system (182), the DLT system including a first DLT node assigned to the buyer and a second DLT node assigned to the seller, the DLT system (182) providing at least one smart contract including program instructions for entering and checking delivery orders (190) and order confirmations (191); The method includes initializing the item delivery in the DLT system (182), the initialization comprising: receiving, by the first DLT node, via a first network, a delivery order (190) from the buyer for goods to be delivered by the seller to the buyer, the delivery order (190) defining, as first specifications, one or more physical characteristics of the goods to be delivered, the physical characteristics of the first specifications including at least one quantity of the goods to be delivered; creating, by the first DLT node, a first dataset (148) managed by the first DLT node by using the at least one smart contract, and inputting at least the one or more physical characteristics of the delivery order (190) into the first dataset (148), the first dataset (148) being a first portion of a dataset shared between the first DLT node and the second DLT node; transmitting at least the first data set (148) from the first DLT node to the second DLT node; - creating a second dataset (168) managed by the second DLT node, which is a second part of the shared dataset, and performing a first update of the second dataset (168) by the second DLT node based on the first dataset (148), the first update including entering at least one or more of the physical characteristics of the first item into the second dataset (168), the at least one or more entered physical characteristics of the first item including the quantity of goods to be delivered; receiving, by the second DLT node, via the first network (184), an order confirmation (191) from the seller, the order confirmation (191) including a second description of one or more physical characteristics of the goods to be delivered; - checking said second specification for compatibility with said first specification by using said at least one smart contract; - performing a second update of said second dataset (168) by said second DLT node by using the first result of the check of said second particulars; - forwarding at least a first update message from said second DLT node to said first DLT node; performing a first update of the first data set (148) by the first DLT node by using the first update message; A method comprising:

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

3. The at least one smart contract includes program instructions for entering and checking a shipping goods log during the course of goods delivery from the seller to the buyer, the method including logging the goods delivery in the DLT system (182), wherein the logging includes: receiving, by the second DLT node, a shipping goods log from the seller via the first network (184), the shipping goods log including one or more first sensor values ​​for the one or more physical characteristics of the shipping goods according to the second specification detected by one or more first physical sensors (114) assigned to the seller, the one or more first sensor values ​​including at least one first sensor value quantifying the amount of goods delivered; - checking, by using the at least one smart contract, the one or more first sensor values ​​of the shipped goods log for consistency with the one or more physical characteristics of the goods to be delivered according to the shared dataset within a first predefined tolerance, wherein the checked first sensor values ​​include at least the first sensor value quantifying the amount of goods delivered; performing, by the second DLT node, a third update of the second data set (168) using a second result of checking the one or more first sensor values ​​of the shipping goods log; - forwarding at least one second update message from said second DLT node to said first DLT node; performing a second update of the first data set (148) by the first DLT node by using the second update message; The method of claim 1 , comprising:

4. The method includes verifying the delivery of the goods in the DLT system (182), wherein the at least one smart contract includes program instructions for verifying the delivery of the goods, the verification comprising: - checking parameters of a validation message (194) for validating the goods delivery by the second DLT node by using the at least one smart contract, the parameters including at least one quantity of goods to be validated, and the checking of the parameters including checking the quantity of goods to be validated for consistency with the first sensor value quantifying the quantity of goods delivered within a second predefined tolerance; - if the quantity of goods to be verified matches the first sensor value quantifying the quantity of goods delivered within the second predefined tolerance, performing a fourth update of the second dataset (168) by the second DLT node, the fourth update comprising registering the verification message (194) in the second dataset (168) by the second DLT node by using the at least one smart contract; - forwarding at least one third update message from the second DLT node to the first DLT node; performing a third update of the first data set (148) by the first DLT node by using the third update message, the third update of the first data set (148) comprising registering the validation message (194) in the first data set (148); The method of claim 1 , comprising:

5. further comprising signing, by the first DLT node, the data transferred 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 check the signature of the transferred data; and / or further comprising signing, by the second DLT node, the 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 data transfer between the first DLT node and the second DLT node is performed over one or more communications links that are cryptographically secured using end-to-end encryption; Establishing the one or more cryptographically protected communication connections may, for example, include in each case mutual authentication of the first DLT node and the second DLT node; The method of claim 1.

6. the checking of said second details for consistency with said first details during said initialization is an identity check; The initialization further comprises: If the one or more physical characteristics according to the second specification entered in the second data set (168) differ from the 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 match the first specification from the first data set (148) with the second specification from the second data set (168), such that the resulting first and second specifications are identical; or checking the second specification for consistency with the first specification during the initialization is checking for consistency within a third predefined tolerance in accordance with the at least one smart contract; The initialization may be, for example: and if one or more deviations between the one or more physical characteristics according to the second specification entered in the second data set (168) and the one or more physical characteristics according to the first specification from the first data set (148) are greater than the predefined third tolerance, performing a handshake between the first DLT node and the second DLT node to match the first specification from the first data set (148) with the second specification from the second data set (168), such that the resulting first and second specifications are identical within the predefined fourth tolerance. The method of claim 1.

7. The program instructions included in the at least one smart contract are further configured to input and check an incoming goods log during the course of goods delivery from the seller to the buyer, wherein the log record of the goods delivery in the DLT system (182) includes: receiving, by the first DLT node via the first network (184), an incoming goods log from the purchaser, the incoming goods log including one or more second sensor values ​​for the one or more physical characteristics of the incoming goods according to the first specification detected by one or more of the second physical sensors (134) assigned to the purchaser, the one or more second sensor values ​​including at least one second sensor value quantifying the amount of goods delivered; - checking, by using the at least one smart contract, the one or more second sensor values ​​of the incoming goods log for conformance with the one or more physical characteristics of the goods to be delivered according to the split data set and with the one or more first sensor values ​​according to the outgoing goods log within a fourth predefined tolerance range, wherein the checked second sensor values ​​include at least the second sensor value quantifying the amount of goods delivered; - performing a fourth update of the first data set (148) by the first DLT node by using a third result of checking the one or more second sensor values ​​of the incoming goods log; - forwarding at least one fourth update message from the first DLT node to the second DLT node; performing a fifth update of the second data set (168) by the second DLT node by using the fourth update message; The method of claim 1 , comprising:

8. the validation message (194) comprises an invoice, and the program instructions included in the at least one smart contract are further configured to create the invoice, the creation of the invoice being performed by the second DLT node using the at least one smart contract, and the validation message parameters (194) are checked during the creation of the invoice; or an invoice is received from a first ERP system of the seller that creates the invoice; The method of claim 1.

9. or the data entered into the shared data set provided in the DLT system (182) in the process of logging the item delivery is mirrored data of the item delivery from the first ERP system of the seller and / or the second ERP system of the buyer, the first and / or second ERP systems being configured to control the processing of the item delivery, and data consistency between the shared data set and the ERP systems is ensured by entering mirrored data; or the processing of the item delivery is controlled by the at least one smart contract, and program instructions of the at least one smart contract are also configured to control the processing of the item delivery. The method of claim 1.

10. the first network (184) is a public network; and / or a prerequisite for receiving the delivery order (190) of the buyer by the first DLT node is successful authentication of the buyer by the first DLT node; and / or a prerequisite for receiving the order confirmation (191) of the seller by the second DLT node is successful authentication of the seller by the second DLT node; and / or a prerequisite for receiving the shipment goods log from the seller by the second DLT node is successful authentication of the seller by the second DLT node; and / or a prerequisite for receiving the incoming goods log from the purchaser by the first DLT node is successful authentication of the purchaser by the first DLT node; and / or a prerequisite for the use of the delivery order (190) of the buyer by the first DLT node is a successful signature check of the signature of the delivery order (190) by the first DLT node; and / or a precondition for the receipt of the order confirmation (191) of the seller by the second DLT node is a successful signature check of the signature of the order confirmation (191) by the second DLT node; and / or a prerequisite for using the shipping goods log from the seller by the second DLT node is a successful signature check of the signature of the shipping goods log by the second DLT node; and / or a prerequisite for the first DLT node to use the incoming goods log of the purchaser is a successful signature check of the signature of the incoming goods log by the first DLT node; and / or the first DLT node and the second DLT node are provided by one or more DLT servers (140, 160) of the DLT system (182); the one or more DLT servers (140, 160) of the DLT system (182) are located, for example, in one or more data centers protected against unauthorized access; and / or Data transfer between the DLT nodes is performed through a second network (180); The second network may be, for example, a private network or a public network. The method of claim 1.

11. the program instructions included in the at least one smart contract are further configured to trigger an electronic payment transaction, the payment transaction according to the smart contract being triggered upon registration of the validation message (194) in the DLT system (182); The triggered electronic payment transaction is, for example, an IBAN transfer from the buyer's IBA account to the seller's IBAN account, or The triggered electronic payment transaction is, for example, a programmable amount transaction executed using said DLT system (182), the DLT system (182) is configured, for example, to transfer the invoice amount due from an account belonging to the purchaser for programmable currency to an account belonging to the seller for programmable currency, the DLT system (182) being further configured, for example, to convert a fiat amount in a fiat account assigned to the purchaser into a programmable currency amount in an account belonging to the purchaser for programmable currency; and / or the payment transaction is logged in the DLT system (182), e.g., using the at least one smart contract, and by using the smart contract, e.g., electronic account statements relating to the logged payment transaction are also issued for the buyer and / or the seller; The method of claim 1.

12. Use of a shared data set in a limited-access DLT system (182) in the course of computer-implemented monitoring of a delivery of goods from a seller to a buyer, said use being for the purposes of initializing said delivery of goods in said DLT system (182) and / or logging said delivery of goods in said DLT system (182) and / or verifying said delivery of goods in said DLT system (182); the shared dataset includes a first portion, the first portion being a first dataset (148) managed by a first DLT node assigned to the buyer, and the shared dataset further includes a second portion, the second portion being a second dataset (168) managed by a second DLT node assigned to the seller; use.

13. a DLT node of a limited-access DLT system (182) for computer-implemented monitoring of goods delivery from a seller to a buyer, said DLT node being implemented on a DLT server (140) of said DLT system (182) and assigned to said buyer, said DLT server (140) comprising a processor (142) and a memory having program instructions (144), at least one smart contract being provisioned on said DLT node by said program instructions, said program instructions providing said at least one smart contract including program instructions for entering and checking delivery orders (190), order confirmations (191) and / or shipped goods logs in the course of goods delivery from said seller to said buyer, and / or for verifying said goods delivery; Execution of the program instructions by the processor causes the processor to control the DLT node such that the DLT node performs the method steps of the first DLT node of the method of any one of claims 1 to 11; DLT node.

14. a DLT node of a limited-access DLT system (182) for computer-implemented monitoring of goods delivery from a seller to a buyer, said DLT node being implemented on a DLT server (160) of said DLT system (182) and assigned to said seller, said DLT server (160) comprising a processor (162) and a memory (166) having program instructions (164), at least one smart contract being provisioned on said DLT node by said program instructions (164), said program instructions (164) providing said at least one smart contract including program instructions for entering and checking delivery orders (190), order confirmations (191) and / or shipped goods logs in the course of goods delivery from said seller to said buyer, and / or for verifying said goods delivery; Execution of the program instructions by the processor causes the processor to control the DLT node such that the DLT node performs the method steps of the second DLT node of the method of any one of claims 1 to 11. DLT node.

15. a DLT system (182) for computer-implemented monitoring of goods delivery from a seller to a buyer, the DLT system including a first DLT node assigned to the buyer and a second DLT node assigned to the seller, the first DLT node and the second DLT node being provided by one or more DLT servers (140, 160) of the DLT system (182), the DLT system (182) including program instructions for entering and checking delivery orders (190), order confirmations (191) and / or shipped goods logs during the course of goods delivery from the seller to the buyer, and / or for verifying the goods delivery; The DLT system (182) is configured to perform the method according to any one of claims 1 to 11. DLT system.

16. A computer program for monitoring delivery of goods from a seller to a buyer using a limited-access DLT system (182), the DLT system including a first DLT node assigned to the buyer and a second DLT node assigned to the seller, the computer program providing at least one smart contract including program instructions for entering and checking delivery orders (190), order confirmations and / or shipped goods logs in the course of delivery of goods from the seller to the buyer, and / or for verifying the delivery of goods; The computer program product comprises program instructions for carrying out the method according to any one of claims 1 to 11.

Images