Generation and processing of data associated with materials in decentral systems

Abstract

The invention relates to the field of sustainability, in particular to the field of sustainable industrialization. The disclosure relates to methods, apparatuses, systems, and computer elements for generating an output product data set associated with an output product. The disclosure further relates to methods, apparatuses, systems, and computer elements for validating input material data associated with input material(s).

Description

[0001] 240990

[0002] GENERATION AND PROCESSING OF DATA ASSOCIATED WITH MATERIALS IN DECENTRAL

[0003] SYSTEMS

[0004] TECHNICAL FIELD

[0005] The invention relates to the field of sustainability, in particular to the field of sustainable industrialization. The disclosure relates to methods, apparatuses, systems, and computer elements for generating an output product data set associated with an output product. The disclosure further relates to methods, apparatuses, systems, and computer elements for validating input material data associated with input material(s).

[0006] TECHNICAL BACKGROUND

[0007] 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. Hence, there is a need to simplify the procedure in providing reliable material data.

[0008] SUMMARY OF THE INVENTION

[0009] Disclosed is in one aspect a method for generating an output product data set associated with an output product produced or producible by a production, the method comprising: receiving a data structure defined by a data consumer for collecting properties associated with the output product, wherein the properties are related to chemical and / or physical property / ies of the output product and / or production properties related to the production of the output product; providing data associated with the output product including at least one output product identifier; gathering - based on the provided data associated with the output product - output product data from one or more databases; generating the output product data set by transforming the gathered output product data using a rulebased engine including one or more rule(s) associated with the received data structure; providing the generated output product data set for access by a decentral data consuming node under control of or controlled by a decentral data providing node associated with data owner of the generated output product data set. 240990

[0010] 2

[0011] Disclosed is in one aspect an apparatus for generating an output product data set associated with an output product produced or producible by a production, the apparatus comprising: an intake interface configured to receive a data structure defined by a data consumer for collecting properties associated with the output product, wherein the properties are related to chemical and / or physical property / ies of the output product and / or production properties related to the production of the output product; a data providing interface configured to provide data associated with the output product including at least one output product identifier; a data gathering unit configured to gather - based on the provided data associated with the output product - output product data from one or more databases; an output product data set generator configured to generate the output product data set by transforming the gathered output product data using a rule-based engine including one or more rule(s) associated with the received data structure; a decentral network interface configured to provide the generated output product data set for access by a decentral data consuming node under control of or controlled by a decentral data providing node associated with data owner of the generated output product data set.

[0012] Disclosed is in yet a further aspect a method, in particular a computer-implemented method, for generating an output product data set associated with an output product, the method comprising: producing the output product from one or more production input(s) through one or more process(es) performed within a production; receiving a data structure defined by a data consumer for collecting properties associated with the output product, wherein the properties are related to chemical and / or physical property / ies of the output product and / or production properties related to the production of the output product; providing data associated with the output product including at least one output product identifier; gathering - based on the provided data associated with the output product - output product data from one or more databases; generating the output product data set by transforming the gathered output product data using a rulebased engine including one or more rule(s) associated with the received data structure; providing the produced output product in associated with the generated output product data set, wherein the generated output product data set is provided for access by a decentral data consuming node under control of or controlled by a decentral data providing node associated with a data owner of the generated output product data set. 240990

[0013] 3

[0014] In a further aspect disclosed is a system for generating an output product data set associated with an output product, the system comprising: a production configured to produce the output product from one or more production input(s) through one or more process(es) performed within the production; an intake interface configured to receive a data structure defined by the data consumer for collecting properties associated with the output product, wherein the properties are related to chemical and / or physical property / ies of the output product and / or production properties related to the production of the output product; a data providing interface configured to provide data associated with the output product including at least one output product identifier; a data gathering unit configured to gather - based on the provided data associated with the output product - output product data from one or more databases; an output product data set generator configured to generate the output product data set by transforming the gathered output product data using a rule-based engine including one or more rule(s) associated with the received data structure; the production configured to provide the produced output product in association with the generated output product data set, wherein the generated output product data set is provided by a decentral network interface configured to provide the generated output product data set for access by a decentral data consuming node under control of or controlled by a decentral data providing node associated with data owner of the generated output product data set.

[0015] In yet a further aspect disclosed is a method for validating input material data associated with input material(s), wherein the input material(s) are used to produce a product by a production, the method comprising: providing product data including product identifier(s) associated with the product and input material identifier(s) associated with the input material(s); obtaining the input material data from decentral data providing node(s) associated with the input material data, wherein the input material data is gathered from a decentral data providing node associated with the input material data based on the provided input material identifier(s), in particular wherein the input material data is generated and provided according to the methods disclosed herein or by the apparatuses or systems disclosed herein; validating at least a part of the gathered input material data by using a rule-based engine including one or more rule(s) associated with the product or product type and including one or more rule(s) associated with a data structure defined for collecting properties associated with the input material, 240990

[0016] 4 wherein the properties are related to chemical and / or physical property / ies of the input material and / or production properties related to the production of the input material and wherein the data structure has been provided for generating the input material data; linking the validated input material data to at least one of the product identifiers; providing verified input material data linked to at least one of the product identifier(s) for generating product passport(s) associated with the product(s) based on at least a part of the verified input material data.

[0017] Disclosed is in one aspect an apparatus for validating input material data associated with input material(s), wherein the input material(s) are used to produce a product by a production, the apparatus comprising: a product data providing interface configured to provide product data including product identifier(s) associated with the product and input material identifier(s) associated with the input material(s); a decentral network interface configured to obtain the input material data from decentral data providing node(s) associated with the input material data, wherein the input material data is gathered from a decentral data providing node associated with the input material data based on the provided input material identifier(s), in particular wherein the input material data is generated and provided according to the methods disclosed herein or by the apparatuses or systems disclosed herein; a data validator configured to validate at least a part of the gathered input material data by using a rule-based engine including one or more rule(s) associated with the product or product type and including one or more rule(s) associated with a data structure defined for collecting properties associated with the input material, wherein the properties are related to chemical and / or physical property / ies of the input material and / or production properties related to the production of the input material and wherein the data structure has been provided for generating the input material data; a linking unit link the validated input material data to at least one of the product identifiers; a validated data providing interface configured to provide verified input material data linked to at least one of the product identifier(s) for generating product passport(s) associated with the product(s) based on at least a part of the verified input material data.

[0018] In yet a further aspect disclosed is a method, in particular a computer-implemented method, for validating input material data associated with an input material received from an upstream production stage of one or more production chain(s) associated with the production of a product, wherein the product is produced from input material(s) provided by the one or more production chain(s), the method comprising: 240990

[0019] 5

[0020] • producing a downstream output product from the received input material(s) through one or more process(es) performed within the production;

[0021] • providing identifier(s) associated with the downstream output product and input material identifier(s) associated with the input material;

[0022] • gathering the input material data via a decentral network, wherein the input material data is gathered at a decentral data providing node associated with a production producing the received input material based on the provided input material identifier(s), in particular wherein the input material data is generated by the methods as disclosed herein or by the systems as disclosed herein;

[0023] • validating at least a part of the gathered input material data by using a rule-based engine including one or more rule(s) associated with the product or a product type;

[0024] • linking the validated data associated with the output product to at least one of the identifiers associated with the downstream output product;

[0025] • providing the validated data linked to the identifier(s) for generating output product data set(s) associated with the downstream output product based at least in part on the validated data.

[0026] In yet a further aspect disclosed is a system for validating input material data associated with an input material received from an upstream production stage of one or more production chain(s) associated with the production of a product, wherein the product is produced from input material(s) provided by the one or more production chain(s), the system comprising:

[0027] • a production configured to produce a downstream output product from the received input material(s) through one or more process(es) performed within the production;

[0028] • a data providing interface configured to provide identifier(s) associated with the downstream output product and input material identifier(s) associated with the input material data;

[0029] • a decentral network node configured to gather the input material data via a decentral network, wherein the input material data is gathered at a decentral data providing node associated with a production producing the received input material based on the provided asset identifier(s), in particular wherein the input material data is generated by the methods as disclosed herein or by the systems as disclosed herein;

[0030] • a data validator configured to validate at least a part of the gathered input material data by using a rule-based engine including one or more rule(s) associated with the product or a product type;

[0031] • a linking unit configured to link the validated data associated with the output product to at least one of the identifiers associated with the downstream output product; 240990

[0032] 6 a data providing interface configured to provide the validated data linked to the identifier(s) for generating output product data set(s) associated with the downstream output product based at least in part on the validated data.

[0033] In yet a further aspect disclosed is a method, in particular a computer-implemented method, for validating input material data associated with an input material, wherein the input material is used to produce a product, the method comprising:

[0034] • producing the product from the input material through one or more process(es) performed within the production;

[0035] • providing identifier(s) associated with the product and input material identifier(s) associated with the input material;

[0036] • gathering the input material data via a decentral network, wherein the input material data is gathered at a decentral data providing node associated with a production producing the received input material based on the provided input material identifier(s), in particular wherein the input material data is generated by the methods as disclosed herein or by the systems as disclosed herein;

[0037] • validating at least a part of the gathered input material data by using a rule-based engine including one or more rule(s) with the product or a product type;

[0038] • linking the validated input material data to at least one of the identifiers associated with the product;

[0039] • providing the validated input material data linked to the identifier(s) for generating product passport(s) associated with the product based at least in part on the validated input material data.

[0040] In yet a further aspect disclosed is a system for validating input material data associated with an input material, wherein the input material is used to produce a product, the system comprising:

[0041] • a production configured to produce the product from the input material through one or more process(es) performed within the production;

[0042] • a data providing interface configured to provide identifier(s) associated with the product and input material identifier(s) associated with the input material;

[0043] • a decentral network node configured to gather the input material data via a decentral network, wherein the input material data is gathered at a decentral data providing node associated with a production producing the received input material based on the provided input material data 240990

[0044] 7 identifier(s), in particular wherein the input material data is generated by the methods as disclosed herein or by the systems as disclosed herein;

[0045] • a data validator configured to validate at least a part of the gathered input material data by using a rule-based engine including one or more rule(s) associated with the product or a product type;

[0046] • a linking unit configured to link the validated input material data to at least one of the identifiers associated with the product;

[0047] • a data providing interface configured to provide the validated input material data linked to the identifier(s) for generating product passport(s) associated with the product based at least in part on the validated input material data.

[0048] In yet another aspect disclosed is a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out any of the methods described herein.

[0049] In yet another aspect disclosed is a computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out any of the method described herein.

[0050] EMBODIMENTS

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

[0052] To improve the data quality of product passports to allow more efficient processing of the products associated with such product passports based on data included in the product passports, exchange of output product data containing all data to be included in such product passports is crucial. However, the absence of data models for such output products hampers the exchange of all output product data required by the data consumer generating the product passports and inhibits seamless integration between disparate systems. There is a technical need to ensure that output product data sets exchange via decentralized networks include all output product data points required for such output product for generation of the product passports.

[0053] By using standardized data structure(s) provided by the data consumer it may be ensured that the generated output product data sets include all data points required for the generation of the product passports. This way, a higher data quality of the product passports can be achieved, allowing more efficient processing of the product, such as more efficient production of further products using the product or more efficient recycling of the product, based on the data included in the product passport. The fixed data structure facilities seamless integration with existing data management systems, enhancing the efficiency of both data transmission and reception between the data consumer and the data provider. Furthermore, the data structure provided by the data consumer allows for reliable collecting of properties associated with the output product. In particular it allows for collecting of properties such as water consumption, ethical sourcing practice, testing protocols of the output product and a sustainability report that cannot be determined by the output product consumer, for example by analysis of the received output product. Thus, the data structure also allows more fruitful and flexible data exchange within the product ecosystem and facilitate the generation of product passports having a higher data quality.

[0054] By embedding conditions within the received data structure and deriving rules from these conditions, the method ensures compliance with predefined criteria during data set generation. This integration enhances data integrity and reliability by systematically verifying the data against established conditions.

[0055] Consequently, it facilitates a more efficient approach to data handling and transmission, ensuring that the data meets the required conditions before being made accessible. This method also supports a structured verification process, which can be crucial for maintaining high data quality and consistency across the decentral network.

[0056] By using a rule-based engine including rule(s) associated with the data structure provided by the data consumer, it can be ensured that output product data point(s) required by the data consumer, for example, according to a data model, such as an aspect model, associated with products produced from such output products are contained in the output product data set, hence avoiding missing data point(s) during generation of a product passport associated with the product using said semantic model and ensuring a higher data quality of the generated product passports. Since the rule(s) are derived from the data structure provided by the data consumer, suppliers producing input material(s) used in the production of such product do not have to use or generate complex data models to generate output product data set(s) fulfilling a data structure and including the data points required by the data consumer for processing of the output product data set(s). This way, the data quality of product passports generated based on the shared output product data sets may be improved, allowing to improve the processing of the product and / or product(s) produced from the product based on the data included in the in product passport. 240990

[0057] 9

[0058] By transforming the gathered output product data using such rule-based engine, aggregation of the gathered output product into a data structure defined by the data consumer, such as a tabular representation, can be achieved without the use of complex data models, hence facilitating simple generation and reliable sharing of output product data set(s) by output product producers within the product ecosystem. The output product data set(s) may be associated with authorization rule(s), hence avoiding unauthorized access to such data and ensuring secure sharing of such data. The output product data sets, such as the tabular representation(s), may be stored within a local data storage associated with the production producing the output products for consumption of such output product data sets by decentral network nodes associated with production producing the product under the control of the data owner of the output product data sets, e.g. the output product producer. The output product data sets can be directly consumed based on identifier(s) associated with such output product data sets and endpoint(s) of decentral network nodes associated with the local data storage rendering the use and maintenance of decentral registries storing digital representation(s) for accessing the output product data sets superfluous. This way, the effort for sharing the generated output product data sets within the decentral network may be reduced, allowing more reliable sharing of such output product data sets and hence also a higher data quality of passports generated based on such shared output product data sets.

[0059] By using rule template(s) derived from the data structure received from the data consumer and including unstructured data associated with transformation operation(s), generation of one or more rule(s) may be facilitated using natural language, hence allowing simple and reliable generation of rule(s) based on natural language text, such as user input, contract clauses, etc. In addition, the rule template(s) may be predefined, hence allowing generation of output product data set(s) based on given rule template(s) and rule(s), resulting in a further simplification of the generation of the output product data set(s).

[0060] By enabling simple generation of output product data set(s) based on data structures received from the data consumer, it can be ensured that the generated output product data sets include all data point(s) required by the data consumer for generation of the product passports. By sharing such output product data sets within a decentral network more efficient production and / or recycling processes based on product passports generated using the shared output product data, may be enabled. By using a decentral network, the generated output product data set(s) may be shared in a secure and controlled manner by avoiding access to such data set(s) by unauthorized decentral network participant(s), hence avoiding unwanted transparency on supply chains by third parties. 240990

[0061] 10

[0062] By using a rule-based engine operating on data point level, multiple data points level or whole data level, it may be ensured that the generated output product data set include(s) all output product data point(s) required by the data structure provided by the data consumer. This ensures that product passports associated with such products can be reliably generated from data gathered via the decentral network, without a risk that required data point(s) are missing, hence resulting in product passports having a higher data quality. The higher data quality may allow more efficient processing of the product based on the data included in the product passports.

[0063] By validating the output product data set(s) generated in a simple and efficient way using a rule-based engine including rules associated with the product or product type, in particular associated with data model(s) of the product or the product type, it can be ensured that the consumed output product data set(s) include the data point(s) required by the data model. This allows to avoid missing data points upon generation of product passports associated with such products using the consumed output product data. Validation of consumed output product data sets by the consumer side ensures that the product passport contains all data required by a data model used to generate such product passports, hence allowing to reduce the complexity associated with the output product data set generation at the provider side by providing data structures to the data provider which are derived from or generated based on such data models. This may enable reliable sharing of output product data of output product(s) irrespective of the existence of data models for such output products since the rule(s) required to transform the gathered output product data may be readily derived from the data structure provided by the data consumer.

[0064] The method for generating the output product data sets associated with the output product may be executed by one or more computing node(s) associated with a production producing the output product and / or the output product producer. The output product producer may operate the production. The method for validating the input material data may be executed by one or more computing node(s) associated with a downstream production producing the further output products or the product. The method for validating the input material data may be executed by one or more computing node(s) associated with downstream output product producer or the product producer.

[0065] In an embodiment, gathering output product data from one or more databases includes providing updated data structure containing properties associated with the output product, propagating the updated data structure to a database, gathering based on the provided data associated with the output product - the updated data structure from the database and optionally from further databases. The data structure may refer to a predefined format or form that organizes data fields in a specific layout, guiding a user in 240990

[0066] 11 providing data in a consistent and orderly manner. The user may be the data provider or an authorized individual. The user input may also be provided by a machine (auto-filling). By providing updated data structure, for example, by supplementing user input related to the properties of the output product, implicit information or properties of the output product may be available. Such as water consumption, ethical sourcing practice, testing protocols of the output product. Thus, the data structure also allows more fruitful data exchange within the product ecosystem and facilitate the generation of chemical product passports.

[0067] In one embodiment, the received data structure includes one or more conditions to be satisfied, the one or more rule(s) includes at least one rule derived from and / or checking the one or more conditions. The condition(s) may be a collection of predefined criteria embedded within the data structure provided by the data consumer and governs the acceptable inputs for each data field. The conditions may be checked by one or more rules during the data set generation. For example, the conditions may include data type constrains (e.g., integer, string, date), value ranges(e.g., minimum or maximum allowable values), mandatory fields (e.g., cannot be null). The rule-based engine may generate output product data set based on the data structure and also taking the conditions into consideration. Thus, the conditions may provide a higher standard than just being syntactically correct.

[0068] In one embodiment, the method further comprises: obtaining one or more conditions associated with the received data structure, the one or more rule(s) includes at least one rule derived from and / or checking the one or more conditions, preferably the one or more conditions are included in one or more standardized and / or pre-defined rules. Likewise, the one or more conditions may provide a higher standard than just being syntactically correct. The one or more standardized and / or pre-defined rules may be provided by one or more regulatory or oversight entities associated with due diligence standards. By sourcing conditions directly from certain entities, it can be ensured that the conditions applied with the data compliance process are accurate, up-to-date and reflective of current due diligence requirements. Such entities may include but not limited to non-governmental organizations, regulatory agencies, industry bodies, or other standardsetting organizations that establish and monitor frameworks for due diligence practices. This approach provides a dynamic, adaptable framework for data verification, wherein conditions may be continuously aligned with evolving regulatory standards and industry best standards.

