Handling of data usage rules in decentral systems

Abstract

The present disclosure relates to the field of data validation, in particular to the validation of access data associated with the usage of material data associated with a material by a data consumer. The disclosure relates to a method, an apparatus and a computer element for validating access data including usage rule data associated with the usage of the material data by a data consumer. The disclosure further relates to a method, an apparatus and a computer element for generating agreement data associated with the material data, a material associated with agreement data and a method, an apparatus and a computer element for providing material data associated with material(s) via a decentral network to a data consumer. The disclosure further relates to the use of the accessed material data in the production of a product using material(s) associated with the accessed material data.

Description

[0001] HANDLING OF DATA USAGE RULES IN DECENTRAL SYSTEMS

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to the field of data validation, in particular to the validation of access data associated with the usage of material data associated with a material by a data consumer. The disclosure relates to a method, an apparatus and a computer element for validating access data including usage rule data associated with the usage of the material data by a data consumer. The disclosure further relates to a method, an apparatus and a computer element for generating agreement data associated with the material data, an input material associated with the agreement data and a method, an apparatus and a computer element for accessing the material data associated with the material via a decentral network to a data consumer. The disclosure further relates to the use of the accessed material data in the production of a product using material(s) associated with the accessed material data.

[0004] TECHNICAL BACKGROUND

[0005] 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 usage of such material data the data consumers can be linked to the material data. A data-driven validation of such access policies at the data consumer side can aid in handling access policies for a large amount of material data to be exchanged, ensuring reliable gathering of material data, such as input material data related to input materials used to produce one or more product(s) by a production or product data associated with product(s) produced or producible by one or more of the input material(s).

[0006] SUMMARY OF THE INVENTION

[0007] Disclosed is in one aspect a method, in particular a computer-implemented method, for validating access data associated with material data, wherein the access data includes usage rule data associated with the usage of the material data by a data consumer and wherein the material data is associated with a material produced or producible by a production, the method comprising:

[0008] • providing one or more decentral material identifier(s) associated with the material,

[0009] • providing via a decentral network the access data based on the decentral material identifier(s), in particular wherein the access data is provided by a decentral data providing node associated with a data owner of the material data associated with the material in response to a request for accessing the material data, wherein the request includes the decentral material identifier(s) associated with the material,

[0010] • validating at least a part of the access data using a rule-based engine including usage rule(s) or using a data-driven model trained on historical data sets including access data sets and associated acceptability scores, 231357

[0011] 2

[0012] • based on the validated access data, generating and providing data indicating an acceptance of the access data via the decentral network to a data providing node associated with the owner of the material data.

[0013] Disclosed is in a further aspect an apparatus for validating access data associated with material data, wherein the access data includes usage rule data associated with the usage of the material data by a data consumer and wherein the material data is associated with a material produced or producible by a production, the apparatus comprising:

[0014] • a data providing interface configured to provide one or more decentral material identifier(s) associated with the material,

[0015] • a decentral network interface configured to provide via a decentral network the access data based on the decentral material identifier(s), in particular wherein the access data is provided by a decentral data providing node associated with a data owner of the material data associated with the material in response to a request for accessing the material data, wherein the request includes the decentral material identifier(s) associated with the material,

[0016] • a validation engine configured to validate at least a part of the access data using a rule-based engine including usage rule(s) or using a data-driven model trained on historical data sets including access data sets and associated acceptability scores,

[0017] • a data providing interface configured to generate and provide - based on the validated access data - data indicating an acceptance of the access data via the decentral network to a data providing node associated with the owner of the material data.

[0018] Disclosed is in yet a further aspect a method, in particular a computer-implemented method, for validating access data associated with the processing of material data by a data consumer, wherein the access data includes usage rule data associated with processing and wherein the material data is related to a material producible by a production, the method comprising:

[0019] • providing via a decentral network a data set including at least one digital representation of a data processing system configured to process the material data, wherein the digital representation includes the access data and a representation for providing the material data to the data processing system,

[0020] • validating at least a part of the access data using a rule-based engine including usage rule(s) or using a data-driven model trained on historical data sets including access data sets and associated acceptability scores,

[0021] • based on the validated access data, generating and providing data indicating an acceptance of the access data to a decentral network node associated with the data consumer.

[0022] Disclosed is in yet a further aspect an apparatus for validating access data associated with the processing of material data by a data consumer, wherein the access data includes usage rule data associated with processing and wherein the material data is related to a material producible by a production, the apparatus comprising:

[0023] • a decentral network interface configured to provide a data set including at least one digital representation of a data processing system configured to process the material data, wherein the digital representation includes the access data and a representation for providing the material data to the data processing system, 231357

[0024] 3

[0025] • a validation engine configured to validate at least a part of the access data using a rule-based engine including usage rule(s) or using a data-driven model trained on historical data sets including access data sets and associated acceptability scores,

[0026] • a decentral network interface configured to generate and provide - based on the validated access data - data indicating an acceptance of the access data to a decentral network node associated with the data consumer.

[0027] Disclosed is in yet a further aspect a method, in particular a computer-implemented method, for generating agreement data associated with material data, wherein the agreement data indicates agreement with access data including usage rule data associated with the usage of the material data by a data consumer, wherein the material data is associated with a material produced or producible by a production associated with the data consumer , the method comprising:

[0028] • receiving via a decentral network data indicating acceptance of the access data, wherein the data indicating the acceptance of the access data is generated by the methods or by the apparatuses disclosed herein,

[0029] • generating the agreement data based on the received data indicating the acceptance of the access data,

[0030] • providing the generated agreement data via the decentral network to the data consumer.

[0031] Disclosed is in yet a further aspect an apparatus for generating agreement data associated with material data, wherein the agreement data indicates agreement with access data including usage rule data associated with the usage of the material data by a data consumer and being associated with the input material data, wherein the material data is associated with a material produced or producible by a production associated with the data consumer, the apparatus comprising:

[0032] • a decentral data consuming interface configured to receive data indicating acceptance of the access via a decentral network, wherein the data indicating the acceptance of the access data is generated by the methods or by the apparatuses disclosed herein,

[0033] • an agreement data generator configured to generate the agreement data based on the received data indicating the acceptance of the access data,

[0034] • a decentral data providing interface configured to provide the generated agreement data via the decentral network to the data consumer.

[0035] Disclosed is in yet a further aspect a material produced or producible by a production and being associated with agreement data as generated according to the methods or by the apparatuses disclosed herein.

[0036] Disclosed is in yet a further aspect a method, in particular a computer-implemented method, for providing material data associated with material(s) produced by a production via a decentral network to a data consumer wherein the material data is associated with access data including usage rule data associated with the usage of the material data by the data consumer, the method comprising:

[0037] • receiving via the decentral network a request to access the material data by a data consumer, wherein the request includes decentral material identifier(s) associated with the material and agreement data indicating an agreement between the data owner and the data consumer on the usage rule data, wherein the agreement data is generated by the methods or by the apparatuses disclosed herein, 231357

[0038] 4

[0039] • authorizing the request to access the material data based on the agreement data and the decentral material identifier(s),

[0040] • based on the authorization, providing the material data via the decentral network to the data consumer.

[0041] Disclosed is in yet a further aspect an apparatus for providing material data associated with material(s) produced by a production via a decentral network to a data consumer, wherein the material data is associated with access data including usage rule data associated with the usage of the material data by the data consumer, the apparatus comprising:

[0042] • a decentral data providing interface configured to receiving via the decentral network a request to access the material data by a data consumer, wherein the request includes decentral material identifier(s) associated with the material and agreement data indicating an agreement between the data owner and the data consumer on the usage rule data, wherein the agreement data is generated by the methods or by the apparatuses disclosed herein,

[0043] • an authorization unit configured to authorize the request to access the material data based on the agreement data and the decentral material identifier(s),

[0044] • a decentral data providing interface configured to provide the material data via the decentral network to the data consumer based on the authorization.

[0045] Disclosed is in yet a further aspect a method, in particular a computer-implemented method, for providing material data related to material(s) producible by a production via a decentral network to a data consumer for processing the material data, wherein the processing of the material data by the data consumer is associated with usage rule data defining the processing of the material data by the data consumer, the method comprising:

[0046] • receiving via the decentral network material data including decentral material identifier(s) and agreement data indicating an agreement between the data owner and the data consumer on the usage rule data, wherein the agreement data is generated by the methods or by the apparatuses disclosed herein

[0047] • authorizing the processing of the material data based on the agreement data,

[0048] • based on the authorization, processing the material data.

[0049] Disclosed is in yet a further aspect an apparatus for providing material data related to material(s) producible by a production via a decentral network to a data consumer for processing the material data, wherein the processing of the material data by the data consumer is associated with usage rule data defining the processing of the material data by the data consumer, the apparatus comprising:

[0050] • a decentral network interface configured to receive material data including decentral material identifier(s) and agreement data indicating an agreement between the data owner and the data consumer on the usage rule data, wherein the agreement data is generated by the methods or by the apparatuses disclosed herein

[0051] • an authorization unit configured to authorize the processing of the material data based on the agreement data,

[0052] • a data processing system configured to process the material data based on the authorization.

[0053] Disclosed is in yet a further aspect a use of material data as provided according to the methods disclosed herein or by the apparatuses disclosed herein in the production of a product using material(s) associated with the provided material data. 231357

[0054] 5 Disclosed is in yet a further aspect a computer element with instructions, which when executed on one or more computing node(s) is configured to carry out the steps of the method(s) of the present disclosure or configured to be carried out by the apparatus(es) of the present disclosure.

[0055] Any disclosure, embodiments and examples described herein relate to the methods, the apparatuses, the material, the uses, 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.

[0056] Embodiments

[0057] 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.

[0058] Material data associated with materials may be exchanged between the material producer and the material consumer via a decentral network. The decentral network allows exchange of such material data in a standardized and reliable manner via a peer-to-peer connection between a provider node operated by the material producer and a consumer node operated by the material consumer. The material data may be used by the material consumer to control and / or monitor the production of product(s) from the material(s) based on such gathered material data and / or to perform a data-driven control of the quality of the material(s) to ensure that the quality of the material(s) conforms to given quality standards or specifications. The material data may be linked to access policies defining access to such data and usage of such data by data consumers to ensure that such data is only accessed by authorized participants of the decentral network. Such access policies need to be validated and accepted by the data consumer, such as the material consumer, prior to exchange of the respective material data linked to such access policy. Since acceptance of the access policies results in legally binding the data consumer to usage rules included in the access policies, such access policies must be checked and agreement to such access policies must be approved, for example by authorized representatives of the data consumer. However, applications gathering material data via the decentral network are not necessarily used by such authorized representatives. In addition, manual checking of each access policy by authorized representatives for a huge amount of t material data for which access is requested by the data consumer via the decentral network may result in production delays if material data cannot be gathered due to lack or delay of acceptance of the associated access policies. To avoid or mitigate a negative impact on the production of products using the materials, acceptance of access policies associated with material data in an efficient and reliable yet legally sound manner is crucial.

[0059] By using a rule-based engine or a trained data-driven model, the acceptability of access policies associated with material data linked to material(s) produced or producible by the production may be efficiently and reliably validated even for large scale productions producing one or more product(s) from such material(s) and consuming large amounts of material data and hence also requiring validation of large amounts of access policies. The data-driven validation allows to determine whether usage rule(s) included in the access policies associated with the material data are acceptable in a reliable yet efficient manner, hence avoiding acceptance of unacceptable usage rule(s) or inefficient manual acceptance of each access policy associated with requested material. This way, a delay in accessing the material data and hence a negative impact on the 231357

[0060] 6 production of the product(s) using the material(s) due to the delayed access to the material data can be avoided.

[0061] The rule-based engine may operate on usage-rule level and may be configured to compare usage rule(s) included in received access policies with acceptable usage rule(s). Acceptable usage rule(s) may be determined based on existing agreements with the material producer and / or may be predefined usage rule(s), e.g. usage rule(s) defined by the data consumer to be acceptable. By using a trained data-driven model, previously unknown usage rule(s) included in received access policies may be reliably validated, reducing the amount of access policies that need to be manually checked and approved or declined. This way, the negative impact of a delay of accessing material data due to manual checking of usage rule(s) on the production of the product can be further reduced.

[0062] Data-driven validation of usage rule(s) associated with material data allows to reliably and efficiently determine whether said usage rule(s) are acceptable or not, hence allowing to gather or receive material data from various different material data owners via the decentral network in an automated matter. This way, inefficient checking of each usage rule associated with the material data as well as acceptance of usage rule(s) by unauthorized persons may be circumvented, allowing to avoid a negative influence on the production of product(s) using such materials due to delayed availability of such material data for controlling and / or monitoring the production of the product. Data-driven validation of usage rule(s) associated with material data allows more efficient processing of the materials based on the material data by enabling more efficient access to such material data.

[0063] 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.”

[0064] 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.

[0065] The material may include any material produced or producible by the production. Produced material(s) may include physical entity / ies of material(s) having been produced by the production. Producible material(s) may not yet have been produced by the production but may be producible by one or more production process(es) performed within the production. Producible 231357

[0066] 7 material(s) may include material (s) planned to be produced, for example based on demand data received from downstream participant(s) (e.g. material consumer(s)). Producible material (s) may include material (s) which can be produced by one or more process step(s) performed within the production.

[0067] The material may be produced or producible via one or more process steps. The process steps may involve chemical reactions and / or physical processes and / or assembly processes. The material may be used in one or more of such production step(s). The material may comprise or be any material produced or producible by the material production and provided at any exit point of the material production. The material may be used as input material by material consumers to produce one or more product(s). The product(s) may be produced by one or more material consumers, such as downstream participant(s), which may use the material(s) produced by one or more upstream participants as input material(s). The material may comprise any indiscrete material, e.g., may be a continuous volume of solid or liquid material. The material may be a chemical intermediate product or a chemical product. The material may be any discrete material, e.g. may be a component or a part or a component assembly or an end product or an end-of-life product. The material may be a virgin material, e.g. a material that has not undergone a previous production-and-use cycle, in particular, has not been processed and / or used. The material may be a recycled material having undergone at least one recycling step.

[0068] The material may be used as feedstock to produce the one or more product(s). The product(s) may be produced via one or more intermediate product(s). Hence, the material may be directly or indirectly used to produce the one or more product(s).The product may be a component, a component assembly, an end-product or a recycled material. The product may be a chemical product or an intermediate chemical product.

[0069] The production may be any production producing products. The production may comprise one or more production chain(s). A production chain may comprise one or more production step(s). A production step may be performed by a machine or apparatus or a collection of machines or apparatuses. The production may be any facility or plant performing at least one production, reuse, repair, refurbish, remanufacture, recycle or recover operation. The material may be produced or producible by any of the production chain(s). The material may be produced or producible by any of the production step(s).

[0070] The production may be a chemical production. In this case, the material may be a chemical material. Likewise, the product produced from the material by a chemical production may be a chemical product. Chemical materials may include or be any material produced by the chemical production using at least one input material. The chemical material may be produced from input materials by the chemical production. The chemical material may be produced from the input material(s) via one or more chemical and / or physical processes. Hence, chemical intermediate products produced from input materials may be used to produce the chemical material(s)). Chemical processes may include chemical reactions. Chemical reactions may include any chemical reaction commonly known in the state of the art in which the reactants are converted to one or more different chemical products. Chemical reactions may involve the use of catalysts, enzymes, bacteria, etc. to achieve the chemical reaction between the reactants. Physical processes may include mixing, separation and / or extrusion. The input material may be selected from petrochemical feedstocks, such as naphtha crude oil, and natural gas, or intermediates from such feedstocks that in turn require a certain amount of naphtha, crude oil, and natural gas. The input material may be selected from natural feedstocks, such as vegetable oils, biologicals like enzymes, and / or naturally occurring inorganic or organic chemical materials, or intermediates from such feedstocks that in turn require a certain amount of vegetable oils, 231357

[0071] 8 biologicals and / or naturally occurring inorganic or organic chemical materials.

[0072] The chemical production may be a chemical production network. Chemical production networks may include multiple types of production processes for producing different chemical materials from input materials. The chemical production network may include a complex production network producing multiple chemical materials in multiple production or value chains. A production or value chain may include one or more process(es) configured to produce one chemical material or chemical material class from one or more input material(s). The chemical production network may include connected, interconnected and / or non-connected production chains. The production chains included in the chemical production network may be defined by the physical system boundary of the chemical production network. The system boundary may be defined by location or control over production processes. The system boundary may be defined by the site of the chemical production network. The system boundary may be defined by production processes controlled by one entity or multiple entities jointly. The system boundary may be defined by the value chain with staggered production processes to the chemical material, which may be controlled by multiple entities jointly or separately. The chemical production network may include a waste collection and sorting step, a recycling step such as pyrolysis, a cracking step such as steam cracking, a production step to produce chemical materials or intermediates from provided input material(s), a separation step to separate intermediates of one process step and further processing steps to convert such outputs to chemical material(s) leaving the system boundary of the chemical production network. The chemical production network may produce from input materials multiple intermediates and from intermediates one or more chemical material(s). Input material may enter the chemical production network at entry points. Chemical materials may leave the production network at exit points (or feed-out points).

[0073] The chemical production network may comprise one or more entry points at which input materials are provided to the chemical production network. Input material may include raw materials, or chemical intermediate products. Input material may be provided to a plant performing the first production step of the production chain associated with the chemical material.

