CN117957552A

CN117957552A - Secure and verifiable agricultural product tracking

Info

Publication number: CN117957552A
Application number: CN202280063092.0A
Authority: CN
Inventors: 理查德·L·莱斯; 乌尔里希·G·特罗格尔; 肯特·W·詹姆斯
Original assignee: Amwack Hong Kong Ltd
Current assignee: Amwack Hong Kong Ltd
Priority date: 2021-09-16
Filing date: 2022-04-22
Publication date: 2024-04-30
Also published as: IL311424A; AU2022348386A1; CA3231360A1; AR127051A1; UY39940A; WO2023043497A1; TW202316355A

Abstract

A computer-implemented system and method for collecting and storing data related to products stored in a container. In response to filling the container with the product, the following data is stored in at least one first record in an external database, such as a distributed ledger (e.g., blockchain): a product type of the first product; the amount of the first product filled into the first container; a unique identification of the first container; and a unique identification of a first user of the first container when the first container is filled with the first product. Data representing the unique identification of the container data module on the container is stored in the container data module. As the container moves, dispenses products, and experiences changes in occupancy and ownership, data representing these events is stored in the distributed ledger and/or container data module.

Description

Secure and verifiable agricultural product tracking

Background

With the growing public and government concern over climate change, there is an increasing need to reduce the carbon footprint caused by emissions of greenhouse gases (Greenhouse Gase, GHG) associated with the production of commercially grown food and fiber crops, wherein best practices associated with such practices (best MANAGEMENT PRACTICE, BMP) reflect a balance between reducing the carbon footprint produced by the production of crops and agricultural productivity.

Nitrogen is an important component of life, necessary for the construction of proteins and DNA, and although nitrogen is abundant in the atmosphere, only limited inorganic soil nitrogen reserves are available to plants in usable forms, mainly nitrate (NO 3-) and/or ammonium (nh4+). Thus, unless supplemental forms of nitrogen are applied, agricultural yield is often limited by the availability of nitrogen. At the beginning of the 20 th century, the german chemist friez Haber (Fritz Haber) and Carl Bosch have invented and improved an industrial scale process for converting atmospheric nitrogen to ammonium, one of the nitrogen forms readily available and used by plants. During the green revolution, the use of synthetic or artificial nitrogenous fertilizers is a major contributor to the drastically increased crop yield, especially in developing countries. According to the american society of plant food control officials, any fertilizer made from one or more synthetic materials that do not contain animal parts, animal by-products, manure, or stucco (renderings) should be considered a "synthetic" fertilizer, and therefore, all nitrogen fertilizers made using modifications to the Haber-Bosch process are considered synthetic fertilizers.

Currently, the survival of nearly half of the world's population relies on the use of such synthetic fertilizers, but the process of converting atmospheric nitrogen into useful crop fertilizers requires significant amounts of energy, estimated to be 1% to 2% of the total energy consumption worldwide. For example, production of one ton of artificial nitrogen fertilizer requires about one ton of natural gas. While one ton of fertilizer may be sufficient to supply the nitrogen requirements of 4 to 5 acres of high yield corn, a similar amount of petroleum energy in the form of gasoline, measured in british thermal units (British Thermal Units, BTU's), would drive an average vehicle of only 20 miles per gallon over a distance of 8000 miles.

While nitrogen fertilizer is a key factor in modern agriculture to produce high crop yields, it is also the largest single source of global agricultural GHG emissions. The use of artificial nitrogenous fertilizers results in the emission of large amounts of nitrogen oxides (N ₂ O), N ₂ O being a GHG with a global warming potential of about 300 times that of carbon dioxide (CO ₂). According to the national greenhouse gas list of the U.S. environmental protection agency 2014, the N ₂ O emissions from farmland soil in the united states alone are about 1.95 million metric tons of CO ₂ equivalents. This amount corresponds to the emission of about 4100 ten thousand passenger cars per year.

Ammonium nitrate (ammonium nitrate, AN) is the most common nitrogen source in european agriculture. UAN (urea ammonium nitrate (urea ammonium nitrate)) consists of urea, ammonia and nitric acid. The AN fertilizer used AN average carbon footprint of about 5.6 kg CO ₂ equivalents per kg applied nitrogen. In other words, approximately 5.6 tons of GHG are released into the atmosphere per ton of nitrogen fertilizer applied.

The us carbon registry (American Carbon Registry, ACR) is a leading us-based carbon offset program, approved for strong environmental integrity standards. ACR, established in 1996, was the first private voluntary cancellation program in the world, formulated strict, scientific-based carbon cancellation standards and methods, and possessed operational experience in terms of carbon cancellation project registration, audit supervision, and cancellation release. ACR is also an approved carbon offset project registration and early action carbon offset program for the California total volume control and Trade program (California Cap-and-Trade program), which is the first economic range of the united states. As a certification authority, the ACR oversees the registration and verification of carbon countering items in accordance with approved carbon accounting methods or protocols and issues countering on a transparent registration system. Each offset represents a reduction or removal of carbon dioxide in the atmosphere equivalent to one metric ton.

An organization named Delta Institute (Delta Institute) initiated a nitrogen credit program supported by United STATES DEPARTMENT Of agricultural/natural resource protection agency (Natural Resources Conservation Service, NRCS) that provided qualified corn farmers with financial incentives for carbon credits that were charged to their accounts by reducing nitrogen oxide (N ₂ O) emissions due to their use Of less nitrogen-based fertilizer in the production Of corn crops. The participating farmers have been compensated for reduced GHG emissions by selling their carbon credits to the climate Trust foundation (THE CLIMATE Trust), a non-profit organization established in 1997, which manages carbon offset acquisition plans and projects for organizations seeking to reduce their carbon footprint.

