Flexible handling of data processing rules in decentral systems

Abstract

The present disclosure relates to the flexible handling of data processing rule(s) defining permission(s), obligation(s) and / or prohibition(s) of data consumer(s) with respect to the processing of data associated with such data processing rule(s) within decentral systems. The disclosure relates to a method, an apparatus and a computer element for controlling access to digital assets associated with supply chain product(s), for monitoring and / or controlling generation of such digital assets and for gathering such digital assets via a decentral communication protocol.

Description

[0001] 241022

[0002] FLEXIBLE HANDLING OF DATA PROCESSING RULES IN DECENTRAL SYSTEMS

[0003] TECHNICAL FIELD

[0004] The present disclosure relates to the flexible handling of data processing rule(s) defining permission(s), obligation(s) and / or prohibition(s) of data consumer(s) with respect to the processing of data associated with such data processing rule(s) within decentral systems. The disclosure relates to a method, an apparatus and a computer element for controlling access to digital assets associated with supply chain product(s), for monitoring and / or controlling generation of such digital assets and for gathering such digital assets via a decentral communication protocol.

[0005] TECHNICAL BACKGROUND

[0006] In the supply of materials for a production multiple regulatory requirements need to be met, which differ depending on the material. To fulfil such regulatory requirements, material producers need to provide material data to data consumers, such as data consumer(s) producing product(s) using materials associated with such material data. To ensure that such material data can only be accessed by authorized data consumers, access policies defining access to such data and processing of such material data the data consumers can be linked to the material data. Processing of the material data may be governed by highly complex processing rule(s) defining contractual obligation(s) of the data owner of the material data and a data consumer intending to consume the material data. Owing to such highly complex processing rule(s), generation and validation of policy data reflecting such processing rule(s) is cumbersome and complicated. Hence, there is a need to simplify generation and validation of highly complex processing rule(s).

[0007] SUMMARY OF THE INVENTION

[0008] Disclosed is in one aspect a method, in particular a computer-implemented method executed by one or more local data provider component(s) of a local data provider compute and storage environment associated with a supply chain product producer, for controlling access to a digital asset associated with the supply chain product by one or more decentral consumer network node(s) connected to one or more local data consumer component(s) of a local data consumer compute and storage environment via a decentral communication protocol, wherein the access is controlled by a data owner, in particular the supply chain product producer, of the digital asset, optionally wherein the one or more local data consumer component(s) and the one or more data provider component(s) are connected via local communication protocol(s) to at least one orchestration component, optionally wherein the at least one orchestration component is configured to orchestrate the one or more local data consumer component(s) and the one or more local data provider component(s), e.g. via local communication protocol(s), for 241022

[0009] 2 exchange of digital assets between decentral consumer network node(s) connected to the one or more local consumer component(s) and decentral provider network node(s) connected to the one or more local provider component(s), e.g. via decentral communication protocol(s), the method comprising: providing the digital asset including supply chain product data and decentral asset identifier(s) associated with the supply chain product data, providing contract data including processing rule data associated with the processing of the digital asset by one or more of the local data consumer component(s), generating a digital representation of the contract data by computing a hash value of at least a part of the contract data and generating a representation for accessing the contract data, wherein the generated digital representation of the contract data includes the generated representation for accessing the contract data and the computed hash value, linking the generated digital representation of the contract data to the digital asset, providing the digital representation of the contract data linked to the digital asset for controlling access to the digital asset at least in part based on the contract data associated with the digital asset, wherein the digital representation of the contract data is provided for access by the decentral consumer network node(s) via to the decentral communication protocol or provided to one or more of the local data consumer component(s) via at least one orchestration component according to a local communication protocol.

[0010] Disclosed is in another aspect an apparatus, in particular a local data provider compute and storage environment associated with a supply chain product producer, for controlling access to a digital asset associated with a supply chain product by one or more decentral consumer network node(s) connected to one or more local data consumer component(s) of a local data consumer compute and storage environment via a decentral communication protocol, wherein the access is controlled by a data owner, in particular the supply chain product producer, of the digital asset, optionally wherein the one or more local data consumer component(s) and the one or more data provider component(s) are connected via local communication protocol(s) to at least one orchestration component, optionally wherein the at least one orchestration component is configured to orchestrate the one or more local data consumer component(s) and the one or more local data provider component(s), e.g. via local communication protocol(s), for exchange of digital assets between decentral consumer network node(s) connected to the one or more local consumer component(s) and decentral provider network node(s) connected to the one or more local provider component(s), e.g. via decentral communication protocol(s), the apparatus comprising: a data providing interface configured to provide

[0011] • the digital asset including supply chain product data and decentral asset identifier(s) associated with the supply chain product data,

[0012] • including processing rule data associated with the processing of the digital asset by one or more of the local data consumer component(s), 241022

[0013] 3 a digital representation generator configured to generate a digital representation of the contract data by computing a hash value of at least a part of the contract data and generating a representation for accessing the contract data, wherein the generated digital representation of the contract data includes the generated representation for accessing the contract data and the computed hash value, a linking unit configured to link the generated digital representation of the contract data to the digital asset, a data providing interface configured to provide digital representation of the contract data linked to the digital asset for controlling access to the digital asset at least in part based on the contract data associated with the digital asset, wherein the digital representation of the contract data is provided for access by the decentral consumer network node(s) via to the decentral communication protocol or provided to one or more of the local data consumer component(s) via at least one orchestration component according to a local communication protocol.

[0014] Disclosed is in another aspect a method, in particular a computer-implemented method executed by one or more local data consumer component(s) of a local data consumer compute and storage environment associated with a data consumer, for monitoring and / or controlling generation of a digital asset to be provided for access via a decentral communication protocol by one or more decentral consumer network node(s) connected to one or more of the local data consumer component(s) of the local data consumer compute and storage environment associated with the data consumer, wherein the digital asset is associated with a supply chain product produced or producible by a supply chain product production associated with a supply chain product producer and wherein the digital asset is generated by one or more local data provider component(s) of a local data provider compute and storage environment, optionally wherein the one or more local data consumer component(s) and the one or more data provider component(s) are connected via local communication protocol(s) to at least one orchestration component, optionally wherein the at least one orchestration component is configured to orchestrate the one or more local data consumer component(s) and the one or more local data provider component(s), e.g. via local communication protocol(s), for exchange of digital assets between decentral consumer network node(s) connected to the one or more local consumer component(s) and decentral provider network node(s) connected to the one or more local provider component(s), e.g. via decentral communication protocol(s), the method comprising: providing data associated with a product produced or producible by a production at least in part from the supply chain product, providing - based on the provided data associated with a product - contract data including rule(s) for generating the digital asset by one or more local data provider component(s) of a local data provider compute and storage environment associated with the supply chain product producer, generating a digital representation of the contract data by computing a hash value of at least a part of the contract data and generating a representation for accessing the contract data, wherein the generated digital 241022

[0015] 4 representation of the contract data includes the generated representation for accessing the contract data and the computed hash value, generating - based on the digital representation of the contract data - a trigger for generation of the digital asset and for provisioning of the generated digital asset for access via the decentral communication protocol by the decentral consumer network node(s), providing the generated trigger via a local communication protocol to at least one orchestration component for triggering - at one or more of the local data provider component(s) - generation of the digital asset according to the rule(s) and for provisioning of the generated digital asset for access via the decentral communication protocol by the decentral consumer network node(s), optionally wherein the at least one orchestration component is configured to determine local identifier(s) associated with the local data provider compute and storage environment(s) based on the received trigger and to provide a request for generating and providing the digital asset via the local communication protocol to one or more of the local data provider component(s) associated with the determined local identifier(s), optionally wherein the trigger is provided to the orchestration component for providing the request via the local communication protocol from the orchestration component to at least a part of the one or more local data providing component(s), in particular the local data providing component(s) associated with the determined local identifier(s).

[0016] Disclosed is in yet another aspect an apparatus, in particular a local data consumer compute and storage environment associated with a data consumer, for monitoring and / or controlling generation of a digital asset to be provided for access via a decentral communication protocol by one or more decentral consumer network node(s) connected to one or more of the local data consumer component(s) of a local data consumer compute and storage environment associated with a data consumer, wherein the digital asset is associated with a supply chain product produced or producible by a supply chain product production associated with a supply chain product producer, optionally wherein the one or more local data consumer component(s) and the one or more data provider component(s) are connected via local communication protocol(s) to at least one orchestration component, optionally wherein the at least one orchestration component is configured to orchestrate the one or more local data consumer component(s) and the one or more local data provider component(s), e.g. via local communication protocol(s), for exchange of digital assets between decentral consumer network node(s) connected to the one or more local consumer component(s) and decentral provider network node(s) connected to the one or more local provider component(s), e.g. via decentral communication protocol(s), the apparatus comprising: a data providing interface configured to provide data associated with a product produced or producible by a production at least in part from the supply chain product, a contract providing interface configured to provide- based on the provided data associated with a product - contract data including rule(s) for generating the digital asset by one or more local data provider component(s) of a local data provider compute and storage environment associated with the supply chain product producer, 241022

[0017] 5 a digital representation generator configured to generate a digital representation of the contract data by computing a hash value of at least a part of the contract data and generating a representation for accessing the contract data, wherein the generated digital representation of the contract data includes the generated representation for accessing the contract data and the computed hash value, a trigger generator configured to generate - based on the digital representation of the contract data - a trigger for generation of the digital asset and for provisioning of the generated digital asset for access via the decentral communication protocol by the decentral consumer network node(s), a local communication interface configured to provide the generated trigger via the local communication protocol to the at least one orchestration component for triggering generation of the digital asset according to the rule(s) and for provisioning of the generated digital asset for access via the decentral communication protocol by the decentral consumer network node(s).

[0018] Disclosed is in yet another aspect a method, in particular a computer-implemented method executed by one or more local data consumer component(s) of a local data consumer compute and storage environment associated with a data consumer, for gathering a digital asset associated with a supply chain product via a decentral communication protocol from decentral provider network node(s) connected to local data provider component(s) of a local data provider compute and storage environment storing the digital asset, wherein the digital asset is gathered via the decentral communication protocol by one or more decentral consumer network node(s) connected to one or more of the local data consumer component(s) of the local data consumer compute and storage environment, optionally wherein the one or more local data consumer component(s) and the one or more data provider component(s) are connected via local communication protocol(s) to at least one orchestration component, optionally wherein the at least one orchestration component is configured to orchestrate the one or more local data consumer component(s) and the one or more local data provider component(s), e.g. via local communication protocol(s), for exchange of digital assets between decentral consumer network node(s) connected to the one or more local consumer component(s) and decentral provider network node(s) connected to the one or more local provider component(s), e.g. via decentral communication protocol(s), the method comprising: providing policy data associated with the digital asset and a digital representation of contract data associated with the digital asset, wherein the policy data includes decentral asset identifier(s) associated with the digital asset and processing rule data associated with the processing of the digital asset by one or more of the local data consumer component(s), wherein the processing rule data includes a digital representation of contract data or wherein the digital representation of contract data is provided in combination with the policy data, and wherein the digital representation of contract data includes a representation for accessing the contract data and a hash value computed from at least a part of the contract data, gathering the contract data based on the digital representation of contract data, 241022

[0019] 6 verifying the contract data based on the digital representation of contract data, based on verified contract data, validating the policy data and optionally the contract data, based on the validated policy data and optionally the validated contract data, gathering the digital asset via the decentral communication protocol from the decentral provider network node(s).

[0020] Disclosed is in yet a further aspect an apparatus, in particular a local data consumer compute and storage environment associated with a data consumer, for gathering a digital asset associated with a supply chain product via a decentral communication protocol from decentral provider network node(s) connected to local data provider component(s) of a local data provider compute and storage environment storing the digital asset, wherein the digital asset is gathered via the decentral communication protocol by one or more decentral consumer network node(s) connected to one or more local data consumer component(s) of a local data consumer compute and storage environment, optionally wherein the one or more local data consumer component(s) and the one or more data provider component(s) are connected via local communication protocol(s) to at least one orchestration component, optionally wherein the at least one orchestration component is configured to orchestrate the one or more local data consumer component(s) and the one or more local data provider component(s), e.g. via local communication protocol(s), for exchange of digital assets between decentral consumer network node(s) connected to the one or more local consumer component(s) and decentral provider network node(s) connected to the one or more local provider component(s), e.g. via decentral communication protocol(s), the apparatus comprising: a data providing interface configured to provide policy data associated with the digital asset and a digital representation of contract data associated with the digital asset, wherein the policy data includes decentral asset identifier(s) associated with the digital asset and processing rule data associated with the processing of the digital asset by one or more of the local data consumer component(s), wherein the processing rule data includes a digital representation of contract data or wherein the digital representation of contract data is provided in combination with the policy data, and wherein the digital representation of contract data includes a representation for accessing the contract data and a hash value computed from at least a part of the contract data, a contract data collector configured to gather the contract data based on the digital representation of contract data, a verifying engine configured to verify the contract data based on the digital representation of contract data, a validation engine configured to validate - based on verified contract data - the policy data and optionally the contract data, a decentral network interface configured to gather - based on validated policy data and optionally contract data - the digital asset via the decentral communication protocol from the decentral provider network node(s). 241022

[0021] 7

[0022] In yet another aspect the present disclosure relates to a computer element with instructions, which when executed on one or more computing node(s) are configured to carry out the steps of the method(s) of the present disclosure or are configured to be carried out by the apparatus(es) of the present disclosure.

[0023] Any disclosure, embodiments and examples described herein relate to the methods, the apparatuses and computer elements lined out above and below. Advantageously, the benefits provided by any of the embodiments and examples equally apply to all other embodiments and examples.

[0024] EMBODIMENTS

[0025] In the following, embodiments of the present disclosure will be outlined by ways of embodiments and / or examples. It is to be understood that the present disclosure is not limited to said embodiments and / or examples.

[0026] Supply chain product data associated with supply chain products may be exchanged between the supply chain product producer and the supply chain product consumer or a downstream participant of the supply chain product consumer, such as an end-product producer, via a decentral network. The decentral network allows exchange of such supply chain product data in a standardized and reliable manner via a peer-to-peer connection between a decentral provider network node connected to local data provider component(s) of a local data provider compute and storage environment associated with the supply chain product producer and a decentral consumer network node connected to one or more local data consumer component(s) of a local data consumer compute and storage environment associated with the supply chain product consumer or the downstream participant. The supply chain product data may be used by the supply chain product consumer or the downstream participant to generate digital product passport(s) associated with the end-product or components / materials included therein. These digital product passport(s) may enhance transparency on the composition of the end-product, allowing improved recycling and / or re-use of the end-product due to the enhanced transparency on the material composition. The supply chain product data may be linked to policy data defining access to such data and processing of such data by the local data consumer component(s) to ensure that such data is only accessed by authorized decentral consumer network nodes and processed by the local data consumer component(s) in line with processing rule(s) defined in such policy data. Hence, it is crucial that such policy data includes all processing rule(s) with respect to the processing of the supply chain product data by the local data consumer component(s). This, however, may result in processing rule(s) to be included in such policy data. Generation and validation of such complex processing rule(s) reflecting complex contractual obligations is cumbersome and complicated, hence posing a hurdle to negotiate such complex processing rule(s) according to decentral communication protocols in a standardized manner.

[0027] By linking the digital representation of contract data to digital assets, the data owners of the digital assets may flexibly define processing rule(s) with respect to the processing of the digital asset by the local data consumer 241022

[0028] 8 component(s) without having to rely on agreements having been signed by the data consumers and including processing rule(s) and without having to convert such processing rule(s) according to data model used to generate policy data that can be negotiated between decentral provider network nodes and decentral consumer network nodes via the decentral communication protocol in a standardized manner. Such data models may not be able to accommodate complex processing rule(s) included in the contract data, hence the data owner may be restricted in the use of processing rule(s) included in the contract data when converting the contract data into policy data using such data models. The use of a digital representation of the contract data avoids dependency on existing agreements signed by the data consumers and conversion of contract data into policy data using such data models, hence allowing to link contract data to the digital assets in a flexible and reliable manner irrespective of the complexity of the processing rule(s) included in such contract data and the existence of signed agreements. Avoiding conversion results in reduced computing resources, hence improving the environmental impact of the digital asset sharing within the decentral network. This way, digital asset(s) may be shared in a reliable yet secure manner under full control of the data owner of the digital assets despite limitations of processing rule(s) included in signed agreements and / or of data models used to generated policy data to enable negotiation of the policy data according to decentral communication protocols in a standardized manner. This way, efficient generation of product passports with a higher data quality of the data included in the digital product passport is enabled, allowing more efficient processing, such as recycling and / or re-use of the product based on the data included in the digital product passports.

[0029] By using contract data in addition to policy data, processing of provided digital asset(s) by the local data consumer component(s) associated with the data consumer(s) may be flexibly adjusted and / or tailored to the needs of the data provider, without having to convert the contract data according to a predefined data model into policy data and without having to rely on existing agreements signed by the data consumer and including the terms and conditions required by the data provider with respect to the processing of the digital asset. This enables efficient sharing of digital asset(s) within the decentral network under full control of the data owner of the respective digital asset(s). This way, efficient generation of product passports associated with product(s) produced from output product(s) associated with such digital asset(s) is enabled allowing more efficient processing, such as recycling and / or re-use of the product based on the data included in the digital product passports.

[0030] By verifying the data integrity of the contract data prior to gathering the digital asset(s) associated with such contract data, trust and acceptance of data consumer(s) with respect to the use of additional processing rule(s) included in the contract data besides the processing rules included in the policy data may be improved. This way, conversion of complex contractual obligation(s) contained in the contract data into policy data may be avoided while still allowing to flexibly adjust the policy data with respect to multiple decentral consumer network node(s) and / or different confidentiality level(s) associated with the data included in the digital assets. In addition, the verification avoids interruption(s) of the processing of the gathered digital assets by the local data consumer 241022

[0031] 9 component(s) due to modification(s) of the contract data by the local data provider component(s) after acceptance of the contract data by the data consumer. This generated trust may result in a more efficient processing of the digital assets and hence also in a more reliable and efficient generation of digital product passport(s) based on processed digital assets is ensured, allowing a higher data quality of the data included in the digital product passport and hence a more efficient processing, such as recycling and / or re-use, of the product based on the data included in the digital product passports.

[0032] By providing the rule(s) associated with the generation of digital asset(s) via the orchestration component to the local data provider component(s), the data consumer(s) may ensure that the digital assets are generated according to the rule(s) defined by the contract data. This way the generated digital assets may include the data and may possess the data structure the local data consumer component(s) expect for processing. This allows efficient processing of gathered digital assets and hence also efficient generation of digital product passports associated with the product based on the processed digital assets. By providing the contract data associated with the processing of digital asset(s) via the digital representation to the local data provider component(s), the data consumer(s) may render processing of digital asset(s) transparent to such data provider(s) prior to the data provider(s) providing any digital asset(s) to such data consumer(s). This allows local data provider node(s) to determine whether such processing complies with processing rule(s) associated with such digital asset(s) prior to generating and / or providing such digital asset(s) for access to decentral consumer network node(s) associate with such data consumer(s). Such transparency may aid in efficient generation of digital asset(s) and efficient processing of consumed digital assets since failure of asset transfer due to lack of consent to processing rule(s) associated with the digital assets or failure of processing due to lack of data or incompatible data structures may be avoided.

[0033] By validating permission(s), obligation(s) and / or prohibition(s) included in policy data and optionally contractual obligation(s) included in contract data by the consumer(s) prior to initiating transfer of the digital assets associated with the policy data and the contract data, a reliable processing of the digital assets by instruction(s) executed by the local data consumer component(s) is enabled while avoiding gathering of non-processable digital assets. This way, it can be ensured that digital assets are only gathered from decentral provider network nodes according to the decentral communication protocol if associated policy data and contract data allows to process the digital assets according to instructions executed by the local data consumer component(s). This avoids unnecessary data transactions within the decentral network, allowing to reduce the environmental impact associated with the generation of digital product passports and improving the latency, bandwidth and stability of the decentral network. This aids in improving the trust of data providers with respect to adherence to processing rule(s) defined by the policy data and the contract data, enabling reliable sharing of digital assets within the decentral network. This way, the data quality of the digital product passport(s) generated based on gathered digital assets can be improved, allowing more efficient processing of the products based on data included in such passport(s). 10

[0034] Various units, entities, nodes or other computing components may be described as “configured to” perform a task or tasks. Configured to shall recite structure meaning “having circuitry that” performs the task or tasks on operation. The units, circuits, entities, nodes or other computing components can be configured to perform the task even when the unit / circuit / component is not operating. The units, circuits, entities, nodes or other computing components that form the structure corresponding to “configured to” may include hardware circuits and / or memory storing program instructions executable to implement the operation. The units, circuits, entities, nodes or other computing components may be described as performing a task or tasks, for convenience in the description. Such descriptions shall be interpreted as including the phrase “configured to.”

[0035] In general, the methods, apparatuses, systems, computer elements, nodes or other computing components described herein may include memory, software components and hardware components. The memory can include volatile memory such as static or dynamic random-access memory and / or nonvolatile memory such as optical or magnetic disk storage, flash memory, programmable read-only memories, etc. The hardware components may include any combination of combinatoric logic circuitry, clocked storage devices such as flops, registers, latches, etc., finite state machines, memory such as static random-access memory or embedded dynamic random-access memory, custom designed circuitry, programmable logic arrays, etc.

[0036] The supply chain product may include production inputs for producing the product. The supply chain product may be produced or producible by a supply chain product production from one or more production input(s). The supply chain product(s) may be produced or producible by upstream production stage(s) with respect to the product production stage. Produced supply chain product(s) may be physical entity / ies of supply chain product(s) having been produced by the supply chain product production. Producible supply chain product(s) may not yet have been produced by the supply chain product production but may be producible by one or more production process(es) performed within the supply chain product production. Producible supply chain product(s) may include supply chain product(s) planned to be produced, for example based on demand data received from downstream production stages. The supply chain product may be a discrete product, such as a component or a component assembly. The supply chain product may be a battery or a battery component. The supply chain product may be a chemical product.

[0037] The product may be a discrete product. The product may be a component, a component-assembly or an endproduct. The product may be a battery or a battery component. The product may be an electronic product. The product may be a chemical product.

[0038] The chemical product may include inorganic chemical products and organic chemical products. Inorganic chemical products may be devoid of carbon atoms and / or carbon-hydrogen bond(s) while organic chemical products may include at least one carbon atom and / or at least one carbon-hydrogen bond. The chemical product may be a naturally occurring chemical product, i.e. any unprocessed chemical substance that is found in nature, such as 11 chemicals from plants, micro-organisms, animals, the earth and the sea or any chemical substance that is found in nature and extracted using a process that does not change its chemical composition. The chemical product may be produced via one or more process steps. The process steps may involve chemical reactions and / or physical processes. The physical process(es) may involve the use of chemical production inputs, such as chemical materials. Physical process(es) may include mixing, dispersing, extrusion, molding, casting, weaving, knitting, coating and / or filling.

[0039] Inorganic chemical products may include aluminium, iron, steel, copper, zinc, lead, nickel, titanium, magnesium, chromium, tin, manganese and / or cobalt. Organic chemical products may include detergents, cosmetic products, paints, lubricants, paper, pulp paper, paper boards and / or polymer products. Polymer products may include chemical products including or consisting of at least one polymer, such as synthetic textiles, footwear, mattresses, absorbent hygiene products, toys, fishing nets and fishing gear. The polymer may be selected from polyolefins, polyvinyls, polystyrenes, polyesters, polyethers, polyurethanes, poly(meth)acrylates, polyamides, polycarbonates, polyacetals, fluoropolymers, epoxides, silicons, polyimides, polylactic acid, cellulose, lignin, copolymers of such polymers and / or blends of such polymers. Organic chemical products may include compositions including alkanes, alkenes and alkynes, aromatic compounds, alcohols, aldeyhdes, ketons, carboxylic acids, esters, ethers, amines, amides, nitriles and / or halides.

[0040] The supply chain product and the product may be part of a product ecosystem. The product ecosystem may include chemical products. The product ecosystem may include production stage(s) for producing the product. The product ecosystem may include processing chains to process used products resulting from the use of produced products. Processing chains may include recycling chains to recycle at least part of the used product or a component thereof. Processing chains may include re-use chains to re-use the used product. The product ecosystem may include various participants, such as raw input material producers, chemical product producers, chemical product users, end-product producers, end-product users, EOL product collectors and recyclers. The participants may be associated with the local data provider compute and storage environment(s) and / or the local data consumer compute and storage environment(s). Participants associated with the local data provider compute and storage environment(s) may include data providers. Participants associated with the local data provider compute and storage environment(s) may include data providers, such as supply chain product producers. Participants associated with the local data consumer compute and storage environment(s) may include data consumers, such as supply chain product consumer(s), product producer(s) and / or entity / les generating the digital product passport(s).

[0041] The local data provider compute and storage environment(s) may include one or more component(s) configured to perform different functionalities. The component(s) may include one or more local data provider component(s) configured to generate and / or provide digital assets, one or more local data provider component(s) configured to 241022

[0042] 12 request consumption of generated digital asset(s) and / or one or more local data provider component(s) configured to orchestrate, e.g. to monitor and / or control, generation and / or provision of digital assets. Requesting consumption of generated digital assets from or by the one or more decentral consumer network node(s) connected to one or more local data consumer component(s) may include triggering consumption of the generated digital assets by the decentral data consumer network node(s) through the decentral network. The local data provider compute and storage environment and the one or more local data provider component(s) included therein may be associated with a local identifier (also referred to as tenant identifier) uniquely identifying such local environment within other environments. The local data consumer compute and storage environment(s) may include one or more component(s) configured to perform different functionalities. The component(s) may include one or more local data consumer component(s) configured to trigger access of digital assets via the decentral network protocol, one or more local data consumer component(s) configured to process accessed digital assets and / or one or more local data consumer component(s) configured to orchestrate, e.g. to monitor and / or control, accessing of digital assets and / or processing of accessed digital assets. The local data consumer compute and storage environment and the one or more local data consumer component(s) included therein may be associated with a local identifier (also referred to as tenant identifier) uniquely identifying such local environment within other environments.

