System and method for forecasting deliveries via blockchain smart contracts using hyperspectral computer vision

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation application of U.S. application Ser. No. 16/534,538, filed Aug. 7, 2019, which claims the benefit of U.S. Provisional Application No. 62/715,564, filed on Aug. 7, 2018, and the disclosures of which are incorporated by reference herein in their entirety.

TECHNICAL FIELD

A blockchain may generally refer to a distributed database that maintains a growing and ordered list or chain of records in which each block contains a hash of some or all previous records in the chain to secure the record from tampering and unauthorized revision. The blockchain may be managed in a peer-to-peer network or by a private entity.

BRIEF DESCRIPTION OF THE DRAWINGS

Illustrative embodiments are shown by way of example in the accompanying figures and should not be considered as a limitation of the present invention. The accompanying figures, which are incorporated in and constitute a part of this specification, illustrate one or more embodiments of the invention and, together with the description, help to explain the invention. In the figures:

<figref idref="DRAWINGS">FIGS. 1A-K</figref> are exemplary screens of an application to initiate delivery of physical objects in accordance with an exemplary embodiment;

<figref idref="DRAWINGS">FIGS. 2A-E</figref> are exemplary screens to be rendered on a GUI of a computing device in accordance with an exemplary embodiment;

<figref idref="DRAWINGS">FIG. 3</figref> illustrates an exemplary supply chain forecasting system in accordance with an exemplary embodiment;

<figref idref="DRAWINGS">FIG. 4</figref> illustrates an exemplary architecture in accordance with an exemplary embodiment;

<figref idref="DRAWINGS">FIG. 5</figref> depicts blocks in a blockchain as configured in accordance with an exemplary embodiment;

<figref idref="DRAWINGS">FIG. 6</figref> depicts blockchain transactions in accordance with an exemplary embodiment;

<figref idref="DRAWINGS">FIG. 7</figref> is a flowchart depicting a sequence of steps performed in an exemplary embodiment;

<figref idref="DRAWINGS">FIG. 8</figref> is a flowchart depicting a blockchain update in accordance with an exemplary embodiment;

<figref idref="DRAWINGS">FIG. 9</figref> depicts an exemplary system in accordance with an exemplary embodiment;

<figref idref="DRAWINGS">FIG. 10</figref> is a block diagram of an exemplary mobile device in accordance with an exemplary embodiment;

<figref idref="DRAWINGS">FIG. 11</figref> illustrates a block diagram of an exemplary computing device in accordance with an exemplary embodiment;

<figref idref="DRAWINGS">FIG. 12</figref> depicts an exemplary sequence of steps performed by a supply chain system in an exemplary embodiment; and

<figref idref="DRAWINGS">FIG. 13</figref> depicts an exemplary sequence of steps performed by a supply chain system in an exemplary embodiment.

DETAILED DESCRIPTION

Described in detail herein is a supply chain forecasting system with blockchain controls. In one embodiment, the supply chain forecasting system can include a central computing system executing a first application. The first application of the central computing system generates a cryptographically verifiable ledger represented by a sequence of data blocks with each data block containing one or more transaction records and each subsequent data block contains a hash value associated with a previous data block. The first application also generates a first block in the cryptographically verifiable ledger including information associated with a request for one or more physical objects. The first block includes identification information associated with the physical objects, a destination location, and one or more constraints associated with the request for delivery of the one or more physical objects. The central computing system also communicates with one or more third party computing systems that execute an instance of the first application and include a hyperspectral image sensor. At least one of the third party computing systems is configured to store a copy of a full or partial version of the cryptographically verifiable ledger, detect, via the first application, the generation of the first block including the request for the one or more physical objects, and generate, via the first application, a second block in the cryptographically verifiable ledger. The second block includes an acceptance of the request for delivery of the physical objects. The at least one third party computing system is further configured to instruct the hyperspectral image sensor to capture an image of the one or more physical objects prior to initiating delivery of the one or more physical objects, and generate, via the first application, a third block including the image of the one or more physical object captured by the hyperspectral image sensor. The central computing system is configured to detect, via the first application, the generation of the second and third block in the cryptographically verifiable ledger, execute a hyperspectral image analysis on the image of the one or more physical objects, extract one or more characteristics associated with the one or more physical objects based on the hyperspectral image analysis, derive a quality value associated with the one or more physical objects based on the one or more characteristics and generate, via the first application, a fourth block in the cryptographically verifiable ledger, the fourth block including the quality value associated with the one or more physical objects.

In one embodiment, a forecasting system can include a central computing system including a database and executing a first application. The first application of the central computing system can generate a cryptographically verifiable ledger represented by a sequence of data blocks, each data block containing one or more transaction records and each subsequent data block containing a hash value associated with a previous data block and generate a first block in the cryptographically verifiable ledger including information associated with a request for one or more physical objects. The first block includes identification information associated with the physical objects, a destination location, and one or more constraints associated with a request for delivery of the one or more physical objects. The central computing system can further communicate with one or more third party computing systems executing a copy an instance of the first application. The at least one of the third party computing systems is configured to store a copy of a full or partial version of the cryptographically verifiable ledger, detect, via the first application, the generation of the first block including the request for the one or more physical objects, and generate, via the first application, a second block in the cryptographically verifiable ledger, the second block including an acceptance of the request for delivery of the physical objects. The central computing system is further configured to queries the database to retrieve information associated with the physical objects, determine a status of the delivery of the one or more physical objects, forecast a failure of fulfillment of at least one of the constraints, and generates, via the first application, a third block in the cryptographically verifiable ledger, the third block including information associated with an action, the third block generated in response to the forecast of the failure of fulfillment of the at least one of the constraints.

In one embodiment, a forecasting method can include generating, via a central computing system executing a first application including a database, a cryptographically verifiable ledger represented by a sequence of data blocks, each data block containing one or more transaction records and each subsequent data block containing a hash value associated with a previous data block and generating, via the first application of the central computing system, a first block in the cryptographically verifiable ledger including information associated with a request for one or more physical objects. The first block includes identification information associated with the physical objects, a destination location, and one or more constraints associated with a request for delivery of the one or more physical objects. The method further includes communicating, via the first application of the central computing system, with at least one of one or more third party computing systems executing a copy an instance of the first application. The at least one of the third party computing systems is configured to store a copy of a full or partial version of the cryptographically verifiable ledger, detect, via the first application, the generation of the first block including the request for the one or more physical objects, and generate, via the first application, a second block in the cryptographically verifiable ledger, the second block including an acceptance of the request for delivery of the physical objects. The method further includes querying, via the central computing system, the database to retrieve information associated with the physical objects, determining, via the central computing system, a status of the delivery of the one or more physical objects, forecasting, via the central computing system, a failure of fulfillment of at least one of the constraints, and generating, via the first application of the central computing system, a third block in the cryptographically verifiable ledger, the third block including information associated with an action, the third block generated in response to the forecast of the failure of fulfillment of the at least one of the constraints.

Embodiments of the present invention provide a supply chain forecasting system with blockchain controls. A central computing system and third party computing systems can initiate, adjust, and fulfill smart contracts associated with the delivery of physical objects using blockchain controls. The smart contracts may use hyperspectral imaging and IOT devices to allow inventory to be tracked with respect to time, inventory and quality. The ability to share forecasts and inventory with suppliers, expedite payments and reconciliations, determine whether product is delivered on-time in full (OTIF) at designated locations, to dynamically reroute product to new locations based on tracked quality and to dynamically add replacement supply as needed are among the benefits provided by embodiments. The system can also be embodied as a system of record for various documents like commercial invoices, bill of loading, fumigation and other country specific certifications, sailing messages etc. The system can apply image analytics to ensure that the documents are genuine and can scrape the content from the documents to populate other systems, ensuring real time automation. The system can constantly monitor inventory at multiple points and ensure contingency alternatives are met. The contingency alternatives are not only within markets but also across markets. To accommodate the continency alternatives based on Smart Contract new PO's can be generated based on demand forecasting and availability of product within supply chain and inventory levels with the supplier. The smart contracts can include a time dimension, inventory dimension, and quality dimension.

<figref idref="DRAWINGS">FIGS. 1A-K</figref> are exemplary screens of a contract application to initiate delivery of physical objects in accordance with an exemplary embodiment. A central computing system and a third party computing system can execute a contract application. The contract application can be used to initiate smart contracts for deliveries of physical objects using a blockchain record. As a non-limiting example, the central computing system can be associated with a retail store and the third party computing system can be associated with a vendor. The central computing system, third party computing system, contract application, and blockchain record will be described in greater detail with respect to <figref idref="DRAWINGS">FIG. 3</figref>.