[0074] The material data may be part of a digital twin of the material. The digital twin may be a digital representation of a physical entity of the material with a defined semantic description of said physical entity of the material. The digital twin of the physical entity of the material is hence a digital version of said physical entity. Once created, the digital twin may be used to represent the physical entity of the material in a digital representation of a real-world system. The digital twin may be uniquely linked to the physical material via at least the decentral material identifier. The digital twin may be created such that it is identical in form and behavior of the corresponding material. Additionally, the digital twin may mirror the properties of the material during its lifetime and / or events occurring with respect to the material during its lifetime. For example, sensors may capture real-time (or near real-time) data, such as transport data or use data, and / or event-driven data, such as data captured in response to the occurrence of a predetermined event, such as an accident, of the physical material to relay it back to its remote digital twin. The digital twin may then be updated to maintain its correspondence to the physical entity of the material. Hence, the digital twin may at any time represent the current state of the physical entity of the material. The digital twin may contain the decentral material identifier and the material data. The digital twin may further contain a material identifier. The digital twin may contain one or more data sets (e.g. digital twin data set(s)). A data set(s) may hence represent a part of the digital twin. The decentral material identifier may comprise any unique identifier uniquely associated with the material data and optionally the data owner of the material data. The decentral material identifier may connect the physical entity of the material to the material data. The decentral material identifier may include one or more Universally Unique Identifier(s) (UUID(s)) and / or one or more Decentralized Identifier(s) (DID(s)). The one or more DID(s) and / or UUID(s) may further be associated with the material. The decentral material identifier may further include or be associated with an material identifier associated with the material. The decentral material identifier may be issued by a central or decentral identity issuer. The decentral material identifier may be generated by the data owner or on behalf of the data owner of the material data. The decentral material identifier may include authentication information. Via the decentral material identifier and its unique association with the material data associated with the material and optionally the data owner of the material data, access to the material data may be controlled by the data owner of the material data. The data owner of the material data may be the material producer. This contrasts with central authority schemes, where identifiers are provided by such central authority and access to material data is controlled by such central authority. Decentral in this context refers to the usage of the decentral material identifier in implementations as controlled by the data owner of the material data. The decentral material identifier may be a digital or virtual identifier, e.g. may not correspond to physical identifier(s) physically attached to the material.

[0075] The decentral material identifier may include or be associated with one or more identifier(s) used in the decentral network and allowing for exchange of material data via the decentral network. For instance, the decentral material identifier may include or be associated with identifier(s) of data sets included in the material data. Data exchange may include discovery of the decentral material identifier and optionally identifier(s) included in or be associated with said decentral material identifier for participant nodes of the decentral network, authentication of participant nodes of the decentral network and / or authorization of data transfers via a peer-to-peer communication between participant nodes of the decentral network.

[0076] The decentral material identifier may be associated with one or more decentral identifier(s) associated with input material(s) used to produce the material. This allows to determine the input material(s) used to produce the material based on the decentral material identifier. The decentral material identifier may be associated with intermediate chemical products, chemical products, components, component assemblies, end products, end-of-life products and / or recycled materials produced using the material. This allows to track the material and its use within the product ecosystem. The decentral material identifier may or may be assigned to a physical identifier connected to the material. The physical identifier may be any identifier for the produced material, such as a batch number or a part number. The physical identifier may comprise a passive or active element, e.g. bar code, QR-code, RFID-tag, but is not limited thereto. The physical identifier may include markers embedded in the material or similar physical arrangement that allows to digitally identify the material.

[0077] The material data may include at least one measured physical and / or chemical property of the material and / or at least one physical and / or chemical property determined from collected data associated with a production and / or a use of the material. The chemical property may be a property of the material that becomes evident during, or after, a chemical reaction. Hence, the chemical property may be any quality that can be established only by changing the chemical identity of the material. 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, material composition, recyclate content of the material, bio-based content of the material, renewable content of the material and / or pH value. 231357

[0078] 10

[0079] Property may be any property that is measurable. Hence, the value of a physical property describes a state of the material. 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.

[0080] The measured at least one physical and / or chemical property may be obtained by sensors configured to measure the physical and / or chemical property. The sensor may be included in a measuring device. The sensor may correspond to the measuring device. For example, the physical and / or chemical property may include a property provided by sensors of a mobile device such as a camera, or measurement devices configured to measure at least one physical and / or chemical property.

[0081] Data associated with the production of the material may be collected before, during and / or after production of the material. The collected data may be used to determine at least one physical and / or chemical property of the produced material. For instance, emission data of the material may be determined based on data collected during production of the material. Data associated with the production of the material may include production data from the production of the material. Data associated with the production of the material may include monitoring and / or control data associated with the production of the material. Data associated with the use of the material may be collected via at least one identifier associated with the material. The data may be collected during and / or after use of the material. Collected data may include at least one measured physical and / or chemical property of the used material. The measured physical and / or chemical property may include the chemical and / or physical properties described previously. The data may be collected with a suitable sensor configured to measure the chemical and / or physical property. The sensor data may be interrelated with the identifier associated with the material. The chemical and / or physical property determined from the sensor data may be interrelated with the identifier associated with the material. The identifier may be the material identifier. The identifier may be the decentral material identifier. The decentral material identifier may be linked to other decentral identifier(s) according to a physical relation of the material entity with other physical entities e.g. those produced using the material or those produced from the material. The linking of the decentral material identifier with other decentral identifier(s) allows to determine the decentral participant node(s) storing the collected data associated with the use of the material or the determined physical and / or chemical property. The collected data and / or the determined chemical and / or physical property may be provided by said decentral participant node(s) and may be used to generate or update material data. For instance, a new data set may be generated by applying a data model associated with the use of the material to the collected data and / or the determined property and said new data set may be used to update existing material data.

[0082] The material data may further include data related to the use of the material, data related to the production of the material, one or more material identifiers, the material name, the composition of the material, emission data of the material, recyclate content data of the material, bio-based content data of the material, renewable content data of the material, biodegradability data associated with the biodegradability of the material, material declaration data, material safety data, certificate of 231357

[0083] 11 analysis data associated with the material, certificate data associated with the material, or a combination thereof.

[0084] The material data may be stored in a database associated with the data owner of the material for access by the data consumer. Access to the database may be controlled by the data owner of the material data. Access to the database and hence the material data stored therein may be controlled by the data owner via the decentral data providing node associated with the database. Access to the database and hence the material data stored therein may be controlled by the data owner via the decentral material identifier. The data owner may be the material producer.

[0085] The decentral material identifier may be linked to a digital representation of the material data. The digital representation may include a representation for accessing the material data or parts thereof. The representations may include a locator pointing to the decentral data providing node associated with the database storing the respective material data or the part thereof. The representation may be used by decentral data consuming node(s) to request access to the material data associated with such digital representation.

[0086] The material data may be generated by a decentral participant node. The decentral participant node may be in communication with the decentral data providing node providing the material data. The decentral participant node may be associated with the decentral data providing node providing the material data. The material data may be generated by the data owner of the material data. The data owner of the material data may be the production producing the material. The data owner of the material data may be a legal entity operating the production producing the material. The data owner of the material data may be a natural person operating the production producing the material. The material data may be generated on behalf of the data owner of the material data. For instance, the material data may be generated by a third party based on a service provided by the third party to the data owner.

[0087] The data provider and the data consumer may be part of a product ecosystem. The data provider may be the material producer. The data provider may be the product producer producing product(s) using the material as input material. The data consumer may be the material consumer consuming the material as input material to produce one or more product(s). The data consumer may be the material producer producing the material. The product ecosystem may include different stages including manufacturing, use and re-use. In these stages one or more ecosystem participant(s) may contribute to the manufacture, use or re-use of a product. For example, the manufacturing stage may include raw material manufacturers, intermediate material manufactures and / or end-product manufacturers. Further for example, the use stage may include product user, product maintainers and / or product distributors. Further for example, the re-use stage may include collectors, sorters, dismantlers, recyclers, restorers and / or re-furbishers.

[0088] The participants of the product ecosystem may be connected via the decentral network. The decentral network may include computing nodes associated with participants of the product ecosystem and may be configured to perform data transactions. The computing nodes associated with participants of the product ecosystem may be associated with producers, users or reusers of physical products, such as chemical intermediate product producers, chemical product producers, intermediate product producers, end product producers, end product users, used product users or product re-users, collector(s), sorter(s) and / or recycler(s). The data transactions may be based on a transaction protocol including authentication and / or 231357

[0089] 12 authorization mechanism(s). Based on the authentication and / or authorization mechanism(s) a peer-to-peer communication between computing nodes associated with participants of the product ecosystem may be established. The respective nodes of the decentral network associated with the participants of the product ecosystem may be configured as decentral data consuming network node(s) and / or decentral data providing network node(s).

[0090] The one or more authentication mechanism(s) may be associated with or linked to a decentral identifier associated with the physical entity of the respective raw material, chemical product, intermediate product, component, component assembly, end-product, end-of life product or recycled material. The decentral identifier may uniquely identify the respective physical entity within the decentral network. The decentral identifier may connect the physical entity of the respective raw material, chemical product, intermediate product, end-product or end-of life product data to respective raw material data, chemical product data, intermediate product data, part data, component assembly data, end-product data, end-of-life product data, recycled material data respectively. The decentral identifier may include one or more Universally Unique Identifier(s) (UUID(s)) and / or one or more Decentralized Identifier(s) (DID(s)). The one or more authentication mechanism(s) associated with the decentral identifier may be provided to participant node(s). The one or more authentication mechanism(s) associated with the decentral identifier may be accessible by the decentral data providing network node and / or the decentral data consuming network node. The decentral configuration allows for more efficient use of computing resources and strengthens control by the data owners of the decentral network.

[0091] The one or more authorization mechanism(s) may include at least one authorization rule for controlling access to data under control by the data owners. The computing nodes associated with participants of the product ecosystem may be configured to provide decentral data consuming node(s) and / or decentral data providing node(s). A decentral data providing node may be configured to provide or send data to another participant node of the decentral network. A decentral data consuming node may be configured to ingest or receive data from another participant node of the decentral network. Providing data to a decentral data providing node for access by a decentral data consuming node may include indirect or direct access of the decentral data consuming node to the respective data, such as material data.

[0092] The decentral data network node may comprise computer-executable instructions for providing and / or processing data within a decentral network, such as the material data, requested by a decentral data consuming node. The decentral data providing node may be associated with or connected to one or more database(s) storing the material data. The decentral data providing node may be directly or indirectly connected to the database(s) storing the material data. Hence, the decentral data providing node may be associated with the material data. The database(s) may be under control of the data owner of the material data. The data owner may have access to the database(s). This way, the data owner of the material data may control access to the material data from various decentral data consuming nodes.

[0093] The decentral data consuming node may comprise computer-executable instructions for accessing and / or processing data within a decentral network, such as material data, provided by a decentral data providing network node. The decentral data consuming node may be controlled or owned by or associated with a consumer of the material data, such as the product producer. The consumer may be any entity processing the material data. The consumer may be any entity operating a production configured to process the material. Processing may include using the material to produce products. Processing may include performing one or more recycling step(s) on the material. The consumer may be a downstream participant of the material supplier in the product ecosystem the produced product is associated with, e.g. the product is used in.

[0094] A rule-based engine may be used to validate the gathered access data. The rule-based engine may be a software or software component that applies one or more rules to at least a part of the gathered access data. The rule-based engine used to validate at least part of the gathered access data may include usage rule(s). Usage rule(s) may be associated with individual data point(s), multiple data points and / or usage rule data included in the access data. Usage rule(s) associated with individual data point(s) may include one or more rule(s) defining allowable or non-allowable values for individual data points present with the gathered access data. The individual data points may be part of the usage rule data included in the access data. The individual data points may correspond to the value of key-value pair(s) defining usage rule(s). Use of such usage rule(s) allows to identify unacceptable data points, hence avoiding acceptance of unacceptable usage rule(s) while allowing to reliably accept usage rule(s) included in the access data.

[0095] Usage rule(s) associated with multiple data points may include one or more rules defining allowable combination(s) of data points present within the gathered access data. The usage rule(s) may define acceptable or unacceptable combination of data points. A combination of data point(s) may correspond to a usage rule, such as to a permission, a prohibition or an obligation. Use of such usage rule(s) allows to identify unacceptable usage rule(s), hence avoiding acceptance of unacceptable usage rule(s) while allowing to reliably accept usage rule(s) included in the access data.

[0096] Usage rule(s) may define acceptable usage rule(s) and / or unacceptable usage rule(s). The rules may define acceptable and / or unacceptable permissions, acceptable and / or unacceptable prohibitions and / or acceptable and / or unacceptable obligations. This allows to consider different constraints with regard to the usage of the material data, ensuring that the access data does not contain any unacceptable usage rule(s).

[0097] The trained data driven model may be trained on historical data sets including access data sets and associated acceptability scores. The access data sets may include one or more usage rule(s). The acceptability score may be indicative of the acceptability of respective usage rule. For instance, an acceptability score of 1 indicates that the usage rule is unacceptable while an acceptability score of 5 indicates that the usage rule 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 a usage rule is considered acceptable or not.

[0098] The trained data driven model may be a trained machine learning algorithm. Machine learning may refer to computer algorithms that improve through experience and are built on a model based on sample data, often described as training data, utilizing supervised, unsupervised, or semi-supervised machine learning techniques. Supervised learning may include using training data having a known label or result and preparing a model through a training process in which it is required to make predictions and the model is corrected when those predictions are wrong. The training process may continue until the model achieves a desired level of accuracy on the training data. Semi-supervised learning may include using a mixture of labelled and unlabeled data and preparing a model through a training process in which the model learns the structures to organize the data as well as to make predictions. Unsupervised learning may include using unlabeled data not having a known result 14 and preparing a model by deducing structures, such as general rules, similarity, etc., present in the data.

[0099] The data driven model may be trained by selecting inputs and outputs to define an internal structure of the machine learning algorithm, applying a collection of input and output data samples to train the machine learning algorithm, verifying the accuracy of the machine learning algorithm by applying material input data samples of known plausibility and comparing the produced output values with expected output values, and modifying the parameters of the machine learning algorithm using an optimizing algorithm in case the received output values are not corresponding to the known plausibility. As access data sets being labelled with a respective acceptability score may be used. Hence, each access data set may be labelled with an appropriate acceptability score indicating the degree of acceptability (e.g. acceptable to unacceptable) associated with the respective usage rule. The data may be selected randomly but with the proviso that the training data contains the complete spectra of acceptability scores.

[0100] Gathering may include receiving or retrieving data, such as access data and material data. Providing may include receiving or retrieving data, such as access data and material data.

[0101] The data processing system may include any system configured to process received material data, The data processing system may be communicatively coupled with the decentral data consuming node associated with the data consumer. For instance, the data processing system may be coupled via an API with the decentral data consuming network node. The data processing system may be configured to perform at least one data processing operation on the received material data. Data processing operation(s) may include deleting a part of the material data, filtering the material data, joining the material data, aggregating the material data, merging the material data, updating the material data, comparing the material data to further data and / or extracting at least a part of the material data.

[0102] The digital representation of the data processing system may include the access data and a representation for providing material data to the data processing system. The representations may include a locator pointing to the data processing system. The representation may be used by decentral data providing node(s) to provide material data to such data processing system. The locator may be a URI or a URL of the data processing system. The locator may be a URI or URL of an API of the data processing system. The representation may further include a decentral identifier.

[0103] In an embodiment, the material data is stored in a database associated with the data owner of the material data, such as the material producer, and access to the material data stored in the database is controlled by the data owner of the material data. The database may be controlled by the data owner of the material data. The database may be a dedicated storage of the data owner of the material data. The database may be associated with the production producing the material. The database may be associated with the decentral data providing node. The material data may be accessible for the data owner. The data owner may be the owner of the material associated with said material data. The database may be accessible by the data owner and the decentral data providing node. The data owner may be the entity operating the production producing the material. The data owner may control access to the database storing the material data via the decentral material identifier. The data owner may control access to the database storing the material data via the access data. This way, sharing of the material data with multiple data consumers is enabled within the decentral network under full 231357

[0104] 15 control of the data owner of the material data.

[0105] In an embodiment the access data includes the decentral material identifier and policy data. The policy data may include a policy identifier and usage rule data indicating one or more usage rule(s) defining the usage of the material data by the data consumer. The access data may be generated by the data owner of the material data. The access data may be generated on behalf of the material data owner. The access data may be associated with the material data via the decentral material identifier. The usage rule(s) may define permissions, prohibitions and / or obligations of the data consumer using the material data. Use of the material data may include performing at least one processing operation on the material data. Permissions may indicate the ability to perform an action on the material data associated with the access data. In contrast, prohibitions may indicate the inability to exercise an action on the material data associated with the access data, e.g. may indicate actions that are not allowed to be performed on the material data associated with the access data. The prohibition may hence disallow an action to be exercised on the material data associated with the access data. The obligations may indicate obligations to exercise an action on the material data associated with the access data. Via the access data associated with the material data, the material data owner may define permissions, prohibitions and / or obligations associated with the usage of the material data by data consumers. This way, usage of the material data by various data consumers within the decentral network may be controlled by the data owner of the material data in a secure and reliable manner.

[0106] In an embodiment the material includes a raw material, a chemical intermediate product, a chemical product, a part or component, a component-assembly, an end product or an end-of-life product. The raw material may be a virgin material. The raw material may be a recycled material.

[0107] In an embodiment, the decentral material identifier is provided from a sensor reading an identifier element physically connected to the material. The identifier element may be present on the packaging unit of the respective material. The identifier element may be present on the material. The identifier element may uniquely identify the respective material. The identifier element may include any physical arrangement that associates the decentral material identifier with the respective material. The identifier element may include any physical arrangement that associates the material with the material identifier the decentral material identifier is associated with. The material identifier may be used to determine the respective decentral material identifier via the decentral network. The identifier element may include markers embedded in the material, a bar code, a QR-Code, a tag like a RFID tag or similar physical arrangement that allows to digitally identify the material. The identifier element may be a physical identifier physically connected to the material, such as a packaging unit comprising the material. The packaging unit may be any enclosure suitable to store the material. Packaging units may depend on the type of material as well as the amount of produced material or the intended use of the material at the production. Suitable packaging units for liquid materials may include containers, bottles, tanks, etc. Suitable packaging units for solid materials may include tanks, bags, bottles, containers, etc..

[0108] In an embodiment the access data is provided in response to a request to access the material data by a decentral data consuming node associated with a data consumer via a decentral network at a decentral data providing node associated with a data owner of the material data The access may be requested at the data providing node associated with the material owner. Access may be requested by querying decentral registry node(s) storing digital representations (also denoted as 231357

[0109] 16 access elements hereinafter) associated with the material data and requesting access based on such digital representation(s). The decentral registry node(s) may be queried based on the material identifier associated with the material(s). The digital representations may include decentral material identifier(s) and representation(s) for accessing the respective material data associated with the respective decentral material identifier.