[0043] Tenants may also be referred to as one or more local data provider compute and / or storage environments and / or data local data consumer compute and / or storage environments. Tenant component(s) may also be referred to as one or more local data provider component(s) and / or one or more local data consumer component(s). The tenant component(s) may be configured to communicate with the orchestration component via the local communication protocol(s). The tenant component(s) may be configured to communicate with other tenant component(s) via or by using the orchestration component. The tenant component(s) may be configured to communicate with other tenant component(s) solely through the orchestration component.

[0044] The local orchestration compute and storage environment may include one or more component(s) configured to perform different functionalities. The component(s) may include one or more local orchestration component(s) configured to receive requests via the local communication protocol(s) from local data provider component(s) and / or local data consumer component(s), one or more local orchestration component(s) configured to process the received requests, one or more local orchestration component(s) configured to generate and provide requests via the local communication protocol(s) to local data provider component(s) and / or local data consumer component(s), one or more component(s) configured to store data model(s) received via the local communication protocol(s) from local data consumer component(s) and / or to store mappings between local identifiers associated with the local data provider compute and / or storage environments and the local data consumer compute and / or storage environments and decentral participant identifiers associated with such compute and / or storage environments. The orchestration component may be configured to orchestrate, e.g. control and / or monitor, data 241022

[0045] 13 exchange via the decentral network by exchanging, receiving and / or sending, requests via the local communication protocol with, from and / or to local data consumer and / or provider component(s). The orchestration component may be communicatively connected to the tenant component(s). The orchestration component may be configured to communicate with tenant component(s) based on the local communication protocol. The orchestration component may be configured to communicate with individual tenant component(s) based on the local communication protocol. The orchestration component may be configured to orchestrate communication channels to multiple tenant components. The orchestration component may be configured to centrally orchestrate communication to multiple tenant components. The orchestration component may be configured to centrally orchestrate communication between multiple tenant components indirectly, e.g. through or via the orchestration component. The orchestration component may implement network interface(s) for communication with the tenants via the local communication protocol. The network interface(s) may include API(s), such as a REST API(s).

[0046] The local compute and / or storage environment may include distributed compute and / or storage environments. The distributed compute and / or storage environments may be controlled by the data providers, such as supply chain product producers and / or supply chain productions, data consumers, such as supply chain product producers, product producers, product productions, or entities orchestrating the tenants.

[0047] The local communication protocol may facilitate communication in distributed compute and storage environment. The local communication protocol may include web protocols, such as HTTP / HTTPS methods, URI, MIME types or combinations thereof. The local communication protocol may implement stateless communication. Stateless communication may include requests and triggers that include all data required to process the request or trigger by the at least one orchestration component. This way, the orchestration component(s) do not have to retain session information, allowing efficient communication with multiple tenants and improving scalability and reliability. The local communication protocol may be configured to communicatively couple the orchestration component with multiple tenant components. The local communication protocol may be configured to decouple communication between tenant components. The local communication protocol may be configured to open communication channel between the orchestration component and multiple tenant components. The local communication protocol may be configured to open communication channel between the orchestration component and multiple tenant components per tenant component. The local communication protocol may be configured to close communication channel between the orchestration component and multiple tenant components e.g. per tenant component.

[0048] The local data provider component(s) may be connected to decentral provider network node(s) of the decentral network. The decentral network may be associated with participants of the product ecosystem. The local data consumer component(s) may be connected to decentral consumer network node(s) of the decentral network. The decentral network nodes may be configured to perform data transactions or data exchanges, e.g. via peer-to-peer communication. The decentral provider network node(s) may be associated with data providers, such as supply 241022

[0049] 14 chain product producer and / or the supply chain product productions. The decentral consumer network node(s) may be associated with data consumers, such as supply chain product users, product producers and / or entities generating digital product passports associated with the product. The data transactions or exchanges may be based on a decentral network protocol establishing peer-to-peer communication between the decentral network nodes. The decentral network nodes of the decentral network may be configured to provide or send digital assets to another decentral network node of the decentral network and / or to ingest or receive digital assets from another decentral network node of the decentral network. Providing digital assets for access via the decentral network by decentral consumer network node(s) may include indirect or direct access of the decentral network consumer node(s) to the digital assets.

[0050] The decentral network protocol may specify a communication protocol for peer-to-peer communication according to a communication standard defined for the decentral network. The decentral network protocol may relate to decentral asset identifier(s) identifying the at least one supply chain product and / or decentral participant identifiers related to the least one participant node and / or authentication and / or authorization mechanism(s) authentication and / or authorizing the at least one participant node for data exchange.

[0051] The data transactions or exchanges may be based on the decentral network protocol including decentral asset identifier(s) associated with at the least one supply chain product and / or decentral participant identifiers associated with the decentral network nodes. Based on the decentral participant identifier(s) associated with the decentral network nodes, the decentral network nodes for peer-to-peer communication may be identified. Based on the decentral asset identifier(s) of the supply chain products the digital assets associated with the supply chain product(s) for peer-to-peer data exchange may be identified.

[0052] The digital assets may include the decentral asset identifier(s) associated with the supply chain product. The asset identifier(s) may be linked to one or more supply chain product data points associated with the supply chain product. The decentral asset identifier(s) may be linked to the one or more property data points associated with property / ies of the supply chain product. Property may include chemical and / or physical properties, emission properties, recycled content properties, biobased content properties, renewable content properties and / or production properties associated with the production of the supply chain product. Emission properties may include the carbon footprint of the supply chain product. The one or more property data points may be linked to the decentral asset identifier included in the digital asset. The one or more supply chain product data points, or the one or more property data points may be stored in local data base of the respective local data provider compute and / or storage environment for access by decentral consumer network node(s) associated with local data consumer component(s), e.g. authenticated and / or authorized for such access. The one or more supply chain product data points, or one or more property data points may be stored in the respective local data provider 241022

[0053] 15 compute and / or storage environment for transfer to the decentral consumer network node(s) associated with local data consumer component(s), e.g. when accessed or on providing the supply chain product.

[0054] The decentral asset identifier(s) may comprise any unique identifier uniquely associated with the physical entity of the supply chain product and the supply chain product data points and / or the property data points. Decentral asset identifier(s) in this context may refer to the use of the asset identifier(s) for exchange of the digital assets via the decentral network protocol. The decentral asset identifier(s) may relate to local identifiers such as unique locators and / or decentral identifier(s) as defined by the decentral network. The decentral identifier(s) may include Universally Unique IDentifier(s) (UUID(s)) and / or Digital IDentifier(s) (DID(s)). The decentral identifier(s) may be issued by a central or decentral identity issuer of the decentral network according to the decentral network protocol. The decentral asset identifier(s) may not be discoverable by participant nodes of the decentral network according to the decentral network protocol. The decentral asset identifier(s) may be discoverable and / or accessible by participant nodes of the decentral network according to the decentral network protocol. The decentral asset identifier(s) may be linked to authentication and / or authorization information. Via the decentral asset identifier(s) and the unique association with the physical entity of the supply chain product and the supply chain product data points and / or the property data points, access to such data points may be controlled by the data owner of such data points, such as the supply chain product producer. This contrasts with central authority schemes, where identifiers are provided by such central authority and access to data is controlled by such central authority.

[0055] The decentral asset identifier(s) may be uniquely associated with the supply chain product or the physical entity of the supply chain product, e.g. as packaged for transportation to the supply chain product consumer. The decentral asset identifier(s) may be uniquely associated with the digital assets providing access to the supply chain product data associated with the supply chain product.

[0056] The decentral asset identifier(s) may be uniquely associated with the decentral participant identifier associated with the decentral provider network node configured to provide digital asset(s) the decentral identifier(s) are associated with and an endpoint of such decentral provider network node. The decentral asset identifier(s) may be uniquely associated with the decentral participant identifier associated with the decentral provider network node. The decentral provider network node may be any computing node or data storage structure providing an endpoint accessible for the decentral consumer network node(s) via the decentral network protocol. Decentral in this context may refer to implementations where the digital assets are stored in a local database associated with the data owner of the digital asset(s) and access to the digital assets stored in such local database is controlled by the data owner of the digital assets based on the decentral asset identifier(s) and decentral participant identifier(s) associated with decentral consumer network node(s). The data transactions or exchanges may be based on a decentral network protocol including authentication and / or authorization mechanism(s). Based on the authentication and / or authorization mechanism(s) a peer-to-peer network between participant nodes, e.g. decentral network nodes, of the decentral network may be established. The one or more authentication mechanism(s) may be associated with or linked to the decentral participant identifier(s) associated with the participant nodes of the decentral network. The one or more authentication mechanism(s) associated with the decentral participant identifier(s) may be provided to participant node(s) for authenticating the peer-to-peer communication between respective participant nodes. The one or more authentication mechanism(s) associated with the decentral participant identifier(s) may be accessible by the decentral provider network node and / or the decentral consumer network node. The one or more authorization mechanism(s) may include at least one authorization rule for providing and / or consuming and / or accessing digital assets. The one or more authorization mechanism(s) may be associated with or linked to the decentral participant identifier(s) associated with the participant nodes and / or the decentral asset identifier(s) associated with the digital assets. The one or more authorization mechanism(s) may be associated with or linked to the decentral asset identifier(s) related to digital assets to be accessed and / or exchanged. The decentral configuration allows for more efficient use of computing resources and strengthens control by each data owner of the decentral network.

[0057] The orchestration component may be associated with a configuration data base. The configuration data base may provide access to mapping data and respective one or more data model(s) provided by the one or more local data consumer component(s) for collecting properties of the supply chain product. The configuration data base may store the mapping data and one or more data model(s) provided by the one or more local data consumer component(s) for collecting properties of the supply chain product. The configuration data base may store the mapping data in key value pairs including pairs of local identifiers and decentral participant identifiers per tenant. The mapping data may further include endpoints of decentral provider network nodes connected to the one or more local data provider component(s), names of participants associated with local data provider compute and / or storage environments and / or names of participants associated with the local data consumer compute and / or storage environments.

[0058] The orchestration component may receive requests from the one or more local data consumer component(s) for generating digital asset(s) to be provided via the decentral network protocol of decentral network. In addition or alternatively, the orchestration component may receive requests from the one or more local data provider component(s) for consuming generated digital asset(s) via the decentral network protocol of decentral network. The request for generating digital asset(s) to be provided may include local identifier(s) associated with the one or more local data consumer component(s) and decentral participant identifier(s) associated with decentral data provider network node(s) connected to the local data provider compute and / or storage environment requested to generate the digital asset(s). The request for consuming generated digital asset(s) may include local identifier(s) associated with the one or more local data provider component(s) and decentral participant identifier(s) 241022

[0059] 17 associated with decentral data consumer network node(s) to be accessing the generated digital asset. Based on the local identifier(s) and the decentral participant identifier(s) included in the requests the orchestration component may identify the tenant the request was received by and the tenant(s) the request is to be provided to. Depending on the envisaged data transfer to be executed via the decentral network, the orchestration component orchestrates the data pipeline setup in the local environments of the tenants. The exchange of the actual digital assets is not executed via the orchestration component and the orchestration component does not have access to such digital assets. Hence the digital assets are transferred only via a peer-to-peer communication between decentral network nodes of the decentral network under full control of the data owner of the digital assets. The orchestration component only enables communication between tenants with respect to requests for digital assets or offers of digital assets and ensures that the digital asset(s) transferred via the decentral network adhere(s) to the data structure(s) and content the provider and / or recipient of such data expect. This way the digital assets associated with the supply chain products are kept under full control of the respective data owner of such digital assets, such as the supply chain product producer, while enabling secure and efficient transfer of such digital assets via the decentral network based on the orchestration of requests from tenants by the orchestration component. This way, discovery of endpoint(s) of respective decentral network node(s) and decentral asset identifier(s) of digital asset(s) to request the digital asset(s) and / or to offer digital asset(s) by querying the decentral network and configuration of such decentral network node(s) to process such data offer(s) can be avoided. This reduces the number of data transactions performed within the decentral network, reducing latency and energy consumption and hence also the environmental impact associated with the digital asset transfers via the decentral network.

[0060] The data owner may be an entity having access to the digital asset and controlling access by decentral consumer network node(s) to the digital asset. The data owner may be the supply chain product producer and / or the supply chain product owner. The data owner may be the entity operating the production producing the supply chain product. The digital assets may be accessible for the data owner. The digital assets may be stored in a database of or associated with the data owner for access by data consumer(s). The data owner may control access to the digital assets via the decentral asset identifiers.

[0061] Verifying the contract data may include verifying the data integrity of the contract data. Validation of the policy data may include validating permission(s), obligation(s) and / or prohibition(s) defined by the processing rule data included in the policy data. Validating the contract data may include validating the contractual obligation(s) defined by the contract data.

[0062] In an embodiment providing the digital asset includes: providing at least one supply chain product identifier associated with the supply chain product, 241022

[0063] 18 gathering - based on the provided supply chain product identifier - supply chain product data from one or more databases, providing decentral asset identifier(s) associated with the supply chain product data, generating the digital asset by transforming the gathered supply chain product data and the provided decentral asset identifier(s) using a rule-based engine including one or more rule(s) associated with or derived from a data model of a product produced or producible using the supply chain product.

[0064] The rule-based engine may operate on individual data points present within at least part of the gathered supply chain product data, multiple data points present within at least part of the gathered supply chain product data or the whole gathered supply chain product data. The one or more rule(s) may be generated from a rule template including unstructured data associated with instructions related to transformation operation(s). The one or more rule(s) may include executable instruction(s) configured to transform the supply chain product data. The one or more rule(s) may define aggregation rule(s) for aggregating supply chain product data gathered from multiple local source databases into a given data structure, define filters to filter gathered supply chain product data, define attribute construction(s) to create or add new attributes to the gathered supply chain product data and / or include a trigger condition and a corresponding group of one more actions. The rule(s) may be generated based on a data structure for collecting property / ies of the supply chain product. The data structure may be defined by one or more of the local data consumer component(s) and may be provided via the at least one orchestration component based on the local communication protocol to one or more local data provider component(s) of the local data provider compute and storage environment configured to generate the digital asset.

[0065] In an embodiment providing the digital asset includes: providing at least one supply chain product identifier associated with the supply chain product, gathering - based on the provided supply chain product identifier(s) - supply chain product data from one or more databases, providing decentral identifier(s) associated with the supply chain product data and at least one data model associated with the supply chain product, generating the digital asset by applying the at least one data model to the gathered supply chain product data and the provided decentral identifier(s).

[0066] The data model may define the data point(s) and / or the data structure in the digital asset. The data model may be associated with the supply chain product or a supply chain product class. The data model may be selected based on the at least one supply chain product identifier.

[0067] In an embodiment the supply chain product data includes supply chain product property data point(s), supply chain product identifier data point(s), supply chain product name data point(s), supply chain product producer data point(s), supply chain product declaration data point(s), supply chain product safety data point(s), supply chain 241022

[0068] 19 product emission data point(s), supply chain product recyclate content data point(s), supply chain product biobased content data point(s), supply chain product biodegradability data point(s), supply chain product production data point(s), supply chain product certificate of analysis data point(s), supply chain product certificate data point(s), supply chain product life cycle data point(s), supply chain product storage instruction data point(s), supply chain product assembly instruction data point(s), supply chain product processing condition data point(s), any combinations thereof or any single data point thereof.

[0069] In an embodiment the contract data includes unstructured data associated with contractual obligation(s) between the data owner and a data consumer associated with the local data consumer compute and storage environment. The obligation(s) may define terms and conditions (TnC) between the data provider and the data consumer. The terms and conditions may include processing rule(s) for processing the digital assets by the local data consumer component(s). The terms and conditions may include rule(s) for generating the digital assets.

[0070] In an embodiment the processing rule data includes permission(s), obligation(s) and / or prohibition(s) with respect to the processing of the digital asset by one or more of the local data consumer component(s). The permission(s), obligation(s) and / or prohibition(s) may be defined via terms and conditions.

[0071] In an embodiment the contract data is accessible for one or more of the local data consumer component(s) based on the representation for accessing the contract data included in the digital representation of the contract data. The contract data may be stored in a local database of the local data provider compute and storage environment. The database may be accessible for the local data consumer component(s) based on the representation for accessing the contract data. The contract data may be stored in a local database of the local data consumer compute and storage environment. The database may be accessible for the local data provider component(s) based on the representation for accessing the contract data. The contract data may be stored in a configuration database accessible for the orchestration component. The database may be accessible for the local data provider component(s) and / or the local data consumer component(s) based on the representation for accessing the contract data. Access to the local database may be controlled by the local data provider component(s), the local data consumer component(s) or the orchestration component. This way, contract data may be reliably accessed based on the representation for accessing the contract data, ensuring trust of the data providers that the digital assets are processing in line with the processing rule(s) included in the contract data or ensuring generation of digital assets according to the rules included in the contract data. This allows to improve the sharing of digital assets within the decentral network, resulting in a higher data quality of digital product passports generated using the digital assets and hence also a more efficient processing of the products associated with such digital product passports. This allows to ensure that the digital assets adhere to the data structure and include the data point(s) as defined by the rule(s) included in the contract data, allowing more efficient processing of the digital assets and improving the data quality of the digital product passports generated using processed digital assets.. 241022

[0072] 20

[0073] In an embodiment computing the hash value of at least a part of the contract data includes applying a predefined hash function to the contract data or a part thereof. The predefined hash function may include MD5 (Message- Digest Algorithm 5), SHA-1 (Secure Hash Algorithm 1), SHA-256 (Secure Hash Algorithm 256-bit), SHA-3 (Secure Hash Algorithm 3), CRC32 (Cyclic Redundancy Check 32-bit), BLAKE2, RIPEMD-160 (RACE Integrity Primitives Evaluation Message Digest 160-bit), HMAC (Hash-based Message Authentication Code), Whirlpool or Tiger. The hash value may act as a fingerprint of the contract data and may allow to detect modification of the contact data since modification would result in a different hash value. This way, the data integrity of the contract data may be verified by the recipient of the contract data, ensuring that the contract data referenced by the digital representation of contract data has not been tampered with. This increases the trust in the use of additional processing rule(s) next to the processing rule(s) included in the policy data. In addition, this increases the trust in the use of the contract data to define rule(s) for generating digital assets.

[0074] In an embodiment the representation for accessing the contract data is generated based on the representation for accessing a data storage storing the provided contract data and the computed hash value.

[0075] In an embodiment the generated digital representation of the contract data includes the computed hash value appended to the generated representation for accessing the contract data. The hash value may be separated from the representation for accessing the contract data by a predefined symbol, such as a #. This way, local data provider component(s) and / or local data consumer component(s) accessing the contract data based on the digital representation may be able to determine the representation for accessing the contract data and the hash value by parsing the digital representation to separate the representation for accessing the contract data from the hash value.

[0076] In an embodiment linking the generated digital representation of the contract data to the digital asset includes generating policy data including one or more of the decentral asset identifier(s) and processing rule data associated with the processing of the digital asset by one or more of the local data consumer component(s). The processing rule data may include the generated digital representation of the contract data. By including the digital representation of contract data withing the policy data, existing agreement(s) including data processing rule(s) associated with the processing of digital assets consumed via the decentral network may be flexibly adjusted and / or tailored to the needs of the data provider while still allowing negotiation of the processing rule(s) included in the contract data according to the decentral communication protocol in a standardized manner. In contrast to the contract data, such agreement(s) have already been signed by the data consumer(s) and the processing rule(s) included in such agreement(s) may not have been defined by the data owner of the digital asset or may not be applicable to the needs of the data owner with respect to the digital asset(s) to be provided by the data owner for access within the decentral network. Hence, the use of contract data exclusively defined by the data owner may allow the data owner to flexibly adapt or expand processing rule(s) included in existing agreement(s) to the 241022

[0077] 21 needs of the data owner with respect to the processing of a specific digital asset without having to request amendment of existing agreements. This way, the data owner may flexibly tailor processing rule(s) included in existing agreement(s) to the data included in a specific digital asset. This way, an efficient sharing of digital assets under full control of the data owner may be enabled within a decentral network, allowing efficient and timely generation of product passports and avoiding gathering of digital assets by a data consumer via a fragmented set of communication channels due to the lack of willingness of data providers to share their digital assets via the decentral network because of unsuitable existing processing rule(s). More efficient sharing of digital assets may result a higher data quality of the data included in the digital product passport can be ensured, allowing more efficient processing, such as recycling and / or re-use of the product based on the data included in the digital product passports.

[0078] In an embodiment, linking the generated digital representation of the contract data to the digital asset includes generating a digital representation of a digital twin of the supply chain product. The digital representation of the digital twin includes the digital representation of contract data, a decentral identifier associated with the digital twin and a digital representation(s) of the digital asset. The digital representation may further include the decentral asset identifier. The digital representation may be provided to the decentral network for the decentral asset identifier and the digital representation of the contract data to be discoverable and / or accessible for decentral consumer network nodes of the decentral network. The digital representation may be stored in a decentral registry accessible for at least a part of the decentral consumer network nodes. Access to the decentral registry may be controlled by the data owner of the digital twin via decentral participant identifier(s) associated with the decentral consumer network node(s). By referencing contract data in the digital representation of digital twin(s), addition of complex obligation(s) defined by the contract data to the policy data can be avoided while ensuring that all relevant obligation(s) to be fulfilled and / or permission(s) to be granted and / or prohibition(s) defined by the data owner with respect to the processing of the output product data are provided to the data consumer. This way, all relevant obligation(s), permission(s) and / or prohibition(s) may be made transparent to the data consumer prior to requesting access to such data, enabling the data consumer to determine whether data processing to be performed on the data to be consumed by the data consumer is possible or not. Such transparency avoids gathering of data which cannot be processed by the data consumer due to processing rule(s) defined by the data provider, reducing the amount of data exchanged within the decentral network and allowing more efficient exchange of data within the decentral network due to lower latency, improved bandwidth utilization and increased network stability. In addition, reduced data exchange may allow to reduce the environmental impact associated with the operation of the decentral network due to reduced energy consumption required to provide data, to gather data and / or to process data.

[0079] In an embodiment the digital representation of the contract data is provided for access by the decentral consumer network node(s) under control of the data owner of the digital asset. Access to the digital representation of the 22 contract data may be controlled by the data owner based on the decentral asset identifier associated with the digital asset and decentral participant identifier(s) of decentral consumer network node(s) requesting access to the digital twin. Access to the digital representation of the contract data may be controlled by the data owner based on decentral participant identifier(s) associated with the decentral consumer network node(s) requesting access to the digital representation of the digital twin including the digital representation of the contract data.

[0080] In an embodiment the digital representation of the contract data is provided for access by one or more of the local data consumer component(s) via a request for consumption of the digital asset provided by at least one orchestration component via local communication protocol(s). The request includes the digital representation of the contract data. The request is received based on a trigger by one or more local data provider component(s) of at least one local data provider computing and storage environment associated with the data owner. The trigger is provided via the local communication protocol(s) by the one or more local data provider component(s) to the at least one orchestration component. The trigger may be provided to the orchestration component for providing the request via the local communication protocol to one or more of the local data consumer component(s). The trigger may include the digital representation of the contract data. The trigger may further include decentral asset identifier(s) associated with the digital asset. The request may further include the decentral asset identifier(s) and an endpoint of the decentral provider network node(s) providing the digital asset. Based on the received request, the contract data may be accessed by the local data consumer component(s) or the local data provider component(s). By providing the digital representation of the contract data via the central orchestration component to the local component(s), such component(s) may gather the contract data and may verify the gathered contract data with respect to data integrity and acceptability of included processing rule(s) or rule(s) prior to requesting access to the digital asset or prior to generating the digital asset. This way, it can be ensured that the processing rule(s) defined by the data owner of the digital asset are acceptable for the data consumer, avoiding gathering of digital assets that cannot be processed by operation(s) performed by the local data consumer component(s). This reduces the number of data transactions within the decentral network, allowing to reduce the environmental impact associated with the sharing of digital assets within the decentral network. This way, it can be ensured that the rule(s) defined by the data consumer for generating the digital assets are acceptable for the data provider, avoiding generation of digital assets that do not fulfil the data structure and / or do not include the data point(s) expected during validation by the local data consumer component(s), resulting in failure of the validation and requiring regeneration of the digital assets. Failure of validation may result in low data quality of the digital product passports, negatively impairing the processing of the product based on data included in the product passports.

[0081] In an embodiment verifying the gathered contract data includes computing a hash value of the gathered contract data and comparing the computed hash value to the hash value included in the digital representation of contract data. 23

[0082] In an embodiment the gathered contract data is verified if the computed hash value matches the hash value included in the digital representation of the contract data. This way, it can be ensured that the gathered contract data was not modified, verifying the data integrity of the contract data and improving the trust of the data consumer the use of contract data to provide additional processing rule(s) regulating the processing of the digital assets.

[0083] In an embodiment validating the policy data and optionally the contract data includes providing the policy data and optionally the contract data for display and receiving a user input indicating validation or rejection of the policy data and / or optionally the contract data. The policy data and / or the contract data may be provided for display in a user interface. The policy data may be converted to a human-readable data structure prior to providing the converted policy data for display.

[0084] In another embodiment the policy data and optionally the contract data are validated using a rule-based engine including processing rule(s) and / or using at least one data-driven model trained on historical data sets including policy data sets and associated acceptability scores and / or including contract data sets and associated acceptability scores. The rule-based engine may operate on individual data point(s) included in the policy data and optionally the contract data, multiple data point(s) included in the policy data and optionally the contract data and / or the policy data and optionally the contract data. The one or more processing rule(s) may include instruction(s) for validating the policy data and optionally the contract data The instructions may include instructions to match at least a part of the policy data to predefined processing rule data and optionally instructions to match at least a part of the contract data to predefined contract data. The predefined processing rule data may include allowable processing rule data, such as allowable permission(s), obligation(s) and / or prohibition(s). The predefined contract data may include allowable contract data, such as hash value(s) of allowable contract data. Matching the predefined processing rule data to the policy data may include comparing predefined processing rule data to individual data point(s) present within the policy data to be validated and / or comparing data point combination(s) of predefined processing rule data to data point combination(s) present within the policy data to be validated and / or comparing predefined processing rule data to processing rule data included in the policy data to be validated. The policy data may be validated if the policy data fulfils at least one predefined processing rule. Likewise, the contract data may be validated if the contract data matches predefined contract data. The rule-based engine may be configured to generate a validation result. The validation result may include data indicating validation of the policy data and the contract data or data indicating rejection of the policy data and / or the contract data.