With respect to <figref idref="DRAWINGS">FIG. 1A</figref>, a central computing system can initiate the contract application. The first screen <b>100</b> can be rendered on the GUI of the contract application. The first screen <b>100</b> can include buttons to create a shipment, add trip, delay shipment, dynamic routing, and shipment information. With reference to <figref idref="DRAWINGS">FIG. 1B</figref>, a shipment screen <b>102</b> can be rendered on the GUI, in response to selecting the create shipment button on the first screen (i.e., first screen <b>200</b> as shown in <figref idref="DRAWINGS">FIG. 1A</figref>). The shipment screen <b>102</b> can include fields to generate a smart contract for a delivery of physical objects. The fields can include a channel to distribute the smart contract, chain code, peers, function name, and function arguments. The channel field can indicate a channel in which the third party computing systems can find the smart contract. The peers field can be conditions/constraints or consensus to which each party in the smart contract has to agree in order for the smart contract to execute. For example, the conditions may include an objective quality of items determined with the aid of hyperspectral imaging and IOT devices as discussed further below. The function name can be the name of the requested function such as “a shipment”. The function arguments can be the details associated with the delivery of the physical objects. The details can include destination location, date and time of expected delivery, an amount of the physical objects to be delivered, the identifier of the physical object. In response to completing the field, the central computing system can invoke the transaction to generate a new block in a blockchain record.

With reference to <figref idref="DRAWINGS">FIG. 1C</figref>, the first block screen <b>104</b> can be rendered on the GUI. The first block screen <b>104</b> can include information associated with the first block in the blockchain record. The information can include information associated with the smart contract for the delivery of the physical objects.

With reference to <figref idref="DRAWINGS">FIG. 1D</figref>, a shipment search screen <b>106</b> can be rendered on the GUI. One or more third party computing systems can query the latest blocks added to the blockchain record using the shipment search screen <b>106</b>. The query can return the block in the blockchain detailing the smart contract.

With reference to <figref idref="DRAWINGS">FIG. 1E</figref>, an acknowledgement screen <b>108</b> can be rendered on the GUI. The acknowledgement screen allows a third party system to add a trip which carries one or multiple shipments e.g.: vessel details, so that a retailer can track the shipment status through the carrier and can be informed of any delays and take reactive actions based on this delay. In response to the one or more third party computing systems adding a trip, a second block can be generated in the blockchain record.

With reference to <figref idref="DRAWINGS">FIG. 1F</figref>, a second block screen <b>110</b> can be rendered on the GUI. The second block screen <b>110</b> can include information associated with the trip added by the third party system (as shown in <figref idref="DRAWINGS">FIG. 1E</figref>).

With reference to <figref idref="DRAWINGS">FIG. 1G</figref>, a delay shipment screen <b>112</b> can be rendered on the GUI. The one or more third party computing systems can delay the shipment of the physical objects. In response to delaying the shipment, a third block can be generated in the Blockchain record detailing the delay in shipment. The delay shipment screen <b>212</b> can render the details of the third block.

With reference to <figref idref="DRAWINGS">FIG. 1H</figref>, a dynamic re-route screen <b>114</b> can be rendered on the GUI. The central computing system can dynamically reroute the delivery of the physical objects to another location, based on the current status of the delivery of the physical objects (i.e., the delay) and/or a cost/benefit analysis. A fourth block can be generated in the blockchain record detailing the rerouting of the physical objects.

With reference to <figref idref="DRAWINGS">FIGS. 1I-1K</figref>, shipment information screens <b>116</b>-<b>120</b> can be rendered on the GUI. The shipment information screen <b>116</b> can include information associated with shipment of the physical objects at the time of the initiation of the smart contract. The shipment initiation screen <b>118</b> can include shipment information associated with the delay in the shipment of the physical objects. The shipment information screen <b>120</b> can include shipment information associated with the rerouting of the shipment of the physical objects.

The information from the blocks may also be used to provide additional information to an end consumer after the product has arrived in a retail facility. <figref idref="DRAWINGS">FIGS. 2A-B</figref> are exemplary screens to be rendered on a GUI of a computing device in accordance with an exemplary embodiment. The computing device can be operated by a user or a third party computing system. The computing device can execute an object delivery application. As a non-limiting example, the object delivery application can be associated with a retail store selling products such as food or drink items. The object delivery application will be described further with respect to <figref idref="DRAWINGS">FIG. 3</figref>.

With reference to <figref idref="DRAWINGS">FIG. 2A</figref>, a first screen <b>200</b> can be rendered on a GUI of a computing device (or mobile device) executing the object delivery application. In one embodiment, a user, such as but not limited to a grocery store customer, can transmit an image of a food or drink item, via the object delivery application. In response to transmitting the image, a flavor profile value can be returned and displayed on the first screen <b>200</b>. The flavor profile value can identify characteristics associated with the food or drink item, such as skin color, sweetness, sourness, and firmness using information identified by sensors earlier in the product's trip through the supply chain and recorded in blocks. The flavor profile value can further identify compounds to minimize risks of several diseases. The flavor profile value can be a numerical value. The flavor profile value can be rendered on the first screen <b>100</b>. The first screen can include further information such as a graph of the flavor profile value over time and information associated with the origin of the food or drink item, harvest date, and remaining shelf life.

With reference to <figref idref="DRAWINGS">FIG. 2B</figref>, a second screen <b>210</b> can be rendered on the GUI. The second screen <b>210</b> can include options to share the flavour profile value on messenger/social media websites, such as Facebook®, Twitter®, Snapchat®, or WhatsApp®. The messenger/social media websites hyperlinks can be embedded in icons which are rendered on the second screen <b>210</b>. In response to selecting the links the flavor profile value of the food or drink item can be embedded on the messenger/social media website.

With reference <figref idref="DRAWINGS">FIG. 2C</figref>, a third screen <b>220</b> can be rendered on the GUI. The third screen <b>120</b> can include a button to place an order for the food or drink item. The third screen <b>120</b> can include store IDs where the food or drink item is available. In response to clicking the “place order button” the food or item can be automatically and delivered at a desired location.

With reference to <figref idref="DRAWINGS">FIG. 2D</figref>, a fourth screen <b>230</b> can rendered on the GUI. The fourth screen <b>230</b> can include an option to provide comments associated with the food or drink item and the flavor profile value.

With reference to <figref idref="DRAWINGS">FIG. 2E</figref>, a fifth screen <b>250</b> depicting the supply chain process can be rendered on the GUI. The supply chain process can begin at the production stage. For example, in operation <b>252</b> food item such as cherries can be harvested. In operation <b>254</b>, the cherries can be loaded and transported on local transportation to a packaging location. In operation <b>256</b>, the cherries can be packaged. In operation <b>258</b>, the cherries can be loaded and transported to an origin port. In operation <b>260</b>, the cherries can arrive at the origin port.

In operation <b>262</b>, the cherries can be loaded and transported on a vessel such as train, airplane, truck, or cargo ship. In operation <b>264</b>, the cherries can reach a destination port. In operation <b>266</b>, the cherries can be hauled by dray. In operation <b>268</b>, the cherries can be stored in a warehouse. In operation <b>270</b>, the cherries can be transported to a general distribution center. In operation <b>272</b>, the cherries can be transported and displayed at a retail store for sale.

The supply chain process can include an expected time each operation was supposed to take and the actual time each operation took. The supply chain process can also include the amount of days it may take to reach the retail store. It can be appreciated, that while cherries was used as an example, any other type of physical object may also go through the described supply chain process.

In one embodiment, hyperspectral imaging of the physical objects may take place at one or more steps of the objects journey throughout the supply chain and the data gathered by the hyperspectral imaging may be added to associated blocks and/or used to construct a flavor profile for the physical objects. For example, hyperspectral imaging of an object may take place at a farm, at a packaging facility, at a shipping location and/or at a destination location. Additionally, environmental and other data associated with the physical objects such as humidity levels, temperature, vibration levels, light levels, etc. may be gathered by one or more IOT devices and the gathered data may be added to a block associated with the object.