[0069] In an embodiment, the one or more databases are distributed databases, wherein at least one of the databases stores instance(s) of the output product data. A distributed database may be a collection of data stored at different sites of a computer network. Each site might expose a degree of autonomy, providing services for the execution of local applications, but also participating in the execution of a global 240990

[0070] 12 application. For instance, a distributed data source may be a distributed database. A distributed database can be created by splitting and scattering the data of an existing database over different sites or by federating together multiple existing databases. Each data source may contain only a fragment of the data associated with the respective output product. This leads to a fragmentation of said data. Two common types of data fragmentation are horizontal fragmentation, wherein (possibly overlapping) subsets of data tuples are stored at different sites; and vertical fragmentation, wherein (possibly overlapping) subtuples of data tuples are stored at different sites. More generally, the data associated with the output product may be fragmented into a set of relations (tables of a relational database, distributed across multiple sites).

[0071] In an embodiment, the output product is a chemical intermediate product, a chemical product, a part, a component or a component assembly. The chemical intermediate product and / or the chemical product may be produced from virgin input material(s) and / or recycled input material(s). The component may be a battery component, such as an electrode, a battery cell, a battery module, a separator, a cell casing, a battery management system, a cooling system, mechanical subsystem or a battery pack housing.

[0072] In an embodiment, the gathered output product data includes output product identifier data, property data associated with the output product, output product name data, output product producer data, output product declaration data, output product safety data, emission data associated with the output product, recyclate content data associated with the output product, biobased content data associated with the output product, biodegradability data associated with the output product, production data associated with the output product, certificate of analysis data associated with the output product, certificate data associated with the output product, life cycle data associated with the output product, storage instruction data associated with the output product, assembly instructions associated with the output product, operating conditions associated with the output product or a combination thereof.

[0073] Output product identifier data may include a batch number, a serial number, a LOT number or a combination thereof.

[0074] Property data may include at least one measured chemical and / or physical property of the produced output product and / or at least one chemical and / or physical property determined from collected data associated with the production of the output product. The data may be collected before, during and / or after production of the output product. The collected data may be used to determine at least one physical and / or chemical property of the produced output product. For instance, the at least one physical and / or chemical property 240990

[0075] 13 may be determined from sensor data obtained from sensor(s). The data may be collected with a suitable sensor configured to measure the chemical and / or physical property. The chemical property may be a property of the output product 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 output product. Examples of chemical properties include heat of combustion, enthalpy of formation, toxicity, chemical stability in a given environment, flammability, oxidation state(s), ability to corrode, combustibility, acidity and basicity, chemical composition, recyclate content used for producing or manufacturing the product, bio-based content used for producing or manufacturing the product, renewable content used for producing or manufacturing the product and / or pH value. The physical property may be any property of the output product that is measurable. Hence, the value of a physical property describes a state of the output product. Examples of physical properties include absorption, brittleness, boiling point, capacitance, color, concentration, continuous discharge, density, ductility, physical dimensions, distribution, efficacy, elasticity, electric charge, electrical conductivity, electrical impedance, electric potential, flow rate, fluidity, hardness, capacity, inductance, intrinsic impedance, luminance, luminescence, luster, mass, melting point, opacity, permeability, permittivity, plasticity, pulse discharge, power, pressure, radiance, resistivity, reflectivity, refractive index, solubility, specific heat, strength, stiffness, temperature, tension, thermal conductivity, thermal resistance, weight, viscosity, volume and / or wave impedance. The measured at least one physical and / or chemical property may be obtained by sensors configured to measure such property. The sensor may be included in a measuring device. The sensor may correspond to the measuring device.

[0076] Recyclate content data and / or bio-based content data may comprise any data related to the recyclate content or the bio-based content used for providing or manufacturing the output product.

[0077] Emission data may comprise any data related to environmental footprint. The environmental footprint may refer to the output product and its associated environmental footprint. The environmental footprint may be output product specific. For instance, the environmental footprint may relate to the output product or additional output product-specific relations. Emission data may include data relating to the carbon footprint of the output product or a Product Carbon Footprint (PCF). Emission data may include data relating to greenhouse gas emissions e.g. released in production of the output product. Emission data may include data related to greenhouse gas emissions. Greenhouse gas emissions may include emissions such as carbon dioxide (CO2) emission, methane (CH4) emission, nitrous oxide (N2O) emission, hydrofluorocarbons (HFCs) emission, perfluorocarbons (PFCs) emission, sulphurhexafluoride (SFe) emission, nitrogen trifluoride (NF3) emission, combinations thereof and additional emissions. Emission data may include data related to greenhouse gas emissions of an entities or companies own operations (production, power plants 240990

[0078] 14 and waste incineration). Scope 2 may comprise emissions from energy production which is sourced externally. Scope 3 may comprise all other emissions along the value chain. Specifically, this may include the greenhouse gas emissions of raw materials obtained from suppliers. Product Carbon Footprint (PCF) may sum up greenhouse gas emissions and removals from the consecutive and interlinked process steps related to a particular product. Cradle-to-gate PCF may sum up greenhouse gas emissions based on selected process steps: e.g. from the extraction of resources up to the factory gate where the product leaves the company. Such PCFs may be called partial PCFs. In order to achieve such summation, each company providing any products may provide the scope 1 and scope 2 contributions to the PCF for each of its products.

[0079] Production data may comprise any data related to the production of the output product. Production data may include monitoring and / or control data associated with the production of the output product. Production data may be acquired prior to, during and / or after production of the output product.

[0080] In an embodiment, the rule-based engine operates on individual data points present within at least part of the gathered output product data, multiple data points present within at least part of the gathered output product data or the whole gathered output product data. The rule-based engine may be configured to transform gathered output product data based on one or more included rule(s). The rule-based engine may apply one or more rule(s) to individual data point(s), multiple data point(s) and / or the whole data set to generate the output product data set(s). If the rule-based engine determines that individual data point(s), multiple data point(s) and / or the whole data matches one or more condition(s) in the rule(s), such individual data point(s), multiple data point(s) or the whole data may be included in the generated output product data set.

[0081] In an embodiment, the one or more rule(s) are generated from a rule template including unstructured data associated with instructions related to transformation operation(s). The rule template may be generated based on or derived from the data structure received from the data consumer. The instructions may signify the transformation operation(s). the instruction(s) may relate to the transformation operation(s). The transformation operation(s) may relate to aggregation output product data gathered from multiple data sources into a given format, filters to filter gathered output product data, attribute construction(s) to create or add new attributes to the gathered output product data and / or a trigger condition and a corresponding group of one more actions. The rule template may be used to generate executable logic that may be executed by the rule-based engine. Use of a rule template may facilitate generation of one or more rule(s) since the instructions for generation of executable logic may be formulated in natural language. The rule 240990

[0082] 15 template may be a predefined rule template. The rule template may be generated to match semantic model(s) associated with product(s) produced by using the output product as input material. The rule template may be generated and provided by a third party. This may allow to provide rule template(s) as a service to data providers to further simplify the generation of the output product data sets and to lower the entry barrier for input material suppliers to generate and provide output product data sets via a decentral network to allow data consumers access to such data for generation of product passports.

[0083] In an embodiment, the one or more rule(s) define aggregation rule(s) for aggregating output product data gathered from multiple data sources into a given format, define filters to filter gathered output product data, define attribute construction(s) to create or add new attributes to the gathered output product data and / or include a trigger condition and a corresponding group of one more actions. The given format may be a tabular representation. Hence, the rule-based engine may be configured to generate, based on the one or more included rule(s), a tabular representation filled with gathered output product data matching one or more included rule(s). The tabular representation may be stored within a dedicated storage associated with the decentral data providing node, allowing provision of the tabular representation by requesting access to such tabular representation based on an output product identifier included in such tabular representation. Filters may define data point(s) to be included in the generated output product data set. For instance, a filter may define one for more output product property data point(s), output product identifier data point(s), output product name data point(s), output product producer data point(s), output product declaration data point(s), output product safety data point(s), output product emission data point(s), output product recyclate content data point(s), output product biobased content data point(s), output product biodegradability data point(s), output product production data point(s), output product certificate of analysis data point(s), output product certificate data point(s), output product life cycle data point(s), output product storage instruction data point(s), output product assembly instruction data point(s) and / or output product operating condition data point(s). A filter may define data point(s) per data category. A filter may define data point(s) for at least two different data categories. A data category may signify property data, declaration data, safety data, emission data, recyclate content data, biobased content data, biodegradability data, production data, certificate of analysis data, certificate data, storage instruction data, assembly instruction data or operating condition data.

[0084] In an embodiment, transforming the gathered output product data by the rule-based engine includes identifying one or more rule(s) applicable to the gathered output product data and providing the applicable rule(s) to the rule-based engine. The applicable rule(s) may be identified based on an identifier associated with each applicable rule matching or being related to at least one output product identifier included in the 240990

[0085] 16 gathered output product data. The applicable rule(s) may be included in a rule template. Hence transforming the gathered output product data may include identifying an applicable rule template. The applicable rule(s) and / or the applicable rule template may be stored on a database connected to the rulebased engine. The identifier associated with each applicable rule or rule template may correspond to a digital output product identifier included in the gathered output product data. The applicable rule(s) or rule template may be gathered based on mapping data include identifier(s) associated with rule(s) or rule template(s) and associated output product identifier(s) and optionally output product type identifier(s).

[0086] In an embodiment, transforming the gathered output product data includes

[0087] • generating executable logic from the one or more identified applicable rule(s),

[0088] • and transforming the gathered output product data by executing the generated executable logic by the rule-based engine subject to rule execution criteria.

[0089] The rule execution criteria may be included in the executable logic. The execution criteria may relate to action(s) associated with triggers included in the executable logic. Generating executable logic allows provision of rule(s) or rule template(s) as unstructured data, such as in natural language, hence simplifying creation of executable logic by using rule template(s) or rule(s) including unstructured data, such as rule(s) and / or rule template(s) written in natural language. Simplifying creation of the executable logic ensures that the barrier to generate and provide output product data set(s) within the decentral network is lowered, hence ensuring that also small supplier entities are able to participant as output data providers within the decentral network. This in turn allows data consumers generating product passports to reliably consume all required input material data via the decentral network, hence ensuring efficient and reliable generation of product passports using the gathered input material data.

[0090] In an embodiment, the output product data set is generated responsive to fulfilment of one or more rule(s) applied to the gathered output product data by the rule-based engine. This may ensure that generation of output product data set(s) is only then performed if the rule(s) could be successfully applied to the gathered data by the rule-based engine, e.g. if application of the rule(s) did not result in an error, for example due to missing data, wrong data, incomplete data, etc. This may ensure that only output product data set(s) are provided via the decentral network which fulfil the applied rule(s), hence avoiding errors during validation performed on the consumer side which may prevent generation of required product passports. This may in turn have a negative influence on the provision of such products for example if the product passport is required from a regulatory standpoint for products sold to downstream participants of the product ecosystem or end product users. The delayed provision of such products may result in a negative influence 240990

[0091] 17 on the production of downstream participants, since required input materials are not available for production.

[0092] In an embodiment, the generated output product data set includes or is associated with at least one output product identifier, in particular the output product identifier(s) included in the provided data associated with the output product.

[0093] In an embodiment, the generated output product data set includes at least a part of the data included in the gathered output product data. For instance, the generated output product data set may include data point(s) defined by the one or more rule(s) used to generate the output product data set. Such rule(s) may define one or more data point(s) to be included in the generated output product data set(s).

[0094] In an embodiment, the generated output product data set includes output product property data point(s), output product identifier data point(s), output product name data point(s), output product producer data point(s), output product declaration data point(s), output product safety data point(s), output product emission data point(s), output product recyclate content data point(s), output product biobased content data point(s), output product biodegradability data point(s), output product production data point(s), output product certificate of analysis data point(s), output product certificate data point(s), output product life cycle data point(s), output product storage instruction data point(s), output product assembly instruction data point(s) and / or output product operating condition data point(s). For instance, the generated output product data set may include output product emission data point(s).

[0095] In an embodiment, the method further includes a step of generating group access data associated with the generated output product data set and optionally one or more authorization rule(s) defining access to and / or processing of the generated output product data set. The group access data may identify access control groups including decentral participant identifier(s) associated with decentral network participants permitted to access at the generated output product data set. This access group data may allow to control access to such data sets, hence avoiding access of unauthorized data consumers to such data. This may ensure that the output product data sets are only shared with such data consumers that require such data, for example for the generation of product passports.

[0096] In an embodiment, the method further includes a step of generating a contract template including the digital output product identifier and the group access data identifier. The contract template may be used by the decentral data providing node to generate an electronic contract. The electronic contract may be provided 240990

[0097] 18 to a decentral data consuming node requesting access to such output product data set(s) associated with the decentral data providing node. The contract may include access data. The access data may include an endpoint pointing to the dedicated storage storing the respective output product data set. This may allow the decentral data consumer node to use such endpoint within the request for such output product data upon accepting the electronic contract. The electronic contract may include authorization rule(s) associated with the usage of the output product data set(s). This may avoid unauthorized use of the provided output product data by the data consumer, hence improving data security.

[0098] In an embodiment, the access to the generated output product data set is controlled by the decentral data providing node associated with the data owner based on the group access data and contract template associated with the output product data set. This may allow to configure access to the output product data set such that access to such data by data consumers not requiring access to such data is avoided.

[0099] In an embodiment, the method further includes a step of generating incident data responsive to the determination that at least one rule applied by the rule-based engine to the gathered output product data is not fulfilled. The incident data may identify the data point(s) and rule(s) which resulted in non-fulfillment. The incident data may be used to generate an updated output product data set. Use of such incident data may allow to avoid provision of output product data sets which may not be validated by the consumer side, thus resulting in delay of generation of product passport(s) since such generation must be delayed until output product data set(s) including valid data are available from the provider side.

[0100] In an embodiment of the method for validating input material data associated with input material(s), the product data further includes product property data including at least one measured chemical and / or physical property of the product and / or at least one chemical and / or physical property determined from collected data associated with the production of the product. The chemical and / or physical property may correspond to the properties previously described. The data may be collected prior to, during and / or after production of the product.

[0101] In an embodiment of the method for validating input material data associated with input material(s), the decentral data providing node(s) are determined from mapping data mapping decentral data providing node data to associated input material identifier(s) by matching input material identifier(s) included in the product data to output product identifier(s) included in the mapping data. This mapping data may be stored in a database. The output product identifier(s) and associated data providing node data may be provided by respective decentral data providing node(s) to the consuming entity consuming such output product data 240990

[0102] 19 from such data providing node(s). Data providing node data may include location data pointing to the location of the output product data set associated with the respective data providing node, an endpoint address associated with the respective data providing node and / or a decentral participant identifier associated with the respective data providing node. The database may not contain associated output product data set(s), hence the database may not be regarded as a central repository of output product data set(s). Instead, the control over access to the output product data set(s) is retained by the respective data providers, while such database only allows to locate output product data set(s) required to generate respective product passports.

[0103] In an embodiment of the method for validating input material data associated with input material(s), the obtained input material data is provided to one or more input node(s) configured to gather the obtained input material data and to provide the gathered input material data as input material data set(s) to one or more downstream node(s), wherein the one or more downstream node(s) are configured to validate at least a part of the data included in the input material data set(s) provided by the one or more input node(s), link the validated input material data to at least one of the product identifiers, determine storage location(s) for the validated input material data and to provide the validated input material data linked to product identifier(s) to the determined storage location(s). An input node may represent a computing node gathering input material data from one or more decentral data consuming node(s). The one or more input node(s) may be configured to generate data packages, such as messages or events, from the received input material data. The generated data packages may be sent downstream from the input node to the one or more downstream node(s). The downstream node(s) may be configured to retrieve data packages provided by the input node(s). The input node(s) may be configured to provide data packages to a persistent or non-persistent log. The downstream node(s) may be configured to retrieve data packages provided to the persistent or non-persistent log. The downstream node(s) may be configured to receive data packages provided to the persistent or non-persistent log. The input node(s) may be associated with a decentral network. For instance, the input node(s) may be associated with a decentral data consuming network node being part of a decentral network. Downstream node may refer to a computing node consuming data from a computing node present upstream with respect to the flow of data. Consuming data may include receiving data or retrieving data packages from the input node(s) or the persistent or non- persistent log. For instance, data “flows” downstream from an input node to the downstream node. The downstream node may be regarded as an output node. A request for data may be sent upstream from the downstream node to the input node. 240990

[0104] 20

[0105] In an embodiment of the method for validating input material data associated with input material(s), the rule-based engine operates on individual data points present within at least part of the input material data, multiple data points present within at least part of the input material data or the whole input material data. The rule-based engine may be configured to validate input material data based on one or more included rule(s). The rule-based engine may apply one or more rule(s) to individual data point(s), multiple data point(s) and / or the whole data set to generate validated input material data. If the rule-based engine determines that individual data point(s), multiple data point(s) and / or the whole data matches one or more condition(s) in the rule(s), such individual data point(s), multiple data point(s) or the whole data may be regarded as validated. The validated data may be associated with a classifier indicating successful validation of the respective data point, combination of data point(s) or the whole data. The classifier may indicate that the input material data passed the one or more applied rule(s). Validating the input material data on data point level may ensure that all input material data point(s) required by the semantic model associated with the product are contained in the gathered input material data. Validation on data point level may compensate for the simplified output product data set generation at the provider side which does not require the use of semantic models ensuring that the generated output product data set(s) include all required data point(s).

[0106] In an embodiment of the method for validating input material data associated with input material(s), the one or more rule(s) are generated from a rule template including unstructured data associated with instructions related to validation operation(s). The validation operation(s) may relate to one or more data point(s) and / or data point combination(s) to be present within the input material data. The rule template may be used to generate executable logic that may be executed by the rule-based engine. Use of a rule template may facilitate generation of one or more rule(s) since the instructions for generation of executable logic may be formulated in natural language. The rule template may be a predefined rule template. The rule template may be generated to match semantic model(s) associated with product(s).