[0085] The at last one data-driven model trained to validate the policy data and optionally the contract data may generate at least one classifier discriminating between validated and non-validated policy data and optionally between validated and non-validated contract data. The trained data driven-model may include a data processing layer, an 24 embedding layer, a named entity recognition (NER) layer, an intermediate representation layer and a classifier layer.

[0086] By using the rule-based engine and / or the trained data-driven model, the acceptability of permission(s), obligation(s) and / or prohibition(s) included in the policy data as well as contractual obligation(s) included in the contract data may be reliably validated prior to initiating transfer of digital assets associated with the policy data and the contract data. This allows to ensure that the digital assets gathered according to the decentral communication protocol can be processed by instruction(s) executed by the local data consumer component(s) while avoiding gathering of non-processable digital assets. This way, it can be ensured that digital assets are only gathered from decentral provider network nodes according to the decentral communication protocol if associated policy data and contract data allows to process the digital assets according to instructions executed by the local data consumer component(s). This avoids unnecessary data transactions within the decentral network, allowing to reduce the environmental impact associated with the generation of digital product passports and improving the latency, bandwidth and stability of the decentral network. This aids in improving the trust of data providers with respect to adherence to processing rule(s) defined by the policy data and the contract data, enabling reliable sharing of digital assets within the decentral network. This way, the data quality of the digital product passport(s) generated based on gathered digital assets can be improved, allowing more efficient processing of the products based on data included in such passport(s).

[0087] In an embodiment the method further includes a step of validating the gathered digital asset using a rule-based engine including one or more rule(s) related to a data model associated with a product produced or producible at least in part from the supply chain product. The data model may be associated with a product class the product is associated with. The rule(s) may be generated based on the data model. The rule(s) may include executable instruction(s) configured to compare supply chain product data included in the digital asset to supply chain product data point(s) defined by the data model.

[0088] BRIEF DESCRIPTION OF THE DRAWINGS

[0089] In the following, the present disclosure is further described with reference to the enclosed figures. The same reference numbers in the drawings and this disclosure are intended to refer to the same or like elements, components, and / or parts. The description of drawings is provided for illustrative purposes and shall not be considered limiting. The embodiments and examples are illustrative embodiments and examples to further line out the concepts lined out herein. The figures include schematic illustrations and shall not be considered limiting. Other embodiments and examples that fall under the concepts lined out herein are possible and may not be explicitly described herein. 25

[0090] FIG. 1 illustrates an example of a participant network of a product ecosystem associated with a decentral peer-to-peer network for transfer of data associated with materials and products used within the product ecosystem.

[0091] FIG. 2A to FIG. 2E illustrate example systems for providing contractual obligation(s) related to the processing of digital asset(s) associated with output product(s) by computing node(s) associated with a data consumer from computing node(s) associated with a data owner of the digital asset(s) to the computing node(s) associated with the data consumer.

[0092] FIG. 3 illustrates an example system and associated methods for generating digital asset(s) associated with produced supply chain product(s) and for exchanging the generated digital asset(s) based on a decentral communication protocol under control of the data owner of the digital asset(s).

[0093] FIG. 4 illustrates an example of contract data including one or more contractual obligation(s) between a data owner of digital asset(s) associated with supply chain product(s) and a data consumer intending to consume one or more of the digital asset(s).

[0094] FIG. 5 illustrates an example of a system architecture including a local compute and / or storage environment and a decentral network environment.

[0095] FIG. 6 illustrates a block diagram of an example system for generating digital asset(s) associated with supply chain product(s) and for providing the generated digital asset(s) for access to decentral consumer network node(s) associated with local data consumer compute and storage environment(s).

[0096] FIG. 7 illustrates a block diagram of an example system for generating and providing policy data associated with digital asset(s) and including a digital representation of contract data associated with the digital asset(s).

[0097] FIG. 8A illustrates a data model of policy data expressing permissions, prohibitions and duties related to the processing of an associated asset.

[0098] FIG. 8B illustrates examples of different policy data that can be linked to digital asset(s) associated with supply chain product(s).

[0099] FIG. 8C illustrates an example of linking policy data to a given digital asset associated with a given supply chain product. 241022

[0100] 26

[0101] FIG. 9 illustrates an example data structure of a digital representation of a digital twin including a digital representation of contract data.

[0102] FIG. 10A illustrates a method for controlling access to digital asset(s) associated with supply chain product(s) by one or more decentral consume network node(s) connected to one or more local data consumer component(s) of one or more local data consumer compute and storage environment(s) associated with one or more data consumer(s).

[0103] FIG. 10B illustrates an example embodiment of the method shown in FIG. 10A.

[0104] FIG. 10C illustrates another example embodiment of the method shown in FIG. 10A.

[0105] FIG. 11 D illustrates yet another example embodiment of the method shown in FIG. 10A.

[0106] FIG. 11 illustrates a method for monitoring and / or controlling generation of digital asset(s) to be provided for access via a decentral communication protocol by one or more decentral consumer network node(s) connected to one or more of the local data consumer component(s) of a local data consumer compute and storage environment associated with a data consumer.

[0107] FIG. 12A illustrates a block diagram of an example system for validating policy data and contract data associated with digital assets of supply chain products and for validating digital assets gathered via a decentral communication protocol.

[0108] FIG. 12B illustrates a block diagram of an example system for validating policy data and contract data associated with digital assets.

[0109] FIG. 12C illustrates a block diagram of an example system for validating digital asset(s) associated with supply chain product(s) used to produce a product.

[0110] FIG. 13 illustrates a sequence diagram of an example data exchange according to a decentral communication protocol between decentral provider network node(s) connected to local data provider component(s) of a local data provider compute and storage environment and decentral consumer network node(s) connected to local data consumer component(s) of a local consumer compute and storage environment.

[0111] FIG. 14A illustrates an example of a user interface generated by local data consumer component(s) of a local data consumer compute and storage environment for displaying requests for 241022

[0112] 27 consumption of digital asset(s) received via an orchestration component from local data provider component(s).

[0113] FIG. 14B illustrates a user interface containing details on the requests described in the context of FIG.

[0114] 14A.

[0115] FIG. 14C illustrates a user interface generated by local data consumer component(s) of a local data consumer compute and storage environment for prompting the user to verify contract data and to accept or reject the policy data and the contract data.

[0116] FIG. 15A illustrates a flow chart of an example method for gathering digital asset(s) associated with supply chain product(s) via a decentral communication protocol from decentral provider network node(s) connected to local data provider component(s) of a local data provider compute and storage environment storing the digital asset(s).

[0117] FIG. 15B illustrates an embodiment of the method of FIG. 15A.

[0118] FIG. 15C illustrates a flow chart of an example method for providing digital assets associated with supply chain product(s) via a decentral communication protocol to decentral consumer network node(s) connected to local data consumer component(s) of a local data consumer compute and storage environment for generation of digital product passport(s) associated with one or more product(s) produced or producible using the supply chain product(s).

[0119] DETAILED DESCRIPTON

[0120] FIG. 1 illustrates an example of a participant network of a product ecosystem associated with a decentral peer-to- peer network for transfer of data associated with materials and produced products used within the product ecosystem.

[0121] The participant network 130 of the product ecosystem associated may be associated with a decentral peer-to-peer network decentral network 134 for exchange of data associated with or related to raw material(s), chemical intermediate product(s), chemical product(s), discrete product(s), end product(s), recycled material(s) and / or their respective production. The participant network may include one or more network participants 102 to 1 14 associated with decentral participant nodes 116 to 128. The network participants may be part of an industry or may be part of different industries. The network participants may be part of a product ecosystem including chemical products. The product ecosystem may include production chains to produce one or more end-product(s). The product ecosystem may include recycling chain(s) to recycle at least part of an end-of-life product resulting 241022

[0122] 28 from the use of the end product(s). The product ecosystem may include re-use chain(s) to re-use at least a part of the end-of-life product(s).

[0123] The product ecosystem may include a raw material producer 104, a chemical product producer 102, a chemical product user 106, an end-product producer 108, an end-product user 110, an EOL product collector 1 12 and a recycler 1 14. The product ecosystem illustrated in FIG. 1 is a mere example and may include more or less network participants. For example, the product ecosystem may include a chain of chemical product producers instead of only one chemical product producer 102. The participant network 130 may include a chemical supply chain. The product ecosystem may allow the use of recycled materials resulting from recycling of end-of-life products to produce new products, such as chemical products. The product ecosystem may be associated with the production and / or recycling and / or re-use of physical products. The product may be a chemical product, an intermediate chemical product, a component, a component assembly, an end product, an end-of-life product or a recycled material.

[0124] The participant(s) of the participant network may be associated with the production of products and / or recycling and / or re-use of products. The decentral network participant 102 to 114 may refer to a manufacturer of physical products, such as raw material producer 104, chemical product producer 102, chemical product user 106, endproduct producer 108, a user of physical goods, such as end-product user 1 10, and / or a participant of a recycling chain associated with the physical product, such as EOL product collector 112 and recycler 1 14. The network participant may be associated with a participant node 116 to 128 and a decentral participant identifier related to associated participant node(s) 1 16 to 128. The participant node may be associated with an endpoint for accessing the participant node. The decentral participant identifier may uniquely identify the decentral network participant within the decentral network. The decentral participant identifier in combination with the endpoint may uniquely identify the participant node within the decentral network.

[0125] The participant(s) of the participant network may be connected via material flows. The material flow may be a loop material flow 136. The loop material flow may be a closed loop material flow. A closed loop material flow may refer to a material loop where recycled material is used to produce the same end products the recycled material is obtained from via recycling. The loop material flow may be an open loop material flow. An open loop material flow may refer to a material loop where recycled material is used to produce different end products than the one the recycled material is obtained from. The material flow may be a linear material flow (e.g. not including recycling). The material flow may correspond to the flow of product from one participant of the participant network to the downstream participant of the participant network. The material flow may refer to a continuous or a discontinuous flow of product. The flow of product may include any means of transportation suitable to transport the product from a participant to the downstream participant. The means of transportation may include pipes, containers, barrels, packages. The material flow may be associated with raw materials used to produce the chemical product, such as 241022

[0126] 29 virgin raw materials 158. The raw materials may be provided to the chemical product producer for producing chemical product(s) and / or intermediate chemical product(s) (not shown). The loop material flow may be associated with chemical product(s) 156. The chemical product(s) may be provided from the chemical product producer to the chemical product user for producing discrete product(s). In contrast to chemical production, the discrete products being produced are distinct units sold as individual products. The loop material flow may be associated with recycled material 160. The recycled material may be provided from the recycler to the chemical product producer to produce chemical product(s).

[0127] At least part of the participants of the participant network may be associated with decentral participant network nodes 116 to 128. The decentral participant nodes may be under control of the respective decentral participant associated with the respective decentral participant node. The decentral participant nodes may form the decentral network decentral network. The decentral network decentral network may be a peer-to-peer communication network. The decentral peer-to-peer network decentral network may be configured to perform data transactions 132 according to at least one network protocol. The data transactions may be based on at least one transaction protocol including authentication and / or authorization mechanism(s). Based on the authentication and / or authorization mechanism(s) a peer-to-peer communication between the decentral network nodes associated with the network participants may be established. The one or more authentication mechanism(s) may be associated with or linked to a decentral identifier as described in the context of FIG. 3 and FIG. 13. The one or more authentication mechanism(s) associated with the decentral identifier may be accessible by the decentral participant nodes as described in the context of FIG. 3. The decentral configuration allows for more efficient use of computing resources and strengthens control by the data owners of the decentral network by allowing for data sovereignty.

[0128] Data transactions between decentral network participant nodes may be based on the decentral identifier associated with respective data to be accessed, for example as described in the context of FIG. 3 and FIG. 13. The decentral identifier may be uniquely associated with the physical entity of the product and associated product data. The decentral identifier may uniquely identify the respective product within the decentral network. The decentral identifier may be associated with further decentral identifier(s), such as decentral identifier(s) of product(s) used to produce the product. This may allow to track the product(s) used to produce a product, such as an end-product. The decentral identifier may be included in a digital access element associated with the product.

[0129] The data flow (e.g. transactions) between the decentral network participant nodes may be directly or indirectly associated with the material flow (depicted by bold solid lines) between the network participants. For instance, the data flow may be directly associated with the material flow if data associated with a material provided from the raw material producer to the chemical product producer is accessed by the decentral participant node 1 18 associated with said chemical product producer. For instance, the data flow may be indirectly associated with the material 241022

[0130] 30 flow if data associated with a chemical product produced by the chemical product producer is accessed by the decentral participant node 128 associated with the recycler.

[0131] The decentral participant nodes may be decentral computing nodes. The decentral computing node may be any device or system that includes at least one physical and tangible processor, and a physical and tangible memory capable of having thereon computer-executable instructions that are executed by a processor. The memory may take any form of volatile or non-volatile storages and may depend on the nature and form of the computing node.

[0132] At least part of the decentral participant nodes may be configured as decentral data providing nodes. At least part of the participant nodes may be configured as decentral data consuming nodes. A participant of the decentral participant network may be associated with a decentral data providing node and / or a decentral data consuming node depending on whether data is provided to downstream participants and / or consumed from upstream participants. For instance, the chemical product producer may be associated with a decentral data providing node configured to provide chemical product data to a downstream participant (e.g. chemical product consumer and / or OEM) for example as described in the context of FIG. 3 and FIG. 13. In addition to or alternatively, the chemical product producer may be associated with a decentral data consuming node configured to access data associated with material produced by an upstream participant (e.g. material supplier).

[0133] The decentral network may include further decentral network nodes (not shown in FIG. 1). The further decentral network nodes may not be associated with or operated by a participant of the product ecosystem. The further decentral network nodes may provide services for the network participants. The further decentral network nodes may be decentral infrastructure service nodes. The decentral infrastructure service nodes may provide services for the decentral participant nodes, such as verifying the identity of the decentral network participant nodes prior to performing a data exchange, providing decentral participant identifier(s) and / or providing endpoint(s) of participant node(s). The decentral network participant nodes may be associated with or include certificate(s), such as X.509 certificate(s). The certif icate(s) may be associated with decentral infrastructure service node(s) including e.g. a certificate issuing service and / or a dynamic provisioning service providing dynamic attribute tokens (e.g. OAuth Access Tokens). This way the decentral network participant nodes may be associated with a unique identifier embedded in a X.509 certificate that identifies the respective decentral network participant node. The information required to verify the certificate may be provided via an authentication registry associated with the certificate issuing service and / or the dynamic provisioning service. For instance, in the IDSA Reference Architecture Model, Version 3.0 of April 2019, a decentral data providing node associated with a data owner of data and a decentral data consuming node associated with a data consumer requesting access to such data may use the Certification Authority (CA) and the Dynamic Attribute Provisioning Service (DAPS) to verify the identity of the counter node prior to performing exchange of the data (not shown in FIG. 1). 241022

[0134] 31

[0135] FIG. 2A to FIG. 2E illustrate example systems for providing contractual obligation(s) related to the processing of digital asset(s) associated with output product(s) by computing node(s) associated with a data consumer from computing node(s) associated with a data owner of the digital asset(s) to the computing node(s) associated with the data consumer. The contractual obligation(s) may be defined by the data provider.

[0136] The digital asset(s) may be associated with output product(s) produced or producible by a production. The data owner may be the output product producer. The digital asset(s) may be generated by or on behalf of the data owner, for example as described in the context of FIG. 3 to FIG. 6. The digital asset(s) may be stored in a database associated with the data owner for access by data consumer(s). Access to the digital asset(s) may be controlled by the data owner, for example via a decentral identifier included in the digital asset(s) as described in the context of FIG. 11A, FIG. 13 and FIG. 16C. Access to the database may be controlled by the data owner, for example via a decentral identifier included in the digital asset(s) as described in the context of FIG. 11 A, FIG. 13 and FIG. 16C. The data provider may be associated with local data provider compute and storage environment(s) including one or more local data provider component(s) (e.g. local provider environment(s), such as environment 202). One or more of such local data provider component(s) may be connected to decentral provider network node(s). One or more of such local data provider component(s) may be configured to generate the digital asset(s) and to provide the generated digital asset(s) for access by decentral network node(s) connected to local data consumer component(s) of local data consumer compute and storage environment(s). The local data provider storage and compute environment may include the local data provider component(s) described in the context of FIG. 6 and FIG. 7.

[0137] The data consumer may be an entity associated with a local data consumer compute and storge environment (e.g. local consumer environment(s), such as environment 204) consuming or gathering digital asset(s) via a decentral network protocol at decentral network node(s) connected to local data provider compute and storage environment(s) and processing the gathered digital asset(s). The data consumer may be a product producer producing product(s) using the output product(s) associated with the digital asset(s). The data consumer may be any downstream participant of the data provider such as illustrated in FIG. 1 . The data consumer may be an entity generating digital product passport(s) using the consumed digital asset(s). The data consumer may be associated with the local data consumer compute and storage environment. The local data consumer compute and storage environment may include one or more local data consumer component(s)connected to one or more decentral consumer network node(s). The local data consumer component(s) may be configured to gather digital asset(s) via the decentral consumer network node(s) from decentral provider network node(s) based on the decentral network protocol, to validate the gathered digital asset(s) and to generate product passport(s) at least in part from such validated digital asset(s). The local data consumer storage and compute environment may include the local data consumer component(s) described in the context of FIG. 12A to FIG. 12C. 241022

[0138] 32

[0139] The digital asset(s) may be associated with policy data and contract data. The policy data may define decentral data consumer network node(s) allowed to access the digital asset(s). Decentral data consumer network node(s) allowed to access the digital asset(s) may be defined via decentral participant identifier(s) associated with such decentral data consumer network node(s). The policy data may include processing rule data defining permission(s), obligation(s) and or prohibition(s) of the local data consumer component(s) with respect to the processing of the digital asset. The policy data may be generated according to a predefined data model, such as the ODRL data model (see FIG. 8A). An example of policy data is described in the context of FIG. 8B. The contract data may include one or more contractual obligation(s) between the data owner of the digital asset(s) and a data consumer associated with the local data consumer component(s) configured to trigger gathering of the digital asset(s) and to process the digital asset(s). The contract data may be stored in a database of the local data provider compute and storage environment for access by one or more of the local data consumer component(s) (see for example FIG. 6). The contract data may include data defining the contractual obligation(s). The obligation(s) may define terms and conditions (TnC) between the data provider and the data consumer. An example of contract data is described in the context of FIG. 4. By using contract data in addition to policy data, processing of provided digital asset(s) by the local data consumer component(s) associated with the data consumer(s) may be flexibly adjusted and / or tailored to the needs of the data provider, without having to convert the contract data according to a predefined data model into policy data and without having to rely on existing agreements signed by the data consumer and including the terms and conditions required by the data provider with respect to the processing of the digital asset. This enables efficient sharing of digital asset(s) within the decentral network under full control of the data owner of the respective digital asset(s). This way, efficient generation of product passports associated with product(s) produced from output product(s) associated with such digital asset(s) is enabled allowing more efficient processing, such as recycling and / or re-use of the product based on the data included in the digital product passports.

[0140] The contract data may be provided to the data consumer via a digital representation of the contract data. The digital representation of the contract data may include a representation for accessing the contract data and a computed hash value of the contract data. By using a hash value within the digital representation, the data integrity of the contract data gathered based on the digital representation may be verified by comparing a hash value computed after gathering the contract data and comparing the hash value in the digital representation with the computed hash value. This way, trust in the use of digital representations of contract data may be improved since alterations of the contract data associated with the digital representation by the local data provider component(s) and / or the local data consumer component(s) may be readily detected based on the hash values. The digital representation of the contract data may be generated as described in the context of FIG. 7. The local data consumer component(s) may access or gather the contract data via the digital representation of the contract data provided to the local data consumer component(s), for example as described in the context of FIG. 12A and FIG. 12B. 241022

[0141] 33

[0142] By using digital representation(s) of the contract data, conversion of complex processing rule(s) defined by the contract data into a data structure required for the policy data according to the decentral network protocol can be avoided while ensuring that all relevant processing rule(s) defined by the data owner with respect to the processing of the digital asset(s) are provided to the local data consumer component(s). This way, data providers may flexibly adjust and / or tailor processing rule(s) to the data included in the digital asset(s) without having to rely on processing rule(s) included in existing agreements signed by the data consumers. In addition, this allows to negotiate contract data according to the decentral network protocol (see for example FIG. 13) without requiring any additional negotiation(s) and / or fragmented communication channels to negotiate all relevant processing rule(s) for a given digital asset prior to granting access to such digital asset. This may improve the trust of the data owner of the digital asset(s) that the digital asset(s) will only be processed by the local data consumer component(s) according to the processing rule(s) included in the contract data, enable sharing of sensitive data, such as composition data associated with the composition of the output product. This way, missing data during generation of the digital product passport can be avoided, resulting in a higher data quality of the data included in the digital product passport and allowing more efficient processing, such as recycling and / or re-use of the product based on the data included in the digital product passports. By including the hash value of the contract data in the digital representation, the data integrity of the contract data accessible via the digital representation can be reliably verified. Such improved trust may allow to negotiate the contract data via the decentral network protocols avoiding conversion of complex contractual obligation(s) included in the contract data according to data model(s) used to generate policy data required according to the decentral network protocol and allowing to flexibly link contract data to digital asset(s) without having to rely on existing agreements including data processing rules and having been signed by the data consumer(s).

[0143] Moreover, this allows to render all processing rule(s) associated with a given digital asset transparent to the data consumer prior to triggering access to such digital asset, enabling to determine whether data processing to be performed on the digital data to be consumed by the local data consumer component(s) is possible or not. Such transparency avoids gathering of data which cannot be processed by the data consumer due to processing rule(s) defined by the data provider, reducing the amount of data exchanged within the decentral network and allowing more efficient exchange of data within the decentral network due to lower latency, improved bandwidth utilization and increased network stability. In addition, reduced data exchange may allow to reduce the environmental impact associated with the operation of the decentral network due to reduced energy consumption required to provide data, to gather data and / or to process data.

[0144] FIG. 2A illustrates an example of providing the digital representation of the contract data as part of policy data associated with the digital asset(s). The policy data may be provided by decentral provider network node(s) connected to one or more of the local data provider component(s) via the decentral network to one or more decentral consumer network node(s) connected to the one or more local data consumer component(s).The policy 241022

[0145] 34 data may be provided by the decentral provider network node(s) in response to a request to access digital asset(s) associated with the policy data received via the decentral network protocol from the decentral consumer network node(s) (see FIG. 13). The local data consumer component(s) may be configured to verify and / or validate the gathered contract data and the received policy data, for example as described in the context of FIG. 12A and FIG. 12B.

[0146] In contrast to FIG. 2A, FIG. 2B illustrates an example of providing the digital representation of the contract data as part of a digital representation of a digital twin of the output product the digital asset is associated with. The digital asset may be part of the digital twin as described in the context of FIG. 7. The digital asset may correspond to the digital twin. The digital representation of the digital twin may include decentral twin identifier(s) associated with the digital twin, decentral asset identifier(s) associated with the digital asset(s) included in the digital twin and data indicating data model(s) used to generate the digital asset(s). The digital representation of the digital twin may further include a representation for accessing digital the asset(s)). The digital representation(s) of the digital twin(s) may be provided to the decentral network for the decentral asset identifier(s) and the digital representation of the contract data to be accessible and / or discoverable by decentral consumer network node(s). Providing the digital representation(s) to the decentral network may include storing such representation(s) in a database 208 accessible for at least a part of the decentral consumer network node(s). Access to the database may be controlled by the data owner of the digital twin. Access may be controlled based on decentral participant identifier(s) associated with such decentral consumer network node(s). The database may be part of the local data provider compute and storage environment. The database may be connected to the decentral provider network node(s) connected to the local data provider compute and storage environment. The digital representation of the digital twin may be gathered from the data base by decentral consumer network node(s) connected to the local data consumer component(s) based on the decentral asset identifier(s) associated with the digital asset, for example as described in the context of FIG. 3. In addition policy data associated with asset(s) may be provided by the decentral provider network node(s) associated with the local provider component(s) as described in the context of FIG. 2A.

[0147] FIG. 2C illustrates an example of providing the digital representation of the contract data via a central orchestration component 210 to one or more local data consumer component(s) of one or more local data consumer compute and storage environment(s). With reference to FIG. 5, local data provider compute and storage environment(s) and local data consumer compute and storage environment(s) may be connected via a local communication protocol to the central orchestration component. The central orchestration component may be configured to provide requests received via the local communication protocol from local data provider component(s) to respective local data consumer component(s), for example as described in the context of FIG. 5. The central orchestration component may be configured to provide requests respective local data provider component(s) based on triggers received via the local communication protocol from local data consumer 241022

[0148] 35 component(s) to, for example as described in the context of FIG. 5. The requests or triggers may include the digital representation of the contract data. In addition policy data associated with digital asset(s) may be provided by one or more decentral network node(s) connected to the local data provider component(s) via the decentral network protocol to one or more decentral network node(s) connected to the local data consumer component(s) as described in the context of FIG. 2A. The local data consumer component(s) or the local data provider component(s) may be configured to gather contract data based on the digital representation of the contract data received via the local communication protocol from the central control unit, for example as described in the context of FIG. 12A and FIG. 12B. The local data consumer component(s) or the local data provider component(s) may be configured to verify and / or validate the gathered contract data and the received policy data, for example as described in the context of FIG. 12A and FIG. 12B.

[0149] In contrast to FIG. 2C, FIG. 2D illustrates an example of providing the digital representation of the contract data by the decentral provider network node connected to the local data provider component(s) via the decentral network protocol to decentral consumer network node(s) connected to the local data consumer component(s). The decentral consumer network node(s) may be configured to receive and process such digital representations. The digital representation may be provided based on digital representation(s) of local consumer component(s) configured to receive digital representations of contract data. The digital representations may include a representation for accessing such local data consumer component(s). the digital representation(s) may be accessible at the decentral consumer network node(s) upon request by the decentral provider network node(s).

[0150] FIG. 2E illustrates an example of providing the digital representation of the contract data as part of a digital asset provided by the decentral provider network node(s) to the requesting decentral consumer network node. The digital asset may be provided under control of the data owner of the digital asset via the decentral network protocol to the decentral consumer network node(s), for example as described in the context of FIG. 3.