[0110] In an embodiment providing the access data includes providing the decentral material identifier(s) by the decentral data consuming node to the decentral data providing node, and receiving the access data from the decentral data providing node in response to providing decentral material identifier(s). The access data may correspond to a dataset of a data catalog (e.g. a collection of entries representing material data and associated policy data that is published in the decentral network by the material data owner) provided by the decentral data providing node in response to receiving the decentral material identifier(s). The number of entries in the data catalog may correspond to the number of decentral material identifiers provided by the decentral data consuming node. This way, only access data associated with the provided decentral material identifier(s) (e.g. access data including decentral material identifier(s) matching the provided decentral material identifier(s)) is provided, allowing efficient validation of the provided access data.

[0111] In an embodiment, providing at least one digital representation pointing to the data processing system configured to process the material data includes requesting dataset(s) available for access at the decentral participant node of the data consumer. The dataset(s) may correspond to the data catalog. The data set(s) may be requested from the decentral data consuming node associated with the data consumer. The dataset(s) may include the at least one digital representation. The digital representation may include the access data and a representation pointing to the data processing system.

[0112] In an embodiment the usage rule data relates to emission data, production data, recyclate content data, bio-based content data, provenance data and / or labour conditions data included in the material data. The emission data, production data, recyclate content data, bio-based content data, provenance data and / or labour conditions data may be included in the material data in the form of data set(s). Each data set (e.g. emission data set, production data set, recyclate content data set, bio-based content data set, provenance data set and labor conditions data set) may be associated with usage rule data. The usage rule data associated with each data set may differ from the usage rule data associated with the other data set(s). This way, the data owner of the material data may define access on a more granular level, allowing for improved control over the sharing of the material data with downstream participants.

[0113] In an embodiment the usage rule data defines one or more action(s) permitted by the data consumer to be performed on the material data, one or more action(s) not permitted by the data consumer to be performed on the material data and / or one or more obligations to be fulfilled by the data consumer.

[0114] In an embodiment, the usage rule data includes one or more local usage rule(s) that are specific to a particular location, wherein the location is associated with a jurisdiction and the local rule for the location is associated with legal requirements related to the supply of the material(s) and / or the product(s). The local rules may include instructions configured to provide access to the material data based on the location of the data consumer. This way, different requirements and / or obligations in terms of usage of the material data by the data consumer based in different jurisdictions and / or locations can be 231357

[0115] 17 considered. This allows to flexibly adapt the usage rule(s) to different legal requirements, ensuring material data can be accessed according to legal requirements.

[0116] In an embodiment the usage rule data includes one or more usage rule(s) related to regulatory requirements for the supply of the material(s) and / or the product(s). For instance, regulatory requirements may stipulate access to material safety data included in the material data. Hence, usage rule data may include usage rule(s) permitting the usage of the material safety data by data consumers.

[0117] In an embodiment the usage rule data includes one or more aggregation rule(s) relating to the material data. The aggregation rule(s) may define allowable modification operation(s) to be performed on the material data. Modification operations may include data transformation operation(s), data processing operations and / or data aggregation operation(s).

[0118] In an embodiment the rule-based engine operates on individual data point(s) included in the access data, multiple data point(s) included in the access data and / or usage rule data included in the access data. The rule-based engine may be configured to determine the acceptability of individual data point(s), combinations of data points and / or the usage rule data. The rule-based engine may operate on the individual data point(s), combinations of data points and / or the usage rule data using usage rule(s) as previously described. For instance, the rule-based engine may apply predefined usage rule(s) to individual data point(s), multiple data point(s) and / or the usage rule data included in the access data to determine the acceptability of the individual data point(s), multiple data point(s) and / or the usage rule data. If the rule-based engine determines that the individual data point(s), multiple data point(s) and / or the usage rule data set is acceptable, said individual data point(s), multiple data point(s) and / or the usage rule data may be regarded as validated.

[0119] In an embodiment the one or more usage rule(s) include instruction(s) for validating the access data. The instructions may include instructions to match at least a part of the access data, such as usage rule data included in the gathered access data, to predefined usage rule data. The predefined usage rule data may include allowable usage rule(s), combination of allowable usage rule(s) and / or data associated with agreements signed by the material data owner and one or more participant(s) of the decentral network. The one or more participant(s) of the decentral network may be data consumer(s) requesting access to the material data associated with the data owner. The one or more participant(s) of the decentral network may be data provider(s) providing material data. The data associated with signed agreements may include agreement identifier(s) associated with or included in such signed agreement(s). Matching the predefined usage rule data to the access data may include comparing predefined usage rule data to individual data point(s) present within the access data to be validated and / or comparing data point combination(s) of predefined usage rule data to data point combination(s) present within the access data to be validated and / or comparing predefined usage rule data to usage rule data included in the access data to be validated. The instructions may include instructions to signify usage rule data included in the gathered access data as validated or non-validated based on the result of the comparison. For instance, the instructions may signify usage rule data included in the gathered access data as validated if such usage rule data matches to one or more predefined usage rule(s). The predefined usage rule(s) may be stored in a database. The database may store acceptable or allowable usage rule(s) related to acceptable permissions, prohibitions and / or obligations. In addition, the database may further store combination(s) of acceptable or allowable usage rule(s) related to acceptable permissions, prohibitions and / or obligations. 231357

[0120] 18

[0121] In an embodiment the data-driven model trained to validate the access data is a classifier model. The classifier model may classify the input data (e.g. at least part of the gathered access data) into two classes, such as “acceptable” and “not acceptable”. The classifier model may be selected from Decision Trees, Naive Bayes Classifiers, K-Nearest Neighbors, Support Vector Machines and deep learning models. Deep learning may refer to methods based on artificial neural networks (AN Ns) having an unbounded number of layers of bounded size, which permits practical application and optimized implementation, while retaining theoretical universality under mild conditions. Deep learning architectures implementing deep learning algorithms may include deep neural networks, deep belief networks (DBNs), recurrent neural networks (RNNs) and convolutional neural networks (CNNs) and feed-forward networks.

[0122] In an embodiment the data-driven model trained to validate the access data generates at least one classifier discriminating between validated and non-validated access data. The classifier may classify validated access data as acceptable and nonvalidated access data as unacceptable.

[0123] In an embodiment the access data is validated if the access data fulfils at least one usage rule. In another embodiment, the access data is validated if the access data is associated with a classifier indicates acceptable access data.

[0124] In an embodiment data indicative of acceptance may include data indicating the acceptance of usage rule data included in the access data. Data indicative of acceptance may signify an offer for an agreement on the usage rule data. The data indicating the acceptance of the usage rule data may include the validated usage rule data, a decentral participant identifier associated with the data owner of the material data, a decentral participant identifier associated with the data consumer, an offer identifier and the decentral material identifier. The decentral participant identifier may uniquely identify the respective participant within the decentral network. The decentral participant identifier may include letters, numbers or a combination thereof. The data may indicate acceptance of the usage rule data by the data consumer. Acceptance of the usage rule data by the data consumer may indicate that the data consumer accepts the permissions, prohibitions and / or obligations included in the usage rule data.

[0125] In an embodiment, the method further includes a step of gathering the material data based on the decentral material identifier and the data indicative of acceptance. Gathering material data may include receiving agreement data in response to providing data indicative of acceptance, validating the received agreement data and requesting access to the material data based on the decentral material identifier and the agreement data. The agreement data may be generated by the data provider, such as the material data owner, in response to receiving the data indicative of acceptance. The agreement data may be generated by the decentral data providing node associated with the data provider. The agreement data may include the agreement identifier, the offer identifier, the decentral material identifier, the decentral participant identifier associated with the data owner of the material data, the decentral participant identifier associated with the data consumer and the accepted or validated usage rule data.

[0126] BRIEF DESCRIPTION OF THE DRAWINGS

[0127] 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 231357

[0128] 19 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.

[0129] 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.

[0130] FIG. 2A illustrates schematically an example of a system for accessing material data associated with materials by downstream node(s) associated with downstream participant(s) using the materials to produce one or more products.

[0131] FIG. 2B illustrates schematically an example of a system for providing material data related to producible materials by upstream node(s) associated with upstream participant(s) to data consumer(s) using the materials to produce product(s).

[0132] FIG. 3A illustrates a data model of policy data expressing permissions, prohibitions and duties related to the usage of an associated asset.

[0133] FIG. 3B illustrates examples of different policy data that can be linked to an asset.

[0134] FIG. 30 illustrates an example of a data set linking different policy data to a given asset.

[0135] FIG. 4 illustrates a sequence diagram of an example data exchange involving access data associated with material data between a decentral data providing node associated with the material data and a decentral data consuming node requesting access to such material data.

[0136] FIG. 5A illustrates an example of a digital credential certifying the signature of a contract between a data consumer and a data provider.

[0137] FIG. 5B illustrates an example of access data associated with material data and provided by a data provider associated with such material data to a data consumer upon request to access such material data by the data consumer.

[0138] FIG. 50 illustrates an example of agreement data generated by the data consumer in response to successful validation of policy data included in the access data of FIG. 5B. 231357

[0139] 20

[0140] FIG. 5D illustrates an example of agreement data indicating an agreement between a data provider and a data consumer on usage rule(s) associated with material data to be transferred by the data provider to the data consumer.

[0141] FIG. 6A, FIG. 6B illustrate examples of a production producing one or more product(s) from one or more material(s) in connection with an operating system including a policy data validation system.

[0142] FIG. 60 illustrates an example of a production producing material(s) from one or more input(s) in connection with an operating system including a policy data validation system.

[0143] FIG. 7A illustrates a diagram showing an example of gathering policy data and validating at least a part of the gathered policy data using a rule-based engine.

[0144] FIG. 7B illustrates a diagram showing an example of gathering policy data and validating at least part of the gathered policy data using a trained data-driven model.

[0145] FIG. 70 illustrates a diagram showing an example of gathering material data based on agreement data generated in response to successful validation of the policy data.

[0146] FIG. 8 illustrates a flow chart of an example method for validating access data including usage rule data associated with the usage of material data by a data consumer.

[0147] FIG. 9 illustrates a flow chart of an example method for providing material data associated with produced material(s) via a decentral network to a data consumer for controlling the production of product(s) based on the material data.

[0148] FIG. 10 illustrates a flow chart of an example method for validating access data associated with the processing of material data by a data consumer.

[0149] FIG. 11 illustrates a flow chart of an example method for providing material data associated with material(s) producible by a production via a decentral network to a data consumer for processing the material data.

[0150] FIG. 12 illustrates an example method for training a data-driven model to validate access data including usage rule data associated with the usage of material data by a data consumer.

[0151] DETAILED DESCRIPTION

[0152] FIG. 1 illustrates an example of a participant network of a product ecosystem associated with a decentral peer-to-peer 231357

[0153] 21 network for transfer of data associated with materials and produced products used within the product ecosystem.

[0154] The participant network 130 of the product ecosystem associated may be associated with a decentral peer-to-peer 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 130 may include one or more network participants 102 to 114 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 chains to recycle at least part of an end- of-life product resulting from the use of the end product(s).

[0155] 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 112 and a recycler 114. 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 to use 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 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.

[0156] The participant(s) of the participant network 130 may be associated with the production of products and / or recycling 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, end-product producer 108, a user of physical goods, such as end-product user 110, and / or a participant of a recycling chain associated with the physical product, such as EOL product collector 112 and recycler 114. The network participant may be associated with a participant node 116 to 128 and a decentral participant identifier related to an associated participant node(s) 116 to 128. The decentral participant identifier may uniquely identify the decentral network participant and its associated decentral participant node within the decentral peer-to-peer network 134.

[0157] The participant(s) of the participant network 130 may be connected via material flows. The material flow may be a loop material flow 136. The loop material flow 136 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 136 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 136 may correspond to the flow of product from one participant of the participant network 130 to the downstream participant of the participant network 130. The material flow 136 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 231357

[0158] 22 transportation may include pipes, containers, barrels, packages. The material flow 136 may be associated with raw materials used to produce the chemical product, such as virgin raw materials 158. The raw materials may be provided to chemical product producer 102 for producing chemical product(s) and / or intermediate chemical product(s) (not shown). The loop material flow 136 may be associated with chemical product(s) 156. The chemical product(s) may be provided from chemical product producer 102 to chemical product user 106 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 136 may be associated with recycled material 160. The recycled material may be provided from recycler 114 to chemical product producer 102 to produce chemical product(s).

[0159] At least part of the participants of the participant network 130 may be associated with decentral participant network nodes 116 to 128. The decentral participant nodes 116 to 128 may be under control of the respective decentral participant associated with the respective decentral participant node 116 to 128. The decentral participant nodes 116 to 128 may form decentral network 134. The decentral network 134 may be a peer-to-peer communication network. The decentral peer-to- peer network 134 may be configured to perform data transactions 132 according to at least one network protocol. The data transactions 132 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 decentral network nodes 116 to 128 associated with network participants 102 to 114 may be established. The one or more authentication mechanism(s) may be associated with or linked to the decentral identifier as described in the context of FIG.

[0160] 2. The one or more authentication mechanism(s) associated with the decentral identifier may be accessible by the decentral participant nodes 116 to 128 as described in the context of FIG. 2. 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.

[0161] Data transactions between decentral network participant nodes 116 to 128 may be based on a decentral identifier associated with respective product data to be accessed, for example as described in the context of FIG. 2. 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.

[0162] The data flow 132 (e.g. transactions, depicted by dashed lines) between decentral network participant nodes 116 to 128 may be directly or indirectly associated with the material flow 136 (depicted by bold solid lines) between the network participants 102 to 114. For instance, data flow 132 may be directly associated with material flow 136 if data associated with a material provided from the raw material producer 104 to the chemical product producer 102 is accessed by decentral participant node 118 associated with said chemical product producer 102. For instance, data flow 132 may be indirectly associated with material flow 136 if data associated with a chemical product produced by chemical product producer 102 is accessed by decentral participant node 128 associated with recycler 114. 23 The decentral participant nodes 116 to 128 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.

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