[0107] In an embodiment of the method for validating input material data associated with input material(s), the one or more rule(s) define data point(s) and / or combination(s) of data point(s) to be present within the input material data. This may ensure that the input material data includes all data point(s) required by the semantic model of the product, hence ensuring that the gathered input material data includes all data points required by the semantic model for the particular input material.

[0108] In an embodiment of the method for validating input material data associated with input material(s), validation of the input material data may further include transforming the input material data. Transforming 240990

[0109] 21 the input material data may include unit transformation to transform a unit associated with a data point into a unit required by the semantic model associated with the product. This may allow to shift unit transformation operations to the consumer side, hence allowing to simplify generation of output product data sets at the provider side to ensure reliable provision of output product data set(s) by various suppliers of the product ecosystem, irrespective of the size of the entity producing the output products.

[0110] In an embodiment of the method for validating input material data associated with input material(s), the one or more rule(s) are associated with or derived from a semantic model of the product, in particular wherein the one or more rule(s) are defined by the mandatory input material data point(s) present within the semantic model. The semantic model may be a predefined (e.g. existing) semantic model. The semantic model may define the data structure of the product passport. The semantic model may define the value(s) and / or value range(s) for data point(s) to be included in the product passport. The semantic model may define mandatory and optional data point(s) to be included in the product passport. The semantic model may define relationships between different data point(s).

[0111] In an embodiment of the method for validating input material data associated with input material(s), validating the gathered input material data by the rule-based engine includes identifying one or more rule(s) applicable to the gathered input material data and providing the applicable rule(s) to the rule-based engine. The applicable rule(s) may be identified based on an identifier associated with each applicable rule matching or being related to at least one input material identifier included in the gathered input material data as previously described. The applicable rule(s) may be included in a rule template. Hence validating the gathered input material data may include identifying an applicable rule template. The applicable rule(s) and / or the applicable rule template may be stored on a database connected to the rule-based engine. The identifier associated with each applicable rule or rule template may correspond to a digital input material identifier included in the gathered input material data. The applicable rule(s) or rule template may be gathered based on mapping data include identifier(s) associated with rule(s) or rule template(s) and associated input material identifier(s) and optionally input material type identifier(s).

[0112] In an embodiment of the method for validating input material data associated with input material(s), transforming the gathered input material data includes

[0113] • generating executable logic from the one or more identified applicable rule(s),

[0114] • and transforming the gathered input material data by executing the generated executable logic by the rule-based engine subject to rule execution criteria. 240990

[0115] 22

[0116] In an embodiment of the method for validating input material data associated with input material(s), the input material data is validated responsive to fulfilment of one or more rule(s) applied to the input material data by the rule-based engine. This may ensure that the gathered input material data is only validated if the rule(s) could be successfully applied to the gathered data by the rule-based engine, e.g. if application of the rule(s) did not result in an error, for example due to missing data, wrong data, incomplete data, etc. This may ensure that the product passport may be generated by applying the respective semantic model to the validated input material data and respective product data without any errors due to missing or wrong input material data, hence avoiding a delay in generation of the product passports.

[0117] In an embodiment of the method for validating input material data associated with input material(s), the storage location is determined based on mapping data including a mapping between input material identifier(s) and associated storage location data or a mapping between input material identifier(s) and associated input material type identifier(s) and storage location data. The storage location may correspond to a database. The database may be a relational or a non-relational database. Use of different storage location (s) allows to improve data security, since validated input material data to be used for the generation of product passports associated with a specific product type, such as a battery, may be stored within a particular dedicated storage accessible only by the application generating the passports for such specific product type but not for other applications generating passports for other product types.

[0118] In an embodiment of the method for validating input material data associated with input material(s), the validated input material data includes one or more validated input material property data point(s), validated input material identifier data point(s), validated input material name data point(s), validated input material producer data point(s), validated input material declaration data point(s), validated input material safety data point(s), validated input material emission data point(s), validated input material recyclate content data point(s), validated input material biobased content data point(s), validated input material biodegradability data point(s), validated input material production data point(s), validated input material certificate of analysis data point(s), validated input material certificate data point(s), validated input material life cycle data point(s), validated input material storage instruction data point(s), validated input material assembly instruction data point(s) and / or validated input material operating condition data point(s).

[0119] In an embodiment of the method for validating input material data associated with input material(s), the method further includes a step of generating incident data responsive to the determination that at least one rule applied by the rule-based engine to the gathered input material data is not fulfilled. The incident data may identify the data point(s) and rule(s) which resulted in non-fulfilment. The incident data may be 240990

[0120] 23 provided to the data provider from which the objected input material data was received, hence allowing the data provider to generated updated input material data and to provide such updated input material data for repeated validation.

[0121] Input material may refer to any good which is bought from suppliers and brought to the respective production plant. The input material may include starting material used in the production process of the production plant to produce the product. An input material can be used in any production step used to produce the product. This means, the product of the one production plant can be the input material of the other production plant. Likewise, the output product of one supply chain participant may be used as input material to produce a further output product by a downstream participant. Input material may include recycled material. The input material may comprise or be any input material entering a production. The input material may comprise or be any input material provided at any entry point of the production.

[0122] Output product may include any product produced from one or more input materials. The output product may be produced via one or more process steps. The process steps may involve chemical reactions and / or physical processes and / or assembly processes. The input material may be used in one or more of such production step(s). The output product may comprise or be any product produced by a production and provided at any exit point of the production. The output product may be used as input material to produce one or more product(s). The output product may include production inputs for producing the product. The product may be produced from output product(s) produced by one or more production chain(s). The production chain(s) may include one or more production stage(s). The output product produced by an upstream production stage may be used as production input by a downstream production stage. The downstream production stage may be a further output product production stage or the product production stage. Output product(s) may be produced by upstream production stage(s) with respect to the product production stage. The product(s) may be produced by one or more downstream participants which may use the output product(s) produced by one or more upstream participants as input material(s). The output product may be associated with an output product identifier. The output product identifier may be a digital or virtual output product identifier. The output product identifier may uniquely identify the output product within the entity producing the output product. The output product identifier may uniquely identify the output product within the decentral network. The output product identifier may be associated with an identifier element physically connected to the output product. The identifier element may encode the digital output product identifier. The output product identifier may include an output product name, an output product number, a LOT number, a batch number, a serial number, etc. The downstream output product may be produced by a downstream production stage with respect to the production stage producing the output product. The downstream output product may be used to produce the product.

[0123] The output product may be produced using the product. The output product may be used in a production stage associated with the production of the product. The product may be a chemical product, The product may be a discrete product. The product may be a component, a componentassembly or an end-product. The product may be a battery. The product type may include a product class the product belongs to.

[0124] The output products and / or the product may be produced via one or more process steps performed within the production. The process steps may involve chemical reactions and / or physical processes. The production may be a chemical production. The chemical production may perform one or more chemical reactions and / or physical processes.

[0125] The output products may be associated with an output product data set. The output product data set may include an identifier associated with the output product and output product data transformed by the rule-based engine. The identifier may not be discoverable by participant nodes of the decentral network.

[0126] The output product / input material and the product may be part of a product ecosystem. The product ecosystem may include chemical products. The product ecosystem may include production chains to produce a product. The product may be a chemical product, an intermediate chemical product, a component, a component assembly or an end-product. The product ecosystem may include processing chains to process used products resulting from the use of produced products. Processing chains may include recycling chains to recycle at least part of the used product or a component thereof. Processing chains may include re-use chains to re-use the used product. The product ecosystem may include various participants, such as raw input material producers, chemical product producers, chemical product users, end-product producers, end-product users, EOL product collectors and recyclers. The product ecosystem may allow to use of recycled materials resulting from recycling of end-of-life end products to produce new products, such as chemical products. The product ecosystem may be associated with the production and / or re-use and / or recycling of physical products.

[0127] The participants of the product ecosystem may be connected via a decentral network. The decentral network may include one or more decentral network node(s) configured to perform data transactions. The decentral network node(s) may be associated with participants of the product ecosystem. The data transactions may be based on a transaction protocol including authentication and / or authorization 25 mechanism(s). Based on the authentication and / or authorization mechanism(s) a peer-to-peer network between decentral network node(s) of the decentral network may be established. The one or more authentication mechanism(s) may be associated with or linked to decentral identifier(s). The one or more authentication mechanism(s) associated with decentral identifier(s) may be provided to decentral network node(s). The one or more authentication mechanism(s) associated with decentral identifier(s) may be accessible by decentral network node(s). The decentral configuration allows for more efficient use of computing resources and strengthens control by each data owner of the decentral network.

[0128] The decentral data providing network node may comprise computer-executable instructions for providing and / or processing data within a decentral network, such as the output product data sets, by a decentral data consuming network node. The decentral data providing network node may be associated with or connected to one or more dedicated data storage(s) storing the output product data sets. The decentral data providing network node may be directly or indirectly connected to the data storage(s) storing the output product data sets. Hence, the decentral data providing network node may be associated with the output product data sets. The dedicated data storage(s) may be under control of the data owner of the output product data sets. The data owner may be an entity having access to the output product data sets and controlling access by data consuming services of the decentral network to the output product data sets. The data owner may be the output product producer. Via the output product identifier and its unique association with the data owner and output product data set access to the output product data set may be controlled by the data owner. The output product data sets may be accessible for the data owner. The data owner may hence directly or indirectly own the output product data sets. The output product data sets may be stored in a database of or associated with the data owner. The output product data sets may be stored in a database accessible by the data owner. The data owner may control access to the output product data sets via the data providing service of the data owner. The data owner may control access to the output product data sets. The output product data sets may be associated with the data owner. The data owner may be the owner of the output product data sets or the output product data set owner. The output product data sets may be stored in a data base of or under control by the data owner.

[0129] The decentral data consuming network node may comprise computer-executable instructions for accessing and / or processing data within a decentral network, such as input material data, provided by a decentral data providing network node. The decentral data consuming network node may be controlled or owned by or associated with a consumer of the input material data (e.g. the entity generating the product passport). The consumer may be any entity processing the input material data. The consumer may be any entity operating a production configured to process the output products associated with the output product data 240990

[0130] 26 as input material(s) Processing may include using the output products as input materials to produce further products. Processing may include performing one or more recycling step(s) on the output products as input material. The consumer may be an upstream participant of the output product producer in the product ecosystem.

[0131] A rule-based engine may be used to transform at least part of the gathered output product data associated with output product(s). The rule-based engine may be a software or software component that applies one or more rules to at least part of the gathered output product data. The rule(s) may include or correspond to executable logic. The executable logic may be generated from a rule template including unstructured data associated with instructions related to transformation operation(s). The rule-based engine used to transform at least part of the gathered output product data may include one or more rule(s) associated with product(s) produced from the output product(s) (e.g. by using the output products as input materials). The one or more rule(s) may be associated with or derived from a semantic model of the product. Hence, the one or more rule(s) may ensure that data point(s) for such output products required according to the semantic model may be included in the generated output product data set. The one or more rule(s) may be defined by the mandatory output product data points present within the semantic model. The one or more rule(s) may be generated based on the mandatory output product data points present within the semantic model. This may ensure that output product data required by the semantic model is included in the generated output product data set. The one or more rule(s) may hence be generated or defined by the semantic model associated with the product produced from the output product(s) as input materials. The one or more rule(s) may hence not be derived or generated based on a semantic model associated with the produced output products. This may allow to avoid generation of complex semantic models for produced output products but may instead allow to use existing semantic models of product(s) for generation of rule(s) to transform gathered output product data to output product data set(s).

[0132] The rule-based engine may operate on individual data point level, combination of data points or the whole gathered output product data. The operation of the rule-based engine may be defined by the one or more rule(s). The rule(s) may include or correspond to executable logic. The executable logic may be generated from a rule template including unstructured data associated with instructions related to validation operation(s). Rule(s) associated with individual data point(s) may include one or more rule(s) defining condition(s) for individual data points present with the gathered output product data. Use of such rule(s) allows to ensure that data point(s) required by the semantic model associated with the product are contained in the generated output product data sets. Rule(s) associated with multiple data points may include one or more rules defining required combination of data points. Use of such rule(s) allows to ensure 240990

[0133] 27 that combination(s) of data point(s) required by the semantic model associated with the product are contained within the generated output product data sets.

[0134] A rule-based engine may be used to validate at least part of the input material data gathered via the decentral network. The rule-based engine may be a software or software component that applies one or more rules to at least part of the gathered input material data. The rule-based engine used to validate at least part of the gathered input material data may include one or more rule(s) associated with product(s). The one or more rule(s) may be associated with or derived from a semantic model of the product. Hence, the one or more rule(s) may ensure that data point(s) for such input materials required according to the semantic model may be included in the gathered input material data. The one or more rule(s) may be defined by the mandatory input material data points present within the semantic model. The one or more rule(s) may be generated based on the mandatory input material data points present within the semantic model. This may ensure that input material data required by the semantic model is included in the gathered input material data, hence ensuring reliable and efficient generation of product passports using such validated input material data.

[0135] The rule-based engine may operate on individual data point level, combination of data points or the whole gathered input material data. The operation of the rule-based engine may be defined by the one or more rule(s). Rule(s) associated with individual data point(s) may include one or more rule(s) defining condition(s) for individual data points present with the gathered input material data. Use of such rule(s) allows to ensure that data point(s) required by the semantic model associated with the product are contained in the consumed input material data. Rule(s) associated with multiple data points may include one or more rules defining required combination of data points. Use of such rule(s) allows to ensure that combination(s) of data point(s) required by the semantic model associated with the product are contained within the consumed input material data.

[0136] The product passport may refer to a data set having a defined semantic structure. The defined semantic structure may be obtained by applying a semantic model, such as an aspect model, to validated input material data and product data associated with the respective product. The product passport may include a product identifier, at least one decentral identifier, validated input material data and product data (e.g. passport data). The product passport may include one or more authentication mechanisms associated with the decentral identifier(s), the validated input material data and the product data. The product passport may relate to one or more authorization mechanisms associated with the decentral identifier(s), the validated input material data and the product data. The one or more authorization mechanisms may include 240990

[0137] 28 authorization rules determining if access to the at least a part of the validated input material data and / or product data is granted. The product passport may be associated with one or more digital representations of the passport data. The digital representations may be regarded as access element(s) providing access to the product passport or parts thereof. The digital representation may include a decentral identifier and access data. The access data may include a locator or pointer, such as am url or uri, to a dedicated storage, such as a dedicated storage address, associated with the data owner of the product passport. The pointer or locator may point directly to the dedicated storage. The pointer or locator may point to a data providing network node associated with the dedicated storage. The access element may include one or more authentication mechanisms associated with the decentral identifier(s) and the access data. The access element may be associated with one or more authentication mechanisms associated with the decentral identifier(s) and the access data. The access element may be provided to a decentral registry storing access elements. The decentral registry may be associated with a data providing network node. This may allow to control access to such registry and access to access element(s) stored in such registry via the data providing network node. The decentral registry may be associated with a participant of the product ecosystem. The decentral registry may be associated with the data owner of the product passport. The decentral registry may be part of the decentral network but may not be associated with a particular participant of the product ecosystem, e.g. may be regarded as infrastructure node of the decentral network.

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

[0139] 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 240990

[0140] 29 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.

[0141] BRIEF DESCRIPTION OF THE DRAWINGS

[0142] In the following, the present disclosure is further described with reference to the enclosed figures. The same reference numbers in the drawings and this disclosure are intended to refer to the same or like elements, components, and / or parts.

[0143] FIG. 1 illustrates an example of a participant network of a product ecosystem including a material loop and being associated with a decentral peer-to-peer network for exchange of data associated with raw materials, chemical product(s), discrete product(s), end product(s) and recycled material(s).

[0144] FIG. 2 A illustrates an example system of providing a data structure defined by a data consumer for collecting output product properties and the data exchange via decentral network.

[0145] FIG. 2B illustrates another example system of providing a data structure defined by a data consumer for collecting output product properties and the data exchange via decentral network.

[0146] FIG. 2C illustrates another example system of providing a data structure defined by a data consumer for collecting output product properties and the data exchange via decentral network.

[0147] FIG. 3A illustrates an example of conditions integrated into a data structure.

[0148] FIG. 3B illustrates another example of conditions integrated into a data structure.

[0149] FIG. 4A illustrates an example of data structure provided by the data consumer.

[0150] FIG. 4B illustrates an example of the conditions.

[0151] FIG. 40 illustrates another example of data structure provided by the data consumer. 240990

[0152] 30

[0153] FIG. 5 A illustrates an example of a structural architecture including a central component and a plurality of data consumers and data providers acting as tenants of the central component.

[0154] FIG. 5 B illustrates another example of a structural architecture including a central component and a plurality of data consumers and data providers acting as tenants of the central component.

[0155] FIG. 6A illustrates a block diagram of a system for generating output product data set(s) associated with produced output product(s) and providing generated output product data set(s) for access by decentral data consuming nodes in accordance with one embodiment of the present disclosure.

[0156] FIG. 6B illustrates a diagram showing an example of gathering output product data and transforming at least part of the gathered output product data using a rule-based engine in accordance with one embodiment of the present disclosure.

[0157] FIG. 7 illustrates an example system and associated methods for generating output product data set(s) associated with produced output product(s) and providing access to the generated output product data set(s) in accordance with one embodiment of the present disclosure.

[0158] FIG. 8 illustrates a decentral system for accessing output product data set(s) associated with produced output product(s) in accordance with one embodiment of the present disclosure.

[0159] FIG. 9A illustrates a block diagram of a system for validating input material data associated with input material(s) used to produce a product in accordance with one embodiment of the present disclosure.

[0160] FIG. 9B illustrates a diagram showing an example of validating input material data associated with input material(s) used to produce a product using a rule-based engine in accordance with one embodiment of the present disclosure.

[0161] DETAILED DESCRIPTION

[0162] FIG. 1 illustrates an example of a participant network of a product ecosystem associated with a decentral peer-to-peer network for exchange of data associated with raw materials, chemical product(s), discrete 240990