[0151] What has been said with respect to providing contract data associated with a digital asset from local data provider component(s) to local data consumer component(s) equally applies to providing contract data associated with processing of digital assets intended to be performed by the local data consumer component(s) from such the local data consumer component(s) to the local data provider component(s).This way, it can be ensured that digital asset(s) requested to be generated by local data consumer component(s) are generated by the local data provider component(s) in accordance with the rule(s) defined by the contract data, ensuring that the generated digital asset(s) include the data and adhere to the data structure the local data consumer component(s) expect when processing the provided digital asset(s). Such rule(s) may define data model(s) to be used by the local data provider component(s) for generation of the digital asset(s) for example as described in the context of FIG. 6. This may ensure reliable processing of the gathered digital asset(s) by the local data consumer component(s), ensuring reliable and efficient generation of the digital product passports. 241022

[0152] 36

[0153] FIG. 3 illustrates an example system and associated methods for generating digital asset(s) associated with produced or producible supply chain product(s) and for exchanging the generated digital asset(s) based on a decentral communication protocol under control of a data owner of the digital asset(s). The supply chain product may be a chemical product, an intermediate chemical product, a component or a component assembly. The supply chain product may be a component or component assembly of a battery, such as a battery cell, a battery module or a battery pack. The system may be configured to perform the methods described in the context of FIG. 10A to FIG. 10D.

[0154] The data owner may comprise any entity generating data, particularly data relating to the supply chain product identified. The data generating node may be coupled to the entity owning physical supply chain product(s) from or for which digital asset(s) is / are generated. The digital asset(s) may be generated by a third-party entity on behalf of the entity owning the physical supply chain products. The data owner may be the producer of the supply chain product. The digital asset(s) may be stored in a storage environment of or associated with or controlled by the data owner for access by decentral consumer network node(s) associated with data consumer(s). The digital asset (s) may be stored in a storage environment accessible by the data owner. The data owner may control access to the digital asset (s) stored in the storage environment. Access to the digital asset (s) may be controlled based on identifier(s), such as a decentral identifier(s) as described later on, associated with the digital asset (s). Access to the digital asset (s) may be controlled via a decentral provider network node associated with or controlled by the data owner. The decentral provider network node may have access to the storage environment and may control access to the digital asset (s) stored in the storage environment based on the identifier(s).

[0155] The supply chain product 312 may be produced or producible using one or more production input(s) by the supply chain product production 308. The supply chain product may be produced or producible via one or more process steps from the production input(s) within the supply chain product production. The process steps may involve chemical reactions and / or physical processes. Physical processes may involve the use of chemical production inputs. The production input may be used in one or more of such production step(s). The production input may include starting material used in a production process performed within the supply chain product production to produce the supply chain product. Production input may include recycled material. The supply chain product production may be operated by a supply chain product producer. The supply chain product production may be a chemical production. The supply chain product production may be a chemical production network (see FIG. 8A). The production may be a chemical production network. The chemical production network may include multiple interlinked processing steps. The chemical production network may be an integrated chemical production network with connected or interconnected production chains. The chemical production network may include multiple different production chains that have at least one intermediate product in common. The chemical production network may include multiple stages of the chemical value chain. The chemical production network may include the producing, refining, processing and / or purification of chemical products. The chemical production network may 241022

[0156] 37 include multiple production chains that produce from one or more material(s) chemical products that exit the chemical production network. The chemical production network may include multiple tiers of a chemical value chain. The chemical production network may include physically connected or interconnected supply chains and / or production sites. The production sites may be at the same location or at different locations. In the latter case, the production sites may be connected or interconnected by means of dedicated transportation systems such as pipelines, supply chain vehicles, like trucks, ships or other cargo transportation means. The chemical production or production network may include one or more process step(s) involving chemical reaction(s). The chemical production or production network may further include one or more process step(s) involving physical processes. The physical processes may involve the use of chemical production inputs.

[0157] The supply chain product production may be associated with an operating system configured to monitor and / or control the supply chain production. The operating system may include the local data provider compute and storage environment 202 (e.g. provider tenant). The operating system may be associated with the provider tenant. The provider tenant may communicate via a local communication protocol with an orchestration component as described in the context of FIG. 5. The provider tenant may communicate via the orchestration component with local data consumer compute and storage environment(s), such as consumer tenant 204, based on the local communication protocol. The provider tenant may include asset generation and transfer system 302 configured to generate digital asset(s) based on supply chain product data stored in data layer 306 and to provide the generated digital asset(s) for access by decentral consumer network node(s) connected to local data consumer component(s) of consumer tenant(s). Generation of the digital assets may be triggered by trigger event(s), such as request(s) for generating and providing digital assets(s) received via the orchestration component from the consumer tenant(s) (see FIG. 5), supply chain product identifier(s) received from a trigger generator included in a packaging line and / or generation of data pipelines for generating digital asset(s) to be offered for consumption to consumer tenant(s) (see FIG. 5). The generated digital asset(s) may be stored in a local data storage of the provider tenant, such as assets DB 304, for access by the decentral consumer network node(s) connected to the local data consumer component(s) of the consumer tenants via the decentral network 134. The asset generation and transfer system may include the local data provider components described in the context of FIG. 6. The asset generation and transfer system may be configured to generate digital asset(s) and to provide generated digital asset(s) for access via the decentral network protocol, for example as described in the context of FIG. 6. In the example illustrated in FIG. 3, the provider tenant may be associated with the supply chain product data layer storing supply chain product data associated with the supply chain products produced or producible by the supply chain product production. The supply chain product data layer may be included in an operating system associated with the supply chain product production. In another example (not shown in FIG. 3), the provider tenant may include the supply chain product data layer. 241022

[0158] 38

[0159] The supply chain product data stored in the supply chain product data layer may be generated before, during and / or after production of the supply chain product. The supply chain product data stored in such data layer may be linked to a digital supply chain product identifier associated with the supply chain product. The supply chain product data may include measured data and / or data generated from measured data. The supply chain product data may include at least one chemical and / or physical property of the supply chain products. The supply chain product data may further include supply chain product name(s), production data, emission data, safety data, certificates, processing data, handling data, life cycle data, storage instruction(s), processing instructions or any combination thereof. Examples of chemical properties include heat of combustion, enthalpy of formation, toxicity, chemical stability in a given environment, flammability, oxidation state(s), ability to corrode, combustibility, acidity and basicity, chemical composition, recyclate content used for producing or manufacturing the supply chain product, bio-based content used for producing or manufacturing the supply chain product, renewable content used for producing or manufacturing the supply chain product, biodegradability, and / or pH value. Examples of physical properties include absorption, brittleness, boiling point, capacitance, color, concentration, density, ductility, distribution, efficacy, elasticity, electric charge, electrical conductivity, electrical impedance, electric potential, flow rate, fluidity, hardness, heat capacity, inductance, intrinsic impedance, luminance, luminescence, luster, mass, melting point, opacity, permeability, permittivity, plasticity, pressure, radiance, resistivity, reflectivity, refractive index, solubility, specific heat, strength, stiffness, temperature, tension, thermal conductivity, thermal resistance, viscosity, volume and / or wave impedance.

[0160] The provider tenant may include local data provider component(s), such as component(s) of the asset generation and transfer system, connected to a decentral provider network node, such as node 118, of the decentral network. The decentral network may be a decentral peer-to-peer network as described in the context of FIG. 1. Provider node 118 may be configured to gather digital asset(s) from the assets DB in response to request(s) received via the decentral network from decentral consumer network node(s), such as node 122, connected to local data consumer component(s) of the consumer tenant, such as component(s) of the asset generation and transfer system 11 18. Data exchange via peer-to-peer communication between the decentral provider network node and the decentral consumer network node(s) may be based on a decentral network protocol. The decentral network protocol may implement authentication and / or authorization mechanism. Such authentication may be based on data related to an authentication mechanism. The authentication mechanism may be based on certificate(s) and / or token(s), for example a device certificate (X.509v3), a TLS connection certificate (X.509v3) and a ‘Dynamic Attribute Token’ (OAuth Access Token), associated with the respective decentral network nodes, e.g. consumer node 120 and provider node 118. If authentication fails, no data, such as digital asset(s), may be provided to the requesting decentral consumer network node(s). Such authorization may be based on or related to an authorization mechanism. The authorization mechanism may relate to or include decentral asset identifier(s) associated with the generated digital assets. The authorization mechanism may be based on policy data linked via the decentral asset identifier(s) to the respective digital assets. The policy data may include decentral participant 241022

[0161] 39 identif ier(s) associated with decentral consumer network node(s) allowed to access the digital asset. The policy data may further include data indicating permission(s), prohibition(s) and / or obligation(s) of consumer tenant(s) with respect to the processing of the digital assets. If authorization fails, no data, such as digital asset(s), may be provided to the requesting decentral consumer network node(s).

[0162] The supply chain product may be provided to a downstream production stage producing product(s) using the supply chain product as production input. The product may be a chemical product, a component, a componentassembly, an end-product or a recycled material. The downstream production stage may include product production 320. The product production may be operated by a product producer. The product production may be associated with an operating system configured to monitor and / or control the product production. The operating system may include the consumer tenant. The consumer tenant may be associated with the operating system. The consumer tenant may communicate via the local communication protocol with the orchestration component, for example as described in the context of FIG. 5. The consumer tenant may communicate via the orchestration component with provider tenant(s), such as provider tenant 202, using the local communication protocol. The consumer tenant may include local data consumer component(s), such as components of asset generation and transfer system 314, configured to process digital asset(s) gathered via the decentral network from decentral provider network node(s). The gathered digital asset(s) may be processed based on a data pipeline generated by local data consumer component(s) of the consumer tenant, for example as described in the context of FIG. 5. Processing may include validation of gathered digital asset(s), for example as described in the context of FIG. 12A to FIG. 12C. The asset generation and transfer system 314 may include the components described in the context of FIG. 12A. In the example illustrated in FIG. 3, the consumer tenant may be associated with the product data layer storing product data gathered before, during and / or after production of the product, as described previously. In another example (not shown in FIG. 3), the consumer tenant may include the product data layer. The local data consumer component(s) may be associated with a decentral consumer network node of the decentral network. The decentral consumer network node may be configured to request access to digital asset(s) at decentral provider network nodes associated with such digital asset(s) based on decentral asset identifier(s) associated with the digital asset(s) and to provide the digital asset(s) received from the decentral provider network node(s) to the asset generation and transfer system for processing.

[0163] The digital asset(s) may be accessed based on the decentral asset identifiers, the decentral participant identifier associated with the decentral consumer network node requesting access and the endpoint of the decentral provider network node. The decentral consumer network node and decentral provider network node may authenticate as previously described. The request to access the digital asset(s) may be authorized as previously described. Upon successful authentication and / or authorization of the request to access to the digital asset(s), the decentral provider network node may gather the digital assets from assets DB 304 based on the decentral asset identifier(s) received from the decentral consumer network node. The decentral provider network node may 241022

[0164] 40 provide the gathered digital asset to the requesting decentral consumer network node. The decentral provider network node may apply policy data associated with the digital asset(s) to the gathered digital asset(s) prior to providing such digital asset(s) to the decentral consumer network node. The decentral consumer network node may provide the received digital asset(s) to the asset generation and transfer system. The asset generation and transfer system may be configured to process the received digital assets.

[0165] FIG. 4 illustrates an example of contract data including one or more contractual obligation(s) between a data owner of digital asset(s) associated with supply chain product(s) and a data consumer intending to consume one or more of the digital asset(s).

[0166] The contract data 402 may include or correspond to one or more computer-readable legal document(s). The legal documents may be stored in one or more file formats. An example file format includes the portable document format (PDF), which can be described as a file format that captures the elements of a printed document as an electronic image. The legal documents may be stored in a database, such as contract DB 620 illustrated in FIG. 6.

[0167] The contract data may govern the processing of the digital asset(s) the contract data is associated with by the local data consumer component(s). The contract data may govern the relationship between the data provider and the data consumer(s).

[0168] The contract data may include data defining the contractual obligation(s). The obligation(s) may define a legal clause or a set of legal clauses. The obligation(s) may define terms and conditions (TnC) between the data provider and the data consumer. The contract data may include unstructured data. The unstructured data may be associated with or relate to the contractual obligation(s). The unstructured data may include or define the contractual obligation(s). Unstructured data may include data that does not conform to a predefined data model or schema. The contract data may one or more blocks of text in natural language. At least a part of the blocks may include the terms and conditions.

[0169] FIG. 5 illustrates an example of a system architecture including a local compute and / or storage environment and a decentral network environment.

[0170] Local compute and / or storage environment:

[0171] The local compute and / or storage environment may include an orchestration component 210 and a plurality of local data provider compute and / or storage environments and / or local data consumer compute and / or storage environments, such as 202, 506, 508 and 204, acting as tenants of the orchestration component. Each tenant may be associated with a unique identifier (e.g. tenant ID) uniquely identifying the tenant within the local compute and / or storage environment. 41

[0172] The local compute and / or storage environment may include distributed compute and / or storage environments controlled by the tenants and / or the orchestration component. Local compute and / or storage environment may relate to access controlled distributed compute and / or storage components communicatively connected through local communication protocol(s). Local compute and / or storage environment may relate to access controlled distributed compute and / or storage components communicatively connected through local communication protocol(s). Local may relate to the association of the compute and / or storage environment with the supply chain product data storage or data base and / or the digital asset storage or data base of the supply chain product producer accessible by the supply chain product producer or to the association of the compute and / or storage environment with a storage or data base storing processed digital assets of the digital asset consumer accessible by the digital asset consumer. Local may hence relate to the accessibility of digital assets or processed digital assets, which may be shared by decentral network nodes under control of the supply chain product producer (e.g. the data provider) or the data consumer.

[0173] The local communication protocol may facilitate communication in distributed compute and / or storage environment. The local communication protocol may include web protocols, such as HTTP / HTTPS methods, URI, MIME types or combinations thereof. The local communication protocol may implement stateless communication. Stateless communication may include requests and triggers that include all data required to process the request or trigger by the at least one orchestration component. This way, the orchestration component(s) do not have to retain session information, allowing efficient communication with multiple tenants and improving scalability and reliability. The local communication protocol may be configured to communicatively couple the orchestration component with multiple tenant components. The local communication protocol may be configured to decouple communication between tenant components. The local communication protocol may be configured to open communication channel between the orchestration component and multiple tenant components. The local communication protocol may be configured to close communication channel between the orchestration component and multiple tenant components. The orchestration component may be configured to orchestrate communication channels to multiple tenant components. The orchestration component may be configured to centrally orchestrate communication to multiple tenant components. The orchestration component may be configured to centrally orchestrate communication between multiple tenant components indirectly, e.g. through or via the orchestration component. The tenant components may be configured to communicate with orchestration component directly. The tenant components may be configured to not communicate with other tenant components directly. The tenant components may be configured to communicate with other tenant components indirectly, e.g. through or via the orchestration component. The core feature of the local network protocol includes the local tenant identifiers stored and used by the orchestration component for communication with the tenants, while individual tenants do not have access to tenant identifiers of other tenants and can only communicate with the other tenants through the orchestration component. 42

[0174] Tenants:

[0175] The tenant(s) may be configured to communicate with the orchestration component. The tenant(s) may be configured to communicate with other tenant(s) via or by using the orchestration component. The tenant(s) may be configured to communicate with other tenant component(s) solely through the orchestration component. The tenant(s) may not be communicatively coupled to each other. The tenant(s) may be configured to communicate with the orchestration component via peer-to-peer communication according to the local communication protocol(s).

[0176] The local data provider compute and / or storage environments may include one or more data provider component(s) (e.g. tenant component(s)) configured to generate and / or provide digital assets, one or more local data provider component(s) configured to request consumption of generated digital asset(s) and / or one or more local data provider component(s) configured to orchestrate, e.g. to monitor and / or control, generation and / or provision of digital assets. The local data provider compute and / or storage environments may include the local data provider component(s) illustrated in FIG. 6. The one or more local data provider component(s) may be connected to decentral provider network node(s), such as nodes 1 16, 118 and 120. The local data consumer compute and / or storage environments may include one or more data consumer component(s) (e.g. tenant component(s)) configured to trigger access of digital assets via the decentral network protocol, one or more local data consumer component(s) configured to process accessed digital assets and / or one or more local data consumer component(s) configured to orchestrate, e.g. to monitor and / or control, accessing of digital assets and / or processing of accessed digital assets. The local data consumer compute and / or storage environments may component(s) illustrated in FIG. 12A.

[0177] The exchange of digital assets may be orchestrated via one or more data pipeline(s) configured by the one or more tenants. The one or more data pipeline(s) configured by the one or more tenants may be orchestrated by orchestration component. The data pipelines may be configured for generating digital assets to be provided and / or consumed via one or more decentral network protocols. The data pipelines may be configured for processing digital assets consumed via the decentral network protocol(s). The data pipeline may be connected or communicatively coupled to or may relate to a local data source associated with the tenant. The local data source may store supply chain product data used to generate the digital asset(s) exchanged via the decentral network. The local data source may store validated supply chain product data obtained by processing (e.g. validating) digital assets received or consumed via the decentral network.

[0178] The configured data pipeline may be associated with any number of computational steps. The computational step(s) may be included in the data pipeline and / or may provide access to data specified by the data pipeline. The computational step(s) may be performed within the respective tenant configured for generating and providing digital assets and / or the respective tenants configured for consuming generated digital assets connected by the 241022

[0179] 43 data pipeline. The computational step(s) may be defined by the user creating the data pipeline. The user may select one or more computational step(s) from a list of available computational step(s) upon creating the data pipeline. The computational step(s) may be predefined for given data pipeline(s) and the user may select a predefined data pipeline upon creating the data pipeline. A computation step may include a specified computation platform (e.g., JavaScript, Kusto Query Language, SparkQL, Python, CSLinq), a specified input to the computational step, a specified computation for the computational step, a specified output schema, a specified output storage, or a combination thereof. A specified input to a computational may identify a data input or parameters thereof or a data source storing data inputs on which the computational step will operate. A specified computation for a computational step may identify one or more executable operations to be performed on a specified input to the computational step. A specified computation can be a template computation (e.g., map, reduce, fuse, unfold, append, filter, split, or the like, or more generally any type of arithmetic operation, aggregation, summarization, filtering, sorting, bounding, or other computation), a custom computation (e.g., identified from an existing set of assets or provided through an associated script editor), or a combination thereof. A specified output schema for a computational step may define the form or structure of the computational result of the step. For example, a specified output schema may include an identification of a particular component of a computational result (e.g., variable, array, vector, matrix, row, column, property) and one or more corresponding attributes (e.g., data type, description, dimensionality). The specified output schema may include a data format for the computational result.

[0180] The configured data pipeline may be associated with a data pipeline identifier uniquely identifying the data pipeline within the respective tenant. The data pipeline may be associated with configuration data. The configuration data may define computational step(s) included in the data pipeline, a specified input to each computational step, a specified computation for each computational step, a specified output schema and / or a specified output storage. The output storage may be predefined. The output storage may be selected by the user upon generation of the data pipeline. The data pipeline identifier and the configuration data may be stored in a data storage included in the tenant setting generating the data pipeline. The data pipeline identifier may be used to generate digital asset(s) according to computational step(s) as defined by the respective data pipeline. The data pipeline identifier may be used to map digital asset(s) to respective data pipeline(s), allowing to process the digital asset(s) according to computational step(s) as defined by the respective data pipeline.

[0181] The one or more local data consumer component(s) may be connected to decentral provider network node(s), such as node 122.

[0182] The decentral provider network nodes and the decentral consumer network nodes may be part of a decentral network, such as the decentral network described in the context of FIG. 1. The decentral provider and consumer network nodes may be associated with a decentral participant identifier uniquely identifying such decentral 241022

[0183] 44 network nodes within the decentral network environment. The local data provider and local data consumer components may be associated with the decentral participant identifier uniquely identifying such components within the decentral network environment. The tenants may be associated with the decentral participant identifier uniquely identifying such tenants within the decentral network environment. The decentral participant identifier may include letters and / or numbers. The decentral participant identifier may include one or more Universally Unique Identifier(s) (UUID(s)) and / or one or more Decentralized Identifier(s) (DID(s)). The decentral participant identifier may be associated with or may include a verifiable credential. The verifiable credential may be issued by a central or decentral identity issuer making one or more claims about a subject, such as an entity being a trustworthy participant of the decentral network. The verifiable credential may include at least one proof associated with the identity of the decentral network participant. The verifiable credential may include at least one proof associated with the membership of the decentral network participant in the decentral network. The verifiable credential may include at least one proof associated with an agreement signed by the decentral network participant.

[0184] Orchestration component:

[0185] The orchestration component may include a local orchestration compute and / or storage environment. The local orchestration compute and / or storage environment may include one or more local orchestration component(s) configured to receive requests via the local communication protocol(s) from local data provider component(s) and / or local data consumer component(s), one or more local orchestration component(s) configured to process the received requests, one or more local orchestration component(s) configured to generate and provide requests via the local communication protocol(s) to local data provider component(s) and / or local data consumer component(s), one or more component(s) configured to store data structure(s) received via the local communication protocol(s) from local data consumer component(s) and / or to store mappings between tenant identifiers and decentral participant identifiers associated with such tenants. The orchestration component may be communicatively connected to the one or more tenants. The orchestration component may be to orchestrate, e.g. control and / or monitor, data exchange via the decentral network by exchanging, receiving and / or sending, requests via the local communication protocol with, from and / or to local data consumer and / or provider component(s). The orchestration component may be communicatively connected to the tenant(s) or tenant component(s). The orchestration component may be configured to communicate with tenant(s) or tenant component(s) based on the local communication protocol. The orchestration component may be configured to communicate with individual tenant(s) or tenant component(s) based on the local communication protocol. The orchestration component may be configured to orchestrate communication channels to multiple tenants or tenant components. The orchestration component may be configured to centrally orchestrate communication to multiple tenants or tenant components. The orchestration component may be configured to centrally orchestrate communication between multiple tenants or tenant components indirectly, e.g. through or via the orchestration 241022

[0186] 45 component. The orchestration component may implement network interface(s) for communication with the tenants or tenant components via the local communication protocol. The network interface(s) may include API(s), such as a REST API(s).

[0187] The orchestration component may be communicatively connected to one or more databases storing configuration data, such as database 504. The configuration data may relate to the orchestration of data pipelines configured by the one or more tenants. The database may store pairs of decentral participant identifiers and respective tenant identifiers. The database may further store endpoint(s) of decentral network node(s) associated with the decentral participant identifier(s).

[0188] The orchestration component may receive triggers from the local data consuming component(s) for generating digital asset(s) to be provided and / or consumed via the one or more decentral network protocols of the decentral network. In addition or alternatively, the orchestration component may receive requests from the local data providing component(s) for consuming generated digital asset(s) via the one or more decentral network protocols of the decentral network. The triggers and / or requests may be triggered after generation of the data pipeline. The triggers and / or requests may relate to the tenant identifier associated with the tenant component(s) providing the request to the orchestration component and configuration data associated with the data pipeline. The triggers and / or requests may not relate to the digital asset(s) to be provided and / or to be consumed and to the generated digital asset(s). The digital asset(s) may be stored in a local database of the tenant configured for data provisioning and access to such database via the decentral network may be controlled based on the decentral asset identifiers associated with the digital assets stored in such database. Based on the tenant identifier and the decentral participant identifier(s) included in the triggers and / or requests, the orchestration component may identify the tenant the request or trigger was received by and the tenant(s) the request or trigger is to be provided to. Based on the configuration data included in the received requests or triggers, the orchestration component may generate and provide a request for generating digital asset(s) to be provided and / or consumed or may generate and provide a request for consumption of generated digital asset(s) to the identified tenant(s). The requests may include at least a part of the configuration data included in the requests or triggers received by the orchestration component. Based on the configuration data the tenant receiving the request may generate a new data pipeline or assign the request to an existing data pipeline. The new data pipeline may be generated based on the configuration data included in the received request.

[0189] Depending on the envisaged data transfer to be executed via the decentral network, the orchestration component orchestrates the data pipeline setup in the local environments of the tenants associated with decentral network nodes. The communication of the actual digital assets is hence not executed via the orchestration component and the orchestration component does not have access to such digital assets. Hence the assets are transferred only in peer-to-peer communication between nodes of the decentral network under full control of the data owner of the 241022

[0190] 46 digital assets. The orchestration component only enables communication between tenants with respect to requests for digital assets or offers of digital assets and ensures that the digital asset(s) transferred via the decentral network adheres to the formats and content the provider and / or recipient of such digital asset(s) expect. This way, access to the digital assets associated with the supply chain products are controlled by of the respective data owner of such digital assets, such as the supply chain product producers, while enabling secure and efficient transfer of such digital assets via the decentral network based on the orchestration of requests from tenants by the orchestration component.

[0191] Decentral network environment:

[0192] The decentral network environment may include decentral network nodes, such as nodes 116 to 122. The decentral network node(s) may form the decentral network (see also FIG. 1 ). The decentral network nodes may be configured to communicate with other decentral network nodes via peer-to-peer communication according to decentral communication protocol. The decentral communication protocol may facilitate communication in decentral network environment. In addition, the decentral network nodes may be communicatively coupled to components of the local compute and / or storage environment, such as tenant components. Decentral network nodes may be configured to communicate directly or indirectly, e.g. through bridging component(s) configured to translate between local and decentral communication protocol(s), with tenant components based on the local communication protocol. The decentral network protocol may include the decentral participant identifiers and / or decentral asset identifier(s) associated with digital assets of supply chain products being discoverable and / or accessible by decentral participant nodes, e.g. through, via, in or by decentral storage. Individual decentral network nodes have hence access to decentral participant identifiers related to other decentral network nodes and can communicated directly with other decentral network nodes. In addition at least a part of the decentral network nodes may hence have access to the decentral asset identifiers associated with digital assets and can request access to such digital assets based on the decentral asset identifiers.

[0193] The setup of the local computing and / or storage environment and the decentral network environment illustrated in FIG. 5 are mere examples and shall not be considered limiting. Different numbers of tenants with or without associated decentral network node are feasible. Also different functionalities including the generation of data pipelines configured for data providing or consuming may be executed by a single or multiple tenant(s).

[0194] FIG. 6 illustrates a block diagram of an example system for generating digital asset(s) associated with supply chain product(s) and for providing the generated digital asset(s) for access to decentral consumer network node(s) associated with local data consumer compute and storage environment(s). Access to the digital asset(s) may be controlled by the data owner of the digital asset(s), such as the supply chain product producer, based on policy data associated with the digital asset(s). The policy data may include a digital representation of contract data including one or more contractual obligation(s) between the data owner of the digital asset(s) and a data 241022