<figref idref="DRAWINGS">FIG. 3</figref> illustrates an exemplary network diagram of a supply chain forecasting system <b>350</b> in accordance with an exemplary embodiment. The supply chain forecasting system <b>350</b> can include one or more data storage devices <b>305</b>, one or more central computing systems <b>300</b>, one or more third party computing systems <b>340</b>, one or more user devices <b>342</b>, one or more hyperspectral image sensors <b>355</b>, and one or more intermediate party computing system <b>370</b>. The central computing system <b>300</b> can be in communication with the data storage devices <b>305</b>, the third party computing systems <b>340</b>, the user devices <b>342</b>, the hyperspectral image sensors <b>355</b>, and the intermediate party computing system <b>370</b>, via a communications network <b>315</b>. The user devices <b>342</b> can be associated with users. The third party computing systems <b>340</b> can be associated with third party entities delivering physical objects. The third party computing systems <b>340</b> and the user devices <b>342</b> can execute an instance of the object delivery application <b>332</b>. The object delivery application <b>332</b> can be an executable application configured to provide tracking on the delivery of physical objects.

The central computing system <b>300</b> can execute at least one instance of a control engine <b>320</b>. The control engine <b>320</b> can be an executable application executed on the central computing system <b>300</b>. The control engine <b>320</b> can execute the process of the supply chain forecasting system <b>350</b> as described herein. The control engine <b>320</b> can include a contracts application <b>333</b>, the contracts application <b>333</b> can be configured to initiate, edit and track smart contracts.

In an example embodiment, one or more portions of the communications network <b>315</b> can be an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless wide area network (WWAN), a metropolitan area network (MAN), a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a cellular telephone network, a wireless network, a WiFi network, a WiMax network, another type of network, or a combination of two or more such networks.

The central computing system <b>300</b> includes one or more computers or processors configured to communicate with the third party computing systems <b>340</b>, the user devices <b>342</b>, the hyperspectral sensors <b>355</b>, and the intermediate party computing system <b>370</b>. The data storage devices <b>305</b> can store information/data, as described herein. For example, the data storage devices <b>305</b> can include a physical objects database <b>335</b>, analytics database <b>345</b>, and a delivery blockchain <b>330</b>. The physical objects database <b>335</b> can include information associated with physical objects and a representation of physical objects. The delivery blockchain <b>330</b> can be embodied as a blockchain storage system that is configured to store a blockchain record or a shared ledger based on a delivery of physical objects to and from a third party. A blockchain may generally refer to a distributed database that maintains a growing and ordered list or chain of records in which each block contains a hash of some or all previous records in the chain to secure the record from tampering and unauthorized revision. A hash generally refers to a derivation of original data. In some embodiments, the hash in a block of a blockchain may include a cryptographic hash that is difficult to reverse and/or a hash table. Blocks in a blockchain may further be secured by a system involving one or more of a distributed timestamp server, cryptography, public/private key authentication and encryption, proof standard (e.g. proof-of-work, proof-of-stake, proof-of-space), and/or other security, consensus, and incentive features. In some embodiments, a block in a blockchain may include one or more of a data hash of the previous block, a timestamp, a cryptographic nonce, a proof standard, and a data descriptor to support the security and/or incentive features of the system. As an example, the blockchain storage system can store digital licenses, invoices, receipts, or rights of ownership associated with physical objects and the central computing system <b>300</b> can use the blocks of the blockchain to authorize the transfer of ownership of physical objects. The analytics database <b>345</b> can store data associated with forecasting the delivery of physical objects. The data storage devices <b>305</b> and the central computing system <b>300</b> can be located at one or more geographically distributed locations from each other. Alternatively, the data storage devices <b>305</b> can be included within the central computing system <b>300</b>.

The central computing system <b>300</b> can include one or more nodes <b>325</b>. Each of the one or more nodes <b>325</b> can store a copy of the delivery blockchain <b>330</b> associated with the transfer of one or more physical objects. The one or more nodes <b>325</b> can be configured to update the blocks in the delivery blockchain <b>330</b> based on the operation or transfer of one or more physical objects. The third party computing system <b>342</b> can execute an instance of the contract application <b>333</b> and a node <b>334</b>. The node <b>334</b> can store a partial and/or full copy of the delivery blockchain <b>330</b>. The contract application <b>333</b> can be an executable application configured to search the blockchain records and accept smart contracts included in blocks of the blockchain record. The intermediate party computing system <b>370</b> can include a node <b>375</b>. The node <b>375</b> can store a partial and/or full copy of the delivery blockchain <b>375</b>. The nodes <b>325</b>, <b>334</b>, and <b>375</b> can receive an alert each time a new block is generated in the delivery blockchain <b>375</b>. The nodes <b>325</b>, <b>334</b>, and <b>375</b> can verify the event which spawned the creation of the new block in the delivery blockchain <b>330</b>.

In one embodiment, the control engine <b>320</b> can execute the contract application <b>333</b> of the central computing system <b>300</b> can generate a smart contract for delivery of a specified amount of one or more physical objects. The smart contract can also include identifiers associated with the physical objects and a destination location. The smart contract can include constraints/conditions which must occur for the smart contract to execute. The smart contract can include a consensus. The consensus can be the parties (i.e., third party computing systems <b>340</b>) which need to accept the smart contract. Upon delivery of the physical objects and fulfilling the constraints/conditions the smart contract can automatically self-execute. For example, the constraints/conditions can include one or more of a type of physical object, condition of physical object, a specified amount of the physical object, delivery location, type of third party computing system delivering the object, price, a total monetary value, date and time of delivery and cost associated with delivery. In response to the generation of the smart contract, the node <b>325</b> can create a new block in the delivery blockchain <b>330</b>. The new block can store a copy of the smart contract including the identifiers associated with the physical objects, destination location, and constraints/conditions associated with the smart contract.

A third party computing system <b>342</b>, using the contract application <b>333</b> can query the delivery blockchain <b>330</b> and identify the new block including the smart contract. The third party computing system <b>342</b> can generate a new event by accepting the smart contract. In response to the new event being generated, the node <b>334</b> can create a new block in the delivery blockchain <b>330</b>. The node <b>325</b> can receive an alert of the new block including the acceptance/acknowledgment of the smart contract by the third party computing system <b>342</b>. The new block can include a hash value of the previous block.

In one embodiment, in response to the delivery blockchain creating a new block including the smart contract, the node <b>325</b> can transmit an alert to some or all third party computing systems <b>342</b> of the creation of the new block in the delivery blockchain including the smart contract. Alternatively, or in addition to, the node <b>334</b> can automatically determine a new block has been created. In one embodiment, the contract application <b>333</b> can identify the smart contract and the identifiers associated with the physical objects, destination location, and constraints/conditions associated with the smart contract. The contract application <b>333</b> of the third party computing system <b>340</b> can automatically accept the smart contract in response to being able to forecast fulfillment of the contract.

In response to the, third party computing system <b>340</b> accepting the smart contract, the control engine <b>320</b> can begin to track the delivery of the physical objects. The third party computing systems <b>340</b> can begin the delivery of the physical objects. The third party computing system <b>340</b> can interface with multiple intermediate party computing systems <b>370</b> to complete the delivery of the physical objects. The intermediate party computing system <b>370</b> can be part of the consensus. The intermediate party computing system <b>370</b> can be associated with the delivery entities, airlines, couriers, suppliers, distributors, farms, or other entities associated with delivering physical objects. In one embodiment, the intermediate party computing system <b>370</b> can be, or can include, IoT devices. Each time a third party computing system <b>340</b> interfaces with an intermediate party system <b>370</b> the node <b>334</b> or the node <b>375</b> can generate a new block indicating the new event associated with the delivery of the physical objects. For example, the new event can be packaging of the physical objects, loading the physical objects onto a transportation vehicle, or other events associated with the delivery of the physical object. Each new block can include a hash value of the previous block. In response to the delivery of the physical objects and fulfilling all of the constraints/conditions, the node <b>325</b> can generate a new block in the delivery blockchain <b>330</b> indicating the fulfilment of the smart contract. The new block can include a hash value of the previous block.