[0163] 31 product(s), end product(s) and recycled material(s). The decentral participant network 134 may include one or more decentral network participants, such as decentral participants 102 to 114. The decentral network participants may be part of a product ecosystem including chemical products. The product ecosystem may include production chains to produce an end-product. 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. 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 end-of-life (EOL) product collector 112 and a recycler 114. The decentral participant network 134 may include a chemical supply chain. The product ecosystem may allow to use of recycled materials resulting from recycling of end-of-life products to produce new products, such as chemical products. The product ecosystem may be associated with the production and / or recycling 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. At least a part of the participant(s) of the decentral participant network 134 may be associated with the production of the product and / or the recycling of end-of-life products resulting from the use of the product by product users, such as end-product users 110. 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 decentral network participant may be associated with a decentral participant identifier. The decentral participant identifier may uniquely identify the decentral network participant within the decentral participant network 134. At least a further part of the participant(s) of the decentral participant network 134 may be associated with the generation of product passport(s). Such decentral participants may not be associated with the production of the product and / or the recycling of the end-of-life products. Such decentral participants may gather input material data and may generate product passports using at least a part of the gathered input material data. The generated product passports may be provided by such participants for access via the decentral network 134. For instance, recycler 114 may access such product passports to determine the composition of the end-of-life product, allowing adaption of the recycling process to the determined composition.

[0164] The participant(s) of the decentral participant network 134 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 240990

[0165] 32 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, 138 may correspond to the flow of product from one participant of the decentral participant network 134 to the downstream participant of the decentral participant network 134. The material flow 136, 138 may refer to a continuous or a discontinuous flow of product. The flow of product may include any means of transportation suitable to transport the product from a participant to the downstream participant. The means of transportation may include pipes, containers, barrels, packages. The material flow 138 may be associated with raw materials used to produce a chemical product, such as virgin raw materials. 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) and discrete product(s). 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. The recycled material may be provided from recycler 114 to chemical product producer 102 for the production of chemical product(s) using the recycled material.

[0166] At least part of the participants of the decentral participant network 134 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. 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 network 134 may be configured to perform data transactions 132. The data transactions 132 may be based on a 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 decentral network participants 102 to 114 may be established. The one or more authentication mechanism(s) may be associated with or linked to an identifier as described in the context of FIG. 8. The one or more authentication mechanism(s) associated with the identifier may be accessible by the decentral participant nodes as described in the context of FIG. 8. The decentral configuration allows for more efficient use of computing resources and strengthens control by the data owners of the decentral network. Data transactions between decentral network participant nodes may be based on an identifier associated with respective data to be accessed, for example as described in the context of FIG. 8. The identifier may be uniquely associated with the physical entity of the respective product and associated product data. The identifier may be a decentral identifier uniquely identifying the product within the decentral network. The identifier may be a local identifier used by the respective product producer to uniquely identify the 240990

[0167] 33 respective product. The identifier may be associated with further identifier(s), such as identifier(s) of production input(s) (e.g. input materials) used to produce the output product. This may allow to track the product input(s) used to produce a product, such as an end-product. The identifier may, for example, be included in an output product data set associated with the product.

[0168] The data flow 132 (e.g. transactions) between decentral network participant nodes may be directly or indirectly associated with the material flow 136, 138 between the decentral network participants. For instance, data flow 132 may be directly associated with material flow 136, 138 if data associated with an input 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, 138 if data associated with a chemical product produced by chemical product producer 102 is accessed by decentral participant node 128 associated with recycler 114. 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 and depends on the nature and form of the computing node.

[0169] At least part of the decentral participant nodes 116 to 128 may be decentral data providing network nodes. At least part of the participant nodes 116 to 128 may be decentral data consuming network nodes. A participant of the decentral participant network 134 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, end-product producer 108 may be associated with a decentral data providing network node configured to provide product data to a downstream participant (e.g. recycler 114). In addition to or alternatively, end-product producer 108 may be associated with a decentral data consuming network node configured to access data associated with a discrete product produced by an upstream participant (e.g. chemical product user 106) for example as described in the context of FIG. 8. The decentral network 134 may include further decentral network nodes. The further decentral network nodes may be decentral infrastructure service nodes (not shown in FIG. 1). The decentral infrastructure service nodes may not be associated with a participant of the product ecosystem. 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 240990

[0170] 34 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 possess 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 are used to verify the identity prior to performing a data exchange (not shown, refer to FIG. 8).

[0171] FIG. 2A to FIG. 2C illustrate some examples of sharing data structure and / or one or more conditions between the data consumer and the data provider to facilitate the generation of output product data set associated with an output product. Specifically, the data structure for collecting properties associated with the output product may be shared via a channel different from the decentral network. For instance, the data consumer may transmit the data structure via a central control unit (as described in Fig. 5A and Fig. 5B). Therein, the data consumer may create a data pipeline configured to request generation and provision of output product data sets by one or more provider tenants. The consumer tenant may create a data pipeline including data pipeline identifier, data pipeline specification and decentral identifier(s) associated with data providing node(s) requested to generated and provide the output product data sets via the decentral network. The data pipeline specification may relate to the data pipeline identifier and may include a target data storage for storing the output product data set to be provided, a data structure for requesting the product data by the data providing node(s) of the decentral network, one or more conditions for verifying the provided product data provided via the decentral network and / or decentral identifiers of data providing node(s) to provide the asset including product data. The data pipeline identifier and at least parts of the data pipeline specification including the data structure for providing the product data and / or decentral identifiers of data providing node(s) may be provided to the central control unit. Based on the decentral identifiers the central control unit may retrieve tenant identifiers related to the respective decentral identifier(s) from the configuration storage storing pairs of decentral identifiers and respective tenant identifiers. Based on the retrieved tenant identifier(s) the central control unit may send one or more request(s) for product data to the respective provider tenants(along with the data structure provided by the data consumer). The request may include the decentral identifier of the consumer node of the decentral network associated with the consumer tenant and at least part of the provided data pipeline specification such as the data structure for providing the product data. Based on such request(s) provider tenant(s) may 240990

[0172] 35 accept the request for data by the consumer tenant. The provider tenant(s) may generate the assets including the product data as specified by the received data structure. The provider tenant(s) may provide the generated asset for access by the consumer node associated with the consumer tenant through or via the decentral network.

[0173] The data consumer may provide conditions for verifying the output product data set provided by the data provider. The condition(s) may be shared with the data provider. The condition(s) may be integrated into the data structure (Fig. 2B, Fig. 3A). FIG. 3A shows an example of integrating the conditions into the data structure. The integrated data structure may be a table with specific fields representing output product attributes, such as "Battery Carbon Footprint," "Share of Battery Carbon Footprint," and "voltagejnin." Each field may be associated with a data type (e.g., Float, String) and / or a corresponding condition that defines the criteria for valid entries. For instance, the "Battery Carbon Footprint" must be a positive numerical value. The data type may be part of the conditions. FIG. 3B shows another example of integrating the conditions into the data structure. The data fields may be in the form of questions. The corresponding conditions (e.g., required for the corresponding input) may be Boolean value with evidence. The evidence may be any supporting document in an electronic file format. Such as PDF document, word document, excel file and similar types. The evidence may be one or more links to an accessible resource. The one or more condition(s) may indicate the type of the evidence. When data is entered into the table, each field's condition may be checked against the input. If any input violates its corresponding condition, an error may be flagged, preventing the output product data set from being generated. This ensures all entries in the table are consistent, accurate, and adhere to the defined standards. A rule-based engine may be employed at the data provider and / or data consumer to automate the verification process. This engine may utilize the predefined conditions associated with one or more field(s) in the integrated data structure. The engine may process incoming data entries by comparing them against the conditions derived from the integrated data structure. Upon receiving a new data entry, the rule-based engine may perform the following steps: Data Input: The user may submit a data entry for one or more fields in the integrated data structure. This may be done by directly filling out the data structure via a user interface configured for receiving user input. Alternatively, the user may first download the received data structure and upload the updated data structure to the system for further processing. Condition Extraction: The engine may extract the relevant conditions corresponding to the fields in the entry. One or more rules may be generated based on the extracted condition(s). Condition Evaluation: Each condition may be evaluated against the provided data: If the data satisfies all conditions, the output product data set may be generated and stored in the database. If any condition is violated (e.g., a negative value for "Battery Carbon Footprint", an invalid link as evidence), the engine may generate an error message indicating the specific field and nature of the 240990

[0174] 36 violation. Feedback Loop: The system may provide feedback to the user, allowing for corrections and resubmission of the data entry. The rule-based engine may automate the verification process, significantly reducing the time and effort required for manual checks. By enforcing uniform conditions, the system ensures consistent data quality across the application. The method can be easily scaled to accommodate additional fields and conditions as data requirements evolve. The feedback mechanism also aids users in understanding and rectifying verification errors, ensuring that the output product data set includes all verified data points required in a product passport generated based on the output product data set. This way, processing of the product associated with the passport may be improved.

[0175] The conditions may be obtained by the data provider from other sources (e.g., FIG. 2C), the conditions may be included in one or more standardized and / or pre-defined rules, for example, the conditions may be obtained from one or more regulatory or oversight entities associated with due diligence standards. By sourcing conditions directly from certain entities, it can be ensured that the conditions applied with the data compliance process are accurate, up-to-date and reflective of current due diligence requirements. Such entities may include but not limited to non-governmental organizations, regulatory agencies, industry bodies, or other standard-setting organizations that establish and monitor frameworks for due diligence practices. The system or apparatus may comprise a user interface configured for verification (e.g., verify button or similar interface element), which, upon activation, initiates a process to retrieve conditions from a third-party server. The system may analyze the one or more data fields (or key words) in the received the data structure. This analysis may include identifying specific question formats, terms or metadata that are unique to the conditions set by a known external entity, such as an NGO. The system may compare the identified data against a library of publicly accessible resources, such as databases or repositories maintained by the oversight entities. For instance, if the identified key words correspond to the keywords or structures commonly associated with a specific NGO’s due diligence framework, the system may determine that the questions fields may be aligned with that NGO’s standards. Once confirmed, the system may send an HTTP request to an external API associated with the third-party organization. This API may return a set of conditions, formatted in machine-readable data formatted (e.g., JSON or XML), defining the requirements for compliance verification. These conditions may be parsed and stored locally within the system’s database or cache for further processing. The system may then verify the user input (e.g., response to the questions) with the rule engine based on at least one rule derived from or checking the retrieved conditions. Data entry may include a Boolean input and may optionally be supplemented by supporting documents or links. Based on the conditions retrieved, the system may evaluate whether a “YES” response mandates additional documentation or if compliance is otherwise satisfied. If the user responses or the data retrieved from one or more database(s) meet the conditions, the system may confirm 240990

[0176] 37 the verification and may generate the output product data set. If the user responses (e.g., the updated data structure) do not comply, the system may generate a prompt indicating further action required, such as attaching additional documents. The conditions obtained from the external sources may be different from the conditions provided by the data consumer. In such cases, all the conditions may need to be satisfied.

[0177] FIG. 4A illustrates an example of data structure provided by the data consumer and FIG. 4B shows an example of the conditions. The data structure may be a structured template for collecting one or more properties of an output product as shown in Fig. 4A. The data structure may include or be associated with a product ID of the output product. By providing such a data structure, it is possible to ensure that the necessary data points required by the data consumer may be collected. Further, some of the property information may not be available during the production of the output product (such as the properties illustrated in FIG. 4G, such required properties may be collected in the form of questions). Such properties may be populated by manual entry of information by a user, where the user inputs data directly into the system or interface. The data structure may be populated by automatically retrieving data from one or more local or remote data bases associated with the data provider, where the system may automatically queries, extracts and inputs relevant data into the data structure. The data structure may be populated by automatically searching and retrieving data from external sources, including but not limited to publicly available databases, web-based resources, or internet-based data repositories, where the system identifies relevant data through automated searches and inputs the results into the data structure. The data structure may be populated using a hybrid approach, wherein a combination of the above mentioned approaches may be employed to populate the data structure.

[0178] Fig. 4B shows an example of conditions, which may be optionally provided at the data consumer to ensure the data quality and integrity. The conditions may define the required data type, allowable value range, allowable values for name, address, countries ZIP codes, format of the required supporting evidence etc. Further, some values contained in the data structure may contain links (e.g., URLs). Conditions may be implemented to ensure the links are functional, properly formatted, and lead to correct resource. For instance, the condition may check whether the value entered in the field adhere to the standard URL format (e.g., starting with http: / / or https: / / ). For example, the condition may use a regular expression to verify the format. The condition may check if the link is reachable or accessible by attempting to make a network request to the provided URL. For example, the system makes an HTTP request to the ULR and checks the response code. If the response is within the successful range, the link is deemed valid. If there is a failure response (e.g., HTTP 404, 500). The system flags the link as potentially broken. The condition may check if the link belongs to an approved domain (whitelisting,) or if it is on a disallowed list (blacklisting). For 240990

[0179] 38 example, the system may compare the domain of the URL to a predefined list of allowed or disallowed domains. If the link belongs to a whitelist domain, it passes the verification. The condition may verify whether the content at the link is of the expected type (e.g., text, image, PDF) or whether it matches certain criteria for content integrity. Hence, by obtaining such condition at the data consumer, besides facilitating and ensuring the quality of the generation of a product passport (all the required data points are present), the data integrity, safety, and reliability can be ensured.

[0180] FIG. 5 illustrates an example of a system architecture including a central component and a plurality of data consumers and data providers acting as tenants of the central component. The number of tenants connected to the central component may vary and the number illustrated in FIG. 5 is to be considered as a mere example and not limiting. For instance, the architecture may include more or less tenants. Likewise, the number of consumer environments and provider environments may vary compared to the number illustrated in FIG. 5. The tenants may be connected via communication interfaces to central control unit 210. Each tenant may be associated with a unique identifier (e.g. tenant ID) uniquely identifying the tenant within the system. Each tenant may further be associated with a decentral participant identifier of the entity associated with the tenant. The decentral participant identifier may comprise any identifier uniquely associated with a participant of the decentral network and / or with a production site of the participant of the decentral network. The decentral participant identifier may include letters and / or numbers. The decentral participant identifier may include one or more Universally Unique Identifier(s) (UUID(s)) and / or one or more Decentralized Identifier(s) (DID(s)). The decentral participant identifier may be associated with or may include a verifiable 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 decentral network. For instance, the issuer may make a claim about a consumer (e.g. the entity operating data consuming network node(s)) or a provider (e.g. the entity operating data providing network node(s)) the decentral participant identifier is associated with. The verifiable claim may include those claim(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 an 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 entity, for presentation to any relying party that relies upon the veracity of those claims, such as a decentral data provider. The signature of the verifiable claim may be validated with a public key associated with the claims issuer to determine that the respective entity is a trusted entity within the decentral network. The verifiable credential may be presented by a 240990

[0181] 39 decentral data consuming network node and may be used by a decentral data providing network node to verify that the decentral participant associated with the decentral data consuming network node is a trusted entity within the decentral network prior to providing access to data, such as output product data, hence ensuring that the output product data can be exchanged in a secure and controlled manner within the decentral network.

[0182] Each tenant may include one or more component(s), such as software component(s) and / or hardware component(s). The software component(s) may be modular unit(s) of software encapsulating a set of instruction(s). The software component(s) may be configured to interact with other components of the tenant. The component(s) may adhere to defined interfaces and protocols, to facilitate interaction with other components of the tenant. The software component(s) and / or the hardware component(s) may be connected via communication interfaces. Each tenant may be associated with at least one decentral node of a decentral network (see FIG. 1) allowing for peer-to-peer communication via such nodes between the tenants. The central component may act as a central control unit 210 and may allow centralized updating and / or configuration of component(s) included in the tenants, e.g. consumer environment 1 204 to provider environment 3 514. For instance, software update(s) of component(s) included in the tenant(s) may be provided to all tenant(s) via the central control unit 210. However, central control unit 210 may not store any output product data associated with output products produced or producible by production(s) operated by one or more entity / ies associated with the tenant(s).

[0183] The provider environments may include component(s), such as databases, configured to store data associated with created pipelines, such as pipeline identifiers linked to respective decentral participant identifier(s) of data consumer(s) consuming or intending to consume assets provided by the data provider via such pipelines. The data stored in the database may be updated based on message data received from central control unit 210. The provider environments may further include component(s) configured to execute instructions for generating output product data set(s) (e.g. asset(s)) associated with output product(s)) and for providing such asset(s) for access to data consumer environment(s) via the decentral network. In particular, the data provider may be configured to generate output product data set(s) based on a data model provided by a data consumer via a dedicated data pipeline. The data pipeline may be created by the data consumer. The output product(s) may be produced or producible by a production. The provider environments may be associated with such production. Providing such asset(s) may include linking policy data and contract data to the assets. Provider environments may include asset generation system(s). Provider environments may include asset validation system(s). The provider environments may include component(s) configured to generate a user interface presentation and to provide such user interface 40 presentation for display to a display device. The display device may display the user interface presentation as graphical user interface to a user. User interface presentations may be generated during generation of asset(s) to assist a user in the generation of assets and in the provision of the assets for access.

[0184] The consumer environment may comprise a database storing data associated with created pipelines, such as pipeline identifiers linked to respective decentral participant identifier(s) of data provider(s) providing assets consumed or to be consumed via such pipelines. Consumer environments, such as consumer environment 1 204, may include component(s) configured to execute instructions for triggering consumption of asset(s) from provider environments, component(s) configured to execute instructions for validating asset(s) consumed from provider environments and / or component(s) configured to execute instructions for generating product passport(s) associated with product(s) produced from input material(s) associated with the consumed asset(s) and / or component(s) configured to execute instructions for generating control and / or monitoring data for controlling and / or monitoring production of product(s) using the input material(s) associated with the consumed asset(s). The product(s) may be producible or produced by a production. Consumer environments may include asset validation system(s). Consumer environments may include asset generation system(s). Consumer environments may further include passport generation system(s). The provider environments may include component(s) configured to generate a user interface presentation and to provide such user interface presentation for display to a display device. The display device may display the user interface presentation as graphical user interface to a user. User interface presentations may be generated during triggering consumption of asset(s), during validation of consumed asset(s) and / or during generation of product passport(s).

[0185] The provider and / or consumer environments may further include component(s) configured to execute instructions for generating a data pipeline. Such component(s) may be included in the asset validation system(s) of provider environment(s). Such component(s) may be included in asset validation system(s) of consumer environment(s). The data pipeline may allow data consumer(s) to request data from data provider(s). The data pipeline may allow data provider(s) to offer generated assets to data consumer(s). The data pipeline may hence connect provider environment(s) with consumer environment(s). The data pipeline(s) generated by a data consumer may be associated with one or relate to one or more data provider(s) defined by the data consumer. Likewise, the data pipeline(s) created by the data provider may be associated with or relate to one or more data consumer(s) defined by the data provider.