[0195] 47 consumer intending to consume the one or more of the digital asset(s) via decentral consumer network node(s) associated with such data consumer. The policy data may include processing rule data defining processing rule(s) associated with the processing of the respective digital asset by local data consumer component(s) included in the local data consumer compute and storage environment(s). The processing rule(s) may include permission(s), obligation(s) and / or prohibition(s) with respect to the processing of the digital asset, for example as described in the context of FIG. 7 to FIG. 8C. Access to the digital asset(s) may be controlled by the data owner of the digital asset(s) based on the policy data in combination with the digital representation of the contract data. The example system illustrated in FIG. 6 may implement any of the methods described in the context of FIG. 10A to FIG. 10C. The supply chain product may be a supply chain product as described in the context of FIG. 3. The supply chain product may be produced or producible by a production from one or more input material(s), for example as described in the context of FIG. 3.

[0196] The asset generation and transfer system 302 may be configured to generate the digital asset(s) associated with the supply chain product(s) produced or producible by production 308. The asset generation and transfer system may be configured to generate digital twin(s) of supply chain product(s) produced or producible by the production. The digital twin of a supply chain product may include one or more digital asset(s) associated with the given supply chain product. Digital asset(s) of a digital twin may be linked via a digital twin identifier. The digital twin may be uniquely linked to the physical supply chain product via at least a decentral digital twin identifier. The digital twin may be created such that it is identical in form and behavior of the corresponding supply chain product. Additionally, the digital twin may mirror the properties of the supply chain product during its lifetime. The digital twin may contain the decentral digital twin identifier. The decentral digital twin identifier may be associated with decentral identifiers of input material(s) used to produce the supply chain product. This allows to track the output product within the value chain. The decentral digital twin identifier may or may be assigned to a physical identifier physically connected to the supply chain product.

[0197] The asset generation and transfer system may include one or more component(s), such as data transfer service 602, asset generator servicer 604, asset publisher service 622, rule DB 612, assets DB 304 and contract DB 620. The asset generator service may be configured to generate digital asset(s) in response to receiving a trigger. The trigger may be received from a system configured to detect packaged supply chain products. The trigger may be received from a labelling machine. The trigger may be generated in response to generating a data pipeline configured to generate and provide the digital asset(s) or in response to initiating an existing data pipeline configured to generate and provide the digital asset(s). The data pipeline may be generated as described in the context of FIG. 5. The data pipeline may be associated with configuration data (see FIG. 5). The configuration data may be stored in a local pipeline data storage of the provider tenant. The configuration data may include a configuration data identifier uniquely identifying the configuration data within the provider tenant and data pipeline configuration data associated with a configuration of a data pipeline. The data pipeline configuration data may 241022

[0198] 48 relate to the configuration data identifier and may include a representation for accessing a local source data storage storing supply chain product data used to generate the digital asset(s), e.g. data layer 306, a data model defined by the data provider for generating the digital asset(s) or a data model for collection property / ies of supply chain products provided via the orchestration component by consumer tenants, a mapping for mapping the data points included in the data model or data structure to the data structure of the source data storage and policy data defining access to the generated digital asset(s). The trigger may include the configuration data identifier associated with the generated data pipeline or the initiated data pipeline. The trigger or trigger data may be received by data gathering unit 606 of the asset generator service.

[0199] The data gathering unit may be connected to a local source data storage storing supply chain product data, such as data layer 306. The local source data storage may be associated with the data provider. The local source data storage may be associated with the provider tenant including the system. The local source data storage may include one or more databases, such as DB 1 614, DB 2 616 and DB 3 618. The local source data storage may be owned or controlled by the data owner of the supply chain product data. The local source data storage may be associated with the data owner of the supply chain product data. In response to receiving the trigger, the data gathering unit may gather configuration data associated with data pipelines from a local database storing such configuration data based on the configuration data identifier. The data gathering unit may be configured to gather the supply chain product data based on the configuration data from the local source data storage. In response to receiving the trigger, the data gathering unit may gather supply chain product data based on a digital supply chain product identifier associated with the supply chain product the digital asset is to be generated for.

[0200] The supply chain product data gathered by the data gathering unit may be provided to data transforming unit 608. The gathered supply chain product data may be provided in combination with the configuration data identifier. The data transforming unit may be configured to generate digital asset(s) by transforming the received supply chain product data based on one or more rule(s) stored in a local data storage, such as rule DB 612. The rule(s) may be gathered from the local data storage based on the configuration data identifier and / or the digital supply chain product identifier. The rule(s) may include executable instructions for transforming the supply chain product data. The rule(s) may be associated with a data model defined by the data provider (e.g. defined data model), such as a data model of a product or product type producible from the supply chain product(s). The rule(s) may be associated with a data structure or data model (e.g. provided data model) provided via the orchestration component by the consumer tenant for collecting property / ies of the supply chain product(s) (see for example FIG. 5). The rule(s) may be derived or generated based on the data model of the product or product type and / or based on the data model provided by the consumer tenant.

[0201] The one or more rule(s) may define aggregation rule(s) for aggregating supply chain product data gathered from multiple data sources into a given data structure. The given data structure may be a tabular representation or a 241022

[0202] 49 structured data structure, such as a JSON document. Aggregation may hence result in filling gathered supply chain product data into a tabular data structure or a structured data structure. The one or more rule(s) may define filters to filter gathered supply chain product data. The filters may be associated with or relate to the defined data model or the provided data model. The filters may define data point(s) to be included in the generated digital asset. A filter may define data point(s) per data category. A filter may define data point(s) for at least two different data categories. A data category may signify property data, declaration data, safety data, emission data, recyclate content data, biobased content data, biodegradability data, production data, certificate of analysis data, certificate data, storage instruction data, assembly instruction data or operating condition data. This may ensure that supply chain product data required by the data model used to generate the digital product passport is included in the generated digital asset. The one or more rule(s) may define attribute construction(s) to create or add new attributes to the gathered supply chain product data. The one or more rule(s) may define manipulation(s) to convert supply chain product data point(s). The one or more rule(s) may include a trigger condition and a corresponding group of one more actions. The trigger conditions may involve a set of variables, sometimes called “working memory”, which may contain data (sometimes called “facts” or “data tuples”) representing the states of pertinent real-world items. The one or more action(s) may include attribute construction, filters and / or manipulations. The rule(s) may be associated with a given order defining the order of execution of the rule(s).

[0203] The received supply chain product data may be transformed using a rule-based engine executing the one or more rule(s). The rule-based engine may generate rule data executable by the rule-based engine. The rule data may include or correspond to executable logic. This may allow to transform rule(s) into code that can be executed by the rule-based engine. Execution of the code may result in applying the executable rule data to the gathered supply chain product data to transform the supply chain product data according to the obtained rule(s). Execution of the logic may result in matching gathered supply chain product data to condition(s) included in the executable logic, evaluating the condition(s) with matched supply chain product data and triggering execution of rule actions based on condition evaluation results.

[0204] The generated digital assets may include at least a part of the received supply chain product data. Use of rule(s) associated with a provided data structure ensures that the content and structure of the generated digital asset adheres to the content and structure the consumer tenant expects. This way, more efficient processing of the consumed digital assets may be enabled, allowing more efficient generation of digital product passports and hence more efficient processing of the products and / or production of further products based on the data included in the digital product passports.

[0205] The generated digital asset(s) may include a decentral asset identifier, chemical and / or physical property data point(s), supply chain product identifier data point(s), supply chain product name data point(s), producer data point(s), declaration data point(s), safety data point(s), production data point(s), certificate of analysis data 241022

[0206] 50 point(s), certificate data point(s), life cycle data point(s), storage instruction data point(s), assembly instruction data point(s) and / or processing condition data point(s). The decentral asset identifier may include a UUID or a DID. The decentral asset identifier may not be discoverable and / or accessible for decentral consumer network nodes. The digital asset(s) may include at least a part of the gathered supply chain product data in a tabular data structure. The tabular data structure may be readily consumed via a decentral network by a decentral consume network node connected to local data consumer component(s) of a consumer tenant and may be processed by validating the consumed digital asset for generation of digital product passports (see for example FIG. 12A to FIG. 12D).

[0207] The data transforming unit may further be configured to provide the generated digital assets to data provider unit 610. The data provider unit may be configured to provide the received digital assets to a local target data storage, such as assets DB 304. The digital asset(s) may include or be associated with decentral asset identifier(s) associated with the supply chain product(s) and the digital asset(s). The local target data storage may be configured to store digital asset(s) generated by the data transforming unit for access by the decentral consumer network node(s). The local target data storage may be configured to provide digital asset(s) to the decentral provider network node(s) connected to the local target data storage. The local target data storage may be a dedicated data storage associated with the data owner of the digital assets. The data owner may own such dedicated data storage. The data owner may have access to such dedicated data storage. The data owner may control access to the local target data storage based on the decentral asset identifiers included in the digital asset, for example as described in the context of FIG. 3.

[0208] The data provider unit may further be configured to provide asset metadata to asset publisher service 622. Asset metadata may include the decentral asset identifiers. Asset metadata may further include the configuration data identifier associated with the data pipeline used to generate the digital assets. The asset publisher service may be configured to gather policy configuration data associated with the respective digital asset from the local data pipeline data storage, for example based on the configuration data identifier. The policy configuration data may define decentral participant identifier(s) associated with decentral consumer network node(s) permitted to access at the respective digital asset. This way, decentral consumer network node(s) requesting access to the digital asset may be filtered based on the decentral participant identifier associated with such decentral consumer network node(s). The policy configuration data may further define processing rule data associated with processing rule(s) for processing the digital asset(s). Processing may include storing the digital asset, validating the digital asset and / or generating digital product passports using the validated digital asset. The asset publisher service may be configured to generate policy data based on the gathered policy configuration data. The asset publisher service may be configured to generate the policy data in response to instruction(s) associated with user input(s). The asset publisher service may be configured to generate the policy data based on predefined processing rule data and / or predefined data indicating that the digital representation of the contract data is to be included in the 241022

[0209] 51 policy data. The policy data may be generated per digital asset. The policy data may be generated according to the ODRL Information Model 2.2 from W3C ( https: / / www.w3.org / TR / odrl-model / ).

[0210] The asset publisher service may further be configured to link the generated policy data to the decentral asset identifier associated with the respective digital asset. The policy data linked to the decentral asset identifier(s) may be provided to the decentral provider network node. The decentral provider network node may be configured to control access to digital asset(s) based on policy data linked to such digital asset(s) via the decentral asset identifier(s). The asset publisher service may further be configured to generate a digital representation of contract data, for example as described in the context of FIG. 7. The asset publisher service may be configured to use the generated digital representation during generation of the policy data, for example as described in the context of FIG. 7. The asset publisher service may be configured to provide the digital representation to storage 304 for linking to the respective digital asset stored therein, for example as described in the context of FIG. 7. The asset publisher service may be configured to generate a request for consuming generated digital asset(s) and to provide the request via the local communication protocol to a central orchestration component, for example as described in the context of FIG. 5. The digital representation of the contract data may be included in the request.

[0211] The asset publisher service may further be configured to generate metadata for registering the digital assets with the decentral provider network node connected to the system. The metadata may include the decentral asset identifier and a digital representation of the digital asset. The digital representation may include a representation for accessing the digital asset. The representation may include a locator or pointer to the local target data storage storing the digital asset. The policy data and metadata may be generated by the asset publisher service per digital asset. The generated policy data and metadata may be provided to the decentral provider network node.

[0212] The asset publisher service may further be configured to generate digital representations of the digital assets for discovery of the digital assets within the decentral network. The digital representations may include the decentral asset identifier associated with the digital assets and a representation for accessing the digital asset. The representation may include a locator or pointer to the decentral provider network node. The digital representations may further include digital representations of the contract data. The digital representations may be provided to the decentral network for the decentral asset identifier to be discoverable and / or accessible by the decentral network nodes of the decentral network. The digital representations may be provided to the decentral network to provide access to the digital assts, e.g. via the locator. The digital representation(s) may be provided to a decentral data storage associated with the provider tenant, such as decentral registry 208. The digital representation(s) may be provided to a decentral data storage included in the provider tenant. The decentral data storage may be accessible by the decentral consumer network nodes. Access to the decentral data storage may be controlled by the data owner of the digital assets. Access may be controlled based on policy data associated with the decentral 241022

[0213] 52 data storage and including decentral participant identifier(s) associated with decentral consumer network node(s) allowed to access the decentral data storage. Access may be controlled via the decentral provider network node.

[0214] The decentral provider network node may be configured to control access to digital asset(s) based on associated policy data. The decentral provider network node may be configured to provide digital asset(s) in response to a request received from decentral consumer network node(s) associated with consumer tenant(s), for example as described in the context of FIG. 3. The digital assets may be gathered or fetched by data transfer service 602 based on decentral asset identifiers received from the decentral provider network node from the local target data storage. The data transfer service and / or decentral provider network node may be configured to apply policy data associated with the digital asset to such digital asset prior to providing such digital asset to the decentral consuming network node(s).

[0215] FIG. 7 illustrates a block diagram of an example system for generating and providing policy data associated with digital asset(s) and including a digital representation of contract data associated with the digital asset(s). The digital asset(s) may be associated with supply chain product(s). The policy data may include processing rule data defining processing rule(s) associated with the processing of the respective digital asset by local data consumer component(s) of local data consumer compute and storage environment(s). The processing rule(s) may include permission(s), obligation(s) and / or prohibition(s), for example as described in the context of FIG. 8A to FIG. 8C. The supply chain product may be a supply chain product(s) as described in the context of FIG. 3. The supply chain product(s) may be produced or producible by a production from one or more input material(s), for example as described in the context of FIG. 3.

[0216] The asset publisher service 622 illustrated in FIG. 7 may be included in an asset generation and transfer system 302 described in the context of FIG. 6. The asset publisher service may include a policy generator 714 and a DR contract data generator 724.

[0217] The policy generator may be connected to asset generator service 604 and may receive asset metadata, such as decentral asset identifier(s) associated with digital asset(s) generated by the asset generator service. The policy generator may be configured to generate policy data. The policy data may include a digital representation of contract data, for example as described in the context of FIG. 8A to FIG. 8C. The policy data may define decentral consumer network node(s) allowed to access the digital asset (see for example FIG. 8B). Decentral consumer network node(s) allowed to access the digital asset(s) may be defined via decentral participant identifier(s) associated with such decentral consumer network node(s).

[0218] The policy generator may be configured to generate the policy data based on the digital representation of the contract data received from DR contract data generator 726. The policy generator may be configured to generate the policy data based on received user input indicating processing rule(s) to be included in the policy data. The 241022

[0219] 53 processing rule(s) may include contract data to be included in the policy data. The policy generator may be configured to generate the policy data based on predefined data, for example as described in the context of FIG.

[0220] 6. The policy generator may be configured to link the policy data to the respective digital asset, for example as described in the context of FIG. 8C. The policy generator may be configured to provide the generated policy data to a decentral provider network node (see FIG. 6).

[0221] The policy generator may be configured to trigger generation of a digital representation of contract data. The policy generator may be configured to trigger such generation in response to receiving the decentral asset identifier(s), in response to a user input or based on predefined data. The generation may be triggered by providing an identifier associated with the contract data to be included in the policy data to DR contract data generator 724.

[0222] The DR contract data generator may be configured to generate and provide digital representation(s) of contract data stored in contract DB 620. The contract data may define contractual obligation(s) between the data owner of the digital asset(s) and a data consumer associated with a local data consumer compute and storage environment consuming the digital asset(s). An example of contract data stored in contract DB 620 is illustrated in FIG. 4. The digital representation may include a representation for accessing the contract data and a hash value computed from the contract data. The hash value may be combined with or included in the representation for accessing the contract data. The representation for accessing the contract data may be a pointer to the storage location storing the contract data. Based on the representation, the contract data may be accessed by local data consumer component(s) of the local data consumer compute and storage environment(s).

[0223] The DR contract data generator may be configured to generate the representation for accessing the contract data. The representation may be generated based on a contract data identifier received from the policy generator. The representation may include a pointer to contract DB 620. The contract DB may store contract data. The contract data may be associated with a contract identifier. The contract DB may be publicly accessible, for example via an API. The DR contract data generator may further be configured to compute a hash value from contract data stored in the contract DB. The hash value may be computed per file stored in the contract DB. The hash value may be computed by gathering contract data based on a contract data identifier received from the policy generator from the contract DB and computing the hash value of the gathered contract data. The hash value may be computed by applying a hash function, such as MD5 (Message-Digest Algorithm 5), SHA-1 (Secure Hash Algorithm 1), SHA- 256 (Secure Hash Algorithm 256-bit), SHA-3 (Secure Hash Algorithm 3), CRC32 (Cyclic Redundancy Check 32- bit), BLAKE2, RIPEMD-160 (RACE Integrity Primitives Evaluation Message Digest 160-bit), HMAC (Hash-based Message Authentication Code), Whirlpool or Tiger, to the gathered data.

[0224] The DR contract data generator may be configured to generate the digital representation of the contract data based on the generated representation for accessing the contract data and the computed hash value. The digital 241022

[0225] 54 representation of contract data may be generated per contract data identifier. The digital representation may be generated by joining the representation for accessing the contract data and the computed hash value. The representation and the hash value may be separated by a predefined symbol or letter. This way, the recipient of the digital representation may determine the representation for accessing the contract data and the hash value contained in the digital representation as described in the context of FIG. 16A. An example of a digital representation may include representation for accessing contract data>#<computed hash value>. The generated digital representation may be provided to the policy generator for generation of the policy data. In another example (not shown in FIG. 7), the generated digital representation may be linked to the respective decentral asset identifier(s) and provided to the local storage 304 for updating digital asset(s) stored in such local storage with the digital representation(s) of contract data. This way, the digital representation(s) of contract data may be included in respective digital asset(s) and may be provided to the local data consumer component(s) via the digital asset, allowing to access the contract data based on the digital representation of the contract data after gathering the digital asset. In yet another example, a request for consumption of generated digital asset(s) may be generated and provided via the local communication protocol to the central orchestration component (see FIG. 5). The request may include the decentral participant identifier(s) of decentral consumer network node(s) requested to consume the generated digital asset(s), the decentral asset identifier(s) associated with the generated digital asset(s) requested to be consumed and the digital representation of the contract data. The central orchestration component may be configured to determine recipient local data consumer component(s) and to provide the digital representation, the decentral asset identifier(s) and the endpoint associated with the decentral provider network node providing the digital asset(s) to such determined recipient local data consumer component(s), for example as described in the context of FIG. 5. A component included in the recipient local data consumer component(s) may be configured to gather the contract data based on the received digital representation of the contract data and to verify the gathered contract data and / or to provide the gathered contract data for display (see also FIG. 15A)

[0226] The asset publisher service may further include a component configured to generate digital representations associated with digital twin(s) of the supply chain product(s) (not shown in FIG. 7). The digital twin(s) may include the digital asset(s). The component may be connected to the DR contract data generator. The component may trigger generation of the digital representation of the contract data in response to receiving the decentral asset identifier(s), in response to a user input or based on predefined data. With reference to FIG. 9, the digital representation(s) associated with the digital twin(s) may include the decentral asset identifier(s), a representation for accessing the digital asset(s) included in the digital twin(s) and the digital representation of contract data 838. The component may be configured to provide the generated digital representation(s) associated with the digital twin(s) to the decentral network for the decentral asset identifier(s) and the digital representation of the contract data to be discoverable and / or accessible by decentral consumer network node(s). Providing the generated digital representation(s) associated with the digital twin(s) to the decentral network may include storing such digital representation(s) in a decentral registry, such as registry 208, for storage (see also FIG. 6) 241022

[0227] 55

[0228] FIG. 8A illustrates a data model of policy data expressing permissions, prohibitions and duties related to the processing of an associated asset. The data model may be defined by the ODRL Information Model (see technical report for ODRL Information Model 2.2. at https: / / www.w3.org / TR / 2018 / REC-odrl-model-20180215 / ). The data model may use the Open Digital Rights Language (ODRL). ODRL is a policy expression language that provides a flexible and interoperable information model, vocabulary, and encoding mechanisms for representing statements about the processing of output product data and / or product data exchanged within a decentral network, such as decentral network 134 described in the context of FIG. 1. The data model illustrated in FIG. 8A may be used by the asset publisher service 622 described in the context of FIG. 6 and FIG. 7 to generate the policy data.

[0229] The data model may define various classes that allow to express permissions, prohibitions and duties related to the processing of an associated asset. The policy data may be linked to the asset by including the asset identifier in the policy data. The Policy class 804 may define the Permissions (via the permission property) and / or Prohibitions (via the prohibition property) and / or Duties (via the obligation property). The Policy class may be the parent class to the Set, Offer, and Agreement subclasses. An ODRL Policy of subclass Set 806 may represent any combination of Rules while and ODRL Policy of subclass Offer. The Offer subclass 808 may represent rules that are being offered from assignor Parties to assignee Parties or from assignee parties to assignor parties. An ODRL Policy of subclass Agreement 810 may represent rules that have been granted from an assignor party, such as the data owner of the respective data, to an assignee party, such as the consumer of such data.

[0230] The Asset class 802 may be a resource or a collection of resources that are the subject of a rule. The asset may correspond to a digital asset associated with a given supply chain product.

[0231] The Party class 822 may describe an entity or a collection of entities that undertake functional roles in a rule, such as a person, a collection of people, an organization or the like. The party may or may not perform actions or may have a function in a duty, e.g. by associating the party with the function it plays in the rule. A function property may be used to link a rule to a party to indicate the function undertaken by the Party with respect to the rule that links to it. The function may include sub-properties such as “assigner” and “assignee”. Assignor may indicate the party that is issuing the rule while assigner may indicate the party that is the recipient the of rule.

[0232] The Action class 820 may indicate an operation that can be exercised on the asset. The action may be associated with the asset via the action property in a rule. The rule may provide the specific interpretations of the action. For instance, an action may be permitted to be exercised on the target asset when related to a Permission while an action may indicate that the operation is prohibited to be exercised on the target asset when related to a Prohibition. Actions may involve the use of the asset or the transfer of ownership of the asset.

[0233] The Rule class 812 may represent the parent of the Permission, Prohibition, and Duty classes. The Rule class may represent the common characteristics of these three classes. The Permission sub-class 814 may indicate the 241022

[0234] 56 ability to perform an action on the asset and may inherit all properties from the Rule class 812. The Permission sub-class may have a duty property that indicates an agreed action that must be exercised on the asset as a precondition to be granted the Permission. A permission may hence allow an action, with all refinements satisfied, to be exercised on the asset if all constraints are satisfied and if all duties are fulfilled. In contrast, the Prohibition sub-class 818 may indicate the inability to exercise an action on the asset, e.g. may indicate actions that are not allowed to be performed on the asset. The prohibition may hence disallow an action, with all refinements satisfied, to be exercised on an asset if all constraints are satisfied. The Prohibition sub-class 818 may inherit all properties from the Rule class 812. A remedy property may be used to express an agreed obligation that must be fulfilled in case the prohibition has been infringed. The Duty sub-class 816 may indicate an obligation to exercise an action. The duty may hence be an obligation to exercise the action, with all refinements satisfied. The duty may be fulfilled if all constraints are satisfied and if its action, with all refinements satisfied, has been exercised. If its action has not been exercised, then all consequences must also be fulfilled to fulfil the duty, e.g. consequences are additional duties that must also be fulfilled.

[0235] The Constraint class 824 may be used for expressions which compare two operands (which are not Constraints) by one relational operator. If the comparison returns a match the constraint is satisfied, otherwise it is not satisfied. The Constraint class hence allows to formulate a comparison expression to refine an action applicable to a rule. The Logical Constraint class 826 may be used for comparing two or more operands which are existing Constraints by one logical operator. If the comparison returns a logical match, then the Logical Constraint is satisfied, otherwise it is not satisfied.

[0236] The data model may include property relationships between the classes as illustrated in FIG. 8A. The data model may be used to generate policy data including permissions, prohibitions and / or obligations associated with a given asset. Examples of policy data associated with a given asset and generated using the data model illustrated in FIG. 8A are shown in FIG. 8B.

[0237] FIG. 8B illustrates examples of different policy data that can be linked to an asset. The policy data may be linked to a given asset as described in the context of FIG. 8C. The asset may correspond to a digital asset associated with a given supply chain product or passport data associated with a given product, such as a chemical product or a discrete product.

[0238] The asset 802 may be associated with policy data 842. The policy data may include an access policy 834 and / or a contract policy 836. The access policy and / or the contract policy may be generated using the data model illustrated in FIG. 8A. The access policy may define access to the asset. The access policy may define decentral consumer network node(s) that are allowed to access to the asset. The access policy may define decentral consumer network node(s) that are allowed to be offered asset 802 for access. The decentral consumer network node(s) may be defined by associated decentral participant identifier(s), uniquely identifying the decentral 241022

[0239] 57 consumer network node(s) within a decentral network, such as the decentral network illustrated in FIG. 1. The decentral consumer network node(s) may be defined by their membership within a group allowed to access the asset. This way, decentral consumer network node(s) may be flexibly added or removed from the group without having to adjust the access policy 834.

[0240] The asset may further be associated with a contract policy 836. The contract policy may determine the conditions for initiating data transactions according to the decentral network protocol (e.g. contract negotiations) for asset 802. If a decentral consumer network node fulfils permission(s) and / or obligation(s) defined by the contract policy and does not fulfil prohibition(s) defined by contract policy, the decentral consumer network node may initiate the data transactions for a particular asset. The contract policy may define processing rule(s) as described in the context of FIG. 8A. The contract policy may include the digital representation of contract data 838. This way, processing of the asset may be defined and enforced by the data owner of the asset, such as the supply chain product producer or the product producer. The processing rule(s) may be connected by a logical constraint to define a combination of processing rule(s) that must be adhered to by the local data consumer component(s) processing the asset. Decentral provider network node(s) enforcing the policy data may be configured to determine if condition(s) defined in the contract policy are fulfilled by the decentral consumer network node(s) at the time of executing the data transactions. Decentral consumer network node(s) may prove that condition(s) defined in the contract policy are fulfilled by using one or more verifiable credential(s).