GHG emissions reductions by farmers involved in the program were quantified and validated via ACR approval methods developed by michigan state University (MICHIGAN STATE University, MSU) and electric institute (Electric Power Research Institute, EPRI). The MSU-EPRI method represents a3 year scientific study by MSU scientists at the Karlog biostatic long-term ecological research base of the national science foundation (National Science Foundation's Kellogg Biological Station Long-term Ecological RESEARCH SITE) and the commercial farm in Michigan.

These field trials indicate that the rate of nitrogen fertilizer application per treated area (acre, hectare, etc.) is the best predictor of N ₂ O emissions in U.S. corn production. Such programs demonstrate that farmers can obtain financial returns by reducing N ₂ O emissions, mainly in the form of marketable carbon credits. However, several challenges must be addressed in order to be widely adopted worldwide.

For example, one problem that must be addressed is how to reduce the use of nitrogen fertilizer without a corresponding decrease in crop yield. All plants require nitrogen to grow and survive. Nitrogen is a major component of chlorophyll, a compound that plants use solar energy to produce sugars (i.e., photosynthesis) from water and carbon dioxide. It is also a major component of amino acids, which are components of proteins. Without protein, plants will die and die.

Corn plants grow using large amounts of nitrogen and produce economically viable yields. About 1 pound of nitrogen is removed from the soil every time corn produces one bushel (bushel) of grain, so a yield target of 250 bushels per acre will remove about 250 pounds of nitrogen from the soil. Because even the highest yielding soils do not naturally contain as much nitrogen, farmers add to the soil supplemental artificial nitrogen fertilizer produced using the various adaptations of the Haber-Bosch process previously described to achieve the high yields required to meet global needs at a level of commercial profit acceptable to farmers. While corn is repeatedly mentioned in this document as an example crop, all commercially planted non-leguminous crops require nitrogen supplementation to produce economically viable crop yields, and in response to the reduction in the use of artificial nitrogen fertilizer in these crops, GHG emissions will also correspondingly be reduced.

Unlike corn and other non-leguminous crops, leguminous crops such as soybeans, peanuts, peas, vetch, clover, and the like, grow in symbiotic relationship with nitrogen-fixing rhizobia in the soil, which absorbs or "fixes" gaseous nitrogen from the air in the soil, and feeds the nitrogen to the leguminous plant. Legumes provide the bacteria with the necessary carbohydrates for the exchange of nitrogen obtained from these soil-borne (soil-borne) bacteria. The ability of legumes to obtain substantially all of their nitrogen requirements from atmospheric nitrogen is primarily based on their ability to produce nodules in which nitrogen-fixing bacteria survive and reproduce. In natural ecosystems, the nitrogen fixation of legumes can range from 25-75 pounds per acre per year, while in planting systems, the nitrogen fixation of legumes can be hundreds of pounds per acre per year. Thus, leguminous crops typically do not require or receive supplemental nitrogen fertilizer treatment in most commercial crop production programs. Some legumes are inoculated with rhizobia-based products to enhance early root nodule development, enabling the legume to fix nitrogen from the atmosphere.

Scientific research has shown that non-legumes such as corn, sugar beet, potato, wheat, etc. can also benefit from symbiotic relationship with azotobacter, but unfortunately, non-legumes are unable to form or produce nodules required for rhizobia to thrive and reproduce. Many agricultural universities and agricultural importation companies are researching the use of soil inoculants consisting of a group of non-native microorganisms that infect non-leguminous plants in order to enable these plants to fix or acquire part of their nitrogen demand from the atmosphere in a manner consistent with that of leguminous use, even though the non-leguminous plants still do not produce nodules that were previously thought to be critical to nitrogen fixation of the plants. The key to understanding this process is that unlike legumes which generally fully meet all of the nitrogen requirements of the atmospheric supply, non-legumes utilizing nitrogen-fixing microorganisms, after inoculation with these non-native soil microorganisms, can only meet a portion of their total nitrogen requirements. However, even relatively small reductions in nitrogen fertilizer use can result in significant environmental and social benefits, and due in part to the significant reduction in GHG emissions associated with such reductions, the potential of even replacing a portion of the artificial nitrogen fertilizer with a nitrogen fixation inoculant for non-leguminous plants such as corn is attractive. Farmers have the opportunity to win and gain financial incentives in the form of carbon credits because they reduce GHG emissions and combine the use of nitrogen fixing inoculants to correspondingly reduce the combined practice of artificial nitrogenous fertilizers, which increases the likelihood of timely and rapid adoption of these practices worldwide.

One example of a nitrogen fixing bacteria product that may be used to replace a portion of an artificial nitrogen fertilizer is Envita ^TM from subsonic north america (Azotic North America). Azotic well-managed farm test results showed that Envita inoculated non-leguminous crops used about 25% less artificial nitrogen than control crops, and that the yield was comparable to control crops produced using full-rate artificial nitrogen fertilizer. Unlike rhizobia bacteria of the legume family, which are used to fix nitrogen, the presence of rhizobia bacteria is limited to roots and nodules, envita-based microorganisms are present throughout the plant, including leaves, and nitrogen fixed by these microorganisms is used by the plant to produce chlorophyll. Envita is but one of many nitrogen-producing microbial products currently available or under development, the purpose of which is to enable non-leguminous plants to meet a portion of their nitrogen requirements from a fixed atmospheric nitrogen. Another example of a nitrogen fixation product is PROVEN ^TM from Pivot Bio. According to the statement from Pivot Bio, "PROVEN extracts nitrogen from air and produces ammonia by using bacteria. This bacteria live on corn roots and feed ammonia to the corn plants. Regardless of weather, this process provides a constant nitrogen source for the plants during the growing season. "

Scientific advances in the development and production of nitrogen-fixing microbial products such as Envita, PROVEN indicate that the potential to significantly reduce nitrogen-related GHG emissions is substantial, but is only largely employed when farmers have financial incentives to replace the known performance of applying artificial nitrogen fertilizer at 100% of the historical rate with the unproven consistency of co-application of fertilizer at 75% of the historical rate with nitrogen-fixing microbial products such as Envita. Some nitrogen fixation products have demonstrated that when such fertilizer reduction is combined with the use of nitrogen fixation microbial products, historical average yields can be maintained while reducing the applied nitrogen fertilizer rate by as much as or more than 50%.

While the above description focuses on agricultural crops and land areas or fields for producing these crops, it should be understood that large areas of grasses are used for hay production purposes, as livestock food, or for livestock grazing, where livestock eat living plant material in their grazing area, rather than being harvested and stored by a machine, via a grazing process. Many grasslands, whether used in hay production or animal husbandry, also employ synthetic nitrogen fertilizer, and thus the goal of reducing the use of fertilizer on the grassland to reduce GHG emissions associated with grassland fertilization, and the practice thereof, falls within the definition of agricultural use of synthetic nitrogen fertilizer.

As described above, an organization such as climate trust is willing to pay a peasant for carbon credits verified by an authentication organization such as the united states carbon registry. Once a certification authority such as the united states carbon registry verifies that farmers do reduce the use of a specific amount of artificial nitrogen fertilizer, rather than the amount of fertilizer normally applied using best management practices for that particular crop in that particular region, calculating the reduction in GHG emissions associated with a reduction in fertilizer application per acre is a simple arithmetic problem using 5.6 to 1 per ton of artificial nitrogen fertilizer GHG emissions. The 32% UAN fertilizer is a mixture of ammonium nitrate and water containing 32% nitrogen, so one ton of artificial UAN fertilizer contains 640 pounds of nitrogen. Using the example previously cited 250 bushel of corn per acre required 250 pounds of nitrogen, this amount was reduced by 25% to 62.5 pounds. Using the 5.6 to 1 ratio previously described, it was shown that a 62.5 pound reduction in artificial nitrogen fertilizer per acre would result in a 350 pound reduction in GHG emissions per acre. In the united states, carbon credits are typically calculated and paid for based on the resulting GHG emissions reduction. Since 350 pounds represents 17.5% of 2000 pounds per ton, it was confirmed that the nitrogen fertilizer application per acre was reduced by 62.5 pounds from what would normally be required to produce the target yield, and thus was qualified to obtain carbon credits equivalent to the then-current carbon credit value per ton. One report from the S & P global month 2020 of one of the world leading agricultural consultants is reported as follows: "carbon prices have been realized in 40 countries and 20 cities and regions. According to 2019 world bank reports on carbon pricing trends, by 2020, a carbon pricing range of $40-80 per ton is necessary to reach the objectives set by Paris agreement 2015. "this work is done using a midpoint count of 60 dollars per ton, in this example, 17.5% of the 60 dollars produce a carbon credit value of 10.50 dollars per acre for farmers who reduce the usage of 62.5 pounds of artificial nitrogen fertilizer per acre.

It is challenging to confirm or verify the amount of artificial nitrogen actually applied to a field. While strict production practice agreements are implemented and monitored in fields of cooperating farmers participating in the ACR/Delta institute nitrogen credit program described previously, it is not feasible for carbon credit certification authorities and/or carbon credit marketing authorities to provide human supervision for millions of fields, which would be necessary for large scale implementation of paying carbon credits to farmers in exchange for reduced GHG emissions resulting from the combined practice of using artificial nitrogen fertilizer and applying nitrogen fixing microbial products. The method or system for verifying the total amount of artificial nitrogen fertilizer applied to each of a number of fields is not manually implementable, nor is the process for verifying that nitrogen fixing microbial products are applied to each of a number of fields in order to supplement the nitrogen demand of crops with fewer artificial nitrogen fertilizer applications. With respect to carbon credits earned by farmers, it is also important to verify where and at what rate to apply nitrogen fixation and other soil health and regeneration agricultural crop inputs, as in addition to being able to gain carbon credits to reduce GHG emissions associated with production crops, farmers can gain carbon credits by increasing the amount of carbon stored or sequestered in field soil where commercial crops are planted.

Disclosure of Invention

A computer-implemented system and method of collecting and storing data related to products stored in a container. In response to filling the container with the product, the following data is stored in at least one first record in an external database (e.g., a distributed ledger (e.g., blockchain)): a product type of the first product; the amount of the first product filled into the first container; a unique identification of the first container; and a unique identification of a first user of the first container when the first container is filled with the first product. Data representing the unique identification of the container data module on the container is stored in the container data module. As the container moves, dispenses products, and experiences changes in occupancy and ownership, data representing these events is stored in the distributed ledger and/or container data module. Thus, a verifiable application/consumption record of the product within the container is generated.

Drawings

FIG. 1 is a schematic diagram of a system for tracking products in a container according to one embodiment of the invention;

FIG. 2 is a flow chart of a method performed by one embodiment of the system of FIG. 1;

FIGS. 3A-3N and 4A-4P are swim lane diagrams of a method for validating compliance with carbon credit activity in accordance with two embodiments of the invention;

FIG. 5 is a schematic diagram of a system for tracking products in a container and for locally storing data about the products until a network becomes accessible in accordance with one embodiment of the invention; and

FIG. 6 is a flow chart of a method performed by one embodiment of the system of FIG. 5.

Detailed Description

Embodiments of the present invention relate to computer-implemented methods and systems for recording information about agricultural products in a container in an external database, such as a distributed ledger (e.g., blockchain). The following description discloses various embodiments of such methods and systems.

For example, embodiments of the present invention may be used to verify that certain activities that meet carbon credits are performed in accordance with the requirements associated with obtaining carbon credits. For example, embodiments of the present invention may track a product at a manufacturing point, where the product is transferred to a label container that may be in communication with a product transfer device and a product application device. In embodiments where product information is stored on the container label, the product information may include, for example, the type of product, the amount of product filled in the container, the location of the container at the time of filling, the date and time of filling, and the manufacturer, owner, and owner of the product in the container and/or the container itself. This establishes the provenance or judicial availability of the product that may be tracked, for example, for the purpose of obtaining carbon credits.

Embodiments of the present invention may also be used to verify that a reduction in product usage has been achieved as compared to some baselines. Such reduced product use may be beneficial for a variety of reasons, such as reduced greenhouse gas emissions from synthetically produced nitrogen fertilizers, reduced environmental loads of pesticides and nutrients, reduced sewage runoff in environmentally sensitive areas (such as the gulf of mexico, the gulf of chesapak and the great five lakes) and/or forest guard areas, wetlands, and in areas of propagation of endangered species. A key advantage of embodiments of the present invention is that they provide the ability to verify whether such reductions (or more importantly, whether they are not) in compliance with environmental laws and regulations and corporate policies in a manner that is difficult or impossible to circumvent via fraud or human error.

Embodiments of the present invention may also be used to verify that a particular product (e.g., pesticide or fertilizer) is used or unused (e.g., applied, dispensed, transferred, planted or consumed) at a particular location or area (e.g., a particular latitude and longitude or a set of latitude and longitude), or that no less than or no more than a particular amount of a particular product (e.g., pesticide or fertilizer) is used (e.g., applied, dispensed, transferred, planted or consumed) at a particular location or area. For example, embodiments of the present invention may use records created and stored in an external database (e.g., a distributed ledger) to prove that the organic farm is not using non-organic chemicals. Such a process of creating records in a non-counterfeitable manner represents a significant improvement over the prior art, which relies on the authenticity and accuracy of human self-reporters, whether intentional or unintentional, who may inaccurately record and/or report the use or non-use of a particular chemical and/or chemicals at a particular location or area.

Certain embodiments disclosed herein use a distributed ledger to store information. The distributed ledger gives control of all information and transactions to the ledger user and improves transparency. The distributed ledger technique minimizes transaction time and improves efficiency and automation. Distributed ledger accounting tends to have greater security and customer confidence than non-distributed ledger central database accounting because of its decentralized nature and invariance to transaction records.

Blockchains are one type of distributed ledgers. Blockchain technology provides a method of securely and efficiently creating tamper-resistant logs of transaction activity. Blockchain technology is often used to provide quality of service transaction accounting for a variety of products including international remittance, heterogeneous universal certification (non-fungible token, NFT) or cryptocurrency transactions, stakeholder records, and even agricultural products, to name a few. The distributed ledger accounting process is fast, providing a safer, more digital alternative to users, replacing the usual time-consuming, paper-intensive and costly clearing house process.

The data written to the distributed ledger may be variably inscribed on the network. Over time, an accurate and immutable audit trail is created through a series of transactions. This is very useful for auditing and/or legal purposes, as all data is stored where no single entity has possession of or control of it, nor can someone alter what has been written. This provides similar benefits to duplex billing, but with less likelihood of error or fraud.

Transaction data stored in a central database that does not utilize distributed ledger techniques may be as accurate as data stored in a distributed ledger, and embodiments disclosed herein may use distributed ledger techniques and/or a central database to store data. While both types of systems may be 100% accurate and verifiable, distributed ledger technology facilitates the auditing process, and because of invariance to transaction records, distributed ledgers are generally considered more trustworthy because, as previously described, all data is stored where there is no single entity owner or control of it, nor can someone alter what has been recorded. The ability to verify the timestamp, geotag application/consumption records of agricultural inputs and fuels using distributed ledger techniques can greatly improve the trustworthiness associated with these records. This level of audit capability aids in legal accounting purposes when disputes occur that require legal resolution. The law accounting analyzes, interprets and summarizes complex financial and business matters, possibly employed by insurance companies, banks, police forces, government agencies, etc. The legal accountant surveys and compiles financial evidence that can be presented as evidence in a court. An important object of certain embodiments disclosed herein is to facilitate creation and capture of audit data suitable for use as a proof of practice.

Once embodiments of the present invention have been used to store data in a verifiable record (e.g., a distributed ledger), such a record may be used to impose a penalty (e.g., tax or other penalty) on one or more parties, for example, based on the data in the record. For example, if a verifiable record indicates that a party has taken one or more actions that violate and/or are not compliant with requirements (e.g., laws, regulations, and/or production agreements established by, for example, a private entity or government legislation or custody organization), embodiments of the present invention may determine that a penalty should be imposed on the party and may select the penalty based on the data and/or requirements in the record. As a particular example, if a buyer refuses to pay a premium for a product from a non-agreed upon area, embodiments of the present invention may determine that no subsidy should be issued for the area and/or that a tax or penalty should be imposed on the buyer. Or the records may be used to provide incentives or rewards, such as carbon credits, to entities whose records are shown to meet requirements associated with obtaining such incentives.

As another example, embodiments of the present invention may use verifiable records to establish provenance of harvested products that need to be tracked and their identity saved after harvesting the product. For example, most seeds are produced by some type of identity protection means. Without such identity protection, it is not practical to sell seeds as unique varieties or hybrids. When the seeds are harvested from the seed production field, the seeds are harvested separately from all other products, and the equipment used to harvest the seeds from the production field is thoroughly cleaned prior to harvesting to ensure that the equipment is not contaminated with other types of seeds or other products. After harvesting the seeds, the seeds are transported, stored and cleaned separately from all other seeds to maintain the integrity of the seeds. However, this process does not always perfectly preserve the identity of the seed, mainly due to human error. Therefore, a seed bag marketed as containing only seeds of type a may also contain a certain amount of seeds of type B. Embodiments of the present invention may be used to track each seed from the time of harvest to all subsequent processing of the seed to the time of sale of the seed to the end customer. The verifiable record of the resulting seed from harvest to final sale can be used to confirm that the identity of the seed is protected throughout the process.

Embodiments of the present invention may also be used to track and identify agricultural products that food has contacted. For example, if a particular food product is exposed to a particular agricultural product (e.g., pesticide or fertilizer) in a field, information about the agricultural product may be stored in one or more container data records in a container data module associated with the particular food product. For example, such a container data module may be affixed to the food product itself (e.g., through the use of a label) or to a container containing the food product. In the case where the container data module is associated with (e.g., affixed to) the food product itself, the container data module may be unrelated to the "container" as used herein. The container data records stored on such containers may contain any of a variety of information, such as information identifying the food product, the agricultural product being applied, and the date, time, and location of application of the agricultural product to the food product. Later, the data may be read from the container data record on the container data module to identify the agricultural product being applied to the food product. For example, a consumer may read such data at or before the point of sale of the food product to identify the agricultural product applied to the food product.

Embodiments of the present invention may also be used to generate verifiable records of the path traveled by the contents of a particular container, from when the container was initially filled with the contents, through each of a plurality of movements of the container (including, for example, records of the container being at a plurality of locations and corresponding times at those locations), to and including the time and/or times and locations and/or locations at which the contents of the container were consumed.

Embodiments of the present invention may also be used to generate verifiable records of product transfer from one container to another over time (this may be records other than those that track the location of the containers over time). For example, one example of a product that embodiments of the present invention may track is nitrogen fertilizer. The initial container in which the nitrogen fertilizer is placed after manufacture is typically a large tank, even a bulk warehouse that is only isolated by boxes or dividers within the warehouse. Nitrogenous fertilizer is typically sold in tons and is therefore often transported by railroad cars or sea containers. Embodiments of the present invention may be used to mark and track the filling and dispensing of fertilizer and other products from such bulk containers, for example for the purpose of creating verifiable chain of custody and application records, for the purpose of carbon credit verification.

The definition of the underlined terms is provided below only to aid in the understanding of certain embodiments of the invention, and not to limit the scope of the claims herein.

The amount is as follows: the amount of material may be any one or more of the following unit amounts, weights, masses, or volumes: in the case of a dry material (e.g., a granular product, or a powder product for soil or plants, fertilizers, seeds, etc.), for example, the amount of the dry material may be the amount of the dry material itself, such as the mass or volume of the dry material. In the case where the material has been diluted to produce a mixture of material and diluent, the amount of the mixture may be: (1) an amount of material mixed with the liquid; or (2) the amount of the mixture. Where a material has been sprayed onto a particle (e.g., clay, fertilizer, or other dry material), the amount of material may be the amount of material sprayed onto the particle (e.g., mass or volume) rather than the amount of particle on which the material is sprayed (e.g., mass or volume), or it may include both the amount of dry material (e.g., mass or volume) and the amount of liquid material sprayed onto the dry material (e.g., mass or volume). One example of a product in which the recorded weight of material includes the weight of the dry material and the weight of the liquid sprayed onto the dry material is force 10G, wherein 50 pounds of the dry material includes the weight of the clay particles impregnated with a liquid formulation of a tetrafluoroinsecticide, wherein 10% of the recorded weight will be represented by the tetrafluoro active ingredient sprayed and impregnated onto the dry clay particles.

And (3) application: when the product is dispensed from the container and placed on soil or plants in a field or other area, the product is applied from the container, for example, by using a sprayer or other application device. Thus, administration is an example of dispensing.

Area: geographic location greater than a set of latitude and longitude coordinates. For example, the region may include a plurality of coordinates. An area is an example of a location.

A central database: an external database with a central administrator. The central database may be located, stored and maintained in a single location. For example, a central database may be maintained by a single computer. As another example, the central database may be stored on a single computer-readable storage device. The central database may, for example, store its data in a single database file. The central database may access its data, for example, only via a direct cable connection or via a local area network. Although the central database may be distributed across more than one computer and/or storage device, the central database is not a distributed ledger, nor is the distributed ledger a central database, as these terms are used herein, although both the central database and the distributed ledger are examples of external databases, as these terms are used herein.

Consumption: the product is consumed when the product is removed from the container without transferring the removed product to another container. Application of a product is an example of a consumer product. Burning fuel is an example of consuming a product without applying the product. Spilling or handling product from a container is also an example of a consumer product. Consuming a product (e.g., human, animal, fungus, or bacteria) from a container is also an example of a consumable product. Administration of a drug from a container to a human or animal (e.g., by injection or ingestion) is also an example of a consumer product. Destroying the product when it is in the container or after dispensing it from the container is also an example of a consumer product.

A container: any device capable of storing a product. Examples include a closed conveyor container, a vehicle (e.g., truck, automobile, boat, or airplane), a trailer, a rail car, a seed hopper on a planter, a tank or hopper on an application device, a tank trailer, a stationary or mobile bulk tank, a bulk warehouse, a loading device (e.g., hopper on a front end loader), an auger tube, pipe, or line, or any type of smaller packaging type, such as, but not limited to, a drum, small bulk, a handbag, a1 or 2.5 gallon tank, a bottle, a tank, or even a smaller sized container. Other examples include any type or size of reservoir for storing or containing fuel (in any phase, e.g., solid, liquid, or gas), including a fuel tank, fuel lines, and/or any fuel-containing vessel or device that contains or holds fuel. The container may comprise one or more other containers. For example, a labeled container may contain one or more other labeled containers. The compartment or other portion of the container may be the container.

Container data module (Container Data Module, CDM): a physical object containing one or more container data records associated with one or more containers, and these container data records are not stored in an external database. A single CDM may contain one or more container data records for only a single corresponding container or for multiple containers. CDM of a container may be, for example, on, integrated into, coupled to (e.g., attached to), or otherwise associated with the container. CDM may be electronic (e.g., CDM may be or include a static or dynamic RFID tag) or non-electronic (e.g., CDM may be or include a bar code or QR code, which may be printed on paper or other non-electronic media). CDM may be static or dynamic. CDM may include means (e.g., RFID tags) for transmitting and/or receiving signals (e.g., signals representing data stored or intended to be stored within CDM). CDM may be or include any kind of electronic memory (e.g., non-transitory computer readable medium) that may store any kind of data disclosed herein. CDM may include one or more automatic identification and data capture (Automatic Identification and Data Capture, AIDC) components, such as "smart cards" or other devices that may be updated via magnetic fields, optical radiation, or other wireless transmissions.

Container Data Module (CDM) identifier: data uniquely identifying a particular Container Data Module (CDM). As this means, a plurality of container data modules may each be identified by a respective different CDM identifier. CDM ID may be contained within the container data record. As this means, CDM IDs may be stored on CDM (e.g., electronic or non-electronic CDM).

Container Data Record (CDR): a data record comprising data associated with the container, the data may or may not relate to one or more transactions associated with the container. The CDRs may include any one or more of the following, for example, in any combination: a container identifier of the container; CDM ID of CDM associated with the container; a unique identifier of the product contained in the container; data representing the amount of product contained in the container; and one or more transaction data records. In addition to or instead of the above data, the container data record may include aggregated data derived from a plurality of container data records, such as the total amount of a particular product consumed from the container at a particular location or during a particular period of time (e.g., the lifetime of the container or since the container was filled with the consumed product). Data from multiple container data records associated with a particular container may be used to identify the amount of a particular product in that container at any particular time. For example, when a particular product is first filled into a container, information regarding the type and amount of product filled may be stored in a container data record associated with the container. When the same type of product is filled into and/or dispensed from a container, one or more additional container data records may be generated and stored to represent such filling and dispensing. Such container data records may be used to identify the amount of product stored in the container at any particular time. The container data record may be, be contained within, or contain one or more non-homogenous pass (NFT).

Container history data: a set of one or more container data records associated with a particular container. For example, the container history data for a particular container a may include a first container data record containing data regarding a first product that was filled by the manufacturer for container a and a second container data record containing data regarding a second product that was filled or refilled for container a by an entity other than the original filler. The container history data of the container may constitute or include a verifiable record of the container contents in time and space. The container history data for the container may be stored in one or more container data modules. As a specific example, the container history data for the container may be stored in an external database or a distributed ledger (e.g., blockchain). Each of the plurality of containers may have its own corresponding container history data.

Container Identifier (ID): data uniquely representing a particular container. This means that the container IDs of different containers may be different from each other. The container ID may be contained within the container data record.

Coordinates: the data representing the position at a particular point may be represented, for example, by GPS geographical coordinates, which may include horizontal coordinates of latitude and longitude, or vertical coordinates corresponding to the horizontal coordinates, for the purpose of determining altitude or altitude above sea level or ground level.

Data configuration file: data stored in CDM may be marked as public or private. Public data stored in CDM can be read by any entity without limitation. Private data stored in CDM may be read only by entities that meet certain criteria. For example, private data stored in CDM may be read only by the manufacturer, owner, or user of CDM.

And (3) distribution: the product is removed from the container, whether or not the product is transferred to another container. Examples of products that are dispensed without transfer to another container include when the product is dispensed from a container (i.e., applied) to a field, and when petroleum-based fuel is metered from a fuel container or fuel system into an engine. When the product is dispensed without being transferred to another container, it is consumed.

Distributed ledger: shared and synchronized databases are agreed to be accessible to multiple persons across multiple sites, institutions, or regions. The distributed ledger allows transactions to have public witnesses. Participants at each node of the network may access the shared records on the network and may have their identical copies. Any changes or additions made to the distributed ledger will typically be quickly reflected and quickly replicated to all participants, for example, in seconds or minutes. Blockchains are examples of distributed ledgers. The distributed ledger is not a central database, as these terms are used herein.

Electronic memory device (Electronic Memory Device, EMD): specific examples of CDM include any type of electronic memory (e.g., one or more non-transitory computer-readable media) for storing any type of data disclosed herein that can be stored in CDM.

Entity: natural persons or legal entities (e.g., corporations). The entity may be, for example, the manufacturer of the product, the owner or owner of the container, the user of the product or container, or a personal or legal entity responsible for using the container or product. The entity may be a participant in the transaction (e.g., an entity that caused or performed the transaction).

Entity Identifier (ID): a unique identifier of an entity (e.g., manufacturer, owner, or user of the container). Specific terms such as "manufacturer ID" are examples of entity IDs.

An external database: data storage storing container history data on non-CDM media. The external database may be or include a central database or a distributed ledger. Examples of external databases are inventory management systems, transportation management systems and databases stored on the administration device. Unless otherwise indicated herein, any techniques disclosed herein for storing data into and/or reading data from a distributed ledger or CDM should be understood to be additionally or alternatively applicable to storing and/or reading such data to/from an external database. The data stored in the external database may have been previously stored on CDM before being subsequently stored to the external database, and the data previously stored on the external database may be subsequently stored on CDM.

Filling: the product is placed in a container. If the product is received directly from another container, this is an example of transferring the product from one container to another. This includes mixing/processing/merging/compounding materials from multiple potentially non-traceable products together to create a product that will be added (e.g., first) to a container, which will be identifiable via container history data.

Geographic location service: any device and/or software that includes means for automatically identifying a location (e.g., the location of a container). The geolocation service may identify the location, for example, using a global positioning system (Global Positioning System, GPS) and/or other satellite-based technologies, internet protocol (Internet Protocol, IP), RADAR (RADAR), SONAR (sonor), LIDAR, real-time kinematic (real-TIME KINETIC, RTK), spatial signals (SIGNAL IN SPACE, SIS), and/or image analysis techniques. As another example, the geolocation service may identify the location as a known (current or past) location of an entity (e.g., the owner or owner of the container), for example, by looking up the location in a container data module or an external database (e.g., a distributed ledger).

Position: including general terms of coordinates and area.

Materials: one of the possible components of the product. As this means, the product may comprise one or more materials.

The operation is as follows: the act of filling or dispensing the product into or from the container.

The owner: an entity that is a legal owner of a particular container and/or product at a particular time, whether or not the entity is the owner of the container at the time. The owners of the containers may or may not be the same as the owners of the products contained in the containers. The owner of a container at a particular time may or may not be the same entity as the owner of the container at the particular time.

The owner: an entity occupying a particular container at a particular time, whether or not the entity is the container and/or the owner of the product in the container at the time

The product is as follows: may comprise the material within the container, or a mixture that results when multiple materials are contained within the container. The product may be any of a variety of product types.

Product amount data: data representing the amount of product, for example: the amount of product contained within a particular container containing only one type of product; the amount of a particular differentiated product contained within a particular container that contains multiple types of products and/or single types of products that are distinguished from one another by, for example, the number of manufacturing lots or lot numbers, the date of manufacture, etc.; the amount of product filled into the container during the filling operation; or the amount of product dispensed from the container during the dispensing operation. The container data record may include product quantity data representing a quantity of product stored in a container associated with the container data record.

Product application equipment: a device capable of applying a product from a container.

Product consumption equipment: a device capable of consuming a product (i.e., dispensing the product without applying the product).

Product type: data identifying the category to which a particular material belongs. The product type may, for example, include an entity ID identifying the manufacturer of the product and a product name. Examples of product types include: soil application inputs and/or plant application inputs, such as fertilizer/plant nutrient products (e.g., nitrogen fertilizer), pesticides, soil health additives, plant health additives, nitrogen-fixing microorganisms; soil application inputs, such as seeds; unrefined and/or refined petroleum products, such as oil, gasoline, kerosene, jet fuel, diesel fuel, and/or mixtures of one or more petroleum fuels with ethanol and/or other combustion fuels or additives; a food/beverage product. These are merely examples of product types; embodiments of the present invention are not limited to use with any particular product type. The product type may specify any general level of product type, such as a very high level (e.g., "fertilizer" or "pesticide"). In addition to or instead of such advanced product types, the product types may include information such as any one or more of the following: manufacturer, brand name, variety, lot number, chemical composition, formula, expiration date, bulk density, and the like.

Provenance: the origin of the item or the earliest known history, and/or a record or document of the history of the proving object. The external database and/or data in CDM (e.g., container history data) may be used to establish provenance of the product stored in the corresponding container. Examples of where the product comes from are the locations where the product is first filled into the container, e.g., by the manufacturer of the product and/or container. Another example of the provenance of the product is the product owner when the product is first filled into the container or the container owner at that time. Any combination of Container Data Records (CDRs) from CDM and/or external databases may be used to verify the history of individual containers and/or individual containers: history of product combinations.

RFID tag: a class of CDM that includes RFID transmitter/receiver modules. RFID tags may store static and/or dynamic data.

And (3) tag: synonyms for Container Data Module (CDM). The tag may be, but is not necessarily, an RFID tag.

Label container: a container with associated CDM, whether or not the CDM is or includes EMD. CDM of the tag container may be, for example, integrated into the tag container, affixed to the tag container, coupled to the tag container, contained within the tag container, and/or in electronic communication with the tag container. The tag container may have one or more associated CDMs.

Transaction: recordable events involving a particular container. Based on the data stored in the container data module, data regarding transactions involving a particular container may be recorded in: (1) In a container data module associated with a particular container, or (2) in a data store other than the container data module. Examples of transactions include moving a container to a new location; transfer of occupancy, ownership or use of the container; filling the container with the product; dispensing the product from the container; and satisfaction of a condition by the container (e.g., effecting dispensing of at least a certain amount or percentage of the product in the container or through at least a certain specified amount of time).

Transaction data record: data representing the transaction. The transaction data record representing a particular transaction may include any combination of any one or more of the following: a product type; product amount; entity ID of manufacturer of the product; entity ID of the owner of the container at the time of operation; entity ID of the owner of the container at the time of operation; entity ID of a user of the administration device for performing the operation; a ratio of filling or dispensing product as part of the operation; date and/or time of operation; or the location of the operation.

And (3) transferring: the product is removed from one container and stored in another container. The transfer may, but need not, be in a tamper-proof or tamper-proof manner.

The user: an entity transacting containers and/or products, such as filling the containers with the products or dispensing the products from the containers. The user of the container may, but need not be, the owner of the container.

The record may be verified: storage of authenticity verifiable container history data. For example, if the container history data indicates that the product was dispensed at a particular time and location, the techniques disclosed herein may be used to verify that the product was dispensed at that particular time and location. A distributed ledger (e.g., blockchain) is an example of a verifiable record.

Some descriptions of EMD mentioned herein are equally applicable to non-electronic CDM. Similarly, any reference herein to a "labeled container" should be understood to refer to a container having any type of associated CDM, whether or not the CDM includes an RFID tag. Any reference herein to data stored in, on, or otherwise associated with a container should be understood to disclose storing such information in one or more CDMs associated with the container.

As disclosed herein, some embodiments of the invention may store one or more CDRs in an external database as a distributed ledger. At any time after performing such storing, such embodiments may store some or all of the CDRs in an external database of the non-distributed ledger (e.g., by copying the contents of the CDRs from the external database of the non-distributed ledger into one or more CDRs in the external database that are the distributed ledger).

Similarly, as disclosed herein, some embodiments of the invention may store one or more CDRs in an external database of a non-distributed ledger. At any time after performing such storing, such embodiments may store some or all of the CDRs in an external database that is a distributed ledger (e.g., by copying the contents of the CDRs from the external database that is a distributed ledger into one or more CDRs in an external database that is a non-distributed ledger).

Referring to FIG. 1, a schematic diagram of a system 100 for implementing one embodiment of the invention is shown. Referring to FIG. 2, a flow chart of a method 200 performed by the system 100 of FIG. 1 is shown, according to one embodiment of the invention. Although not shown in fig. 1, the system 100 may include at least one computer processor executing computer program instructions stored on at least one first non-transitory computer readable medium to perform the method 200 of fig. 2.

The system 100 includes a first container 102. The first container 102 includes a first product 104. The first container 102 may have included the first product 104 in any of a variety of ways. For example, the system 100 may include a second container 152 (also referred to herein as a "source container"), and the second container 152 may include a second product 154 (also referred to herein as a "source product"). The system 100 may also include a filling module 130, the filling module 130 may fill the first container 102 with the first product 104 (operation 202 of fig. 2), for example, by transferring some or all of the second product 154 from the second container 152 to the first container 102. As suggested by this description, the first product 104 and the second product 154 may be the same product type. The first container 102 may be empty or may not contain any first product 104 prior to transferring the second product 154 from the second container 152 into the first container 102. Accordingly, the amount of the second product 154 transferred from the second container 152 to the first container 102 may be equal (precisely or within a tolerance) to the amount of the first product 104 in the first container 102 after the filling (e.g., transferring) operation performed by the filling module 130.

The system 100 may include a first storage module 106 and an external database 108 (e.g., may be a central database or a distributed ledger). In response to filling the first container 102 with the first product 104 or after filling the first container 102 with the first product 104, the first storage module 106 may store data in at least one container data record 110 in the external database 108 that represents a filling operation performed by the filling module 130 to fill the first product 104 into the first container 102 (operation 204 of fig. 2). The collection of container data records 110 is an example of "container history data," as that term is used herein.

The first storage module 106 may store any one or more of the following in any combination, for example, in the container data records 110 of the external database 108:

One or more dates and/or times (e.g., time stamps) associated with the filling operation and/or the first product 104, such as the date and/or time at which the filling operation occurred and/or the date and time of manufacture of the first product 104;

the position of the first container 102, for example, the position of the first container 102 at the time of the filling operation;

A unique identification of the first container 102;

The product type of the first product 104;

the amount of first product 104 that the filling module 130 fills into the first container 102 in a filling operation;

the amount of first product 104 in first container 102 as a result of the filling operation (which may be greater than the amount of first product 104 filled into the first container in the filling operation if first container 102 contained the same type of product as first product 104 prior to the first filling operation);

An owner ID of the owner of the first container 102, for example, an owner ID of the owner of the first container 102 at the time of the filling operation;

an owner ID of the owner of the first container 102, for example, the owner ID of the owner of the first container 102 at the time of the filling operation;

Manufacturer ID of the manufacturer of the first product 104; and

The user ID of the user of the first container 102, for example, the user ID of the user of the first container 102 at the time of the filling operation.

The system 100 may include a second storage module 116 and a container data module 118. Although the container data module 118 is shown in fig. 1 as being distinct from the first container 102, the container data module 118 may be integrated into the first container 102, fixed to the first container 102, attached to the second container 102, coupled to the first container 102, or otherwise on the first container 102.

In addition to or in lieu of the first storage module 106 storing the container data records 110 in the external database 108 (operation 204 of fig. 2), the second storage module 116 may store, for example, in one or more container data records 120 in the container data module 118: (1) Any one or more of the types of data disclosed above in connection with operation 204, and/or (2) CDM ID of CDM 118 (operation 206 of fig. 2). If both operations 204 and 206 are performed, such operations may, but need not, store the same data in the external database 108 and the container data module 118. For example, the first storage module 106 may store some data (e.g., user IDs) that the second storage module 116 does not store in the container data module 118 in the external database 108. Conversely, the second storage module 116 may store some data (e.g., manufacturer ID) that the first storage module 106 does not store in the external database 108. These are merely examples, do not constitute a limitation of the present invention, and are merely for illustration that the first storage module 106 and the second storage module 116 may or may not store data that is identical to each other.

The filling operation 202 may be performed, for example, at the beginning of the first container 102, e.g., after the manufacturer of the first product 104 and/or the manufacturer of the first container 102 has manufactured and first filled the first container 102 with the product (e.g., the first product 104), or after the first container 102 has been emptied and cleaned and then filled with the product (e.g., the first product 104). The first product 104 may be, for example, a liquid or a dry product. The system 100 and method 200 may measure the amount of the first product 104 that has been filled into the first container 102 and store the measured amount in the container data record 120 in the external database 108 and/or the container data module 118. The stored measured quantity may be expressed, for example, as a volume, weight, volume, or other unit of measurement. Such measured quantity is one of the characteristics associated with the originating certificate of the first container 102, which may be captured and stored in the container data module 118. As described in greater detail elsewhere herein, when some or all of the first product 104 is dispensed from the first container 102, the amount of the first product 104 remaining in the first container 102 may be stored in the external database 108 and/or the container data module 118.

The amount of product filled into and/or dispensed from the container may be measured in any of a variety of ways. For example, if the mechanism that dispenses the product (e.g., during transfer of the product from one container to another) uses an auger gauge, the system 100 may calculate the amount of product dispensed by the gauge based on the number of times the auger is rotated and/or the number and duration of times the gauge is operated. The system 100 may, for example, count the number of revolutions, strokes, openings, pulses, flow rates, and/or cycle times of the dispensing meter and calculate the amount of product dispensed from the dispensing container using each measured cycle or operating unit.

The data stored in CDR 118 in operation 206 may, for example, include data (referred to herein as "lookup data"), such as a container ID of first container 102 and/or a CDM ID of CDM 118, which may be used by external database 108 or other external computer system (not shown in fig. 1) to identify data associated with first container 102 and/or first product 104, such as some or all of the data stored in CDR 110 of external database 108 in operation 204. The external computer system, which may include external database 108, may use the data stored in CDR 120 to find such data associated with first container 102 and/or first product 104. As a specific example, in operation 206, a CDM ID of CDM 118 may be stored in CDR 120. The external computer system may read CDM ID of CDM 118 from CDM 118 (or otherwise receive the CDM ID) and use the CDM to look up (e.g., as an index, key, or query) in an external database (e.g., external database 108) data associated with first container 102 and/or first product 104, such as data associated with fill operation 202, such as any or all of the data stored in CDR 110 of external database 108 (e.g., any one or more of the container ID of first container 102, the type of first product 104, the amount of first product 104 filled into first container 102, and the time and location of fill operation 202). CDR 120 of CDM 118 may, for example, include such lookup data without including any data stored in CDR 110 of external database 108. In this way, CDR 120 of CDM 118 may efficiently utilize memory space, and system 100 may in turn rely on the broader memory space of an external computer system to store the details of fill operation 202.

As a particular example, CDM 118 may include CDRs 120, which may include only lookup data, and may not include any data stored in CDRs 110 of external database 108. For example, CDM 118 may be static and include a printed code (e.g., a bar code or QR code) that may represent a container ID of first container 102 and/or a CDM ID of CDM 118, and may not include any data representing a product contained in first container 102, data representing an entity associated with first container 102, or an operation associated with first container 102 (e.g., a fill or dispense operation). As a specific example in this regard, CDM 118 may include such printed code without including other code.

The first container 102 may be filled (in operation 202) with the first product 104 in a tamper-proof manner. The first container 102 may be filled with the first product 104 in a tamper-proof and/or tamper-proof manner. For example, the techniques disclosed herein for storing data in the external database 108 may provide tamper evidence. For example, assume that the first container 102 is empty and then filled with X ₁ pounds of product Y, and that the filling is recorded in the external database 108 when occupied by the first owner of the first container 102 using any of the techniques disclosed herein, then the occupancy of the first container 102 is transferred to the second owner, and the techniques disclosed herein are used to record on the external database 108 that the first container 102 contains X ₂ pounds of product Y (where X ₁≠X₂). Embodiments of the present invention may determine whether the external database 108 contains any records other than the records just described, which indicate that the first container 102 has been filled with product Y. If it is determined that the external database 108 does not contain any such records, embodiments of the present invention may conclude that: the records of the first container 102 on the external database 108 are evidence that the first container 102 has been tampered with, as these records fail to account for the amount of the first product 104 in the first container 102.

The external database 108 may be, for example, a distributed ledger, such as a blockchain. CDR 110 (and any other CDRs disclosed herein that are stored in external database 108) may include one or more blocks in a blockchain.

CDM 118 may be, for example, electronic (e.g., containing electronic memory) or non-electronic, as implied by the definition of the container data module. For example, CDM 118 may include an RFID tag, and operation 206 may include wirelessly receiving any data stored in CDM 118 by second storage module 116 using the RFID tag. CDM 118 may use any form of wireless communication. As just two examples, CDM 118 may communicate by transmitting and/or receiving ultra-high frequency (Ultra High Frequency, UHF) signals and/or light waves. As other examples, CDM 118 may communicate by transmitting and/or receiving low, medium, or high frequency signals.

Operations 202, 204, and 206 may be, but need not be, performed in the order shown in fig. 2. To name a few examples:

operations 202, 204, and 206 may be performed in the order shown in fig. 2. In such an embodiment, operation 206 may be performed in response to filling the first container with the first product.

Operation 206 may be performed prior to operation 202 and/or prior to operation 204. For example, CDM 118 may be non-electronic (e.g., paper) CDM, CDR 120 may be a non-electronic CDR (e.g., a printed barcode or QR code), and operation 206 may include storing the non-electronic CDR on the non-electronic CDM prior to operation 202 and/or prior to operation 204.

In embodiments where operation 204 includes storing data representing a first owner of the first container 102 in the CDR 110 in the external database 108, the first storage module 106 may also store data representing a second owner of the first container 102 in at least one second record in the external database 108 sometime after the first container 102 is occupied by the second owner (other than the first owner).

In embodiments where operation 206 includes storing data representing a first owner of first container 102 in CDR 120 in CDM 118, second storage module 116 may also store data representing a second owner of first container 102 in container data record 120 or the other container data record in CDM 118 sometime after first container 102 is occupied by the second owner (different from the first owner).

In embodiments where operation 204 includes storing data representing a first location of the first container 102 in the CDR 110 in the external database 108, the first storage module 106 may also store data representing a second location of the first container 102 in at least one second record in the external database 108 sometime after the first container 102 is moved to the second location (different from the first location).

In embodiments where operation 206 includes storing data representing a first location of first container 102 in CDR 120 in CDM 118, second storage module 116 may also store data representing a second location of first container 102 in container data record 120 or another container data record in CDM 118 some time after first container 102 is moved to the second location (different from the first location).

Some or all of the first product 104 may be dispensed from the first container 102. In response to such an allocation, or at any time after such an allocation:

the first storage module 106 may store data representing the allocation in at least one second CDR in the external database 108; and/or

Second storage module 116 may store data representing the allocation in at least one second CDR in CDM 118.

Such data representing the allocation (whether stored in external database 108 and/or CDM 118) may include data representing any one or more of the following:

the amount of first product 104 dispensed from the first container 102;

the amount of first product 104 remaining in the first container 102 after dispensing;

the type of first product 104 dispensed from the first container 102;

A unique identification of the owner of the first container 102 at the time of dispensing;

a unique identification of the applicator device used to dispense the first product 104 from the first container 102;

A unique identification of an operator of the applicator device for dispensing the first product 104 from the first container 102;

A unique identification of the owner of the applicator device for dispensing the first product 104 from the first container 102;

A second position of the first container 102 at the time of dispensing, wherein the second position is different from the position of the first container 102 at the time of filling in operation 202;

Allocation time;

A ratio of dispensing the first product 104 from the first container 102 (e.g., applied to a field); and

For each of a plurality of locations L at which the first product 104 is dispensed from the first container 102, any one or more of: (1) Data representing an amount of the first product dispensed from the first container at location L; (2) data representing the location L; (3) Data representing a time at which the first product was dispensed from the first container at location L; and/or (4) data representing the ratio of product dispensed from the container at location L.

At any time after filling the first container 102 with the first product 104 in operation 202, at least some of the first product 104 may be transferred to a third container (not shown). After such a transfer, the system 100 may perform one or both of the following:

the first storage module 106 may store data representing the transmission in the CDR 110 and/or another CDR in the external database 108; and

Second storage module 116 may store data representing the transmission in CDR 120 and/or another CDR in CDM 118.

Further, after such transmission, system 100 may store data representing the transmission in CDM (not shown) associated with the third container.

The stored data regarding the transfer (in any of the above-described locations) may include, for example, any data disclosed herein that may be stored regarding the operation 202 of filling the first container 102. For example, the stored data regarding the transfer may include, in any combination, but is not limited to, any one or more of the following: product type of the transferred product; the amount of product transferred; a unique identification of the first container 102 and/or a unique identification of the third container; a unique identification of the owner of the first container 102 and/or a unique identification of the owner of the third container at the time of transfer; a unique identification of the owner of the first container 102 and/or a unique identification of the owner of the third container at the time of transfer; transfer date; transfer time; the location of the transfer (e.g., latitude and longitude or GPS coordinates); and a unique identification of the entity responsible for causing the transfer.

When recording data regarding a transfer from the first container 102 to the third container, embodiments of the present invention may read the data regarding the transfer from CDM 118 of the first container 102 and store some or all of the read data regarding the transfer in CDM of the third container. For example, embodiments of the present invention may read information about the type and amount of product transferred from first container 102 from CDM 118 of first container 102 and store information about the type and amount of product transferred from the first container into the third container in CDM of the third container.

This transfer from the first container 102 to the third container may be repeated for any number of containers. For example, after transferring at least some of the first product from the first container 102 to the third container, at least some of the first product may be transferred from the third container to a fourth container (not shown), and so on. At or after each such transfer, embodiments of the invention may perform any of the functions disclosed herein associated with transferring material from the first container to the third container, such as storing data representing the transfer in any of the ways disclosed herein in external database 108 and/or CDM associated with (e.g., coupled to) the receiving container. Any such container into which material is transferred may be a closed delivery container suitable as part of a mobile product dispensing device from which product may be dispensed onto a field or other area.

Any of the techniques disclosed herein in connection with transferring a product from a first container 102 to a third container may be applied to transferring a second product 154 from a second container 152 to the first container 102.

Because the system 100 and method 200 may store a record of product transfer from one container to another, embodiments of the present invention may be used to automatically determine that product dispensed from a particular container is initially stored in a different container. For example, container a may be filled with a quantity of product a, and any of the techniques disclosed herein may be used to store the filled first record (e.g., in an external database and/or CDM of container a). Some or all of product a may be transferred from container a to container B, and any of the techniques disclosed herein may be used to store a second record of the transfer (e.g., in an external database, CDM of container a, and/or CDM of container B). Some or all of product a may be dispensed from container B, and any of the techniques disclosed herein may be used to store a third record of the dispensing (e.g., in an external database and/or CDM of container B). Embodiments of the present invention may determine (e.g., based on the first record, the second record, and/or the third record) that product a dispensed from container B is initially contained in container a. This is merely one example of the manner in which embodiments of the present invention provide traceability of a product from one container to another over time and identify the provenance of the product based on records stored in a verifiable ledger/accounting system. Further, if the first record, the second record, and the third record are stored in a distributed ledger, such traceability is verifiable and tamper-proof, or at least tamper-proof. Method 200 of fig. 2 may include establishing provenance of first product 104 based on data stored in CDR 110 in external database 108 and/or data stored in CDR 120 in CDM 118.

More generally, embodiments of the present invention may use data stored in a plurality of container data records to track a particular product in time and space, and identify one or more of the following states of the product at a previous point in time (e.g., the time the product was first filled into the container, e.g., by an entity that manufactured the product in the container and/or an entity that filled the container with the product) based on the data records of the plurality of containers:

The position of the product at this point in time;

a container containing the product at that point in time (e.g., identifiable by a container ID of the container, which may be stored in CDM of the container);

the amount of product contained in the container at this point in time;

The type of product contained in the container at this point in time;

One or more entities associated with the product at the point in time (e.g., manufacturer, owner, and/or user, such as a user filling the container);

one or more entities (e.g., manufacturer, owner, and/or user, such as a user filling a container) associated with the container at the point in time.

Such tracking may be performed in a verifiable and tamper-proof manner, or at least tamper-proof if, for example, the container data records are stored in a distributed ledger. For example, such tracking may involve:

Identifying a current container data record associated with the product (e.g., a container data record containing data representing the amount of product currently stored in a particular container);

One or more container data records that identify data associated with previous states of the product (e.g., previous locations of the product, previous containers containing the product, and/or previous owners, and/or users of the product);

identifying a chain related to the product, such as a chain of quantity, location, container, owner, and/or user, based on the current container data record and one or more previous container data records;

Tracing the product through the identified chains (e.g., chain tracing of throughput, location, container, owner, and/or user) to identify any status of the product at a previous point in time; and/or

Determining whether any links in the chain are broken or missing, such as by determining whether links between the quantity, location, container, and/or entity (e.g., owner, or user) associated with the product are broken or missing.

Examples of broken or missing links in such a chain include two or more container data records (e.g., two or more consecutive data records) in such a chain that:

not indicating that ownership of the product is transferred from one entity to another, but indicating a different owner of the product;

No indication of the transfer of product occupancy from one entity to another, but a different occupancy of the product;

does not indicate any product being dispensed from the container, but indicates that the container contains different amounts of product;

No indication is made that any product has been filled into the container, but that the container contains a different amount of product.

Embodiments of the present invention may perform carbon credit verification based on one or more container data records (e.g., one or more container data records stored in a distributed ledger and/or one or more container data modules). Typically, performing such carbon credit validation may include, for example:

Receive a plurality of container data records (e.g., from a distributed ledger and/or one or more container data modules);

determining whether a carbon credit criterion is met based on the plurality of container data records; and

An output is generated and provided indicating whether the carbon credit criterion is met.

For example, such an output may indicate that the carbon credit criteria have been met or that the carbon credit criteria have not been met based on the results of the determination. As with any other method disclosed herein, such a carbon credit verification method may be performed (e.g., automatically) by one or more computer processors executing computer program instructions stored on one or more non-transitory computer readable media.

One way to determine whether the carbon credit criteria have been met is to determine whether a plurality of container data records indicate that the product within the labeled container has been applied to a particular geographic coordinate. For example, the plurality of container data records may include data representing an application time map representing a plurality of geographic coordinates at which the product has been applied. Embodiments of the present invention may determine whether a plurality of geographic coordinates in an applied map include particular geographic coordinates, such as those required for carbon credits. For example, the plurality of container data records may be stored in an external database, such as an external database of a distributed ledger (or containing or contained in a distributed ledger), or an external database of a non-distributed ledger (or not containing or contained in a distributed ledger). Determining whether the applied map indicates that the product is applied within a particular geographic coordinate may provide evidence or demonstration of such application for the purpose of meeting carbon credit criteria. However, embodiments of the present invention may verify that the product is applied for purposes other than carbon credit verification within specific geographic coordinates. Embodiments of the present invention may similarly be used to determine whether a plurality of container data records indicate that a product within a labeled container has not been applied to a particular geographic coordinate.

Any data stored by the first storage module 106 (e.g., any data stored in the external database 108, the container data record 110, the container data module 118, and/or the container data record 120) and/or any data stored by the second storage module 116 may be stored in encrypted form. As does any data disclosed herein.

The system 100 may update the container data record 110 and/or the container data record 120 at any of a variety of times and in response to any of a variety of events. For example, system 100 may update container data record 110 and/or container data record 120:

In response to meeting the time-related criteria, such as at a predetermined time (e.g., a predetermined time of day) or time (e.g., periodically, such as every second, minute, hour, day, week, or month), upon expiration of a timer (e.g., expiration of a timer after at least one second, minute, hour, day, week, or month has elapsed), or after a predetermined amount of time has elapsed since a last update (e.g., one second, minute, hour, day, week, or month);

in response to filling or dispensing any product (e.g., some or all of the first product 104) from the container 102;

responsive to meeting the movement-based criteria, such as responsive to any movement of the container 102, responsive to movement of the container 102 beyond a predetermined distance, responsive to movement of the container 102 from a predetermined location, or responsive to the container 102 reaching a predetermined location;

In response to a change in the owner, owner or user of the container 102.

Any such updating of container data record 110 and/or container data record 120 may update any of the various data in container data record 110 and/or container data record 120, for example, by updating data representing (e.g., changing, adding, or deleting) any one or more of the following:

The type of product stored in the container 102;

an amount related to the amount, such as the amount of product 104 filled into the container 102 in a filling operation, the amount of product 104 dispensed from the container 102 in a dispensing operation, the total amount of product 104 contained in the container 102, or the amount of space remaining in the container 102;

A location-related quantity, such as the current location of the container 102, the location of the container 102 when a particular operation (e.g., filling, dispensing, or change of owner/user) is performed, or the location of the container 102 at a particular time;

an identification of the owner, owner or user of the container 102, e.g., an identification of the current, previous and/or new owner, owner or user of the container 102.

The system 100 may store any such updated data, for example, by adding the updated data to the container data record 110 and/or the container data record 120. In some embodiments of the present invention, the system 100 generates and stores, at least in the external database 108, container data records representing all fill and dispense operations performed on the container 102. The system 100 may also generate and store a container data record representing all occupancy changes of the container 102, at least in a distributed ledger. In this way, the system may record a record of all significant changes to container 102 over time in a verifiable ledger, such as a verifiable chain of custody of product 154 and/or product 104. Thus, CDRs 110 and/or 120 can be used to verifiably trace any applied product (e.g., any product 104 applied from container 102) to its original point of manufacture (e.g., to a second product 154 in a second container 152), thereby preventing human error and fraud, and enabling carbon credit verification.

The system 100 may perform any number of such updates. For example, the container 102 may undergo many filling and dispensing operations, many changes in location, and many changes in owner/user. The system 100 may record each such event by updating the container data record 110 and/or the container data record 120. The result may be container history data that contains a large number (e.g., 10, 100, 500, or more) of container data records for the container 102.

The system 100 may time stamp and geotag each of the container data records 110 and/or 120, for example, by storing one or both of the following in each of the container data records 110 and/or 120:

Data representing a time associated with the container data record (e.g., a time of creation or modification of the container data record, or a time of an event represented by the container data record (e.g., a time of filling or dispensing product from the container 102, a time of movement of the container 102, or a time of change of an owner/user of the container 102)); and

Data representing the location associated with the container data record (e.g., the current location of the container 102, or the location of the container 102 when an event represented by the container data record occurs (e.g., filling or dispensing product from the container 102, moving the container 102, or changing the owner/user of the container 102).

Any data representing time (e.g., data representing the time of fill operation 202) stored in external database 108 and/or CDM 118 may be represented in any of a variety of ways, such as by a combination of date (e.g., a combination of year, month, and day) and time of day, or by a timestamp uniquely representing a point in time.

Any data representing a location (e.g., data representing a location of fill operation 202) stored in external database 108 and/or CDM 118 may be represented in any of a variety of ways, such as by coordinates obtained using Global Positioning System (GPS) technology or by a combination of latitude and longitude. One way to establish geographic coordinates associated with the population process may be to associate the IP address of the population operation with latitude/longitude information provided by a separate and independent global navigation system (e.g., google map).

Any updates to CDRs 110 and/or 120 can be performed automatically or semi-automatically. For example, when some or all of the first products 104 are dispensed from the first container 102, the system 100 may automatically detect that such dispensing is occurring or has occurred, automatically identify the type and amount of the first products 104 that have been dispensed from the first container 102 (e.g., by reading the type and amount of the first products 104 from the CDRs 110 and/or 120), and automatically store (in the CDRs 110 and/or 120) information about the dispensing, such as the type and amount of the products 104 dispensed; a ratio of product 104 dispensed from container 102; the location, date, and/or time of the allocation; and the owner, owner and/or user of the container 102 at the time of dispensing. The same applies to filling the first container 102 and other actions, such as moving the first container 102 (in which case the new position of the container may be automatically detected and stored in the CDRs 110 and/or 120).

Unless otherwise indicated herein, any information disclosed herein stored in external database 108 and/or CDM 118 may be stored in any of the following: (1) only an external database 108; (2) CDM 118 only; or (3) both external database 108 and CDM 118. As this means, some or all of the information disclosed herein may be stored in external database 108, but not in CDM 118.

The owner of the first container 102 at any particular time (e.g., the time the first container 102 is filled with the first product) may be the same as or different from the owner of the first container 102 at that particular time. For example, the owner of the first container 102 at the particular time may have legal ownership of the first container 102 at the particular time, but not occupy the first container 102 at the particular time, in which case a party other than the owner may occupy the first container 102 at the particular time. Likewise, the owner or owners of the containers 102 may be different at a particular time than the owners of the products 104 in the containers 102 at that particular time. For example, one entity may own a container ship while another entity may operate the container ship and may be considered to occupy the container without having the container, while another entity or person may own the product in the container that the first entity occupies while the second entity occupies.

Ownership of the first container 102 may change without physical movement of the first container 102, and the first container 102 may physically move without changing ownership or occupancy of the first container 102. Embodiments of the present invention may track and record values of one or more of the following attributes in any combination within CDM 118 and/or external database 108 of the container, as they may change over time and location: container ownership, container occupancy, and container location. For example, embodiments of the present invention may track and store any one or more of the following in any combination in CDM 118 and/or external database 108 of the container: (1) A first owner of the first container 102 at a first time and a second owner of the first container 102 at a second time, wherein the first owner is different from the second owner; (2) A first owner of the first container 102 at a first time and a second owner of the first container 102 at a second time, wherein the first owner is different from the second owner; and (3) a first position of the first container 102 at a first time and a second position of the first container 102 at a second time, wherein the first position is different from the second position. In all these cases, the first time may be different from the second time (e.g., the second time may be later than the first time).

When the first container 102 is loaded into an application device for dispensing some or all of the first product 104 from the first container 102 (e.g., onto a field or other area), the system 100 may read information from the container data records 120 in the container data module 118 and store at least some of the information in a non-transitory computer-readable medium on the application device (where the non-transitory computer-readable medium may itself be an example of a container data module). One benefit of reading such information from CDM 118 of container 102 is to eliminate operator error and operator fraud in generating a record of the contents of container 102 and the amount of product filled into container 102 and dispensed from container 102. Further, the application device may be configured to determine whether all necessary information has been read from CDM 118 of container 102. Such confirmation may be performed automatically or manually (e.g., by receiving input from an operator of the administration device indicating whether all necessary information has been read from CDM 118 of container 102). The application device may be configured to dispense product 104 from container 102 only if it has been determined that all necessary information has been read from CDM 118 of container 102.

By automatically recording the type and amount of product (including the first product 104 and possibly other products) that has been stored into and dispensed from each of the plurality of containers (e.g., the first container 102 and the second container 152), the location of such storage and dispensing, and the movement and transfer in space and time of ownership/occupancy/use of such containers, embodiments of the present invention may be used to enable an entity who has allocated carbon credits to farmers who have applied less fertilizer than using historical Best management practices (Best MANAGEMENT PRACTICE, BMP) to be confident (e.g., on CDM 118 and/or in external database 108) that the recorded information is accurate. Further, the entity purchasing carbon credits from farmers can be confident that they received the fees they paid, because establishing a verifiable and tamper-proof (or at least tamper-proof) carbon credit-related activity record can be used as evidence of actual reduction of greenhouse gas emissions. This reduces the hassle of purchasing carbon credits from someone but later knowing that the credits purchased to offset their own carbon footprint are not valid.

When a container is orphaned, i.e., when the current owner/owner of the container is unknown, embodiments of the present invention may be used to determine who may be the current or closest owner/owner of the container. For example, in this case, the unique container ID of the container may be read from CDM of the container. Embodiments of the present invention may associate the unique container ID with the same unique container ID stored in a data store external to CDM, such as an external database (e.g., an external database of a distributed ledger or an external database of a non-distributed ledger) or a distributed ledger intermediary. Once this association is performed, the unique container ID may be used to search the external data store for information about the current or closest owner/owner of the container, and any resulting information found in the external data store may be used to identify the current or closest owner/owner of the container. Or for example, if CDM of a container contains data representing the current or most recent owner/owner of the container, the owner/owner data may be read directly from CDM of the container to identify the current or most recent owner/owner of the container.

Embodiments of the present invention may track the number of multiple products within a single container. For example, after dispensing portions of the first product from the container, the container may be filled with one or more additional products to replace some or all of the removed first product. When this occurs, the amount of mixing of the ingredients may be tracked on the CDM and/or distributed ledger of the container, as may each individual component of the mixed material to the extent that tracking of the component is required. For example, if the pesticide is mixed within a labeled container, some or all of the individual EPA registered active ingredients included as ingredients of the mixed product contained within the container may be tracked without simultaneously tracking the various inert ingredients that are also constituent ingredients of the mixed/blended contents.

As a container of fill material (e.g., first container 102) moves through the supply chain, embodiments of the present invention may establish and maintain uninterrupted transaction records, for example, in order to generate quality of service records regarding the effectiveness of the application or consumption of the product or material in the container. If there is no uninterrupted chain of legal transactions, it may not be possible to verify the application records resulting from the application of the contents of the tracked container. For the application record to be created, the application device must be provided with information about the applied product. Historically, this information was provided by the applicator operator at the time of application, but as previously described, the operator's probability of error was great. In embodiments of the invention, information about the applied or consumed product may be transferred from CDM to the application device. Communication of the application product information from the CDM to the application device ensures that the information about the application product is consistent with the product information on the CDM, but in order to automatically authenticate or automatically verify that the product information on the CDM is accurate, uninterrupted product/material and container transaction records must be maintained (e.g., by a distributed ledger and/or a central database). One advantage of embodiments of the present invention is that they can be used to convince purchasers of carbon credits that a product that meets carbon credits is actually applied in conjunction with an application product record associated with the creation of the carbon credit being purchased.

Embodiments of the present invention may track and store each attribute individually and/or collectively with the purpose of creating and generating a comprehensive legal record of who owns or has owned the container, who now occupied the container, who occupied the container in the past, and where the container was located or was located at any given point in time. The owner of the container may also be different from the owner of the container contents. However, within a combined distributed ledger and/or CDM system, embodiments of the present invention may track ownership of content within a container of individual and/or mixed constituent content components, even though multiple owners are involved. The container can only be located in one place at a time and can only be occupied by one entity at a time (even if the owning entity has multiple owners), for example, entity a may own the container itself, while entity B may own product 1 within the container, while entity C may own product 2 within the same container. Product 1 and product 2 may maintain the integrity of their individual components within the container, or the quantities of product 1 and product 2 may be mixed together, with each entity continuing to have a tracked amount of the entity's contribution to the components of the mixed product, due to physical separation within the container via walls, bulkheads, partitions, etc. One advantage of embodiments of the present invention is that they may create a comprehensive, quality of service distributed ledger record that represents substantially all of the recordable attributes associated with each labeled container, such as, but not limited to, the container itself, the product and/or products within the container, and/or the entity that manufactured, all, filled, owned, used or distributed, transported, handled, disposed of, etc., the container or the contents of the container itself. Such a chain of legal custody may be necessary in order to be able to verify, for example, whether a time-stamped geo-administration/distribution record of an end user/consumer provided for obtaining carbon credits is accurate and consistent with the product actually administered or consumed when the time-stamped geo-administration record was created. To eliminate all doubts, embodiments of the present invention may be used to provide automatically generated chain of custody for each container and product within the container, and automatically generated transaction records for each transaction associated with the container and product within the container. It is important to understand that while each custody change may result in the generation and storage of a corresponding transaction record, some transactions may occur without custody change. Embodiments of the present invention provide a means for tracking all transactions so that uninterrupted chain of custody can be verified as an element within a larger body of transaction data.

Any of the systems and methods disclosed herein (e.g., system 100 and method 200) may defer storing data unless and until external database 108 is accessible over a network. For example, referring to FIG. 5, a schematic diagram of a system 500 for tracking a first product 104 in a first container 102 and for storing data about the first product in a container data module 118 until a network 502 becomes accessible is shown, according to one embodiment of the invention. Fig. 6 is a flow chart of a method 600 performed by one embodiment of the system 500 of fig. 5. The system 500 of fig. 5 includes elements from the system 100 of fig. 1. Any of the descriptions of these elements herein in connection with fig. 1 are equally applicable to the system 500 of fig. 5.

The system 500 includes a network 502, which network 502 may be any type of communication network, such as a local area network (Local Area Network, LAN) and/or a wide area network (e.g., the internet). Network 502 may include mechanisms for sending and receiving data via wires and/or wirelessly. Any of the techniques disclosed herein for storing data in the external database 108 using the first storage module 106 may include the first storage module 106 sending such data over the network 502, the external database 108 may receive such data and store the data in the external database 108. External database 108 may or may not be, include, or be included within a distributed ledger, as described elsewhere herein.

For example, the system 100 may include a computer 510 having at least one computer processor 512 and a first non-transitory computer readable medium 514 (labeled "memory" in fig. 5 for ease of illustration). The computer program instructions may be stored on a first non-transitory computer readable medium 514. When the computer processor 512 executes computer program instructions, the computer processor 512 performs methods defined by those computer program instructions, such as some or all of the method 600 of fig. 6.

The filling module 130 may fill the first container 102 with the first product 104 (operation 602 of fig. 6), for example, in any manner disclosed herein in connection with operation 202 of the method 200 (fig. 2). The first storage module 106 may receive data indicative of filling the first container 102 with the first product 104 (operation 604 of fig. 6). For example, the first memory module 106 may receive such data in the form of RFID signals received at RFID tags on the first container 102.

The first storage module 106 may determine whether the external database 108 is accessible through the network 502 (operation 606 of fig. 6). The first storage module 106 may make this determination in any of a variety of ways, such as by determining whether a network connection exists between the first storage module 106 and the network 502, or by determining whether a network connection exists between the first storage module 106 and the external database 108. If the first storage module 106 determines that the external database 108 is accessible via the network 502, the first storage module 106 may store the received data in the external database 108, such as in any of the manners disclosed above in connection with operation 204 of FIG. 2 (operation 608 of FIG. 6).

In response to determining that the external database 108 is not accessible through the network 502, the first storage module 106 may store the received data in a second non-transitory computer-readable medium (e.g., the non-transitory computer-readable medium 514) without accessing the network 502, which may include any data disclosed herein (e.g., any data disclosed herein as stored in operation 204) (operation 610 of fig. 6). Such storage may be performed, for example, without transmitting data over the network 502.

The second non-transitory computer readable medium (e.g., non-transitory computer readable medium 514) may be, for example, a local medium of the first container 102 and/or the first storage module 106, meaning that the second non-transitory computer readable medium may be accessed by the first storage module 106 without accessing the network 502. For example, a second non-transitory computer readable medium may be on the first container 102. For example, the second non-transitory computer readable medium may be the container data module 118, may contain the container data module 118, or may be contained within the container data module 118.

As a particular example, the second non-transitory computer readable medium may be in or on an administration device (e.g., an administration device that includes or is coupled to the first container 102 and/or the first storage module 106). Such an application device may comprise a computer comprising or coupled to a second non-transitory computer readable medium. As another example, the second non-transitory computer-readable medium may be a container data module in or coupled to the first container.

At some time after storing the received data in the second non-transitory computer readable medium, the first storage module 106 may determine that the external database 108 is accessible over the network 502, for example, by determining that a network connection has been established between the first storage module and the external database 108. In response to determining that the external database 108 is accessible via the network 502, the first storage module 106 may store some or all of the data previously stored in the second non-transitory computer-readable medium in at least one first record in the external database 108 (e.g., in the container data record 110) (operation 608 of fig. 6). The external database 108 may be, for example, a blockchain and the at least one first record may be at least one first block in the blockchain.

After determining that the external database 108 is not accessible through the network 502 and storing the received data in the second non-transitory computer readable medium, the first storage module 106 may again (e.g., after some delay, such as at least 10 seconds, 1 minute, or 10 minutes) determine whether the external database 108 is accessible through the network 502. If the first storage module 106 determines that the external database 108 is accessible via the network 502, in response to the determination, the first storage module 106 may store some or all of the data previously stored in the second non-transitory computer-readable medium in at least one first record in the external database 108 (e.g., in the container data record 110). Conversely, if the first storage module 106 does not determine that the external database 108 is accessible through the network 502, the first storage module 106 may again (e.g., after some delay) determine whether the external database 108 is accessible through the network 502. This process of determining whether the external database 108 is accessible over a network and storing only the received data in response to determining that the external database 108 is accessible over a network may be repeated any number of times.

The system 500 of fig. 5 and the method 600 of fig. 6, respectively, solve the technical problem of electronically storing data representing a product in a container even in the event that the electronic communication network (e.g., network 502) is not accessible. The system 500 and method 600 solve this technical problem by providing a technical solution in which data is stored in a local storage medium when an electronic communication network is not available, and then transmitted for remote storage over the electronic communication network when the electronic communication network becomes available. Certain embodiments of the system 500 and method 600 include the additional features of automatically and repeatedly determining whether an electronic communication network is available and automatically transmitting data over the electronic communication network for remote storage in response to determining that the electronic communication network has become available.

The above description describes storing received data in a second non-transitory computer-readable medium in response to determining that the external database 108 is not accessible via the network 502. Other embodiments of the invention may store the received data in a second non-transitory computer readable medium even though the external database 108 may be accessed through the network 502. For example, it is beneficial that even though the external database 108 may be accessible through the network 502, the received data may be stored in the second non-transitory computer readable medium for a period of time and then later stored in the external database 108, which may not be responsive to determining that the external database 108 is accessible through the network 502. For example, embodiments of the present invention may store received data in a second non-transitory computer readable medium, even though external database 108 may be accessed through network 502, to collect and store some minimal amount of such data prior to transmission of such data through network 502 for storage in external database 108, thereby reducing network utilization.

Referring to fig. 3A-3N, a swim lane diagram of a method for validating activity consistent with carbon credits is shown, according to one embodiment of the invention. Each row in fig. 3A-3N corresponds to a particular participant and illustrates the actions taken by that participant. In particular, the schematic diagrams of fig. 3A-3N contain rows corresponding to the following participants:

manufacturer of the product (e.g., synthetic nitrogen fertilizer or nitrogen fixation crop input);

The first owner of the container containing the product ("owner 1");

A second owner of the container containing the product ("owner 2");

An nth owner of the container containing the product ("owner N"), wherein any value is greater than or equal to zero (e.g., 0, 1, 2, 3, or greater);

End-owners (e.g., consumers or end-users) of the products ("end-owners");

An external database (e.g., a distributed ledger, e.g., blockchain) comprising one or more computer systems that can be written to and read from the external database; and

Container Data Module (CDM) associated with a container containing a product ("label container data module").

The method may begin (step 301) and include the following. The manufacturer manufactures product a (step 302). The manufacturer transfers a quantity of product a to a labeled container a (i.e., fills container a with a quantity of product a) (step 303). Note that the manufacturer in fig. 3A-3N may be the manufacturer of product a and/or the manufacturer of container a. Or the manufacturer in fig. 3A-3N may not be the manufacturer of product a or container a, but may be any party performing the functions shown in the lanes labeled "manufacturer" in fig. 3A-3N.

One or more records 5 are stored in an external database (step 304), the one or more records 5 containing data representing information about storing product a into container a. The storing in step 304 may be performed by any of the parties in any of a variety of ways. The following description of examples of the manner in which step 304 may be performed applies equally to other steps (i.e., steps 310, 313, 318, 321, 326, 329, 334, 337, 340, 348, and 351) in the method of fig. 3A-3N for storing data in a distributed ledger.

The particular data stored in the external database record 305 disclosed herein (as well as other external database records disclosed herein) is merely an example of such data and is not a limitation of the present invention. The record 305 may also include data other than the data stored in the record 305 as disclosed herein. Record 305 need not include all of the data disclosed herein as being stored in record 305.

For example, the storing in step 304 may be performed by the manufacturer, e.g., using one or more computing devices to communicate with an external database (e.g., over a network such as the internet), such that the record 305 is stored in the external database. For example, the computing devices used by the manufacturer to store records 305 in the external database may be different from the computing devices used by the other participants shown in fig. 3A-3N to store records 311, 314, 319, 322, 327, 330, 335, 338, 343, and 349 in the external data set.

As another example, a manufacturer may use one or more computing devices to transmit some or all of the information to be stored in record 305 (over a network, such as the internet) to another participant (e.g., one of the other participants shown in fig. 3A-3N, or a participant not shown in fig. 3A-3N), for simplicity, one or more computing devices being referred to herein as an external database intermediary. The external database intermediary may then communicate with the external database (e.g., over a network, such as the internet) such that the record 305 is stored in the external database. This use of the intermediary prevents the necessity of developing a computer application that allows each participant's computing device to communicate with and transact directly with an external database. One or more of the other participants shown in fig. 3A-3N may similarly use one or more computing devices to transfer some or all of the information to be stored in records 314, 319, 322, 327, 330, 335, 338, 343, and 349 (over a network, such as the internet) to the same external database intermediary, which may then communicate with an external database (e.g., over a network, such as the internet) such that the records are stored in the external database. In other words, the external database intermediary may act as a centralized mechanism for some or all of the participants in fig. 3A-3N to store records in the external database. Some of the participants in fig. 3A-3N may communicate directly (i.e., without using an external database intermediary) with the external database such that records are stored in the external database, while other participants in fig. 3A-3N may communicate indirectly with the external database through the external database intermediary such that records are stored in the external database.

The record 305 may contain any of a variety of data in any combination, such as data representing any one or more of the following:

one type of action represented by an external database entry, e.g. "Container initialization action"

The unique ID of container a.

The unique ID of the owner of container a (e.g., the unique ID of the manufacturer) at the time of filling in step 303.

Unique ID of product a.

The number of lots, quantity, date, time and location to transfer product a to container a in step 303.

Some or all of the information stored in external database record 305 may be stored in CDM for container a, such as in record 307 in CDM, or by otherwise updating CDM (step 306). For example, in step 306, the manufacturer may update CDM for container a using a computing device. Any of the teachings disclosed herein in connection with step 306 are equally applicable to the other CDM updates in fig. 3A-3N, i.e., steps 315, 323, 331 and 344.

Step 306 is optional and may be omitted from the methods of fig. 3A-3N. For example, CDM of container a may store data in the form of a bar code, QR code, or other non-updatable (static) data. For example, data representing information about container a may be stored in CDM of container a, such as a unique container ID of container a, prior to step 306 (even prior to the start 301 of the method of fig. 3A-3N). Embodiments of the present invention may read the container ID from CDM of container a and associate the container ID with a container ID stored elsewhere (e.g., in an external database) at any of a variety of times. For example, in addition to step 306 or instead of step 306, the manufacturer may store some or all of the information contained in external database record 305 in a data store other than the external database and CDM of container a, e.g., a database local to the manufacturer or remote from the manufacturer. Other updates to the external database shown in fig. 3A-3N may also be stored in such another data store and may contain the unique ID of container a. At any time, the manufacturer may read the container ID of container a from CDM of container a, associate the container ID with the container ID in one or more records stored in another data store, thereby retrieving information about container a that is not stored in CDM of container a.

An event triggers a transfer of occupancy of container a (step 308). The manufacturer transfers the occupancy of container a to owner 1 (step 309). Owner 1 may be, for example, a retailer of product a, but more generally any party performing the functions shown in the lanes labeled "owner 1" in fig. 3A-3N.

One or more records 311 are stored in an external database (step 310), the one or more records 311 containing data representing information about the occupancy of container a transferred from the manufacturer to the owner 1. The storing in step 310 may be performed by the manufacturer or any other party in any of the ways disclosed above in connection with step 304.

The record 311 may contain any of a variety of data in any combination, such as data representing any one or more of the following:

An action type represented by an external database entry, e.g. "chain of custody action"

The unique ID of container a.

Unique ID of owner 1.

Unique ID of product a.

The number of lots, quantity, date, time and location of container a transferred from manufacturer to owner 1.

Owner 1 accepts occupancy of container a (step 312). One or more records 314 are stored in the distributed ledger (step 313), the one or more records 314 containing data representing information about the occupancy of the recipient a by the owner 1. The storing in step 313 may be performed by owner 1 or any other party in any of the ways disclosed above in connection with step 304.

Record 314 may contain any of a variety of data in any combination, such as data representing any one or more of the following:

The unique ID of container a.

Unique ID of owner 1.

Unique ID of product a.

The owner 1 receives the lot number, date, time, and position stored in the container a.

Some or all of the information stored in external database record 314 may be stored in CDM for container a, such as in record 316 in CDM, or by otherwise updating CDM (step 315). Owner 1 may perform step 315 in any manner such as that disclosed above in connection with step 306. Step 315 is optional and may be omitted from the method of fig. 3A-3N, as described above in connection with the optional nature of step 306.

Owner 1 transfers the occupancy of container a to owner 2 (step 317). Owner 2 may be, for example, a farmer using product a, but more generally may be any party performing the functions shown in the lanes labeled "owner 2" in fig. 3A-3N. In practice, there may not be any owners 2. Thus, step 317 and other steps shown in the lanes labeled "owner 2" in fig. 3A-3N are optional and may be omitted from the methods of fig. 3A-3N.

One or more records 319 are stored in the distributed ledger (step 318), the one or more records 319 containing data representing information about the transfer of occupancy of container a from owner 1 to owner 2. The storing in step 318 may be performed by the manufacturer or any other party in any of the ways disclosed above in connection with step 310.

The record 319 may contain any of a variety of data, such as any data disclosed in connection with the record 311, except that the data in the record 319 may represent data that is represented as transferring the occupancy of the owner 1 to the owner 2 instead of transferring the occupancy from the manufacturer to the owner 1.

Owner 2 accepts the occupancy of container a (step 320). One or more records 322 are stored in the distributed ledger (step 321), the one or more records 322 containing data representing information about the occupancy of the recipient a by the owner 2. The storing in step 321 may be performed by owner 1 or any other party in any of the ways disclosed above in connection with step 313.

The record 322 may contain any of a variety of data, such as any data disclosed in connection with the record 314, except that the data in the record 322 may represent data that is represented as being accepted by the owner 2 instead of the owner 1.

Some or all of the information stored in external database record 322 may be stored in CDM for container a, such as in record 324 in CDM, or by otherwise updating CDM (step 323). Owner 2 may perform step 323, for example, in any of the ways disclosed above in connection with step 315. Step 323 is optional and may be omitted from the method of fig. 3A-3N, as described above in connection with the optional nature of step 306.

Owner 2 transfers the occupancy of container a to owner N (step 325). In practice, there may not be any owner N. Thus, step 325 and other steps shown in the lanes labeled "owner N" in FIGS. 3A-3N are optional and may be omitted from the methods of FIGS. 3A-3N. In practice, there may be more than one owner N. Thus, step 325 and other steps shown in the lanes labeled "owner N" in FIGS. 3A-3N may be performed multiple times, once for each of the plurality of owners. More generally, the lanes labeled "owner 1", "owner 2", and "owner N" in fig. 3A-3N are intended to illustrate that other parties occupying any number (i.e., one or more) of transfers from the manufacturer may be sequentially performed, and that the steps shown in each "owner" lane in fig. 3A-3N may be performed for each such owner.

One or more records 327 are stored in an external database (step 326), the one or more records 327 containing data representing information about the transfer of occupancy of container a from owner 2 to owner N. The storing in step 326 may be performed by the owner N or any other party in any of the ways disclosed above in connection with step 310.

Record 327 may contain any of a variety of data, such as any data disclosed in connection with record 311, except that the data in record 327 may represent data represented as occupying a transfer from owner 2 to owner N instead of occupying a transfer from the manufacturer to owner 1. For example, a wholesale owner may transfer the occupancy of a container to a retail owner, or a wholesale owner may transfer the occupancy to another wholesale owner.

Owner N accepts occupancy of container a (step 328). One or more records 330 are stored in an external database (step 329), the one or more records 330 containing data representing information about the occupancy of the recipient a by the owner N. The storing in step 329 may be performed by owner N or any other party in any of the ways disclosed above in connection with step 313.

Record 330 may contain any of a variety of data, such as any data disclosed in connection with record 314, except that the data in record 330 may represent data that is represented as being accepted by owner N, rather than owner 1.

Some or all of the information stored in external database record 30 may be stored in CDM for container a, such as in record 332 in CDM, or by otherwise updating CDM (step 331). Owner N may perform step 331 in any manner such as that disclosed above in connection with step 315. Step 331 is optional and may be omitted from the method of fig. 3A-3N, as described above in connection with the optional nature of step 306.

Owner N transfers the occupancy of container a to a customer or other end user, such as the consumer or applicator of the container (step 333). (for ease of explanation, the term "customer" is used herein to refer to any party receiving occupancy of container a and applying product a from container a.) if owner N is omitted from the method of fig. 3A-3N, the transfer in step 333 is to the customer from the nearest owner of container a (e.g., owner 1 or owner 2).

One or more records 35 are stored in the distributed ledger (step 334), the one or more records 35 containing data representing information about transferring occupancy of container a from owner N to the customer. The storing in step 334 may be performed by the customer or any other party in any of the ways disclosed above in connection with step 310.

Record 335 may contain any of a variety of data, such as any data disclosed in connection with record 311, except that the data in record 335 may represent data represented as occupying a transfer from owner N (or other nearest owner of container A) to a customer instead of occupying a transfer from a manufacturer to owner 1.

The customer accepts occupancy of container a (step 336). One or more records 338 are stored in an external database (step 337), the one or more records 338 containing data representing information regarding the occupancy of the customer recipient container a. The storing in step 337 may be performed by the customer or any other party in any of the ways disclosed above in connection with step 313.

Record 338 may contain any of a variety of data, such as any data disclosed in connection with record 314, except that the data in record 338 may represent data that is represented as accepted by a customer rather than owner 1.

Some or all of the information stored in external database record 338 may be stored in CDM for container a, such as in record 340 in CDM, or by otherwise updating CDM (step 339). The customer may perform step 339 in any manner such as that disclosed above in connection with step 315. Step 339 is optional and may be omitted from the method of fig. 3A-3N, as described above in connection with the optional nature of step 306.

When the present invention is used in conjunction with applying soil or applying a plant product, the customer consumes some or all of the product a from container a, for example by dispensing some or all of the product a in container a onto the field (step 341), or by simply operating the internal combustion engine when the present invention is used to track end user fuel consumption. One or more records 343 are stored in the distributed ledger (step 342), the one or more records 343 containing data representing information about the consumer's consumption of product a from container a. The storing in step 342 may be performed by the customer or any other party in any of the ways disclosed above in connection with step 304.

The record 343 may contain any of a variety of data in any combination, such as data representing any one or more of the following:

An action type represented by an external database entry, e.g. "consumer action"

The unique ID of container a.

The unique ID of the owner of container a at the time of consumption (e.g., the unique ID of the customer) in step 341.

Unique ID of product a.

The number of lots, quantity, date, time and location of consumed product a in step 341. The data may include, for example, data representing multiple consumptions (e.g., disperses) of product a from containers a at multiple locations, for example, in the form of consumption records applying maps or geographic markers, as disclosed elsewhere herein.

Some or all of the information stored in external database record 343 may be stored in CDM of container a, such as in record 345 in CDM, or by otherwise updating CDM (step 344). The customer may perform step 344 in any of the ways disclosed above in connection with step 315, for example. Step 344 is optional and may be omitted from the method of fig. 3A-3N, as described above in connection with the optional nature of step 306.

If container A is a returnable container (step 346), the method of FIGS. 3A-3N may include and execute steps 347-351. If container A is not a returnable container, the method of FIGS. 3A-3N may not include or perform steps 347-351.

If container A is a returnable container, the customer transfers the occupancy of container A to the previous owner of container A, such as manufacturer, owner 1, owner 2, or owner N (step 347). For ease of illustration and explanation, fig. 3A-3N illustrate the transfer of occupancy by a customer to a manufacturer. More generally, however, the customer may return to container a by transferring the occupancy of container a to any of the parties shown in fig. 3A-3N (e.g., owner 1 or owner 2).

One or more records 349 are stored in the distributed ledger (step 348), the one or more records 349 containing data representing information regarding the transfer of occupancy of container a from a customer to a previous owner (e.g., manufacturer). The storing in step 348 may be performed by the previous owner or any other party in any of the ways disclosed above in connection with step 310.

Record 349 may contain any of a variety of data, such as any data disclosed in connection with record 311, except that the data in record 349 may represent data represented as occupying a transfer from a customer to a previous owner (e.g., manufacturer) rather than occupying a transfer from the manufacturer to owner 1.

The previous owner (e.g., manufacturer) accepts the occupancy of container a (step 350). One or more records 352 are stored in the distributed ledger (step 351), the one or more records 352 containing data representing information about previous owners accepted occupancy of container a. The storing in step 351 may be performed by the previous owner or any other party in any of the ways disclosed above in connection with step 313.

The record 352 may contain any of a variety of data, such as any data disclosed in connection with the record 314, except that the data in the record 352 may represent data that is represented as accepted by a customer rather than the owner 1.

Regardless of whether container a may be returned (i.e., whether the method of fig. 3A-3N performed steps 347-351), the method of fig. 3A-3N generates a final report of available authentication data in an external database relating to container a, e.g., for purposes of carbon credit verification. The final report may include various information, such as one or more of the following in any combination:

Indication and/or confirmation of consistent occupancy of container a at each stage in the chain of custody of container a. For example, if the external database indicates that the occupancy of container a is transferred from owner 1 to owner 2 and then from owner 2 to owner N, the report will indicate that the owners are consistent, whereas if the external database indicates that the occupancy of container a is transferred from manufacturer to owner 1 and then from owner 2 to owner N, the report will indicate that the owners are inconsistent.

Indication and/or confirmation of the type of product stored in container a being consistent throughout the history of container a. For example, if the external database indicates that container a is filled with product a and then indicates that container a later contains product B, without any record indicating that container a is filled with product B, the report will indicate that the types of products stored by container a are inconsistent.

Indication and/or confirmation that the amount of product a administered reported by the administration device matches the agronomic prescription (see fig. 4A-4P below).

Indication and/or confirmation that the geographic location of application reported by the application device matches the geographic boundary of the agronomic prescription (see fig. 4A-4P below).

The methods of fig. 3A-3N may be used to verify carbon credit practices in any of a variety of ways. For example, if any of the following conditions cannot be satisfied during or after the method of fig. 3A-3N, the satisfaction of the carbon credit condition cannot be confirmed:

the validated product used must be equal to the ledger entry from the manufacturer.

The amount used must be less than or equal to, but not greater than, the amount of chain of custody verification.

The application device cannot apply more than the product initially held and identified by the manufacturer and owner.

The geographic location of the product usage must match the geographic boundaries of the application location of the prescription.

Embodiments of the present invention may use computer-implemented methods and/or systems to determine whether such conditions are automatically met to verify carbon credit practices in whole or in part. For example, the computer-implemented method and/or system may determine whether one or more of the above conditions are met based on the contents of an external database. If it is determined that one or more of the above conditions are not met, the method and/or system may conclude that carbon credits are not guaranteed. As a particular additional example, the method and/or system may:

Identifying a plurality of records in an external database indicating operations to fill the container with a particular product, and calculating a sum of the amounts of product filled in such filling operations to produce a first measure of the current amount of the current particular product in the container.

A second measure identifying the current amount of the particular product in the container, for example by identifying a record in an external database, indicating the current amount of the particular product in the container, or by measuring the current amount of the particular product in the container independently of the content of the external database (e.g. by weighing the container).

Determining whether the first metric of the current quantity of the particular product in the current container is sufficiently similar to the second metric of the particular product in the current container. As an example, the first metric and the second metric may be considered sufficiently similar to each other if they are equal to each other, or if they differ from each other by no more than some predetermined amount or some predetermined percentage.

If the first and second metrics are determined not to be sufficiently similar to each other, then it is concluded that carbon credits are not guaranteed.

* Referring to fig. 4A-4P, a swim lane diagram of a method for validating activity consistent with carbon credits is shown, in accordance with another embodiment of the present invention. The methods of fig. 4A-4P are example uses of the methods of fig. 3A-3N and are presented merely as examples to aid in understanding and not limiting the invention. Each row in fig. 4A-4P corresponds to a particular participant and illustrates the actions taken by that participant. In particular, the schematic diagrams of fig. 4A-4P contain rows corresponding to the following participants:

Retailers of the products;

farmers (or other consumers) of the products;

an agrologist who formulates a product usage prescription;

product usage data tracking systems (e.g., the Ultimus system available from AMVAC chemical company) for tracking data related to one or more containers, such as the type and amount of product filled into and dispensed from the containers;

Container Data Module (CDM) of the container (e.g., RFID tag).

The product usage data tracking system may be implemented in any of a variety of ways. For example, it may include a Software system accessible from one or more computing devices over one or more networks (e.g., as a Software-as-a-service (SaaS) product). The data regarding the containers and/or products filled into and/or applied from the containers may be stored by the product usage data tracking system at one or more locations remote from the containers, such as on one or more servers remote from the containers. The product usage tracking system may include one or more computers and other devices that are local devices to the container containing the product, such as a computer on an application device that applies the product, and that are capable of reading data from and writing data to a Container Data Module (CDM) (e.g., an RFID tag) associated with (e.g., contained within or coupled to) the container. Each such computer may include appropriate client software to enable the computer to act as a client in communication with one or more servers of the product usage data tracking system over a network. As a particular example, RFID scanning software may be executed on a handheld computing device that may read data from CDM (e.g., RFID tag) associated with a container and transmit the data over a network to a server of a product usage data tracking system, which may remotely store the data from the container.

The method may begin (step 401) and include the following:

Manufacturer produces product a (step 402).

The manufacturer transfers a quantity of product a to container a (i.e., fills container a with a quantity of product a) (step 403).

The product usage data tracking system identifies data in any combination, such as any one or more of the following: the unique ID of container A, the unique ID of product A, the lot ID of product A, the number of product A transferred to container A in step 403, the date product A was transferred to container A in step 403, the time product A was transferred to container A in step 403, and the location of product A was transferred to container A in step 403 (step 404).

The product usage data tracking system generates an external database entry 406 and causes the external database entry 406 to be stored in an external database, the external database entry 406 containing data representing filling of the container a with the product a (step 405). For example, the external database entry may contain data representing any one or more of the following in any combination:

an action type represented by an external database, e.g. "Container initialization action"

The unique ID of container a.

The unique ID of the owner of container a at the time of filling in step 403.

Unique ID of product a.

The lot number, quantity, date, time and location data described above.

The product usage data tracking system may store a record 408 in CDM of container a, the record 408 containing some or all of the data stored in the external database entry in step 405 (step 407).

The farmer interacts with the farmer and/or retailer regarding the farmer's demand for product a (step 409). The farmer creates an electronic prescription (also called a product demand file) defining where and at what rate a particular product should be applied (e.g., a shape file) within the boundaries of a particular agricultural field, or a demand document for product a (step 410). The farmer (e.g., login via authentication) uploads the prescription to the product usage data tracking system (step 411). For example, the prescription may include one or more of the following in any combination: defining a geographical boundary of a field; a unique product ID for each of the one or more products specified by the prescription (e.g., product ID for product a); application rate; and the ID of the crop.

The product usage data tracking system receives the prescription (step 412), creates an external database entry 414 containing some or all of the information contained therein (plus an indication of the type of action represented by the external database entry, e.g., a "product demand action") (step 413), and stores the external database entry 14 in the external database. The product usage data tracking system calculates an enhanced prescription file container in any combination of one or more of the following (step 415):

acres to which product a was applied;

the amount of product required; and

The number of containers needed to store product a.

The product usage data tracking system creates an external database entry 417, the external database entry 417 containing some or all of the data in the enhanced prescription file (plus an indication of the type of action (e.g., "product demand action") represented by the external database entry) (step 416), and stores the external database entry 417 in an external database.

The farmer receives the enhanced prescription file from the product usage data tracking system (step 418). The retailer receives notification of the enhanced prescription file from the product usage data tracking system; the amount of fertilizer required; and storing the number of containers required for the specified amount of fertilizer (step 419). The retailer orders from the manufacturer the number of label containers pre-filled with product a (step 420). The manufacturer receives the retailer's request for the tag container (step 421) and in response, transfers the occupancy/custody of the tag container a to the retailer (step 422) and ships the tag container a to the retailer (step 426). The retailer accepts occupancy/custody of the label container a (step 427).

Once the product usage data tracking system knows the location and owner of container a after transferring the occupancy/custody of container a to the retailer (step 423), which can read from, write to, or generally communicate with CDM of container a, e.g., using a device (e.g., handheld or mounted at a doorway or at any location such as on or within a building or vehicle), the product usage data tracking system creates an external database entry 425 that contains information about the chain of custody of container a, e.g., data indicating that the occupancy of container a is transferred from the manufacturer to the retailer, and an indication of an action (e.g., a "chain of custody action") represented by the distributed ledger entry 425 (step 424). The product usage data tracking system may also update CDM for container a with some or all of the information contained in external database entry 425, creating a record in CDM for container a.

The retailer accepts occupancy/custody of container a (step 427). Once the product usage data tracking system knows the location and owner of container A after the retailer accepts the occupancy/custody of container A (step 428), the product usage data tracking system creates an indication (step 429) that contains information about the chain of custody of container A (e.g., data indicating that the retailer has confirmed custody of container A, and an action represented by external database entry 430 (e.g., a "chain of custody action").

The retailer transfers the occupancy/custody of container a to the farmer (step 433). Once the product usage data tracking system knows the location and owner of container A after the farmer accepts the occupancy/custody of container A (step 434), the product usage data tracking system creates an external database entry 436 that contains information about the chain of custody of container A (e.g., data indicating that the retailer has transferred the occupancy/custody of container A to the farmer, and an indication of the action represented by external database entry 436 (e.g., the "chain of custody action") (step 435). The product usage data tracking system may also update CDM of container a with some or all of the information in external database entry 436, creating record 38 in CDM of container a (step 437).

The retailer delivers container a to the farmer (step 439). Farmers accept the occupation/custody of container a (step 440). The farmer installs container a on the application device and validates container a (step 441). The farmer or farmer uploads the enhanced prescription file to the application device (step 442).

The farmer applies or consumes the product a in container a (step 443). In step 443, the farmer's application device (e.g., planter) automatically updates CDM of container a with information about the application/consumption of product a, such as by storing any one or more of the following in CDM of container a in any combination, thereby creating record 445 in CDM of container a: the rate of application, the product applied, latitude and longitude, date and time. The farmer's application device stores some or all of the data in the record 445 (as well as an indication of the action represented by the data (e.g., the "product consuming action") in an entry 446 of an external database.

If container A is returnable (step 447 a), the method of FIGS. 4A-4P proceeds to step 447b, where the farmer transfers the occupancy/custody of container A to the retailer (step 447 b); otherwise, the method ends (step 467).

If container A is returnable, the retailer accepts occupancy/custody of container A (step 448). Once the product usage data tracking system knows the location and owner of container A after the retailer accepts occupancy/custody (step 449), the product usage tracking system creates an external database entry 451 containing information about the chain of custody of container A (e.g., data indicating that the retailer has confirmed the owner of container A, the unique ID of the farmer, data indicating that the farmer has returned container A to the retailer, the unique ID of the product ID, the number of products A returned to container A, and an indication of the action (e.g., "chain of custody action") represented by external database entry 451) (step 450).

The retailer transfers the occupancy/custody of container a to the manufacturer (step 456). The manufacturer accepts the occupancy/custody of container a (step 457). Once the product usage data tracking system knows the location and owner of container A after the retailer has transferred the occupancy/custody of container A to the manufacturer (step 458), the product usage data tracking system creates an external database entry 460 containing information about the chain of custody of container A, such as data indicating that the retailer has transferred the occupancy/custody of container A to the manufacturer, and an indication of an action (e.g., a "chain of custody action") represented by the distributed ledger entry 460 (step 459).

The manufacturer performs a container return process (step 461), which may include any one or more of the following steps (step 462) in any combination:

The reader reads CDM of container a and confirms the amount of product used (e.g., by weighing container a using a physical scale and comparing the resulting weight to the weight indicated by the data in CDM of container a).

A global information system (Global Information System, GIS) (e.g., on the application device) establishes and confirms the location (e.g., latitude and longitude) at which product a is applied from container a based on data in CDM of container a.

Compare the location of product a applied from container a (based on data in CDM of container a) to the GEO location of the expected field determined in the prescription.

Farmers using container a were confirmed using the farmer ID in CDM of container a.

Based on the data in CDM of container a, confirm the date and time of application of product a from container a.

The product usage data tracking system tracks, stores, and reports all usage data (step 463). For example, data from CDM of container a may be captured locally to container a (e.g., using a handheld RFID scanner) and then transmitted over a network (in addition to other data, such as a reading of the weight of container a from a scale) to a remote server that stores the data from container a remotely.

The product usage data tracking system creates an external database entry 65, the external database entry 65 containing data indicating that the manufacturer has confirmed product usage (step 464).

The product usage data tracking system generates a final report indicating that the verified data is available (step 466). The method ends (step 467).

It should be understood that while the invention has been described above in terms of specific embodiments, the foregoing embodiments are provided by way of illustration only and are not intended to limit or restrict the scope of the invention. Various other embodiments, including but not limited to the following, are also within the scope of the claims. For example, the elements and components described herein may be further divided into additional components or connected together to form fewer components for performing the same functions.

Any of the functions disclosed herein may be implemented using means for performing the functions. Such means include, but are not limited to, any of the components disclosed herein, such as the computer-related components described below.

The techniques described above may be implemented, for example, in hardware, one or more computer programs tangibly stored on one or more computer-readable media, firmware, or any combination thereof. The techniques described above may be implemented in one or more computer programs executing on (or executable by) a programmable computer comprising any combination of any number of the following: a processor, a storage medium readable and/or writable by the processor (including, for example, volatile and non-volatile memory and/or storage elements), an input device, and an output device. Program code may be applied to inputs entered using the input device to perform the functions described and to generate output using the output device.

Embodiments of the invention include possible and/or practical features implemented solely by using one or more computers, computer processors and/or other elements of a computer system. Such features are not possible or practical to implement mentally and/or manually. For example, embodiments of the present invention may read and write data to electronic memory devices (e.g., RFID tags) and/or distributed ledgers (e.g., blockchains), functions that cannot be performed mentally or manually.

Any claims herein that positively require a computer, processor, memory, or similar computer-related element are intended to claim such element, and should not be construed as absent from or claimed by such claim. Such claims are not intended to, and should not be interpreted as, encompassing methods and/or systems lacking the enumerated computer-related elements. For example, any method claims herein recite a method performed by a computer, a processor, a memory, and/or similar computer-related elements, and are intended to, and should only be interpreted to, include the method performed by the recited computer-related elements. For example, such method claims should not be construed to include methods performed mentally or manually (e.g., using pencils and paper). Similarly, any product claims herein recite an article of manufacture comprising a computer, a processor, a memory, and/or similar computer-related elements, and are intended to, and should only be construed to, include the article of manufacture comprising the recited computer-related elements. For example, such a product claim should not be construed to include a product that does not include the recited computer-related elements.

Each computer program within the scope of the following claims may be implemented in any programming language, such as assembly language, machine language, a high-level procedural programming language, or an object-oriented programming language. The programming language may be, for example, a compiled or interpreted programming language.

Each such computer program may be embodied in a computer program product tangibly embodied in a machine-readable storage device for execution by a computer processor. The method steps of the invention may be performed by one or more computer processors executing a program tangibly embodied on a computer readable medium to perform the functions of the invention by operating on inputs and producing outputs. Suitable processors include, by way of example, both general and special purpose microprocessors. Generally, a processor receives (reads) instructions and data from a memory (e.g., read-only memory and/or random access memory) and writes (stores) the instructions and data to the memory. Storage devices suitable for tangibly embodying computer program instructions and data include, for example, all forms of non-volatile Memory, such as semiconductor Memory devices, including EPROM (erasable programmable read-Only Memory), EEPROM (charged erasable programmable read-Only Memory (ELECTRICALLY ERASABLE PROGRAMMABLE READ-Only Memory)), and flash Memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disk; CD-ROM (compact disc read Only Memory (Compact Disc Read-Only Memory)). Any of the above may be supplemented by, or incorporated in, specially-designed ASICs (application-specific integrated circuits) or FPGAs (Field-Programmable gate arrays GATE ARRAY). A computer may also typically receive (read) and write (store) programs and data from and to a non-transitory computer-readable storage medium such as an internal magnetic disk (not shown) or a removable disk. These elements will also be found in conventional desktop or workstation computers, as well as other computers suitable for executing computer programs adapted for carrying out the methods described herein, which may be used in conjunction with any digital print engine or marking engine, display monitor or other device capable of producing color or gray scale pixels on paper, film, display screen or other output medium.

Any of the data disclosed herein may be implemented, for example, in one or more data structures tangibly stored on a non-transitory computer-readable medium. Embodiments of the present invention may store such data in, and read such data from, such data structures.

Any steps or acts disclosed herein as being performed or capable of being performed by a computer or other machine may be performed automatically by a computer or other machine, whether or not explicitly disclosed herein. The steps or actions performed automatically are performed solely by a computer or other machine without human intervention. For example, the automatically performed steps or actions may operate solely according to input received from a computer or other machine, rather than from a human being. For example, the automatically performed steps or actions may be initiated by signals received from a computer or other machine, rather than from a human being. The automatically performed steps or actions may, for example, provide output to a computer or other machine instead of to a human.

The terms "a or B", "at least one of a and B", "at least one of a or B", or "one or more of a and/or B" as used in various embodiments of the present disclosure include any and all combinations of words recited therewith. For example, "a or B", "at least one of a and B" or "at least one of a or B" may mean: (1) comprising at least one A, (2) comprising at least one B, (3) comprising A or B, or (4) comprising at least one A and at least one B.

Claims

1. A method performed by at least one computer processor executing computer program instructions stored on at least one first non-transitory computer readable medium, the method comprising:

(A) In response to filling the first container with the first product, storing data in at least one first record in an external database, the data representing:

a product type of the first product;

an amount of the first product filled into the first container;

A unique identification of the first container; and

A unique identification of a first user of the first container while filling the first container with the first product; and

(B) Data representing a unique identification of the container data module is stored in a container data module on the first container.

2. The method of claim 1, further comprising:

(C) Establishing provenance of the first product based on data stored in at least one of (a) and (B).

3. The method of claim 2, wherein (C) comprises establishing provenance of the first product based on the data stored in the external database in (a).

4. The method of claim 2, wherein (C) comprises establishing provenance of the first product based on the data stored in the container data module in (B).

5. The method of claim 2, wherein (C) comprises establishing provenance of the first product based on the data stored in (a) in the external database and the data stored in (B) in the container data module.

6. The method of claim 1, wherein (a) further comprises:

In response to filling the first container with the first product, data representing a unique identification of a first owner of the first container when the first container is filled with the first product is stored in at least one first record in the external database.

7. The method of claim 1, wherein (a) further comprises:

In response to filling the first container with the first product, data is stored in at least one first record in the external database representing a first location of the first container when the first container was filled with the first product.

8. The method of claim 1, wherein (a) further comprises:

In response to filling the first container with the first product, data representing a first time of filling the first container with the first product is stored in at least one first record in the external database.

9. The method of claim 1, wherein (a) further comprises:

10. The method of claim 9, further comprising:

(C) Data representing a second owner of the first container is stored in at least one second record of the external database, wherein the first owner is different from the second owner.

11. The method of claim 1, further comprising:

(C) In response to filling the first container with the first product, storing in electronic memory on the container at least one of:

a product type of the first product;

an amount of the first product filled into the first container;

A unique identification of the first container; and

A unique identification of a first user of the first container when the first container is filled with the first product.

12. The method of claim 11, wherein the container data module comprises the electronic memory.

13. The method of claim 11, further comprising:

(D) Before (C), wirelessly receiving a signal representing data stored in (a) at an RFID tag on the first container.

14. The method of claim 1, wherein the container data module is a non-electronic container data module, and wherein storing data representing the unique identification of the container data module comprises storing data representing the unique identification of the container data module in a non-electronic form on the container data module.

15. The method of claim 14, wherein storing data representing the unique identification of the container data module on the container data module in a non-electronic form comprises storing the unique identification of the container data module as a bar code on the container data module.

16. The method of claim 14, wherein storing data representing the unique identification of the container data module on the container data module in a non-electronic form includes storing the unique identification of the container data module as a QR code on the container data module.

17. The method of claim 1, further comprising:

(C) Data representing a second location of the first container is stored in at least one second record of the external database, wherein the first location is different from the second location.

18. The method of claim 1, further comprising:

(C) After dispensing at least some of the first product from the first container, data representing the dispensing is stored in at least one second record in the external database.

19. The method of claim 18, wherein the data representative of the dispensing comprises data representative of an amount of the first product dispensed from the first container.

20. The method of claim 18, wherein the data representative of the dispensing comprises data representative of an amount of the first product remaining in the first container after the dispensing.

21. The method of claim 18, wherein the data representing the dispensing comprises data representing a type of the first product dispensed from the first container.

22. The method of claim 18, wherein the data representing the allocation comprises data representing a unique identification of an owner of the first container at the time of the allocation.

23. The method of claim 18, wherein the data representing the allocation comprises data representing a unique identification of an owner of the first container at the time of the allocation.

24. The method of claim 18, wherein the data representing the dispensing comprises data representing a second location of the first container at the time of the dispensing, wherein the second location is different from the first location.

25. The method of claim 18, wherein the data representing the dispensing comprises data representing a ratio of dispensing the first product from the first container.

26. The method of claim 18, wherein the dispensing comprises dispensing at least some of the first product at each of a plurality of locations L, and wherein (C) comprises:

For each of the plurality of locations L, storing in data representing the allocation: (1) Data representing the amount of the first product dispensed from the first container at location L; and (2) data representing the location L.

27. The method of claim 26, wherein (C) further comprises:

For each of the plurality of locations L, storing in data representing the allocation: (3) Data representing the ratio of product dispensed from the container at location L.

28. The method of claim 26, further comprising:

(D) Determining whether a carbon credit criterion is met based on at least one first record in the external database and at least one second record in the external database; and

(E) An output is generated indicating whether the carbon credit criteria have been met.

29. The method of claim 1, further comprising:

(C) Prior to (a), filling the first container with the first product in a tamper-proof manner.

30. The method of claim 1, further comprising:

(C) After transferring at least some of the first products from the first container to a second container, data representing the transfer is stored in at least one second record in the external database.

31. The method of claim 1, wherein (a) comprises storing the data in the external database in encrypted form.

32. The method of claim 1, wherein the first product comprises a fertilizer.

33. The method of claim 1, wherein the first product comprises an insecticide.

34. The method of claim 1, wherein the first product comprises a nitrogen-fixing microorganism.

35. The method of claim 1, wherein the first product comprises a seed.

36. The method of claim 1, wherein the first product comprises a petroleum-based fuel.

37. The method of claim 1, wherein the first product comprises an agricultural crop input product.

38. The method of claim 1, wherein the external database comprises a distributed ledger.

39. The method of claim 38, wherein the distributed ledger comprises a blockchain, and wherein the at least one first record comprises at least one first block in the blockchain.

40. The method of claim 1, wherein the external database does not include a distributed ledger.

41. The method of claim 40, further comprising:

(C) After (a), storing the product type, the quantity of the first product, the unique identification of the first container, and the unique identification of the first user of the first container in a distributed ledger.

42. The method of claim 1, wherein filling the first container with the first product comprises transferring the first product from a source container to the first container, and

Wherein (a) comprises reading a product type of the first product from a container data module on the source container.

43. The method of claim 1, wherein (a) comprises:

reading a unique identification of the first container from a container data module on the first container; and

After reading the unique identification of the first container from the container data module on the first container, the unique identification of the first container is stored in at least one first record in the external database.

44. The method of claim 1, wherein (a) comprises:

automatically obtaining a first location of the first container from an automatic geolocation service; and

After obtaining the first location of the first container from the automatic geolocation service, the first location of the first container is stored in at least one first record in the external database.

45. The method of claim 1, wherein (a) comprises measuring an amount of the first product filled into the first container based on a number of revolutions of a motor in a product dispensing module that dispenses the first product into the first container.

46. A system comprising at least one first non-transitory computer-readable medium having computer program instructions stored thereon, the computer program instructions being executable by at least one computer processor to perform a method comprising:

a product type of the first product;

an amount of the first product filled into the first container;

A unique identification of the first container; and