[0186] The data pipeline may include any number of computational steps. The computational step(s) may be performed at the respective data provider environment(s) and / or the respective data consumer 41 environment(s) connected by the data pipeline. The computational step(s) may be defined by the user creating the data pipeline. The user may select one or more computational step(s) from a list of available computational step(s) upon creating the data pipeline. The computational step(s) may be predefined for given data pipeline(s) and the user may select a predefined data pipeline upon creating the data pipeline. A computation step may include a specified computation platform (e.g., Javascript, Kusto Query Language, SparkQL, Python, C#Linq), a specified input to the computational step, a specified computation for the computational step, a specified output schema, a specified output storage, or a combination thereof. A specified input to a computational may identify an input dataset or parameters thereof or a data source storing input datasets, on which the computational step will operate. For instance, the data source may store output product data and the input data set may be the output product data associated with a given output product for which an asset is to be generated. In another instance, the input dataset may correspond to input material data gathered via the decentral network from one or more data providers. In yet another instance, the input data set may correspond to validated input material data, aggregated validated input material data, decentral identifier(s) or a combination thereof. A specified computation for a computational step may identify one or more executable operations to be performed on a specified input to the computational step. A specified computation can be a template computation (e.g., map, reduce, fuse, unfold, append, filter, split, or the like, or more generally any type of arithmetic operation, aggregation, summarization, filtering, sorting, bounding, or other computation), a custom computation (e.g., identified from an existing set of assets or provided through an associated script editor), or a combination thereof. For instance, a computation may include transforming output product data into an output product data set by mapping the output product data to a data model associated with a product produced from the output product using a rule-based engine. A computation may include transforming an output product data set from one data format into another data format. For instance, the output product data may be provided by the data provider with a data model provided by a data consumer. Then transform the output product data from the data model provided by the data consumer to a data model associated with a product produced from the output product. A computation may include validating the output product data set in the new data format. A computation may include transforming a user input into policy data and / or a digital representation of contract data. A computation may include generating digital representation(s) of digital twin(s) of output product(s). A computation may include validating policy data and contract data linked to assets. A computation may include validating gathered input material data using a rule-based engine. A computation may include aggregating validated input material data associated with input material(s) used to produce a given product based on the identifier(s) associated with the product and / or the input material(s). A further computation may include transforming the aggregated input material data according to a data model to generate the product passport. A specified output schema for a computational step may define the form or 240990

[0187] 42 structure of the computational result of the step. For example, a specified output schema may include an identification of a particular component of a computational result (e.g., variable, array, vector, matrix, row, column, property) and one or more corresponding attributes (e.g., data type, description, dimensionality). The specified output schema may include a data format for the computational result.

[0188] Each data pipeline may be associated with a data pipeline identifier uniquely identifying the data pipeline within the respective provider and / or consumer environment. Each data pipeline may be associated with data related to the configuration of the data pipeline, such as computational step(s) included in the data pipeline, a specified input to each computational step, a specified computation for each computational step, a specified output schema and / or a specified output storage. The output storage may be predefined. The output storage may be selected by the user upon generation of the data pipeline. The data pipeline identifier and data related to the configuration may be stored in a data storage included in the tenant setting up the data pipeline. The data pipeline identifier may be used by the consumer environment to map gathered asset(s) to respective data pipeline(s), allowing to transform the asset(s) according to computational step(s) as defined by the respective data pipeline.

[0189] A tenant may be linked to or associated with one or more other tenants. A tenant may be linked to or associated with one or more other tenants by data pipeline(s) allowing to transfer assets between the tenants linked to or associated with each other. For instance and with reference to the example shown in FIG. 5, tenant 1 may be linked to or associated with tenant 2 and 3 via data pipeline(s) while tenant 4 may be associated with or linked to tenant 5 via one or more data pipeline(s). Assets may be transferred between tenants via a decentral network using decentral network node(s) associated with the tenants (not shown in FIG. 5, see FIG. 1). For instance, asset(s) such as output product data set(s) and / or product passport(s) associated with output product(s) may be exchanged between tenants, such as consumer environment 1 204 and provider environment 1 202 via the peer-to-peer communication(s) of the decentral network, for example as described in the context of FIG. 1 . This way, output product data set(s) and / or product passport(s) may be exchanged under control of the data owner of the respective output product data set / product passport despite the presence of the central control unit 210. Hence, configuration storage 504 of central control unit 210 may not store any data set(s) associated with product(s) produced, producible or consumed by entities associated with the tenants connected to central control unit 210. The architecture ensures that each tenant's data and processes are isolated while allowing the central unit to manage resources efficiently. 240990

[0190] 43

[0191] Configuration storage 504 may store configuration data per tenant including a linking between tenant ID of the tenant, decentral participant identifier(s) associated with the tenant and endpoint(s) of node(s) associated with the tenant. The decentral participant identifier and endpoint(s) may be provided to central control unit 210 upon registering the tenant with central control unit 210. Central control unit 210 may generate the tenant ID upon registering the tenant. Central control unit 210 may generate the configuration data by linking the tenant ID with the provided data. Central control unit 402 may provide the configuration data to configuration storage 504 for storage. Upon setting up a data pipeline by a tenant acting as consumer environment, data associated with the generated data pipeline, such as decentral participant identifier(s) of data provider(s) providing data via such data pipeline to the consumer environment, a data pipeline identifier and a decentral participant identifier related to the consumer environment and / or the tenant ID of the consumer environment, may be provided by the tenant to central control unit 210. Central control unit 210 may be configured to update the configuration data based on the received data associated with the generated data pipeline. Updating may include determining the configuration data associated with the tenant setting up the data pipeline by matching the decentral participant identifier related to the consumer environment or the tenant ID to decentral participant identifiers or tenant IDs included in the configuration data. Upon determination of the configuration data of the tenant, provided decentral participant identifier(s) of data provider(s) may be linked to the existing configuration data. Likewise, setting up a data pipeline by a data provider may trigger updating of configuration data of the data provider as previously described. The configuration storage 504 may hence store configuration data including a mapping for each tenant between the tenant ID, the decentral participant identifier related to the tenant associated with the tenant ID and decentral participant identifiers associated with data consumer(s) and / or data provider(s) consuming / providing data to such tenant. The mapping may further include endpoint(s) associated with or related to such tenant ID. For instance and with reference to FIG. 5, the configuration data for tenant 1 may include the tenant ID of tenant 1, the decentral participant identifier of the entity associated with tenant 1, such as end-product producer 108, the endpoint of the data consuming node associated with tenant 1 , optionally an endpoint of a data providing node associated with tenant 1 and decentral identifier(s) associated with entities providing data to tenant 1 , e.g. decentral identifier(s) of entities associated with tenant 2 and 3.The configuration data may hence be used to determine tenants linked to a given tenant based on data associated with such given tenant, such as the decentral participant identifier and / or the tenant ID.

[0192] In addition to the connection of the tenants via the decentral network, a tenant may be linked to other tenants via the central control unit 210. Central control unit 210 may be configured to receive message data from a sender tenant and to provide such message data to one or more recipient tenants based on the 240990

[0193] 44 configuration data stored in configuration storage 504. The message data may be provided to the recipient tenants upon request of the sender tenant. For providing message data to recipient tenants a sender tenant may sent a request to provide message data to one or more recipient tenant(s) to the central control unit 210. The request may include the decentral participant identifier of the sender tenant and the data to be provided to the other tenant, such as a data structure for collecting properties associated with the output product. The request may further include a pipeline identifier associated with the data pipeline the message data is related to. The request may be generated after providing the data structure for collecting properties associated with the output product. Central control unit 210 may be configured to determine the tenant ID of the recipient tenants based on the decentral participant identifier of the sender tenant using the configuration data stored in configuration storage 504. For instance central control unit 210 may determine tenant I D(s) of tenants linked to the decentral participant identifier included in the received request based on the mappings included in the configuration data stored in configuration storage 504. Central control unit 210 may be configured to provide the received message data to the tenant(s) associated with the determined tenant ID(s). In addition, central control unit 210 may be configured to enrich the received message data with configuration data. For instance, central control unit 210 may include the data pipeline identifier associated with the tenant ID of the sender tenant and / or the recipient tenant.

[0194] The central control unit 210 may be configured to provide message data to recipient tenants without an explicit request of a sender tenant. For instance, central control unit 210 may provide data indicating that a data consumer has set up a new data pipeline and is requesting assets to provider environment(s) designated by the data consumer. Such data may be provided to recipient tenants in response to data received by central control unit 210 that a new data pipeline was created. Central control unit 210 may determine the recipient tenant(s) as previously described. This way, data provider(s) may be notified about requests for assets by data consumer(s), allowing the data provider(s) to set up the data pipeline on their end to allow for efficient data exchange via the decentral network with the data consumer(s). Setting up the data pipeline at the provider environment may include providing output product data according to the data structure provided by the data consumer, generating asset(s) and providing the asset(s) for access. In another instance, central control unit 210 may provide message data indicating that a data provider has set up a new data pipeline offering asset(s) to one or more consumer environment(s) designated by the data provider. This way, data consumer(s) may be made aware of available data offers of data provider(s) without having to query the decentral network for such data, enabling a more efficient generation of product passports. 240990

[0195] 45

[0196] Fig. 5B illustrates another example of a system architecture including a central control unit, a plurality of data providing and / or consuming components acting as tenants of the central control unit and decentral network components acting as decentral data providing and / or consuming nodes.

[0197] Central control unit:

[0198] The central control unit may be communicatively connected to one or more tenants configured for data providing and / or consuming. The central control unit may be communicatively connected to one or more databases storing orchestration data and / or configuration databases storing configuration data. Orchestration data may relate to the orchestration of data pipelines configured by the one or more tenants configured for data providing and / or consuming. Configuration data may relate to the configuration of decentral network protocols and / or data models. The central control unit may be configured to orchestrate data pipelines configured by the one or more tenants. The data pipelines may be configured for generating assets (e.g., output product data set associated with the output product) to be provided and / or consumed via one or more decentral network protocols. The data pipeline may relate to a local data source associated with the tenant. The central control unit may receive and / or send requests to the one or more tenants configured for generating data pipelines for generating assets to be provided and / or consumed via one or more decentral network protocols. The requests may relate at least to the tenant identifiers, data pipeline identifiers and / or data pipeline specifications. The requests may not relate to the product data associated with the supply chain product and stored in the product data base associated with each tenant. Based on the tenant identifiers the central control unit may identify the tenant the request was received by and / or is to be send to. Based on the pipeline identifiers and / or specifications the tenant receiving requests may identify the data pipeline the request was received for. The staged data transfer concept utilizing the central control unit may be more apparent based on the following two scenarios as examples:

[0199] Consumer pipeline scenario:

[0200] For example, a consumer may request a specific data transfer from a provider. The consumer may include a consumer tenant in a local compute environment of the consumer and a decentral network node connecting such environment to the decentral network. The consumer tenant may generate a data pipeline configured to provide product data by one or more provider tenant(s). The consumer tenant may generate a data pipeline including data pipeline identifier, data pipeline specification and decentral identifier(s) of data providing node(s) requested to provide product data via the decentral network protocol. The data pipeline specification may relate to the data pipeline identifier and may include a target data storage for 240990

[0201] 46 storing the digital asset to be provided, a data model for providing the product data by the data providing node(s) of the decentral network, a data model for mapping the product data provided through the asset via the decentral network, one or more validation rules for validating the provided product data provided through the asset via the decentral network and / or decentral identifiers of data providing node(s) to provide the asset including product data. The data pipeline identifier and at least parts of the data pipeline specification including the data model for providing the product data and / or decentral identifiers of data providing node(s) may be provided to the central control unit. Based on the decentral identifiers the central control unit may retrieve tenant identifiers related to the respective decentral identifier(s) from the configuration storage storing pairs of decentral identifiers and respective tenant identifiers. Based on the retrieved tenant identifier(s) the central control unit may send one or more request(s) for product data to the respective provider tenants. The request may include the decentral identifier of the consumer node of the decentral network associated with the consumer tenant and at least part of the provided data pipeline specification such as the data model for providing the product data. Based on such request(s) provider tenant(s) may accept the request for data by the consumer tenant. The provider tenant(s) may generate the assets including the product data as specified by the received data model. The provider tenant(s) may provide the generated asset for access by the consumer node associated with the consumer tenant through or via the decentral network.

[0202] Provider pipeline scenario:

[0203] Further for example, a provider may request or offer consumption of a specific data transfer from a consumer. The provider may include a provider tenant in a local compute environment of the provider and a decentral network node connecting such environment to the decentral network. The provider tenant may generate a data pipeline configured to provide product data to one or more consumer tenant(s). The provider tenant may generate a data pipeline including data pipeline identifier, data pipeline specification and decentral identifier(s) of data consuming node(s) requested to consume product data via the decentral network. The data pipeline specification may relate to the data pipeline identifier and may include a source data storage storing the product data, a data model for providing the product data by the data providing node(s) of the decentral network, and / or decentral identifiers of data consuming node(s) to consume the asset including the product data. The provider tenant(s) may generate the assets including the product data as specified by the received data model. The provider tenant(s) may provide the generated asset for access by the consumer node associated with the consumer tenant through or via the decentral network. The data pipeline identifier and at least parts of the data pipeline specification including the data model for providing the product data and / or decentral identifiers of data consuming node(s) may be provided to the 240990

[0204] 47 central control unit. Based on the decentral identifiers the central control unit may retrieve tenant identifiers related to the respective decentral identifier(s) from the configuration database storing pairs of decentral identifiers and respective tenant identifiers. Based on the retrieved tenant identifier(s) the central control unit may send one or more request(s) for consuming product data to the respective consuming tenants. The request may include the decentral identifier of the provider node of the decentral network associated with the provider tenant and at least part of the provided data pipeline specification such as the data model for providing the product data. Based on such request(s) consumer tenant(s) may accept the request for data by the provider tenant. Depending on the envisaged product data transfer to be executed via the decentral network the central control unit orchestrates the data pipeline setup in the local environments of the tenants associated with decentral network nodes. The communication of the actual product data is hence not executed via the central control unit and the central control unit does not have access to such product data. Hence the product data is transferred only in peer-to-peer communication between nodes of the decentral network. The central control unit only ensures that the product data transferred via the decentral network adheres to the formats and content the provider and / or recipient of such data expect. This way the product data associated with the supply chain product is kept under full control of the data owner, such as the supply chain product producer.

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

[0206] FIG. 6A illustrates a block diagram of a system 646 for generating output product data set(s) associated with produced output product(s) and providing generated output product data set(s) for access by decentral data consuming nodes in accordance with one embodiment of the present disclosure. The output product may be a chemical product, an intermediate chemical product, a component or a component assembly. The output product may be a component of a battery, such as a battery cell, a battery module or a battery pack. With reference to FIG. 7, the output product 706 may be produced using one or more input material(s) 702. The output product may comprise or be any product produced by the production 704 and provided at any exit point of the production 704. The input material may include starting material used in a production process performed within production 704 to produce the output product. An input material can be used in any process step of the production process. This means, the intermediate output product of the one production plant of production 704 can correspond to the input material of a subsequent production plant of production 704. Input material may include recycled material. The input material may comprise or 240990

[0207] 48 be any input material entering the production 704. The input material may comprise or be any input material provided at any entry point of the production 704.

[0208] The output product may be produced via one or more process steps from the input material(s) 702 within production 704. The process steps may involve chemical reactions and / or physical processes and / or assembly processes involving the assembly of different discrete input material(s) and / or processes involving chemical input materials and discrete input materials, such as filling processes. The input material may be used in one or more of such production step(s). The input materials 702 may enter the system boundary 714 of the production 704 at the entry point, such as a production plant or a material storage associated with the production 704. The amount of input material entering the system boundary 714 of the production 704 may be measured, for example using sensor 708a. Sensors 708a include sensors configured to measure an amount of input material, such as a weight and / or a volume. Chemical and / or physical properties of the input material may be measured, for example using sensor 708b, upon passing system boundary 714 of the production 704. The measured data may be used to determine at least one chemical and / or physical property of the respective input 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, chemical composition, recyclate content used for producing or manufacturing the input material, bio-based content used for producing or manufacturing the input material, renewable content used for producing or manufacturing the input material, biodegradability, and / or pH value. Examples of physical properties include absorption, brittleness, boiling point, capacitance, color, concentration, density, ductility, distribution, efficacy, elasticity, electric charge, electrical conductivity, electrical impedance, electric potential, flow rate, fluidity, hardness, heat capacity, inductance, intrinsic impedance, luminance, luminescence, luster, mass, melting point, opacity, permeability, permittivity, plasticity, pressure, radiance, resistivity, reflectivity, refractive index, solubility, specific heat, strength, stiffness, temperature, tension, thermal conductivity, thermal resistance, viscosity, volume and / or wave impedance.

[0209] An operating system 716 of the production 704 may monitor and / or control the production 704 based on operating parameters of the different processes. The operating system 716 may receive production demand data associated with the production planning for the production 704. The production demand data may be produced from target production capacities for one or more output product(s) produced by the production 704. The production demand data may be produced from pre-defined production capacities or data-driven models that relate production capacities to market demand data or quantities consumed at the consumption location. The production demand data may include target capacities for output products 240990

[0210] 49 produced by the production 704. The operating system 716 may further receive a bill of materials associated with output products to be produced. The bill of materials may include material data associated with the input materials used to produce the output product, process data associated with the production chain for producing the output product and / or output product data associated with the output product, such as a product specification data or data on the amount of output product to be produced.

[0211] Based on the received production demand data and the bill of materials, material demand data may be determined. The material demand data may include data on the amount of input material required to produce the target capacities of output product. The material demand data may include input material identifiers associated with input materials required to produce the output product and data on amounts of input material for respective input materials. The material demand data may include one or more material specifier(s) per input material identifier signifying the material specification. The material demand data may include data on the material amount per input material identifier signifying the amount of material to be supplied. The material demand data may specify the production chain(s) of the production 704. The material demand data may include a bill of materials for one or more production chain(s) of the production 704. The material demand data may include one or more recipe(s) specifying one or more material(s) for production process(es) of the production 704. The determined material demand data may be provided for access by a supplier system associated with a supplier outside the physical system boundary of the production 704. Material supply may be triggered by the supplier system accessing the material demand data.

[0212] The amount of output product(s) resulting from processes performed within production 704 may be measured using a sensor, such as sensor 708b. The measured data may be stored in one or more databases associated with operating system 716. Moreover, processes performed within production 704 may be monitored using sensors, such as sensors 708b, and the generated monitoring data may be stored in one or more databases associated with operating system 716. The monitoring data may be interrelated with a digital output product identifier associated with the respective output product. Physical and / or chemical properties of produced output products may be measured by sensors, such as sensors 708a. Physical and / or chemical properties may include the properties previously described. The measured and / or determined chemical and / or physical properties of the produced output products may be stored in one or more databases associated with operating system 716. The measured and / or determined chemical and / or physical properties of the produced output products may be interrelated with a digital output product identifier associated with the respective output product. The produced output products 706 may be provided at one or more exit points of the production 704. The output product 706 may exit the system 240990

[0213] 50 boundary 714 of the production 704. The operating system 716 may include asset generation system 646. The operating system 716 may be associated with asset generation system 646 (not shown). Asset generation system 646 may be configured to generate output product data set(s) (e.g. asset(s)) associated with output product(s) produced by production 704.

[0214] Referring back to FIG. 6A and with continued reference to FIG. 7, the asset generation system 646 may generate output product data set(s) in response to receiving a trigger. The trigger may be associated with or may include trigger data. The trigger data may include data associated with the output product produced by production 704. The trigger may be generated by trigger generator 712. Trigger generator 712 may be part of a packaging line or may be present within a storage location, such as a warehouse. Trigger generator 712 may include sensor(s) configured to detect produced output product(s) and / or packaged output products. The sensor(s) may be configured to detect an identification element physically attached to the produced output product or the packaged output product. The sensor data may be used by trigger generator 712 to generate trigger data including data associated with the produced output product. Data associated with the produced output product may include a digital output product identifier associated with the produced output product. The trigger may be generated by a user, for example using a front-end application allowing to generate trigger data. The front-end application may display data associated with produced output products, such as output product name(s), output product quantities, output product identifiers, etc. The data associated with the output product may be gathered from the one or more databases storing such data. The user may select output product(s) displayed by the front-end application. In response to selecting output product(s), a back-end application connected to the front-end application may generate the trigger data by collecting digital output product identifier(s) associated with the selected output product(s). The collected digital output product identifier(s) be used to generate the trigger data.

[0215] The trigger or trigger data may be received by data gathering unit 622 of asset generator service 606. Data gathering unit 622 may be connected to a data source layer 620. The data source layer 620 may include one or more databases, such as DB 1 614, DB 2 616 and DB 3 618. The databases may be distributed data sources. The distributed data source may be a data lake comprising output product data from a plurality of distributed data sources. A distributed data source may be a collection of data stored at different sites of a computer network. Each site might expose a degree of autonomy, providing services for the execution of local applications, but also participating in the execution of a global application. For instance, a distributed data source may be a distributed database. A distributed database can be created by splitting and scattering the data of an existing database over different sites or by federating together multiple existing databases. Each data source may contain only a fragment of the data associated with the chemical 240990

[0216] 51 product. This leads to a fragmentation of said data. Two common types of data fragmentation are horizontal fragmentation, wherein (possibly overlapping) subsets of data tuples are stored at different sites; and vertical fragmentation, wherein (possibly overlapping) subtuples of data tuples are stored at different sites. More generally, the data associated with the output product may be fragmented into a set of relations (tables of a relational database, distributed across multiple sites). The one or more distributed data sources may contain output product data associated with produced output products. The output product data may include supplementary data provided by user input. The supplementary data may be related to properties associated with the output product which are not directly detectable. The output product data may include output product identifier(s), property data associated with the output product, the output product name, the output product producer, output product declaration data, output product safety data, emission data associated with the output product, recyclate content data associated with the output product, biobased content data associated with the output product, production data associated with the output product, certificate of analysis data associated with the output product, certificates associated with the output product, life cycle data associated with the output product, storage instruction data associated with the output product, assembly instructions associated with the output product, operating conditions associated with the output product or a combination thereof. At least one of the distributed data sources may contain data instances that relate to the output product for which the system 710 is configured to generate the output product data set(s). The data source layer 620 may be owned or controlled by the data owner of the data associated with output product data. The data source layer 620 may be associated with the data owner of the output product data. Data gathering unit 622 may be configured to gather output product data based on received trigger data (e.g. data associated with produced output products) from the data source layer 620. The gathered output product data may include property data associated with the output product, the output product name, the output product producer, output product declaration data, output product safety data, emission data associated with the output product, recyclate content data associated with the output product, biobased content data associated with the output product, production data associated with the output product, certificate of analysis data associated with the output product, certificates associated with the output product, life cycle data associated with the output product, storage instruction data associated with the output product, assembly instructions associated with the output product, operating conditions associated with the output product or a combination thereof. Data source layer 620 may be configured to gather data from a user via a front-end application allowing to upload output product data. The output product data may be provided in a data format given by the data consumer so that validation (both at the data consumer and the data provider) can be applied at scale. The front-end application may display data associated with produced output products, such as output product name(s), output product quantities, output product identifiers, or implicit (supplementary) properties of the output product which may 240990

[0217] 52 not be directly detectable during the production etc. The output product data associated with the output product may be stored in the one or more databases. The user may select output product(s) or output product data displayed by the front-end application. In response to selecting output product(s), a back-end application connected to the front-end application may start generating assets associated with the selected output product.

[0218] The output product data gathered by data gathering unit 622 may be provided to data transforming unit 624. Data transforming unit 624 may be configured to generate output product data set(s) by transforming output product data gathered by data gathering unit 622 based on one or more rule(s) retrieved from rule DB 612, for example as described in the context of FIG. 6B. Transforming may include filtering the gathered output product data, aggregating output product data gathered from multiple data sources into a given format, attribute construction to create or add new attributes to the output product data based on existing attributes, discretization to convert continuous output product data values into sets of data intervals with specific values, generalization of gathered output product data to convert low-level data attributes into high-level data attributes, manipulation to change or alter gathered output product data and / or normalization to converts output product data into another format to limit the occurrence of duplicated data. The rule(s) may define key-value pair(s) to be included in the generated output product data. The rule(s) may define value(s) to be included in the generated output product data. The rule(s) may define unit(s) for data point(s) and / or one or more conversion(s) to convert a unit associated with a data point into another unit. The rule(s) may define key-value pair(s) for property data, output product identifier data, output product name data, output product producer data, output product declaration data, output product safety data, emission data, recyclate content data, biobased content data, biodegradability data, production data, certificate of analysis data, certificate data, life cycle data, storage instruction data, assembly instruction data and / or operating condition data. A rule may define key-value pairs for per data category. A rule may define key-value pairs for at least two different data categories. A data category may signify property data, declaration data, safety data, emission data, recyclate content data, biobased content data, biodegradability data, production data, certificate of analysis data, certificate data, storage instruction data, assembly instruction data or operating condition data. Gathered data may be aggregated and filtered to extract the value(s) matching the key(s) defined in the rule(s) from the aggregated data. The generated output product data sets may include one or more data points. The output product data sets may include one or more key-value pairs. The generated output product data sets may include at least a part of the gathered output product data. The generated output product data set(s) may include output product property data point(s), output product identifier data point(s), output product name data point(s), output product producer data point(s), output product declaration data point(s), output product safety data point(s), 240990

[0219] 53 output product emission data point(s), output product recyclate content data point(s), output product biobased content data point(s), output product biodegradability data point(s), output product production data point(s), output product certificate of analysis data point(s), output product certificate data point(s), output product life cycle data point(s), output product storage instruction data point(s), output product assembly instruction data point(s) and / or output product operating condition data point(s). The output product data set(s) may include at least a part of the gathered output product data in tabular form. Use of rule(s) associated with a product produced from such output product(s) allows to ensure that output product data point(s) required according to a data model, such as an aspect model, associated with the product are contained in the output product data set, hence avoiding missing data point(s) during generation of a product passport associated with the product using said data model. The transformation allows to aggregate the gathered output product into a given data format, such as a tabular format, without the use of complex semantic models, hence facilitating generation and sharing of output product data set(s) within the product ecosystem. Such sharing may enable more efficient production and / or recycling processes based on the shared output product data, for instance output product composition data. The tabular format can be readily consumed via a decentral network by a consumer backend configured to verify the consumed data and to persist verified consumed data to data storages for generation of product passports. Verification by the consumer side ensures that the product passport contains all data required by a semantic model used to generate such passport, hence allowing to reduce the complexity associated with the output product data set generation at the provider side by avoiding the use of complex semantic models during generation of the output product data set(s). This may enable reliable sharing of output product data of output product(s) irrespective of the existence of semantic models for such output products since the rule(s) required to transform the gathered output product data may be readily derived from existing semantic model associated with the product.

[0220] Data transforming unit 624 may further be configured to provide the generated output product data set(s) (hereinafter also referred to as asset(s)) to data provider unit 644. Data provider unit 644 may be configured to provide the received output product data set(s) to a database for storage, such as assets DB 604. The asset(s) may include or be associated with the digital output product identifier associated with the output product. This may allow to retrieve the asset based on the digital output product identifier. The asset(s) may be persisted by data transforming unit 624 in assets DB 604. Assets DB 604 may be configured to store output product data set(s) generated by data transforming unit 624. Assets DB 604 may be configured to provide output product data set(s) to data transfer service 602. Data provider unit 644 may further be configured to provide data included in the generated output product data set(s), such as the digital output product identifier, to asset publisher service 608. 240990

[0221] 54

[0222] Asset publisher service 608 may be configured to generate group access data associated with the respective output product data set. The group access data may identify access control groups including decentral participant identifier(s) associated with decentral network participants permitted to access at the respective output product data set. The group access data may include a group access data identifier. The group access data may further identify one or more authorization rule(s) defining access to and / or usage of the output product data set. Asset publisher service 608 may further be configured to generate a contract template including the digital output product identifier and the group access data identifier. The contract template may hence be associated with the output product data set as well as respective group access data. The contract template may further include access data associated with assets DB 604. The access data may include a locator or pointer to the assets DB 604 storing the respective output product data set. This may allow to access the respective output product data set based on data included in the contract template, e.g. the digital output product identifier and the access data. The group access data and contract template may be generated by asset publisher service 608 per data included in the output product data set, for example per digital output product identifier. The generated group access data and contract template may be provided to decentral data providing node 118 connected to asset generation system 646.

[0223] Decentral data providing node 118 may be part of a decentral network, such as decentral network 134 described in the context of FIG. 1 . Decentral data providing node 118 may be configured to provide output product data set(s) in response to a request received from decentral data consuming node(s), for example as described in the context of FIG. 8. Decentral data providing node 118 may be configured to control access to output product data set(s) based on associated group access data and contract template generated by asset publisher service 608, for example as described in the context of FIG. 8. Decentral data providing node 118 may be associated with a participant of the product ecosystem, such as a producer of the output product(s).

[0224] Data transfer service 602 may be configured to gather output product data set(s) from assets DB 604 in response to a request from decentral data providing node 118. Data transfer service 602 may be configured to fetch asset metadata from assets DB 604 based on data received from decentral data providing node 118. Data transfer service 602 may be configured to parse the fetched metadata to determine group access data associated with the respective output product data set and / or the storage location of the respective output product data set. Data transfer service 602 may be configured to gather respective output product data set(s) from assets DB 604 based on the fetched metadata. Data transfer 240990

[0225] 55 service 602 may be configured to provide the gathered output product data set(s) to decentral data providing node 118.

[0226] The system may not comprise a decentral registry storing access elements allowing access to the output product data set(s) stored in assets DB 604. Hence, output product data set(s) may not be located by querying the decentral network using the digital output product identifier but may only be accessed directly from decentral data providing node 118 using the digital output product identifier. Hence, location data pointing to the dedicated storage storing the output product data set as well as the output product identifier may be required to access the respective output product data set. The location data in combination with the digital output product identifier of the output product data set may result in a unique identifier allowing to uniquely identify a given output product data set within the decentral network.

[0227] FIG. 6B illustrates a diagram showing an example of gathering output product data and transforming at least part of the gathered output product data using a rule-based engine in accordance with one embodiment of the present disclosure. Transforming at least a part of the gathered output product data may result in generation of output product data set(s) as described in the context of FIG. 6A.

[0228] Data transforming unit 624 may include rule based engine 628. The rule based engine 628 may operate on individual data point(s), multiple data point(s) and / or the gathered output product data. The rule based engine 628 may operate on data gathered per digital output product identifier individually. This allows to transform gathered output product data per output product, hence allowing a more granular transformation of the output product data. Rule based engine 628 may receive a request to transform gathered output product data. The request may contain at least a part of the gathered output product data. Output product data may be gathered (see operation 626) by data gathering unit 622 from a data source layer 620 as described in the context of FIG. 6A. Rule based engine 628 may be configured to determine output product identifier(s) associated with the output product data. For instance, rule based engine 628 may parse the received output product data to determine the respective output product identifier(s). The rule based engine 628 may have access to one or more rule(s). The rule based engine 628 may include one or more rule(s). The one or more rule(s) may be present within a rule template. The one or more rule(s) may be stored in a data storage, such as rule DB 612. The one or more rule(s) or rule template(s) may be provided to rule DB 612 by a user. The one or more rule(s) may correspond to unstructured data associated with instructions related to transformation operation(s). The rule template(s) may correspond to unstructured data associated with instructions related to transformation operation(s). The one or more rule(s) or the rule template may be included in a file provided by the user. The one or more rule(s) or the rule template(s) may 240990

[0229] 56 be associated with output product type identifier(s) and / or output product data identifier(s). Rule based engine 628 may generate a request to obtain one or more rule(s) from rule DB 612. The request may contain the respective output product identifier(s).

[0230] One or more rule(s) associated with the received data structure to be transformed or one or more rule(s) associated with the output product data to be transformed (e.g. one or more applicable rule(s)) may be provided to rule based engine 628 in response to the request. The one or more rule(s) may be associated with product(s) produced from the output product associated with the output product data to be transformed, e.g. the output product associated with the output product data to be transformed may be used as input material to produce the product. The product may be a component. The product may be a component-assembly. The product may be an end product. The product may be a chemical product. The one or more rule(s) may be associated with or derived from a data model provided by a data consumer or a semantic model of the product. Hence, the one or more rule(s) together with the given data structure provided by the data consumer may ensure that data point(s) for such output products required according to the semantic model may be included in the generated output product data set. The one or more rule(s) may be defined by the mandatory output product data points present within the semantic model. The one or more rule(s) may be generated based on the mandatory output product data points present within the semantic model. This may ensure that output product data required by the semantic model is included in the generated output product data set. The one or more rule(s) may be associated with output product identifier(s) and / or output product type identifier(s). A mapping table may be used to map output product identifier(s) to corresponding output product type identifier(s). The output product type identifier(s) may be associated with output product type(s). The mapping table may be stored in a separate database (not shown). Rule based engine 628 may be configured to gather output product type identifier(s) based on determined output product identifiers) and to request rule(s) based on the gathered output product type identifier(s). This may allow to gather rule(s) associated with output product type identifier(s) based on output product identifier(s), hence avoiding generation of rule(s) per output product identifier and reducing the number of rule(s) that need to be generated, stored and maintained in rule DB 1318.