In one embodiment, the control engine <b>320</b> can query the analytics database <b>345</b> to retrieve information forecasting the delivery of the physical objects. The analytics database <b>345</b> can include information such as information associated with the third party computing system <b>340</b> such as past history of delivery of physical objects, the travel time from the third party computing system <b>340</b>, and other forecasting information associated with the physical object. The control engine <b>320</b> can further retrieve information associated with the delivery of the physical object from the blocks associated with the delivery of the physical objects in the delivery blockchain <b>330</b>. The information can include a location and status of the physical objects. The control engine <b>320</b> can reach a determination that one or more constraints/conditions of the smart contract may not be fulfilled and in view of this the smart contract may not be executed, based on the information associated with the delivery of the physical objects and the information retrieved from the analytics database <b>345</b>. For example, the control engine <b>320</b> can determine based on the information received from the blocks in the delivery blockchain <b>330</b> that a less than a specified amount of physical objects were loaded onto a delivery vehicle associated with an intermediate party system <b>340</b>. As another example, the control engine <b>320</b> can determine the delivery is going to take longer than the date and time of delivery indicated in the constraints/conditions of the smart contract due to inclement weather, heavy traffic, or other circumstances, based on information retrieved from the analytics database <b>330</b>. As another example, the control engine <b>320</b> can determine the third party computing system <b>340</b> may not be able to fulfill the delivery of the physical objects based on the availability of the physical objects for the third party computing system.

In one embodiment, in response to the control engine <b>320</b> determining that the smart contract may not be executed based on a failure of meeting one of the constraints/conditions of the smart contract, the contract application <b>333</b> can instruct the node <b>325</b> to generate a new block in the delivery blockchain <b>330</b> indicating a cancelation of the smart contract. Alternatively, the contract application <b>333</b> can instruct the node <b>325</b> to generate a new block of the smart contract including an adjustment to the constraints/conditions of the smart contract. For example, the adjustments can be associated with the specified amount of physical objects, the delivery costs, monetary amount due, date and time of expected delivery, a re-routing of the delivery to a new delivery destination location, or other data associated with the delivery of the physical objects. Alternatively, or in addition to, the node <b>325</b> can generate a side chain with a new block including the new smart contract to reconcile the constraints/conditions not being met.

In one embodiment, the physical objects requested for delivery can be a perishable item such as food or drink items. A flavor profile can be associated with the food or drink item. The flavor profile can indicate characteristics of the food or drink item, such as color, taste, and physical state. As an example, the food or drink can be cherries. The flavor profile can be associated with the skin color, sweetness, sourness, and firmness of the cherries. The flavor profile can be a numerical value. As a non-limiting example, the numerical value can be from 0-10, where <b>10</b> represents a high flavor value and <b>0</b> represents a low flavor value.

The node <b>325</b> can generate new block in the delivery blockchain, including a smart contract for a food or drink item. The constraints/conditions for the smart contract can include a specified flavor profile. For example, the condition of the smart contract can be that the food or drink item cannot have a less than a specified flavor profile value at the time of delivery of the food or drink item. Additionally, a constraint/condition of the smart contract can include a hyperspectral image sensor reading of the food or drink item prior to delivery of the food or drink item. A hyperspectral image sensor <b>355</b> can capture an image of a physical object. The hyperspectral image sensor <b>355</b> can obtain the spectrum for each pixel of an image in a scene. A hyperspectral image sensor's <b>355</b> image can be used to find objects, identify materials, and detect process. For example, a hyperspectral image sensor's <b>355</b> image can be used to determine a decomposing or damaged food item. In this regard, the hyperspectral image sensor's <b>355</b> image can be used to determine color, taste, and physical state of a food or drink item. Additionally the hyperspectral image sensor <b>355</b> can be an Internet of Things (IoT) device. The hyperspectral image sensor <b>355</b> can include a transceiver and communicate over the communications network <b>315</b>.

A third party computing system <b>340</b> can accept the smart contract by the node <b>334</b> generating a new block in the delivery blockchain <b>330</b>, including an acceptance/acknowledgement of the smart contract and the hash value of the block including the smart contract. Prior to delivery, the third party computing system <b>340</b> can capture an image of the food or drink items using the hyperspectral image sensor <b>355</b>. The node <b>334</b> can generate a new block including the image captured by the hyperspectral image sensor <b>355</b>. The control engine <b>320</b> can determine a flavor profile value of the food or drink items by executing an analysis of the image captured by the hyperspectral image sensor <b>355</b>. The control engine <b>320</b> can generate a new block in the delivery blockchain <b>330</b> including the flavor profile value of the food or drink item.

The control engine <b>320</b>, via the contract application <b>333</b>, can track the delivery of the food or drink item. The flavor profile value can decrease overtime. The control engine <b>320</b> can determine the rate at which the flavor profile value decreases over time. Each time the flavor profile value decreases more than a threshold amount, the node <b>325</b> can generate a new block in the delivery blockchain <b>330</b> including the new flavor profile value. The control engine <b>320</b> can retrieve information from the analytics database <b>345</b> and retrieve the information associated with the delivery of the food or drink item from the delivery blockchain <b>330</b>. The control engine <b>320</b> can determine that the flavor profile value of the food or drink item may decrease below a specified threshold level by the time of the delivery, based on the retrieved information from the analytics database <b>345</b> and the information associated with the delivery of the food or drink item. In one embodiment, the contract application <b>333</b> can instruct the node <b>325</b> to generate a new block in the delivery blockchain <b>330</b> including information associated with voiding the smart contract, in response to the control engine <b>320</b> determining that the flavor profile value of the food or drink item may decrease below a minimum threshold amount. Alternatively, the contract application <b>333</b> can instruct the node <b>325</b> to generate a new block in the delivery blockchain <b>330</b> including an adjustment of the constraints/conditions of the smart contract. The adjustments can be a change in monetary value, an adjustment to the minimum threshold flavor profile value, or a re-routing of the delivery to a new delivery destination location.

As a non-limiting example, the supply chain forecasting system <b>350</b> can be implemented as in a retail store and/or e-commerce website. The physical objects can be products for inventory at retail stores. The third party computing systems <b>340</b> can be vendors or suppliers of the products. The central computing system <b>300</b> can be associated with the retail store. The user device <b>342</b> can be associated with a customer. The retail store can purchase inventory from the vendors of or suppliers. The delivery blockchain <b>330</b> can be used to track the delivery of the products. In one embodiment, based on the real-time tracking of the delivery of the retail store can re-route the delivery to different stores. For example, based on the real-time tracking, if it is determined a flavor profile value of a food or drink item is going to decrease below a minimum threshold amount by the time of delivery, the delivery of the food or drink item can be re-routed to another retail store that is closer to the current location of the delivery of the food or drink item. In another embodiment, if the real-time tracking indicates that fewer physical objects than agreed may arrive at a destination by a due date, additional supplies of the physical objects may be programmatically ordered from a different supplier to ensure an adequate supply.

In one embodiment, a customer can execute the object delivery application <b>332</b> on their user device <b>342</b>. The object delivery application <b>332</b> can render screens (i.e., screens <b>100</b>-<b>130</b>) providing a GUI on the user device <b>342</b> that indicate the flavor profile value of the food or drink item delivered to the retail store. A customer can track the delivery from the originating location to the delivery of the retail store using the user application <b>342</b>. The customer can also track the change in the flavor profile value of the food or drink item over time. Each time a new block is generated in the delivery blockchain including a new flavor profile value of the food or drink item, the control engine <b>320</b> can interface with the object delivery application <b>332</b> to update the flavor profile value. In one embodiment, the third party computing system <b>340</b> can also track the flavor profile value by executing an instance of the object delivery application <b>332</b>.

<figref idref="DRAWINGS">FIG. 4</figref> illustrates an exemplary architecture <b>400</b> of the supply chain forecasting system in accordance with exemplary embodiments. The architecture <b>400</b> can include a mobile device <b>402</b>, a hyperledger blockchain node <b>404</b>, a database <b>406</b>, a DMZ <b>408</b>, an app server <b>410</b>, a message broker <b>412</b>, an analytics engine <b>414</b>. The hyperledger blockchain node <b>404</b> can store a copy of a blockchain record associated with a flavor profile value of a food or drink item. The mobile device <b>402</b> can execute an instance of an application (e.g., object delivery application <b>332</b> or contract application <b>333</b> as described in <figref idref="DRAWINGS">FIG. 3</figref>). The application can be hosted on the app server <b>410</b>. The mobile device <b>402</b> can be a user device (e.g., user device <b>342</b> as shown in <figref idref="DRAWINGS">FIG. 3</figref>) or a part of a third party computing system (e.g., third party computing system <b>340</b> as shown in <figref idref="DRAWINGS">FIG. 3</figref>).