[0164] The decentral network 134 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 102 to 114 of the product ecosystem. The further decentral network nodes may provide services for network participants 102 to 114. For instance, the further decentral network nodes may provide digital marketplaces for network participants 102 to 114. The further decentral network nodes may be decentral infrastructure service nodes. The decentral infrastructure service nodes may provide services for decentral participant nodes 116 to 128, such as verifying the identity of the decentral network participant nodes 116 to 128 prior to performing a data exchange. The decentral network participant nodes 116 to 128 may be associated with or include certificate(s), such as X.509 certificate(s). The certificate(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 116 to 124 may be associated with a unique identifier embedded in a X.509 certificate that identifies the respective decentral network participant node 116 to 128. The information required to verify the certificate may be provided via an authentication registry associated with the certificate issuing service and / or a dynamic provisioning service. For instance, in the IDSA Reference Architecture Model, Version 3.0 of April 2019, a decentral data providing network node associated with a data owner, a Certification Authority (CA), a Dynamic Attribute Provisioning Service (DAPS) and a decentral data consuming network node associated with a data consumer may be used to verify the identity prior to performing a data exchange (not shown).

[0165] FIG. 2A illustrates schematically an example of a system for accessing material data associated with materials by downstream node(s) associated with downstream participant(s) using the materials to produce one or more products. The system shown in FIG. 2 may be used to exchange data, such as material data associated with materials supplied to participants of the product ecosystem to produce products, within a participant network, such as the participant network described in the context of FIG. 1 . Material(s) may include raw material(s), chemical intermediate material(s), chemical material(s), part(s), component(s), component assembly / ies, end product(s), end-of-life product(s) or recycled material(s). What is described in the context of FIG. 2 with respect to material data equally applies to product data associated with 24 products produced from such materials. Product(s) may include chemical intermediate material(s), chemical material(s), part(s), component(s), component assembly / ies, end product(s), end-of-life product(s) or recycled material(s).

[0166] For exchanging material data within the participant network illustrated for example in FIG. 1 , digital twins associated with the material 140 may be generated. The digital twin may be a digital representation of a physical entity of the material with defined semantic description(s) of said physical entity of the material. The digital twin of the physical entity of the material is hence a digital version of said physical entity. Once created, the digital twin can be used to represent the physical entity of the material in a digital representation of a real-world system. The digital twin may be uniquely linked to the physical material via an identifier. The digital twin may be created such that it is identical in form and behavior of the corresponding material. Additionally, the digital twin may mirror the properties of the material, e.g. during its production and / or lifetime. For example, sensors may capture real-time (or near real-time) data, such as transport data or use data, from the physical material to relay it back to a remote digital twin. The digital twin may then be updated to maintain its correspondence to the physical entity of the material. Hence, the digital twin may at any time represent the current state of the physical entity of the material.

[0167] The digital twin of the material may include a decentral material identifier and material data. The material data may include at least one measured chemical and / or physical property of the material and / or at least one physical and / or chemical property determined from collected data associated with the production and / or the use of the material. The data may be collected prior to, upon or after production of the respective material. Different parts of the data to be collected may be associated with a common identifier to allow collecting of the data based on a single identifier. The material data may further include material identifier(s), material producer data, material declaration data, material safety data, production data associated with the material, certificate of analysis data associated with the material, emission data associated with the material, recycled content data associated with the material, biobased content data associated with the material, renewable content data associated with the material, biodegradability data associated with the material, certificate data associated with the material, life cycle data associated with the material, storage instruction data associated with the material, processing conditions associated with the material or a combination thereof. The material data may contain one or more material data set(s) (also denoted as assets hereinafter). The at least one property or further data may be included in at least one of the data set(s).

[0168] The digital twin may be generated by the data owner of the material data, such as material supplier 104. The digital twin may be generated on behalf of the data owner of the material data. The digital twin may be generated by gathering data associated with the material, applying one or more data models to the gathered data to generate the material data and linking the generated material data to the decentral material identifier to generate the digital twin. Via the decentral material identifier and its unique association with the digital twin (and hence with the material and material data) and optionally the data owner, access to the digital twin or parts thereof generated from said data may be controlled by the data owner. This contrasts with central authority schemes, where identifiers are provided by such central authority and access to data is controlled by such central authority. Decentral in this context refers to the usage of the decentral identifier(s) as controlled by the data owner of the data associated with such decentral identifier(s). The decentral material identifier may include or be associated with one or more identifier(s) used in the decentral network and allowing for data exchange via the decentral network. For instance, the decentral identifier may include or be associated with data set identifier(s) of data sets included in the material data, such as UUID(s) of twin data set(s). Any combination of UUID(s) and DID(s) may be possible. For 231357

[0169] 25 instance, the decentral material identifier may be a DID while the data set identifier(s) may be UUID(s). In another instance, the decentral material identifier, and the digital twin set data identifier(s) may be UUlDs. Data exchange may include discovery of the decentral material identifier and optionally identifier(s) associated with said decentral material identifier for participant nodes of the decentral network, authentication of participant nodes of the decentral network and / or authorization of data transfers via a peer-to-peer communication between participant nodes of the decentral network. The digital twin may be stored in a dedicated storage (material data DB 202) associated with the decentral data providing node 116. The dedicated storage may be associated with the data owner of the digital twin. The dedicated storage may be accessible by the data owner of the digital twin. Access to the dedicated storage may be controlled by the data owner of the digital twin, for example via the decentral material identifier and related policy data as described in the context of FIG. 6A to FIG. 9. The policy data may be associated with the material data or parts thereof. Defining policy data per data set may allow to control access to the digital twin on a data set level, hence allowing a more granular access control to the digital twin of the material.

[0170] The decentral material identifier may be linked to other decentral identifier(s) according to a physical relation of the material entity with other physical entities e.g. those used to produce the material or those produced from the material. This way decentral participant node(s) of the decentral network may be able to interpret the relation of the decentral material identifier corresponding to the physical relation of the physical material entity to other physical entities. The linking of the decentral material identifier with other decentral product identifier(s) allows to determine the decentral participant node(s) storing the data associated with products produced using the material or materials used to produce the material. The decentral material identifier may be digital or virtual identifier(s), e.g. may not correspond to physical identifier(s) physically attached to the material.

[0171] The decentral material identifier may be assigned to a physical identifier connected to the material 140. The connection of the physical identifier with the material 140 may be provided by means of physical connection to the physical material 140 or physical entity. For instance, the physical identifier may be connected with the physical entity of the material 140. The physical identifier may have one-to-one correspondence to a virtual identity or to a physical identity by means of a physical connection to the physical entity. The physical identifier may be physically attached to the material 140 via an identifier element. Physical identifier or physical identifier element may refer to any virtual or physical arrangement that associates the decentral identifier with the material 212. The physical identifier may be any identifier for the produced material 140, such as a batch number or a part number. The physical identifier element may comprise a passive or active element, e.g. QR-code, RFID-tag, but is not limited thereto. The physical identifier element may be a physical identifier physically connected to the material. The identifier element may include markers embedded in the material, a bar code, a QR-Code, a tag like a RFID tag or similar physical arrangement that allows to digitally identify the material.

[0172] Digital access element(s) may be generated to allow access to the material data or parts thereof via the decentral network 134. A digital access element may be generated per data set (denoted as asset hereinafter). This may allow access to the material data on asset level. The digital access element may include a decentral access element identifier and access data. The decentral access element identifier may be associated with the decentral material identifier. The decentral access element identifier may correspond to the decentral material identifier. The access data may include a digital representation pointing to the decentral data providing node associated with the digital twin of the material. The access data may include a 231357

[0173] 26 representation for accessing the digital twin or parts thereof. The decentral material identifier may be associated with the representation for accessing the digital twin or parts thereof. The digital representation pointing to the decentral data providing node may include an endpoint for data exchange or sharing (resource endpoint) or an endpoint for service interaction (service endpoint), that is uniquely identified via a communication protocol. The digital representation may be regarded as locator directly or indirectly indicating the location or dedicated data storage(s) where the digital twin or parts thereof is / are stored. The digital access element may further include or relate to authentication and / or authorization information linked to the decentral access element identifier. The authentication and / or authorization information may be provided for authentication and / or authorization of the decentral network node / decentral data consuming network nodes and decentral data providing network nodes. The digital access element may be provided to a decentral registry node, such as decentral registry 204. The decentral registry node may store decentral access element identifier(s) and associated access data. Access to the decentral registry 204 may be controlled by the data owner of the material data associated with such access elements. Access to the decentral registry 204 may be controlled via decentral data providing node 116. Access to the decentral registry 204 may be controlled based on decentral participant identifiers related to decentral data consuming nodes associated with data consumers. This way, data consuming node(s) requesting access to decentral registry 204 may be filtered. The access elements stored in decentral registry 204 may be used to generate a data catalog including a list of assets accessible for the data consuming node querying decentral registry 204, for example as illustrated in FIG. 5A.

[0174] Policy data may be generated to control access to the digital twin or parts thereof and / or usage of the material data contained in digital twin or the part thereof (e.g. assets of the digital twin), for example as described in the context of FIG. 3A to FIG. 3C.

[0175] The material 140 may be produced by a production, for example as described in the context of FIG. 6A. The material 140 may have been produced by the production. The production may be a chemical production, for example as described in the context of FIG. 6A. The production may be operated by material supplier 104. The physical entity of the material 140 as produced by the production material supplier 104 may be physically provided from the material supplier 104 to the chemical product producer 102. The material may be provided in association with the digital twin to chemical product producer 102. The chemical product producer 102 may use the supplied material to produce product(s) (e.g. output product(s)), for example as described in the context of FIG. 6A to FIG. 6C. Output products may be chemical intermediate product(s) or chemical product(s). The material 140 may be connected to a code, such as a bar code or QR-code. The code may encode the input material identifier. The code may encode the decentral material identifier. The code may further encode a digital representation pointing to the data providing node associated with the material data, such as node 116 and / or the decentral participant identifier related to such node. The code may further encode a digital representation pointing to the backend 206. The chemical product producer 102 receiving material 140 may read the code through code reader 214. The code reader 214 may be a smartphone running a code reading application, such as a QR code reader app. The code reading application may be configured to determine the material identifier. The code reading application may be configured to determine the decentral material identifier. The code reading application may further be configured to determine the digital representation pointing to the data providing node or the backend 206. The code reading application may be configured to display the data, such as the identifier(s) and / or the digital representation(s). The code reading application may be configured to provide the data, such as the input material identifier or decentral material identifier and optionally the digital representation and / or 231357

[0176] 27 decentral participant identifier, to backend 206.

[0177] Backend 206 may be in a client-server relationship with code reader 214, where code reader 214 functions as client and backend 206 functions as server. Backend 206 may be configured to provide data to code reader 214, such as gathered decentral material identifiers and / or gathered digital twins or parts thereof. Code reader 214 may be configured to display such data, for example within a graphical user interface. Backend 206 may be connected to a decentral data consuming network node being part of a decentral network 134, such as node 118. Node 118 may be associated with a chemical production producing one or more chemical product(s) using the material 140 (not shown, see for example FIG. 6A to FIG. 6C). Node 118 may be associated with the entity operating the chemical production, such as chemical product producer 102. Node 118 may be configured to determine - based on the data received from code reader 214 - provider node(s) being associated with the producer of the material 140, such as node 116. For instance, node 118 may be configured to query infrastructure node(s) of decentral network 134 (not shown in FIG. 2) using the material identifier to determine decentral participant identifier(s) of data provider(s) associated with the material identifier. The determined decentral participant identifier(s) may then be used by node 118 to query the infrastructure node(s) to determine endpoints of provider node(s), such as node 116, associated with said decentral participant identifier(s).

[0178] Backend 206 may be configured to generate query data to query decentral registries, such as decentral registry 204, associated with the obtained endpoint(s) of the provider node(s), such as node 116 (see step [2] in FIG. 2). The query data may include the material identifier. The query data may include key value pair(s), where at least one value may be the material identifier. The backend 206 may be configured to generate a request for gathering the decentral material identifier(s) associated with said material identifier(s). The request may include at least a part of the received end point(s) of provider node(s) and the query data. The request may be provided to node 118. Consumer node 118 may be configured - in response to the request from the backend 206 - to query the decentral registries of decentral network 134. The queries may include the query data and a decentral participant identifier associated with the consumer node 118.

[0179] Consumer node 118 may be configured to send such queries to the endpoint(s) of provider node(s), such as node 116, included in the request received from backend 206 (see step [2] of FIG. 2). The queries may be authenticated. 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 participant nodes, e.g. consumer node 118 and provider node 116. If authentication fails, no query results may be provided by respective data provider(s). The queries may further be authorized. Such authorization may be based on or related to an authorization mechanism. The authorization mechanism may be based on access data defining decentral data consuming network nodes allowed to request data stored in decentral registry 204 associated with such provider node(s), such as node 116 and one or more usage rule(s) associated with the usage of the data stored within the decentral registry 204. The authorization mechanism may further be based on acceptance of the policy data by the consumer node(s), such as node 118, as described later on. Such access data may be provided to consumer node(s), such as node 118, in response to requesting data stored in decentral registry 204. 231357

[0180] 28

[0181] If authentication is successful, provider node(s), such as node 116, may be configured to query associated decentral registry(ies), such as decentral registry 204, to determine whether the associated decentral registry includes decentral identifier(s) (e.g. decentral material identifiers) related to the query data contained in the query from the consumer node 118 (see steps [3], [4] in FIG. 2). If authentication and authorization is successful, provider node(s), such as node 116, may be configured to query associated decentral registry(ies), such as decentral registry 204, to determine whether the associated decentral registry includes decentral identifier(s) (e.g. decentral material identifiers) related to the query data contained in the query from the consumer node 118. Provider node(s) not having determined decentral identifier(s) related to the query data may send a respective response to consumer node 118. Provider node(s), such as node 116, not having determined decentral identifier(s) related to the query data may not send any response to consumer node 118. Provider node(s) 116 having determined decentral identifier(s) related to the query data may return such decentral identifier(s) to consumer node 118 (see step [5] in FIG. 2). Consumer node 118 may provide such decentral identifier(s) to backend 206.

[0182] In response to receiving decentral identifier(s) from providing node(s) 116, consuming node 118 may be configured to request policy data associated with such decentral identifier(s) (e.g. material identifier(s)) from provider node(s) 116 (see step [6] in FIG. 2) The policy data may be requested, for example, as described in the context of FIG. 4. Provider node 116 may provide policy data associated with such decentral identifier(s) to requesting consumer node 118, for example as described in the context of FIG. 4. Consumer node 118 may provide such policy data to backend 206. Backend 206 may be configured to validate the policy data, for example as described in the context of FIG. 6A to FIG. 8. If the policy data is validated, backend 206 may provide data indicating acceptance to consumer node 118. In response to such acceptance data, consumer node 118 may generate offer data including the decentral material identifier and at least a part of the validated policy data and may provide such data offer to provider node 116, for example as described in the context of FIG. 4. The offer data may be accepted by provider node 118, for example as described in the context of FIG. 4. This way, an electronic contract can be agreed upon between network nodes of the decentral network 134, the electronic contract including the policy data agreed upon by the nodes (see for example FIG. 4 to FIG. 5C). If the policy data is not validated, backend 206 may likewise forward data being indicative of rejecting the policy data to consumer node 118. In response to such rejection data, consumer node 118 may indicate termination of the negotiation on the policy data to provider node 116. In response to such termination, provider node 116 may close the connection to consumer node 118 and may not provide any further data, in particular may not provide material data. This way, it can be ensured that material data is only provided to data consumers which agreed to the usage rule(s) defined within the respective policy data associated with the material data.

[0183] Backend 206 may be configured to generate a request to gather access element(s) associated with the decentral material identifier(s) upon receiving an indication that the offer data was accepted by provider node 116. The request may include an agreement identifier associated with the electronic contract negotiated between the nodes and the material identifier. The request may be provided to consumer node 118. Consumer node 118 may be configured to request respective access element(s) from provider node(s) 116 having provided decentral material identifier(s) in step [5]) (see step [6] of FIG. 2). The request to respective provider node(s) 116 may include the decentral material identifier(s) and the decentral participant identifier associated with consumer node 118. Upon receiving the request, provider node(s) 116 may gather access element(s) from associated decentral registry 204 based on the decentral material identifier(s) contained in the received 231357

[0184] 29 request. The gathered access element(s) may then be provided to consumer node 118. Consumer node 118 may provide the received access element(s) to backend 206. Backend 206 may store the access elements in a storage associated with the server, such as storage 208.

[0185] Backend 206 may be configured to parse the received access element(s) (e.g. the received access element data). The access element(s) may include decentral material identifier(s) and associated access data. Backend 206 may be configured to match access data contained in received access elements with data provided by code reader 214, such as material identifier(s) to determine decentral identifiers and associated access data matching the provided data. Backend 206 may be configured to generate a respective request to retrieve such asset(s) associated with such decentral material identifier(s). The request may include the decentral material identifier(s), the associated access data and the respective agreement identifier. The request may be generated upon determining a match between material identifier(s) provided by code reader 214 and material identifier(s) included in the access element(s) provided by consumer node 118. The request may be forwarded to consumer node 118. Consumer node 118 may generate a request to gather the respective material data associated with the decentral material identifier from respective provider node(s) 116. The request may include the decentral material identifier and the agreement identifier included in the request received from backend 206. The request may further include the decentral participant identifier associated with consumer node 118. The request may be sent by consumer node 118 to the endpoint defined in the access data gathered from provider node 116. Consumer node 118 and provider node 116 may be authenticating as previously described.

[0186] Provider node 116 may determine whether consumer node 118 is authorized to access the requested material data. Provider node 116 may match the decentral participant identifier provided by consumer node 118 to policy data associated with the respective material data. This may allow to filter consumer nodes requesting access to such material data based on associated decentral participant identifiers, hence improving security to ensure that no unauthorized consumer nodes can access the material data. Provider node 116 may gather the requested material data from material data DB 202 based on the decentral material identifier(s) received from consumer node 118 (see steps [7], [8] of FIG. 2). Provider node 116 may gather the requested material data upon successful authorization of consumer node 118. Provider node 116 may provide the gathered material data to consumer node 118 (see step [9] in FIG. 2). Provider node 116 may apply policy data to the gathered material prior to providing such data to consumer node 118. Consumer node 118 may provide the received material data to backend 206. Backend 206 may be configured to store such data in storage 208 (see steps

[0010] ,

[0011] in FIG. 2).

[0187] Through the decentral material identifier, the material data can be uniquely associated with the material. Through the decentral network, the material data may be transferred between a material producer and a material consumer in a standardized and secure way, allowing the material producer to control access to the material data by multiple decentral data consuming network nodes existing within the decentral network via the decentral material identifier. This way, the material data can be shared with unique association to the material and without central intermediary directly between the participants of the product ecosystem in a secure and reliable manner.

[0188] By using policy data associated with such decentral material identifier, access to the material data by multiple data consumer nodes within the decentral network and / or usage of the provided material data by data consumers may be reliably controlled by the data owner of the material data. This way, the material data can be shared in a secure yet reliable way within the 231357

[0189] 30 decentral network, allowing users of the material to consume material data associated with such material, for example to control the production of chemical products using such materials.

[0190] FIG. 2B illustrates schematically an example of a system for providing material data related to producible materials by upstream node(s) associated with upstream participant(s) to downstream participant(s) using the materials to produce product(s). Producible material(s) may not yet have been produced by the production but may be producible by one or more production process(es) performed within the production, for example upon request of the downstream participant(s). Producible material(s) may include material(s) planned to be produced, for example based on demand data received from downstream participant(s) (e.g. material consumer(s)). Producible material(s) may include the material(s) described in the context of FIG. 2A.

[0191] For exchanging material data within the participant network illustrated for example in FIG. 1 , digital twins associated with the material 140 may be generated, for example as described in the context of FIG. 2A. The digital twins may include production data related to the production of the material. The production data may include capacity data associated with production capacities of the production producing the material. The capacity data may indicate the amount of material producible by the production within a given time period. The digital twin(s) may be stored in a database, such as material database 202, associated with the data owner, such as material supplier 104. Access to the database may be controlled by the data owner, such as described in the context of FIG. 2A.

[0192] In contrast to FIG. 2A, the data consumer, such as chemical product producer 102, does not request access to the material data based on a material identifier associated with a physical entity of a produced material 140. Instead, the material data related to the producible material is provided by the data owner, such as the material supplier 104, to the data consumer without prior request for such data by the data consumer. This way, material supplier(s) 104 may provide material data via the decentral network to data consumer(s) without requiring a previous request for such data from the data consumer side. The material data may include capacity data related to the production of material(s) by the material supplier 104. The capacity data may define production capacity / ies for production process(es) and / or production step(s) used to produce the material(s). The capacity data may be used by the data consumer(s) to control and / or monitor the production of product(s). For instance, the capacity data may be used to generate control and / or monitoring data for controlling and / or monitoring the production of the product(s).

[0193] Chemical product producer 104 may operate a data processing system processing material data provided by upstream participant(s), such as material supplier 104. The data processing system may be included in backend 206. The data processing system may be associated with backend 206 (not shown in FIG. 2B, see FIG. 6C). Data consuming node 118 may store digital representation(s) associated with the data processing system. The digital representations may include a locator pointing to the data processing system. The digital representations may be used by decentral data providing node(s) to provide material data to such data processing system. The locator may be a URI or a URL of the data processing system. The locator may be a URI or URL of an API of the data processing system. The digital representation may further include a decentral identifier associated with such digital representation. The digital representation may further include access data. The access data may include usage rule data associated with the processing of the material data by the data consumer. The 31 usage rule data may include permission(s) of the data consumer with respect to processing operation(s) performed on the received material data. The permission(s) may be included in the usage rule data. The permission(s) may be included in contract(s) signed by the data consumer. In this case, the usage rule data may include an indication to such contract(s).

