Patent Application
20220351276
The present disclosure relates generally to equipment and marketplace tracking and operations, and more particularly to systems and methods for equipment tracking and operations via digital distributed ledgers.
This section is intended to introduce the reader to various aspects of art that may be related to various aspects of the present disclosure, which are described and/or claimed below. This discussion is believed to help provide the reader with background information to facilitate a better understanding of the various aspects of the present disclosure. Accordingly, it is understood that these statements are to be read in this light, and not as admissions of prior art.
Various entities, including operators of equipment (e.g., farming equipment) may engage in various operations (e.g., planting, harvesting) that may be logged, for example, for subsequent reporting. For example, an agricultural vehicle may tow a seeder/planter to create a trench in the soil, deposit seeds, and fill the trench. Likewise, a harvesting vehicle may reap, thresh, and/or winnow a crop during harvesting operations. Crops may then be sold in a marketplace. It would be beneficial to improve equipment and marketplace operations and/or reporting.
The techniques described herein are generally directed at creating and/or using a digital distributed ledger-based system (e.g., blockchain-based system) to improve operations, reporting, and/or analysis of equipment. While the techniques described herein use farming equipment as an example, equipment may include industrial equipment, mining equipment, power generation equipment, automotive equipment, and so on. The digital distributed ledger may provide an immutable data repository that may then be leveraged for equipment verification, logging of operations, financial recordkeeping, data analysis of operation, maintenance, authentication, and the like. For example, operations of equipment (e.g., farming equipment) may produce data logs that may be now stored in the digital distributed ledger and that may be authenticated as being produced by a specific equipment, at a given time and date. Likewise, an equipment service provider, such as an equipment maintainer, may now enter information into the digital distributed ledger, including parts maintained/replaced, type of maintenance work done, cost of maintenance, and so on, and verify that the work was done by entering their authentication information. Other participants in the digital distributed ledger-based system include equipment manufacturers, equipment operators, data analysts, financial entities, governmental agencies, regulatory agencies, and the like, which may be authenticated to participate in an authenticated and validated ecosystem provided via the digital distributed ledger, as further described below.
The techniques described herein also include the creation of production logs or “trails” and market logs or “trails”, as well as providing for digital ledger-based market that would enable the tracking of production items (e.g., farm crops), buyers, sellers, and so on, as well as the purchasing of data, data analytics, services, products (including virtual products) as further described below. Accordingly, a product, such as agricultural produce, may now have a verifiable, auditable, and immutable trail that includes a more comprehensive history of the product from seeds used, ambient conditions (e.g., weather), operator that applied the seed, equipment used, fertilizer used, harvesting date, harvesting equipment used, storage log (storage facility used, ambient conditions), transport log (transport vehicle used, ambient conditions), distributor, and so on. Likewise, a marketplace, such as a cloud-based marketplace, for data and data analytics based on the product, as well as for the product itself, may now be created with verifiable and immutable transaction records.
A digital distributed ledger, such as a blockchain, may thus be used to provide an immutable or otherwise unchangeable record of certain operations, logs, documents, reports, analysis, transactions, and so on, related to equipment associated with the digital distributed ledger. The digital distributed ledger-based system may further provide for crypto security features and for records that may be verified to provide for enhanced security and trust. Additionally, certain ledger entries may be automatically stored, signed and updated through blockchain techniques, eliminating middlemen and providing for enhanced transactional efficiencies.
It is appreciated that implementations in accordance with the present disclosure can include any combination of the aspects and features described herein. That is, implementations in accordance with the present disclosure are not limited to the combinations of aspects and features specifically described herein, but also include any other appropriate combinations of the aspects and features provided.
The details of one or more implementations of the present disclosure are set forth in the accompanying drawings and the description below. Other features and advantages of the present disclosure will be apparent from the description and drawings, and from the claims.
Embodiments of the present disclosure may include systems, devices, methods, and computer-readable media for creating, maintaining, and updating equipment and equipment-related entities (e.g., manufacturer, owner, operator, service provider, data analyst, financial entity, governmental agency, regulatory agency, etc.) interaction information, authentication information, and the like, via digital distributed ledgers. In some embodiments, one or more digital ledgers may be implemented to include equipment “trails” and entity “trails.” In use, information may be tagged as belonging to a specific equipment (e.g., a tractor that may be identified by vehicle identification number (VIN)), equipment type, equipment manufacturer, equipment owner, equipment service provider, data analyst, and the like, and stored in a digital distributed ledger via the trails. The trail information may be linked, thus providing for a chain or trail for a given equipment. For example, a physical description of the equipment may be linked to manufacturing information describing when, where, by whom, and by what process (e.g., additive manufacturing, milling, assembly processes, etc.) equipment and equipment parts have been manufactured. During equipment operations, e.g., farming operations, log data such as seed type, seed deposition rates, soil type, soil humidity, soil pH, soil temperature, weather data (e.g., humidity, air temperature, wind speed, wind direction, solar radiation, sun exposure), vehicle speed, vehicle direction, vehicle position (e.g., latitude, longitude), vehicle orientation (e.g., driving forward, driving backward), and so on, may be stored in the digital distributed ledger.
Likewise, harvesting records may be logged via the digital distributed ledger, such as equipment used (e.g., type of harvester and/or related equipment such as a towed harvesting system), type of crop, harvest rates, yields, harvester speed, harvester direction, harvester position (e.g., latitude, longitude), harvester orientation (e.g., driving forward, driving backward), and so on. Various entities may use the digital distributed ledger, including service operators, equipment owners, manufacturers, data analysts, and so on. Each entity may be authenticated, for example, via public/private key techniques further described below, to participate in the distribute ledger-based system described herein. Service operators, such as a mechanic, may inspect the equipment, service the equipment and log the maintenance performed via the digital distributed ledger-based system. Owners of equipment may use the digital distributed ledger to store ownership records, as well as to verify that certain events have occurred, such as scheduled maintenance, updates to equipment manuals, and so on. Operators of the equipment may similarly use the digital distributed ledger to verify equipment maintenance, equipment conditions, to log operation records (e.g., planting operations, harvesting operations), to read current equipment operation manuals, to view field instructions (e.g., instructions on how to traverse a given field during planting and/or harvesting), and so on.
Data analysts may now use authenticated data to better analyze field yields, to analyze crop production and the like, based on how planting operations were performed, which seeds were used, type of soil used, meteorological data, and so on. Financial entities may also participate in the digital distributed ledger-based system, for example to verify ownership records, perform loan analysis, provide loan information, store payment received, and so on. The information described herein may be stored in trails to be tracked using the digital distributed ledger-based system, such as a system that includes one or more blockchains. The blockchain(s) provide immutable and secure data storage, which may be distributed across a plurality of computing systems or nodes. As new information is generated (e.g., new equipment operations logs, field information, maintenance information, financial information, and so on), the new information may be included in the digital distributed ledger-based system, thus “growing” the trails throughout the lifetime of the equipment being tracked. The digital distributed ledger system, which may include one or more blockchains, may be used to store the information, including new information, more efficiently, securely, and robustly. The digital distributed ledger-based system may also provide enhanced security, such that only authorized individuals and/or processes can access cryptographically protected data on the digital distributed ledger-based system. The digital distributed ledger-based system may also provide for immutability, such that data records written to the digital distributed ledger may not be changed or removed once written.
The blockchain may grow as new blocks are added based on a new set of information. In some examples, a single block may be derived from multiple information, e.g., from an operations log and associated information (e.g., sensor data, field condition records, meteorological records) that were collected during operations. In general, blocks are added to the blockchain in a linear, chronological order by one or more computing devices in a peer-to-peer network of interconnected computing devices that execute a blockchain protocol. The peer-to-peer network may be described as a plurality of interconnected nodes, each node being a computing device that uses a client to validate and to relay transactions to other nodes. Each node may maintain a copy of the blockchain, which is automatically downloaded to the node upon joining the peer-to-peer network. The blockchain protocol may provide for a secure and reliable method of updating the blockchain, copies of which are distributed across the peer-to-peer network, without use of a central authority. Blocks and/or information included in the blocks may be encrypted, thus providing for increased security.
As described in further detail below, a ledger of trails may be used based on the amount of work (e.g., computing work such as hashing) required to add a transaction to the ledger (e.g., add a block to the blockchain). Blockchains may also employ other protocols, for example, that may define “work” differently. The work may be a computing task that may be difficult for any single node (e.g., computing device) in the peer-to-peer network to complete quickly based on the size of the digital distributed ledger, but may be relatively easy for any node (e.g., computing device) to verify.
The peer-to-peer network may include multiple “miners” (e.g., computing devices) that add blocks to a blockchain based on the blockchain protocol. In general, multiple miners validate transactions that are to be added to a block, and compete (e.g., perform computing work, as introduced above) to have their respective block added to the blockchain. Validation of transactions includes verifying digital signatures associated with respective transactions. For a block to be added to the blockchain, a miner must demonstrate a proof of work before their proposed block of transactions is accepted by the peer-to-peer network, and before the block is added to the blockchain. In certain embodiments, a blockchain protocol include a proof of work scheme that is based on a cryptographic hash function (CHF). An example CHF includes the secure hash algorithm 256 (SHA-256). In general, the CHF receives information as input, and provides a hash value as output, the hash value being of a predetermined length. For example, SHA-256 outputs a 256-bit (32-byte, 64-character) hash value. In some examples, the hash value is a one-way hash value such that the output hash value cannot be ‘un-hashed’ to determine what the input was. The blockchain protocol can require multiple pieces of information as input to the CHF. For example, the input to the CHF can include a reference to the previous (most recent) block in the blockchain, details of the transaction(s) that are to be included in the to be created block, and a “nonce” value (e.g., a random number used only once).
Multiple nodes may compete to hash a set of transactions and to provide the next block that is to be added to the blockchain. The blockchain protocol provides a threshold hash to qualify a block to be added to the blockchain. For example, the threshold hash can include a predefined number of zeros (0's) that the hash value must have at the beginning (e.g., at least the first four characters of the hash value must each be zero). The higher the number of zeros, the more computationally time-consuming it may be to arrive at a qualifying hash value.
In accordance with the blockchain protocol, each miner in the peer-to-peer network receives transaction information for one or more transactions that are to be included in a block that is to be added next in the blockchain. Each miner provides the reference to the previous (most recent) block in the blockchain, details of the transaction(s) that are to be included in the to-be-created block, and the nonce value to the CHF that may then be used to provide a hash value. If the hash value does not meet the threshold hash (e.g., the first four characters of the hash value are not each zero), the miner starts again to provide another hash value, thus increasing the amount of work. If the hash value meets the threshold hash (e.g., at least the first four characters of the hash value are each zero), the respective miner may have successfully created the next block that is to be added to the blockchain. Consequently, the respective miner's block is broadcast across the peer-to-peer network. All other miners cease work (because one miner was already successful), and all copies of the blockchain are updated across the peer-to-peer network to append the block to the blockchain. Each miner may produce hundreds of thousands (or more) of hash values, before any one miner provides a qualifying hash value (e.g., at least the first four characters of the hash value are each zero).
In some embodiments, the digital distributed ledger or blockchain system can include one or more sidechains. A sidechain may be described as a blockchain that validates data from other blockchains. In some examples, a sidechain may provide for granularity of information so that different information “types”, (e.g., equipment operation logs, field condition logs, meteorological conditions logs, and so on) may be stored in a different sidechain linked to a main chain. The blockchain may be a public blockchain, such that data stored on the blockchain is generally accessible to all. The blockchain or portions of the blockchain (e.g., certain blocks and/or certain sidechains) may alternatively or additionally be a private blockchain, such that the stored data is accessible only to authorized individuals and/or processes on the blockchain. The blockchain or portions of the blockchain may also include semipublic information, such as information to be provided to regulatory bodies (e.g., Occupational Safety and Health Administration (OSHA), Environmental Protection Act (EPA) authorities, General Data Protection Regulation (GDPR) authorities, and so on). Further, the blockchain may also include semiprivate information, such as information accessible to a farming cooperative, owner groups (e.g., ownership-by-share groups), and the like. By providing for authenticated, information, and/or associated transactions via blockchains, as further described below, enhanced transactional efficiencies, security, and information flows may be provided.
The digital distributed ledger system 102 may store any appropriate number of data records of various types, including equipment trail records 104 and/or entity trail records 106. The equipment trail records 104 may include information related to equipment (e.g., farming equipment), while the entity trail records 106 may include information related to entities 107 associated with the equipment. For example, entities 107 may include owner(s) 108 of the equipment, manufacturer(s) 110 of the equipment, operator(s) 112 of the equipment, equipment service providers 114, data analysts 116, regulatory bodies 118 (e.g., Food and Drug administration (FDA), U.S. Department of Agriculture (USDA), Department of Health and Human Services (DHHS), Environmental Protection Agency (EPA), Department of Transportation (DOT), National Highway Traffic Safety Administration (NHTSA), and so on), producing entities 119 (e.g., entities such as farming entities that produce crop), consumer entities 123 (e.g., entities that consume product produced by producing entities 119), and other parties 127 (e.g., financial entities, equipment dealers, equipment brokers, equipment inspectors, insurance providers, other governmental agencies). Each of the entities 108, 110, 112, 114, 116, 118, 119, 123, 127 may include entity authentication and/or verification information that identifies a particular entity, such as an individual, a corporation, a club, and so on, participating in digital distributed ledger 102. For example, unique identification, such as cryptographic key(s) and/or IDs 120, 121, 122, 124, 125, 126, 128, 129, 130, certificates of trust, government identification (e.g., operator licenses, driver's license, passport) and the like, may be used to uniquely identify parties involved in the digital distributed ledger 102.
In certain embodiments, the keys 120-130 may be a public/private key pair suitable for public/private key cryptography and/or authentication. In these embodiments, a public key owned by party A may be transmitted through open channels to party B. Party B may use their private key and the public key of party A to encrypt certain data, which may then be transmitted through open channels to party A. Party A may then receive the encrypted data, and use their private key to decrypt the data. Example public/private key pair systems include pretty good privacy (PGP), Gnu Privacy Guard (GPG), Diffie-Hellman key exchanges, Station-to-Station (STS) protocol, password-authenticated key (PK) agreement, and so on. In the depicted embodiment, an authentication/cryptography system 132 may be used to provide for authentication services 134 and/or encryption/decryption services 136. The authentication/cryptography system 132 may be implemented as computer code or instructions executable via one or more processors 133 of the system 100 and stored in a memory 135. The authentication/cryptography system 132 may also include or be operatively coupled to a storage (e.g., secure storage) system 138 used to store keys, certificates of trust, and other secure data.
In use the entities 108-127 may log into the authentication/cryptography system 132 to enter and/or to retrieve information stored in the digital distributed ledger 102. For example, two-factor authentication may be used to log into the authentication/cryptography system 132, and communications may include secure communications such as secure shell (SSH) protocol, transport layer security (TLS), hypertext transfer protocol secure (HTTPS), internet protocol security (IPsec), and the like. Accordingly, the entities 108-118 may input information 140 into the digital distributed ledger 102 and read information 142 from the digital distributed ledger 102. In some cases, data may be stored unencrypted in the digital distributed ledger 102, for example, data for public consumption.
In use, equipment 144 may also utilize the digital distributed ledger 102. For example, the equipment 144 may include multiple sensors 145 to provide for data such as engine revolutions per minute (RPM), equipment temperature(s), equipment pressures, fuel levels, liquid flows (e.g., coolant flows, fuel flows), electric battery levels, alarms, alerts, and so on. Accordingly, the equipment 144 may include keys 146 (e.g., public/private keys) suitable for accessing the authentication/cryptography system 132 to enter and/or to retrieve information stored in the digital distributed ledger 102. For example, a communications system 147 that may use WiFi, mesh networks, cellular networks, and so on, may be used to communicate between the equipment 144 and the authentication/cryptography system 132. In some cases, the equipment 144 may be stationary, so wired networks (e.g., internet networks, Foundation Fieldbus networks, industrial protocol networks, and so on) may be used to communicate between the equipment 144 and the authentication/cryptography system 132. It is to be noted that while the techniques herein are described in terms of farming equipment, any industrial equipment may benefit, including electric generators, power equipment, construction equipment, aviation equipment, and so on.
As the equipment operates, equipment logs may be stored as operations records 148 in the digital distributed ledger 102. As mentioned earlier, operations data such as seed type, seed deposition rates, soil type, soil humidity, soil pH, soil temperature, weather data (e.g., humidity, air temperature, wind speed, wind direction, solar radiation, sun exposure), vehicle speed, vehicle direction, vehicle position (e.g., latitude, longitude), vehicle orientation (e.g., driving forward, driving backward), fuel use, and so on, may be stored in the digital distributed ledger 102 via the operations records 148 (e.g., in one or more blockchain blocks). The records 148 may additionally store harvesting records, such as equipment 144 used (e.g., type of harvester and/or related equipment such as a towed harvesting system), type of crop, harvest rates, yields, harvester speed, harvester direction, harvester position (e.g., latitude, longitude), harvester orientation (e.g., driving forward, driving backward), fuel use, and so on. Operations data may also include data sensed via sensors, such as engine revolutions per minute (RPM), equipment temperature(s), equipment pressures, fuel levels, liquid flows (e.g., coolant flows, fuel flows), electric battery levels, alarms, alerts, and so on, stored in the records 148.
During planting, spraying, and/or fertilizer applications, the operations records 148 may include field inputs and field prescriptions such as what was applied (e.g., seed genetics, fertilizer, insecticides, pesticides, manure, and so on), when it was applied (date, time, or a combination thereof), application conditions (e.g., weather: wind speed/direction, precipitation, relative humidity, ambient pressure, temperature); application rates (e.g., gallons per acre, pounds per acre, and so on). The records 148 may also include, at what ground speed, pressures, flows throughout the field, and so on, where the planting, spraying, and/or fertilizer applications performed, slopes (e.g., sections of field, route taken) used in the applications, and/or how close the applications where, for example, to sensitive landscapes such as roads, parks, surface waterbodies, residential areas, and so on.
A physical description of the equipment, including manufacturing details, may also be stored in records 150. For example, the manufacturer 110 may enter into the records 150 the equipment model number, a description of the equipment, as well as manufacturing provenance such as where the equipment (and/or equipment parts) was made, date of manufacture, process involved, (e.g., additive manufacturing, milling, assembly processes, etc.), materials used, and so on. Records 152 may be used to store equipment manuals. For example, operator's manuals, maintenance manuals, and so on, may be stored in the records 152. As new manuals are created or the manuals updated, the new manuals and/or the updates may also be stored in records 152.
Maintenance information may be stored in records 154. For example, a service provider 114, such as a mechanic or a service shop, may log into the digital distributed ledger via the authentication/cryptography system 132 and enter maintenance events, such as repairs, fluid changes (e.g., oil changes, transmission fluid changes, differential fluid changes), tire rotations, upgrades (e.g., suspension upgrades, ECU flashing upgrades), parts replacements, and so on. In some embodiments, financial information related to the equipment 144 may also be stored. For example, records 156 may store information such as purchase price paid for the equipment by the owner 108, loan information, insurance information, return on investment information (e.g., monies collected by using the equipment taking into account equipment price, depreciation, and the like), tax information for the equipment, and so on. Other information may include operator 112 information such as operator licenses (e.g., license to use or to drive the equipment 144), regulatory data (e.g., emissions tests, equipment inspections, and so on), reports/analysis entered by the data analyst(s) 116, and other data entered by entities 108-118.
It is to be understood that data entered into records (e.g., blockchain blocks) 148-158 may be authenticated by the authentication/cryptography system 132 as being entered by one or more of the entities 108-118 and the data may be stored in the records 148-158 as encrypted. For example, each records 148-158 in a blockchain may include an ID of the entity or entities 108-118 that provided the data in the records and the ID of the equipment 144 that the data belongs to. Because the digital distributed ledger system 102 provides for immutable and traceable storage, the records 148-158 may provide for a secure, reliable, and distributed storage of the data associated with the equipment 144. Entity trail 106 may similarly store records 160-172. For example, records 160 may store ownership information, include owner name(s), addresses, deed records, fractional ownership records (e.g., shares owned and by whom), tax IDs, and the like. Records 162 may store manufacturer data, such as company name, division, address, agent of record, and so on. Records 164 may store operator data, such as company name (when operator is a company or a cooperative), individual name(s) (when operators include individuals), addresses, operator licensing information (e.g., equipment certification licenses, driver's licenses, permits to operate in certain jurisdictions), and so on. Records 166 may be used to store service provider information. For example, service providers may include mechanics providing maintenance services, meteorological entities providing meteorological data services, financial entities providing financial services (e.g., loans, banking services, brokerage services), consulting entities providing consulting services (e.g., field utilization services for farming), and the like. Accordingly, names, addresses, and/or identification information may be stored for each service provider in records 166.
Records 168 may store information related to data analysts, for example data analysts that have been vetted to work with the data in records 148, 150, 152, 154, 156, and/or 158. Data analyst information may include name, address, certifications, area(s) of expertise, and so on, for the data analyst or data analysis company. Records 170 may store information for other parties that participate in the system 100. For example, regulatory entity 118 information (e.g., U.S. Department of Agriculture (USDA), farm service agency (FSA), farm credit administration (FCA), environmental protection agency (EPA), local governments, state governments, federal governments), and the like, may be stored in records 170. Likewise, producing entity 119 information such as name, any corporation information (e.g., incorporation information), tax information, and so on, may be stored in records 170. Consumer entity 123 information such as name, address, and so on, may also be stored in records 170. Other parties may also include entities, including private entities, that may be authorized access to certain data in records 148, 150, 152, 154, 156, and/or 158, for example, for a fee. These buyers of data may use the information, as vetted by the information owners, for commercial purposes for example.
It is to be noted that the records 148-170 may be interrelated. For example, the operations records 148 may include information (e.g., unique ID) pointing to an operator in records 164 to link the operator 112 to certain operations data or logs. Likewise, the physical description records 150 and the manual(s) records 154 may include information (e.g., unique ID) pointing to one or more manufacturer(s) 110 whose information is stored in record(s) 162. Similarly, maintenance records 154 may include information (e.g., unique ID) pointing to one or more service providers 114 (e.g., mechanics) whose information may be stored in records 166. Financial records and/or other information records 158 may also include information (e.g., unique ID) pointing to one or more entities 108-127 whose information is stored in records 160-170. It is also to be noted that the records 148-158, and in some cases, the records 160-170, may store information (e.g., unique ID such as a VIN) identifying specific equipment 144. By interrelating information (e.g., many-to-many relationships between records 148-170 and equipment 144), traceability of information may be more easily provided.
Production trails 171 may be used to store, for example, auditable information related to production of crops and the like. While crops are envisioned, other farming products may be tracked, such as animal production. Further, other non-farming products may be tracked, such as industrial manufacturing productions. For farming productions, as mentioned earlier, farming log data such as seed type used, seed deposition rates, soil type, soil humidity, soil pH, soil temperature, weather data (e.g., humidity, air temperature, wind speed, wind direction, solar radiation, sun exposure), vehicle speed, vehicle direction, vehicle position (e.g., latitude, longitude), vehicle orientation (e.g., driving forward, driving backward), and so on, may be stored in the digital distributed ledger as part of production trails 171 for a given crop. Likewise, harvesting records may be logged via the digital distributed ledger, such as equipment used (e.g., type of harvester and/or related equipment such as a towed harvesting system), type of crop, harvest rates, yields, harvester speed, harvester direction, harvester position (e.g., latitude, longitude), harvester orientation (e.g., driving forward, driving backward), and so on.
Likewise, application of consumables such as fertilizer, may be stored as fertilizer logs in the production trails 171. Similarly, other logs such as water logs that detail a watering schedule for the product may be stored in production trails 171. More generally, information used to produce the product, such as all the equipment (e.g., equipment 144) used, planting information, fertilizing information, water information, and/or harvesting information may be stored in the production trails 171 via records 175. In some cases, the records 175 may be “pointers” to records stored in other trails such as trails 104, 106. That is, the “pointers” may store record IDs for records stored in trails 104, 106. In other cases, the records 175 may store actual information (e.g., seeding, plating, fertilizing, and/or watering information) in addition to or in lieu of record IDs. Production trails 171 may also include storage facilities records used to provide storage information of the harvested crop, ambient temperatures used in storage (e.g., silo temperatures, refrigeration temperatures), processing of the product (e.g., crop processing information including any crop disinfection activities) and so on.
Once the product is to be place for sale, marketplace trails 173 may store information related to packing of product activities, distribution activities (transportation used, ambient temperatures, handling equipment, handling personnel), storage activities (warehouse information, ambient conditions, storage handling equipment, storage handling personnel), as well as buy/sell activity, as described in more detail below with respect to
By providing for the records stored in the trails 104, 106, 171, 173 the system 100 may enable governing bodies and regulatory agencies to receive a “raw” view of field (e.g., agricultural field, construction field) and/or product production activities for compliance purposes. Instead of “averages” or “estimates”, unbiased actuals may be queried as posted in a public area of the distributed ledger system 102. Because of the immutable nature of distributed ledger system 102 combined with verifiable authentication information of data sources into the distributed ledger system 102, the distributed ledger system 102 may now provide irrefutable documentation to prove compliance and/or defend against litigation. Additionally, high speed reporting and inspections by regulatory agencies may now be more feasible due to executing queries against information stored in the trails 104, 106, 171, 173 from one or more sources (e.g., distributed storage of immutable information). Further, a manufacturer of machinery, such as CNH Industrial N.V., of Amsterdam, the Netherlands, could provide secure/trusted access to a cloud ecosystem that may satisfy the demands listed above, e.g., for regulatory compliance, evidence, and/or high speed reporting.
In some embodiments, the digital distributed ledger system 102 may include a main blockchain 300 and one or more sidechains 172, 174 that may be linked to the main blockchain 300. In some embodiments, the sidechain 172 may be used to store certain record types. For example, an equipment trails sidechain 172 may store only equipment trail records 104. Likewise, an entity trails sidechain 174 may store only entity trail records 106. Likewise, sidechains 179, 181 may store information for trails 171, 173. By using sidechains 171, 172, 174, 179, 181 dedicated to specific trail types 104, 106, 171, 173, the techniques described herein may enable a more efficient record allocation in the digital distributed ledger 102. Further, in some embodiments, a side chain may be managed by various entities, for example, side chains 172 may be managed by multiple parties, such as equipment owners 108 and manufacturers 110, while the side chains 172 may be managed by entities 108-127. Likewise, the authentication/cryptography system 132 may be provided by the manufacturer 110, for example, as a cloud-based portal, while the digital distributed ledger 102 may be created initially by the manufacturer 110 but then grown by all participants in the system 100, e.g., entities 108-127 and/or equipment 144. A farm management information systems (FMIS) 111 is also shown, which may be communicatively and/or operatively coupled to the distributed ledger 102 and to the equipment 144. The FMIS 111 may be a platform system providing data to and from the vehicle 144, as well as users of the vehicle 144. For example, the FMIS 111 may provide for farming operations support and may be available from CNH Industrial N.V., of Amsterdam, the Netherlands.
In the depicted embodiment, the digital distributed ledger 102 may be used to provide for distributed ledger marketplace, for example, via a cloud system 202. For example, the cloud system 202 may be used to access the distributed ledger 102, to access portions of the distributed ledger 102, and/or to store portions of the distributed ledger 102. That is, the cloud system 202 may access the distributed ledger 102 and/or may also act as one or more computing nodes of a network that stores and uses data for the digital distributed ledger system 102. The cloud system 202 may provide for a virtual marketplace, as well as for equipment tracking and/or auditing, product production tracking and/or auditing, and to ensure regulatory compliance. Indeed, the cloud system 202 may be used, for example, 1) to provide a digital identity for equipment (e.g., vehicle) that is traceable and verifiable; 2) to track what has occurred to the equipment under right to repair; 3) to provide a marketplace for the equipment and equipment related goods; 4) to provide for data monetization; 5) to create and/or use audit trails of when farming activities occur, the type of farming activity (e.g., tilling, planting, crop collecting), farming products applied (e.g. seeds, fertilizer, pesticides, and the like); 6) to provide for proof of authority; and 7) to provide for a value add system that may be set up by a manufacturer, as further described below.
Digital equipment identity tracking may be provided by the distributed ledger 102. As mentioned above with respect to
Repair tracking, including repair tracking in right-to-repair jurisdictions, may also be provided. For example, the equipment 144 may be sold from the manufacturer with an original set of parts. As the equipment 144 is operated, parts may be replaced and/or repaired in an equipment service facility and/or in the field. A service provider 114 (e.g., mechanic) may replace and/or repair the part and then update the equipment's 114 maintenance log to denote that the repair took place. Likewise, an owner 108 of the equipment 144 may perform the replacement/repair and subsequently update the maintenance log. In some embodiments, a new part (e.g., “plug and play” part) may identify itself to the ECU 103 (e.g., when “plugged” into the equipment) and the ECU 103 and/or the part may then itself update the maintenance log. An immutable repair log may thus be provided, that lists the type of repair, parts used, date of repair, personnel that performed the repair, and so on. The immutable repair log and each log entry may then be non-erasable and may provide for a more secure log of repairs performed, for example on the equipment 144.
As mentioned earlier, one or more marketplaces may be provided, such as the public markets 204, the private markets 206, and/or the governmental markets 208. In operations, the digital distributed ledger 102 may provide for a system where goods (e.g., real and/or virtual goods) may be offered for sale, the sale may then be recorded, and ownership records may be updated. That is, goods may be offered as a buy now style listing, as part of an auction (increasing price auction, Dutch auction, sealed-bid auction, and the like), as a financed purchase, and so on, between the owner(s) 108 and any party or parties interested in the good (e.g., other owner(s) 108, parties 110, 112, 114, 116, 118, 119, 123, 127).
A sale transaction may then be recorded in the digital distributed ledger 102, storing information such as a transaction date, the good(s) sold, buyer information, seller information, sale price information, financing information, and so on. Ownership information may also be updated after the sale transaction, creating, for example, and ownership chain. Other information stored with the sale transaction may include warranty information, sales contract, delivery information, purchase order information, and so on. By providing a digital distributed ledger platform to offer for sale, conduct a sale, record the sale, and record new ownership information, the marketplace 200 may be more efficient in terms of storage, security, immutability, transparency, and verification when compared to, for example, e-commerce sites that use traditional database technology (e.g., relational database technology).
As mentioned earlier, the goods sold in the marketplace 200 may include real goods as well as virtual goods. Accordingly, data monetization may be provided. For example, data and/or data analysis may be sold as a good or service in the marketplace 200. Data sold may include any data stored in the digital distributed ledger 102 with owner 108 authorization. For example, equipment types sold data, auction data, maintenance log data, and so forth, may now be monetized. Likewise, data analytic services providing for sales trends, repair trends, price trends, and so on, as opposed to raw data may be sold on the marketplace 200. In some embodiments, the data and/or data analytics sold may have undergone an anonymization process which may remove or otherwise obfuscate private data such as name(s), addresses, and the like of the parties 108, 110, 112, 114, 116, 118, 119, 123, 127, as well as any other information deemed private by regulatory parties 118. Data may be owned by one or more of the parties 108, 110, 112, 114, 116, 118, 119, 123, 127, based on, for example, which party created the data or otherwise participated in the creation of the data. Owners of data may decide to store the data in the digital distributed ledger 102 as encrypted data, and then subsequently decrypt the data for further use (e.g., monetization).
Goods sold may include non-equipment goods such as agricultural goods 212. Production information for the agricultural goods 212 (and other goods types), may also be stored in the digital distributed ledger 102. For example, the equipment, such as the equipment 144 used in the production (planting, fertilizing, harvesting) of the goods 212 may be stored in a production log for the goods 212. As the agricultural goods 212 are planted, an agricultural log stored in the digital distributed ledger 102 may keep track of seeds used, type of soil, weather conditions, equipment 144 used, other equipment used, equipment operator(s), and so on. As the goods 212 are grown, the agricultural log may include watering schedules, water sources, fertilizer schedules, fertilizer sources, pesticide schedules, pesticide sources, personnel and equipment that applied the fertilizer and pesticides, weather conditions, and the like.
When the goods 212 are harvested, the agricultural log may then store the equipment used for harvesting, date and time of harvest, personnel used in harvesting, storage facilities, used, and the like. Likewise, as the goods 212 are transported, the agricultural log may store transport used, operators used, dates and times of transport, transport conditions (e.g., temperatures, humidity), weather conditions, and so on. The goods 212 may then be sold at supermarkets, farmer's markets, and so on, and the agricultural log may store the date of sale, price paid, seller (and buyer) information, and so on. Accordingly, a more comprehensive and accessible record of the goods 212 may now be provided. That is, the goods 212 may now be tracked using the same system, e.g., digital distributed ledger, to include a “soup-to-nuts” history, including audit trails for each of the goods 212, that may be verifiable and immutable.
Verification and proof of authority may now be more easily provided. For example, an operation, such as maintenance work on the equipment, planting, fertilizing, applying pesticide, transporting, storing, and so on, of the goods 212 may include an entity (e.g., parties 108, 110, 112, 114, 116, 118, 119, 123, 127) approving the operation. The approval may now be stored as part of the goods' 212 ledger and provide for a technique to verify approval. For example, each operation may be approved only by certain entities and the entities may have to enter authentication information (e.g., via crypto keys) to provide proof of authority for the operation. In some embodiments, the marketplace 200 ecosystem may be provided by the manufacturer of the equipment 144 as a value added component for purchasers/leasers of the equipment 144. That is, the manufacturer may provide for software executable via computing systems 210 that uses the digital distributed ledger 102 as described to 1) to provide a digital identity for equipment (e.g., vehicle) that is traceable and verifiable; 2) to track what has occurred to the equipment under right to repair; 3) to provide a marketplace for the equipment and equipment related goods; 4) to provide for data monetization; 5) to create and/or use audit trails of when farming activities occur, the type of farming activity (e.g., tilling, planting, crop collecting), farming products applied (e.g. seeds, fertilizer, pesticides, and the like); and 6) to provide for proof of authority. Access and use for the software may then be given to various entities (e.g., parties 108, 110, 112, 114, 116, 118, 119, 123, 127).
Data, such as records included in the distributed digital ledger 102 may be stored in a section 318 (and/or in another section). In certain embodiments, a new block may be created when a new record 148-170 is to be created. For example, an operations records 148 may result in the creation of a new block in the blockchain, which may be tied in via block ID to existing block(s). In another embodiment, empty blocks may be first created and then assigned to new blocks for the trails 104, 106, 171, 173 as new information comes in. When a new block is created, the block will receive a new header 310 uniquely identifying the new block. As mentioned earlier, a peer-to-peer network may include multiple “miners” (e.g., computing devices used by entities 108-118 and/or by the equipment 144) that add blocks to the blockchain 300 based on the blockchain protocol. In general, multiple miners validate transactions or data 318 that are to be added to a block, and compete (e.g., perform computing work, as introduced above) to have their respective block added to the blockchain 300. Validation of transactions and/or data includes verifying digital signatures associated with respective transactions and/or data 318. For a block to be added to the blockchain 300, a miner must demonstrate a proof of work before their proposed block of transactions is accepted by the peer-to-peer network, and before the block is added to the blockchain 300. In certain embodiments, a blockchain protocol include a proof of work scheme (e.g., Merkle Tree) that is based on a cryptographic hash function (CHF). An example CHF includes the secure hash algorithm 256 (SHA-256). In general, the CHF receives information as input, and provides a hash value as output, the hash value being of a predetermined length. For example, SHA-256 outputs a 256-bit (32-byte, 64-character) hash value. In some examples, the hash value is a one-way hash value such that the output hash value cannot be ‘un-hashed’ to determine what the input was. The blockchain protocol can require multiple pieces of information as input to the CHF. For example, the input to the CHF can include a reference to the previous (most recent) block (e.g., hash 312) in the blockchain 300, details of the transaction(s) or data 318 that are to be included in the to be created block, and a “nonce” value (e.g., a random number used only once).
Multiple nodes may compete to hash a set of transactions and to provide the next block that is to be added to the blockchain 300. The blockchain protocol may provides a threshold hash to qualify a block to be added to the blockchain 300. For example, the threshold hash can include a predefined number of zeros (0's) that the hash value must have at the beginning (e.g., at least the first four characters of the hash value must each be zero). The higher the number of zeros, the more computationally time-consuming it may be to arrive at a qualifying hash value.
In accordance with the blockchain protocol, each miner in the peer-to-peer network receives transaction information for one or more transactions that are to be included in a block that is to be added next in the blockchain 300. Each miner provides the reference to the previous (most recent) block in the blockchain 300, details of the data or transaction(s) 318 that are to be included in the to-be-created block, and the nonce value to the CHF that may then be used to provide a hash value. If the hash value does not meet the threshold hash (e.g., the first four characters of the hash value are not each zero), the miner starts again to provide another hash value, thus increasing the amount of work. If the hash value meets the threshold hash (e.g., at least the first four characters of the hash value are each zero), the respective miner may have successfully created the next block that is to be added to the blockchain 300. Consequently, the respective miner's block is broadcast across the peer-to-peer network (e.g., all devices communicatively coupled to the system 100). All other miners cease work (because one miner was already successful), and all copies of the blockchain 300 are updated across the peer-to-peer network to append the block to the blockchain 300. Each miner may produce hundreds of thousands (or more) of hash values, before any one miner provides a qualifying hash value (e.g., at least the first four characters of the hash value are each zero).
It is to be noted that any computing device, such as desktop computers, laptops, tables, mobile phones, other mobile devices, and so on, may be used for mining. Accordingly, as new information for the trails 104, 106, 171, 173 is created, new blocks may be added to the blockchain 300, including blocks 302, 304, 306, and 308. Indeed, the blockchain 300 may continue to grow, storing new records for information 148-170. Because of the distributed nature of the peer-to-peer network created via the digital distributed ledger-based system 100, each node (e.g., computing devices of the entities 108, 110, 112, 114, 116, 118, 119, 123, 127 and/or equipment 144) may include copies of the blockchain 300 and share copies of the blockchain 300 as new peers enter the peer-to-peer network. Each copy of the blockchain 300 may include authenticate and/or encrypted information (e.g., records for the trails 104, 106, 171, 173) for all or substantially all of the information tracked by the digital distributed ledger system 102. The information is immutable, and more efficiently tracked as new information gets added via the digital distributed ledger-based system 100. Accordingly, logs, relationships, transactions, or other information pertaining to the equipment 144 and/or products 212 may be captured, as shown in
As mentioned earlier, authentication/cryptography system 132 may be used to authenticate (block 402) access (e.g., read access, write access) to the blockchain 300. For example, after authentication (block 402), an entity 108-118 or the equipment 144 may write (block 406) data into the digital distributed ledger via the blockchain 300. In some embodiments, the data may be stored encrypted. As mentioned above, the data may include records stored in trails 104 and 106. For example, operations records 148, physical description records 150, manuals 152, maintenance records 154, financial records 156, and/or other records associated with the equipment 144 and/or goods 212 may be written (block 406) as encrypted data in the blockchain 300.
The data in the blockchain 300 may also be read (block 408), for example, via the authentication/cryptography system 132. That is, after authentication (block 404), the authentication/cryptography system 132 may retrieve desired blocks included in the blockchain 300 and convert the encrypted data into non-encrypted data viewable in a display. For example, data analysis may be executed to determine how to improve crop yields, how to improve planting in a specific field using the equipment 144, how to improve fuel efficiency with planting/harvesting, and so on. Likewise, ownership information may be verified, use of equipment and operator manuals may be improved, service provider data may be validated and used for further data analysis, and so on.
The processor(s) 510 may be configured to process instructions for execution within the system 500. The processor(s) 510 may include single-threaded processor(s), multi-threaded processor(s), or both. The processor(s) 510 may be configured to process instructions stored in the memory 520 or on the storage device(s) 530. For example, the processor(s) 510 may execute instructions for the various software module(s) described herein. The processor(s) 510 may include hardware-based processor(s) each including one or more cores. The processor(s) 510 may include general purpose processor(s), special purpose processor(s), or both.
The memory 520 may store information within the system 500. In some implementations, the memory 520 includes one or more computer-readable media. The memory 520 may include any number of volatile memory units, any number of non-volatile memory units, or both volatile and non-volatile memory units. The memory 520 may include read-only memory, random access memory, or both. In some examples, the memory 520 may be employed as active or physical memory by one or more executing software modules.
The storage device(s) 530 may be configured to provide (e.g., persistent) mass storage for the system 500. In some implementations, the storage device(s) 530 may include one or more computer-readable media. For example, the storage device(s) 530 may include a floppy disk device, a hard disk device, an optical disk device, or a tape device. The storage device(s) 530 may include read-only memory, random access memory, or both. The storage device(s) 530 may include one or more of an internal hard drive, an external hard drive, or a removable drive.
One or both of the memory 520 or the storage device(s) 530 may include one or more computer-readable storage media (CRSM). The CRSM may include one or more of an electronic storage medium, a magnetic storage medium, an optical storage medium, a magneto-optical storage medium, a quantum storage medium, a mechanical computer storage medium, and so forth. The CRSM may provide storage of computer-readable instructions describing data structures, processes, applications, programs, other modules, or other data for the operation of the system 500. In some implementations, the CRSM may include a data store that provides storage of computer-readable instructions or other information in a non-transitory format. The CRSM may be incorporated into the system 500 or may be external with respect to the system 500. The CRSM may include read-only memory, random access memory, or both. One or more CRSM suitable for tangibly embodying computer program instructions and data may include any type of non-volatile memory, including but not limited to: semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. In some examples, the processor(s) 510 and the memory 520 may be supplemented by, or incorporated into, one or more application-specific integrated circuits (ASICs).
The system 500 may include one or more I/O devices 550. The I/O device(s) 550 may include one or more input devices such as a keyboard, a mouse, a pen, a game controller, a touch input device, an audio input device (e.g., a microphone), a gestural input device, a haptic input device, an image or video capture device (e.g., a camera), or other devices. In some examples, the I/O device(s) 550 may also include one or more output devices such as a display, LED(s), an audio output device (e.g., a speaker), a printer, a haptic output device, and so forth. The I/O device(s) 550 may be physically incorporated in one or more computing devices of the system 500, or may be external with respect to one or more computing devices of the system 500.
The system 500 may include one or more I/O interfaces 540 to enable components or modules of the system 500 to control, interface with, or otherwise communicate with the I/O device(s) 550. The I/O interface(s) 540 may enable information to be transferred in or out of the system 500, or between components of the system 500, through serial communication, parallel communication, or other types of communication. For example, the I/O interface(s) 540 may comply with a version of the RS-232 standard for serial ports, or with a version of the IEEE 1284 standard for parallel ports. As another example, the I/O interface(s) 540 may be configured to provide a connection over Universal Serial Bus (USB) or Ethernet. In some examples, the I/O interface(s) 540 may be configured to provide a serial connection that is compliant with a version of the IEEE 1394 standard.
The I/O interface(s) 540 may also include one or more network interfaces that enable communications between computing devices in the system 500, or between the system 500 and other network-connected computing systems. The network interface(s) may include one or more network interface controllers (NICs) or other types of transceiver devices configured to send and receive communications over one or more communication networks using any network protocol.
Computing devices of the system 500 may communicate with one another, or with other computing devices, using one or more communication networks. Such communication networks may include public networks such as the internet, private networks such as an institutional or personal intranet, or any combination of private and public networks. The communication networks may include any type of wired or wireless network, including but not limited to local area networks (LANs), wide area networks (WANs), wireless WANs (WWANs), wireless LANs (WLANs), mobile communications networks (e.g., 3G, 4G, Edge, etc.), and so forth. In some implementations, the communications between computing devices may be encrypted or otherwise secured. For example, communications may employ one or more public or private cryptographic keys, ciphers, digital certificates, or other credentials supported by a security protocol, such as any version of the Secure Sockets Layer (SSL) or the Transport Layer Security (TLS) protocol.
The system 500 may include any number of computing devices of any type. The computing device(s) may include, but are not limited to: a personal computer, a smartphone, a tablet computer, a wearable computer, an implanted computer, a mobile gaming device, an electronic book reader, an automotive computer, a desktop computer, a laptop computer, a notebook computer, a game console, a home entertainment device, a network computer, a server computer, a mainframe computer, a distributed computing device (e.g., a cloud computing device), a microcomputer, a system on a chip (SoC), a system in a package (SiP), and so forth. Although examples herein may describe computing device(s) as physical device(s), implementations are not so limited. In some examples, a computing device may include one or more of a virtual computing environment, a hypervisor, an emulation, or a virtual machine executing on one or more physical computing devices. In some examples, two or more computing devices may include a cluster, cloud, farm, or other grouping of multiple devices that coordinate operations to provide load balancing, failover support, parallel processing capabilities, shared storage resources, shared networking capabilities, or other aspects.
Implementations and all of the functional operations described in this specification may be realized in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed in this specification and their structural equivalents, or in combinations of one or more of them. Implementations may be realized as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer readable medium for execution by, or to control the operation of, data processing apparatus. The computer readable medium may be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of matter effecting a machine-readable propagated signal, or a combination of one or more of them. The term “computing system” encompasses all apparatus, devices, and machines for processing data, including by way of example a programmable processor, a computer, or multiple processors or computers. The apparatus may include, in addition to hardware, code that creates an execution environment for the computer program in question, e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them. A propagated signal is an artificially generated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal that is generated to encode information for transmission to suitable receiver apparatus.
A computer program (also known as an application, program, software, software application, script, or code), such as one or more programs used to implement the process 400, may be written in any appropriate form of programming language, including compiled or interpreted languages, and it may be deployed in any appropriate form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program may be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
The processes and logic flows described in this specification may be performed by one or more programmable processors executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows may also be performed by, and apparatus may also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).
Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any appropriate kind of digital computer. Generally, a processor may receive instructions and data from a read only memory or a random access memory or both. Elements of a computer can include a processor for performing instructions and one or more memory devices for storing instructions and data. Generally, a computer may also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto optical disks, or optical disks. However, a computer need not have such devices. Moreover, a computer may be embedded in another device, e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio player, a Global Positioning System (GPS) receiver, to name just a few. Computer readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto optical disks; and CD ROM and DVD-ROM disks. The processor and the memory may be supplemented by, or incorporated in, special purpose logic circuitry.
To provide for interaction with a user, implementations may be realized on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user may provide input to the computer. Other kinds of devices may be used to provide for interaction with a user as well; for example, feedback provided to the user may be any appropriate form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any appropriate form, including acoustic, speech, or tactile input.
Implementations may be realized in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a client computer having a graphical user interface or a web browser through which a user may interact with an implementation, or any appropriate combination of one or more such back end, middleware, or front end components. The components of the system may be interconnected by any appropriate form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet.
The computing system may include clients and servers. A client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
The operator, or if the vehicle 144 is autonomous, then vehicle and/or the operator, can apply (block 608) the verified prescription. For example, the field application of the prescription 604 may include a applying a certain type of seed genetics, seed amount, fertilizer, insecticides, pesticides, manure, and so on. Upon application (block 608), the process 600 may generate (block 610) a new application record 612, which may contain pertinent details including vehicle identity, field data, product data, weather conditions, type of seed genetics applied, seed amount applied, fertilizer applied, insecticides applied, pesticides applied, manure deposited, and so on, as well as when it was applied (date, time, or a combination thereof), application conditions (e.g., weather: wind speed/direction, precipitation, relative humidity, ambient pressure, temperature), application rates (e.g., gallons per acre, pounds per acre, and so on).
The application record 612 may then be hashed (e.g., a cryptographic hashing applied to the record 612), and the hash then written (block 614) into the distributed ledger 102. Data may then be read (block 616) from various entities (108-116) that access the distributed ledger 102. For example, public ledger registration may be maintained for future data processing, searches, etc. This would allow any interested parties such as regulatory bodies, food processors, consumers, etc. to verify the prescription record 606 and/or resulting application record 612.
While this specification contains many specifics, these should not be construed as limitations on the scope of the disclosure or of what may be claimed, but rather as descriptions of features specific to particular implementations. Certain features that are described in this specification in the context of separate implementations may also be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation may also be implemented in multiple implementations separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination may in some examples be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination.
Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems may generally be integrated together in a single software product or packaged into multiple software products.
A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the disclosure. For example, various forms of the flows shown above may be used, with steps re-ordered, added, or removed. Accordingly, other implementations are within the scope of the following claims.