The DMZ <b>408</b> can be embodied as a firewall configured to interface with the user device <b>342</b> and the app server and hyper blockchain node <b>404</b>. The DMZ can include a message broker <b>409</b>. The message broker <b>409</b> can receive and distribute messages from the DMZ <b>408</b>. The analytics engine can be separate or integrated with the control engine (e.g., control engine <b>320</b> as shown in <figref idref="DRAWINGS">FIG. 3</figref>). The database <b>406</b> can be separate or be integrated with the databases (e.g., databases <b>305</b> as shown in <figref idref="DRAWINGS">FIG. 3</figref>).

In one embodiment, a mobile device <b>402</b> can capture an image of a food or drink item and transmit the image to the app server <b>410</b>. The message broker <b>409</b> of the DMZ <b>408</b> can receive the image and forward the image to the hyperledger blockchain node <b>404</b> and the app server <b>410</b>. The hyperledger blockchain node <b>404</b> can create a new block in the blockchain record associated with the flavor profile values of the food or drink items. The new block can include the image of the food or drink item. The app server <b>410</b> can retrieve information associated with the food or drink item from the database <b>406</b>. The app server <b>410</b> can forward the image and information associated with the food or drink item, to the analytics engine, via the message broker <b>412</b>. The analytics engine <b>414</b> can execute an analysis on the image to determine the flavor profile value of the food or drink item based on the image and the information retrieved from the database <b>406</b>. The analytics engine <b>414</b> can also determine a forecast of a rate at which the flavor profile value may decrease overtime. The analytics engine <b>414</b> can transmit the flavor profile value to the app server <b>410</b>. The app server can transmit the flavor profile value to the hyperledger blockchain node <b>404</b>. The hyperledger blockchain node <b>404</b> can create a new block in the blockchain record associated with the flavor profile values of the food or drink items. The new block can include the flavor value of the food or drink item. The app server <b>410</b> can also transmit the flavor profile value to the mobile device <b>402</b>, via the message broker <b>409</b> of the DMZ <b>408</b>. The flavor profile value can be rendered on the display of the mobile device <b>402</b>.

Descriptions of some embodiments of blockchain technology are provided with reference to <figref idref="DRAWINGS">FIGS. 5-9</figref> herein. In some embodiments, blockchain technology may be utilized to track/verify the delivery of physical objects as described herein. One or more of the central computing systems described herein may include a node in a distributed blockchain system storing a copy of the blockchain record. Updates to the blockchain may include information associated with requests for transferring one or more physical objects, and one or more nodes on the system may be configured to incorporate one or more updates into blocks to add to the distributed database.

Distributed database and shared ledger database generally refer to methods of peer-to-peer record keeping and authentication in which records are kept at multiple nodes in the peer-to-peer network instead of being kept at a trusted party. However, exemplary embodiments of the present disclosure can also utilize a private (trusted) system to maintain the blockchains.

In some embodiments, the supply chain forecasting system includes a distributed timestamp server including multiple nodes configured to generate computational proof of record integrity and the chronological order of its use for content, trade, and/or as a currency of exchange through a peer-to-peer network. In some embodiments, when a blockchain is updated, a node in the distributed timestamp server system takes a hash of a block of items to be timestamped and broadcasts the hash to other nodes on the peer-to-peer network. The timestamp in the block serves to prove that the data existed at the time in order to get into the hash. In some embodiments, each block includes the previous timestamp in its hash, forming a chain, with each additional block reinforcing the ones before it. In some embodiments, the network of timestamp server nodes performs the following steps to add a block to a chain: 1) new activities are broadcasted to all nodes, e.g., resulting from in-field authentication of autonomous electronic devices, 2) each node collects new activities into a block, 3) each node works on finding a difficult proof-of-work for its block, 4) when a node finds a proof-of-work, it broadcasts the block to all nodes, 5) nodes accept the block only if activities are authorized, and 6) nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash. In some embodiments, nodes may be configured to consider the longest chain to be the correct one and work on extending it.

Now referring to <figref idref="DRAWINGS">FIG. 5</figref>, an illustration of a blockchain according to embodiments of the present disclosure is shown. As mentioned in above, with reference to <figref idref="DRAWINGS">FIG. 3</figref>, a blockchain includes a hash chain or a hash tree in which each block added in the chain contains a hash of the previous block. In <figref idref="DRAWINGS">FIG. 5</figref>, block <b>0</b><b>500</b> represents a genesis block of the chain and can be generated in response to initiation of a request to transfer one or more physical objects. The block <b>0</b><b>500</b> can include information associated with the delivery of the one or more physical objects and a hash key, and a timestamp. The information associated with the delivery of the one or more physical objects can include information associated with the physical objects, destination location, a smart contract, constraints/conditions of the smart contract, updates to the delivery of the physical objects, a hyperspectral image of the physical object, and information associated with the ownership of the physical objects. Block <b>1</b><b>510</b> can be generated in response to a verification of the transfer of the physical objects during the delivery process of the physical objects. The block <b>1</b><b>510</b> can contain a hash of block <b>0</b><b>500</b>. If the transfer of one or more physical objects is verified the block <b>1</b><b>510</b> can include the information associated with the transfer of the physical objects and updates to the delivery of the physical objects. Otherwise, the block <b>1</b><b>510</b> can include information indicating a transfer was not verified. Additional blocks can be generated as additional requests are received and each block that is generated can include a hash of a previous block. For example, block <b>2</b><b>520</b> can be generated in response to a subsequent request and can contain a hash of block <b>1</b><b>510</b>, block <b>3</b><b>530</b> can be generated in response to a yet another subsequent request and can contain a hash of block <b>2</b><b>520</b>, and so forth. Continuing down the chain, block N contains a hash of block N-<b>1</b>. The block N can include information of the execution or failure to execute a smart contract. In some embodiments, the hash may include the header of each block. Once a chain is formed, modifying or tampering with a block in the chain would cause detectable disparities between the blocks. For example, if block <b>1</b> is modified after being formed, block <b>1</b> would no longer match the hash of block <b>1</b> in block <b>2</b>. If the hash of block <b>1</b> in block <b>2</b> is also modified in an attempt to cover up the change in block <b>1</b>, block <b>2</b> would not then match with the hash of block <b>2</b> in block <b>3</b>. In some embodiments, a proof standard (e.g. proof-of-work, proof-of-stake, proof-of-space, etc.) may be required by the system when a block is formed to increase the cost of generating or changing a block that could be authenticated by the consensus rules of the distributed system, making the tampering of records stored in a blockchain computationally costly and essentially impractical. In some embodiments, a blockchain may include a hash chain stored on multiple nodes as a distributed database and/or a shared ledger, such that modifications to any one copy of the chain would be detectable when the system attempts to achieve consensus prior to adding a new block to the chain. In some embodiments, a block may generally contain any type of data and record. In some embodiments, each block may include a plurality of transaction and/or activity records.

In some embodiments, the blocks generated by the central computing system can contain rules and data for authorizing different types of actions and/or parties who can take action as described herein. In some embodiments, transaction and block forming rules may be part of the software algorithm on each node. When a new block is being formed, any node on the system can use the prior records in the blockchain to verify whether the requested action is authorized. For example, a block may contain a public key associated with the user of a user device that purchased/acquired the design file that allows the user to show possession and/or transfer the digital license using a private key. Nodes may verify that the user is in possession of the one or more physical objects and/or is authorized to transfer the one or more physical objects based on prior transaction records when a block containing the transaction is being formed and/or verified. In some embodiments, rules themselves may be stored in the blockchain such that the rules are also resistant to tampering once created and hashed into a block. In some embodiments, the blockchain system may further include incentive features for nodes that provide resources to form blocks for the chain. Nodes can compete to provide proof-of-work to form a new block, and the first successful node of a new block earns a reward.

