Generating and processing data associated with materials in a decentralized system

Abstract

This invention relates to the field of sustainability, and more particularly to the field of sustainable industrialization. This disclosure relates to methods, apparatus, systems, and computer elements for generating output product datasets associated with output products. This disclosure further relates to methods, apparatus, systems, and computer elements for verifying input material data associated with (multiple) input materials. This disclosure further relates to using verified input material data associated with (multiple) input materials as generated herein to generate product passes associated with products produced at least in part from such (multiple) input materials.

Description

Technical Field

[0001] This invention relates to the field of sustainability, and more particularly to the field of sustainable industrialization. This disclosure relates to methods, apparatus, systems, and computer elements for generating output product datasets associated with output products. This disclosure further relates to methods, apparatus, systems, and computer elements for verifying input material data associated with (multiple) input materials. This disclosure further relates to using verified input material data associated with (multiple) input materials as generated herein to generate product passes associated with products produced at least in part from such (multiple) input materials. Background Technology

[0002] In the supply and production of a product, various regulatory requirements need to be met, which vary from product to product. Meeting these requirements may necessitate the exchange of data about the product among different participants involved in its production and use. This data can be exchanged securely and in a controlled manner within a decentralized network connecting the different participants involved in the production and / or recycling of the product. The generation of these highly standardized data packets within a decentralized network is cumbersome to process, especially for the diverse supply chain participants. Therefore, it is necessary to simplify the generation of data packets that can be exchanged via a decentralized network (particularly for data packets related to the (multiple) production inputs used to produce the product), while ensuring the transmission of all data required for further processing (such as generating chemical product permits associated with the product). Summary of the Invention

[0003] On one hand, a method for generating an output product dataset associated with an output product is disclosed, particularly a computer-implemented method, wherein the output product is used as input material to produce one or more products, the method comprising:

[0004] • Provide data associated with the output product, including at least one output product identifier;

[0005] • Collect output product data from one or more databases based on the provided data associated with the output product;

[0006] • The collected output product data is transformed using a rule-based engine to generate the output product dataset, the rule-based engine including one or more rules associated with at least one of the output products (multiple products);

[0007] • Provide the generated output dataset to be accessible to distributed data consumer nodes, either under the control of or controlled by the distributed data provider node associated with the data owner of the generated output dataset.

[0008] On the other hand, an apparatus for generating an output product dataset associated with an output product is disclosed, wherein the output product is used as input material to produce one or more products, the apparatus comprising:

[0009] • A data providing interface configured to provide data associated with the output product, the data including at least one output product identifier;

[0010] • A data collection unit configured to collect output product data from one or more databases based on provided data associated with the output product;

[0011] • Output product dataset generator, which is configured to generate the output product dataset by transforming the collected output product data using a rule-based engine, the rule-based engine including one or more rules associated with at least one of the output products(s).

[0012] • A distributed network interface configured to provide the generated output dataset to distributed data consumer nodes for access, under the control of or controlled by a distributed data provider node associated with the data owner of the generated output dataset.

[0013] On another front, a system for generating an output product dataset associated with an output product is disclosed, wherein the output product is used as input material to produce one or more products, the system comprising:

[0014] • Data source layer, which is configured to provide output material data from one or more data sources.

[0015] • Data consumer layer, which is configured to collect output product data provided by the one or more data sources, which contain one or more data instances associated with the output product;

[0016] • Data Transformer Layer, configured to generate the output product dataset by transforming the collected output product data using a rule-based engine, the rule-based engine including one or more rules associated with at least one of the output products(s).

[0017] • A connector layer to the distributed network, configured to provide the generated output dataset to distributed data consumer nodes for access, under the control of or controlled by a distributed data provider node associated with the data owner of the generated output dataset.

[0018] On another front, a method for generating an output product dataset associated with an output product is disclosed, particularly a computer-implemented method, wherein the output product is used as input material to produce one or more products, the method comprising:

[0019] • Incident data is received via a distributed network, including unconfirmed output product data and data associated with the rule(s) or rule template(s) that caused such unconfirmed output product data;

[0020] • Collect output product data associated with the received accident data;

[0021] • Update one or more rules associated with the output based on the received accident data;

[0022] • An updated output product dataset is generated by transforming the collected output product data using a rule-based engine, which includes one or more rules associated with at least one of the products, wherein at least one of the rules is an updated rule.

[0023] • Provide the generated updated output dataset to be accessible to distributed data consumer nodes, either under the control of or controlled by the distributed data provider node associated with the data owner of the generated output dataset.

[0024] In another aspect, an apparatus for generating an output product dataset associated with an output product is disclosed, wherein the output product is used as input material to produce one or more products, the apparatus comprising:

[0025] • Distributed network interface, configured to receive incident data via a distributed network, the incident data including unacknowledged output product data and data associated with the rule(s) or rule template(s) that caused such unacknowledged output product data;

[0026] • Data collection unit, configured to collect output product data associated with the output product based on the received accident data;

[0027] • Rule updater, which is configured to update one or more rules associated with the output product based on the received incident data;

[0028] • A data transformer configured to generate an updated output product dataset by transforming collected output product data using a rule-based engine, the rule-based engine comprising one or more rules associated with at least one of the products, wherein at least one of the rules is an updated rule.

[0029] • A distributed network interface configured to provide the generated updated output datasets to distributed data consumer nodes for access, under the control of or controlled by a distributed data provider node associated with the data owner of the generated output datasets.

[0030] On another front, a system for generating an output product dataset associated with an output product is disclosed, wherein the output product is used as input material to produce one or more products, the system comprising:

[0031] • Connector layer to the distributed network, which is configured to receive incident data via the distributed network, the incident data including unacknowledged output product data and data associated with (multiple) rules or rule templates that caused such unacknowledged output product data;

[0032] • Data source layer, which is configured to provide output material data from one or more data sources.

[0033] • Data consumption layer, which is configured to collect output product data associated with the output product based on the received incident data;

[0034] • Rule updater, which is configured to update one or more rules associated with the output product based on the received incident data;

[0035] • Data Transformer Layer, configured to generate an updated output product dataset by transforming collected output product data using a rule-based engine, the rule-based engine including one or more rules associated with at least one of the products, wherein at least one of the rules is an updated rule.

[0036] • A connector layer to the distributed network, configured to provide the generated updated output datasets to distributed data consumer nodes for access, under the control of or controlled by a distributed data provider node associated with the data owner of the generated output datasets.

[0037] On another front, a method for verifying input material data associated with (multiple) input materials is disclosed, particularly a computer-implemented method, wherein the (multiple) input materials are used to produce one or more products through production, the method comprising:

[0038] • Provide product data, which includes (multiple) product identifiers and (multiple) input material identifiers associated with (multiple) input materials;

[0039] • The input material data is obtained from the distributed data providing nodes associated with the input material data, wherein the input material data is collected by the distributed data consuming nodes based on the provided input material identifiers, and in particular, wherein the input material data is generated by the method disclosed herein or by the apparatus disclosed herein or by the system disclosed herein;

[0040] • Use a rule-based engine to identify at least a portion of the collected input material data, the rule-based engine including one or more rules associated with at least one of these products;

[0041] • Link the confirmed input material data to at least one of these product identifiers;

[0042] • The storage location of the confirmed input material data is determined based on the input material identifier(s) associated with the confirmed input material data;

[0043] • Provide the confirmed input material data linked to the product identifier(s) to the identified storage locations(s) to generate the product pass(s) associated with the product(s), which includes at least a portion of the confirmed input material data(s).

[0044] On another front, a method for verifying input material data associated with (multiple) input materials is disclosed, particularly a computer-implemented method, wherein the (multiple) input materials are used to produce one or more products through production, the method comprising:

[0045] • Provide product data, which includes (multiple) product identifiers and (multiple) input material identifiers associated with (multiple) input materials;

[0046] • The input material data is obtained from the distributed data providing nodes associated with the input material data, wherein the input material data is collected by the distributed data consuming nodes based on the provided input material identifiers, and in particular, wherein the input material data is generated by the method disclosed herein or by the apparatus disclosed herein or by the system disclosed herein;

[0047] • Use a rule-based engine to identify at least a portion of the collected input material data, the rule-based engine including one or more rules associated with at least one of these products;

[0048] • Link the confirmed input material data to at least one of these product identifiers;

[0049] • Provide verified input material data linked to the product(s) identifier(s) to generate product(s) associated with the product(s), including at least a portion of the verified input material data.

[0050] On another front, an apparatus for verifying input material data associated with (multiple) input materials, wherein the (multiple) input materials are used to produce one or more products through production, the apparatus comprising:

[0051] • Product data providing interface, which is configured to provide product data including (multiple) product identifiers and (multiple) input material identifiers associated with (multiple) input materials;

[0052] • A distributed network interface configured to obtain the input material data from (multiple) distributed data provider nodes associated with the input material data, wherein the input material data is collected by distributed data consumer nodes based on (multiple) provided input material identifiers;

[0053] • Data confirmer, configured to confirm at least a portion of collected input material data by using a rule-based engine, the rule-based engine including one or more rules associated with at least one of these products;

[0054] • Linking unit, which is configured to link the confirmed input material data to at least one of the product identifiers.

[0055] • Storage determiner, which is configured to determine the storage location of the confirmed input material data based on the input material identifier(s) associated with the confirmed input material data;

[0056] • A confirmed data provision interface, configured to provide confirmed input material data linked to the product identifier(s) to identified storage locations(s) for generating product passes(s) associated with the product(s) including at least a portion of the confirmed input material data.

[0057] On another front, an apparatus for verifying input material data associated with (multiple) input materials, wherein the (multiple) input materials are used to produce one or more products through production, the apparatus comprising:

[0058] • Product data providing interface, which is configured to provide product data including (multiple) product identifiers and (multiple) input material identifiers associated with (multiple) input materials;

[0059] • A distributed network interface configured to obtain the input material data from (multiple) distributed data provider nodes associated with the input material data, wherein the input material data is collected by distributed data consumer nodes based on (multiple) provided input material identifiers;

[0060] • Data confirmer, configured to confirm at least a portion of collected input material data by using a rule-based engine, the rule-based engine including one or more rules associated with at least one of these products;

[0061] • Linking unit, which is configured to link the confirmed input material data to at least one of the product identifiers.

[0062] • A confirmed data provider interface configured to provide confirmed input material data linked to the product identifier(s) for generating product passes(s) associated with the product(s) including at least a portion of the confirmed input material data.

[0063] On another front, a system for verifying input material data associated with (multiple) input materials, wherein the (multiple) input materials are used to produce one or more products through production, the system comprising:

[0064] • A connector layer to a distributed network, configured to obtain the input material data from (multiple) distributed data provider nodes associated with the input material data, wherein the input material data is collected by distributed data consumer nodes based on (multiple) input material identifiers associated with the (multiple) input materials;

[0065] • Service layer, which includes one or more input nodes configured to collect input material data provided by the connector layer and provide the collected input material data as one or more input material datasets to one or more downstream nodes.

[0066] • Data acknowledgment layer, which includes the one or more downstream nodes and is configured to...

[0067] ○ By using a rule-based engine to identify at least a portion of the input material dataset(s) provided by the service layer, the rule-based engine includes one or more rules associated with at least one of these products.

[0068] ○ Link the confirmed input material data to at least one of these product identifiers.

[0069] ○ The storage location of the confirmed input material data is determined based on the input material identifier(s) associated with it.

[0070] ○ The confirmed input material data linked to the product identifier(s) is provided to the identified storage locations(s) to generate product passes(s) associated with the product(s), including at least a portion of the confirmed input material data.

[0071] • Storage layer, which includes one or more databases and is configured to store the provided verified input material data.

[0072] On another front, a system for verifying input material data associated with (multiple) input materials, wherein the (multiple) input materials are used to produce one or more products through production, the system comprising:

[0073] • A connector layer to a distributed network, configured to obtain the input material data from (multiple) distributed data provider nodes associated with the input material data, wherein the input material data is collected by distributed data consumer nodes based on (multiple) input material identifiers associated with the (multiple) input materials;

[0074] • Service layer, which includes one or more input nodes configured to collect input material data provided by the connector layer and provide the collected input material data as one or more input material datasets to one or more downstream nodes.

[0075] • Data acknowledgment layer, which includes the one or more downstream nodes and is configured to...

[0076] ○ By using a rule-based engine to identify at least a portion of the input material dataset(s) provided by the service layer, the rule-based engine includes one or more rules associated with at least one of these products.

[0077] ○ Link the confirmed input material data to at least one of these product identifiers.

[0078] ○ Provides verified input material data linked to the product(s) identifier(s) to generate product(s) associated with the product(s), including at least a portion of the verified input material data.

[0079] • Storage layer, which includes one or more databases and is configured to store the provided verified input material data.

[0080] On another front, a method for verifying input material data associated with (multiple) input materials is disclosed, particularly a computer-implemented method, wherein the (multiple) input materials are used to produce one or more products through production, the method comprising:

[0081] • Generate incident data, which includes input material data that failed to pass validation and data associated with the rule(s) or rule template(s) that caused such input material data to fail validation;

[0082] • The generated accident data is provided via a distributed network to the distributed data provider node associated with the input material data that failed verification.

[0083] • Receive updated input material data from the distributed data provider nodes(s) via the distributed network;

[0084] • By using a rule-based engine to identify at least a portion of the updated input material data, the rule-based engine includes one or more rules associated with at least one of these products;

[0085] • Link the confirmed input material data to at least one associated product identifier;

[0086] • The storage location of the confirmed input material data is determined based on the input material identifier(s) associated with the confirmed input material data;

[0087] • Provide the confirmed input material data linked to the product identifier(s) to the identified storage locations(s) to generate the product pass(s) associated with the product(s), which includes at least a portion of the confirmed input material data(s).

[0088] On another front, an apparatus for verifying input material data associated with (multiple) input materials, wherein the (multiple) input materials are used to produce one or more products through production, the apparatus comprising:

[0089] • An accident data generator, which is configured to generate accident data, including input material data that failed to pass validation and data associated with the rule(s) or rule template(s) that caused such input material data to fail validation.

[0090] • A distributed network interface configured to provide the generated incident data via a distributed network to the distributed data providing node associated with the unverified input material data.

[0091] • Distributed network interface, configured to receive updated input material data from the distributed data provider node(s) via the distributed network;

[0092] • Data confirmer, configured to confirm at least a portion of updated input material data by using a rule-based engine, the rule-based engine including one or more rules associated with at least one of these products;

[0093] • Linking unit, which is configured to link the confirmed input material data to at least one associated product identifier;

[0094] • Storage determiner, which is configured to determine the storage location of the confirmed input material data based on the input material identifier(s) associated with the confirmed input material data;

[0095] • A data provision interface configured to provide the confirmed input material data linked to the product identifier(s) to the identified storage locations(s) for generating product passes(s) associated with the product(s), including at least a portion of the confirmed input material data(s).

[0096] On another front, a system for verifying input material data associated with (multiple) input materials, wherein the (multiple) input materials are used to produce one or more products through production, the system comprising:

[0097] • A connector layer to the distributed network, which is configured as

[0098] The generated accident data is provided via a distributed network to the distributed data-providing node associated with the input material data that failed verification.

[0099] ○ Receive updated input material data from the distributed data provider nodes(s) via the distributed network;

[0100] • Service layer, which includes one or more input nodes configured to collect updated input material data provided by the connector layer and provide the collected updated input material data as an updated input material dataset to one or more downstream nodes.

[0101] • Data acknowledgment layer, which includes the one or more downstream nodes and is configured to...

[0102] ○ This incident data is generated, which includes input material data that failed validation and data associated with the rule(s) or rule template(s) that caused the input material data to fail validation.

[0103] ○ By using a rule-based engine to identify at least a portion of the updated input material dataset(s) provided by the service layer, the rule-based engine includes one or more rules associated with at least one of these products.

[0104] ○ Link the confirmed input material data to at least one associated product identifier.

[0105] ○ The storage location of the confirmed input material data is determined based on the input material identifier(s) associated with it.

[0106] ○ The confirmed input material data linked to the product identifier(s) is provided to the identified storage locations(s) to generate product passes(s) associated with the product(s), including at least a portion of the confirmed input material data.

[0107] • Storage layer, which includes one or more databases and is configured to store the provided verified input material data.

[0108] In another aspect, the use of verified input material data associated with (multiple) input materials generated by the methods, apparatus, or systems disclosed herein is disclosed for generating product passes associated with products produced at least in part from the (multiple) input materials.

[0109] In another aspect, a computer element, particularly a computer program product or computer-readable medium, having instructions is disclosed, which, when executed on one or more computing nodes, is configured to perform the steps of any of the methods disclosed herein.

[0110] In another aspect, this disclosure relates to a computer element having instructions that, when executed on one or more computing nodes, is configured to perform the steps of the methods(s) disclosed herein or to be performed by the means(s) disclosed herein.

[0111] Any disclosures, embodiments, and examples described herein relate to the methods, apparatus, systems, uses, and computer elements listed above and below. Advantageously, the benefits provided by any embodiment and example also apply to all other embodiments and examples. Example

[0112] Embodiments of this disclosure will be outlined below through examples and / or embodiments. It should be understood that this disclosure is not limited to the embodiments and / or examples described.

[0113] To achieve or improve the exchange of output product data associated with (multiple) output products used as input materials to produce one or more products, it is crucial to generate such output product data simply and efficiently. However, sharing (multiple) output product datasets within a distributed network is often associated with using highly complex (multiple) semantic models or (multiple) data models to ensure consistency of (multiple) datasets containing all (multiple) required data points. However, such complex (multiple) data models are costly to generate and maintain. Therefore, using such complex semantic models makes generating (multiple) output product datasets a complex and tedious task. This effort may be infeasible for small supplier companies, thus posing an obstacle to sharing output product data associated with output products produced by such companies within a distributed network.

[0114] By using a rule-based engine (which includes multiple rules associated with products produced from multiple output products as input materials, particularly with multiple data models of the product or the product type associated with that product), it can be ensured that the multiple output product data points required according to the data model (e.g., an aspect model) associated with the product or product type produced from such output products are included in the output product dataset, thus avoiding the loss of multiple data points during the generation of product passes associated with the product using the semantic model. Since the multiple rules are derived from the product's data model, suppliers of the multiple input materials used in the production of such products do not necessarily have to use complex data models to generate the multiple output product dataset. Instead, existing data models for such products can be used to generate the multiple rules used during the creation of the multiple output product dataset, thus avoiding the costly and tedious generation of such a model for the produced output products.

[0115] By transforming the collected output product data using this rule-based engine, the collected output product data can be aggregated into a given data structure (such as a tabular representation) without using complex data models. This facilitates the simple generation and reliable sharing of (multiple) output product datasets by output product producers within the product ecosystem. These (multiple) output product datasets can be associated with (multiple) authorization rules, thereby preventing unauthorized access to such data and ensuring its secure sharing via a decentralized network. The (multiple) output product datasets (such as tabular representations) can be stored in dedicated storage associated with the data owner of the (multiple) datasets, allowing them to be consumed by decentralized data consumption nodes associated with data consumers under the control of that data owner (such as the output product producer). Therefore, output product datasets can be consumed directly based on (multiple) identifiers associated with such datasets and (multiple) endpoints of decentralized data provider nodes associated with dedicated storage, without the use of any intermediate registries, such as decentralized registries storing access elements to (multiple) output product datasets generated using a highly defined data model.

[0116] By using rule templates that include unstructured data associated with (multiple) transformation operations, natural language can facilitate the generation of one or more rules, allowing for the simple and reliable generation of (multiple) rules based on natural language text (such as user input, contract terms, etc.). Furthermore, (multiple) rule templates can be predefined, allowing for the generation of (multiple) output product datasets based on given rule templates and (multiple) rules, further simplifying the generation of (multiple) output product datasets.

[0117] By enabling the simple generation of multiple output product datasets, supply chain participants unfamiliar with semantic data or unable to afford to create such complex data models can reliably share these datasets within a decentralized network. This sharing enables more efficient production and / or recycling processes based on shared output product data, such as output product composition data included in the shared datasets. Through the use of decentralized networks, the generated output product datasets can be shared securely and in a controlled manner by preventing unauthorized access to such datasets by multiple decentralized network participants, thus avoiding unwanted transparency regarding the supply chain and / or chemical composition of the output products from third parties.

[0118] By using a rule-based engine that operates at the data point level, multiple data point levels, or the entire data level, it can be ensured that the generated output product dataset includes all (or more) output product data points required by the data model associated with the product or the product type (e.g., product classification) associated with the product. This ensures that product passes associated with such products can be reliably generated from data collected via a distributed network without the risk of missing (or more) required data points, resulting in low data quality for the product passes. Since products sold to customers may be required to be associated with such product passes, the inability to generate such passes due to missing output product data can lead to increased product storage time and potentially negatively impact downstream participants in the supply chain due to a lack of product supply. Furthermore, low data quality in product passes can negatively affect the processing of the product based on the data included in the product pass and / or the use of the product to produce other products.

[0119] By using a rule-based engine to validate the generated output product datasets in a simple and efficient manner, it is ensured that the consumed output product datasets include the data points required by the data model. This rule-based engine includes rules associated with products produced using the output products associated with such datasets as production inputs. This allows for the avoidance of missing data points when generating product passes associated with the consumed output product data. Validation of the consumed output product datasets on the consumer side ensures that the product passes contain all the data required by the data model used to generate them. This allows for a reduction in the complexity associated with generating the output product datasets on the provider side by avoiding the use of complex data models during the generation of the output product datasets, as this complexity is shifted to the consumer side that generates the product passes. This enables reliable sharing of output product data for (multiple) output products regardless of the existence of a data model for such output products, because the (multiple) rules required to transform the collected output product data can be easily derived or generated based on a data model associated with the product or product type, or derived or generated from a data model derived from a data model associated with the product or product type.