[0194] Material supplier 104 may trigger provisioning of material data to chemical product producer 102 by providing a respective indication to backend 216. Backend 216 may be configured to send a request for a data catalog containing a list of digital representations accessible for material supplier 104 to data providing node 116 (see step [1]). Data providing node 116 may be configured to determine respective data consuming node(s) based on data included in the received request, such as the decentral participant identifier. Data providing node 116 may be configured to determine such data consuming node(s) 118 using infrastructure node(s) 210 as described in the context of FIG. 2A. Data providing node 118 may be configured to request the data catalog of data consuming node 118 via the decentral network 134, for example as described in the context of FIG. 4 (see step [2]). The request may include the decentral participant identifier related to data providing node 116, such as the decentral participant identifier of material supplier 104. Data providing node 116 and data consuming node 118 may perform authentication step(s), for example as described in the context of FIG. 2A. Upon successful authentication, data consuming node 118 may generate the data catalog based on the decentral participant identifier, for example as described in the context of FIG. 4. The generated data catalog may be provided to data providing node 116 ( see step [3]). Data providing node 116 may forward the received data catalog to backend 216 (see step [4]). Backend 216 may be configured to parse the received data catalog to determine the digital representation associated with the data processing system. Backend 216 may be configured to determine the digital representation based on data included in the digital representation(s), such as a description included in the digital representation(s). The description may indicate the purpose of the digital representation(s).

[0195] Backend 216 may be configured to provide the determined digital representation including the access data to a policy validation system, for example as described in the context of FIG. 6C. The access data may be validated, for example as described in the context of FIG. 6C and FIG. 10. Upon validation of the access data, data indicating agreement may be received by backend 216. Backend 216 may provide such data indicating agreement (e.g. offer data) to data providing node 116. Data providing node 116 may provide such offer data to data consuming node 118 (see also FIG. 4). Data consuming node 118 may generate agreement data based on the received offer data and may provide the generated agreement data to data providing node 116, for example as described in the context of FIG. 2A and FIG. 4. Data providing node 118 may provide the received agreement data to backend 216. The agreement data may include an agreement identifier and further data, for example as described in the context of FIG. 2A.

[0196] Backend 216 may be configured to extract the endpoint for providing the material data included in the determined digital representation and to generate a request to provide the material data to such determined endpoint. Generating the request may include gathering material data from material database 202 (see step [5]). The material data may be gathered based on metadata included in the material data and matching or being related to data included in the determined digital representation. The request generated by backend 216 may include the material data, the determined endpoint and the agreement identifier included in the agreement data. Backend 216 may provide the request to data providing node 116 (see step [6]). Data providing node 116 may provide the material data, agreement identifier and decentral participant identifier related to such node 116 to data consuming node 118 (see step [7]). Data consuming node 118 may authorize the receipt of 32 such data, for example as described in the context of FIG: 11. Upon successful authorization, data consuming node may provide the received material data to the endpoint of the data processing system (see step [8]).

[0197] By using usage rule data associated with the processing of material data by a data consumer, data provider(s) may check and approve such processing of the material data prior to providing such material data. This way, material data can be processed by data consumers under conditions agreed to by the data provider, avoiding that data consumer performs operations on the material data that are not approved by the data provider. This allows provision of data via the decentral network while ensuring that processing of the provided data is performed in line with usage rule(s) agreed to between data provider and data consumer prior to the data provision. This enables secure sharing and processing of data within the decentral network, allowing to improve the production based on the shared data, for example by reducing bottlenecks in the supply of material(s).

[0198] FIG. 3A illustrates a data model of policy data expressing permissions, prohibitions and duties related to the usage 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 usage of material data and / or product data exchanged within a decentral network, such as decentral network 134 described in the context of FIG. 1.

[0199] The data model may define various classes that allow to express permissions, prohibitions and duties related to the usage 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 304 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 306 may represent any combination of Rules while and ODRL Policy of subclass Offer. The Offer subclass 308 may represent rules that are being offered from assigner Parties to assignee Parties or from assignee parties to assigner parties. An ODRL Policy of subclass Agreement 310 may represent rules that have been granted from an assigner party, such as the data owner of the respective data, to an assignee party, such as the consumer of such data.

[0200] The Asset class 302 may be a resource or a collection of resources that are the subject of a rule. The asset may correspond to a data set, such as material data associated with a given material or product data associated with a given chemical product.

[0201] The Party class 322 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 subproperties such as “assigner” and “assignee”. Assigner may indicate the party that is issuing the rule while assigner may indicate the party that is the recipient the of rule. 231357

[0202] 33 The Action class 320 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.

[0203] The Rule class 312 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 314 may indicate the ability to perform an action on the asset and may inherit all properties from the Rule class 312. The Permission sub-class may have a duty property that indicates an agreed action that must be exercised on the asset as a pre-condition 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 318 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 318 may inherit all properties from the Rule class 312. 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 316 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.

[0204] The Constraint class 324 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 326 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.

[0205] The data model may include property relationships between the classes as illustrated in FIG. 3A. 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. 3A are shown in FIG. 3B.

[0206] By using the data model illustrated in FIG. 3A, policy data associated with a given asset can be generated in a flexible manner, allowing the data owner of the asset to define the permitted and / or prohibited actions over a certain asset, as well as the obligations required to be meet by stakeholders. The permissions, prohibitions and obligations may be limited by constraints (e.g., temporal or spatial constraints) and the data model may allow duties (e.g. payments) to be imposed on permissions. This way, the data owner may be able to flexibly adjust the permissions, prohibitions and / or obligations for different assets and may hence also flexibly control access to such assets by various data consuming nodes within a decentral network, such as network 134 illustrated in FIG. 1. 231357

[0207] 34

[0208] FIG. 3B 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. 30. The asset may correspond to a data set, such as material data associated with a given material or product data associated with a given product, such as a chemical product.

[0209] The asset 302 may be associated with an access policy 334 and / or a contract policy 336. The access policy 334 and / or the contract policy 336 may be generated using the data model illustrated in FIG. 3A. The access policy 334 may define access to the asset, e.g. the material data or a part thereof or the product data or a part thereof. The access policy 334 may define data consumers that are offered access to the asset 302. The access may be defined by defining data consumer(s) allowed to access the asset 302. The data consumer(s) may be defined by associated decentral participant identifier(s), uniquely identifying a participant of a decentral network, such as the decentral network illustrated in FIG. 1. In this example, the “permission” object may express the semantics of the constraint. With reference to FIG. 3A, the object may be a specialization of “rule”, which expresses either a MUST (duty), MAY (permission) or MUST NOT (prohibition) relation. The action may express the type of action for which the rule is intended. With reference to FIG. 3A, the constraint object may express a logical relationship of a key (leftOperand), a value (rightoperand) and an operator.

[0210] The decentral participant identifier associated with a data consumer may be provided by the consumer node associated with such data consumer to a provider node associated with the data provider upon data exchange, for example as described in the context of FIG. 4. The decentral participant identifier may be associated with or may include a verifiable claim or credential. The verifiable claim 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 product ecosystem. For instance, the issuer may make a claim about a participant of the decentral network the decentral participant identifier is associated with. The verifiable claim may include those cl aim (s) as well as proof instructions to prove that claim (s) have not been tampered with and were indeed issued by the claims issuer. The verifiable claim may also include duration information metadata that defines a period of time that the verifiable claim is valid for use or that defines a specific number of times that the verifiable claim is authorized for use. The verifiable claim may also include a DID of the claims issuer and / or the subject, such as a consumer entity. The verifiable claim may be signed by the claims issuer. The claims issuer may provide the verifiable claim to a claims holder, such as the data consumer, for presentation to any relying party that relies upon the veracity of those claims, such as a data provider. The signature of the verifiable claim may be validated with a public key associated with the claims issuer to determine that the customer entity is a trusted entity within the product ecosystem.

[0211] The decentral participant identifiers defined by the access policy 334 may be matched by the provider node to the decentral participant identifier provided by the data consumer to determine whether the data consumer is allowed to access the asset 302. If a data consumer is not allowed to access the asset 302 (e.g. if the provided decentral participant identifier does not match to decentral participant identifiers defined within the access policy 334), the data provider may not provide any policy data associated with such asset (e.g. the catalog provided by the data provider as described in the context of FIG. 4 and FIG. 5A may not contain policy data associated with such asset). Hence, such data consumers would not have a data set indicating the asset ID and associated policy data in the catalog returned by the provider node as described in the context of FIG. 4 and FIG. 5B. This way, data consumers having access to the respective asset 302 can be filtered, hence allowing to securely control access to the asset 302 by multiple decentral data consuming nodes of a decentral network, such as decentral network 134 described in FIG. 1.

[0212] The asset may further be associated with a contract policy 336. The contract policy 336 may determine the conditions for initiating data transactions according to a predefined negotiation protocol (e.g. contract negotiations) for asset 302. If a data consumer fulfils the contract policy 336, it may initiate data transactions according to a negotiation protocol for a particular asset. The contract policy 336 may define usage rule(s) as described in the context of FIG. 5A. This way, usage of the asset, e.g. the material data or product data, may be defined and enforced by the data owner of the asset, such as the material producer or the product producer. The usage rule(s) may be connected by a logical constraint to define a combination of usage rule(s) that must be fulfilled to by the data consumer. As illustrated in this example, the logical constraint defines that two rule(s) must be fulfilled by the data consumer, e.g. the data consumer must be associated with a given decentral participant identifier and the data consumer must have signed a defined contract. The data consumer may provide, upon initiating a data connection with the data provider, a digital credential certifying signature of a defined individual contract between the data consumer and the data provider, such as described in the context of FIG. 4 and FIG. 5A.

[0213] The policy data, such as access policy 334 and / or contract policy 336, may hence be regarded as a container for usage rule data indicating usage rule(s), such as duties, permissions and / or prohibitions. The usage rule data may include one constraint (see example of access policy 334) or multiple constraints (see example of contract policy 336).

[0214] FIG. 30 illustrates an example of a data set linking different policy data to a given asset. The data set may indicate a relationship between the decentral participant identifier and policy data associated with such decentral identifier The asset may correspond to a data set, such as material data associated with a given material or product data associated with a given product. The policy data may include access policy 334 and / or contract policy 336.

[0215] Linking of policy data with an asset may be performed by generating a contract definition 338. The contract definition may be a data set defining identifier(s) of policy data linked to given asset(s) as well as the decentral identifier(s) of such asset(s) (defined by the query expression “assetsSelector”). The contract definition 338 may be used by the provider node to generate the access data (or catalog) upon request of the consumer node as described in the context of FIG. 4.

[0216] By linking different policy data to a given asset, such as asset 302, access to the asset (e.g. material data or product data) may be controlled by the data owner of the asset on a more granular level. This way, the data owner may control access to the asset on different levels, such as a more general level by defining data consumers having access to the asset, and a more specific level by defining further conditions that data consumers must fulfil to receive or gather the asset from the data provider.

[0217] By linking different policy data to a given asset, the data owner of the asset can flexibly control access to the asset without having to generate policy data for each asset. Instead, already existing policy data, such as access policy 334, can be linked to multiple assets of a data owner, hence avoiding generation and storage of multiple instances of the same policy data. This way, the data owner can control access to an asset by different data consumers within a decentral network in a flexible yet secure manner. 36

[0218] FIG. 4 illustrates a sequence diagram of an example data exchange involving policy data associated with a given asset between a decentral data providing node associated with an asset and a decentral data consuming node requesting access to such asset. The asset may correspond to a data set, such as material data associated with a given material or product data associated with a given product. The material may be a raw material, a chemical intermediate, a chemical material, a component, a component assembly, an end product, an end-of-life product or a recycled material. The product may be a chemical intermediate, a chemical product, a component, a component assembly, an end product, an end-of-life product or a recycled material. The data consuming node 118 may be associated with a chemical product producer as illustrated in FIG. 2. The data providing node 116 may be associated with a material supplier 104 as described in the context of FIG. 2. Consuming node 118 and providing node 116 may be part of a decentral network, such as decentral network 134 described in the context of FIG. 1 and FIG. 2. While FIG. 4 illustrates that the data consuming node 118 initiates the sequence, such sequence can likewise be initiated by the data providing node 116, for instance if the data providing node 116 provides data, such as material data associated with material producible by material supplier 104, to data consuming node 118 as described in the context of FIG. 2B.

[0219] Consuming node 118 may request a data catalog from data providing node 116 associated with the data provider, such as material supplier 104. The data catalog may include a collection of digital representations of data, such as material data, accessible for data consuming node 118 at data providing node 116. Consuming node 118 may provide a request for such data catalog to provider node 116. The request may include the decentral identifier associated with the asset and a decentral participant identifier related to the consuming node 118. The decentral participant identifier may be associated with a participant of the decentral network 134 operating the consuming node 118, such as chemical product producer 102. The decentral identifier may be determined by consuming node 118 as described in the context of FIG. 2 based on a physical identifier element attached to the physical entity of the material the decentral identifier is associated with. Including the decentral identifier in the request may allow to restrict the data offer included in the data catalog to the digital representation(s) associated with such decentral identifier. This way, filtering of digital representation(s) included in the provided data catalog can be avoided on the consumer side.

[0220] With reference to FIG. 5A, the request may further include a digital credential 502 or a digital credential presentation certifying signature of an individual agreement or contract between the data consumer and the data provider. The digital credential may be a verifiable credential. The digital credential 502 may include information such as an ID of the digital credential, an identifier associated with the issuer of the digital credential, the date of issuance, the date of expiration of the digital credential and the claims made about the credential subject. The credentialsubject property may include a claim with respect to the contract signed between the data consumer and the data provider. The credentialsubject property may include decentral participant identifier(s), such as a participant's DID and business partner number, of the digital credential holder. The digital credential holder may be the data consumer. The credentialsubject property may further include the contract identifier and the contract version number. The digital credential 502 illustrated in FIG. 5A may allow the data consumer to proof to a third party, such as the data provider, that an agreement covering data exchange between such data consumer and data provider is existing. The use of digital credentials allows the data consumer to showcase or proof that a certain agreement covering data exchange between the data consumer and a data provider is existing and can help to allow 231357

[0221] 37 secure exchange of data, such as material data or product data, within the decentral network.

[0222] The presentation may be a verifiable presentation. A verifiable presentation may be a tamper-evident presentation encoded in such a way that authorship of the data can be trusted after a process of cryptographic verification. The verifiable credential presentation may be generated according to the Verifiable Credentials Data Model v2.0 of W3C (see https: / / www.w3.Org / TR / vc-data-model-2.0 / ).

[0223] Returning to FIG. 4, the data providing node 116 receiving the request may be configured to generate access data. Providing node 116 may generate the access data based on at least a part of the data contained in the received request. Providing node 116 may be configured to generate the access data based on the decentral identifier, the decentral participant identifier and / or the digital credential or verifiable presentation contained in the received request. Providing node 116 may be configured to gather a contract definition data set indicating a relationship between the decentral participant identifier and policy data associated with such decentral identifier (e.g. a contract definition, such as contract definition 338 illustrated in FIG. 30) based on the decentral participant identifier contained in the received request. Provider node 116 may further be configured to gather policy data associated with identifier(s) included in such gathered data set. Policy data may include a data set defining decentral participant identifiers having access to the asset associated with the decentral identifier and / or a data set defining conditions for being entitled to start contract negotiations for such asset. Policy data may include access policy data 334 and / or contract policy data 336 as described in the context of FIG. 3B. Provider node 116 may be configured to map the data contained in the request received from consumer node 118, such as decentral identifier, decentral participant identifier and digital credential, to the gathered policy data. For instance, provider node 116 may match the decentral identifier, the decentral participant identifier and the credentialsubject property included in the digital credential or verifiable presentation to usage rule(s) included in the policy data. If such data can be matched to the usage rule(s) included in the policy data, the provider node 116 may be configured to generate access data (e.g. the catalog) and to provide such access data to the consumer node 118.

[0224] With reference to FIG. 5B, the generated data catalog 504 may include the decentral identifier 506 associated with the asset and policy data 508. The policy data 508 may include an identifier associated with the policy data (e.g. data offer ID in FIG. 5B). This identifier may allow to uniquely identify the policy data on the provider side. The policy data 508 may include usage rule data 510. The usage rule data 510 may define one or more usage rule(s) associated with the usage of the asset by data consumers. The usage rule data 510 may correspond to the usage rule data contained in the gathered policy data (e.g. contained within the contract policy 336). The generated access data may further include an endpoint 512 of the data providing node 116 associated with the asset. The asset may be stored on a dedicated storage associated with the provider node 116, for example as described in the context of FIG. 2.

[0225] Returning to FIG. 4, the provider node 116 may provide the generated data catalog to the requesting consumer node 118.

[0226] The data catalog may be provided to the consumer node 118 along with the decentral participant identifier related to the data providing node 116. 231357

[0227] 38

[0228] With continued reference to FIG. 4 and with further reference to FIG. 2, the consuming node 118 may provide the received data catalog to backend 206. Backend 206 may be configured to validate the access data included in the received data catalog, for example as described in the context of FIG. 6B to FIG. 8. If the access data was successfully validated (e.g. if the policy data fulfils predefined usage rule data and / or usage score(s)), the backend 206 may generate a request to the consumer node 118 to generate a contract offer data set indicating a data offer or contract offer for the asset associated with the decentral identifier. Based on such request, the consumer node 118 may be configured to generate the contract offer data set. The consumer node 118 may be configured to generate the contract offer data set 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 consumer node 118 may be configured to generate the contract offer data set according to the data model described in the context of FIG. 3A.

[0229] With reference to FIG. 5C, the contract offer data set 514 may include the validated usage rule data 516. The validated usage rule data 516 may include the usage rule data contained in the access data provided by the providing node 116. The contract offer data set may further include the decentral identifier associated with the asset (e.g. ASSET-ID) and the identifier associated with the policy data (e.g. DATA OFFER-ID). The contract offer data set may further include an offer identifier associated with such data set as well as the decentral participant identifiers associated with the data provider and the data consumer.