Now referring to <figref idref="DRAWINGS">FIG. 6</figref>, an illustration of blockchain based transactions according to some embodiments is shown. In some embodiments, the blockchain illustrated in <figref idref="DRAWINGS">FIG. 6</figref> includes a hash chain protected by private/public key encryption. Transaction A <b>610</b> represents a transaction recorded in a block of a blockchain showing that owner <b>1</b> (recipient) (e.g., a first user who acquired the physical objects from owner <b>0</b> such as a supplier). Transaction A <b>610</b> contains owner's <b>1</b> public key and owner <b>0</b>'s signature for the transaction and a hash of a previous block. When owner <b>1</b> (e.g., the first user) transfers the physical objects to owner <b>2</b> (e.g., a second user such as another user in the supply chain), a block containing transaction B <b>620</b> is formed. The record of transaction B <b>620</b> includes the public key of owner <b>2</b> (recipient), a hash of the previous block, and owner <b>1</b>'s signature for the transaction that is signed with the owner <b>1</b>'s private key <b>625</b> and verified using owner <b>1</b>'s public key in transaction A <b>610</b>. If owner <b>2</b> (e.g., the second user) transfers the physical objects to owner <b>3</b> (the third user, such as another user in the supply chain), a block containing transaction C <b>630</b> is formed. The record of transaction C <b>630</b> includes the public key of owner <b>3</b> (recipient), a hash of the previous block, and owner <b>2</b>'s signature for the transaction that is signed by owner <b>2</b>'s private key <b>635</b> and verified using owner <b>2</b>'s public key from transaction B <b>620</b>. In some embodiments, when each transaction record is created, the system may check previous transaction records and the current owner's private and public key signature to determine whether the transaction is valid. In some embodiments, transactions are be broadcasted in the peer-to-peer network and each node on the system may verify that the transaction is valid prior to adding the block containing the transaction to their copy of the blockchain. In some embodiments, nodes in the system may look for the longest chain in the system to determine the most up-to-date transaction record to prevent the current owner from double spending the asset. The transactions in <figref idref="DRAWINGS">FIG. 6</figref> are shown as an example only. In some embodiments, a blockchain record and/or the software algorithm may include any type of rules that regulate who and how the chain may be extended. In some embodiments, the rules in a blockchain may include clauses of a smart contract that is enforced by the peer-to-peer network.

Now referring to <figref idref="DRAWINGS">FIG. 7</figref>, a flow diagram according to some embodiments is shown. In some embodiments, the steps shown in <figref idref="DRAWINGS">FIG. 7</figref> may be performed by a computer system as described in <figref idref="DRAWINGS">FIG. 3</figref>, a server, a distributed server, a timestamp server, a blockchain node, and the like. In some embodiments, the steps in <figref idref="DRAWINGS">FIG. 7</figref> may be performed by one or more of the nodes in a system using blockchain for record keeping.

In step <b>701</b>, a node receives a new activity in response to a request for delivery of one or more physical objects. The new activity may include an update to the record being kept in the form of a blockchain. In some embodiments, for blockchain supported digital or physical record keeping, the new activity can correspond to the ownership of the one or more physical objects and/or the transfer of the ownership of the physical objects from a first user to a second user. In some embodiments, the new activity may be broadcasted to a plurality of nodes on the network prior to step <b>701</b>. In step <b>702</b>, the node works to form a block to update the blockchain. In some embodiments, a block may include a plurality of activities or updates and a hash of one or more previous block in the blockchain. In some embodiments, the system may include consensus rules for individual transactions and/or blocks and the node may work to form a block that conforms to the consensus rules of the system. In some embodiments, the consensus rules may be specified in the software program running on the node. For example, a node may be required to provide a proof standard (e.g. proof of work, proof of stake, etc.) which requires the node to solve a difficult mathematical problem for form a nonce in order to form a block. In some embodiments, the node may be configured to verify that the activity is authorized prior to working to form the block. In some embodiments, whether the activity is authorized may be determined based on records in the earlier blocks of the blockchain itself.

After step <b>702</b>, if the node successfully forms a block in step <b>705</b> prior to receiving a block from another node, the node broadcasts the block to other nodes over the network in step <b>706</b>. In step <b>720</b>, the node then adds the block to its copy of the blockchain. In the event that the node receives a block formed by another node in step <b>703</b> prior to being able to form the block, the node works to verify that the activity (e.g., authentication of transfer) recorded in the received block is authorized in step <b>704</b>. In some embodiments, the node may further check the new block against system consensus rules for blocks and activities to verify whether the block is properly formed. If the new block is not authorized, the node may reject the block update and return to step <b>702</b> to continue to work to form the block. If the new block is verified by the node, the node may express its approval by adding the received block to its copy of the blockchain in step <b>720</b>. After a block is added, the node then returns to step <b>701</b> to form the next block using the newly extended blockchain for the hash in the new block.

In some embodiments, in the event one or more blocks having the same block number is received after step <b>720</b>, the node may verify the later arriving blocks and temporarily store these blocks if they pass verification. When a subsequent block is received from another node, the node may then use the subsequent block to determine which of the received blocks is the correct/consensus block for the blockchain system on the distributed database and update its copy of the blockchain accordingly. In some embodiments, if a node goes offline for a time period, the node may retrieve the longest chain in the distributed system, verify each new block added since it has been offline, and update its local copy of the blockchain prior to proceeding to step <b>701</b>.

Now referring to <figref idref="DRAWINGS">FIG. 8</figref>, a process diagram for a blockchain update according to some embodiments is shown. In step <b>801</b>, party A (an initial user such as a third party computing system) initiates the delivery and transfer one or more physical objects to party B (the retail store). In some embodiments, Party A may be authenticated by signing the transaction with a private key that may be verified with a public key in the previous transaction associated with the physical objects are to be transferred. In step <b>802</b>, the authentication initiated in step <b>801</b> is represented as a block. In some embodiments, the transaction may be compared with transaction records in the longest chain in the distributed system to verify part A's authentication. In some embodiments, a plurality of nodes in the network may compete to form the block containing the authentication record. In some embodiments, nodes may be required to satisfy proof-of-work by solving a difficult mathematical problem to form the block. In some embodiments, other methods of proof such as proof-of-stake, proof-of-space, etc. may be used in the system. In step <b>803</b>, the block is broadcasted to parties in the network. In step <b>804</b>, nodes in the network authenticate party A by examining the block that contains the party A's authentication. In some embodiments, the nodes may check the solution provided as proof-of-work to approve the block. In some embodiments, the nodes may check the transaction against the transaction record in the longest blockchain in the system to verify that the transaction is valid (e.g. party A is in possession of the object to be transferred). In some embodiments, a block may be approved with consensus of the nodes in the network. After a block is approved, the new block <b>806</b> representing the authentication is added to the existing chain <b>805</b> including blocks that chronologically precede the new block <b>806</b>. The new block <b>806</b> may contain the transaction(s) and a hash of one or more blocks in the existing chain <b>805</b>. In some embodiments, each node may then update their copy of the blockchain with the new block and continue to work on extending the chain with additional transactions. In step <b>807</b>, when the chain is updated with the new block, the physical objects can be transferred from party A to party B.

Now referring to <figref idref="DRAWINGS">FIG. 9</figref>, a system according to some embodiments is shown. A supply chain forecasting system includes a plurality of nodes <b>910</b> communicating over a network <b>920</b>. In some embodiments, the nodes <b>910</b> may include a distributed blockchain server and/or a distributed timestamp server. Each node <b>910</b> in the system includes a network interface <b>911</b>, a control circuit <b>912</b>, and a memory <b>913</b>.

The control circuit <b>912</b> may include a processor, a microprocessor, and the like and may be configured to execute computer readable instructions stored on a computer readable storage memory <b>913</b>. The computer readable storage memory may include volatile and/or non-volatile memory and have stored upon it a set of computer readable instructions which, when executed by the control circuit <b>912</b>, causes the node <b>910</b> update the blockchain <b>914</b> stored in the memory <b>913</b> based on communications with other nodes <b>910</b> over the network <b>920</b>. In some embodiments, the control circuit <b>912</b> may further be configured to extend the blockchain <b>914</b> by processing updates to form new blocks for the blockchain <b>914</b>. Generally, each node may store a version of the blockchain <b>914</b>, and together, may form a distributed database. In some embodiments, each node <b>910</b> may be configured to perform one or more steps described with reference to <figref idref="DRAWINGS">FIGS. 7-9</figref> herein.

The network interface <b>911</b> may include one or more network devices configured to allow the control circuit to receive and transmit information via the network <b>920</b>. In some embodiments, the network interface <b>911</b> may include one or more of a network adapter, a modem, a router, a data port, a transceiver, and the like. The network <b>920</b> may include a communication network configured to allow one or more nodes <b>910</b> to exchange data. In some embodiments, the network <b>920</b> may include one or more of the Internet, a local area network, a private network, a virtual private network, a home network, a wired network, a wireless network, and the like. In some embodiments, the system does not include a central server and/or a trusted third party computing system. Each node in the system may enter and leave the network at any time.