[0120] In cases where an error occurs when the application of one or more rules by a rule-based engine (e.g., failure to meet conditions specified in such rules), updated output product data can be generated and provided to the consumer by generating incident data during the generation of output product data on the provider side. This ensures that the generated output product datasets satisfy one or more applied rules, thereby avoiding confirmation errors on the consumer side. By generating incident data during the consumer-side confirmation of output product data (e.g., input material data), the data provider is able to generate updated output product datasets that satisfy the confirmation rules used by the rule-based engine on the consumer side. By using incident data on the provider side to update the rules included in the rule-based engine that transforms the collected output product data, it is ensured that output product datasets satisfying the confirmation rules used on the consumer side are generated, thereby reducing errors and delays in the generation of product passes.

[0121] Various units, entities, nodes, or other computing components can be described as being "configured to" perform one or more tasks. "Configured to" should be interpreted as meaning "having a circuit system that performs one or more tasks during operation." Units, circuits, entities, nodes, or other computing components can be configured to perform tasks even when the unit / circuit / component is not operational. Units, circuits, entities, nodes, or other computing components forming the structure corresponding to "configured to" may include hardware circuitry and / or memory storing executable program instructions to perform the operation. For convenience in the description, units, circuits, entities, nodes, or other computing components can be described as performing one or more tasks. This description should be interpreted as including the phrase "configured to."

[0122] Generally, the methods, apparatuses, systems, computer elements, nodes, or other computing components described herein may include memory, software components, and hardware components. Memory may include volatile memory (such as static or dynamic random access memory) and / or non-volatile memory (such as optical or magnetic disk storage devices, flash memory, programmable read-only memory, etc.). Hardware components may include any combination of the following: combinational logic circuit systems, clock storage devices (such as flip-flops, registers, latches, etc.), finite state machines, memory (such as static random access memory or embedded dynamic random access memory), custom-designed circuit systems, programmable logic arrays, etc.

[0123] The method for generating the output product dataset can be executed by one or more computing nodes associated with the production of the output product. The method for generating the output product dataset can be executed by one or more computing nodes associated with the output product producer. The output product producer can operate the output product production. The method for verifying the input material data can be executed by one or more computing nodes associated with the production of the product. The method for verifying the input material data can be executed by one or more computing nodes associated with the product producer. The product producer can operate the production.

[0124] Input materials can refer to any goods purchased from a supplier and brought to the corresponding production plant. Input materials can include starting materials used in the production process at the production plant to produce the finished product. Input materials can be used at any production step used to produce the finished product. This means that the finished product of one production plant can be the input material of another production plant. Similarly, the output product of one supply chain participant can be used as input material by a downstream participant to produce another output product. Input materials can include recycled materials. Input materials can include any input material that is either incorporated into or enters production. Input materials can include any input material that is either incorporated into or provided at any entry point in production. Input materials can be any material produced by an upstream production stage relative to the output product production stage.

[0125] Output products can include any product produced from one or more input materials. Output products can be produced via one or more process steps. Process steps can involve chemical reactions and / or physical processes and / or assembly processes. Input materials can be used in one or more such production steps. Output products can include any product that is produced by production and provided at any exit point of that production. Output products can be used as input materials for the production of one or more products. (Multiple) products can be produced by one or more downstream participants who can use (multiple) output products produced by one or more upstream participants as (multiple) input materials. Output products can be associated with an output product identifier. The output product identifier can be a numerical or virtual output product identifier. The output product identifier can uniquely identify the output product within the entity that produces it. The output product identifier can uniquely identify the output product within a distributed network. The output product identifier can be associated with an identifier element physically linked to the output product. The identifier element can encode the numerical output product identifier. The output product identifier can include the output product name, output product number, LOT number, batch number, serial number, etc.

[0126] Output products / input materials and products can be part of a product ecosystem. A product ecosystem can include chemical products. A product ecosystem can include a production chain that produces products. Products can be chemical products, intermediate chemical products, components, component assemblies, or final products. A product ecosystem can include a processing chain that handles used products generated from the use of the produced products. A processing chain can include a recycling chain that recovers at least a portion of used products or their components. A processing chain can include a reuse chain that reuses used products. A product ecosystem can include various participants, such as producers of original input materials, producers of chemical products, users of chemical products, producers of final products, users of final products, collectors of end-of-life products, and recyclers. A product ecosystem can allow the use of recycled materials generated from the recycling of end-of-life products to produce new products, such as chemical products. A product ecosystem can be associated with the production and / or reuse and / or recycling of physical products.

[0127] Output products can be associated with an output product dataset (e.g., assets). The output product dataset may include an output product identifier associated with the dataset and output product data transformed by a rule-based engine. Output product identifiers can be associated with output products. Output product identifiers (e.g., asset identifiers) may differ from the numerical output product identifiers that uniquely identify output products within the output product production process. Output product identifiers may be undiscoverable by participant nodes in the decentralized network. Output product identifiers may be inaccessible to participant nodes within the decentralized network.

[0128] Participants in the product ecosystem can connect via a decentralized network. The decentralized network can include one or more decentralized network nodes configured to execute data transactions. Multiple decentralized network nodes can be associated with participants in the product ecosystem. Data transactions can be based on transaction protocols that include multiple authentication and / or authorization mechanisms. Based on these authentication and / or authorization mechanisms, a peer-to-peer network can be established between multiple decentralized network nodes. One or more authentication mechanisms can be associated with or linked to multiple decentralized identifiers. One or more authentication mechanisms associated with multiple decentralized identifiers can be provided to multiple decentralized network nodes. One or more authentication mechanisms associated with multiple decentralized identifiers can be accessed by multiple decentralized network nodes. Decentralized configuration allows for more efficient use of computing resources and strengthens each data owner's control over the decentralized network.

[0129] A distributed data providing network node may include computer-executable instructions for providing and / or processing data (such as output product datasets) requested by distributed data consuming network nodes within the distributed network. A distributed data providing network node may be associated with or connected to one or more dedicated data storage devices storing the output product dataset. A distributed data providing network node may be directly or indirectly connected to multiple data storage devices storing the output product dataset. Therefore, a distributed data providing network node may be associated with the output product dataset. The multiple dedicated data storage devices may be under the control of the data owner of the output product dataset. The data owner may be an entity capable of accessing the output product dataset and controlling access to the output product dataset through the data consumption service of the distributed network. The data owner may be an output product producer. Access to the output product dataset may be controlled by the data owner through the output product identifier and its unique association with the data owner and the output product dataset. The output product dataset may be accessible to the data owner. Therefore, the data owner may directly or indirectly own the output product dataset. The output product dataset may be stored in the data owner's database or a database associated with the data owner. The output product dataset may be stored in a database accessible to the data owner. A data owner can control access to the output product dataset by providing services through their data. The output product dataset can be associated with a data owner. The data owner can be the owner of the output product dataset or the data owner of the output product dataset itself. The output product dataset can be stored in the data owner's database or under the data owner's control.

[0130] Decentralized data consuming network nodes may include computer-executable instructions for accessing and / or processing data (such as input material data) provided by decentralized data providing network nodes within the decentralized network. Decentralized data consuming network nodes may be controlled, owned, or associated with consumers of the input material data (e.g., entities generating product passes). Consumers may be any entity that processes the input material data. Consumers may be any entity operating production configured to process output products associated with output product data as input materials (multiple types). Processing may include using the output products as input materials to produce additional products. Processing may include performing one or more recycling steps on the output products as input materials. Consumers may be upstream participants in the product ecosystem of output product producers.

[0131] A rule-based engine can be used to transform at least a portion of collected output product data associated with (multiple) output products. The rule-based engine can be software or a software component that applies one or more rules to at least a portion of the collected output product data. The (multiple) rules can include or correspond to executable logic. The executable logic can be generated from a rule template that includes unstructured data associated with instructions related to (multiple) transformation operations. A rule-based engine for transforming at least a portion of the collected output product data can include one or more rules associated with products produced from (multiple) output products (e.g., produced using output products as input materials). One or more rules can be associated with or derived from a data model of the product or product type. Therefore, one or more rules can ensure that (multiple) data points of such output products required according to the data model can be included in the generated output product dataset. One or more rules can be defined by mandatory output product data points existing within the data model. One or more rules can be generated based on mandatory output product data points existing within or defined by the data model. This ensures that the output product data required by the data model is included in the generated output product dataset. Therefore, one or more rules can be generated or defined by a data model associated with a product or product type produced from (multiple) output products as input materials. Thus, one or more rules may not be derived or generated based on a data model associated with the produced output products. This allows for avoiding the generation of complex data models for the produced output products, and instead allows for the use of existing data models of (multiple) products or product types to generate (multiple) rules to transform the collected output product data into (multiple) output product datasets.

[0132] Rule-based engines can operate at the level of individual data points, combinations of data points, or the entire collected output product data. The operation of a rule-based engine can be defined by one or more rules. Rules(s) may include or correspond to executable logic. Executable logic can be generated from a rule template that includes unstructured data associated with instructions related to(s) confirmation operations(s). Rules(s) associated with individual data points(s) may include one or more rules defining conditions(s) for individual data points present in the collected output product data. Using such rules(s) ensures that the data points(s) required for the data model associated with the product are included in the generated output product dataset. Rules(s) associated with multiple data points may include one or more rules defining the required combinations of data points. Using such rules(s) ensures that the combination(s) of data points(s) required for the data model associated with the product or product type are included in the generated output product dataset.

[0133] A rule-based engine can be used to validate at least a portion of input material data collected via a distributed network. The rule-based engine can be software or a software component that applies one or more rules to at least a portion of the collected input material data. The rule-based engine used to validate at least a portion of the collected input material data can include one or more rules associated with (multiple) products. One or more rules can be associated with, derived from, or generated based on data about a product or product type. Therefore, one or more rules can ensure that (multiple) data points of such input material required according to the data model can be included in the collected input material data. One or more rules can be defined by mandatory input material data points existing within the data model. One or more rules can be generated based on mandatory input material data points existing within or defined by the data model. This ensures that the input material data required by the data model is included in the collected input material data, thereby ensuring the reliable and efficient generation of product passes using such validated input material data.

[0134] Rule-based engines can operate at the level of individual data points, combinations of data points, or the entire collected input material data. The operation of a rule-based engine can be defined by one or more rules. Rules associated with individual data points may include one or more rules defining conditions for individual data points present in the collected input material data. Using such rules ensures that the data points required for the data model associated with the product are included in the consumed input material data. Rules associated with multiple data points may include one or more rules defining desired combinations of data points. Using such rules ensures that the combination of multiple data points required for the data model associated with the product or product type is included in the consumed input material data.

[0135] A product pass can refer to a dataset with a defined semantic structure. This defined semantic structure can be obtained by applying a data model (such as an aspect model) to verified input material data and product data associated with the corresponding product. A product pass may include at least one distributed identifier and pass data. Pass data may include product identifiers, verified input material data, and product data. A product pass may include one or more authentication mechanisms associated with the distributed identifier(s) and pass data. A product pass may involve one or more authorization mechanisms associated with the distributed identifier(s) and pass data. One or more authorization mechanisms may include authorization rules that determine whether to grant access to at least a portion of the verified input material data and / or product data. A product pass may be associated with one or more digital representations of pass data or a portion thereof. A digital representation can be considered as multiple access elements providing access to a product pass (e.g., pass data) or a portion thereof. A digital representation may include a distributed identifier and access data for accessing the pass data or a portion thereof. Access data may include locators or pointers (such as URLs or URIs) to a dedicated storage device (such as a dedicated storage address) that stores pass data, associated with the data owner of the product pass. The pointer or locator may point directly to the dedicated storage device. The pointer or locator may also point to a data-providing network node associated with the dedicated storage device. Access elements may include one or more authentication mechanisms associated with distributed identifiers and access data. Access elements may be associated with one or more authentication mechanisms associated with distributed identifiers and access data. Access elements may be provided to a distributed registry that stores access elements that can be discovered and / or accessed by participant nodes of the distributed network. Distributed identifiers may be discoverable and / or accessible by participant nodes of the distributed network, for example, via access elements stored in the distributed registry. The distributed registry may be associated with the data owner of the pass data. The distributed registry may be associated with a data-providing network node. This allows control over access to such a registry and access to the access elements stored in such a registry via the data-providing network node. A decentralized registry can be associated with participants in the product ecosystem. A decentralized registry can be associated with the data owner of a product token. A decentralized registry can be part of a decentralized network, but may not be associated with a specific participant in the product ecosystem; for example, it can be considered an infrastructure node of the decentralized network.

[0136] In this embodiment, one or more databases are distributed databases, wherein at least one of these databases stores multiple instances of output product data. A distributed database can be a collection of data stored at different sites on a computer network. Each site may have a degree of autonomy, serving the execution of a local application but also participating in the execution of a global application. For example, a distributed data source can be a distributed database. A distributed database can be created by splitting data from an existing database and distributing it across different sites or by joining multiple existing databases together. Each data source may contain only a fragment of data associated with a corresponding output product. This results in the partitioning of the data. Two common types of data partitioning are: horizontal partitioning, where (potentially overlapping) subsets of data tuples are stored at different sites; and vertical partitioning, where (potentially overlapping) sub-tuples of data tuples are stored at different sites. More generally, data associated with output products can be partitioned into a set of relations (tables in a relational database distributed across multiple sites).

[0137] In this embodiment, the output product is a chemical intermediate, a chemical product, a part, a component, or a component assembly. The chemical intermediate and / or chemical product may be produced from (multiple) original input materials and / or (multiple) recycled input materials. 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, a mechanical subsystem, or a battery pack casing.

[0138] In this embodiment, the collected output product data includes output product identifier data, characteristic 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, recyclable content data associated with the output product, bio-based content data associated with the output product, biodegradability data associated with the output product, production data associated with the output product, analytical certificate data associated with the output product, certificate data associated with the output product, life cycle data associated with the output product, storage instructions data associated with the output product, assembly instructions associated with the output product, operating conditions associated with the output product, or combinations thereof.

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

[0140] Characteristic 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 based on data collected in connection with the production of the output product. Data may be collected before, during, and / or after the 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 example, at least one physical and / or chemical property may be determined based on sensor data obtained from (multiple) sensors. Data may be collected using suitable sensors configured to measure chemical and / or physical properties. Chemical properties may be properties of the output product that become apparent during or after the chemical reaction. Therefore, chemical properties may be any property that can only be established by altering 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, (multiple) oxidation states, corrosiveness, combustibility, acidity and alkalinity, chemical composition, content of recyclables used in the production or manufacture of the product, bio-based content used in the production or manufacture of the product, recyclable content used in the production or manufacture of the product, and / or pH value. Physical properties may be any measurable characteristic of the output product. Therefore, the values ​​of physical properties describe the 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, charge, conductivity, impedance, potential, flow rate, fluidity, hardness, capacitance, inductance, intrinsic impedance, brightness, luminosity, gloss, mass, melting point, opacity, permeability, permittivity, plasticity, pulsed discharge, power, pressure, emissivity, resistivity, reflectivity, refractive index, solubility, specific heat, strength, stiffness, temperature, tensile strength, thermal conductivity, thermal resistance, weight, viscosity, volume, and / or wave impedance. At least one physical and / or chemical property being measured can be obtained by a sensor configured to measure such property. The sensor can be included in a measuring device. The sensor can correspond to the measuring device.

[0141] Data on recycled content and / or bio-based content may include any data related to the recycled content or bio-based content used to provide or manufacture the output product.

[0142] Emissions data can include any data related to an environmental footprint. An environmental footprint can refer to the output product and its associated environmental footprint. An environmental footprint can be product-specific. For example, an environmental footprint can relate to a product-specific or additional output product relationship. Emissions data can include data related to the carbon footprint or product carbon footprint (PCF) of the output product. Emissions data can include data related to greenhouse gas emissions, such as those released during the production of the output product. Emissions data can include data related to greenhouse gas emissions. Greenhouse gas emissions can include, for example, emissions of carbon dioxide (CO2), methane (CH4), nitrous oxide (N2O), hydrofluorocarbons (HFCs), perfluorocarbons (PFCs), sulfur hexafluoride (SF6), nitrogen trifluoride (NF3), and combinations thereof, as well as other emissions.

[0143] Emissions data can include data related to greenhouse gas emissions generated by an entity or company's own operations (production, power plants, and waste incineration). Scope 2 can include emissions generated from the production of energy supplied externally. Scope 3 can include all other emissions generated along the value chain. Specifically, this can include greenhouse gas emissions from raw materials obtained from suppliers. Product carbon footprint (PCF) can be the sum of greenhouse gas emissions and removals generated by consecutive and interrelated process steps associated with a specific product. Cradle-to-gate PCF can be an aggregation of greenhouse gas emissions based on selected process steps: for example, from the extraction of resources to the product leaving the company's plant gate. This type of PCF can be referred to as a partial PCF. To achieve this aggregation, each company that provides any product can provide its contribution to the PCF generation in Scope 1 and Scope 2 for each of its products.

[0144] Production data may include 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 before, during, and / or after the production of the output product.

[0145] In an embodiment, the rule-based engine operates on individual data points, multiple data points, or the entire collected output product data that exist within at least a portion of the collected output product data. The rule-based engine can be configured to transform the collected output product data based on one or more included rules. The rule-based engine can apply one or more rules to individual data points, multiple data points, and / or the entire dataset to generate multiple output product datasets. If the rule-based engine determines that multiple individual data points, multiple data points, and / or the entire data match one or more conditions in the multiple rules, then such individual data points, multiple data points, or the entire data can be included in the generated output product dataset.

[0146] In an embodiment, one or more rules are generated from a rule template, which includes unstructured data associated with instructions related to multiple transformation operations. These instructions may represent multiple transformation operations. The instructions may relate to multiple transformation operations. Multiple transformation operations may involve aggregating output product data collected from multiple data sources into a given data structure, filters for filtering the collected output product data, attribute constructs for creating or adding new attributes to the collected output product data, and / or triggering conditions, and a corresponding set of one or more actions. The rule template can be used to generate executable logic that can be executed by a rule-based engine. Using rule templates facilitates the generation of one or more rules because the instructions for generating executable logic can be formulated in natural language. The rule template may be a predefined rule template. Rule templates can be generated to match multiple data models associated with multiple products or product types produced using output products as input materials. Rule templates may be generated and provided by third parties. This allows rule templates to be offered as a service to data providers, further simplifying the generation of output product datasets and lowering the barriers to entry for input material suppliers to generate and provide output product datasets via a decentralized network, enabling data consumers to access such data to generate product passes.

[0147] In an embodiment, one or more rules are associated with, derived from, or generated based on a semantic model (e.g., a data model) associated with at least one of these products, particularly wherein the one or more rules are defined by one or more mandatory output product data points existing within the semantic model. The data model may be associated with a product type associated with the product. This allows avoiding the use of complex data models associated with output products, and instead allows the use of existing data models of the (multiple) products produced from such output products. This allows for a significant reduction in the complexity of generating output product datasets for producers of such (multiple) output products, thereby ensuring the reliable and efficient provision of such output product datasets within a distributed network for consumer entities to access for generating product passes.

[0148] In an embodiment, one or more rules define aggregation rules for aggregating output product data collected from multiple data sources into a given data structure, filters for filtering the collected output product data, attribute constructs for creating or adding new attributes to the collected output product data, and / or triggering conditions and a corresponding set of one or more actions. The given data structure may be a tabular representation. Therefore, the rule-based engine can be configured to generate a tabular representation that populates the collected output product data and matches one or more of the included rules, based on one or more of the included rules. The tabular representation may be stored in a dedicated storage device associated with the distributed data providing nodes, thereby allowing the tabular representation to be provided by requesting access to it based on an output product identifier included in such a tabular representation. Filters may define data points to be included in the generated output product dataset. For example, a filter can define one or more output product characteristic data points, output product identifier data points, output product name data points, output product producer data points, output product claim data points, output product safety data points, output product emission data points, output product recycled content data points, output product bio-based content data points, output product biodegradability data points, output product production data points, output product analysis certificate data points, output product certificate data points, output product life cycle data points, output product storage instructions data points, output product assembly instructions data points, and / or output product operating condition data points. A filter can define (multiple) data points for each data category. A filter can define (multiple) data points for at least two different data categories. Data categories can represent characteristic data, claim data, safety data, emission data, recycled content data, bio-based content data, biodegradability data, production data, analysis certificate data, certificate data, storage instructions data, assembly instructions data, or operating condition data.

[0149] In an embodiment, transforming the collected output product data by the rule-based engine includes identifying one or more rules applicable to the collected output product data and providing the applicable rules(s) to the rule-based engine. The applicable rules(s) can be identified based on an identifier associated with each applicable rule that matches or relates to at least one output product identifier included in the collected output product data. The applicable rules(s) can be included in rule templates. Therefore, transforming the collected output product data can include identifying applicable rule templates. The applicable rules(s) and / or applicable rule templates can be stored on a database connected to the rule-based engine. The identifier associated with each applicable rule or rule template can correspond to a numerical output product identifier included in the collected output product data. The applicable rules(s) or rule templates can be collected based on mapping data, which includes the identifier(s) associated with the rule(s) or rule template(s) and the associated output product identifier(s), and optionally, the output product type identifier(s).

[0150] In this embodiment, the transformation of the collected output product data includes

[0151] • Generate executable logic based on one or more of the identified applicable rules.

[0152] • And transform the collected output product data by executing the generated executable logic under the constraints of rule enforcement standards by a rule-based engine.