[0231] The one or more rule(s) may define aggregation rule(s) for aggregating output product data gathered from multiple data sources into a given format. The given format may be a tabular representation. Aggregation may hence result in filling gathered output product data into a tabular format. The one or more rule(s) may define filters to filter gathered output product data. The filters may be associated with or relate to the semantic model of the product. The filters may define data point(s) to be included in the generated output product data set. For instance, a filter may define one for more output product property data point(s), output 240990

[0232] 57 product identifier data point(s), output product name data point(s), output proudct producer data point(s), output product declaration data point(s), output product safety data point(s), output product emission data point(s), output product recyclate content data point(s), output product biobased content data point(s), output product biodegradability data point(s), output product production data point(s), output product certificate of analysis data point(s), output product certificate data point(s), output product life cycle data point(s), output product storage instruction data point(s), output product assembly instruction data point(s) and / or output product operating condition data point(s). A filter may define data point(s) per data category. A filter may define data point(s) for at least two different data categories. A data category may signify property data, declaration data, safety data, emission data, recyclate content data, biobased content data, biodegradability data, production data, certificate of analysis data, certificate data, storage instruction data, assembly instruction data or operating condition data. This may ensure that output product data required by the semantic model is included in the generated output product data set. The one or more rule(s) may define attribute construction(s) to create or add new attributes to the gathered output product data. The one or more rule(s) may define manipulation(s) to convert output product data point(s). For instance, data point(s) present within the gathered output product data may be converted from one unit into another unit. This may ensure that the generated output product data set includes data points associated with a unit required by the semantic model of the product. The one or more rule(s) may include a trigger condition and a corresponding group of one more actions. The trigger conditions may involve a set of variables, sometimes called “working memory”, which may contain data (sometimes called “facts” or “data tuples”) representing the states of pertinent real-world items. The one or more action(s) may include attribute construction, filters and / or manipulations. A given output product identifier and / or output type identifier may be associated with rule(s) defining aggregation, rule(s) defining filters, rule(s) defining attribute construction, rule(s) defining manipulations and / or rule(s) including a trigger condition and action(s). The rule(s) may be associated with a given order.

[0233] Rule based engine 628 may be configured to initialize the rule engine (see operation 632). Initialization of the rule engine may include generating rule data executable by a processor included in rule based engine 628. The rule data may include or correspond to executable logic. This may allow to transform rule(s) or rule template(s) present in unstructured data form into code that can be executed by the processor. Execution of the code may result in applying the executable rule data to the gathered output product data (see operation 634) to transform the output product data according to the obtained rule(s). Execution of the logic may result in matching gathered output product data to condition(s) included in the executable logic, evaluating the condition(s) with matched output product data and triggering execution of rule actions based on condition evaluation results. Transforming the output product data may include filtering gathered output 240990

