System and method for automatic carbon intensity calculation and tracking

Abstract

To provide carbon intensity tracking, a block chain system, and a smart contract.SOLUTION: The embodiments of the present disclosure describe systems and methods for automatically generating and tracking a carbon intensity (CI) score assigned to a particular product when a product traverses through discrete steps in a processing plant and a supply chain. In some embodiments, an intermediate CI score may be assigned to the product when the intermediate CI score 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 a block chain such that the CI scores are independently verifiable and auditable.SELECTED DRAWING: None

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims the benefit and priority of U.S. Provisional Application No. 63 / 180,309, filed Apr. 27, 2021, the disclosure of which is incorporated herein by reference.

[0002] This disclosure relates to the fields of carbon intensity tracking, blockchain systems, and smart contracts.

Background Art

[0003] Entities today trying to reduce their carbon footprints struggle to measure and verify the environmental impact of their corporate activities from headquarters to global operations and supply chains. For example, customers desiring to purchase environmentally - conscious products often have to rely on the word of suppliers because the ability to transparently audit and verify the environmental impact of a product is difficult with today's climate accounting technologies. As the number of companies making climate pledges continues to grow, holding these companies accountable is becoming increasingly important.

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

[0005] Collecting data from different suppliers, i.e., from energy use and potentially carbon, and using this to determine emissions is difficult due to the lack of a single set of guidelines for comprehensive criteria regarding carbon accounting or for how to audit, verify, and report carbon emissions throughout the entire supply chain. One current method of climate accounting involves carbon credits, which involves explaining changes in the raw materials, manufacturing processes, and handling of products that affect 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 the global warming potential to convert carbon dioxide to an equivalent value). In a cap-and-trade system, companies are allocated a certain number of carbon credits. If a company is going to emit more greenhouse gases than their cap, the company must purchase carbon credits to offset their excess production of greenhouse gases. Carbon credits can be purchased directly from companies that are producing below their cap or from exchanges that aggregate excess carbon credits. Another carbon market mechanism can include scenarios where entities are required to purchase carbon credits (as required, for example, by the Regional Greenhouse Gas Initiative (RGGI)). Such carbon credit markets can exist in compliance and non-compliance (i.e., voluntary) environments, and some carbon tracking is done against internal performance criteria as opposed to regulated standards.

[0006] Carbon credits not purchased from companies using less than their upper limits are obtained from projects that recover greenhouse gases from the atmosphere or projects that produce fewer greenhouse gases than current alternatives. Examples of projects that produce fewer greenhouse gases than typical methods are usually projects that are powered by burning coal but where the coal has been replaced by an energy source that does not involve greenhouse gas emissions such as solar power generation. Examples of projects that recover greenhouse gases from the atmosphere are carbon capture projects such as forest afforestation. However, one issue with carbon credits and carbon offsets is ensuring that the purchase of a carbon credit is actually the purchase of a carbon credit that has not already been purchased by another entity. Since reliable end-to-end and fully auditable solutions do not exist today, double-purchases of carbon credits occur frequently. Another issue is properly verifying claims associated with carbon credits, such as determining the date of origin, location, input technology, and other characteristics of the carbon credit.

[0007] Existing methods for measuring current carbon emissions are the carbon intensity (CI) score, or as it is referred to 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 a crop and processing it into biofuel. Currently, in some jurisdictions, the crops used to produce biofuel at a particular plant are aggregated and assigned a CI score (e.g., g / MJ (megajoule), g / TJ (terajoule), etc.) regardless of differences in growing methods. Differences in growing methods and transportation are not considered. As a result, carbon credits derived from the CI score may not accurately reflect reduced (or not reduced) carbon emissions. For example, little documentation remains to determine whether a CI score from a certain crop producer accurately reflects that producer's production method.

[0008] Another problem related to carbon credits is the inefficiency in exchanging / trading carbon credits. Buyers and sellers typically cannot verify and confirm the true value of carbon credits and, at the same time, audit the value of carbon credits (i.e., determine that the carbon credits are derived from a legitimate environmentally conscious and carbon - considered process). Buyers and sellers also typically have to wait several days until those carbon credits are transferred and settled. Thus, there is a need to more efficiently and transparently verify the value of carbon credits and transfer this among entities.

[0009] One aspect of the present application is blockchain - based technology and, 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 a previous block, a timestamp, and transaction data (e.g., each block may contain many transactions). By design, a blockchain is 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 can be added to the blockchain and each additional block (i.e., “change”) can be recorded on the blockchain. A blockchain can be managed by a peer - to - peer network of nodes (e.g., devices) that collectively adhere to a consensus protocol for validating new blocks. Once recorded, the transaction data within a given block cannot be retroactively modified without modifying all previous blocks, which would require collusion of a majority of the network nodes.

[0010] A public permissionless blockchain is an append-only data structure maintained by a network of nodes that do not fully trust each other. A permissioned blockchain is a type of blockchain that is controlled, for example, by a central authority and / or other nodes in the network in a manner that access to the network of nodes is restricted. All nodes in a blockchain network agree on a sequenced set of blocks, and each block may contain one or more transactions. Thus, a blockchain can be viewed as a log of sequenced transactions. One particular type of blockchain (e.g., Bitcoin) stores coins as a system state that is shared by all nodes of 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. Additionally, a public blockchain may include full nodes, which may contain the entire transaction history (e.g., the log of transactions), and nodes that may not contain the entire transaction history. For example, Bitcoin includes thousands of full nodes at all nodes connected to Bitcoin.

[0011] With the emergence of decentralized blockchains, decentralized finance, i.e., "DeFi", has emerged. DeFi is a general term for decentralized and freely participating financial infrastructures, and various cryptocurrency-based financial applications are operating. What makes these applications decentralized is that they are not managed by a central authority. Instead, the rules of these applications are described in code, and the code is publicly available for anyone to audit. These rules described in the 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 regarded as a class of second-layer decentralized applications (e.g., DApps) that run on the blockchain.

Summary of the Invention

Means for Solving the Problems