With the system and processes shown, once a block is formed, the block cannot be changed without redoing the work to satisfy census rules thereby securing the block from tampering. A malicious attacker would need to provide proof standard for each block subsequent to the one he/she seeks to modify, race all other nodes, and overtake the majority of the system to affect change to an earlier record in the blockchain.

In some embodiments, blockchain may be used to support a payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party. A blockchain system uses a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. Generally, a blockchain system is secure as long as honest nodes collectively control more processing power than any cooperating group of attacker nodes. With a blockchain, the transaction records are computationally impractical to reverse. As such, sellers are protected from fraud and buyers are protected by the routine escrow mechanism.

In some embodiments, in the peer-to-peer network, the longest chain proves the sequence of events witnessed, proves that it came from the largest pool of processing power, and that the integrity of the document has been maintained. In some embodiments, the network for supporting blockchain based record keeping requires minimal structure. In some embodiments, messages for updating the record are broadcast on a best-effort basis. Nodes can leave and rejoin the network at will and may be configured to accept the longest proof-of-work chain as proof of what happened while they were away.

<figref idref="DRAWINGS">FIG. 10</figref> is a block diagram of a mobile device that can be utilized to implement and/or interact with embodiments of a location verification system in an exemplary embodiment. The mobile device <b>402</b> can be a smartphone, tablet, subnotebook, laptop, personal digital assistant (PDA), or a handheld device, such as a Symbol® MC18 and/or any other suitable mobile device that can be programmed and/or configured to implement and/or interact with embodiments of the system via wireless communication. The mobile device <b>402</b> can be the user device (e.g., user device <b>342</b> as shown in <figref idref="DRAWINGS">FIG. 3</figref>), can be part of the third party computing system (e.g., third party computing system <b>340</b> as shown in <figref idref="DRAWINGS">FIG. 3</figref>), or party of the central computing system (e.g., central computing system <b>300</b> as shown in <figref idref="DRAWINGS">FIG. 3</figref>).

The mobile device <b>402</b> can include a processing device <b>1004</b>, such as a digital signal processor (DSP) or microprocessor, memory/storage <b>1006</b> in the form a non-transitory computer-readable medium, an image capture device <b>1008</b>, a touch-sensitive display <b>1010</b>, a power source <b>1012</b>, a radio frequency transceiver <b>1014</b> and a reader <b>1030</b>. Some embodiments of the mobile device <b>402</b> can also include other common components commonly, such as sensors <b>1016</b>, subscriber identity module (SIM) card <b>1018</b>, audio input/output components <b>1020</b> and <b>1022</b> (including e.g., one or more microphones and one or more speakers), and power management circuitry <b>1024</b>. The sensors <b>1016</b> can include a location-based sensor <b>1034</b>, configured to determine the location of the mobile device <b>402</b>.

The memory <b>1006</b> can include any suitable, non-transitory computer-readable storage medium, e.g., read-only memory (ROM), erasable programmable ROM (EPROM), electrically-erasable programmable ROM (EEPROM), flash memory, and the like. In exemplary embodiments, an operating system <b>1026</b> and applications <b>1028</b> can be embodied as computer-readable/executable program code stored on the non-transitory computer-readable memory <b>1006</b> and implemented using any suitable, high or low level computing language and/or platform, such as, e.g., Java, C, C++, C#, assembly code, machine readable language, and the like. In some embodiments, the applications <b>1028</b> can include a facility application configured to interact with the microphone, a web browser application, a mobile application specifically coded to interface with one or more servers of embodiments of the system for data transfer in a distributed environment. One or more servers are described in further detail with respect to <figref idref="DRAWINGS">FIG. 3</figref>. While memory is depicted as a single component those skilled in the art will recognize that the memory can be formed from multiple components and that separate non-volatile and volatile memory devices can be used.

The processing device <b>1004</b> can include any suitable single- or multiple-core microprocessor of any suitable architecture that is capable of implementing and/or facilitating an operation of the mobile device <b>402</b>. For example, a user can use the mobile device <b>402</b> in a facility to perform an image capture operation, capture a voice input of the user (e.g., via the microphone), transmit messages including a captured image and/or a voice input and receive messages from a central computing system, display data/information including GUIs of the user interface <b>1010</b>, captured images, voice input transcribed as text, and the like. The mobile device <b>402</b> can perform the aforementioned operations using on an internet browser executing on the mobile device, or any web-based application. The processing device <b>1004</b> can be programmed and/or configured to execute the operating system <b>1026</b> and applications <b>1028</b> to implement one or more processes and/or perform one or more operations. The processing device <b>1004</b> can retrieve information/data from and store information/data to the storage device <b>1006</b>.

The RF transceiver <b>1014</b> can be configured to transmit and/or receive wireless transmissions via an antenna <b>1015</b>. For example, the RF transceiver <b>1014</b> can be configured to transmit data/information, such as input based on user interaction with the mobile device <b>402</b>. The RF transceiver <b>1014</b> can be configured to transmit and/or receive data/information having at a specified frequency and/or according to a specified sequence and/or packet arrangement.

The touch-sensitive display <b>1010</b> can render user interfaces, such as graphical user interfaces to a user and in some embodiments can provide a mechanism that allows the user to interact with the GUIs. For example, a user may interact with the mobile device <b>402</b> through touch-sensitive display <b>1010</b>, which may be implemented as a liquid crystal touch-screen (or haptic) display, a light emitting diode touch-screen display, and/or any other suitable display device, which may display one or more user interfaces (e.g., GUIs) that may be provided in accordance with exemplary embodiments.

The power source <b>1012</b> can be implemented as a battery or capacitive elements configured to store an electric charge and power the mobile device <b>402</b>. In exemplary embodiments, the power source <b>1012</b> can be a rechargeable power source, such as a battery or one or more capacitive elements configured to be recharged via a connection to an external power supply. The scanner <b>1030</b> can be implemented as an optical reader configured to scan and decode machine-readable elements disposed on objects.

In one embodiment, the mobile device can execute an object delivery application (e.g., object delivery application <b>332</b> as shown in <figref idref="DRAWINGS">FIG. 3</figref>). The object delivery application <b>1032</b> can be an executable configured to track the location and/or supply chain process of physical objects of the mobile device <b>402</b>. The object delivery application can store and access the status of a delivery of physical objects. The central computing system can interface with the object delivery application.

<figref idref="DRAWINGS">FIG. 11</figref> is a block diagram of an example computing device for implementing exemplary embodiments of the present disclosure. The computing device <b>1100</b> may be, but is not limited to, a smartphone, laptop, tablet, desktop computer, server or network appliance. The computing device <b>1100</b> can be embodied as part of the central computing system, third party computing system, or user device. The computing device <b>1100</b> includes one or more non-transitory computer-readable media for storing one or more computer-executable instructions or software for implementing exemplary embodiments. The non-transitory computer-readable media may include, but are not limited to, one or more types of hardware memory, non-transitory tangible media (for example, one or more magnetic storage disks, one or more optical disks, one or more flash drives, one or more solid state disks), and the like. For example, memory <b>1106</b> included in the computing device <b>1100</b> may store computer-readable and computer-executable instructions or software (e.g., applications <b>1130</b> such as the control engine <b>320</b>, object delivery application <b>332</b>, and contract application <b>333</b>) for implementing exemplary operations of the computing device <b>1100</b>. The computing device <b>1100</b> also includes configurable and/or programmable processor <b>1102</b> and associated core(s) <b>1104</b>, and optionally, one or more additional configurable and/or programmable processor(s) <b>1102</b>′ and associated core(s) <b>1104</b>′ (for example, in the case of computer systems having multiple processors/cores), for executing computer-readable and computer-executable instructions or software stored in the memory <b>1106</b> and other programs for implementing exemplary embodiments of the present disclosure. Processor <b>1102</b> and processor(s) <b>1102</b>′ may each be a single core processor or multiple core (<b>1104</b> and <b>1104</b>′) processor. Either or both of processor <b>1102</b> and processor(s) <b>1102</b>′ may be configured to execute one or more of the instructions described in connection with computing device <b>1100</b>.

Virtualization may be employed in the computing device <b>1100</b> so that infrastructure and resources in the computing device <b>1100</b> may be shared dynamically. A virtual machine <b>1112</b> may be provided to handle a process running on multiple processors so that the process appears to be using only one computing resource rather than multiple computing resources. Multiple virtual machines may also be used with one processor.