[0230] Returning to FIG. 4, the consumer node 118 may provide the generated contract offer data set to provider node 116. Provider node 116 may validate the received contract offer data set. Validation may include comparing the policy data 516 included in the contract offer data set with the policy data associated with the asset. For this purpose, the contract definition data set associated with the decentral identifier included in the received contract offer data set may be gathered as previously described. Based on such contract definition data set, policy data may be gathered based on identifiers included in the contract definition data set as previously described. The gathered policy data may be matched to policy data 516 included in the received contract offer data set. Upon successful validation of the received contract offer data set (e.g. upon determining that the policy data 516 included in the contract offer data set matches at least a part of the gathered policy data, such as the contract policy data 336), providing node 116 may be configured to generate agreement data indicating an agreement on the policy data associated with the asset.

[0231] With reference to FIG. 5D, the agreement data 518 may include an agreement identifier and the decentral identifier associated with the asset. The agreement data 518 may further include the usage rule data 520 included in the contract offer data set 514, the decentral participant identifiers related to the data provider 116 and data consumer 118 and the signing date of the agreement.

[0232] Returning to FIG. 4, the data provider 116 may provide the agreement data to consumer node 118. Consumer node 118 may verify the agreement data. Verification of the agreement data may include comparing or matching the decentral identifier as well as the contract offer data set identifier and the policy data included in the agreement data to the decentral identifier, the contract offer data set identifier and the policy data included in the generated contract offer data set. The agreement data may be verified if the respective compared data matches. Upon verification of the agreement data, the consumer node 118 231357

[0233] 39 may be configured to provide verification data to the provider node 116. The verification data may indicate agreement of the data consumer with the agreement data provided by the data provider. After receiving the verification of the agreement data, the negotiation process may be completed and an electronic agreement with respect to the asset associated with the agreement data has been negotiated. Consumer node 118 may be configured to provide the agreement identifier to backend 206. Backend 206 may store the agreement identifier in association with the decentral identifier. This may allow to avoid repeated negotiations upon repeated access to the respective asset (e.g. material data or product data).

[0234] Consumer node 118 may be configured to request the material data (e.g. asset) from provider node 118, for example as described in the context of FIG. 2. The request may include the decentral identifier associated with the material data and the agreement identifier.

[0235] FIG. 6A and FIG. 6B illustrate examples of a production producing one or more product(s) from one or more material(s) in connection with an operating system including a policy data verification system. The production may be a chemical production 604. The product(s) may be chemical product(s) 602.

[0236] For producing one or more chemical product(s) 602 different materials (feedstocks) 212 may be provided as physical inputs from material providers or suppliers 104 (see also FIG. 1 and FIG. 2). The chemical products 602 produced from the materials 140 may be supplied to chemical product consumer 106, for example as described in the context of FIG. 1. The chemical production 604 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 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.

[0237] The chemical production 604 may chemically convert materials 140 via chemical intermediates to one or more chemical product(s) 602 that exit the chemical production 604. The chemical production 604 may convert material(s) 140 by way of chemical conversion to one or more chemical product(s).

[0238] The material(s) 140 may be fed into the chemical production 604 at any entry point. The material(s) 140 may be fed into the chemical production 604 at the start of the chemical production 604. Materials 140 may be provided to chemical production 606 at the feed-in-point 612. After they are delivered to chemical production 604, the materials 140 may be stored into material storage(s), such as tanks, as they enter the chemical production process. Materials may for example be consumed from the tank by of the plant performing the first production step of the production chain associated with the chemical 231357

[0239] 40 product. The materials may include raw materials. The materials may include chemical intermediate products. The materials may include recycled materials.

[0240] The chemical production 604 may produce the chemical product 602 via multiple production steps. The production steps may be defined by the system boundary of the chemical production 604. The system boundary may be defined by location or control over production processes. The system boundary may be defined by the site of the chemical production 604. The system boundary may be defined by production processes controlled by one entity or multiple entities jointly. The system boundary may be defined by a value chain with staggered production processes to an end product, which may be controlled by multiple entities separately. The chemical production 604 may include a waste collection and sorting step, a recycling step such as pyrolysis, a cracking step such as steam cracking, a chemical reaction step, a separation step to separate outputs of one process step and further processing steps to convert such outputs to a chemical products leaving the system boundary of the chemical production 604.

[0241] Chemical products 602 produced by chemical production 604 may be stored in chemical product storage(s), such as tanks, prior to providing such produced chemical products 602 to the feed-out-point 614. At the feed-out-point 614, the produced chemical products 602 may be provided to one or more chemical product consumers 108 (not shown, see for example FIG. 1). The chemical product consumers 108 may use the supplied chemical products 602 to produce further chemical products or discrete products.

[0242] The operating system 606 of the chemical production 604 may be a digital operating system. Operating system 606 may be configured to monitor and / or control the chemical production 604 based on operating parameters of the different processes. One process step monitored and / or controlled may be the feed of materials or the discharge of chemical products. Another process step monitored and / or controlled may be the validation of policy data associated with material data associated with such materials, for example as described in the context of FIG. 7A to FIG. 8. Operating system 606 may be configured to collect, store, manage and interpret a wide range of production and / or business data for chemical production 604. Operating system 606 may be part of an Enterprise Resource Planning (ERP) system. Alternatively, operating system 606 may be partly implemented in an ERP system and partly implemented in one or more additional systems coupled with an ERP system. Operating system 606 may also be implemented in one or more systems outside of an ERP system.

[0243] With reference to FIG. 6B, materials 140 may comprise a physical identifier element as described in the context of FIG. 2. The physical identifier element may be scanned by code reader 214 to determine the material identifier(s) (denoted as ID1, ID2 in FIG. 6B), for example as described in the context of FIG. 2. With further reference to FIG. 7A and FIG. 7B, the determined material identifier(s) may be used by backend 206 to request access to material data associated with such material identifier(s) via decentral data consuming network node 118 associated with operating system 606, for example as described in the context of FIG. 2 and FIG. 4 (see also operation 702 of FIG. 7A, FIG. 7B). The access may be requested at provider nodes 116a, 116b associated with material producers producing the respective materials. Provider nodes 116a, 116b may return access data including policy data associated with the respective material data, for example as described in the context of FIG. 4 and FIG. 5B. The received policy data 508 may include usage rule data 510. The usage rule data 510 may define one or more usage rule(s). The usage rule data may define one or more action(s) which are allowed and / or 231357

[0244] 41 prohibited by the data consumer and / or obligations that need to be fulfilled by the data consumer, for example as described in the context of FIG. 3A. Backend 206 may provide the received policy data to policy data validation system 616 for validation of the received policy data.

[0245] In one embodiment and with reference to FIG. 7A, policy data validation system 616 may include a rule-based engine 704. The rule-based engine 704 may operate on individual data point(s) included in the policy data, multiple data point(s) included in the policy data and / or the whole policy data. The rule-based engine 704 may operate on each policy data individually. This allows to validate each policy data individually, hence allowing a more granular validation of the policy data associated with the material data and hence also the material. Rule-based engine 704 may receive a request to validate obtained policy data. The request may include the access data received from provider nodes 116a, 116b. The request may include the policy data included in the received access data. In response to the request, rule-based engine 704 may be configured to initiate validation of the received policy data (see operation 706). Rule-based engine 704 may be configured to determine decentral participant identifier(s) associated with the policy data. For instance, rule-based engine 704 may parse the received policy data to determine the decentral participant identifier(s). Rule-based engine 704 may generate a request for rule(s) to obtain one or more rule(s) from rule DB 708. The request may contain the determined decentral participant identifier(s). Rule DB 708 may store one or more rule(s). The one or more rule(s) may include instruction(s) for validating the policy data. The one or more rule(s) may define instruction(s) to match at least a part of the policy data, such as one or more usage rule data 510 included in the policy data, to predefined usage rule data, such as usage rule data stored in policy DB 712. The one or more rule(s) may include instruction(s) to gather predefined usage rule data from a database, such as policy DB 712, and to match at least a part of the policy data to the gathered predefined usage rule data. Predefined usage rule data may include allowable usage rule data and / or data associated with agreements signed by the data consumer and one or more third party / ies, such as upstream and / or downstream participant(s) of the decentral network (see FIG. 1). Data 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. In response to the request, one or more rule(s) may be provided from rule DB 708 to rule-based engine 704. Predefined usage rule data included in policy DB 712 may be updated in response to receiving updated predefined usage rule data, for example from a device in communication with policy data validation system 616. Updated usage rule data may be provided to policy data validation system 616 via a graphical user interface associated with or included in the device. This way, it can be ensured that only acceptable usage rule(s) are used for validation of the policy data, hence allowing accurate and reliable validation of the received policy data based on the usage rule data stored in policy DB 712.

[0246] Rule-based engine 704 may be configured to apply the received rule(s) to at least a part of the policy data to be validated (see operation 710) to validate the policy data. 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) applied by rule-based engine 704 are fulfilled. Policy data may be considered acceptable if the usage rule data, such as usage rule data 510, included in such policy data, such as policy data 508, match predefined usage rule data stored in policy DB 712. Applying the rule(s) to the policy data may include comparing the predefined usage rule data to individual data point(s) present within the policy data to be validated to determine whether individual data point(s) within the policy data match data points present within predefined usage rule data. Applying the rule(s) to the policy data may include comparing data point combination(s) of predefined usage 231357

[0247] 42 rule data to data point combination(s) present within the policy data to be validated to determine whether the policy data contains unacceptable usage rule(s). Applying the rule(s) to the policy data may include comparing the predefined usage rule data to the whole policy data to be validated to determine whether the policy data contains unacceptable usage rule(s). Operations performed by rule-based engine 704 may be determined by rule(s) gathered from rule DB 708. For instance, rule(s) gathered from rule DB 708 may determine whether rule-based engine 704 operates on individual data point(s) and / or multiple data point(s) and / or the whole policy data.

[0248] Rule-based engine 704 may be configured to determine whether the policy data to be validated is acceptable (see operation 714). If at least a part of the usage rule data included in the received policy data is not validated, rule-based engine 704 may proceed to operation 716. In operation 716, rule-based engine 704 may generate message data indicating that at least part of the policy data could not be validated. Non-validation may occur, for example, if unknown policy data is provided for the first time to the rule-based engine 704. The message data may include an indication which usage rule data of which policy data could not be validated. The message data may further include reason(s) associated with the non-validation. The message data may be provided to a display device configured to display data received from rule-based engine 704. The display device may comprise a graphical user interface 720. The display device may display the message 718 in response to receiving message data from rule-based engine 704. The message may include the non-validated usage rule(s). The message may further include a reason for the non-validation. This allows to trigger checking of usage rule(s) identified as unacceptable by rule-based engine 704. Checking may be performed by a user. Checking may include checking the usage rule(s) by a user. Checking may include providing the non-validated usage rule data to a data driven model trained on historical policy. The historical policy data may include policy data deemed acceptable by the data consumer. The trained data driven model may include a classifier model trained to classify the non-validated usage data into “acceptable” or “non- acceptable”. Such classification may be based on acceptable policy data used for training the model. The classification outputted by the model may be revised by a user. If the user deems non-validated the usage rule data acceptable, the user may update the policy DB 712, for example by providing updated usage rule data, to policy DB 712. Policy DB 712 may be configured to update stored usage rule data in response to receiving updated usage rule data. This way, identification of unacceptable usage rule(s) by rule-based engine 704 may trigger checking of such usage rule(s) and optionally updating of usage rule data associated with such usage rule(s) within policy DB 712. After updating the usage rule data in policy DB 712, rule-based engine 704 may receive a request to initiate re-validation of the policy data. This way, the policy data can be validated using updated usage rule data stored in policy DB 712. In addition or alternatively to operation 716, rule-based engine 704 may be configured to provide an indication that at least a part of the received policy data is not validated to backend 206. Such indication may include the decentral participant identifier related to the policy data (e.g. the decentral participant identifier associated with the provider node providing the policy data) and data associated with the non-validated usage rule data. Data associated with the non-validated usage rule data may include the non-validated usage rule data and a respective reason for non-validation. Backend 206 may be configured to generate decline data (see operation 722) in response to receiving such indication from rule-based engine 704. Decline data may include the decentral participant identifier related to the respective policy data and an indication of declining the policy data associated with the decentral identifier. The indication may include a reason for declining the policy data. Backend 206 may be configured to provide the generated decline data to consumer node 118. Consumer node 118 may provide the decline data to respective provider node(s) 116a, 116b. Consumer node 118 may be configured to determine respective provider node(s) 116a, 116b based on 231357

[0249] 43 the decentral participant identifier included in the decline data. Respective provider node(s) 116a, 116b may terminate contract negotiations with consumer node 118 upon receipt of such decline data and may not provide any material data to consumer node 118 after receipt of such decline data.

[0250] With reference to FIG. 7C, rule-based engine 704 may be configured to provide an indication that the usage rule data included in the received policy data is / are validated to backend 206 if such usage rule data has been successfully validated by rule-based engine 704. Such indication may include the decentral identifier associated with the input material the policy data is related to and validated usage rule data. Backend 206 may be configured to generate acceptance data (see operation 724) in response to receiving such indication from rule-based engine 704. Acceptance data may include a decentral identifier of the acceptance data, decentral participant identifiers of the consumer node and the provider node providing the asset associated with the validated policy data, and the validated usage rule data. An example of acceptance data generated by backend 206 is illustrated in FIG. 5C. Backend 206 may be configured to provide the generated acceptance data to consumer node 118. Consumer node 118 may provide the acceptance data to respective provider node(s) 116a, 116b. Consumer node 118 may be configured to determine respective provider node(s) 116a, 116b based on the decentral participant identifier included in the acceptance data. In response to receiving acceptance data, respective provider nodes, such as nodes 116a, 116b, may validate the acceptance data and may generate agreement data based on the validated acceptance data, for example as described in the context of FIG. 4. The agreement data may include an agreement identifier, the decentral identifier associated with the asset (e.g. material data) and the validated usage data included in the acceptance data. The agreement data may further include a signing date and time, the decentral participant identifier(s) of the provider and consumer node or a combination thereof. An example of agreement data generated by the provider node(s) is illustrated in FIG. 5D. Provider node(s) may provide the generated agreement data to consumer node 118. Consumer node 118 may provide the agreement data to backend 206. Backend 206 may verify the agreement data, for example as described in the context of FIG. 4, and may store the verified agreement data in agreement DB 726. Backend 206 may be configured to provide an indication of verification of the agreement data to respective provider node(s), for example as described in the context of FIG. 4. Backend 206 may be configured to trigger gathering of material data (see operation 728). Gathering of material data may be triggered upon verification of the received agreement data. Gathering of material data may be triggered by generating a request to gather material data. The request may include the agreement identifier associated with the agreement data related to the material data and the decentral identifier associated with the respective material data. The request may further include the decentral participant identifier of the respective provider node. The request may be provided to consumer node 118. Consumer node 118 may be configured to request or gather material data from respective provider node(s), such as provider node(s) 116a, 116b, for example as described in the context of FIG. 2A. The material data received or gathered by consumer node 118 may be provided by consumer node 118 to backend 206. Backend 206 may be configured to store such material data in database 620.

[0251] In another embodiment and with reference to FIG. 6B and FIG. 7B, policy data validation system 616 may validate at least part of the policy data using at least one trained data driven model 730. The data-driven model(s) may be trained as described in the context of FIG. 9. The data-driven model(s) may be stored on a data storage (not shown) associated with policy data validation system 616 and may be gathered by policy data validation system 616 upon verifying at least part of 231357

[0252] 44 the policy data in operation 706.

[0253] The policy data may be obtained in operation 702 as described in the context of FIG. 7A above using the material identifier(s) associated with received material(s). At least part of the policy data obtained in operation 702 may be validated using at least one trained data driven model 730 in operation 726. For this purpose, the policy data to be validated may be provided as input to at least one trained data driven model 730. The at least one trained data driven model 730 may include a classifier model classifying the input into “acceptable” and “not acceptable” or into “validated” and “non-validated”. The input may be classified into “acceptable” or “not acceptable” or into “validated” and “non-validated” based on acceptability score(s) determined by the model. The classification may be used in operation 714 to determine whether the policy data to be validated is acceptable or not. Policy data validation system 616 may provide an indication of successful validation to backend 206 responsive to the policy data being validated, for example as described in the context of FIG. 7C. If at least a part of the received policy data, e.g. usage rule data included in the received policy data, is not verified, policy data validation system 616 may proceed to operation 716 and / or may generate an indication of non-validation of usage rule data as described in the context of FIG. 7A.By using a rule-based engine or a trained data-driven model, the acceptability of usage rule(s) associated with the usage of material data or product data gathered via a decentral network from respective provider nodes may be reliably validated. This allows ensure that only acceptable policy data (e.g. policy data including usage rule data matching predefined usage rule data or determined to be acceptable by the trained data-driven model) is agreed upon prior to transfer of any data, hence avoiding that policy data is accepted by users that do not have the legal power to accept or approve such policy data. This way, it can be ensured that applications can only gather data from the decentral network after ensuring the associated policy data is acceptable, e.g. matches predefined usage rule data, avoiding that users of such application enter into legally binding agreements without having the respective power to sign such agreements on behalf of the respective entity the user is associated with, giving rise to doubts with respect to the validity of such agreements and hence reducing the trust of the data provider that the usage rule(s) defined in such agreement are legally binding. By validating the policy data against a set of predefined usage rule(s), it can be ensured that electronic contracts are only generated based on acceptable policy data governing the transfer and use of material data or product data, hence improving the trust of the data providers within the decentral network and ensuring that usage rule(s) stipulated in such agreements are adhered to by the consumer side when using the provided data.

[0254] FIG. 6C illustrates an example of a production producing material(s) from one or more input(s) in connection with an operating system including a policy data validation system.

[0255] For producing one or more material(s) 140 different input(s) (raw material(s)) 622 may be provided as physical inputs from raw material providers or suppliers. The materials 140 produced from the input(s) 622 may be supplied to chemical product producers 102, for example as described in the context of FIG. 1. The chemical production 624 may be a chemical production network as described in the context of FIG: 6A and FIG. 6B. The chemical production 624 may chemically convert input(s) 622 via chemical intermediates to one or more material(s) 140 that exit the chemical production 624. The chemical production 624 may convert input(s) 622 by way of chemical conversion to one or more material(s) 140. 231357