[0012] The present invention provides, for example, the following. (Item 1) A system comprising: at least one processor; and a memory coupled to the at least one processor, the memory comprising computer-executable instructions which, when executed by the at least one processor, perform the steps of: receiving at least one contractual condition, the at least one contractual condition being in the form of program code; constructing at least one smart contract on a blockchain based on the at least one contractual condition; 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 associated with the at least one participant and the at least one smart contract; 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 state; and generating at least one proposal for reducing the at least one CI score. A memory for performing the steps comprising: A system. (Item 2) The system according to Item 1, further comprising the step of recording at least one state of a farm or production facility on the blockchain; and the step of recording at least one measurement of the number of acres of the farm or the production facility on the blockchain. The system according to Item 1, further comprising: (Item 3) The system according to Item 1, wherein the input data comprises at least one agricultural practice. (Item 4) The system according to Item 1, wherein the input data comprises at least one chemical production practice. (Item 5) The input data comprises at least one of location, process, financial constraints, regenerative agricultural practices, green energy input, measurements of water usage, and measurements of at least one energy source, for the system of item 1. (Item 6) The CI score is further determined by referring to the CI score calculation of at least one regulatory agency, for the system of item 1. (Item 7) The step further comprises generating a CI token based on the CI score, and storing the CI token on the blockchain for the system of item 1. (Item 8) The step further comprises applying the CI token to offset at least one instance of carbon emissions, and incinerating the CI token based on the application of the CI token for the system of item 7. (Item 9) The at least one proposal is a proposal to at least one participant in the future iteration of the supply chain to reduce the at least one CI score, for the system of item 1. (Item 10) The at least one proposal is a proposal to a second participant in the supply chain to reduce the at least one CI score, and the second participant follows the at least one participant in the supply chain, for the system of item 1. (Item 11) The at least one proposal is a proposal to select at least one subsequent processing facility in the supply chain based on the at least one CI score exceeding a CI score threshold, for the system of item 1. (Item 12) The at least one subsequent processing facility is a processing facility powered by renewable energy if the at least one CI score exceeds the CI score threshold, for the system of item 11. (Item 13) The at least one subsequent processing facility is a processing facility powered by fossil fuel if the at least one CI score does not exceed the CI score threshold, for the system of item 11. (Item 14) The at least one proposal comprises at least one proposal associated with shipping method, fuel selection, fertilizer brand, and pesticide application rate, for the system of item 9. (Item 15) The system according to 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 neighbor, learning vector quantization, neural networks, support vector machines (SVM), bagging and random forests, and AdaBoost. (Item 16) 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, wherein the at least one machine learning model is 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 the intermediate CI score to the at least one stage; comparing the intermediate CI score with a threshold CI score; generating at least one intelligent suggestion associated with reducing the intermediate CI score based on the comparison between the intermediate CI score and the threshold CI score. A method comprising the above steps. (Item 17) The method according to item 16, wherein the at least one stage comprises data related to at least one current participant in the supply chain and at least one product being processed in the supply chain. The method according to item 16. (Item 18) The method according to item 17, wherein the at least one intelligent suggestion is a suggestion to at least one participant for reducing the intermediate CI score in a future iteration of the supply chain. (Item 19) The method according to item 17, wherein the at least one suggestion is a suggestion to a second participant following the at least one participant in the supply chain, and the second participant has not yet received the at least one product in the supply chain. (Item 20) A computer-readable medium storing non-transitory computer-executable instructions that, when executed, cause a computing system to receive at least one contractual condition, wherein the at least one contractual condition is in the form of program code, construct at least one smart contract on a blockchain based on the at least one contractual condition, receive input data associated with a plurality of stages in a supply chain, generate a plurality of states associated with the input data from each of the plurality of stages, record each of the plurality of states on the blockchain, analyze each of the plurality of states using at least one machine learning model, wherein the at least one machine learning model is trained to identify a plurality of characteristics that increase and decrease a carbon intensity (CI) score, calculate a plurality of intermediate CI scores based on the analysis of each of the plurality of states on the blockchain, record each of the intermediate CI scores on the blockchain, generate an aggregated CI score based on the plurality of intermediate CI scores, generate a CI token based on the aggregated CI score, wherein the CI token is tradable in at least one carbon credit market, A computer-readable medium that causes the steps for generating a CI token including the above to be implemented. Aspects disclosed herein have been made with respect to these and other general considerations. Also, relatively specific problems may be discussed, but it should be understood that the examples should not be limited to solving the specific problems identified in the background or elsewhere in this disclosure.

Brief Description of the Drawings

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

[0014]

Figure 1

[0015]

Figure 2

[0016]

Figure 3

[0017]

Figure 4

[0018]

Figure 5

[0019]

Figure 6

[0020]

Figure 7

[0021]

Figure 8

[0022]

Figure 9

[0023]

Figure 10

[0024]

Figure 11

[0025]

Figure 12

[0026]

Figure 13

[0027]

Figure 14

[0028] Detailed Description Various aspects of the present disclosure form part of this specification and are fully described below with reference to the accompanying drawings, which show specific exemplary aspects. However, the different aspects of the present disclosure may be implemented in many different forms and should not be construed as limited to the aspects described 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. The aspects may be practiced as a method, system, or device. Thus, the aspects may take the form of a hardware implementation, a completely software implementation, or an implementation 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. Additionally, the present application also describes exemplary embodiments for generating CI tokens having values derived from the CI scores. In yet further examples, the present application is directed to using at least one machine learning (ML) algorithm to generate dynamic and intelligent suggestions for reducing the CI score as a product moves through the supply chain.

[0030] In one example, a method for tracking CI scores associated with a particular crop using a distributed ledger is described. As the crop traverses through the supply chain, the CI score associated with the crop may be updated based on certain inputs such as the way the crop is harvested and the way the crop is processed into a final product, such as biofuel. Relevant information about the crop and the 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. Other examples may include utilizing biofuel for electricity and hydrogen. The information may be captured on a blockchain and the information may be input using devices (e.g., IoT devices) (e.g., by farmers, plant operators, processors, etc.). The CI score associated with a particular product (e.g., a batch of corn) evolves continuously along the supply chain and the CI score may become finalized in response to the delivery of the final product (e.g., jet fuel) to the customer. The finalized CI score may be captured in a certificate and stored on the blockchain. The certificate may then be used to generate an exchangeable CI token with a value directly correlated to the CI score recorded on the certificate. The CI token may retain its value unless the token is used / applied to offset actual carbon emissions. Once the CI token is applied to offset actual carbon emissions, the CI token may be "burned".

[0031] In some embodiments, an intermediate CI score may be calculated at a location in the supply chain. The CI score (e.g., an attribute) may be bought and sold independently of the underlying physical commodity (e.g., corn). For example, these intermediate CI scores may be combined and recombined at the time of final consumption or prior thereto. The intermediate CI score may be used as an input to a machine learning model for generating intelligent suggestions for reducing the CI score at the next or subsequent step in the supply chain. For example, if the intermediate CI score is unusually high for a particular location in the supply chain, the machine learning algorithm may propose an adjustment (e.g., using sunlight for electricity instead of fossil fuels) at the next step in the supply chain in an attempt to reduce the CI score or at least decelerate the increase of 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 energy sources and conventional energy sources in the plant depending on the current CI score of the product and the 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 propose the use of solar energy if the current plant in the supply chain is not equipped to use solar power generation). In other exemplary aspects, the systems and methods described herein can track the energy sources within a particular plant processing a commodity (e.g., corn). The energy sources may be tracked in terms of minutes, hours, etc. Such energy sources may comprise wind power, 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 intellectual proposals to previous participants in the supply chain. For example, if the CI score was unusually high at a location in the supply chain, the machine learning algorithm may propose certain optimization methods to past participants (or previous processes) such that they may implement these optimization methods in the future, which, in turn, would, if successful, reduce the CI score at that point in the supply chain. The lower the CI score, the higher the value that the generated CI tokens would have (i.e., an efficient market can drive the CI score lower). It should be understood that the teachings herein can be applied not only to achieve a lower CI score, but also to achieve a target CI range or to stay below a target CI threshold.

[0033] Figure 1 illustrates an example of a distributed system for automatically generating and tracking CI scores. The exemplary system 100 presented 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, 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 across the supply chain and the CI score associated with that particular product. The CI score may continuously evolve as the product continues to progress through the supply chain, and the CI score may be updated on a blockchain that can 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 the blockchain network and locally host a copy of the blockchain within local databases 110, 112, and / or 114. A DeFi application, configured such that client devices 102, 104, and / or 106 initiate (and / or interact with) it, may reside on the blockchain. 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 within the 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 imagery of a processing step), unmanned ground vehicles (e.g., to monitor a processing step of a certain machine used in the supply chain), etc.