[0153] Rule execution criteria can be included in the executable logic. Execution criteria can involve actions associated with trigger signals included in the executable logic. Generating executable logic allows providing rules or rule templates as unstructured data (e.g., in natural language), thereby simplifying the creation of executable logic by using rule templates or rules (e.g., rules written in natural language and / or rule templates) that include unstructured data. Simplifying the creation of executable logic lowers the barrier to generating and providing output product datasets within a decentralized network, ensuring that even small supplier entities can participate as data providers within the decentralized network. This, in turn, allows data consumers generating product passes to reliably consume all the necessary input material data via the decentralized network, ensuring efficient and reliable generation of product passes using the collected input material data. This improves the data quality of product passes, allowing for more reliable processing of products based on the data included in the product passes and / or the use of those products to produce additional products.

[0154] In this embodiment, the output product dataset is generated in response to satisfying one or more rules applied by a rule-based engine to the collected output product data. This ensures that the generation of the output product dataset is performed only if the rule-based engine can successfully apply at least a portion of the rules(s) to the collected data (e.g., if the application of the rules(s) does not produce errors (e.g., due to missing data, incorrect data, incomplete data, etc.)). This ensures that the output product dataset(s) satisfying the applied rules(s) are provided only via a distributed network, thereby avoiding errors during confirmation performed on the consumer side—which could negatively impact the data quality of the generated product pass. This, in turn, could negatively impact the availability of such products, for example, in situations where, from a regulatory perspective, certain data must be included in the product pass for products sold to downstream participants in the product ecosystem or end-product users. Delayed availability of such products could negatively impact production by downstream participants because the required input materials are unavailable for production. Additionally, low data quality could negatively impact data processing products included in the product pass.

[0155] In an embodiment, the generated output product dataset includes at least one output product identifier, particularly including or associated with multiple output product identifiers in the provided data associated with the output products.

[0156] In an embodiment, the generated output product dataset includes at least a portion of the data included in the collected output product data. The output product dataset may further include a digital output product identifier associated with the output product dataset, such as an asset identifier. For example, the generated output product dataset may include data points(s) defined by one or more rules used to generate the output product dataset. Such rules(s) ...

[0157] In this embodiment, the generated output product dataset includes (multiple) output product characteristic data points, (multiple) output product identifier data points, (multiple) output product name data points, (multiple) output product producer data points, (multiple) output product declaration data points, (multiple) output product safety data points, (multiple) output product emission data points, (multiple) output product recyclable content data points, (multiple) output product bio-based content data points, (multiple) output product biodegradability data points, (multiple) output product production data points, (multiple) output product analysis certificate data points, (multiple) output product certificate data points, (multiple) output product lifecycle data points, (multiple) output product storage instructions data points, (multiple) output product assembly instructions data points, and / or (multiple) output product operating condition data points. For example, the generated output product dataset may include (multiple) output product emission data points.

[0158] In an embodiment, the method further includes the steps of: generating group access data associated with the generated output product dataset and optionally defining one or more authorization rules for access to and / or use of the generated output product dataset. The group access data may identify access control groups, which include decentralized participant(s) identifiers associated with decentralized network participants authorized to access the generated output product dataset. This access group data can allow control over access to such dataset, thereby preventing unauthorized data consumers from accessing it. This ensures that the output product dataset is shared only with data consumers who require such data (e.g., for generating product passes).

[0159] In an embodiment, the method further includes the step of generating a contract template that includes a digital output product identifier and a group access data identifier. The method may further include the step of linking the group access data to the digital output product identifier. The link may be included in the contract template. The contract template may be used by a decentralized data provider node to generate an electronic contract. The electronic contract may be provided to a decentralized data consumer node requesting access to such output product dataset(s) associated with the decentralized data provider node. The contract may include access data. The access data may include an endpoint pointing to a dedicated storage device storing the corresponding output product dataset. This allows the decentralized data consumer node to use such an endpoint within a request for such output product data when accepting the electronic contract. The electronic contract may include multiple authorization rules associated with the use of the output product dataset(s). This can prevent data consumers from using the provided output product data without authorization, thereby improving data security.

[0160] In this embodiment, access to the generated output product dataset is controlled by a decentralized data providing node associated with the data owner, based on group access data and contract templates associated with the output product dataset. This allows for the configuration of access to the output product dataset, thereby preventing unauthorized data consumers from accessing such data. Access to the generated output product dataset can be controlled based on a digital output product identifier associated with the output product dataset and the output product.

[0161] In an embodiment, the method further includes the step of: generating incident data in response to determining that at least one rule applied by a rule-based engine to the collected output product data is not satisfied. The incident data may identify the data points(s) and rule(s)(s) that caused the non-compliance. The incident data may be used to generate an updated output product dataset. Using such incident data can allow for the avoidance of providing an output product dataset that may not be verifiable by the consumer side, thus causing a delay in the generation of(s) product passes(s), since such generation must be delayed until an output product dataset including valid data becomes available from the provider side.

[0162] In embodiments of the method for verifying input material data associated with (multiple) input materials, the product data further includes product characteristic data, which includes at least one measured chemical and / or physical property of the product, and / or at least one chemical and / or physical property determined based on data collected in connection with the production of the product. The chemical and / or physical properties may correspond to the properties previously described. Data may be collected before, during, and / or after the production of the product.

[0163] In an embodiment of a method for identifying input material data associated with (multiple) input materials, (multiple) distributed data provider nodes are determined based on mapping data by matching (multiple) input material identifiers included in product data with (multiple) output product identifiers included in mapping data, which maps distributed data provider node data to associated (multiple) input material identifiers. This mapping data may be stored in a database. The database may be associated with a data consumer or an entity performing the method. The database may be associated with a system performing the method. The (multiple) output product identifiers and associated data provider node data may be provided by the respective (multiple) distributed data provider nodes to consuming entities that consume such output product data from such data provider nodes. The data provider node data may include location data pointing to the location of the output product dataset associated with the respective data provider node, an endpoint address associated with the respective data provider node, and / or a distributed participant identifier associated with the respective data provider node. The database may not contain associated output product datasets, and therefore the database may not be considered a central repository for the (multiple) output product datasets. Conversely, control over access to (multiple) output product datasets is retained by the respective data providers, and such databases only allow access to (multiple) output product datasets required to generate the corresponding product passes.

[0164] In an embodiment of the method for verifying input material data associated with (multiple) input materials, the obtained input material data is provided to one or more input nodes configured to collect the obtained input material data and provide the collected input material data as (multiple) input material datasets to one or more downstream nodes. The one or more downstream nodes are configured to verify at least a portion of the data included in the (multiple) input material datasets provided by the one or more input nodes, link the verified input material data to at least one of the product identifiers, determine (multiple) storage locations of the verified input material data, and provide the verified input material data linked to the (multiple) product identifiers to the determined (multiple) storage locations. An input node may represent a computing node that collects input material data from one or more distributed data consumer nodes. One or more input nodes may be configured to generate data packets, such as messages or events, based on the received input material data. The generated data packets may be sent downstream from the input nodes to one or more downstream nodes. The (multiple) downstream nodes may be configured to retrieve the data packets provided by the (multiple) input nodes. The (multiple) input nodes may be configured to provide data packets to persistent or non-persistent logs. Multiple downstream nodes can be configured to retrieve packets provided to persistent or non-persistent logs. Multiple downstream nodes can be configured to receive packets provided to persistent or non-persistent logs. Multiple input nodes can be associated with a distributed network. For example, multiple input nodes can be associated with distributed data consuming network nodes that are part of a distributed network. A downstream node can refer to a computing node that consumes data from a computing node that exists upstream relative to the data flow. Consuming data can include receiving data or retrieving packets from multiple input nodes or persistent or non-persistent logs. For example, data “flows” downstream from input nodes to downstream nodes. A downstream node can be considered an output node. Requests for data can be sent from downstream nodes upstream to input nodes.

[0165] In embodiments of a method for verifying input material data associated with (multiple) input materials, the rule-based engine operates on individual data points, multiple data points, or the entire input material data present in at least a portion of the input material data. The rule-based engine can be configured to verify the input material data based on one or more included rules. The rule-based engine can apply one or more rules to (multiple) individual data points, multiple data points, and / or the entire dataset to generate verified input material data. If the rule-based engine determines that (multiple) individual data points, multiple data points, and / or the entire data matches one or more conditions in (multiple) rules, then such (multiple) individual data points, multiple data points, or the entire data can be considered verified. Verified data can be associated with a classifier indicating successful verification of the corresponding data point, combination of (multiple) data points, or the entire data. The classifier can indicate that the input material data has passed one or more applied rules. Verifying input material data at the data point level ensures that all (multiple) input material data points required for a data model associated with a product or product type are included in the collected input material data. Data point-level validation can compensate for the simplified generation of output product datasets on the provider side, which does not require the use of a data model, thereby ensuring that the generated output product datasets include all the required data points.

[0166] In embodiments of a method for verifying input material data associated with (multiple) input materials, one or more rules are generated from a rule template that includes unstructured data associated with instructions related to (multiple) verification operations. The (multiple) verification operations may involve one or more data points and / or combinations of data points to be present within the input material data. The rule template can be used to generate executable logic that can be executed by a rule-based engine. Using a rule template facilitates the generation of one or more rules because the instructions for generating the executable logic can be formulated in natural language. The rule template can be a predefined rule template. Rule templates can be generated to match (multiple) data models associated with (multiple) products or (multiple) product types.

[0167] In embodiments of a method for verifying input material data associated with (multiple) input materials, one or more rules define (multiple) data points and / or (multiple) combinations of data points to be present within the input material data. This ensures that the input material data includes all (multiple) data points required for a data model of a product or product type, thereby ensuring that the collected input material data includes all data points required for a data model of a specific input material.

[0168] In embodiments of the method for verifying input material data associated with (multiple) input materials, the verification of the input material data may further include transforming the input material data. Transforming the input material data may include unit transformation to convert the units associated with the data points to units required by the data model associated with the product or product type. This can allow the unit transformation operation to be shifted to the consumer side, thereby allowing for simplified generation of provider-side output product datasets to ensure that various suppliers in the product ecosystem can reliably provide (multiple) output product datasets regardless of the physical size of the produced output product.

[0169] In embodiments of a method for verifying input material data associated with (multiple) input materials, one or more rules are associated with or derived from a data model of a product or product type, particularly wherein the one or more rules are defined by (multiple) mandatory input material data points existing within the data model. The data model may be a predefined (e.g., existing) data model. The data model may define the data structure of a product pass. The data model may define (multiple) values ​​and / or (multiple) value ranges of (multiple) data points to be included in the product pass. The data model may define (multiple) mandatory and optional data points to be included in the product pass. The data model may define relationships between (multiple) different data points.

[0170] In embodiments of the method for verifying input material data associated with (multiple) input materials, verification of the collected input material data by a rule-based engine includes identifying one or more rules applicable to the collected input material data and providing (multiple) applicable rules to the rule-based engine. As previously described, (multiple) applicable rules can be identified based on an identifier associated with each applicable rule that matches or relates to at least one input material identifier included in the collected input material data. (Multiple) applicable rules can be included in rule templates. Therefore, verifying the collected input material data may include identifying applicable rule templates. (Multiple) applicable rules and / or applicable rule templates can be stored on a database connected to the rule-based engine. The identifier associated with each applicable rule or rule template can correspond to a numeric input material identifier included in the collected input material data. (Multiple) applicable rules or rule templates can be collected based on mapping data that includes (multiple) identifiers associated with (multiple) rules or rule templates and associated (multiple) input material identifiers, and optionally (multiple) input material type identifiers.

[0171] In embodiments of the method for verifying input material data associated with (multiple) input materials, the transformation of the collected input material data includes

[0172] • Generate executable logic based on one or more of the identified applicable rules.

[0173] • And transform the collected input material data by executing executable logic generated by a rule-based engine under the constraints of rule enforcement standards.

[0174] In embodiments of the method for verifying input material data associated with (multiple) input materials, the input material data is verified in response to satisfying one or more rules applied to the input material data by a rule-based engine. This ensures that the collected input material data is verified only if the rule-based engine can successfully apply (multiple) rules to the collected data, for example, if the application of (multiple) rules does not produce errors (e.g., due to missing data, incorrect data, incomplete data, etc.). This ensures that product passes can be generated by applying the appropriate data model to the verified input material data and the corresponding product data without any errors due to missing or incorrect input material data, thereby avoiding delays in product pass generation.

[0175] In embodiments of the method for verifying input material data associated with (multiple) input materials, the storage location is determined based on mapping data, which includes mappings between (multiple) input material identifiers and associated storage location data, or mappings between (multiple) input material identifiers and associated (multiple) input material type identifiers and storage location data. The storage location may correspond to a database. The database may be a relational database or a non-relational database. Using (multiple) different storage locations enhances data security because verified input material data used to generate product passes associated with a specific product type (e.g., a battery) can be stored in a dedicated storage device accessible only by an application that generates passes for that specific product type, and not by other applications that generate passes for other product types.

[0176] In embodiments of the method for verifying input material data associated with (multiple) input materials, the verified input material data includes one or more verified input material characteristic data points, verified input material identifier data points, verified input material name data points, verified input material producer data points, verified input material declaration data points, verified input material safety data points, verified input material emission data points, verified input material recyclable content data points, verified input material bio-based content data points, verified input material biodegradability data points, verified input material production data points, verified input material analysis certificate data points, verified input material certificate data points, verified input material lifecycle data points, verified input material storage instructions data points, verified input material assembly instructions data points, and / or verified input material operating condition data points.

[0177] In an embodiment of the method for verifying input material data associated with (multiple) input materials, the method further includes the step of: generating incident data in response to determining that at least one rule applied to the collected input material data by a rule-based engine is not satisfied. The incident data may identify (multiple) data points and (multiple) rules that cause the non-compliance. The incident data may be provided to a data provider from which disputed input material data is received, thereby allowing the data provider to generate updated input material data and provide such updated input material data for duplicate verification. Attached Figure Description

[0178] The disclosure will be further described below with reference to the accompanying drawings. In the drawings and the disclosure, the same reference numerals are intended to refer to the same or similar elements, components and / or portions.

[0179] Figure 1 An example of a participant network in a product ecosystem is shown, which includes material recycling and is associated with a decentralized peer-to-peer network for exchanging data related to raw materials, (multiple) chemical products, (multiple) discrete products, (multiple) final products and (multiple) recycled materials.

[0180] Figure 2 An example of a participant network in the battery ecosystem is shown, which includes material recycling and is associated with a decentralized peer-to-peer network for exchanging data related to raw materials, (multiple) chemical products, batteries, (multiple) end products and (multiple) recycled materials.

[0181] Figure 3A and Figure 3B A schematic block diagram illustrating the battery manufacturing process is shown.

[0182] Figure 4 The illustration shows a battery with battery identification elements as a product.

[0183] Figure 5 The illustration schematically shows a battery component with identification elements, which is used as an input material for battery production.

[0184] Figure 6A A block diagram of an example system is shown for generating multiple output product datasets associated with multiple output products and providing the generated multiple output product datasets for access by distributed data consumer nodes.

[0185] Figure 6B The diagram shows an example of collecting output product data and transforming at least a portion of the collected output product data using a rule-based engine.

[0186] Figure 7 An example system and associated method are shown for generating (multiple) output product datasets associated with (multiple) output products produced and providing access to the generated (multiple) output product datasets.

[0187] Figure 8 An example of a decentralized system for accessing datasets of multiple output products associated with multiple output products is shown.

[0188] Figure 9 A flowchart illustrates an example method for generating a dataset of (multiple) output products associated with (multiple) output products.

[0189] Figure 10 Showing Figure 9 Examples of the methods shown in the document.

[0190] Figure 11 A flowchart is shown for another example method for generating a dataset of (multiple) output products associated with (multiple) output products.

[0191] Figure 12 A sequence diagram illustrating example methods for generating a dataset of output products associated with the (multiple) output products produced.

[0192] Figure 13A A block diagram of an example system for identifying input material data associated with (multiple) input materials used in the production of products is shown.

[0193] Figure 13B The diagram shows an example of using a rule-based engine to identify input material data associated with (multiple) input materials used to produce the product.

[0194] Figure 14 A flowchart illustrates an example method for identifying input material data associated with (multiple) input materials used to produce the product.

[0195] Figure 15 Showing Figure 14 Examples of the methods shown in the document.

[0196] Figure 16 A sequence diagram illustrating an example method for identifying input material data associated with (multiple) input materials used to produce an output product.

[0197] Figure 17 A flowchart illustrates another example method for identifying input material data associated with (multiple) input materials used to produce the product. Detailed Implementation

[0198] Figure 1 An example of a participant network in a product ecosystem is illustrated, which is associated with a decentralized peer-to-peer network for exchanging data related to raw materials, (multiple) chemical products, (multiple) discrete products, (multiple) end products, and (multiple) recycled materials. Decentralized participant network 130 may include one or more decentralized network participants, such as decentralized participants 102 to 114. Decentralized network participants may be part of a product ecosystem that includes chemical products. The product ecosystem may include a production chain that produces the end product. The product ecosystem may include a recycling chain to recover at least a portion of the end-of-life products generated from the use of the end product. The product ecosystem may include raw material producer 104, chemical product producer 102, chemical product user 106, end-of-life product producer 108, end-of-life product user 110, EOL product collector 112, and recycler 114. Decentralized participant network 130 may include a chemical supply chain. The product ecosystem may allow the production of new products, such as chemical products, using recycled materials generated from the recycling of end-of-life products. The product ecosystem may be associated with the production and / or recycling of physical products. Products can be chemical products, intermediate chemical products, components, component assemblies, final products, scrapped products, or recycled materials.

[0199] At least some of the participants in the decentralized participant network 130 may be associated with the production of the product and / or the recycling of end-of-life products generated from the use of the product by product users (such as end-of-life user 110). Decentralized network participants 102 to 114 may refer to manufacturers of physical products, such as raw material producers 104, chemical product producers 102, chemical product users 106, end-of-life product producers 108, users of physical goods (such as end-of-life user 110), and / or participants in the recycling chain associated with the physical product (such as EOL product collectors 112 and recyclers 114). Decentralized network participants may be associated with decentralized participant identifiers. Decentralized participant identifiers can uniquely identify decentralized network participants within the decentralized participant network 130.

[0200] At least another portion of the participants in the decentralized participant network 130 may be associated with the generation of product passes(s). Such decentralized participants may not be associated with the production of products and / or the recycling of end-of-life products. Such decentralized participants may collect input material data (e.g., as in...) Figure 14 (as described in the context), and at least a portion of the collected input material data can be used to generate a product pass. The generated product pass can be provided by such a participant for access via a decentralized network 130. For example, recycler 114 can access such a product pass to determine the composition of the end-of-life product, thereby allowing the recycling process to be adapted based on the determined composition.

[0201] The participants(s) of the decentralized participant network 130 can be connected via material flows. A material flow can be a circular material flow 136. A circular material flow 136 can be a closed-loop material flow. A closed-loop material flow can refer to a material cycle from which recycled material is used to produce the same final product, the recycled material being obtained from that material cycle via recycling. A circular material flow 136 can also be an open-loop material flow. An open-loop material flow can refer to a material cycle from which recycled material is used to produce a different final product compared to the material flow from which recycled material is obtained. A material flow can be a linear material flow (e.g., excluding recycling). Material flows 136, 138 can correspond to the flow of product from one participant in the decentralized participant network 130 to a downstream participant in the decentralized participant network 130. Material flows 136, 138 can refer to continuous or discontinuous flow of product. The flow of product can include any mode of transport suitable for transporting product from a participant to a downstream participant. Transport modes can include pipes, containers, barrels, and packaging. Material flow 138 can be associated with raw materials (e.g., virgin raw materials) used to produce the chemical product. Raw materials can be supplied to chemical product producer 102 for the production of (multiple) chemical products and / or (multiple) intermediate chemical products (not shown). A recycled material stream 136 can be associated with (multiple) chemical products and (multiple) discrete products. The (multiple) chemical products can be supplied from chemical product producer 102 to chemical product user 106 for the production of (multiple) discrete products. The discrete products produced are different units sold as individual products, as opposed to chemical production. The recycled material stream 136 can be associated with recycled materials. Recycled materials can be supplied from recycler 114 to chemical product producer 102 for the production of (multiple) chemical products using the recycled materials.

[0202] At least some of the participants in the distributed participant network 130 may be associated with distributed participant network nodes 116 to 128. Distributed participant nodes 116 to 128 may be under the control of the corresponding distributed participant associated with the respective distributed participant node. Distributed participant nodes 116 to 128 may form a distributed network 134. Distributed network 134 may be a peer-to-peer communication network. Distributed network 134 may be configured to execute data transactions 132. Data transactions 132 may be based on a transaction protocol including (multiple) authentication and / or authorization mechanisms. Based on (multiple) authentication and / or authorization mechanisms, peer-to-peer communication may be established between distributed network nodes 116 to 128 associated with distributed network participants 102 to 114. One or more authentication mechanisms may be associated with or linked to an identifier, such as in... Figure 8 The context described above. One or more authentication mechanisms associated with the identifier can be accessed by distributed participant nodes, as in... Figure 8Decentralized configurations allow for more efficient use of computing resources and enhance the control of data owners in decentralized networks, as described in the context of [the previous sentence].