[0256] 45

[0257] The input(s) 622 may be fed into the chemical production 624 at any entry point, for example as described in the context of FIG. 6A and FIG. 6B. After they are delivered to chemical production 624, the input(s) 622 may be stored into material storage(s), such as tanks, as they enter the chemical production process. Inputs may for example be consumed from the tank by of the plant performing the first production step of the production chain associated with the material 140. The inputs may include raw materials, such as virgin material(s) and / or recycled material(s).

[0258] The chemical production 624 may produce the material 140 via multiple production steps. The production steps may be defined by the system boundary of the chemical production 624, for example as described in the context of FIG. 6A and FIG. 6B. The chemical production 624 may include a cracking step such as steam cracking, a chemical reaction step, a separation step to separate outputs of one process step and further processing steps to convert such outputs to a materials leaving the system boundary of the chemical production 624.

[0259] Materials 140 produced by chemical production 624 may be stored in material storage(s), such as tanks, prior to providing such produced materials 140 to the feed-out-point 628. At the feed-out-point 628, the produced materials 140 may be provided to one or more chemical product producer(s) 102 (not shown, see for example FIG. 1). The chemical product producer(s) 102 may use the supplied materials 140 to produce chemical products 602 (see for example FIG. 6A, FIG. 6B).

[0260] The operating system 630 of the chemical production 624 may be a digital operating system. Operating system 630 may be configured to monitor and / or control the chemical production 624 based on operating parameters of the different processes. One process step monitored and / or controlled may be the feed of inputs or the discharge of materials. Another process step monitored and / or controlled may be the validation of policy data associated with the processing of material data associated with materials producible by the chemical production 624 by data consumer(s), such as chemical product producer(s) 104, for example as described in the context of FIG. 10. Operating system 630 may be configured to collect, store, manage and interpret a wide range of production and / or business data for chemical production 624. Operating system 630 may be part of an Enterprise Resource Planning (ERP) system. Alternatively, operating system 630 may be partly implemented in an ERP system and partly implemented in one or more additional systems coupled with an ERP system. Operating system 630 may also be implemented in one or more systems outside of an ERP system.

[0261] With reference to FIG. 2B, material supplier 104 operating chemical production 624 may provide material data, such as capacity data defining production capacity / ies for material 140 producible by chemical production 624 for one or more given time period(s), to chemical product producer 102 operating chemical production 608 (see FIG. 6A, FIG. 6B). Capacity data may be stored within database 636 storing production data associated with the production of materials 140 by chemical production 624. Capacity data may be generated from the production data at one or more given time points. Capacity data stored in database 636 may be updated based on the production data. After generation of capacity data and / or after updating of existing capacity data, backend 216 may be triggered to provide such capacity data to downstream participant(s), such as chemical product producer(s) 102.

[0262] Backend 216 may be configured to provide a request for a data catalog to node 118, for example as described in the context of FIG. 2B and FIG. 4. Node 118 may request the data catalog from node(s) 116, such as node(s) 116a, 116b, associated 231357

[0263] 46 with the downstream participant(s). Node(s) 116 may provide a list of digital representation(s) (e.g. the data catalog) associated with material data accessible at such node(s) and / or associated with data processing system(s) processing provided material data. The digital representation(s) may include access data. The digital representation(s) associated with data processing system(s) processing provided material data may further include a locator or pointer to the data processing system(s). The access data may include policy data associated with the respective material data or the processing of the material data, for example as described in the context of FIG. 2B, FIG. 4 and FIG. 5B. The received policy data 508 may include usage rule data 510. The usage rule data 510 may define one or more usage rule(s). The usage rule data may define one or more data processing operation(s) which are allowed and / or prohibited by the data processor and / or obligations that need to be fulfilled by the data processor, for example as described in the context of FIG. 3A. The usage rule data may include data related to contract(s) including regulation(s) defining permissions, prohibitions and / or obligations with respect to processing of received material data. The contract(s) may be valid contract(s) signed by the data processor (e.g. the downstream participant of material supplier 104). Backend 216 may provide the received policy data to policy data validation system 616 for validation of the received policy data as described in the context of FIG. 7A and FIG. 7B.

[0264] Rule-based engine 704 of policy validation system 616 may be configured to provide an indication that the usage rule data included in the received policy data is / are validated to backend 216 if such usage rule data has been successfully validated by rule-based engine 704, for example as described in the context of FIG. 7C. Backend 216 may be configured to generate acceptance data (see operation 724) in response to receiving such indication from rule-based engine 704, for example as described in the context of FIG. 7C. Backend 216 may be configured to provide the generated acceptance data to node 118. Node 118 may provide the acceptance data to respective node(s) 116a, 116b. In response to receiving acceptance data, respective provider nodes, such as nodes 116a, 116b, may validate the acceptance data and may generate agreement data based on the validated acceptance data, for example as described in the context of FIG. 2B, FIG. 4 and FIG. 7C. Node(s) 116a, 116b may provide the generated agreement data to node 118. Node 118 may provide the agreement data to backend 216. Backend 216 may verify the agreement data, for example as described in the context of FIG. 4, and may store the verified agreement data. Backend 216 may be configured to provide an indication of verification of the agreement data to respective provider node(s), for example as described in the context of FIG. 4.

[0265] Backend 216 may be configured to trigger providing of material data, for example as described in the context of FIG. 2B. Providing of material data may be triggered upon verification of the received agreement data. Backend 216 may be configured to generate a request to provide the material data. The request may include the agreement identifier associated with the agreement data and the material data. The request may be provided to node 118. Node 118 may be configured to provide the material data to respective node(s), such as consumer node(s) 116a, 116b, for example as described in the context of FIG. 2B. The material data received by consumer node(s) 116a, 116b may be used by downstream participant(s) associated with such consumer node(s) to control the production of product(s) produced from material(s) related to such material data.

[0266] By using a rule-based engine or a trained data-driven model, the acceptability of usage rule(s) associated with the processing of material data by downstream participant(s) may be reliably validated prior to providing any material data to such downstream participant(s). This allows ensure that only acceptable policy data (e.g. policy data including usage rule 231357

[0267] 47 data matching predefined usage rule data or determined to be acceptable by the trained data-driven model) is agreed upon prior to transfer of any data, hence avoiding that the provided material data is processed without consent of the data provider. This way, material data can be processed by data consumers under conditions agreed to by the data provider, avoiding that data consumer performs operations on the material data that are not approved by the data provider. This allows provision of data via the decentral network while ensuring that processing of the provided data is performed in line with usage rule(s) agreed to between data provider and data consumer prior to the data provision. This enables secure sharing and processing of data within the decentral network, allowing to improve the production based on the shared data, for example by reducing bottlenecks in the supply of material(s).

[0268] FIG. 8 illustrates a flow chart of an example method for validating access data including usage rule data associated with the usage of material data by a data consumer. The material data may be associated with material(s) used to produce a product by a production. Material(s) may include raw material(s), chemical intermediate material(s), chemical material(s), part(s), component(s), component assembly / ies, end product(s), end-of-life product(s) or recycled material(s). The production may be a chemical production as described in the context of FIG. 6A and FIG. 6B. The material data may be accessed by the data consumer via a decentral data consuming node at a decentral data providing node associated with the data owner of the material data, for example as described in the context of FIG. 2A.

[0269] Decentral material identifier(s) associated with the material(s) may be provided. The decentral material identifier(s) may be digital identifier(s), e.g. the decentral identifier may not correspond to an identifier physically attached to the respective material. The decentral identifier(s) may be associated with digital material identifier(s). The digital material identifier(s) and / or the decentral material identifier(s) may be assigned to a physical identifier connected to the material. The connection of the physical identifier with the respective material may be provided by means of physical connection to the physical material or physical entity. For instance, the physical identifier may be connected with the physical entity of the respective material. The physical identifier may have one-to-one correspondence to a virtual identity or to a physical identity by means of a physical connection to the physical entity. The physical identifier may be physically attached to the material via an identifier element. Physical identifier or physical identifier element may refer to any virtual or physical arrangement that associates the decentral material identifier or the digital material identifier with the respective material. The physical identifier may be any identifier for the produced material, such as a batch number or a part number. The physical identifier element may comprise a passive or active element, e.g. QR-code, RFID-tag, but is not limited thereto. The physical identifier element may be a physical identifier physically connected to the chemical product. The identifier element may include markers embedded in materials, a bar code, a QR-Code, a tag like a RFID tag or similar physical arrangement that allows to digitally identify the material.

[0270] The decentral material identifier(s) may be provided from a sensor reading an identifier element physically connected to the respective material. The decentral material identifier(s) may be provided based on digital material identifier(s), for example as described in the context of FIG. 2A, FIG. 6A and FIG. 6B. The digital material identifier(s) may be provided from a sensor reading an identifier element physically connected to the respective material. The digital material identifier(s) may be selected from an material name, an material number, a LOT number, a batch number, a serial number, an identification 231357

[0271] 48 number or a combination thereof.

[0272] Access data associated with the material data may be provided based on the decentral material identifier(s). Access data may include the decentral material identifier associated with the respective material and policy data, for example as described in the context of FIG. 4 and FIG. 5B. The policy data, such as policy data 508, may include a policy identifier and usage rule data, such as usage rule data 510. The usage rule data may define one or more usage rule(s). The one or more usage rule(s) may define permissions, prohibitions and / or obligations of the data consumer with respect to the material data associated with the decentral material identifier, for example as described in the context of FIG. 3A to FIG. 5B. Permissions may define actions the data consumer is allowed to perform on the material data. Prohibitions may define actions the data consumer is not allowed to perform on the material data. Obligations may define actions the data consumer must fulfil before being allowed to perform any permissions on the material data. By using access data, the data owner, such as the material data owner, can define the scope of actions, the data consumer is allowed to perform on the material data, hence allowing for secure yet reliable sharing of material data with data consumers consuming material associated with such material data while preventing unauthorized access to such data by other participants of the decentral network.

[0273] At least a part of the access data may be validated using a rule-based engine including one or more usage rule(s) or using a data-driven model trained on historical data sets including policy data and acceptability scores. Validation may include validating at least a part of the policy data included in the access data. Validation may include validating at least a part of the usage rule data included in the policy data. The rule-based engine may operate on individual data points included in the access data or policy data, a combination of data points included in the access data or policy data or the whole access data or policy data, for example as described in the context of FIG. 6A to FIG. 7A. Validating at least a part of the access data may include determining the acceptability of such access data. Access data may be considered acceptable if one or more rule(s) applied by the rule-based engine are fulfilled. Access data may be considered acceptable if the usage rule data included in such access data match predefined usage rule data. Validating at least a part of the access data may include applying one or more rule(s), such as rule(s) stored in a database, to at least a part of the access data, such as the usage rule data included in the access data. Applying the rule(s) to the access data or a part thereof may include comparing the predefined usage rule data to individual data point(s) present within the access data to be verified to determine whether individual data point(s) within the policy data match data points present within predefined usage rule data. Applying the rule(s) to the access data or a part thereof may include comparing data point combination(s) of predefined usage rule data to data point combination(s) present within the access data to be verified to determine whether the access data contains unacceptable usage rule(s). Applying the rule(s) to the access data or a part thereof may include comparing the predefined usage rule data to the whole access data or policy data to be verified to determine whether the access data or policy contains unacceptable usage rule(s). Operations performed by the rule-based engine may be determined by rule(s) gathered from a database storing such rule(s). For instance, gathered rule(s) may determine whether the rule-based engine operates on individual data point(s) and / or multiple data point(s) and / or the whole policy data. The rule-based engine may operate on the access data or a part thereof as described in the context of FIG. 6A to FIG. 7A. The data-driven model may validate at least a part of the access data as described in the context of FIG. 6A to FIG. 7B. The data-driven model may include a classifier model classifying the input, e.g. at least a part of the access data, into “acceptable” and “not acceptable”. The input may be classified into “acceptable” or “not acceptable” based on acceptability score(s) determined by the model. The data- 231357

[0274] 49 driven model may be trained as described in the context of FIG. 12.

[0275] It may be determined whether at least a part of the access data is validated. If at least a part of the access data, such as usage rule data, is not validated, message data may be generated. The message data may indicate the access data that could not be validated. The message data may indicate the policy data and / or usage rule data that could not be validated. Non-validation may occur, for example, if access data is provided for the first time to the rule-based engine. The message data may include an indication which usage rule data of which policy data could not be validated. The message data may further include reason(s) associated with the non-validation. The generated message data may be provided. The generated message data may be provided to a display device configured to display data. This allows to trigger checking of nonvalidated usage rule(s), for example as described in the context of FIG. 6A to FIG. 7A. Non-validated policy data may be persisted in a database. Persisting the non-validated policy data in the database may be triggered by a user. Persisting may be triggered after checking the non-validated policy data. Persisting may include updating existing data stored within the database. Persisting may include storing the policy data or a part thereof as a new data entry in the database. This way, non-validation of access data may trigger checking of such access data and optionally persisting of a part of such access data, such as policy data included in such access data. After persisting policy data or a part thereof in the database, validation of at least a part of the access data may be initiated. This way, the access data or a part thereof can be validated using updated data stored in the database.

[0276] If at last a part of the access data, such as policy data and / or usage rule data included therein, is validated, data indicating acceptance of access data may be generated. Data indicating acceptance of access data may include a decentral identifier of the acceptance data, decentral participant identifiers of the consumer node and the provider node providing the asset associated with the validated policy data, and the validated usage rule data. An example of such data is illustrated in FIG. 50. The generated data indicating acceptance of access data may be provided. In response to providing such data, agreement data may be received, for example as described in the context of FIG. 4 and FIG. 6A to FIG. 70. The agreement data may include an agreement identifier, the decentral identifier associated with the asset (e.g. material data) and the validated usage data included in the acceptance data. The agreement data may further include a signing date and time, the decentral participant identifier(s) of the provider and consumer node or a combination thereof. An example of received agreement data is illustrated in FIG. 5D. The received agreement data may be verified, for example as described in the context of FIG. 4 and FIG. 6A to FIG. 70. Material data may be gathered based on the agreement data. The material data may be gathered based on the agreement identifier included in the agreement data related to the material data and the decentral identifier associated with the respective material data. The gathered material data may be provided. Providing the gathered material data may include storing the provided material data within a database, for example as described in the context of FIG. 6A to FIG. 70.

[0277] By using a rule-based engine or a trained data-driven model, the acceptability of usage rule(s) associated with the usage of material data or product data gathered via a decentral network from respective provider nodes may be reliably validated. This allows ensure that only acceptable policy data (e.g. policy data including usage rule data matching predefined usage rule data or determined to be acceptable by the trained data-driven model) is agreed upon prior to transfer of any data, hence avoiding that policy data is accepted by users that do not have the legal power to accept or approve such policy data. 231357

[0278] 50

[0279] This way, it can be ensured that applications can only gather data from the decentral network after ensuring the associated policy data is acceptable, e.g. matches predefined usage rule data, avoiding that users of such application enter into legally binding agreements without having the respective power to sign such agreements on behalf of the respective entity the user is associated with, giving rise to doubts with respect to the validity of such agreements and hence reducing the trust of the data provider that the usage rule(s) defined in such agreement are legally binding. By validating the policy data against a set of predefined usage rule(s), it can be ensured that only acceptable policy data is used to generate legally binding agreements governing the transfer and use of material data or product data, hence improving the trust of the data providers within the decentral network and ensuring that usage rule(s) stipulated in such agreements are adhered to by the consumer side when using the provided data.

[0280] FIG. 9 illustrates a flow chart of an example method for providing material data associated with produced material(s) via a decentral network to a data consumer for controlling the production of product(s) based on the material data. The material data may be associated with material(s). The material(s) may include raw material(s), chemical intermediate material(s), chemical material(s), part(s), component(s), component assembly / ies, end product(s), end-of-life product(s) or recycled material(s). The production may be a chemical production, for example as described in the context of FIG. 6A and FIG. 6B. The product(s) may be product(s) described in the context of FIG. 2A. The decentral network may be decentral network 136 described in the context of FIG. 1 .

[0281] With reference to FIG. 2A, a material data owner, such as material supplier 104, may receive a request to access the material data by a data consumer via the decentral network. The request may be received at the decentral data providing node associated with the data owner. The material data may be stored in a database associated with the decentral data providing node. The material data may be stored in a database for access by data consumer(s). Access to the database may be controlled by the data owner, for example as described in the context of FIG. 2A. The data consumer may be a downstream participant of the product ecosystem, such as the chemical product producer 102 (see also FIG. 1). The request may include decentral material identifier(s) associated with the material and agreement data. The decentral material identifier(s) may be associated with or linked to the material data. The decentral material identifier(s) may be associated with a digital representation for accessing the material data. The digital representation may include a representation pointing to the database storing the material data. The representation may include a URI or URL of the database and / or the decentral data providing node associated with the database. The digital representation may be stored in a decentral registry, such as registry 204 described in the context of FIG. 2A.

[0282] The request may further include the decentral participant identifier associated with the downstream participant requesting access to the material data. The agreement data may be generated as described in the context of FIG. 7C and FIG. 8. The decentral material identifier(s) may be linked to the material data. The agreement data may include the agreement identifier associated with the respective agreement data. The agreement data may indicate an agreement between data provider and data consumer on usage rule data associated with the material data. The usage rule data may define permission(s), prohibition(s) and / or obligation(s) of the data consumer with respect to the usage of the consumed material data. 231357

[0283] 51

[0284] The received request may be authorized based on the decentral material identifier(s) and the agreement data. Authorizing the request may include validating the agreement data. Validating the agreement data may include comparing the agreement data to existing agreement data. The existing agreement data may be stored in a database. Authorizing the request may further include selecting policy data associated with the material data based on the decentral material identifier(s). The determined policy data may be applied to the material data optionally using the decentral participant identifier contained in the received request. The policy may be applied prior to access of the material data. The selected policy data may be applied during run-time on access of the material data.