[0241] The policy data, such as the access policy and / or the contract policy, may hence be regarded as a container for processing rule data indicating processing rule(s), such as duties, permissions and / or prohibitions. The processing rule data may include one constraint or multiple constraints. The processing rule data may include the digital representation of contract data 838.

[0242] FIG. 8C illustrates an example of linking policy data to a given asset, such as a given digital asset associated with a given supply chain product. The policy data may be linked to the digital asset via a data set indicating a relationship between the decentral asset identifier(s) associated with the digital asset and the policy data associated with the digital asset. The policy data may include an access policy 834 and / or a contract policy 836.

[0243] Linking of the policy data with the digital asset may be performed by generating a contract definition 840. The contract definition may be a data set defining identifier(s) of the access policy and the contract policy as well as the decentral asset identifier(s) of such digital asset(s) (defined by the query expression “assetsSelector”).

[0244] FIG. 10A illustrates a method for controlling access to digital asset(s) associated with supply chain product(s) by one or more decentral consume network node(s) connected to one or more local data consumer component(s) of one or more local data consumer compute and storage environment(s) associated with one or more data consumer(s). The method illustrated in FIG. 10A may be implemented by any of the systems illustrated in FIG. 3 241022

[0245] 58 and FIG. 6. The supply chain product may be a supply chain product as described in the context of FIG. 3. The supply chain product may be used by one or more downstream participants of the product ecosystem as input material to produce one or more products. The supply chain product may be produced or producible by a production, for example as described in the context of FIG. 3.

[0246] Access to digital asset(s) may be controlled by the data owner of the digital asset(s). The data owner may be the producer of the supply chain product(s). The digital asset(s) may be stored in a local data provider compute and storage environment associated with or controlled by the data owner (see for example FIG. 3 and FIG. 5). The local data provider compute and storage environment may include one or more local data provider component(s) configured to generate digital asset(s) and to provide the generated digital asset(s) for access via the decentral network protocol. The one or more local data provider component(s) may be connected to decentral provider network node(s) configured to provide the digital asset(s) via the decentral network protocol upon request by the decentral consumer network node(s). Access to the digital asset(s) may be controlled based on identifier(s), such as a decentral asset identifier(s), associated with the digital asset(s). Access to the digital asset(s) may be controlled based on policy data associated with the digital asset(s). The policy data may define decentral consumer network node(s) allowed to access the digital asset(s) as well as processing rule(s) defining permission(s), obligation(s) and / or prohibition(s) of local data consumer component(s) connected to the decentral consumer network node(s) allowed to access the digital asset(s). Permission(s) defined by the policy data may include a digital representation of contract data associated with the digital asset(s). The contract data may include processing rule(s) for processing the digital asset by the local data consumer component(s). The processing rule(s) may define allowed processing operation(s) and / or non-allowed processing operation(s). Access to the digital asset(s) may be controlled based at least in part on the contract data associated with the digital representation of contract data. Access to the digital asset(s) may be controlled via the decentral provider network node associated with or controlled by the data owner. The decentral provider network node may have access to the local storage storing the digital assets and may control access to the digital asset(s) stored in the local storage based on the decentral asset identifier(s). The decentral provider network node may control access to the digital asset(s) based on policy data associated with the digital asset(s).

[0247] The digital asset associated with the supply chain product may be provided. The digital asset may include decentral asset identifier(s) and supply chain product data. The decentral asset identifier(s) may be associated with the supply chain product. The decentral asset identifier(s) may further be associated with the output product data. The decentral asset identifier(s) may include one or more Universally Unique Identifier(s) (UUID(s)) and / or one or more Decentralized Identifier(s) (DID(s)). The decentral asset identifier(s) may not be discoverable and / or accessible for decentral consumer network nodes. The decentral asset identifiers may be accessible and / or discoverable for decentral consumer network nodes. The digital asset may be generated by transforming supply 241022

[0248] 59 chain product data using a rule-based engine including one or more rule(s) associated with the product, for example as described in the context of FIG. 6.

[0249] Contract data including processing rule(s) for processing the digital asset by the local data consumer component(s) may be provided. The processing rule(s) may define permitted processing operation(s) and / or prohibited processing operation(s). The processing rule(s) may further define obligation(s) of the local data consumer component(s) with respect to the processing of the digital asset. The contract data may further include contractual obligation(s) between the data owner of the digital asset and the data consumer. The contractual obligation(s) may define legal clause(s) or a set of legal clauses. The contractual obligation(s) may define terms and conditions (TnC) between the data provider and the data consumer. The contract data may include unstructured data. An example of provided contract data is illustrated in FIG. 4. The contract data may be provided as data entry / ies to a digital user interface such as a display. The contract data may be provided based on the decentral asset identifier(s) or digital supply chain product identifier(s) associated with such decentral asset identifier(s). The contract data may be gathered from a database storing contract data based on the decentral asset identifier(s) and / or the digital supply chain product identifier(s). Gathering the contract data may include determining contract data matching the decentral asset identifier(s) and / or the digital supply chain product identifier(s).

[0250] A digital representation of the contract data may be generated by generating a representation for accessing the contract data and by computing a hash value of at least a part of the contract data. The representation may point to the data storage storing the contract data. The data storage may be a publicly accessible data storage, e.g. access to the data storage may not be access restricted. The data storage may be a cloud storage. The data storage may be included in or associated with a web server. The contract data may be stored on a data storage accessible by the local data consumer component(s). The contract data stored in the data storage may be associated with a unique identifier, such as a contract identifier. The digital representation may be generated by appending the computed hash value to the representation for accessing the contract data. The representation for accessing the contract data and the computed hash value may be separated by a predefined symbol, such as a #. This way, computing systems at the data consumer side may determine the representation for accessing the contract data and the computed hash value included in the digital representation of the contract data.

[0251] The representation may be generated based on the contract identifier associated with the provided contract data and a representation for accessing the data storage, such as a URI of the data storage or an API of the data storage. The URI may be a base URL of the data storage. The representation may be generated by appending the contract identifier to the base URL. The representation may be generated based on the contract identifier associated with the provided contract data and an API of the data storage. The representation may be generated by appending the contract identifier to the API. 241022

[0252] 60

[0253] The hash value may be computed by applying a hash function, such as MD5 (Message-Digest Algorithm 5), SHA- 1 (Secure Hash Algorithm 1), SHA-256 (Secure Hash Algorithm 256-bit), SHA-3 (Secure Hash Algorithm 3), CRC32 (Cyclic Redundancy Check 32-bit), BLAKE2, RIPEMD-160 (RACE Integrity Primitives Evaluation Message Digest 160-bit), HMAC (Hash-based Message Authentication Code), Whirlpool or Tiger, to at least a part of the provided contract data. The hash function may be a predefined hash function used for hashing contract data within the decentral network. This way, local data consumer component(s) may be able to verify the data integrity of gathered contract data by computing a hash value of the gathered contract data using the predefined hash function and comparing the computed hash value with the hash value included in the digital representation of the contract data.

[0254] The generated digital representation of the contract data may be linked to the digital asset associated with the decentral asset identifier(s). Linking may include generating a digital asset including the generated digital representation and at least one of the decentral asset identifier(s), for example as described in the context of FIG. 10C and / or FIG. 10D.

[0255] The digital representation of the contract data may be provided for access by decentral consumer network node(s) connected to the local data consumer component(s) and / or the local data consumer component(s) for controlling access to the digital asset at least in part based on the contract data associated with the output product data set. The digital asset accessed upon agreement to the processing rule(s) included in the contract data may be used for generation of digital product passport(s) associated with product(s) produced using the supply chain product. The digital product passport(s) may be generated by one or more of the local data consumer component(s). Access to the digital asset associated with the digital representation of the contract data may be controlled by the data owner based at least in part on the contract data linked to the digital asset. For instance, access to the digital asset may require consent of the local data consumer component(s) and / or the data consumer associated with such component(s) to the processing rule(s) included in the contract data prior to being granted access to the digital asset.

[0256] By using the digital representation of contract data in combination with the policy data, existing agreement(s) including data processing rule(s) associated with the processing of digital assets consumed via the decentral network may be flexibly adjusted and / or tailored to the needs of the data provider. In contrast to the contract data, such agreement(s) have already been signed by the data consumer(s) and the processing rule(s) included in such agreement(s) may not have been defined by the data owner of the digital asset or may not be applicable to the needs of the data owner with respect to the digital asset(s) to be provided by the data owner for access within the decentral network. Hence, the data owner would need to request amendment or updating of processing rule(s) included in such agreement(s). Such amendment or updating of may not be feasible with respect to the negotiation of such amendments with multiple parties, in particular multiple data consumer(s) having signed such 241022

[0257] 61 agreements. Hence, the use of contract data exclusively defined by the data owner may allow the data owner to flexibly adapt or expand processing rule(s) included in existing agreement(s) to the needs of the data owner with respect to the processing of a specific digital asset without having to request amendment of existing agreements. This way, the data owner may flexibly tailor processing rule(s) included in existing agreement(s) to the data included in a specific digital asset. For instance, the data owner may restrict processing rule(s) included in existing agreement(s) by additional use of the contract data for digital asset(s) including composition data associated with the composition of the supply chain product. This way, an efficient sharing of digital assets under full control of the data owner may be enabled within a decentral network, allowing efficient and timely generation of product passports and avoiding gathering of digital assets by a data consumer via a fragmented set of communication channels due to the lack of willingness of data providers to share their digital assets via the decentral network because of unsuitable existing processing rule(s). Efficient gathering of the digital asset associated with the supply chain products via the decentral network is crucial to fulfil regulatory requirements with respect to digital product passports to avoid disruption(s) of supply chains due to the lack of product supplies because of delayed passport generation or incomplete passport data due to missing digital assets or delayed provision of digital assets. In addition, this avoids incomplete and / or missing data present within the digital product passport. This way, a higher data quality of the data included in the digital product passport can be ensured, allowing more efficient processing, such as recycling and / or re-use of the product based on the data included in the digital product passports.

[0258] By using the representation for accessing the contract data, the local data consumer component(s) may access the contract data and may verify the data integrity of the contract data based on the hash value included in the digital representation. This way, trust in the usage of additional processing rule(s) apart from the processing rule(s) included in the policy data can be improved since modification of the contract data may result in failure of the verification of the data integrity of the contract data. This way, the contract data included in an agreement resulting from negotiation of policy data via the decentral network protocol may be clearly defined, avoiding ambiguity on the processing rule(s) governing the processing of the digital asset by the local data consumer component(s). This improves trust of the data owner that defined processing rule(s) will be adhered to by the local data consumer component(s) without having to be defined in policy expression languages to enable negotiation data transaction according to the decentral network protocol. The improved trust of data owners may result in reliable sharing of a larger amount of digital assets and / or of confidential data within the decentral network since data owner(s) can flexibly define suitable processing rule(s) to accommodate their needs in terms of data processing by the local data consumer component(s) while minimizing the risks related to misuse of the digital assets by the data consumer(s). The improved trust of data consumers may result in more efficient processing of the accessed digital assets, since changes to or interruptions of the data processing due to modification(s) to the agreed processing rule(s) by the data owner are avoided. This way, a more reliable and efficient generation of product passport(s) using the accessed digital asset is ensured, enabling a higher data quality of the data 241022

[0259] 62 included in the digital product passport. This allows a more efficient processing, such as recycling and / or re-use of the product based on the data included in the digital product passports.

[0260] FIG. 10B illustrates another embodiment of the method of FIG. 10A. The method illustrated in FIG. 10B describes an embodiment of including the digital representation of contract data in policy data associated with a given digital asset. The policy data may be provided for access by the decentral consumer network node(s). Providing the policy data for access may include providing the policy data upon request to access a digital asset associated with such policy data. Access to such digital asset may be controlled by the data owner of the digital asset based on the policy data, e.g. access to the digital asset may be granted upon successful negotiation of the policy data and hence also the contract data referenced therein according to the decentral network protocol.

[0261] The method illustrated in FIG. 10B may include the steps described in the context of FIG. 10A. The generated digital representation of the contract data may be used to generate the policy data. The policy data may include processing rule data associated with the processing of the digital asset by the local data consumer component(s). The policy data may further include one or more policy data identifier(s) associated with the policy data. The processing rule data may include the generated digital representation of the contract data. The processing rule data may define processing rule(s) associated with the processing of the respective digital asset by the local data consumer component(s). The processing rule(s) may include permission(s), obligation(s) and / or prohibition(s) with respect to the processing of the digital asset. The permission(s) may include access permission(s) defining decentral consumer network node(s) allowed to access the digital asset. The permission(s) may include processing permission(s) defining action(s) of local data consumer component(s) allowed to be performed on the digital asset. The processing permission(s) may include the digital representation of the contract data. The policy data may include at least two policy data set(s) containing different processing rule data. For instance, a first policy data set may include access permission(s) and a second policy data set may include processing permission(s) (see for example FIG. 8B). The policy data may be generated according to a data model for permission, prohibition, and obligation statements describing content processing. The policy data may be generated according to the ODRL Information Model 2.2 (see technical report for ODRL Information Model 2.2. at https: / / www.w3.org / TR / 2018 / REC-odrl-model-20180215 / ) (see also FIG. 8A). Examples of generated policy data including the digital representation of the contract data are illustrated in FIG. 8B. By using the digital representation of the contract data to generate the policy data, the contract data and hence also the processing rule(s) included therein may be referenced within the policy data. This way, conversion of the processing rule(s) according to a data model used to generate the policy data may be avoided, allowing for flexible generation of policy data by referencing contract data as required to control access to the associated digital asset. Such referencing may allow to use contract data including complex processing rule(s) without requiring complex instruction(s) to transform such complex processing rule(s) according to the data model used to generate the 241022

[0262] 63 policy data. In addition or alternatively, such referencing may allow to flexibly modify processing rule(s) having been agreed to by the data consumer(s) for a variety of digital assets and a plurality of data consumers.

[0263] The generated policy data may be linked to the digital asset. The generated policy data may be linked to the digital asset by linking the policy data to the decentral asset identifier(s) associated with or included in the digital asset. Linking of the policy data to the digital asset may include generating a data set including the decentral asset identifier(s) and policy identifier(s) associated with or included in the policy data (see for example FIG. 8C).

[0264] The policy data may be provided for access by the decentral consumer network node(s) for controlling access to the digital asset based on the policy data. Providing the policy data for access may include providing the policy data to the decentral provider network node. The decentral provider network node may be configured to provide the policy data to the decentral consumer network node(s) upon request to access the digital asset (see for example FIG. 3). Access to the digital asset by the decentral consumer network node(s) may be controlled by the data owner based on the policy data linked to the digital asset. For instance, access to the digital asset may require consent to the processing rule(s) defined by the policy data and hence also by the referenced contract data prior to being granted access to the digital asset.

[0265] By linking the digital representation of contract data to digital asset(s), the data owner of the digital asset(s) may flexibly define processing rule(s) with respect to the processing of the digital asset by the local data consumer component(s) without having to convert such processing rule(s) to complex policy expression languages for representing statements about the processing of data, such as the ODRL Information Model. Such policy expression languages may be used within the decentral network to enable negotiation of processing rule(s) between data provider network node(s) and data consumer network node(s) according to the decentral communication protocol in a standardized manner (see for example FIG. 13). Such policy expression languages may not be able to accommodate complex processing rule(s) included in the contract data, hence the data owner may be restricted in the use of contractual obligation(s) when converting contract data into policy expression languages. The use of a digital representation of the contract data avoids such conversion of contract data into policy expression languages, hence allowing to link contract data to digital asset(s) in a flexible and reliable manner irrespective of the complexity of the processing rule(s) included in such contract data. Avoiding conversion results in reduced computing resources, hence improving the environmental impact of the digital asset sharing within the decentral network. This way, digital asset(s) may be shared in a reliable yet secure manner under full control of the data owner of the digital assets despite limitations of existing processing rule(s) and / or of policy expression languages to enable negotiation of the processing rule(s) in a fully automated manner according to decentral network protocols. This way, efficient generation of product passports with a higher data quality of the data included in the digital product passport is enabled, allowing more efficient processing, such as recycling and / or re-use of the product based on the data included in the digital product passports. 241022

[0266] 64

[0267] FIG. 10C illustrates another embodiment of the method of FIG. 10A. The method illustrated in FIG. 10C describes an embodiment of referencing the contract data in a digital representation of a digital twin of a given supply chain product. The digital twin may include one or more digital asset(s) associated with the supply chain product. The digital representation of the digital twin may be provided to a decentral network for access to digital asset(s) included in the digital twin by data consumer(s). The digital representation of the digital twin may be provided to the decentral network for the decentral asset identifier(s) associated with the digital asset(s) and the digital representation of the contract data to be discoverable and / or accessible for decentral consumer network node(s). Access to the digital asset(s) may be controlled by the data owner of the digital asset based at least in part on the referenced contract data, e.g. access to the digital asset may be granted upon agreement to the contract data referenced in the digital representation of the digital twin.

[0268] The method illustrated in FIG. 10C may include the steps described in the context of FIG. 10A. The generated digital representation of the contract data may be used to generate the digital representation of the digital twin of the supply chain product. The digital twin of the supply chain product may include one or more digital asset(s). Digital asset(s) of a digital twin may be linked via a digital twin identifier. The digital twin may be uniquely linked to the physical supply chain product via one or more decentral identifier(s). The digital twin may contain the decentral identifier(s). The decentral identifier(s) may include a decentral digital twin identifier and decentral asset identifier(s). The digital representation of the digital twin may include the digital representation of the contract data, decentral asset identifier(s), the decentral digital twin identifier and one or more representation(s) for accessing digital asset(s) included in the digital twin. Such representation(s) may include an endpoint for accessing the respective digital asset(s). The endpoint may be associated with the decentral provider network node associated with the data owner of the digital asset(s). The data provider network node may be configured to enforce processing rule data included in policy data associated with the digital asset (s), for example as described in the context of FIG. 13.

[0269] The digital representation of the digital twin may be provided for access to the digital asset by the decentral consumer network node(s). The digital representation of the digital twin may be provided to the decentral network for access to the digital asset. Providing the digital representation to the decentral network include storing such representation in a decentral repository associated with or under control of the data owner of digital twin. The decentral repository may be associated with the local data provider compute and storage environment or may be included in such environment. Access to the decentral repository may be controlled by the data owner. Access to the decentral repository may be controlled via the decentral provider network node associated with the data owner. The decentral data providing node may be associated with the decentral repository. The decentral repository may store digital representations of digital twins of output products for access by data consumers via the decentral network. Access to the digital asset may be controlled by the data owner based on the policy data linked to the digital asset and based on the contract data linked to the digital asset. For instance, access to the 241022

[0270] 65 digital asset may require consent to the processing rule(s) defined by the policy data and the contract data prior to being granted access to the digital asset. Consent to the policy data may indicate consent to the contract data since the contract data is accessible to the local data consumer component(s) upon providing data indicating consent with the policy data via the decentral consumer network node(s) connected to such component(s) to the decentral provider network node.

[0271] By referencing contract data in the digital representation of digital twin(s), addition of complex obligation(s) defined by the contract data to the policy data can be avoided while ensuring that all relevant obligation(s) to be fulfilled and / or permission(s) to be granted and / or prohibition(s) defined by the data owner with respect to the processing of the output product data are provided to the data consumer. This way, all relevant obligation(s), permission(s) and / or prohibition(s) may be made transparent to the data consumer prior to requesting access to such data, enabling the data consumer to determine whether data processing to be performed on the data to be consumed by the data consumer is possible or not. Such transparency avoids gathering of data which cannot be processed by the data consumer due to processing rule(s) defined by the data provider, reducing the amount of data exchanged within the decentral network and allowing more efficient exchange of data within the decentral network due to lower latency, improved bandwidth utilization and increased network stability. In addition, reduced data exchange may allow to reduce the environmental impact associated with the operation of the decentral network due to reduced energy consumption required to provide data, to gather data and / or to process data.

[0272] FIG. 10D illustrates another embodiment of the method of FIG. 10A. The method illustrated in FIG. 10D describes an embodiment of providing the digital representation of the contract data via a local communication protocol using a central orchestration component to local data consumer component(s) of local data consumer compute and storage environment(s) associated with data consumer(s). The digital representation of the contract data may be provided by local data provider component(s) of a local data provider compute and storage environment associated with the data owner of the digital asset via the local communication protocol to the central orchestration component.

[0273] The method illustrated in FIG. 10D may include the steps described in the context of FIG. 10A. A request for consumption of the generated digital asset via the decentral network protocol by the decentral consumer network node(s) may be generated. The request may include the digital representation of the contract data, decentral asset identifier(s) of digital asset(s) to be consumed and decentral participant identifier(s) associated with decentral consumer network node(s) requested to consume the digital asset(s). The request may be provided via the local communication protocol to the central orchestration component, for example as described in the context of FIG. 5. The central orchestration component may be configured to determine request recipients based on the decentral participant identifier(s) and to provide the request via the local communication protocol to the determined local data consumer component(s). The request provided by the central orchestration component to 241022

[0274] 66 the local data consumer component(s) may include the digital representation of the contract data, the decentral asset identifier(s) and the endpoint of the decentral provider network node providing the digital asset(s).

[0275] By providing the digital representation of the contract data via the central orchestration component to the local data consumer component(s), such component(s) may gather the contract data and may verify the gathered contract data with respect to data integrity and acceptability of included processing rule(s) prior to requesting access to the digital asset. This way, it can be ensured that the processing rule(s) defined by the data owner of the digital asset are acceptable for the data consumer, avoiding gathering of digital assets that cannot be processed by operation(s) performed by the local data consumer component(s). This reduces the number of data transactions within the decentral network, allowing to reduce the environmental impact associated with the sharing of digital assets within the decentral network.

[0276] FIG. 11 illustrates a method for monitoring and / or controlling generation of digital asset(s) to be provided for access via a decentral communication protocol by one or more decentral consumer network node(s) connected to one or more of the local data consumer component(s) of a local data consumer compute and storage environment associated with a data consumer. The digital asset(s) may be associated with supply chain product(s). The supply chain product(s) may supply chain product(s) described in the context of FIG. 3. The supply chain product may be used by one or more downstream participants of the product ecosystem as input material to produce one or more products. The supply chain product may be produced or producible by a production, for example as described in the context of FIG. 3. The method illustrated in FIG. 12 may be implemented by one or more of the local data consumer component(s).

[0277] Data associated with the product may be provided. Data associated with the product may include product identifier(s), a product name, a product type, a product class or a combination thereof. The product identifier(s) may include a batch number, a LOT number, a serial number, a part number, an identification number or a combination thereof. The product may be produced or producible by a production, for example as described in relation to FIG. 3.

[0278] Contract data including rule(s) for generating the digital asset by one or more local data provider component(s) of a local data provider compute and storage environment associated with a data provider may be provided. The local data provider component(s) may be connected to decentral provider network node(s) configured to provide the digital asset(s) via a decentral network protocol. The rule(s) may define requirements to be fulfilled by the local data provider component(s) before and / or during generation of the digital asset. The contract data may further define processing rule(s) for processing the generated digital assets. The contract data may further define contractual obligation(s) between the data owner (e.g. data provider) of the digital asset and the data consumer of the digital asset. The contractual obligation(s) may include obligation(s) of the data provider with respect to the generation of the digital asset and / or processing rule(s) with respect to the processing of the generated digital 241022

[0279] 67 asset. The contractual obligation(s) may define legal clause(s) or a set of legal clauses. The contractual obligation(s) may define terms and conditions (TnC) between the data provider and the data consumer. The contract data may include unstructured data. An example of provided contract data is illustrated in FIG. 4. The contract data may be gathered from a database storing contract data based on the data associated with the product. Gathering the contract data may include determining contract data matching the data associated with the product.

[0280] A digital representation of the contract data may be generated, for example as described in the context of FIG. 10A. The digital representation may include a representation for accessing the provided contract data and a hash value of at least a part of the contract data.

[0281] A trigger for generation of the digital asset and for provisioning of the generated digital asset for access via the decentral network protocol by the decentral consumer network node(s) may be generated based on the digital representation of the contract data. The trigger may further be generated based on configuration data for requesting generation of the digital asset and provisioning of the generated digital asset for access via the decentral network protocol by the decentral consumer network node(s). The configuration data may be associated with a data pipeline configured to process consumed digital assets, for example as described in the context of FIG. 5. The trigger may include the digital representation of the contract data, the decentral participant identifier(s) associated with the decentral provider network node(s) and a local identifier associated with the local data consumer compute and storage environment.

[0282] The generated trigger may be provided via the local communication protocol to at least one orchestration component for triggering generation of the digital asset according to the rule(s) and provisioning of the digital asset for access via the decentral network protocol. The at least one orchestration component may be configured to determine local identifier(s) associated with the local data provider compute and storage environment(s) based on the received trigger and to provide a request for generating and providing the digital asset via the local communication protocol to the local data provider compute and storage environment(s) associated with the determined local identifier(s). The request may include the digital representation of the contract data. Based on such received digital representation, the local data provider component(s) may gather the contract data and may generate the digital asset(s) based on the rule(s) included in such contract data. The local data provider component(s) may provide the generated digital asset(s) for access by the decentral consumer network node(s).

[0283] By providing the rule(s) associated with the generation of digital asset(s) via the orchestration component to the local data provider component(s), the data consumer(s) may ensure that the digital assets are generated according to the rule(s) defined by the contract data. This way the generated digital assets may include the data and may posses the data structure the local data consumer component(s) expect for processing. This allows efficient processing of gathered digital assets and hence also efficient generation of digital product passports 241022

[0284] 68 associated with the product based on the processed digital assets. By providing the contract data associated with the processing of digital asset(s) via the digital representation to the local data provider component(s), the data consumer(s) may render processing of digital asset(s) transparent to such data provider(s) prior to the data provider(s) providing any digital asset(s) to such data consumer(s). This allows local data provider node(s) to determine whether such processing complies with processing rule(s) associated with such digital asset(s) prior to generating and / or providing such digital asset(s) for access to decentral consumer network node(s) associate with such data consumer(s). Such transparency may aid in efficient generation of digital asset(s) and efficient processing of consumed digital assets since failure of asset transfer due to lack of consent to processing rule(s) associated with the digital assets or failure of processing due to lack of data or incompatible data structures may be avoided.