[0035] In some exemplary 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 satellites) within 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 in remote servers 116, 118, and / or 120. In other embodiments, client devices 102, 104, and / or 106 may be configured to communicate with each other via a short-range communication protocol such as Bluetooth®.

[0036] Client devices 102, 104, and / or 106 may also be configured to automatically generate, track, and once determined, authenticate a CI score associated with a product in the supply chain by launching software that implements (and / or interacts with) a blockchain with at least one DeFi application. Further, client devices 102, 104, and / or 106 may be configured to launch software that uses at least one ML model having access to current processing techniques and input data for processing a particular product / raw material in the supply chain to generate intelligent suggestions for reducing the CI score. For example, the generation of intelligent suggestions may depend on information (such as agricultural techniques, plant operator energy sources, etc.) already stored on at least one blockchain and / or other conventional information storage locations such as databases. In some embodiments, the characteristics of each participant in the supply chain may be stored as a "state" within the blockchain, and the state of the participant may include an information identifier with values that can be accessed by the system to determine a particular CI score and / or predict future CI scores. The same state 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 implementing an intelligent suggestion (such as changing electricity in a factory from fossil fuel to sunlight) may record a new "state" regarding 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 information in the system via client devices 102, 104, and / or 106. The system may process that information and construct the "state" of that participant. The state of that participant may be stored remotely on servers 116, 118, and / or 120 and / or locally in databases 110, 112, and / or 114. The state profile may be stored as a block on the blockchain. Participants may observe the states 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 regulatory authority) verifying the state information of a participant in the supply chain. Access to such state methods may be provided via a DeFi application launched on the blockchain.

[0038] One or more smart contracts may also reside on a blockchain network. Copies of the smart contract may be stored locally in local databases 110, 112, and / or 114, and / or remotely at servers 116, 118, and / or 120. The smart contract may determine the amount that the end consumer pays for the end product based on the finalized CI score of the end product. For example, a consumer contracting 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 the payment between the supplier and the customer based on the finalized CI score. If the customer desired 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 CI score lower than expected, the customer may, in some embodiments, choose to pay a premium for the lower CI score product or not obtain ownership of the product (e.g., standard fuel purchase agreement). Assets to be transferred between the end customer and the supplier may be placed in escrow on the blockchain. For example, the smart contract may be a smart contract between a fuel supplier and an airline (customer). Based on the aggregated CI score associated with each unit of jet received by the airline, the airline's deposited assets may be automatically transferred to the jet fuel supplier based on certain conditions being met on the smart contract. For example, if the aggregated CI score is one point higher than expected, a certain amount of assets is deducted from the agreed 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 having access to at least one database of historical processing techniques that have been proven to reduce the CI score. For example, the database may comprise information regarding the average reduction in the CI score by transitioning from machines powered by fossil fuels to machines powered by hydropower. 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 exemplary aspects, client devices 102, 104, and / or 106 may be equipped to receive signals from input devices. The signals may be received on client devices 102, 104, and / or 106 via, among other media and protocols for transmitting / receiving signals, Bluetooth®, Wi-Fi, infrared, optical signals, binary. For example, a user may use mobile device 102 to query a DeFi application launched on a blockchain and receive updates regarding the current CI score of a product (e.g., a large quantity of corn) and the predicted CI score of a product based on future processing steps in the supply chain. A graphical user interface associated with the DeFi application may be displayed on mobile device 102, showing a CI score tracker and an expected value to be captured within a CI token after the CI score is finalized and authenticated.

[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 the system 100 of FIG. 1. In FIG. 2, network devices are interconnected and communicate with each other. In some embodiments, each device in the network has a copy of the blockchain (or at least a partial copy of the blockchain, e.g., a light node) because the blockchain is not controlled by any single entity but rather by the distributed system. In other embodiments, the blockchain is a permissioned blockchain that includes an access control layer, and some devices may be prevented or permitted from reading and writing certain information to the blockchain.

[0042] Specifically, in FIG. 2, mobile devices 202, 206, 210, and 214 are connected to laptops 204 and 212 and “smart” factories 208 and 216 (e.g., processing plants such as monitoring devices on machinery in the factory or IoT devices in a factory) within the distributed system 200. The devices depicted in FIG. 2 communicate with each other within the 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 the blockchain in the blockchain network, and the server may receive the query and produce blocks from a copy of the blockchain stored on the server. Laptop 204 may receive information located within the block (e.g., the current CI score, the predicted CI score, an ML-based proposal to lower the CI score, etc.). In short, the systems and methods described herein are implemented within a distributed architecture such as that shown in FIG. 2 and, in some embodiments, may be implemented on a single node within the distributed blockchain network.

[0043] Figure 3 illustrates an exemplary input processing system for implementing a system and method for automatically generating and tracking CI scores. The input processing system (e.g., one or more data processors) is capable of executing algorithms, software routines, and / or instructions based on processing data provided by various sources related to the generation and tracking of CI scores and the generation of intelligent suggestions to entities within the supply chain to reduce the CI score of a particular product. The input processing system can be a general-purpose computer or a dedicated special-purpose computer. According to the embodiment shown in Figure 3, the disclosed system can include a 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 communication 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 incorporate two or more of these modules and components into a single module and / or associate a portion of the functionality of one or more of these modules with different modules.

[0044] Memory 305 can store instructions for launching one or more applications or modules on processor 310. For example, in one or more embodiments, memory 305 may be used to store all or some of the instructions necessary to execute the functionality of data collection module 315, smart contract module 320, CI calculation module 325, ML proposal module 330, and communication module 335. Generally, memory 305 can include any device, mechanism, or incorporated 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 include, but is not limited to, any type of volatile memory, non-volatile memory, and dynamic memory. For example, memory 305 can be random access memory, a memory storage device, an optical memory device, a magnetic medium, a floppy (registered trademark) disk, magnetic tape, a hard drive, a SIMM, SDRAM, RDRAM, DDR, RAM, a SODIMM, EPROM, EEPROM, a compact disk, a 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, a local cache memory, a processor cache memory, a relational database, a flat database, and / or the like. Additionally, those skilled in the art will understand many additional devices and techniques for storing information that can be used as memory 305. In some exemplary aspects, memory 305 may store at least one database containing, for example, the current CI score for a particular product, a certain CI score threshold based on regulatory information (e.g., a CI score threshold for determining tax deductions in a particular region / state), a historical average CI score for a particular product, an average decrease or increase in CI score based on a certain processing technique, and the like.In other exemplary aspects, the memory 305 may store at least one copy of a blockchain with at least one DeFi application that runs on the blockchain. In yet other exemplary aspects, the memory 305 may store assets (e.g., fungible or non-fungible CI tokens, stablecoins, etc.) that can be submitted to the blockchain via a DeFi application. In other aspects, the memory 305 may be configured to store at least one current CI score and a predicted supply chain path, and the predicted supply chain path and the current CI score are used as inputs for generating an intelligent ML-based proposal for reducing the CI score as the product traverses the supply chain. Any of the data, programs, and databases that may be stored within the memory 305 may be applied to the data collected by the data collection module 315.

[0045] Memory 305 may also be configured to store a “state” of the product and manufacturing / processing techniques. For example, a certain farm may have previously utilized harvesting techniques that rely on fossil fuels (State A). If the farm changes its harvesting techniques to rely on renewable energy sources instead of fossil fuels, the state may be updated and stored within memory 305 (State B). Further, memory 305 is configured to record the CI score of a product or products as they move through the supply chain. At each step of the supply chain, the CI score is captured and recorded. For example, the CI score before and after processing may be captured at each supply chain step, which may be used to accurately verify the finalized CI score once the end consumer receives the final product. The finalized CI score may be used in determining the value of 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. The audit trail of CI scores may be stored within memory 305. For example, memory 305 may store a copy of the blockchain having the CI scores recorded at each step of the supply chain as individual immutable blocks added to the blockchain. In some embodiments, to ensure the immutability of the blocks, each block must be signed (i.e., agreed / accepted) by all required signatories. Once all signatures are collected, the block may become involved, and the inputs to that block may be marked as historical (e.g., in the supply chain). In addition to the CI score, other data related to the location, including aerial images of the farmland (e.g., to ensure that the number of acres has not increased or decreased), may be captured and stored on the blockchain.

[0046] The data collection module 315 may be configured to collect data associated with at least one process within the supply chain. For example, the data collection module 315 may be configured to receive data associated with a farmer's cultivation practices, the use of fossil fuel vs. 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, operation, production, environmental, social, regulatory, output, and / or financial performance data associated with product production. Such information may be automatically received by the data collection module 315 through client devices and / or trusted third - party sources (e.g., a farmer may input data regarding agricultural techniques into a third - party application, which then stores the data and 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 embodiments, the processes may be categorized according to the products being produced and / or the industry. The historical processes may include state information, including discrete processing steps and inputs used by a participant in the supply chain. Additionally, the historical data within the database may include a CI score for a product at a given point in time as it occurs within the supply chain. The database may also reflect how the CI score changes as the associated product flows 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 processing of supply chain data and CI score history may have a historical trend of successful and failed attempts to reduce the CI score from past participant processing methods (e.g., applying a new type of fermentation technique, replacing gas-powered machinery for harvesting with EV-powered machinery, etc.). The data collection module 315 may also be configured to receive real-time updates regarding the CI score at a certain step within 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 processing steps applied to the product so far. 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 the 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 processing steps of the product through the supply chain showing how the CI score of the product 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 specific CI score based on its input (e.g., recorded in a state within a state diagram on a blockchain). In one case, the net-zero plant may utilize wind power generation, 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 onto the 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 can affect the CI score at a particular stage in the supply chain include transportation methods, auxiliary equipment operation (tractors, loaders, etc.), elevator operation, transportation of intermediate products, transportation of final products, etc. The CI score that can be produced from this net-zero plant can be affected by the range of use of each of the aforementioned energy inputs. Based on the current CI score of the goods arriving at the net-zero plant and the expected CI score of the processed goods at later stages in the supply chain, a specific mixture of energy inputs may be determined in the net-zero plant to produce a CI score that maximizes both energy efficiency and economic efficiency (i.e., balances carbon emissions and cost).

[0048] Alternatively, the data collection module 315 may query or otherwise obtain data from one or more data sources (e.g., other nodes within the network) that have such information. For example, the data collection module 315 may have access to data within one or more external systems such as a content system, a distribution system, a marketing system, a supply chain participant / entity / partner profile 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 CI score data and current CI score data and analysis (e.g., an analysis regarding environmental impact including predicted CI scores for a particular product in applying a certain process in the supply chain), which may inform the system of steps within the supply chain where a product should next be shipped, which may provide the best opportunity to limit an increase in the CI score of a product or alternatively to limit a decrease in its CI score as compared to applying other processes to the product. The data collection module 315 may use a set of APIs or similar interfaces to communicate requests to such data sources and then receive response data. In at least one embodiment, the data collection process of the data collection module 315 may be triggered in response to a specific user request for data (e.g., a user desires to know the current CI scores for a batch of a larger product group currently traversing the supply chain) or in response to meeting 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 has exceeded a particular threshold), according to a pre-set schedule.