[0203] Data transactions between participating nodes in a decentralized network can be based on identifiers associated with the corresponding data to be accessed, for example, as in... Figure 8 Described in the context of [the relevant context]. Identifiers can be uniquely associated with the physical entity of the corresponding product and the associated product data. Identifiers can be decentralized identifiers that uniquely identify products within a decentralized network. Identifiers can be local identifiers used by the corresponding product producer to uniquely identify the corresponding product. Identifiers can be associated with (multiple) other identifiers, such as (multiple) identifiers of (multiple) production inputs (e.g., input materials) used to produce the output product. This allows tracking (multiple) product inputs used to produce the product (e.g., the final product). Identifiers can, for example, be included in the output product dataset associated with the product, such as in [the relevant context]. Figure 9 Described in the context of.

[0204] Data flows 132 (e.g., transactions) between distributed network participant nodes can be directly or indirectly associated with material flows 136, 138 between distributed network participants. For example, if data associated with input materials supplied from raw material producer 104 to chemical product producer 102 is accessed by a distributed participant node 118 associated with said chemical product producer 102, then data flow 132 can be directly associated with material flows 136, 138. For example, if data associated with chemical products produced by chemical product producer 102 is accessed by a distributed participant node 128 associated with recycler 114, then data flow 132 can be indirectly associated with material flows 136, 138.

[0205] Distributed participant nodes 116 to 128 may be distributed computing nodes. A distributed computing node may be any device or system comprising at least one physical tangible processor and physical tangible memory capable of having computer-executable instructions executed by the processor thereon. The memory may take any form and depends on the nature and form of the computing node.

[0206] At least some of the distributed participant nodes 116 to 128 may be distributed data providing network nodes. At least some of the participant nodes 116 to 128 may be distributed data consuming network nodes. Participants in the distributed participant network 130 may be associated with distributed data providing network nodes and / or distributed data consuming network nodes, depending on whether the data is provided to downstream participants or consumed from upstream participants. For example, final product producer 108 may be associated with a distributed data providing network node configured to provide product data to downstream participants (e.g., recycler 114). Alternatively, final product producer 108 may be associated with a distributed data consuming network node configured to access data associated with discrete products produced by upstream participants (e.g., chemical product user 106), for example, in Figure 8 Described in the context of.

[0207] The distributed network 134 may include additional distributed network nodes. These additional distributed network nodes may be distributed infrastructure service nodes (...). Figure 1 (Not shown in the image). Distributed infrastructure service nodes may not be associated with participants in the product ecosystem. Distributed infrastructure service nodes can provide services to distributed participant nodes 116 to 128, such as verifying the identity of distributed network participant nodes 116 to 128 before performing data exchange. Distributed network participant nodes 116 to 128 may be associated with or include multiple certificates, such as multiple X.509 certificates. Multiple certificates may be associated with multiple distributed infrastructure service nodes, which may include, for example, certificate issuance services and / or dynamic provisioning services that provide dynamic attribute tokens (e.g., OAuth access tokens). Thus, distributed network participant nodes 116 to 124 have a unique identifier embedded in the X.509 certificate that identifies the corresponding distributed network participant node 116 to 128. The information required to verify the certificate can be provided via a certification registry associated with the certificate issuance service and / or dynamic provisioning service. For example, in the IDSA Reference Architecture Model version 3.0 of April 2019, decentralized data provisioning network nodes associated with data owners, Certificate Authorities (CAs), and Dynamic Attribute Provisioning Services (DAPS), as well as decentralized data consuming network nodes associated with data consumers, verify identities before performing data exchange (not shown, see reference). Figure 8 ).

[0208] Figure 2An example of a participant network in a battery ecosystem is shown, which includes material recycling and is associated with a decentralized peer-to-peer network for exchanging data related to raw materials, (multiple) chemical products, batteries, (multiple) end products, and (multiple) recycled materials. Decentralized participant network 216 may include one or more decentralized network participants, such as decentralized network participants 108, 112, and 202 to 212. The battery ecosystem may include a production chain to produce end products, such as machines containing batteries. The battery ecosystem may include a recycling chain to recycle at least a portion of end-of-life batteries generated from the use of end products. The battery ecosystem may include miners 202, refiners 204, precursor cathode active material (PCAM) and cathode active material (CAM) producers 206, battery producers 208, end-of-life product producers 108, end-of-life product collectors 112, black powder producers 210, and metal extractors 212. A battery ecosystem can allow the production of new products, such as PCAM and CAM, from recycled materials (e.g., recycled metals and metal salts) generated from the recycling of end-of-life batteries or their components. A product ecosystem can be associated with battery production and / or recycling.

[0209] The decentralized participant network 216 may include participants(s) associated with the production of end products containing batteries and / or the recycling of end-of-life batteries or their components. Decentralized network participants may be manufacturers of physical products, such as miners 202, refiners 204, PCAM and CAM producers 206, chemical product producers 102, chemical product users 106, end-of-life product producers 108, and / or participants in recycling chains associated with end-of-life batteries or their components (such as EOL product collectors 112, black powder producers 210, and metal extractors 212). For example, metal extractor 212 and PCAM and CAM producers 206 may be a single entity performing recycling operations to obtain recycled materials (such as recycled metals and / or metal salts) and using the recycled metals and / or metal salts to produce (multiple) new chemical products (such as PCAM and / or CAM). Decentralized network participants may be associated with decentralized participant identifiers. Decentralized participant identifiers uniquely identify decentralized network participants within decentralized participant network 216.

[0210] At least another portion of the participants in the decentralized participant network 130 may be associated with the generation of the battery tokens. Such decentralized participants may not be associated with the production of end products containing batteries and / or the recycling of end-of-life batteries or components. Such decentralized participants may collect input material data (e.g., as in...) Figure 14(as described in the context), and at least a portion of the collected input material data can be used to generate a battery pass. The generated battery pass can be provided by such a participant for access via a decentralized network 130. For example, recycler 114 can access such a battery pass to determine the chemical composition of the end-of-life battery or its components, thereby allowing the recycling process to be adapted based on the determined composition.

[0211] In a distributed participant network 216, multiple participants can be connected via material flow, as in Figure 1 As described in the context. Raw materials (such as metals) can be supplied to refiner 204 for refining. Refined metals can be supplied to PCAM and CAM producers 206 for the production of cathode active materials. CAM can be used, for example, by battery producer 208 for the production of battery cells (see also...). Figure 3A , Figure 3B Individual cells can be used to produce batteries or battery packs (see also...). Figure 3B Batteries or battery packs can be supplied to end-product producer 108 to produce end products containing batteries, such as electric vehicles. Waste generated from battery production can be supplied to black powder producer 210.

[0212] At least some of the participants in distributed participant network 216 can be associated with distributed participant network nodes 218 to 232, as in Figure 1 Decentralized participant nodes 218 to 232 can form a decentralized network 208. The decentralized network 208 can be as described in... Figure 1 The context describes a peer-to-peer communication network. Decentralized configurations allow for more efficient use of computing resources and strengthen the control of data owners in decentralized networks.

[0213] Data transactions between participating nodes in a decentralized network can be based on identifiers associated with the corresponding data to be accessed, for example, as in... Figure 8 Described in the context of [the relevant context]. Identifiers can be uniquely associated with the physical entity of the corresponding product and the associated product data. Identifiers can be decentralized identifiers that uniquely identify products within a decentralized network. Identifiers can be local identifiers used by the corresponding product producer to uniquely identify the corresponding product. Identifiers can be associated with (multiple) other identifiers, such as (multiple) identifiers of (multiple) production inputs (e.g., input materials) used to produce the output product. This allows tracking (multiple) product inputs used to produce the product (e.g., the final product). Identifiers can, for example, be included in input material data associated with the input materials, such as [example data]. Figure 14 Described in the context of.

[0214] Data flows 132 (e.g., transactions) between distributed network participant nodes can be directly or indirectly associated with material flows 136, 138 between distributed network participants, as in... Figure 1 Described in the context of.

[0215] Distributed participant nodes 218 to 232 can be distributed computing nodes, such as in... Figure 1 Described in the context of.

[0216] At least some of the distributed participant nodes 218 to 232 may be distributed data providing network nodes. At least some of the participant nodes 116 to 128 may be distributed data consuming network nodes. Participants in the distributed participant network 130 may be associated with distributed data providing network nodes and / or distributed data consuming network nodes, depending on whether the data is provided to downstream participants or consumed from upstream participants (see also...). Figure 1 ).

[0217] The distributed network 134 may include additional distributed network nodes, such as in Figure 1 Described in the context of.

[0218] Figure 3A and Figure 3B A schematic block diagram illustrating the battery manufacturing process is shown. Batteries can be used in machines (such as automobiles). Batteries can be used until the end of their lifespan. Discarded batteries may have a state of health (SoH) below a predefined threshold. SoH can be a measurement indicating the level of battery degradation and remaining capacity. It can be defined as the ratio of maximum battery capacity to its rated capacity. SoH can be determined using the battery's battery management system (BMS). SoH can also be determined using battery capacity determination (BCD).

[0219] refer to Figure 4 The battery 402 may include a battery management system 408 and multiple battery cells 410 disposed within a battery housing 412. The battery cells 410 may be arranged in a battery pack or module comprising multiple battery cells 410. Each battery cell 410 may include an electrolyte 414, an anode element 416, a cathode element 418, and a separator 420. Depending on the application, different components of the battery may include different material compositions. For example, through... Figure 3A and Figure 3B The batteries produced in the demonstrated production process can be lithium-ion batteries.

[0220] Continue to refer to Figure 4Cathode elements 318 and 418 may include cathode active material (CAM) 342 coated on current collector foil 344 (such as aluminum foil or copper foil). CAM 342 may contain layered oxides (LiMO2, where M = Co, Ni, Mn, Al, such as LCO (LiCoO2) or NCM (LiNiO2). x Mn y Co z O2), NCA (LiNi) x Co y Al z O2); spinel (LiM2O4, where M = Mn, Ni, e.g., LMO (LiMnO4)); or phosphate (LiMPO4, where M = Fe, Mn, Co, Ni, e.g., LiFePO4). CAM 342 can be produced from lithium salts (e.g., LiOH and Li2CO3). CAM 342 can be produced from precursor materials via solid-state synthesis. Precursor materials can be produced by co-precipitation of transition metal sulfates or hydroxides (e.g., NiSO4, MnSO4, CoSO4, Ni(OH)2, Mn(OH)2, Co(OH)2). Co-precipitation can be achieved by adding sodium hydroxide and ammonia to a solution of the transition metal sulfate or hydroxide material. Precursor materials (e.g., Ni) can be produced by co-precipitation of transition metal sulfates or hydroxides. x Co y Mn 1-x-y (OH)2) is mixed with (various) lithium salts and calcined. The calcined material is ground and sorted to obtain CAM 342. CAM may further include binder 338, polyvinylidene fluoride (PVDF), and carbon as a conductive agent. Binder 338 may be a polymer produced from one or more monomers (e.g., raw material binder 306).

[0221] Continue to refer to Figure 4 The anode elements 316 and 416 may include an anode active material 334 coated on a current collector foil 336 (such as aluminum or copper foil). The anode active material may comprise artificial graphite (e.g., synthetically produced graphite), natural graphite, or mixtures thereof. Further, the anode active material may comprise silicon, SiO2, lithium titanate (LTO), or combinations thereof. Further, the anode active material may include a binder 338, such as styrene-butadiene rubber (SBR), a polymer thickener (such as carboxymethyl cellulose (CMC)), and carbon as a conductive agent. The binder 338 may be a polymer produced from one or more monomers (e.g., raw material binder 306).

[0222] Continue to refer to Figure 4Electrolytes 324 and 414 may include a salt 354 for providing conductivity, a solvent 352 (such as a carbonate, ester, or ether), and additives (such as alkyl sulfites and sulpholipids, for example, vinyl sulfite and propylene sulpholipid) for supporting the formation of the SEI layer. The solvent may include cyclic carbonates (such as ethylene carbonate (EC) or propylene carbonate (PC)), open-chain carbonates (such as dimethyl carbonate (DMC) and / or ethyl methyl carbonate (EMC)) or mixtures thereof. Salt 354 may include conductive lithium salts (such as lithium hexafluorophosphate (LiPF6), lithium bis(trifluoromethyl)sulfonylimide (LiTFSI)) and their derivatives (e.g., lithium bis(fluorosulfonyl)imide (LiFSI) or [tri(pentafluoroethyl)-trifluorophosphate] (LiFAP), lithium 4,5-dicyano-2-trifluoromethyl-imidazolium (LiTDI), lithium bis(oxalate)borate (LiBOB)). Salt 354, solvent 352 and other additives can be prepared from the corresponding raw materials 364, 366 and 368.

[0223] Continue to refer to Figure 4 The separators 320 and 420 may include microporous membranes, coated separators, nonwoven pads, solid inorganic materials, or polymer materials. Coated separators may include polyolefin-based membranes coated with, for example, PVDF or ceramic. Polyolefin-based membranes may be produced from the corresponding raw material 346. Separators 320 and 420 can separate spaces between electrodes and are permeable to ions.

[0224] A single battery cell (such as a lithium-ion battery cell 370) can be manufactured from an anode element 316, a cathode element 318, a separator 320, a casing 322, and an electrolyte 324. The casing can be a metal casing made of steel or aluminum 348. The casing can have various shapes, such as prismatic, circular, or pouch-shaped. The anode element 316, cathode element 318, and separator 320 can be placed inside the casing 322. The casing 322, including the anode element, cathode element, and separator, can be filled with electrolyte 324. The casing can be filled with electrolyte after it has been sealed and emptied. The casing can also be filled with electrolyte before it has been sealed.

[0225] refer to Figure 5Component identification elements 404 and 406 can be associated with the manufactured battery cell 410. Identification elements 404 and 406 can be physically attached to component 410. Identification elements 404 and 406 can be arranged inside or outside the product component 410. Identification elements 404 and 406 can be passive identification elements. Passive elements 404 and 406 can be arranged on the outer surface of the battery cell housing lithium salt 310. Passive elements 404 and 406 can be based on markings embedded in the cell housing. Passive elements 404 and 406 can include printed codes (such as barcodes or QR codes) and / or printed numbers (such as serial numbers) and / or combinations of printed numbers and letters (including symbols). Identification elements 404 and 406 can also be active identification elements. Active identification elements 404 and 406 can be transmitter or transceiver tags, such as RFID tags capable of communication via, for example, NFC, Bluetooth, Zigbee, or other suitable short-to-mid-range communication protocols. Identification elements 404 and 406 can be associated with digital component identifiers (e.g., digital battery cell identifiers). Digital component identifiers can include or relate to at least one input material identifier associated with (multiple) production inputs used to produce the component (e.g., the battery cell). Specifically, identification elements 404 and 406 can be configured to provide digital component identifiers, such as digital battery cell identifiers, for accessing component data associated with the corresponding component (e.g., the battery cell). Component data can include, for example, cathode active material composition data, anode active material composition data, and / or electrolyte composition data. Composition data can include data related to key compounds present within the CAM, anode active material, and / or electrolyte.

[0226] The manufactured battery cells (such as lithium-ion battery cell 370) can be used to produce battery packs, such as lithium-ion battery pack 372. Battery pack production can involve both module production and battery pack production. For module production, electrically insulating liquid or solid adhesives can be used, for example, to bond the battery cells. Examples of adhesives may include polyurethane-based adhesives. The bonded or stacked cells can be pressed to create a defined stack geometry and minimize expansion during charging and discharging. Plastic sheets or foils can be applied to the bonded or stacked cells for heat dissipation and electrical insulation. Stacked cells can be wired via electrical connections of contact tabs / current collectors. Depending on the module voltage, these cells can be contacted to form one or more parallel strings. A slave circuit board of the Battery Management System (BMS) 326 or a complete contact unit for processing data and controlling sensors can be bonded to the module via soldering and / or threaded connections. A controller, as well as a cooling system 332 (if required) later connected to the BMS host, can be bonded to the module. The manufactured modules can undergo testing procedures. Test procedures may include control of external irregularities (optical tolerances), communication and sensor functionality (software testing), cell voltage, cell differences (balance), module state of charge (SOC), HV strength (resistance measurement), gas leak testing, overvoltage testing, vacuum testing, etc. Modules may also be associated with identification elements, as described in the context of battery cells. Identification elements may also be configured to provide a digital module identifier for accessing module data associated with the corresponding module. Module data may include, for example, adhesive data associated with the adhesive used to bond the battery cells, data associated with the slave circuit board, and / or data associated with the cooling system. Module data may further include identifiers associated with the input materials used to produce the module, such as multiple battery cell identifiers, slave circuit board identifiers, and / or cooling system identifiers.

[0227] For battery pack production, cooling elements can be installed in the bottom of the battery pack tray or housing 328 for cooling and / or heating the modules. The produced battery modules can then be secured inside the battery pack housing. A cooling system 332 can be attached to and connected to the cooling elements in the battery pack housing. High-voltage modules can be installed and connected to the modules. The high-voltage modules may include relays, fuses, pre-charge and current measurement systems, insulation monitoring, etc. A battery management system (BMS host) can be installed and wired to control the cooling system, modules, slave circuit boards, and high-voltage modules. The final battery pack 372 can be obtained by applying sealant to the edge of the housing or cover, placing the cover of the housing on the sealant, and attaching it to the housing.

[0228] refer to Figure 4Identification elements 404 and 406 can be physically associated with battery 402. Identification elements 404 and 406 can be physically attached to battery housing 412. Identification elements 404 and 406 can be arranged inside or outside battery housing 412. Identification elements 404 and 406 can be passive identification elements 404 and 406 as described above, or active identification elements 404 and 406. For example, if the battery identifier associated with the battery is stored in BMS 408, then identification elements 404 and 406 can be part of battery management system 408.

[0229] Battery 402 may be associated with a digital battery identifier. The digital battery identifier may be associated with identification elements 404 and 406. The digital battery identifier may be stored within BMS 408. The digital battery identifier may be unique to the physical entity of battery 402. The digital battery identifier may be associated with battery data. This data may include any data collected during the production and / or lifespan of battery 402. For example, this data may include multiple input material identifiers associated with multiple production inputs used to produce the battery, data collected before, during, and / or after battery production, and / or monitoring data collected during the use of battery 402.

[0230] A digital battery identifier may be associated with or include at least one decentralized battery identifier. A decentralized battery identifier may include any unique identifier uniquely associated with the battery data and the identified battery 402. The decentralized battery identifier may further be associated with the data owner of the battery data. The decentralized battery identifier may include at least one Universally Unique Identifier (UUID) and / or at least one Digital Identifier (DID). The decentralized battery identifier may be issued by a centralized or decentralized identity issuing authority. The decentralized battery identifier may include authentication information used to authenticate the battery data. Access to the battery data can be controlled by the data owner of the battery data through the decentralized battery identifier and its unique association with battery 402. This contrasts with a centralized authority scheme, in which identifiers are provided by a centralized authority and access to the data is controlled by such a centralized authority. In this context, decentralized refers to the data owner controlling the use of the identifier. The decentralized battery identifier may be discoverable and / or accessible to the participating nodes(s) of the decentralized network. Based on the discovered and / or accessed decentralized battery identifier, access to a battery pass can be requested by (multiple) decentralized network nodes associated with a data consumer (such as a battery user or (multiple) recyclers handling the battery). Identification elements 404 and 406 can be configured to provide a decentralized battery identifier for accessing battery data.

[0231] A data owner can include any entity that generates data, particularly data related to the identified battery. A generating node can be coupled to an entity that owns a physical product from which data (particularly data related to the identified battery) is generated. This data (particularly data related to the identified battery) can be generated by a third-party entity representing an entity that owns a physical product from which data is generated. A data owner can be a producer of materials and / or (multiple) components contained in the battery, a battery manufacturer, or a producer of a final product containing a battery. A data owner can be a producer of materials or components that produces materials or components, a battery manufacturer that produces batteries, or a producer that produces (multiple) products containing batteries. Access to the corresponding data can be controlled by the data owner through a decentralized identifier and its unique association with the data owner and the data related to the identified product. The data owner can access the data related to the identified product. Therefore, the data owner can directly or indirectly own or control the data related to the identified product. The data related to the identified product can be stored in the data owner's storage environment or in a storage environment associated with the data owner. Data associated with the identified product can be stored in a storage environment accessible to the data owner. The data owner can control access to the data associated with the identified product by providing services through the data owner's data. The data owner can control access to the data associated with the identified product. The data owner can control access to battery tokens via distributed battery identifiers. Data associated with the identified product can be associated with the data owner. The data owner can be the owner or controller of the data associated with the identified product or the data associated with the owner of the identified product. Data associated with the identified product can be stored in the data owner's storage environment or in a storage environment controlled by the data owner. In this sense, a data owner can refer to an entity capable of accessing data associated with the identified product or its components and controlling access to data associated with the identified product or its components provided by network nodes through distributed data provision in a distributed computing environment.

[0232] Specifically, the distributed identifier may relate to material data specifying the material composition of one or more components of the battery. The distributed battery identifier may be associated with battery 402, and the material data may specify the material composition of one or more components of battery 402.

[0233] The battery packs produced (such as lithium-ion battery pack 372) can be used to produce machines powered by electric motors, such as electric vehicles or vehicles that include both combustion engines and electric motors.

[0234] Figures 3A to 5 The use of batteries in production should not be interpreted as a limitation on the basic concepts outlined in these figures. Figures 3A to 5 The concepts shown also apply to the production of other (multiple) discrete products from one or more chemical materials and / or components, and to the use of such discrete products to produce component assemblies and / or final products. Figures 3A to 5 The concept shown also applies to the production of (multiple) chemical products from one or more input materials.