[0285] FIG. 12A illustrates a block diagram of an example system for validating policy data and contract data associated with digital assets of supply chain products and for validating digital assets gathered via a decentral communication protocol. The supply chain product(s) may supply chain product(s) described in the context of FIG. 3. The policy data may include processing rule data defining processing rule(s) associated with the processing of the digital asset by local data consumer component(s). The processing rule(s) may include permission(s), obligation and / or prohibition(s) with respect to the processing of the digital asset, for example as described in the context of FIG. 7 to FIG. 8C. The contract data may govern the processing of the digital asset the contract data is associated with by the local data consumer component(s). The contract data may include one or more contractual obligation(s) between a data owner of digital assets and a data consumer associated with local data consumer component(s) processing the digital assets, for example as described in the context of FIG. 4.

[0286] The asset generation and transfer system 314 may be included in a local consumer storage and compute environment, such as consumer 1 environment 204, described in the context of FIG. 5. The asset generation and transfer system may include various components, e.g. local data consumer components, described in the following. The data consumer may be an entity generating digital product passports for product(s) produced or producible from the supply chain product(s). The entity generating digital product passports may be an endproduct producer. The entity generating digital product passports may be a third party generating digital product passports on behalf of a participant of the product ecosystem. The data consumer may be a product producer consuming the supply chain product(s) to produce one or more product(s).

[0287] Some of the local data consumer components may be connected to decentral consumer network node 122. The node may be part of a decentral network, such as decentral network 134 described in the context of FIG. 1. The node may be configured to exchange data with other decentral network nodes, such as decentral provider network nodes according to a decentral communication protocol. The node may be configured to gather data, such as policy data, digital representation(s) of digital twin(s) of supply chain product(s) and / or digital assets, according to 241022

[0288] 69 the decentral communication protocol, for example as described in the context of FIG. 3. The node may be configured to provide the gathered data to processing rule validator 1228 and / or to asset validation system 1224 for validation.

[0289] The processing rule validator may be configured to validate policy data associated with digital assets to be gathered from decentral provider network nodes according to the decentral communication protocol. The processing rule validator may be configured to gather contract data based on a representation for accessing the contract data included in the policy data, the digital representation(s) or a request received from the orchestration component 502 described in the context of FIG. 5. The processing rule validator may be configured to validate the policy data and / or the contract data as described in the context of FIG. 12B and FIG. 16A.

[0290] The asset validation system may be configured to validate digital assets gathered from the decentral provider network nodes according to the decentral communication protocol. The asset validation system may validate the digital assets using a rule-based engine including one or more rule(s) associated with at least one product produced or producible from the supply chain product(s). The asset validation system may be configured to validate the gathered digital assets as described in the context of FIG. 12C and FIG. 15B. The asset validation system may be configured to provide validated digital assets for storage in one or more databases, such as asset storage general 1204 and / or asset storage App X 1206. The asset validation system may be configured to trigger generation of digital product passports by passport generation system 1238.

[0291] FIG. 12B illustrates a block diagram of an example system for validating policy data and contract data associated with digital assets. The digital assets may be associated with supply chain products. The supply chain products may include supply chain products as described in the context of FIG. 3. The system may be configured to perform the methods described in the context of FIG. 15A.

[0292] For gathering digital assets at decentral provider network nodes by the decentral consumer network node 122 according to the decentral communication protocol, acceptance data indicating acceptance of policy data associated with the digital assets needs to be provided to the decentral provider network nodes to receive the digital assets from such nodes. For generating such acceptance data, the permission(s), obligation(s) and / or prohibition(s) defined by policy data need to be validated and / or verified by local data consumer component(s) to ensure that acceptance data is only generated for policy data defining acceptable permission(s), obligation(s) and / or prohibition(s). This may enable processing of gathered digital assets according to instructions executed by the local data consumer component(s) while avoiding gathering of digital assets which cannot be processed by the local data consumer component(s). Reduction of unnecessary data transactions may allow to improve the environmental impact of the data exchange performed within the decentral network as well as improved bandwidth, latency and stability of the decentral network. 241022

[0293] 70

[0294] The processing rule validator 1228 may receive policy data and / or digital representation(s) of digital twin(s) of supply chain product(s) from decentral consumer network node 122 connected to the processing rule validator. The policy data may be received from decentral provider network node(s) in response to a request to access the digital assets at such decentral provider network node(s), for example as described in the context of FIG. 3. The policy data may include processing rule data. The processing rule data may define permission(s), obligation(s) and / or prohibition(s) of local data consumer component(s) with respect to the processing of the digital asset associated with the policy data. The processing rule data may include a digital representation of contract data. The contract data may define contractual obligation(s) between the data owner of the digital asset(s) and a data consumer associated with a local data consumer compute and storage environment consuming the digital asset(s), for example as described in the context of FIG. 4. The contract data may include processing rule(s) for processing the digital asset by the local data consumer component(s). The processing rule(s) may define allowed processing operation(s) and / or non-allowed processing operation(s). The digital representation(s) of digital twin(s) may be received in response to querying decentral repositories for given decentral identifier(s), for example as described in the context of FIG. 3. The digital representation(s) of digital twin(s) may include the digital representation of contract data.

[0295] In addition or alternatively, the processing rule validator may be configured to receive a request for consumption of generated digital assets via a local communication protocol from orchestration component 502, for example as described in the context of FIG. 5. The request may include the digital representation of contract data. The request may be generated by the orchestration component in response to a trigger received via the local communication protocol from local data provider component(s) generating the digital representation of contract data, for example as described in the context of FIG. 5 and FIG. 7.

[0296] The policy data, digital representation(s) of digital twin(s) and / or the requests may be received by data gathering unit 1232. The data gathering unit may be configured to gather contract data based on the digital representation of contract data included in the received policy data, digital representation(s) of digital twin(s) and / or the requests. The data gathering unit may be configured to parse the received policy data, digital representation(s) of digital twin(s) and / or the requests to determine the representation for accessing the contract data and the hash value included in the digital representation of contract data. The data gathering unit may be configured to gather contract data from a database storing the contract data based on the representation for accessing the contract data. The database, such as contract DB 324, may be associated with or included in local data provider compute and storage environments, such as environment 202. The data gathering unit may be configured to provide gathered contract data to hash generator 1234. The data gathering unit may be configured to provide gathered contract data to validation engine 1236. The contract data may be linked to decentral asset identifier(s) associated with the digital assets. This way, contract data may be uniquely allocated to the respective digital asset. The data 241022

[0297] 71 gathering unit may be configured to provide the digital representation of contract data and the policy data to the validation engine.

[0298] The hash generator may be configured to compute hash value(s) for contract data received from the data gathering unit. The hash value(s) may be computed by applying a predefined hash function to received contract data. Predefined hash function(s) may include the function(s) described in the context of FIG. 7. The hash generator may be configured to link the computed hash value to decentral asset identifier(s) associated with the contract data. The hash generator may be configured to provide the computed hash value optionally linked to the decentral asset identifier(s) to the validation engine. The hash generator may further be configured to provide the contract data used to compute the hash value to the validation engine.

[0299] The validation engine may be configured to validate the policy data and the contract data. Validation of the policy data may include validation of the permission(s), obligation(s) and / or prohibition(s) defined by the policy data. Validation of the contract data may include verification of the data integrity of the contract data. Validation of the contract data may further include validation of contractual obligation(s) defined by the contract data. The validation engine may be configured to provide the contract data and / or permission(s), obligation(s) and / or prohibition(s) defined by the policy data for display for validation of the contractual obligation(s), permission(s), obligation(s) and / or prohibition(s) by a user and to detect and / or receive data indicating validation or rejection of the contract data and / or the policy data. The validation engine may be configured to generate a validation result based on the data indicating validation or rejection. The validation result may indicate acceptance of the policy data and the contract data or rejection of the policy data and / or the contract data. The validation engine may be configured to provide the validation result to the decentral consumer network node 122 connected to the validation engine. The node 122 may be configured to generate offer data or the data indicating rejection depending on the validation result and to provide the offer data or the data indicating rejection to decentral provider network node(s), such as node 1 18, having provided the policy data (see for example FIG. 13).

[0300] The validation engine may include a rule-based engine including one or more processing rule(s). The processing rule(s) may be stored in a rule database (not shown in FIG. 12B) and may be gathered by the rule-engine upon receiving data to be validated. The rule(s) may be gathered based on the type of data (e.g. policy data and / or contract data) to be validated. The processing rule(s) may be configured to validate the received policy data and to verify the received contract data. The processing rule(s) may further be configured to validate the received contract data. The processing rule(s) may include instruction(s) or executable logic configured validate the policy data by matching at least a part of the policy data, such as processing rule data included in the policy data, and / or the contract data, such as the computed hash value, to predefined processing rule data stored in the rule database. Predefined processing rule data may include allowable processing rule data, hash value(s) of acceptable contract data and / or data associated with agreements having been signed by the data consumer. Data 241022

[0301] 72 associated with signed agreements may include agreement identifier(s) associated with or included in such signed agreement(s). The signed agreement(s) may be valid agreement(s), e.g. may not be revoked, terminated and / or lapsed.

[0302] The processing rule(s) may further include instruction(s) or executable logic configured verify the contract data by determining the hash value included in the received digital representation of contract data associated with given decentral asset identifier(s) and to compare such determined hash value with the hash value received from the hash generator for such decentral asset identifier(s).

[0303] The rule-based engine may operate on individual data point(s) included in the policy data and / or the contract data, multiple data point(s) included in the policy data and / or the contract data and / or the whole policy data and / or contract data. The rule-based engine may be configured to apply one or more processing rule(s) to at least a part of the policy data and the contract data to be validated. Validating the policy data may include determining the acceptability of the policy data. Policy data may be considered acceptable if one or more rule(s) related to the policy data validation and applied by the rule-based engine are fulfilled. Policy data may be considered acceptable if the processing rule data included in such policy data match predefined processing rule data. Validating the contract data may include verifying the data integrity of the contract data. Validating may further include determining the acceptability of the contract data. Contract data may be considered verified if the hash value included in the digital representation of contract data matches the computed hash value of the contract data associated with such digital representation (e.g. the hash value computed by the hash generator). Contract data may be considered acceptable if one or more rule(s) related to the contract data validation and applied by the rule-based engine are fulfilled. Contract data may be considered acceptable if the contract data matches predefined contract data.

[0304] The rule-based engine may be configured to generate a validation result. The validation result may include data indicating validation of the policy data and the contract data or data indicating rejection of the policy data and / or the contract data. The validation result may be generated based on whether processing rule(s) applied to the policy data and the contract data are fulfilled or are at least in part not fulfilled.

[0305] In addition or alternatively to the rule-based engine, the validation engine may include a data-driven model trained on historical data sets including policy data sets and associated acceptability scores and / or including contract data sets and associated acceptability scores. The data-driven model(s) may be stored on a data storage (not shown) associated with the validation engine and may be gathered by the validation engine upon validation of received policy data and contract data.

[0306] The data driven-model may include a data processing layer, an embedding layer, a named entity recognition (NER) layer, an intermediate representation layer and a classifier layer. The data processing layer may be 241022

[0307] 73 configured to tokenize the input, to normalize the input, to remove common stop words and / or to reduce words to their base or root form. Normalizing the input may include converting text to lowercase, removing punctuation and / or handling of special characters. The data processing layer may be a Convolutional Neural Network or an encoder comprising multiple layers of self-attention mechanisms and feed-forward neural networks. The embedding layer may be configured to convert the output of the processing layer into embeddings. The embedding layer may be a pre-trained model like BERT (Bidirectional Encoder Representations from Transformers) or RoBERT (Robustly Optimized BERT). The NER layer may be configured to extract key entities related to the contractual obligations of the data consumer with respect to the processing of the input material data. Key entities may include “consent”, “permitted”, “prohibited”, “obligation”, “third party”, “processing”, “storage” or the like. The Intermediate Representation Layer may be configured to abstract, process, and transform features extracted by previous layers to capture complex patterns, relationships, and dependencies in the data. The Intermediate Representation Layer may provide contextual or semantic-enriched representations that encapsulate more information than the output of previous layers. The Intermediate Representation Layer may include Convolutional Layers (CNNs), Recurrent Layers (RNNs, LSTMs, GRUs), Self-Attention Layers and / or Multi-Head Attention layers, encoder layers and decoder layers or encoder layers, Feedforward Neural Networks (FFNs), Normalization Layers, Dropout Layers and / or Residual Connections. The Intermediate Representation Layer may be a Bi-LSTM (Bidirectional Long Short-Term Memory), a CNN, an RNN, a neural network architecture using self-attention and / or multi-attention mechanisms such as BERT or GPT or an FFN. The classifier layer may include dense layers, dropout layers and an output layer. The output layer may output the binary classification. The data processing layer, the embedding layer, the named entity recognition (NER) layer, the intermediate representation layer and the classifier layer may be implemented using an open source library, such as SpaCy.

[0308] The data-driven model may be trained using training data (e.g. historical data sets). The training data may be collected by gathering various policy data associated with various digital assets (e.g. historical policy data) and / or various contract data associated with various digital assets (e.g. historical contract data) and annotating individual data points and / or combinations of data points and / or the whole data with acceptability score(s). The acceptability score(s) may indicate the acceptability of respective individual data points, combination of data points or the whole data. For instance, an acceptability score of 1 indicates that the data point, combination of data points or whole data is unacceptable while an acceptability score of 5 indicates that the data point, combination of data points or whole data is acceptable. Scores between 1 and 5 may be used to indicate a finer degree of acceptability. Hence, the acceptability score may be regarded as the likelihood that the data point, combination of data points or the whole data is considered acceptable or not. The training data set may include samples throughout a full range of acceptability scores.

[0309] Policy data and / or contract data to be validated may be provided as input to the trained data driven model. The input may be classified into “acceptable” or “not acceptable” or into “validated” and “non-validated” based on 241022

[0310] 74 acceptability score(s) determined for the input by the trained data-driven model. The classification generated by the trained data-driven model may correspond to the validation result.

[0311] By using the rule-based engine and / or the trained data-driven model, the acceptability of permission(s), obligation(s) and / or prohibition(s) included in the policy data as well as contractual obligation(s) included in the contract data may be reliably validated prior to initiating transfer of digital assets associated with the policy data and the contract data. This allows to ensure that the digital assets gathered according to the decentral communication protocol can be processed by instruction(s) executed by the local data consumer component(s) while avoiding gathering of non-processable digital assets. This way, it can be ensured that digital assets are only gathered from decentral provider network nodes according to the decentral communication protocol if associated policy data and contract data allows to process the digital assets according to instructions executed by the local data consumer component(s). This avoids unnecessary data transactions within the decentral network, allowing to reduce the environmental impact associated with the generation of digital product passports and improving the latency, bandwidth and stability of the decentral network. This aids in improving the trust of data providers with respect to adherence to processing rule(s) defined by the policy data and the contract data, enabling reliable sharing of digital assets within the decentral network. This way, the data quality of the digital product passport(s) generated based on gathered digital assets can be improved, allowing more efficient processing of the products based on data included in such passport(s).

[0312] FIG. 12C illustrates a block diagram of a system for validating digital asset(s) associated with supply chain product(s) used to produce a product. The supply chain product(s) and product(s) may include supply chain products and products described in the context of FIG. 3. The system may be configured to perform the methods described in the context of FIG. 15B.

[0313] For ensuring that digital assets gathered from decentral provider network nodes according to the decentral communication protocol fulfil predefined conditions, for example with respect to data structure of the digital assets and / or data point(s) included in the digital assets, the gathered digital assets may be validated by asset validation system 1224. The asset validation system may include one or more local data consumer component(s), such as data transfer service 1208, stream storage system 1218 and data transforming unit 1210. Various databases, such as rule DB 1212, asset storage general 1204 and asset storage App X 1206 may be connected to the data transforming unit.

[0314] The data transfer service may be configured to initiate gathering of the digital assets, for example by providing decentral asset identifier(s) associated with the digital assets to be gathered to the decentral consumer network node, e.g. node 122, connected to the data transfer service. The decentral asset identifier(s) may be provided to the node in response to validating contract data associated with the decentral asset identifier(s), for example as described in the context of FIG. 12B and FIG. 15A. In response to receiving the decentral asset identifier(s), the 241022

[0315] 75 node may be configured to request access to the digital asset(s), for example as described in the context of FIG. 13. The node may be configured to provide received digital assets to the data transfer service. The received digital assets may represent a stream of data. Such a stream may be an ordered sequence of records received from the node relatively continuously, i.e. not in accumulated batches or chunks. A record may for example comprise a digital asset associated with a given supply chain product via the decentral asset identifier. The records may or may not be time-ordered. The data transfer service may be configured to generate data package(s) per received digital asset. The data package may include further data, such as a time stamp, a date stamp, the decentral participant identifier associated with the decentral provider network node, an endpoint of the decentral provider network node or a combination thereof. The data package may represent a message or an event. The data transfer service may be connected to the stream storage system. The data transfer service may be positioned downstream from the stream storage system, e.g. digital assets may flow through the data transfer service and the stream storage system to the data transforming unit. The data transfer service may be configured to provide the generated data packages to the stream storage system.

[0316] The stream storage system may be configured to store data packages received (e.g. pushed) or gathered (e.g. pulled) from the data transfer service in one or more persistent or non-persistent logs, such as logs 1220, 1222. Records stored in said logs may be ordered, for example by using IDs. This allows to identify a record within a specific log. A record may include a data package received or gathered from the data transfer service. The stream storage system may provide a streaming service or stream processing service between one or more streaming sources (e.g. the data transfer service) and one or more streaming sinks (e.g. the logs). The stream storage system may act as a persistent or non-persistent stream sink for digital assets received from the node 122. For example, open-source software systems such as Apache Kafka ("Kafka") or Azure Event Hubs may act as a persistent stream sink. The stream storage system may be configured to determine if the received or pulled data packages are already contained in the one or more persistent or non-persistent logs. This may avoid that the same data package is stored multiple times in the persistent or non-persistent log(s), hence avoiding redundant validation operations on the digital assets included in such data packages by the data transforming unit. The stream storage system may be configured to provide the stored data to the data transforming unit, such as data consuming unit 1414 of the data transforming unit.

[0317] The data consuming unit may be configured to ingest and process digital assets included in data packages stored within the log(s). The stream storage system may be in a publisher-subscriber relationship with the data consuming unit. For instance, data in one or more the logs(s) may be periodically read (e.g. pulled) by the data consuming unit. To avoid consumption of a data package stored in a log several times, an integer indicating the offset to the next data package to be consumed may be used. Such integer may be periodically checkpointed. Use of such an integer may allow the data consuming unit to re-consume data packages by rewinding the integer to an old offset. The data consuming unit may be connected to the data validation unit. The data consuming unit may be 241022

[0318] 76 configured to provide data packages gathered from the stream storage system to the data validation unit for validation of digital assets included in said data packages. The data consuming unit may be configured to extract data included in the digital assets from the data packages and provide the extracted decentral asset identifier and supply chain product data to the data validation unit.

[0319] The data validation unit may be configured to validate digital assets (e.g. supply chain product data included in the digital assets and / or the data structure of the digital assets) based on configuration data associated with a data pipeline configured for validation of digital assets. The configuration data may be associated with one or more rule(s) stored in rule DB 1212. The data validation unit may include a rule based engine including one or more rule(s) associated with product(s) produced from the supply chain product(s) associated with the digital assets to be validated. The one or more rule(s) may be associated with or derived from a data model of the product or product type / class the product is associated with. The product may be a chemical product, a component, a component-assembly, an end-product or a recycled material. Hence, the one or more rule(s) may ensure that data point(s) associated with supply chain product(s) and being required according to the data model of the product / product type may be included in the consumed digital assets. The rule based engine may operate on individual data point(s), multiple data point(s) and / or the gathered digital assets. The rule based engine may operate on data gathered per decentral asset identifier individually. This allows to validate digital assets per supply chain product, hence allowing a more granular validation of the digital assets. The rule based engine may have access to the one or more rule(s). The rule based engine may include the one or more rule(s). The one or more rule(s) may be present within a rule template. The one or more rule(s) and / or the rule template(s) may be stored in the rule DB. The one or more rule(s) or rule template(s) may be provided to the rule DB by a user. The one or more rule(s) may correspond to unstructured data associated with validation operation(s). The rule template(s) may include unstructured data associated with instructions related to validation operation(s). The one or more rule(s) or the rule template may be included in a file provided by the user. The one or more rule(s) or the rule template(s) may be associated with supply chain product type identifier(s) and / or supply chain product identifier(s). Rule based engine may generate a request to obtain one or more rule(s) from the rule DB. The request may contain the respective supply chain product identifier(s).

[0320] One or more rule(s) associated with the digital asset to be validated (e.g. one or more applicable rule(s)) may be provided to rule based engine in response to the request. The one or more rule(s) may define data point(s) and / or combination(s) of data point(s) to be present within the consumed digital asset. The one or more rule(s) may be defined by mandatory supply chain product point(s) present within the data model. The one or more rule(s) may be generated based on the mandatory supply chain product data point(s) present within the data model. This may ensure that supply chain product data required by the data model is included in the consumed digital assets. The one or more rule(s) may define one for more supply chain product data points associated with property / ies, name(s), a producer, declaration(s), safety data, emission(s), a recyclate content, a biobased content, a renewable content, a biodegradability, the production, certificate(s) of analysis, certificate(s), a life cycle, storage instruction(s), assembly instruction(s) and / or processing condition(s) of the supply chain product. The rule may define data point(s) per data category. The rule may define data point(s) for at least two different data categories. A data category may signify property data, declaration data, safety data, emission data, recyclate content data, biobased content data, renewable content data, biodegradability data, production data, certificate of analysis data, certificate data, storage instruction data, assembly instruction data or processing condition data. The one or more rule(s) may be associated with supply chain product identifier(s) and / or supply chain product type identifier(s), allowing to gather such rules based on such identifier(s). Use of rule(s) associated with supply chain product type identifier(s) allows to avoid generation of rule(s) per supply chain product identifier and to reduce the number of rule(s) that need to be generated, stored and maintained in the rule DB.

[0321] The rule engine may be initialized, for example based on rule(s) stored in the storage. Initialization of the rule engine may include generating rule data executable by a processor included in rule based engine. The rule data may include or correspond to executable logic. This may allow to transform rule(s) or rule template(s) present in unstructured data form into code that can be executed by the processor. Execution of the code may result in applying the executable rule data to the extracted supply chain product data to validate such data according to the obtained rule(s). Execution of the logic may result in matching extracted supply chain product data to data point(s) and / or combination(s) of data point(s) included in the executable logic, evaluating the data point(s) or combination(s) of data point(s) with matched supply chain product data and generating validation result data based on the evaluation results. Extracted supply chain product data may be validated if the extracted supply chain product data does include all data point(s) required according to one or more obtained rule(s). Extracted supply chain product data may not be validated or only partially validated if the extracted supply chain product data does not include data point(s) required according to one or more obtained rule(s). The validation result data may include a classifier and associated validated or non-validated supply chain product data point(s). The classifier may be a binary classifier discriminating validated and non-validated supply chain product data.

[0322] By validating the digital assets and / or data included in the digital assets against one or more rule(s) generated from the data model, it may be ensured that supply chain product data required by the data model is indeed included in the gathered digital assets, allowing to ensure that digital product passport(s) generated from such validated supply chain product data include all required supply chain product data points. Validation of the supply chain product data on data point level may allow to reliably perform the validation irrespective of the data structure of the digital assets. This may allow, in turn, to generate the digital assets without having to use complex data models, hence allowing efficient and reliable generation of such digital assets and provisioning of such digital assets for access. This way, the data quality of the digital product passports may be improved, allowing more efficient processing of products associated with such passports based on the data included in such passports. 241022

[0323] 78

[0324] The validated supply chain product data generated by the data validation unit may include one or more validated property data point(s), validated identifier data point(s), validated name data point(s), validated producer data point(s), validated declaration data point(s), validated safety data point(s), validated emission data point(s), validated recyclate content data point(s), validated biobased content data point(s), validated renewable content data point(s), validated biodegradability data point(s), validated production data point(s), validated certificate of analysis data point(s), validated certificate data point(s), validated life cycle data point(s), validated storage instruction data point(s), validated assembly instruction data point(s) and / or validated processing condition data point(s).

[0325] In response to receiving the validation result, the data validation unit may be configured to determine target data storage(s) where the validated supply chain product data and / or the non-validated supply chain product data is to be persisted to. The target data storage may be determined based on the configuration data including a representation for accessing the target data storage. By persisting the validated supply chain product data in predefined target data storages, data security may be improved by avoiding unauthorized access to such data, for example by computing node(s) or executable instructions configured to generate digital product passports for products not being produced from the supply chain product(s) the supply chain product data stored in the target data storage is associated with. The data persistent in the target data storage may be used by a passport generator service to generate and / or update digital product passports based on such persisted data. The data validation unit may further be configured to provide the validated supply chain product data to the determined target data storage(s). Non-validated supply chain product data may be persisted to a different target data storage than validated supply chain product data. Non validated supply chain product data may be associated with a classifier indicating non-validation.

[0326] The asset validation system may further be configured to generate incident data based on the non-validated supply chain product data. The non-validated supply chain product data may be associated with rule data indicating the rule that resulted in non-validation of the respective data point. The rule data may include the rule. The rule data may include the executable logic generated from the rule. Incident data may include the decentral asset identifier(s) associated with the gathered digital asset(s) and non-validated supply chain product data associated with such decentral asset identifier. The incident data may be provided to the data transfer service. The data transfer service may be configured to determine the decentral provider network node(s) having provided the digital assets including the non-validated supply chain product data based on a mapping of decentral asset identifier(s) and endpoints of such decentral provider network node(s). The data transfer service may be configured to initiate a transfer of the incident data to the determined decentral provider network node(s), via the decentral consumer network node 122. Generation and provision of incident data associated with non-validated data point(s) may allow to generate updated digital assets by local data provider component(s) receiving the incident data and to provide the updated digital assets for access. Hence, the use of incident data may ensure 241022

[0327] 79 that non-validated supply chain product data point(s) can be corrected such that the updated digital asset(s) pass(es) the validation. This may result in a higher data quality of the digital product passports generated based on the validated supply chain product data.

[0328] FIG. 13 illustrates a sequence diagram of an example data exchange according to a decentral communication protocol between decentral provider network node(s) connected to local data provider component(s) of a local data provider compute and storage environment and decentral consumer network node(s) connected to local data consumer component(s) of a local consumer compute and storage environment. The decentral communication protocol may include the Dataspace Protocol 2024-1 of the International Data Space Association (IDSA). The decentral communication protocol may include the Contract Negotiation Protocol of the Dataspace Protocol 2024- 1.