[0234] 58 product data. Filtering the gathered output product data may include comparing individual data points present within the gathered output product data to data points defined by the filter(s) to determine output product data points to be included in the output product data set. Transforming the output product data may include comparing attributes of the gathered or filtered output product data to attributes defined in rule(s) to determine whether new attributes have to be created or added to the gathered or filtered output product data. In addition or alternatively, transforming may include comparing attribute(s) included in the gathered or filtered output product data or output product data including added or created attribute(s) to attribute(s) included in the modification rule(s). The modification rule(s) may include a trigger condition which may be associated with one or more action(s), for example unit conversion, if the trigger condition is satisfied and / or error handling if application of filters results in empty data points due to lack of data points in the gathered output product data. The trigger condition may be satisfied if the attribute(s) included in the gathered or filtered output product data or output product data including added or created attribute(s) are not matching attribute(s) defined in the modification rule(s). Operations performed by rule based engine 628 may be determined by rule(s) gathered from rule DB 612. For instance, rule(s) gathered from rule DB 612 may determine whether rule based engine 628 operates on individual data point(s) and / or multiple data point(s) and / or the whole gathered output product data.

[0235] Rule based engine 628 may be configured to determine whether the gathered output product data can be transformed by one or more applied rule(s) (see operation 636). Gathered output product data may not be transformed or only partially transformed (e.g. transformation may result in at least one error associated with applying one or more obtained rule(s) to the gathered output product data) if the gathered output product data does not include data point(s) required according to one or more obtained rule(s ). Rule based engine 628 may provide the generated output product data set to assets DB 604 responsive to the gathered output product data being successfully transformed (e.g. responsive to generation of an output product data set by applying one or more obtained rule(s) without resulting in an error. If at least a part of the gathered output product data could not be transformed, rule based engine 628 may proceed to operation 638. In operation 638, rule based engine 628 may generate message data indicating that at least part of the gathered output product data could not be transformed. The message data may include an indication which data point(s) of the gathered output product data could not be transformed. The message data may be provided to a display device configured to display data received from rule based engine 628. The display device may comprise a graphical user interface 640. The display device may display the message in response to receiving message data from rule based engine 628. This allows to trigger correction or updating of data point(s) identified as not matching one or more of the obtained rule(s). After 240990

[0236] 59 correction or updating of respectively identified data point(s), gathering and transformation of updated or corrected output product data may be initiated.

[0237] FIG. 8 illustrates a decentral system for accessing data associated with produced output product(s) in accordance with one embodiment of the present disclosure. The output product may be a battery component, such as a battery cell, a battery module or a battery pack. The output product may be a chemical product or an intermediate chemical product. The decentral system may be a decentral peer-to- peer network 134, 208 as described in the context of FIG. 1 .

[0238] The output product may be associated with output product data set(s). The output product data set(s) may be generated as described in the context of FIG. 6A to FIG. 7. The output product data set(s) may be stored in assets DB 604 associated with data transfer service 602. Assets DB 604 may be associated with a decentral provider node 118. The decentral provider node may be associated with a decentral network participant. The decentral network participant may be the producer of the output product. The decentral network participant may be the data owner of the output product data set(s) stored in assets DB 604. The output product data set(s) may represent at least a part of a digital twin of the physical entity of the output product. The digital twin may be a digital representation of the physical entity. The digital twin may hence represent a digital version of said physical entity. Once created, the digital twin may be used to represent the physical entity of the output product in a digital representation of a real-world system.

[0239] The decentral system may be used to gather input material data associated with input material(s) used to produce product(s). The input material data may correspond to output product data set(s) stored in assets DB 604. The decentral system may include one or more decentral participants, such as a data consumer and a data provider. The data consumer and the data provider may be connected via a decentral network, such as a decentral peer-to-peer network (see for example FIG. 1). The data provider may provide data, such as output product data, associated with an output product to data consumer. The data consumer may request input material data, such as the output product data, from the data provider. The data provider may correspond to an entity producing output products, such as chemical products or discrete products. The data consumer may correspond to an entity using the produced output product(s). The data provider may be associated with a data provider environment 808. The data consumer may be associated with a data consumer environment 802. The environments may include one or more node(s). The node(s) may be connected via peer-to-peer communication channels to allow data transfer between the nodes, as described in the context of FIG. 1 . The decentral system may include more or less environments than illustrated in FIG. 8. 240990

[0240] 60

[0241] The participants of the decentral network may be associated with decentral participant identifiers. Each participant of the decentral network may be associated with one or more decentral participant identifier(s). The decentral participant identifier may comprise any identifier uniquely associated with a participant of the decentral network and / or with a production site of the participant of the decentral network. The decentral participant identifier may include letters and / or numbers. The decentral participant identifier may include one or more Universally Unique Identifier(s) (UUID(s)) and / or one or more Decentralized Identifier(s) (DID(s)). The decentral participant identifier may be associated with or may include a verifiable 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 decentral network. For instance, the issuer may make a claim about a consumer (e.g. the entity operating data consuming network node(s)) or a provider (e.g. the entity operating data providing network node(s)) the decentral participant identifier is associated with. The verifiable claim may include those claim(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 an 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 entity, for presentation to any relying party that relies upon the veracity of those claims, such as a decentral data provider. The signature of the verifiable claim may be validated with a public key associated with the claims issuer to determine that the respective entity is a trusted entity within the decentral network. The verifiable credential may be presented by a decentral data consuming network node and may be used by a decentral data providing network node to verify that the decentral participant associated with the decentral data consuming network node is a trusted entity within the decentral network prior to providing access to data, such as output product data, hence ensuring that the output product data can be exchanged in a secure and controlled manner within the decentral network.

[0242] Data consumer environment 802 may include a consumer node 122 (e.g. decentral data consuming network node 122) and a consumer backend 804. Consumer backend 804 may include or correspond to the system illustrated in FIG. 9A and FIG. 9B. Consumer node 122 may be configured to communicate with consumer backend 804. Consumer node 122 may be configured to receive data from the consumer backend 804. Consumer node 122 may be configured to receive data from provider node 118. Consumer node 122 may be configured to request data from provider node 118. Consumer node 122 may be configured to provide data to provider node 118. Consumer node 122 may be configured to receive data 240990

[0243] 61 from the consumer backend 804 and configured to receive and / or request data from provider node 118. Consumer node 122 may be configured to gather output product data (also denoted as input material data hereinafter) stored in assets DB 604 associated with the provider node 118 of the data owner. Consumer backend 804 may be configured to send a request for data to consumer node 122. Consumer backend 804 may be configured to process output product data received from consumer node 122. Consumer backend 804 may be configured to send a data structure to a data provider via the central control unit 210 as described in Fig. 5. The data structure may include one or more data points in a given data format. The data points may be related to properties of the output product.

[0244] Data consumer environment 802 may be associated with a participant of the product ecosystem, such as product ecosystem illustrated in FIG. 1 . For instance, data consumer environment 802 may be associated with an output product producer, such as chemical product producer 102 or chemical product user 106, receiving input material(s) and producing output product(s) using the input material(s). Data consumer environment 802 may be associated with an entity performing the methods according to the claims. The entity performing such methods may be a participant of the product ecosystem. The entity performing such methods may not be a participant of the product ecosystem but may function as a service provider providing verified input material data for generation of product passports. The service provider may gather input material data from various provider environment(s) associated with input material data of input materials used to produce a given product, such as an end-product or a component thereof. The service provider may process the gathered input material data. The service provider may provide the processed input material data for generation of product passports.

[0245] Data provider environment 808 may include provider node 118, data transfer service 602 and assets DB 604. Data provider environment 808 may include the asset generation system 646 illustrated in FIG. 6A, FIG. 6B and FIG. 7. Data provider environment 808 may be associated with a data owner, such as a manufacturer producing the output product(s). Data provider environment 808 may include assets DB 604 storing output product data set(s) of produced output product(s). Assets DB 604 may be a dedicated storage associated with the data owner. The data owner may own such dedicated storage. The data owner may have access to such dedicated storage. Provider node 118 may be configured to provide data, such as output product data set(s) stored in assets DB 604. Provider node 118 may be configured to perform authentication and authorization step(s) prior to providing output product data. Provider node 118 may be coupled to data transfer service 602 configured to gather output product data set(s) from assets DB 604 in response to a request received from provider node 118 and to provide the gathered output product data set(s) to provider node 118. 240990

[0246] 62

[0247] FIG. 9A illustrates a block diagram of a system 1342 for validating input material data associated with input material(s) used to produce a product in accordance with one embodiment of the present disclosure. The input material(s) may be used as production input(s) in one or more process step(s) associated with the production of the product. The process step(s) may be performed by one or more entities. The product may be a discrete product, such as a component, a part, a component-assembly, an end product or a recycled material. The product may be a battery. The product may be a chemical product or a chemical intermediate product. Input material(s) may include chemical input materials and / or discrete input material(s). Discrete input material(s) may include part(s), component(s) and / or component assembly / ies. Chemical input material(s) may include raw materials, such as virgin material(s) and / or recycled material(s).

[0248] Asset validation system 1342 may include data transfer service 1302, stream storage system 1312 and data transforming unit 1304. Various databases, such as rule DB 1306, storage general 806 and storage application A 810 may be connected to data transforming unit 1304. The asset validation system 1342 may be connected to a decentral data consuming node, such as node 122. The asset validation system 1342 may be connected to a decentral data providing node, such as node 118 (not shown in the figure). The decentral data consuming node and / or the data providing node may be part of a decentral network, such as decentral network 134, 208 described in the context of FIG. 1. The decentral data consuming and / or providing node may be associated with a decentral participant. The decentral participant may be a participant of the product ecosystem associated with the product. The decentral participant may be a service provider providing validated input material data for generation of product passports, e.g. may not be a participant of the product ecosystem. With reference to FIG. 8, decentral data consuming node 122 may be configured to request access to output product data set(s) at provider node(s) associated with such output product data set(s). The output product data set(s) may correspond to the input material data to be validated by the system. The request may include the output product identifier associated with the output product data set(s) and a decentral participant identifier associated with the decentral participant operating consumer node 122. The request may be generated in response to data received from the system, for example received from data transfer service 1302. The data received from the system may include the output product identifier(s) and associated access data pointing to decentral provider node(s), such as provider node 118. The access data may include endpoint(s) associated with the decentral provider node(s), such as URI(s). The request may be generated per output product identifier and associated access data. The request received by the respective provider node(s) 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 240990

[0249] 63

[0250] TLS connection certificate (X.509v3) and a ‘Dynamic Attribute Token’ (OAuth Access Token), associated with the respective decentral participant nodes, e.g. consumer node 122 and provider node 118. If authentication fails, no output product data set(s) may be provided by respective data provider(s).

[0251] Provider node(s) may initiate contract negotiations with consumer node 122. Contract negations may be initiated upon successful authentication. Provider node(s) may provide electronic contract(s) to consumer node 122. The electronic contract may include one or more authorization rule(s) associated with the output product identifier. The electronic contract may further include the endpoint(s) associated with the output product data set(s). The endpoint(s) may point to the dedicated storage storing the respective output product data set(s), such as assets DB 604. The electronic contract may be generated by the provider node(s) based on group access data and a contract template associated with the respective output product identifier(s). The system may automatically accept the provided electronic contract(s). The system may be configured to parse the provided electronic contract(s) to determine the authorization rule(s) associated with the output product data set(s) to be gathered. Consumer node 122 may provide data being indicative of the signature, such as a token, to respective provider node(s). If the electronic contract is not signed, consumer node 122 may likewise forward data being indicative of declining the contract to the respective provider node(s). Upon declining the contract, respective provider node(s) may terminate the connection and may not provide any output product data set(s). Signature of such electronic contracts generated from group access data and a contract template associated with respective output product identifier(s) ensures that the consumer node 122 and further systems, such as asset validation system 1342, handling the provided output product data are complying to at least one authorization rule included in the electronic contract associated with the output product data set(s). This may ensure that the output product data set(s) may be exchanged in a secure and controlled manner, hence avoiding access to output product data set(s) by unauthorized decentral network participants while allowing to provide the output product data set(s) to decentral network participants required to use such provided output product data set(s), for example to control and / or monitor production of the product and / or to monitor and / or control recycling operations and / or to generate product passports associated with the products.

[0252] With continued reference to FIG. 8, data providing node(s) may provide output product data set(s) associated with output product data identifier(s) included in the request received from consumer node 122 upon signature of the electronic contract. The output product data set(s) may be gathered from a dedicated storage, such as assets DB 604 as described in the context of FIG. 6A. Returning to FIG. 9A, consumer node 122 may provide the received output product data set(s) (e.g. input material data) to data transfer service 1302. Data transfer service 1302 may be connected to stream storage system 1312. Stream 240990

[0253] 64 storage system 1312 may be connected to data transforming unit 1304. Data transforming unit 1304 may be positioned upstream from data transfer service 1302. Input material data gathered via the decentral network may flow through data transfer service 1302 and stream storage system 1312 to data transforming unit 1304. Data transfer service 1302 may be configured to receive input material data from consumer node 122. The input material data may represent a stream of data. Such a stream may be an ordered sequence of records received from consumer node 122 relatively continuously, i.e. not in accumulated batches or chunks. A record may for example comprise input material data associated with a given input material via an input material identifier. A record may be in a tabular representation. A record maybe in an object representation, e.g. using JSON, an XML document. A record may be defined as data that can be delivered continuously in small chunks or increments. The records may or may not be time-ordered. Data transfer service 1302 may be configured to generate data package(s) including the input material data received from consumer node 122. A data package may be generated by received input material data set. The data package may include further data, such as a time stamp, a date stamp, the input material identifier associated with the input material data, the decentral participant identifier associated with the provider node, location data pointing to the dedicated storage storing the output product data set or a combination thereof. The data package may represent a message or an event. The generated data package data may be provided to stream storage system 1312.

[0254] Stream storage system 1312 may be configured to store data packages received (e.g. pushed) from data transfer service 1302. The stream storage system 1312 may be configured to provide the stored data to data transforming unit 1304. The stream storage system 1312 may be configured to provide the stored data to data consuming unit 1308 of data transforming unit 1304. Stream storage system 1312 may comprise one or more persistent or non-persistent logs 1314, 1316. In this embodiment, stream storage system 1312 comprises two persistent or non-persistent logs 1314, 1316 (i.e. log 1 1314 and log 2 1316). Records stored in said logs may be ordered, for example by using IDs. This allows to identify a record within a specific log. A record may include a data package generated by data transfer service 1302. Stream storage system 1312 may provide a streaming service or stream processing service between one or more streaming sources (e.g. data transfer service 1302) and one or more streaming sinks (e.g. log 1 1314 and log 2 1316). Stream storage system 1312 may act as a persistent or non-persistent stream sink for input material data received from consumer node 122. For example, open-source software systems such as Apache Kafka ("Kafka") or Azure Event Hubs may act as a persistent stream sink. Stream storage system 1312 may be configured to pull input material data from data transfer service 1302. For instance, stream storage system 1312 may be configured to request input material data from data transfer service 1302 at regular time intervals. Stream storage system 1312 may be configured to determine if the received or 240990

[0255] 65 pulled input material data is already contained in the one or more persistent or non-persistent logs. If said input material data is already contained in the one or more persistent or non-persistent logs, stream storage system 1312 may not store the received or pulled input material data in said logs. If said input material data is not contained in one or more persistent or non-persistent logs or is an update, stream storage system 1312 may be configured to store the received or pulled input material data in the one or more persistent or non-persistent logs or to update input material data present in the persistent or non- persistent log(s) with the received or pulled updated input material data. This may avoid that the same input material data is stored multiple times in the persistent or non-persistent log(s), hence avoiding redundant validation operations on the input material data stored in stream storage system 1312.

[0256] Data transforming unit 1304 may be connected to the stream storage system 1312. Data consuming unit 1308 of data transforming unit 1304 may be connected to stream storage system 1312. Data consuming unit 1308 may be connected to one or more persistent or non-persistent logs (e.g. in this embodiment in log 1 1314 and log 2 1316) of stream storage system 1312 to ingest and process input material data stored within the log(s). The stream storage system 1312 may be in a publisher-subscriber relationship with the data consuming unit 1308. For instance, data in one or more the logs(s) may be periodically read (e.g. pulled) by data consuming unit 1308. To avoid consumption of a data package stored in a log several times, such data package may be marked as consumed by stream storage system 1312. To avoid consumption of a data package stored in a log several times, an integer indicating the offset of the next data package to consume may be used. Such integer may be just one number for each persistent or non- persistent log. Such integer may be periodically checkpointed. Use of such an integer may allow data consuming unit 1308 to re-consume data packages by rewinding the integer to an old offset. Data consuming unit 1308 may be connected to data validation unit 1310 of data transforming unit 1304. Data consuming unit 1308 may be configured to provide data packages gathered from stream storage system 1312 to data validation unit 1310 for validation of input material data included in said data packages. Data consuming unit 1308 may be configured to extract input material data from the data packages and provide the extracted input material identifier and input material data to data validation unit 1310. Data validation unit 1310 may be configured to validate input material data (e.g. data packages received from stream storage system 1312) based on one or more rule(s) retrieved from rule DB 1306, for example as described in the context of FIG. 9A. Validation may include applying one or more rule(s) retrieved from rule DB 1306 to the input material data. The input material data may be validated if at least a part of the applied rules are fulfilled. Applying the rule(s) to the input material data may include comparing the combination of input material identifier and location data to a database storing such combinations of input material identifier(s) and associated location data. Applying the rule(s) to the input material data may include comparing data 240990

[0257] 66 point(s) present within one or more rule(s) to individual data point(s) present within the input material data to be validated. Applying the rule(s) to the input material data may include checking if the links (e.g., web addresses for accessing supplementary output product data) is valid. Applying the rule(s) to the input material data may include comparing data point combination(s) defined in the rule(s) to data point combination present within the input material data to be validated. Applying the rule(s) to the input material data may include comparing the data defined in one or more rule(s) to the whole input material data to be validated. The one or more rule(s) may be associated with a product produced from the input material(s). The one or more rule(s) may be associated with a semantic model of the product. The semantic model may include a semantic description of the product passport associated with the product. The semantic description may include a semantic description of input material data and product data. The semantic description may include the structure of at least a portion of the product passport, and / or properties of the product passport. The properties of the product passport set may include data types. The properties of the product passport set may include possible or allowable values and / or value ranges. The properties of the product passport set may be a physical unit of parameter(s) described by values contained in the product passport. The data type(s) and associated value(s) and / or value range(s) of input material data may be included in the one or more rule(s). This may allow to verify whether gathered input material data fulfils the data type(s) and associated value(s) and / or value range(s) required for input material data according to the semantic model. The one or more rule(s) may define one for more input material property data point(s), input material identifier data point(s), input material name data point(s), input material producer data point(s), input material declaration data point(s), input material safety data point(s), input material emission data point(s), input material recyclate content data point(s), input material biobased content data point(s), input material biodegradability data point(s), input material production data point(s), input material certificate of analysis data point(s), input material certificate data point(s), input material life cycle data point(s), input material storage instruction data point(s), input material assembly instruction data point(s) and / or input material operating condition data point(s). The rule may define data point(s) per data category. The rule may define data point(s) for at least two different data categories. A data category may signify property data, declaration data, safety data, emission data, recyclate content data, biobased content data, biodegradability data, production data, certificate of analysis data, certificate data, storage instruction data, assembly instruction data or operating condition data.

[0258] By validating the input material data against one or more rule(s) generated from the semantic model, it may be ensured that input material data required by the semantic model is indeed included in the gathered input material data, allowing to ensure that product passport(s) generated from such validated input material data include all required input material data. The one or more rules may be generated from public information 240990

[0259] 67 from the internet. For example, by searching specific data point(s) from the input material data, comparing whether the information provided according to the input material data is consistent with the public information from the internet. Validation of gathered input material data on data point level may allow to reliably perform the validation irrespective of the format of the input material data. This may allow, in turn, to generate the input material data (denoted as output product data in FIG. 6A, FIG. 6B) without having to use complex semantic models. Instead, output product data set(s) may be generated in a tabular representation by the data providers and may be used by data validation unit 1310 for validation of data point(s) included in the output product data set(s) received as input material data by the data consumer side. The validated input material data generated by data validation unit 1310 may include one or more validated input material property data point(s), validated input material identifier data point(s), validated input material name data point(s), validated input material producer data point(s), validated input material declaration data point(s), validated input material safety data point(s), validated input material emission data point(s), validated input material recyclate content data point(s), validated input material biobased content data point(s), validated input material biodegradability data point(s), validated input material production data point(s), validated input material certificate of analysis data point(s), validated input material certificate data point(s), validated input material life cycle data point(s), validated input material storage instruction data point(s), validated input material assembly instruction data point(s) and / or validated input material operating condition data point(s). Data validation unit 1310 may further be configured to determine the storage location to which the validated input material is to be persisted. The storage location may be determined based on mapping data including a mapping between input material identifier(s) and associated storage location data. The storage location data may include endpoint(s) associated with said storage location(s). The storage location(s) may be identified by way of storage location identifier(s) included in the storage location data. Such identifier(s) may be used to gather endpoint(s) associated with such storage location(s). The mapping data may include a first mapping between input material identifier and input material type identifier and a second mapping between input material type identifier and associated storage location data. The mapping data may be stored in a database connected to data validation unit 1310 (not shown). Determining the storage location of validated input material data may allow to persist validated input material data in storage locations associated with given applications or systems(s). For instance, the validated input material data associated with a given product, such as a battery or a given chemical product, may be persisted in a storage location associated with a given application processing such validated input material data. Processing may, for example include generation of product passport(s) using such validated input material data. Validated input material data which may not be mapped to a given application may be persisted in a general storage, such as storage general 806. 240990

[0260] 68

[0261] Data validation unit 1310 may further be configured to provide the validated input material data to the determined storage location, such as general storage general 806 or storage application A 810, for storage.

[0262] The asset validation system 1342 may further include incident data generator 1344. Incident data generator 1344 may be configured to generate incident data based on non-validated input material data stored in a database, such as storage general 806. The non-validated input material data may be associated with a classifier indicating non-compliance with one or more applied rule(s). The classifier may include “not validated”, “not valid”, “validation failed” or “failed”. The classifier may be associated with each data point which could not be validated upon application of the one or more rule(s). Each data point which could not be validated may be associated with a respective input material identifier. Each data point which could not be validated may be associated with rule data indicating the rule that resulted in non-validation of the respective data point. The rule data may include the rule. The rule data may include the executable logic generated from the rule, for example as described in the context of FIG. 9B. Incident data generator 1344 may be configured to gather data point(s) associated with the classifier per input material identifier. Incident data generator 1344 may query the database for input material data associated with the classifier. Incident data generator 1344 may assemble gathered input material data into incident data based on the input material identifier associated with the gathered input material data. Incident data generator 1344 may provide the generated incident data to data transfer service 1302. Data transfer service 1302 may be configured to determine the provider node having provided the non-validated input material data. Data transfer service 1302 may be configured to initiate a transfer of the incident data to the determined node associated with asset generator system 606 generating the non-validated input material data (e.g. output product data set) via consumer node 122. The incident data may be provided to the node, such as provider node 118, using an endpoint of such node configured to receive data from other nodes of the decentral network. The endpoint may be provided by such node to data transfer service 1302 or a backend connected to data transfer service 1302. The endpoint may be stored in a ledger interrelating consumer node(s) with respective endpoints used for pushing incident data to such consumer nodes. The consumer node(s) may be identified by decentral participant identifier(s). Generation and provision of incident data associated with non-validated data point(s) may allow the data provider providing such non-validated data point(s) to generate updated output product data set(s), and to provide the updated output product data set(s). Hence, the use of incident data may ensure that non-validated input material data point(s) can be corrected by respective data providers such that the updated output product data set(s) generated by the asset generator service 606 associated with node 118 pass(es) the validation. This may result in efficient and reliable generation of validated input material data required to generate product passports and hence also in reliable generation of product passports. The product passports may allow to improve and / or control 240990

[0263] 69 production of further products using the product and / or recycling processes of end products produced from the product based on passport data contained in the product passports.

[0264] By generating incident data during generation of the output product data at the provider side if application of one or more rule(s) by the rule-based engine results in an error (e.g. conditions stipulated in such rule(s) are not fulfilled), updated output product data may be generated and provided to the consumer side. This allows to ensure that the generated output product data set(s) fulfil the one or more applied rule(s), avoiding validation errors at the consumer side. By generating incident data during validation of the output product data (e.g. input material data) at the consumer side, data providers may be enabled to generate updated output product data set(s) fulfilling the validation rule(s) used by the rule-based engine at the consumer side. By using the incident data at the provider side to update rule(s) included in the rule-based engine transforming the gathered output product data ensures that output product data set(s) fulfilling the validation rule(s) used at the consumer side is generated, hence reducing the occurrence of errors and delays in the generation of product passports.

[0265] FIG. 9B illustrates a diagram showing an example of validating input material data associated with input material(s) used to produce a product using a rule-based engine in accordance with one embodiment of the present disclosure. The input material data may be gathered via a decentral network as described in the context of FIG. 6A. The gathered input material data may correspond to output product data set(s) stored in a dedicated storage of a data provider environment, such as data provider environment 808 described in the context of FIG. 8. Data validation unit 1320 may include rule based engine 1322. The rule based engine 1322 may operate on individual data point(s), multiple data point(s) and / or the gathered input material data. The rule based engine 1322 may operate on data gathered per input material identifier individually. This allows to validate input material data per input material, hence allowing a more granular validation of the input material data. Rule based engine 628 may receive a request to validate gathered input material data. The request may contain at least a part of the gathered input material data. Data packages (e.g. messages or events) may be consumed from one or more log(s) of stream storage system 1312 (see operation 1338) by data consuming unit 1308 as described in the context of FIG. 9A. The consumed data packages may be extracted by data consuming unit 1308 (see operation 1346). The extracted input material identifier may be provided to rule based engine 1322. The rule based engine 1322 may have access to one or more rule(s). The rule based engine 1322 may include one or more rule(s). The one or more rule(s) may be present within a rule template. The one or more rule(s) and / or the rule template(s) may be stored in a data storage, such as rule DB 1318. The one or more rule(s) or rule template(s) may be provided to rule DB 1318 by a user. The one or more rule(s) may correspond to unstructured data associated with validation operation(s). 240990

[0266] 70

[0267] The rule template(s) may include unstructured data associated with instructions related to validation operation(s). The one or more rule(s) or the rule template may be included in a file provided by the user. The one or more rule(s) or the rule template(s) may be associated with input material type identifier(s) and / or input material identifier(s). Rule based engine 1322 may generate a request to obtain one or more rule(s) from rule DB 1318. The request may contain the respective input material identifier(s).

[0268] One or more rule(s) associated with the input material data to be validated (e.g. one or more applicable rule(s)) may be provided to rule based engine 1322 in response to the request. The one or more rule(s) may define data point(s) and / or combi nation(s) of data point(s) to be present within the consumed input material data, e.g. to be present within a consumed input material data set. The one or more rule(s) may be associated with product(s) produced from the input material associated with the input material data to be validated. The product may be a component. The product may be a component-assembly. The product may be a chemical product. The one or more rule(s) may be associated with or derived from a semantic model of the product. Hence, the one or more rule(s) may ensure that data point(s) associated with input material(s) and being required according to the semantic model may be included in the consumed input material data. The one or more rule(s) may be defined by the mandatory input material data point(s) present within the semantic model. The one or more rule(s) may be generated based on the mandatory input material data point(s) present within the semantic model. This may ensure that input material data required by the semantic model is included in the consumed input material data. The one or more rule(s) may define one for more input material property data point(s), input material identifier data point(s), input material name data point(s), input material producer data point(s), input material declaration data point(s), input material safety data point(s), input material emission data point(s), input material recyclate content data point(s), input material biobased content data point(s), input material biodegradability data point(s), input material production data point(s), input material certificate of analysis data point(s), input material certificate data point(s), input material life cycle data point(s), input material storage instruction data point(s), input material assembly instruction data point(s) and / or input material operating condition data point(s). The rule may define data point(s) per data category. The rule may define data point(s) for at least two different data categories. A data category may signify property data, declaration data, safety data, emission data, recyclate content data, biobased content data, biodegradability data, production data, certificate of analysis data, certificate data, storage instruction data, assembly instruction data or operating condition data. The one or more rule(s) may be associated with input material identifier(s) and / or input material type identifier(s). A mapping table may be used to map input material identifier(s) to corresponding input material type identifier(s). The input material type identifier(s) may be associated with input material type(s). The mapping table may be stored in a separate database (not shown). Rule based engine 1322 240990

[0269] 71 may be configured to gather input material type identifier(s) based on determined input material identifier((s) and to request rule(s) based on the gathered input material type identifier(s). This may allow to gather rule(s) associated with input material type identifier(s) based on input material identifier(s), hence avoiding generation of rule(s) per input material identifier and reducing the number of rule(s) that need to be generated, stored and maintained in rule DB 1318.

[0270] Rule based engine 1322 may be configured to initialize the rule engine (see operation 1326). Initialization of the rule engine may include generating rule data executable by a processor included in rule based engine 1322. The rule data may include or correspond to executable logic. This may allow to transform rule(s) or rule template(s) present in unstructured data form into code that can be executed by the processor. Execution of the code may result in applying the executable rule data to the extracted input material data (see operation 1328) to validate the consumed input material data according to the obtained rule(s). Execution of the logic may result in matching consumed input material data to data point(s) and / or combination(s) of data point(s) included in the executable logic, evaluating the data point(s) or combination(s) of data point(s) with matched input material data and generating validation result data based on the evaluation results. The validation result data may include a classifier and associated validated or non-validated input material data point(s). The classifier may be a binary classifier discriminating validated and non-validated input material data. Consumed input material data point(s) may be considered validated if one or more rule(s) applied by rule based engine 1322 are fulfilled. Applying the rule(s) to the consumed input material data may include comparing individual data point(s) present within the rule(s) to individual data point(s) present within the input material data to be validated to determine whether the input material data to be validated includes individual data point(s) required by such rule(s). Applying the rule(s) to the consumed input material data may include comparing data point combination(s) defined in the rule(s) to data point combination present within the input material data to be validated to determine whether the input material data contains data point combinations required by such rule(s). Applying the rule(s) to the consumed input material data may include comparing the data defined in the rule(s) to the whole input material data set to be validated to determine whether the input material data set contains all data required by such rule(s). Operations performed by rule based engine 1322 may be determined by rule(s) gathered from rule DB 1318. For instance, rule(s) gathered from rule DB 1318 may determine whether rule based engine 1322 operates on individual data point(s) and / or multiple data point(s) of the consumed input material data and / or the whole input material data.

[0271] Rule based engine 1322 may be configured to determine whether the consumed input material data fulfills one or more applied rule(s) (see operation 1330). Consumed input material data may not be validated or 240990

[0272] 72 only partially validated (e.g. validation may result in at least one error associated with applying one or more obtained rule(s) to the consumed input material data) if the consumed input material does not include data point(s) required according to one or more obtained rule(s). Rule based engine 1322 may indicate to data validation unit 1320 successful validation of the consumed input material data responsive to the determination that the consumed input material data is successfully validated (e.g. fulfils one or more obtained rule(s)). In response to receiving that indication, data validation unit 1320 may determine the target data storage where the validated input material data is to be persisted (see operation 1340). The target data storage may be determined as described in the context of FIG. 9A. If data validation unit 1320 determines that the validated input material data is not associated with a given application, data validation unit 1320 may provide the validated input material data to a storage not being associated with any application processing the validated input material data, such as storage general 806. If data validation unit 1320 determines that the validated input material data is associated with a given application, data validation unit 1320 may provide the validated input material data to a storage being associated with such application processing the validated input material data stored therein, for example by generating product passports. If at least a part of the consumed input material data could not be validated, rule based engine 1322 may indicate to data validation unit 1320 that at least a part of the consumed input material data could not be validated. In response to receiving the indication, data validation unit 1320 may generate message data (operation 1332). The message data may indicate that at least part of the consumed input material data could not be validated. The message data may include an indication which data point(s) of the consumed input material data could not be validated. The message data may be provided to a display device configured to display data received from data validation unit 1320. The display device may comprise a graphical user interface 1334. The display device may display the message in response to receiving message data from rule based engine 1322. This allows to trigger correction or updating of non-validated data points, for example by generating incident data as described in the context of FIG. 9A.

[0273] Rule based engine 1322 may be configured to provide non-validated input material data to a storage not being associated with any application processing the validated input material data, such as storage general 806. The non-validated input material data may be provided to such storage along with a classifier classifying such input material data as non-validated. The non-validated input material may be provided to such storage along with the classifier and rule data indicating the applied rule(s) resulting in non-validation of at least a part of the input material data.

[0274] 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 240990

[0275] 73 practicing the claimed invention, from the studies of the drawings, this disclosure and the claims. 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. 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”.

[0276] “Initiating or causing to perform an action” includes any processing signal that triggers a computing node or device to perform the respective action. 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. 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. 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

74CLAIMS1 . A method for generating an output product data set associated with an output product produced or producible by a production, the method comprising: receiving a data structure defined by a data consumer for collecting properties associated with the output product, wherein the properties are related to chemical and / or physical property / ies of the output product and / or production properties related to the production of the output product; providing data associated with the output product including at least one output product identifier; gathering - based on the provided data associated with the output product - output product data from one or more databases; generating the output product data set by transforming the gathered output product data using a rule-based engine including one or more rule(s) associated with the received data structure; providing the generated output product data set for access by a decentral data consuming node under control of or controlled by a decentral data providing node associated with data owner of the generated output product data set.

2. The method of claim 1 , wherein the received data structure includes one or more conditions to be satisfied, the one or more rule(s) includes at least one rule derived from and / or checking the one or more conditions.

3. The method of claim 1 , wherein the method further comprises: obtaining one or more conditions associated with the received data structure, the one or more rule(s) includes at least one rule derived from and / or checking the one or more conditions, preferably the one or more conditions are included in one or more standardized and / or pre-defined rules.

4. The method of any one of the preceding claims, wherein the gathered output product data includes output product identifier data, property data associated with the output product, output product name data, output product producer data, output product declaration data, output product safety data, emission data associated with the output product, recyclate content data associated with the output product, biobased content data associated with the output product, biodegradability data associated with the output product, production data associated with the output product, certificate of analysis data associated with the output product, certificate data associated with the output product, life cycle24099075 data associated with the output product, storage instruction data associated with the output product, assembly instructions associated with the output product, operating conditions associated with the output product or a combination thereof.

5. The method of any one of the preceding claims, wherein the rule-based engine operates on individual data points present within at least part of the gathered output product data, multiple data points present within at least part of the gathered output product data or the whole gathered output product data.

6. The method of any one of the preceding claims, wherein the one or more rule(s) are generated from a rule template including unstructured data associated with instructions related to transformation operation(s).

7. A method for validating input material data associated with input material(s), wherein the input material(s) are used to produce one or more product(s) by a production, the method comprising: providing product data including product identifier(s) and input material identifier(s) associated with the input material(s); obtaining the input material data from decentral data providing node(s) associated with the input material data, wherein the input material data is gathered by a decentral data consuming node based on the provided input material identifier(s); validating at least a part of the gathered input material data by using a rule-based engine including one or more rule(s) associated with product or product type and including one or more rule(s) associated with a data structure defined for collecting properties associated with the input material, wherein the properties are related to chemical and / or physical property / ies of the input material and / or production properties related to the production of the input material and wherein the data structure has been provided for generating the input material data: linking the validated input material data to at least one of the product identifiers; providing validated input material data linked to at least one of the product identifier(s) for generating product passport(s) associated with the product(s) including at least a part of the validated input material data.

8. The method of claim 7, wherein the provided data structure includes one or more conditions to be satisfied, the one or more rule(s) associated with the data structure includes at least one rule derived from the one or more conditions240990769. The method according to any of claims 7 to 8, wherein the decentral data providing node(s) are determined from data mapping decentral data providing node data to associated input material identifier(s) matching output product identifier(s) of output product data set(s) associated with such decentral data providing node(s).

10. The method of any one of claims 7 to 9, wherein the rule-based engine(s) operates on individual data points present within at least part of the input material data, multiple data points present within at least part of the input material data or the whole input material data.

11. A data processing device comprising means for carrying out the method according to any of claims 1 to 10.

12. A computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method according to any of claims 1 to 10.

13. A computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the method according to any of claims 1 to 10.

14. Use of the validated input material data associated with input materials as generated by the methods claimed in any one of claims 7 to 10 or by the device of claim 11 for generating product passports associated with products produced at least in part from the input material(s).

Images