[0235] Figure 6A A block diagram of an example system is shown for generating a dataset of output products associated with (multiple) output products and providing the generated dataset of output products to distributed data-consuming nodes. Output products can be chemical products, intermediate chemical products, components, or component assemblies. Output products can be components of a battery, such as battery cells, battery modules, or battery packs. Output products can be any output product produced by (multiple) upstream production stages relative to the product production stage. Asset generation system 646 can be configured to perform... Figure 9 The method is illustrated in the diagram. This system can be associated with production (e.g., output product production) that produces (multiple) output products. Output products can be produced through production or can be produced through production. Produced output products can include the physical entity of an output product that has already been produced through that production. Producible output products can include output products that have not yet been produced through that production. Producible output products can be produced through one or more production processes executed within that production.

[0236] refer to Figure 7 Output product 706 may be produced or producible using one or more input materials 702. Output products may include or be produced by production 704 and provided at any exit point of production 704. Production 404 may be chemical production. Chemical production may be a chemical production network. Production 404 may be discrete production. Input materials may include starting materials used in the production process performed within production 704 to produce the output product. Input materials may be used in any process step of the production process. This means that an intermediate output product of one production plant of production 704 may correspond to the input materials of a subsequent production plant of production 704. Input materials may include recycled materials. Input materials may include or be any input material entering production 704. Input materials may include or be any input material provided at any entry point of production 704.

[0237] The output product can be produced within production 704 from (multiple) input materials 702 via one or more process steps. These process steps may involve chemical reactions and / or physical processes, and / or assembly processes involving the assembly of different discrete input materials, and / or processes involving both chemical and discrete input materials, such as filling processes. The input materials can be used in one or more such production steps. Input materials 702 can enter the system boundary 714 of production 704 at an entry point, such as a production plant or material storage facility associated with production 704. The amount of input material entering the system boundary 714 of production 704 can be measured, for example, using a sensor 708a. Sensor 708a includes a sensor configured to measure the amount (e.g., weight and / or volume) of the input material. As the input material passes through the system boundary 714 of production 704, the chemical and / or physical properties of the input material can be measured, for example, using a sensor 708b. The measured data can be used to determine at least one chemical and / or physical property of the corresponding input material. Examples of chemical properties include heat of combustion, enthalpy of formation, toxicity, chemical stability in a given environment, flammability, (multiple) oxidation states, corrosiveness, combustibility, acidity and alkalinity, chemical composition, content of recycled materials used in the production or manufacture of the input material, bio-based content of the input material used in the production or manufacture of the input material, recyclability content of the input material used in the production or manufacture of 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, charge, conductivity, electrical impedance, potential, flow rate, fluidity, hardness, heat capacity, inductance, intrinsic impedance, brightness, luminosity, gloss, mass, melting point, opacity, permeability, permittivity, plasticity, pressure, emissivity, resistivity, reflectivity, refractive index, solubility, specific heat, strength, stiffness, temperature, tensile strength, thermal conductivity, thermal resistance, viscosity, volume and / or wave impedance.

[0238] The operating system 716 for production 704 can monitor and / or control production 704 based on operating parameters of different processes. The operating system 716 can receive production demand data associated with the production plan of production 704. Production demand data can be generated from the target production capacity of one or more output products produced by production 704. Production demand data can be generated from predefined production capacity or from a data-driven model that links production capacity to market demand data or the amount consumed at a consumption location. Production demand data may include the target capacity of the output products produced by production 704. The operating system 716 can further receive a bill of materials associated with the output products to be produced. The bill of materials may include material data associated with the input materials used to produce the output products, process data associated with the production chain used to produce the output products, and / or output product data associated with the output products (such as product specification data or data about the quantity of output products to be produced).

[0239] Based on the received production demand data and bill of materials, material demand data can be determined. Material demand data may include data on the amount of input materials required for the target production capacity of the output product. Material demand data may include input material identifiers associated with the input materials required for the production output product, and data on the quantity of the corresponding input materials. Material demand data may include one or more material specifiers representing each input material identifier. Material demand data may include data on the quantity of material for each input material identifier representing the quantity of material to be supplied. Material demand data may specify the production chain(s) for producing 704. Material demand data may include a bill of materials for one or more production chains used to produce 704. Material demand data may include one or more formulations of one or more materials used in one or more production processes used to produce 704. The determined material demand data may be made available to supplier systems associated with suppliers outside the physical system boundaries for producing 704. Material supply can be triggered by accessing the material demand data through the supplier system.

[0240] Sensors (such as sensor 708b) can be used to measure the quantity of (multiple) output products generated by the process performed within production 704. The measured data can be stored in one or more databases associated with operating system 716. Furthermore, sensors (such as sensor 708b) can be used to monitor the process performed within production 704, and the generated monitoring data can be stored in one or more databases associated with operating system 716. The monitoring data can be correlated with digital output product identifiers associated with the corresponding output product. The physical and / or chemical properties of the produced output products can be measured by sensors (such as sensor 708a). Physical and / or chemical properties can include the properties previously described. The measured and / or determined chemical and / or physical properties of the produced output products can 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 can be correlated with digital output product identifiers associated with the corresponding output product.

[0241] The produced output product 706 can be provided at one or more exit points of production 704. The output product 706 can leave the system boundary 714 of production 704.

[0242] Operating system 716 may include asset generation system 646. Operating system 716 may be associated with asset generation system 646 (not shown). Asset generation system 646 may be configured to generate a dataset of output products (e.g., multiple assets) associated with the multiple output products produced by production 704, such as in... Figure 9 Described in the context of.

[0243] Return to reference Figure 6A And continue to refer to Figure 7 The asset generation system 646 can generate multiple output product datasets in response to receiving a trigger signal. The trigger signal may be associated with or may include trigger data. Trigger data may include data associated with the output products produced by production 704. The trigger signal may be generated by a trigger generator 712. The trigger generator 712 may be part of a packaging line or may be located in a storage location (e.g., a warehouse). The trigger generator 712 may include multiple sensors configured to detect the produced and / or packaged output products. The multiple sensors may be configured to detect identification elements physically attached to the produced or packaged output products. The trigger generator 712 may use sensor data to generate trigger data, which includes data associated with the produced output products. Data associated with the produced output products may include a digital output product identifier associated with the produced output product. The trigger signal may be generated by a user, for example, using a front-end application that allows the generation of trigger data. The front-end application may display data associated with the produced output products, such as the output product name, output product quantity, output product identifier, etc. This data can be collected from one or more databases that store data associated with the output products. The user can select (multiple) output products to be displayed by the front-end application. In response to the selection of (multiple) output products, a back-end application connected to the front-end application can generate trigger data by collecting (multiple) digital output product identifiers associated with the selected (multiple) output products. The collected (multiple) digital output product identifiers are used to generate the trigger data.

[0244] Trigger signals or trigger data can be received by the data collection unit 622 of the asset generator service 606. The data collection unit 622 can be connected to the data source layer 620. The data source layer 620 can include one or more databases, such as DB 1614, DB 2 616, and DB 3 618. The database can be a distributed data source. A distributed data source can be a data lake that includes output product data from multiple distributed data sources. A distributed data source can be a collection of data stored at different sites on a computer network. Each site may have a degree of autonomy, serving the execution of a local application but also participating in the execution of a global application. For example, a distributed data source can be a distributed database. A distributed database can be created by splitting data from an existing database and distributing it across different sites or by combining multiple existing databases. Each data source may contain only fragments of data associated with chemical products. This results in the segmentation of the data. Two common types of data segmentation are: horizontal segmentation, where (potentially overlapping) subsets of data tuples are stored at different sites; and vertical segmentation, where (potentially overlapping) sub-tuples of data tuples are stored at different sites. More generally, data associated with output products can be partitioned into a set of relations (tables in a relational database distributed across multiple sites). One or more distributed data sources can contain output product data associated with the produced output products. Output product data can include output product identifier(s), characteristic data associated with the output product, output product name, output product producer, output product declaration data, output product safety data, emission data associated with the output product, recyclable content data associated with the output product, bio-based content data associated with the output product, production data associated with the output product, analytical certificate data associated with the output product, certificates associated with the output product, lifecycle data associated with the output product, storage instructions data associated with the output product, assembly instructions associated with the output product, operating conditions associated with the output product, or combinations thereof. At least one of the distributed data sources can contain data instances relating to output products for which system 710 is configured to generate output product datasets(s). Data source layer 620 can be owned or controlled by the data owner of the data associated with the output product data. Data source layer 620 can be associated with the data owner of the output product data. Data collection unit 622 can be configured to collect output product data based on received trigger data (e.g., data associated with the produced output product from data source layer 620), for example, as in... Figure 9The collected output product data may include characteristic data associated with the output product, output product name, output product producer, output product declaration data, output product safety data, emission data associated with the output product, recyclable content data associated with the output product, bio-based content data associated with the output product, production data associated with the output product, analytical certificate data associated with the output product, certificates associated with the output product, life cycle data associated with the output product, storage instructions associated with the output product, assembly instructions associated with the output product, operating conditions associated with the output product, or combinations thereof.

[0245] The output product data collected by the data collection unit 622 can be provided to the data transformation unit 624. The data transformation unit 624 can be configured to transform the output product data collected by the data collection unit 622 based on one or more rules retrieved from the rule database 612, thereby generating (multiple) output product datasets, for example, as in... Figure 6BDescribed in the context of [the document / parameter]. Transformations may include: filtering collected output product data; aggregating output product data collected from multiple data sources into a given data structure; constructing attributes based on existing attributes to create or add new attributes to output product data; discretizing to transform continuous output product data values ​​into a set of data intervals with specific values; generalizing collected output product data to transform low-level data attributes into high-level data attributes; manipulating to change or modify collected output product data; and / or normalizing to transform output product data into another data structure to limit the occurrence of duplicate data. Multiple rules may define multiple key-value pairs to be included in the generated output product data. Multiple rules may define multiple values ​​to be included in the generated output product data. Multiple rules may define multiple units for multiple data points and / or one or more transformations for transforming units associated with data points into another unit. Multiple rules can define key-value pairs for the following: characteristic data, output product identifier data, output product name data, output product producer data, output product declaration data, output product safety data, emissions data, recyclable content data, bio-based content data, biodegradability data, production data, analysis certificate data, certificate data, lifecycle data, storage instructions data, assembly instructions data, and / or operating condition data. Rules can define key-value pairs for each data category. Rules can define key-value pairs for at least two different data categories. Data categories can represent characteristic data, declaration data, safety data, emissions data, recyclable content data, bio-based content data, biodegradability data, production data, analysis certificate data, certificate data, storage instructions data, assembly instructions data, or operating condition data. The collected data can be aggregated and filtered to extract values ​​from the aggregated data that match the keys defined in the multiple rules. The resulting output product dataset can include one or more data points. The output product dataset can include one or more key-value pairs. The resulting output product dataset can include at least a portion of the collected output product data.The generated output product datasets may include multiple output product characteristic data points, multiple output product identifier data points, multiple output product name data points, multiple output product producer data points, multiple output product declaration data points, multiple output product safety data points, multiple output product emission data points, multiple output product recyclable content data points, multiple output product bio-based content data points, multiple output product biodegradability data points, multiple output product production data points, multiple output product analysis certificate data points, multiple output product certificate data points, multiple output product lifecycle data points, multiple output product storage instructions data points, multiple output product assembly instructions data points, and / or multiple output product operating condition data points. The multiple output product datasets may include at least a portion of the collected output product data in a tabular data structure. Using rules associated with products produced from such multiple output products allows for ensuring that multiple output product data points required according to a data model (e.g., an aspect model) associated with the product or product type are included in the output product dataset, thus avoiding the loss of multiple data points during the generation of product passes associated with the product using said data model. This transformation allows for the aggregation of collected output products into a given data structure (e.g., a tabular data structure) without using complex data models, thereby facilitating the generation and sharing of multiple output product datasets within the product ecosystem. This sharing enables more efficient production and / or recycling processes based on shared output product data (e.g., based on output product composition data included in the shared output product dataset). The tabular data structure can be easily consumed by a consumer backend via a decentralized network, which is configured to confirm the consumed data and persistently store the confirmed consumed data to a data storage device for the generation of product passes (see, for example). Figure 13A and Figure 13B Consumer-side validation ensures that the product pass contains all the data required for the data model used to generate such a pass, thereby reducing the complexity associated with generating output product datasets on the provider side by avoiding the use of a data semantic model during the generation of (multiple) output product datasets. This enables reliable sharing of output product data for (multiple) output products regardless of the existence of a data model for such output products, as the (multiple) rules required to transform the collected output product data can be readily derived from or generated based on an existing data model associated with the product or product type.

[0246] Data transformation unit 624 can be further configured to provide the generated output product datasets (hereinafter also referred to as assets) to data provider unit 644. Data provider unit 644 can be configured to provide the received output product datasets to a database (e.g., asset DB 604) for storage. The assets may include or be associated with a digital output product identifier. This allows for the retrieval of assets based on the digital output product identifier. The assets can be persistently stored in asset DB 604 by data transformation unit 624. Asset DB 604 can be configured to store the output product datasets generated by data transformation unit 624. Asset DB 604 can be configured to provide the output product datasets to data transmission service 602.

[0247] The data provider unit 644 may be further configured to provide data (such as digital output product identifiers) included in the generated output product dataset(s) to the asset publisher service 608.

[0248] Asset publisher service 608 can be configured to generate group access data associated with a corresponding output product dataset. The group access data can identify access control groups, which include decentralized participant(s) identifiers associated with decentralized network participants granted access to the corresponding output product dataset. The group access data may include a group access data identifier. The group access data may further identify one or more authorization rules defining access to and / or use of the output product dataset. Asset publisher service 608 can be further configured to generate a contract template that includes a digital output product identifier and a group access data identifier. Therefore, the contract template can be associated with the output product dataset and the corresponding group access data. The contract template may further include access data associated with asset DB 604. The access data may include a locator or pointer to asset DB 604, where the corresponding output product dataset is stored. This can allow access to the corresponding output product dataset based on data included in the contract template (e.g., digital output product identifiers and access data). The group access data and contract template can be generated by asset publisher service 608 for each piece of data included in the output product dataset (e.g., for each digital output product identifier). The generated group access data and contract templates can be provided to the decentralized data provider node 118 connected to the asset generation system 646.

[0249] Distributed data provider node 118 can be part of a distributed network, such as in... Figure 1 and Figure 2The distributed network 134 is described in the context of the distributed network. The distributed data provider node 118 can be configured to provide (multiple) output product datasets in response to requests received from (multiple) distributed data consumer nodes, for example, as in... Figure 8 Decentralized data provider node 118 can be configured to control access to (multiple) output artifact datasets based on associated group access data and contract templates generated by asset publisher service 608, for example, as described in... Figure 8 As described in the context, distributed data provider node 118 can be associated with participants in the product ecosystem, such as producers of (multiple) output products.

[0250] Data transfer service 602 can be configured to collect (multiple) output product datasets from asset DB 604 in response to a request from distributed data provider node 118. Data transfer service 602 can be configured to retrieve asset metadata from asset DB 604 based on data received from distributed data provider node 118. Data transfer service 602 can be configured to parse the retrieved metadata to determine group access data associated with the corresponding output product dataset and / or the storage location of the corresponding output product dataset. Data transfer service 602 can be configured to collect the corresponding output product datasets from asset DB 604 based on the retrieved metadata. Data transfer service 602 can be configured to provide the collected output product datasets (multiple) to distributed data provider node 118.

[0251] The system may not include a distributed registry storing access elements that allow access to (multiple) output product datasets stored in asset DB 604. Therefore, instead of locating (multiple) output product datasets by querying the distributed network using digital output product identifiers, (multiple) output product datasets can be accessed directly from the distributed data provider node 118 using only the digital output product identifiers. Therefore, location data pointing to dedicated storage devices storing the output product datasets and their identifiers may be required to access the respective output product datasets. Combining the location data with the digital output product identifiers of the output product datasets produces a unique identifier that allows a given output product dataset to be uniquely identified within the distributed network.

[0252] Figure 6B The diagram illustrates an example of collecting output product data and transforming at least a portion of the collected output product data using a rule-based engine. Transforming at least a portion of the collected output product data can result in the generation of (multiple) output product datasets, as shown in... Figure 6A Described in the context of.

[0253] Data transformation unit 624 may include rule-based engine 628. Rule-based engine 628 can operate on individual data points, multiple data points, and / or collected output product data. Rule-based engine 628 can operate individually on data collected for each digital output product identifier. This allows for transformation of the collected output product data for each output product, thereby allowing for finer-grained transformation of the output product data. Rule-based engine 628 can receive requests to transform the collected output product data. These requests may include at least a portion of the collected output product data. Output product data may be collected by data collection unit 622 from data source layer 620 (see operation 626), as in... Figure 6A The rule-based engine 628 is described in the context of [the description]. It can be configured to determine output product identifiers(s) associated with output product data. For example, the rule-based engine 628 can parse received output product data to determine corresponding output product identifiers(s). The rule-based engine 628 can access one or more rules. The rule-based engine 628 can include one or more rules. One or more rules can exist within a rule template. One or more rules can be stored in a data storage device (e.g., rule DB 612). One or more rules or rule templates(s) can be provided to rule DB 612 by a user. One or more rules can correspond to unstructured data associated with instructions related to transformation operations(s). Rule templates(s) can correspond to unstructured data associated with instructions related to transformation operations(s). One or more rules or rule templates can be included in a file provided by a user. One or more rules or rule templates(s) can be associated with output product type identifiers(s) and / or output product data identifiers(s). The rule-based engine 628 can generate a request to obtain one or more rules from rule DB 612. This request can contain corresponding output product identifiers(s).

[0254] One or more rules (e.g., one or more applicable rules) associated with the output product data to be transformed can be provided to the rule-based engine 628 in response to a request. One or more rules can be associated with (multiple) products produced from the output product associated with the output product data to be transformed, for example, the output product associated with the output product data to be transformed can be used as input material to produce the product. The product can be a component. The product can be a component assembly. The product can be a final product. The product can be a chemical product. One or more rules can be associated with or derived from a data model of the product or product type. Thus, one or more rules can ensure that (multiple) data points of such output product required according to the data model can be included in the generated output product dataset. One or more rules can be defined by mandatory output product data points existing within the data model. One or more rules can be generated based on mandatory output product data points existing within or defined by the data model. This ensures that the output product data required by the data model is included in the generated output product dataset. One or more rules can be associated with (multiple) output product identifiers and / or (multiple) output product type identifiers. A mapping table can be used to map (multiple) output product identifiers to corresponding (multiple) output product type identifiers. The (multiple) output product type identifiers can be associated with (multiple) output product types. The mapping table can be stored in a separate database (not shown). The rule-based engine 628 can be configured to collect (multiple) output product type identifiers based on the determined (multiple) output product identifiers, and to request (multiple) rules based on the collected (multiple) output product type identifiers. This allows for the collection of (multiple) rules associated with (multiple) output product type identifiers based on the (multiple) output product identifiers, thereby avoiding the generation of (multiple) rules for each output product identifier and reducing the number of rules that need to be generated, stored, and maintained in the rule DB 1318.

[0255] One or more rules can define aggregation rules for aggregating output product data collected from multiple data sources into a given data structure. The given data structure can be a tabular representation. Therefore, aggregation allows the collected output product data to be populated into the tabular data structure. One or more rules can define filters for filtering the collected output product data. Filters can be associated with or related to semantic data of the product or product type. Filters can define data points to be included in the generated output product dataset. For example, a filter can define one or more output product characteristic data points, output product identifier data points, output product name data points, output product producer data points, output product declaration data points, output product safety data points, output product emission data points, output product recyclable content data points, output product bio-based content data points, output product biodegradability data points, output product production data points, output product analysis certificate data points, output product certificate data points, output product lifecycle data points, output product storage instructions data points, output product assembly instructions data points, and / or output product operating conditions data points. Filters can define data points for each data category. A filter can define (multiple) data points for at least two distinct data categories. Data categories can represent characteristic data, claim data, safety data, emissions data, recyclable content data, bio-based content data, biodegradability data, production data, analytical certificate data, certificate data, storage instruction data, assembly instruction data, or operating condition data. This ensures that the output product data required by the data model is included in the generated output product dataset. One or more rules can define attribute constructs (multiple) for creating new attributes or adding new attributes to the collected output product data. One or more rules can define manipulations (multiple) for transforming (multiple) output product data points. For example, (multiple) data points present in the collected output product data can be transformed from one unit to another. This ensures that the generated output product dataset includes data points associated with the units required by the product's data model. One or more rules can include trigger conditions and a corresponding set of one or more actions. Trigger conditions can involve a set of variables, sometimes called "working memory," which can contain data representing the state of relevant real-world items (sometimes called "facts" or "data tuples"). One or more actions can include attribute constructs, filtering, and / or manipulations. A given output product identifier and / or output type identifier may be associated with the following: rules defining aggregation, rules defining filters, rules defining attribute construction, rules defining manipulation, and / or rules including triggering conditions and actions. These rules may be associated in a given order.