[0329] The local data consumer compute and storage environment may be associated with a data consumer. The data consumer may be an entity generating digital product passport(s). The data consumer may be an entity consuming supply chain products to produce one or more product(s) or the product production producing the product(s). The local data provider compute and storage environment may be associated with a data provider. The data provider may be the data owner of the digital asset(s). The data provider may be the supply chain product producer or the supply chain product production. The decentral provider network node 1 18 and the decentral consumer network node 122 may be part of a decentral network, such as decentral network 134 described in the context of FIG. 1.

[0330] With reference to FIG. 5, the local data consumer compute and storage environment and the local data provider environment may act as tenants of the orchestration component 502. One or more of the local data provider component(s) and one or more of the local data consumer component(s) may be connected to the orchestration component. The orchestration component may communicate with the component(s) based on a local communication protocol, as described in the context of FIG. 5. One or more local data provider component(s) may be configured to generate digital assets and to provide the generated digital assets for access by the decentral consumer network node(s), for example as described in the context of FIG. 6 and FIG. 7. The digital assets may be generated in response to a request for generating and providing digital assets received from the orchestration component via the local communication protocol, for example as described in the context of FIG. 5. The digital assets may be generated based on a data pipeline. The data pipeline may be generated or selected in response to the request (see FIG. 5). The generated digital assets may be associated with policy data. The policy data may include a digital representation of contract data. Generation and provisioning of the digital assets may trigger a request for consumption of the generated digital assets. A trigger may be provided via the local communication protocol from the local data provider component(s) to the orchestration component and the orchestration component may generate the request and may provide the request via the local communication protocol to local 241022

[0331] 80 data consumer component(s) (see FIG. 5, FIG. 7). The request may include decentral asset identifier(s) associated with the generated digital asset(s) and an endpoint of the decentral provider network node providing the generated digital assets. The request may further include the digital representation of contract data,

[0332] In response to receiving the request for consumption via the local communication protocol, one or more of the local data consumer component(s) may be configured to provide at least a part of the data included in the received request for display. The local data consumer component(s) may be configured to generate or select a data pipeline based on data included in the received request (see FIG. 5). The local data consumer component(s) may be configured to store data include in the received request or to update existing data based on data included in the received request. The local data consumer component(s) may be configured to trigger gathering of digital asset(s) associated with the received decentral asset identifier(s).

[0333] With reference to FIG. 14A, one or more of the local data consumer component(s) may be configured to generate display data for displaying the requests received via the local communication protocol from the orchestration component. The display data may be provided for display to a display device. The graphical user interface 1402 displayed by the display device may provide an overview of requests and existing data pipelines 1440. The number of data pipelines and requests shown in graphical user interface 1402 may depend on the number of data pipelines created or requests received. Details of the data pipeline or the requests may be accessible via one or more buttons in the user interface. For instance, upon clicking on button 1446, details on the received request may be displayed. With reference to FIG. 14B, the display device may display a graphical user interface 1402 including an area displaying basic details on the selected data pipeline or the received request 1410, such as name of target database, creation date of pipeline, date of last data transfer using the pipeline, name and email address of user having created the pipeline and / or a pipeline description. The graphical user interface 1402 may further include a list of data provider(s) offering digital assets that can be processed using the data pipeline. The list may indicate the number of data provider(s) offering digital assets for accessed that are processed using the data pipeline. The list of data provider(s) may include a provider name and decentral participant identifier associated with the decentral provider network node, a status and a date indicating last update of the status. The list of data provider(s) may further include one or more button(s) triggering instruction(s). The number of button(s) may depend on the status of the respective pipeline. Whether or not instruction(s) can be triggered by the button(s) may depend on the status of the respective pipeline. For instance, button(s) may be deactivated if instruction(s) associated with such button(s) cannot be triggered for the current pipeline status. Button 1414 may trigger gathering of policy data and contract data linked to digital asset(s) associated with decentral asset identifier(s) included in the received request. Button 1418 may trigger generation of message data for providing a message to the respective data provider. Button 1420 may trigger transfer of digital asset(s). 241022

[0334] 81

[0335] Returning to FIG. 13, gathering of the digital assets may be triggered by the one or more local data consumer component(s) by providing the decentral asset identifiers associated with the digital assets to be gathered and endpoints of decentral provider network node(s) providing the digital assets to decentral consumer network node(s) connected to the local data consumer component(s). In addition, a representation for accessing the local data consumer component(s) may be provided to the decentral consumer network node(s). The representation for accessing may include the pipeline identifier. The decentral consumer network node(s) may request a data set including digital representation(s) of digital asset(s) associated with the decentral asset identifier(s) (e.g. a data catalog) at the decentral provider network node(s). The request may include the decentral asset identifier(s) and a decentral participant associated with the decentral consumer network node. The digital representation(s) may include the decentral asset identifier(s) associated with the digital asset(s), policy data associated with the digital asset(s), and an endpoint of the decentral provider network node providing the digital asset upon request.

[0336] The decentral provider network node receiving the request may be configured to generate the catalog based on the decentral asset identifier(s) and the decentral participant identifier. Based on the decentral asset identifier(s) the policy data associated with the decentral asset identifier(s) may be gathered, for example via the contract definition data. The policy data may include access policy data 834 and / or contract policy 836 as described in the context of FIG. 8B. The decentral provider network node may match the decentral participant identifier to processing rule data included in the policy data to determine whether the decentral consumer network node is allowed to access the digital asset(s)). The decentral provider network node may be configured to generate the digital representation(s) of digital asset(s) allowed to be accessed by the decentral consumer network node(s) and to compile such digital representation(s) into the catalog, for example according to a given data space protocol, such as Dataspace Protocol 2024-1 of the International Data Space Association (IDSA). The data space protocol may utilize the Data Catalog Vocabulary (DCAT). DCAT is an RDF vocabulary that enables data providers to describe datasets and data services in a catalog using a standard model and vocabulary that facilitates data transfer within the decentral network 134. The digital representation(s) may include the decentral asset identifier associated with the digital asset and the policy data. The generated catalog may further include an endpoint of the decentral provider network node providing the digital asset upon request to such endpoint. The digital asset(s) may be stored on a dedicated storage associated with the decentral provider network node, for example as described in the context of FIG. 3 and FIG. 6.

[0337] The decentral provider network node may provide the generated catalog to the requesting decentral consumer network node. The decentral consumer network node may provide the received catalog to processing rule validator 1228. The processing rule validator may be configured to parse the catalog to determine the policy data and digital representation(s) of contract data included therein. In another embodiment, the digital representation of the contract data may be provided to the processing rule validator via a request received via the local 241022

[0338] 82 communication protocol from the orchestration component or via a digital representation of the digital twin gathered by decentral consumer network node based on the decentral asset identifier(s).

[0339] The processing rule validator may be configured to gather contract data based on the representation for accessing the contract data included in the digital representation of the contract data. The contract data may be gathered at a communication interface provided by the database storing the contract data.

[0340] The processing rule validator may be configured to validate the policy data and the gathered contract data, for example as described in the context of FIG. 12B. With reference to FIG. 14C, the user interface or part thereof, such as window 1424, may include a list of digital asset(s) associated with the received request. The window 1424 may further include button(s) 1454 to view the policy data (e.g. processing rule(s)) and button(s) 1448 to view the contract data (e.g. terms and cond ition(s)) associated with each digital asset. This may allow a user to validate whether contractual obligation(s) included in the contract data and / or permission(s), obligation(s) and / or prohibition(s) included in the policy data are acceptable or not. Window 1424 may further include button(s) 1450 to trigger verification of the contract data (e.g. button “verify”) by the processing rule validator, for example as described in the context of FIG. 12B and FIG. 15A. The processing rule validator may be configured to provide the verification result for display (see 1452). Window 1424 may further include button(s) 1456 to trigger validation of the policy data and the contract data by the processing rule validator, for example as described in the context of FIG. 12B and FIG. 15A. The processing rule validator may be configured to provide the validation result for display. Window 1424 may further button(s) allowing to accept or decline the policy data and optionally the contract data associated with digital asset(s). Clicking on button “accept” for a given digital asset may trigger generation of offer data for such digital asset as described later on. Clicking on button “decline” for a given digital asset may trigger generation of data indicating rejection for such digital asset as described later on. Window 1424 may further include check boxes to allow selection of multiple digital assets for which an action, such as validation of policy data and optionally contract data, verification of contract data, generation of offer data or generation of data indicating rejection is to be triggered. This way, a user may initiate verification and / or validation of policy data and contract data for a plurality of digital assets offered for consumption, allowing efficient verification and / or validation and efficient gathering of the digital asset(s). This enables efficient gathering of a large amount of digital assets from multiple data providers, ensuring efficient generation of digital product passports using such gathered digital assets. In addition, this increases the quality of the digital product passports, enabling more efficient processing of product(s) based on the data included in the passports.

[0341] Triggering generation of offer data may include providing a request to generate offer data to the decentral consumer network node. The request may be generated by the processing rule validator. The request may include decentral asset identifier(s) for which offer data is to be generated. Based on such request, the decentral consumer network node may be configured to generate the offer data. The offer data may be generated per 241022

[0342] 83 decentral asset identifier. The offer data may be generated according to the ODRL Information Model (see technical report for ODRL Information Model 2.2. at https: / / www.w3.org / TR / 2018 / REC-odrl-model-20180215 / ). The offer data may include the validated policy data. The validated policy data may include a digital representation of the validated contract data.

[0343] The decentral consumer network node may provide the generated offer data to decentral provider network node. The decentral provider node may verify the received offer data by comparing the policy data included in the offer data with the policy data associated with the digital asset. Upon successful verification of the received offer data (e.g. upon determining that the policy data included in the offer data matches at least a part of the policy data associated with the digital asset), decentral provider network node may be configured to generate agreement data indicating an agreement on the policy data associated with the digital asset(s). The agreement data may include an agreement identifier and the decentral asset identifier associated with the digital asset. The agreement data may further include the validated policy data, the decentral participant identifiers associated with the decentral provider network node and the decentral consumer network node and a creation date of the agreement.

[0344] The generated agreement data may be provided to the decentral consumer network node. The consumer network node may verify the agreement data by comparing or matching the decentral asset identifier(s) as well as the offer data identifier(s) and the policy data included in the agreement data to the decentral asset identifier(s), the offer data identifier(s) and the policy data included in the generated offer data. Upon verification of the agreement data (e.g. upon matching of the decentral asset identifiers, offer data identifiers and policy data), the verification data may be provided to the decentral provider network node. The verification data may indicate agreement with the received agreement data. The agreement identifier(s) may be provided by the decentral consumer network node to one or more local data consumer component(s) for storage. This may allow to avoid repeated negotiations for access to a given digital asset upon repeated access to the respective digital asset.

[0345] The decentral consumer network node may be configured to gather the digital asset(s) based on the decentral asset identifier(s) and the agreement identifier at the decentral provider network node. The decentral provider network node may fetch the digital asset(s) based on the received decentral asset identifier(s) from a local database storing the digital assets and provide the digital assets via the decentral communication protocol to the requesting decentral consumer network node. The decentral consumer network node may provide the received digital asset(s) to one or more local data consumer component(s) for processing, for example as described in the context of FIG. 12C.

[0346] FIG. 15A illustrates a flow chart of an example method for gathering digital asset(s) associated with supply chain product(s) via a decentral communication protocol from decentral provider network node(s) connected to local data provider component(s) of a local data provider compute and storage environment storing the digital asset(s). The digital asset(s) may be gathered by decentral consumer network node(s) connected to local data consumer 241022

[0347] 84 component(s) of a local data consumer compute and storage environment. The digital asset(s) may be generated as described in the context of FIG. 6. The digital asset(s) may be generated and provided in response to a request received from the orchestration component via the local communication protocol, for example as described in the context of FIG. 5. The supply chain products may include supply chain products described in the context of FIG: 3. The method illustrated in FIG. 15A may be implemented by the system described in the context of FIG. 12A to FIG. 12C.

[0348] The digital asset(s) may be associated with policy data. The policy data may include processing rule data defining permission(s), obligation(s) and / or prohibition(s) with respect to the processing of the associated digital asset(s) by the one or more local data consumer component(s). An example of policy data associated with the digital asset(s) is illustrated in FIG. 8B. The policy data may be generated as described in the context of FIG. 6 and FIG. 7.

[0349] Policy data including processing rule data and a digital representation of contract data may be provided. Policy data including processing rule data may be provided in combination with the digital representation of contract data. The digital representation of contract data may include a representation for accessing the contract data and a hash value computed from the contract data, for example as described in the context of FIG. 7. The policy data may be provided as described in the context of FIG. 13. The digital representation of contract data may be provided as described in the context of FIG. 13.

[0350] Contract data may be gathered based on the digital representation of the contract data. With reference to FIG. 4, the contract data may include one or more contractual obligation(s) between the data owner of digital asset(s), e.g. the supply chain product producer, supply chain product production, and the data consumer, e.g. the supply chain product consumer, product production, associated with the local data consumer compute and storage environment. The contract data may include or correspond to one or more computer-readable legal document(s). The contract data may include data defining the contractual obligation(s). The obligation(s) may define terms and conditions (TnC) between the data provider and the data consumer. Returning to FIG. 15A, the contract data may be gathered from a database associated with the data provider, for example as described in the context of FIG. 12B.

[0351] The gathered contract data may be verified based on the digital representation of the contract data. Verifying the gathered contract data may include verifying the data integrity of the gathered contract data. With reference to FIG. 12B, verifying the gathered contract data may include computing a hash value of the gathered contract data and comparing the computed hash value to the hash value included in the digital representation of the contract data. The gathered contract data may be verified if the computed hash value matches the hash value included in the digital representation of the contract data. Failure of verification of the contract data may trigger generation of 241022

[0352] 85 display data or message data indicating failure of verification, for example as described in the context of FIG. 12B and FIG. 13.

[0353] If the gathered contract data is not verified, data indicating rejection of the policy data or the contract data may be generated, for example as described in the context of FIG. 13. The data indicating rejection may be provided via the decentral consumer network node to the decentral provider network node. In response to receiving such data, the decentral provider network node may terminate the peer-to-peer connection and may not provide the requested digital asset(s).

[0354] If the gathered contract data is verified, the policy data and the contract data may be validated. A user may validate the policy data and the contract data may provide a user input indicating validation or rejection of the policy data and / or the contract data, for example as described in the context of FIG. 12B and FIG. 13. The policy data and / or the contract data may be validated using at least one rule-based engine and / or at least one trained data-driven model, for example as described in the context of FIG. 12B.

[0355] If the policy data and the contract data is validated, the digital asset(s) may be gathered via the decentral communication protocol, for example as described in the context of FIG. 13. The gathered digital assets may be processed, for example as described in the context of FIG. 12C and the processed digital assets may be provided for generating digital product passports associated with products produced or producible from the supply chain product(s).

[0356] By verifying the data integrity of the contract data prior to gathering the digital asset(s) associated with such contract data, trust and acceptance of data consumer(s) with respect to the use of additional processing rule(s) included in the contract data besides the processing rules included in the policy data may be improved. This way, conversion of complex contractual obligation(s) contained in the contract data into policy data may be avoided while still allowing to flexibly adjust the policy data with respect to multiple decentral consumer network node(s) and / or different confidentiality level(s) associated with the data included in the digital assets. In addition, the verification avoids interruption(s) of the processing of the gathered digital assets by the local data consumer component(s) due to modification(s) of the contract data by the local data provider component(s) after acceptance of the contract data by the data consumer. This way, a more reliable and efficient generation of digital product passport(s) based on processed digital assets is ensured, allowing a higher data quality of the data included in the digital product passport and hence a more efficient processing, such as recycling and / or re-use, of the product based on the data included in the digital product passports.

[0357] By using a rule-based engine and / or a trained data-driven model to validate the policy data and / or the contract data, the acceptability of permission(s), obligation(s) and / or prohibition(s) included in policy data as well as contractual obligation(s) included in contract data may be reliably validated prior to initiating transfer of digital 241022

[0358] 86 assets associated with such policy data and contract data. This way, it can be ensured that digital assets are only gathered from decentral provider network nodes according to the decentral communication protocol if associated policy data and contract data allows to process the digital assets according to instructions executed by the local data consumer component(s), avoiding unnecessary data transactions within the decentral network and reducing the environmental impact associated with the exchange of digital assets within the decentral network.

[0359] FIG. 15B illustrates an embodiment of the method of FIG. 15A. The method illustrated in FIG. 15B may be implemented by the system illustrated in FIG. 12C. The method illustrated in FIG. 15B may be used to process, e.g. validated, digital assets gathered as described in the context of FIG. 15A.

[0360] The method illustrated in FIG. 15B may the steps described in the context of FIG. 15A. The gathered digital assets may be validated using a rule-based engine including one or more rule(s) related to a data model associated with the product or a product type the product is associated with. The data model may be used to generate digital product passports associated with the product. The rule-based engine may be a rule-based engine as described in the context of FIG. 12C.

[0361] Validation of the gathered digital assets may include determining applicable rule(s) based on supply chain product identifier(s) and generating executable logic from the applicable rule(s), for example as described in the context of FIG. 12C. The gathered digital assets may be validated by executing the generated executable logic. Execution of the logic may result in matching supply chain data included in the gathered digital assets to data point(s) and / or combination(s) of data point(s) included in the executable logic, evaluating the data point(s) or combination(s) of data point(s) with matched supply chain product data and generating validation result data based on the evaluation results. The validation result data may include a binary classifier discriminating validated and nonvalidated supply chain product data. Digital assets may be considered validated if one or more rule(s) applied by the rule based engine are fulfilled.

[0362] A validation result may be generated by the rule engine. The validation result data may include a classifier and associated validated or non-validated supply chain product data point(s).

[0363] It may be verified whether the gathered digital assets could be validated. If at least a part of the gathered digital assets could not be validated, such non-validated supply chain product data may be provided for storage and message data may be generated and provided, or example as described in the context of FIG. 12C. If the gathered digital assets could be validated, the validated supply chain product data may be provided for generating digital product passport(s) associated with product(s) produced or producible using the supply chain product(s). Providing the validated supply chain product data may include providing the validated supply chain product data to storage location(s), for example as described in the context of FIG. 12C. The storage location(s) may be accessible by a system configured to generate the digital product passports. Providing the validated supply chain 241022

[0364] 87 product data to the storage location(s) may include linking at least a part of the validated supply chain product data to at least one of the product identifiers prior to providing the validated supply chain product data to the storage location(s). This way, validated data may be gathered based on at least one of the product identifiers, for example upon generating and / or updating the digital product passport.

[0365] By validating the digital assets using one or more rule(s) related to a data model associated with the product or product type, it can be ensured that the data points defined according to the data model are included in the validated supply chain product data. This avoids incomplete, false and / or missing data during generation of the digital product passports using the validated supply chain product data. This way, a higher data quality of the digital product passports can be ensured, allowing more efficient processing of the product based on the data included in the digital product passports.

[0366] FIG. 15C illustrates a flow chart of an example method for providing digital assets associated with supply chain product(s) via a decentral communication protocol to decentral consumer network node(s) connected to local data consumer component(s) of a local data consumer compute and storage environment for generation of digital product passport(s) associated with one or more product(s) produced or producible using the supply chain product(s). The digital assets may be generated as described in the context of FIG. 6. The supply chain products and the product may include supply chain products and products described in the context of FIG. 3.

[0367] The digital assets may be associated with policy data including processing rule data associated with a processing of the digital assets by the local data consumer component(s). The policy data may be generated as described in the context of FIG. 7. The digital assets may further be associated with contract data including further processing rule data. The contract data may b...

Claims

24102290CLAIMS1 . A method for controlling access to a digital asset associated with a supply chain product by one or more decentral consumer network node(s) connected to one or more local data consumer component(s) of a local data consumer compute and storage environment via a decentral communication protocol, wherein the access is controlled by a data owner of the digital asset, the method comprising: providing the digital asset including supply chain product data and decentral asset identifier(s) associated with the supply chain product data, providing contract data including processing rule data associated with the processing of the digital asset by one or more of the local data consumer component(s), generating a digital representation of the contract data by computing a hash value of at least a part of the contract data and generating a representation for accessing the contract data, wherein the generated digital representation of the contract data includes the generated representation for accessing the contract data and the computed hash value, linking the generated digital representation of the contract data to the digital asset, providing the digital representation of the contract data linked to the digital asset for controlling access to the digital asset at least in part based on the contract data associated with the digital asset, wherein the digital representation of the contract data is provided for access by the decentral consumer network node(s) via to the decentral communication protocol or provided to one or more of the local data consumer component(s) via at least one orchestration component according to a local communication protocol.

2. The method of claim 1 , wherein providing the digital asset includes: providing at least one supply chain product identifier associated with the supply chain product, gathering - based on the provided supply chain product identifier - supply chain product data from one or more databases, providing decentral asset identifier(s) associated with the supply chain product data, generating the digital asset by transforming the gathered supply chain product data and the provided decentral asset identifier(s) using a rule-based engine including one or more rule(s) associated with or derived from a data model of a product produced or producible using the supply chain product.

3. The method of claim 2, wherein the rule-based engine operates on individual data points present within at least part of the gathered supply chain product data, multiple data points present within at least part of the gathered supply chain product data or the whole gathered supply chain product data.241022914. The method of claim 2 or 3, wherein the one or more rule(s) are generated from a rule template including unstructured data associated with instructions related to transformation operation(s).

5. The method of any one of claims 2 to 4, wherein the one or more rule(s) define aggregation rule(s) for aggregating supply chain product data gathered from multiple local source databases into a given data structure, define filters to filter gathered supply chain product data, define attribute construction(s) to create or add new attributes to the gathered supply chain product data and / or include a trigger condition and a corresponding group of one more actions.

6. The method of claim 2 to claim 5, wherein the rule(s) are generated based on a data structure for collecting property / ies of the supply chain product, wherein the data structure is defined by one or more of the local data consumer component(s) and wherein the data structure is provided via an orchestration component based on a local communication protocol to one or more local data provider component(s) of a local data provider compute and storage environment configured to generate the digital asset.

7. The method of any one of the preceding claims, wherein the supply chain product data includes supply chain product property data point(s), supply chain product identifier data point(s), supply chain product name data point(s), supply chain product producer data point(s), supply chain product declaration data point(s), supply chain product safety data point(s), supply chain product emission data point(s), supply chain product recyclate content data point(s), supply chain product biobased content data point(s), supply chain product biodegradability data point(s), supply chain product production data point(s), supply chain product certificate of analysis data point(s), supply chain product certificate data point(s), supply chain product life cycle data point(s), supply chain product storage instruction data point(s), supply chain product assembly instruction data point(s), supply chain product processing condition data point(s), any combinations thereof or any single data point thereof.

8. The method of any one of the preceding claims, wherein the contract data includes unstructured data associated with contractual obligation(s) between the data owner and a data consumer associated with the local data consumer compute and storage environment.

9. The method of any one of the preceding claims, wherein the contract data is accessible for one or more of the local data consumer component(s) based on the representation for accessing the contract data included in the digital representation of the contract data, in particular wherein the contract data is stored in a local database of a local data provider compute and storage environment associated with the data owner.2410229210. The method of any one of the preceding claims, wherein the generated digital representation of the contract data includes the computed hash value appended to the generated representation for accessing the contract data.11 . The method of any one of the preceding claims, wherein linking the generated digital representation of the contract data to the digital asset includes generating policy data including one or more of the decentral asset identifier(s) and processing rule data associated with the processing of the digital asset by one or more of the local data consumer component(s), in particular wherein the processing rule data includes the generated digital representation of the contract data.

12. A method for monitoring and / or controlling generation of a digital asset to be provided for access via a decentral communication protocol by one or more decentral consumer network node(s) connected to one or more of the local data consumer component(s) of a local data consumer compute and storage environment associated with a data consumer, wherein the digital asset is associated with a supply chain product produced or producible by a supply chain product production associated with a supply chain product producer, the method comprising: providing data associated with a product produced or producible by a production at least in part from the supply chain product, providing - based on the provided data associated with a product - contract data including rule(s) for generating the digital asset by one or more local data provider component(s) of a local data provider compute and storage environment associated with the supply chain product producer, generating a digital representation of the contract data by computing a hash value of at least a part of the contract data and generating a representation for accessing the contract data, wherein the generated digital representation of the contract data includes the generated representation for accessing the contract data and the computed hash value, generating - based on the digital representation of the contract data - a trigger for generation of the digital asset and for provisioning of the generated digital asset for access via the decentral communication protocol by the decentral consumer network node(s), providing the generated trigger via a local communication protocol to at least one orchestration component for triggering generation of the digital asset according to the rule(s) and for provisioning of the generated digital asset for access via the decentral communication protocol by the decentral consumer network node(s).

13. A method for gathering a digital asset associated with a supply chain product via a decentral communication protocol from decentral provider network node(s) connected to local data provider component(s) of a local data provider compute and storage environment storing the digital asset, wherein24102293 the digital asset is gathered via the decentral communication protocol by one or more decentral consumer network node(s) connected to one or more local data consumer component(s) of a local data consumer compute and storage environment, the method comprising: providing policy data associated with the digital asset and a digital representation of contract data associated with the digital asset, wherein the policy data includes decentral asset identifier(s) associated with the digital asset and processing rule data associated with the processing of the digital asset by one or more of the local data consumer component(s), wherein the processing rule data includes a digital representation of contract data or wherein the digital representation of contract data is provided in combination with the policy data, and wherein the digital representation of contract data includes a representation for accessing the contract data and a hash value computed from at least a part of the contract data, gathering the contract data based on the digital representation of contract data, verifying the contract data based on the digital representation of contract data, based on verified contract data, validating the policy data and optionally the contract data, based on the validated policy data and optionally the validated contract data, gathering the digital asset via the decentral communication protocol from the decentral provider network node(s).

14. The method of claim 13, wherein the contract data is gathered based on the representation for accessing the contract data from a local data storage, optionally wherein the local data storage is included in the local data provider compute and storage environment.

15. The method of claim 13 or 24, wherein the policy data and optionally the contract data are validated using a rule-based engine including processing rule(s) and / or using at least one data-driven model trained on historical data sets including policy data sets and associated acceptability scores and / or including contract data sets and associated acceptability scores.

Images