[0285] If the request is authorized, e.g. if the agreement data is matching existing agreement data and if application of the selected policy data to the material data results in material data allowed to be accessed by the requesting entity, the data owner may provide the material data according to the selected policy data. The material data may be provided according to the selected policy data via the decentral network.

[0286] If the request is not authorized, the connection established with the data consuming node may be terminated and no material data may be provided.

[0287] By validating received requests for access to material data based on agreement data and policy data associated with the material data to be accessed, the data owner of the material data may ensure that only authorized participants of the decentral network having agreed to usage rule(s) defined by the data owner for such material data can access such material data. This way, the material data can be exchanged in a secure yet reliable manner under full control of the data owner. This allows the data owner to retain data sovereignty over the material data while at the same time enabling the data owner to share the material data with authorized participants of the decentral network. The data consumer(s) may use the accessed material data to control and / or monitor the production of product(s) from material(s) associated with such material data. This enables more efficient production of the product(s) based on such material data.

[0288] FIG. 10 illustrates a flow chart of an example method for validating access data associated with the processing of material data by a data consumer. The material data may be associated with material(s) producible by a production, for example as described in the context of FIG. 2B. The material data may be provided by the data owner of the material data via a decentral data to data consumer(s), such as described in the context of FIG. 2B. Examples of material data provided by the data owner may include capacity data as described in the context of FIG. 2B. The method may be performed by the data owner of the material data prior to providing the material data to the data consumer.

[0289] The data processing system may be operated by or associated with the data consumer. The data processing system may be configured to perform one or more data processing operation(s) on the material data provided by the data owner via the decentral network. Data processing operation(s) may include deleting a part of the material data, filtering the material data, joining the material data, aggregating the material data, merging the material data, updating the material data, comparing the material data to further data and / or extracting at least a part of the material data. In one example, the data processing system may be configured to process capacity data received from the data owner via the decentral network. Processing capacity data may include matching received capacity data with demand data defining amounts of material required by the 231357

[0290] 52 data consumer for a given time period to produce one or more product(s).

[0291] A data set including at least one digital representation of the data processing system may be provided via the decentral network. The data set may be provided by the data consumer associated with the data processing system. The data set may be provided in response to a request received from the data owner via an associated data providing node, for example as described in the context of FIG. 2B and FIG. 4. The data set may include at least one digital representation(s) including access data and a representation for providing material data to the data processing system. The data set may include at least one further digital representation including access data associated with product data accessible at the data consuming node associated with the data consumer. The access data may include policy data as described in the context of FIG. 6B to FIG. 8. The policy data may include usage rule data defining usage rule(s) as described in the context of FIG. 2B and FIG. 60. By using access data, the data processor, such as the data consumer, can define the scope of processing operations the data consumer is allowed to perform on the received material data, hence allowing for transparency on processing operations for the data provider prior to providing any data to the data consumer.

[0292] At least a part of the access data may be validated using a rule-based engine including one or more usage rule(s) or using a data-driven model trained on historical data sets including policy data and acceptability scores, for example as described in the context of FIG. 60 and FIG. 8. The data-driven model may be trained as described in the context of FIG. 12.

[0293] It may be determined whether at least a part of the access data is validated. If at least a part of the access data, such as usage rule data, is not validated, message data may be generated and provided, for example as described in the context of FIG. 8. Non-validated policy data may be persisted in a database, for example as described in the context of FIG. 8. This way, non-validation of access data may trigger checking of such access data and optionally persisting of a part of such access data, such as policy data included in such access data. After persisting policy data or a part thereof in the database, validation of at least a part of the access data may be initiated. This way, the access data or a part thereof can be validated using updated data stored in the database.

[0294] If at last a part of the access data, such as policy data and / or usage rule data included therein, is validated, data indicating acceptance of access data may be generated, for example as described in the context of FIG. 8. The generated data indicating acceptance of access data may be provided. In response to providing such data, agreement data may be received, for example as described in the context of FIG. 4 and FIG. 6A to FIG. 70. The agreement data may include an agreement identifier, the decentral identifier associated with the digital representation and the validated usage data included in the acceptance data. The agreement data may further include a signing date and time, the decentral participant identifier(s) of the provider and consumer node or a combination thereof. An example of received agreement data is illustrated in FIG. 5D. The received agreement data may be verified, for example as described in the context of FIG. 4 and FIG. 6A to FIG. 70. Material data may be provided to the data consumer via the decentral network based on the agreement data and the representation for accessing the data processing system. The material data may be provided together with the agreement identifier included in the agreement data to the data consuming node associated with the data consumer. The data consuming node may be configured to provide the received material data to the data processing system. 231357

[0295] 53

[0296] By using a rule-based engine or a trained data-driven model, the acceptability of usage rule(s) associated with the processing of material data by a material data consumer may be reliably validated. This allows the data owner of the material data ensure that only acceptable processing operations are performed on the material data by the data consumer prior to providing the material data, hence avoiding that unallowed data processing operations are performed by the data consumer on the provided material data. This way, material data can be processed by data consumers under conditions agreed to by the data provider, avoiding that data consumer performs operations on the material data that are not approved by the data provider. This allows provision of data via the decentral network while ensuring that processing of the provided data is performed in line with usage rule(s) agreed to between data provider and data consumer prior to the data provision. This enables secure sharing and processing of data within the decentral network, allowing to improve the production based on the shared data, for example by reducing bottlenecks in the supply of material(s).

[0297] FIG. 11 illustrates a flow chart of an example method for providing material data associated with material(s) producible by a production via a decentral network to a data consumer for processing the material data. The material data may be associated with material(s) producible by a production. The material(s) producible by the production may include raw material(s), chemical intermediate material(s), chemical material(s), part(s), component(s), component assembly / ies, end product(s), end-of-life product(s) or recycled material(s). The production may be a chemical production, for example as described in the context of FIG. 6A and FIG. 6B. The data consumer may be the entity operating the production using the material(s) as input(s) to produce one or more product(s).

[0298] With reference to FIG. 2B, the data consumer may receive material data and agreement data via a decentral network. The material data and agreement data may be provided via the decentral network by the data owner of the material data. The data owner of the material data may be the entity operating the production for producing the materials. The material data may include capacity data. The capacity data may indicate production capacity / ies of production chain(s) and / or production process(es) producing the material for one or more given time period(s). The production capacity / ies may be idle production capacity / ies usable for producing the material. The agreement data may indicate an agreement between the data owner and the data consumer on usage rule data defining the processing of the material data by the data consumer. The usage rule data may define data processing operation(s) on the material data permitted and / or prohibited by the data consumer and / or obligation(s) of the data consumer with respect to data processing operation(s) performed on the material data. The agreement data may include an agreement identifier associated with the agreement, for example as described in the context of FIG. 70.

[0299] Processing of the received material data may be authorized by the data consumer. Authorization may be performed by the data consuming node associated with the data consumer. Authorization may include validating the received agreement data. Validating the agreement data may include comparing the agreement data to existing agreement data. The existing agreement data may be stored in a database, such as a database associated with or included in the data consuming node. This way, it may be ensured that an existing agreement between the data provider and the data consumer is in place prior to processing the received material data. 231357

[0300] 54

[0301] If processing of the material data is authorized, e.g. if the agreement data is matching existing agreement data, the data consumer may process the received material data according to the agreement data, e.g. the usage rule data included in the agreement data. Processing the received material data may include providing the received material data to the data processing system configured to process the material data. The data consuming node receiving the material data and authorizing the processing may be configured to forward the received material data to the data processing system upon successful authorization of the data processing. The data consuming node may further forward the usage rule data and / or the agreement data to the data processing system. This way, the data processing system may be able to determine the permitted and / or prohibited processing operation(s) and / or obligation(s) with respect to the processing of the material data. The data processing system may be configured to process the received material data in accordance with the usage rule data agreed between data provider and data consumer.

[0302] If processing of the material data is authorized, e.g. if the provided agreement data does not match existing agreement data, the received material data may not be processed by the data consumer. The received material data may not be provided by the data consuming node associated with the data consumer to the data processing system.

[0303] By validating material data associated with materials producible by a production based on agreement data associated with the processing of the material data, the data consumer may ensure that the processing is performed in line with usage rule data agreed between data owner and data consumer. This way, the material data can be processed in a transparent way for the data owner. This allows provision of data via the decentral network while ensuring that processing of the provided data is performed in line with usage rule(s) agreed to between data provider and data consumer prior to the data provision. This enables secure sharing and processing of data within the decentral network, allowing to improve the production based on the shared data, for example by reducing bottlenecks in the supply of material(s).

[0304] FIG. 12 illustrates an example method for training a data-driven model to validate access data including usage rule data associated with the usage of material data by a data consumer. The method may be used to obtain trained data driven model 730 described in the context of FIG. 6B, FIG. 60 and FIG. 7B. The data-driven model may be a classifier model as described in the context of FIG. 7B.

[0305] The input and outputs may be selected. In case an artificial neural network (ANN) is used, the inputs and outputs may refer to the number of data points in each of the input and output layers which will be separated in the ANN model by one or more layers of neurons. Any number of input and output data points may be utilized. There may be numerous data inputs, such numerous access data points and two data outputs, such as a classifier being “plausible” or “not plausible”.

[0306] A training data set may be developed and / or collected. A generally accepted practice is to divide the model training data sets into three portions: the training set, the validation set, and the verification (or “testing”) set. In case an ANN is used, the training set is used to adjust the internal weighting algorithms and functions of the hidden layers of the neural network so that the neural network iteratively “learns” how to correctly recognize and classify patterns in the input data. The validation set, however, is primarily used to minimize overfitting. The validation set typically does not adjust the internal weighting algorithms of the neural network as does the training set, but rather verifies that any increase in accuracy over the training 231357

[0307] 55 data set yields an increase in accuracy over a data set that has not been applied to the neural network previously, or at least the network has not been trained on it yet (i.e. validation data set). If the accuracy over the training data set increases, but the accuracy over then validation data set remains the same or decreases, the process is often referred to be “overfitti ng” the neural network and training should cease. Finally, the verification set is used for testing the final solution in order to confirm the actual predictive power of the neural network.

[0308] In one example, approximately 70% of the developed or collected data model sets are used for model training, 15% are used for model validation, and 15% are used for model verification. These approximate divisions can be altered as necessary to reach the desired result.

[0309] The training data may be collected by gathering various access data sets associated with various input materials (e.g. historical access data) and annotating individual data points and / or combinations of data points and / or whole data set(s) with an acceptability score. The acceptability score may be indicative of the acceptability of respective individual data point, combination of data points or whole data set. For instance, an acceptability score of 1 indicates that the data point, combination of data points or whole data set is unacceptable while an acceptability score of 5 indicates that the data point, combination of data points or whole data set 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 a data point, combination of data points or a whole set is considered acceptable or not. The training data set may include samples throughout a full range of acceptability scores.

[0310] A classifier model may be selected. The classifier model may be selected from Decision Trees, Naive Bayes Classifiers, K- Nearest Neighbors, Support Vector Machines and deep learning models. Guidelines known to those skilled in the art and / or associated with specific algorithm software can aid in the initial selection of the model type and dimensions.

[0311] The selected model may be pointed to the training and validation portions of the training data set. Training is an iterative process that - in case of ANNs - sets the internal weights, or weighting algorithms, between the ANN model neurons, with each neuron of each layer being connected to each neuron of each adjacent layer, and further with each connection represented by a weighting algorithm. With each iteration of training data to adjust the weights, the validation data is run on the ANN model and one or more measures of accuracy is determined by comparison of the model output for fill level with the actual measurement of fill level collected with the training data. For example, generally the standard deviation and mean error of the output will improve for the validation data with each iteration and then the standard deviation and mean error will start to increase with subsequent iterations. The iteration for which the standard deviation and mean error is minimized is the most accurate set of weights for that ANN model for that training set of data.

[0312] The trained model may be pointed to the verification data set to determine whether the output of the model is sufficiently accurate when compared to the actual acceptability of the respective access data. If the accuracy is not sufficient, the method may return to block 906 or to block 904 to improve the model accuracy. The sufficiently trained model may be provided in block 806 of FIG. 8. The trained model may be improved over time with additional data, such as additional 231357

[0313] 56 access data.

[0314] The present disclosure has been described in conjunction with preferred embodiments and examples as well. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the claims.

[0315] Any steps presented herein can be performed in any order. The methods disclosed herein are not limited to a specific order of these steps. It is also not required that the different steps are performed at a certain place or in a certain computing node of a distributed system, i.e. each of the steps may be performed at different computing nodes using different equipment / data processing.

[0316] As used herein ..determining" also includes ..initiating or causing to determine", “generating" also includes ..initiating and / or causing to generate" and “providing” also includes “initiating or causing to determine, generate, select, send and / or receive”. “Initiating or causing to perform an action” includes any processing signal that triggers a computing node or device to perform the respective action.

[0317] In the claims as well as in the description the word “comprising” or “including” or similar wording does not exclude other elements or steps and shall not be construed limiting to the elements or steps lined out. The indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation or further elements may be included.

[0318] Providing in the scope of this disclosure may include any interface configured to provide data. This may include an application programming interface, a human-machine interface such as a display and / or a software module interface.

[0319] Providing may include communication of data or submission of data to the interface, in particular display to a user or use of the data by the receiving entity.

Claims

23135757CLAIMS1 . A method, in particular a computer-implemented method executed by one or more computing node(s) associated with a data consumer, for validating access data associated with material data, wherein the access data includes usage rule data associated with the usage of the material data by a data consumer and wherein the material data is associated with a material produced or producible by a production, the method comprising: providing one or more decentral material identifier(s) associated with the material, providing via a decentral network the access data based on the decentral material identifier(s), validating at least a part of the access data using a rule-based engine including usage rule(s) or using a data- driven model trained on historical data sets including access data sets and associated acceptability scores, based on the validated access data, generating and providing data indicating an acceptance of the access data via the decentral network to a data providing node associated with an owner of the material data.

2. The method of claim 1 , wherein the material data is stored in a database associated with the data owner of the material data and access to the material data stored in the database is controlled by the data owner of the material data, in particular wherein the data owner of the material data is the material producer.

3. The method of claim 1 or 2, wherein providing the access data includes providing the decentral material identifier(s) by the data consuming node to the data providing node, and receiving the access data from the data providing node in response to providing decentral material identifier(s).

4. The method of any one of claims 1 to 3, wherein the usage rule data relates to emission data, production data, recyclate content data, bio-based content data, provenance data and / or labour conditions data included in the material data.

5. The method of any one of claims 1 to 4, wherein the usage rule data defines one or more action(s) permitted by the data consumer to be performed on the material data, one or more action(s) not permitted by the data consumer to be performed on the material data and / or one or more obligations to be fulfilled by the data consumer.

6. The method of any one of claims 1 to 5, wherein the rule-based engine operates on individual data point(s) included in the access data, multiple data point(s) included in the access data and / or usage rule data included in the access data.

7. The method of any one of claims 1 to 6, wherein the one or more usage rule(s) include instruction(s) for validating the access data, in particular wherein the instructions include instructions to match at least a part of the access data to predefined usage rule data.

8. The method of claim 7, wherein the predefined usage rule data includes allowable usage rule data and / or data associated with agreements signed by the data owner of the material data and one or more participant(s) of the23135758 decentral network.

9. The method of claim 7 or 8, wherein matching the predefined usage rule data to the access data includes comparing predefined usage rule data to individual data point(s) present within the access data to be validated and / or comparing data point combination(s) of predefined usage rule data to data point combination(s) present within the access data to be validated and / or comparing predefined usage rule data to usage rule data included in the access data to be validated.

10. The method of any one of claims 1 to 9, wherein the data-driven model trained to validate the access data generates at least one classifier discriminating between validated and non-validated access data.11 . The method of any one of claims 1 to 10, wherein the access data is validated if the access data fulfils at least one usage rule.

12. The method of any one of claims 1 to 11 , further including a step of gathering the material data based on the decentral material identifier and the data indicative of acceptance.

13. An apparatus for validating access data associated with material data, wherein the access data includes usage rule data associated with the usage of the material data by a data consumer and wherein the material data is associated with a material produced or producible by a production, the apparatus comprising: a data providing interface configured to provide one or more decentral material identifier(s) associated with the material, a decentral network interface configured to provide via a decentral network the access data based on the decentral input material identifier(s), a validation engine configured to validate at least a part of the access data using a rule-based engine including usage rule(s) or using a data-driven model trained on historical data sets including access data sets and associated acceptability scores, a data providing interface configured to generate and provide - based on the validated access data - data indicating an acceptance of the access data via the decentral network to a data providing node associated with an owner of the material data.

14. A method, in particular a computer-implemented method executed by one or more computing node(s) associated with a data provider, for providing material data associated with material(s) produced or producible by a production via a decentral network to a data consumer, wherein the input material data associated with access data including usage rule data associated with the usage of the material data by the data consumer, the method comprising: receiving via the decentral network a request to access the material data by a data consumer, wherein the request includes decentral material identifier(s) associated with the material and agreement data indicating an agreement between the data owner and the data consumer on the usage rule data, wherein the agreement data is generated by the method of any one of claims 1 to 12 or by the apparatus of claim 13,23135759 authorizing the request to access the material data based on the agreement data and the decentral material identifier(s), based on the authorization, providing the material data via the decentral network to the data consumer.

15. An apparatus for providing material data associated with material(s) produced or producible by a production via a decentral network to a data consumer, wherein the material data is associated with access data including usage rule data associated with the usage of the material data by the data consumer, the apparatus comprising: a decentral data providing interface configured to receiving via the decentral network a request to access the material data by a data consumer, wherein the request includes decentral material identifier(s) associated with the material and agreement data indicating an agreement between the data owner and the data consumer on the usage rule data, wherein the agreement data is generated by the method of any one of claims 1 to 12 or by the apparatus of claim 13, an authorization unit configured to authorize the request to access the material data based on the agreement data and the decentral material identifier(s), - a decentral data providing interface configured to provide the material data via the decentral network to the data consumer.

Images