[0256] The rule-based engine 628 can be configured to initialize a rule engine (see operation 632). Initialization of the rule engine may include generating rule data executable by a processor included in the rule-based engine 628. The rule data may include or correspond to executable logic. This may allow the transformation of rules(s) or rule(s) templates existing in unstructured data form into code executable by the processor. Execution of the code may enable the application of the executable rule data to collected output product data (see operation 634) to transform the output product data according to the obtained rules(s). Execution of the logic may enable matching the collected output product data with conditions(s) included in the executable logic, evaluating the conditions(s) with the matched output product data, and triggering the execution of rule actions based on the condition evaluation results. Transforming the output product data may include filtering the collected output product data. Filtering the collected output product data may include comparing individual data points present in the collected output product data with data points defined by the filters(s) to determine output product data points to be included in the output product dataset. Transforming output product data may include comparing attributes of the collected or filtered output product data with attributes defined in multiple rules to determine whether new attributes must be created or added to the collected or filtered output product data. Alternatively, transformation may include comparing attributes included in the collected or filtered output product data, or in output product data including added or created attributes, with attributes included in multiple modification rules. Multiple modification rules may include trigger conditions that can be associated with one or more actions, such as unit conversion if the trigger condition is met, and / or error handling if applying a filter results in empty data points due to missing data points in the collected output product data. Trigger conditions may be met if attributes included in the collected or filtered output product data, or in output product data including added or created attributes, do not match attributes defined in multiple modification rules. Operations performed by the rule-based engine 628 may be determined by multiple rules collected from rule DB 612. For example, the rules collected from rule DB 612 can determine whether the rule-based engine 628 operates on (multiple) individual data points and / or multiple data points and / or the entire collected output product data.

[0257] The rule-based engine 628 can be configured to determine whether the collected output product data can be transformed by one or more applied rules (see operation 636). If the collected output product data does not include the data points(s) required according to one or more obtained rules, the collected output product data may not be transformed or may only be partially transformed (e.g., transformation may result in at least one error associated with applying one or more obtained rules to the collected output product data). The rule-based engine 628 may provide the generated output product dataset to the asset DB 604 in response to successful transformation of the collected output product data (e.g., in response to generating an output product dataset by applying one or more obtained rules without generating an error).

[0258] If at least a portion of the collected output product data cannot be transformed, the rule-based engine 628 can proceed to operation 638. In operation 638, the rule-based engine 628 can generate message data indicating that at least a portion of the collected output product data cannot be transformed. The message data may include an indication of which data points(s) of the collected output product data cannot be transformed. The message data can be provided to a display device configured to display data received from the rule-based engine 628. The display device may include a graphical user interface 640. The display device may display the message in response to receiving the message data from the rule-based engine 628. This allows triggering correction or update of data points(s) identified as not matching one or more of the acquired rules(s). After correcting or updating the correspondingly identified data points(s), collection and transformation of the updated or corrected output product data can be initiated.

[0259] Figure 8 An example of a decentralized system for accessing data associated with the produced (multiple) output products is shown. Output products can be battery components, such as battery cells, battery modules, or battery packs. Output products can be chemical products or intermediate chemical products. Output products can be any output product produced by (multiple) upstream production stages relative to the chemical product production stage. A decentralized system can be as follows: Figure 1 and Figure 2 The distributed peer-to-peer networks described in the context of 134, 208.

[0260] The output product can be associated with (multiple) output product datasets. This can be done as follows: Figures 6A to 7Multiple output product datasets are generated as described in the context. These datasets may be stored in an asset DB 604 associated with data transmission service 602. Asset DB 604 may be associated with distributed provider node 118. Distributed provider nodes may be associated with distributed network participants. Distributed network participants may be producers of the output products. Distributed network participants may be data owners of the multiple output product datasets stored in asset DB 604. Each output product dataset may represent at least a portion of a digital twin of the physical entity of the output product. The digital twin may be a digital representation of the physical entity. Therefore, a digital twin may represent a digital version of the physical entity. Once created, the digital twin can be used to represent the physical entity of the output product in a digital representation of a real-world system.

[0261] Distributed systems can be used to collect input material data associated with (multiple) input materials used to produce (multiple) products, such as in... Figure 13A and Figure 16 The context describes this. Input material data may correspond to multiple output product datasets stored in asset DB604. Input material data may be collected by downstream production stages relative to the production stage of the output product.