[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 construct 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 (e.g., a farmer) in the supply chain that agrees to the conditions of the smart contract (i.e., a discrete formula for calculating the CI score based on specific input provided by an IOT device monitoring a particular product of interest and the farmer and / or the farmer's equipment) will enter into a contract with the CI score generation and tracking system described herein and will agree that the generated CI score is correct. For example, the initial data received by the smart contract module 320 may be the contractual conditions (i.e., rules) for calculating the carbon intensity (CI). Additional contractual conditions, such as certain conditions requested by a customer (e.g., the smart contract may contain conditions for the customer to automatically reject a certain product that exceeds a maximum CI score threshold), may be provided in some cases. In such embodiments, the contractual conditions for calculating the immutable CI score are distinct from the additional contractual conditions. 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 conditions are triggered. In another example, a supplier and a producer may agree that a product showing a CI score below a particular threshold will automatically result in a premium charge for the product. Based on the smart contract calculation of the CI score, a certain supplier may automatically receive a higher price for the final product due to the lower CI score of the product (i.e., a product that is more valuable to the end customer).In an embodiment, 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 a data collection module 315 and provided to a 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 (and vice versa) from an escrow wallet to the end - customer's wallet. 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 delivered successfully 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 another example, 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 of a farm, processing plant, manufacturing facility, packaging supplier, etc. Such status information may include information regarding how a participant in the supply chain is processing a particular product at that stage in the supply chain. The information may include the type of energy used to power machinery in the facility, whether environmentally considerate techniques are applied, farming practices, application rates of agricultural chemicals (e.g., fertilizers, herbicides, insecticides, etc.), types of agricultural chemicals 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 embodiments, the CI calculation module 325 may be configured to calculate a CI score based on inputs from participants in the supply chain, in combination with a regulatory and normalization algorithm for calculating the CI score. Those skilled in the art will understand that CI score calculations are standardized according to jurisdiction. For example, the state of California in the United States calculates the CI score according to the life cycle analysis, which is an analytical method for estimating the aggregated amount of greenhouse gases emitted during the entire fuel life cycle. The GHG protocol calculates the CI score as the amount of CO2 emissions per functional energy unit of the product. The Environmental Protection Agency uses a greenhouse gas equivalent calculator (e.g., CA.GREET 3.0). Other jurisdictions and institutions measure carbon intensity as the weight of carbon per British thermal unit (Btu) of energy. Further embodiments of calculating CI include variations of the GREET model of Argonne National Laboratory implemented by certain jurisdictions and entities such as the state of California, the International Civil Aviation Organization (ICAO), and the European Union (e.g., the Renewable Energy Directive (RED and REDII)). The aforementioned calculation methodologies each have differences in their premises and may not enable carbon credits to be traded equally across the carbon market.

[0053] The CI calculation module may be configured to communicate with the smart contract module 320 because certain contract 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 without 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 algorithmic conditions 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 the machine learning (ML) proposal module 330 (and vice versa). The ML proposal module 330 may, in particular, rely on the information provided by the smart contract module 320 and the CI calculation module 325 to provide an intelligent machine learning model-driven proposal to a participant in the supply chain, related to how the participant may modify its processing method to reduce the CI score of a future product. In an alternative embodiment, the ML proposal module 330 may provide the system with real-time proposals regarding the participants in the supply chain to which the product should next be sent. 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 current CI score of the product, the historical CI score, and the status information from plant A and plant B, the ML proposal module 330 may intelligently propose to the system the plant (plant A or plant B) to which the product should next be shipped for processing, based on a predicted 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 proposal module 330 may be configured to automatically make intellectual proposals regarding how to optimize (i.e., lower the CI score) the supply chain by directly providing proposals to participants and stakeholders in the supply chain regarding fine-tuning, substitution, and improvement processes to make them more ecosystem-friendly in order to achieve a lower CI score for the final product. Instead of attempting to manually adjust the supply chain (typically with insufficient information about the supply chain as a whole), the ML proposal module 330 may automatically make intellectual proposals to a participant in the supply chain in at least two types of settings, namely, (i) based on past performance indicators (e.g., status information reflecting current data about the operation of certain machines and participants in the supply chain), and (ii) regarding where a certain product should be processed next based on its current CI score (e.g., a certain processing plant may be more ecosystem-friendly than another plant, and the current CI score of the product is at a certain threshold, so the product needs to be processed in a more ecosystem-friendly plant to ensure that the CI score of the product does not exceed the threshold). Such decisions may be made according to the current CI score, historical data associated with a participant in the supply chain, budget constraints, end-customer requirements, etc., which may be received from the data collection module 315 and supplied to the ML proposal module 330.

[0056] In one example, the ML proposal module 330 may propose a substitution and application rate of an input (e.g., fertilizer, pesticide, etc.), aggregation and timing of shipments (e.g., to more economically and efficiently deliver the required inputs at a specific stage in the supply chain), optimization of transportation methods and route designation, and customer rotation (e.g., to encourage a specific co - product / by - product formulation based on shelf life). In other words, the stakeholders in the supply chain may receive the ML proposal and make changes such as modifying its shipping methodology, changing its fuel selection used when shipping the product, changing the brand of its fertilizer, changing the application rate and amount of pesticide applied to a specific crop, etc.

[0057] In some aspects, the ML proposal module 330 may be configured with a pattern recognizer that can understand a certain historical trend to identify a certain pattern (e.g., a certain input typically reduces the CI score by X%, a certain input typically increases the CI score by Y%, etc.). The pattern recognizer within the ML proposal module 330 may have two modes, namely, a training mode and a processing mode. During the training mode, the pattern recognizer may use the identified inputs that have been proven to affect the CI score of a certain product to train one or more ML models. Once one or more ML models are trained, the pattern recognizer may enter the processing mode, and the input data is compared against the trained ML models in the pattern recognizer. The pattern recognizer then produces a confidence score representing the likelihood that a certain input in the supply chain will either increase or decrease the CI score for a particular product, and a high 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 the training mode, the pattern recognizer trains one or more ML models and uses inputs from different types of processing, manufacturing, packaging, agriculture, shipping, etc. from participants in similar positions in the historical supply chain to distinguish certain data points that suggest whether a certain input will increase, decrease (or have no effect on) the CI score. For example, a farmer implementing machinery powered by renewable energy sources may result in a high confidence interval that the techniques of this particular farmer will reduce the CI score of a certain product, while a farmer using fossil fuels to power the machinery will have a high confidence interval of increasing the CI score of a certain product.

[0058] The ML proposal 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 the training mode. For example, to train a 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 proposal module 330 may utilize various machine learning algorithms for training at least one machine learning model, including but not limited to, among other machine learning algorithms, linear regression, logistic regression, linear discriminant analysis, classification and regression trees, naive Bayes, k-nearest neighbor, learning vector quantization, neural networks, support vector machines (SVMs), bagging and random forests, and / or boosting and AdaBoost. The aforementioned machine learning algorithms may also be applied when comparing input data to a trained machine learning model. 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 for training at least one machine learning model. For example, if the supply chain features and processes are complex and demonstrate non-linear relationships, the pattern recognizer may select the bagging and random forest algorithms to train a machine learning model. However, if the supply chain features and processes demonstrate a linear relationship to a certain increase or decrease in the CI score for a product, the pattern recognizer may apply a linear or logistic regression algorithm to train a machine learning model.

[0059] Communication module 335 is associated with transmitting / receiving information (e.g., collected by data collection module 315, smart contract module 320, CI calculation module 325, and ML proposal module 330) using a remote server or one or more client devices, streaming devices, servers, blockchain nodes, IoT devices, etc. These communications can 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, communication module 335 transmits information collected by data collection module 315 and processed by smart contract module 320 and CI calculation module 325 (and ML proposal module 330). Further, communication module 335 may be configured to communicate certain conditions of the smart contract from smart contract module 320, the calculated CI score from CI calculation module 325, and automated supply chain process improvements based on ML proposal module 330 to a client device. Additionally, communication module 335 may be configured to communicate an updated CI score to a client device after a product has completed processing at a certain step in the supply chain. Communication module 335 may also be configured to communicate a complete audit trail of the CI score development associated with the product from the farm to the final product. Communication module 335 may also communicate values associated with the CI score, where the values may be captured within CI tokens that are exchangeable (traded, purchased, and sold) by third parties in the carbon credit market.

[0060] Figure 4 illustrates an exemplary method for automatically generating and tracking a CI score. Method 400 begins at step 402, where smart contract conditions are received. The smart contract conditions at step 402 may define an algorithm for calculating the CI score. The calculations regarding the CI score may depend on the type of product, the quantity of the product, inputs from stakeholders throughout the supply chain, and other input variables that measure the ecological considerations of the production process and the range of its CO2 emissions.

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

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

[0063] At step 406, the system may receive input data from steps in the supply chain. For example, at step number 1 in the supply chain, the system may receive data regarding the farmer's harvesting techniques. If the product of interest is corn, certain inputs regarding the types 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 may be received by the system. Such inputs may be captured as the farmer's "state" in the supply chain. This state data may be received by the system at step 406. The state data may be updated as the farmer's process is updated. For example, if the farmer changes their practices (e.g., tilling techniques), the soil composition, or applies 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 at step 406, the system may analyze the input data at 408. Such analysis may include the step of comparing the input data to a certain formula defined by the smart contract conditions (received at step 402). Further, the system may consider historical data related to that particular party in the supply chain and parties in similar positions in other supply chains. Such analysis may provide the system with a benchmark against which the system may compare the input data received at 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 an output of a combination of the smart contract conditions and the input data received at supply chain step number 1. This initial CI score may be stored and recorded on the blockchain in step 412, and other stakeholders may be able to view the CI score and the arguments regarding 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 the smart contract conditions).

[0066] As the product continues to traverse the supply chain, the CI score of the product may be updated. The "product" traversing through the supply chain may refer to a single manufactured product or a collection of products. One CI score formula may be applied to a single product, while other CI score formulas may be applied to grouped products. When the product enters the next step in the supply chain, the system receives input data at step 414 in method 400 in the next supply chain step (e.g., supply chain step number 2, step number 3, ... step number N, etc.). As mentioned with respect to step 406, the received data may include status information regarding the processes of participants in the supply chain. In addition to status information that may be recorded by the stakeholders themselves (or a trusted third party, e.g., an auditor), the system may also receive information from pre-deployed IOT devices that may be attached to a certain machine or area where processing is taking place. For example, the IOT device may be a carbon dioxide meter that measures a certain exhaust air emitted from the machine. The 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 deployed within the processing facility, and the camera is configured to capture the type of power source used to power a certain machine. For example, if a participant in the supply chain runs out of power in the battery, the participant may need to rely on fossil fuels for that day in order to continue processing the product. Such deviations may be captured by IOT devices (e.g., cameras, machine monitoring devices, devices that monitor battery power, etc.). These daily changes in the supply chain may be accurately captured by the system described herein such that the CI score assigned to the product at each step in the supply chain is an accurate representation of the environmental impact of the processing / manufacturing of the product as it traverses the supply chain.

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

[0068] Figure 5 illustrates an exemplary method for verifying a CI score on a blockchain. Method 500 begins at step 502 and receives a request to verify a CI score. An application launched on the blockchain (e.g., a DeFi application) may provide an interface for a user to request and verify the CI score of a product. For example, an end customer may desire to verify that a particular product advertised as having a certain CI score actually has that CI score by double-checking it against 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 exemplary aspects, an authentication layer is applied prior to querying the blockchain at step 504 to ensure that an authorized user can query regarding the CI score. Such an authentication layer may also be an extension of a permissioned blockchain network, as opposed to a permissionless blockchain network where the public can query the blockchain regarding the CI score.

[0069] Once the blockchain performs a query at step 504, the CI score may be received by the system at step 506. The CI score from a specific block within the blockchain will be verified and immutable. The CI score results may be provided to the verifier at step 508. Optionally, the system may receive an action response from the verifier at step 510. In some embodiments, the verifier may be the end customer considering purchasing a product with a CI score. For example, an action response that the system may receive from the verifier at step 510 is a purchase action. In another embodiment, the verifier may be a government regulatory authority that verifies that a certain advertised CI score corresponds to the verified CI score on the blockchain. If the verified CI score is different from the advertised CI score, the verifier may flag the CI score of that particular product as suspect. Flagging the CI score as suspect may be an action response received by the system at step 510.

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

[0071] FIG. 6 illustrates an exemplary method for providing an intelligent suggestion for reducing the CI score. Method 600 is directed to the application of artificial intelligence (AI) and machine learning (ML) models to an automated system that generates and tracks the CI score, as described herein. Method 600 begins at step 602, where input data is received at a step in the supply chain (supply chain step N, where "N" is a numerical placeholder). Similar to the method described in FIG. 4, this input data may be data from any stakeholder / participant in the supply chain that characterizes the processing performed at that step. For example, the input data may be in the form of status information, where certain characteristics of the farmer's harvesting technique (e.g., tillage, type of machinery used, fuel consumption, water usage, pesticide usage, etc.) are captured. Other input data may be received from IoT devices (e.g., CO2 emissions measurement devices, cameras, etc.) disposed on a machine and within an environment that automatically measure and analyze the input data. This data may be received by the system at 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 the reception 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, since this is the first supply chain processing information input into the system that is required to generate the CI score, the CI score will be generated. If step N is, for example, step number 3, at least two previous intermediate CI scores have already been calculated, and thus 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 described above, the CI score calculation technique depends on the conditions of the smart contract negotiated among the parties. Such smart contract conditions may include a calculation formula for deriving the CI score, which may be based on industry standards and / or regulatory bodies (e.g., the 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 added to the blockchain, as described with respect to method 400 in FIG. 4. Method 600 may then proceed to optional step 608, where data associated with supply chain step N+1 (where "N" represents a number) is received by the system. Step N+1 is the subsequent step to step N in the supply chain. The data received in step 608 is input data associated with the processing methods and techniques applied to the product in step N+1 of the supply chain. The same type of input data as described above may be collected here. Further, the participants in the supply chain in steps N and N+1 may be the same participant (e.g., different facilities managed by the same entity), or they may be different participants (e.g., step N is a farmer and step N+1 is the first processing plant, etc.).

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

[0075] The output of the ML model analysis is an intelligent proposal that occurs at step 612. The intelligent proposal may propose to a participant (or third - party operator / controller) in the supply chain certain manufacturing / processing changes that may potentially lower the CI score in the future. Specifically, for example, after step N (or step N + 1) in the supply chain is completed and the product has received its intermediate CI score, the ML model output may provide to the participant in the supply chain a proposal to fine - tune the process in order to potentially achieve 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 at step 612 may suggest to the supply chain participants (and / or operators, controllers, 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 evaluate each of these participants and determine the most optimal participant for the current product based on the current CI score of the product. In one example, participant A in the supply chain may have deployed state-of-the-art environmentally friendly technology in its processing techniques, such that a lower CI score may be obtained compared to participant B, who may apply fossil fuel-based machinery for processing. If the CI score of a product at a certain step in the supply chain exceeds a certain threshold, the ML model output may intelligently suggest that the product be provided to participant A (instead of participant B) regarding 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 provided to participant B (instead of participant A), among other reasons, because participant B may have lower processing costs than participant A and participant B may be more likely to increase the CI score, but the increase (based on historical data from participant B) may not be sufficient to substantially affect the final score of the product.

[0077] Once the intelligent suggestion is generated at step 612, the suggestion may be provided at step 614 to the supply chain participants, supply chain operators / controllers, sellers, buyers, and / or any other relevant and interested parties who would benefit from receiving the intelligent suggestion based on the current intermediate CI score of a product across the current state of the supply chain.

[0078] Figure 7 illustrates an exemplary 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 exemplary environment illustrated in Figure 7, the inputs at the farm include fertilizer, insecticide, fuel, and tillage. Each of these inputs at farm 702 has an associated CI score. These CI scores may be pre-defined as the products (or processes) to be used at farm 702. For example, the fertilizer for the final product used by the farm may have received a final CI score during its manufacturing process. This final CI score may be referred to here as the first step in the supply chain.

[0079] In addition, at farm 702, different "farms" may have different calculations based on soil differences, fuel availability, tillage differences, etc. In some embodiments, multiple farms may receive different CI scores based on the unique inputs of each individual farm (e.g., fertilizer, insecticide, 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 large quantity of corn) is harvested and placed in a storage bin, an aggregated CI score may be assigned to the bin (or in an alternative scenario, directly to the large quantity of corn to prevent unauthorized replacement of the actual commodity in the bin for manipulating the CI score in the supply chain), which is reflected in bin 704. Bin 704 represents a single CI score assigned to the product containing inputs such as fertilizer, insecticide, fuel, etc. Similarly, for farms 2 - 4, etc., the product may receive an aggregated CI score at the bin stage.

[0081] Following the bin 704 (e.g., a large amount of corn), the product is then transported to the processing plant 706. In 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 when determining the derived CI score from the processing plant for the fuel produced at a given point in time. As described above, the CI score formula may take into account different factors such as the amount of water used by the processing plant, whether the machinery is powered via gas or electricity, etc. when determining the CI score for that specific step in the supply chain.

[0082] After the product (e.g., corn) is processed in the processing plant 706, the final products that can be produced may each receive an individual CI score. For example, the co-products / by-products of corn processing may be ethanol alcohol, isobutanol, isooctane, jet fuel, DDG (dry distillers grains, i.e., high-protein feed), oil, etc. These products each have unique processing requirements applied in the processing plant 706. Thus, these by-products will each be associated with a unique CI score based on the way they are manufactured. In some embodiments, the CI score may also indicate the extent to which the by-product takes into account the ecosystem when it is consumed. For example, burning ethanol-based gasoline produces less CO2 emissions than burning jet fuel, so ethanol may have a lower CI score compared to jet fuel. In other cases, ethanol may have a higher CI score than jet fuel.

[0083] In addition, the CI scores 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 through each step in the supply chain. Specifically, the CI scores associated with each component input at the farm 702 may be summed with the CI score at the bin 704. The aggregated intermediate CI score at the bin 704 may then be added to the CI score associated with the amount of gas, electricity, water, etc. utilized at the processing plant 706. In other embodiments, each step in the supply chain may produce its own additional 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 CI scores thus far (stored as blocks within the blockchain) and check that the final CI score is the sum of all the intermediate CI scores thus far. Finally, a certificate of sustainability may be issued that describes (and guarantees) the carbon footprint of the fuel product.

[0084] FIG. 8 illustrates exemplary inputs and outputs used to automatically generate and track CI scores along a supply chain. Environment 800 is an exemplary supply chain that illustrates processing steps related to corn and its potential co-products and by-products. As described previously, each discrete step in the supply chain may be assigned a CI score (an intermediate CI score). The final co-product / by-product may receive a final, verified CI score that can be verified by applying a checksum function (described in FIG. 7) to sum the CI scores thus far stored as blocks on the blockchain. Here, in environment 800, the initial inputs include water, energy, nutrients, and pesticides. The co-product of the initial input may be savings from reduced tillage related to corn cultivation. Savings from reduced tillage can lead to a lower CI score in the corn cultivation step in the supply chain illustrated in FIG. 8. Following the corn cultivation step, the corn is then, in this example, 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 the process in the supply chain. Exemplary co-products from the alcohol production step may be corn oil, dried distillers grains with solubles (DDGS), isobutanol, ethanol, etc. Each co-product may be assigned a CI score based on the sum of the CI scores thus far from the steps in the supply chain. In an example from environment 800, one of the products from the production step is isobutanol, which can be used in transportation. Isobutanol can also serve as a raw material for manufacturing hydrocarbon fuels and other chemical products. Further, other products from the production step in the supply chain may be sent to a hydrocarbon conversion processing step in the supply chain. Again, in this step, more water and more energy may be input into that 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 the intermediate CI scores so far in order 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 previously, the CI score may be stored on the blockchain and may be fully auditable by looking at the blockchain ledger of the nodes that point to a reference node containing data associated with the intermediate CI scores.

[0086] Figure 9 illustrates an exemplary state diagram used to automatically generate and track CI scores. Environment 900 illustrates different states of different participants / stakeholders in an exemplary supply chain (e.g., the supply chain illustrated in FIG. 8). In the present embodiment of FIG. 9, two farm states, namely, farm state 902 and farm state 904, are displayed. Each farm state includes objects such as identifiers, product yields, moisture content, seeding materials, fertilizer pesticides, other fertilizers, pesticides, energy consumption, and total emissions, among other objects. These objects are each used as inputs 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, herbicide, pesticide, in-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 farm state 902, while a lower totalEmissions object in farm state 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 process, farm state 902 may be updated to farm state 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 associated with 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 source identifiers that point back to previous states.

[0087] As a product is transported and processed step by step in a supply chain, more states of each participant are recorded and linked to each other. 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, a source, a CI score, a timestamp, and an owner. In one exemplary aspect, when corn moves from one step (e.g., a farm) to the next step (e.g., a shipper) in the supply chain, the CI score is updated and / or assigned. As illustrated in FIG. 9, CornDeliveryState indicates the first time the 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 products in this exemplary environment 900. For example, in a processing plant, since the processing of this product will be performed on a large amount of corn (and thus multiple CornDeliveryStates), multiple CornDeliveryStates may be combined into a single PlantState. Following the processing step in the plant, by-products, each having a ProductState that points back to the PlantState, may be created. 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 embodiments, the ProductState may be the final, verified product that constitutes the final CI score.

[0088] Regarding the overall architecture, the status of each participant / stakeholder in the supply chain may be represented as a block within the blockchain. Each status may be a block added to the blockchain accessible by the end customer who seeks to verify the authenticity and accuracy of the participants and the final CI score in the supply chain (ultimately, verify the value of the CI token). When the status of a participant is updated, a new block may be added to the blockchain and pointed back to the previous state so that other stakeholders in the supply chain (e.g., shipping companies, processing plants, etc.) are aware of reading data from the most recent block within the blockchain associated with that particular participant in the supply chain. For example, one way this can be implemented programmatically is by checking whether a block has a forward pointer. If no forward pointer exists, the current block is the most recent block, i.e., the most recent status of the participant in the supply chain.

[0089] In some illustrative aspects, each state may represent a block within a blockchain. When a verifier / claimer desires to verify the CI score of a final product, the verifier / claimer may receive not only the verified CI score (one of the properties of the state), but also each of the other properties of that state, and the referenced states captured by (i.e., linked to the current state) other blocks within the blockchain. 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 previous states by following the backpointer 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, without limitation, may be extrapolated to other industries and products that utilize a multi-step supply chain. 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 the subsequent CI score to be recorded in that state.

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

[0091] As shown in FIG. 10, the input data constituting the state of each participant in the supply chain may be obtained via a web application interface (e.g., a blockchain network, e.g., the user interface of a DeFi application running on network 1004). In other embodiments, the input data may be received from IoT devices attached to certain machines, storage containers, pipes, etc. that measure a certain carbon emissions in one embodiment. These IoT devices automatically measure data and report it to a central system where the system uses the data to create the state of the participants in the supply chain. Further, as described above, each state may be updated for each product flowing through the supply chain. The state can change as frequently or infrequently as the participants desire. For example, a farmer may have used up a certain ecosystem-friendly fertilizer in just one day and thus may have to apply a less "environmentally friendly" fertilizer. This change (although it is just for one day) may be captured within the updated state data block that is ultimately considered in the final calculation of the CI score.

[0092] FIG. 10 may also include a third-party verification entity, which is a node within blockchain network 1004. The third-party verification entity may act as a notary (i.e., an independent signatory) who can effect and confirm the submission of a certain transaction and to the blockchain. Such third-party verification can prevent double spending (e.g., a participant in the supply chain attempting to copy a lower CI score from a previous block and display a higher intermediate CI score, attempting to use the information of that block in the supply chain instead of the previous block where the entity attempts to double spend the CI token, attempting to forge the intermediate CI score, etc.).

[0093] FIG. 11 illustrates an exemplary environment for automatically generating and verifying a CI score. The exemplary environment 1100 of FIG. 11 shows the same supply chain as from FIG. 10. The environment 1100 also illustrates a Dapp (decentralized application) 1102 that may be utilized by a final customer to pay a supplier. The Dapp 1102 may be utilized to query a blockchain (such as the blockchain network 1004, etc.) to verify the final CI score of a product. When the CI score is verified (e.g., via a CI score certificate 1106 generated by verifying the CI score on the blockchain), the supplier may receive money from the final customer. As described above, this transaction may be automatically executed via a smart contract. For example, the conditions of the smart contract may stipulate that once a certain final product is verified as having a certain CI score, a certain deposited funds from the buyer may be transferred to the seller. The CI score verification process may be performed by querying the blockchain and analyzing each state data block leading to the final product (i.e., auditing the development of the CI score from when the product was first grown to its final processing step prior to becoming the final product for the buyer).

[0094] FIG. 12 illustrates an exemplary environment for generating CI tokens via a CI score. After a particular product has been verified as having a certain CI score, the verified CI score (e.g., in the form of a certificate generated from a blockchain) may be used to create a CI token, which may represent the value of carbon offset credits that can be traded. For example, after money has been transferred from a buyer to a seller due to the verification of a product's CI score, there exists here a verified immutable record that a certain amount of carbon emissions has been avoided by utilizing an ecosystem - considerate process throughout the supply chain. The CI score (and accompanying state data block with properties) may reflect this. As a by - product of tracking the CI score and purchasing products with a low CI score, a CI token may be created that captures the value of the avoided carbon emissions. This is similar to carbon credits that can be bought and sold between parties. Preferably, CI tokens are fungible tokens, and thus, they are all the same but divisible into smaller units and can be easily exchanged.

[0095] Specifically, a CI token may be sold to a company that desires to emit a certain level of carbon emissions and pay for that carbon emissions via the CI token. A CI token is a storage place for a measurable and verifiable emissions reduction value, which may enable an entity to emit a certain amount of carbon emissions if the entity can pay for the carbon emissions via the CI token. In essence, a CI token is a tradable cryptocurrency that enables its holder to emit an amount of carbon emissions equivalent to the value of the CI token. A CI token may also function as a common - denominator currency between market sectors (e.g., facilitating transactions between an agricultural entity and an electricity provider).

[0096] Buyers of products that take ecosystem considerations into account may pay a premium price for products with a verified low CI score. To offset the paid premium, the buyer may also receive CI tokens, which may be sold by the buyer to other entities that desire to emit excessive carbon emissions that would otherwise not be permitted to emit based on regulations and laws in a certain jurisdiction. Thus, a low CI score leads to higher value CI tokens.

[0097] Figure 13 illustrates an exemplary environment for generating and trading CI tokens, at least in part, using the Corda blockchain development platform available from R3 Ltd. In this specific implementation, Environment 1300, referred to as "Verity", combines a large-scale and highly transparent voluntary carbon credit market with a supply management system that ensures the reliability of low, neutral, and / or negative carbon intensity in material production through an immutable and automated audit using blockchain technology. Verity's 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 enables all parties to record and manage their agreements with each other in a secure, consistent, reliable, private, and auditable manner.

[0098] In Verity, each participant can be a farmer, a plant, a seller, etc. Each participant runs a node within the Corda application 1302. Each node communicates with external data sources via an API and reads production data to calculate the 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 in technology) to calculate the CI score.

[0099] Producers may calculate their CI scores and read out the value of their sustainable practices through a market that may be referred to as the "Verity Carbon Market". The CI scores may be transmitted and stored within database 1304, which then communicates with the Verity token solution 1306. Participants may tokenize their CI scores via the Verity token solution 1306. Such tokens may be direct carbon value (DCV) tokens that are minted within the Verity platform based on the calculation of the CI scores and are tradable among network participants. The Verity tokens may ultimately be traded and exchanged on the cryptocurrency exchange platform 1308. Since the Verity source data is directly extracted from the supply chains of each economic actor within the Verity network, the certainty associated with each carbon offset exists (i.e., there is no double counting).

[0100] FIG. 14 illustrates an example of a suitable operating environment in which one or more than one 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 the 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 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 a memory 1404. Depending on the exact configuration and type of the computing device, the memory 604 (especially, storing information related to devices, blockchain networks, payment settings, asset balances, CI score formulas, ML-based proposals for reducing the CI score, and instructions for implementing the methods disclosed herein) may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.), or a combination of the two. This most basic configuration is illustrated by dashed line 1406 in FIG. 14. 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 tapes. 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, speaker, printer, etc. Also, what is 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 medium. The computer-readable medium can be any available medium that can be accessed by the processing unit 1402 or other devices that make up the operating environment. By way of example and not limitation, the computer-readable medium may comprise a computer storage medium and a communication medium. The computer storage medium includes volatile and nonvolatile, removable and nonremovable 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. The computer storage medium includes RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage device, magnetic cassette, magnetic tape, magnetic disk storage device, or other magnetic storage device, or any other tangible medium that can be used to store the desired information. The computer storage medium does not include the communication medium.

[0103] The communication medium 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 medium. The term "modulated data signal" means a signal in which one or more of the characteristics are set or changed in such a manner as to encode information in the signal. By way of example and not limitation, the communication medium includes wired media such as a wired network or direct-wired connection and wireless media such as acoustic, RF, infrared, and other wireless media. Any combination of the above should also be included within the scope of the computer-readable medium.

[0104] The operating environment 1400 may be a single computer (e.g., a mobile computer) operating within a networked environment that uses a logical connection to one or more remote computers. The remote computer may be a personal computer, a server, a router, a network PC, a peer device, an IOT measurement device (e.g., a carbon emissions measurement device), or other common network nodes, and typically includes 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 connection may include any method supported by an available communication medium. Such networking environments are common 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 the supply side management (SSM) component. Corda presents an attractive development platform due to its prowess in interconnecting IOT devices or process information (PI) systems for recording, analyzing, and monitoring real-time information. Further, Corda works in concert with standard REST APIs for plant control systems. Another attractive feature of Corda is its improved ability to establish tokens within those platforms. This makes it a more attractive platform at present than others such as Flyperledger Fabric which has deprecated its token SDK. Another advantage of using Corda is its utilization of the unspent transaction output (UTXO) model where each state on the ledger is immutable. That being 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 described within the blocks may be performed in any order other than that shown in any flowchart. For example, depending on the functionality / acts involved, two consecutively shown blocks may actually be executed substantially in parallel or the blocks may sometimes be executed in the reverse order.

[0107] The description and illustration of one or more aspects provided in this application are not intended to limit or restrict the scope of the disclosure in any way as claimed. The aspects, embodiments, and details provided in this application are considered sufficient to convey possession and 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, embodiment, or detail provided in this application. 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. Although the description and illustration of this application are 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 in this application without departing from the broader scope of the claimed disclosure.

[0108] From the foregoing, it should be understood that while specific embodiments of the invention have been described herein for purposes of illustration, 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. A method comprising: Prior to any step in the process for converting the feedstock into biofuel, A processor obtaining a carbon intensity (CI) score of the product provided to said step; the processor using the CI score to select a power source for the step; wherein the product is applied to the step in the process using the selected power source and any remaining steps in the process are completed to produce the biofuel.

2. The method of claim 1, further comprising: during the process for converting the feedstock into biofuel, the processor determining which of a set of power sources are available for performing the step, and wherein selecting a power source for the step is limited to selecting a power source from the available power sources.

3. The method of claim 2, wherein the collection of power sources is limited to power sources implemented at a facility used to convert the feedstock into the biofuel.

4. The method of claim 1, wherein selecting the power source includes the processor selecting a power source to obtain a desired CI score for the biofuel.

5. The method of claim 2, wherein selecting which of the set of power sources is available includes the processor tracking the status of each power source implemented in a facility while performing steps in the process of producing the product.

6. The method of claim 1, wherein producing the biofuel further comprises the processor generating an invariant CI score for the biofuel that reflects the carbon intensity associated with growing the feedstock, transporting the feedstock, and converting the feedstock into the biofuel.

7. The processor generating a CI token based on the CI score for the biofuel; and the processor uses the CI tokens, the processor offsetting at least one instance of a carbon emission; The method of claim 6 further comprising:

8. The method of claim 7, wherein using the CI token includes the processor marking the CI token such that the CI token cannot be used to offset other carbon emissions.

9. A method comprising: Prior to the process for creating a biofuel, a processor obtains a respective carbon intensity (CI) score for each of a plurality of loads of feedstock present in a processing plant configured for creating a biofuel, and the processor uses the CI scores for the plurality of loads of feedstock to select loads of feedstock for use in the process for creating a biofuel. wherein a selected load of said feedstock is applied to said process for producing said biofuel.

Images