Memory <b>1106</b> may include a computer system memory or random access memory, such as DRAM, SRAM, EDO RAM, and the like. Memory <b>1106</b> may include other types of memory as well, or combinations thereof.

A user may interact with the computing device <b>1100</b> through a visual display device <b>1114</b>, such as a computer monitor, which may display one or more graphical user interfaces <b>1116</b>, multi touch interface <b>1120</b>, a pointing device <b>1118</b>, an image capturing device <b>1134</b> and a scanner <b>1132</b>.

The computing device <b>1100</b> may also include one or more computer storage devices <b>1126</b>, such as a hard-drive, CD-ROM, or other computer-readable media, for storing data and computer-readable instructions and/or software that implement exemplary embodiments of the present disclosure (e.g., applications). For example, exemplary storage device <b>1126</b> can include one or more databases <b>1128</b> for storing information regarding delivery of physical objects. The databases <b>1128</b> may be updated manually or automatically at any suitable time to add, delete, and/or update one or more data items in the databases.

The computing device <b>1100</b> can include a network interface <b>1108</b> configured to interface via one or more network devices <b>1124</b> with one or more networks, for example, Local Area Network (LAN), Wide Area Network (WAN) or the Internet through a variety of connections including, but not limited to, standard telephone lines, LAN or WAN links (for example, 802.11, T1, T3, 56 kb, X.25), broadband connections (for example, ISDN, Frame Relay, ATM), wireless connections, controller area network (CAN), or some combination of any or all of the above. In exemplary embodiments, the computing system can include one or more antennas <b>1122</b> to facilitate wireless communication (e.g., via the network interface) between the computing device <b>1100</b> and a network and/or between the computing device <b>1100</b> and other computing devices. The network interface <b>1108</b> may include a built-in network adapter, network interface card, PCMCIA network card, card bus network adapter, wireless network adapter, USB network adapter, modem or any other device suitable for interfacing the computing device <b>1100</b> to any type of network capable of communication and performing the operations described herein.

The computing device <b>1100</b> may run any operating system <b>1110</b>, such as versions of the Microsoft® Windows® operating systems, different releases of the Unix and Linux operating systems, versions of the MacOS® for Macintosh computers, embedded operating systems, real-time operating systems, open source operating systems, proprietary operating systems, or any other operating system capable of running on the computing device <b>1100</b> and performing the operations described herein. In exemplary embodiments, the operating system <b>1110</b> may be run in native mode or emulated mode. In an exemplary embodiment, the operating system <b>1110</b> may be run on one or more cloud machine instances.

<figref idref="DRAWINGS">FIG. 12</figref> is a flowchart illustrating the process of the supply chain forecasting system using blockchain controls. In operation <b>1200</b> a first application executed on a central computing system including a database can generate a cryptographically verifiable ledger represented by a sequence of data blocks, each data block containing one or more transaction records and each subsequent data block containing a hash value associated with a previous data block. In operation <b>1202</b>, the first application can generate a first block in the cryptographically verifiable ledger including information associated with a request for one or more physical objects. The first block includes identification information associated with the physical objects, a destination location, and one or more constraints associated with the request for delivery of the one or more physical objects. In operation <b>1204</b>, the central computing system communicates with one of one or more third party computing systems that execute an instance of the first application and includes a hyperspectral image sensor. At least one of the third party computing systems is configured to store a copy of a full or partial version of the cryptographically verifiable ledger and detect the generation of the first block including the request for the one or more physical objects. The third party computing system is further configured to generate a second block in the cryptographically verifiable ledger, the second block including an acceptance of the request for delivery of the physical objects. The third party computing system is also configured to instruct the hyperspectral image sensor to capture an image of the one or more physical objects prior to initiating delivery of the one or more physical objects, and generate, via the first application, a third block including the image of the one or more physical object captured by the hyperspectral image sensor.

In step <b>1206</b>, the central computing system detects, via the first application, the generation of the second and third block in the cryptographically verifiable ledger. In step <b>1208</b> the first application when executed by the central computing system executes a hyperspectral image analysis on the image of the one or more physical objects and in step <b>1210</b> extracts one or more characteristics associated with the one or more physical objects based on the hyperspectral image analysis. In step <b>1212</b> the first application derives a quality value associated with the one or more physical objects based on the one or more characteristics; and in step <b>1214</b> generates a fourth block in the cryptographically verifiable ledger, the fourth block including the quality value associated with the one or more physical objects.

<figref idref="DRAWINGS">FIG. 13</figref> is a flowchart illustrating the process of the supply chain forecasting system using blockchain controls. In operation <b>1302</b>, the central computing system can generate a cryptographically verifiable ledger represented by a sequence of data blocks, each data block containing one or more transaction records and each subsequent data block containing a hash value associated with a previous data block. In operation <b>1304</b>, the first application of the central computing system can generate a first block in the cryptographically verifiable ledger including information associated with a request for one or more physical objects. The first block includes identification information associated with the physical objects, a destination location, and one or more constraints associated with the request for delivery of the one or more physical objects. In operation <b>1306</b>, the central computing system communicates with one or more third party computing systems that execute an instance of the first application. At least one third party system can store a copy of a full or partial version of the cryptographically verifiable ledger, detect the generation of the first block including the request for the one or more physical objects, and generate a second block in the cryptographically verifiable ledger. The second block includes an acceptance of the request for delivery of the physical objects.

In operation <b>1306</b>, the central computing system can query the database to retrieve information associated with the delivery of the physical objects. In operation <b>1308</b>, the central computing system can determine the status of the delivery of the one or more physical objects. In operation <b>1310</b>, the central computing system can forecast a failure of fulfillment of at least one of the constraints. In operation <b>1312</b>, the central computing system can generate a third block in the cryptographically verifiable ledger, the third block including the information associated with an action associated with the smart contract, in response to the forecast of the failure of fulfillment of the at least one of the constraints.

In describing exemplary embodiments, specific terminology is used for the sake of clarity. For purposes of description, each specific term is intended to at least include all technical and functional equivalents that operate in a similar manner to accomplish a similar purpose. Additionally, in some instances where a particular exemplary embodiment includes a multiple system elements, device components or method steps, those elements, components or steps may be replaced with a single element, component or step. Likewise, a single element, component or step may be replaced with multiple elements, components or steps that serve the same purpose. Moreover, while exemplary embodiments have been shown and described with references to particular embodiments thereof, those of ordinary skill in the art will understand that various substitutions and alterations in form and detail may be made therein without departing from the scope of the present disclosure. Further still, other aspects, functions and advantages are also within the scope of the present disclosure.

One or more of the exemplary embodiments, include one or more localized Internet of Things (IoT) devices and controllers. As a result, in an exemplary embodiment, the localized IoT devices and controllers can perform most, if not all, of the computational load and associated monitoring and then later asynchronous uploading of summary data can be performed by a designated one of the IoT devices to a remote server. In this manner, the computational effort of the overall system may be reduced significantly. For example, whenever a localized monitoring allows remote transmission, secondary utilization of controllers keeps securing data for other IoT devices and permits periodic asynchronous uploading of the summary data to the remote server. In addition, in an exemplary embodiment, the periodic asynchronous uploading of summary data may include a key kernel index summary of the data as created under nominal conditions. In an exemplary embodiment, the kernel encodes relatively recently acquired intermittent data (“KRI”). As a result, in an exemplary embodiment, KRI is a continuously utilized near term source of data, but KRI may be discarded depending upon the degree to which such KRI has any value based on local processing and evaluation of such KM. In an exemplary embodiment, KRI may not even be utilized in any form if it is determined that KM is transient and may be considered as signal noise. Furthermore, in an exemplary embodiment, the kernel rejects generic data (“KRG”) by filtering incoming raw data using a stochastic filter that provides a predictive model of one or more future states of the system and can thereby filter out data that is not consistent with the modeled future states which may, for example, reflect generic background data. In an exemplary embodiment, KRG incrementally sequences all future undefined cached kernels of data in order to filter out data that may reflect generic background data. In an exemplary embodiment, KRG incrementally sequences all future undefined cached kernels having encoded asynchronous data in order to filter out data that may reflect generic background data.

Exemplary flowcharts are provided herein for illustrative purposes and are non-limiting examples of methods. One of ordinary skill in the art will recognize that exemplary methods may include more or fewer steps than those illustrated in the exemplary flowcharts, and that the steps in the exemplary flowcharts may be performed in a different order than the order shown in the illustrative flowcharts.