[0262] Decentralized systems can include one or more decentralized participants, such as data consumers and data providers. Data consumers and data providers can communicate via decentralized networks (such as decentralized peer-to-peer networks, see e.g. ... Figure 1 and Figure 2 A data provider can offer data consumers data associated with the output products, such as output product data. A data consumer can request input material data from a data provider, such as output product data. A data provider can correspond to an entity that produces the output products (such as chemical products or discrete products). A data consumer can correspond to an entity that uses the produced (multiple) output products and / or performs [activities / operations]. Figures 13A to 16 The entities disclosed in the method. Data consumers may correspond to downstream participants in the production chain used to produce the product. Data providers may be associated with data provider environment 808. Data consumers may be associated with data consumer environment 802. These environments may include one or more nodes. Nodes (multiple) may be connected via peer-to-peer communication channels to allow data transfer between nodes, as in... Figure 1 and Figure 2 Decentralized systems can include more than [the context described]. Figure 8 The environment shown is more or less.

[0263] Participants in a decentralized network can be associated with decentralized participant identifiers. Each participant in a decentralized network can be associated with one or more decentralized participant identifiers. Decentralized participant identifiers can include any identifier that uniquely associates with a participant in the decentralized network and / or with a production site of a participant in the decentralized network. Decentralized participant identifiers can include letters and / or numbers. Decentralized participant identifiers can include one or more Universally Unique Identifiers (UUIDs) and / or one or more Distributed Identifiers (DIDs). Decentralized participant identifiers can be associated with or include verifiable claims or credentials. Verifiable claims can be issued by a centralized or decentralized identity issuing authority that makes one or more claims to a subject, such as an entity that is a trusted participant in the decentralized network. For example, an issuing authority can make claims about consumers (e.g., entities operating multiple data-consuming network nodes) or providers (e.g., entities operating multiple data-providing network nodes) associated with a decentralized participant identifier. Verifiable claims can include these claims and proof instructions demonstrating that the claims have not been tampered with and were indeed issued by the claim issuing authority. Verifiable claims may also include duration information metadata, which defines the valid period of use of the verifiable claim or the specific number of times the verifiable claim is authorized for use. Verifiable claims may also include the DID of the claim issuing authority and / or subject (such as an entity). Verifiable claims may be issued by the claim issuing authority. The claim issuing authority may provide verifiable claims to claim holders (such as entities) to present them to any dependent parties that rely on the authenticity of these claims, such as decentralized data providers. The signature of the verifiable claim can be verified using the public key associated with the claim issuing authority to determine that the corresponding entity is a trusted entity within the decentralized network. Verifiable credentials may be presented by decentralized data consuming network nodes and may be used by decentralized data providing network nodes to verify that the decentralized participant associated with the decentralized data consuming network node is a trusted entity within the decentralized network before providing access to data (such as output product data), thereby ensuring that output product data can be exchanged securely and in a controlled manner within the decentralized network.

[0264] The data consumer environment 802 may include consumer node 122 (e.g., distributed data consumption network node 122) and consumer backend 804. The consumer backend 804 may include or correspond to... Figure 13A and Figure 13BThe system is illustrated in the diagram. Consumer node 122 can be configured to communicate with consumer backend 804. Consumer node 122 can be configured to receive data from consumer backend 804. Consumer node 122 can be configured to receive data from provider node 118. Consumer node 122 can be configured to request data from provider node 118. Consumer node 122 can be configured to receive data from consumer backend 804 and to receive and / or request data from provider node 118. Consumer node 122 can be configured to collect output product data (also referred to hereinafter as input material data) stored in asset DB 604 associated with provider node 118, the data owner. Consumer backend 804 can be configured to send requests for data to consumer node 122, for example, as shown in... Figures 13A to 16 The context described above. Consumer backend 804 can be configured to process output product data received from consumer node 122, for example, as in... Figures 13A to 16 Described in the context of.

[0265] Data consumer environment 802 can be integrated with product ecosystem (e.g.) Figure 1 and Figure 2 The data consumer environment 802 can be associated with participants in the product ecosystem shown. For example, the data consumer environment 802 can be associated with output product producers (such as chemical product producer 102 or chemical product user 106) who receive (multiple) input materials and use (multiple) input materials to produce (multiple) output products.

[0266] Data consumer environment 802 can be used with execution Figures 14 to 17 The entities associated with the methods demonstrated herein are as follows. The entity performing this method can be a participant in the product ecosystem. Alternatively, the entity performing this method may not be a participant in the product ecosystem, but may act as a service provider offering verified input material data for generating product permits. The service provider can collect input material data from various provider(s) environments associated with input material data used to produce a given product (such as a final product or its components). The service provider can process the collected input material data, such as in… Figures 13A to 17 As described in the context. Service providers can provide processed input material data for generating product passes.

[0267] The data provider environment 808 may include provider node 118, data transfer service 602, and asset database 604. The data provider environment 808 may include... Figure 6A , Figure 6B and Figure 7The asset generation system 646 shown in the figure. A data provider environment 808 may be associated with a data owner (e.g., a manufacturer producing (multiple) output products). The data provider environment 808 may include an asset DB 604 storing datasets of (multiple) output products. The asset DB 604 may be a dedicated storage device associated with the data owner. The data owner may own and access this dedicated storage device. A provider node 118 may be configured to provide data, such as datasets of (multiple) output products stored in the asset DB 604. The provider node 118 may be configured to perform (multiple) authentication and authorization steps before providing the output product data, for example, as described later. Figure 9 As described. Provider node 118 may be coupled to data transmission service 602, which is configured to collect (multiple) output product datasets from asset DB 604 in response to a request received from provider node 118 and provide the collected (multiple) output product datasets to provider node 118.

[0268] Figure 9 A flowchart illustrates an example method for generating a dataset of (multiple) output products associated with (multiple) output products. Figure 9 The methods shown can be derived from Figures 6A to 7 The system implementation is shown. Output products can be chemical products or chemical intermediates. Output products can be discrete products. Discrete products can be components, parts, or assembly of parts. Discrete products can be batteries or battery components, such as battery cells, battery modules, or battery packs. Output products can be used as input materials by one or more downstream participants in the product ecosystem to produce one or more products. Output products can be any output product produced relative to one or more upstream production stages (or more) of the product production stage. Output products can be produced by production or can be produced by production, such as... Figure 7 As shown.

[0269] refer to Figure 12 It can provide data associated with the output products (see box 902). The data can be connected to the execution... Figure 9 The computing system provides the method (e.g., asset generation system 646). Data can be provided by the user to the execution system via a communication interface. Figure 9 The system uses a method such as asset generation system 646. Data can be provided to the data collection unit 622 of asset generation system 646. The provided data can be generated in response to a received trigger signal, for example, as in... Figure 7The data associated with the output product may include (multiple) digital output product identifiers. These (multiple) digital output product identifiers may include the output product name, output product number, LOT number, batch number, or a combination thereof.

[0270] Continue to refer to Figure 12 Output product data can be collected based on the provided data (see box 904). This can be done from the data source layer (e.g., in...). Figure 6A and Figure 6B The data source layer 620, as described in the context, collects output product data. Output product data can be collected from the data source layer 620 based on the multiple digital output product identifiers included in the data provided in box 902. Output product data can be collected by the data collection unit 622. Output product data may include output product identifier data, characteristic 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, recyclable content data associated with the output product, bio-based content data associated with the output product, biodegradability data associated with the output product, production data associated with the output product, analytical certificate data associated with the output product, certificate data associated with the output product, lifecycle data associated with the output product, storage instructions data associated with the output product, assembly instructions associated with the output product, and / or operating conditions or combinations thereof associated with the output product, such as… Figure 6A As described in the context.

[0271] An output product dataset can be generated by transforming the collected output product data using a rule-based engine, which includes one or more rules associated with the products produced from the output products (see Box 906). The one or more rules may be associated with, derived from, or generated based on a data model associated with a product or product type. Products can be produced from the output products by using the output products as input materials in at least one production step in the product's production process. The product's production process may include one or more production steps. These production steps may be performed by one or more entities within the product ecosystem. The output products may be used as input materials in at least one of these production steps.

[0272] refer to Figure 6B , Figure 10 and Figure 12The output product data collected by the rule-based engine transformation may include one or more rules that identify the applicable output product data. The collected output product data can be transformed by the data transformation unit 624, which can identify multiple applicable rules based on identifiers associated with each applicable rule that matches or relates to an output product identifier included in the collected output product data. The identifier associated with each applicable rule may include an output product identifier that matches an output product identifier included in the collected output product data. The identifier associated with each applicable rule may include an output product type identifier related to an output product identifier included in the collected output product data. The output product type identifier related to the output product identifier included in the collected output product data can be determined based on mapping data, such as in... Figure 6B Described in the context of.

[0273] Continue to refer to Figure 6B , Figure 10 and Figure 12 Executable logic can be generated from one or more applicable rules. The executable logic can be generated by the data transformation unit 624. The executable logic may include machine code, interpretable code, bytecode, and / or code running on a virtual machine. Logic included in the applicable rules(s) may be encoded in the executable logic. Logic included in the applicable rules(s) may be mirrored in the executable logic. Upon completion of the generation of the executable logic, the data transformation unit 624 may send a response to the data collection unit 622 instructing the completion of the generation of the executable logic.

[0274] Continue to refer to Figure 6B , Figure 10 and Figure 12 The output product dataset can be generated by transforming the collected output product data through the execution of executable logic generated under the constraints of rule execution criteria by a rule-based engine. The data collection unit 622 can send a request to the data transformation unit 624 to transform the output product data based on executable logic generated for (multiple) applicable rules. Rule execution criteria may include rule execution order, exemptions, and conditions. For example, a rule specified in the conditions is executed first because it triggers an execution or exemption action when executing its associated rule. The generated output product dataset can be provided from the data transformation unit 624 to the data provider unit 644.

[0275] It can be verified whether the collected output product data can be transformed according to one or more applicable rules (e.g., one or more rules collected from rule DB 612 based on the collected output product data) (see box 908). Verification can be performed as follows: Figure 6BThe method can proceed to box 912 if the collected output data can be transformed according to applicable rules(s), for example, if applying such rules(s) does not result in any errors. Otherwise, message data can be generated and provided, for example, as described in... Figure 6B Described in the context of.

[0276] The generated output product dataset may include at least a portion of the collected output product data. A portion of the output product data may be defined by one or more applied rules. A portion of the output product data may be in tabular form. The generated output product dataset may include (multiple) output product characteristic data points, (multiple) output product identifier data points, (multiple) output product name data points, (multiple) output product producer data points, (multiple) output product declaration data points, (multiple) output product safety data points, (multiple) output product emission data points, (multiple) output product recyclable content data points, (multiple) output product bio-based content data points, (multiple) output product biodegradability data points, (multiple) output product production data points, (multiple) output product analysis certificate data points, (multiple) output product certificate data points, (multiple) output product lifecycle data points, (multiple) output product storage instructions data points, (multiple) output product assembly instructions data points, and / or (multiple) output product operating condition data points.

[0277] The generated output datasets can be made accessible via a distributed network, under the control of the data owners of the output datasets. (Reference) Figure 12 This can include storing the generated output dataset in a data storage device (such as Assets DB 604), for example, as in Figure 6A Described in the context of [the above]. See also [the relevant documentation / reference]. Figure 12 This can further include generating group access data and contract templates, such as in Figure 6A Described in the context of [the relevant context]. Group access data and contract data can be used to control access to associated output product datasets, for example, as in [the context of...]. Figure 14 Described in the context of.

[0278] Using rules associated with products produced from such multiple output products allows for ensuring that multiple output product data points required according to a data model (e.g., an aspect model) associated with the product or product type are included in the output product dataset, thus avoiding the loss of multiple data points during the generation of product passes associated with the product using said data model. This transformation allows for the aggregation of collected output product data into a given data structure (e.g., a tabular data structure) without using complex data models, thereby facilitating the generation and sharing of multiple output product datasets within the product ecosystem. This sharing enables more efficient production and / or recycling processes based on shared output product data (e.g., based on output product composition data included in the shared output product dataset). The tabular data structure can be easily consumed by a consumer backend via a decentralized network, which is configured to confirm the consumed data and persistently store the confirmed consumed data to a data storage device for the generation of product passes. The consumer-side verification ensures that the product pass contains all the data required for the data model used to generate such a pass, thereby reducing the complexity associated with generating output product datasets on the provider side by avoiding the use of complex data models during the generation of (multiple) output product datasets. This enables reliable sharing of output product data for (multiple) output products regardless of the existence of a data model for such output products, since (multiple) rules required to transform the collected output product data can be easily derived from or generated based on the data model associated with the product or product type.

[0279] Figure 11 A flowchart is shown for another example method for generating a dataset of (multiple) output products associated with (multiple) output products. Figure 11 The methods shown can be derived from Figures 6A to 7 The system implementation is shown. Output products can be chemical products or chemical intermediates. Output products can be discrete products. Discrete products can be components, parts, or assembly of parts. Discrete products can be batteries or battery components, such as battery cells, battery modules, or battery packs. Output products can be any output product produced relative to one or more upstream production stages relative to the product production stage. Output products can be used as input materials by one or more downstream participants in the product ecosystem to produce one or more products. Output products can be produced by production or can be produced by production, such as... Figure 7 As shown.

[0280] Incident data, including unacknowledged output product data and data associated with the rule(s) or rule template(s) that caused such unacknowledged output product data, can be received via a distributed network (see box 1102). The distributed network can be... Figure 1 and Figure 2 The distributed networks described in the context of [134, 208] are described. Incident data can be generated from the consumer environment, for example, as in […]. Figure 17 The incident data may include (multiple) unconfirmed output product data points, output product identifiers, and indications of unconfirmation. Indications may be category symbols such as "confirmation failed" or "unconfirmed." Data associated with (multiple) rules or rule templates may include unstructured data, such as... Figure 6B The data associated with the rules or rule templates may include executable logic generated from the rules or rule templates.

[0281] refer to Figure 8 Incident data can be received by a data provider environment 808 associated with unconfirmed output product data. The data provider environment 808 may include distributed consumer nodes configured to consume data provided via a distributed network. Figure 8 (Not shown in the image). Data can be provided by a data provider node associated with the data consumer environment 802 ( Figure 8 (Not shown in the image). Incident data can be provided to consumer nodes in the data provider environment 808, such as in... Figure 17 Described in the context of.

[0282] refer to Figure 6A Incident data received by the consumer node of the data provider environment 808 can be provided to the asset generator service 606 by the consumer node. Incident data can also be provided to the asset generator service 606 via the data transmission service 602.

[0283] Continue to refer to Figure 6A Based on the received incident data, output product data associated with the output products can be collected. Output product data can be collected based on the output product identifier included in the incident data. Output product data can be collected from the data source layer by the asset generator service 606.

[0284] Continue to refer to Figure 6A And refer to Figure 6BIt can update one or more rules associated with the output product based on the received incident data. This can include generating one or more rules or rule templates based on the incident data. The generated rule(s) or rule templates can be associated with an output product identifier or a corresponding output product type identifier. The generated rule(s) or rule templates can be stored in a database containing the rule(s) and rule(s), such as rule DB 612 associated with the rule-based engine 628.

[0285] Continue to refer to Figure 6A and Figure 6B An updated output product dataset can be generated by transforming the collected output product data using a rule-based engine that includes multiple updated rules. The multiple updated rules can be applied to the collected output product data, for example, they can be associated with matching output product identifiers or corresponding output product type identifiers. Then, the method can be as follows: Figure 9 Proceed as described in the context of boxes 908 to 912.

[0286] Using incident data to update rules applicable to output product data associated with the incident data allows for the generation of updated output product datasets that may no longer fail when validated using the rules associated with the incident data. This allows for the provision of updated output product data in response to validation errors occurring in a consumer context validating such consumed output product data, passing validation rules that failed in previous validation processes. Therefore, using such incident data to update rules allows for ensuring that future output product datasets may not produce the same validation errors. This enables more efficient validation and ensures that validated input material data is available for generating product passes before the product associated with the product pass is provided to the consumer. This allows consumers (such as end-product users or recyclers) to collect pass data included in the product pass associated with the product and use the collected pass data to optimize and / or control the production of additional products using the product, and / or optimize and / or control the recycling process of the final product produced from the product.

[0287] Figure 13AA block diagram of an example system for verifying input material data associated with (multiple) input materials used to produce an output is shown. (Multiple) input materials can be used as (multiple) production inputs in one or more process steps associated with the production of the output. (Multiple) process steps can be performed by one or more entities. The output can be a discrete output, such as a part, component, component assembly, final product, or recycled material. The output can be a battery. The output can be a chemical product or a chemical intermediate. (Multiple) input materials can include chemical input materials and / or (multiple) discrete input materials. (Multiple) discrete input materials can include (multiple) parts, (multiple) components, and / or component assemblies. (Multiple) chemical input materials can include raw materials, such as (multiple) virgin materials and / or (multiple) recycled materials. Asset verification system 1342 can be configured to perform... Figure 14 , Figure 15 and Figure 17 The method is described in the context of [the system]. This system can be associated with product production.

[0288] The asset verification system 1342 may include a data transmission service 1302, a streaming storage system 1312, and a data transformation unit 1304. Various databases (such as a rule-based database 1306, a general-purpose storage device 806, and a storage application A 810) may be connected to the data transformation unit 1304.

[0289] The asset verification system 1342 can connect to distributed data consumption nodes, such as node 122. These distributed data consumption nodes can be part of a distributed network, for example, in... Figure 1 and Figure 2 The decentralized networks 134 and 208 are described in the context of [the previous sentence]. The decentralized data consumer node 122 can be associated with a decentralized participant. A decentralized participant can be a participant in a product ecosystem associated with the product. A decentralized participant can be a service provider that provides verified input material data for generating product tokens; for example, it may not be a participant in the product ecosystem. [Reference] Figure 8The distributed data consumer node 122 can be configured to request access to the output product dataset(s) associated with the output product dataset(s). The output product dataset(s) may correspond to input material data to be validated by the system. The request may include an output product identifier associated with the output product dataset(s) and a distributed participant identifier associated with the distributed participant operating the consumer node 122. The request may be generated in response to data received from the system (e.g., data received from data transmission service 1302). The data received from the system may include the output product identifier(s) and associated access data pointing to the distributed provider node(s), such as provider node 118. The access data may include endpoints associated with the distributed provider node(s), such as URI(s). A request may be generated for each output product identifier and associated access data. Authentication may be performed on the requests received by the corresponding provider node(s). This authentication may be based on data related to an authentication mechanism. The authentication mechanism can be based on (multiple) certificates and / or (multiple) tokens associated with the corresponding distributed participant nodes (e.g., consumer node 122 and provider node 118), such as device certificates (X.509v3), TLS connection certificates (X.509v3), and 'dynamic attribute tokens' (OAuth access tokens). If authentication fails, the corresponding (multiple) data providers may not provide (multiple) output artifact datasets.

[0290] Multiple provider nodes can initiate contract negotiation with consumer node 122. Contract negotiation can be initiated upon successful authentication. Multiple provider nodes can provide multiple electronic contracts to consumer node 122. Electronic contracts may include one or more authorization rules associated with output product identifiers. Electronic contracts may further include multiple endpoints associated with multiple output product datasets. Multiple endpoints may point to dedicated storage devices storing the corresponding multiple output product datasets, such as asset DB 604. Electronic contracts may be generated by multiple provider nodes based on group access data and contract templates associated with the corresponding multiple output product identifiers. The system can automatically accept the provided multiple electronic contracts. The system can be configured to parse the provided multiple electronic contracts to determine the multiple authorization rules associated with the multiple output product datasets to be collected. Consumer node 122 can provide data indicating signature, such as tokens, to the corresponding multiple provider nodes. If an electronic contract is not signed, consumer node 122 can also forward data indicating rejection of the contract to the corresponding multiple provider nodes. Upon contract rejection, the corresponding provider node(s) can terminate the connection and may not provide any output product dataset(s). The signature of this electronic contract, generated from the group access data and contract template associated with the corresponding output product(s) identifier, ensures that the consumer node(s) and other systems processing the provided output product data (such as asset verification system(s)) comply with at least one authorization rule included in the electronic contract associated with the output product dataset(s). This ensures that the output product dataset(s) can be exchanged securely and in a controlled manner, thereby preventing unauthorized decentralized network participants from accessing the output product dataset(s), while allowing the output product dataset(s) to be provided to decentralized network participants who need to use such output product dataset(s), for example, to control and / or monitor product production, and / or monitor and / or control recycling operations, and / or generate product passes associated with the product.

[0291] Continue to refer to Figure 8 When signing an electronic contract, (multiple) data providing nodes can provide (multiple) output product datasets associated with (multiple) output product data identifiers included in the request received from consumer node 122. These datasets can be retrieved from dedicated storage devices (e.g., in...). Figure 6A and Figure 9 The asset DB 604 described in the context collects (multiple) output product datasets.

[0292] return Figure 13AConsumer node 122 can provide the received output product dataset(s) (e.g., input material data) to data transmission service 1302. Data transmission service 1302 can be connected to streaming storage system 1312. Streaming storage system 1312 can be connected to data transformation unit 1304. Data transformation unit 1304 can be located upstream of data transmission service 1302. Input material data collected via a distributed network can flow through data transmission service 1302 and streaming storage system 1312 to reach data transformation unit 1304.

[0293] Data transmission service 1302 can be configured to receive input material data from consumer node 122. The input material data can represent a data stream. This stream can be an ordered sequence of records received relatively continuously from consumer node 122 (i.e., not in cumulative batches or blocks). Records can, for example, include input material data associated with a given input material via an input material identifier. Records can be represented tabularly. Records can be represented as objects, for example, using JSON or XML documents. Records can be defined as data that can be delivered continuously in small chunks or incrementally. Records can be chronologically ordered or not. Data transmission service 1302 can be configured to generate data packets(s) including the input material data(s) received from consumer node 122. Data packets can be generated from the received input material dataset. Data packets can include additional data such as timestamps, datestamps, input material identifiers associated with the input material data, distributed participant identifiers associated with provider nodes, location data pointing to a dedicated storage device storing the output product dataset, or combinations thereof. Data packets can represent messages or events. The generated data packets can be provided to streaming storage system 1312.

[0294] Streaming storage system 1312 can be configured to store data packets received (e.g., pushed) from data transmission service 1302. Streaming storage system 1312 can be configured to provide the stored data to data transformation unit 1304. Streaming storage system 1312 can be configured to provide the stored data to data consumption unit 1308 of data transformation unit 1304. Streaming storage system 1312 may include one or more persistent or non-persistent logs 1314, 1316. In this embodiment, streaming storage system 1312 includes two persistent or non-persistent logs 1314, 1316 (i.e., log 1 1314 and log 2 1316). Records stored in the logs can be sorted, for example, by using an ID. This allows identification of records within a specific log. Records may include data packets generated by data transmission service 1302.

[0295] Streaming storage system 1312 can provide streaming or streaming services between one or more streaming sources (e.g., data transmission service 1302) and one or more streaming receivers (e.g., log 1 1314 and log 2 1316). Streaming storage system 1312 can act as a persistent or non-persistent streaming receiver for input material data received from consumer node 122. For example, open-source software systems such as Apache Kafka (“Kafka”) or Azure Event Hubs can act as persistent streaming receivers.

[0296] The streaming storage system 1312 can be configured to pull input material data from the data transmission service 1302. For example, the streaming storage system 1312 can be configured to request input material data from the data transmission service 1302 at fixed time intervals.

[0297] Streaming storage system 1312 can be configured to determine whether received or pulled input material data has been included in one or more persistent or non-persistent logs. If the input material data is already included in one or more persistent or non-persistent logs, streaming storage system 1312 may not store the received or pulled input material data in those logs. If the input material data is not included in one or more persistent or non-persistent logs or is updated, streaming storage system 1312 can be configured to store the received or pulled input material data in one or more persistent or non-persistent logs, or update the input material data existing in the persistent or non-persistent logs(s) with the received or pulled updated input material data. This avoids storing the same input material data multiple times in the persistent or non-persistent logs(s), thereby avoiding redundant confirmation operations on the input material data stored in streaming storage system 1312.

[0298] Data transformation unit 1304 can be connected to streaming storage system 1312. Data consumption unit 1308 of data transformation unit 1304 can be connected to streaming storage system 1312. Data consumption unit 1308 can be connected to one or more persistent or non-persistent logs of streaming storage system 1312 (e.g., in this embodiment, connected to log 1 1314 and log 2 1316) to ingest and process input material data stored in the log(s). Streaming storage system 1312 can have a publisher-subscriber relationship with data consumption unit 1308. For example, data in one or more logs can be periodically read (e.g., pulled) by data consumption unit 1308. To avoid consuming data packets stored in the logs multiple times, such data packets can be marked as consumed by streaming storage system 1312. To avoid consuming data packets stored in the logs multiple times, an integer can be used to indicate the offset of the next data packet to be consumed. For each persistent or non-persistent log, such an integer can be just a number. Such an integer can be periodically set as a checkpoint. Using this integer allows the data consumption unit 1308 to reconsume data packets by rolling back to the old offset.

[0299] Data consumption unit 1308 can be connected to data verification unit 1310 of data transformation unit 1304. Data consumption unit 1308 can be configured to provide data packets collected from streaming storage system 1312 to data verification unit 1310 for verifying input material data included in the data packets. Data consumption unit 1308 can be configured to extract input material data from the data packets and provide the extracted input material identifier and input material data to data verification unit 1310. Data verification unit 1310 can be configured to verify input material data (e.g., data packets received from streaming storage system 1312) based on one or more rules retrieved from rule DB 1306, such as... Figure 13AThe context described herein. Validation may include applying one or more rules retrieved from rule DB 1306 to the input material data. The input material data can be validated if at least a portion of the applied rules are satisfied. Applying rules(s) to the input material data may include comparing a combination of input material identifiers and location data with a database storing such combinations of input material identifiers(s) and associated location data. Applying rules(s) to the input material data may include comparing (multiple) data points present in one or more rules with (multiple) individual data points present in the input material data to be validated. Applying rules(s) to the input material data may include comparing a combination of (multiple) data points defined in (multiple) rules with a combination of data points present in the input material data to be validated. Applying rules(s) to the input material data may include comparing data defined in one or more rules with the entire input material data to be validated. One or more rules may be associated with a product produced from (multiple) input materials. One or more rules may be associated with a data model of the product or product type. The data model may include a semantic description of a product pass associated with the product. The semantic description may include semantic descriptions of the input material data and the product data. Semantic descriptions may include at least a portion of the structure and / or characteristics of the product pass. Characteristics of the product pass set may include data types. Characteristics of the product pass set may include possible or permitted values ​​and / or value ranges. Characteristics of the product pass may be physical units of the parameters described by the values ​​contained in the product pass. Multiple data types and associated values ​​and / or value ranges of the input material data may be included in one or more rules. This allows verification that the collected input material data meets the multiple data types and associated values ​​and / or value ranges required by the data model for the input material data. Verifying the input material data against one or more rules generated from the data model ensures that the input materials required by the data model are indeed included in the collected input material data, thereby ensuring that the multiple product passes generated from such verified input material data include all required input material data. Verifying the collected input material data at the data point level allows for reliable verification regardless of the data structure of the input material data. This, in turn, allows input material data to be generated without the need for complex data models. Instead, the input material data can be generated in tabular form by a data provider and can be used by a data verification unit to verify the data points included in the input material data.One or more rules can define one or more input material property data points, input material identifier data points, input material name data points, input material producer data points, input material declaration data points, input material safety data points, input material emission data points, input material recycled content data points, input material bio-based content data points, input material biodegradability data points, input material production data points, input material analysis certificate data points, input material certificate data points, input material life cycle data points, input material storage instructions data points, input material assembly instructions data points, and / or input material operating conditions data points. A rule can define (multiple) data points for each data category. A rule can define (multiple) data points for at least two different data categories. Data categories can represent property data, declaration data, safety data, emission data, recycled content data, bio-based content data, biodegradability data, production data, analysis certificate data, certificate data, storage instructions data, assembly instructions data, or operating conditions data.

[0300] By verifying the input material data against one or more rules generated from the data model, it can be ensured that the input material data required by the data model is indeed included in the collected input material data. This allows it to ensure that the (multiple) product passes generated from this verified input material data include all required input material data. Verifying the collected input material data at the data point level allows for reliable verification regardless of the data structure of the input material data. This, in turn, allows for the generation of input material data without the need for a complex data model. Figure 6A , Figure 6B (This is represented as output product data). Conversely, (multiple) output product datasets can be generated in tabular form by the data provider and can be used by the data verification unit 1310 to verify (multiple) data points included in (multiple) output product datasets, such as those received as input material data from the data consumer side.

[0301] The verified input material data generated by the data verification unit 1310 may include one or more verified input material characteristic data points, verified input material identifier data points, verified input material name data points, verified input material producer data points, verified input material declaration data points, verified input material safety data points, verified input material emission data points, verified input material recyclable content data points, verified input material bio-based content data points, verified input material biodegradability data points, verified input material production data points, verified input material analysis certificate data points, verified input material certificate data points, verified input material life cycle data points, verified input material storage instructions data points, verified input material assembly instructions data points, and / or verified input material operating condition data points.

[0302] The data verification unit 1310 can be further configured to determine a storage location where the verified input material is to be persistently stored. The storage location can be determined based on mapping data, which includes mappings between input material identifiers(s) and associated storage location data. The storage location data can include endpoints(s) associated with said storage location(s). The storage location(s) can be identified by storage location identifiers(s) included in the storage location data. Such identifiers(s) can be used to collect endpoints(s) associated with such storage location(s). The mapping data can include a first mapping between input material identifiers and input material type identifiers, and a second mapping between input material type identifiers and associated storage location data. The mapping data can be stored in a database (not shown) connected to the data verification unit 1310. Determining the storage location of the verified input material data allows the verified input material data to be persistently stored in a storage location associated with a given application or system(s). For example, verified input material data associated with a given product (such as a battery or a given chemical product) can be persistently stored in a storage location associated with a given application that processes such verified input material data. The process may include, for example, generating (multiple) product passes using such verified input material data. Verified input material data that may not be mapped to a given application can be persistently stored in a general-purpose storage device (such as general-purpose storage device 806).

[0303] The data verification unit 1310 can be further configured to provide the verified input material data to a determined storage location (such as a general storage device 806 or a storage application A 810) for storage.

[0304] The asset verification system 1342 may further include an incident data generator 1344. The incident data generator 1344 may be configured to generate incident data based on input material data that failed verification and is stored in a database (e.g., general-purpose storage device 806). The input material data that failed verification and is not valid may be associated with a classifier indicating non-compliance with one or more applied rules. The classifier may include “failed verification,” “invalid,” “verification failed,” or “failed.” The classifier may be associated with each data point that cannot be verified when one or more rules are applied. Each data point that cannot be verified may be associated with a corresponding input material identifier. Each data point that cannot be verified may be associated with rule data indicating the rule that caused the corresponding data point to fail verification. The rule data may include rules. The rule data may include executable logic generated from the rules, such as... Figure 13B The incident data generator 1344 can be configured to collect data points(s) associated with a classifier for each input material identifier. The incident data generator 1344 can query a database for input material data associated with a classifier. The incident data generator 1344 can assemble the collected input material data into incident data based on the input material identifiers associated with the collected input material data. The incident data generator 1344 can provide the generated incident data to the data transmission service 1302. The data transmission service 1302 can be configured to determine if a provider node has provided unacknowledged input material data. The data transmission service 1302 can be configured to initiate the transmission of incident data via consumer node 122 to the identified node associated with the asset generator system 606 that generated the unacknowledged input material data (e.g., an output product dataset). Incident data can be provided to such a node using an endpoint of a node configured to receive data from other nodes in a distributed network (e.g., provider node 118). Such a node can provide its endpoint to the data transmission service 1302 or connect to the backend of the data transmission service 1302. Endpoints can be stored in a ledger that associates (multiple) consumer nodes with corresponding endpoints used to push incident data to such consumer nodes. The (multiple) consumer nodes can be identified by (multiple) decentralized participant identifiers. Generating and providing incident data associated with (multiple) unconfirmed data points allows data providers providing such unconfirmed data points to generate (multiple) updated output product datasets (e.g., as in...). Figure 11(As described in the context) and provides (multiple) updated output product datasets. Therefore, using incident data ensures that (multiple) unconfirmed input material data points can be corrected by the appropriate data provider, resulting in (multiple) updated output product datasets generated by the asset generator service 606 associated with node 118 passing (multiple) confirmations. This can lead to the efficient and reliable generation of confirmed input material data required for generating product passes, and thus also the reliable generation of product passes. Product passes can allow for improvements and / or control over the production of additional products using the product and / or the recycling process of the final product produced by the product, based on the pass data contained in the product pass.

[0305] Figure 13B The diagram illustrates an example of using a rule-based engine to identify input material data associated with (multiple) input materials used to produce the product. Input material data can be collected via a distributed network, such as in... Figure 6A The collected input material data may correspond to data stored in the data provider's environment (e.g., in...). Figure 8 The data provider environment (808) described in the context of the data provider environment contains (multiple) output product datasets in a dedicated storage device.

[0306] Data verification unit 1320 may include rule-based engine 1322. Rule-based engine 1322 can operate on individual data points, multiple data points, and / or collected input material data. Rule-based engine 1322 can operate on data collected for each input material identifier individually. This allows verification of input material data for each type of input material, thus allowing for finer-grained verification of the input material data. Rule-based engine 1328 can receive requests to verify collected input material data. These requests may include at least a portion of the collected input material data. Data packets (e.g., messages or events) from one or more logs of streaming storage system 1312 (see Operation 1338) can be consumed by data consumption unit 1308, as in... Figure 13AThe context is described below. Data consumption unit 1308 can extract consumed data packets (see operation 1346). The extracted input material identifiers can be provided to rule-based engine 1322. Rule-based engine 1322 can access one or more rules. Rule-based engine 1322 can include one or more rules. One or more rules can exist within a rule template. One or more rules and / or rule templates can be stored in a data storage device, such as rule DB 1318. One or more rules or rule templates can be provided to rule DB 1318 by a user. One or more rules can correspond to unstructured data associated with confirmation operations. Rule templates can include unstructured data associated with instructions related to confirmation operations. One or more rules or rule templates can be included in a file provided by a user. One or more rules or rule templates can be associated with input material type identifiers and / or input material identifiers. Rule-based engine 1322 can generate a request to obtain one or more rules from rule DB 1318. The request can contain the corresponding input material identifiers.

[0307] One or more rules (e.g., one or more applicable rules) associated with the input material data to be validated can be provided to the rule-based engine 1322 in response to a request. One or more rules can define (multiple) data points and / or (multiple) combinations of data points to be present within the consumed input material data (e.g., within the consumed input material dataset). One or more rules can be associated with (multiple) products produced from the input materials associated with the input material data to be validated. A product can be a component. A product can be a component assembly. A product can be a chemical product. One or more rules can be associated with, derived from, or generated based on a data model of the product. Therefore, one or more rules can ensure that (multiple) data points associated with (multiple) input materials and required according to the data model can be included in the consumed input material data. One or more rules can be defined by (multiple) mandatory input material data points present within the data model. One or more rules can be generated based on (multiple) mandatory input material data points present within or defined by the data model. This ensures that the input material data required by the data model is included in the consumed input material data. One or more rules can define one or more input material property data points, input material identifier data points, input material name data points, input material producer data points, input material declaration data points, input material safety data points, input material emission data points, input material recycled content data points, input material bio-based content data points, input material biodegradability data points, input material production data points, input material analysis certificate data points, input material certificate data points, input material life cycle data points, input material storage instructions data points, input material assembly instructions data points, and / or input material operating conditions data points. A rule can define (multiple) data points for each data category. A rule can define (multiple) data points for at least two different data categories. Data categories can represent property data, declaration data, safety data, emission data, recycled content data, bio-based content data, biodegradability data, production data, analysis certificate data, certificate data, storage instructions data, assembly instructions data, or operating conditions data. One or more rules can be associated with (multiple) input material identifiers and / or (multiple) input material type identifiers. A mapping table can be used to map (multiple) input material identifiers to corresponding (multiple) input material type identifiers. The (multiple) input material type identifiers can be associated with (multiple) input material types. The mapping table can be stored in a separate database (not shown). The rule-based engine 1322 can be configured to collect (multiple) input material type identifiers based on the determined (multiple) input material identifiers, and to request (multiple) rules based on the collected (multiple) input material type identifiers.This allows for the collection of rules associated with multiple input material type identifiers based on multiple input material identifiers, thereby avoiding the generation of multiple rules for each input material identifier and reducing the number of rules that need to be generated, stored, and maintained in rule DB 1318.

[0308] The rule-based engine 1322 can be configured to initialize a rule engine (see operation 1326). Initialization of the rule engine may include generating rule data executable by a processor included in the rule-based engine 1322. The rule data may include or correspond to executable logic. This may allow the transformation of rules(s) or rule(s) templates existing in unstructured data form into code executable by the processor. Execution of the code may enable the application of the executable rule data to extracted input material data (see operation 1328) to validate the consumed input material data according to the obtained rules(s). Execution of the logic may enable matching the consumed input material data with data(s) and / or combinations of data(s) included in the executable logic, evaluating the data(s) or combinations of data(s) with the matched input material data, and generating validation result data based on the evaluation results. The validation result data may include a classifier and associated data(s) of validated or unvalidated input material data(s). The classifier may be a binary classifier distinguishing between validated and unvalidated input material data. If one or more rules applied by the rule-based engine 1322 are satisfied, then the consumed input material data points(s) can be considered validated. Applying the rules(s) to the consumed input material data may include comparing the individual data points(s) present in the rules(s) with the individual data points(s) present in the input material data to be validated, to determine whether the input material data to be validated includes the individual data points(s) required by such rules(s). Applying the rules(s) to the consumed input material data may include comparing the combination of data points(s) defined in the rules(s) with the combination of data points(s) present in the input material data to be validated, to determine whether the input material data contains the combination of data points(s) required by such rules(s). Applying the rules(s) to the consumed input material data may include comparing the data(s) defined in the rules(s) with the entire input material dataset(s) to be validated, to determine whether the input material dataset(s) contains all the data(s) required by such rules(s). The operations performed by the rule-based engine 1322 may be determined by the rules(s) collected from the rule DB 1318. For example, the rules collected from rule DB 1318 can determine whether the rule-based engine 1322 operates on the individual data points and / or multiple data points and / or the entire input material data consumed.

[0309] The rule-based engine 1322 can be configured to determine whether consumed input material data satisfies one or more applied rules (see operation 1330). If the consumed input material does not include the data points(s) required according to one or more obtained rules, the consumed input material data may fail validation or only partially pass validation (e.g., validation may result in at least one error associated with applying one or more obtained rules to the consumed input material data). The rule-based engine 1322 can indicate to the data validation unit 1320 that the consumed input material data has been successfully validated (e.g., satisfies one or more obtained rules) in response to determining that the consumed input material data has successfully passed validation (e.g., satisfies one or more obtained rules). In response to receiving this indication, the data validation unit 1320 can determine the target data storage device where the validated input material data will be persistently stored (see operation 1340). The target data storage device may be as follows: Figure 13A The data verification unit 1320 determines the input material data as described in the context. If the data verification unit 1320 determines that the verified input material data is not associated with a given application, the data verification unit 1320 may provide the verified input material data to a storage device, such as general-purpose storage device 806, that is not associated with any application that processes the verified input material data. If the data verification unit 1320 determines that the verified input material data is associated with a given application, the data verification unit 1320 may provide the verified input material data to a storage device associated with an application that processes (e.g., by generating product passes) the verified input material data stored therein.

[0310] If at least a portion of the consumed input material data fails verification, the rule-based engine 1322 can indicate to the data verification unit 1320 that at least a portion of the consumed input material data has failed verification. In response to receiving this indication, the data verification unit 1320 can generate message data (operation 1332). The message data may indicate that at least a portion of the consumed input material data has failed verification. The message data may include an indication of which(s) of the consumed input material data failed verification. The message data can be provided to a display device configured to display the data received from the data verification unit 1320. The display device may include a graphical user interface 1334. The display device may display the message in response to receiving the message data from the rule-based engine 1322. This allows, for example, triggering correction or updates of the failed verification data points by generating incident data, as in... Figure 13A Described in the context of.

[0311] The rule-based engine 1322 can be configured to provide unvalidated input material data to a storage device, such as general-purpose storage device 806, that is not associated with any application that processes validated input material data. The unvalidated input material data can be provided to this storage device along with a classifier that categorizes such input material data as unvalidated. The unvalidated input material data can also be provided to this storage device along with the classifier and rule data, which indicates the applied rules(s) that caused at least a portion of the input material data to fail validation.

[0312] Figure 14 A flowchart illustrates an example method for identifying input material data associated with (multiple) input materials used to produce the product. Figure 14 The method shown can be derived from Figure 13A and Figure 13B The system shown is used for implementation. Multiple input materials can be used as production inputs in one or more process steps associated with the production of the product. Multiple process steps can be performed by one or more entities. The product can be a discrete product, such as a component, part, component assembly, final product, or recycled material. The product can be a battery. The product can be a chemical product or a chemical intermediate. Multiple input materials can include chemical input materials and / or multiple discrete input materials. Multiple discrete input materials can include multiple parts, components, and / or component assemblies. Multiple chemical input materials can include raw materials, such as multiple virgin materials and / or multiple recycled materials. The product can be produced through production.

[0313] Product data may be provided, including product identifiers and input material identifiers associated with the input materials used to produce the product (see box 1402). The identifiers associated with the input materials may be asset identifiers associated with or included in the input material data. This product data may be provided from one or more databases storing the product data. One or more databases may be associated with production. The product data may be provided to the execution entity by the entity producing the product. Figure 14The entity of the method presented. Product data may further include product characteristic data. Product characteristic data may include at least one measured chemical and / or physical property of the product, and / or at least one chemical and / or physical property determined based on data collected in connection with the production of the product. At least a portion of the product data may be stored in one or more databases. One or more databases may be determined based on mapping data. Mapping data may map product identifier(s) to applications and associated databases. Mapping data may map product identifier(s) to product type identifiers and associated applications and databases.

[0314] Input material data can be collected via a distributed network based on (multiple) input material identifiers included in the provided product data (see box 1404). The distributed network can be... Figure 1 and Figure 2 The decentralized networks 134 and 208 described in the context of this study can collect input material data from decentralized data provider nodes (such as provider node 118) associated with the corresponding input material data, such as distributed data consumer nodes (e.g., consumer node 122). Figure 8 Described in the context of [the document / context]. References Figure 15Collecting input material data may include identifying multiple distributed data provider nodes associated with input material data that matches (e.g., input material data associated with the provided input material identifiers). Identifying such provider nodes may include providing candidate distributed provider nodes associated with input material data for (multiple) input materials used to produce the product. Multiple candidate provider nodes may be provided by providing a database storing candidate provider node data associated with input material identifiers that match (e.g., output product identifiers) of output product datasets associated with (e.g., accessible via) such candidate provider nodes. Candidate provider node data may include access data associated with the candidate provider nodes. Candidate provider node data may further include candidate provider node identifiers and / or multiple distributed participant identifiers associated with the candidate provider nodes. The database may include mapping data that maps candidate provider node data to multiple input material identifiers associated with input material data provided by candidate provider nodes linked to the candidate provider node data. The database can be updated upon receiving new candidate provider data and associated input material identifiers. Using this mapping data allows for the efficient identification of multiple target provider nodes associated with the desired input material data, thereby reducing latency associated with collecting input material data. This ensures that input material data can be validated and processed, for example, by generating product tokens, before the product associated with a product token is provided to the consumer (e.g., the end-product user). Efficient generation of product tokens avoids storing multiple produced products due to a lack of associated product tokens before providing them to consumers, which, from a regulatory perspective, might require generating the associated product token before providing the product to the consumer.

[0315] Continue to refer to Figure 15Access data for a target distributed provider node associated with input material data can be determined based on the provided input material identifier(s). The target provider node can be identified by matching the provided input material identifier(s) with input material identifiers stored in mapping data. Candidate provider node data associated with the matching input material identifier(s) can be collected from this database as target provider node data. The collected target provider node data can be parsed to determine access data associated with the target distributed provider node(s), e.g., provider nodes associated with multiple dedicated storage devices storing input material data associated with the provided input material identifier(s).

[0316] Continue to refer to Figure 15 Access to input material data associated with the provided input material identifier(s) can be requested from the target data provider(s) associated with the determined access data. This can be done as follows: Figure 13A The request requests access to input material data as described in the context. Multiple target provider nodes can provide the input material data in response to such a request, for example, as in... Figure 8 Described in the context of.

[0317] return Figure 14 And refer to Figure 13A and Figure 16 The collected input material data can be provided to a streaming storage system, for example in... Figure 13A The streaming storage system 1312 is described in the context of data consumers (e.g., in...). Figure 13A The data consumption unit 1308 described in the context can consume input material data collected from the streaming storage system. The consumer can extract input material identifiers and input material data from the consumed data packets. Therefore, the streaming storage system can be used as an input material data receiver and allows for compensation for asynchronous collection of input material data from a distributed network. The collected input material datasets can be provided to the streaming storage system as messages or events. The streaming storage system can publish such received messages or events, for example, by persistently storing the received messages or events in a persistent or non-persistent log, such as in... Figure 13A The message or event may be generated by the data transmission service 1302, for example, as described in the context of... Figure 13A As described in the context. Data consumers can listen to published messages and / or events (see [reference]). Figure 13AIt can also consume new messages and / or events. This ensures that acknowledgment can be performed on each input material dataset and avoids multiple acknowledgments for a given input material dataset.

[0318] Continue to refer to Figure 13A and Figure 16 And further reference Figure 13B At least a portion of the collected input material data can be verified using a rule-based engine that includes one or more rules associated with the product. The input material data can be verified by the data verification unit 1310. Applicable rules(s) can be identified based on identifiers associated with each applicable rule that matches or relates to the input material identifiers included in the extracted input material data. Identifiers associated with each applicable rule can include input material identifiers that match the input material identifiers included in the extracted input material data. Identifiers associated with each applicable rule can include input material type identifiers related to the input material identifiers included in the extracted input material data. Input material type identifiers related to the input material identifiers included in the extracted input material data can be determined based on mapping data, such as in… Figure 13B Described in the context of.

[0319] Continue to refer to Figure 13B and Figure 16 Executable logic can be generated from one or more applicable rules. The executable logic can be generated by the data verification unit 1310. The executable logic may include machine code, interpretable code, bytecode, and / or code running on a virtual machine. Logic included in the applicable rules(s) may be encoded in the executable logic. Logic included in the applicable rules(s) may be mirrored in the executable logic. Upon completion of the generation of the executable logic, the data verification unit 1310 may send a response to the data consumption unit 1308 indicating the completion of the generation of the executable logic.

[0320] Continue to refer to Figure 13B and Figure 16In response to receiving an indication that the generation of executable logic has been completed, the data consumption unit 1308 can provide the extracted input material data to the data verification unit 1310. The extracted input material data can be verified by executing the generated executable logic. The executable logic can be constrained by rule execution criteria. The data consumption unit 1308 can send a request to the data verification unit 1310 to transform the extracted input material based on the executable logic generated for (multiple) applicable rules. Rule execution criteria can include rule execution order, exemptions, and conditions. Verification data, including verification results, can be generated by the rule engine. Verification data can include the input material data points that have undergone the verification process and associated classifiers. Classifiers can indicate whether the corresponding input material data point has passed or failed the verification process. Verification data can further include rule data associated with (multiple) data points that failed verification. This rule data can indicate (multiple) applied rules that caused the verification failure of such data points.

[0321] Return to Figure 14 And continue to refer to Figure 16 This allows verification of whether the extracted input material data can be confirmed according to one or more applicable rules (e.g., one or more rules collected from rule DB 1318 based on the collected output product data) (see box 1408). Confirmation can be made as follows... Figure 13B The process proceeds as described in the context. If the input material data extracted according to the applicable rules(s) passes verification—for example, applying such rules(s) does not result in any errors—then the method may proceed to box 1418. If only a portion of the extracted input material data passes verification, the method may proceed to box 1414. If the extracted input material data fails verification, the method may proceed to box 1410.

[0322] In box 1410, message data can be generated, for example, as shown in... Figure 13B Described in the context of [the above]. Confirmation data, including input material data that failed confirmation, can be provided to a storage location, for example, as in [the context of the above]. Figure 13B The context described above. Confirmation data, including input material data that failed confirmation, can be used to generate incident data, for example, as in... Figure 13A and Figure 17 Described in the context of.

[0323] In box 1414, message data can be generated, for example, as shown in... Figure 13B As described in the context. In box 1416, confirmation data, including input material data that failed confirmation, can be provided to the storage location, as previously described.

[0324] The confirmed input material data can be linked to at least one product identifier in the product identifier (see box 1418). This allows the confirmed input material data to be collected, for example, based on at least one product identifier in the product identifier when generating a product pass.

[0325] Continue to refer to Figure 13A and Figure 13B The storage locations of at least a portion of the confirmed input material data can be determined based on the input material identifier(s) associated with the confirmed input material data (see box 1420). The input material identifier(s) can be included in the confirmed input material data. This can be done as follows: Figure 13A and Figure 13B The storage locations are determined as described in the context. Providing verified input material data to a database used by a defined application that processes the verified input material data allows for sorting of the verified input material data based on the application processing or consuming it. This improves security by preventing unauthorized data access by applications that do not process verified input material data stored in such databases. Furthermore, this reduces latency in generating product passes because the amount of data stored within a particular database is reduced by selectively providing verified input material data to be processed by a given application to the database(s) associated with that application.

[0326] Continue to refer to Figure 16 At least a portion of the verified input material data linked to at least one product identifier in the product identifier can be provided to the determined storage(s) for generating a product pass(s) associated with the product, which includes at least a portion of the verified input material data (see box 1422). The verified input material data provided to such storage(s) can be persistently stored in such storage(s).

[0327] Input material data can be reliably and quickly collected via a distributed network by directly collecting input material data from the corresponding data provider nodes associated with it, for example, by locating the data provider(s) associated with the desired input material data by avoiding queries to the distributed network. By verifying the collected input material data with a rule-based engine that includes one or more rules associated with the product or product type (e.g., rules associated with the data model of the product or product type), product passes can be reliably generated from this verified input material data, because verification ensures that all input material data points required for generating the product pass are available (e.g., stored in dedicated storage). By verifying the collected input material data on the consumer side, input material data can be collected directly from the provider side without requiring the provider to provide input material data conforming to a defined data structure. Therefore, it is not necessary for the provider to generate the input material data collected by the consumer side using a complex data model that produces highly defined input material data points. Conversely, input material data can be provided to the consumer side as a tabular representation, and this input material data can be verified at the data point level to ensure that the collected input material data includes all (or more) data points mandated by the data model used to generate product passes from the verified input material data. By verifying input material data on the consumer side, the workload of generating and providing input material data on the provider side is significantly reduced while maintaining security, thereby enabling reliable, rapid, and secure sharing of the input material data required to generate product passes. This, in turn, allows for the reliable and efficient generation of product passes associated with products produced from such input materials, ensuring high data quality of chemical product passes and their availability when the product is provided to consumers, without having to store the product until the associated product pass generation is complete. The high data quality of the product passes allows consumers of the associated product to control and / or monitor the production process using the product and / or processes involving the recycling of the final product or a portion thereof produced from the product in a more reliable and / or efficient manner. In addition, this setup allows for the simultaneous collection of input material data from various data provider nodes for a wide range of input materials, while ensuring that the collected input material data is correctly verified and persistently stored in a database associated with the application that consumes the verified input material data persistently stored in this database.

[0328] Figure 17 A flowchart illustrates another example method for identifying input material data associated with (multiple) input materials used to produce the product. Figure 17 The method shown can be derived from Figure 13A and Figure 13BThe system shown is used for implementation. Multiple input materials can be used as production inputs in one or more process steps associated with the production of the product. Multiple process steps can be performed by one or more entities. The product can be a discrete product, such as a component, part, component assembly, final product, or recycled material. The product can be a battery. The product can be a chemical product or a chemical intermediate. Multiple input materials can include chemical input materials and / or multiple discrete input materials. Multiple discrete input materials can include multiple parts, components, and / or component assemblies. Multiple chemical input materials can include raw materials, such as multiple virgin materials and / or multiple recycled materials.

[0329] Incident data can be generated, including input material data that failed validation and data associated with the rule(s) or rule template(s) that caused such input material data to fail validation (see box 1702). Incident data can be generated by incident data generator 1344, for example, as in... Figure 13A Described in the context of.

[0330] The generated accident data can be provided via a distributed network to distributed data providers associated with input material data that has not passed verification. This can be based on, for example... Figure 15 The generated incident data, described in the context of [the previous sentence], includes input material identifiers. Mapping data, including candidate provider node data and associated input material identifiers, is used to determine the distributed data provider. For example, input material identifiers included in the incident data can be matched against (multiple) input material identifiers included in the mapping data to determine associated provider node data. The associated provider node data can be parsed to determine access data associated with such provider nodes. Access data can then be used to provide incident data to the provider nodes associated with the access data.

[0331] In response to receiving incident data, the backend system associated with the provider node that received the incident data (such as asset generation system 646) can generate an updated output product dataset (corresponding to the updated input material data), for example, as in Figure 11 As described in the context, updated input material data can be provided to the consumer node that provides the incident data used to generate the updated input material data. This data can be provided to the consumer node by pushing the updated input material data to the consumer node without receiving a request for such data, for example, as in... Figure 13AThis is described in the context of [the previous sentence]. This allows for the provision of updated input material data after it has been generated, thereby reducing latency in transmitting updated input material data to consumer nodes and facilitating timely confirmation of updated input material data, as well as the generation of product passes using updated and successfully confirmed input material data. This avoids the inability to generate product passes due to a lack of confirmed input material data and ensures that the product provided to consumers (such as end-product users or recyclers) is associated with a product pass, allowing consumers to collect pass data included in the product pass and use the collected pass data to control and / or optimize further production processes using the product and / or the recycling process of the final product or a portion thereof produced from the product.

[0332] The updated input material data can be confirmed, for example, as in Figure 14 Described in the context of.

[0333] This disclosure has also been described in conjunction with various preferred embodiments and examples. However, by studying the accompanying drawings, this disclosure, and the claims, those skilled in the art, as well as those who practice the claimed invention, will understand and implement other variations.

[0334] Any steps presented in this document can be performed in any order. The methods disclosed herein are not limited to a specific order of these steps. Nor is it required that different steps be performed in a particular place or on a particular computing node in a distributed system; that is, each step can be performed on different computing nodes using different devices / data processing.

[0335] As used herein, "determine" also includes "initiating or causing determination," "generate" also includes "initiating and / or causing generation," and "provide" also includes "initiating or causing determination, generation, selection, sending, and / or receiving." "Initiating or causing an action" includes any processing signal that triggers a computing node or device to perform a corresponding action.

[0336] In the claims and specification, the word "comprising" or "including" or similar wording does not exclude other elements or steps and should not be construed as limiting oneself to the listed elements or steps. The indefinite article "a" or "an" does not exclude multiple. A single element or other unit may perform the function of several entities or items recited in the claims. The fact that certain measures are recited only in mutually different dependent claims does not indicate that a combination of these measures cannot be used in advantageous implementations or that additional elements may be included.

[0337] Within the scope of this disclosure, provision may include any interface configured to provide data. This may include application programming interfaces, human-machine interfaces (such as displays), and / or software module interfaces. Provision may include transmitting or submitting data to the interface, particularly displaying data to a user or having data used by a receiving entity.

Claims

1. A method for generating an output product dataset associated with the output product, wherein, The output product is used as input material to produce one or more products, the method comprising: - Provide data associated with the output product, including at least one output product identifier; - Collect output product data from one or more databases based on the provided data associated with the output product; - The output product dataset is generated by transforming the collected output product data using a rule-based engine, which includes one or more rules associated with at least one of the output products (multiple types); - Provide the generated output dataset to be accessed by distributed data consuming nodes, either under the control of or controlled by the distributed data consuming node associated with the data owner of the generated output dataset.

2. The method as described in claim 1, wherein, The collected output product data includes output product identifier data, characteristic 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, recyclable content data associated with the output product, bio-based content data associated with the output product, biodegradability data associated with the output product, production data associated with the output product, analytical certificate data associated with the output product, certificate data associated with the output product, life cycle data associated with the output product, storage instructions data associated with the output product, assembly instructions associated with the output product, and operating conditions or combinations thereof associated with the output product.

3. The method as described in claim 1 or 2, wherein, The rule-based engine operates on individual data points existing in at least a portion of the collected output product data, multiple data points existing in at least a portion of the collected output product data, or the entire collected output product data.

4. The method as described in any of the preceding claims, wherein, The one or more rules are generated from a rule template that includes unstructured data associated with instructions related to transformation operations(s).

5. The method as described in any one of the preceding claims, wherein, The one or more rules are associated with or derived from a semantic model associated with at least one of these products, wherein, in particular, the one or more rules are defined by one or more mandatory output product data points existing within the semantic model.

6. The method as described in any of the preceding claims, wherein, The one or more rules define (multiple) aggregation rules for aggregating output product data collected from multiple data sources into a given data structure, define filters for filtering the collected output product data, define (multiple) attribute constructs for creating or adding new attributes to the collected output product data, and / or include triggering conditions and a corresponding set of one or more actions.

7. A method for verifying input material data associated with (multiple) input materials, wherein, The input materials (multiple types) are used to produce one or more products through a process comprising: - Provide product data, which includes (multiple) product identifiers and (multiple) input material identifiers associated with (multiple) input materials; - The input material data is obtained from the distributed data provider node(s) associated with it, wherein the input material data is collected by the distributed data consumer node(s) based on the provided input material identifier(s); - By using a rule-based engine to identify at least a portion of the collected input material data, the rule-based engine includes one or more rules associated with at least one of these products; - Link the confirmed input material data to at least one of these product identifiers; - The storage location(s) of the confirmed input material data are determined based on the input material identifier associated with the confirmed input material data; - Provide confirmed input material data linked to at least one of these product identifiers to the identified storage locations for generating product passes associated with the product(s) including at least a portion of the confirmed input material data.

8. The method of claim 7, wherein, The distributed data provider node(s) are determined by matching the input material identifier(s) included in the product data with the output product identifier(s) included in the mapping data, which maps the distributed data provider node data to the associated input material identifier(s).

9. The method of claims 7 and 8, wherein the obtained input material data is provided to one or more input nodes, the one or more input nodes being configured to collect the obtained input material data and provide the collected input material data as one or more input material datasets to one or more downstream nodes, wherein, The one or more downstream nodes are configured to identify at least a portion of the data included in the input material dataset(s) provided by the one or more input nodes, link the identified input material data to at least one product identifier associated with at least one of the products, determine the storage(s) of the identified input material data(s), and provide the identified input material data(s) linked to the product identifier(s) to the determined storage(s) of the determined storage(s).

10. The method according to any one of claims 7 to 9, wherein, The rule-based engine operates on individual data points existing in at least a portion of the input material data, multiple data points existing in at least a portion of the input material data, or the entire input material data.

11. The method according to any one of claims 7 to 10, wherein, The one or more rules are generated from a rule template that includes unstructured data associated with instructions related to confirmation operations(s).

12. The method according to any one of claims 7 to 11, wherein, The one or more rules define the (multiple) data points and / or (multiple) combinations of data points that must exist within the input material data.

13. The method according to any one of claims 7 to 12, wherein, The storage location is determined based on mapping data, which includes mappings between input material identifiers and associated storage location data, or mappings between input material identifiers and associated input material type identifiers and storage location data.

14. An apparatus for verifying input material data associated with (multiple) input materials, wherein, The (multiple) input materials are used to produce one or more products through production, and the apparatus includes: - A product data providing interface configured to provide product data, which includes (multiple) product identifiers and (multiple) input material identifiers associated with (multiple) input materials; - A distributed network interface configured to obtain the input material data from (multiple) distributed data provider nodes associated with the input material data, wherein the input material data is collected by distributed data consumer nodes based on (multiple) provided input material identifiers; - A data confirmer configured to confirm at least a portion of collected input material data using a rule-based engine, the rule-based engine including one or more rules associated with at least one of the products; - Linking unit, which is configured to link the confirmed input material data to at least one of the product identifiers; - A storage determiner configured to determine the storage location of the confirmed input material data based on the input material identifier(s) associated with the confirmed input material data; - A confirmed data provider interface, configured to provide confirmed input material data linked to the product identifier(s) to identified storage locations(s) for generating product passes(s) associated with the product(s) including at least a portion of the confirmed input material data.

15. Use of verified input material data associated with (multiple) input materials generated by the method of any one of claims 7 to 13 or by the apparatus of claim 14 for generating a product pass associated with a product produced at least in part from said (multiple) input materials.

Images