Systems and methods for automatic carbon intensity calculation and tracking

Abstract

Examples of the present disclosure describe systems / methods for automatically generating and tracking Carbon Intensity (CI) scores assigned to a particular product as it traverses through processing plants and discrete steps in the supply chain. In some examples, intermediate CI scores may be assigned to a product as it completes each step in its lifecycle. The intermediate CI scores may be aggregated to produce a final CI score. Each intermediate CI score is recorded on the blockchain such that the CI scores are independently verifiable and auditable.

Description

[Technical Field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority to and the benefit of U.S. Provisional Application No. 63 / 180,309, filed April 27, 2021, the disclosure of which is incorporated herein by reference.

[0002] The present disclosure relates to the fields of carbon intensity tracking, blockchain systems, and smart contracts. [Background technology]

[0003] Today's entities seeking to reduce their carbon footprint struggle to measure and verify the environmental impact of their activities, from headquarters to global operations and supply chains. For example, customers looking to purchase environmentally friendly products typically must rely on the word of their suppliers, as today's climate accounting technology challenges the ability to transparently audit and verify a product's environmental impact. As an ever-increasing number of companies make climate pledges, holding these companies accountable becomes increasingly important.

[0004] An important objective of some providers of "environmentally friendly products" is to efficiently and accurately substantiate environmental marketing claims (e.g., as required under 16 CFR § 260, "Guidelines for the Use of Environmental Marketing Claims"), assist in the monetization of such marketing claims, protect against allegations of unjustified claims (e.g., "greenwashing"), and ensure economic value based on the costs incurred in producing environmentally friendly products.

[0005] Collecting and using data from different sources, i.e., energy use and potential carbon emissions, to determine emissions is difficult due to the lack of a comprehensive standard for carbon accounting or a single set of guidelines on how to audit, verify, and report carbon emissions throughout the supply chain. One current method of climate accounting involves carbon credits, which involve accounting for changes in a product's raw materials, manufacturing processes, and handling that affect its carbon intensity (i.e., the carbon emitted per unit of raw material, process, or handling). A carbon credit is one metric ton of carbon dioxide or an equivalent amount of a different greenhouse gas (e.g., using global warming potentials to convert carbon dioxide to an equivalent value). In a cap-and-trade system, companies are allocated a certain number of carbon credits. If companies would emit more greenhouse gases than their cap, they must purchase carbon credits to offset their excess production of greenhouse gases. Carbon credits can be purchased directly from companies producing below their cap or from exchanges that aggregate excess carbon credits. Another carbon market mechanism may include a scenario in which an entity is required to purchase carbon credits (e.g., as required by the Regional Greenhouse Gas Initiative (RGGI)). Such carbon credit markets may exist in compliance and non-compliance (i.e., voluntary) environments, where carbon is tracked against internal performance standards as opposed to regulated standards.

[0006] Carbon credits not purchased from companies using less than these caps are obtained from projects that capture greenhouse gases from the atmosphere or that produce less greenhouse gases than current alternatives. An example of a project that produces less greenhouse gases than typical methods would be a project that is usually powered by burning coal, but in which the coal is replaced with an energy source that does not involve greenhouse gas emissions, such as solar power. An example of a project that captures greenhouse gases from the atmosphere is a carbon capture project, such as reforestation. However, one challenge with carbon credits and carbon offsets is ensuring that the purchase of carbon credits is, in fact, a purchase of carbon credits that have not already been purchased by another entity. Because a reliable, end-to-end, and fully auditable solution does not exist today, duplicate purchases of carbon credits are common. Another challenge is properly substantiating claims associated with carbon credits, such as determining the date, location, input technology, and other characteristics of the carbon credits' origin.

[0007] The existing method for measuring carbon emissions today is the carbon intensity (CI) score, or, as it is called in Europe, the direct carbon value (DCV). The CI score is calculated based on the amount of carbon dioxide produced during the process of growing crops and processing them into biofuel. Currently, in some jurisdictions, crops used to produce biofuel at a particular plant are aggregated and assigned a CI score (e.g., g / MJ (megajoules), g / TJ (terajoules), etc.) regardless of differences in growing methods. Differences in growing methods and transportation are not taken into account. As a result, carbon credits derived from CI scores may not accurately reflect reduced (or non-reduced) carbon emissions. For example, there is little documentary evidence to determine whether a crop producer's CI score accurately reflects their production methods.

[0008] Another issue with carbon credits is the inefficiency in exchanging / trading them. Buyers and sellers typically cannot verify and verify the true value of the carbon credits and simultaneously audit the value of the carbon credits (i.e., determine that the carbon credits originate from legitimate environmentally conscious and carbon-conscious processes). Buyers and sellers also typically must wait several days for their carbon credits to be transferred and settled. Therefore, a need exists to more efficiently and transparently verify the value of carbon credits and transfer them between entities.

[0009] One aspect of this application is blockchain-based technology, or more generally, distributed ledger technology (DLT). A blockchain is a continuously growing list of records, called blocks, that are linked and secured using cryptography. Each block may contain a hash pointer as a link to previous blocks, a timestamp, and transaction data (e.g., each block may contain many transactions). By design, blockchains are inherently resistant to modification of already recorded transaction data (i.e., once a block is added to the blockchain, it cannot be changed). Additional blocks may be added to the blockchain, and each additional block (i.e., "change") may be recorded on the blockchain. A blockchain may be managed by a peer-to-peer network of nodes (e.g., devices) that collectively adhere to a consensus protocol to establish new blocks. Once recorded, transaction data in a given block cannot be retroactively altered without altering all previous blocks, which requires the collusion of a majority of the network nodes.

[0010] A public, permissioned blockchain is an append-only data structure maintained by a network of nodes that do not completely trust each other. A permissioned blockchain is a type of blockchain in which access to the network of nodes is controlled in some manner, for example, by a central authority and / or other nodes in the network. All nodes in a blockchain network agree on an ordered set of blocks, and each block may contain one or more transactions. Thus, a blockchain can be viewed as a log of ordered transactions. One particular type of blockchain (e.g., Bitcoin) stores coins as a system state shared by all nodes in the network. Bitcoin-based nodes implement a simple replicated state machine model that moves coins from one node address to another, and each node may contain many addresses. Furthermore, a public blockchain may include full nodes, which may contain the entire transaction history (e.g., a log of transactions), or nodes may not contain the entire transaction history. For example, Bitcoin includes thousands of full nodes, with all of the nodes connected to it.

[0011] With the advent of decentralized blockchains came the emergence of decentralized finance, or "DeFi." DeFi is a general term for decentralized, peer-to-peer financial infrastructure on which various cryptocurrency-based financial applications run. What makes these applications decentralized is that they are not controlled by a central authority; instead, the rules for these applications are written in code, which is publicly available for anyone to audit. These rules written in code are known as "smart contracts," which are programs that run on the blockchain and are automatically executed when certain conditions are met. DeFi applications are built using smart contracts. DeFi applications can be thought of as a cluster of second-layer decentralized applications (e.g., DApps) that run on top of the blockchain. The present invention provides, for example, the following. (Item 1) 1. A system comprising: at least one processor; a memory coupled to the at least one processor, the memory comprising computer-executable instructions that, when executed by the at least one processor, receiving at least one contract term, wherein the at least one contract term is in the form of program code; establishing at least one smart contract on a blockchain based on the at least one contract term; receiving input data associated with at least one participant in a supply chain; generating at least one state associated with the input data from the at least one participant; recording the at least one state on the blockchain; determining at least one carbon intensity (CI) score based on the input data and the at least one smart contract associated with the at least one participant; recording the at least one CI score on the blockchain, the at least one CI score being associated with the at least one state; applying at least one machine learning model to the at least one CI score and the at least one condition; generating at least one suggestion for reducing said at least one CI score; a memory; A system comprising: (Item 2) recording at least one state of a farm or production facility on the blockchain; recording at least one measurement of the acreage of the farm or the production facility on the blockchain; Item 1. The system of item 1, further comprising: (Item 3) Item 10. The system of item 1, wherein the input data comprises at least one agricultural practice. (Item 4) 2. The system of claim 1, wherein the input data comprises at least one chemical production practice. (Item 5) Item 10. The system of item 1, wherein the input data comprises at least one of a location, a process, financial constraints, regenerative agricultural practices, green energy inputs, water usage measurements, and measurements of at least one energy source. (Item 6) Item 10. The system of item 1, wherein the CI score is further determined by reference to at least one regulatory agency's CI score calculation. (Item 7) The step further comprises: generating CI tokens based on the CI scores; storing the CI token on the blockchain; Item 1. The system according to item 1, comprising: (Item 8) The step further comprises: applying said CI tokens to offset at least one instance of carbon emissions; burning the CI tokens based on the application of the CI tokens; Item 8. The system according to item 7, comprising: (Item 9) 2. The system of claim 1, wherein the at least one suggestion is a suggestion to the at least one participant to reduce the at least one CI score in a future iteration of the supply chain. (Item 10) 2. The system of claim 1, wherein the at least one suggestion is a suggestion to a second participant in the supply chain to reduce the at least one CI score, the second participant being a successor to the at least one participant in the supply chain. (Item 11) 2. The system of claim 1, wherein the at least one suggestion is a suggestion for selecting at least one subsequent processing facility in the supply chain based on the at least one CI score exceeding a CI score threshold. (Item 12) Item 12. The system of item 11, wherein the at least one downstream processing facility is a renewable energy-powered processing facility if the at least one CI score exceeds the CI score threshold. (Item 13) Item 12. The system of item 11, wherein the at least one downstream processing facility is a fossil fuel-powered processing facility if the at least one CI score does not exceed the CI score threshold. (Item 14) 10. The system of claim 9, wherein the at least one suggestion comprises at least one suggestion associated with shipping method, fuel selection, fertilizer brand, and pesticide application rate. (Item 15) Item 1, wherein the at least one machine learning model utilizes at least one of the following algorithms: linear regression, logistic regression, linear discriminant analysis, classification and regression trees, naive Bayes, k-nearest neighbors, learning vector quantization, neural networks, support vector machines (SVMs), bagging and random forests, and AdaBoost. (Item 16) 1. A method for generating intelligent suggestions for reducing a CI score, comprising: receiving input data associated with at least one stage in a supply chain; analyzing the at least one stage in the supply chain using at least one machine learning model, the at least one machine learning model being trained to identify a plurality of characteristics that either increase or decrease a carbon intensity (CI) score; calculating an intermediate CI score based on the analysis of the at least one stage in the supply chain; assigning said intermediate CI score to said at least one stage; comparing the intermediate CI score to a threshold CI score; generating at least one intelligent suggestion associated with decreasing the intermediate CI score based on a comparison of the intermediate CI score and the threshold CI score; A method comprising: (Item 17) 17. The method of claim 16, wherein the at least one stage comprises data regarding at least one current participant in the supply chain and at least one product being processed in the supply chain. (Item 18) Item 18. The method of item 17, wherein the at least one intelligent suggestion is a suggestion to the at least one participant to reduce the intermediate CI score in a future iteration of the supply chain. (Item 19) Item 18. The method of item 17, wherein the at least one proposal is to a second participant subsequent to the at least one participant in the supply chain, the second participant not having yet received the at least one product in the supply chain. (Item 20) A computer-readable medium having stored thereon non-transient computer-executable instructions that, when executed, cause a computing system to: receiving at least one contract term, wherein the at least one contract term is in the form of program code; establishing at least one smart contract on a blockchain based on the at least one contract term; receiving input data associated with a plurality of stages in a supply chain; generating a plurality of states associated with the input data from each of the plurality of stages; recording each of the plurality of states on the blockchain; analyzing each of the plurality of conditions using at least one machine learning model, the at least one machine learning model being trained to identify a plurality of characteristics that increase and decrease a carbon intensity (CI) score; calculating a plurality of intermediate CI scores based on an analysis of each of the plurality of states on the blockchain; recording each of the intermediate CI scores in the blockchain; generating an aggregate CI score based on the plurality of intermediate CI scores; generating CI tokens based on the aggregate CI scores, the CI tokens being tradable in at least one carbon credit market; 12. A computer-readable medium for performing steps for generating a CI token comprising: Summary of the Invention [Means for solving the problem]

[0012] It is with respect to these and other general considerations that the aspects disclosed herein have been made, and although relatively specific problems may be discussed, it should be understood that the embodiments should not be limited to solving the specific problems identified in the background or elsewhere in this disclosure. [Brief explanation of the drawings]

[0013] Non-limiting and non-exhaustive examples are described with reference to the following figures.

[0014] [Figure 1] FIG. 1 illustrates an example of a distributed system for automatically generating and tracking CI scores.

[0015] [Figure 2]FIG. 2 illustrates an exemplary distributed blockchain architecture for automatically generating and tracking CI scores.

[0016] [Figure 3] FIG. 3 illustrates an exemplary input processing system for implementing systems and methods for automatically generating and tracking CI scores.

[0017] [Figure 4] FIG. 4 illustrates an exemplary method for automatically generating and tracking CI scores.

[0018] [Figure 5] FIG. 5 illustrates an exemplary method for verifying CI scores on a blockchain.

[0019] [Figure 6] FIG. 6 illustrates an exemplary method for providing intelligent suggestions for reducing CI scores.

[0020] [Figure 7] FIG. 7 illustrates an exemplary environment for automatically generating and tracking CI scores.

[0021] [Figure 8] FIG. 8 illustrates exemplary inputs and outputs used to automatically generate and track CI scores along a supply chain.

[0022] [Figure 9] FIG. 9 illustrates an exemplary state diagram used to automatically generate and track CI scores.

[0023] [Figure 10] FIG. 10 illustrates an exemplary environment from which data is captured for automatically generating and tracking CI scores.

[0024] [Figure 11] FIG. 11 illustrates an exemplary environment for automatically generating and validating CI scores.

[0025] [Figure 12] FIG. 12 illustrates an exemplary environment for generating CI tokens via CI scores.

[0026] [Figure 13] FIG. 13 illustrates an example environment for generating CI tokens using a Corda application.

[0027] [Figure 14] FIG. 14 illustrates one example of a suitable operating environment in which one or more of the present embodiments may be implemented. DETAILED DESCRIPTION OF THE INVENTION

[0028] Detailed Description Various aspects of the present disclosure are described more fully below with reference to the accompanying drawings, which form a part of this specification and which show specific exemplary aspects. However, different aspects of the present disclosure may be embodied in many different forms and should not be construed as limited to the aspects set forth herein; rather, these aspects are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the aspects to those skilled in the art. Aspects may be embodied as methods, systems, or devices. Thus, aspects may take the form of hardware implementations, entirely software implementations, or implementations combining software and hardware aspects. The following detailed description is therefore not to be taken in a limiting sense.

[0029] Embodiments of the present application are directed to systems and methods for automatically generating and tracking Carbon Intensity (CI) scores. In addition, the present application also describes example embodiments for generating CI tokens having values ​​derived from CI scores. In still further examples, the present application is directed to using at least one machine learning (ML) algorithm to generate dynamic and intelligent suggestions for lowering CI scores as products move through a supply chain.

[0030] In one example, a method is described for tracking a CI score associated with a particular crop using a distributed ledger. As the crop traverses through the supply chain, the CI score associated with the crop may be updated based on certain inputs, such as how the crop is harvested and how the crop is processed into a final product, e.g., biofuel. Relevant information about the crop and subsequent biofuel is continuously added to the distributed ledger as the crop is, for example, harvested, transported to a production facility, processed into biofuel, blended, transported, sold, and ultimately consumed. Another example may include utilizing biofuel for electricity and hydrogen. Information may be captured on a blockchain, or the information may be entered (e.g., by a farmer, plant operator, processor, etc.) using a device (e.g., an IoT device). The CI score associated with a particular product (e.g., a batch of corn) continuously evolves along the supply chain, and the CI score may become final upon delivery of the final product (e.g., jet fuel) to a customer. The finalized CI score may be captured in a certificate and stored on the blockchain. The certificate may then be used to generate redeemable CI tokens with a value directly correlated to the CI score recorded on the certificate. The CI tokens may retain value unless the tokens are used / applied to offset actual carbon emissions. Once the CI tokens are applied to offset actual carbon emissions, the CI tokens may be "burned."

[0031] In some examples, intermediate CI scores may be calculated at a location in the supply chain. CI scores (e.g., attributes) may be traded independently from the physical underlying commodity (e.g., corn). For example, these intermediate CI scores may be combined and recombined at or before final consumption. The intermediate CI scores may be used as input to a machine learning model to generate intelligent suggestions for lowering the CI score in the next or subsequent step in the supply chain. For example, if the intermediate CI score is abnormally high for a particular location in the supply chain, the machine learning algorithm may suggest certain adjustments in the next step in the supply chain (e.g., using solar power for electricity instead of fossil fuels) in an attempt to lower the CI score or at least slow the increase in the CI score. The systems and methods described herein may determine which crop loads should be paired with which processing techniques and energy sources to produce biofuels with specific CI scores and monetary costs. The energy sources that may be recommended by the machine learning algorithm may alternate between green and conventional energy sources at the plant depending on the product's current CI score and input constraints of the current participants in the supply chain (e.g., farmers, shippers, processors, plant operators, refiners, buyers, etc.) (e.g., the ML algorithm will not suggest using solar energy if the current factory in the supply chain is not equipped to use solar power). In other exemplary aspects, the systems and methods described herein can track energy sources within a particular plant that is processing a commodity (e.g., corn). Energy sources may be tracked by the minute, by the hour, etc. Such energy sources may comprise wind, combined heat and power (CHP) electricity, biogas, renewable natural gas (RNG), natural gas, grid electricity, and / or combinations of the foregoing.

[0032] In another example, a machine learning model may be used to provide intelligent suggestions to previous participants in the supply chain. For example, if the CI score is unusually high at a certain point in the supply chain, a machine learning algorithm may suggest certain optimization methods to the previous participants (or previous processes) so that the past participants can implement these optimization methods in the future, which would hopefully lower the CI score at that point in the supply chain. The lower the CI score, the higher the value that the generated CI tokens will have (i.e., an efficient market may result in a lower CI score). It should be understood that the teachings herein may be applied not only to achieving a lower CI score, but also to achieving a target CI range or staying below a target CI threshold.

[0033] 1 illustrates an example of a distributed system for automatically generating and tracking CI scores. The presented exemplary system 100 is a combination of interdependent components that interact to form an integrated whole for automatically transferring assets based on one or more smart contracts. The components of the system may be hardware components or software implemented on and / or executed by the hardware components of the system. For example, system 100 includes client devices 102, 104, and 106, local databases 110, 112, and 114, a network 108, and server devices 116, 118, and / or 120.

[0034] Client devices 102, 104, and / or 106 may be configured to receive and transmit information related to products traversing the supply chain and a CI score associated with that particular product. The CI score continuously evolves as the product continues to progress through the supply chain, and the CI score may be updated on a blockchain that may be stored and accessed by client devices 102, 104, and / or 106. Client devices 102, 104, and / or 106 may also be configured to communicate within a blockchain network and locally host a copy of the blockchain in local databases 110, 112, and / or 114. DeFi applications may reside on the blockchain, upon which client devices 102, 104, and / or 106 are configured to run (and / or interact with). In one example, client device 102 may be a mobile phone, client device 104 may be an IoT device in a factory (e.g., a monitoring device on a conveyor belt in a factory), and client device 106 may be a laptop / personal computer. Other possible client devices include, but are not limited to, tablets, smart devices / sensors, unmanned aerial vehicles (e.g., to capture aerial footage of a processing step), unmanned ground vehicles (e.g., to monitor the processing steps of a machine used in a supply chain), etc.

[0035] In some demonstrative aspects, client devices 102, 104, and / or 106 may be configured to communicate with a satellite, such as satellite 122. Satellite 122 may be a satellite (or multiple satellites) in a cellular system. Client devices 102, 104, and / or 106 may receive data from satellite 122 via a cellular protocol. Cellular data received by client devices 102, 104, and / or 106 may be stored in local databases 110, 112, and / or 114. Additionally, such cellular data may be stored remotely at remote servers 116, 118, and / or 120. In other examples, client devices 102, 104, and / or 106 may be configured to communicate with one another via a short-range communication protocol, such as Bluetooth®.

[0036] Client devices 102, 104, and / or 106 may also be configured to launch software implementing (and / or interacting with) a blockchain with at least one DeFi application to automatically generate, track, and validate CI scores associated with products in the supply chain once they have been determined. Additionally, client devices 102, 104, and / or 106 may be configured to launch software that generates intelligent suggestions for reducing CI scores using at least one ML model with access to current processing techniques and input data for processing particular products / raw materials in the supply chain. For example, the generation of intelligent suggestions may rely on information gleaned from information already stored on at least one blockchain and / or other traditional information repositories, such as databases (e.g., agricultural techniques, plant operator energy sources, etc.). In some embodiments, the characteristics of each participant in the supply chain may be stored as a “state” within the blockchain, and the participant’s state includes an information identifier with a value that can be accessed by the system to determine a particular CI score and / or predict future CI scores. The same states of these participants in the supply chain may also be accessed by at least one ML model to generate intelligent suggestions for reducing the CI score at each step in the supply chain. As an example, a participant that implements an intelligent suggestion (e.g., changing electricity at a factory from fossil fuels to solar) may record a new "state" for the participant, which may affect future CI scores associated with future products moving through the supply chain.

[0037] For example, during initial setup, participants in the supply chain may provide certain information to the system via client devices 102, 104, and / or 106. The system may process that information and build a “state” for that participant. The participant’s state may be stored remotely on servers 116, 118, and / or 120 and / or locally in databases 110, 112, and / or 114. State profiles may be stored as blocks on the blockchain. Participants may observe the state of other participants in the supply chain via network 108 or satellite 122. For example, a participant may be a government agency (e.g., a regulator) verifying the state information of a participant in the supply chain. Access to such state profiles may be provided via DeFi applications running on the blockchain.

[0038] One or more smart contracts may also reside on the blockchain network. Copies of the smart contracts may be stored locally in local databases 110, 112, and / or 114 and remotely on servers 116, 118, and / or 120. The smart contract may determine the amount an end consumer pays for an end product based on the end product's determined CI score. For example, a consumer who contracts with a supplier to purchase a product with a certain CI score may receive a product with a higher or lower CI score. The smart contract stored on the blockchain may automatically adjust payments between the supplier and the customer based on the determined CI score. If the customer wanted to purchase a product with a lower CI score but received a product with a higher CI score, the customer may automatically receive a discount according to the terms of the smart contract. If the product has a lower CI score than expected, the customer may, in some embodiments, choose to pay a premium for the product with the lower CI score or not take ownership of the product (e.g., a standard fuel purchase agreement). Assets to be transferred between end customers and suppliers may be placed in escrow on the blockchain. For example, a smart contract may be between a fuel supplier and an airline (customer). Based on an aggregate CI score associated with each unit of jet fuel received by the airline, the airline's escrowed assets may be automatically transferred to the jet fuel supplier based on certain conditions being met on the smart contract. For example, if the aggregate CI score is one point higher than expected, a certain amount of assets is deducted from an agreed-upon amount and transferred from the escrow account (e.g., wallet) to the supplier account (e.g., wallet). The transaction may be recorded as a block on the blockchain, which ensures the integrity of claims regarding carbon benefits in the supply chain.

[0039] Additionally, the systems and methods described herein may implement at least one ML model with access to at least one database of history processing techniques proven to reduce CI scores. For example, the database may comprise information regarding the average reduction in CI scores due to a transition from fossil fuel-powered machinery to hydro-powered machinery. Such data may be accessed by client devices 102, 104, and / or 106 via network 108 and / or satellite 122. The database may also be stored locally in databases 110, 112, and / or 114.

[0040] In some example aspects, client devices 102, 104, and / or 106 may be equipped to receive signals from input devices. Signals may be received on client devices 102, 104, and / or 106 via Bluetooth, Wi-Fi, infrared, optical signals, binary, among other mediums and protocols for transmitting / receiving signals. For example, a user may use a mobile device 102 to query a DeFi application running on a blockchain to receive updates regarding a product's (e.g., a large quantity of corn) current CI score and a predicted CI score for the product based on future processing steps in the supply chain. A graphical user interface associated with the DeFi application may be displayed on the mobile device 102, showing a CI score tracker and the expected value to be captured in CI tokens after the CI score is determined and verified.

[0041] FIG. 2 illustrates an exemplary distributed blockchain architecture for automatically generating and tracking CI scores. FIG. 2 is an alternative illustration of a distributed system 200, such as system 100 of FIG. 1. In FIG. 2, network devices are interconnected and communicate with each other. Each device in the network has a copy of the blockchain (or at least a partial copy of the blockchain, e.g., light nodes) because, in some embodiments, the blockchain is not controlled by any single entity but rather by a distributed system. In other embodiments, the blockchain is a permissioned blockchain that includes an access control layer, which may prevent and allow some devices from reading and writing certain information to the blockchain.

[0042] Specifically, in FIG. 2 , mobile devices 202, 206, 210, and 214 are connected with laptops 204 and 212 and “smart” factories 208 and 216 (e.g., IoT devices in a process plant or factory, such as monitoring devices on machinery in the factory) in a distributed system 200. The devices depicted in FIG. 2 communicate with each other within a blockchain network 220. Each node may store a local copy of the blockchain or at least a portion of the blockchain. For example, laptop 204 may query a blockchain in the blockchain network, and a server may receive the query and produce blocks from the copy of the blockchain stored on the server. Laptop 204 may receive information located in the blocks (e.g., current CI score, predicted CI score, ML-based suggestions for lowering the CI score, etc.). In summary, the systems and methods described herein may be implemented within a distributed architecture such as that shown in FIG. 2 and, in some examples, on a single node within the distributed blockchain network.

[0043] FIG. 3 illustrates an exemplary input processing system for implementing systems and methods for automatically generating and tracking CI scores. The input processing system (e.g., one or more data processors) may execute algorithms, software routines, and / or instructions based on processing data provided by various sources related to generating and tracking CI scores and generating intelligent suggestions to entities in the supply chain to reduce a particular product's CI score. The input processing system may be a general-purpose computer or a dedicated special-purpose computer. According to the embodiment shown in FIG. 3, the disclosed system may include memory 305, one or more processors 310, a data collection module 315, a smart contract module 320, a carbon intensity (CI) calculation module 325, a machine learning (ML) suggestion module 330, and a communications module 335. Other embodiments of the present technology may include some, all, or none of these modules and components, along with other modules, applications, data, and / or components. Still further, some embodiments may combine two or more of these modules and components into a single module and / or associate some of the functionality of one or more of these modules with a different module.

[0044] Memory 305 can store instructions for running one or more applications or modules on processor 310. For example, memory 305, in one or more embodiments, can be used to store all or some of the instructions needed to execute the functionality of data collection module 315, smart contract module 320, CI computation module 325, ML proposal module 330, and communication module 335. Generally, memory 305 can include any device, mechanism, or capture data structure used to store information, including a local copy of a blockchain data structure. According to some embodiments of the present disclosure, memory 305 can encompass any type of volatile memory, non-volatile memory, and dynamic memory, without limitation. For example, memory 305 can be a random access memory, memory storage device, optical memory device, magnetic media, floppy disk, magnetic tape, hard drive, SIMM, SDRAM, RDRAM, DDR, RAM, SODIMM, EPROM, EEPROM, compact disc, DVD, and / or the like. According to some embodiments, memory 305 may include one or more disk drives, flash drives, one or more databases, one or more tables, one or more files, local cache memory, processor cache memory, relational databases, flat databases, and / or the like. Additionally, those skilled in the art will recognize many additional devices and techniques for storing information that may be used as memory 305. In some exemplary aspects, memory 305 may store at least one database containing current CI scores for a particular product, certain CI score thresholds based on regulatory information (e.g., CI score thresholds for determining tax credits in a particular region / state), historical average CI scores for a product, average decreases or increases in CI scores based on certain processing techniques, etc.In other exemplary aspects, memory 305 may store at least one copy of a blockchain with at least one DeFi application running on the blockchain. In yet other exemplary aspects, memory 305 may store assets (e.g., fungible or non-fungible CI tokens, stablecoins, etc.) that may be submitted to the blockchain via a DeFi application. In other aspects, memory 305 may be configured to store at least one current CI score and a predicted supply chain path, where the predicted supply chain path and the current CI score are used as inputs to generating intelligent ML-based suggestions for reducing the CI score as the product traverses the supply chain. Any of the data, programs, and databases that may be stored in memory 305 may be applied to the data collected by data collection module 315.

[0045] The memory 305 may also be configured to store certain “states” of products and manufacturing / processing techniques. For example, a farm may previously have utilized harvesting techniques that rely on fossil fuels (State A). If the farm changes its harvesting techniques to rely on renewable energy sources rather than fossil fuels, the state may be updated and stored in the memory 305 (State B). Additionally, the memory 305 is configured to record the CI scores of a product or products as they move through the supply chain. At each step in the supply chain, a CI score is captured and recorded. For example, pre- and post-processing CI scores may be captured at each supply chain step, which may be used to accurately verify the established CI score once the end consumer receives the final product. The established CI score may be used in determining a value for the CI token. To accurately determine the value of the CI token, the system described herein may rely on an accurate and verifiable audit trail of CI scores to establish provenance. An audit trail of CI scores may be stored in memory 305; for example, memory 305 may store a copy of a blockchain with CI scores recorded at each step in the supply chain as individual immutable blocks added to the blockchain. In some embodiments, to ensure the immutability of the block, each block must be signed (i.e., agreed / accepted) by all required signatories. Once all signatures are collected, the block may become committed, and the entries in that block may be marked as historical (e.g., in the supply chain). In addition to CI scores, other data related to location may be captured and stored on the blockchain, including aerial images of the farmland (e.g., to ensure that acreage has not increased or decreased).

[0046] The data collection module 315 may be configured to collect data associated with at least one process in the supply chain. For example, the data collection module 315 may be configured to receive data associated with a farmer's cultivation practices, use of fossil fuels versus renewable energy machinery, fermentation techniques, the types of vehicles involved in the shipping process (e.g., whether they are electric vehicles or combustion engine-driven), and the like. Other information that may be received by the data collection module 315 may include location, operational, production, environmental, social, regulatory, yield, and / or financial performance data associated with product production. Such information may be received automatically by the data collection module 315 through a client device and / or a trusted third-party source (e.g., a farmer may enter data about farming techniques into a third-party application, which then stores the data, transmits the data to the data collection module 315, or alternatively, makes the data available for observation and analysis via the data collection module 315). The data collection module 315 may also be configured to query at least one database associated with historical processes in the supply chain. In some examples, processes may be categorized according to the product and / or industry being produced. A historical process may include state information, including discrete processing steps and inputs used by a participant in the supply chain. Additionally, the historical data in the database may comprise a CI score for a product generated at that point in the supply chain. The database may also reflect how the CI score changed as the associated product flowed through different steps in the supply chain (e.g., one process in the supply chain led to a lower CI score, while another process in the supply chain increased the CI score).Such historical processing of supply chain data and CI scores may comprise historical trends of successful and unsuccessful attempts to reduce CI scores from past participants' processing methods (e.g., applying new types of fermentation techniques, replacing gas-powered machinery with EV-powered machinery for harvesting, etc.). The data collection module 315 may also be configured to receive real-time updates regarding the CI score at a step in the supply chain. For example, after a product moves to a subsequent step in the supply chain, this status update may be recorded on the blockchain, and a new CI score may be recorded based on the previous processing steps applied to the product. After a product is processed at a new step in the supply chain, a new CI score may be updated (and recorded on the blockchain) based on data captured by the data collection module 315. Similarly, when a CI score is determined and used to create a CI token, information associated with the value of the CI token (e.g., a complete, immutable audit trail of the product's processing steps through the supply chain, showing how the product's CI score evolved at each step) may be stored on the blockchain and received by the data collection module 315.

[0047] For example, a net-zero processing plant may be expected to obtain a particular CI score based on its inputs (e.g., recorded at a state in a state diagram on a blockchain). In one example, the net-zero plant may be expected to utilize wind power, biogas generated on-site from wastewater (e.g., to reduce the use and reliance on fossil-fuel-based natural gas), electricity generated from biogas also generated on-site, renewable natural gas brought on-site (which may be characterized by a different CI score than biogas generated on-site), grid electricity, and fossil-fuel natural gas. Other inputs that may affect the CI score at a particular stage in the supply chain include transportation method, auxiliary equipment operation (tractors, loaders, etc.), elevator operation, intermediate product transportation, final product transportation, etc. The CI score that may be produced from this net-zero plant may be affected by the extent of use of each of the aforementioned energy inputs. Based on the current CI score of the commodity arriving at the net-zero plant and the expected CI score of the processed commodity at a later stage in the supply chain, a particular mix of energy inputs may be determined at the net-zero plant to produce a CI score that maximizes both energy efficiency and economic efficiency (i.e., balances carbon emissions and costs).

[0048] Alternatively, the data collection module 315 may query or otherwise seek data from one or more data sources (e.g., other nodes in the network) that comprise such information. For example, the data collection module 315 may have access to data in one or more external systems, such as a content system, a distribution system, a marketing system, supply chain participant / entity / partner profiles or preference settings, an authentication / authorization system, a device manifest, or the like. Specifically, the data collection module 315 may have access to at least one database of historical and current CI score data and analysis (e.g., an analysis regarding the environmental impact of applying a process in the supply chain, including a predicted CI score for a particular product), which may inform the system regarding the next step in the supply chain where a product should be shipped, which may provide the product's CI score with the best opportunity to reduce its CI score or, alternatively, limit an increase in the CI score compared to applying another process to the product. The data collection module 315 may use an API or similar set of interfaces to communicate requests to and receive response data from such data sources. In at least one embodiment, the data collection process of data collection module 315 may be triggered according to a pre-set schedule, in response to a specific user request to collect data (e.g., a user desires to know the current CI score for a batch of a larger product group currently traversing the supply chain), or in response to the satisfaction of one or more criteria (e.g., a push notification is sent to an entity after an updated CI score for a product reveals that the CI score exceeds a particular threshold).

[0049] The smart contract module 320 may be configured to receive data from the data collection module 315 (e.g., in a spreadsheet format, a database table, etc.). The data received by the smart contract module 320 may enable the smart contract module 320 to establish at least one smart contract between an entity in the supply chain and the system described herein. The smart contract may be for generating a CI score. Thus, for example, an entity in the supply chain (e.g., a farmer) who agrees to the terms of the smart contract (i.e., a discrete formula for calculating a CI score based on a particular product of interest and specific inputs provided by an IoT device monitoring the farmer and / or the farmer's equipment) will contract with the CI score generation and tracking system described herein and agree that the generated CI score will be correct. For example, the initial data received by the smart contract module 320 may be the contract terms (i.e., rules) for calculating carbon intensity (CI). Additional contract terms may be provided in some cases, such as certain conditions required by the customer (e.g., a smart contract may contain a condition for the customer to automatically reject certain products that exceed a maximum CI score threshold). In such an embodiment, the contract terms that calculate the immutable CI score are distinct from the additional contract terms. However, the initial generation / calculation of the CI score may be used as an input value in determining whether certain additional customer-specific smart contract terms are triggered. In another embodiment, a supplier and a manufacturer may agree that certain products that exhibit a CI score below a certain threshold automatically result in a premium price for the product. Based on the smart contract calculation of the CI score, a supplier may automatically receive a higher price for the end product due to the product's lower CI score (i.e., a product that is more valuable to the end customer).In embodiments, a smart contract (e.g., operating via a DeFi application on a blockchain) may have access to a third-party application that monitors the use of certain processes and machinery by entities in a supply chain. Based on information received from monitoring the use of certain processes and machinery (which may be collected by data collection module 315 and provided to smart contract module 320), certain smart contract conditions can be automatically triggered.

[0050] In another embodiment, the smart contract module 320 may be configured to trigger the transfer of funds from the escrow wallet to the end customer's wallet (or vice versa). For example, if a malfunction occurs in the delivery of a product, the rules of the smart contract may require that a certain amount of assets (e.g., fiat currency, cryptocurrency, etc.) be transferred from the supplier's wallet address to the end customer's wallet address. Conversely, once the product is successfully delivered and verified with a certain CI score, the smart contract module 320 may be configured to trigger an automatic payment from the end customer to the supplier.

[0051] In yet another embodiment, the smart contract module 320 may be configured to interact with a carbon intensity (CI) calculation module 325. The CI calculation module 325 may be configured to receive real-time input from a participant in the supply chain, such as status information from a farm, processing plant, manufacturing facility, packaging supplier, etc. Such status information may contain information about how a participant in the supply chain intends to process a particular product at that stage in the supply chain. The information may include the type of energy being used to power machinery at the facility, whether certain environmentally friendly techniques are being applied, farming practices, application rates of pesticides (e.g., fertilizers, herbicides, insecticides, etc.), the types of pesticides applied to crops, information derived from soil audits (e.g., from third-party auditors and / or sensors), and other carbon offset measurements.

[0052] In some examples, the CI calculation module 325 may be configured to calculate the CI score based on input from participants in the supply chain in combination with regulatory and standardization algorithms for calculating the CI score. Those skilled in the art will understand that CI score calculations are standardized according to jurisdiction. For example, the U.S. state of California calculates the CI score according to life cycle analysis, an analytical method for estimating the intensive amount of greenhouse gases emitted during an entire fuel life cycle. The GHG Protocol calculates the CI score as the amount of CO2 emitted per functional energy unit of a product. The Environmental Protection Agency utilizes a greenhouse gas equivalent calculator (e.g., CA.GREET 3.0). Other jurisdictions and agencies measure carbon intensity as the weight of carbon per British thermal unit (Btu) of energy. Further examples of calculating CI include Argonne National Laboratory's GREET model, including GREET model variations implemented by certain jurisdictions and entities, such as the State of California, the International Civil Aviation Organization (ICAO), and the European Union (e.g., Renewable Energy Directives (RED and REDII)). Each of the aforementioned calculation methodologies has differences in assumptions and may not allow carbon credits to be traded equally across carbon markets.

[0053] The CI calculation module may be configured to communicate with the smart contract module 320, as certain terms and conditions from the smart contract module 320 may determine how the CI score is calculated by the CI calculation module 325. For example, the smart contract module 320 may contain an algorithm that does not involve any input from participants in the supply chain, but the CI calculation module 325 may receive those inputs (via the data collection module 315) and use those inputs in conjunction with the algorithm terms defined in the smart contract module 320 to generate (and / or update and / or finalize) a CI score for a particular product.

[0054] The smart contract module 320 and the CI calculation module 325 may be configured to communicate with a machine learning (ML) suggestion module 330 (or vice versa). The ML suggestion module 330 may rely on information provided by the smart contract module 320 and the CI calculation module 325 to provide intelligent machine learning model-driven suggestions to a participant in the supply chain, specifically related to how the participant can modify its processing methods to reduce the CI score of future products. In an alternative embodiment, the ML suggestion module 330 may provide the system with real-time suggestions regarding the participant in the supply chain to which the product should be sent next. For example, at step number 3 in the supply chain, the product may be further processed at Plant A or Plant B. Based on the product's current and historical CI scores and status information from Plant A and Plant B, the ML suggestion module 330 may intelligently suggest to the system which plant (Plant A or Plant B) the product should be shipped to next for processing, based on a prediction output that one plant is more likely to produce a lower CI score for that particular product at the current time than the other plant.

[0055] The ML suggestion module 330 may be configured to automatically make intelligent suggestions on how to optimize the supply chain (i.e., lower the CI score) by providing suggestions directly to participants and stakeholders in the supply chain regarding tweaks, substitutions, and improved processes to make them more eco-friendly in order to achieve a lower CI score for the final product. Rather than attempting to manually make adjustments to the supply chain (typically with insufficient information about the supply chain as a whole), the ML suggestion module 330 may automatically make intelligent suggestions in at least two types of settings: (i) to a participant in the supply chain based on past performance indicators (e.g., status information reflecting current data about the operation of certain machinery and participants in the supply chain), and (ii) to a supply chain operator / controller regarding where a product should be processed next based on its current CI score (e.g., one processing plant may be more eco-friendly than another plant, and the current product's CI score is at a certain threshold, so the product needs to be processed in a more eco-friendly plant to ensure that the product's CI score does not exceed the threshold). Such decisions may be made according to current CI scores, historical data associated with certain participants in the supply chain, budget constraints, end customer requirements, etc., which may be received from the data collection module 315 and provided to the ML suggestion module 330.

[0056] In one example, the ML suggestion module 330 may suggest certain substitutions and application rates of inputs (e.g., fertilizers, pesticides, etc.), shipment aggregation and timing (e.g., to more economically and efficiently deliver required inputs at a particular stage in the supply chain), transportation method and routing optimization, customer rotation (e.g., to encourage the blending of certain co-products / by-products based on shelf life), etc. In other words, actors in the supply chain may receive ML suggestions and modify their shipping methodology, change their fuel selection used in shipping products, change their fertilizer brand, change the application rate and amount of pesticide applied to a particular crop, etc.

[0057] In some aspects, the ML suggestion module 330 may be configured with a pattern recognizer that can understand historical trends to identify patterns (e.g., an input typically reduces the CI score by X%, an input typically increases the CI score by Y%, etc.). The pattern recognizer in the ML suggestion module 330 may have two modes: a training mode and a processing mode. During the training mode, the pattern recognizer may use identified inputs that have been proven to affect a product's CI score to train one or more ML models. Once one or more ML models are trained, the pattern recognizer may enter a processing mode, in which input data is compared against the trained ML models in the pattern recognizer. The pattern recognizer then produces a confidence score that represents the confidence that an input in the supply chain will either increase or decrease the CI score for a particular product; a higher confidence score may be associated with a higher likelihood that the particular input will affect the CI score (either negatively or positively). In other aspects, during training mode, the pattern recognizer may train one or more ML models using different types of processing, manufacturing, packaging, farming, shipping, etc. inputs from participants in similar positions in the historical supply chain to distinguish between data points that suggest that an input will increase or decrease (or have no effect on) the CI score. For example, a farmer who implements machinery powered by renewable energy sources may have a high confidence interval that this particular farmer's techniques will decrease the CI score of a product, while a farmer who uses fossil fuels to power their machinery will have a high confidence interval that increases the CI score of a product.

[0058] The ML suggestion module 330 may be configured with at least one machine learning model. In some aspects, the supply chain processes and features extracted from the supply chain participant data collected by the data collection module 315 may be used to train at least one machine learning model associated with a pattern recognizer during a training mode. For example, to train the machine learning model, the extracted and identified supply chain participant processes may be associated with specific risk identifiers, such as increased CO2 emissions, fossil fuel use, hazardous waste, etc. The pattern recognizer of the ML suggestion module 330 may utilize various machine learning algorithms to train the at least one machine learning model, including, but not limited to, linear regression, logistic regression, linear discriminant analysis, classification and regression trees, naive Bayes, k-nearest neighbors, learning vector quantization, neural networks, support vector machines (SVMs), bagging and random forests, and / or boosting and AdaBoost, among other machine learning algorithms. The aforementioned machine learning algorithms may also be applied when comparing input data with already trained machine learning models. Based on the identified and extracted supply chain participant features and patterns, the pattern recognizer may select an appropriate machine learning algorithm to apply to the supply chain data to train at least one machine learning model. For example, if the supply chain features and processes are complex and demonstrate nonlinear relationships, the pattern recognizer may select bagging and random forest algorithms to train the machine learning model. However, if the supply chain features and processes demonstrate a linear relationship for an increase or decrease in CI score for a product, the pattern recognizer may apply a linear or logistic regression algorithm to train the machine learning model.

[0059] The communications module 335 is associated with sending / receiving information (e.g., collected by the data collection module 315, smart contract module 320, CI calculation module 325, and ML proposal module 330) with a remote server or with one or more client devices, streaming devices, servers, blockchain nodes, IOT devices, etc. These communications may employ any suitable type of technology, such as Bluetooth, WiFi, WiMax, cellular, single-hop communication, multi-hop communication, dedicated short-range communication (DSRC), or a proprietary communication protocol. In some embodiments, the communications module 335 transmits information collected by the data collection module 315 and processed by the smart contract module 320 and CI calculation module 325 (and ML proposal module 330). Additionally, the communications module 335 may be configured to communicate certain terms of the smart contract from the smart contract module 320, the calculated CI score from the CI calculation module 325, and the automatic supply chain process improvements based on the ML proposal module 330 to the client device. Additionally, the communications module 335 may be configured to communicate an updated CI score to the client device after the product completes processing at a step in the supply chain. The communications module 335 may also be configured to communicate a complete audit trail of the CI score evolution associated with the product from farm to final product. The communications module 335 may also communicate a value associated with the CI score, which may be captured in a CI token that may be exchangeable (traded, bought, and sold) by third parties in the carbon credit market.

[0060] 4 illustrates an exemplary method for automatically generating and tracking a CI score. Method 400 begins at step 402 with receiving smart contract terms. The smart contract terms in step 402 may define an algorithm for calculating the CI score. The calculation for the CI score may depend on the type of product, the quantity of product, input from actors throughout the supply chain, and other input variables that measure the extent of the ecological friendliness of the production process and its CO2 footprint.

[0061] In other embodiments, the smart contract terms received in step 402 may comprise customer-specific terms, which may include price adjustments directly correlated with the final CI score of the end product. Other example terms may include paying a premium price for lower CI scores and denying ownership of the end product if it exceeds a certain CI score threshold. In some cases, the smart contract may be configured so that the end customer remits payments to the supplier in stages based on certain CI score milestones achieved (or missed) during the product's progression through the supply chain. In this pay-per-step environment, payments remitted to the supplier may be based on the degree to which each step in the supply chain is carbon-intensive. In a standard contract, if the payment structure were configured as a pay-per-step structure, manual monitoring of payment remittances and each process in the supply chain would need to be performed as frequently as the specified terms. Even routine monitoring of such manual contracts would be infeasible and cumbersome for the parties to implement. However, with a smart contract, terms can be automatically executed as frequently as the parties would desire. For example, every 60 seconds, the system may monitor the processing steps of a particular product and, based on the data received by the process at that time, transfer assets from an escrow wallet (representing assets deposited by the end customer) to the supplier / seller's wallet. No intermediary (e.g., bank, financial institution) is required.

[0062] Once the smart contract terms are received by the system in step 402, the smart contract may be constructed in step 404. Here, the smart contract may be automatically deployed on the blockchain according to defined rules agreed upon between the seller and buyer.

[0063] In step 406, the system may receive input data from a step in the supply chain. For example, in step number 1 in the supply chain, the system may receive data regarding a farmer's harvesting techniques. If the product of interest is corn, the system may receive input regarding the type of machinery the farmer is deploying to harvest the corn, the pesticides (if any) the farmer has applied to the corn, and the soil composition in which the corn is grown. Such input may be captured as the "state" of the farmer in the supply chain. This state data may be received by the system in step 406. The state data may be updated as the farmer's process is updated. For example, if a farmer has changed their practices (e.g., tillage techniques), soil composition, or applied a different type of pesticide to the corn, such updates may be reflected in an updated "state" data block.

[0064] Once the data is received by the system in step 406, the system may analyze the input data at 408. Such analysis may include comparing the input data to certain formulas specified by the smart contract terms (received in step 402). Additionally, the system may consider historical data related to that particular actor in the supply chain and similarly positioned actors in other supply chains. Such analysis may provide the system with a benchmark against which the system can compare the input data received in step 406 at supply chain step number 1.

[0065] After the input data is analyzed in step 408, an initial carbon intensity (CI) score may be generated in step 410. The initial CI score may be the output of a combination of the smart contract terms and the input data received in supply chain step number 1. This initial CI score may be stored and recorded on the blockchain in step 412, and other interested parties may be able to view the CI score and the rationale for the CI score (i.e., the input data received by a particular participant in the supply chain and provided to the CI score formula and smart contract terms).

[0066] As a product continues to traverse the supply chain, its CI score may be updated. A "product" traversing the supply chain may refer to a single product or a collection of products being manufactured. Some CI score formulas may apply to single products, while other CI score formulas may apply to collections of products. When a product enters the next step in the supply chain, the system receives input data at the next supply chain step (e.g., supply chain step number 2, step number 3, ... step number N, etc.) in step 414 in method 400. As mentioned with respect to step 406, the received data may comprise status information regarding the process of participants in the supply chain. In addition to status information that may be recorded by the participants themselves (or a trusted third party, e.g., an auditor), the system may also receive information from pre-installed IoT devices that may be attached to certain machines or areas where processing is occurring. For example, the IoT device may be a carbon dioxide meter that measures certain exhaust air emitted from a machine. Data captured by the carbon dioxide IoT device may be provided to the system (e.g., data collection module 315) for analysis. In another example, the IOT device may be a camera disposed within a processing facility, configured to capture the type of power source used to power a machine. For example, if a participant in the supply chain runs out of power in its battery, the participant may need to rely on fossil fuels for that day to continue processing products. Such deviations may be captured by an IOT device (e.g., a camera, a machine monitoring device, a device that monitors battery power, etc.). These day-to-day changes in the supply chain may be accurately captured by the system described herein so that the CI score assigned to a product at each step in the supply chain is an accurate representation of the environmental impact of the product's processing / manufacturing as it traverses the supply chain.

[0067] After the data is received by the system in step 414, the input data is analyzed in step 416. Similar to step 408, the input data is compared against the terms of the smart contract and a CI score may be calculated, and other customer-specific conditions may be considered in parallel (e.g., withdrawing partial payments, triggering notifications, etc.). Based on the input data and the smart contract terms, the CI score for the product may be updated in step 418. The updated CI score (also referred to as the "intermediate CI score") may be stored on the blockchain in step 420 as an appended block for interested parties to view, audit, and verify.

[0068] FIG. 5 illustrates an example method for verifying a CI score on a blockchain. Method 500 begins at step 502 with receiving a request to verify a CI score. An application (e.g., a DeFi application) running on the blockchain may provide a user with an interface for requesting and verifying a product's CI score. For example, an end customer may want to verify that a particular product advertised as having a CI score actually has that CI score by double-checking it with the CI score recorded on the blockchain. The system may receive the request at step 502, and in response to receiving the request at step 502, the system may query the blockchain at step 504. In some example aspects, an authentication layer may be applied prior to querying the blockchain at step 504 to ensure that authorized users are able to query for the CI score. Such an authorization layer may also be an extension of a permissioned blockchain network, as opposed to a public-only blockchain network where the public may query the blockchain for CI scores.

[0069] Once the blockchain is queried in step 504, the CI score may be received by the system in step 506. The CI score from a particular block in the blockchain will be validated and immutable. The CI score result may be provided to a verifier in step 508. Optionally, the system may receive an action response from the verifier in step 510. In some embodiments, the verifier may be an end customer considering purchasing a product with a CI score. For example, an action response the system may receive from the verifier in step 510 is a purchase action. In another embodiment, the verifier may be a government regulator that verifies that an advertised CI score corresponds to a validated CI score on the blockchain. If the validated CI score differs from the advertised CI score, the verifier may flag the CI score for that particular product as suspicious. Flagging the CI score as suspicious may be the action response received by the system in step 510.

[0070] In yet other embodiments, a verifier may wish to buy or sell CI tokens. To verify the value of a CI token, the verifier may request a verified CI score. For example, a verifier seeking to purchase a CI token may first engage in due diligence on the particular CI token and verify its value by querying the blockchain and receiving the results (steps 502-508). Based on the CI score provided to the verifier, the verifier may engage in purchasing the CI token associated with the CI score associated with the underlying product. The action response in step 510 may be to buy, sell, and / or trade the CI token on an exchange.

[0071] FIG. 6 illustrates an exemplary method for providing intelligent suggestions for reducing CI scores. Method 600 is directed to the application of artificial intelligence (AI) and machine learning (ML) models to the automated system for generating and tracking CI scores described herein. Method 600 begins in step 602, where input data is received at a step in the supply chain (supply chain step N, where "N" is a proxy for a number). Similar to the method described in FIG. 4, this input data may be data from any actor / participant in the supply chain that characterizes the processing occurring at that step. For example, this input data may be in the form of status information capturing certain characteristics of a farmer's harvesting techniques (e.g., tillage, type of machinery used, fuel consumption, water use, pesticide use, etc.). Other input data may be received from IoT devices (e.g., CO2 emission measurement devices, cameras, etc.) located on certain machines and in certain environments that automatically measure and analyze the input data. This data may be received by the system in step 602. In some embodiments, the input data may comprise a list of activities / inputs that have already been verified to reduce carbon emissions.

[0072] Following receipt of the input data in step 602, a carbon intensity (CI) score is generated and / or updated in step 604. If step N in the supply chain is step number 1, a CI score will be generated because this is the first supply chain processing information entered into the system required to generate a CI score. If step N is, for example, step number 3, at least two previous intermediate CI scores have already been calculated, and therefore, the results of the manufacturing / processing data in step number 3 will result in an updated CI score (e.g., intermediate CI score number 3). As explained above, the CI score calculation technique depends on the terms of the smart contract negotiated between the parties. Such smart contract terms may include a calculation formula for deriving the CI score, which may be based on industry standards and / or regulatory bodies (e.g., government).

[0073] After the CI score is generated / updated in step 604, the CI score is recorded on the blockchain in step 606. The CI score may be recorded as a new block appended to the blockchain, as described with respect to method 400 of FIG. 4. Method 600 may then proceed to optional step 608, in which data associated with supply chain step N+1 (where "N" represents a number) is received by the system. Step N+1 is a step subsequent to step N in the supply chain. The data received in step 608 is input data associated with processing methods and techniques applied to the product at step N+1 in the supply chain. The same types of input data described above may be collected here. Furthermore, the participants in the supply chain at step N and step N+1 may be the same participant (e.g., different facilities managed by a party) or they may be different participants (e.g., step N is a farmer and step N+1 is an initial processing plant, etc.).

[0074] Once the input data is received in step 608, the data may be provided to at least one machine learning (ML) model in step 610. This analytical functionality in step 610 is described in detail with respect to input processor 300 in FIG. 3. As explained above, the input data may be compared against historical data of participants in the supply chain and similarly positioned participants in similar supply chains (e.g., peer participants). The comparative data may also be taken into account by the ML model in step 610. The ML model is equipped with at least one pattern recognizer that may identify certain trends and inputs that affect a product's CI score.

[0075] The output of the ML model analysis is an intelligent suggestion, generated in step 612. The intelligent suggestion may suggest to a participant in the supply chain (or a third-party operator / controller) certain manufacturing / processing changes that could potentially lower the CI score in the future. Specifically, for example, after a product has completed step N (or step N+1) in the supply chain and received its intermediate CI score, the ML model output may provide that participant in the supply chain with a suggestion to fine-tune its process to potentially obtain a lower CI score in future iterations through the supply chain.

[0076] Alternatively, the ML model may generate an intelligent suggestion regarding the next step in the supply chain. For example, after receiving data associated with the current CI score, the intelligent suggestion generated by the ML model in step 612 may suggest to the supply chain participant (and / or operator, controller, etc.) where to send the product next in the supply chain. For example, if multiple participants in the supply chain are available to receive and process the product in the next step in the supply chain, the system described herein may analyze and assess each of these participants and determine the participant that is most optimal for the current product based on the current product's CI score. In one example, participant A in the supply chain may be deploying cutting-edge environmentally friendly technology in its processing techniques, thereby likely obtaining a lower CI score than participant B, which may be applying fossil fuel-based machinery for processing. If the CI score of a product at a certain step in the supply chain is above a certain threshold, the ML model output may intelligently suggest that the product be provided to participant A (instead of participant B) for the next step in the supply chain. Conversely, if the current CI score is already sufficiently low, the ML model may intelligently suggest that the product be offered to participant B (instead of participant A) because, among other reasons, participant B may have cheaper processing costs than participant A, and although participant B would be more likely to increase his CI score, the increase (based on historical data from participant B) would not be enough to materially affect the product's final score.

[0077] Once the intelligent suggestions are generated in step 612, the suggestions may be provided in step 614 to participants in the supply chain, supply chain operators / controllers, sellers, buyers, and / or any other related parties and stakeholders that would benefit from receiving intelligent suggestions based on the current state of the supply chain and the current intermediate CI scores of certain products traversing the supply chain.

[0078] FIG. 7 illustrates an example environment for automatically generating and tracking CI scores. Environment 700 includes a farm 702, a storage bin 704, a processing plant 706, and a dock 708. In the example environment illustrated in FIG. 7, inputs at the farm include fertilizer, pesticides, fuel, and tillage. Each of these inputs at the farm 702 has an associated CI score. These CI scores may be predefined as products (or processes) to be used at the farm 702. For example, the end product fertilizer used by the farm may have received a final CI score during its manufacturing process. This final CI score may be referred to herein as the first step in the supply chain.

[0079] Additionally, in farms 702, different "farms" may have different calculations based on soil variances, fuel availability, tillage variances, etc. In some embodiments, multiple farms may receive different CI scores based on each individual farm's unique inputs (e.g., fertilizer, pesticides, fuel, tillage, etc.). This is illustrated by the grouping of farms 2, 3, 4... below the initial farm 702.

[0080] Once a product (e.g., a bulk of corn) is harvested and placed in a storage bin, an aggregate CI score may be assigned to the bin (or in an alternative scenario, assigned directly to the bulk of corn to prevent unauthorized substitution of actual goods in the bin to manipulate CI scores in the supply chain), which is reflected in bin 704. Bin 704 shows a single CI score assigned to a product, containing inputs such as fertilizer, pesticides, fuel, etc. Similarly, for farms 2-4, etc., the product may receive an aggregate CI score at the bin stage.

[0081] Following bin 704 (e.g., a bulk of corn), the product is then transported to a processing plant 706. At the processing plant 706, additional inputs such as gas, electricity, water (H2O), etc. are attributed to the production of the product. These inputs are measured and analyzed in determining a derived CI score from the processing plant for the fuel produced at a given point in time. As explained above, the CI score formula may consider different factors, such as the amount of water used by the processing plant, whether machinery is powered via gas or electricity, etc., in determining the CI score for that particular step in the supply chain.

[0082] After a product (e.g., corn) is processed in the processing plant 706, each of the final products that may be produced may receive an individual CI score. For example, co-products / by-products of corn processing may be ethanol alcohol, isobutanol, isooctane, jet fuel, DDG (dried distillers grains, i.e., high protein feed), oil, etc. Each of these products has unique processing requirements applied in the processing plant 706. Therefore, each of these by-products will be associated with a unique CI score based on how they are produced. In some examples, the CI score may also indicate the degree to which the by-product is ecologically friendly when consumed. For example, ethanol may have a lower CI score compared to jet fuel because burning ethanol-based gasoline produces fewer CO2 emissions than burning jet fuel. In other instances, ethanol may have a higher CI score than jet fuel.

[0083] Additionally, the CI score of each co-product and / or by-product (ethanol, isobutanol, isooctane, etc.) may be verified using a checksum function that adds and sums the intermediate CI scores together. For example, the final CI score may be the sum of each intermediate CI score assigned to the product throughout each step in the supply chain. Specifically, the CI scores associated with each component input at farm 702 may be summed to the CI score at bin 704. The aggregate intermediate CI score at bin 704 may then be added to the CI score associated with the amount of gas, electricity, water, etc. utilized at processing plant 706. In other examples, each step in the supply chain may produce its own additive CI score that will be summed at the final supply chain step to obtain the final CI score. In this case, the checksum function can reference the previous CI scores (stored as blocks in the blockchain) and check that the final CI score is the sum of all previous intermediate CI scores. Finally, a sustainability certificate may be issued that describes (and guarantees) the carbon footprint of the fuel product.

[0084] FIG. 8 illustrates example inputs and outputs used to automatically generate and track CI scores along a supply chain. Environment 800 is an example supply chain illustrating processing steps for corn and its potential co-products and by-products. As described above, each discrete step in the supply chain may be assigned a CI score (intermediate CI score). The final co-product / co-product may receive a final, validated CI score, which may be verified by applying a checksum function (described in FIG. 7) to sum the previous CI scores, which are stored as blocks on the blockchain. Here, in environment 800, the initial inputs include water, energy, nutrients, and pesticides. The initial input co-product may be savings from reduced tillage for corn cultivation. The savings from reduced tillage may lead to a lower CI score for the corn cultivation step in the supply chain illustrated in FIG. 8. Following the corn cultivation step, the corn, in this example, is then placed in bins and transported to a production facility. In an alcohol production facility, more water and more energy may be added as inputs to processes in the supply chain. Exemplary co-products from the alcohol production step may be corn oil, dried distillers grains (DDGS), isobutanol, ethanol, etc. Each co-product may be assigned a CI score based on the sum of previous CI scores from previous steps in the supply chain. In an example from environment 800, one of the products from the production step is isobutanol, which may be used in transportation. Isobutanol may also serve as a feedstock for producing hydrocarbon fuels and other chemical products. Additionally, other products from the production step in the supply chain may be sent to a hydrocarbon conversion processing step in the supply chain. Again, at this step, more water and energy may be input to the step.The output of the hydrocarbon conversion step may be a hydrocarbon fuel such as jet fuel, gasoline, diesel, and bunker fuel, and the hydrocarbon fuel product will be assigned a CI score that can be verified and audited by adding together previous intermediate CI scores to obtain a final verified CI score for the final product (e.g., jet fuel). In other exemplary aspects, the chemical by-products may include isobutylene, paraxylene, isooctane, and / or other hydrocarbon-based chemical products.

[0085] As mentioned above, the CI scores may be stored on the blockchain and may be fully auditable by viewing the blockchain ledger of a node that points to a reference node containing data associated with the intermediate CI score.

[0086] FIG. 9 illustrates an example state diagram used to automatically generate and track CI scores. Environment 900 illustrates different states of different participants / actors in an example supply chain (e.g., the supply chain illustrated in FIG. 8). In this example of FIG. 9, two farm states are displayed: farm state 902 and farm state 904. Each farm state includes objects such as identifiers, product yields, moisture content, seeding material, fertilizer pesticides, other fertilizers, pesticides, energy consumption, and total emissions, among other objects. Each of these objects is used as an input to the CI score calculation formula. Any asset (e.g., output), such as fuel-related, biogas, wind, solar, hydrogen, water, farm-related (e.g., fertilizer type, herbicides, pesticides, internal farm life cycle optimization, water use, groundwater protection, etc.), and / or chemical / material assets, may be tracked through the distributed ledger technology systems and methods described herein. For example, a higher totalEmissions object may increase the CI score of FarmState 902, while a lower totalEmissions object in FarmState 904 may decrease the CI score. As depicted in FIG. 9, the state of each participant in the supply chain may change over time. For example, if a farm upgrades its machinery or cultivation processes, FarmState 902 may be updated to FarmState 904. Each state may have unique properties that reflect its current state. Once a new state is created, it may contain a list of identifiers to associate with the linked states. For example, PlantState may contain a list of identifiers from which a product (e.g., corn) was harvested, and the product may have a source identifier that points back to a previous state.

[0087] As a product is transported and processed from step to step in the supply chain, more states of each participant are recorded and linked together. For example, when a product is delivered from a farm to a shipping company, a delivery state (e.g., CornDeliveryState) may be created. The CornDeliveryState data block may include objects such as an ID, origin, CI score, timestamp, and owner. In one exemplary aspect, when corn moves from one step (e.g., farm) to the next step (e.g., shipper) in the supply chain, a CI score is updated and / or assigned. As illustrated in FIG. 9 , CornDeliveryState displays the first time a CI score was assigned to the product. The CI score for each delivery state may vary depending on the input data received from the farm state. Similarly, the plant state reflects the combined state of a batch of product in this exemplary environment 900. For example, in a processing plant, the processing plant may combine multiple CornDeliveryStates into a single PlantState because the processing of this product will occur in large quantities of corn (hence multiple CornDeliveryStates). Following the processing steps in the plant, by-products may be created, each having a ProductState that points back to the PlantState. Based on the processing inputs in the plant and the information received from the PlantState, a CI score can be derived for the ProductState. In some examples, the ProductState may be the final validated product that constitutes the final CI score.

[0088] With respect to the overall architecture, the state of each participant / stakeholder in the supply chain may be represented as a block in the blockchain. Each state may be a block that is added to the blockchain that is accessible by participants in the supply chain and end customers who wish to verify the authenticity and accuracy of the final CI score (and ultimately, the value of the CI token). As a participant's state is updated, a new block may be added to the blockchain that points back to the previous state so that other participants in the supply chain (e.g., shipping companies, processing plants, etc.) know to read data from the most recent block in the blockchain associated with that particular participant in the supply chain. For example, one way this may be implemented programmatically is by checking whether a block has a forward pointer. If no forward pointer is present, the current block is the most recent block, i.e., the most recent state of the participant in the supply chain.

[0089] In some example aspects, each state may represent a block in the blockchain. When a verifier / requester wishes to verify the CI score of an end product, the verifier / requester may receive not only the confirmed CI score (which is one of the properties of the state) but also each of the other properties related to that state and referenced states captured by other blocks in the blockchain (i.e., linked to the current state). For example, the verifier may first receive data from ProductState indicating the CI score and other properties associated with ProductState. The verifier may then choose to analyze a previous state by following a back-pointer from ProductState to PlantState and receiving property data from PlantState. From there, the verifier may receive data from other available states, including CornDeliveryState and FarmState. This example is not limiting and may be extrapolated to other industries and products that utilize multi-step supply chains. At each step in the supply chain, a state is captured, the CI score is one property of that state, and the property serves as an input in calculating subsequent CI scores to be recorded in that state.

[0090] FIG. 10 illustrates an example environment from which data is captured to automatically generate and track CI scores. FIG. 10 illustrates another example environment 1000 showing different steps in a supply chain and how participants in the supply chain can communicate with each other, verify each other's CI scores, and produce updated CI scores as products traverse through the supply chain. For example, a farmer may initially enter information locally into database 1002. This information may be utilized by the system described herein to create an initial FarmState (as illustrated in FIG. 9 ). The FarmState may be created and propagated throughout the network to other participants in the supply chain via blockchain network 1004. A copy of the FarmState may also be accessed via a central database / server 1006, upon which application programming interfaces (APIs) and distributed ledger technology (DLT) middleware (e.g., DeFi applications) may run. For example, a truckload participant in a supply chain may desire to access FarmState information regarding a particular product received from a farmer. To receive this information and verify the product's initial CI score, the truck scale participant may access the blockchain network 1004 via a DeFi application interface, which also utilizes a central (and distributed) database / server 1006. The system may return a copy of FarmState to the truck scale participant, who may then input their processing information, and a new state (e.g., TruckScaleState) based on the information from FarmState and the truck scale participant's input data may be created.

[0091] As illustrated in FIG. 10 , input data constituting the state of each participant in the supply chain may be obtained via a web application interface (e.g., a user interface of a DeFi application running on a blockchain network, e.g., network 1004). In other embodiments, input data may be received from IoT devices attached to machinery, storage containers, pipes, etc., which, in one embodiment, measure carbon emissions. These IoT devices automatically measure and report data to a central system, which then uses the data to create the state of participants in the supply chain. Furthermore, as described above, each state may be updated for each product flowing through the supply chain. States may change as frequently or infrequently as participants desire. For example, a farmer may run out of ecological fertilizer for one day, thus forcing them to apply a less “environmentally friendly” fertilizer. This change (albeit only for one day) may be captured in an updated state data block that is ultimately considered in the final calculation of the CI score.

[0092] 10 may also include a third-party verifying entity, which is a node in the blockchain network 1004. The third-party verifying entity may act as a notary (i.e., an independent signer) that may establish and verify certain transactions and submissions to the blockchain. Such third-party verification may prevent double-spending (e.g., an entity may attempt to double-spend CI tokens, a participant in the supply chain may attempt to forge an intermediate CI score by copying a lower CI score from a previous block and attempting to use information from that block in the supply chain rather than the previous block that displays a higher intermediate CI score, etc.).

[0093] FIG. 11 illustrates an example environment for automatically generating and validating CI scores. The example environment 1100 of FIG. 11 shows the same supply chain as that from FIG. 10. The environment 1100 also illustrates a Dapp (decentralized application) 1102 that an end customer can use to pay a supplier. The Dapp 1102 may be used to query a blockchain (such as the blockchain network 1004) to verify a product's final CI score. If the CI score is verified (e.g., via a CI score certificate 1106 produced by validating the CI score on the blockchain), the supplier may receive money from the end customer. As described above, this transaction may be automatically executed via a smart contract. For example, the terms of the smart contract may stipulate that once a final product is validated as having a CI score, certain escrowed funds from the buyer may be transferred to the seller. The CI score validation process may be done via querying the blockchain and analyzing each state data block leading up to the final product (i.e., auditing the evolution of the CI score from when the product is first grown to its final processing step prior to becoming the final product for the buyer).

[0094] FIG. 12 illustrates an example environment for generating CI tokens via CI scores. After a co-product is validated as having a CI score, the validated CI score (e.g., in the form of a certificate generated from a blockchain) may be used to create CI tokens, which may represent the value of carbon offset credits that can be traded. For example, after money is transferred from buyer to seller due to the validation of a product's CI score, there is now a verified, immutable record that certain carbon emissions were avoided by utilizing ecologically responsible processes throughout the supply chain. The CI score (and the accompanying state data block with properties) may reflect this. CI tokens may be created that track CI scores and capture the value of the avoided carbon emissions as a co-product of purchasing a product with a low CI score. This is similar to carbon credits that can be bought and sold between parties. Preferably, CI tokens are fungible tokens, so they are all the same but divisible into smaller units and can be easily exchanged.

[0095] Specifically, CI tokens may be sold to businesses that emit a certain level of carbon emissions and wish to pay for those emissions via CI tokens. CI tokens are a store of measurable and verifiable emissions reduction value, which may allow an entity to emit a certain amount of carbon emissions if the entity can pay for the carbon emissions via CI tokens. Essentially, CI tokens are tradable cryptocurrencies that allow their holders to emit a certain amount of carbon emissions that is equivalent to the value of the CI tokens. CI tokens may also function as a common reference currency between market sectors (e.g., facilitating transactions between agricultural entities and electricity providers).

[0096] A buyer of an eco-conscious product may pay a premium price for a product with a verified low CI score. To offset this premium paid, the buyer may also receive CI tokens, which may be sold by the buyer to other entities wishing to emit excess carbon emissions that they would otherwise not be permitted to emit under regulations and laws in a certain jurisdiction. Thus, a lower CI score leads to a higher value of CI tokens.

[0097] Figure 13 illustrates an exemplary environment for generating and trading CI tokens, using, at least in part, the Corda blockchain development platform available from R3 Ltd. In this specific implementation, the environment 1300, referred to as "Verity," combines a large-scale, transparent, voluntary carbon credit market with a supply management system that ensures the reliability of low, neutral, and / or negative carbon intensity of materials production through immutable, automated audits using blockchain technology. The Verity blockchain-based system provides a single source of truth across the production value chain, and each economic actor interacts with other economic actors within the system. This interaction allows all parties to record and manage agreements between themselves in a secure, consistent, reliable, private, and auditable manner.

[0098] In Verity, each participant can be a farmer, plant, distributor, etc. Each participant runs a node within the Corda application 1302. Each node communicates via APIs to external data sources and reads production data to calculate a CI score at each stage in the supply change. Each Corda node may also receive algorithmic information related to the GREET model (greenhouse gas, regulated emissions, and energy use of a technology) to calculate a CI score.

[0099] Producers may calculate their CI scores and retrieve the value of their sustainable practices via a marketplace that may be referred to as the “Verity Carbon Marketplace.” CI scores may be transmitted and stored in database 1304, which is then communicated to Verity Token Solutions 1306. Participants may tokenize their CI scores via Verity Token Solutions 1306. Such tokens may be Direct Carbon Value (DCV) tokens minted within the Verity platform based on the calculation of CI scores and tradeable among network participants. Verity tokens may ultimately be traded and exchanged on cryptocurrency exchange platform 1308. Because Verity source data is extracted directly from the supply chain of each economic actor in the Verity network, there is certainty associated with each carbon offset (i.e., no double counting).

[0100] 14 illustrates an example of a suitable operating environment in which one or more of the present embodiments may be implemented. This is only one example of a suitable operating environment and is not intended to suggest any limitation as to scope of use or functionality. Other well-known computing systems, environments, and / or configurations that may be suitable for use include, but are not limited to, personal computers, server computers, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, programmable consumer electronics devices such as smartphones, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

[0101] In its most basic configuration, the operating environment 1400 typically includes at least one processing unit 1402 and memory 1404. Depending on the exact configuration and type of computing device, the memory 1404 (which stores, among other things, information related to the device, the blockchain network, payment settings, asset balances, CI score formulas, ML-based suggestions for reducing CI scores, and instructions for implementing the methods disclosed herein) may be volatile (e.g., RAM), non-volatile (e.g., ROM, flash memory), or some combination of the two. This most basic configuration is illustrated in FIG. 14 by dashed line 1406. Additionally, the environment 1400 may also include storage devices (removable 1408 and / or non-removable 1410), including, but not limited to, magnetic or optical disks or tape. Similarly, the environment 1400 may also have input devices 1414, such as a keyboard, mouse, pen, voice input, etc., and / or output devices 1416, such as a display, speakers, printer, etc. Also included within the environment may be one or more communication connections 1412 such as Bluetooth, WiFi, WiMax, LAN, WAN, point-to-point, etc.

[0102] The operating environment 1400 typically includes at least some form of computer-readable media. Computer-readable media may be any available media that can be accessed by the processing unit 1402 or other devices that comprise the operating environment. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures (e.g., blockchain), program modules, or other data. Computer storage media includes RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVDs) or other optical storage devices, magnetic cassettes, magnetic tape, magnetic disk storage devices, or other magnetic storage devices, or any other tangible medium that can be used to store the desired information. Computer storage media does not include communication media.

[0103] Communication media embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media.

[0104] The operating environment 1400 may be a single computer (e.g., a mobile computer) operating in a networked environment using logical connections to one or more remote computers. The remote computers may be personal computers, servers, routers, network PCs, peer devices, IoT measurement devices (e.g., carbon emissions measurement devices), or other common network nodes, and typically include many or all of the elements described above, as well as others not so mentioned. Any of these operating devices may be part of a larger blockchain network (such as that illustrated in FIG. 2). The logical connections may include any method supported by available communication media. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet.

[0105] The current implementation of the teachings herein has been developed, in part, using the open-source Corda enterprise blockchain platform for supply-side management (SSM) components. Corda offers an attractive development platform due to its expertise in interconnecting IoT devices or process information (PI) systems to record, analyze, and monitor real-time information. Additionally, Corda works with standard REST APIs for plant control systems. Another attractive feature of Corda is its improved ability to establish tokens within their platform. This makes it a more attractive platform at this time than others, such as Flyperledger Fabric, which has deprecated its token SDK. Another advantage of using Corda is its use of an unspent transaction output (UTXO) model, in which each state on the ledger is immutable. That said, those skilled in the art will recognize and understand that other open-source or proprietary blockchain architectures and protocols, or combinations thereof, may be utilized to achieve the benefits described herein.

[0106] Aspects of the present disclosure are described above with reference to, for example, block diagrams and / or operational illustrations of methods, systems, and computer program products according to aspects of the present disclosure. The functions / acts noted in the blocks may occur out of the order shown in any flowchart. For example, two blocks shown in succession may, in fact, be executed substantially in parallel, or the blocks may sometimes be executed in the reverse order, depending on the functionality / acts involved.

[0107] The description and illustration of one or more aspects provided herein are not intended to limit or restrict the scope of the disclosure as claimed in any way. The aspects, examples, and details provided herein are deemed sufficient to convey the invention and to enable others to make and use the best mode of the claimed disclosure. The claimed disclosure should not be construed as limited to any aspect, example, or detail provided herein. Various features (both structural and methodological), whether shown and described in combination or separately, are intended to be selectively included or omitted to produce embodiments with a particular set of features. While description and illustration of the present application have been provided, those skilled in the art may envision variations, modifications, and alternative aspects that fall within the spirit of the broader aspects of the general inventive concept embodied herein without departing from the broader scope of the claimed disclosure.

[0108] From the foregoing, it will be appreciated that specific embodiments of the invention have been described herein for purposes of illustration, but that various modifications may be made without departing from the scope of the invention. Accordingly, the invention is not limited except as by the appended claims.

Claims

1. 1. A system comprising: at least one processor; a memory coupled to the at least one processor, the memory comprising computer-executable instructions that, when executed by the at least one processor, receiving at least one contract term, said contract term defining an algorithm for calculating a carbon intensity (CI) score; receiving input data associated with at least one participant in a supply chain; determining a CI score based on the input data associated with the at least one participant and the algorithm defined by the at least one term of contract; recording the CI score so that the recorded CI score remains constant; a memory; A system comprising:

2. 1. A system comprising: at least one processor; a memory coupled to the at least one processor, the memory comprising computer-executable instructions that, when executed by the at least one processor, receiving at least one contract term, said contract term defining an algorithm for calculating a carbon intensity (CI) score; receiving input data associated with at least one participant in a supply chain; determining a CI score based on the input data associated with the at least one participant and the algorithm defined by the at least one term of contract; recording the CI score such that the recorded CI score remains constant; applying at least one machine learning model to the CI scores; generating at least one suggestion for reducing the CI score; a memory; wherein the at least one suggestion is a suggestion to the at least one participant to reduce the CI score in a future iteration of the supply chain.

3. 1. A system comprising: at least one processor; a memory coupled to the at least one processor, the memory comprising computer-executable instructions that, when executed by the at least one processor, receiving at least one contract term, said contract term defining an algorithm for calculating a carbon intensity (CI) score; receiving input data associated with at least one participant in a supply chain; determining a CI score based on the input data associated with the at least one participant and the algorithm defined by the at least one term of contract; recording the CI score such that the recorded CI score remains constant; applying at least one machine learning model to the CI scores; generating at least one suggestion for reducing the CI score; a memory; wherein the at least one suggestion is a suggestion to a second participant in the supply chain to reduce the CI score, the second participant following the at least one participant in the supply chain.

4. 1. A system comprising: at least one processor; a memory coupled to the at least one processor, the memory comprising computer-executable instructions that, when executed by the at least one processor, receiving at least one contract term, said contract term defining an algorithm for calculating a carbon intensity (CI) score; receiving input data associated with at least one participant in a supply chain; determining a CI score based on the input data associated with the at least one participant and the algorithm defined by the at least one term of contract; recording the CI score such that the recorded CI score remains constant; applying at least one machine learning model to the CI scores; generating at least one suggestion for reducing the CI score; a memory; wherein the at least one suggestion is a suggestion for selecting at least one subsequent processing facility in the supply chain based on the CI score exceeding a CI score threshold.

5. The system of any one of claims 1 to 4, wherein the input data comprises at least one agricultural practice.

6. The system of any one of claims 1 to 4, wherein the input data comprises at least one chemical production practice.

7. 5. The system of claim 1, wherein the input data comprises at least one of a location, a process, a financial constraint, a regenerative agricultural practice, a green energy input, a water usage measurement, and a measurement of at least one energy source.

8. The system of any one of claims 1 to 4, wherein the CI score is further determined by reference to at least one regulatory body's CI score calculation.

9. The steps include: generating a CI token based on the CI score; storing the CI token such that the stored CI token is immutable; The system of any one of claims 1 to 4, further comprising:

10. The steps include: applying said CI tokens to offset at least one instance of carbon emissions; Burning the CI tokens based on the application of the CI tokens; The system of claim 9 further comprising:

11. 5. The system of claim 4, wherein the at least one downstream processing facility is a renewable energy powered processing facility if the CI score exceeds the CI score threshold.

12. 5. The system of claim 4, wherein the at least one downstream processing facility is a fossil fuel-powered processing facility if the CI score does not exceed the CI score threshold.

13. The system of claim 2 , wherein the at least one suggestion comprises at least one suggestion associated with a shipping method, a fuel selection, a fertilizer brand, and a pesticide application rate.

14. 3. The system of claim 2, wherein the at least one machine learning model utilizes at least one of the following algorithms: linear regression, logistic regression, linear discriminant analysis, classification and regression trees, naive Bayes, k-nearest neighbors, learning vector quantization, neural networks, support vector machines (SVMs), bagging and random forests, and AdaBoost.

15. 1. A method comprising: a processor receiving at least one contract term, the contract term defining an algorithm for calculating a carbon intensity (CI) score; receiving input data associated with a stage in a supply chain; the processor calculating a CI score based on the input data and the algorithm defined by the at least one contract term; the processor assigning the CI score to the stage; the processor storing the CI scores such that the stored CI scores are constant; A method comprising:

16. 1. A method comprising: a processor receiving input data associated with a stage in a supply chain; the processor calculating a carbon intensity (CI) score based on the input data; and the processor assigning the CI score to the stage; storing the CI scores such that the stored CI scores are constant; the processor comparing the CI score to a threshold CI score; generating at least one intelligent suggestion associated with lowering the CI score based on a comparison of the CI score to the threshold CI score; wherein the at least one intelligent suggestion is a suggestion to a participant to reduce the CI score in a future iteration of the supply chain.

17. 1. A method comprising: a processor receiving input data associated with a stage in a supply chain; the processor calculating a carbon intensity (CI) score based on the input data; and the processor assigning the CI score to the stage; storing the CI scores such that the stored CI scores are constant; the processor comparing the CI score to a threshold CI score; generating at least one intelligent suggestion associated with lowering the CI score based on a comparison of the CI score to the threshold CI score; wherein the at least one proposal is to a second participant subsequent to the participant in the supply chain, the second participant having not yet received the product in the supply chain.

18. The method of claim 15 , wherein the input data comprises data regarding participants in the supply chain and products being processed in the supply chain.

Images