EP4591501A1 - Verwendung eines distributed-ledger-systems zur kontrolle von warenlieferungen - Google Patents

Verwendung eines distributed-ledger-systems zur kontrolle von warenlieferungen

Info

Publication number
EP4591501A1
EP4591501A1 EP23772286.3A EP23772286A EP4591501A1 EP 4591501 A1 EP4591501 A1 EP 4591501A1 EP 23772286 A EP23772286 A EP 23772286A EP 4591501 A1 EP4591501 A1 EP 4591501A1
Authority
EP
European Patent Office
Prior art keywords
goods
dlt
node
data set
delivery
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP23772286.3A
Other languages
English (en)
French (fr)
Inventor
Heinz-Günter LUX
Oliver Pieper
Ralf KAHRE
Nils GAGELMANN
Sven LEHNERT
Patrik VÖLKER
Andreas JÖST
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
BASF SE
Commerzbank AG
Evonik Operations GmbH
Original Assignee
BASF SE
Commerzbank AG
Evonik Operations GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by BASF SE, Commerzbank AG, Evonik Operations GmbH filed Critical BASF SE
Publication of EP4591501A1 publication Critical patent/EP4591501A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0607—Regulating the sale of restricted items, e.g. alcohol
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/083—Shipping
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/087—Inventory or stock management, e.g. order filling, procurement or balancing against orders
    • G06Q10/0875—Itemisation or classification of parts, supplies or services, e.g. bill of materials
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/108—Remote banking, e.g. home banking
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/018—Certifying business or products
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0609—Qualifying participants for shopping transactions
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0613—Electronic shopping [e-shopping] using intermediate agents
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Managing shopping lists, e.g. compiling or processing purchase lists
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication

Definitions

  • the invention relates to a method for computer-implemented control of a delivery of goods from a goods sender to a goods recipient using an access-restricted DLT system.
  • the invention further relates to a use of a shared data record of a DLT system in the course of a computer-implemented control of the delivery of goods, a DLT node of the access-restricted DLT system, which is implemented on a DLT server of the DLT system and is assigned to the goods recipient of the goods delivery, a DLT node of the restricted-access DLT system, which is implemented on a DLT server of the DLT system and assigned to the sender of the goods delivery, the restricted-access DLT system for computer-implemented control of the delivery of goods, and a computer program for controlling the delivery of goods using the access-restricted DLT systems.
  • a method for adapting a production process wherein a first node of a first party of a blockchain network is designed to publish order transactions in the blockchain network, wherein published order transactions are validated by the blockchain network, wherein the method includes analyzing validated order transactions in the blockchain network by at least one second party node of the blockchain network, the analyzing comprising:
  • Identifying validated order transactions extracting order parameters, sending the order parameters to a simulation system to simulate a production process for the ordered product based on the order parameters, receiving a capacity parameter from the simulation system, generating an offer based on the Capacity parameters, and if the first-party node accepts the offer, adjusting the production process based on the offer.
  • blockchains have the disadvantage that once data has been entered into the blockchain, it can no longer be adjusted. Furthermore, data entered into a blockchain is visible at least to all blockchain servers that manage the corresponding blockchain. In the case of a public blockchain, the data entered into the blockchain is even public, i.e. accessible to everyone.
  • the invention is based on the object of creating an improved method which is suitable for checking a delivery of goods and can ensure the security and confidentiality of the data used in the course of this checking.
  • Embodiments include a method for computer-implemented control of a delivery of goods from a goods sender to a goods recipient using an access-restricted DLT system.
  • the DLT system includes a first DLT node assigned to the goods recipient and a second DLT node assigned to the goods sender.
  • the DLT system also provides at least one smart contract.
  • the at least one smart contract includes program instructions for entering and checking delivery orders and order confirmations.
  • the method includes initializing the delivery of goods in the DLT system. Initializing includes:
  • the delivery order specifies one or more physical properties of the goods to be delivered as a first specification, wherein the physical properties of the first specification comprise at least a quantity of goods to be delivered, • Creating a first data set managed by the first DLT node and entering at least the one or more physical properties of the delivery order by the first DLT node into the first data set using the at least one smart contract, wherein the first data set is a first part of a data set shared between the first DLT node and the second DLT node,
  • the order confirmation comprising a second specification of the one or more physical properties of the goods to be delivered
  • Embodiments include a method further comprising logging delivery of goods in the DLT system.
  • the at least one smart contract includes program instructions for entering and checking outgoing goods protocols in the course of goods deliveries from the goods sender to the goods recipient.
  • Logging includes: • Receiving an outgoing goods protocol from the goods sender via the first network through the second DLT node, the outgoing goods protocol comprising one or more first sensor values for the one or more physical properties of the outgoing goods according to the second specification, which are determined by means of one or more assigned to the goods sender first physical sensors are detected, the one or more first sensor values comprising at least a first sensor value which quantifies the quantity of goods delivered,
  • Embodiments include a method further comprising validating delivery of goods in the DLT system.
  • the at least one smart contract includes program instructions for validating the delivery of goods.
  • Validating includes:
  • fourth updating of the second data set by the second DLT Node comprises registering the validation message by the second DLT node in the second data set using the at least one smart contract
  • a split data set is generated on two DLT nodes of a restricted-access DLT system.
  • This split data set is a data set that includes a first partial data set on the first DLT node and a second partial data set on the second DLT node.
  • Authorization to edit the first partial data set i.e. write authorization
  • the second data set only the second DLT node (or another DLT node authorized to do so) and thus the sender of the goods can have authorization to edit it, i.e. write authorization.
  • only the recipient of the goods can have read authorization to read the first partial data set via the first DLT node (or the other authorized DLT node) and only the sender of the goods can have read authorization to read the second partial data set via the second DLT node (or the other authorized DLT node).
  • the term distributed ledger technology describes a technology that is used to log transactions or the states of transactions.
  • a ledger as a general ledger is usually managed by only one entity, here any number of basically equal copies of the ledger are maintained by different parties in a decentralized manner.
  • Parties with at least one corresponding node in the DLT system can be, for example, goods sender, goods recipient, goods producer or goods supplier, where parties can also exist overlapping, such as the goods producer and the goods supplier as a single party.
  • a party with at least one node can be a savings bank, a bank be a banking institution, a payment service provider and/or a credit institution.
  • a regulator with at least one node can also be provided to carry out special functions, such as compliance with regulatory requirements such as preventing money laundering or mandatory sanctions or embargo checks.
  • At least one node in the DLT system can act as a notary to ensure the uniqueness of each transaction and prevent double use of the DLT-based gel units.
  • the at least one smart contract which is executed on both DLT nodes, for example, is configured to ensure data consistency between the two partial data sets of the shared data set.
  • mirror-like, i.e. identical, data can be implemented in both partial data sets of the shared data set using synchronous data maintenance.
  • the present method does not use blockchain, but is based, for example, on direct data exchange between the DLT nodes of the parties involved and on direct data validation by the corresponding DLT nodes.
  • Using a restricted-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, the participants in the DLT system only have access to one DLT node that is assigned to them. For example, data from the shared data sets within the DLT system is only transmitted between the DLT nodes between which the shared data set is shared. For example, the transmission only takes place between the first DLT node of the goods recipient and the second DLT node of the goods sender.
  • unicast is used for transmission, which means that the transmitted data is addressed to a single recipient, i.e. a single DLT node.
  • transmission via unicast has the advantage that only the sender and recipient are aware of the transmitted data. Since transactions in a blockchain are usually visible to all validating nodes, for example when transactions to be entered are transmitted within the blockchain network via broadcast, there is a lack of confidentiality.
  • a blockchain typically stores data as transactions in individual blocks, which are chained together and managed redundantly in a distributed peer-to-peer network. As a result of the redundant management, a large number of nodes have access to all data stored in the blockchain.
  • embodiments of the present invention have the advantage that both data security and confidentiality of the data stored in the shared data set can be ensured. This is achieved by the fact that communication regarding the transactions to be mapped, ie the data to be stored in a shared data record, takes place within the DLT system only between the affected DLT nodes, ie those DLT nodes between which the corresponding data record is shared . For example, these are only the first DLT node of the goods recipient and the second DLT node of the goods sender. The delivery of goods is controlled using one or more smart contracts that are executed on the nodes involved. It is not stored in a blockchain or any other data set that can be viewed by all DLT nodes.
  • a data record shared by the DLT nodes involved which has a first (partial) data record that is managed by the DLT node of the goods recipient and a second (partial) data record that is managed by the DLT node of the goods sender becomes.
  • the two (partial) data sets should correspond to each other and reflect the view of the responsible node. Only the responsible DLT node is authorized to change the corresponding part of the data record.
  • the partial data records and thus the transactions stored in the corresponding partial data records are each transmitted to the other DLT node. For example, only changes to the corresponding partial data set are transmitted to the other DLT node.
  • the data transmitted to the other DLT nodes is signed. Using the signature, the other DLT node can check whether the changes are correct or have been authorized by the signing DLT node and thus by the assigned participants.
  • first and second partial data sets are identical.
  • one partial data record can have one or more compared to the other partial data record include several different data values, for example with regard to the delivery of goods, for example with regard to the quantity of the corresponding goods to be delivered or others.
  • tolerances within which deviations are acceptable can be predefined.
  • a semi-automatic or fully automatic handshake can take place between the two DLT nodes managing the two partial data sets until agreement has been reached on individual data values that deviate from one another in the data set, for example the goods to be delivered and their properties, i.e. the deviations have been remedied.
  • Embodiments can therefore have the advantage that an approach for the confidential processing of transactions between the two DLT nodes is provided based on the data set distributed over two DLT nodes and/or the further features described above for comparing the (partial) data sets. It also makes it possible to secure transactions and increase data security between the DLT nodes.
  • Communication between the DLT nodes takes place, for example, via transport connections secured using the Transport Layer Security Protocol (TLS). Furthermore, communication with the DLT nodes takes place, for example when the goods recipient accesses the first DLT node using a computer system assigned to the goods recipient and/or when the goods sender accesses the second DLT node using a computer system assigned to the goods sender TLS secured transport connections.
  • TLS Transport Layer Security Protocol
  • the security principle within the DLT system is based, for example, on peer-to-peer communication between the DLT nodes and the need-to-know principle. Peer-to-peer communication is based on a computer-computer connection between computers with equal rights.
  • the need-to-know principle or necessity principle requires, as a security goal for data, that not only a basic access authorization is necessary to access the corresponding data, but also that the data to be accessed is directly necessary for the fulfillment of a requirement are necessary for a specific task. For example, even if a DLT node has access to data of a certain or a certain security level, the need-to-know principle prohibits access if the corresponding one does not are required directly for the fulfillment of a specific task by this DLT node.
  • Each DLT node only receives the data that concerns it. Therefore, information cannot flow through a compromised DLT node because it is not involved in managing shared data sets from other DLT nodes and data is not publicly accessible or published within the DLT system.
  • Embodiments can have the advantage that encryption of the data in the partial data sets of the shared data set is not necessary.
  • Data can be entered and stored in the partial data sets in plain text.
  • the need-to-know principle ensures that relevant data is only exchanged between the DLT nodes involved. This provides effective protection of sensitive information against unauthorized access.
  • the network architecture used in the DLT system thus already ensures effective data security and confidentiality. No data is sent to other DLT nodes that does not directly concern them or the participants assigned to them (need-to-know principle). This is in contrast to the approach of a classic blockchain. In order to be able to securely store sensitive data in a blockchain, this data must be entered and stored in encrypted form.
  • a blockchain is typically also visible to all nodes in the system, so sensitive information in a blockchain must be protected by additional measures.
  • additional measures such as encryption or the use of a one-way function, only provide basic protection for the data and information stored in the blockchain.
  • data is encrypted in the partial data sets of the shared data set, this leads to the level of security for the corresponding data being additionally increased based on an already existing basic protection, which is already provided by the network architecture, and not just to implement basic protection serves, as in the case of a classic blockchain.
  • the data in the partial data records of the shared data record are entered in encrypted form and/or the partial data records are stored in encrypted form.
  • communication between the DLT nodes is based on a unicast or direct communication between the DLT nodes involved, for example via a dedicated communication connection.
  • Embodiments make it possible, for example, to ensure mirror-identical data regarding the transfer of goods on both sides, i.e. at the goods recipient and the goods sender, in the form of the first and second data sets.
  • This mirrored data can also be integrated into connected enterprise resource planning (ERP) systems on both sides, for example.
  • ERP enterprise resource planning
  • the mirrored data and synchronous data maintenance provided in this way is advantageous for the digital integration of ordering, delivery and financial processes between business partners, for example the goods recipient and the goods sender.
  • constant data quality can be ensured and can be measured reciprocally, for example using performance indicators such as Key Performance Indicators (KPIs).
  • KPIs Key Performance Indicators
  • the implementation of in-process validation ensures the sustainability of data quality that has already been achieved and thus prevents gradual deterioration.
  • reconciliation effort is reduced.
  • the effort required for later account reconciliation can be significantly reduced or, ideally, completely eliminated for both business partners. This can help increase data quality and process efficiency. For example, the amount of manual work can be reduced.
  • a data set is entered into the first data set managed by the first DLT node, ie the first partial data set of the shared data set or several physical properties of the goods to be delivered are entered in accordance with the first specification.
  • These registered one or more physical properties according to the first specification include at least one quantity of goods to be delivered.
  • This first data set or the one or more physical properties entered in the first data set according to the first specification are transmitted to the second DLT node of the goods sender.
  • the second DLT node creates the second partial data set of the shared data set, in which one or more physical properties are entered according to the first specification.
  • the registered one or more physical properties according to the first specification include at least one quantity of goods to be delivered.
  • the second specification Upon receipt of an order confirmation, which includes a second specification of the one or more physical properties of the goods to be delivered, the second specification is checked for compliance with the first specification by the second DLT node using the at least one smart contract and a updating the second data set using the result of checking the second specification.
  • updating the second data set using the test result includes, for example, entering a confirmation of the first specification.
  • updating the second data set using the test result includes entering the second specification in the second data set in addition to the first specification.
  • updating the second data set using the test result includes, for example, replacing or updating the physical properties according to the first specification with the different physical properties according to the second specification.
  • the different physical properties according to the second specification are entered into the second data set in addition to the first specification.
  • the second specification is entered into the second data record in addition to the first specification.
  • a first update message is transmitted from the second DLT node to the first DLT node.
  • the first update message indicates whether the second specification matches the first specification. For example, if one or more physical properties according to the second specification differ from the first specification, the first update message identifies the different one or more physical properties according to the second specification.
  • the first update message includes the entire second specification or a copy of the second specification.
  • Such a deviation of one or more physical properties according to the second specification from the first specification can occur, for example, because only a certain minimum quantity of goods can be delivered or the goods are only delivered in certain units of quantity, e.g. in the size of a tank car or a tanker truck.
  • Such a deviation of one or more physical properties according to the second specification from the first specification can occur, for example, because the deliverable product properties differ from the ordered product properties.
  • the first DLT node updates the first record, i.e. the first sub-record of the shared record, using the first update message. If the second specification matches the first specification, updating the first data set using the first update message includes, for example, entering a confirmation of the first specification. For example, updating the first data set using the first update message includes entering the second specification in addition to the first specification into the first data set.
  • updating the first data set using the first update message includes, for example, replacing or updating the physical properties according to the first specification with the different physical properties according to second specification.
  • the different physical properties according to the second specification are entered into the second data set in addition to the first specification.
  • the second specification is entered into the second data record in addition to the first specification.
  • a “handshake” is carried out between the first DLT node and the second DLT node to compare the first specification with the second specification, so that the first and second specifications resulting from the comparison match .
  • a handshake refers to an automated negotiation process between two participants, in this case the two DLT nodes, through an exchange of data, in this case information on the physical properties of the goods to be delivered.
  • the handshake can be used to determine the terms of a delivery of goods before the physical delivery of the goods begins.
  • a handshake protocol is carried out between the two DLT nodes, the result of which is an adjustment of one or both specifications until there is an identical match, i.e. identity, between these two specifications.
  • a confirmation message is transmitted from the second DLT node to the goods sender via the network.
  • a match between the second specification and the first specification occurs, for example, when the two specifications are identical, that is to say an identical match.
  • the second specification agrees with the first specification, for example, if no deviations occur that exceed a predefined tolerance range.
  • the confirmation message shows the sender of goods, for example, that an agreement has been reached between the recipient of the goods and the sender of the goods regarding the corresponding delivery of goods.
  • the confirmation message includes, for example, the specification of the corresponding delivery of goods.
  • the corresponding confirmation message serves as a trigger to initiate the corresponding delivery of goods.
  • the delivery of goods is logged in the DLT system.
  • the corresponding outgoing goods protocol includes one or more sensor values for the one or more physical properties of the outgoing goods according to the second specification, which are recorded by means of one or more physical sensors assigned to the goods sender.
  • the outgoing goods protocol therefore indicates sensory measured values for one or more physical properties for which target values are specified in the second specification, which reflect the actual condition of the outgoing goods with regard to the corresponding physical properties.
  • the corresponding sensor values include at least one sensor value which quantifies the delivered, ie outgoing, quantity of goods.
  • the second DLT node of the goods sender receives the goods issue protocol from the goods sender via the first network and checks the one or more first sensor values of the goods issue protocol for compliance with the one or more physical properties of the goods to be delivered. This checks whether the one or more sensor values of the outgoing goods protocol match one or more physical properties according to the shared data set within predefined tolerances. If there is no such match, a warning is sent, for example, to the sender of the goods and/or the recipient of the goods. Such a warning can, for example, trigger a subsequent delivery from the goods sender if the delivery quantity is too small. Such a warning could, for example, mean that the delivery process will be stopped if, for example, a product feature is not in accordance with the specification. In this case, for example, either the recipient of the goods must agree to the different specification and the delivery takes place or the order is canceled. As an alternative to cancellation, the delivery date can, for example, be changed to a date on which goods in accordance with the specification are available.
  • the second data set is updated by the second DLT node using the result of checking the one or more first sensor values of the goods issue log.
  • the update includes entering the outgoing goods log and/or one or more of the sensor values specified by the outgoing goods log.
  • all sensor values specified in the goods issue log are entered. For example, only those sensor values are entered that deviate from the values entered in the second data set for the physical properties of the goods to be delivered.
  • only a confirmation is entered in the second data set that the corresponding values for the physical properties match the recorded sensor values.
  • a second update message is transmitted from the second DLT node to the first DLT node.
  • the second update message includes, for example, the outgoing goods log and/or one or more of the sensor values specified by the outgoing goods log.
  • the second update message includes all sensor values specified by the goods issue log.
  • the second update message only includes those sensor values that deviate from the values entered in the second data set for the physical properties of the goods to be delivered.
  • the second update message for sensor values of the outgoing goods protocol which match the values entered in the second data set for the physical properties of the goods to be delivered, only includes a confirmation that the corresponding values for the physical properties according to the shared data set match the recorded sensor values .
  • the first DLT node updates the first data set, that is, the first sub-data set of the shared data set, using the second update message.
  • the update includes entering the outgoing goods log and/or one or more of the sensor values specified by the outgoing goods log.
  • all sensor values specified in the goods issue log are entered.
  • only those sensor values are entered that differ from those in the Values entered in the first data set for the physical properties of the goods to be delivered may differ.
  • a confirmation is entered in the first data set that the corresponding values for the physical properties match the recorded sensor values.
  • a validation of the delivery of goods is carried out in the DLT system.
  • parameters of a validation message for validating the delivery of goods are checked by the second DLT node.
  • the checked parameters of the validation message include at least one indication of the quantity of goods delivered to be validated.
  • Checking the corresponding parameters includes checking the quantity of goods to be validated for compliance with the sensor value quantifying the quantity of goods delivered according to the goods issue protocol within a predefined tolerance. If the quantity of goods to be validated matches the sensor value quantifying the quantity of goods delivered within the predefined tolerance, the second data set is updated by the second DLT node using the validation message. Updating includes registering the validation message by the second DLT node in the second data set.
  • an identifier of the validation message is entered into the second data record.
  • a check value, such as a hash value, of the validation message is entered into the second data record.
  • one or more parameters of the validation message are entered into the second data record.
  • the validation message is entered into the second record.
  • a hash value is the result of applying a hash function, also called a scatter function, to an input, also called a key.
  • a hash function is a mapping that maps a large input set, the keys, to a smaller target set, the hash values.
  • a hash function is therefore generally not injective.
  • the input set can contain elements of different lengths, whereas the elements of the target set generally have a fixed length.
  • validation is triggered by receiving the validation message or by generating the validation message.
  • a create the validation message is triggered by receipt of a confirmation of receipt of the delivered goods from the goods recipient.
  • a confirmation of receipt is received in the form of a goods receipt report.
  • a third update message is transmitted from the second DLT node to the first DLT node.
  • the third update message includes, for example, the validation message data entered into the second data record during the update.
  • the third update message includes, for example, the complete updated second record.
  • the third update message includes, for example, the validation message.
  • the first DLT node updates the first record using the third update message. Updating the first data record includes registering the validation message in the first data record. For example, during registration, an identifier of the validation message is entered into the first data record. For example, a check value, such as a hash value, of the validation message is entered into the first data record. For example, one or more parameters of the validation message are entered into the first data record. For example, the validation message is entered in the first record.
  • the DLT system comprises, for example, a plurality of DLT servers. Two or more DLT nodes from two or more participants can be arranged on one and the same DLT server of the DLT system, for example. For example, the DLT nodes of different participants are arranged on different DLT servers of the DLT system.
  • a single smart contract is used to carry out the process for computer-implemented control of the delivery of goods.
  • a plurality of smart contracts are used.
  • the individual smart contracts of the plurality of smart contracts are each configured to carry out certain sub-processes, for example initialization, logging and/or validation.
  • a smart contract defines a set of conditions that are recorded in a DLT system and trigger automated, self-executing actions when at least some of these predefined conditions are met.
  • a smart contract comprises program instructions that map agreed rules or corresponding conditions.
  • Such a smart contract which defines rules for a majority of participants, cannot be changed unilaterally. Rather, a consensus of the majority of participants is necessary for a change. Such a consensus can, for example, require the consent of a majority of the majority of participants and/or all participants of the majority of participants.
  • changes to the smart contract are logged. For example, a complete history of changes to the smart contract is provided.
  • the network over which the DLT nodes are accessed is, for example, a TCP/IP network.
  • the DLT nodes can be hosted on one or more servers.
  • the DLT system can establish secured connections between the DLT servers and the DLT nodes hosted therein.
  • the DLT nodes can also be implemented locally on computer systems assigned to the participants.
  • the one or more first physical sensors of the goods sender include one or more physical measuring devices for acquiring measurement data or sensor values.
  • Measurement data is data that quantitatively or qualitatively describes the physical and/or chemical properties of a measurement object. Corresponding properties include, for example, weight, volume, temperature, humidity, pressure, grain size, sound field sizes, brightness, pH value, ionic strength, electrochemical potential, conductivity, viscosity, and/or translucency.
  • Measurement data is recorded using physical or chemical effects and converted into an electrical signal that can be further processed electronically.
  • the corresponding electrical signal which includes the recorded measurement data, is cryptographically encrypted.
  • symmetrical, asymmetrical or hybrid cryptographic encryption can be used. This means that the corresponding measurement data can be protected from unauthorized access, for example.
  • the corresponding electrical signal which includes the recorded measurement data
  • Embodiments may have the advantage that bidirectional claim settlement can be implemented. This includes, for example, a 2-way match (2-way comparison) and/or a 3-way match (3-way comparison).
  • fully automatic billing is possible, for example.
  • a consistent declaration of intent regarding delivery conditions for the delivery of goods can be implemented using the at least one smart contract and using the DLT system document.
  • the “2” in the name 2-Way-Match means that the delivery order and order confirmation are validated.
  • delivery conditions for the delivery of goods such as physical properties of the delivered goods and/or a price of the goods to be delivered, are compared in accordance with the delivery order and order confirmation. This makes it possible to ensure that they match, that is, that they are identical or that any deviations that occur do not exceed a predefined tolerance range.
  • This 2-way match is implemented, for example, in the form of checking information according to the order confirmation in the course of entering it into the second data record by the second DLT node.
  • the delivery order includes an initial indication of a price for the goods to be delivered.
  • a price indication is an indication of the price to be paid for the goods to be delivered.
  • the price information is identical to the price to be paid.
  • the price to be paid can be derived or calculated from the price information. If the price information refers to the entire quantity of goods to be delivered, the price information corresponds to the price of the goods to be delivered.
  • the first price quotation is a price quotation per quantity of goods delivered. If the price is quoted per quantity of goods delivered, the actual price to be paid depends on the quantity of goods actually delivered.
  • a price indication per quantity of goods delivered such as per piece, per weight, or per volume, must be multiplied by the quantity of goods delivered in order to determine the price to be paid for the goods delivered.
  • this first price information is entered into the first data record by the first DLT node in accordance with the delivery order and transmitted to the second DLT node for entry into the second data record.
  • the order confirmation includes a second price indication of a price for the goods to be delivered, in particular a second price indication per delivered Quantity of goods.
  • this second price information is checked by the second DLT node to ensure that it matches the first price information and is entered into the second data record in the course of updating the second data record using the order confirmation.
  • This test can be used to implement the 2-way match, for example, or the 2-way match includes this test, for example.
  • a price for the goods to be delivered can be compared according to the delivery order and order confirmation.
  • the update message sent to the first DLT node about the update of the second data set using the order confirmation includes the second price indication.
  • the second price information transmitted in this way is entered by the second DLT node into the second one.
  • first price information differs from the second price information in such a way that they are not identical or the difference exceeds a predefined tolerance range
  • a handshake is initiated between the first DLT node and the second DLT node to compare the price information.
  • the price information resulting from the comparison is identical or has a remaining difference that does not exceed the predefined tolerance range.
  • delivery conditions that result from the 2-way match, together with the information in the outgoing goods protocol regarding the goods actually delivered, can be compared with the corresponding information in the validation message and documented using the DLT system.
  • One or more delivery conditions for the delivery of goods such as a price of the goods to be delivered, result from the 2-way match and are not, for example, the subject of the goods issue protocol.
  • One or more delivery conditions for the delivery of goods such as physical properties of the delivered goods, may differ from the result of the 2-way match.
  • the actual values for this delivery condition, such as an actual quantity of goods delivered are therefore recorded using the goods issue log. In this way, it can be checked whether there are deviations from the result of the 2-way match and these deviations can be taken into account when validating the validation message.
  • the “3” in the name 3-Way Match means that the corresponding validation is based on the goods issue protocol and the validation message in addition to the result of the 2-Way Match based on the delivery order and the order confirmation.
  • a real order includes information about certain physical properties of the goods to be delivered, which may differ in the actual delivery for efficiency and/or production reasons.
  • a real order also includes information about certain physical properties, which may differ in the actual delivery due to naturally occurring variations. Therefore, for example, physical properties of the goods to be delivered are recorded by sensors during delivery by the goods sender and recorded in the outgoing goods log. These sensory-detected physical properties of the delivered goods according to the outgoing goods protocol are recorded, for example, as physical properties of the actually delivered goods in the shared data set of the DLT system and are used as the basis for checking the validation message.
  • a real order defines a specific quantity of the ordered goods to be delivered. For reasons of efficiency, however, it can be advantageous to fill transport vehicles to the full for transporting the goods to be delivered, for example in the case of bulk goods, so that the actual quantity delivered can differ from the ordered quantity. For example, a larger quantity is delivered than ordered. This actual quantity delivered can be recorded using sensors and recorded in the goods issue log.
  • a real order defines certain physical properties of the ordered goods. However, due to production reasons, only goods with physical properties that differ from the properties defined in the order can be produced. In this case, for example, the recipient of the goods must either agree to the different specification and the delivery takes place, or the order is canceled.
  • production of the goods to be delivered with the specific physical properties is temporarily not possible, for example because necessary starting products and/or starting products with certain necessary physical properties are temporarily unavailable for production. It may also be possible that certain production resources, such as systems or parts of systems, are temporarily unavailable for production.
  • certain production resources such as systems or parts of systems, are temporarily unavailable for production.
  • a total price for the goods delivered is determined from a price indication per quantity of goods, which results from the 2-way match, and the indication of the quantity of goods actually delivered included in the goods issue protocol and compared with a corresponding information for the total price contained in the validation message.
  • the validation message is created using the smart contract, whereby in the course of the 3-way match it can be ensured that the information on the delivery conditions in the validation message is consistent with the delivery conditions agreed on the basis of the delivery order and the order confirmation as well as the actual delivery conditions according to the goods issue protocol.
  • a payment of an invoice amount resulting from the validation message can be triggered using the smart contract.
  • a corresponding check of the validation message using the smart contract can thus replace a classic invoice check.
  • the aforementioned approach can be particularly advantageous for deliveries such as bulk product deliveries, where delivery conditions of a delivery order and/or an order confirmation can deviate, such as an actually delivered final quantity.
  • the actual delivery conditions can in this case be determined based on the goods issue protocol.
  • the delivery conditions are set as actually unchangeable.
  • the quantity of goods to be delivered is determined by the order confirmation or the result of a handshake between the sender and recipient of the goods.
  • the corresponding specified delivery conditions can therefore be taken from the order confirmation or the result of the 2-way match, for example.
  • the 3-way match is used to check the correspondingly adopted delivery conditions in the validation message using the goods issue protocol.
  • the validation message can trigger the sending of a warning and/or a correction, for example by a subsequent delivery or a delivery of correct goods by the sender of the goods.
  • the system works in such a way that the signals provided by the sensors in the form of the outgoing goods protocol and/or an incoming goods protocol are evaluated by one of the several smart contracts, compared with the status of the order or goods delivery process in accordance with the shared data record and stored in the shared data record be logged. Furthermore, using the one or more smart contracts, a transfer of the payment amount between the eWallets or electronic wallets is initiated, semi-automatically or fully automatically.
  • the method further comprises signing the data transmitted from the first DLT node to the second DLT node by the first DLT node.
  • the at least one smart contract is set up on the second DLT node to verify the signatures of the transmitted data.
  • Embodiments can have the advantage that the corresponding signatures can be used to check the authenticity of data that the first DLT node transmits to the second DLT node. It can thus be ensured that the second data set is updated by the second DLT node based on data that is signed and therefore authorized by the first DLT node.
  • the first DLT node uses a first signature key to sign the data.
  • This first signature key is, for example, a first private cryptographic key of a first asymmetric cryptographic key pair.
  • This first signature key is stored, for example, in a protected storage area of the first DLT node.
  • the second DLT node and/or the smart contract running on the second DLT node includes a first signature verification key for validating signatures that were created using the first signature key.
  • This first signature verification key is, for example, a first public cryptographic key of the first asymmetric cryptographic key pair.
  • Data protection can be implemented or increased, for example, using cryptographic means, such as hashing and/or encryption.
  • An asymmetric cryptographic key pair includes a public cryptographic key, which is shared with third parties or made available to third parties, and a private cryptographic key, which is not shared with third parties or not made available to third parties.
  • the public cryptographic key enables the third party to decrypt data that was encrypted with the private cryptographic key by the owner of the asymmetric key pair. Furthermore, the public cryptographic key enables the third party to encrypt data so that only the owner of the asymmetric key pair can decrypt the encrypted data with the private cryptographic key.
  • the private key is used by the owner of the asymmetric key pair to encrypt data so that it can be decrypted by third parties using the public cryptographic key.
  • the private cryptographic key serves the owner of the asymmetric key pair to decrypt data encrypted with the public cryptographic key for him.
  • the private cryptographic key therefore enables the owner of the asymmetric key pair to sign data, for example, while the public cryptographic key enables any third party to verify a corresponding signature.
  • a digital signature is an asymmetric cryptosystem in which a sender uses a secret signature key, i.e. a private cryptographic key, to calculate a value for a digital message, which is also called a digital signature. This value enables anyone to verify undeniable authorship of the owner of the signature key and the integrity of the message using a public signature verification key, i.e. a public cryptographic key.
  • the signature can, for example, be an encrypted hash value of the signed data, in particular a hash value encrypted with a private cryptographic key.
  • the private cryptographic key is, for example, assigned to a public cryptographic key, which serves as a signature verification key.
  • the public cryptographic key is provided, for example, as part of a certificate.
  • a “certificate” here means a digital certificate, which is also referred to as a public key certificate.
  • Such certificates based on asymmetric key pairs, create a so-called Public Key Infrastructure (PKI).
  • PKI Public Key Infrastructure
  • Such a certificate is structured data that is used to assign a public key of an asymmetric cryptosystem to an entity, such as a person, an organization, a computer system or a DLT node.
  • a certificate can contain a public key and be signed.
  • the certificate may conform to the X.509 standard or another standard.
  • the PKI provides a system for issuing, distributing and verifying digital certificates.
  • a digital certificate is used to confirm or define the authenticity of a public key and its permissible scope of application and validity.
  • the digital certificate itself is protected by a digital signature, the authenticity of which can be verified using the public key of the certificate issuer.
  • a digital certificate is used to verify the authenticity of the issuer key.
  • a chain of digital certificates can be built, each of which confirms the authenticity of the public key with which the previous certificate can be verified.
  • Such a chain of certificates forms a so-called validation path or certification path.
  • the participants of the PKI must be able to rely on the authenticity of the last certificate, the so-called root certificate, and the key certified by this certificate without the need for another certificate.
  • the root certificate is managed by a so-called root certification authority, whose assumed authenticity forms the basis for the authenticity of all PKI certificates.
  • a certificate can be associated with a digital signature if the private cryptographic key associated with the public cryptographic key was used to generate the digital signature to be verified.
  • a certificate available to the general public in association with a public key, users of asymmetric cryptosystems are enabled to assign the public key to an entity, for example a person, an organization, a computer system or a DLT node.
  • the method further comprises signing by the second DLT node the data transmitted from the second DLT node to the first DLT node.
  • the at least one smart contract is set up on the first DLT node to check the signatures of the transmitted data.
  • Embodiments can have the advantage that the authenticity of data that the second DLT node transmits to the first DLT node can be checked using corresponding signatures. It can thus be ensured that the first data set is updated by the first DLT node based on data that is signed and therefore authorized by the second DLT node.
  • the second DLT node uses a second signature key.
  • This second signature key is, for example, a second private cryptographic key of a second asymmetric cryptographic key pair.
  • This second signature key is stored, for example, in a protected storage area of the second DLT node.
  • the second DLT node and/or the smart contract running on the second DLT node includes a second signature verification key for validating signatures that were created using the second signature key.
  • This second signature verification key is, for example, a second public cryptographic key of the second asymmetric cryptographic key pair.
  • the data transmission between the first DLT node and the second DLT node takes place via one or more communication connections that are cryptographically protected by end-to-end encryption.
  • Embodiments may have the advantage of ensuring that data transmitted between the DLT nodes within the DLT system is effectively protected against man-in-the-middle attacks.
  • the encryption is, for example, symmetric encryption, asymmetric encryption or hybrid encryption.
  • encryption occurs using the TLS encryption protocol.
  • setting up the one or more cryptographically protected communication connections each includes mutual authentication of the TI first DLT node and the second DLT node.
  • Embodiments may have the advantage that based on mutual authentication, both DLT nodes can ensure who they are communicating with over the corresponding communication links.
  • the first DLT node of the goods recipient can ensure that it actually communicates with the DLT node that is assigned to the goods sender, i.e. the second DLT node.
  • the second DLT node of the goods sender can ensure that it actually communicates with the DLT node that is assigned to the goods recipient, i.e. the first DLT node.
  • checking the second specification for compliance with the first specification during initialization is checking for identity.
  • Embodiments may have the advantage that it can be ensured that there is an identity between the first specification according to the delivery order and the second specification according to the order confirmation.
  • Such an identity means that the recipient of the goods and the sender of the goods have agreed on an identical specification of the goods to be delivered.
  • identical specifications are stored in both partial data sets of the shared data set. If the first and second specifications differ from each other, a handshake protocol can be carried out between the two DLT nodes using the at least one smart contract, for example, the result of which is an adjustment of one or both specifications until an identity is established.
  • initializing further includes performing a handshake between the first DLT node and the second DLT node for matching the first specification of the first data set and the second specification of the second data set so that the first and second specifications resulting from the matching match.
  • the handshake can be, for example, an automatic or a semi-automatic handshake.
  • an automatic handshake both For example, tolerance ranges for the parameters to be negotiated are defined for the goods recipient and goods sender. In this case, deviations between parameters can be achieved by adjusting them within the respective tolerance ranges.
  • a semi-automatic handshake a suggestion for a parameter value is received from one of the two participants or from a DLT node assigned to the corresponding participant, which deviates from the corresponding participant's own suggestion for the corresponding parameter. This different parameter value can be confirmed, for example, by receiving a user input from the corresponding participant.
  • a confirmation of the proposed parameter value can also be sent to the suggesting second participant during the handshake.
  • a counter-suggestion for the different parameter value can be received by receiving a user input from the corresponding participant.
  • this counterproposal for the different parameter value can be sent to the second participant.
  • the second participant either confirms the counterproposal by sending a corresponding confirmation during the handshake, or makes a new counterproposal. This procedure can, for example, continue until agreement is reached on the corresponding parameter value or until a predefined termination criterion is met.
  • a corresponding termination criterion can, for example, be a predefined maximum number of suggestions for a parameter value, an expiration of a predefined maximum time period for negotiating a parameter value or a receipt of a user input that explicitly rejects a current suggestion for the corresponding parameter value.
  • the handshake can be executed or at least initiated by one or more smart contracts.
  • iterations of the automatic or semi-automatic handshake between the DLT nodes of the negotiating partners can be carried out by entering suggestions into the respectively managed part of the shared data set, which is then transmitted to the DLT node of the negotiating partner. All changes therefore remain traceable and can be checked by the negotiating partners.
  • Embodiments can have the advantage that an effective method for aligning different specifications according to the delivery order and order confirmation, ie different proposals for the specification between the goods recipient and the goods sender, can be provided.
  • checking the second specification for compliance with the first specification during the initialization is checking for compliance within predefined third tolerances according to the at least one smart contract.
  • Embodiments may have the advantage that there need not be any identity between the specifications. This means that deviations are permitted within predefined tolerances.
  • the goods sender can adapt the specification of the goods to be delivered, such as a quantity of goods to be delivered, within predefined limits, i.e. the tolerances, to his ability to deliver the requested goods.
  • initializing 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 and the second specification of the second data set if one or more discrepancies between the one or more physical properties according to the second specification, which are entered into the second data set, and the one or more physical properties according to the first specification from the first data set are greater than the predefined third tolerances.
  • the handshake causes the first and second specifications resulting from the comparison to agree within the predefined third tolerances.
  • Embodiments can have the advantage that an effective method for aligning different specifications according to the delivery order and order confirmation, ie different proposals for the specification between the goods recipient and the goods sender, can be provided.
  • a handshake protocol is carried out between the two DLT nodes, the result of which is an adjustment of one or both specifications until deviations between the two specifications are only within the corresponding predefined tolerances.
  • the program instructions included in the at least one smart contract are further configured to enter and check goods receipt protocols in the course of goods deliveries from the goods sender to the goods recipient.
  • Logging the delivery of goods in the DLT system also includes:
  • the goods receipt protocol comprising one or more second sensor values for the one or more physical properties of the incoming goods according to the first specification, which are determined by means of one or more assigned to the goods recipient second physical sensors are detected, the one or more second sensor values comprising at least one second sensor value which quantifies the quantity of goods delivered,
  • Embodiments can have the advantage that the logging of the delivery of goods includes, in addition to the outgoing goods log of the goods sender about the goods actually sent, also an incoming goods log of the goods recipient about the goods actually received.
  • the corresponding goods receipt protocol includes one or more sensor values for the one or more physical properties of the incoming goods according to the first specification, which are recorded by means of one or more physical sensors assigned to the goods recipient.
  • the incoming goods log therefore indicates sensory measured values for one or more physical properties for which target values are specified in the first specification, which reflect the actual condition of the incoming goods with regard to the corresponding physical properties.
  • the corresponding sensor values include at least one sensor value which quantifies the delivered, ie incoming, quantity of goods.
  • the first DLT node of the goods recipient receives the goods receipt protocol from the goods recipient via the first network and checks the one or more second sensor values of the goods receipt protocol for compliance with the one or more physical properties of the goods to be delivered. This checks whether the one or more sensor values of the goods receipt log match one or more physical properties according to the shared data set within predefined tolerances. If there is no such match, a warning is sent, for example, to the recipient of the goods and/or the sender of the goods. Such a warning can, for example, trigger a subsequent delivery from the goods sender if the delivery quantity is too small. On the part of the goods recipient, such a warning may, for example, require confirmation of the different physical properties on the part of the goods recipient for a successful final validation of the delivery of goods.
  • the first data set is updated by the first DLT node using the result of checking the one or more first sensor values of the goods receipt log.
  • the update includes entries in the goods receipt log and/or one or more of the sensor values specified by the goods receipt log.
  • all sensor values specified in the goods receipt log are entered.
  • only those sensor values are entered that deviate from the values entered in the first data set for the physical properties of the goods to be delivered.
  • only a confirmation is entered in the second data set that the corresponding values for the physical properties match the recorded sensor values.
  • a fourth update message is transmitted from the first DLT node to the second DLT node.
  • the fourth update message includes, for example, the goods receipt log and/or one or more of the sensor values specified by the goods receipt log.
  • the fourth update message includes all sensor values specified by the goods receipt log.
  • the fourth update message only includes those sensor values that deviate from the values entered in the first data set for the physical properties of the goods to be delivered.
  • the fourth update message for sensor values of the goods receipt log, which match the values entered in the first data set for the physical properties of the goods to be delivered only includes a confirmation that the corresponding values for the physical properties according to the shared data set match the recorded sensor values .
  • the second DLT node updates the second data set, i.e. the second partial data set of the split data set, using the fourth update message.
  • the update comprises an entry of the goods receipt log and/or one or more of the sensor values specified by the goods receipt log.
  • all sensor values specified by the goods receipt log are entered.
  • only those sensor values are entered that differ from the values entered in the second data set for the physical properties of the goods to be delivered.
  • only a confirmation is entered in the second data set that the corresponding values for the physical properties match the recorded sensor values.
  • the one or more second physical sensors of the goods sender include one or more physical measuring devices for acquiring measurement data or sensor values.
  • Such measurement data are data that contain physical and/or chemical properties. describe the properties of a measurement object quantitatively or qualitatively.
  • Corresponding properties include, for example, weight, volume, temperature, humidity, pressure, grain size, sound field sizes, brightness, pH value, ionic strength, electrochemical potential, conductivity, viscosity, and/or translucency.
  • Measurement data is recorded using physical or chemical effects and converted into an electrical signal that can be further processed electronically.
  • the corresponding electrical signal which includes the recorded measurement data, is cryptographically encrypted.
  • symmetrical, asymmetrical or hybrid cryptographic encryption can be used. This means that the corresponding measurement data can be protected from unauthorized access, for example.
  • the corresponding electrical signal, which includes the recorded measurement data can be digitally signed. This means, for example, that the authenticity of the corresponding measurement data can be proven.
  • the validation message includes an invoice.
  • Embodiments can have the advantage that an invoice for the delivery of goods is checked in the course of checking the validation message. This makes it possible to ensure that information on the invoice regarding the physical properties of the delivered goods corresponds to the actual physical properties of the delivered goods. In particular, it can be ensured that the information on the quantity of goods delivered on which the invoice is based corresponds to the quantity of goods actually delivered.
  • the program instructions included in the at least one smart contract are further configured to generate the invoice.
  • the invoice is created by the second DLT node using the at least one smart contract. Checking the parameters of the validation message can be done during invoice creation.
  • Embodiments can have the advantage that invoice creation can be integrated directly in the course of validating the delivery of goods. For example, by registering the created invoice in the DLT system, the control of the delivery of goods is successfully completed.
  • the invoice is received by a first ERP system of the goods sender that creates the invoice.
  • the DLT system can be combined with an ERP system, for example an existing ERP system, of the goods sender.
  • the DLT system or the shared data record managed by the DLT system represents a single point of truth for the delivery of goods.
  • registration is required at least in the second data record on the second DLT node necessary.
  • registering includes entering an invoice number of the invoice in the second data record.
  • both the goods sender and the goods recipient have their own ERP systems, while the shared data set provided in the DLT system serves as a single point of truth for both parties involved, i.e. the goods recipient and the goods sender.
  • ERP enterprise resource planning
  • An ERP system refers to an application software or IT system or a large number of intercommunicating application software or IT systems that are used to support a company's resource planning. For example, complex ERP systems are divided into subsystems, i.e. application modules, which can be combined with each other as required.
  • Enterprise resource planning refers to the entrepreneurial task of planning, controlling and managing personnel and resources such as capital, operating resources, materials and information and communication technology in a timely manner and in accordance with requirements.
  • a core function of ERP in manufacturing companies is material requirements planning to ensure that all materials required to produce products and/or components are available in the right place, at the right time and in the right quantity.
  • the ERP systems of the goods sender and goods recipient can be used to be configured to create and/or compile data relevant to the delivery of goods and make this available to the DLT system.
  • the goods recipient's ERP system creates the delivery order and/or the goods receipt protocol and sends them to the first DLT node.
  • the ERP system of the goods sender creates the order confirmation, the goods issue log and/or the validation message and sends them to the second DLT node.
  • the data entered in the shared data set provided in the DLT system in the course of logging the delivery of goods is mirror-identical data of the delivery of goods from the first ERP system of the goods sender and / or a second ERP system of the goods recipient.
  • the first and/or second ERP systems are configured to control the processing of the delivery of goods.
  • Embodiments may have the advantage that data consistency can be implemented between the shared data set and the ERP systems of the goods sender and/or goods recipient.
  • the shared data record represents a single point of truth for both participants or their independent ERP systems.
  • the first DLT node receives the delivery order from the goods recipient's ERP system.
  • the second DLT node receives the delivery order from the ERP system of the goods sender.
  • the data entered in the shared data record reflects the goods delivery data stored in the first and/or second ERP system.
  • the processing of the delivery of goods is controlled by at least one smart contract, the program instructions of which are further configured to control the processing of the delivery of goods.
  • Embodiments can have the advantage that the delivery of goods can be handled by at least one smart contract.
  • neither the recipient of the goods nor the sender of the goods need an ERP system to handle the delivery of goods.
  • a computer The recipient's computer system can send the delivery order directly to the first DLT node via the first network, or the first DLT node can receive the delivery order directly from the recipient's computer system.
  • a sender's computer system can send the order confirmation directly to the second DLT node via the first network.
  • the first network is, for example, a public network.
  • the first network is the Internet or another wide area network, for example a radio or Ethernet-based network in a company or between participating companies.
  • the first network can be, for example, an intranet.
  • a prerequisite for receiving the delivery order from the goods recipient by the first DLT node is a successful authentication of the goods recipient by the first DLT node.
  • the first DLT node can ensure, by means of successful authentication of the goods recipient, that the delivery order actually comes from the goods recipient and is authorized by the goods recipient. Authentication can take place, for example, using a first user name and a first password, which the goods recipient must provide to the first DLT node in order to successfully authenticate. Further authentication methods, for example using cryptographic methods, chip cards, and/or biometric data, can also be provided.
  • a prerequisite for receiving the order confirmation of the goods sender by the second DLT node is a successful authentication of the goods sender by the second DLT node.
  • the second DLT node can ensure, by means of a successful authentication of the goods sender, that the order confirmation actually comes from the goods sender and is authorized by the goods sender.
  • Authentication can take place, for example, using a second user name and a second password, which the goods recipient uses to successfully authenticate against the first DLT Node must be specified. Further authentication methods, for example using cryptographic methods, chip cards, and/or biometric data, can also be provided.
  • a prerequisite for receiving the outgoing goods protocol from the goods sender by the second DLT node is a successful authentication of the goods sender by the second DLT node.
  • the second DLT node can ensure, by means of a successful authentication of the goods sender, that the goods issue protocol actually comes from the goods sender and is authorized by the goods sender.
  • Authentication can take place, for example, using a second user name and a second password, which the goods recipient must provide to the first DLT node in order to successfully authenticate.
  • Further authentication methods for example using cryptographic methods, chip cards, and/or biometric data, can also be provided.
  • a prerequisite for receiving the goods receipt protocol from the goods recipient by the first DLT node is a successful authentication of the goods recipient by the first DLT node.
  • the first DLT node can ensure, by means of a successful authentication of the goods recipient, that the goods receipt protocol actually comes from the goods recipient and is authorized by the goods recipient. Authentication can take place, for example, using a first user name and a first password, which the goods recipient must provide to the first DLT node in order to successfully authenticate.
  • a prerequisite for the use of the goods recipient's delivery order by the first DLT node is a successful signature verification of a signature of the delivery order by the first DLT node.
  • Embodiments can have the advantage that the authenticity of the delivery order can be checked based on the signature of the delivery order, that is, the first DLT node can check whether the received delivery order is actually authorized by the goods recipient.
  • the goods recipient uses one to sign the delivery order third signature key.
  • This third signature key is, for example, a third private cryptographic key of a third asymmetric cryptographic key pair.
  • the first DLT node and/or the smart contract executed on the first DLT node includes a third signature verification key for validating signatures of the goods recipient that were created using the third signature key.
  • This third signature verification key is, for example, a third public cryptographic key of the third asymmetric cryptographic key pair.
  • a prerequisite for the use of the goods sender's order confirmation by the second DLT node is a successful signature check of a signature of the order confirmation by the second DLT node.
  • Embodiments can have the advantage that the authenticity of the order confirmation can be checked based on the signature of the order confirmation, i.e. the second DLT node can check whether the received order confirmation is actually authorized by the sender of the goods.
  • the goods sender uses a fourth signature key to sign the order confirmation.
  • This fourth signature key is, for example, a fourth private cryptographic key of a fourth asymmetric cryptographic key pair.
  • the second DLT node and/or the smart contract executed on the second DLT node includes a fourth signature verification key for validating signatures of the goods sender that were created using the fourth signature key.
  • This fourth signature verification key is, for example, a fourth public cryptographic key of the fourth asymmetric cryptographic key pair.
  • a prerequisite for the use of the outgoing goods protocol of the goods sender by the second DLT node is a successful signature check of a signature of the outgoing goods protocol by the second DLT node.
  • Embodiments can have the advantage that the signature of the outgoing goods protocol can be used to check the authenticity of the outgoing goods protocol, that is, the second DLT node can check whether the received outgoing goods protocol is actually authorized by the sender of the goods. Used to sign the order confirmation For example, the goods sender has the fourth signature key, whose signatures the second DLT node can validate with the fourth signature verification key.
  • a prerequisite for the use of the goods receipt protocol of the goods recipient by the first DLT node is a successful signature verification of a signature of the goods receipt protocol by the first DLT node.
  • Embodiments can have the advantage that the signature of the goods receipt protocol can be used to check the authenticity of the goods receipt protocol, i.e. the first DLT node can check whether the received goods receipt protocol is actually authorized by the goods recipient. For example, to sign the goods receipt protocol, the goods recipient uses the third signature key, whose signatures the first DLT node can validate with the signature verification key.
  • the first DLT node and the second DLT node are provided by one or more DLT servers of the DLT system.
  • the first DLT node and the second DLT node are implemented on the same DLT server of the DLT system.
  • the first DLT node and the second DLT node are implemented on two different DLT servers of the DLT system.
  • the one or more DLT servers of the DLT system are located in one or more data centers secured against unauthorized access.
  • Embodiments can have the advantage that access security can prevent unauthorized physical access to the DLT servers and thus to the DLT nodes implemented on the DLT servers.
  • This physical access or access security can, for example, be implemented in addition to cryptographic access security, which prevents unauthorized access to the DLT servers or the DLT nodes via the first network, for example the Internet.
  • This cryptographic access security includes, for example, successful authentication as a prerequisite for access to the DLT nodes via the first network. For example, authentication requires the correct entry of a user name and password for the participant, such as the sender or recipient of the goods, to whom the corresponding DLT node is assigned.
  • Access security for the data center includes, for example, controlling access to the data center and using an alarm system to secure the rooms in the data center.
  • the alarm system includes, for example, an intruder alarm system (EMA), ie an electronically operated device that serves to protect the property.
  • EMA intruder alarm system
  • a burglar alarm system is configured, for example, to prevent burglaries by deterring them, to notify services providing assistance in the event of a burglary, such as the police and/or a private security service, to minimize the action time of burglars, to alert the immediate surroundings and the people involved , and/or to reconstruct an actual break-in.
  • data transmission between the DLT nodes takes place via a second network.
  • the second network is a different network from the first network.
  • the second network is a network that is independent of the first network.
  • the second network is the same network as the first network.
  • the second network is a private or a public network.
  • the second network is, for example, an intranet.
  • the second network is, for example, the Internet.
  • the program instructions included in the at least one smart contract are further configured to trigger an electronic payment transaction.
  • the payment transaction is triggered by the smart contract upon registration of the validation message in the DLT system.
  • Embodiments can have the advantage that payments and bookings can take place in real time. Embodiments may further have the advantage that by registering the validation message in the DLT system, ie with a successful validation of the delivery of goods in the DLT system, an electronic payment transaction is triggered. For example, the payment transaction is triggered with the registration of the validation message in the first data record and/or the second data record. For example, the registered validation message specifies the amount to be paid for the electronic payment transaction.
  • Payment transactions can be linked to data streams from validation and kept in a closed data cycle.
  • the triggered electronic payment transaction is a transfer from a bank account of the goods recipient to a bank account of the goods sender.
  • the triggered electronic payment transaction is an IBAN transfer from an IBAN account of the goods recipient to an IBAN account of the goods sender.
  • the triggered electronic payment transaction is a transaction of an amount of programmable money executed using the DLT system.
  • Embodiments may have the advantage that the transaction of the amount of programmable money can occur within the DLT system.
  • the transaction can thus be triggered by registering the validation message and executed directly in the DLT system, for example using the at least one smart contract.
  • Programmable money refers to a digital form of money in which the user can program inherent logic for conditional uses based on attributes of the digital money itself. Examples of this include triggering a transaction after one or more conditions have been met, such as time, location, type of use, etc.
  • the DLT system is configured to transfer the invoice amount to be paid from a goods recipient's programmable money account to a goods sender's programmable money account.
  • the DLT system may be configured to transform a fiat money amount of a fiat money account associated with the goods recipient into an amount of programmable money in the goods recipient's programmable money account.
  • the DLT system can be configured to at least partially transform the invoice amount transferred in the form of programmable money in the programmable money account of the goods sender into a fiat money amount in a fiat money account assigned to the goods sender.
  • Embodiments may have the advantage that the transaction can be processed using programmable money.
  • the fiat money amount of the goods recipient can be transformed into an amount of programmable money, which is at least partially used to pay for the delivered goods.
  • the invoice amount received by the goods sender as payment for the delivered goods in the form of programmable money can then be transformed into a fiat money amount.
  • This amount of fiat money can be credited to the sender of the goods in a fiat money account assigned to the sender of the goods.
  • Fiat money refers to a classic currency, i.e. a government-defined means of exchange and payment that is artificially created, uncovered and not limited. In other words, it is an economic object with no intrinsic value that serves as a medium of exchange.
  • the payment transaction is logged in the DLT system using the at least one smart contract.
  • electronic account statements about the recorded payment transaction are also issued to the recipient of the goods and/or the sender of the goods.
  • Embodiments may have the advantage that, in addition to executing the electronic payment transaction, electronic account statements are also issued for the corresponding payment transaction for the goods recipient and/or the goods sender.
  • the account statements are issued according to the MT940 standard.
  • the first data record of the first part includes information on one or more physical properties of the goods to be delivered from a delivery order as a first specification.
  • the physical properties of the first specification include at least a quantity of goods to be delivered.
  • the first data record of the first part includes information on a second specification of the one or more physical properties of the goods to be delivered according to an order confirmation.
  • the first data record of the first part includes a test result of a test of the second specification.
  • the first data set of the first part includes one or more first sensor values for the one or more physical properties of the goods according to an outgoing goods protocol, which are recorded by means of one or more physical sensors assigned to the goods sender.
  • the one or more first sensor values include at least a first sensor value that quantifies the quantity of goods delivered.
  • the first data record of the first part includes a test result of a test of the first sensor values of the goods issue log.
  • the first data set of the first part includes one or more second sensor values for the one or more physical properties of the goods according to a goods receipt protocol, which are recorded by means of one or more physical sensors assigned to the goods recipient.
  • the one or more second sensor values include at least one second sensor value that quantifies the quantity of goods delivered.
  • the first data record of the first part includes a test result of a test second sensor values of the goods issue log.
  • the first data record of the first part includes a registration of a validation message for validating the delivery of goods.
  • the registration includes information about one or more parameters of the validation message.
  • the parameters include at least one quantity of goods to be validated.
  • the first data record of the first part includes a test result of a test of the parameters of the validation message.
  • the second data record of the second part includes information on one or more physical properties of the goods to be delivered from a delivery order as a first specification.
  • the physical properties of the first specification include at least a quantity of goods to be delivered.
  • the second data record of the second part includes information on a second specification of the one or more physical properties of the goods to be delivered according to an order confirmation.
  • the second data record of the second part includes a test result of a test of the second specification.
  • the second data set of the second part includes one or more first sensor values for the one or more physical properties of the goods according to an outgoing goods protocol, which are recorded by means of one or more physical sensors assigned to the goods sender.
  • One or more first sensor values include at least a first sensor value that quantifies the quantity of goods delivered.
  • the second data record of the second part includes a test result of a test of the first sensor values of the goods issue log.
  • the second data set of the second part includes one or more second sensor values for the one or more physical properties of the goods according to a goods receipt protocol, which are recorded by means of one or more physical sensors assigned to the goods recipient.
  • the one or more second sensor values include at least one second sensor value that quantifies the quantity of goods delivered.
  • the second data record of the second part includes a test result of a test of the second sensor values of the goods issue log.
  • the second data record of the second part includes a registration of a validation message for validating the delivery of goods.
  • the registration includes information about one or more parameters of the validation message.
  • the parameters include at least one quantity of goods to be validated.
  • the second data record of the second part includes a test result of a test of the parameters of the validation message.
  • the shared data record is the result of executing one or more of the aforementioned method steps of the method for computer-implemented control of the delivery of goods.
  • the shared data set is the result of executing each of the aforementioned method steps of the method for computer-implemented control of the delivery of goods.
  • the shared data set which is distributed across two DLT nodes and includes the two (partial) data sets of the goods recipient and the goods sender, can have the advantage of providing an effective approach for the confidential processing of transactions between the two DLT nodes. Furthermore, such a shared data set enables effective security of transactions and an increase in data security between the DLT nodes.
  • the shared data set may be used in any method according to one or more embodiments of the present description.
  • the data record can be the subject of the aforementioned methods and can be processed and updated by them.
  • Further embodiments include using a shared data set according to one or more embodiments of the present description to initialize delivery of goods in the DLT system.
  • the shared data set may be used for initialization in any method according to one or more embodiments of the present description.
  • Further embodiments include using a shared data set according to one or more embodiments of the present description to log the delivery of goods in the DLT system.
  • the shared data set may be used for logging in any method according to one or more embodiments of the present description.
  • Further embodiments include using a shared data set according to one or more embodiments of the present description to validate delivery of goods in the DLT system.
  • the shared data set can be validated in any method according to one or more embodiments of the present description.
  • Execution of the program instructions by the processor causes the processor to control the DLT node so that the DLT node does the following in the course of initializing the delivery of goods in the DLT system:
  • Further embodiments include a DLT node, wherein the program instructions providing the at least one smart contract include program instructions for entering and checking outgoing goods protocols in the course of goods deliveries from the goods sender to the goods recipient. Execution of the program instructions by the processor of the DLT node causes the processor to further control the DLT node so that the DLT node does the following in the course of logging the delivery of goods in the DLT system:
  • Further embodiments include a DLT node, wherein the program instructions providing the at least one smart contract include program instructions for validating the delivery of goods. Execution of the program instructions by the processor of the DLT node causes the processor to further control the DLT node so that the DLT node does the following in the course of validating the delivery of goods in the DLT system:
  • the DLT node is configured to carry out one or more of the aforementioned method steps of the DLT node assigned to the goods recipient according to an exemplary embodiment of the method for computer-implemented control of the delivery of goods.
  • the DLT node is configured to carry out each of the aforementioned method steps of the DLT node assigned to the goods recipient according to an exemplary embodiment of the method for computer-implemented control of the delivery of goods.
  • a “processor” here means a logic circuit that is used to execute program instructions.
  • the logic circuit can be implemented on one or more discrete components, in particular on one or more chips.
  • a “processor” is understood to mean a microprocessor or a microprocessor system consisting of several processor cores and/or several microprocessors.
  • program or “program instructions” is understood here, without limitation, to mean any type of computer program that includes machine-readable instructions for controlling a functionality of the computer.
  • memory here refers to both volatile and non-volatile memories, in particular electronic memories or digital storage media.
  • Non-volatile memory here means an electronic memory for the permanent storage of data.
  • a non-volatile memory can be considered non-changeable Memory can be configured, also known as Read-Only Memory (ROM), or as changeable memory, also known as Non-Volatile Memory (NVM).
  • ROM Read-Only Memory
  • NVM Non-Volatile Memory
  • this can be an EEPROM, for example a flash EEPROM, referred to as flash for short.
  • flash flash for short.
  • a non-volatile memory is characterized by the fact that the data stored on it is retained even after the power supply is switched off.
  • a “volatile memory” here is understood to mean an electronic memory for the temporary storage of data, which is characterized by the fact that stored data is lost after the power supply is switched off.
  • this can be a volatile random access memory, also referred to as random access memory (RAM), or a volatile main memory of the processor.
  • RAM random access memory
  • a “protected memory area” here is understood to mean an area of an electronic memory to which access, i.e. read access or write access, is only possible via a processor of the corresponding electronic device. According to embodiments, access from the processor coupled to the memory is only possible if a necessary condition is met. This can be, for example, a cryptographic condition, in particular a successful authentication and/or a successful authorization check of an access request.
  • a “communication interface” here is understood to mean an interface through which data can be received and sent, whereby the communication interface can be configured as contact-based or contactless.
  • the communication interface can be an internal interface or an external interface, which is connected to an assigned device, for example by means of a cable or wirelessly.
  • a “network” is understood here to mean any transmission medium with a connection for communication, in particular a local connection or a local network, in particular a local area network (LAN), a private network, in particular an intranet, or a virtual private network (VPN).
  • a computer system can have a standard radio interface for connection to a WLAN. It can also be a public network, such as the Internet. Depending on the embodiment, this connection can also be established via a mobile network.
  • a “mobile network” is understood here and in the following to mean a digital cellular mobile network, which can be constructed according to a mobile radio standard such as GSM, UMTS, LTE, CDMA or another standard.
  • Execution of the program instructions by the processor causes the processor to control the DLT node so that the DLT node does the following in the course of initializing the delivery of goods in the DLT system:
  • the first data record being a first part of a data record shared between the DLT node and the further DLT node, the first data record being at least one or more physical properties of the goods to be delivered according to a first specification of a delivery order, the physical properties of the first specification comprising at least one quantity of goods to be delivered,
  • Further embodiments include a DLT node, wherein the program instructions providing the at least one smart contract include program instructions for entering and checking goods dispatch protocols in the course of goods deliveries from the goods sender to the goods recipient.
  • the execution of the program instructions by the processor of the DLT node causes the processor to further control the DLT node such that the DLT node carries out the following in the course of logging the goods delivery in the DLT system:
  • the outgoing goods protocol comprising one or more first sensor values for the one or more physical properties of the outgoing goods according to the second specification, which are determined by means of one or more first ones assigned to the goods sender physical sensors are detected, the one or more first sensor values comprising at least a first sensor value which quantifies the quantity of goods delivered,
  • Further embodiments include a DLT node, wherein the program instructions providing the at least one smart contract include program instructions for validating the delivery of goods.
  • the execution of the program instructions by the processor of the DLT node causes the processor to further control the DLT node so that the DLT node carries out the following in the course of validating the delivery of goods in the DLT system:
  • the DLT node is configured to carry out one or more of the aforementioned method steps of the DLT node assigned to the goods sender according to an exemplary embodiment of the method for computer-implemented control of the delivery of goods.
  • the DLT node is configured to carry out each of the aforementioned method steps of the DLT node assigned to the goods sender according to an exemplary embodiment of the method for computer-implemented control of the delivery of goods.
  • 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.
  • the DLT system is configured to initialize the delivery of goods in the DLT system. Initializing includes:
  • the delivery order determining one or more physical properties of the goods to be delivered as a first specification, the physical properties of the The first specification includes at least one quantity of goods to be delivered,
  • Further embodiments include a DLT system further configured to perform logging of goods delivery in the DLT system.
  • the at least one smart contract includes program instructions for entering and checking outgoing goods protocols in the course of goods deliveries from the goods sender to the goods recipient.
  • Logging includes:
  • the outgoing goods protocol comprising one or more first sensor values for the one or more physical properties of the outgoing goods according to the second specification, which are determined by means of one or more assigned to the goods sender first physical sensors are detected, the one or more first sensor values comprising at least a first sensor value which quantifies the quantity of goods delivered,
  • Further embodiments include a DLT system further configured to perform validating delivery of goods in the DLT system.
  • the at least one smart contract includes program instructions for validating the delivery of goods.
  • Validating includes:
  • fourth updating of the second data set by the second DLT node, the fourth updating being registering the validation message by the second DLT node in the second Data set using the at least one smart contract includes,
  • the DLT system is configured to execute one or more of the aforementioned exemplary embodiments of the method for computer-implemented goods delivery control.
  • the DLT system is configured to to carry out the aforementioned exemplary embodiments of the method for computer-implemented control of the delivery of goods.
  • the computer program includes program instructions for initializing the delivery of goods in the DLT system. Initializing includes:
  • the delivery order determining one or more physical properties of the goods to be delivered as a first specification, the physical properties of the The first specification includes at least one quantity of goods to be delivered,
  • the order confirmation comprising a second specification of the one or more physical properties of the goods to be delivered
  • Further embodiments include a computer program, which further includes program instructions for logging the delivery of goods in the DLT system.
  • the at least one smart contract includes program instructions for entering and checking outgoing goods protocols in the course of goods deliveries from the goods sender to the goods recipient.
  • Logging includes:
  • the outgoing goods protocol comprising one or more first sensor values for the one or more physical properties of the outgoing goods according to the second specification, which are determined by means of one or more assigned to the goods sender first physical sensors are detected, the one or more first sensor values comprising at least a first sensor value which quantifies the quantity of goods delivered,
  • Further embodiments include a computer program which further includes program instructions for validating the delivery of goods in the DLT system.
  • the at least one smart contract includes program instructions for validating the delivery of goods.
  • Validating includes:
  • fourth update of the second data set by the second DLT node comprises registering the validation message by the second DLT node in the second data set using the at least one smart contract
  • the computer program is configured to execute one or more of the aforementioned exemplary embodiments of the method for computer-implemented control of the delivery of goods.
  • the computer program is configured to execute each of the aforementioned exemplary embodiments of the method for computer-implemented control of the delivery of goods.
  • a computer-readable disk or medium that stores thereon program instructions that, when executed by at least one processor (or at least one electronic device), the at least one processor (or at least one electronic device) set up to carry out a method according to one of the above embodiments.
  • the program instructions can correspond to the program instructions of the computer program according to embodiments. It should be understood that multiple data carriers or media may also be provided, which are based on individual processors or electronic devices for carrying out the intended methods.
  • FIG. 1A shows a schematic flowchart of a first part of an exemplary method for checking a delivery of goods
  • FIG. 1B shows a schematic flowchart of a second part of an exemplary method for checking a delivery of goods
  • Figure 2 is a schematic flowchart of logging a delivery of goods using a goods receipt log
  • FIG. 3 shows a schematic block diagram of an exemplary DLT system for computer-implemented control of a delivery of goods
  • 4 shows a schematic flowchart of an exemplary method for computer-implemented control of a delivery of goods
  • 5 shows a schematic flowchart of an exemplary method for computer-implemented control of a delivery of goods
  • FIG. 6 shows a schematic flowchart of an exemplary method for computer-implemented control of a delivery of goods
  • FIG. 7 shows a schematic block diagram of an exemplary system for computer-implemented control of a delivery of goods including electronic payment transactions
  • Figure 8A shows a first part of a first exemplary graphical user interface
  • Figure 8B shows a second part of a first exemplary graphical user interface
  • Figure 9 shows a second exemplary graphical user interface.
  • Figures 1A and 1B show an exemplary method for computer-implemented control of a delivery of goods from a goods sender to a goods recipient using an access-restricted DLT system.
  • the DLT system includes a first DLT node assigned to the goods recipient and a second DLT node assigned to the goods sender.
  • the DLT system provides at least one smart contract, which includes program instructions for entering and checking delivery orders, order confirmations and/or outgoing goods protocols in the course of goods deliveries from the goods sender to the goods recipient and/or for validating the goods deliveries.
  • the method includes initializing the delivery of goods in the DLT system, logging the delivery of goods in the DLT system and validating the delivery of goods in the DLT system.
  • the initialization is shown in Figure 1A, the logging and validation in Figure 1B.
  • a delivery order from the goods recipient is received via a first network by the first DLT node.
  • the delivery order is a delivery order for goods to be delivered from the goods sender to the goods recipient.
  • the delivery order determines one or more physical properties of the goods to be delivered as a first specification, which include at least a quantity of goods to be delivered.
  • the first data record managed by the first DLT node is created, for example as a result of receipt of the delivery order.
  • This first data record is a first partial data record of a split data record.
  • the corresponding split data record is a data record that includes the first partial data record on the first DLT node and a second partial data record on the second DLT node. Only the first DLT node and thus the goods recipient has authorization to edit the first partial data record, i.e. write authorization, while only the second DLT node and thus the goods sender has authorization to edit the second data record, i.e. write authorization.
  • At least one or more physical properties of the delivery order are also entered by the first DLT node into the first data record using the at least one smart contract.
  • These registered one or more physical properties include at least one quantity of goods to be delivered.
  • this first data set or the one or more physical properties entered in the first data set are transmitted to the second DLT node of the goods sender in accordance with the first specification of the delivery order.
  • the second DLT node creates the second sub-dataset of the split data set, in which a or several physical properties can be entered according to the first specification.
  • the registered one or more physical properties according to the first specification include at least one quantity of goods to be delivered.
  • the second DLT node receives an order confirmation from the goods sender via the first network, which includes a second specification of the one or more physical properties of the goods to be delivered.
  • the second specification is checked for compliance with the first specification by the second DLT node using the at least one smart contract and in block 212 the second data set is updated using the check result of the Checking the second specification.
  • updating the second data set using the test result includes, for example, entering a confirmation of the first specification.
  • updating the second data set using the test result includes entering the second specification in the second data set in addition to the first specification.
  • updating the second data set using the test result includes, for example, replacing or updating the physical properties according to the first specification with the different physical properties according to the second specification.
  • the different physical properties according to the second specification are entered into the second data set in addition to the first specification.
  • the second specification is entered into the second data record in addition to the first specification.
  • a first update message is transmitted from the second DLT node to the first DLT node in block 214.
  • the first update message identifies the different one or more physical properties according to the second specification.
  • the first update message includes the entire second specification or a copy of the second specification.
  • the first DLT node updates the first data set, i.e. the first sub-data set of the shared data set, using the first update message. If the second specification matches the first specification, updating the first data set using the first update message includes, for example, entering a confirmation of the first specification. For example, updating the first data set using the first update message includes entering the second specification in addition to the first specification into the first data set.
  • updating the first data set using the first update message includes, for example, replacing or updating the physical properties according to the first specification with the different physical properties according to the second specification.
  • the different physical properties according to the second specification are entered into the second data set in addition to the first specification.
  • the second specification is entered into the second data record in addition to the first specification.
  • a handshake is carried out between the first DLT node and the second DLT node to compare the first specification and the second specification, so that the first and second specifications resulting from the comparison match.
  • a confirmation message is sent from the second DLT node to the goods sender via the network work transmitted.
  • a match between the second specification and the first specification occurs, for example, in the case of an identity.
  • the second specification agrees with the first specification, for example, if no deviations occur that exceed a predefined tolerance range.
  • the confirmation message shows the sender of goods, for example, that an agreement has been reached between the recipient of the goods and the sender of the goods regarding the corresponding delivery of goods.
  • the confirmation message includes, for example, the specification of the corresponding delivery of goods.
  • the corresponding confirmation message serves as a trigger to initiate the corresponding delivery of goods.
  • steps 200 to 216 of the method according to Figure 1A may be optional.
  • the second DLT node of the goods sender receives the goods issue protocol from the goods sender via the first network and in block 222 checks the one or more first sensor values of the goods issue protocol for compliance with the one or more physical properties of the goods to be delivered. This checks whether the one or more sensor values of the outgoing goods protocol match one or more physical properties according to the shared data set within predefined tolerances. If there is no such match, both For example, a warning message is sent to the sender of the goods and/or the recipient of the goods. Such a warning can, for example, trigger a subsequent delivery from the goods sender if the delivery quantity is too small. On the part of the goods recipient, such a warning can, for example, trigger a check of the different physical properties upon arrival of the goods. For example, such a warning may require confirmation of the different physical properties by the recipient of the goods for a successful final validation of the delivery of goods.
  • the second data set is updated by the second DLT node using the result of checking the one or more first sensor values of the goods issue log.
  • the update includes entries in the outgoing goods log and/or one or more of the sensor values specified by the outgoing goods log.
  • all sensor values specified in the goods issue log are entered.
  • only those sensor values are entered that deviate from the values entered in the second data set for the physical properties of the goods to be delivered.
  • only a confirmation is entered in the second data set that the corresponding values for the physical properties match the recorded sensor values.
  • a second update message is transmitted from the second DLT node to the first DLT node.
  • the second update message includes, for example, the outgoing goods log and/or one or more of the sensor values specified by the outgoing goods log.
  • the second update message includes all sensor values specified by the goods issue log.
  • the second update message only includes those sensor values that deviate from the values entered in the second data set for the physical properties of the goods to be delivered.
  • the second update message for sensor values of the goods issue log, which match the values entered in the second data set for the physical properties of the goods to be delivered only includes a confirmation that the corresponding values for the physical properties according to the shared data set match the recorded sensor values .
  • the first DLT node updates the first record, ie, the first subset of the shared record, using the second update message.
  • the update includes entries in the outgoing goods log and/or one or more of the sensor values specified by the outgoing goods log.
  • all sensor values specified in the goods issue log are entered.
  • only those sensor values are entered that deviate from the values entered in the first data set for the physical properties of the goods to be delivered.
  • only a confirmation is entered in the first data set that the corresponding values for the physical properties match the recorded sensor values.
  • a validation of the delivery of goods is carried out in the DLT system.
  • parameters of a validation message for validating the delivery of goods are checked by the second DLT node.
  • the checked parameters of the validation message comprise at least one indication of the quantity of goods delivered that is to be validated.
  • Checking the corresponding parameters comprises checking the quantity of goods to be validated for agreement with the sensor value quantifying the quantity of goods delivered according to the goods issue protocol within a predefined tolerance. If the quantity of goods to be validated matches the sensor value quantifying the quantity of goods delivered within the predefined tolerance, the second data set is updated by the second DLT node in block 242 using the validation message.
  • the updating comprises registering the validation message by the second DLT node in the second data set.
  • an identifier of the validation message is entered in the second data set.
  • a check value, such as a hash value, of the validation message is entered in the second data set.
  • one or more parameters of the validation message are entered in the second data record.
  • the validation message is entered in the second data record.
  • validation is triggered by receiving the validation message or by generating the validation message.
  • generating The validation message is triggered by the receipt of a confirmation of receipt of the delivered goods from the recipient of the goods.
  • a confirmation of receipt is received in the form of a goods receipt protocol.
  • a third update message is transmitted from the second DLT node to the first DLT node.
  • the third update message includes, for example, the validation message data entered into the second data record during the update.
  • the third update message includes, for example, the complete updated second record.
  • the third update message includes, for example, the validation message.
  • the first DLT node updates the first record using the second record's third update message.
  • Updating the first data record includes registering the validation message in the first data record. For example, during registration, an identifier of the validation message is entered into the first data record. For example, a check value, such as a hash value, of the validation message is entered into the first data record. For example, one or more parameters of the validation message are entered into the first data record. For example, the validation message is entered in the first record.
  • steps 220 to 246 of the method according to Figure 1B may be optional. Furthermore, steps 220 to 246 can be combined as desired with one or more of steps 200 to 216 according to FIG. 1A and in any order.
  • Figure 2 shows an example of logging a delivery of goods using a goods receipt protocol.
  • the program instructions included in the at least one smart contract are also configured to enter and check goods receipt protocols in the course of goods deliveries from the goods sender to the goods recipient.
  • the corresponding goods receipt log includes one or more sensor values for the one or more physical properties of the incoming goods according to the first specification, which are recorded by means of one or more physical sensors assigned to the goods recipient.
  • the incoming goods log therefore indicates sensory measured values for one or more physical properties for which target values are specified in the first specification, which reflect the actual condition of the incoming goods with regard to the corresponding physical properties.
  • the corresponding sensor values include at least one sensor value which quantifies the delivered, ie incoming, quantity of goods.
  • logging the delivery of goods in the DLT system according to FIG. 1 B includes block 230.
  • the first DLT node receives a goods receipt log from the goods recipient via the first network.
  • the first DLT node checks the one or more second sensor values of the goods receipt protocol for compliance with the one or more physical properties of the goods to be delivered. This checks whether the one or more sensor values of the goods receipt log match one or more physical properties according to the shared data set within predefined tolerances. If there is no such match, a warning is sent, for example, to the recipient of the goods and/or the sender of the goods. Such a warning can, for example, trigger a subsequent delivery from the goods sender if the delivery quantity is too small. On the part of the goods recipient, such a warning may, for example, require confirmation of the different physical properties on the part of the goods recipient for a successful final validation of the delivery of goods.
  • the first data set is updated by the first DLT node using the result of checking the one or more first sensor values of the goods receipt log.
  • the update includes entries in the goods receipt log and/or one or more of the sensor values specified by the goods receipt log.
  • all sensor values specified in the goods receipt log are entered.
  • only those sensor values are entered that deviate from the values entered in the first data set for the physical properties of the goods to be delivered.
  • only one Confirmation is entered in the second data set that the corresponding values for the physical properties match the recorded sensor values.
  • a fourth update message is transmitted from the first DLT node to the second DLT node.
  • the fourth update message includes, for example, the goods receipt log and/or one or more of the sensor values specified by the goods receipt log.
  • the fourth update message includes all sensor values specified by the goods receipt log.
  • the fourth update message only includes those sensor values that deviate from the values entered in the first data set for the physical properties of the goods to be delivered.
  • the fourth update message for sensor values of the goods receipt log, which match the values entered in the first data set for the physical properties of the goods to be delivered only includes a confirmation that the corresponding values for the physical properties according to the shared data set match the recorded sensor values .
  • the second DLT node updates the second data set, i.e. the second sub-data set of the split data set, using the fourth update message.
  • the update includes entries in the goods receipt log and/or one or more of the sensor values specified by the goods receipt log. For example, all sensor values specified in the goods receipt log are entered. For example, only those sensor values are entered that deviate from the values entered in the second data set for the physical properties of the goods to be delivered. For example, for sensor values of the goods receipt log that match the values entered in the second data set for the physical properties of the goods to be delivered, only a confirmation is entered in the second data set that the corresponding values for the physical properties match the recorded sensor values.
  • FIG. 3 shows an exemplary DLT system 182 for computer-implemented control of a delivery of goods from a goods sender to a goods recipient.
  • the DLT system 182 includes a plurality of DLT servers 140, 160.
  • the DLT system 182 includes a first DLT node assigned to the goods recipient, which is provided by a first DLT server 140 of the DLT system 182.
  • the DLT system 182 includes a second DLT node assigned to the goods sender, which is provided by a second DLT server 160 of the DLT system 182.
  • the DLT nodes can also be deployed on a single DLT server, for example DLT server 140 or DLT server 160, and this description is not intended to deploy DLT nodes on separate DLT servers limited.
  • the first DLT server 140 includes a processor 142 configured to execute program instructions 144.
  • the program instructions 144 implement the first DLT node of the goods recipient on the first DLT server 140.
  • the program instructions 144 implement one or more smart contracts for execution by the first DLT node on the first DLT server 140.
  • the program instructions 144 which implement the one or more smart contracts, include program instructions for executing a method, for example the method according to Figures 1A and/or 1B or parts thereof, for the computer-implemented control of a delivery of goods from a goods sender to a goods recipient using the access-restricted DLT system 182.
  • the method can include entering and checking delivery orders, order confirmations and/or goods issue protocols in In the course of goods deliveries from the goods sender to the goods recipient and/or validation of the goods deliveries, in any combination.
  • the first DLT server 140 has a memory 146 and a communication interface 156.
  • the communication interface 156 is configured so that the first DLT server 140 can communicate via a network 184, for example with a computer system 120 of the goods recipient.
  • the network 184 is, for example, the Internet.
  • the communication interface 156 is, for example, for communication via a DLT network 180 with other DLT servers of the DLT system, for example with the second DLT server 160, on which the DLT node of the goods sender is implemented.
  • the DLT network 180 can, for example, be from the network 184 will be included.
  • the DLT network 180 is an independent network, such as an intranet.
  • a private cryptographic key 154 of an asymmetric key pair assigned to the first DLT node of the goods recipient is stored in a protected memory area 152 of the memory 146 of the first DLT server 140.
  • This private cryptographic key 154 serves, for example, as a signature key for creating electronic signatures of the first DLT node.
  • Corresponding signatures can be checked with a public cryptographic key 150 of the corresponding asymmetric key pair.
  • the public cryptographic key 150 is provided as part of a certificate.
  • the first DLT node of the goods recipient makes this public cryptographic key 150 or the certificate comprising the public cryptographic key 150 available to other DLT nodes, such as the second DLT node of the goods sender, as a signature verification key.
  • the second DLT server 160 includes a processor 162 configured to execute program instructions 164.
  • the program instructions 164 implement the second DLT node of the goods sender on the second DLT server 160.
  • the program instructions 164 also implement one or more smart contracts on the second DLT server 160 for execution by the second DLT node.
  • the smart contracts on the second DLT node can correspond to the smart contracts on the first DLT node, ensuring that both DLT nodes define corresponding behavior.
  • the program instructions 164 which implement the one or more smart contracts, include program instructions for executing a method, for example the method according to Figures 1A and/or 1B or parts thereof, for computer-implemented control of a delivery of goods from a goods sender to a goods recipient using of the access-restricted DLT system 182.
  • the procedure can include entering and checking delivery orders, order confirmations and/or outgoing goods protocols in the course of goods deliveries from the goods sender to the goods recipient and/or validating the goods deliveries, in any combination.
  • the second DLT server 160 has a memory 166 and a communication interface 176.
  • the communication interface 176 is configured so that the first DLT server 160 can communicate via the network 184, for example with a computer system 100 of the goods sender.
  • the communication interface 176 is, for example, for communication via the DLT network 180 with other DLT servers of the DLT system, for example with the first DLT server 140 on which the DLT node of the goods sender is implemented.
  • a private cryptographic key 174 of an asymmetric key pair assigned to the second DLT node of the goods sender is stored in a protected memory area 172 of the memory 166 of the second DLT server 160.
  • This private cryptographic key 174 serves, for example, as a signature key for creating electronic signatures of the second DLT node.
  • Corresponding signatures can be checked with a public cryptographic key 170 of the corresponding asymmetric key pair.
  • the public cryptographic key 170 is provided as part of a certificate.
  • the first DLT node of the goods sender makes this public cryptographic key 170 or the certificate comprising the public cryptographic key 170 available to other DLT nodes, such as the first DLT node of the goods recipient, as a signature verification key.
  • a split data record is generated on the two DLT nodes, which includes a first partial data record 148 on the first DLT node and a second partial data record 168 on the second DLT node.
  • the first partial data set 148 is stored in the memory 146 of the first DLT server 140.
  • the second partial data set 168 is stored in the memory 166 of the second DLT server 160.
  • Only the first DLT node and thus the goods recipient has authorization to edit the first partial data record, ie write authorization
  • only the second DLT node and thus the goods sender has authorization to edit the second data record, ie write authorization.
  • only the goods recipient has read authorization to read the first partial data record via the first DLT node implemented on the first DLT server 140 and only the goods sender has read authorization to read the second partial data record via the on the second DLT node implemented on the second DLT server 160.
  • Execution of the program instructions 144 by the processor 142 causes the processor 142 to control the first DLT server 140 so that the first DLT node implemented on the first DLT server 140 in the course of initializing the delivery of goods in the DLT system 182 to receive a delivery order from the goods recipient for goods to be delivered by the goods sender to the goods recipient.
  • the first DLT node receives the delivery order, for example via the network 184 from a computer system 120 of the goods recipient.
  • the delivery order specifies one or more physical properties of the goods to be delivered as an initial specification.
  • the physical properties of the first specification include at least one quantity of goods to be delivered.
  • the consignee's computer system 120 includes a processor 130 configured to execute program instructions 132.
  • the program instructions 132 cause the computer system 120 to communicate, for example via the network 184, with the first DLT server 140 or the first DLT node of the goods recipient implemented on the first DLT server 140.
  • the goods recipient's computer system 120 sends the delivery order to the first DLT node.
  • the computer system 120 includes a communication interface 136 for communication via the network 184.
  • the computer system 120 has a memory 122.
  • a private cryptographic key 128 of an asymmetric key pair assigned to the goods recipient is stored in a protected memory area 126 of the memory 122 of the computer system 120.
  • This private cryptographic key 128 serves, for example, as a signature key for creating electronic signatures of the goods recipient.
  • Corresponding signatures can be checked with a public cryptographic key 124 of the corresponding asymmetric key pair.
  • the public cryptographic key 124 is provided as part of a certificate.
  • the computer system 120 makes this public cryptographic key 124 or the certificate comprising the public cryptographic key 124 available to other participants, such as the goods recipient's first DLT node implemented on the first DLT server 140, as a signature verification key.
  • the first node creates the record 148 managed by the DLT node and enters at least the one or more physical properties of the delivery order into the first record 148 using the at least one smart contract.
  • the first data set 148 is sent from the first DLT node or the first DLT server 140 via the DLT network 180 to the second DLT node implemented on the second DLT server 160.
  • the first DLT node receives via the DLT network 180 from the second DLT node or the second DLT server 160 at least one first update message about an update of the second data set 168 on the second DLT server.
  • the update was carried out using a first test result of a test of a second specification of the one or more physical properties of the goods to be delivered according to an order confirmation from the sender of the goods for compliance with the first specification according to the delivery order from the goods recipient.
  • the first record 148 is then updated by the first DLT node using the first update message.
  • the second DLT server 160 receives the corresponding order confirmation, for example via the network 184, from a computer system 100 of the goods sender.
  • the consignee's computer system 160 includes a processor 110 configured to execute program instructions 112.
  • the program instructions 112 cause the computer system 100 to communicate, for example via the network 184, with the second DLT server 160 or the second DLT node of the goods sender implemented on the second DLT server 160.
  • the computer system 100 of the goods sender sends the order confirmation to the second DLT node.
  • the computer system 100 includes a communication interface 116 for communication via the network 184.
  • the computer system 100 has a memory 102.
  • a private cryptographic key 108 of an asymmetric key pair assigned to the goods recipient is stored in a protected memory area 106 of the memory 102 of the computer system 100.
  • This private cryptographic key 108 serves, for example, as a signature key for creating electronic signatures of the goods sender.
  • Corresponding signatures can be checked with a public cryptographic key 104 of the corresponding asymmetric key pair.
  • the public cryptographic key 104 is provided as part of a certificate.
  • the computer system 100 makes this public cryptographic key 104 or the certificate comprising the public cryptographic key 104 available to other participants, such as the goods sender's second DLT node implemented on the second DLT server 160, as a signature verification key.
  • execution of the program instructions by the processor 142 causes the processor 142 to control the first DLT node such that the DLT node receives at least a second update message from the second DLT in the course of logging the delivery of goods in the DLT system 182.
  • Node receives an update of the second data set 168.
  • This second update is an update using a second test result of a test of one or more first sensor values of a goods issue protocol for compliance with the one or more physical properties of the goods to be delivered according to the shared data set within predefined first tolerances.
  • This one or more first sensor values of the outgoing goods protocol are recorded by means of one or more physical sensors 113 assigned to the goods sender.
  • the tested first sensor values include at least the first sensor value that quantifies the quantity of goods delivered.
  • the first record 148 is then updated by the DLT node using the second update message.
  • execution of the program instructions 144 by the processor 142 causes the processor 142 to control the first DLT node so that the first DLT node receives at least a third update message from the second in the course of validating the delivery of goods in the DLT system 182 DLT node receives an update of the second data set 168 using a validation message.
  • Updating the second data set 168 using the validation message includes registering the validation message in the second data set 168.
  • the updating of the second data set 168 using the validation message confirms a successful check of parameters of the validation message by the second DLT node. These parameters include at least a quantity of goods to be validated.
  • Execution of the program instructions 164 by the processor 162 causes the processor 162 to control the second DLT server 160 so that the second DLT node implemented on the second DLT server 160 in the course of initializing the delivery of goods in the DLT system 182 receives at least the first data set 148 created by the first DLT node of the goods recipient, which includes at least the one or more physical properties of the goods to be delivered according to the first specification of the delivery order.
  • the second DLT node then creates the second data set 168 managed by the DLT node.
  • the second DLT node updates the created second data set 168.
  • the updating includes entering at least one or more physical properties of the first specification into the second data set 168 , which include at least one or more registered physical properties of the first specification of the quantity of goods to be delivered.
  • the second DLT node receives the order confirmation from the goods sender from the goods sender's computer system 100 via the network 184.
  • the order confirmation includes the second specification of one or more physical properties of the goods to be delivered.
  • the second DLT node checks the second specification for compliance with the first specification using the one or more smart contracts and updates the second data set 168 using the resulting check result.
  • the second DLT node transmits at least the first update message to the first DLT node to update the first data set 148.
  • the execution of the program instructions 164 by the processor 162 further causes the processor 162 to control the second DLT node so that the second DLT node, in the course of logging the delivery of goods in the DLT system 182, receives the outgoing goods log from the goods sender via the first network 184 receives.
  • the second DLT node receives the outgoing goods protocol from the computer system 100 of the goods sender.
  • the goods issue log includes one or more first sensor values for the one or more physical properties of the outgoing goods according to the second specification, which are recorded by means of the one or more physical sensors 114 assigned to the goods sender.
  • the second DLT node checks the one or more first sensor values of the outgoing goods protocol for compliance with the one or more physical properties of the goods to be delivered according to the shared data set or the second sub-data set 168 of the shared data set within predefined first tolerances.
  • the second DLT node uses one of the one or more smart contracts.
  • the tested first sensor values include at least the first sensor value that quantifies the quantity of goods delivered.
  • the second data set 168 is updated by the second DLT node using the check result.
  • the second DLT node transmits at least the second update message to the first DLT node to update the first data set 148.
  • execution of the program instructions 164 by the processor 162 causes the processor 162 to control the second DLT node such that, in the course of validating the delivery of goods in the DLT system 182, the second DLT node uses the parameters of the validation message to validate the Delivery of goods using the one or more smart contracts is verified.
  • the tested parameters include at least the quantity of goods to be validated.
  • Checking the parameters includes checking the quantity of goods to be validated for compliance with the first sensor value that quantifies the quantity of goods delivered within the predefined tolerance. If the quantity of goods to be validated matches the first sensor value quantifying the quantity of goods delivered within the predefined tolerance, the second DLT node updates the second data set 168.
  • This updating includes registering the validation message by the second DLT node in the second data set 168 using at least one of the one or more smart contracts.
  • the second DLT node transmits the corresponding update message for registering the validation message to the first DLT node for updating the first data set 148.
  • the first DLT node and the second DLT node may also be implemented on a common DLT server of the DLT system 180.
  • the first DLT node can also, for example the computer system 120 of the goods recipient and/or the second DLT node can be implemented on the computer system 100 of the goods sender.
  • FIG. 4 shows a schematic flow diagram of an exemplary method for computer-implemented control of a delivery of goods from a sender of goods to a recipient of goods.
  • the recipient of goods sends a delivery order 190 to a DLT node assigned to it in the DLT system 182.
  • this delivery order 190 specifies, for example, a quantity of the goods to be delivered as a physical property of the corresponding goods.
  • This sending of the delivery order 190 results in a first partial data set of a split data set being generated in the DLT system 182 using the delivery order 190.
  • the data of the delivery order 190 is also transmitted to the sender of goods.
  • the status of the delivery of goods is "proposed" at this stage.
  • step 302 the goods sender sends an order confirmation 191 to a DLT node assigned to it in the DLT system 182.
  • this order confirmation 191 specifies, for example, a quantity of the goods to be delivered as a physical property of the corresponding goods.
  • This confirmation is entered, for example, in a second partial data record of the split data record on the DLT node of the goods sender in the DLT system 182. If the quantity specified in the order confirmation 191 matches the quantity specified in the delivery order 190, the delivery of goods takes on the status "confirmed" in the DLT system 182.
  • the data of the order confirmation 191 or an update of the second partial data record are also transmitted to the goods recipient.
  • the goods recipient can send an update 192 of the delivery order 190 with a new quantity information to the DLT system 182 or the first DLT node assigned to it in the DLT system 182.
  • the first DLT node enters this update of the specification of the goods delivery, for example, in the first partial data record and also transmits it to the goods sender or the second DLT node assigned to the goods sender.
  • the status of the delivery of goods in the DLT system 182 changes to, for example, “updated”.
  • the goods sender sends an update 193 of the order confirmation 191 with the new quantity information to the DLT system 182 or the second DLT node assigned to it in the DLT system 182.
  • the second DLT node carries this update of the confirmation Specification of the delivery of goods, for example, in the second partial data record and also transmits this to the goods recipient or the first DLT node assigned to the goods recipient.
  • the status of the delivery of goods in the DLT system 182 changes back to “confirmed”, for example.
  • the goods sender sends, for example, a validation message, such as an invoice, to the DLT system for validating or updating the shared data record using the validation message 194.
  • Validating includes, for example, checking the information in the validation message the specification of the delivery of goods stored in the shared data record. If these match, the validation message is registered in the shared data set in the DLT system 182. For example, an invoice number of the validation message is stored in the shared record. In this case, for example, the status of the delivery of goods in the DLT system 182 changes to “completed”.
  • Figure 5 shows a further schematic flowchart of an exemplary method for computer-implemented control of a delivery of goods from a goods sender to a goods recipient.
  • a first DLT node of the goods recipient and a second DLT node of the goods sender carry out the following steps using one or more smart contracts:
  • the first DLT node creates a first partial data record of a shared data record and updates it Data from a delivery order from the goods recipient.
  • This first partial data record is sent to the second DLT node of the goods sender.
  • the second DLT node creates a second subset of the split record with the data from the delivery order.
  • the status of the delivery of goods at this stage is “proposed”.
  • the second DLT node updates the second partial data record with data from an order confirmation from the goods sender. Furthermore, an update message about the update of the second partial data record is sent to the first DLT node of the goods recipient using the order confirmation. The first DLT node updates the first partial data set accordingly. Subsequently, for example, one or more update steps and/or a cancellation can take place.
  • the first DLT node updates, for example, the first partial data set based on an update of the delivery order. For example, the quantity, delivery date, price, etc. of the goods to be delivered are updated. This update is sent to the second DLT node. The second DLT node notes this update, for example, in the second partial data set. The status of the goods delivery thus changes to "updated”.
  • the second DLT node confirms the proposed update, for example based on an updated order confirmation, and enters this confirmation in the second partial data set. This confirmation of the update is transmitted to the first DLT node. The first DLT node notes this confirmation, for example, in the first partial data set. The status of the goods delivery thus changes back to "confirmed”.
  • An update of the delivery conditions can also come from the goods sender.
  • the second DLT node updates the second partial data set based on an update to the order confirmation. For example, the quantity, delivery date, price, etc. of the goods to be delivered are updated. This update is delivered to the first DLT node. The first DLT node notes this update, for example, in the first partial data record. The status of the goods delivery changes to “updated”.
  • the first DLT node confirms the proposed update, for example based on an updated delivery order, and enters this confirmation into the first partial data record. This confirmation of the update is sent to the second DLT node. The second DLT node notes this confirmation, for example, in the second partial data record. The status of the delivery of goods then changes back to “confirmed”.
  • the delivery of goods can also be canceled by the sender or the goods recipient.
  • the first or second DLT node enters a cancellation into the first or second partial data set based on a received cancellation notification.
  • a cancellation message is also sent to the second or first DLT node.
  • the second or first DLT node notes the corresponding cancellation in the second or first partial data record. In this case, the status of the delivery of goods changes to “cancelled” and the procedure is ended.
  • the second DLT node updates the second partial data record in step 334 based on a check of a validation message, for example on a delivery of goods. If the check is successful, the validation message is registered in the second partial data record, for example an identifier of the validation message is correct, such as entering an invoice number into the second partial data record. This update is delivered to the first DLT node. The first DLT node notes this update, for example, in the first partial data record by also registering the validation message. The status of the goods delivery changes to “completed”.
  • Both the first and the second DLT node according to Figure 5 can have one or more features of the DLT nodes according to Figure 3 implemented on the first and second DLT servers 140, 160. Furthermore, the DLT nodes according to Figure 5 can be configured to at least partially carry out the method according to Figures 1A and/or 1B or parts thereof.
  • step 350 the goods recipient or a computer system 120 of the goods recipient sends a delivery order to a first assigned to the goods recipient DLT node in the DLT system 182.
  • step 352 the goods sender or a computer system 100 of the goods sender sends an order confirmation to a second DLT node in the DLT system 182 assigned to the goods sender.
  • Conditions are based on the delivery order and the order confirmation of the delivery of goods is entered into two partial data records of a split data record and compared with each other in the course of a 2-way match.
  • the goods sender or a computer system 100 of the goods sender sends an outgoing goods protocol in step 354 to the second DLT node in the DLT system 182.
  • the outgoing goods protocol includes sensor values for physical properties of the outgoing goods, which were recorded using physical sensors of the goods sender and include at least one sensor value that quantifies the quantity of goods delivered.
  • the goods sender or a computer system 100 of the goods sender sends a validation message to the second DLT node in the DLT system 182 in step 356.
  • the goods issue protocol and the validation message in the course of a 3-Way Matches checks whether the condition of the goods actually delivered and the conditions according to 2-Way Match match the information in the validation message agree on this. This ensures that the information in the validation message is correct. If the validation message is checked successfully, it is registered in the shared data record.
  • Figure 7 shows a further schematic block diagram of an exemplary system for computer-implemented control of a delivery of goods from a sender of goods to a recipient of goods, including electronic payment transactions.
  • the system can comprise a DLT system 182, for example the DLT system according to embodiments of Figures 3 or 4.
  • the payment transactions can be coupled with data streams from the control of the delivery of goods and kept in a closed data cycle.
  • participant A can in step 360 transfer fiat money, for example euros, to a pool account of a bank that processes the payment transactions. This is done within a banking system or using a bank computer system 186.
  • the bank or a DLT node assigned to the bank records the receipt of fiat money in the DLT system 182, for example via an API of the bank or another suitable programming or communication interface of the bank in the DLT system 182.
  • An API application programming interface
  • the bank automatically allocates e-money, i.e. electronic money, to a DLT account of user A.
  • the amount of e-money received in user A's DLT account corresponds to the amount of fiat money transferred.
  • Any participant, for example user B, can carry out a corresponding procedure in order to provide e-money to an associated DLT account in the DLT system 182.
  • the DLT accounts may be provided on respective DLT nodes of the participants in the DLT system 182.
  • User A as a goods recipient can, for example on an ERP system, place an order with a goods sender, e.g. user B.
  • the order is transmitted as a delivery order to a DLT node of user A in step 366.
  • the delivery order can contain ERP data from the goods recipient's ERP system.
  • user A can, for example, use the goods recipient's computer system. which may be connected to the associated DLT node in the DLT system 182 via an API or any other programming or communication interface.
  • the DLT node of user A initializes the delivery of goods, as stated above, for example with regard to the embodiment according to FIG. 1A.
  • an order specification is transmitted to a DLT node of the goods sender, which can transmit the order specification to a computer system of the goods sender in step 368.
  • user B can confirm the order using an ERP system on the sender's computer system.
  • the order specification and the confirmation can, for example, contain ERP data from the ERP system of the goods sender.
  • the sender's computer system may be connected to the associated DLT node in the DLT system 182 via an API or any other programming or communication interface.
  • the ordering process is handled by the DLT system 182 between the DLT nodes of the goods sender and the goods recipient using one or more smart contracts, which is shown as an example in step 370.
  • one of the exemplary methods described in the preceding figures is used for checking a delivery of goods from a goods sender to a goods recipient using the access-restricted DLT system 182. If necessary, a handshake can be carried out (semi-)automatically between the DLT nodes involved. If further data is required or parameters need to be confirmed, the DLT nodes involved can communicate with the associated computer systems of the goods sender or goods recipient in order to receive input, for example via the respective ERP systems, which are then incorporated into the DLT system 182 . Accordingly, the ordering process and delivery of goods can take place via the DLT system 182.
  • a delivery of goods and possibly a sending of an invoice, which must take place due to requirements outside the DLT system 182, can be carried out in step 372.
  • an electronic payment transaction can be triggered from the DLT account of user A to a DLT account of user B.
  • a participant for example user B, can in step 374 instruct at least some of the e-money received in the course of one or more electronic payment transactions to be paid out. This can be done via the bank's associated DLT node, which can communicate with the bank's computer system.
  • the bank changes the issued e-money into fiat money and transfers the corresponding fiat money via the pool account to an account of user B.
  • Any participant for example user A, can carry out a corresponding procedure in order to e-money. Withdraw money as fiat money to an associated bank account. It should be understood that the delivery of goods does not necessarily have to entail a payout of electronic money as fiat money. Rather, the e-money can remain in DLT accounts to carry out further electronic payment transactions
  • the DLT system 182 may additionally be configured to record and audit all DLT payment transactions in the DLT system 182, such as for AML (Anti-Money Laundering) reasons, i.e. to prevent money laundering, by the bank.
  • AML Anti-Money Laundering
  • the bank's anti-money laundering software is used to check the recorded DLT transactions.
  • customer data is analyzed to detect suspicious transactions.
  • the customer data is filtered, classified according to the level of trust and examined for anomalies.
  • a report is generated, for example. Furthermore, payments can be released or prevented.
  • regulatory-compliant processing of all payment transactions is also ensured by the DLT system 182:
  • a regulator 378 is implemented, which records all transactions for compliance purposes.
  • a notary (node) 380 also known as a notary node, is implemented, which prevents the same units of electronic money from being used or spent several times.
  • Figures 8A and 8B and Figure 9 show exemplary graphical user interfaces (Graphical User Interface/GUI) for executing the method for computer-implemented control of a delivery of goods from a goods sender to a goods recipient using an access-restricted DLT system.
  • Figure 8A shows a first part of a first exemplary graphical user interface.
  • 8A includes an exemplary representation of the data of a first partial data record 148 of a shared data record, which represents a delivery order from a goods recipient (“buyer”).
  • Figure 8B shows a second part of the first exemplary graphical user interface.
  • 8B includes an exemplary representation of the data of a second partial data set 168 of the shared data set, which represents a suggestion for changed delivery conditions on the part of the goods sender (“Seiler”).
  • the graphical user interface shown in Figures 8A and 8B includes a menu for selecting various areas. These include a “dashboard”, i.e. a graphical user interface for visualizing data, an area with “orders”, a “wallet”, i.e. a digital wallet, an area with “reports” ( “Reports”) and an area with “Settings”. A current user is also specified (“Logged in as”/“Logged In As”). Also shown is a selection element for creating a new order (“Create new order”). Search parameters can also be entered (“Search and filter”). Figures 8A and 8B show an example of an area with “orders”.
  • the following areas can be selected in a submenu: “Open”, “Confirmed”, “Paid” and “Rejected”. These areas list open, confirmed, paid or rejected orders.
  • the graphical user interface includes a “Buyer” area for a goods recipient and a “Seller” area for a goods sender.
  • the representation of the first partial data record 148 of the goods recipient in FIG. 8A shows what the goods recipient sees, ie "Buyer - Their View", and indicates, for example: a time of a last update "Last update"("Lastupdate"("Buyer - Their View”).
  • Last update a status “UPDATED”, a “Transaction ID”, an “Order number”, a “Delivery date”) , a “Product ID buyer”, a “Product name buyer”, a “Product ID seller”, a “Product ID seller” ( “Product name seller”), a “Line Item ID”, a “Settlement (In days)” information, an “Invoice number” , an “invoice date,” a “tax ID,” a “tax” information, a “description,” a “Update reason”, a “quantity” (“Quantity”), an indication of “Units”, a “Price per unit”, a “Unit of price per Unit”, a “Total price”, and a “currency”. Furthermore, a selection element “Accept all” is provided for the goods sender in order to accept all information or specifications according to the first partial data record 148 of the goods recipient.
  • the representation of the second partial data set 168 of the goods sender in Figure 8B shows what the goods sender sees, i.e. “Seller - My View” (“Seiler - My View”) if the user is logged in as a goods sender, and indicates, for example: a time a last update, a status “UPDATED”, a “Transaction ID”, an “Order number”. “Delivery date”, a “Product ID buyer”, a “Product name buyer”, a “Product ID seller”.
  • This information is except for the information about the time of the last update “Last update”, the status “UPDATED”, the “Transaction ID” and the “Order number “ (“Order number”), the “Product ID buyer” and the “Product name buyer” can be changed by the goods sender. Furthermore, selection elements “Cancel”, “Send” and “Confirm” are provided for canceling, sending or confirming the information or updates to the information.
  • Figure 9 shows an exemplary dashboard of a DLT node of a goods sender with an overview of current orders and payments.
  • the graphical user interface shown in Figure 9 includes a menu for selecting different areas. These include a “dashboard”, i.e. a graphical user interface for visualizing data, an “orders” section, a “wallet”, i.e. a digital wallet, a “reports” section ( “Reports”) and an area with “Settings”. There is also an indication of who is currently logged in “Logged In As”.
  • Figure 9 shows an example of the “dashboard”.
  • the dashboard includes information about “Cash available now”, “Cash available tomorrow” and “Cash available the day after tomorrow”.
  • the dashboard also includes an “Overview”, a list of “Most recent orders”, “Most recent updates” and “Paid on time “).
  • the “Overview” includes a graphical representation, e.g. in the form of a histogram, of various information for the “Today” period. This information includes a “Wallet balance”, details of incoming payments “Incoming”, outgoing payments “Outgoing” and rejected payments or delivery orders “Rejected” ( “Rejected”).
  • the “Most recent orders” list lists current orders and indicates, for example, how many current orders that are not listed still exist.
  • the “Most recent updates” list lists recent updates and indicates, for example, when a last update took place. “Last updated”. For example, this happened “4 minutes ago”.
  • the “Paid on time” statement shows what percentage of the incoming goods “Incoming” and what percentage of the outgoing goods “Outgoing” are paid on time.
  • the dashboard includes information on a number of “Transactions”, which are pending, “Pending”, which are to be done, “To dos”, which are paid, “Paid “ (“Paid”) and which ones are rejected are “Rejected”.
  • the DLT System provides at least one smart contract, wherein the at least one smart contract includes program instructions for entering and checking delivery orders and order confirmations, the method comprising initializing the delivery of goods in the DLT system, the initializing comprising:
  • the delivery order determining one or more physical properties of the goods to be delivered as a first specification, the physical properties of the The first specification includes at least one quantity of goods to be delivered,
  • the order confirmation comprising a second specification of the one or more physical properties of the goods to be delivered
  • the at least one smart contract comprises program instructions for entering and checking outgoing goods protocols in the course of goods deliveries from the goods sender to the goods recipient, the method further comprising logging the goods delivery in the DLT system, wherein the Logging includes:
  • the outgoing goods protocol comprising one or more first sensor values for the one or more physical properties of the outgoing goods according to the second specification, which are determined by means of one or more assigned to the goods sender first physical sensors are detected, the one or more first sensor values comprising at least a first sensor value which quantifies the quantity of goods delivered,
  • fourth updating of the second data set by the second DLT node, the fourth updating being registering the validation message by the second DLT node in the second Data set using the at least one smart contract includes,
  • initializing further comprises: if the one or more physical properties according to the second specification that are entered into the second data set deviate from the one or more physical properties according to the first specification from the first data set , Performing a handshake between the first DLT node and the second DLT node to match the first specification of the first data set and the second specification of the second data set so that the first and second specifications resulting from the matching match.
  • initializing further comprises: if one or more deviations between the one or more physical properties according to the second specification entered into the second data set and the one or more physical properties according to the first specification the first data set is greater than the predefined third tolerances, performing a handshake between the first DLT node and the second DLT node Node for matching the first specification of the first data set and the second specification of the second data set such that the first and second specifications resulting from the matching match within the predefined third tolerances.
  • the goods receipt protocol comprising one or more second sensor values for the one or more physical properties of the incoming goods according to the first specification, which are determined by means of one or more assigned to the goods recipient second physical sensors are detected, the one or more second sensor values comprising at least one second sensor value which quantifies the quantity of goods delivered,
  • validation message comprises an invoice and which is sent by the at least one smart device
  • the program instructions included in the contract are further configured to invoice the invoice, the invoice being created by the second DLT node using the at least one smart contract, the parameters of the validation message being checked during the invoice creation.
  • the data entered in the shared data set provided in the DLT system during the logging of the delivery of goods are mirror-identical data of the delivery of goods from the first ERP system of the sender of the goods and/or a second ERP system of the recipient of the goods, wherein the first and/or second ERP system are configured to control the processing of the delivery of goods, wherein data consistency between the shared data set and the ERP systems is ensured by entering the mirror-identical data.
  • a prerequisite for receiving the delivery order from the goods recipient by the first DLT node is a successful authentication of the goods recipient by the first DLT node
  • a prerequisite for receiving the order confirmation from Goods sender by the second DLT node is a successful authentication of the goods sender by the second DLT node
  • a prerequisite for receiving the outgoing goods protocol from the goods sender by the second DLT node is a successful authentication of the Goods sender is by the second DLT node
  • a prerequisite for receiving the goods receipt protocol from the goods recipient by the first DLT node is a successful authentication of the goods recipient by the first DLT node.
  • a prerequisite for the use of the delivery order of the goods recipient by the first DLT node is a successful signature verification of a signature of the delivery order by the first DLT node
  • a prerequisite for the use of the order confirmation of the goods sender by the second DLT node is a successful signature verification of a signature of the order confirmation by the second DLT node
  • a prerequisite for the use of the goods dispatch protocol of the goods sender by the second DLT node is a successful signature verification of a signature of the goods dispatch protocol by the second DLT node
  • a prerequisite for the use of the goods receipt protocol of the goods recipient by the first DLT node is a successful signature verification of a signature of the goods receipt protocol by the first DLT node.
  • Method according to feature combination 26 wherein the DLT system is configured to transfer the invoice amount to be paid from an account of the goods recipient for programmable money to an account of the goods sender for programmable money, for example, the DLT system is further configured to do so Transform a fiat money amount of a fiat money account assigned to the goods recipient into an amount of programmable money in the goods recipient's programmable money account.
  • Shared data record of an access-restricted DLT system for computer-implemented control of a delivery of goods from a goods sender to a goods recipient using the DLT system comprising a first part, the first part being a first DLT node assigned to the goods recipient managed first data set, the shared data set further comprising a second Part includes, wherein the second part is a second data set managed by a second DLT node assigned to the goods sender.
  • DLT node of an access-restricted DLT system for computer-implemented control of a delivery of goods from a goods sender to a goods recipient
  • the DLT node being implemented on a DLT server of the DLT system and assigned to the goods recipient
  • the DLT server having a processor and a memory with program instructions
  • at least one smart contract is provided by the program instructions 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
  • executing the Program instructions by the processor cause the processor to control the DLT node so that the DLT node performs the following in the course of initializing the delivery of goods in the DLT system:
  • the delivery order determining one or more physical properties of the goods to be delivered as a first specification, the physical properties of the first Specification includes at least one quantity of goods to be delivered,
  • DLT node according to feature combination 33, wherein the program instructions providing the at least one smart contract include program instructions for entering and checking outgoing goods protocols in the course of goods deliveries from the goods sender to the goods recipient, the execution of the program instructions by the processor causing the processor to do so to further control the DLT node so that the DLT node does the following in the course of logging the delivery of goods in the DLT system:
  • DLT node according to one of the feature combinations 33 or 34, whereby the minimum program instructions providing at least a smart contract include program instructions for validating the delivery of goods, the execution of the program instructions by the processor causing the processor to further control the DLT node so that the DLT node in the course of validating the delivery of goods in the DLT system does the following:
  • DLT node according to one of the feature combinations 33 to 35, wherein the execution of the program instructions by the processor further causes the processor to control the DLT node such that the DLT node carries out the method steps of the first DLT node of the method one of the feature combinations 4 to 28.
  • DLT node of an access-restricted DLT system for computer-implemented control of a delivery of goods from a goods sender to a goods recipient
  • the DLT node being implemented on a DLT server of the DLT system and assigned to the goods sender
  • the DLT server having a processor and a memory with program instructions, wherein at least one smart contract is provided by the program instructions on the DLT node, the program instructions providing the at least one smart contract comprising program instructions for entering and checking delivery orders and order confirmations, wherein execution of the program instructions by the processor causes the processor to control the DLT node such that the DLT node performs the following in the course of initializing the delivery of goods in the DLT system:
  • the first data record being a first part of a data record shared between the DLT node and the further DLT node, the first data record being at least one or more physical properties of the goods to be delivered according to a first specification of a delivery order, the physical properties of the first specification comprising at least one quantity of goods to be delivered,
  • the order confirmation comprising a second specification of the one or more physical properties of the goods to be delivered
  • DLT node according to feature combination 37, wherein the program instructions providing the at least one smart contract include program instructions for entering and checking outgoing goods protocols in the course of goods deliveries from the goods sender to the goods recipient, the execution of the program instructions by the processor causing the processor to do so , further control the DLT node so that the DLT node in the course of logging the delivery of goods in the DLT System does the following:
  • the outgoing goods protocol comprising one or more first sensor values for the one or more physical properties of the outgoing goods according to the second specification, which are determined by means of one or more first ones assigned to the goods sender physical sensors are detected, the one or more first sensor values comprising at least a first sensor value which quantifies the quantity of goods delivered,
  • DLT node according to one of the feature combinations 37 or 38, wherein the program instructions providing the at least one smart contract include program instructions for validating the deliveries of goods, the execution of the program instructions by the processor causing the processor to further activate the DLT node to control that the DLT node carries out the following in the course of validating the delivery of goods in the DLT system:
  • DLT system for computer-implemented control of a delivery of goods from a goods sender to a goods recipient, which comprises a first DLT node assigned to the goods recipient and a second DLT node assigned to the goods sender, the first DLT node and the second DLT node being represented by one or several DLT servers of the DLT system are provided, the DLT system providing at least one smart contract, the at least one smart contract comprising program instructions for entering and checking delivery orders and order confirmations, the DLT system being configured to do so to carry out an initialization of the delivery of goods in the DLT system, the initialization comprising:
  • the delivery order determining one or more physical properties of the goods to be delivered as a first specification, the physical properties of the The first specification includes at least one quantity of goods to be delivered,
  • the order confirmation comprising a second specification of the one or more physical properties of the goods to be delivered
  • the at least one smart contract includes program instructions for entering and checking outgoing goods protocols in the course of goods deliveries from the goods sender to the goods recipient, the DLT system being further configured to log the goods delivery in the DLT system, where logging includes:
  • the outgoing goods protocol comprises one or more first sensor values for the one or more physical properties of the outgoing goods according to the second specification, which are detected by one or more first physical sensors assigned to the goods sender, wherein the one or more first sensor values comprise at least one first sensor value which quantifies the quantity of goods delivered,
  • DLT system according to one of the feature combinations 41 or 42, wherein the at least one smart contract comprises program instructions for validating the delivery of goods, the DLT system being further configured to carry out a validation of the delivery of goods in the DLT system, wherein Validation includes:
  • fourth updating of the second data set by the second DLT node, the fourth updating being registering the validation message by the second DLT node in the second Data set using the at least one smart contract includes, • transmitting at least a third update message from the second DLT node to the first DLT node,
  • DLT system according to one of the feature combinations 41 to 43, wherein the DLT system is further configured to carry out the method according to one of the feature combinations 4 to 28.
  • Computer program for controlling a delivery of goods from a goods sender to a goods recipient using an access-restricted DLT system which comprises a first DLT node assigned to the goods recipient and a second DLT node assigned to the goods sender
  • the computer program providing at least one smart contract , wherein the at least one smart contract comprises program instructions for entering and checking delivery orders and order confirmations
  • the computer program comprises program instructions for initializing the delivery of goods in the DLT system, the initialization comprising:
  • the delivery order determining one or more physical properties of the goods to be delivered as a first specification, the physical properties of the The first specification includes at least one quantity of goods to be delivered,
  • the order confirmation comprising a second specification of the one or more physical properties of the goods to be delivered
  • the outgoing goods protocol comprising one or more first sensor values for the one or more physical properties of the outgoing goods according to the second specification, which are determined by means of one or more assigned to the goods sender first physical Sensors are detected, the one or more first sensor values comprising at least a first sensor value which quantifies the quantity of goods delivered,
  • fourth updating of the second data set by the second DLT node, the fourth updating being registering the validation message by the second DLT node in the second Data set using the at least one smart contract includes, • transmitting at least a third update message from the second DLT node to the first DLT node,
  • Computer program according to one of the feature combinations 45 to 47 the computer program further comprising program instructions for executing the method according to one of the feature combinations 4 to 28.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Marketing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger unter Verwendung eines zugangsbeschränkten DLT-Systems (182). Das DLT-System (182) umfasst einen ersten dem Warenempfänger zugeordneten DLT-Knoten und einen zweiten dem Warensender zugeordneten DLT-Knoten. Ferner stellt das DLT-System (182) mindestens einen Smart-Contract bereit mit Programminstruktionen zu einem Eintragen und Prüfen von Lieferaufträgen (190), Auftragsbestätigungen (191) und Warenausgangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger sowie zu einem Validieren der Warenlieferung. Das Verfahren umfasst beispielsweise ein Initialisieren der Warenlieferung in dem DLT-System (182), beispielsweise ein Protokollieren der Warenlieferung in dem DLT-System (182) und/oder beispielsweise ein Validieren der Warenlieferung in dem DLT-System (182).

Description

Verwendung eines Distributed-Ledger-Systems zur Kontrolle von Warenlieferungen
B e s c h r e i b u n g
Die Erfindung betrifft ein Verfahren zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger unter Verwendung eines zugangsbeschränkten DLT-Systems. Ferner betrifft die Erfindung eine Verwendung eines geteilten Datensatzes eines DLT-Systems im Zuge einer computerimplementierten Kontrolle der Warenlieferung, einen DLT-Knoten des zugangsbeschränkten DLT-Systems, welcher auf einem DLT-Server des DLT-Systems implementiert und dem Warenempfänger der Warenlieferung zugeordnet ist, einen DLT-Knoten des zugangsbeschränkten DLT-Systems, welcher auf einem DLT-Server des DLT-Systems implementiert und dem Warensender der Warenlieferung zugeordnet ist, das zugangsbeschränkte DLT-System zur computerimplementierten Kontrolle der Warenlieferung, sowie ein Computerprogramm zur Kontrolle der Warenlieferung unter Verwendung des zugangsbeschränkte DLT-Systems.
Aus der WO 2021/18366 A1 ist ein Verfahren zur Anpassung eines Produktionsprozesses bekannt, wobei ein erster Knoten einer ersten Partei eines Blockchain-Netzwerks ausgebildet ist, Bestelltransaktionen in dem Blockchain-Netzwerk zu veröffentlichen, wobei veröffentlichte Bestelltransaktionen durch das Blockchain-Netzwerk validiert werden, wobei das Verfahren das Analysieren von validierten Bestelltransaktionen in dem Blockchain-Netzwerk durch mindestens einen Knoten einer zweiten Partei des Blockchain-Netzwerks umfasst, wobei das Analysieren das Folgende umfasst:
Identifizieren validierter Bestelltransaktionen, Extrahieren von Bestellparametern, Senden der Auftragsparameter an ein Simulationssystem zur Simulation eines Produktionsprozesses für das bestellte Produkt basierend auf den Auftrags Parametern, Empfangen eines Kapazitätsparameters von dem Simulationssystem, Erzeugen eines Angebots basierend auf dem Kapazitätsparameter, und wenn der Knoten des Erstanbieters das Angebot annimmt, Anpassen des Produktionsprozesses auf der Grundlage des Angebots.
Dieser oder weitere Ansätze zur Nachverfolgung von Waren setzen Blockchains ein. Allerdings haben Blockchains den Nachteil, dass einmal in die Blockchain eingetragene Daten nicht mehr angepasst werden können. Ferner sind in eine Blockchain eingetragene Daten zumindest für alle die entsprechende Blockchain verwaltenden Blockchain-Server sichtbar. Im Falle einer öffentlichen Blockchain, sind die in die Blockchain eingetragenen Daten sogar öffentlich, d.h. für jedermann, zugänglich.
Der Erfindung liegt die Aufgabe zugrunde, ein verbessertes Verfahren zu schaffen, welches für eine Kontrolle einer Warenlieferung geeignet ist und die Sicherheit sowie Vertraulichkeit der im Zuge dieser Kontrolle verwendeten Daten gewährleisten kann.
Die der Erfindung zugrunde liegende Aufgabe wird jeweils mit den Merkmalen der unabhängigen Patentansprüche gelöst. Ausführungsformen der Erfindung sind in den abhängigen Patentansprüchen angegeben.
Ausführungsformen umfassen ein Verfahren zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger unter Verwendung eines zugangsbeschränkten DLT-Systems. Das DLT-System umfasst einen ersten dem Warenempfänger zugeordneten DLT-Knoten und einen zweiten dem Warensender zugeordneten DLT-Knoten. Ferner stellt das DLT-System mindestens einen Smart-Contract bereit. Der mindestens eine Smart-Contract umfasst Programminstruktionen zu einem Einträgen und Prüfen von Lieferaufträgen und Auftragsbestätigungen.
Das Verfahren umfasst ein Initialisieren der Warenlieferung in dem DLT-System. Das Initialisieren umfasst:
• Empfangen eines Lieferauftrags des Warenempfängers über ein erstes Netzwerk durch den ersten DLT-Knoten über von dem Warensender an den Warenempfänger zu liefernde Ware, wobei der Lieferauftrag eine oder mehrere physikalische Eigenschaften der zu liefernden Ware als eine erste Spezifikation bestimmt, wobei die physikalischen Eigenschaften der ersten Spezifikation zumindest eine zu liefernde Warenmenge umfassen, • Erstellen eines ersten durch den ersten DLT-Knoten verwalteten Datensatzes und Einträgen mindestens der einen oder mehreren physikalischen Eigenschaften des Lieferauftrags durch den ersten DLT-Knoten in den ersten Datensatz unter Verwendung des mindestens einen Smart-Contracts, wobei der erste Datensatz ein erster Teil eines zwischen dem ersten DLT-Knoten und dem zweiten DLT-Knoten geteilten Datensatzes ist,
• Übermitteln mindestens des ersten Datensatzes von dem ersten DLT-Knoten an den zweiten DLT-Knoten,
• Erstellen eines zweiten durch den zweiten DLT-Knoten verwalteten Datensatzes, wobei der zweite Datensatz ein zweiter Teil des geteilten Datensatzes ist, und erstes Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten basierend auf dem ersten Datensatz, wobei das erste Aktualisieren ein Einträgen mindestens einer oder mehrerer der physikalischen Eigenschaften der ersten Spezifikation in den zweiten Datensatz umfasst, wobei die mindestens eine oder mehreren eingetragenen physikalischen Eigenschaften der ersten Spezifikation die zu liefernde Warenmenge umfassen,
• Empfangen einer Auftragsbestätigung des Warensenders über das erste Netzwerk durch den zweiten DLT-Knoten, wobei die Auftragsbestätigung eine zweite Spezifikation der eine oder mehreren physikalischen Eigenschaften der zu liefernden Ware umfasst,
• Prüfen der zweiten Spezifikation auf Übereinstimmung mit der ersten Spezifikation unter Verwendung des mindestens einen Smart-Contracts,
• zweites Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten unter Verwendung eines ersten Prüfergebnisses des Prüfens der zweiten Spezifikation,
• Übermitteln mindestens einer ersten Aktualisierungsnachricht von dem zweiten DLT- Knoten an den ersten DLT-Knoten,
• erstes Aktualisieren des ersten Datensatzes durch den ersten DLT-Knoten unter Verwendung der ersten Aktualisierungsnachricht.
Ausführungsformen umfassen ein Verfahren, welches ferner ein Protokollieren der Warenlieferung in dem DLT-System umfasst. Der mindestens eine Smart-Contract umfasst Programminstruktionen zu einem Einträgen und Prüfen von Warenausgangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger. Das Protokollieren umfasst: • Empfangen eines Warenausgangsprotokolls von dem Warensender über das erste Netzwerk durch den zweiten DLT-Knoten, wobei das Warenausgangsprotokoll eine oder mehrere erste Sensorwerte für die eine oder mehreren physikalischen Eigenschaften der ausgehenden Ware gemäß der zweiten Spezifikation umfasst, welche mittels eines oder mehrerer dem Warensender zugeordneter erster physikalischer Sensoren erfasst sind, wobei der eine oder die mehreren ersten Sensorwerte zumindest einen ersten Sensorwert umfassen, welcher die gelieferte Warenmenge quantifiziert,
• Prüfen des einen oder der mehreren ersten Sensorwerte des Warenausgangsprotokolls auf Übereinstimmung mit der einen oder den mehreren physikalischen Eigenschaften der zu liefernden Ware gemäß dem geteilten Datensatz innerhalb vordefinierter erster Toleranzen unter Verwendung des mindestens einen Smart-Contracts, wobei die geprüften ersten Sensorwerte zumindest den die gelieferte Warenmenge quantifizierenden ersten Sensorwert umfassen,
• drittes Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten unter Verwendung eines zweiten Prüfergebnisses des Prüfens des einen oder der mehreren ersten Sensorwerte des Warenausgangsprotokolls,
• Übermitteln mindestens einer zweiten Aktualisierungsnachricht von dem zweiten DLT-Knoten an den ersten DLT-Knoten,
• zweites Aktualisieren des ersten Datensatzes durch den ersten DLT-Knoten unter Verwendung der zweiten Aktualisierungsnachricht.
Ausführungsformen umfassen ein Verfahren, welches ferner ein Validieren der Warenlieferung in dem DLT-System umfasst. Der mindestens eine Smart-Contract umfasst Programminstruktionen zu einem Validieren der Warenlieferung. Das Validieren umfasst:
• Prüfen von Parametern einer Validierungsnachricht zum Validieren der Warenlieferung durch den zweiten DLT-Knoten unter Verwendung des mindestens einen Smart- Contracts, wobei die Parameter zumindest eine zu validierende Warenmenge umfassen, wobei das Prüfen der Parameter ein Prüfen der zu validierenden Warenmenge auf Übereinstimmung mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb einer vordefinierten zweiten Toleranz umfasst,
• bei Übereinstimmung der zu validierenden Warenmenge mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb der vordefinierten zweiten Toleranz, viertes Aktualisieren des zweiten Datensatzes durch den zweiten DLT- Knoten, wobei das vierte Aktualisieren ein Registrieren der Validierungsnachricht durch den zweiten DLT-Knoten in dem zweiten Datensatz unter Verwendung des mindestens einen Smart-Contracts umfasst,
• Übermitteln mindestens einer dritten Aktualisierungsnachricht von dem zweiten DLT- Knoten an den ersten DLT-Knoten,
• drittes Aktualisieren des ersten Datensatzes durch den ersten DLT-Knoten unter Verwendung der dritten Aktualisierungsnachricht, wobei das dritte Aktualisieren des ersten Datensatzes ein Registrieren der Validierungsnachricht in dem ersten Datensatz umfasst.
Im Zuge des Initialisierens der Warenlieferung wird auf zwei DLT-Knoten eines zugangsbeschränkten DLT-Systems ein geteilter Datensatz erzeugt. Bei diesem geteilten Datensatz handelt es sich um einen Datensatz, weicher einen ersten Teildatensatz auf dem ersten DLT- Knoten und einen zweiten Teildatensatz auf dem zweiten DLT-Knoten umfasst. Eine Berechtigung zur Bearbeitung des ersten Teildatensatzes, d.h. eine Schreibberechtigung, kann ausschließlich der erste DLT-Knoten (oder ein weiterer hierzu autorisierter DLT-Knoten) und damit der Warenempfänger besitzen, während für den zweiten Datensatz ausschließlich der zweite DLT-Knoten oder ein weiterer hierzu autorisierter DLT-Knoten) und damit der Warensender eine Berechtigung zur Bearbeitung, d.h. eine Schreibberechtigung, besitzen kann. Ferner kann in Folge der Zugangsbeschränkung des DLT-Systems beispielsweise auch nur der Warenempfänger über den ersten DLT-Knoten (oder den weiteren autorisierten DLT- Knoten) eine Leseberechtigung zum Lesen des ersten Teildatensatzes und nur der Warensender eine Leseberechtigung zum Lesen des zweiten Teildatensatzes über den zweiten DLT-Knoten (oder den weiteren autorisierten DLT-Knoten) besitzen.
Der Begriff Distributed-Ledger-Technologie beschreibt eine Technik, die für ein Protokollieren von Transaktionen bzw. Zustände von Transaktionen verwendet wird. Im Gegensatz zum klassischen Ansatz, bei welchem ein Ledger als Hauptbuch, in der Regel von nur einer Instanz verwaltet wird, werden hier dezentral beliebig viele prinzipiell gleichgestellte Kopien des Ledgers von unterschiedlichen Parteien unterhalten. Parteien mit mindestens einem entsprechenden Knoten im DLT-System können beispielsweise Warensender, Warenempfänger, Warenproduzenten oder Warenlieferanten sein, wobei Parteien auch überlappend bestehen können, wie die des Warenproduzenten und des Warenlieferanten als eine einzige Partei. Weiterhin kann eine Partei mit mindestens einem Knoten eine Sparkasse, eine Bank, ein Bankinstitut, ein Zahlungsdienstleiter und/oder ein Kreditinstitut sein. Als Partei oder Teilnehmer im DLT-System kann auch ein Regulator mit mindestens einem Knoten vorgesehen sein, um spezielle Funktionen auszuführen, wie beispielsweise die Einhaltung von regulatorischen Vorgaben, wie Verhinderung von Geldwäsche oder vorgeschriebene Sanktions- bzw. Embargoprüfungen. Mindestens ein Knoten im DLT-System kann die Funktion des Notars übernehmen, um die Einmaligkeit jeder Transaktion sicher zu stellen und doppelte Verwendung der DLT-basierten Geleinheiten zu verhindern.
Durch geeignete Maßnahmen wird dafür gesorgt, dass neu hinzuzufügende Transaktionen bzw. Zustände von Transaktionen in allen Kopien des Ledgers übernommen werden und dass es zu einer Übereinkunft (Konsens oder Consensus) über den jeweils aktuellen Stand des Ledgers kommt.
Beispielsweise ist der mindestens eine Smart-Contract, welcher beispielsweise auf beiden DLT-Knoten ausgeführt wird, dazu konfiguriert eine Datenkonsistenz zwischen den beiden Teildatensätzen des geteilten Datensatzes sicherzustellen. So können beispielsweise spiegelgleiche, d.h. identische, Daten in beiden Teildatensätzen des geteilten Datensatzes mittels einer synchronen Datenpflege implementiert werden.
Das vorliegende Verfahren verwendet keine Blockchain, sondern beruht beispielsweise auf einem direkten Datenaustausch zwischen den DLT-Knoten der beteiligten Parteien sowie auf einer direkten Datenvalidierung durch die entsprechenden DLT-Knoten. Die Verwendung eines zugangsbeschränkten DLT-Systems hat den Vorteil gegenüber einer öffentlichen Blockchain, dass der Zugang zu den von dem DLT-System verwalteten Daten beschränkt ist. Beispielsweise haben die Teilnehmer des DLT-Systems jeweils nur Zugriff auf einen DLT- Knoten, welcher ihnen zugeordnet ist. Eine Übermittlung von Daten der geteilten Datensätze innerhalb des DLT-Systems erfolgt beispielsweise nur zwischen den DLT-Knoten, zwischen denen der geteilte Datensatz geteilt ist. Beispielsweise erfolgt die Übertragung nur zwischen dem ersten DLT-Knoten des Warenempfängers und dem zweiten DLT-Knoten des Warensenders. Zur Übertragung wird beispielsweise Unicast verwendet, d.h. die übermittelten Daten werden jeweils an einen einzigen Empfänger adressiert, d.h. einen einzigen DLT-Knoten. Im Gegensatz zu einer Übermittlung mittels Broadcast, wie etwa im Falle zahlreicher Block- chain-Lösungen, hat eine Übermittlung mittels Unicast den Vorteil, dass nur Sender und Empfänger Kenntnis von den übermittelten Daten erlangen. Da in einer Blockchain Transaktionen üblicherweise von allen validierenden Knoten einsehbar sind, etwa bei einer Übermittlung einzutragender Transaktionen innerhalb des Block- chain-Netzwerks mittels Broadcast, fehlt es diesem an Vertraulichkeit. Eine Blockchain speichert Daten üblicherweise als Transaktionen in einzelnen Blöcken, welche miteinander verkettet sind, und in einem verteilten Peer-to-Peer-Netz redundant verwaltet werden. In Folge der redundanten Verwaltung hat eine Vielzahl von Knoten Zugriff auf sämtliche in der Blockchain gespeicherten Daten. Demgegenüber haben Ausführungsformen der vorliegenden Erfindung den Vorteil, dass sowohl Datensicherheit als auch Vertraulichkeit der in dem geteilten Datensatz gespeicherten Daten sichergestellt werden kann. Dies wird dadurch erreicht, dass die Kommunikation zu den abzubildenden Transaktionen, d.h. den in einem geteilten Datensatz zu speichernden Daten, innerhalb des DLT-Systems nur zwischen den betroffenen DLT- Knoten stattfindet, d.h. denjenigen DLT-Knoten, zwischen denen der entsprechende Datensatz geteilt wird. Dies sind beispielsweise nur der erste DLT-Knoten des Warenempfängers und der zweite DLT-Knoten des Warensenders. Dabei erfolgt die Kontrolle der Warenlieferung mittels des einen oder der mehreren Smart-Contracts, welche auf den beteiligten Knoten ausgeführt werden. Eine Speicherung in einer Blockchain oder einem sonstigen für alle DLT- Knoten einsehbaren Datensatz findet nicht statt.
Hierzu wird ein von den beteiligten DLT-Knoten geteilter Datensatz verwendet, der einen ersten (Teil-)Datensatz, der vom DLT-Knoten des Warenempfängers verwaltet wird, und einen zweiten (Teil-)Datensatz aufweist, der vom DLT-Knoten des Warensenders verwaltet wird. Die beiden (Teil-)Datensätze sollen einander entsprechen und spiegeln die Sicht des jeweils zuständigen Knotens wider. Nur der zuständige DLT-Knoten ist berechtigt, den entsprechenden Teil des Datensatzes zu ändern. Die Teildatensätze und damit die in den entsprechenden Teildatensätzen gespeicherten Transaktionen werden jeweils an den anderen DLT-Knoten übermittelt. Beispielsweise werden jeweils nur Änderungen des entsprechenden Teildatensatzes an den anderen DLT-Knoten übermittelt. Beispielsweise sind die an den anderen DLT- Knoten übermittelten Daten signiert. Anhand der Signatur kann der andere DLT-Knoten überprüfen, ob die Änderungen korrekt sind bzw. von dem signierenden DLT-Knoten und damit von den zugeordneten Teilnehmern autorisiert sind.
Ferner ist es nicht erforderlich, dass der erste und der zweite Teildatensatz identisch sind.
Beispielsweise kann ein Teildatensatz gegenüber dem anderen Teildatensatz einen oder mehrere abweichende Datenwerte, beispielsweise hinsichtlich der Warenlieferung, beispielsweise hinsichtlich der zu liefernden Menge der entsprechenden Ware oder weitere, umfassen. Hierdurch können beispielsweise Toleranzen vordefiniert sein, innerhalb derer Abweichungen akzeptabel sind. Alternativ oder zusätzlich, kann ein semiautomatischer oder vollautomatischer Handshake zwischen den beiden die beiden Teildatensätze verwaltenden DLT-Knoten erfolgen, bis Einigung über einzelne voneinander abweichende Datenwerte des Datensatzes, beispielsweise die zu liefernde Ware und ihre Eigenschaften herbeigeführt ist, d.h. die Abweichungen behoben wurden.
Ausführungsformen können somit den Vorteil haben, dass basierend auf den auf zwei DLT- Knoten verteilte Datensatz und/oder den vorangehend beschriebenen weiteren Merkmalen zum Abgleich der (Teil-)Datensätze ein Ansatz zur vertraulichen Abwicklung von Transaktionen zwischen den beiden DLT-Knoten bereitgestellt wird. Ferner wird eine Absicherung der Transaktionen und Erhöhung der Datensicherheit zwischen den DLT-Knoten ermöglicht.
Eine Kommunikation zwischen den DLT-Knoten erfolgt beispielsweise über mittels des Transport-Layer-Security-Protokolls (TLS) abgesicherte Transportverbindungen. Ferner erfolgt eine Kommunikation mit den DLT-Knoten, etwa bei einem Zugriff des Warenempfängers mit einem dem Warenempfänger zugeordneten Computersystem auf den ersten DLT-Knoten und/oder bei einem Zugriff des Warensenders mit einem dem Warensender zugeordneten Computersystem auf den zweiten DLT-Knoten über mittels TLS abgesicherte Transportverbindungen.
Beispielsweise sind alle Transportverbindungen mit TLS abgesichert. Das Sicherheitsprinzip innerhalb des DLT-Systems beruht dabei beispielsweise auf einer Peer-to-Peer-Kommunika- tion zwischen den DLT-Knoten und dem Need-to-know-Prinzip. Eine Peer-to-Peer-Kommu- nikation beruht auf Rechner-Rechner-Verbindung zwischen gleichberechtigten Rechnern. Das Need-to-know-Prinzip bzw. Erforderlichkeitsprinzip, fordert als Sicherheitsziel für Daten, dass für einen Zugriff auf die entsprechenden Daten nicht nur eine grundsätzliche Zugriffsberechtigung notwendig ist, sondern die Daten, auf welche zugegriffen werden soll, zudem unmittelbar für die Erfüllung einer konkreten Aufgabe notwendig sind. Auch wenn ein DLT- Knoten beispielsweise Zugriff auf Daten einer bestimmten oder einer bestimmten Sicherheitsebene hat, verbietet das Need-to-know-Prinzip den Zugriff, wenn die entsprechenden nicht unmittelbar für die Erfüllung einer konkreten Aufgabe von diesem DLT-Knoten benötigt werden.
Jeder DLT-Knoten erhält nur diejenigen Daten, die ihn auch betreffen. Daher können Informationen auch durch einen kompromittierten DLT-Knoten nicht abfließen, da dieser nicht in die Verwaltung geteilter Datensätze anderer DLT-Knoten involviert ist und Daten innerhalb des DLT-Systems nicht öffentlich zugänglich sind bzw. nicht veröffentlicht werden.
Ausführungsformen können den Vorteil haben, dass auf eine Verschlüsselung der Daten in den Teildatensätzen des geteilten Datensatzes verzichtet werden kann. Daten können in die Teildatensätze in Klartext eingetragen und gespeichert werden. Durch das Need-to-know- Prinzip wird gewährleistet, dass relevante Daten nur zwischen den beteiligten DLT-Knoten ausgetauscht werden. Dies stellt einen effektiven Schutz sensitiver Informationen gegen unberechtigte Zugriffe bereit. Bereits durch die verwendete Netzwerkarchitektur des DLT- Systems wird somit eine effektive Datensicherheit und Vertraulichkeit gewährleistet. Dabei werden anderen DLT-Knoten erst gar keine Daten geschickt, die sie oder die ihnen jeweils zugeordneten Teilnehmer nicht unmittelbar betreffen (Need-to-know Prinzip). Dies steht im Gegensatz zum Ansatz einer klassischen Blockchain. Um auch sensitive Daten in einer Blockchain sicher speichern zu können, müssen diese Daten verschlüsselt eingetragen und abgespeichert werden. Alternativ werden nur Ergebnisse aus einer Anwendung einer Einwegfunktion, wie etwa einer Hash-Funktion, auf die entsprechenden Daten eingetragen und abgespeichert. Eine Blockchain ist infolge des Broadcasts unter allen Knoten des Systems typischerweise auch für alle Knoten des Systems sichtbar, sodass sensitive Informationen in einer Blockchain durch zusätzliche Maßnahmen geschützt werden müssen. Diese zusätzlichen Maßnahmen, wie etwa eine Verschlüsselung oder eine Anwendung einer Einwegfunktion, ermöglichen lediglich einen Basisschutz der in der Blockchain gespeicherten Daten und Informationen.
Falls in den Teildatensätzen des geteilten Datensatzes Daten verschlüsselt werden, führt dies dazu, dass das Niveau an Sicherheit für die entsprechenden Daten ausgehend von einem bereits existierenden Basisschutz, welcher durch die Netzwerkarchitektur bereits bereitgestelltwird, zusätzlich erhöht wird und nicht etwa nur zur Implementierung eines Basisschutzes dient, wie im Fall einer klassischen Blockchain. Beispielsweise werden die Daten in den Teildatensätzen des geteilten Datensatzes verschlüsselt eingetragen und/oder die Teildatensätze werden verschlüsselt gespeichert.
Nach Ausführungsformen erfolgt kein Broadcasting innerhalb des DLT-Systems, wie es etwa bei einer Verwendung einer Blockchain der Fall wäre. Beispielsweise beruht eine Kommunikation zwischen den DLT-Knoten vielmehr auf einem Unicast oder einer direkten Kommunikation zwischen den beteiligten DLT-Knoten, bspw. über eine dedizierte Kommunikationsverbindung.
Ausführungsformen ermöglichen es beispielsweise spiegelgleiche Daten bezüglich des Warentransfers auf beiden Seiten, d.h. bei dem Warenempfänger und dem Warensender, in Form des ersten und des zweiten Datensatzes sicherzustellen. Diese spiegelgleichen Daten lassen sich zudem beispielsweise auf beiden Seiten in angebundene Enterprise-Resource- Planning(ERP)-Systeme integrieren.
Die somit bereitgestellten spiegelgleichen Daten und synchrone Datenpflege ist vorteilhaft für die digitale Integration etwa von Bestell-, Liefer- und Finanzprozessen zwischen den Geschäftspartnern, beispielsweise dem Warenempfänger und dem Warensender. Beispielsweise kann so eine konstante Datenqualität sichergestellt werden und wechselseitig messbar sein, etwa unter Verwendung von Leistungsindikatoren, wie Key Performance Indicators (KPIs). Die Implementierung einer In-Prozess Validierung sorgt für eine Nachhaltigkeit bereits erreichter Datenqualität und verhindert so eine schleichende Verschlechterung. Indem mittels des DLT-Systems ein gemeinsamer Ort des Datenbestands in Form geteilter Datensätze zur Kontrolle von Warenlieferungen bereitgestellt wird, fällt beispielsweise ein Reconciliation-Auf- wand geringer aus. So kann der Aufwand für eine spätere Kontenabstimmung beispielsweise deutlich verringert werden oder entfällt im Ideal sogar dauerhaft vollumfänglich auf Seiten beider Geschäftspartner. Somit kann dazu beigetragen werden, die Datenqualität und Prozesseffizienz zu heben. So kann beispielsweise der Umfang manueller Tätigkeiten reduziert werden.
Zunächst werden beispielsweise infolge eines Empfangs eines Lieferauftrags, welcher eine erste Spezifikation der zu liefernden Ware umfasst, in den ersten durch den ersten DLT- Knoten verwalteten Datensatz, d.h. den ersten Teildatensatz des geteilten Datensatzes, eine oder mehrere physikalische Eigenschaften der zu liefernden Ware gemäß der ersten Spezifikation eingetragen. Diese eingetragene eine oder mehreren physikalischen Eigenschaften gemäß der ersten Spezifikation umfassen zumindest eine zu liefernde Warenmenge.
Dieser erste Datensatz bzw. die in dem ersten Datensatz eingetragene eine oder mehreren physikalischen Eigenschaften gemäß der ersten Spezifikation werden an den zweiten DLT- Knoten des Warensenders übermittelt. Der zweite DLT-Knoten erstellt den zweiten Teildatensatz des geteilten Datensatzes, in welchen eine oder mehrere physikalische Eigenschaften gemäß der ersten Spezifikation eingetragen werden. Dabei umfasst die eingetragene eine oder mehreren physikalischen Eigenschaften gemäß der ersten Spezifikation zumindest eine zu liefernde Warenmenge. Im Ergebnis umfassen beide Teildatensätze des geteilten Datensatzes somit beispielsweise identische Daten.
Auf einen Empfang einer Auftragsbestätigung, welche eine zweite Spezifikation der einen oder mehreren physikalischen Eigenschaften der zu liefernden Ware umfasst, erfolgt ein Prüfen der zweiten Spezifikation auf Übereinstimmung mit der ersten Spezifikation durch den zweiten DLT-Knoten unter Verwendung des mindestens einen Smart-Contracts sowie ein Aktualisieren des zweiten Datensatzes unter Verwendung des Ergebnisses des Prüfens der zweiten Spezifikation.
Bei einer Übereinstimmung der zweiten Spezifikation mit der ersten Spezifikation umfasst das Aktualisieren des zweiten Datensatzes unter Verwendung des Prüfergebnisses beispielsweise ein Einträgen einer Bestätigung der ersten Spezifikation. Beispielsweise umfasst das Aktualisieren des zweiten Datensatzes unter Verwendung des Prüfergebnisses ein Einträgen der zweiten Spezifikation in Ergänzung zu der ersten Spezifikation in den zweiten Datensatz.
Bei einer Abweichung der zweiten Spezifikation von der ersten Spezifikation umfasst das Aktualisieren des zweiten Datensatzes unter Verwendung des Prüfergebnisses beispielsweise ein Ersetzen bzw. ein Aktualisieren der physikalischen Eigenschaften gemäß der ersten Spezifikation durch die abweichenden physikalischen Eigenschaften gemäß der zweiten Spezifikation. Beispielsweise werden im Zuge des Aktualisierens des zweiten Datensatzes die abweichenden physikalischen Eigenschaften gemäß der zweiten Spezifikation zusätzlich zu der ersten Spezifikation in den zweiten Datensatz eingetragen. Beispielsweise wird die zweite Spezifikation in Ergänzung zu der ersten Spezifikation in den zweiten Datensatz eingetragen.
Ferner wird eine erste Aktualisierungsnachricht von dem zweiten DLT-Knoten an den ersten DLT-Knoten übermittelt. Beispielsweise gibt die erste Aktualisierungsnachricht an, ob die zweite Spezifikation mit der ersten Spezifikation übereinstimmt. Falls eine oder mehrere physikalische Eigenschaften gemäß der zweiten Spezifikation von der ersten Spezifikation abweichen, identifiziert die erste Aktualisierungsnachricht beispielsweise die abweichende eine oder mehreren physikalischen Eigenschaften gemäß der zweiten Spezifikation. Beispielsweise umfasst die erste Aktualisierungsnachricht die gesamte zweite Spezifikation bzw. eine Kopie der zweiten Spezifikation.
Zu einer solchen Abweichung einer oder mehrerer physikalischer Eigenschaften gemäß der zweiten Spezifikation von der ersten Spezifikation kann es beispielsweise kommen, weil nur eine bestimmte Mindestwarenmenge lieferbar ist oder die Ware nur in bestimmten Mengeneinheiten, z.B. im Umfang eines Kesselwagens oder eines Tanklastzugs, geliefert wird. Zu einer solchen Abweichung einer oder mehrerer physikalischer Eigenschaften gemäß der zweiten Spezifikation von der ersten Spezifikation kann es beispielsweise kommen, weil die lieferbaren Produkteigenschaften von den bestellten Produkteigenschaften abweichen.
Der erste DLT-Knoten aktualisiert den ersten Datensatz, d.h. den ersten Teildatensatz des geteilten Datensatzes, unter Verwendung der ersten Aktualisierungsnachricht. Bei einer Übereinstimmung der zweiten Spezifikation mit der ersten Spezifikation umfasst das Aktualisieren des ersten Datensatzes unter Verwendung der ersten Aktualisierungsnachricht beispielsweise ein Einträgen einer Bestätigung der ersten Spezifikation. Beispielsweise umfasst das Aktualisieren des ersten Datensatzes unter Verwendung der ersten Aktualisierungsnachricht ein Einträgen der zweiten Spezifikation in Ergänzung zu der ersten Spezifikation in den ersten Datensatz.
Bei einer Abweichung der zweiten Spezifikation von der ersten Spezifikation umfasst das Aktualisieren des ersten Datensatzes unter Verwendung der ersten Aktualisierungsnachricht beispielsweise ein Ersetzen bzw. ein Aktualisieren der physikalischen Eigenschaften gemäß der ersten Spezifikation durch die abweichenden physikalischen Eigenschaften gemäß der zweiten Spezifikation. Beispielsweise werden im Zuge des Aktualisierens des ersten Datensatzes die abweichenden physikalischen Eigenschaften gemäß der zweiten Spezifikation zusätzlich zu der ersten Spezifikation in den zweiten Datensatz eingetragen. Beispielsweise wird die zweite Spezifikation in Ergänzung zu der ersten Spezifikation in den zweiten Datensatz eingetragen.
Weicht die zweite Spezifikation von der ersten Spezifikation ab, wird beispielsweise ein „Handshake“ zwischen dem ersten DLT-Knoten und dem zweiten DLT-Knoten zum Abgleich der ersten Spezifikation mit der zweiten Spezifikation durchgeführt, sodass die aus dem Abgleich resultierenden ersten und zweiten Spezifikationen übereinstimmen.
Ein Handshake, zu Deutsch auch Handschlag, bezeichnet einen automatisierten Verhandlungsprozess zwischen zwei Teilnehmern, in diesem Fall den beiden DLT-Knoten, durch einen Austausch von Daten, in diesem Fall von Angaben zu physikalischen Eigenschaften der zu liefernden Ware. Im vorliegenden Fall, kann der Handshake dazu verwendet werden, die Bedingungen einer Warenlieferung festzulegen, bevor die physische Lieferung der Ware beginnt. Unter Verwendung des mindestens einen Smart-Contracts wird beispielsweise ein Handshake-Protokoll zwischen den beiden DLT-Knoten ausgeführt, dessen Resultat eine Anpassung einer oder beider Spezifikationen ist, bis eine identische Übereinstimmung, d.h. Identität, zwischen diesen beiden Spezifikationen vorliegt.
Stimmt die zweite Spezifikation mit der ersten Spezifikation überein, wird beispielsweise eine Bestätigungsnachricht von dem zweiten DLT-Knoten an den Warensender über das Netzwerk übermittelt. Eine Übereinstimmung der zweiten Spezifikation mit der ersten Spezifikation liegt beispielsweise bei einer Identität der beiden Spezifikationen, d.h. identischen Übereinstimmung, vor. Eine Übereinstimmung der zweiten Spezifikation mit der ersten Spezifikation liegt beispielsweise vor, wenn keine Abweichungen auftreten, welche einen vordefinierten Toleranzbereich überschreiten. Die Bestätigungsnachricht zeigt dem Warensender beispielsweise an, dass eine Einigung über die entsprechende Warenlieferung zwischen Warenempfänger und Warensender erzielt wurde. Ferner umfasst die Bestätigungsnachricht beispielsweise die Spezifikation der entsprechenden Warenlieferung. Beispielsweise dient die entsprechende Bestätigungsnachricht als Trigger zum Initiieren der entsprechenden Warenlieferung. Ferner erfolgt ein Protokollieren der Warenlieferung in dem DLT-System. Wird die physische Warenlieferung ausgeführt, d.h. verlässt die zu liefernde Ware ein Lager des Warensenders, wird ein Warenausgangsprotokoll erstellt. Das entsprechende Warenausgangsprotokoll umfasst einen oder mehrere Sensorwerte für die eine oder mehreren physikalischen Eigenschaften der ausgehenden Ware gemäß der zweiten Spezifikation, welche mittels eines oder mehrerer dem Warensender zugeordneter physikalischer Sensoren erfasst sind. Das Warenausgangsprotokoll gibt also für eine oder mehrere physikalische Eigenschaften, für welche in der zweiten Spezifikation Zielwerte angegeben werden, jeweils sensorisch erfasste Messwerte an, welche den tatsächlichen Zustand der ausgehenden Ware im Hinblick auf die entsprechenden physikalischen Eigenschaften wiedergeben. Die entsprechenden Sensorwerte umfassen dabei zumindest einen Sensorwert, welcher die gelieferte, d.h. ausgehende, Warenmenge quantifiziert.
Der zweite DLT-Knoten des Warensenders empfängt das Warenausgangsprotokoll von dem Warensender über das erste Netzwerk und prüft den einen oder die mehreren ersten Sensorwerte des Warenausgangsprotokolls auf Übereinstimmung mit der einen oder den mehreren physikalischen Eigenschaften der zu liefernden Ware. Hierbei wird geprüft, ob der eine oder die mehreren Sensorwerte des Warenausgangsprotokolls mit einer oder mehrerer physikalischer Eigenschaften gemäß dem geteilten Datensatz innerhalb vordefinierter Toleranzen übereinstimmen. Liegt keine solche Übereinstimmung vor, wird beispielsweise ein Warnhinweis an den Warensender und/oder den Warenempfänger übermittelt. Ein solcher Warnhinweis kann beispielsweise bei einer zu geringen Liefermenge eine Nachlieferung seitens des Warensenders triggern. Ein solcher Warnhinweis kann beispielsweise, dass der Auslieferungsprozess gestoppt wird, wenn beispielsweise eine Produkteigenschaft nicht spezifikationsgemäß ist. In diesem Fall muss beispielsweise entweder der Warenempfänger der abweichenden Spezifikation zustimmen und die Lieferung erfolgt oder die Bestellung wird storniert. Als Alternative zu einer Stornierung kann beispielsweise der Liefertermin geändert werden auf einen Termin, zu welchem spezifikationsgemäße Ware verfügbar ist.
Seitens des Warenempfängers kann das Vorliegen eines solchen Warnhinweises beispielsweise eine Überprüfung der abweichenden physikalischen Eigenschaften bei Ankunft der Ware triggern. Beispielsweise kann ein solcher Warnhinweis eine Bestätigung der abweichenden physikalischen Eigenschaften seitens des Warenempfängers für eine erfolgreiche abschließende Validierung der Warenlieferung erforderlich machen. Der zweite Datensatzes wird durch den zweiten DLT-Knoten unter Verwendung des Ergebnisses der Prüfung des einen oder der mehreren ersten Sensorwerte des Warenausgangsprotokolls aktualisiert. Beispielsweise umfasst die Aktualisierung ein Einträgen des Warenausgangsprotokolls und/oder eines oder mehrerer der von dem Warenausgangsprotokoll angegebenen Sensorwerte. Beispielsweise werden alle von dem Warenausgangsprotokoll angegebenen Sensorwerte eingetragen. Beispielsweise werden nur solche Sensorwerte eingetragen, welche von den in dem zweiten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware abweichen. Beispielsweise wird für Sensorwerte des Warenausgangsprotokolls, welche mit den in dem zweiten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware übereinstimmen, nur eine Bestätigung in den zweiten Datensatz eingetragen, dass die entsprechenden Werte für die physikalischen Eigenschaften mit den erfassten Sensorwerten übereinstimmen.
Ferner wird eine zweite Aktualisierungsnachricht von dem zweiten DLT-Knoten an den ersten DLT-Knoten übermittelt. Die zweite Aktualisierungsnachricht umfasst beispielsweise das Warenausgangsprotokoll und/oder einen oder mehrere der von dem Warenausgangsprotokoll angegebenen Sensorwerte. Beispielsweise umfasst die zweite Aktualisierungsnachricht alle von dem Warenausgangsprotokoll angegebenen Sensorwerte. Beispielsweise umfasst die zweite Aktualisierungsnachricht nur solche Sensorwerte, welche von den in dem zweiten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware abweichen. Beispielsweise umfasst die zweite Aktualisierungsnachricht für Sensorwerte des Warenausgangsprotokolls, welche mit den in dem zweiten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware übereinstimmen, nur eine Bestätigung, dass die entsprechenden Werte für die physikalischen Eigenschaften gemäß dem geteilten Datensatz mit den erfassten Sensorwerten übereinstimmen.
Der erste DLT-Knoten aktualisiert den ersten Datensatz, d.h. den ersten Teildatensatz des geteilten Datensatzes, unter Verwendung der zweiten Aktualisierungsnachricht. Beispielsweise umfasst die Aktualisierung ein Einträgen des Warenausgangsprotokolls und/oder eines oder mehrerer der von dem Warenausgangsprotokoll angegebenen Sensorwerte. Beispielsweise werden alle von dem Warenausgangsprotokoll angegebenen Sensorwerte eingetragen. Beispielsweise werden nur solche Sensorwerte eingetragen, welche von den in dem ersten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware abweichen. Beispielsweise wird für Sensorwerte des Warenausgangsprotokolls, welche mit den in dem ersten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware übereinstimmen, nur eine Bestätigung in den ersten Datensatz eingetragen, dass die entsprechenden Werte für die physikalischen Eigenschaften mit den erfassten Sensorwerten übereinstimmen.
Schließlich wird eine Validierung der Warenlieferung in dem DLT-System ausgeführt. Hierzu werden Parameter einer Validierungsnachricht zum Validieren der Warenlieferung durch den zweiten DLT-Knoten geprüft. Die geprüften Parameter der Validierungsnachricht umfassen zumindest eine zu validierende Angabe der gelieferten Warenmenge. Das Prüfen der entsprechenden Parameter umfasst ein Prüfen der zu validierenden Warenmenge auf Übereinstimmung mit dem die gelieferte Warenmenge quantifizierenden Sensorwert gemäß dem Warenausgangsprotokoll innerhalb einer vordefinierten Toleranz. Bei Übereinstimmung der zu validierenden Warenmenge mit dem die gelieferte Warenmenge quantifizierenden Sensorwert innerhalb der vordefinierten Toleranz, erfolgt ein Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten unter Verwendung der Validierungsnachricht. Das Aktualisieren umfasst ein Registrieren der Validierungsnachricht durch den zweiten DLT-Knoten in dem zweiten Datensatz. Beispielsweise wird in Zuge der Registrierung ein Identifikator der Validierungsnachricht in den zweiten Datensatz eingetragen. Beispielsweise wird eine Prüfwert, etwa ein Hash-Wert, der Validierungsnachricht in den zweiten Datensatz eingetragen. Beispielsweise werden ein oder mehrere Parameter der Validierungsnachricht in den zweiten Datensatz eingetragen. Beispielsweise wird die Validierungsnachricht in den zweiten Datensatz eingetragen.
Ein Hash-Wert ist das Ergebnis, einer Anwendung einer Hash-Funktion, auch Streuwertfunktion genannt, auf eine Eingabe, auch Schlüssel genannt. Eine Hash-Funktion ist eine Abbildung, die eine große Eingabemenge, die Schlüssel, auf eine kleinere Zielmenge, die Hash- Werte, abbildet. Eine Hashfunktion ist daher im Allgemeinen nicht injektiv. Die Eingabemenge kann beispielsweise Elemente unterschiedlicher Längen enthalten, die Elemente der Zielmenge haben dagegen im Allgemeinen eine feste Länge.
Beispielsweise wird das Validieren durch einen Empfang der Validierungsnachricht oder durch ein Erzeugen der Validierungsnachricht getriggert. Beispielsweise wird ein Erzeugen der Validierungsnachricht durch einen Empfang einer Empfangsbestätigung der gelieferten Ware von dem Warenempfänger getriggert. Beispielsweise wird eine Empfangsbestätigung in Form eines Wareneingangsprotokolls empfangen.
Ferner wird von dem zweiten DLT-Knoten eine dritte Aktualisierungsnachricht an den ersten DLT-Knoten übermittelt. Die dritte Aktualisierungsnachricht umfasst beispielsweise die im Zuge der Aktualisierung in den zweiten Datensatz eingetragenen Daten der Validierungsnachricht. Die dritte Aktualisierungsnachricht umfasst beispielsweise den vollständigen aktualisierten zweiten Datensatz. Die dritte Aktualisierungsnachricht umfasst beispielsweise die Validierungsnachricht.
Der erste DLT-Knoten aktualisiert den ersten Datensatz unter Verwendung der dritten Aktualisierungsnachricht. Das Aktualisieren des ersten Datensatzes umfasst dabei ein Registrieren der Validierungsnachricht in dem ersten Datensatz. Beispielsweise wird in Zuge der Registrierung ein Identifikator der Validierungsnachricht in den ersten Datensatz eingetragen. Beispielsweise wird eine Prüfwert, etwa ein Hash-Wert, der Validierungsnachricht in den ersten Datensatz eingetragen. Beispielsweise werden ein oder mehrere Parameter der Validierungsnachricht in den ersten Datensatz eingetragen. Beispielsweise wird die Validierungsnachricht in den ersten Datensatz eingetragen.
Die Verarbeitung in Bezug auf die einzelnen Teilnehmer, d.h. den Warensender und den Warenempfänger erfolgt auf DLT-Knoten des DLT-Systems, welche den entsprechenden Teilnehmern jeweils zugeordnet sind. Das DLT-System umfasst beispielsweise eine Mehrzahl von DLT-Servern. Dabei können zwei oder mehr DLT-Knoten von zwei oder mehr Teilnehmern beispielsweise auf ein und demselben DLT-Server des DLT-Systems angeordnet sein. Beispielsweise sind die DLT-Knoten unterschiedlicher Teilnehmer auf unterschiedlichen DLT-Servern des DLT-Systems angeordnet.
Zum Ausführen des Verfahrens zur computerimplementierten Kontrolle der Warenlieferung wird beispielsweise ein einziger Smart-Contracts verwendet. Beispielsweise kommt eine Mehrzahl von Smart-Contracts zum Einsatz. Beispielsweise sind die einzelnen Smart- Contracts der Mehrzahl von Smart-Contracts jeweils dazu konfiguriert, bestimmte Teilverfahren auszuführen, beispielweise das Initialisieren, das Protokollieren und/oder das Validieren. Ein Smart-Contract definiert eine Reihe von Bedingungen, die in einem DLT-System aufgezeichnet sind und automatisierte, selbstausführende Aktionen auslösen, wenn zumindest einige dieser vordefinierten Bedingungen erfüllt sind. Ein Smart-Contract umfasst Programminstruktionen, welche vereinbarte Regeln bzw. entsprechende Bedingungen abbildet. Ein solcher Smart-Contract, welcher Regeln für eine Mehrzahl von Teilnehmern definiert, ist nicht einseitig veränderbar. Vielmehr ist für eine Änderung beispielsweise ein Konsens der Mehrzahl von Teilnehmern notwendig. Ein solcher Konsens kann beispielsweise eine zu Zustimmung einer Mehrheit der Mehrzahl von Teilnehmern und/oder aller Teilnehmer der Mehrzahl von Teilnehmern voraussetzen. Beispielsweise werden Änderungen des Smart-Contracts protokolliert. Beispielsweise wird so eine vollständige Historie der Änderungen des Smart- Contracts bereitgestellt.
Bei dem Netzwerk über welches auf die DLT-Knoten zugegriffen wird, handelt es sich beispielsweise um ein TCP/IP- Netzwerk. Die DLT-Knoten können beispielsweise auf einem oder mehreren Servern gehostet werden. Das DLT-System kann gesicherte Verbindungen zwischen den DLT-Servern und den darin gehosteten DLT-Knoten herstellen. Beispielsweise können die DLT-Knoten aber auch bei den Teilnehmern lokal auf den Teilnehmern zugeordneten Computersystemen implementiert sein.
Der eine oder die mehreren ersten physikalischen Sensoren des Warensenders umfassen eine oder mehrere physikalische Messvorrichtungen zum Erfassen von Messdaten bzw. Sensorwerten. Messdaten sind Daten, welche physikalische und/oder chemische Eigenschaften eines Messobjekts quantitativ oder qualitativ beschreiben. Entsprechende Eigenschaften umfassen beispielsweise Gewicht, Volumen, Temperatur, Feuchtigkeit, Druck, Korngröße, Schallfeldgrößen, Helligkeit, pH-Wert, lonenstärke, elektrochemisches Potential, Leitfähigkeit, Viskosität, und/oder Transluzenz. Messdaten werden mittels physikalischer oder chemischer Effekte erfasst und in ein elektronisch weiterverarbeitbares elektrisches Signal umgeformt. Beispielsweise wird das entsprechende elektrisches Signal, welches die erfassten Messdaten umfasst, kryptographisch verschlüsselt. Hierzu kann beispielsweise eine symmetrische, eine asymmetrische oder eine hybride kryptographische Verschlüsslung zur Anwendung kommen. Somit können die entsprechenden Messdaten beispielsweise vor unerlaubten Zugriffen geschützt werden. Ferner oder alternativ kann das entsprechende elektrisches Signal, welches die erfassten Messdaten umfasst, digital signiert werden. Somit kann beispielsweise eine Authentizität der entsprechenden Messdaten nachgewiesen werden. Ausführungsformen können den Vorteil haben, dass ein bidirektionaler Forderungsausgleich implementiert werden kann. Dieser umfasst beispielsweise einen 2-Way-Match (2-Wege-Ab- gleich) und/oder einen 3-Way- Match (3-Wege-Abgleich). Ferner wird beispielsweise eine vollautomatische Verrechnung ermöglicht.
Mit dem 2-Way-Matches lässt sich unter Verwendung des mindestens einen Smart-Contracts eine übereinstimmende Willenserklärung hinsichtlich Lieferkondition für die Warenlieferung, wie etwa physikalische Eigenschaften der gelieferten Ware und/oder einen Preis der zu liefernden Ware, implementieren und mittels des DLT-Systems dokumentieren.
Die „2“ im Namen 2-Way-Match bedeutet, dass Lieferauftrag und Auftragsbestätigung validiert werden. Im Zuge eines 2-Way-Matches werden Lieferkondition für die Warenlieferung, wie etwa physikalische Eigenschaften der gelieferten Ware und/oder ein Preis der zu liefernden Ware, gemäß Lieferauftrag und Auftragsbestätigung abgeglichen. So kann sichergestellt werden, dass diese übereinstimmen, d.h. identisch sind oder auftretende Abweichungen einen vordefinierten Toleranzbereich nicht überschreiten. Dieser 2-Way-Match wird beispielsweise in Form der Prüfung von Angaben gemäß der Auftragsbestätigung im Zuge der Eintragung derselben in den zweiten Datensatz durch den zweiten DLT-Knoten implementiert. Beispielsweise umfasst der Lieferauftrag eine erste Preisangabe eines Preises für die zu liefernde Ware. Eine Preisangabe ist eine Angabe, aus welcher sich ein für die zu liefernde Ware zu bezahlender Preisgibt. Beispielsweise ist die Preisangabe identisch mit dem zu zahlenden Preis. Beispielsweise ist der zu zahlende Preis aus der Preisangabe ableitbar bzw. berechenbar. Bezieht sich die Preisangabe auf die gesamte zu liefernde Warenmenge, so stimmt die Preisangabe mit dem Preis der zu liefernden Ware überein. Beispielsweise handelt es bei der ersten Preisangabe um eine Preisangabe pro gelieferte Warenmenge. Bei einer Preisangabe pro gelieferte Warenmenge hängt der tatsächlich zu zahlende Preis von der tatsächlich gelieferten Warenmenge ab. Eine Preisangabe pro gelieferter Warenmenge, etwa pro Stück, pro Gewicht, oder pro Volumen, ist mit der gelieferten Warenmenge zu multiplizieren, um den zu zahlenden Preis für die gelieferte Ware zu bestimmen. Beispielsweise wird diese erste Preisangabe gemäß Lieferauftrag durch den ersten DLT-Knoten in den ersten Datensatz eingetragen und zur Eintragung in den zweiten Datensatz an den zweiten DLT- Knoten übermittelt. Beispielsweise umfasst die Auftragsbestätigung eine zweite Preisangabe eines Preises für die zu liefernde Ware, insbesondere eine zweite Preisangabe pro gelieferter Warenmenge. Beispielsweise wird diese zweite Preisangabe gemäß Auftragsbestätigung durch den zweiten DLT-Knoten auf eine Übereinstimmung mit der ersten Preisangabe geprüft und im Zuge der Aktualisierung des zweiten Datensatzes unter Verwendung der Auftragsbestätigung in den zweiten Datensatz eingetragen. Durch diese Prüfung kann beispielsweise der 2-Way-Match implementiert werden bzw. der 2-Way- Match umfasst beispielsweise diese Prüfung. Im Zuge eines 2-Way-Matches kann so ein Preis für die zu liefernde Ware gemäß Lieferauftrag und Auftragsbestätigung abgeglichen werden. Ferner umfasst die an den ersten DLT-Knoten gesendete Aktualisierungsnachricht über die Aktualisierung des zweiten Datensatzes unter Verwendung der Auftragsbestätigung die zweite Preisangabe. Beispielsweise wird die so übermittelte zweite Preisangabe von dem zweiten DLT-Knoten in den zweiten eingetragen.
Unterscheiden sich die erste Preisangabe von der zweiten Preisangabe so, dass sie nicht identisch sind oder der Unterschied einen vordefinierten Toleranzbereich überschreitet, wird beispielsweise ein Handshake zwischen dem ersten DLT-Knoten und dem zweiten DLT- Knoten zum Abgleich der Preisangaben initiiert. Die aus dem Abgleich resultierenden Preisangaben sind beispielsweise identisch oder weisen einen verbleibenden Unterschied auf, welcher den vordefinierten Toleranzbereich nicht überschreitet.
Mit dem 3-Way-Match lassen sich Lieferkonditionen, welche aus dem 2-Way-Match resultieren, zusammen mit den Angaben des Warenausgangsprotokolls bezüglich der tatsächlich gelieferten Ware mit entsprechenden Angaben in der Validierungsnachricht abgleichen und mittels des DLT-Systems dokumentieren. Eine oder mehrere Lieferkonditionen für die Warenlieferung, wie etwa ein Preis der zu liefernden Ware, resultieren aus dem 2-Way-Match und sind beispielsweise nicht Gegenstand des Warenausgangsprotokolls. Eine oder mehrere Lieferkonditionen für die Warenlieferung, wie etwa physikalische Eigenschaften der gelieferten Ware, können von dem Ergebnis des 2-Way-Matches abweichen. Die tatsächlich Werte für diese Lieferkondition, etwa eine tatsächlich gelieferte Warenmenge, werden daher mittels des Warenausgangsprotokolls erfasst. So kann geprüft werden, ob Abweichungen von dem Ergebnis des 2-Way-Matches vorliegen und diese Abweichungen können bei der Validierung der Validierungsnachricht berücksichtigt werden. Die „3“ im Namen 3-Way-Match bedeutet, dass der entsprechenden Validierung neben dem Ergebnis des 2-Way-Matches basierend auf dem Lieferauftrag und der Auftragsbestätigung sowohl das Warenausgangsprotokoll als auch die Validierungsnachricht zugrunde gelegt werden. Eine reale Bestellung umfasst Angaben zu bestimmten physikalischen Eigenschaften der zu liefernden Waren, welche etwa aus Effizienz- und/oder Produktionsgründen bei der tatsächlichen Lieferung abweichen können. Beispielsweise umfasst eine reale Bestellung zudem Angaben zu bestimmten physikalischen Eigenschaften, welche aufgrund natürlich auftretender Variation bei der tatsächlichen Lieferung abweichen können. Daher werden beispielsweise physikalische Eigenschaften der zu liefernden Ware bei der Auslieferung durch den Warensender sensorisch erfasst und im Warenausgangsprotokoll protokolliert. Diese sensorisch erfassten physikalischen Eigenschaften der ausgelieferten Ware gemäß dem Warenausgangsprotokoll werden beispielsweise als physikalische Eigenschaften der tatsächlich gelieferten Ware in dem geteilten Datensatz des DLT-Systems erfasst und der Prüfung der Validierungsnachricht zugrunde gelegt.
Beispielsweise definiert eine reale Bestellung eine bestimmte zu liefernde Menge der bestellten Ware. Aus Effizienzgründen kann es aber vorteilhaft sein, T ransportfahrzeuge zum T rans- port der zu liefernden Ware, beispielsweise im Falle von Schüttgut, voll zu befüllen, so dass die real gelieferte Menge von der bestellten Menge abweichen kann. Beispielsweise wird eine größere Menge als bestellt geliefert. Diese real gelieferte Menge kann beispielsweise mittels Sensorik erfasst und in dem Warenausgangsprotokoll protokolliert werden. Beispielsweise definiert eine reale Bestellung bestimmte physikalische Eigenschaften der bestellten Ware. Produktionsbedingt kann aber beispielsweise nur Ware mit physikalischen Eigenschaften produziert werden, welche von den in der Bestellung definierten Eigenschaften abweichen. In diesem Fall muss beispielsweise entweder der Warenempfänger der abweichenden Spezifikation zustimmen und die Lieferung erfolgt oder die Bestellung wird storniert. Beispielsweise ist eine Produktion der zu liefernden Ware mit den bestimmten physikalischen Eigenschaften vorübergehend nicht möglich, etwa da notwendige Ausgangsprodukte und/oder Ausgangsprodukte mit bestimmten notwendigen physikalischen Eigenschaften vorübergehend für die Produktion nicht zur Verfügung stehen. Ebenso kann es möglich sein, dass bestimmte Produktionsmittel, wie etwa Anlagen oder Anlagenteile, für die Produktion vorübergehend nicht zur Verfügung stehen. In diesem Fall besteht als Alternative zu einer Stornierung beispielsweise die Möglichkeit, den Liefertermin auf einen Termin zu ändern, zu welchem spezifikationsgemäße Ware verfügbar ist bzw. produziert werden kann. Beispielsweise wird im Zuge des 3-Way-Matches eine Preisangabe eines Preises der zu liefernden Ware, insbesondere eine Preisangabe pro Warenmenge, welche aus dem 2-Way- Match resultiert, und eine von dem Warenausgangsprotokoll umfasste Angabe der tatsächlich gelieferten Warenmenge mit entsprechenden in der Validierungsnachricht enthaltenen Angaben für Preis und Warenmenge abgeglichen. Zusätzlich oder alternativ wird aus einer Preisangabe pro Warenmenge, welche aus dem 2-Way-Match resultiert, und der von dem Warenausgangsprotokoll umfassten Angabe der tatsächlich gelieferten Warenmenge ein Gesamtpreis für die gelieferte Ware bestimmt und mit einer entsprechenden in der Validierungsnachricht enthaltenen Angabe für den Gesamtpreis abgeglichen. Beispielsweise wird die Validierungsnachricht unter Verwendung des Smart-Contracts erstellt, wobei im Zuge des 3- Way-Matches sichergestellt werden kann, dass die Angaben der Lieferkonditionen in der Validierungsnachricht mit den basierend auf dem Lieferauftrag und der Auftragsbestätigung vereinbarten Lieferkonditionen sowie den tatsächlichen Lieferkonditionen gemäß dem Warenausgangsprotokoll in Einklang stehen. Ferner kann beispielsweise unter Verwendung des Smart-Contracts eine Zahlung eines aus der Validierungsnachricht resultierenden Rechnungsbetrags ausgelöst werden. Ein entsprechendes Prüfen der Validierungsnachricht unter Verwendung des Smart-Contracts kann somit eine klassische Rechnungsprüfung ersetzen.
Der vorgenannte Ansatz kann insbesondere von Vorteil sein für Lieferung, wie etwa Massenproduktlieferungen, bei welcher Lieferkonditionen eines Lieferauftrags und/oder einer Auftragsbestätigung abweichen können, wie etwa eine tatsächlich gelieferte Endmenge. Die tatsächlichen Lieferkonditionen können in diesem Fall anhand des Warenausgangsprotokolls bestimmt werden. In anderen Fällen werden die Lieferkonditionen als eigentlich unveränderlich festgesetzt. Etwa bei verpackter Ware wird die Menge der zu liefernden Ware durch die Auftragsbestätigung oder das Ergebnis eines Handshakes zwischen Warensender und Warenempfänger bestimmt. Die entsprechenden festgelegten Lieferkonditionen können also beispielsweise aus der Auftragsbestätigung bzw. dem Ergebnis des 2-Way-Matches übernommen werden. In einem solchen Fall dient der 3-Way-Match einer Prüfung der entsprechend übernommenen Lieferkonditionen in der Validierungsnachricht unter Verwendung des Warenausgangsprotokolls. Somit können bei der Validierung beispielsweise Fehler bezüglich der tatsächlichen Lieferkonditionen identifiziert werden und es kann sichergestellt werden, dass diese in der Validierungsnachricht berücksichtigt werden bzw. die Validierungsnachricht auf den tatsächlichen Lieferkonditionen beruht. Entsprechende Abweichungen bzw. Fehler können in diesem Fall ausgehend von der Validierungsnachricht ein Senden eines Warnhinweises und/oder eine Korrektur, etwa durch eine Nachlieferung oder eine Lieferung einer korrekten Ware durch den Warensender, triggern.
Das System funktioniert so, dass die von der Sensorik gelieferten Signale in Form des Warenausgangsprotokolls und/oder eines Wareneingangsprotokolls von den ein der mehreren Smart-Contracts ausgewertet, mit dem Status des Bestell- bzw. Warenliefervorgangs gemäß dem geteilten Datensatz abgeglichen und in dem geteilten Datensatz protokolliert werden. Ferner wird unter Verwendung des einen oder der mehreren Smart-Contracts, semi- oder vollautomatisch, ein Transfer des Bezahlbetrags zwischen den eWallets bzw. elektronischen Brieftaschen veranlasst.
Nach Ausführungsformen umfasst das Verfahren ferner ein Signieren der von dem ersten DLT-Knoten an den zweiten DLT-Knoten übermittelten Daten durch den ersten DLT-Knoten. Der mindestens eine Smart-Contract ist dabei auf dem zweiten DLT-Knoten eingerichtet, die Signaturen der übermittelten Daten zu überprüfen.
Ausführungsformen können den Vorteil haben, dass anhand der entsprechenden Signaturen eine Authentizität von Daten geprüft werden kann, welche der erste DLT-Knoten an den zweiten DLT-Knoten übermittelt. Somit kann sichergestellt werden, dass der zweite Datensatz durch den zweiten DLT-Knoten basierend auf Daten aktualisiert wird, welche von dem ersten DLT-Knoten signiert und damit autorisiert sind. Zum Signieren der Daten verwendet der erste DLT-Knoten beispielsweise einen ersten Signaturschlüssel. Bei diesem ersten Signaturschlüssel handelt es sich beispielsweise um einen ersten privaten kryptographischen Schlüssel eines ersten asymmetrischen kryptographischen Schlüsselpaars. Dieser erste Signaturschlüssel ist beispielsweise in einem geschützten Speicherbereich des ersten DLT-Knotens gespeichert. Beispielsweise umfasst der zweite DLT-Knoten und/oder der auf dem zweiten DLT-Knoten ausgeführte Smart-Contract einen ersten Signaturprüfschlüssel zum Valideren von Signaturen, welche unter Verwendung des ersten Signaturschlüssels erstellt wurden. Bei diesem ersten Signaturprüfschlüssel handelt es sich beispielsweise um einen ersten öffentlichen kryptographischen Schlüssel des ersten asymmetrischen kryptographischen Schlüsselpaars. Eine Datenabsicherung kann so beispielsweise mit kryptographischen Mitteln, wie etwa einem Hashing und/oder Verschlüsseln implementiert bzw. erhöht werden.
Ein asymmetrisches kryptographisches Schlüsselpaar umfasst einen öffentlichen kryptographischen Schlüssel, welcher mit Dritten geteilt bzw. Dritten zur Verfügung gestellt wird, und einen privaten kryptographischen Schlüssel, welche mit Dritten nicht geteilt bzw. Dritten nicht zur Verfügung gestellt wird. Der öffentliche kryptographische Schlüssel versetzt den Dritten dazu in die Lage, Daten zu entschlüsseln, welche von dem Besitzer des asymmetrischen Schlüsselpaars mit dem privaten kryptographischen Schlüssel verschlüsselt wurden. Ferner versetzt der öffentliche kryptographische Schlüssel den Dritten dazu in die Lage, Daten zu verschlüsseln, sodass ausschließlich der Besitzer des asymmetrischen Schlüsselpaars die verschlüsselten Daten mit dem privaten kryptographischen Schlüssel zu entschlüsseln vermag. Der private Schlüssel dient demgegenüber dem Besitzer des asymmetrischen Schlüsselpaars dazu, Daten zu verschlüsseln, sodass sie von Dritten unter Verwendung des öffentlichen kryptographischen Schlüssels entschlüsselt werden können. Ferner dient der private kryptographischen Schlüssel dem Besitzer des asymmetrischen Schlüsselpaar für ihn bestimmte mit dem öffentlichen kryptographischen Schlüssel verschlüsselte Daten zu entschlüsseln. Somit ermöglicht es der private kryptographische Schlüssel dem Besitzer des asymmetrischen Schlüsselpaar beispielsweise Daten zu signieren, während es der öffentliche kryptographische Schlüssel jedem Dritten ermöglicht eine entsprechende Signatur zu verifizieren.
Eine digitale Signatur ist ein asymmetrisches Kryptosystem, bei dem ein Sender mit Hilfe eines geheimen Signaturschlüssels, d.h. einem privaten kryptographischen Schlüssel, zu einer digitalen Nachricht einen Wert berechnet, der ebenfalls digitale Signatur genannt wird. Dieser Wert ermöglicht es jedem, mit Hilfe eines öffentlichen Signaturprüfschlüssels, d.h. eines öffentlichen kryptographischen Schlüssels, eine nicht abstreitbare Urheberschaft des Besitzers des Signaturschlüssels und Integrität der Nachricht zu prüfen.
Die Signatur kann zum Beispiel ein verschlüsselter Hash-Wert der signierten Daten sein, insbesondere ein mit einem privaten kryptographischen Schlüssel verschlüsselter Hash-Wert. Der private kryptographische Schlüssel ist beispielsweise einem öffentlichen kryptographischen Schlüssel zugeordnet, welcher als Signaturprüfschlüssel dient. Der öffentliche kryptographische Schlüssel wird beispielsweise als Bestandteil eines Zertifikats bereitgestellt. Unter einem „Zertifikat“ wird hier ein digitales Zertifikat verstanden, welches auch als Public- Key-Zertifikat bezeichnet wird. Durch solche Zertifikate, basierend auf asymmetrischen Schlüsselpaaren, wird eine so genannte Public Key Infrastructure (PKI) realisiert. Bei einem solchen Zertifikat handelt es sich um strukturierte Daten, die dazu dienen, einen öffentlichen Schlüssel eines asymmetrischen Kryptosystems einer Entität, wie zum Beispiel einer Person, einer Organisation, einem Computersystem oder einem DLT-Knoten, zuzuordnen. Ein Zertifikat kann beispielsweise einen öffentlichen Schlüssel beinhalten und signiert sein. Beispielsweise kann das Zertifikat dem Standard X.509 oder einem anderen Standard entsprechen.
Die PKI stellt ein System zum Ausstellen, Verteilen und Prüfen digitaler Zertifikate bereit. Ein digitales Zertifikat dient in einem asymmetrischen Kryptosystem dazu, die Authentizität eines öffentlichen Schlüssels und seinen zulässigen Anwendungs- und Geltungsbereich zu bestätigen bzw. zu definieren. Das digitale Zertifikat ist selbst durch eine digitale Signatur geschützt, deren Echtheit mit dem öffentlichen Schlüssel des Ausstellers des Zertifikates geprüft werden kann. Um die Authentizität des Ausstellerschlüssels zu prüfen, wird wiederum ein digitales Zertifikat verwendet. Auf diese Weise lässt sich eine Kette von digitalen Zertifikaten aufbauen, die jeweils die Authentizität des öffentlichen Schlüssels bestätigen, mit dem das vorhergehende Zertifikat geprüft werden kann. Eine solche Kette von Zertifikaten bildet einen sogenannten Validierungspfad oder Zertifizierungspfad. Auf die Echtheit des letzten Zertifikats, des sogenannten Wurzelzertifikats, und des durch dieses Zertifikat zertifizierten Schlüssels, müssen sich die Teilnehmer der PKI ohne ein weiteres Zertifikat verlassen können. Das Wurzelzertifikat wird von einer sogenannten Wurzelzertifizierungsinstanz verwaltet, auf deren als gesichert vorausgesetzten Authentizität die Authentizität aller Zertifikate der PKI zurückgeht.
Ein Zertifikat kann einer digitalen Signatur zugeordnet sein, wenn der zu dem öffentlichen kryptographischen Schlüssel gehörende private kryptographische Schlüssel zur Generierung der zu prüfenden digitalen Signatur verwendet wurde. Dadurch, dass ein Zertifikat in Assoziation mit einem öffentlichen Schlüssel der Allgemeinheit zur Verfügung gestellt wird, wird es Nutzern asymmetrischer Kryptosysteme ermöglicht den öffentlichen Schlüssel einer Entität, beispielsweise einer Person, einer Organisation, einem Computersystem oder einem DLT- Knoten, zuzuordnen. Nach Ausführungsformen umfasst das Verfahren ferner ein Signieren der von dem zweiten DLT-Knoten an den ersten DLT-Knoten übermittelten Daten durch den zweiten DLT-Knoten. Der mindestens eine Smart-Contract ist dabei auf dem ersten DLT-Knoten eingerichtet, die Signaturen der übermittelten Daten zu überprüfen.
Ausführungsformen können den Vorteil haben, dass anhand entsprechender Signaturen eine Authentizität von Daten geprüft werden kann, welche der zweite DLT-Knoten an den ersten DLT-Knoten übermittelt. Somit kann sichergestellt werden, dass der erste Datensatz durch den ersten DLT-Knoten basierend auf Daten aktualisiert wird, welche von dem zweiten DLT- Knoten signiert und damit autorisiert sind. Zum Signieren der Daten verwendet der zweite DLT-Knoten beispielsweise einen zweiten Signaturschlüssel. Bei diesem zweiten Signaturschlüssel handelt es sich beispielsweise um einen zweiten privaten kryptographischen Schlüssel eines zweiten asymmetrischen kryptographischen Schlüsselpaars. Dieser zweite Signaturschlüssel ist beispielsweise in einem geschützten Speicherbereich des zweiten DLT- Knotens gespeichert. Beispielsweise umfasst der zweite DLT-Knoten und/oder der auf dem zweiten DLT-Knoten ausgeführte Smart-Contract einen zweiten Signaturprüfschlüssel zum Valideren von Signaturen, welche unter Verwendung des zweiten Signaturschlüssels erstellt wurden. Bei diesem zweiten Signaturprüfschlüssel handelt es sich beispielsweise um einen zweiten öffentlichen kryptographischen Schlüssel des zweiten asymmetrischen kryptographischen Schlüsselpaars.
Nach Ausführungsformen erfolgt die Datenübermittlung zwischen dem ersten DLT-Knoten und dem zweiten DLT-Knoten über eine oder mehrere mittels Ende-zu-Ende-Verschlüsse- lung kryptographisch geschützte Kommunikationsverbindungen.
Ausführungsformen können den Vorteil haben, dass sichergestellt werden kann, dass zwischen den DLT-Knoten innerhalb des DLT-Systems übermittelte Daten effektiv gegen Man- in-the-Middle-Angriffe geschützt sind. Bei der Verschlüsselung handelt es sich beispielsweise um eine symmetrische Verschlüsslung, eine asymmetrische Verschlüsslung oder eine hybride Verschlüsselung. Beispielsweise erfolgt eine Verschlüsselung unter Verwendung des TLS-Verschlüsselungsprotokolls.
Nach Ausführungsformen umfasst ein Aufbauen der einen oder mehreren kryptographisch geschützten Kommunikationsverbindungen jeweils eine gegenseitige Authentifizierung des TI ersten DLT-Knoten und des zweiten DLT-Knotens.
Ausführungsformen können den Vorteil haben, dass basierend auf der gegenseitigen Authentifizierung beide DLT-Knoten sicherstellen können, mit wem sie jeweils über die entsprechenden Kommunikationsverbindungen kommunizieren. So kann der erste DLT-Knoten des Warenempfängers sicherstellen, dass er tatsächlich mit dem DLT-Knoten kommuniziert, welcher dem Warensender zugeordnet ist, d.h. dem zweiten DLT-Knoten. Ferner kann der zweite DLT-Knoten des Warensenders sicherstellen, dass er tatsächlich mit dem DLT-Knoten kommuniziert, welcher dem Warenempfänger zugeordnet ist, d.h. dem ersten DLT-Knoten.
Nach Ausführungsformen ist das Prüfen der zweiten Spezifikation auf Übereinstimmung mit der ersten Spezifikation im Zuge der Initialisierung ein Prüfen auf Identität. Ausführungsformen können den Vorteil haben, dass sichergestellt werden kann, dass eine Identität zwischen der ersten Spezifikation gemäß Lieferauftrag und der zweiten Spezifikation gemäß Auftragsbestätigung vorliegt. Eine solche Identität bedeutet, dass sich Warenempfänger und Warensender auf eine identische Spezifikation der zu liefernden Ware geeinigt haben. In diesem Fall sind in beiden Teildatensätzen des geteilten Datensatzes beispielsweise jeweils identische Spezifikationen gespeichert. Weichen die erste und die zweite Spezifikation voneinander ab, kann beispielsweise unter Verwendung des mindestens einen Smart-Contracts ein Handshake-Protokoll zwischen den beiden DLT-Knoten ausgeführt werden, dessen Resultat eine Anpassung einer oder beider Spezifikationen ist, bis eine Identität vorliegt.
Nach Ausführungsformen umfasst das Initialisieren ferner, falls die eine oder mehreren physikalischen Eigenschaften gemäß der zweiten Spezifikation, die in den zweiten Datensatz eingetragen werden, von der einen oder den mehreren physikalischen Eigenschaften gemäß der ersten Spezifikation aus dem ersten Datensatz abweichen, ein Durchführen eines Handshakes zwischen dem ersten DLT-Knoten und dem zweiten DLT-Knoten zum Abgleich der ersten Spezifikation des ersten Datensatzes und der zweiten Spezifikation des zweiten Datensatzes, sodass die aus dem Abgleich resultierenden ersten und zweiten Spezifikationen übereinstimmen.
Bei dem Handshake kann es sich beispielsweise um einen automatischen oder einen semiautomatischen Handshake handeln. Im Falle eines automatischen Handshakes sind bei- spielsweise für Warenempfänger und Warensender jeweils Toleranzbereiche für die auszuhandelnden Parameter definiert. Abweichungen zwischen Parametern können in diesem Fall durch eine Angleichung innerhalb der jeweiligen Toleranzbereiche erzielt werden. Im Falle eines semi-automatischen Handshakes wird von einem der beiden Teilnehmer bzw. von einem dem entsprechenden Teilnehmer zugeordneten DLT-Knoten ein Vorschlag für einen Parameterwert erhalten, welcher von einem eigenen Vorschlag des entsprechenden Teilnehmers für den entsprechenden Parameter abweicht. Dieser abweichende Parameterwert kann beispielsweise durch Empfang einer Nutzereingabe seitens des entsprechenden Teilnehmers bestätigt werden. Wird der entsprechende Parameterwert durch eine Nutzereingabe bestätigt, kann ferner im Zuge des Handshakes eine Bestätigung des vorgeschlagenen Parameterwerts an den vorschlagenden zweiten Teilnehmer gesendet werden. Alternativ kann durch Empfang einer Nutzereingabe seitens des entsprechenden Teilnehmers ein Gegenvorschlag für den abweichenden Parameterwert empfangen werden. Im Zuge des Handshakes kann dieser Gegenvorschlag für den abweichenden Parameterwert an den zweiten Teilnehmer gesendet werden. Der zweite Teilnehmer bestätigt entweder den Gegenvorschlag, indem er eine entsprechende Bestätigung im Zuge des Handshakes sendet, oder er macht einen neuen Gegenvorschlag. Dieses Verfahren kann beispielsweise solange fortgesetzt werden, bis eine Einigung über den entsprechenden Parameterwert erzielt oder bis ein vordefiniertes Abbruchkriterium erfüllt ist. Bei einem entsprechenden Abbruchkriterium kann es sich beispielsweise um eine vordefinierte maximale Anzahl an Vorschlägen für einen Parameterwert, einen Ablauf einer vordefinierten maximalen Zeitspanne zum Aushandeln eines Parameterwerts oder einen Empfang einer Nutzereingabe, welche einen aktuellen Vorschlag für den entsprechenden Parameterwert explizit ablehnt, handeln.
Der Handshake kann durch den einen oder die mehreren Smart-Contracts ausgeführt oder zumindest initiiert werden. Vorzugsweise können Iterationen des automatischen oder semiautomatischen Handshakes zwischen den DLT-Knoten der Verhandlungspartner durch Einträgen von Vorschlägen in den jeweils verwalteten Teil des geteilten Datensatzes erfolgend, der anschließend an den DLT-Knoten des Verhandlungspartners übermittelt wird. Sämtliche Änderungen bleiben somit nachvollziehbar und können von den Verhandlungspartnern überprüft werden. Zwischen den Verhandlungspartnern herrscht somit Transparenz über die auszuhandelnden Parameter, da der eigene Vorschlag im eigenen Teil des geteilten Datensatzes und der Gegenvorschlag im jeweils anderen Teil des geteilten Datensatzes eingetragen wird. Ausführungsformen können den Vorteil haben, dass ein effektives Verfahren zum Angleichen unterschiedlicher Spezifikationen gemäß Lieferauftrag und Auftragsbestätigung, d.h. unterschiedlicher Vorschläge für die Spezifikation zwischen Warenempfänger und Warensender, bereitgestellt werden können.
Nach Ausführungsformen ist das Prüfen der zweiten Spezifikation auf Übereinstimmung mit der ersten Spezifikation im Zuge der Initialisierung ein Prüfen auf eine Übereinstimmung innerhalb vordefinierter dritter Toleranzen gemäß dem mindestens einen Smart-Contract.
Ausführungsformen können den Vorteil haben, dass keine Identität zwischen den Spezifikationen vorliegen muss. Somit sind Abweichungen innerhalb vordefinierter Toleranzen zulässig. Beispielsweise kann der Warensender somit die Spezifikation der zu liefernden Ware, etwa eine zu liefernde Warenmenge, innerhalb von vordefinierten Grenzen, d.h. den Toleranzen, an seine Möglichkeiten zur Lieferung der angefragten Ware anpassen.
Nach Ausführungsformen umfasst das Initialisieren ferner ein Durchführen eines Handshakes zwischen dem ersten DLT-Knoten und dem zweiten DLT-Knoten zum Abgleich der ersten Spezifikation des ersten Datensatzes und der zweiten Spezifikation des zweiten Datensatzes, falls eine oder mehrere Abweichungen zwischen der einen oder mehreren physikalischen Eigenschaften gemäß der zweiten Spezifikation, die in den zweiten Datensatz eingetragen werden, und den einen oder den mehreren physikalischen Eigenschaften gemäß der ersten Spezifikation aus dem ersten Datensatz größer als die vordefinierten dritten Toleranzen sind. Der Handshake bewirkt, dass die aus dem Abgleich resultierenden ersten und zweiten Spezifikationen innerhalb der vordefinierten dritten Toleranzen übereinstimmen.
Ausführungsformen können den Vorteil haben, dass ein effektives Verfahren zum Angleichen unterschiedlicher Spezifikationen gemäß Lieferauftrag und Auftragsbestätigung, d.h. unterschiedlicher Vorschläge für die Spezifikation zwischen Warenempfänger und Warensender, bereitgestellt werden kann. Unter Verwendung des mindestens einen Smart-Contracts wird beispielsweise ein Handshake-Protokoll zwischen den beiden DLT-Knoten ausgeführt, dessen Resultat eine Anpassung einer oder beider Spezifikationen ist, bis Abweichungen zwischen den beiden Spezifikationen nur noch innerhalb der entsprechenden vordefinierten Toleranzen vorliegen. Nach Ausführungsformen sind die von dem mindestens einen Smart-Contract umfassten Programminstruktionen ferner zu einem Einträgen und Prüfen von Wareneingangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger konfiguriert. Das Protokollieren der Warenlieferung in dem DLT-System umfasst ferner:
• Empfangen eines Wareneingangsprotokolls von dem Warenempfänger über das erste Netzwerk durch den ersten DLT-Knoten, wobei das Wareneingangsprotokoll einen oder mehrere zweite Sensorwerte für die eine oder mehreren physikalischen Eigenschaften der eingehenden Ware gemäß der ersten Spezifikation umfasst, welche mittels eines oder mehrerer dem Warenempfänger zugeordneter zweiter physikalischer Sensoren erfasst sind, wobei der eine oder die mehreren zweiten Sensorwerte zumindest einen zweiten Sensorwert umfassen, welcher die gelieferte Warenmenge quantifiziert,
• Prüfen des einen oder der mehreren zweiten Sensorwerte des Wareneingangsprotokolls auf Übereinstimmung mit der einen oder den mehreren physikalischen Eigenschaften der zu liefernden Ware gemäß dem geteilten Datensatz sowie mit dem einen oder den mehreren ersten Sensorwerten gemäß dem Warenausgangsprotokoll innerhalb vordefinierter vierter Toleranzen unter Verwendung des mindestens einen Smart-Contracts, wobei die geprüften zweiten Sensorwerte zumindest den die gelieferte Warenmenge quantifizierenden zweiten Sensorwert umfassen,
• viertes Aktualisieren des ersten Datensatzes durch den ersten DLT-Knoten unter Verwendung eines dritten Prüfergebnisses des Prüfens des einen oder der mehreren zweiten Sensorwerte des Wareneingangsprotokolls,
• Übermitteln mindestens einer vierten Aktualisierungsnachricht von dem ersten DLT- Knoten an den zweiten DLT-Knoten,
• fünftes Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten unter Verwendung der vierten Aktualisierungsnachricht.
Ausführungsformen können den Vorteil haben, dass die Protokollierung der Warenlieferung neben dem Warenausgangsprotokoll des Warensenders über die tatsächlich gesendete Ware auch ein Wareneingangsprotokoll des Warenempfängers über die tatsächlich empfangende Ware umfasst.
Wird die physische Warenlieferung von dem Warenempfänger empfangen, d.h. erreicht die zu liefernde Ware ein Lager des Warenempfängers, wird ein Wareneingangsprotokoll erstellt. Das entsprechende Wareneingangsprotokoll umfasst einen oder mehrere Sensorwerte für die eine oder mehreren physikalischen Eigenschaften der eingehenden Ware gemäß der ersten Spezifikation, welche mittels eines oder mehrerer dem Warenempfänger zugeordneter physikalischer Sensoren erfasst sind. Das Wareneingangsprotokoll gibt also für eine oder mehrere physikalische Eigenschaften, für welche in der ersten Spezifikation Zielwerte angegeben werden, jeweils sensorisch erfasste Messwerte an, welche den tatsächlichen Zustand der eingehenden Ware im Hinblick auf die entsprechenden physikalischen Eigenschaften wiedergeben. Die entsprechenden Sensorwerte umfassen dabei zumindest einen Sensorwert, welcher die gelieferte, d.h. eingehende, Warenmenge quantifiziert.
Der erste DLT-Knoten des Warenempfängers empfängt das Wareneingangsprotokolls von dem Warenempfänger über das erste Netzwerk und prüft den einen oder die mehreren zweiten Sensorwerte des Wareneingangsprotokolls auf Übereinstimmung mit der einen oder den mehreren physikalischen Eigenschaften der zu liefernden Ware. Hierbei wird geprüft, ob der eine oder die mehreren Sensorwerte des Wareneingangsprotokolls mit einer oder mehreren physikalischen Eigenschaften gemäß dem geteilten Datensatz innerhalb vordefinierter Toleranzen übereinstimmen. Liegt keine solche Übereinstimmung vor, wird beispielsweise ein Warnhinweis an den Warenempfänger und/oder den Warensender übermittelt. Ein solcher Warnhinweis kann beispielsweise bei einer zu geringen Liefermenge eine Nachlieferung seitens des Warensenders auslösen. Seitens des Warenempfängers kann ein solcher Warnhinweis beispielsweise eine Bestätigung der abweichenden physikalischen Eigenschaften seitens des Warenempfängers für eine erfolgreiche abschließende Validierung der Warenlieferung erforderlich machen.
Der erste Datensatz wird durch den ersten DLT-Knoten unter Verwendung des Ergebnisses der Prüfung des einen oder der mehreren ersten Sensorwerte des Wareneingangsprotokolls aktualisiert. Beispielsweise umfasst die Aktualisierung ein Einträgen des Wareneingangsprotokolls und/oder eines oder mehrerer der von dem Wareneingangsprotokoll angegebenen Sensorwerte. Beispielsweise werden alle von dem Wareneingangsprotokoll angegebenen Sensorwerte eingetragen. Beispielsweise werden nur solche Sensorwerte eingetragen, welche von den in dem ersten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware abweichen. Beispielsweise wird für Sensorwerte des Wareneingangsprotokolls, welche mit den in dem ersten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware übereinstimmen, nur eine Bestätigung in den zweiten Datensatz eingetragen, dass die entsprechenden Werte für die physikalischen Eigenschaften mit den erfassten Sensorwerten übereinstimmen.
Ferner wird eine vierte Aktualisierungsnachricht von dem ersten DLT-Knoten an den zweiten DLT-Knoten übermittelt. Die vierte Aktualisierungsnachricht umfasst beispielsweise das Wareneingangsprotokoll und/oder einen oder mehrere der von dem Wareneingangsprotokoll angegebenen Sensorwerte. Beispielsweise umfasst die vierte Aktualisierungsnachricht alle von dem Wareneingangsprotokoll angegebenen Sensorwerte. Beispielsweise umfasst die vierte Aktualisierungsnachricht nur solche Sensorwerte, welche von den in dem ersten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware abweichen. Beispielsweise umfasst die vierte Aktualisierungsnachricht für Sensorwerte des Wareneingangsprotokolls, welche mit den in dem ersten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware übereinstimmen, nur eine Bestätigung, dass die entsprechenden Werte für die physikalischen Eigenschaften gemäß dem geteilten Datensatz mit den erfassten Sensorwerten übereinstimmen.
Der zweite DLT-Knoten aktualisiert den zweiten Datensatz, d.h. den zweiten Teildatensatz des geteilten Datensatzes, unter Verwendung der vierten Aktualisierungsnachricht. Beispielsweise umfasst die Aktualisierung ein Einträgen des Wareneingangsprotokolls und/oder eines oder mehrerer der von dem Wareneingangsprotokoll angegebenen Sensorwerte. Beispielsweise werden alle von dem Wareneingangsprotokoll angegebenen Sensorwerte eingetragen. Beispielsweise werden nur solche Sensorwerte eingetragen, welche von den in dem zweiten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware abweichen. Beispielsweise wird für Sensorwerte des Wareneingangsprotokolls, welche mit den in dem zweiten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware übereinstimmen, nur eine Bestätigung in den zweiten Datensatz eingetragen, dass die entsprechenden Werte für die physikalischen Eigenschaften mit den erfassten Sensorwerten übereinstimmen.
Der eine oder die mehreren zweiten physikalischen Sensoren des Warensenders umfassen eine oder mehrere physikalische Messvorrichtungen zum Erfassen von Messdaten bzw. Sensorwerten. Solche Messdaten sind Daten, welche physikalische und/oder chemische Eigen- schäften eines Messobjekts quantitativ oder qualitativ beschreiben. Entsprechende Eigenschaften umfassen beispielsweise Gewicht, Volumen, Temperatur, Feuchtigkeit, Druck, Korngröße, Schallfeldgrößen, Helligkeit, pH-Wert, lonenstärke, elektrochemisches Potential, Leitfähigkeit, Viskosität, und/oder Transluzenz. Messdaten werden mittels physikalischer oder chemischer Effekte erfasst und in ein elektronisch weiterverarbeitbares elektrisches Signal umgeformt. Beispielsweise wird das entsprechende elektrisches Signal, welches die erfassten Messdaten umfasst, kryptographisch verschlüsselt. Hierzu kann beispielsweise eine symmetrische, eine asymmetrische oder eine hybride kryptographische Verschlüsslung zur Anwendung kommen. Somit können die entsprechenden Messdaten beispielsweise vor unerlaubten Zugriffen geschützt werden. Ferner oder alternativ kann das entsprechende elektrisches Signal, welches die erfassten Messdaten umfasst, digital signiert werden. Somit kann beispielsweise eine Authentizität der entsprechenden Messdaten nachgewiesen werden.
Nach Ausführungsformen umfasst die Validierungsnachricht eine Rechnung. Ausführungsformen können den Vorteil haben, dass im Zuge der Prüfung der Validierungsnachricht eine Rechnung für die Warenlieferung geprüft wird. Somit kann sichergestellt werden, dass Angeben der Rechnung zu physikalischen Eigenschaften der gelieferten Ware mit den tatsächlichen physikalischen Eigenschaften der gelieferten Ware übereinstimmen. Insbesondere kann so sichergestellt werden, dass der Rechnung zugrundeliegende Angaben zur Menge der gelieferten Ware mit einer tatsächlich gelieferten Warenmenge übereinstimmen.
Nach Ausführungsformen sind die von dem mindestens einen Smart-Contract umfassten Programminstruktionen ferner zur Rechnungserstellung der Rechnung konfiguriert. Die Rechnungserstellung erfolgt durch den zweiten DLT-Knoten unter Verwendung des mindestens einen Smart-Contracts. Das Prüfen der Parameter der Validierungsnachricht kann im Zuge der Rechnungserstellung erfolgen.
Ausführungsformen können den Vorteil haben, dass im Zuge der Validierung der Warenlieferung direkt eine Rechnungserstellung integriert werden kann. Mit einer Registrierung der erstellten Rechnung in dem DLT-System wird die Kontrolle der Warenlieferung beispielsweise erfolgreich abgeschlossen.
Unter Verwendung des einen oder der mehreren Smart-Contract können im Zuge der Rech- nungserstellung beispielsweise noch weitere Abgaben und Steuern, beispielsweise eine Umsatzsteuer, für den Rechnungsbetrag berechnet und auf diesen aufgeschlagen werden.
Nach Ausführungsformen wird die Rechnung von einem die Rechnung erstellenden ersten ERP-System des Warensenders empfangen. Ausführungsformen können den Vorteil haben, dass das DLT-System mit einem ERP-System, beispielsweise einem bestehenden ERP- System, des Warensenders kombiniert werden kann. Dabei stellt das DLT-System bzw. der von dem DLT-System verwaltete geteilte Datensatz einen Single-Point-of-Truth für die Warenlieferung dar. Beispielsweise ist für eine Validierung der Rechnung eine Registrierung zumindest in dem zweiten Datensatz auf dem zweiten DLT-Knoten notwendig. Beispielsweise umfasst das Registrieren ein Einträgen einer Rechnungsnummer der Rechnung in den zweiten Datensatz.
Beispielsweise verfügen sowohl der Warensender, als auch der Warenempfänger jeweils über eigenständige ERP-Systeme, während als Single-Point-of-Truth für beide Beteiligten, d.h. den Warenempfänger wie auch den Warensender, der in dem DLT-System bereitgestellte geteilte Datensatz dient.
Ein ERP-System bezeichnet ein Anwendungssoftware- bzw. IT-System oder eine Vielzahl miteinander kommunizierender Anwendungssoftware- bzw. IT-Systeme, welche zur Unterstützung einer Ressourcenplanung eines Unternehmens eingesetzt werden. Komplexe ERP- Systeme werden beispielsweise in Teilsysteme, d.h. Anwendungsmodule, aufgeteilt, welche je nach Bedarf miteinander kombiniert werden können. Enterprise-Resource-Planning (ERP) bezeichnet die unternehmerische Aufgabe, Personal und Ressourcen wie etwa Kapital, Betriebsmittel, Material und Informations- und Kommunikationstechnik rechtzeitig und bedarfsgerecht zu planen, zu steuern und zu verwalten.
Eine Kernfunktion von ERP ist in produzierenden Unternehmen die Materialbedarfsplanung, um sicherzustellen, dass alle für eine Herstellung von Erzeugnissen und/oder Komponenten erforderlichen Materialien an der richtigen Stelle, zur richtigen Zeit und in der richtigen Menge zur Verfügung stehen.
Beispielsweise können die ERP-Systeme von Warensender und Warenempfänger dazu kon- figuriert sein, für die Warenlieferung relevante Daten zu erstellen und/oder zusammenzustellen und diese dem DLT-System zur Verfügung zu stellen. Beispielsweise erstellt das ERP- System des Warenempfängers den Lieferauftrag und/oder das Wareneingangsprotokoll und sendet diese dem ersten DLT-Knoten zu. Beispielsweise erstellt das ERP-System des Warensenders die Auftragsbestätigung, das Warenausgangsprotokoll und/oder die Validierungsnachricht und sendet diese dem zweiten DLT-Knoten zu.
Nach Ausführungsformen handelt es sich bei den im Zuge des Protokollierens der Warenlieferung in den in dem DLT-System bereitgestellten geteilten Datensatz eingetragenen Daten um spiegelgleiche Daten der Warenlieferung aus dem ersten ERP-System des Warensenders und/oder einem zweiten ERP-System des Warenempfängers. Das erste und/oder zweite ERP-System sind zu einer Steuerung der Abwicklung der Warenlieferung konfiguriert. Durch Eintragung der spiegelgleichen Daten wird eine Datenkonsistenz zwischen dem geteilten Datensatz und den ERP-Systemen sichergestellt.
Ausführungsformen können den Vorteil haben, dass eine Datenkonsistenz zwischen dem geteilten Datensatz und den ERP-Systemen von Warensender und/oder Warenempfänger implementiert werden kann. Dabei stellt der geteilte Datensatz einen Single-Point-of-Truth für beide Teilnehmer bzw. deren voneinander unabhängigen ERP-Systeme dar. Beispielsweise empfängt der erste DLT-Knoten den Lieferauftrag vom dem ERP-System des Warenempfängers. Beispielsweise empfängt der zweite DLT-Knoten den Lieferauftrag vom dem ERP- System des Warensenders. Dabei spiegeln die in den geteilten Datensatz eingetragenen Daten die in dem ersten und/oder zweiten ERP-System gespeicherten Daten der Warenlieferung wider.
Nach Ausführungsformen erfolgt die Steuerung der Abwicklung der Warenlieferung durch den mindestens einen Smart-Contract, dessen Programminstruktionen ferner zu der Steuerung der Abwicklung der Warenlieferung konfiguriert sind.
Ausführungsformen können den Vorteil haben, dass die Abwicklung der Warenlieferung durch den mindestens einen Smart-Contract erfolgen kann. In diesem Fall sind beispielsweise weder auf Seiten des Warenempfängers, noch auf Seiten des Warensenders ein ERP- System notwendig zum Abwickeln der Warenlieferung. Beispielsweise kann ein Computer- system des Warenempfängers den Lieferauftrag über das erste Netzwerk direkt an den ersten DLT-Knoten senden bzw. der erste DLT-Knoten den Lieferauftrag direkt von dem Computersystem des Warenempfängers empfangen. Beispielsweise kann ein Computersystem des Warensenders die Auftragsbestätigung über das erste Netzwerk direkt an den zweiten DLT-Knoten senden.
Nach Ausführungsformen handelt es sich bei dem ersten Netzwerk beispielsweise um ein öffentliches Netzwerk. Beispielsweise handelt es sich beide dem ersten Netzwerk um das Internet oder ein anderes vorliegendes Wide Area Netzwerk, bspw. ein Funk- oder Ethernetbasiertes Netzwerk in einem Unternehmen oder zwischen beteiligten Unternehmen.
Entsprechend kann es sich nach Ausführungsformen bei dem ersten Netzwerk beispielsweise um ein Intranet handeln.
Nach Ausführungsformen ist eine Voraussetzung für das Empfangen des Lieferauftrags des Warenempfängers durch den ersten DLT-Knoten eine erfolgreiche Authentifizierung des Warenempfängers durch den ersten DLT-Knoten. Ausführungsformen können den Vorteil haben, dass der erste DLT-Knoten mittels einer erfolgreichen Authentifizierung des Warenempfängers sicherstellen kann, dass der Lieferauftrag tatsächlich von dem Warenempfänger stammt und von diesem autorisiert ist. Eine Authentifizierung kann beispielsweise unter Verwendung eines ersten Nutzernamens und eines ersten Passworts erfolgen, welche der Warenempfänger zum erfolgreichen Authentisieren gegenüber dem ersten DLT-Knoten angeben muss. Weitere Authentifizierungsverfahren, beispielsweise mittels kryptographischer Verfahren, Chip-Karten, und/oder biometrischer Daten können ebenfalls vorgesehen sein.
Nach Ausführungsformen ist eine Voraussetzung für das Empfangen der Auftragsbestätigung des Warensenders durch den zweiten DLT-Knoten eine erfolgreiche Authentifizierung des Warensenders durch den zweiten DLT-Knoten voraussetzt. Ausführungsformen können den Vorteil haben, dass der zweite DLT-Knoten mittels einer erfolgreichen Authentifizierung des Warensenders sicherstellen kann, dass die Auftragsbestätigung tatsächlich von dem Warensender stammt und von diesem autorisiert ist. Eine Authentifizierung kann beispielsweise unter Verwendung eines zweiten Nutzernamens und eines zweiten Passworts erfolgen, welche der Warenempfänger zum erfolgreichen Authentisieren gegenüber dem ersten DLT- Knoten angeben muss. Weitere Authentifizierungsverfahren, beispielsweise mittels kryptographischer Verfahren, Chip-Karten, und/oder biometrischer Daten können ebenfalls vorgesehen sein.
Nach Ausführungsformen ist eine Voraussetzung für das Empfangen des Warenausgangsprotokolls von dem Warensender durch den zweiten DLT-Knoten eine erfolgreiche Authentifizierung des Warensenders durch den zweiten DLT-Knoten. Ausführungsformen können den Vorteil haben, dass der zweite DLT-Knoten mittels einer erfolgreichen Authentifizierung des Warensenders sicherstellen kann, dass das Warenausgangsprotokoll tatsächlich von dem Warensender stammt und von diesem autorisiert ist. Eine Authentifizierung kann beispielsweise unter Verwendung eines zweiten Nutzernamens und eines zweiten Passworts erfolgen, welche der Warenempfänger zum erfolgreichen Authentisieren gegenüber dem ersten DLT-Knoten angeben muss. Weitere Authentifizierungsverfahren, beispielsweise mittels kryptographischer Verfahren, Chip-Karten, und/oder biometrischer Daten können ebenfalls vorgesehen sein.
Nach Ausführungsformen ist eine Voraussetzung für das Empfangen des Wareneingangsprotokolls von dem Warenempfänger durch den ersten DLT-Knoten eine erfolgreiche Authentifizierung des Warenempfängers durch den ersten DLT-Knoten. Ausführungsformen können den Vorteil haben, dass der erste DLT-Knoten mittels einer erfolgreichen Authentifizierung des Warenempfängers sicherstellen kann, dass das Wareneingangsprotokoll tatsächlich von dem Warenempfänger stammt und von diesem autorisiert ist. Eine Authentifizierung kann beispielsweise unter Verwendung eines ersten Nutzernamens und eines ersten Passworts erfolgen, welche der Warenempfänger zum erfolgreichen Authentisieren gegenüber dem ersten DLT-Knoten angeben muss.
Nach Ausführungsformen ist eine Voraussetzung für das Verwenden des Lieferauftrags des Warenempfängers durch den ersten DLT-Knoten eine erfolgreiche Signaturprüfung einer Signatur des Lieferauftrags durch den ersten DLT-Knoten.
Ausführungsformen können den Vorteil haben, dass anhand der Signatur des Lieferauftrags eine Authentizität des Lieferauftrags geprüft werden kann, d.h. der erste DLT-Knoten kann prüfen, ob der empfangene Lieferauftrag tatsächlich von dem Warenempfänger autorisiert ist. Zum Signieren des Lieferauftrags verwendet der Warenempfänger beispielsweise einen dritten Signaturschlüssel. Bei diesem dritten Signaturschlüssel handelt es sich beispielsweise um einen dritten privaten kryptographischen Schlüssel eines dritten asymmetrischen kryptographischen Schlüsselpaars. Beispielsweise umfasst der erste DLT-Knoten und/oder der auf dem ersten DLT-Knoten ausgeführte Smart-Contract einen dritten Signaturprüfschlüssel zum Valideren von Signaturen des Warenempfängers, welche unter Verwendung des dritten Signaturschlüssels erstellt wurden. Bei diesem dritten Signaturprüfschlüssel handelt es sich beispielsweise um einen dritten öffentlichen kryptographischen Schlüssel des dritten asymmetrischen kryptographischen Schlüsselpaars.
Nach Ausführungsformen ist eine Voraussetzung für das Verwenden der Auftragsbestätigung des Warensenders durch den zweiten DLT-Knoten eine erfolgreiche Signaturprüfung einer Signatur der Auftragsbestätigung durch den zweiten DLT-Knoten.
Ausführungsformen können den Vorteil haben, dass anhand der Signatur der Auftragsbestätigung eine Authentizität der Auftragsbestätigung geprüft werden kann, d.h. der zweite DLT- Knoten kann prüfen, ob die empfangene Auftragsbestätigung tatsächlich von dem Warensender autorisiert ist. Zum Signieren der Auftragsbestätigung verwendet der Warensender beispielsweise einen vierten Signaturschlüssel. Bei diesem vierten Signaturschlüssel handelt es sich beispielsweise um einen vierten privaten kryptographischen Schlüssel eines vierten asymmetrischen kryptographischen Schlüsselpaars. Beispielsweise umfasst der zweite DLT- Knoten und/oder der auf dem zweiten DLT-Knoten ausgeführte Smart-Contract einen vierten Signaturprüfschlüssel zum Valideren von Signaturen des Warensenders, welche unter Verwendung des vierten Signaturschlüssels erstellt wurden. Bei diesem vierten Signaturprüfschlüssel handelt es sich beispielsweise um einen vierten öffentlichen kryptographischen Schlüssel des vierten asymmetrischen kryptographischen Schlüsselpaars.
Nach Ausführungsformen ist eine Voraussetzung für das Verwenden des Warenausgangsprotokolls des Warensenders durch den zweiten DLT-Knoten eine erfolgreiche Signaturprüfung einer Signatur des Warenausgangsprotokolls durch den zweiten DLT-Knoten.
Ausführungsformen können den Vorteil haben, dass anhand der Signatur des Warenausgangsprotokolls eine Authentizität des Warenausgangsprotokolls geprüft werden kann, d.h. der zweite DLT-Knoten kann prüfen, ob das empfangene Warenausgangsprotokoll tatsächlich von dem Warensender autorisiert ist. Zum Signieren der Auftragsbestätigung verwendet Warensender beispielsweise den vierten Signaturschlüssel, dessen Signaturen der zweite DLT-Knoten mit dem vierten Signaturprüfschlüssel validieren kann.
Nach Ausführungsformen ist eine Voraussetzung für das Verwenden des Wareneingangsprotokolls des Warenempfängers durch den ersten DLT-Knoten eine erfolgreiche Signaturprüfung einer Signatur des Wareneingangsprotokolls durch den ersten DLT-Knoten.
Ausführungsformen können den Vorteil haben, dass anhand der Signatur des Wareneingangsprotokolls eine Authentizität des Wareneingangsprotokolls geprüft werden kann, d.h. der erste DLT-Knoten kann prüfen, ob das empfangene Wareneingangsprotokoll tatsächlich von dem Warenempfänger autorisiert ist. Zum Signieren des Wareneingangsprotokolls verwendet der Warenempfänger beispielsweise den dritten Signaturschlüssel, dessen Signaturen der erste DLT-Knoten mit dem Signaturprüfschlüssel validieren kann.
Nach Ausführungsformen werden der erste DLT-Knoten und der zweite DLT-Knoten durch einen oder mehrere DLT-Server des DLT-Systems bereitgestellt. Beispielsweise sind der erste DLT-Knoten und der zweite DLT-Knoten auf demselben DLT-Server des DLT-Systems implementiert. Beispielsweise sind der erste DLT-Knoten und der zweite DLT-Knoten auf zwei verschiedenen DLT-Servern des DLT-Systems implementiert.
Nach Ausführungsformen ist der eine oder die mehreren DLT-Server des DLT-Systems in einem oder mehreren gegen unberechtigte Zutritte gesicherten Rechenzentren angeordneten. Ausführungsformen können den Vorteil haben, dass durch die Zutrittssicherung unberechtigte physische Zugriffe auf die DLT-Server und damit auf die auf den DLT-Servern implementierten DLT-Knoten verhindert werden können. Diese physische Zutritts- bzw. Zugriffssicherung kann beispielsweise zusätzlich zu einer kryptographischen Zugriffsicherung implementiert werden, welche unberechtigte Zugriffe auf die DLT-Server bzw. die DLT- Knoten über das erste Netzwerk, beispielsweise das Internet, verhindern. Diese kryptographische Zugriffsicherung umfasst beispielsweise jeweils eine erfolgreiche Authentifizierung als Voraussetzung für Zugriffe auf die DLT-Knoten über das erste Netzwerk. Beispielsweise erfordert die Authentifizierung jeweils die korrekte Angabe eines Benutzernamens und eines Passworts desjenigen Teilnehmers, etwa Warensender oder Warenempfänger, dem der entsprechende DLT-Knoten zugeordnet ist. Beispielsweise ist für eine erfolgreiche Authentifizierung eine Multi-Faktor-Authentisierung, etwa Zwei-Faktor-Authentisierung, Voraussetzung. Die Zutrittssicherung des Rechenzentrums umfasst beispielsweise eine Kontrolle des Zutritts zu dem Rechenzentrum sowie eine Verwendung einer Alarmanlage zur Sicherung der Räume des Rechenzentrums. Die Alarmanlage umfasst beispielsweise eine Einbruchmeldeanlage (EMA), d.h. eine elektronisch betriebene Einrichtung, die dem Objektschutz dienen. Eine Einbruchmeldeanlage ist beispielsweise dazu konfiguriert, durch Abschreckung Einbrüche zu verhindern, im Fall eines Einbruchs hilfeleistende Dienste, etwa die Polizei und/oder einen privaten Sicherheitsdienst, zu benachrichtigen, die Aktionszeit von Einbrechern zu minimieren, eine unmittelbare Umgebung sowie beteiligte, anwesende Personen zu alarmieren, und/oder einen tatsächlich erfolgten Einbruch zu rekonstruieren.
Nach Ausführungsformen erfolgt die Datenübertragung zwischen den DLT-Knoten über ein zweites Netzwerk.
Beispielsweise handelt es sich bei dem zweiten Netzwerk um ein von dem ersten Netzwerk verschiedenes Netzwerk. Beispielsweise handelt es sich bei dem zweiten Netzwerk um ein von dem ersten Netzwerk unabhängiges Netzwerk. Beispielsweise handelt es sich bei dem zweiten Netzwerk um dasselbe Netzwerk wie das erste Netzwerk.
Nach Ausführungsformen handelt es sich bei dem zweiten Netzwerk um ein privates oder ein öffentliches Netzwerk. Im Falle eines privaten Netzwerks handelt es sich bei dem zweiten Netzwerk beispielsweise um ein Intranet. Im Falle eines öffentlichen Netzwerks handelt es sich bei dem zweiten Netzwerk beispielsweise um das Internet.
Nach Ausführungsformen sind die von dem mindestens einen Smart-Contract umfassten Programminstruktionen ferner zu einem Triggern einer elektronischen Zahlungstransaktion konfiguriert. Das Triggern der Zahlungstransaktion durch den Smart-Contract erfolgt auf die Registrierung der Validierungsnachricht in dem DLT-System hin.
Ausführungsformen können den Vorteil haben, dass Zahlungen und Verbuchungen in Echtzeit erfolgen können. Ausführungsformen können ferner den Vorteil haben, dass durch die Registrierung der Validierungsnachricht in dem DLT-System, d.h. mit einer erfolgreichen Validierung der Warenlieferung in dem DLT-System, eine elektronische Zahlungstransaktion getriggert wird. Beispielsweise wird die Zahlungstransaktion mit der Registrierung der Validierungsnachricht in dem ersten Datensatz und/oder dem zweiten Datensatz getriggert. Dabei legt beispielsweise die registrierte Validierungsnachricht den zu zahlenden Betrag der elektronischen Zahlungstransaktion fest.
Der Zahlungsverkehr kann mit Datenströmen aus der Validierung gekoppelt und in einem geschlossenen Datenkreislauf gehalten werden.
Nach Ausführungsformen handelt es sich bei der getriggerten elektronischen Zahlungstransaktion um eine Überweisung von einem Bankkonto des Warenempfängers auf ein Bankkonto des Warensenders.
Nach Ausführungsformen handelt es sich bei der getriggerten elektronischen Zahlungstransaktion um eine IBAN-Überweisung von einem IBAN-Konto des Warenempfängers auf ein IBAN-Konto des Warensenders.
Nach Ausführungsformen handelt es sich bei der getriggerten elektronischen Zahlungstransaktion um eine unter Verwendung des DLT-Systems ausgeführten Transaktion eines Betrags an programmierbarem Geld.
Ausführungsformen können den Vorteil haben, dass die Transaktion des Betrags an programmierbarem Geld innerhalb des DLT-Systems erfolgen kann. Somit kann die Transaktion durch Registrierung der Validierungsnachricht getriggert und direkt in dem DLT-System, bei- spielweis unter Verwendung des mindestens einen Smart-Contracts, ausgeführt werden.
Programmierbares Geld bezeichnet eine digitale Ausprägung von Geld, bei welchem der Nutzer auf der Basis von Attributen des digitalen Geldes selbst inhärente Logiken für bedingte Verwendungen programmieren kann. Beispiele hierfür sind ein Auslösen einer Transaktion nach Erfüllung einer oder mehrerer Bedingungen, etwa Zeit, Ort, Nutzungsart, etc.
Beispielsweise wird eine Zahlungsinfrastruktur bereitgestellt, die es Warensender und Warenempfänger ermöglicht, gemeinsam eine programmierbare Währung zu nutzen. Ferner kann so beispielsweise eine Validierung der Warenlieferung und Verrechnung in einem geschlossenen Datenkreislauf durchgeführt werden. Nach Ausführungsformen ist das DLT-Systems dazu konfiguriert, den zu zahlenden Rechnungsbetrag von einem Konto des Warenempfängers für programmierbares Geld auf ein Konto des Warensenders für programmierbares Geld zu transferieren. Vorzugsweise kann das DLT-System konfiguriert sein, einen Fiat-Geldbetrag eines dem Warenempfänger zugeordneten Fiat-Geldkontos in einen Betrag des programmierbaren Geldes auf dem Konto des Warenempfängers für programmierbares Geld zu transformieren. Ferner kann das DLT- System konfiguriert sein, zumindest teilweise den in Form programmierbaren Geldes transferierten Rechnungsbetrags auf dem Konto des Warensenders für programmierbares Geld in einen Fiat-Geldbetrag auf einem dem Warensender zugeordneten Fiat-Geldkonto zu transformieren.
Ausführungsformen können den Vorteil haben, dass die Transaktion mittels programmierbaren Gelds abgewickelt werde kann. Hierzu kann der Fiat-Geldbetrag des Warenempfängers in einen Betrag des programmierbaren Geldes transformiert werden, welcher zumindest teilweise zur Zahlung der gelieferten Ware verwendet wird. Der von dem Warensender als Bezahlung für die gelieferte Ware empfangene Rechnungsbetrag in Form programmierbaren Geldes kann anschließend in einen Fiat-Geldbetrag transformiert werden. Dieser Fiat-Geldbetrag kann dem Warensender auf einem dem Warensender zugeordneten Fiat-Geldkonto gutgeschrieben werden.
Fiat-Geld bezeichnet eine klassische Währung, d.h. ein staatlich festgelegtes Tauch- und Zahlungsmittel, welches künstlich erschaffen, ungedeckt und nicht limitiert ist. Mit anderen Worten handelt es sich um ein Wirtschaftsobjekt ohne inneren Wert, welches als Tauschmittel dient.
Nach Ausführungsformen wird die Zahlungstransaktion unter Verwendung des mindestens einen Smart-Contracts in dem DLT-System protokolliert. Unter Verwendung des Smart- Contracts werden ferner elektronische Kontoauszüge über die protokollierte Zahlungstransaktion für den Warenempfänger und/oder den Warensender ausgestellt.
Ausführungsformen können den Vorteil haben, dass zusätzlich zum Ausführen der elektronischen Zahlungstransaktion zudem elektronische Kontoauszüge über die entsprechende Zahlungstransaktion für den Warenempfänger und/oder den Warensender ausgestellt werden. Die Kontoauszüge werden beispielweise gemäß dem MT940-Standard ausgestellt. MT940 (MT=Message Type) ist der SWIFT-Standard (Society for Worldwide Interbank Financial Telecommunication) bzw. Banking Communication Standard zur elektronischen Übermittlung von Kontoauszug-Daten.
Weitere Ausführungsformen umfassen einen geteilten Datensatz eines zugangsbeschränkten DLT-Systems zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger unter Verwendung des DLT-Systems. Der geteilte Datensatz umfasst einen ersten Teil. Der erste Teil ist ein durch einen dem Warenempfänger zugeordneten ersten DLT-Knoten verwalteter erster Datensatz. Ferner umfasst der geteilte Datensatz einen zweiten Teil. Der zweite Teil ist ein durch einen dem Warensender zugeordneten zweiten DLT-Knoten verwalteter zweiter Datensatz.
Beispielsweise umfasst der erste Datensatz des ersten Teils Angaben zu einer oder mehreren physikalischen Eigenschaften der zu liefernden Ware aus einem Lieferauftrag als eine erste Spezifikation. Die physikalischen Eigenschaften der ersten Spezifikation umfassen zumindest eine zu liefernde Warenmenge. Beispielsweise umfasst der erste Datensatz des ersten Teils Angaben zu einer zweiten Spezifikation der eine oder mehreren physikalischen Eigenschaften der zu liefernden Ware gemäß einer Auftragsbestätigung. Beispielsweise umfasst der erste Datensatz des ersten Teils ein Prüfergebnis einer Prüfung der zweiten Spezifikation. Beispielsweise umfasst der erste Datensatz des ersten Teils einen oder mehrere erste Sensorwerte für die eine oder mehreren physikalischen Eigenschaften der Ware gemäß einem Warenausgangsprotokoll, welche mittels eines oder mehrerer dem Warensender zugeordneter physikalischer Sensoren erfasst sind. Der eine oder die mehreren ersten Sensorwerte umfassen zumindest einen ersten Sensorwert, welcher die gelieferte Warenmenge quantifiziert. Beispielsweise umfasst der erste Datensatz des ersten Teils ein Prüfergebnis einer Prüfung der ersten Sensorwerte des Warenausgangsprotokolls. Beispielsweise umfasst der erste Datensatz des ersten Teils einen oder mehrere zweite Sensorwerte für die eine oder mehreren physikalischen Eigenschaften der Ware gemäß einem Wareneingangsprotokoll, welche mittels eines oder mehrerer dem Warenempfänger zugeordneter physikalischer Sensoren erfasst sind. Der eine oder die mehreren zweiten Sensorwerte umfassen zumindest einen zweiten Sensorwert, welcher die gelieferte Warenmenge quantifiziert. Beispielsweise umfasst der erste Datensatz des ersten Teils ein Prüfergebnis einer Prüfung der zweiten Sensorwerte des Warenausgangsprotokolls. Beispielsweise umfasst der erste Datensatz des ersten Teils eine Registrierung einer Validierungsnachricht zum Validieren der Warenlieferung. Beispielsweise umfasst die Registrierung Angaben zu einem oder mehreren Parametern der Validierungsnachricht. Beispielsweise umfassen die Parameter zumindest eine zu validierende Warenmenge. Beispielsweise umfasst der erste Datensatz des ersten Teils ein Prüfergebnis einer Prüfung der Parameter der Validierungsnachricht.
Beispielsweise umfasst der zweite Datensatz des zweiten Teils Angaben zu einer oder mehreren physikalischen Eigenschaften der zu liefernden Ware aus einem Lieferauftrag als eine erste Spezifikation. Die physikalischen Eigenschaften der ersten Spezifikation umfassen zumindest eine zu liefernde Warenmenge. Beispielsweise umfasst der zweite Datensatz des zweiten Teils Angaben zu einer zweiten Spezifikation der eine oder mehreren physikalischen Eigenschaften der zu liefernden Ware gemäß einer Auftragsbestätigung. Beispielsweise umfasst der zweite Datensatz des zweiten Teils ein Prüfergebnis einer Prüfung der zweiten Spezifikation. Beispielsweise umfasst der zweite Datensatz des zweiten Teils einen oder mehrere erste Sensorwerte für die eine oder mehreren physikalischen Eigenschaften der Ware gemäß einem Warenausgangsprotokoll, welche mittels eines oder mehrerer dem Warensender zugeordneter physikalischer Sensoren erfasst sind. Dir eine oder die mehreren ersten Sensorwerte umfassen zumindest einen ersten Sensorwert, welcher die gelieferte Warenmenge quantifiziert. Beispielsweise umfasst der zweite Datensatz des zweiten Teils ein Prüfergebnis einer Prüfung der ersten Sensorwerte des Warenausgangsprotokolls. Beispielsweise umfasst der zweite Datensatz des zweiten Teils einen oder mehrere zweite Sensorwerte für die eine oder mehreren physikalischen Eigenschaften der Ware gemäß einem Wareneingangsprotokoll, welche mittels eines oder mehrerer dem Warenempfänger zugeordneter physikalischer Sensoren erfasst sind. Der eine oder die mehreren zweiten Sensorwerte umfassen zumindest einen zweiten Sensorwert, welcher die gelieferte Warenmenge quantifiziert. Beispielsweise umfasst der zweite Datensatz des zweiten Teils ein Prüfergebnis einer Prüfung der zweiten Sensorwerte des Warenausgangsprotokolls. Beispielsweise umfasst der zweite Datensatz des zweiten Teils eine Registrierung einer Validierungsnachricht zum Validieren der Warenlieferung. Beispielsweise umfasst die Registrierung Angaben zu einem oder mehreren Parametern der Validierungsnachricht. Beispielsweise umfassen die Parameter zumindest eine zu validierende Warenmenge. Beispielsweise umfasst der zweite Datensatz des zweiten Teils ein Prüfergebnis einer Prüfung der Parameter der Validierungsnachricht. Beispielsweise ist der geteilte Datensatz das Resultat eines Ausführens eines oder mehrere der vorgenannten Verfahrensschritte des Verfahrens zur computerimplementierten Kontrolle der Warenlieferung auszuführen. Beispielsweise ist der geteilte Datensatz das Resultat eines Ausführens jedes der vorgenannten Verfahrensschritte des Verfahrens zur computerimplementierten Kontrolle der Warenlieferung auszuführen.
Der geteilte Datensatz, welcher auf zwei DLT-Knoten verteilt ist und die beiden (Teil-)Datens- ätze von Warenempfänger und Warensender umfasst, kann den Vorteil haben, einen effektiven Ansatz zur vertraulichen Abwicklung von Transaktionen zwischen den beiden DLT- Knoten bereitzustellen. Ferner ermöglicht ein solcher geteilte Datensatz eine effektive Absicherung von Transaktionen sowie eine Erhöhung der Datensicherheit zwischen den DLT- Knoten.
Der geteilte Datensatz kann in einem beliebigen Verfahren gemäß einer oder mehreren Ausführungsformen der vorliegenden Beschreibung verwendet werden. Ferner kann der Datensatz Gegenstand der vorgenannten Verfahren sein und durch diese bearbeitet und aktualisiert werden.
Weitere Ausführungsformen umfassen eine Verwendung eines geteilten Datensatz gemäß einer oder mehreren Ausführungsformen der vorliegenden Beschreibung zu einem Initialisieren der Warenlieferung in dem DLT-System. Der geteilte Datensatz kann zu einem Initialisieren in einem beliebigen Verfahren gemäß einer oder mehreren Ausführungsformen der vorliegenden Beschreibung verwendet werden.
Weitere Ausführungsformen umfassen eine Verwendung eines geteilten Datensatz gemäß einer oder mehreren Ausführungsformen der vorliegenden Beschreibung zu einem Protokollieren der Warenlieferung in dem DLT-System. Der geteilte Datensatz kann zu einem Protokollieren in einem beliebigen Verfahren gemäß einer oder mehreren Ausführungsformen der vorliegenden Beschreibung verwendet werden.
Weitere Ausführungsformen umfassen eine Verwendung eines geteilten Datensatz gemäß einer oder mehreren Ausführungsformen der vorliegenden Beschreibung zu einem Validieren der Warenlieferung in dem DLT-System. Der geteilte Datensatz kann zu einem Validieren in einem beliebigen Verfahren gemäß einer oder mehreren Ausführungsformen der vorliegenden Beschreibung verwendet werden.
Weitere Ausführungsformen umfassen einen DLT-Knoten eines zugangsbeschränkten DLT- Systems zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger. Der DLT-Knoten ist auf einem DLT-Server des DLT-Systems implementiert und dem Warenempfänger zugeordnet. Der DLT-Server umfasst einen Prozessor und einen Speicher mit Programminstruktionen. Durch die Programminstruktionen wird auf dem DLT-Knoten mindestens ein Smart-Contract bereitgestellt. Die den mindestens einen Smart-Contract bereitstellenden Programminstruktionen umfassen Programminstruktionen zu einem Einträgen und Prüfen von Lieferaufträgen und Auftragsbestätigungen.
Ein Ausführen der Programminstruktionen durch den Prozessor veranlasst den Prozessor dazu, den DLT-Knoten so zu steuern, dass der DLT-Knoten im Zuge eines Initialisierens der Warenlieferung in dem DLT-System Folgendes ausführt:
• Empfangen eines Lieferauftrags des Warenempfängers über von dem Warensender an den Warenempfänger zu liefernde Ware durch den DLT-Knoten über ein erstes Netzwerk, wobei der Lieferauftrag eine oder mehrere physikalische Eigenschaften der zu liefernden Ware als eine erste Spezifikation bestimmt, wobei die physikalischen Eigenschaften der ersten Spezifikation zumindest eine zu liefernde Warenmenge umfassen,
• Erstellen eines ersten durch den DLT-Knoten verwalteten Datensatzes und Einträgen mindestens der einen oder mehreren physikalischen Eigenschaften des Lieferauftrags durch den DLT-Knoten in den ersten Datensatz unter Verwendung des mindestens einen Smart-Contracts, wobei der erste Datensatz ein erster Teil eines zwischen dem DLT-Knoten und einem weiteren, dem Warensender zugeordneten DLT-Knoten des DLT-Systems geteilten Datensatzes ist,
• Übermitteln mindestens des ersten Datensatzes von dem DLT-Knoten an den weiteren DLT-Knoten,
• Empfangen mindestens einer ersten Aktualisierungsnachricht von dem weiteren DLT- Knoten über eine Aktualisierung des zweiten Datensatzes unter Verwendung eines ersten Prüfergebnisses einer Prüfung einerzweiten Spezifikation der einen oder mehreren physikalischen Eigenschaften der zu liefernden Ware gemäß einer Auftragsbestätigung auf Übereinstimmung mit der ersten Spezifikation, erstes Aktualisieren des ersten Datensatzes durch den DLT-Knoten unter Verwendung ersten Aktualisierungsnachricht.
Weitere Ausführungsformen umfassen einen DLT-Knoten, wobei die den mindestens einen Smart-Contract bereitstellenden Programminstruktionen Programminstruktionen zu einem Einträgen und Prüfen von Warenausgangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger umfassen. Das Ausführen der Programminstruktionen durch den Prozessor des DLT-Knotens veranlasst den Prozessor dazu, den DLT-Knoten ferner so zu steuern, dass der DLT-Knoten im Zuge eines Protokollierens der Warenlieferung in dem DLT-System Folgendes ausführt:
• Empfangen mindestens einer zweiten Aktualisierungsnachricht von dem weiteren DLT-Knoten über eine Aktualisierung des zweiten Datensatzes unter Verwendung eines zweiten Prüfergebnisses einer Prüfung eines oder mehrerer erster Sensorwerte eines Warenausgangsprotokolls auf Übereinstimmung mit der einen oder den mehreren physikalischen Eigenschaften der zu liefernden Ware gemäß dem geteilten Datensatz innerhalb vordefinierter erster Toleranzen, wobei der eine oder die mehreren ersten Sensorwerte des Warenausgangsprotokolls mittels eines oder mehrerer dem Warensender zugeordneter erster physikalischer Sensoren erfasst sind, wobei die geprüften ersten Sensorwerte zumindest den die gelieferte Warenmenge quantifizierenden ersten Sensorwert umfassen,
• zweites Aktualisieren des ersten Datensatzes durch den DLT-Knoten unter Verwendung der zweiten Aktualisierungsnachricht.
Weitere Ausführungsformen umfassen einen DLT-Knoten, wobei die den mindestens einen Smart-Contract bereitstellenden Programminstruktionen Programminstruktionen zu einem Validieren der Warenlieferung umfassen. Das Ausführen der Programminstruktionen durch den Prozessor des DLT-Knotens veranlasst den Prozessor dazu, den DLT-Knoten ferner so zu steuern, dass der DLT-Knoten im Zuge eines Validierens der Warenlieferung in dem DLT- System Folgendes ausführt:
• Empfangen mindestens einer dritten Aktualisierungsnachricht von dem weiteren DLT- Knoten über eine Aktualisierung des zweiten Datensatzes unter Verwendung einer Validierungsnachricht, wobei die Aktualisierung des zweiten Datensatzes unter Verwendung der Validierungsnachricht eine Registrierung der Validierungsnachricht in dem zweiten Datensatz umfasst, wobei die Aktualisierung des zweiten Datensatzes unter Verwendung der Validierungsnachricht eine erfolgreiche Prüfung von Parametern der Validierungsnachricht durch den weiteren DLT-Knoten bestätigt, wobei die Parameter zumindest eine zu validierende Warenmenge umfassen, wobei das Prüfen der Parameter ein Prüfen der zu validierenden Warenmenge auf Übereinstimmung mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb einer vordefinierten zweiten Toleranz umfasst,
• drittes Aktualisieren des ersten Datensatzes durch den DLT-Knoten unter Verwendung der dritten Aktualisierungsnachricht, wobei das dritte Aktualisieren des ersten Datensatzes ein Registrieren der Validierungsnachricht in dem ersten Datensatz umfasst.
Beispielsweise ist der DLT-Knoten dazu konfiguriert, einen oder mehrere der vorgenannten Verfahrensschritte des dem Warenempfänger zugeordneten DLT-Knoten gemäß einer beispielhaften Ausführungsformen des Verfahrens zur computerimplementierten Kontrolle der Warenlieferung auszuführen. Beispielsweise ist der DLT-Knoten dazu konfiguriert, jeden der vorgenannten Verfahrensschritte des dem Warenempfänger zugeordneten DLT-Knoten gemäß einer beispielhaften Ausführungsformen des Verfahrens zur computerimplementierten Kontrolle der Warenlieferung auszuführen.
Unter einem „Prozessor“ wird hier eine Logikschaltung verstanden, die zur Ausführung von Programminstruktionen dient. Die Logikschaltung kann auf einem oder mehreren diskreten Bauelementen implementiert sein, insbesondere auf einem oder mehreren Chips. Insbesondere wird unter einem „Prozessor“ ein Mikroprozessor oder ein Mikroprozessorsystem aus mehreren Prozessorkernen und/oder mehreren Mikroprozessoren verstanden.
Unter einem „Programm“ bzw. „Programminstruktionen“ wird hier ohne Einschränkung jede Art von Computerprogramm verstanden, welches maschinenlesbare Instruktionen zur Steuerung einer Funktionalität des Computers umfasst.
Unter einem „Speicher“ werden hier sowohl flüchtige als auch nicht flüchtige Speicher, insbesondere elektronische Speicher bzw. digitale Speichermedien verstanden.
Unter einem „nichtflüchtigen Speicher“ wird hier ein elektronischer Speicher zur dauerhaften Speicherung von Daten verstanden. Ein nichtflüchtiger Speicher kann als nichtänderbarere Speicher konfiguriert sein, der auch als Read-Only Memory (ROM) bezeichnet wird, oder als änderbarer Speicher, der auch als Non-Volatile Memory (NVM) bezeichnet wird. Insbesondere kann es sich hierbei um ein EEPROM, beispielsweise ein Flash-EEPROM, kurz als Flash bezeichnet, handeln. Ein nichtflüchtiger Speicher zeichnet sich dadurch aus, dass die darauf gespeicherten Daten auch nach Abschalten der Energieversorgung erhalten bleiben.
Unter einem „flüchtigen Speicher“ wird hier ein elektronischer Speicher zur vorübergehenden Speicherung von Daten verstanden, welcher dadurch gekennzeichnet ist, dass gespeicherte Daten nach dem Abschalten der Energieversorgung verloren gehe. Insbesondere kann es sich hierbei um einen flüchtigen Direktzugriffsspeicher, der auch als Random-Access Memory (RAM) bezeichnet wird, oder einen flüchtigen Arbeitsspeicher des Prozessors handeln.
Unter einem „geschützten Speicherbereich“ wird hier ein Bereich eines elektronischen Speichers verstanden, auf den ein Zugriff, das heißt ein Lesezugriff oder ein Schreibzugriff, nur über einen Prozessor des entsprechenden elektronischen Geräts möglich ist. Nach Ausführungsformen ist der Zugriff von dem mit dem Speicher gekoppelten Prozessor nur dann möglich, wenn eine hierzu erforderliche Bedingung erfüllt ist. Hierbei kann es sich zum Beispiel um eine kryptografische Bedingung, insbesondere eine erfolgreiche Authentifizierung und/oder eine erfolgreiche Berechtigungsprüfung einer Zugriffsanfrage, handeln.
Unter einer „Kommunikationsschnittstelle“ wird hier eine Schnittstelle verstanden, über die Daten empfangen und gesendet werden können, wobei die Kommunikationsschnittstelle kontaktbehaftet oder kontaktlos konfiguriert sein kann. Bei der Kommunikationsschnittstelle kann es sich um eine interne Schnittstelle oder um eine externe Schnittstelle handeln, welche beispielsweise mittels eines Kabels oder kabellos mit einem zugeordneten Gerät verbunden ist.
Eine Kommunikation kann beispielsweise über ein Netzwerk erfolgen. Unter einem „Netzwerk“ wird hier jedes Übertragungsmedium mit einer Anbindung zur Kommunikation verstanden, insbesondere eine lokale Verbindung oder ein lokales Netzwerk, insbesondere ein Local Area Network (LAN), ein privates Netzwerk, insbesondere ein Intranet, oder ein virtuelles privates Netzwerk (Virtual Private Network - VPN). Beispielsweise kann ein Computersystem eine Standardfunkschnittstelle zur Anbindung an ein WLAN aufweisen. Ferner kann es sich um ein öffentliches Netzwerk, wie beispielsweise das Internet handeln. Je nach Ausführungsform kann diese Verbindung auch über ein Mobilfunknetzwerk hergestellt werden. Unter einem „Mobilfunknetzwerk“ wird hier und im Folgenden ein digitales zellulares Mobilfunknetzwerk verstanden, welches nach einem Mobilfunkstandard wie zum Beispiel GSM, UMTS, LTE, CDMA oder einem anderen Standard aufgebaut sein kann.
Weitere Ausführungsformen umfassen einen DLT-Knoten eines zugangsbeschränkten DLT- Systems zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger. Der DLT-Knoten ist auf einem DLT-Server des DLT-Systems implementiert und dem Warensender zugeordnet. Der DLT-Server umfasst einen Prozessor und einen Speicher mit Programminstruktionen. Durch die Programminstruktionen wird auf dem DLT-Knoten mindestens ein Smart-Contract bereitgestellt. Die den mindestens einen Smart-Contract bereitstellenden Programminstruktionen umfassen Programminstruktionen zu einem Einträgen und Prüfen von Lieferaufträgen, Auftragsbestätigungen und Warenausgangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger sowie zu einem Validieren der Warenlieferung.
Ein Ausführen der Programminstruktionen durch den Prozessor veranlasst den Prozessor dazu, den DLT-Knoten so zu steuern, dass der DLT-Knoten im Zuge eines Initialisierens der Warenlieferung in dem DLT-System Folgendes ausführt:
• Empfangen mindestens eines von einem weiteren DLT-Knoten des Warenempfängers erstellten ersten Datensatzes von dem weiteren DLT-Knoten, wobei der erste Datensatz ein erster Teil eines zwischen dem DLT-Knoten und dem weiteren DLT- Knoten geteilten Datensatzes ist, wobei der erste Datensatz mindestens eine oder mehrere physikalische Eigenschaften der zu liefernden Ware gemäß einer ersten Spezifikation eines Lieferauftrags umfasst, wobei die physikalischen Eigenschaften der ersten Spezifikation zumindest eine zu liefernde Warenmenge umfassen,
• Erstellen eines zweiten durch den DLT-Knoten verwalteten Datensatzes, wobei der zweite Datensatz ein zweiter Teil des geteilten Datensatzes ist, und erstes Aktualisieren des zweiten Datensatzes durch den DLT-Knoten basierend auf dem ersten Datensatz, wobei das erste Aktualisieren ein Einträgen mindestens einer oder mehrerer der physikalischen Eigenschaften der ersten Spezifikation in den zweiten Datensatz umfasst, wobei die mindestens eine oder mehreren eingetragenen physikalischen Eigenschaften der ersten Spezifikation die zu liefernde Warenmenge umfassen, • Empfangen einer Auftragsbestätigung des Warensenders über ein erstes Netzwerk durch den DLT-Knoten, wobei die Auftragsbestätigung eine zweite Spezifikation der eine oder mehreren physikalischen Eigenschaften der zu liefernden Ware umfasst,
• Prüfen der zweiten Spezifikation auf Übereinstimmung mit der ersten Spezifikation unter Verwendung des mindestens einen Smart-Contracts,
• zweites Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten unter Verwendung eines ersten Prüfergebnisses des Prüfens der zweiten Spezifikation,
• Übermitteln mindestens einer ersten Aktualisierungsnachricht von dem DLT-Knoten an den weiteren DLT-Knoten zum Aktualisieren des ersten Datensatzes.
Weitere Ausführungsformen umfassen einen DLT-Knoten, wobei die den mindestens einen Smart-Contract bereitstellenden Programminstruktionen Programminstruktionen zu einem Einträgen und Prüfen von Warenausgangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger umfassen. Das Ausführen der Programminstruktionen durch den Prozessor des DLT-Knotens veranlasst den Prozessor dazu, den DLT-Knoten ferner so zu steuern, dass der DLT-Knoten im Zuge eines Protokollierens der Warenlieferung in dem DLT-System Folgendes ausführt:
• Empfangen eines Warenausgangsprotokolls von dem Warensender über das erste Netzwerk durch den DLT-Knoten, wobei das Warenausgangsprotokoll einen oder mehrere erste Sensorwerte für die eine oder mehreren physikalischen Eigenschaften der ausgehenden Ware gemäß der zweiten Spezifikation umfasst, welche mittels eines oder mehrerer dem Warensender zugeordneter erster physikalischer Sensoren erfasst sind, wobei der eine oder die mehreren ersten Sensorwerte zumindest einen ersten Sensorwert umfassen, welcher die gelieferte Warenmenge quantifiziert,
• Prüfen des einen oder der mehreren ersten Sensorwerte des Warenausgangsprotokolls auf Übereinstimmung mit der einen oder den mehreren physikalischen Eigenschaften der zu liefernden Ware gemäß dem geteilten Datensatz innerhalb vordefinierter erster Toleranzen unter Verwendung des mindestens einen Smart-Contracts, wobei die geprüften ersten Sensorwerte zumindest den die gelieferte Warenmenge quantifizierenden ersten Sensorwert umfassen,
• drittes Aktualisieren des zweiten Datensatzes durch den DLT-Knoten unter Verwendung eines zweiten Prüfergebnisses des Prüfens des einen oder der mehreren ersten Sensorwerte des Warenausgangsprotokolls, Übermitteln mindestens einer zweiten Aktualisierungsnachricht von dem DLT-Knoten an den weiteren DLT-Knoten zum Aktualisieren des ersten Datensatzes.
Weitere Ausführungsformen umfassen einen DLT-Knoten, wobei die den mindestens einen Smart-Contract bereitstellenden Programminstruktionen Programminstruktionen zu einem Validieren der Warenlieferung umfassen. Das Ausführen der Programminstruktionen durch den Prozessor des DLT-Knotens veranlasst den Prozessor dazu, den DLT-Knoten so ferner zu steuern, dass der DLT-Knoten im Zuge eines Validierens der Warenlieferung in dem DLT- System Folgendes ausführt:
• Prüfen von Parametern einer Validierungsnachricht zum Validieren der Warenlieferung durch den DLT-Knoten unter Verwendung des mindestens einen Smart- Contracts, wobei die Parameter zumindest eine zu validierende Warenmenge umfassen, wobei das Prüfen der Parameter ein Prüfen der zu validierenden Warenmenge auf Übereinstimmung mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb einer vordefinierten zweiten Toleranz umfasst,
• bei Übereinstimmung der zu validierenden Warenmenge mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb der vordefinierten zweiten Toleranz, viertes Aktualisieren des zweiten Datensatzes durch den DLT-Knoten, wobei das vierte Aktualisieren ein Registrieren der Validierungsnachricht durch den DLT- Knoten in dem zweiten Datensatz unter Verwendung des mindestens einen Smart- Contracts umfasst,
• Übermitteln mindestens einer dritten Aktualisierungsnachricht von dem DLT-Knoten an den weiteren DLT-Knoten zum Aktualisieren des ersten Datensatzes.
Beispielsweise ist der DLT-Knoten dazu konfiguriert, einen oder mehrere der vorgenannten Verfahrensschritte des dem Warensender zugeordneten DLT-Knoten gemäß einer beispielhaften Ausführungsformen des Verfahrens zur computerimplementierten Kontrolle der Warenlieferung auszuführen. Beispielsweise ist der DLT-Knoten dazu konfiguriert, jeden der vorgenannten Verfahrensschritte des dem Warensender zugeordneten DLT-Knoten gemäß einer beispielhaften Ausführungsformen des Verfahrens zur computerimplementierten Kontrolle der Warenlieferung auszuführen.
Weitere Ausführungsformen umfassen ein DLT-System zur computerimplementierten Kon- trolle einer Warenlieferung von einem Warensender an einen Warenempfänger, welches einen ersten dem Warenempfänger zugeordneten DLT-Knoten und einen zweiten dem Warensender zugeordneten DLT-Knoten umfasst. Der erste DLT-Knoten und der zweite DLT- Knoten werden durch einen oder mehrere DLT-Server des DLT-Systems bereitgestellt. Das DLT-System stellt mindestens einen Smart-Contract bereit. Der mindestens eine Smart- Contract umfasst Programminstruktionen zu einem Einträgen und Prüfen von Lieferaufträgen und Auftragsbestätigungen.
Das DLT-System ist dazu konfiguriert, ein Initialisieren der Warenlieferung in dem DLT- System auszuführen. Das Initialisieren umfasst:
• Empfangen eines Lieferauftrags des Warenempfängers über ein erstes Netzwerk durch den ersten DLT-Knoten über von dem Warensender an den Warenempfänger zu liefernde Ware, wobei der Lieferauftrag eine oder mehrere physikalische Eigenschaften der zu liefernden Ware als eine erste Spezifikation bestimmt, wobei die physikalischen Eigenschaften der ersten Spezifikation zumindest eine zu liefernde Warenmenge umfassen,
• Erstellen eines ersten durch den ersten DLT-Knoten verwalteten Datensatzes und Einträgen mindestens der einen oder mehreren physikalischen Eigenschaften des Lieferauftrags durch den ersten DLT-Knoten in den ersten Datensatz unter Verwendung des mindestens einen Smart-Contracts, wobei der erste Datensatz ein erster Teil eines zwischen dem ersten DLT-Knoten und dem zweiten DLT-Knoten geteilten Datensatzes ist,
• Übermitteln mindestens des ersten Datensatzes von dem ersten DLT-Knoten an den zweiten DLT-Knoten,
• Erstellen eines zweiten durch den zweiten DLT-Knoten verwalteten Datensatzes, wobei der zweite Datensatz ein zweiter Teil des geteilten Datensatzes ist, und erstes Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten basierend auf dem ersten Datensatz, wobei das erste Aktualisieren ein Einträgen mindestens einer oder mehrerer der physikalischen Eigenschaften der ersten Spezifikation in den zweiten Datensatz umfasst, wobei die mindestens eine oder mehreren eingetragenen physikalischen Eigenschaften der ersten Spezifikation die zu liefernde Warenmenge umfassen, • Empfangen einer Auftragsbestätigung des Warensenders über das erste Netzwerk durch den zweiten DLT-Knoten, wobei die Auftragsbestätigung eine zweite Spezifikation der eine oder mehreren physikalischen Eigenschaften der zu liefernden Ware umfasst,
• Prüfen der zweiten Spezifikation auf Übereinstimmung mit der ersten Spezifikation unter Verwendung des mindestens einen Smart-Contracts,
• zweites Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten unter Verwendung eines ersten Prüfergebnisses des Prüfens der zweiten Spezifikation,
• Übermitteln mindestens einer ersten Aktualisierungsnachricht von dem zweiten DLT- Knoten an den ersten DLT-Knoten,
• erstes Aktualisieren des ersten Datensatzes durch den ersten DLT-Knoten unter Verwendung der ersten Aktualisierungsnachricht.
Weitere Ausführungsformen umfassen ein DLT-System, welches ferner dazu konfiguriert ist, ein Protokollieren der Warenlieferung in dem DLT-System auszuführen. Der mindestens eine Smart-Contract umfasst Programminstruktionen zu einem Einträgen und Prüfen von Warenausgangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger. Das Protokollieren umfasst:
• Empfangen eines Warenausgangsprotokolls von dem Warensender über das erste Netzwerk durch den zweiten DLT-Knoten, wobei das Warenausgangsprotokoll einen oder mehrere erste Sensorwerte für die eine oder mehreren physikalischen Eigenschaften der ausgehenden Ware gemäß der zweiten Spezifikation umfasst, welche mittels eines oder mehrerer dem Warensender zugeordneter erster physikalischer Sensoren erfasst sind, wobei der eine oder die mehreren ersten Sensorwerte zumindest einen ersten Sensorwert umfassen, welcher die gelieferte Warenmenge quantifiziert,
• Prüfen des einen oder der mehreren ersten Sensorwerte des Warenausgangsprotokolls auf Übereinstimmung mit der einen oder den mehreren physikalischen Eigenschaften der zu liefernden Ware gemäß dem geteilten Datensatz innerhalb vordefinierter erster Toleranzen unter Verwendung des mindestens einen Smart-Contracts, wobei die geprüften ersten Sensorwerte zumindest den die gelieferte Warenmenge quantifizierenden ersten Sensorwert umfassen, • drittes Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten unter Verwendung eines zweiten Prüfergebnisses des Prüfens des einen oder der mehreren ersten Sensorwerte des Warenausgangsprotokolls,
• Übermitteln mindestens einer zweiten Aktualisierungsnachricht von dem zweiten DLT-Knoten an den ersten DLT-Knoten,
• zweites Aktualisieren des ersten Datensatzes durch den ersten DLT-Knoten unter Verwendung der zweiten Aktualisierungsnachricht.
Weitere Ausführungsformen umfassen ein DLT-System, welches ferner dazu konfiguriert ist, ein Validieren der Warenlieferung in dem DLT-System auszuführen. Der mindestens eine Smart-Contract umfasst Programminstruktionen zu einem Validieren der Warenlieferung. Das Validieren umfasst:
• Prüfen von Parametern einer Validierungsnachricht zum Validieren der Warenlieferung durch den zweiten DLT-Knoten unter Verwendung des mindestens einen Smart- Contracts, wobei die Parameter zumindest eine zu validierende Warenmenge umfassen, wobei das Prüfen der Parameter ein Prüfen der zu validierenden Warenmenge auf Übereinstimmung mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb einer vordefinierten zweiten Toleranz umfasst,
• bei Übereinstimmung der zu validierenden Warenmenge mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb der vordefinierten zweiten Toleranz, viertes Aktualisieren des zweiten Datensatzes durch den zweiten DLT- Knoten, wobei das vierte Aktualisieren ein Registrieren der Validierungsnachricht durch den zweiten DLT-Knoten in dem zweiten Datensatz unter Verwendung des mindestens einen Smart-Contracts umfasst,
• Übermitteln mindestens einer dritten Aktualisierungsnachricht von dem zweiten DLT- Knoten an den ersten DLT-Knoten,
• drittes Aktualisieren des ersten Datensatzes durch den ersten DLT-Knoten unter Verwendung der dritten Aktualisierungsnachricht, wobei das dritte Aktualisieren des ersten Datensatzes ein Registrieren der Validierungsnachricht in dem ersten Datensatz umfasst.
Beispielsweise ist das DLT-System dazu konfiguriert, eine oder mehrere der vorgenannten beispielhaften Ausführungsformen des Verfahrens zur computerimplementierten Kontrolle der Warenlieferung auszuführen. Beispielsweise ist das DLT-System dazu konfiguriert, jeden der vorgenannten beispielhaften Ausführungsformen des Verfahrens zur computerimplementierten Kontrolle der Warenlieferung auszuführen.
Weitere Ausführungsformen umfassen ein Computerprogramm zur Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger unter Verwendung eines zugangsbeschränkten DLT-Systems, welches einen ersten dem Warenempfänger zugeordneten DLT-Knoten und einen zweiten dem Warensender zugeordneten DLT-Knoten umfasst. Das Computerprogramm stellt mindestens einen Smart-Contract bereit. Der mindestens eine Smart-Contract umfasst Programminstruktionen zu einem Einträgen und Prüfen von Lieferaufträgen und Auftragsbestätigungen.
Das Computerprogramm umfasst Programminstruktionen zum Initialisieren der Warenlieferung in dem DLT-System. Das Initialisieren umfasst:
• Empfangen eines Lieferauftrags des Warenempfängers über ein erstes Netzwerk durch den ersten DLT-Knoten über von dem Warensender an den Warenempfänger zu liefernde Ware, wobei der Lieferauftrag eine oder mehrere physikalische Eigenschaften der zu liefernden Ware als eine erste Spezifikation bestimmt, wobei die physikalischen Eigenschaften der ersten Spezifikation zumindest eine zu liefernde Warenmenge umfassen,
• Erstellen eines ersten durch den ersten DLT-Knoten verwalteten Datensatzes und Einträgen mindestens der einen oder mehreren physikalischen Eigenschaften des Lieferauftrags durch den ersten DLT-Knoten in den ersten Datensatz unter Verwendung des mindestens einen Smart-Contracts, wobei der erste Datensatz ein erster Teil eines zwischen dem ersten DLT-Knoten und dem zweiten DLT-Knoten geteilten Datensatzes ist,
• Übermitteln mindestens des ersten Datensatzes von dem ersten DLT-Knoten an den zweiten DLT-Knoten,
• Erstellen eines zweiten durch den zweiten DLT-Knoten verwalteten Datensatzes, wobei der zweite Datensatz ein zweiter Teil des geteilten Datensatzes ist, und erstes Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten basierend auf dem ersten Datensatz, wobei das erste Aktualisieren ein Einträgen mindestens einer oder mehrerer der physikalischen Eigenschaften der ersten Spezifikation in den zwei- ten Datensatz umfasst, wobei die mindestens eine oder mehreren eingetragenen physikalischen Eigenschaften der ersten Spezifikation die zu liefernde Warenmenge umfassen,
• Empfangen einer Auftragsbestätigung des Warensenders über das erste Netzwerk durch den zweiten DLT-Knoten, wobei die Auftragsbestätigung eine zweite Spezifikation der eine oder mehreren physikalischen Eigenschaften der zu liefernden Ware umfasst,
• Prüfen der zweiten Spezifikation auf Übereinstimmung mit der ersten Spezifikation unter Verwendung des mindestens einen Smart-Contracts,
• zweites Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten unter Verwendung eines ersten Prüfergebnisses des Prüfens der zweiten Spezifikation,
• Übermitteln mindestens einer ersten Aktualisierungsnachricht von dem zweiten DLT- Knoten an den ersten DLT-Knoten,
• erstes Aktualisieren des ersten Datensatzes durch den ersten DLT-Knoten unter Verwendung der ersten Aktualisierungsnachricht.
Weitere Ausführungsformen umfassen ein Computerprogramm, welches ferner Programminstruktion zu einem Protokollieren der Warenlieferung in dem DLT-System umfasst. Der mindestens eine Smart-Contract umfasst Programminstruktionen zu einem Einträgen und Prüfen von Warenausgangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger. Das Protokollieren umfasst:
• Empfangen eines Warenausgangsprotokolls von dem Warensender über das erste Netzwerk durch den zweiten DLT-Knoten, wobei das Warenausgangsprotokoll einen oder mehrere erste Sensorwerte für die eine oder mehreren physikalischen Eigenschaften der ausgehenden Ware gemäß der zweiten Spezifikation umfasst, welche mittels eines oder mehrerer dem Warensender zugeordneter erster physikalischer Sensoren erfasst sind, wobei der eine oder die mehreren ersten Sensorwerte zumindest einen ersten Sensorwert umfassen, welcher die gelieferte Warenmenge quantifiziert,
• Prüfen des einen oder der mehreren ersten Sensorwerte des Warenausgangsprotokolls auf Übereinstimmung mit der einen oder den mehreren physikalischen Eigenschaften der zu liefernden Ware gemäß dem geteilten Datensatz innerhalb vordefinierter erster Toleranzen unter Verwendung des mindestens einen Smart-Contracts, wobei die geprüften ersten Sensorwerte zumindest den die gelieferte Warenmenge quantifizierenden ersten Sensorwert umfassen,
• drittes Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten unter Verwendung eines zweiten Prüfergebnisses des Prüfens des einen oder der mehreren ersten Sensorwerte des Warenausgangsprotokolls,
• Übermitteln mindestens einer zweiten Aktualisierungsnachricht von dem zweiten DLT-Knoten an den ersten DLT-Knoten,
• zweites Aktualisieren des ersten Datensatzes durch den ersten DLT-Knoten unter Verwendung der zweiten Aktualisierungsnachricht.
Weitere Ausführungsformen umfassen ein Computerprogramm, welches ferner Programminstruktionen zu einem Validieren der Warenlieferung in dem DLT-System umfasst. Der mindestens eine Smart-Contract umfasst Programminstruktionen zu einem Validieren der Warenlieferung. Das Validieren umfasst:
• Prüfen von Parametern einer Validierungsnachricht zum Validieren der Warenlieferung durch den zweiten DLT-Knoten unter Verwendung des mindestens einen Smart- Contracts, wobei die Parameter zumindest eine zu validierende Warenmenge umfassen, wobei das Prüfen der Parameter ein Prüfen der zu validierenden Warenmenge auf Übereinstimmung mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb einer vordefinierten zweiten Toleranz umfasst,
• bei Übereinstimmung der zu validierenden Warenmenge mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb der vordefinierten zweiten Toleranz, viertes Aktualisieren des zweiten Datensatzes durch den zweiten DLT- Knoten, wobei das vierte Aktualisieren ein Registrieren der Validierungsnachricht durch den zweiten DLT-Knoten in dem zweiten Datensatz unter Verwendung des mindestens einen Smart-Contracts umfasst,
• Übermitteln mindestens einer dritten Aktualisierungsnachricht von dem zweiten DLT- Knoten an den ersten DLT-Knoten,
• drittes Aktualisieren des ersten Datensatzes durch den ersten DLT-Knoten unter Verwendung der dritten Aktualisierungsnachricht, wobei das dritte Aktualisieren des ersten Datensatzes ein Registrieren der Validierungsnachricht in dem ersten Datensatz umfasst. Beispielsweise ist das Computerprogramm dazu konfiguriert, eine oder mehrere der vorgenannten beispielhaften Ausführungsformen des Verfahrens zur computerimplementierten Kontrolle der Warenlieferung auszuführen. Beispielsweise ist das Computerprogramm dazu konfiguriert, jeden der vorgenannten beispielhaften Ausführungsformen des Verfahrens zur computerimplementierten Kontrolle der Warenlieferung auszuführen.
In weiteren Ausführungsformen ist ein computerlesbarer Datenträger oder ein computerlesbares Medium definiert, der/das Programminstruktionen darauf speichert, die, wenn sie von mindestens einem Prozessor (oder mindestens einer elektronischen Vorrichtung) ausgeführt werden, den mindestens einen Prozessor (oder die mindestens eine elektronische Vorrichtung) einrichten, ein Verfahren nach einem der vorstehenden Ausführungsformen auszuführen. Hierbei können die Programminstruktionen den Programminstruktionen des Computerprogramms nach Ausführungsformen entsprechen. Es sollte verständlich sein, dass ferner mehrere Datenträger oder Medien vorgesehen sein können, welche auf einzelnen Prozessoren oder elektronische Vorrichtungen zur Ausführung der vorgesehenen Verfahren einrichten.
Im Weiteren werden Ausführungsformen der Erfindung mit Bezugnahme auf die Zeichnungen näher erläutert. Es zeigen:
Figur 1A ein schematisches Flussdiagramm eines ersten Teils eines exemplarischen Verfahrens zur Kontrolle einer Warenlieferung,
Figur 1 B ein schematisches Flussdiagramm eines zweiten Teils eines exemplarischen Verfahrens zur Kontrolle einer Warenlieferung,
Figur 2 ein schematisches Flussdiagramm eines Protokollierens einer Warenlieferung unter Verwendung eines Wareneingangsprotokolls,
Figur 3 ein schematisches Blockdiagramm eines exemplarischen DLT-Systems zur computerimplementierten Kontrolle einer Warenlieferung,
Figur 4 ein schematisches Ablaufdiagramm eines exemplarischen Verfahrens zur computerimplementierten Kontrolle einer Warenlieferung, Figur 5 ein schematisches Ablaufdiagramm eines exemplarischen Verfahrens zur computerimplementierten Kontrolle einer Warenlieferung,
Figur 6 ein schematisches Ablaufdiagramm eines exemplarischen Verfahrens zur computerimplementierten Kontrolle einer Warenlieferung,
Figur 7 ein schematisches Blockdiagramm eines exemplarischen Systems zur computerimplementierten Kontrolle einer Warenlieferung inklusive elektronischer Zahlungstransaktionen,
Figur 8A einen ersten Teil einer ersten exemplarischen graphischen Benutzeroberfläche,
Figur 8B einen zweiten Teil einer ersten exemplarischen graphischen Benutzeroberfläche, und
Figur 9 eine zweite exemplarische graphische Benutzeroberfläche.
Elemente der nachfolgenden Ausführungsformen, die einander entsprechen, werden mit denselben Bezugszeichen gekennzeichnet.
Figuren 1A und 1 B zeigen ein exemplarisches Verfahren zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger unter Verwendung eines zugangsbeschränkten DLT-Systems. Das DLT-System umfasst einen ersten dem Warenempfänger zugeordneten DLT-Knoten und einen zweiten dem Warensender zugeordneten DLT-Knoten. Ferner stellt das DLT-System mindestens einen Smart-Contract bereit, welcher Programminstruktionen zu einem Einträgen und Prüfen von Lieferaufträgen, Auftragsbestätigungen und/oder Warenausgangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger und/oder zu einem Validieren der Warenlieferungen umfasst.
Das Verfahren umfasst ein Initialisieren der Warenlieferung in dem DLT-System, ein Protokollieren der Warenlieferung in dem DLT-System und ein Validieren der Warenlieferung in dem DLT-System. Das Initialisieren ist in Figur 1A dargestellt, das Protokollieren und Validieren in Figur 1 B.
In Block 200 wird ein Lieferauftrag des Warenempfängers über ein erstes Netzwerk durch den ersten DLT-Knoten empfangen. Bei dem Lieferauftrag handelt es sich um einen Lieferauftrag über von dem Warensender an den Warenempfänger zu liefernde Ware. Der Lieferauftrag bestimmt eine oder mehrere physikalische Eigenschaften der zu liefernden Ware als eine erste Spezifikation, welche zumindest eine zu liefernde Warenmenge umfassen.
In Block 202 wird, beispielsweise infolge eines Empfangs des Lieferauftrags, der erste durch den ersten DLT-Knoten verwaltete Datensatz erstellt. Bei diesem ersten Datensatz handelt es sich um einen ersten Teildatensatz eines geteilten Datensatzes. Bei dem entsprechenden geteilten Datensatz handelt es sich um einen Datensatz, welcher den ersten Teildatensatz auf dem ersten DLT-Knoten und einen zweiten Teildatensatz auf dem zweiten DLT-Knoten umfasst. Eine Berechtigung zur Bearbeitung des ersten Teildatensatzes, d.h. eine Schreibberechtigung, besitzt ausschließlich der erste DLT-Knoten und damit der Warenempfänger, während für den zweiten Datensatz ausschließlich der zweite DLT-Knoten und damit der Warensender eine Berechtigung zur Bearbeitung, d.h. eine Schreibberechtigung, besitzt. Ferner besitzt in Folge der Zugangsbeschränkung des DLT-Systems beispielsweise auch nur der Warenempfänger über den ersten DLT-Knoten eine Leseberechtigung zum Lesen des ersten Teildatensatzes und nur der Warensender eine Leseberechtigung zum Lesen des zweiten Teildatensatzes über den zweiten DLT-Knoten.
Im Zuge des Erstellens des ersten Datensatzes erfolgt ferner ein Einträgen mindestens der einen oder mehreren physikalischen Eigenschaften des Lieferauftrags durch den ersten DLT- Knoten in den ersten Datensatz unter Verwendung des mindestens einen Smart-Contracts. Diese eingetragene eine oder mehreren physikalischen Eigenschaften umfassen zumindest eine zu liefernde Warenmenge.
In Block 204 werden dieser erste Datensatz bzw. die in dem ersten Datensatz eingetragene eine oder mehreren physikalischen Eigenschaften gemäß der ersten Spezifikation des Lieferauftrags an den zweiten DLT-Knoten des Warensenders übermittelt. In Block 206 erstellt der zweite DLT-Knoten den zweiten Teildatensatz des geteilten Datensatzes, in welchen eine oder mehrere physikalische Eigenschaften gemäß der ersten Spezifikation eingetragen werden. Dabei umfassen die eingetragene eine oder mehreren physikalischen Eigenschaften gemäß der ersten Spezifikation zumindest eine zu liefernde Warenmenge. Im Ergebnis umfassen beide Teildatensätze des geteilten Datensatzes somit beispielsweise identische Daten, sofern Einigkeit über die einzelnen Parameter der Spezifikation zwischen dem Warensender und Warenempfänger herrscht, wie nachfolgend ausgeführt.
In Block 208 empfängt der zweite DLT-Knoten eine Auftragsbestätigung des Warensenders über das erste Netzwerk, welche eine zweite Spezifikation der eine oder mehreren physikalischen Eigenschaften der zu liefernden Ware umfasst. Auf einen Empfang einer Auftragsbestätigung hin, erfolgt in Block 210 ein Prüfen der zweiten Spezifikation auf Übereinstimmung mit der ersten Spezifikation durch den zweiten DLT-Knoten unter Verwendung des mindestens einen Smart-Contracts sowie in Block 212 ein Aktualisieren des zweiten Datensatzes unter Verwendung des Prüfergebnisses des Prüfens der zweiten Spezifikation.
Bei einer Übereinstimmung der zweiten Spezifikation mit der ersten Spezifikation umfasst das Aktualisieren des zweiten Datensatzes unter Verwendung des Prüfergebnisses beispielsweise ein Einträgen einer Bestätigung der ersten Spezifikation. Beispielsweise umfasst das Aktualisieren des zweiten Datensatzes unter Verwendung des Prüfergebnisses ein Einträgen der zweiten Spezifikation in Ergänzung zu der ersten Spezifikation in den zweiten Datensatz.
Bei einer Abweichung der zweiten Spezifikation von der ersten Spezifikation umfasst das Aktualisieren des zweiten Datensatzes unter Verwendung des Prüfergebnisses beispielsweise ein Ersetzen bzw. ein Aktualisieren der physikalischen Eigenschaften gemäß der ersten Spezifikation durch die abweichenden physikalischen Eigenschaften gemäß der zweiten Spezifikation. Beispielsweise werden im Zuge des Aktualisierens des zweiten Datensatzes die abweichenden physikalischen Eigenschaften gemäß der zweiten Spezifikation zusätzlich zu der ersten Spezifikation in den zweiten Datensatz eingetragen. Beispielsweise wird die zweite Spezifikation in Ergänzung zu der ersten Spezifikation in den zweiten Datensatz eingetragen.
Ferner wird eine erste Aktualisierungsnachricht in Block 214 von dem zweiten DLT-Knoten an den ersten DLT-Knoten übermittelt. Beispielsweise gibt die erste Aktualisierungsnachricht an, ob die zweite Spezifikation mit der ersten Spezifikation übereinstimmt. Falls eine oder mehrere physikalischen Eigenschaften gemäß der zweiten Spezifikation von der ersten Spezifikation abweichen, identifiziert die erste Aktualisierungsnachricht beispielsweise die abweichende eine oder die abweichenden mehreren physikalischen Eigenschaften gemäß der zweiten Spezifikation. Beispielsweise umfasst die erste Aktualisierungsnachricht die gesamte zweite Spezifikation bzw. eine Kopie der zweiten Spezifikation.
In Block 216 aktualisiert der erste DLT-Knoten den ersten Datensatz, d.h. den ersten Teildatensatz des geteilten Datensatzes, unter Verwendung der ersten Aktualisierungsnachricht. Bei einer Übereinstimmung der zweiten Spezifikation mit der ersten Spezifikation umfasst das Aktualisieren des ersten Datensatzes unter Verwendung der ersten Aktualisierungsnachricht beispielsweise ein Einträgen einer Bestätigung der ersten Spezifikation. Beispielsweise umfasst das Aktualisieren des ersten Datensatzes unter Verwendung der ersten Aktualisierungsnachricht ein Einträgen der zweiten Spezifikation in Ergänzung zu der ersten Spezifikation in den ersten Datensatz.
Bei einer Abweichung der zweiten Spezifikation von der ersten Spezifikation umfasst das Aktualisieren des ersten Datensatzes unter Verwendung der ersten Aktualisierungsnachricht beispielsweise ein Ersetzen bzw. ein Aktualisieren der physikalischen Eigenschaften gemäß der ersten Spezifikation durch die abweichenden physikalischen Eigenschaften gemäß der zweiten Spezifikation. Beispielsweise werden im Zuge des Aktualisierens des ersten Datensatzes die abweichenden physikalischen Eigenschaften gemäß der zweiten Spezifikation zusätzlich zu der ersten Spezifikation in den zweiten Datensatz eingetragen. Beispielsweise wird die zweite Spezifikation in Ergänzung zu der ersten Spezifikation in den zweiten Datensatz eingetragen.
Weicht die zweite Spezifikation von der ersten Spezifikation ab, wird beispielsweise ein Handshake zwischen dem ersten DLT-Knoten und dem zweiten DLT-Knoten zum Abgleich der ersten Spezifikation und der zweiten Spezifikation durchgeführt, sodass die aus dem Abgleich resultierenden ersten und zweiten Spezifikationen übereinstimmen.
Stimmt die zweite Spezifikation mit der ersten Spezifikation überein, wird beispielsweise eine Bestätigungsnachricht von dem zweiten DLT-Knoten an den Warensender über das Netz- werk übermittelt. Eine Übereinstimmung der zweiten Spezifikation mit der ersten Spezifikation liegt beispielsweise bei einer Identität vor. Eine Übereinstimmung der zweiten Spezifikation mit der ersten Spezifikation liegt beispielsweise vor, wenn keine Abweichungen auftreten, welche einen vordefinierten Toleranzbereich überschreiten. Die Bestätigungsnachricht zeigt dem Warensender beispielsweise an, dass eine Einigung über die entsprechende Warenlieferung zwischen Warenempfänger und Warensender erzielt wurde. Ferner umfasst die Bestätigungsnachricht beispielsweise die Spezifikation der entsprechenden Warenlieferung. Beispielsweise dient die entsprechende Bestätigungsnachricht als Trigger zum Initiieren der entsprechenden Warenlieferung.
Jeder der Schritte 200 bis 216 des Verfahrens gemäß Figur 1A kann optional sein.
Das Verfahren aus Figur 1A wird vorzugsweise in Figur 1 B mit einem Protokollieren der Warenlieferung in dem DLT-System fortgesetzt. Wird die physische Warenlieferung ausgeführt, d.h. verlässt die zu liefernde Ware ein Lager des Warensenders, wird ein Warenausgangsprotokoll erstellt. Das entsprechende Warenausgangsprotokoll umfasst einen oder mehrere Sensorwerte für die eine oder mehreren physikalischen Eigenschaften der ausgehenden Ware gemäß der zweiten Spezifikation, welche mittels eines oder mehrerer dem Warensender zugeordneter physikalischer Sensoren erfasst sind. Das Warenausgangsprotokoll gibt also für eine oder mehrere physikalische Eigenschaften, für welche in der zweiten Spezifikation Zielwerte angegeben werden, jeweils sensorisch erfasste Messwerte an, welche den tatsächlichen Zustand der ausgehenden Ware im Hinblick auf die entsprechenden physikalischen Eigenschaften wiedergeben. Die entsprechenden Sensorwerte umfassen dabei zumindest einen Sensorwert, welcher die gelieferte, d.h. ausgehende, Warenmenge quantifiziert.
In Block 220 empfängt der zweite DLT-Knoten des Warensenders das Warenausgangsprotokoll von dem Warensender über das erste Netzwerk und prüft in Block 222 den einen oder die mehreren ersten Sensorwerte des Warenausgangsprotokolls auf Übereinstimmung mit der einen oder den mehreren physikalischen Eigenschaften der zu liefernden Ware. Hierbei wird geprüft, ob der eine oder die mehreren Sensorwerte des Warenausgangsprotokolls mit einer oder mehreren physikalischen Eigenschaften gemäß dem geteilten Datensatz innerhalb vordefinierter Toleranzen übereinstimmen. Liegt keine solche Übereinstimmung vor, wird bei- spielsweise ein Warnhinweis an den Warensender und/oder den Warenempfänger übermittelt. Ein solcher Warnhinweis kann beispielsweise bei einer zu geringen Liefermenge eine Nachlieferung seitens des Warensenders triggern. Seitens des Warenempfängers kann ein solcher Warnhinweis beispielsweise eine Überprüfung der abweichenden physikalischen Eigenschaften bei Ankunft der Ware triggern. Beispielsweise kann ein solcher Warnhinweis eine Bestätigung der abweichenden physikalischen Eigenschaften seitens des Warenempfängers für eine erfolgreiche abschließende Validierung der Warenlieferung erforderlich machen.
In Block 224 wird der zweite Datensatzes durch den zweiten DLT-Knoten unter Verwendung des Ergebnisses der Prüfung des einen oder der mehreren ersten Sensorwerte des Warenausgangsprotokolls aktualisiert. Beispielsweise umfasst die Aktualisierung ein Einträgen des Warenausgangsprotokolls und/oder ein oder mehrerer der von dem Warenausgangsprotokoll angegebenen Sensorwerte. Beispielsweise werden alle von dem Warenausgangsprotokoll angegebenen Sensorwerte eingetragen. Beispielsweise werden nur solche Sensorwerte eingetragen, welche von den in dem zweiten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware abweichen. Beispielsweise werden für Sensorwerte des Warenausgangsprotokolls, welche mit den in dem zweiten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware übereinstimmen, nur eine Bestätigung in den zweiten Datensatz eingetragen, dass die entsprechenden Werte für die physikalischen Eigenschaften mit den erfassten Sensorwerten übereinstimmen.
In Block 226 wird eine zweite Aktualisierungsnachricht von dem zweiten DLT-Knoten an den ersten DLT-Knoten übermittelt. Die zweite Aktualisierungsnachricht umfasst beispielsweise das Warenausgangsprotokoll und/oder ein oder mehrerer der von dem Warenausgangsprotokoll angegebenen Sensorwerte. Beispielsweise umfasst die zweite Aktualisierungsnachricht alle von dem Warenausgangsprotokoll angegebenen Sensorwerte. Beispielsweise umfasst die zweite Aktualisierungsnachricht nur solche Sensorwerte, welche von den in dem zweiten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware abweichen. Beispielsweise umfasst die zweite Aktualisierungsnachricht für Sensorwerte des Warenausgangsprotokolls, welche mit den in dem zweiten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware übereinstimmen, nur eine Bestätigung, dass die entsprechenden Werte für die physikalischen Eigenschaften gemäß dem geteilten Datensatz mit den erfassten Sensorwerten übereinstimmen. In Block 228 aktualisiert der erste DLT-Knoten den ersten Datensatz, d.h. den ersten Teildatensatz des geteilten Datensatzes, unter Verwendung der zweiten Aktualisierungsnachricht. Beispielsweise umfasst die Aktualisierung ein Einträgen des Warenausgangsprotokolls und/oder ein oder mehrerer der von dem Warenausgangsprotokoll angegebenen Sensorwerte. Beispielsweise werden alle von dem Warenausgangsprotokoll angegebenen Sensorwerte eingetragen. Beispielsweise werden nur solche Sensorwerte eingetragen, welche von den in dem ersten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware abweichen. Beispielsweise werden für Sensorwerte des Warenausgangsprotokolls, welche mit den in dem ersten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware übereinstimmen, nur eine Bestätigung in den ersten Datensatz eingetragen, dass die entsprechenden Werte für die physikalischen Eigenschaften mit den erfassten Sensorwerten übereinstimmen.
Schließlich wird eine Validierung der Warenlieferung in dem DLT-System ausgeführt. Hierzu werden in Block 240 Parameter einer Validierungsnachricht zum Validieren der Warenlieferung durch den zweiten DLT-Knoten geprüft. Die geprüften Parameter der Validierungsnachricht umfassen zumindest eine zu validierende Angabe der gelieferten Warenmenge. Das Prüfen der entsprechenden Parameter umfasst ein Prüfen der zu validierenden Warenmenge auf Übereinstimmung mit dem die gelieferte Warenmenge quantifizierenden Sensorwert gemäß dem Warenausgangsprotokoll innerhalb einer vordefinierten Toleranz. Bei Übereinstimmung der zu validierenden Warenmenge mit dem die gelieferte Warenmenge quantifizierenden Sensorwert innerhalb der vordefinierten Toleranz, erfolgt in Block 242 ein Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten unter Verwendung der Validierungsnachricht. Das Aktualisieren umfasst ein Registrieren der Validierungsnachricht durch den zweiten DLT-Knoten in dem zweiten Datensatz. Beispielsweise wird in Zuge der Registrierung ein Identifikator der Validierungsnachricht in den zweiten Datensatz eingetragen. Beispielsweise wird eine Prüfwert, etwa ein Hash-Wert, der Validierungsnachricht in den zweiten Datensatz eingetragen. Beispielsweise werden ein oder mehrere Parameter der Validierungsnachricht in den zweiten Datensatz eingetragen. Beispielsweise wird die Validierungsnachricht in den zweiten Datensatz eingetragen.
Beispielsweise wird das Validieren durch einen Empfang der Validierungsnachricht oder durch ein Erzeugen der Validierungsnachricht getriggert. Beispielsweise wird ein Erzeugen der Validierungsnachricht durch einen Empfang einer Empfangsbestätigung der gelieferten Ware von dem Warenempfänger getriggert. Beispielsweise wird eine Empfangsbestätigung in Form eines Wareneingangsprotokolls empfangen.
In Block 244 wird von dem zweiten DLT-Knoten eine dritte Aktualisierungsnachricht an den ersten DLT-Knoten übermittelt. Die dritte Aktualisierungsnachricht umfasst beispielsweise die im Zuge der Aktualisierung in den zweiten Datensatz eingetragenen Daten der Validierungsnachricht. Die dritte Aktualisierungsnachricht umfasst beispielsweise den vollständigen aktualisierten zweiten Datensatz. Die dritte Aktualisierungsnachricht umfasst beispielsweise die Validierungsnachricht.
In Block 246 aktualisiert der erste DLT-Knoten den ersten Datensatz unter Verwendung der dritten Aktualisierungsnachricht des zweiten Datensatzes. Das Aktualisieren des ersten Datensatzes umfasst dabei ein Registrieren der Validierungsnachricht in dem ersten Datensatz. Beispielsweise wird in Zuge der Registrierung ein Identifikator der Validierungsnachricht in den ersten Datensatz eingetragen. Beispielsweise wird eine Prüfwert, etwa ein Hash-Wert, der Validierungsnachricht in den ersten Datensatz eingetragen. Beispielsweise werden ein oder mehrere Parameter der Validierungsnachricht in den ersten Datensatz eingetragen. Beispielsweise wird die Validierungsnachricht in den ersten Datensatz eingetragen.
Jeder der Schritte 220 bis 246 des Verfahrens gemäß Figur 1 B kann optional sein. Ferner können die Schritte 220 bis 246 beliebig mit einem oder mehreren der Schritte 200 bis 216 gemäß Figur 1A und in beliebiger Reihenfolge kombiniert werden.
Figur 2 zeigt ein exemplarisches Protokollieren einer Warenlieferung unter Verwendung eines Wareneingangsprotokolls. Hierzu sind die von dem mindestens einen Smart-Contract umfassten Programminstruktionen ferner zu einem Einträgen und Prüfen von Wareneingangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger konfiguriert.
Wird die physische Warenlieferung von dem Warenempfänger empfangen, d.h. erreicht die zu liefernde Ware ein Lager des Warenempfängers, wird ein Wareneingangsprotokoll erstellt. Das entsprechende Wareneingangsprotokoll umfasst einen oder mehrere Sensorwerte für die eine oder mehreren physikalischen Eigenschaften der eingehenden Ware gemäß der ersten Spezifikation, welche mittels einen oder mehrerer dem Warenempfänger zugeordneten physikalischen Sensoren erfasst sind. Das Wareneingangsprotokoll gibt also für eine oder mehrere physikalische Eigenschaften, für welche in der ersten Spezifikation Zielwerte angegeben werden, jeweils sensorisch erfasste Messwerte an, welche den tatsächlichen Zustand der eingehenden Ware im Hinblick auf die entsprechenden physikalischen Eigenschaften wiedergeben. Die entsprechenden Sensorwerte umfassen dabei zumindest einen Sensorwert, welcher die gelieferte, d.h. eingehende Warenmenge quantifiziert.
Das Protokollieren der Warenlieferung in dem DLT-System gemäß Figur 1 B umfasst in diesem Fall Block 230. In Block 230 empfängt der erste DLT-Knoten ein Wareneingangsprotokoll von dem Warenempfänger über das erste Netzwerk. Ferner prüft der erste DLT-Knoten der eine oder die mehreren zweiten Sensorwerte des Wareneingangsprotokolls auf Übereinstimmung mit der einen oder den mehreren physikalischen Eigenschaften der zu liefernden Ware. Hierbei wird geprüft, ob der eine oder die mehreren Sensorwerte des Wareneingangsprotokolls mit einer oder mehreren physikalischen Eigenschaften gemäß dem geteilten Datensatz innerhalb vordefinierter Toleranzen übereinstimmen. Liegt keine solche Übereinstimmung vor, wird beispielsweise ein Warnhinweis an den Warenempfänger und/oder den Warensender übermittelt. Ein solcher Warnhinweis kann beispielsweise bei einer zu geringen Liefermenge eine Nachlieferung seitens des Warensenders triggern. Seitens des Warenempfängers kann ein solcher Warnhinweis beispielsweise eine Bestätigung der abweichenden physikalischen Eigenschaften seitens des Warenempfängers für eine erfolgreiche abschließende Validierung der Warenlieferung erforderlich machen.
In Block 232 wird der erste Datensatz durch den ersten DLT-Knoten unter Verwendung des Ergebnisses der Prüfung des einen oder der mehreren ersten Sensorwerte des Wareneingangsprotokolls aktualisiert. Beispielsweise umfasst die Aktualisierung ein Einträgen des Wareneingangsprotokolls und/oder ein oder mehrerer der von dem Wareneingangsprotokoll angegebenen Sensorwerte. Beispielsweise werden alle von dem Wareneingangsprotokoll angegebenen Sensorwerte eingetragen. Beispielsweise werden nur solche Sensorwerte eingetragen, welche von den in dem ersten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware abweichen. Beispielsweise werden für Sensorwerte des Wareneingangsprotokolls, welche mit den in dem ersten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware übereinstimmen, nur eine Bestätigung in den zweiten Datensatz eingetragen, dass die entsprechenden Werte für die physikalischen Eigenschaften mit den erfassten Sensorwerten übereinstimmen.
Ferner wird in Block 234 eine vierte Aktualisierungsnachricht von dem ersten DLT-Knoten an den zweiten DLT-Knoten übermittelt. Die vierte Aktualisierungsnachricht umfasst beispielsweise das Wareneingangsprotokoll und/oder ein oder mehrerer der von dem Wareneingangsprotokoll angegebenen Sensorwerte. Beispielsweise umfasst die vierte Aktualisierungsnachricht alle von dem Wareneingangsprotokoll angegebenen Sensorwerte. Beispielsweise umfasst die vierte Aktualisierungsnachricht nur solche Sensorwerte, welche von den in dem ersten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware abweichen. Beispielsweise umfasst die vierte Aktualisierungsnachricht für Sensorwerte des Wareneingangsprotokolls, welche mit den in dem ersten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware übereinstimmen, nur eine Bestätigung, dass die entsprechenden Werte für die physikalischen Eigenschaften gemäß dem geteilten Datensatz mit den erfassten Sensorwerten übereinstimmen.
Schließlich aktualisiert der zweite DLT-Knoten in Block 236 den zweiten Datensatz, d.h. den zweiten Teildatensatz des geteilten Datensatzes, unter Verwendung der vierten Aktualisierungsnachricht. Beispielsweise umfasst die Aktualisierung ein Einträgen des Wareneingangsprotokolls und/oder ein oder mehrerer der von dem Wareneingangsprotokoll angegebenen Sensorwerte. Beispielsweise werden alle von dem Wareneingangsprotokoll angegebenen Sensorwerte eingetragen. Beispielsweise werden nur solche Sensorwerte eingetragen, welche von den in dem zweiten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware abweichen. Beispielsweise werden für Sensorwerte des Wareneingangsprotokolls, welche mit den in dem zweiten Datensatz eingetragenen Werten für die physikalischen Eigenschaften der zu liefernden Ware übereinstimmen, nur eine Bestätigung in den zweiten Datensatz eingetragen, dass die entsprechenden Werte für die physikalischen Eigenschaften mit den erfassten Sensorwerten übereinstimmen.
Jeder der Schritte 230 bis 236 des Verfahrens gemäß Figur 2 kann optional sein. Ferner können die Schritte 230 bis 236 beliebig mit einem oder mehreren der Schritte 200 bis 216 gemäß Figur 1A und oder einem oder mehreren der Schritte 220 bis 246 gemäß Figur 1 B und in beliebiger Reihenfolge kombiniert werden. Figur 3 zeigt ein exemplarisches DLT-System 182 zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger. Das DLT-System 182 umfasst eine Mehrzahl von DLT-Servern 140, 160. Dabei umfasst das DLT-System 182 einen ersten dem Warenempfänger zugeordneten DLT-Knoten, welcher von einem ersten DLT-Server 140 des DLT-Systems 182 bereitgestellt wird. Zudem umfasst das DLT-System 182 einen zweiten dem Warensender zugeordneten DLT-Knoten, welcher von einem zweiten DLT-Server 160 des DLT-Systems 182 bereitgestellt wird. Es sollte jedoch verständlich sein, dass die DLT-Knoten auch auf einem einzelnen DLT-Server, bspw. DLT-Server 140 oder DLT-Server 160, bereitgestellt werden können und die vorliegende Beschreibung ist nicht auf ein Bereitstellen von DLT-Knoten auf separaten DLT-Servern beschränkt.
Der erste DLT-Server 140 umfasst einen Prozessor 142, welcher dazu konfiguriert ist, Programminstruktionen 144 auszuführen. Durch die Programminstruktionen 144 wird auf dem ersten DLT-Server 140 der erste DLT-Knoten des Warenempfängers implementiert. Dabei implementieren die Programminstruktionen 144 einen oder mehrere Smart-Contracts zur Ausführung durch den ersten DLT-Knoten auf dem ersten DLT-Server 140. Die Programminstruktionen 144, welche den einen oder die mehreren Smart-Contracts implementieren, umfassen Programminstruktionen zum Ausführen eines Verfahrens, beispielsweise des Verfahrens gemäß Figuren 1A und/oder 1 B oder Teilen davon, zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger unter Verwendung des zugangsbeschränkten DLT-Systems 182. Das Verfahren kann ein Einträgen und Prüfen von Lieferaufträgen, Auftragsbestätigungen und/oder Warenausgangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger und/oder ein Validieren der Warenlieferungen, in beliebiger Kombination, umfassen.
Ferner verfügt der erste DLT-Server 140 über einen Speicher 146 sowie eine Kommunikationsschnittstelle 156. Die Kommunikationsschnittstelle 156 ist dazu konfiguriert, dass der erste DLT-Server 140 über ein Netzwerk 184 beispielsweise mit einem Computersystem 120 des Warenempfängers kommunizieren kann. Bei dem Netzwerk 184 handelt es sich beispielsweise um das Internet. Ferner ist die Kommunikationsschnittstelle 156 beispielsweise zu einer Kommunikation über ein DLT-Netzwerk 180 mit anderen DLT-Servern des DLT- Systems, etwa mit dem zweiten DLT-Server 160, auf welchem der DLT-Knoten des Warensenders implementiert ist. Das DLT-Netzwerk 180 kann beispielsweise von dem Netzwerk 184 umfasst sein. Beispielsweise handelt es sich bei dem DLT-Netzwerk 180 um ein eigenständiges Netzwerk, etwa ein Intranet.
Beispielsweise ist in einem geschützten Speicherbereich 152 des Speichers 146 des ersten DLT-Servers 140 ein dem ersten DLT-Knoten des Warenempfängers zugeordneter privater kryptographischer Schlüssel 154 eines asymmetrischen Schlüsselpaars gespeichert. Dieser private kryptographische Schlüssel 154 dient beispielsweise als Signaturschlüssel zum Erstellen elektronischer Signaturen des ersten DLT-Knoten. Entsprechende Signaturen können mit einem öffentlichen kryptographischen Schlüssel 150 des entsprechenden asymmetrischen Schlüsselpaars geprüft werden. Beispielsweise wird der öffentliche kryptographische Schlüssel 150 als Bestandteil eines Zertifikates bereitgestellt. Diesen öffentlichen kryptographischen Schlüssel 150 bzw. das den öffentlichen kryptographischen Schlüssel 150 umfassende Zertifikat stellt der erste DLT-Knoten des Warenempfängers anderen DLT-Knoten, etwa dem zweiten DLT-Knoten des Warensenders, als Signaturprüfschlüssel zur Verfügung.
Der zweiten DLT-Server 160 umfasst einen Prozessor 162, welcher dazu konfiguriert ist, Programminstruktionen 164 auszuführen. Durch die Programminstruktionen 164 wird auf dem zweiten DLT-Server 160 der zweite DLT-Knoten des Warensenders implementiert. Dabei implementieren die Programminstruktionen 164 auch auf dem zweiten DLT-Server 160 einen oder mehrere Smart-Contracts zur Ausführung durch den zweiten DLT-Knoten. Die Smart- Contracts auf dem zweiten DLT-Knoten können den Smart-Contracts auf dem ersten DLT- Knoten entsprechen, sodass sichergestellt ist, dass beide DLT-Knoten ein sich entsprechendes Verhalten definieren. Die Programminstruktionen 164, welche den einen oder die mehreren Smart-Contracts implementieren, umfassen Programminstruktionen zum Ausführen eines Verfahrens, beispielsweise des Verfahrens gemäß Figuren 1A und/oder 1 B oder Teilen davon, zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger unter Verwendung des zugangsbeschränkten DLT-Systems 182. Das Verfahren kann ein Einträgen und Prüfen von Lieferaufträgen, Auftragsbestätigungen und/oder Warenausgangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger und/oder ein Validieren der Warenlieferungen, in beliebiger Kombination, umfassen.
Ferner verfügt der zweite DLT-Server 160 über einen Speicher 166 sowie eine Kommunikationsschnittstelle 176. Die Kommunikationsschnittstelle 176 ist dazu konfiguriert, dass der erste DLT-Server 160 über das Netzwerk 184 beispielsweise mit einem Computersystem 100 des Warensenders kommunizieren kann. Ferner ist die Kommunikationsschnittstelle 176 beispielsweise zu einer Kommunikation über das DLT-Netzwerk 180 mit anderen DLT-Servern des DLT-Systems, etwa mit dem ersten DLT-Server 140, auf welchem der DLT-Knoten des Warensenders implementiert ist.
Beispielsweise ist in einem geschützten Speicherbereich 172 des Speichers 166 des zweiten DLT-Servers 160 ein dem zweiten DLT-Knoten des Warensenders zugeordneter privater kryptographischer Schlüssel 174 eines asymmetrischen Schlüsselpaars gespeichert. Dieser private kryptographische Schlüssel 174 dient beispielsweise als Signaturschlüssel zum Erstellen elektronischer Signaturen des zweiten DLT-Knoten. Entsprechende Signaturen können mit einem öffentlichen kryptographischen Schlüssel 170 des entsprechenden asymmetrischen Schlüsselpaars geprüft werden. Beispielsweise wird der öffentliche kryptographische Schlüssel 170 als Bestandteil eines Zertifikates bereitgestellt. Diesen öffentlichen kryptographischen Schlüssel 170 bzw. das den öffentlichen kryptographischen Schlüssel 170 umfassende Zertifikat stellt der erste DLT-Knoten des Warensenders anderen DLT-Knoten, etwa dem ersten DLT-Knoten des Warenempfängers, als Signaturprüfschlüssel zur Verfügung.
Im Zuge des Initialisierens der Warenlieferung wird auf den beiden DLT-Knoten ein geteilter Datensatz erzeugt, welcher einen ersten Teildatensatz 148 auf dem ersten DLT-Knoten sowie einen zweiten Teildatensatz 168 auf dem zweiten DLT-Knoten umfasst. Der erste Teildatensatz 148 ist in dem Speicher 146 des ersten DLT-Servers 140 gespeichert. Der zweite Teildatensatz 168 ist in dem Speicher 166 des zweiten DLT-Servers 160 gespeichert.
Eine Berechtigung zur Bearbeitung des ersten Teildatensatzes, d.h. eine Schreibberechtigung, besitzt ausschließlich der erste DLT-Knoten und damit der Warenempfänger, während für den zweiten Datensatz ausschließlich der zweite DLT-Knoten und damit der Warensender eine Berechtigung zur Bearbeitung, d.h. eine Schreibberechtigung, besitzt. Ferner besitzt in Folge der Zugangsbeschränkung des DLT-Systems beispielsweise auch nur der Warenempfänger über den auf dem ersten DLT-Server 140 implementierten ersten DLT-Knoten eine Leseberechtigung zum Lesen des ersten Teildatensatzes und nur der Warensender eine Leseberechtigung zum Lesen des zweiten Teildatensatzes über den auf dem zweiten DLT- Server 160 implementierten zweiten DLT-Knoten. Ein Ausführen der Programminstruktionen 144 durch den Prozessor 142 veranlasst den Prozessor 142 dazu, den ersten DLT-Server 140 so zu steuern, dass der auf dem ersten DLT- Server 140 implementierte erste DLT-Knoten im Zuge eines Initialisierens der Warenlieferung in dem DLT-System 182 einen Lieferauftrag des Warenempfängers über von dem Warensender an den Warenempfänger zu liefernde Ware zu empfangen. Den Lieferauftrag empfängt der erste DLT-Knoten beispielsweise über das Netzwerk 184 von einem Computersystem 120 des Warenempfängers. Der Lieferauftrag bestimmt eine oder mehrere physikalische Eigenschaften der zu liefernden Ware als eine erste Spezifikation. Dabei umfassen die physikalischen Eigenschaften der ersten Spezifikation zumindest eine zu liefernde Warenmenge.
Das Computersystem 120 des Warenempfängers umfasst einen Prozessor 130, welcher dazu konfiguriert ist, Programminstruktionen 132 auszuführen. Durch die Programminstruktionen 132 wird das Computersystem 120 dazu veranlasst, beispielsweise über das Netzwerk 184 mit dem ersten DLT-Server 140 bzw. dem auf dem ersten DLT-Server 140 implementierten ersten DLT-Knoten des Warenempfängers zu kommunizieren. Beispielsweise sendet das Computersystem 120 des Warenempfängers dem ersten DLT-Knoten den Lieferauftrag zu. Zu diesem Zweck umfasst das Computersystem 120 eine Kommunikationsschnittstelle 136 zur Kommunikation über das Netzwerk 184.
Ferner verfügt das Computersystem 120 über einen Speicher 122. Beispielsweise ist in einem geschützten Speicherbereich 126 des Speichers 122 des Computersystems 120 ein dem Warenempfänger zugeordneter privater kryptographischer Schlüssel 128 eines asymmetrischen Schlüsselpaars gespeichert. Dieser private kryptographische Schlüssel 128 dient beispielsweise als Signaturschlüssel zum Erstellen elektronischer Signaturen des Warenempfängers. Entsprechende Signaturen können mit einem öffentlichen kryptographischen Schlüssel 124 des entsprechenden asymmetrischen Schlüsselpaars geprüft werden. Beispielsweise wird der öffentliche kryptographische Schlüssel 124 als Bestandteil eines Zertifikates bereitgestellt. Diesen öffentlichen kryptographischen Schlüssel 124 bzw. das den öffentlichen kryptographischen Schlüssel 124 umfassende Zertifikat stellt das Computersystem 120 anderen Beteiligten, etwa dem auf dem ersten DLT-Server 140 implementierten ersten DLT-Knoten des Warenempfängers, als Signaturprüfschlüssel zur Verfügung. Der erste Knoten erstellt den durch den DLT-Knoten verwalteten Datensatzes 148 und trägt mindestens die eine oder die mehreren physikalischen Eigenschaften des Lieferauftrags in den ersten Datensatz 148 ein unter Verwendung des mindestens einen Smart-Contracts.
Ferner wird mindestens des ersten Datensatzes 148 von dem ersten DLT-Knoten bzw. dem ersten DLT-Server 140 über das DLT-Netzwerk 180 an den auf dem zweiten DLT-Server 160 implementierten zweiten DLT-Knoten gesendet. Der erste DLT-Knoten empfängt über das DLT-Netzwerk 180 von dem zweiten DLT-Knoten bzw. dem zweiten DLT-Server 160 mindestens einer ersten Aktualisierungsnachricht über eine Aktualisierung des zweiten Datensatzes 168 auf dem zweiten DLT-Server. Die Aktualisierung erfolgte unter Verwendung eines ersten Prüfergebnisses einer Prüfung einer zweiten Spezifikation der einen oder mehreren physikalischen Eigenschaften der zu liefernden Ware gemäß einer Auftragsbestätigung des Warensenders auf Übereinstimmung mit der ersten Spezifikation gemäß Lieferauftrag des Warenempfängers. Der erste Datensatz 148 wird dann durch den ersten DLT-Knoten unter Verwendung der ersten Aktualisierungsnachricht aktualisiert.
Die entsprechende Auftragsbestätigung empfängt der zweite DLT-Server 160 beispielsweise über das Netzwerk 184 von einem Computersystem 100 des Warensenders. Das Computersystem 160 des Warenempfängers umfasst einen Prozessor 110, welcher dazu konfiguriert ist, Programminstruktionen 112 auszuführen. Durch die Programminstruktionen 112 wird das Computersystem 100 dazu veranlasst, beispielsweise über das Netzwerk 184 mit dem zweiten DLT-Server 160 bzw. dem auf dem zweiten DLT-Server 160 implementierten zweiten DLT-Knoten des Warensenders zu kommunizieren. Beispielsweise sendet das Computersystem 100 des Warensenders dem zweiten DLT-Knoten die Auftragsbestätigung zu. Zu diesem Zweck umfasst das Computersystem 100 eine Kommunikationsschnittstelle 116 zur Kommunikation über das Netzwerk 184.
Ferner verfügt das Computersystem 100 über einen Speicher 102. Beispielsweise ist in einem geschützten Speicherbereich 106 des Speichers 102 des Computersystems 100 ein dem Warenempfänger zugeordneter privater kryptographischer Schlüssel 108 eines asymmetrischen Schlüsselpaars gespeichert. Dieser private kryptographische Schlüssel 108 dient beispielsweise als Signaturschlüssel zum Erstellen elektronischer Signaturen des Warensenders. Entsprechende Signaturen können mit einem öffentlichen kryptographischen Schlüssel 104 des entsprechenden asymmetrischen Schlüsselpaars geprüft werden. Beispielsweise wird der öffentliche kryptographische Schlüssel 104 als Bestandteil eines Zertifikates bereitgestellt. Diesen öffentlichen kryptographischen Schlüssel 104 bzw. das den öffentlichen kryptographischen Schlüssel 104 umfassende Zertifikat stellt das Computersystem 100 anderen Beteiligten, etwa dem auf dem zweiten DLT-Server 160 implementierten zweiten DLT-Knoten des Warensenders, als Signaturprüfschlüssel zur Verfügung.
Ferner veranlasst das Ausführen der Programminstruktionen durch den Prozessor 142 den Prozessor 142 dazu, den ersten DLT-Knoten so zu steuern, dass der DLT-Knoten im Zuge eines Protokollierens der Warenlieferung in dem DLT-System 182 mindestens eine zweiten Aktualisierungsnachricht von dem zweiten DLT-Knoten über eine Aktualisierung des zweiten Datensatzes 168 empfängt. Bei dieser zweiten Aktualisierung handelt es sich um eine Aktualisierung unter Verwendung eines zweiten Prüfergebnisses einer Prüfung eines oder mehrerer erster Sensorwerte eines Warenausgangsprotokolls auf Übereinstimmung mit der einen oder den mehreren physikalischen Eigenschaften der zu liefernden Ware gemäß dem geteilten Datensatz innerhalb vordefinierter erster Toleranzen. Dieser eine oder diese mehreren ersten Sensorwerte des Warenausgangsprotokolls sind mittels eines oder mehrerer dem Warensender zugeordneter physikalischer Sensoren 113 erfasst. Dabei umfassen die geprüften ersten Sensorwerte zumindest den die gelieferte Warenmenge quantifizierenden ersten Sensorwert umfassen. Der erste Datensatz 148 wird dann durch den DLT-Knoten unter Verwendung der zweiten Aktualisierungsnachricht aktualisiert.
Schließlich veranlasst das Ausführen der Programminstruktionen 144 durch den Prozessor 142 den Prozessor 142 dazu, den ersten DLT-Knoten so zu steuern, dass der erste DLT- Knoten im Zuge eines Validierens der Warenlieferung in dem DLT-System 182 mindestens einer dritten Aktualisierungsnachricht von dem zweiten DLT-Knoten über eine Aktualisierung des zweiten Datensatzes 168 unter Verwendung einer Validierungsnachricht empfängt. Die Aktualisierung des zweiten Datensatzes 168 unter Verwendung der Validierungsnachricht umfasst eine Registrierung der Validierungsnachricht in dem zweiten Datensatz 168. Dabei bestätigt die Aktualisierung des zweiten Datensatzes 168 unter Verwendung der Validierungsnachricht eine erfolgreiche Prüfung von Parametern der Validierungsnachricht durch den zweiten DLT-Knoten. Diese Parameter umfassen zumindest eine zu validierende Warenmenge. Dabei umfasst das Prüfen der Parameter ein Prüfen der zu validierenden Warenmenge auf Übereinstimmung mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb einer vordefinierten zweiten Toleranz. Schließlich aktualisiert der erste DLT-Knoten den ersten Datensatz 148 durch den DLT-Knoten unter Verwendung der dritten Aktualisierungsnachricht. Das Aktualisieren des ersten Datensatzes 148 umfasst dabei ein Registrieren der Validierungsnachricht in dem ersten Datensatz 148.
Ein Ausführen der Programminstruktionen 164 durch den Prozessor 162 veranlasst den Prozessor 162 dazu, den zweiten DLT-Server 160 so zu steuern, dass der auf dem zweiten DLT- Server 160 implementierte zweite DLT-Knoten im Zuge eines Initialisierens der Warenlieferung in dem DLT-System 182 mindestens den von dem ersten DLT-Knoten des Warenempfängers erstellten ersten Datensatzes 148 empfängt, welcher mindestens die eine oder mehrere physikalische Eigenschaften der zu liefernden Ware gemäß der ersten Spezifikation des Lieferauftrags umfasst. Der zweite DLT-Knoten erstellt daraufhin den zweiten durch den DLT- Knoten verwalteten Datensatz 168. Ferner aktualisiert der zweite DLT-Knoten den erstellten zweiten Datensatzes 168. Das Aktualisieren umfasst ein Einträgen mindestens einer oder mehrerer physikalischer Eigenschaften der ersten Spezifikation in den zweiten Datensatz 168, welche mindestens eine oder mehrere eingetragene physikalische Eigenschaften der ersten Spezifikation die zu liefernde Warenmenge umfassen.
Ferner empfängt der zweite DLT-Knoten über das Netzwerk 184 von dem Computersystem 100 des Warensenders die Auftragsbestätigung des Warensenders. Die Auftragsbestätigung umfasst die zweite Spezifikation der eine oder mehreren physikalischen Eigenschaften der zu liefernden Ware. Der zweite DLT-Knoten prüft die zweite Spezifikation auf Übereinstimmung mit der ersten Spezifikation unter Verwendung des einen oder der mehreren Smart- Contracts und aktualisiert den zweiten Datensatz 168 unter Verwendung des resultierenden Prüfergebnisses. Schließlich übermittelt der zweite DLT-Knoten mindestens die erste Aktualisierungsnachricht an den ersten DLT-Knoten zum Aktualisieren des ersten Datensatzes 148.
Das Ausführen der Programminstruktionen 164 durch den Prozessor 162 veranlasst den Prozessor 162 ferner dazu, den zweiten DLT-Knoten so zu steuern, dass der zweite DLT-Knoten im Zuge des Protokollierens der Warenlieferung in dem DLT-System 182 das Warenausgangsprotokolls von dem Warensender über das erste Netzwerk 184 empfängt. Beispielsweise empfängt der zweite DLT-Knoten das Warenausgangsprotokoll von dem Computersystem 100 des Warensenders. Das Warenausgangsprotokoll umfasst einen oder mehrere erste Sensorwerte für die eine oder mehreren physikalischen Eigenschaften der ausgehenden Ware gemäß der zweiten Spezifikation, welche mittels der eines oder mehrerer dem Warensender zugeordneter physikalischer Sensoren 114 erfasst sind.
Der zweite DLT-Knoten prüft den einen oder die mehreren ersten Sensorwerte des Warenausgangsprotokolls auf Übereinstimmung mit der einen oder den mehreren physikalischen Eigenschaften der zu liefernden Ware gemäß dem geteilten Datensatz bzw. dem zweiten Teildatensatz 168 des geteilten Datensatzes innerhalb vordefinierter erster Toleranzen. Hierzu verwendet der zweite DLT-Knoten einen der ein oder mehreren Smart-Contracts. Die geprüften ersten Sensorwerte umfassen dabei zumindest den die gelieferte Warenmenge quantifizierenden ersten Sensorwert. Es erfolgt ein Aktualisieren des zweiten Datensatzes 168 durch den zweiten DLT-Knoten unter Verwendung des Prüfergebnisses. Zudem übermittelt der zweite DLT-Knoten mindestens die zweite Aktualisierungsnachricht an den ersten DLT-Knoten zum Aktualisieren des ersten Datensatzes 148.
Schließlich veranlasst ein Ausführen der Programminstruktionen 164 durch den Prozessor 162 den Prozessor 162 dazu , den zweiten DLT-Knoten so zu steuern, dass der zweite DLT- Knoten im Zuge des Validierens der Warenlieferung in dem DLT-System 182 die Parameter der Validierungsnachricht zum Validieren der Warenlieferung unter Verwendung des einen oder der mehreren Smart-Contracts prüft. Die geprüften Parameter umfassen zumindest die zu validierende Warenmenge. Das Prüfen der Parameter umfasst dabei ein Prüfen der zu validierenden Warenmenge auf Übereinstimmung mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb der vordefinierten Toleranz. Bei Übereinstimmung der zu validierenden Warenmenge mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb der vordefinierten Toleranz, aktualisiert der zweite DLT-Knoten den zweiten Datensatzes 168. Dieses Aktualisieren umfasst ein Registrieren der Validierungsnachricht durch den zweiten DLT-Knoten in dem zweiten Datensatz 168 unter Verwendung mindestens eines der ein oder mehreren Smart-Contracts. Zudem übermittelt der zweite DLT- Knoten die entsprechende Aktualisierungsnachricht zur Registrierung der Validierungsnachricht an den ersten DLT-Knoten zum Aktualisieren des ersten Datensatzes 148.
Nach alternativen Ausführungsformen können der erste DLT-Knoten und der zweite DLT- Knoten auch auf einem gemeinsamen DLT-Server des DLT-Systems 180 implementiert sein. Nach alternativen Ausführungsformen kann der erste DLT-Knoten beispielsweise auch auf dem Computersystem 120 des Warenempfängers und/oder der zweite DLT-Knoten auf dem Computersystem 100 des Warensenders implementiert sein.
Figur 4 zeigt ein schematisches Ablaufdiagramm eines exemplarischen Verfahrens zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger. In Schritt 300 sendet der Warenempfänger einen Lieferauftrag 190 an einen ihm zugeordneten DLT-Knoten in dem DLT-System 182. Dieser Lieferauftrag 190 gibt neben einer Bestellnummer und einer Produktnummer beispielsweise eine Menge der zu liefernden Ware als physikalische Eigenschaft der entsprechenden Ware an. Dieses Senden des Lieferauftrags 190 führt dazu, dass in dem DLT-System 182 ein erster Teildatensatz eines geteilten Datensatzes unter Verwendung des Lieferauftrag 190 erzeugt wird. Die Daten des Lieferauftrags 190 werden ferner dem Warensender übermittelt. Der Status der Warenlieferung ist in diesem Stadium „vorgeschlagen“. In Schritt 302 sendet der Warensender eine Auftragsbestätigung 191 an einen ihm zugeordneten DLT-Knoten in dem DLT-System 182. Diese Auftragsbestätigung 191 gibt neben der Bestellnummer und der Produktnummer beispielsweise eine Menge der zu liefernden Ware als physikalische Eigenschaft der entsprechenden Ware an. Diese Bestätigung wird beispielsweise in einen zweiten Teildatensatz des geteilten Datensatzes auf dem DLT-Knoten des Warensenders in dem DLT-System 182 eingetragen. Stimmt die in der Auftragsbestätigung 191 angegebenen Menge mit der in dem Lieferauftrag 190 angegebenen Menge überein, nimmt die Warenlieferung den Status „bestätigt“ in dem DLT-System 182 an. Die Daten der Auftragsbestätigung 191 bzw. einer Aktualisierung des zweiten Teildatensatzes werden ferner dem Warenempfänger übermittelt.
Zusätzlich kann beispielsweise der Warenempfänger in Schritt 304 eine Aktualisierung 192 des Lieferauftrags 190 mit einer neuen Mengenangabe an das DLT-System 182 bzw. den ihm zugeordneten ersten DLT-Knoten in dem DLT-System 182 senden. Der erste DLT- Knoten trägt diese Aktualisierung der Spezifikation der Warenlieferung beispielsweise in den ersten Teildatensatz ein und übermittelt diese zudem an den Warensender bzw. den dem Warensender zugeordneten zweiten DLT-Knoten. Der Status der Warenlieferung in dem DLT-System 182 wechselt in diesem Fall beispielsweise zu „aktualisiert“. In Schritt 306 sendet der Warensender eine Aktualisierung 193 der Auftragsbestätigung 191 mit der neuen Mengenangabe an das DLT-System 182 bzw. den ihm zugeordneten zweiten DLT-Knoten in dem DLT-System 182. Der zweite DLT-Knoten trägt diese Aktualisierung der Bestätigung der Spezifikation der Warenlieferung beispielsweise in den zweiten Teildatensatz ein und übermittelt diese zudem an den Warenempfänger bzw. den dem Warenempfänger zugeordneten ersten DLT-Knoten. Der Status der Warenlieferung in dem DLT-System 182 wechselt in diesem Fall beispielsweise wieder zurück auf zu „bestätigt“. Ist die Warenlieferung erfolgt, sendet der Warensender in Schritt 194 beispielsweise eine Validierungsnachricht, etwa eine Rechnung, an das DLT-System zur Validierung bzw. zur Aktualisierung des geteilten Datensatzes unter Verwendung der Validierungsnachricht 194. Das Validieren umfasst beispielsweise ein Prüfen der Angaben der Validierungsnachricht mit den in dem geteilten Datensatz gespeicherten Spezifikation der Warenlieferung. Stimmen diese überein, wird die Validierungsnachricht in dem geteilten Datensatz in dem DLT-System 182 registriert. Beispielsweise wird eine Rechnungsnummer der Validierungsnachricht in dem geteilten Datensatz gespeichert. Der Status der Warenlieferung in dem DLT-System 182 wechselt in diesem Fall beispielsweise zu „abgeschlossen“.
Figur 5 zeigt ein weiteres schematisches Ablaufdiagramm eines exemplarischen Verfahrens zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger. Hierbei führen ein erster DLT-Knoten des Warenempfängers und ein zweiter DLT-Knoten des Warensenders unter Verwendung von einem oder mehreren Smart- Contracts die folgenden Schritte durch: In Schritt 320 erstellt der erste DLT-Knoten einen ersten Teildatensatz eines geteilten Datensatzes und aktualisiert diesen mit Daten aus einem Lieferauftrag des Warenempfängers. Dieser erste Teildatensatz wird an den zweiten DLT- Knoten des Warensenders gesendet. Der zweite DLT-Knoten erstellt einen zweiten Teildatensatz des geteilten Datensatzes mit den Daten aus dem Lieferauftrag. Der Status der Warenlieferung ist in diesem Stadium „vorgeschlagen“. In Schritt 322 aktualisiert der zweite DLT- Knoten den zweiten Teildatensatz mit Daten aus einer Auftragsbestätigung des Warensenders. Ferner wird eine Aktualisierungsnachricht über die Aktualisierung des zweiten Teildatensatzes unter Verwendung der Auftragsbestätigung an den ersten DLT-Knoten des Warenempfängers gesendet. Der erste DLT-Knoten aktualisiert den ersten Teildatensatz entsprechend. Anschließend können beispielsweise noch einen oder mehrere Aktualisierungsschritte und/oder eine Stornierung erfolgen.
In Schritt 324 aktualisiert der erste DLT-Knoten beispielsweise den ersten Teildatensatz basierend auf einer Aktualisierung des Lieferauftrags. Beispielsweise werden Menge, Lieferdatum, Preis etc. der zu liefernden Ware aktualisiert. Diese Aktualisierung wird dem zweiten DLT-Knoten übermittelt. Der zweite DLT-Knoten vermerkt diese Aktualisierung beispielsweise in dem zweiten Teildatensatz. Der Status der Warenlieferung wechselt damit zu „aktualisiert“. In Schritt 326 bestätigt der zweite DLT-Knoten die vorgeschlagene Aktualisierung beispielsweise basierend auf einer aktualisierten Auftragsbestätigung und trägt diese Bestätigung in den zweiten Teildatensatz ein. Diese Bestätigung der Aktualisierung wird dem ersten DLT-Knoten übermittelt. Der erste DLT-Knoten vermerkt diese Bestätigung beispielsweise in dem ersten Teildatensatz. Der Status der Warenlieferung wechselt damit wieder zurück zu „bestätigt“.
Ebenso kann eine Aktualisierung der Lieferkonditionen von dem Warensender ausgehen. In Schritt 328 aktualisiert der zweite DLT-Knoten beispielsweise den zweiten Teildatensatz basierend auf einer Aktualisierung der Auftragsbestätigung. Beispielsweise werden Menge, Lieferdatum, Preis etc. der zu liefernden Ware aktualisiert. Diese Aktualisierung wird dem ersten DLT-Knoten übermittelt. Der erste DLT-Knoten vermerkt diese Aktualisierung beispielsweise in dem ersten Teildatensatz. Der Status der Warenlieferung wechselt damit zu „aktualisiert“. In Schritt 330 bestätigt der erste DLT-Knoten die vorgeschlagene Aktualisierung beispielsweise basierend auf einem aktualisierten Lieferauftrag und trägt diese Bestätigung in den ersten Teildatensatz ein. Diese Bestätigung der Aktualisierung wird dem zweiten DLT-Knoten übermittelt. Der zweite DLT-Knoten vermerkt diese Bestätigung beispielsweise in dem zweiten T eildatensatz. Der Status der Warenlieferung wechselt damit wieder zurück zu „bestätigt“.
Ebenso kann die Warenlieferung auch von Seiten des Warensenders oder des Warenempfängers storniert werden. In Schritt 332 trägt der erste oder zweite DLT-Knoten beispielsweise in den ersten oder zweiten Teildatensatz eine Stornierung ein basierend auf einer empfangenen Stornierungsmitteilung. Ferner wird dem zweiten oder ersten DLT-Knoten eine Stornierungsnachricht übermittelt. Der zweite oder erste DLT-Knoten vermerkt die entsprechende Stornierung in dem zweiten oder ersten Teildatensatz. Der Status der Warenlieferung wechselt in diesem Fall auf „storniert“ und das Verfahren ist beendet.
Erfolgt keine Stornierung, aktualisiert der zweite DLT-Knoten in Schritt 334 den zweiten Teildatensatz basierend auf einer Prüfung einer Validierungsnachricht, beispielsweise auf eine erfolgte Warenlieferung hin. Ist die Prüfung erfolgreich, wird die Validierungsnachricht in dem zweiten Teildatensatz registriert, beispielsweise wird ein Identifikator der Validierungsnach- richt, wie etwa eine Rechnungsnummer in den zweiten Teildatensatz eingetragen. Diese Aktualisierung wird dem ersten DLT-Knoten übermittelt. Der erste DLT-Knoten vermerkt diese Aktualisierung beispielsweise in dem ersten Teildatensatz, indem er ebenfalls die Validierungsnachricht registriert. Der Status der Warenlieferung wechselt damit zu „abgeschlossen“.
Sowohl der erste als auch der zweite DLT-Knoten gemäß Figur 5 kann ein oder mehrere Merkmale der auf dem ersten und zweiten DLT-Server 140, 160 implementierten DLT-Knoten gemäß Figur 3 aufweisen. Ferner können die DLT-Knoten gemäß Figur 5 eingerichtet sein, zumindest teilweise das Verfahren gemäß Figuren 1A und/oder 1 B oder Teilen davon auszuführen.
Figur 6 zeigt ein weiteres schematisches Ablaufdiagramm eines exemplarischen Verfahrens zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger unter Verwendung eines DLT-Systems 182. In Schritt 350 sendet der Warenempfänger bzw. ein Computersystem 120 des Warenempfängers einen Lieferauftrag an einen dem Warenempfänger zugeordneten ersten DLT-Knoten in dem DLT-System 182. In Schritt 352 sendet der Warensender bzw. ein Computersystem 100 des Warensenders eine Auftragsbestätigung an einen dem Warensender zugeordneten zweiten DLT-Knoten in dem DLT-System 182. Basierend auf dem Lieferauftrag und der Auftragsbestätigung werden Konditionen der Warenlieferung in zwei Teildatensätze eines geteilten Datensatzes eingetragen und im Zuge eines 2-Way-Matches miteinander abgeglichen. So kann sichergestellt werden, dass die Konditionen gemäß Lieferauftrag und Auftragsbestätigung miteinander übereinstimmen. Im Zuge des Ausführens der Lieferung der zu liefernden Ware sendet der Warensender bzw. ein Computersystem 100 des Warensenders in Schritt 354 ein Warenausgangsprotokoll an den zweiten DLT-Knoten in dem DLT-System 182. Das Warenausgangsprotokoll umfasst Sensorwerte für physikalische Eigenschaften der ausgehenden Ware, welche mittels physikalischer Sensoren des Warensenders erfasst wurden und zumindest einen Sensorwert umfassen, welcher die gelieferte Warenmenge quantifiziert. Zudem sendet der Warensender bzw. ein Computersystem 100 des Warensenders in Schritt 356 eine Validierungsnachricht an den zweiten DLT-Knoten in dem DLT-System 182. Basierend auf dem Ergebnis des 2-Way-Matches, des Warenausgangsprotokolls und der Validierungsnachricht, wird im Zuge eines 3-Way-Matches geprüft, ob der Zustand der tatsächlich gelieferten Ware sowie die Konditionen gemäß 2-Way-Match mit den Angaben der Validierungsnachricht hierzu übereinstimmen. So kann sichergestellt werden, dass die Angaben der Validierungsnachricht korrekt sind. Ist die Prüfung der Validierungsnachricht erfolgreich, wird diese in dem geteilten Datensatz registriert.
Figur 7 zeigt ein weiteres schematisches Blockdiagramm eines exemplarischen Systems zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger inklusive elektronischer Zahlungstransaktion. Das System kann ein DLT- System 182 umfassen, beispielsweise das DLT-System gemäß Ausführungsformen der Figuren 3 oder 4. Der Zahlungsverkehr kann mit Datenströmen aus der Kontrolle der Warenlieferung gekoppelt und in einem geschlossenen Datenkreislauf gehalten werden.
Zur Vorbereitung elektronischer Zahlungen können Teilnehmer, beispielsweise Anwender A, in Schritt 360 Fiat-Geld, beispielsweise Euro, auf ein Pool-Konto einer Bank transferieren, welche den Zahlungsverkehr abwickelt. Dies erfolgt innerhalb eines Bankensystems bzw. unter Verwendung eines Bank-Computersystems 186. In Schritt 362 erfasst die Bank bzw. ein der Bank zugeordneter DLT-Knoten in dem DLT-System 182 den Eingang von Fiat-Geld, beispielsweise über eine API der Bank oder eine andere geeignete Programmier- oder Kommunikationsschnittstelle der Bank im DLT-System 182. Bei einer API (Application Programming Interface bzw. Anwendungsprogrammierschnittstelle) handelt es sich um eine Programmierschnittstelle bzw. einen Programmteil, der von einem Softwaresystem anderen Programmen zur Anbindung an das entsprechende System zur Verfügung gestellt wird. In Schritt 364 vergibt die Bank automatisiert E-Geld, d.h. elektronisches Geld, auf ein DLT-Konto des Anwenders A. Der Betrag des auf dem DLT-Konto des Anwenders A eingehenden E-Geldes entspricht dem Betrag des transferierten Fiat-Geldes. Ein entsprechendes Verfahren kann jeder Teilnehmer, bspw. Anwender B ausführen, um E-Geld auf ein zugehöriges DLT-Konto im DLT-System 182 vorzusehen. Die DLT-Konten können auf jeweiligen DLT-Knoten der Teilnehmer im DLT-System 182 vorgesehen sein.
Anwender A als Warenempfänger kann, beispielsweise auf einem ERP-System, eine Bestellung bei einem Warensender, z.B. Anwender B, durchführen. Die Bestellung wird beispielsweise als ein Lieferauftrag an einen DLT-Knoten des Anwenders A in Schritt 366 übermittelt. Der Lieferauftrag kann ERP-Daten aus dem ERP-System des Warenempfängers aufweisen. Hierzu kann der Anwender A beispielsweise ein Computersystem des Warenempfängers ver- wenden, welches über eine API oder eine beliebige andere Programmier- oder Kommunikationsschnittstelle mit dem zugehörigen DLT-Knoten im DLT-System 182 verbunden sein kann. Der DLT-Knoten des Anwenders A initialisiert die Warenlieferung, wie vorstehend ausgeführt, bspw. im Hinblick auf die Ausführungsform gemäß Figur 1A. Hierdurch wird eine Bestellspezifikation an einen DLT-Knoten des Warensenders übermittelt, welcher die Bestellspezifikation in Schritt 368 an ein Computersystem des Warensenders übermitteln kann. Anwender B kann die Bestellung beispielsweise unter Verwendung eines ERP-Systems auf dem Computersystem des Warensenders bestätigen. Die Bestellspezifikation und die Bestätigung können beispielsweise ERP-Daten des ERP-Systems des Warensenders aufweisen. Das Computersystem des Warensenders kann über eine API oder eine beliebige andere Programmier- oder Kommunikationsschnittstelle mit dem zugehörigen DLT-Knoten im DLT- System 182 verbunden sein.
Der Bestellvorgang wird durch das DLT-System 182 zwischen den DLT-Knoten des Warensenders und des Warenempfängers unter Verwendung von einem oder mehreren Smart- Contracts abgewickelt, was exemplarisch in Schritt 370 dargestellt ist. Beispielweise kommt hierzu eines der in den vorangehenden Figuren beschriebenes exemplarisches Verfahren zur Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger unter Verwendung des zugangsbeschränkten DLT-Systems 182 zum Einsatz. Ein gegebenenfalls erforderliches Handshake kann (semi-)automatisch zwischen den beteiligten DLT-Knoten durchgeführt werden. Falls weitere Daten erforderlich sind oder Parameter bestätigt werden müssen, können die beteiligten DLT-Knoten mit den zugehörigen Computersystemen des Warensenders oder des Warenempfängers kommunizieren, um Eingaben zu erhalten, bspw. über die jeweiligen ERP-Systeme, welche dann in das DLT-System 182. Entsprechend können der Bestellvorgang und die Warenlieferung über das DLT-System 182 erfolgen. Eine Warenlieferung und ggf. ein Versenden einer Rechnung, welche aufgrund von Anforderungen außerhalb des DLT-Systems 182 erfolgen müssen, können in Schritt 372 durchgeführt werden.
Auf eine Registrierung einer Validierungsnachricht der Warenlieferung, etwa durch Stellen der Rechnung, in dem DLT-System 182 hin kann eine elektronische Zahlungstransaktion von dem DLT-Konto des Anwenders A auf ein DLT-Konto des Anwenders B getriggert werden. Analog zum Emittieren von E-Geld auf DLT-Konten im DLT-System, kann ein Teilnehmer, beispielsweise Anwender B, in Schritt 374 das im Zuge von einer oder mehreren elektronischen Zahlungstransaktionen erhaltene E-Geld zumindest teilweise zum Ausbezahlen anweisen. Dies kann über den der Bank zugeordneten DLT-Knoten erfolgen, der mit dem Bank- Computersystem kommunizieren kann. In Schritt 376 wechselt die Bank das ausgegebene E-Geld in Fiat-Geld und transferiert das entsprechende Fiat-Geld über das Pool-Konto auf ein Konto des Anwenders B. Ein entsprechendes Verfahren kann jeder Teilnehmer, bspw. Anwender A ausführen, um E-Geld als Fiat-Geld auf ein zugehöriges Bankkonto auszuzahlen. Es sollte verständlich sein, dass die Warenlieferung nicht zwingend eine Auszahlung von E-Geld als Fiat-Geld nach sich ziehen muss. Vielmehr kann das E-Geld auf DLT-Konten verbleiben, um weitere elektronische Zahlungstransaktionen vorzunehmen
Das DLT-System 182 kann zusätzlich dazu konfiguriert sein, alle DLT-Zahlungstransaktionen in dem DLT-System 182, etwa aus AML (Anti-Money Laundering)-Gründen, d.h. zur Verhinderung von Geldwäsche, durch die Bank aufzuzeichnen und zu prüfen. Beispielsweise wird eine Anti-Geldwäsche-Software der Bank zur Prüfung der aufgezeichneten DLT- Transaktionen verwendet. Beispielsweise werden Kundendaten analysiert, um verdächtige Transaktionen zu erkennen. Hierzu werden die Kundendaten gefiltert, nach Höhe eines Vertrauens klassifiziert und auf Anomalien untersucht. Sobald die Anti-Geldwäsche-Software genügend Daten gesammelt hat und verdächtige Vorgänge markiert wurden, wird beispielsweise ein Bericht erzeugt. Ferner können Zahlungen freigegeben oder unterbunden werden.
Beispielsweise wird zudem eine regulatorisch konforme Prozessierung aller Zahlungstransaktionen durch das DLT-System 182 sichergestellt: Beispielsweise wird unter Verwendung des zumindest einen Smart-Contracts ein Regulator 378 implementiert, welcher zu Compli- ance-Zwecken alle Transaktionen erfasst. Ferner wird unter Verwendung des zumindest einen Smart-Contracts beispielsweise ein Notar(-knoten) 380, auch bekannt als Notary Node, implementiert, welcher eine mehrmalige Verwendung bzw. ein mehrmaliges Ausgeben derselben Einheiten von E-Geld verhindert.
Figuren 8A und 8B sowie Figur 9 zeigen exemplarische graphische Benutzeroberfläche (Graphical User Interface/GUI) zum Ausführen des Verfahrens zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger unter Verwendung eines zugangsbeschränkten DLT-Systems. Figur 8A zeigt einen ersten Teil einer ersten exemplarischen graphischen Benutzeroberfläche. Dabei umfasst Figur 8A eine exemplarische Darstellung der Daten eines ersten Teildatensatzes 148 eines geteilten Datensatzes, welche einen Lieferauftrag eines Warenempfängers („Buyer“) wiedergibt. Ferner zeigt Figur 8B einen zweiten Teil der ersten exemplarischen graphischen Benutzeroberfläche. Dabei umfasst Figur 8B eine exemplarische Darstellung der Daten eines zweiten Teildatensatzes 168 des geteilten Datensatzes, welche einen Vorschlag für geänderte Lieferkonditionen seitens des Warensenders („Seiler“) wiedergibt.
Die in den Figuren 8A und 8B gezeigte graphische Benutzeroberfläche umfasst ein Menü zur Auswahl verschiedener Bereiche. Diese umfassen ein „Dashboard“, d.h. eine graphische Benutzeroberfläche zur Visualisierung von Daten, einen Bereich mit „Aufträgen“ („Orders“), eine „Brieftasche“ („Wallet”), d.h. eine digitale Brieftasche, einen Bereich mit „Berichten“ („Reports”) und einen Bereich mit „Einstellungen“ („Settings”). Ferner ist ein aktueller Nutzer angegeben („Eingeloggt als“/„Logged In As”). Dargestellt ist ferner ein Auswahlelement zum Erstellen eines neuen Auftrags („Neuen Auftrag anlegen“/„Create new order”). Ferner können Suchparameter eingegeben werden („Suchen und filtern“/„Search and filter”). Die Figur 8A und 8B zeigen exemplarisch einen Bereich mit „Aufträgen“ („Orders“). In einem Untermenü können folgende Bereiche ausgewählt: „Offen“ („Open”), „Bestätigt“ („Confirmed”), „Bezahlt“ („Paid”) und „Abgelehnt“ („Rejected”). Diese Bereiche listen jeweils offene, bestätigte, bezahlte oder abgelehnte Aufträge auf. Die graphische Benutzeroberfläche umfasst einen Bereich „Käufer“ („Buyer”) für einen Warenempfänger und einen Bereich „Verkäufer“ („Seiler”) für einen Warensender.
Die Darstellung des ersten Teildatensatzes 148 des Warenempfängers in Figur 8A zeigt, was der Warenempfänger sieht, d.h. „Käufer - ihre Sicht“ („Buyer - Their View”), und gibt beispielsweise an: einen Zeitpunkt einer letzten Aktualisierung „Letzte Aktualisierung“ („Last update”), einen Status „AKTUALISIERT“ („UPDATED”), ein „Transaktions-ID“ („Transaction ID”), eine „Bestellnummer“ („Order number”), einen „Liefertermin“ („Delivery date”), eine „Produkt-ID Käufer“ („Product ID buyer”), einen „Produktnamen Käufer“ („Product name buyer”), eine „Produkt-ID Verkäufer“ („Product ID seller”), einen „Produktnamen Verkäufer“ („Product name seller”), eine „Einzelposten-ID“ („Line Item ID”), eine Angabe „Abrechnung (in Tagen)“ („Settlement (In days)”), eine „Rechnungsnummer“ („Invoice number”), ein „Datum der Rechnung“ („Invoice date”), eine „Steuer-ID“ („Tax ID”), eine Angabe zur „Steuer“ („Tax”), eine „Beschreibung“ („Description”), einen „Grund für die Aktualisierung“ („Update reason”), eine „Menge“ („Quantity”), eine Angabe zu „Einheiten“ („Units”), einen „Preis pro Einheit“ („Price per unit”), eine „Preiseinheit pro Einheit“ („Unit of price per Unit”), einen „Gesamtpreis“ („Total price”), und eine „Währung“ („Currency”). Ferner ist ein Auswahlelement „Alles akzeptieren“ („Accept all”) für den Warensender vorgehsehen, um alle Angaben bzw. Festlegungen gemäß dem ersten Teildatensatzes 148 des Warenempfängers zu akzeptieren.
Die Darstellung des zweiten Teildatensatzes 168 des Warensenders in Figur 8B zeigt, was der Warensender sieht, d.h. „Verkäufer - Meine Ansicht“ („Seiler - My View”), falls der Nutzer als ein Warensender eingeloggt ist, und gibt beispielsweise an: einen Zeitpunkt einer letzten Aktualisierung „Letzte Aktualisierung“ („Last update”), einen Status „AKTUALISIERT“ („UPDATED”), ein „Transaktions-ID“ („Transaction ID”), eine „Bestellnummer“ („Order number”), einen „Liefertermin“ („Delivery date”), eine „Produkt-ID Käufer“ („Product ID buyer”), einen „Produktnamen Käufer“ („Product name buyer”), eine „Produkt-ID Verkäufer“ („Product ID seller”), einen „Produktnamen Verkäufer“ („Product name seller”), eine „Einzelposten-ID“ („Line Item ID”), eine Angabe „Abrechnung (in Tagen)“ („Settlement (In days)”), eine „Rechnungsnummer“ („Invoice number”), ein „Datum der Rechnung“ („Invoice date”), eine „SteuerID“ („Tax ID”), eine Angabe zur „Steuer“ („Tax”), eine „Beschreibung“ („Description”), einen „Grund für die Aktualisierung“ („Update reason”), eine „Menge“ („Quantity”), eine Angabe zu „Einheiten“ („Units”), einen „Preis pro Einheit“ („Price per unit”), eine „Preiseinheit pro Einheit“ („Unit of price per Unit”), einen „Gesamtpreis“ („Total price”), und eine „Währung“ („Currency”). Diese Angaben sind bis auf die Angabe zum Zeitpunkt der letzten Aktualisierung „Letzte Aktualisierung“ („Last update”), den Status „AKTUALISIERT“ („UPDATED”), die „Transaktions-ID“ („Transaction ID”), die „Bestellnummer“ („Order number”), die „Produkt-ID Käufer“ („Product ID buyer”) und den „Produktnamen Käufer“ („Product name buyer”) durch den Warensender änderbar. Ferner sind ein Auswahlelemente „Abbrechen“ („Cancel”), „Senden“ („Send”) und „Bestätigen“ („Confirm”) zum Abbrechen, Senden oder Bestätigen der Angabe bzw. der Aktualisierungen der Angaben vorgesehen.
Figur 9 zeigt ein exemplarisches Dashboard eines DLT-Knotens eines Warensenders mit einer Übersicht aktueller Bestellungen und Zahlungen. Die in Figur 9 gezeigte graphische Benutzeroberfläche umfasst ein Menü zur Auswahl verschiedener Bereiche. Diese umfassen ein „Dashboard“, d.h. eine grafische Benutzeroberfläche zur Visualisierung von Daten, einen Bereich mit „Aufträgen“ („Orders“), eine „Brieftasche“ („Wallet”), d.h. eine digitale Brieftasche, einen Bereich mit „Berichten“ („Reports”) und einen Bereich mit „Einstellungen“ („Settings”). Ferner findet sich eine Angabe, wer aktuell eingeloggt ist „Eingeloggt als“ („Logged In As”). Figur 9 zeigt exemplarisch das „Dashboard“. Das Dashboard umfasst Angaben zu „Geld jetzt verfügbar“ („Cash available now”) „Geld morgen verfügbar“ („Cash available tomorrow”) und „Geld übermorgen verfügbar“ („Cash available the day after tomorrow”). Das Dashboard umfasst ferner eine „Übersicht“ („Overview“), eine Auflistung von „Aktuellen Aufträge“ („Most recent orders”), „Aktuellen Aktualisierungen“ („Most recent updates”) und „Pünktlichen Zahlungen“ („Paid on time”). Die „Übersicht“ („Overview“) umfasst eine graphische Darstellung, z.B. in Form eines Histogramms, verschiedener Angaben für den Zeitgerecht „Heute“ („Today”). Diese Angaben umfassen ein „Saldo Brieftasche“ („Wallet saldo”), Angaben zu eingehenden Zahlungen „Eingehend“ („Incoming”), zu ausgehenden Zahlungen „Ausgehend von“ („Outgoing”) und abgelehnten Zahlungen bzw. Lieferaufträgen „Abgelehnt“ („Rejected”). Die Aufstellung „Aktuelle Aufträge“ („Most recent orders”) listet aktuelle Aufträge auf und gibt beispielsweise an, wie viele nicht aufgelistete aktuelle Aufträge es noch gibt. Die Aufstellung „Aktuelle Aktualisierungen“ („Most recent updates”) listet aktuelle Aktualisierungen auf und gibt beispielsweise an, wann eine letzte Aktualisierung erfolgt ist „Zuletzt aktualisiert“ („Last updated”). Diese ist beispielsweise „vor 4 Minuten“ („4 minutes ago”) erfolgt. Schließlich gibt die Aufstellung „Pünktlich gezahlt“ („Paid on time”), wieviel Prozent der eingehenden Waren „Eingehend“ („Incoming”) und wieviel Prozent der ausgehenden Waren „Ausgehend“ („Outgoing”) pünktlich bezahlt sind. Schließlich umfasst das Dashboard Angaben zu einer Anzahl von „Transaktionen“ („Transactions”), welche anhängig sind „Anhängig“ („Pending”), welche zu erledigen sind „Zu erledigen“ („To dos”), welche bezahlt sind „Bezahlt“ („Paid”) und welche abgelehnt sind „Abgelehnt“ („Rejected”).
Vorangehend wurde die Erfindung unter Bezugnahme auf spezifische Ausführungsformen in beispielhafter Form beschrieben. Die vorliegende Erfindung kann ferner ohne Einschränkung und rein beispielhaft durch die folgenden Ausführungsformen weiter beschrieben werden. Die folgenden Ausführungsformen können bevorzugte Ausführungsformen umfassen. Dementsprechend kann sich der Begriff „Merkmalskombination“, wie er darin verwendet wird, auf eine solche „bevorzugte Ausführungsform“ beziehen.
1. Verfahren zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger unter Verwendung eines zugangsbeschränkten DLT-Systems, welches einen ersten dem Warenempfänger zugeordneten DLT-Knoten und einen zweiten dem Warensender zugeordneten DLT-Knoten umfasst, wobei das DLT- System mindestens einen Smart-Contract bereitstellt, wobei der mindestens eine Smart- Contract Programminstruktionen zu einem Einträgen und Prüfen von Lieferaufträgen und Auftragsbestätigungen umfasst, wobei das Verfahren ein Initialisieren der Warenlieferung in dem DLT-System umfasst, wobei das Initialisieren umfasst:
• Empfangen eines Lieferauftrags des Warenempfängers über ein erstes Netzwerk durch den ersten DLT-Knoten über von dem Warensender an den Warenempfänger zu liefernde Ware, wobei der Lieferauftrag eine oder mehrere physikalische Eigenschaften der zu liefernden Ware als eine erste Spezifikation bestimmt, wobei die physikalischen Eigenschaften der ersten Spezifikation zumindest eine zu liefernde Warenmenge umfassen,
• Erstellen eines ersten durch den ersten DLT-Knoten verwalteten Datensatzes und Einträgen mindestens der einen oder mehreren physikalischen Eigenschaften des Lieferauftrags durch den ersten DLT-Knoten in den ersten Datensatz unter Verwendung des mindestens einen Smart-Contracts, wobei der erste Datensatz ein erster Teil eines zwischen dem ersten DLT-Knoten und dem zweiten DLT-Knoten geteilten Datensatzes ist,
• Übermitteln mindestens des ersten Datensatzes von dem ersten DLT-Knoten an den zweiten DLT-Knoten,
• Erstellen eines zweiten durch den zweiten DLT-Knoten verwalteten Datensatzes, wobei der zweite Datensatz ein zweiter Teil des geteilten Datensatzes ist, und erstes Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten basierend auf dem ersten Datensatz, wobei das erste Aktualisieren ein Einträgen mindestens einer oder mehrerer der physikalischen Eigenschaften der ersten Spezifikation in den zweiten Datensatz umfasst, wobei die mindestens eine oder mehreren eingetragenen physikalischen Eigenschaften der ersten Spezifikation die zu liefernde Warenmenge umfassen,
• Empfangen einer Auftragsbestätigung des Warensenders über das erste Netzwerk durch den zweiten DLT-Knoten, wobei die Auftragsbestätigung eine zweite Spezifikation der einen oder mehreren physikalischen Eigenschaften der zu liefernden Ware umfasst,
• Prüfen der zweiten Spezifikation auf Übereinstimmung mit der ersten Spezifikation unter Verwendung des mindestens einen Smart-Contracts, • zweites Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten unter Verwendung eines ersten Prüfergebnisses des Prüfens der zweiten Spezifikation,
• Übermitteln mindestens einer ersten Aktualisierungsnachricht von dem zweiten DLT- Knoten an den ersten DLT-Knoten,
• erstes Aktualisieren des ersten Datensatzes durch den ersten DLT-Knoten unter Verwendung der ersten Aktualisierungsnachricht.
2. Verfahren nach Merkmalskombination 1 , wobei der mindestens eine Smart-Contract Programminstruktionen zu einem Einträgen und Prüfen von Warenausgangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger umfasst, wobei das Verfahren ferner ein Protokollieren der Warenlieferung in dem DLT-System umfasst, wobei das Protokollieren umfasst:
• Empfangen eines Warenausgangsprotokolls von dem Warensender über das erste Netzwerk durch den zweiten DLT-Knoten, wobei das Warenausgangsprotokoll einen oder mehrere erste Sensorwerte für die eine oder mehreren physikalischen Eigenschaften der ausgehenden Ware gemäß der zweiten Spezifikation umfasst, welche mittels eines oder mehrerer dem Warensender zugeordneter erster physikalischer Sensoren erfasst sind, wobei der eine oder die mehreren ersten Sensorwerte zumindest einen ersten Sensorwert umfassen, welcher die gelieferte Warenmenge quantifiziert,
• Prüfen des einen oder der mehreren ersten Sensorwerte des Warenausgangsprotokolls auf Übereinstimmung mit der einen oder den mehreren physikalischen Eigenschaften der zu liefernden Ware gemäß dem geteilten Datensatz innerhalb vordefinierter erster Toleranzen unter Verwendung des mindestens einen Smart-Contracts, wobei die geprüften ersten Sensorwerte zumindest den die gelieferte Warenmenge quantifizierenden ersten Sensorwert umfassen,
• drittes Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten unter Verwendung eines zweiten Prüfergebnisses des Prüfens des einen oder der mehreren ersten Sensorwerte des Warenausgangsprotokolls,
• Übermitteln mindestens einer zweiten Aktualisierungsnachricht von dem zweiten DLT-Knoten an den ersten DLT-Knoten,
• zweites Aktualisieren des ersten Datensatzes durch den ersten DLT-Knoten unter Verwendung der zweiten Aktualisierungsnachricht, 3. Verfahren nach einer der Merkmalskombinationen 1 oder 2, wobei der mindestens eine Smart-Contract Programminstruktionen zu einem Validieren der Warenlieferungen umfasst, wobei das Verfahren ferner ein Validieren der Warenlieferung in dem DLT-System umfasst, wobei das Validieren umfasst:
• Prüfen von Parametern einer Validierungsnachricht zum Validieren der Warenlieferung durch den zweiten DLT-Knoten unter Verwendung des mindestens einen Smart- Contracts, wobei die Parameter zumindest eine zu validierende Warenmenge umfassen, wobei das Prüfen der Parameter ein Prüfen der zu validierenden Warenmenge auf Übereinstimmung mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb einer vordefinierten zweiten Toleranz umfasst,
• bei Übereinstimmung der zu validierenden Warenmenge mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb der vordefinierten zweiten Toleranz, viertes Aktualisieren des zweiten Datensatzes durch den zweiten DLT- Knoten, wobei das vierte Aktualisieren ein Registrieren der Validierungsnachricht durch den zweiten DLT-Knoten in dem zweiten Datensatz unter Verwendung des mindestens einen Smart-Contracts umfasst,
• Übermitteln mindestens einer dritten Aktualisierungsnachricht von dem zweiten DLT- Knoten an den ersten DLT-Knoten,
• drittes Aktualisieren des ersten Datensatzes durch den ersten DLT-Knoten unter Verwendung der dritten Aktualisierungsnachricht, wobei das dritte Aktualisieren des ersten Datensatzes ein Registrieren der Validierungsnachricht in dem ersten Datensatz umfasst.
4. Verfahren nach einer der vorhergehenden Merkmalskombination, ferner umfassend ein Signieren der von dem ersten DLT-Knoten an den zweiten DLT-Knoten übermittelten Daten durch den ersten DLT-Knoten, wobei der mindestens eine Smart-Contract auf dem zweiten DLT-Knoten eingerichtet ist, die Signaturen der übermittelten Daten zu überprüfen.
5. Verfahren nach einer der vorhergehenden Merkmalskombination, ferner umfassend ein Signieren der von dem zweiten DLT-Knoten an den ersten DLT-Knoten übermittelten Daten durch den zweiten DLT-Knoten, wobei der mindestens eine Smart-Contract auf dem ersten DLT-Knoten eingerichtet ist, die Signaturen der übermittelten Daten zu überprüfen. 6. Verfahren nach einer der vorhergehenden Merkmalskombinationen, wobei die Datenübermittlung zwischen dem ersten DLT-Knoten und dem zweiten DLT-Knoten über eine oder mehrere mittels Ende-zu-Ende-Verschlüsselung kryptographisch geschützte Kommunikationsverbindungen erfolgt.
7. Verfahren nach Merkmalskombination 6, wobei ein Aufbauen der einen oder mehreren kryptographisch geschützten Kommunikationsverbindungen jeweils eine gegenseitige Authentifizierung des ersten DLT-Knoten und des zweiten DLT-Knotens umfasst.
8. Verfahren nach einer der vorhergehenden Merkmalskombinationen, wobei das Prüfen der zweiten Spezifikation auf Übereinstimmung mit der ersten Spezifikation im Zuge der Initialisierung ein Prüfen auf Identität ist.
9. Verfahren nach Merkmalskombination 8, wobei das Initialisieren ferner umfasst: falls die eine oder mehreren physikalischen Eigenschaften gemäß der zweiten Spezifikation, die in den zweiten Datensatz eingetragen werden, von der einen oder den mehreren physikalischen Eigenschaften gemäß der ersten Spezifikation aus dem ersten Datensatz abweichen, Durchführen eines Handshakes zwischen dem ersten DLT-Knoten und dem zweiten DLT-Knoten zum Abgleich der ersten Spezifikation des ersten Datensatzes und der zweiten Spezifikation des zweiten Datensatzes, sodass die aus dem Abgleich resultierenden ersten und zweiten Spezifikationen übereinstimmen.
10. Verfahren nach einer der Merkmalskombinationen 1 bis 7, wobei das Prüfen der zweiten Spezifikation auf Übereinstimmung mit der ersten Spezifikation im Zuge der Initialisierung ein Prüfen auf eine Übereinstimmung innerhalb vordefinierter dritter Toleranzen gemäß dem mindestens einen Smart-Contract ist.
11 . Verfahren nach Merkmalskombination 10, wobei das Initialisieren ferner umfasst: falls eine oder mehrere Abweichungen zwischen der einen oder den mehreren physikalischen Eigenschaften gemäß der zweiten Spezifikation, die in den zweiten Datensatz eingetragen werden, und der einen oder den mehreren physikalischen Eigenschaften gemäß der ersten Spezifikation aus dem ersten Datensatz größer als die vordefinierten dritten Toleranzen sind, Durchführen eines Handshakes zwischen dem ersten DLT-Knoten und dem zweiten DLT- Knoten zum Abgleich der ersten Spezifikation des ersten Datensatzes und der zweiten Spezifikation des zweiten Datensatzes, sodass die aus dem Abgleich resultierenden ersten und zweiten Spezifikationen innerhalb der vordefinierten dritten Toleranzen übereinstimmen.
12. Verfahren nach einer der vorhergehenden Merkmalskombinationen, wobei die von dem mindestens einen Smart-Contract umfassten Programminstruktionen ferner zu einem Einträgen und Prüfen von Wareneingangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger konfiguriert sind, wobei das Protokollieren der Warenlieferung in dem DLT-System ferner umfasst:
• Empfangen eines Wareneingangsprotokolls von dem Warenempfänger über das erste Netzwerk durch den ersten DLT-Knoten, wobei das Wareneingangsprotokoll einen oder mehrere zweite Sensorwerte für die eine oder mehreren physikalischen Eigenschaften der eingehenden Ware gemäß der ersten Spezifikation umfasst, welche mittels eines oder mehrerer dem Warenempfänger zugeordneter zweiter physikalischer Sensoren erfasst sind, wobei der eine oder die mehreren zweiten Sensorwerte zumindest einen zweiten Sensorwert umfassen, welcher die gelieferte Warenmenge quantifiziert,
• Prüfen des einen oder der mehreren zweiten Sensorwerte des Wareneingangsprotokolls auf Übereinstimmung mit der einen oder den mehreren physikalischen Eigenschaften der zu liefernden Ware gemäß dem geteilten Datensatz sowie mit dem einen oder den mehreren ersten Sensorwerten gemäß dem Warenausgangsprotokoll innerhalb vordefinierter vierter Toleranzen unter Verwendung des mindestens einen Smart-Contracts, wobei die geprüften zweiten Sensorwerte zumindest den die gelieferte Warenmenge quantifizierenden zweiten Sensorwert umfassen,
• viertes Aktualisieren des ersten Datensatzes durch den ersten DLT-Knoten unter Verwendung eines dritten Prüfergebnisses des Prüfens des einen oder der mehreren zweiten Sensorwerte des Wareneingangsprotokolls,
• Übermitteln mindestens einer vierten Aktualisierungsnachricht von dem ersten DLT- Knoten an den zweiten DLT-Knoten,
• fünftes Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten unter Verwendung der vierten Aktualisierungsnachricht.
13. Verfahren nach einer der vorhergehenden Merkmalskombinationen, wobei die Validierungsnachricht eine Rechnung umfasst und die von dem mindestens einen Smart- Contract umfassten Programminstruktionen ferner zur Rechnungserstellung der Rechnung konfiguriert sind, wobei die Rechnungserstellung durch den zweiten DLT-Knoten unter Verwendung des mindestens einen Smart-Contracts erfolgt, wobei das Prüfen der Parameter der Validierungsnachricht im Zuge der Rechnungserstellung erfolgt.
14. Verfahren nach einer der Merkmalskombinationen 1 bis 12, wobei eine Rechnung von einem die Rechnung erstellenden ersten ERP-System des Warensenders empfangen wird.
15. Verfahren nach einer der vorhergehenden Merkmalskombinationen, wobei es sich bei den im Zuge des Protokollierens der Warenlieferung in den in dem DLT-System bereitgestellten geteilten Datensatz eingetragenen Daten um spiegelgleiche Daten der Warenlieferung aus dem ersten ERP-System des Warensenders und/oder einem zweiten ERP-System des Warenempfängers handelt, wobei das erste und/oder zweite ERP-System zu einer Steuerung der Abwicklung der Warenlieferung konfiguriert sind, wobei durch Eintragung der spiegelgleichen Daten eine Datenkonsistenz zwischen dem geteilten Datensatz und den ERP-Systemen sichergestellt wird.
16. Verfahren nach einer der Merkmalskombinationen 1 bis 14, wobei eine Steuerung der Abwicklung der Warenlieferung durch den mindestens einen Smart-Contract erfolgt, dessen Programminstruktionen ferner zu der Steuerung der Abwicklung der Warenlieferung konfiguriert sind.
17. Verfahren nach einer der vorhergehenden Merkmalskombinationen, wobei es sich bei dem ersten Netzwerk um ein öffentliches Netzwerk handelt.
18. Verfahren nach einer der vorhergehenden Merkmalskombinationen, wobei eine Voraussetzung für das Empfangen des Lieferauftrags des Warenempfängers durch den ersten DLT-Knoten eine erfolgreiche Authentifizierung des Warenempfängers durch den ersten DLT-Knoten ist, und/oder wobei eine Voraussetzung für das Empfangen der Auftragsbestätigung des Warensenders durch den zweiten DLT-Knoten eine erfolgreiche Authentifizierung des Warensenders durch den zweiten DLT-Knoten ist, und/oder wobei eine Voraussetzung für das Empfangen des Warenausgangsprotokolls von dem Warensender durch den zweiten DLT-Knoten eine erfolgreiche Authentifizierung des Warensenders durch den zweiten DLT-Knoten ist, und/oder wobei eine Voraussetzung für das Empfangen des Wareneingangsprotokolls von dem Warenempfänger durch den ersten DLT-Knoten eine erfolgreiche Authentifizierung des Warenempfängers durch den ersten DLT-Knoten ist.
19. Verfahren nach einer der vorhergehenden Merkmalskombinationen, wobei eine Voraussetzung für das Verwenden des Lieferauftrags des Warenempfängers durch den ersten DLT-Knoten eine erfolgreiche Signaturprüfung einer Signatur des Lieferauftrags durch den ersten DLT-Knoten ist, und/oder wobei eine Voraussetzung für das Verwenden der Auftragsbestätigung des Warensenders durch den zweiten DLT-Knoten eine erfolgreiche Signaturprüfung einer Signatur der Auftragsbestätigung durch den zweiten DLT-Knoten ist, und/oder wobei eine Voraussetzung für das Verwenden des Warenausgangsprotokolls des Warensenders durch den zweiten DLT-Knoten eine erfolgreiche Signaturprüfung einer Signatur des Warenausgangsprotokolls durch den zweiten DLT-Knoten ist, und/oder wobei eine Voraussetzung für das Verwenden des Wareneingangsprotokolls des Warenempfängers durch den ersten DLT-Knoten eine erfolgreiche Signaturprüfung einer Signatur des Wareneingangsprotokolls durch den ersten DLT-Knoten ist.
20. Verfahren nach einer der vorhergehenden Merkmalskombinationen, wobei der erste DLT-Knoten und der zweite DLT-Knoten durch einen oder mehrere DLT-Server des DLT- Systems bereitgestellt werden.
21. Verfahren nach Merkmalskombination 20, wobei der eine oder die mehreren DLT- Server des DLT-Systems in einem oder mehreren gegen unberechtigte Zutritte gesicherten Rechenzentren angeordneten sind.
22. Verfahren nach einer der vorhergehenden Merkmalskombinationen, wobei die Datenübertragung zwischen den DLT-Knoten über ein zweites Netzwerk erfolgt.
23. Verfahren nach Merkmalskombination 22, wobei es sich bei dem zweiten Netzwerk um ein privates oder ein öffentliches Netzwerk handelt. 24. Verfahren nach einer der vorhergehenden Merkmalskombinationen, wobei die von dem mindestens einen Smart-Contract umfassten Programminstruktionen ferner zu einem Triggern einer elektronischen Zahlungstransaktion konfiguriert sind, wobei das Triggern der Zahlungstransaktion durch den Smart-Contract auf die Registrierung der Validierungsnachricht in dem DLT-System hin erfolgt.
25. Verfahren nach Merkmalskombination 24, wobei es sich bei der getriggerten elektronischen Zahlungstransaktion um eine IBAN-Überweisung von einem IBAN-Konto des Warenempfängers auf ein IBAN-Konto des Warensenders handelt.
26. Verfahren nach Merkmalskombination 24, wobei es sich bei der getriggerten elektronischen Zahlungstransaktion um eine unter Verwendung des DLT-Systems ausgeführten Transaktion eines Betrags an programmierbarem Geld handelt.
27. Verfahren nach Merkmalskombination 26, wobei das DLT-Systems dazu konfiguriert ist, den zu zahlenden Rechnungsbetrag von einem Konto des Warenempfängers für programmierbares Geld auf ein Konto des Warensenders für programmierbares Geld zu transferieren, wobei das DLT-Systems beispielsweise ferner dazu konfiguriert ist einen Fiat-Geldbetrag eines dem Warenempfänger zugeordneten Fiat-Geldkontos in einen Betrag des programmierbaren Geldes auf dem Konto des Warenempfängers für programmierbares Geld zu transformieren.
28. Verfahren nach einer der Merkmalskombinationen 26 oder 27, wobei die Zahlungstransaktion unter Verwendung des mindestens einen Smart-Contracts in dem DLT-System protokolliert wird, wobei unter Verwendung des Smart-Contracts ferner elektronische Kontoauszüge über die protokollierte Zahlungstransaktion für den Warenempfänger und/oder den Warensender ausgestellt werden.
29. Geteilter Datensatz eines zugangsbeschränkten DLT-Systems zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger unter Verwendung des DLT-Systems, wobei der geteilte Datensatz einen ersten Teil umfasst, wobei der erste Teil ein durch einen dem Warenempfänger zugeordneten ersten DLT- Knoten verwalteter erster Datensatz ist, wobei der geteilte Datensatz ferner einen zweiten Teil umfasst, wobei der zweite Teil ein durch einen dem Warensender zugeordneten zweiten DLT-Knoten verwalteter zweiter Datensatz ist.
30. Verwendung eines geteilten Datensatzes nach Merkmalskombination 29 zu einem Initialisieren der Warenlieferung in dem DLT-System.
31 . Verwendung des geteilten Datensatzes nach Merkmalskombination 29 zu einem Protokollieren der Warenlieferung in dem DLT-System.
32. Verwendung des geteilten Datensatzes nach Merkmalskombination 29 zu einem Validieren der Warenlieferung in dem DLT-System.
33. DLT-Knoten eines zugangsbeschränkten DLT-Systems zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger, wobei der DLT-Knoten auf einem DLT-Server des DLT-Systems implementiert und dem Warenempfänger zugeordnet ist, wobei der DLT-Server einen Prozessor und einen Speicher mit Programminstruktionen umfasst, wobei durch die Programminstruktionen auf dem DLT- Knoten mindestens ein Smart-Contract bereitgestellt wird, wobei die den mindestens einen Smart-Contract bereitstellenden Programminstruktionen Programminstruktionen zu einem Einträgen und Prüfen von Lieferaufträgen und Auftragsbestätigungen umfassen, wobei ein Ausführen der Programminstruktionen durch den Prozessor den Prozessor dazu veranlasst, den DLT-Knoten so zu steuern, dass der DLT-Knoten im Zuge eines Initialisierens der Warenlieferung in dem DLT-System Folgendes ausführt:
• Empfangen eines Lieferauftrags des Warenempfängers über von dem Warensender an den Warenempfänger zu liefernde Ware durch den DLT-Knoten über ein erstes Netzwerk, wobei der Lieferauftrag eine oder mehrere physikalische Eigenschaften der zu liefernden Ware als eine erste Spezifikation bestimmt, wobei die physikalischen Eigenschaften der ersten Spezifikation zumindest eine zu liefernde Warenmenge umfassen,
• Erstellen eines ersten durch den DLT-Knoten verwalteten Datensatzes und Einträgen mindestens der einen oder mehreren physikalischen Eigenschaften des Lieferauftrags durch den DLT-Knoten in den ersten Datensatz unter Verwendung des mindestens einen Smart-Contracts, wobei der erste Datensatz ein erster Teil eines zwischen dem DLT-Knoten und einem weiteren, dem Warensender zugeordneten DLT-Knoten des DLT-Systems geteilten Datensatzes ist,
• Übermitteln mindestens des ersten Datensatzes von dem DLT-Knoten an den weiteren DLT-Knoten,
• Empfangen mindestens einer ersten Aktualisierungsnachricht von dem weiteren DLT- Knoten über eine Aktualisierung des zweiten Datensatzes unter Verwendung eines ersten Prüfergebnisses einer Prüfung einerzweiten Spezifikation der einen oder mehreren physikalischen Eigenschaften der zu liefernden Ware gemäß einer Auftragsbestätigung auf Übereinstimmung mit der ersten Spezifikation,
• erstes Aktualisieren des ersten Datensatzes durch den DLT-Knoten unter Verwendung der ersten Aktualisierungsnachricht.
34. DLT-Knoten nach Merkmalskombination 33, wobei die den mindestens einen Smart- Contract bereitstellenden Programminstruktionen Programminstruktionen zu einem Einträgen und Prüfen von Warenausgangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger umfassen, wobei das Ausführen der Programminstruktionen durch den Prozessor den Prozessor dazu veranlasst, den DLT-Knoten ferner so zu steuern, dass der DLT-Knoten im Zuge eines Protokollierens der Warenlieferung in dem DLT- System Folgendes ausführt:
• Empfangen mindestens einer zweiten Aktualisierungsnachricht von dem weiteren DLT-Knoten über eine Aktualisierung des zweiten Datensatzes unter Verwendung eines zweiten Prüfergebnisses einer Prüfung eines oder mehrerer ersten Sensorwerte eines Warenausgangsprotokolls auf Übereinstimmung mit der einen oder den mehreren physikalischen Eigenschaften der zu liefernden Ware gemäß dem geteilten Datensatz innerhalb vordefinierter erster Toleranzen, wobei der eine oder die mehreren ersten Sensorwerte des Warenausgangsprotokolls mittels eines oder mehrerer dem Warensender zugeordneter erster physikalischer Sensoren erfasst sind, wobei die geprüften ersten Sensorwerte zumindest den die gelieferte Warenmenge quantifizierenden ersten Sensorwert umfassen,
• zweites Aktualisieren des ersten Datensatzes durch den DLT-Knoten unter Verwendung der zweiten Aktualisierungsnachricht.
35. DLT-Knoten nach einer der Merkmalskombinationen 33 oder 34, wobei die den min- destens einen Smart-Contract bereitstellenden Programminstruktionen Programminstruktionen zu einem Validieren der Warenlieferungen umfassen, wobei das Ausführen der Programminstruktionen durch den Prozessor den Prozessor dazu veranlasst, den DLT-Knoten ferner so zu steuern, dass der DLT-Knoten im Zuge eines Validierens der Warenlieferung in dem DLT-System Folgendes ausführt:
• Empfangen mindestens einer dritten Aktualisierungsnachricht von dem weiteren DLT- Knoten über eine Aktualisierung des zweiten Datensatzes unter Verwendung einer Validierungsnachricht, wobei die Aktualisierung des zweiten Datensatzes unter Verwendung der Validierungsnachricht eine Registrierung der Validierungsnachricht in dem zweiten Datensatz umfasst, wobei die Aktualisierung des zweiten Datensatzes unter Verwendung der Validierungsnachricht eine erfolgreiche Prüfung von Parametern der Validierungsnachricht durch den weiteren DLT-Knoten bestätigt, wobei die Parameter zumindest eine zu validierende Warenmenge umfassen, wobei das Prüfen der Parameter ein Prüfen der zu validierenden Warenmenge auf Übereinstimmung mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb einer vordefinierten zweiten Toleranz umfasst,
• drittes Aktualisieren des ersten Datensatzes durch den DLT-Knoten unter Verwendung der dritten Aktualisierungsnachricht, wobei das dritte Aktualisieren des ersten Datensatzes ein Registrieren der Validierungsnachricht in dem ersten Datensatz umfasst.
36. DLT-Knoten nach einer der Merkmalskombinationen 33 bis 35, wobei das Ausführen der Programminstruktionen durch den Prozessor den Prozessor ferner dazu veranlasst, den DLT-Knoten so zu steuern, dass der DLT-Knoten die Verfahrensschritte des ersten DLT- Knotens des Verfahrens nach einer der Merkmalskombinationen 4 bis 28 ausführt.
37. DLT-Knoten eines zugangsbeschränkten DLT-Systems zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger, wobei der DLT-Knoten auf einem DLT-Server des DLT-Systems implementiert und dem Warensender zugeordnet ist, wobei der DLT-Server einen Prozessor und einen Speicher mit Programminstruktionen umfasst, wobei durch die Programminstruktionen auf dem DLT-Knoten mindestens ein Smart-Contract bereitgestellt wird, wobei die den mindestens einen Smart- Contract bereitstellenden Programminstruktionen Programminstruktionen zu einem Einträgen und Prüfen von Lieferaufträgen und Auftragsbestätigungen umfassen, wobei ein Ausführen der Programminstruktionen durch den Prozessor den Prozessor dazu veranlasst, den DLT-Knoten so zu steuern, dass der DLT-Knoten im Zuge eines Initialisierens der Warenlieferung in dem DLT-System Folgendes ausführt:
• Empfangen mindestens eines von einem weiteren DLT-Knoten des Warenempfängers erstellten ersten Datensatzes von dem weiteren DLT-Knoten, wobei der erste Datensatz ein erster Teil eines zwischen dem DLT-Knoten und dem weiteren DLT- Knoten geteilten Datensatzes ist, wobei der erste Datensatz mindestens eine oder mehrere physikalische Eigenschaften der zu liefernden Ware gemäß einer ersten Spezifikation eines Lieferauftrags umfasst, wobei die physikalischen Eigenschaften der ersten Spezifikation zumindest eine zu liefernde Warenmenge umfassen,
• Erstellen eines zweiten durch den DLT-Knoten verwalteten Datensatzes, wobei der zweite Datensatz ein zweiter Teil des geteilten Datensatzes ist, und erstes Aktualisieren des zweiten Datensatzes durch den DLT-Knoten basierend auf dem ersten Datensatz, wobei das erste Aktualisieren ein Einträgen mindestens einer oder mehrerer der physikalischen Eigenschaften der ersten Spezifikation in den zweiten Datensatz umfasst, wobei die mindestens eine oder mehreren eingetragenen physikalischen Eigenschaften der ersten Spezifikation die zu liefernde Warenmenge umfassen,
• Empfangen einer Auftragsbestätigung des Warensenders über ein erstes Netzwerk durch den DLT-Knoten, wobei die Auftragsbestätigung eine zweite Spezifikation der eine oder mehreren physikalischen Eigenschaften der zu liefernden Ware umfasst,
• Prüfen der zweiten Spezifikation auf Übereinstimmung mit der ersten Spezifikation unter Verwendung des mindestens einen Smart-Contracts,
• zweites Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten unter Verwendung eines ersten Prüfergebnisses des Prüfens der zweiten Spezifikation,
• Übermitteln mindestens einer ersten Aktualisierungsnachricht von dem DLT-Knoten an den weiteren DLT-Knoten zum Aktualisieren des ersten Datensatzes.
38. DLT-Knoten nach Merkmalskombination 37, wobei die den mindestens einen Smart- Contract bereitstellenden Programminstruktionen Programminstruktionen zu einem Einträgen und Prüfen von Warenausgangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger umfassen, wobei das Ausführen der Programminstruktionen durch den Prozessor den Prozessor dazu veranlasst, den DLT-Knoten ferner so zu steuern, dass der DLT-Knoten im Zuge eines Protokollierens der Warenlieferung in dem DLT- System Folgendes ausführt:
• Empfangen eines Warenausgangsprotokolls von dem Warensender über das erste Netzwerk durch den DLT-Knoten, wobei das Warenausgangsprotokoll einen oder mehrere erste Sensorwerte für die eine oder mehreren physikalischen Eigenschaften der ausgehenden Ware gemäß der zweiten Spezifikation umfasst, welche mittels eines oder mehrerer dem Warensender zugeordneter erster physikalischer Sensoren erfasst sind, wobei der eine oder die mehreren ersten Sensorwerte zumindest einen ersten Sensorwert umfassen, welcher die gelieferte Warenmenge quantifiziert,
• Prüfen des einen oder der mehreren ersten Sensorwerte des Warenausgangsprotokolls auf Übereinstimmung mit der einen oder den mehreren physikalischen Eigenschaften der zu liefernden Ware gemäß dem geteilten Datensatz innerhalb vordefinierter erster Toleranzen unter Verwendung des mindestens einen Smart-Contracts, wobei die geprüften ersten Sensorwerte zumindest den die gelieferte Warenmenge quantifizierenden ersten Sensorwert umfassen,
• drittes Aktualisieren des zweiten Datensatzes durch den DLT-Knoten unter Verwendung eines zweiten Prüfergebnisses des Prüfens des einen oder der mehreren ersten Sensorwerte des Warenausgangsprotokolls,
• Übermitteln mindestens einer zweiten Aktualisierungsnachricht von dem DLT-Knoten an den weiteren DLT-Knoten zum Aktualisieren des ersten Datensatzes.
39. DLT-Knoten nach einer der Merkmalskombinationen 37 oder 38, wobei die den mindestens einen Smart-Contract bereitstellenden Programminstruktionen Programminstruktionen zu einem Validieren der Warenlieferungen umfassen, wobei das Ausführen der Programminstruktionen durch den Prozessor den Prozessor dazu veranlasst, den DLT-Knoten so ferner zu steuern, dass der DLT-Knoten im Zuge eines Validierens der Warenlieferung in dem DLT-System Folgendes ausführt:
• Prüfen von Parametern einer Validierungsnachricht zum Validieren der Warenlieferung durch den DLT-Knoten unter Verwendung des mindestens einen Smart- Contracts, wobei die Parameter zumindest eine zu validierende Warenmenge umfassen, wobei das Prüfen der Parameter ein Prüfen der zu validierenden Warenmenge auf Übereinstimmung mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb einer vordefinierten zweiten Toleranz umfasst,
• bei Übereinstimmung der zu validierenden Warenmenge mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb der vordefinierten zweiten Toleranz, viertes Aktualisieren des zweiten Datensatzes durch den DLT-Knoten, wobei das vierte Aktualisieren ein Registrieren der Validierungsnachricht durch den DLT- Knoten in dem zweiten Datensatz unter Verwendung des mindestens einen Smart- Contracts umfasst,
• Übermitteln mindestens einer dritten Aktualisierungsnachricht von dem DLT-Knoten an den weiteren DLT-Knoten zum Aktualisieren des ersten Datensatzes.
40. DLT-Knoten nach einer der Merkmalskombinationen 37 bis 39, wobei das Ausführen der Programminstruktionen durch den Prozessor den Prozessor ferner dazu veranlasst, den DLT-Knoten so zu steuern, dass der DLT-Knoten die Verfahrensschritte des zweiten DLT- Knotens des Verfahrens nach einer der Merkmalskombinationen 4 bis 28 ausführt.
41 . DLT-System zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger, welches einen ersten dem Warenempfänger zugeordneten DLT-Knoten und einen zweiten dem Warensender zugeordneten DLT-Knoten umfasst, wobei der erste DLT-Knoten und der zweite DLT-Knoten durch einen oder mehrere DLT-Server des DLT-Systems bereitgestellt werden, wobei das DLT-System mindestens einen Smart-Contract bereitstellt, wobei der mindestens eine Smart-Contract Programminstruktionen zu einem Einträgen und Prüfen von Lieferaufträgen und Auftragsbestätigungen umfasst, wobei das DLT-System dazu konfiguriert ist, ein Initialisieren der Warenlieferung in dem DLT- System auszuführen, wobei das Initialisieren umfasst:
• Empfangen eines Lieferauftrags des Warenempfängers über ein erstes Netzwerk durch den ersten DLT-Knoten über von dem Warensender an den Warenempfänger zu liefernde Ware, wobei der Lieferauftrag eine oder mehrere physikalische Eigenschaften der zu liefernden Ware als eine erste Spezifikation bestimmt, wobei die physikalischen Eigenschaften der ersten Spezifikation zumindest eine zu liefernde Warenmenge umfassen,
• Erstellen eines ersten durch den ersten DLT-Knoten verwalteten Datensatzes und Einträgen mindestens der einen oder mehreren physikalischen Eigenschaften des Lieferauftrags durch den ersten DLT-Knoten in den ersten Datensatz unter Verwendung des mindestens einen Smart-Contracts, wobei der erste Datensatz ein erster Teil eines zwischen dem ersten DLT-Knoten und dem zweiten DLT-Knoten geteilten Datensatzes ist,
• Übermitteln mindestens des ersten Datensatzes von dem ersten DLT-Knoten an den zweiten DLT-Knoten,
• Erstellen eines zweiten durch den zweiten DLT-Knoten verwalteten Datensatzes, wobei der zweite Datensatz ein zweiter Teil des geteilten Datensatzes ist, und erstes Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten basierend auf dem ersten Datensatz, wobei das erste Aktualisieren ein Einträgen mindestens einer oder mehrerer der physikalischen Eigenschaften der ersten Spezifikation in den zweiten Datensatz umfasst, wobei die mindestens eine oder mehreren eingetragenen physikalischen Eigenschaften der ersten Spezifikation die zu liefernde Warenmenge umfassen,
• Empfangen einer Auftragsbestätigung des Warensenders über das erste Netzwerk durch den zweiten DLT-Knoten, wobei die Auftragsbestätigung eine zweite Spezifikation der eine oder mehreren physikalischen Eigenschaften der zu liefernden Ware umfasst,
• Prüfen der zweiten Spezifikation auf Übereinstimmung mit der ersten Spezifikation unter Verwendung des mindestens einen Smart-Contracts,
• zweites Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten unter Verwendung eines ersten Prüfergebnisses des Prüfens der zweiten Spezifikation,
• Übermitteln mindestens einer ersten Aktualisierungsnachricht von dem zweiten DLT- Knoten an den ersten DLT-Knoten,
• erstes Aktualisieren des ersten Datensatzes durch den ersten DLT-Knoten unter Verwendung der ersten Aktualisierungsnachricht.
42. DLT-System nach Merkmalskombination 41 , wobei der mindestens eine Smart- Contract Programminstruktionen zu einem Einträgen und Prüfen von Warenausgangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger umfasst, wobei das DLT-System ferner dazu konfiguriert ist, ein Protokollieren der Warenlieferung in dem DLT-System auszuführen, wobei das Protokollieren umfasst:
• Empfangen eines Warenausgangsprotokolls von dem Warensender über das erste Netzwerk durch den zweiten DLT-Knoten, wobei das Warenausgangsprotokoll einen oder mehrere erste Sensorwerte für die eine oder mehreren physikalischen Eigenschaften der ausgehenden Ware gemäß der zweiten Spezifikation umfasst, welche mittels eines oder mehrerer dem Warensender zugeordneter erster physikalischer Sensoren erfasst sind, wobei der eine oder die mehreren ersten Sensorwerte zumindest einen ersten Sensorwert umfassen, welcher die gelieferte Warenmenge quantifiziert,
• Prüfen des einen oder der mehreren ersten Sensorwerte des Warenausgangsprotokolls auf Übereinstimmung mit der einen oder den mehreren physikalischen Eigenschaften der zu liefernden Ware gemäß dem geteilten Datensatz innerhalb vordefinierter erster Toleranzen unter Verwendung des mindestens einen Smart-Contracts, wobei die geprüften ersten Sensorwerte zumindest den die gelieferte Warenmenge quantifizierenden ersten Sensorwert umfassen,
• drittes Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten unter Verwendung eines zweiten Prüfergebnisses des Prüfens des einen oder der mehreren ersten Sensorwerte des Warenausgangsprotokolls,
• Übermitteln mindestens einer zweiten Aktualisierungsnachricht von dem zweiten DLT-Knoten an den ersten DLT-Knoten,
• zweites Aktualisieren des ersten Datensatzes durch den ersten DLT-Knoten unter Verwendung der zweiten Aktualisierungsnachricht.
43. DLT-System nach einer der Merkmalskombinationen 41 oder 42, wobei der mindestens eine Smart-Contract Programminstruktionen zu einem Validieren der Warenlieferungen umfasst, wobei das DLT-System ferner dazu konfiguriert ist, ein Validieren der Warenlieferung in dem DLT-System auszuführen, wobei das Validieren umfasst:
• Prüfen von Parametern einer Validierungsnachricht zum Validieren der Warenlieferung durch den zweiten DLT-Knoten unter Verwendung des mindestens einen Smart- Contracts, wobei die Parameter zumindest eine zu validierende Warenmenge umfassen, wobei das Prüfen der Parameter ein Prüfen der zu validierenden Warenmenge auf Übereinstimmung mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb einer vordefinierten zweiten Toleranz umfasst,
• bei Übereinstimmung der zu validierenden Warenmenge mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb der vordefinierten zweiten Toleranz, viertes Aktualisieren des zweiten Datensatzes durch den zweiten DLT- Knoten, wobei das vierte Aktualisieren ein Registrieren der Validierungsnachricht durch den zweiten DLT-Knoten in dem zweiten Datensatz unter Verwendung des mindestens einen Smart-Contracts umfasst, • Übermitteln mindestens einer dritten Aktualisierungsnachricht von dem zweiten DLT- Knoten an den ersten DLT-Knoten,
• drittes Aktualisieren des ersten Datensatzes durch den ersten DLT-Knoten unter Verwendung der dritten Aktualisierungsnachricht, wobei das dritte Aktualisieren des ersten Datensatzes ein Registrieren der Validierungsnachricht in dem ersten Datensatz umfasst.
44. DLT-System nach einer der Merkmalskombinationen 41 bis 43, wobei das DLT- System ferner dazu konfiguriert ist, das Verfahren nach einer der Merkmalskombinationen 4 bis 28 auszuführen.
45. Computerprogramm zur Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger unter Verwendung eines zugangsbeschränkten DLT-Systems, welches einen ersten dem Warenempfänger zugeordneten DLT-Knoten und einen zweiten dem Warensender zugeordneten DLT-Knoten umfasst, wobei das Computerprogramm mindestens einen Smart-Contract bereitstellt, wobei der mindestens eine Smart-Contract Programminstruktionen zu einem Einträgen und Prüfen von Lieferaufträgen und Auftragsbestätigungen umfasst, wobei das Computerprogramm Programminstruktionen zum Initialisieren der Warenlieferung in dem DLT-System umfasst, wobei das Initialisieren umfasst:
• Empfangen eines Lieferauftrags des Warenempfängers über ein erstes Netzwerk durch den ersten DLT-Knoten über von dem Warensender an den Warenempfänger zu liefernde Ware, wobei der Lieferauftrag eine oder mehrere physikalische Eigenschaften der zu liefernden Ware als eine erste Spezifikation bestimmt, wobei die physikalischen Eigenschaften der ersten Spezifikation zumindest eine zu liefernde Warenmenge umfassen,
• Erstellen eines ersten durch den ersten DLT-Knoten verwalteten Datensatzes und Einträgen mindestens der einen oder mehreren physikalischen Eigenschaften des Lieferauftrags durch den ersten DLT-Knoten in den ersten Datensatz unter Verwendung des mindestens einen Smart-Contracts, wobei der erste Datensatz ein erster Teil eines zwischen dem ersten DLT-Knoten und dem zweiten DLT-Knoten geteilten Datensatzes ist, • Übermitteln mindestens des ersten Datensatzes von dem ersten DLT-Knoten an den zweiten DLT-Knoten,
• Erstellen eines zweiten durch den zweiten DLT-Knoten verwalteten Datensatzes, wobei der zweite Datensatz ein zweiter Teil des geteilten Datensatzes ist, und erstes Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten basierend auf dem ersten Datensatz, wobei das erste Aktualisieren ein Einträgen mindestens einer oder mehrerer der physikalischen Eigenschaften der ersten Spezifikation in den zweiten Datensatz umfasst, wobei die mindestens eine oder mehreren eingetragenen physikalischen Eigenschaften der ersten Spezifikation die zu liefernde Warenmenge umfassen,
• Empfangen einer Auftragsbestätigung des Warensenders über das erste Netzwerk durch den zweiten DLT-Knoten, wobei die Auftragsbestätigung eine zweite Spezifikation der eine oder mehreren physikalischen Eigenschaften der zu liefernden Ware umfasst,
• Prüfen der zweiten Spezifikation auf Übereinstimmung mit der ersten Spezifikation unter Verwendung des mindestens einen Smart-Contracts,
• zweites Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten unter Verwendung eines ersten Prüfergebnisses des Prüfens der zweiten Spezifikation,
• Übermitteln mindestens einer ersten Aktualisierungsnachricht von dem zweiten DLT- Knoten an den ersten DLT-Knoten,
• erstes Aktualisieren des ersten Datensatzes durch den ersten DLT-Knoten unter Verwendung der ersten Aktualisierungsnachricht.
46. Computerprogramm nach Merkmalskombination 45, wobei der mindestens eine Smart-Contract Programminstruktionen zu einem Einträgen und Prüfen Warenausgangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger umfasst, wobei das Computerprogramm ferner Programminstruktion zu einem Protokollieren der Warenlieferung in dem DLT-System umfasst, wobei das Protokollieren umfasst:
• Empfangen eines Warenausgangsprotokolls von dem Warensender über das erste Netzwerk durch den zweiten DLT-Knoten, wobei das Warenausgangsprotokoll einen oder mehrere erste Sensorwerte für die eine oder mehreren physikalischen Eigenschaften der ausgehenden Ware gemäß der zweiten Spezifikation umfasst, welche mittels eines oder mehrerer dem Warensender zugeordneter erster physikalischer Sensoren erfasst sind, wobei der eine oder die mehreren ersten Sensorwerte zumindest einen ersten Sensorwert umfassen, welcher die gelieferte Warenmenge quantifiziert,
• Prüfen des einen oder der mehreren ersten Sensorwerte des Warenausgangsprotokolls auf Übereinstimmung mit der einen oder den mehreren physikalischen Eigenschaften der zu liefernden Ware gemäß dem geteilten Datensatz innerhalb vordefinierter erster Toleranzen unter Verwendung des mindestens einen Smart-Contracts, wobei die geprüften ersten Sensorwerte zumindest den die gelieferte Warenmenge quantifizierenden ersten Sensorwert umfassen,
• drittes Aktualisieren des zweiten Datensatzes durch den zweiten DLT-Knoten unter Verwendung eines zweiten Prüfergebnisses des Prüfens des einen oder der mehreren ersten Sensorwerte des Warenausgangsprotokolls,
• Übermitteln mindestens einer zweiten Aktualisierungsnachricht von dem zweiten DLT-Knoten an den ersten DLT-Knoten,
• zweites Aktualisieren des ersten Datensatzes durch den ersten DLT-Knoten unter Verwendung der zweiten Aktualisierungsnachricht.
47. Computerprogramm nach einer der Merkmalskombinationen 45 oder 46, wobei der mindestens eine Smart-Contract Programminstruktionen zu einem Validieren der Warenlieferungen umfasst, wobei das Computerprogramm ferner Programminstruktionen zu einem Validieren der Warenlieferung in dem DLT-System umfasst, wobei das Validieren umfasst:
• Prüfen von Parametern einer Validierungsnachricht zum Validieren der Warenlieferung durch den zweiten DLT-Knoten unter Verwendung des mindestens einen Smart- Contracts, wobei die Parameter zumindest eine zu validierende Warenmenge umfassen, wobei das Prüfen der Parameter ein Prüfen der zu validierenden Warenmenge auf Übereinstimmung mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb einer vordefinierten zweiten Toleranz umfasst,
• bei Übereinstimmung der zu validierenden Warenmenge mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb der vordefinierten zweiten Toleranz, viertes Aktualisieren des zweiten Datensatzes durch den zweiten DLT- Knoten, wobei das vierte Aktualisieren ein Registrieren der Validierungsnachricht durch den zweiten DLT-Knoten in dem zweiten Datensatz unter Verwendung des mindestens einen Smart-Contracts umfasst, • Übermitteln mindestens einer dritten Aktualisierungsnachricht von dem zweiten DLT- Knoten an den ersten DLT-Knoten,
• drittes Aktualisieren des ersten Datensatzes durch den ersten DLT-Knoten unter Verwendung der dritten Aktualisierungsnachricht, wobei das dritte Aktualisieren des ers- ten Datensatzes ein Registrieren der Validierungsnachricht in dem ersten Datensatz umfasst.
48. Computerprogramm nach einer der Merkmalskombinationen 45 bis 47, wobei das Computerprogramm ferner Programminstruktionen zum Ausführen des Verfahrens nach ei- ner der Merkmalskombinationen 4 bis 28 umfasst.
Bezugszeichenliste
100 Warensender-Computersystem
102 Speicher
104 öffentlicher Schlüssel
106 geschützter Speicherbereich
108 privater Schlüssel
110 Prozessor
112 Programminstruktion
114 Sensor
116 Kommunikationsschnittstelle
120 Warenempfänger-Computersystem
122 Speicher
124 öffentlicher Schlüssel
126 geschützter Speicherbereich
128 privater Schlüssel
130 Prozessor
132 Programminstruktion
134 Sensor
136 Kommunikationsschnittstelle
140 DLT-Server
142 Prozessor
144 Programminstruktionen
146 Speicher
148 erster Datensatz des geteilten Datensatzes
150 öffentlicher Schlüssel
152 geschützter Speicherbereich
154 privater Schlüssel
156 Kommunikationsschnittstelle
160 DLT-Server
162 Prozessor
164 Programminstruktionen
166 Speicher 168 zweiter Datensatz des geteilten Datensatzes
170 öffentlicher Schlüssel
172 geschützter Speicherbereich
174 privater Schlüssel 176 Kommunikationsschnittstelle
180 D LT- Netzwerk
182 DLT-System
184 Netzwerk
186 Banken-Computersystem 190 Lieferauftrag
191 Auftragsbestätigung
192 aktualisierter Lieferauftrag
193 aktualisierte Auftragsbestätigung
194 Validierungsnachricht

Claims

P a t e n t a n s p r ü c h e
1. Verfahren zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger unter Verwendung eines zugangsbeschränkten DLT-Systems (182), welches einen ersten dem Warenempfänger zugeordneten DLT-Knoten und einen zweiten dem Warensender zugeordneten DLT-Knoten umfasst, wobei das DLT- System (182) mindestens einen Smart-Contract bereitstellt, wobei der mindestens eine Smart-Contract Programminstruktionen zu einem Einträgen und Prüfen von Lieferaufträgen (190) und Auftragsbestätigungen (191) umfasst, wobei das Verfahren ein Initialisieren der Warenlieferung in dem DLT-System (182) umfasst, wobei das Initialisieren umfasst:
• Empfangen eines Lieferauftrags (190) des Warenempfängers über ein erstes Netzwerk (184) durch den ersten DLT-Knoten über von dem Warensender an den Warenempfänger zu liefernde Ware, wobei der Lieferauftrag (190) eine oder mehrere physikalische Eigenschaften der zu liefernden Ware als eine erste Spezifikation bestimmt, wobei die physikalischen Eigenschaften der ersten Spezifikation zumindest eine zu liefernde Warenmenge umfassen,
• Erstellen eines ersten durch den ersten DLT-Knoten verwalteten Datensatzes (148) und Einträgen mindestens der einen oder mehreren physikalischen Eigenschaften des Lieferauftrags (190) durch den ersten DLT-Knoten in den ersten Datensatz (148) unter Verwendung des mindestens einen Smart-Contracts, wobei der erste Datensatz (148) ein erster Teil eines zwischen dem ersten DLT-Knoten und dem zweiten DLT- Knoten geteilten Datensatzes ist,
• Übermitteln mindestens des ersten Datensatzes (148) von dem ersten DLT-Knoten an den zweiten DLT-Knoten,
• Erstellen eines zweiten durch den zweiten DLT-Knoten verwalteten Datensatzes (168), wobei der zweite Datensatz (168) ein zweiter Teil des geteilten Datensatzes ist, und erstes Aktualisieren des zweiten Datensatzes (168) durch den zweiten DLT- Knoten basierend auf dem ersten Datensatz (148), wobei das erste Aktualisieren ein Einträgen mindestens einer oder mehrerer der physikalischen Eigenschaften der ersten Spezifikation in den zweiten Datensatz (168) umfasst, wobei die mindestens eine oder mehreren eingetragenen physikalischen Eigenschaften der ersten Spezifikation die zu liefernde Warenmenge umfassen, Ill
• Empfangen einer Auftragsbestätigung (191) des Warensenders über das erste Netzwerk (184) durch den zweiten DLT-Knoten, wobei die Auftragsbestätigung (191) eine zweite Spezifikation der einen oder mehreren physikalischen Eigenschaften der zu liefernden Ware umfasst,
• Prüfen der zweiten Spezifikation auf Übereinstimmung mit der ersten Spezifikation unter Verwendung des mindestens einen Smart-Contracts,
• zweites Aktualisieren des zweiten Datensatzes (168) durch den zweiten DLT-Knoten unter Verwendung eines ersten Prüfergebnisses des Prüfens der zweiten Spezifikation,
• Übermitteln mindestens einer ersten Aktualisierungsnachricht von dem zweiten DLT- Knoten an den ersten DLT-Knoten,
• erstes Aktualisieren des ersten Datensatzes (148) durch den ersten DLT-Knoten unter Verwendung der ersten Aktualisierungsnachricht.
2. Verfahren nach Anspruch 1 , wobei das DLT-System (182) auf einem direkten Datenaustausch zwischen den DLT-Knoten der beteiligten Parteien und auf einer direkten Datenvalidierung durch die entsprechenden DLT-Knoten beruht.
3. Verfahren insbesondere nach Anspruch 1 oder 2, wobei der mindestens eine Smart- Contract Programminstruktionen zu einem Einträgen und Prüfen von Warenausgangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger umfasst, wobei das Verfahren ein Protokollieren der Warenlieferung in dem DLT-System (182) umfasst, wobei das Protokollieren umfasst:
• Empfangen eines Warenausgangsprotokolls von dem Warensender über das erste Netzwerk (184) durch den zweiten DLT-Knoten, wobei das Warenausgangsprotokoll einen oder mehrere erste Sensorwerte für die eine oder mehreren physikalischen Eigenschaften der ausgehenden Ware gemäß der zweiten Spezifikation umfasst, welche mittels eines oder mehrerer dem Warensender zugeordneter erster physikalischer Sensoren (114) erfasst sind, wobei der eine oder die mehreren ersten Sensorwerte zumindest einen ersten Sensorwert umfassen, welcher die gelieferte Warenmenge quantifiziert,
• Prüfen des einen oder der mehreren ersten Sensorwerte des Warenausgangsprotokolls auf Übereinstimmung mit der einen oder den mehreren physikalischen Eigen- schäften der zu liefernden Ware gemäß dem geteilten Datensatz innerhalb vordefinierter erster Toleranzen unter Verwendung des mindestens einen Smart-Contracts, wobei die geprüften ersten Sensorwerte zumindest den die gelieferte Warenmenge quantifizierenden ersten Sensorwert umfassen,
• drittes Aktualisieren des zweiten Datensatzes (168) durch den zweiten DLT-Knoten unter Verwendung eines zweiten Prüfergebnisses des Prüfens des einen oder der mehreren ersten Sensorwerte des Warenausgangsprotokolls,
• Übermitteln mindestens einer zweiten Aktualisierungsnachricht von dem zweiten DLT-Knoten an den ersten DLT-Knoten,
• zweites Aktualisieren des ersten Datensatzes (148) durch den ersten DLT-Knoten unter Verwendung der zweiten Aktualisierungsnachricht,
4. Verfahren insbesondere nach einem der Ansprüche 1 bis 3, wobei das Verfahren ein Validieren der Warenlieferung in dem DLT-System (182) umfasst, wobei der mindestens eine Smart-Contract Programminstruktionen zu einem Validieren der Warenlieferungen umfasst, wobei das Validieren umfasst:
• Prüfen von Parametern einer Validierungsnachricht (194) zum Validieren der Warenlieferung durch den zweiten DLT-Knoten unter Verwendung des mindestens einen Smart-Contracts, wobei die Parameter zumindest eine zu validierende Warenmenge umfassen, wobei das Prüfen der Parameter ein Prüfen der zu validierenden Warenmenge auf Übereinstimmung mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb einer vordefinierten zweiten Toleranz umfasst,
• bei Übereinstimmung der zu validierenden Warenmenge mit dem die gelieferte Warenmenge quantifizierenden ersten Sensorwert innerhalb der vordefinierten zweiten Toleranz, viertes Aktualisieren des zweiten Datensatzes (168) durch den zweiten DLT-Knoten, wobei das vierte Aktualisieren ein Registrieren der Validierungsnachricht (194) durch den zweiten DLT-Knoten in dem zweiten Datensatz (168) unter Verwendung des mindestens einen Smart-Contracts umfasst,
• Übermitteln mindestens einer dritten Aktualisierungsnachricht von dem zweiten DLT- Knoten an den ersten DLT-Knoten,
• drittes Aktualisieren des ersten Datensatzes (148) durch den ersten DLT-Knoten unter Verwendung der dritten Aktualisierungsnachricht, wobei das dritte Aktualisieren des ersten Datensatzes (148) ein Registrieren der Validierungsnachricht (194) in dem ersten Datensatz (148) umfasst.
5. Verfahren nach einem der vorhergehenden Ansprüche, ferner umfassend ein Signieren der von dem ersten DLT-Knoten an den zweiten DLT-Knoten übermittelten Daten durch den ersten DLT-Knoten, wobei der mindestens eine Smart-Contract auf dem zweiten DLT- Knoten eingerichtet ist, die Signaturen der übermittelten Daten zu überprüfen, und/oder ferner umfassend ein Signieren der von dem zweiten DLT-Knoten an den ersten DLT- Knoten übermittelten Daten durch den zweiten DLT-Knoten, wobei der mindestens eine Smart-Contract auf dem ersten DLT-Knoten eingerichtet ist, die Signaturen der übermittelten Daten zu überprüfen, und/oder wobei die Datenübermittlung zwischen dem ersten DLT-Knoten und dem zweiten DLT-Knoten über eine oder mehrere mittels Ende-zu-Ende-Verschlüsselung kryptographisch geschützte Kommunikationsverbindungen erfolgt, wobei ein Aufbauen der einen oder mehreren kryptographisch geschützten Kommunikationsverbindungen beispielweise jeweils eine gegenseitige Authentifizierung des ersten DLT-Knoten und des zweiten DLT-Knotens umfasst.
6. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Prüfen der zweiten Spezifikation auf Übereinstimmung mit der ersten Spezifikation im Zuge der Initialisierung ein Prüfen auf Identität ist, wobei das Initialisieren beispielsweise ferner umfasst: falls die eine oder mehreren physikalischen Eigenschaften gemäß der zweiten Spezifikation, die in den zweiten Datensatz (168) eingetragen werden, von der einen oder den mehreren physikalischen Eigenschaften gemäß der ersten Spezifikation aus dem ersten Datensatz (148) abweichen, Durchführen eines Handshakes zwischen dem ersten DLT-Knoten und dem zweiten DLT-Knoten zum Abgleich der ersten Spezifikation des ersten Datensatzes (148) und der zweiten Spezifikation des zweiten Datensatzes (168), sodass die aus dem Abgleich resultierenden ersten und zweiten Spezifikationen übereinstimmen, oder wobei das Prüfen der zweiten Spezifikation auf Übereinstimmung mit der ersten Spezifikation im Zuge der Initialisierung ein Prüfen auf eine Übereinstimmung innerhalb vordefinierter dritter Toleranzen gemäß dem mindestens einen Smart-Contract ist, wobei das Initialisieren beispielsweise ferner umfasst: falls eine oder mehrere Abweichungen zwischen der einen oder den mehreren physikalischen Eigenschaften gemäß der zweiten Spezifikation, die in den zweiten Datensatz (168) eingetragen werden, und der einen oder den mehreren physikalischen Eigenschaften gemäß der ersten Spezifikation aus dem ersten Datensatz (148) größer als die vordefinierten dritten Toleranzen sind, Durchführen eines Handshakes zwischen dem ersten DLT-Knoten und dem zweiten DLT-Knoten zum Abgleich der ersten Spezifikation des ersten Datensatzes (148) und der zweiten Spezifikation des zweiten Datensatzes (168), sodass die aus dem Abgleich resultierenden ersten und zweiten Spezifikationen innerhalb der vordefinierten dritten Toleranzen übereinstimmen.
7. Verfahren nach einem der vorhergehenden Ansprüche, wobei die von dem mindestens einen Smart-Contract umfassten Programminstruktionen ferner zu einem Einträgen und Prüfen von Wareneingangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger konfiguriert sind, wobei das Protokollieren der Warenlieferung in dem DLT-System (182) ferner umfasst:
• Empfangen eines Wareneingangsprotokolls von dem Warenempfänger über das erste Netzwerk (184) durch den ersten DLT-Knoten, wobei das Wareneingangsprotokoll einen oder mehrere zweite Sensorwerte für die eine oder mehreren physikalischen Eigenschaften der eingehenden Ware gemäß der ersten Spezifikation umfasst, welche mittels eines oder mehrerer dem Warenempfänger zugeordneter zweiter physikalischer Sensoren (134) erfasst sind, wobei der eine oder die mehreren zweiten Sensorwerte zumindest einen zweiten Sensorwert umfassen, welcher die gelieferte Warenmenge quantifiziert,
• Prüfen des einen oder der mehreren zweiten Sensorwerte des Wareneingangsprotokolls auf Übereinstimmung mit der einen oder den mehreren physikalischen Eigenschaften der zu liefernden Ware gemäß dem geteilten Datensatz sowie mit dem einen oder den mehreren ersten Sensorwerten gemäß dem Warenausgangsprotokoll innerhalb vordefinierter vierter Toleranzen unter Verwendung des mindestens einen Smart-Contracts, wobei die geprüften zweiten Sensorwerte zumindest den die gelieferte Warenmenge quantifizierenden zweiten Sensorwert umfassen,
• viertes Aktualisieren des ersten Datensatzes (148) durch den ersten DLT-Knoten unter Verwendung eines dritten Prüfergebnisses des Prüfens des einen oder der mehreren zweiten Sensorwerte des Wareneingangsprotokolls, • Übermitteln mindestens einer vierten Aktualisierungsnachricht von dem ersten DLT- Knoten an den zweiten DLT-Knoten,
• fünftes Aktualisieren des zweiten Datensatzes (168) durch den zweiten DLT-Knoten unter Verwendung der vierten Aktualisierungsnachricht.
8. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Validierungsnachricht (194) eine Rechnung umfasst und die von dem mindestens einen Smart-Contract umfassten Programminstruktionen ferner zur Rechnungserstellung der Rechnung konfiguriert sind, wobei die Rechnungserstellung durch den zweiten DLT-Knoten unter Verwendung des mindestens einen Smart-Contracts erfolgt, wobei das Prüfen der Parameter der Validierungsnachricht (194) im Zuge der Rechnungserstellung erfolgt, oder wobei eine Rechnung von einem die Rechnung erstellenden ersten ERP-System des Warensenders empfangen wird.
9. Verfahren nach einem der vorhergehenden Ansprüche, wobei es sich bei den im Zuge des Protokollierens der Warenlieferung in den in dem DLT-System (182) bereitgestellten geteilten Datensatz eingetragenen Daten um spiegelgleiche Daten der Warenlieferung aus dem ersten ERP-System des Warensenders und/oder einem zweiten ERP-System des Warenempfängers handelt, wobei das erste und/oder zweite ERP-System zu einer Steuerung der Abwicklung der Warenlieferung konfiguriert sind, wobei durch Eintragung der spiegelgleichen Daten eine Datenkonsistenz zwischen dem geteilten Datensatz und den ERP-Systemen sichergestellt wird, oder wobei eine Steuerung der Abwicklung der Warenlieferung durch den mindestens einen Smart-Contract erfolgt, dessen Programminstruktionen ferner zu der Steuerung der Abwicklung der Warenlieferung konfiguriert sind.
10. Verfahren nach einem der vorhergehenden Ansprüche, wobei es sich bei dem ersten Netzwerk (184) um ein öffentliches Netzwerk handelt, und/oder wobei eine Voraussetzung für das Empfangen des Lieferauftrags (190) des Warenempfängers durch den ersten DLT-Knoten eine erfolgreiche Authentifizierung des Warenempfängers durch den ersten DLT-Knoten ist, und/oder wobei eine Voraussetzung für das Empfangen der Auftragsbestätigung (191) des Warensenders durch den zweiten DLT-Knoten eine erfolgreiche Authentifizierung des Warensenders durch den zweiten DLT-Knoten ist, und/oder wobei eine Voraussetzung für das Empfangen des Warenausgangsprotokolls von dem Warensender durch den zweiten DLT-Knoten eine erfolgreiche Authentifizierung des Warensenders durch den zweiten DLT-Knoten ist, und/oder wobei eine Voraussetzung für das Empfangen des Wareneingangsprotokolls von dem Warenempfänger durch den ersten DLT-Knoten eine erfolgreiche Authentifizierung des Warenempfängers durch den ersten DLT-Knoten ist, und/oder wobei eine Voraussetzung für das Verwenden des Lieferauftrags (190) des Warenempfängers durch den ersten DLT-Knoten eine erfolgreiche Signaturprüfung einer Signatur des Lieferauftrags (190) durch den ersten DLT-Knoten ist, und/oder wobei eine Voraussetzung für das Verwenden der Auftragsbestätigung (191) des Warensenders durch den zweiten DLT-Knoten eine erfolgreiche Signaturprüfung einer Signatur der Auftragsbestätigung (191) durch den zweiten DLT-Knoten ist, und/oder wobei eine Voraussetzung für das Verwenden des Warenausgangsprotokolls des Warensenders durch den zweiten DLT-Knoten eine erfolgreiche Signaturprüfung einer Signatur des Warenausgangsprotokolls durch den zweiten DLT-Knoten ist, und/oder wobei eine Voraussetzung für das Verwenden des Wareneingangsprotokolls des Warenempfängers durch den ersten DLT-Knoten eine erfolgreiche Signaturprüfung einer Signatur des Wareneingangsprotokolls durch den ersten DLT-Knoten ist, und/oder wobei der erste DLT-Knoten und der zweite DLT-Knoten durch einen oder mehrere DLT-Server (140, 160) des DLT-Systems (182) bereitgestellt werden, wobei der eine oder die mehreren DLT-Server (140, 160) des DLT-Systems (182) beispielsweise in einem oder mehreren gegen unberechtigte Zutritte gesicherten Rechenzentren angeordneten sind, und/oder wobei die Datenübertragung zwischen den DLT-Knoten über ein zweites Netzwerk (180) erfolgt. wobei es sich bei dem zweiten Netzwerk (180) beispielsweise um ein privates oder ein öffentliches Netzwerk handelt.
11. Verfahren nach einem der vorhergehenden Ansprüche, wobei die von dem mindestens einen Smart-Contract umfassten Programminstruktionen ferner zu einem Triggern einer elektronischen Zahlungstransaktion konfiguriert sind, wobei das Triggern der Zahlungstransaktion durch den Smart-Contract auf die Registrierung der Validierungsnachricht (194) in dem DLT-System (182) hin erfolgt, wobei es sich bei der getriggerten elektronischen Zahlungstransaktion beispielsweise um eine IBAN-Überweisung von einem IBAN-Konto des Warenempfängers auf ein IBAN- Konto des Warensenders handelt, oder wobei es sich bei der getriggerten elektronischen Zahlungstransaktion beispielsweise um eine unter Verwendung des DLT-Systems (182) ausgeführten Transaktion eines Betrags an programmierbarem Geld handelt, wobei das DLT-Systems (182) beispielsweise dazu konfiguriert ist, den zu zahlenden Rechnungsbetrag von einem Konto des Warenempfängers für programmierbares Geld auf ein Konto des Warensenders für programmierbares Geld zu transferieren, wobei das DLT- Systems (182) beispielsweise ferner dazu konfiguriert ist einen Fiat-Geldbetrag eines dem Warenempfänger zugeordneten Fiat-Geldkontos in einen Betrag des programmierbaren Geldes auf dem Konto des Warenempfängers für programmierbares Geld zu transformieren, und/oder wobei die Zahlungstransaktion beispielsweise unter Verwendung des mindestens einen Smart-Contracts in dem DLT-System (182) protokolliert wird, wobei unter Verwendung des Smart-Contracts beispielsweise ferner elektronische Kontoauszüge über die protokollierte Zahlungstransaktion für den Warenempfänger und/oder den Warensender ausgestellt werden.
12. Verwendung eines geteilten Datensatz eines zugangsbeschränkten DLT-Systems (182) im Zuge einer computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger zu einem Initialisieren der Warenlieferung in dem DLT- System (182) und/oder zu einem Protokollieren der Warenlieferung in dem DLT-System (182) und/oder zu einem Validieren der Warenlieferung in dem DLT-System (182), wobei der geteilte Datensatz einen ersten Teil umfasst, wobei der erste Teil ein durch einen dem Warenempfänger zugeordneten ersten DLT-Knoten verwalteter erster Datensatz (148) ist, wobei der geteilte Datensatz ferner einen zweiten Teil umfasst, wobei der zweite Teil ein durch einen dem Warensender zugeordneten zweiten DLT-Knoten verwalteter zweiter Datensatz (168) ist
13. DLT-Knoten eines zugangsbeschränkten DLT-Systems (182) zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger, wobei der DLT-Knoten auf einem DLT-Server (140) des DLT-Systems (182) implementiert und dem Warenempfänger zugeordnet ist, wobei der DLT-Server (140) einen Prozessor (142) und einen Speicher mit Programminstruktionen (144) umfasst, wobei durch die Programminstruktionen (144) auf dem DLT-Knoten mindestens ein Smart-Contract bereitgestellt wird, wobei die den mindestens einen Smart-Contract bereitstellenden Programminstruktionen (144) Programminstruktionen zu einem Einträgen und Prüfen von Lieferaufträgen (190), Auftragsbestätigungen (191) und/oder Warenausgangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger und/oder zu einem Validieren der Warenlieferungen umfassen, wobei ein Ausführen der Programminstruktionen durch den Prozessor den Prozessor dazu veranlasst, den DLT-Knoten so zu steuern, dass der DLT-Knoten die Verfahrensschritte des ersten DLT-Knotens des Verfahrens nach einem der Ansprüche 1 bis 11 ausführt.
14. DLT-Knoten eines zugangsbeschränkten DLT-Systems (182) zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger, wobei der DLT-Knoten auf einem DLT-Server (160) des DLT-Systems (182) implementiert und dem Warensender zugeordnet ist, wobei der DLT-Server (160) einen Prozessor (162) und einen Speicher (166) mit Programminstruktionen (164) umfasst, wobei durch die Programminstruktionen (164) auf dem DLT-Knoten mindestens ein Smart-Contract bereitgestellt wird, wobei die den mindestens einen Smart-Contract bereitstellenden Programminstruktionen (164) Programminstruktionen zu einem Einträgen und Prüfen von Lieferaufträgen (190), Auftragsbestätigungen (191) und/oder Warenausgangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger und/oder zu einem Validieren der Warenlieferungen umfassen, wobei Ausführen der Programminstruktionen durch den Prozessor den Prozessor dazu veranlasst, den DLT-Knoten so zu steuern, dass der DLT-Knoten die Verfahrensschritte des zweiten DLT-Knotens des Verfahrens nach einem der Ansprüche 1 bis 11 ausführt.
15. DLT-System (182) zur computerimplementierten Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger, welches einen ersten dem Warenempfänger zugeordneten DLT-Knoten und einen zweiten dem Warensender zugeordneten DLT-Knoten umfasst, wobei der erste DLT-Knoten und der zweite DLT-Knoten durch einen oder mehrere DLT-Server (140, 160) des DLT-Systems (182) bereitgestellt werden, wobei das DLT-System (182) mindestens einen Smart-Contract bereitstellt, wobei der mindestens eine Smart- Contract Programminstruktionen zu einem Einträgen und Prüfen von Lieferaufträgen (190), Auftragsbestätigungen (191) und/oder Warenausgangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger und/oder zu einem Validieren der Warenlieferungen umfasst, wobei das DLT-System (182) dazu konfiguriert ist, das Verfahrens nach einem der Ansprüche 1 bis 11 auszuführen.
16. Computerprogramm zur Kontrolle einer Warenlieferung von einem Warensender an einen Warenempfänger unter Verwendung eines zugangsbeschränkten DLT-Systems (182), welches einen ersten dem Warenempfänger zugeordneten DLT-Knoten und einen zweiten dem Warensender zugeordneten DLT-Knoten umfasst, wobei das Computerprogramm mindestens einen Smart-Contract bereitstellt, wobei der mindestens eine Smart-Contract Programminstruktionen zu einem Einträgen und Prüfen von Lieferaufträgen (190), Auftragsbestätigungen (191) und/oder Warenausgangsprotokollen im Zuge von Warenlieferungen des Warensenders an den Warenempfänger und/oder zu einem Validieren der Warenlieferungen umfasst, wobei das Computerprogramm Programminstruktionen zum Ausführen des Verfahrens nach einem der Ansprüche 1 bis 11 umfasst.
EP23772286.3A 2022-09-23 2023-09-22 Verwendung eines distributed-ledger-systems zur kontrolle von warenlieferungen Pending EP4591501A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP22197305 2022-09-23
PCT/EP2023/076270 WO2024062109A1 (de) 2022-09-23 2023-09-22 Verwendung eines distributed-ledger-systems zur kontrolle von warenlieferungen

Publications (1)

Publication Number Publication Date
EP4591501A1 true EP4591501A1 (de) 2025-07-30

Family

ID=83438580

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23772286.3A Pending EP4591501A1 (de) 2022-09-23 2023-09-22 Verwendung eines distributed-ledger-systems zur kontrolle von warenlieferungen

Country Status (8)

Country Link
US (1) US20240311886A2 (de)
EP (1) EP4591501A1 (de)
JP (1) JP2025531048A (de)
KR (1) KR20250076562A (de)
CN (1) CN119908092A (de)
AU (1) AU2023345582A1 (de)
MX (1) MX2025002968A (de)
WO (1) WO2024062109A1 (de)

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5983198A (en) * 1996-04-23 1999-11-09 Novus International, Inc. Integrated system monitoring use of materials, controlling and monitoring delivery of materials and providing automated billing of delivered materials
US20180096175A1 (en) * 2016-10-01 2018-04-05 James L. Schmeling Blockchain Enabled Packaging
US10255600B2 (en) * 2014-06-16 2019-04-09 Bank Of America Corporation Cryptocurrency offline vault storage system
US10740844B2 (en) * 2016-09-26 2020-08-11 Shapeshift Ag System and method of managing trustless asset portfolios
MA52666A (fr) * 2017-10-27 2020-09-02 Bxb Digital Pty Ltd Systèmes et procédés d'exécution de contrats intelligents au moyen d'une chaîne de blocs
US11017405B2 (en) * 2017-12-29 2021-05-25 GoPublic, Inc. Blockchain compliance platform and system for regulated transactions
US10855749B2 (en) * 2018-07-03 2020-12-01 Wandisco Inc. Methods, devices and systems for a distributed coordination engine-based exchange that implements a blockchain distributed ledger
US11170386B2 (en) * 2019-02-28 2021-11-09 Accenture Global Solutions Limited Environmental telemetry supply chain system
US11522690B2 (en) * 2019-06-07 2022-12-06 Bengala Technologies, Llc Supply chain management system
EP3970091A1 (de) * 2019-07-26 2022-03-23 Siemens Aktiengesellschaft Anpassung eines produktionsprozesses, edge-vorrichtung eines industriellen steuerungssystems und produktbestellungsverfahren
CN115398463A (zh) * 2020-10-09 2022-11-25 支付宝(杭州)信息技术有限公司 管理基于区块链的可信交易服务

Also Published As

Publication number Publication date
WO2024062109A1 (de) 2024-03-28
AU2023345582A1 (en) 2025-02-27
US20240311886A2 (en) 2024-09-19
JP2025531048A (ja) 2025-09-19
US20240104620A1 (en) 2024-03-28
MX2025002968A (es) 2025-06-02
CN119908092A (zh) 2025-04-29
KR20250076562A (ko) 2025-05-29

Similar Documents

Publication Publication Date Title
EP4111348B1 (de) Verfahren zum direkten übertragen von elektronischen münzdatensätzen zwischen endgeräten, bezahlsystem, währungssystem und überwachungseinheit
CN110599181B (zh) 基于区块链的数据处理方法、装置和设备及存储介质
DE102018122997A1 (de) Blockkettenentität, kettenexterne entität, zertifizierungsvorrichtung für blockkettenoperationen und verfahren zum durchführen einer kooperation zwischen einer blockkettenentität und einer kettenexternen entität
DE102021122557A1 (de) Konformitätsmechanismen in blockchain-netzwerken
EP4254234A1 (de) Ausstellen eines digitalen credentials für eine entität
DE102012102867A1 (de) Vorrichtung und Verfahren zum Online-ID-Handling
EP4092958A1 (de) Ausstellen eines digitalen verifizierbaren credentials
US20210273780A1 (en) Encrypted blockchain voting system
DE112023003641T5 (de) Über blockchain-netzwerke übergreifende berechnung in zusammenarbeit
EP3777088A1 (de) Verfahren und system zum steuern einer freigabe einer ressource
WO2022233454A1 (de) Verfahren zum registrieren eines elektronischen münzdatensatzes in einem münzregister; ein münzregister; eine teilnehmereinheit und ein computerprogrammprodukt
DE202018102306U1 (de) Systeme zur persönlichen Identifizierung und Verifizierung
WO2020246924A1 (en) Trading proposal arrangement, system and method
WO2022037999A1 (de) Systeme und verfahren zur digitalen beglaubigung von nutzungsdaten einer automatisierungsanlage
CN111861479A (zh) 一种基于区块链和5g技术的金融机构客户身份识别方法
EP4591501A1 (de) Verwendung eines distributed-ledger-systems zur kontrolle von warenlieferungen
WO2025119788A1 (de) Kontrolle und steuerung von abfertigungsschritten einer wareneinheit
US20160358262A1 (en) System for use of retirement funds for investment
EP3283999B1 (de) Elektronisches system zur erzeugung eines zertifikats
DE102021129047B4 (de) Selektiv anonymisierende Überweisung einer Kryptowährung
EP4511784A1 (de) Vorrichtungen, system und verfahren zum elektronischen bargeldlosen bezahlen
HK40015567B (en) Method, apparatus, device, and storage medium for data processing based on blockchain
HK40015567A (en) Method, apparatus, device, and storage medium for data processing based on blockchain
DE102013108472A1 (de) Verfahren und Vorrichtung zum elektronischen Integritätsschutz
CN114186986A (zh) 通证变更方法、装置、设备及存储介质

Legal Events

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

Free format text: STATUS: UNKNOWN

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

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

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

Free format text: ORIGINAL CODE: 0009012

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250423

AK Designated contracting states

Kind code of ref document: A1

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

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)