US20200311666A1

US20200311666A1 - Encoding sensor data and responses in a distributed ledger

Info

Publication number: US20200311666A1
Application number: US16/455,170
Authority: US
Inventors: Douglas Bradley GRAY; Constanza Maria Heath; Gail Anna Rahn Frederick; Venkata Siva Vijayendra Bhamidipati; Michael Chan; Derek Chamorro
Original assignee: eBay Inc
Current assignee: eBay Inc
Priority date: 2019-03-28
Filing date: 2019-06-27
Publication date: 2020-10-01
Also published as: US20200311665A1; US11449819B2; CN113632436A; CN113678476A; US11468390B2; US11842317B2; US11379785B2; US20200313897A1; EP3949312B8; US20200311676A1; EP4307614A2; US20200311675A1; US11651321B2; EP3949312B1; US11748687B2; CN113632434A; EP3949313A1; EP3949450A1; EP3949312A1; US20220351125A1

Abstract

Delivery routing for an item is dynamically changed based on environmental conditions the item experiences during transport. The item may be associated with thresholds describing environmental conditions which must be maintained to avoid damage to the item. If sensors associated with the item detect deviation from the set thresholds during transport, instructions to reroute the item may be dynamically generated and provided to a vehicle or shipping agent responsible for transporting the item. Options for rerouting the item include returning it to the sender, disposing of it in a nearby disposal facility, sending to an inspection facility, or sending it on to the original destination location. The environmental thresholds associated with an item, records of conditions measured by sensors during transport, and alternative delivery locations may be stored in a distributed ledger such as a blockchain. Entities associated with the shipment may have access to the distributed ledger.

Description

PRIORITY APPLICATION

This application claims the benefit of and priority to U.S. Provisional Application No. 62/825,710, filed Mar. 28, 2019, the entire contents of which are incorporated herein by reference.

BACKGROUND

Physical items can be damaged in various ways during shipping. For example, exposure to extremes of temperature, vibration, humidity, and other conditions can damage both containers and items within those containers. Some types of items, such as medicine and frozen food, may be rendered worthless if they become too warm. Other types of items such as live insects, like crickets or ladybugs, may be killed if the temperature becomes too low. Sensitive electronics may be damaged by vibration. High humidity may be damaging for some types of items like paper products, cigars, and dried powders. Low humidity may damage other types of items such as fruit and vegetables.
Many shipping services provide tracking information that identifies a delivery date and may show the location of an item during transport. For example, a shipping agent may pack a global positioning system (GPS) sensor along with the item and utilize the GPS sensor to monitor locations of the item during shipment. Containers may be labeled with identifiers such as barcodes that are read by handheld readers, and the records of these read events can be used to create a record of the movements of the package. However, this type of tracking is generally limited to ensuring that an item reaches its intended destination location.
Tracking the location of an item may fail to capture important events such as damage to the item during transport. Even sophisticated persons with significant experience within the shipping industry may not immediately recognize that an item has been damaged during transport—especially because shipping personnel frequently have little or no insight as to what types of items they are currently transporting. Knowing what happened to an item during shipping may be equally or more relevant than knowing where an item is during its journey. Without knowing what has happened to an item during transport, resources such as fuel may be wasted transporting an item to a destination that is inappropriate given the current condition of the item.
Tracking information, including any records of potential damage, is typically created and controlled by the shipping agent. Access by other parties to this information may be limited and it may be difficult or impossible to independently verify the accuracy of records created by the shipping agent. Disseminating records describing events that happened to items during shipment in a way that is efficient and trusted by multiple parties is difficult.
It is with respect to these and other considerations that the following disclosure is made.

SUMMARY

This disclosure provides technologies for encoding environmental sensor data and pre-determined responses to deviations from environmental conditions in a block chain or other type of distributed ledger. The sensors monitor conditions experienced by items such as heat, humidity, vibration, etc. that may damage or destroy items during shipment. Implementing the thresholds for environmental conditions, records of measurement data collected by sensors during transport, and storing alternative destination locations in a blockchain provides enhanced safety, security, and transparency. For example, by knowing the history of temperature, it is known if a medicine or food has been safely stored. By knowing electronics have been shipped under safe conditions, it is known that the quality and functionality of the electronics should be assured. By knowing a secure history of locations an item has traversed, the security of the item can be verified. The disclosed technologies can also provide additional technical benefits such as improving logistical efficiency, reducing fuel usage, and saving wear-and-tear on vehicles.
Data captured from the sensors may be recorded in a distributed ledger. A distributed ledger (also called a shared ledger or distributed ledger technology or DLT) is a consensus of replicated, shared, and synchronized digital data geographically spread across multiple sites and devices. One example of a distributed ledger is a blockchain system. Blockchain uses cryptography to link the data in each block to the previous block thereby creating a “chain.” Data in one block cannot be altered without severing the link to other blocks in the chain. It is trusted as a single source of truth by participants because the data is both immutable and cryptographically secure. With trust and transparency, the incorporation of blockchain into a system can simplify dispute resolution and ensure that all parties to agree in advance on actions to perform in response to data captured from the sensors.
By identifying potential damage to an item during transport rather than after delivery, the item may be rerouted to a different, potentially closer, destination. This is more efficient than continuing to transport a damaged item to a destination where the item will be undesired or unusable. Technical benefits other than those specifically identified herein might also be realized through implementations of the disclosed technologies.
Information regarding the acceptable environmental conditions for a given item as well as the actual measurements of environmental conditions recorded during transport may be recorded in data blocks of a blockchain. This provides an immutable record that may be accessed by a sender, a receiver, a shipping agent, or other parties associated with the transport of an item.
Storing this record on a distributed ledger such as a blockchain allows many different entities to access the data and provides a reliable record that may be used to assign responsibility for damage that occurs to items during shipping. Additionally, creating a distributed ledger provides data redundancy in case one source of records (e.g., a data stored locally on a memory device in a vehicle) is irretrievably damaged. Data from the record stored in the blockchain may be aggregated for individual shipping agents to generate performance metrics for the shipping agents based on the quality of shipping provided. The performance metrics themselves may also be stored in the blockchain to provide widespread access and the technical benefits of cryptographic security and immutability.
The sensors, which are included in a vehicle, in a container, and/or on the item being shipped, track one or more environmental conditions and provide a rich set of data that describes the quality of shipping. The quality of shipping includes not only the location of the item and timeliness of the delivery but also environmental conditions that the item was exposed to during shipping.
The sensors may provide sensing capabilities, electronics, memory, processing, software, and network connectivity to items other than standard computing devices. For example, the sensors may be included in a vehicle, in packaging material, in a container holding the item, or attached to the item itself. The sensors may have the ability to communicate over a communications network so that they can provide sensed data to a remote computing system for storage and analysis.
The sensors may capture any number of different types of environmental conditions that are relevant to an item being shipped. For example, location sensors (e.g., GPS), thermometers, vibration sensors, hygrometers, orientation sensors, and the like may be used to observe and record the location and environmental conditions experienced by an item during transport. Automatic data collection of signals sent from the sensors can prevent missed scans or measurements that may occur if human action is required to generate the data.
Sensor data may be compared to thresholds that define acceptable conditions for an item in order to determine if the item was potentially damaged during shipping. These thresholds may be obtained from the profile data of an item. The threshold for an environmental condition may be associated with a single threshold (e.g. do not go above or do not go below) or there may be two thresholds that represent a range with an upper and lower limit on acceptable values.
If an item was exposed to environmental conditions that deviated from acceptable thresholds, the destination location for the item may be modified during shipment. Thus, the recipient is saved the disappointment of receiving an item only to open it and learn that it has been damaged. The shipping agent is also saved with the expense and effort of transporting item to a location where it cannot be used. For example, a truck full of produce that has overheated may be redirected to a nearby composting facility rather than continuing to drive hundreds of miles to deliver unusable goods. The truck is then available to transport different items. If a replacement item is to be sent out, the replacement item can be sent out as soon as the damage is detected rather than waiting for the recipient to detect and report the damage.
A damaged item may be returned to the sender or routed to a different location. The item may be inspected to determine if it was in fact damaged. If it is not damaged, then the item may be transported to its original destination. If the item is determined to be damaged either based on the sensor data or based on the later inspection, a replacement item may be shipped out.
For example, a vaccine may need to be stored at a temperature below 3° C. in order to maintain efficacy. If a sensor detects that the package contained the vaccine has warmed to 6° C., exceeding the threshold, then the vaccine is no longer usable. The destination location for the vaccine may be changed to the original shipping agent's address so that is returned, or it may be changed to another location where there are suitable disposal facilities. Additionally, a new shipment of the vaccine may be sent out to the same destination as a replacement for the shipment that was damaged.
It should be appreciated that the above-described subject matter may also be implemented as a computer-controlled apparatus, a computer-implemented process, a computing system, or as an article of manufacture such as a computer-readable medium. These and various other features will be apparent from a reading of the following Detailed Description and a review of the associated drawings.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended that this Summary be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

The Detailed Description is described with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same reference numbers in different figures indicate similar or identical items.

FIG. 1 is a computing system diagram showing an illustrative system for dynamically changing the routing of an item during transport based on sensed environmental conditions.

FIG. 2 is an architectural diagram showing additional details and providing examples of communication between the computing devices shown in FIG. 1.

FIG. 3 is an architectural diagram showing an illustrative example of a blockchain for maintaining a record of environmental measurement data.

FIG. 4 is a data architecture diagram illustrating example data blocks in a blockchain ledger that maintains a record of environmental measurement data.

FIG. 5A is a flowchart of an illustrative method for returning a shipped item back to an origination location after exposure to unfavorable environmental conditions.

FIG. 5B is a flowchart of an illustrative method for shipping a replacement item after the original item was exposed to unfavorable environmental conditions.

FIG. 5C is a flowchart of an illustrative method for determining a performance metric for a shipping agent based on aggregated performance data.

FIG. 5D is a flowchart of an illustrative method for storing measurement data of environmental conditions in a blockchain and modifying delivery of an item based on the measurement data.

FIG. 5E is a flowchart of an illustrative method for redirecting a shipped item to a disposal facility after exposure to unfavorable environmental conditions.

FIG. 5F is a flowchart of an illustrative method for redirecting a shipped item to an inspection facility after exposure to unfavorable environmental conditions.

FIG. 6 is a data architecture diagram showing an illustrative example of a user using an application programming interface to invoke a method in a data block on the environmental measurement blockchain.

FIG. 7A is a data architecture diagram illustrating a simplified example of a blockchain ledger based on the data blocks of the environmental measurement data blockchain of FIG. 3.

FIG. 7B is a data architecture diagram showing an illustrative example of smart contract code, transactions, and messages that are bundled into a block so that their integrity is cryptographically secure and so that they may be appended to a blockchain ledger.

FIG. 8 is a computer architecture diagram illustrating an illustrative computer hardware and software architecture for a computing system capable of implementing aspects of the techniques and technologies presented herein.

FIG. 9 is a diagram illustrating a distributed computing environment capable of implementing aspects of the techniques and technologies presented herein.

FIG. 10 is a computer architecture diagram illustrating a computing device architecture for a computing device capable of implementing aspects of the techniques and technologies presented herein.

DETAILED DESCRIPTION

As discussed briefly above, the disclosure presented herein describes technologies for encoding sensor data and responses to deviations from set thresholds in a distributed ledger. In order to provide this functionality, shipped items may be associated with a particular set of thresholds for environmental conditions, and these thresholds are recorded in a distributed ledger such as a block chain. Records of data collected from the sensors may also be recorded in the same distributed ledger.
Smart contracts implemented in the distributed ledger can generate instructions to change a parameter based on sensor data. As just one example, a delivery destination for an item based on the sensor data and the thresholds for that item. Implementations of the disclosed technologies provide the benefits of system that uses cryptographically secure and verifiable data source together with pre-established and known rules to efficiently adjust delivery routing for damaged items. Additional details regarding the various aspects of these and other features of this disclosure are provided below with respect to the accompanying figures.
FIG. 1 shows the architecture of an illustrative system 100 for changing delivery routes based on the condition of an item 102. In the system 100, the item 102 is an item in transport, which may be any type of good or product. For example, the item 102 may be frozen goods, refrigerated goods, medicine, food, live animals, electronics, antiques, etc. The item 102 may be sensitive to one or more environmental conditions such as pressure (e.g., being stacked under heavy items and/or subjected to unacceptable barometric pressure), acceleration (e.g., being shaken and/or dropped), humidity, temperature, light exposure (e.g., exposure to ultra-violet light), chemical exposure (e.g., exposure to oxygen and/or some other non-inert gas), and so on.
During shipping, the item 102 may be placed or packed inside a container 104. As used herein, “container” refers to an object that can be used to enclose or hold the item 102 such as a box, a package, an envelope, a packet, a mailing tube, bag, a can, a jar, a vial, a bucket, a crate, a cage, a palate, a shipping container, etc.
To monitor environmental conditions during shipping, one or more item sensor(s) 106A may be placed in proximity to the item 102. The item sensor 106A may be placed on the item 102 itself, inside the container 104 with the item 102, or attached to the container 104.
Item 102 is transported by vehicle 108 that may include onboard sensor(s) 106B, which also measure environmental conditions. The onboard sensor(s) 106B may be sensors located inside a cargo compartment of the vehicle 108 in which the container 104 holding the item 102 is transported.
“Vehicle” includes any means of conveyance capable of transporting an item 102 or container 104. For example, a vehicle may be a train, a truck, a car, a motorcycle, a bicycle, an airplane, a helicopter, a drone, a boat, a ship, etc. As used herein, vehicle also includes any onboard computing devices, navigation systems, and the like used to receive data from the item sensor(s) 106A and/or the onboard sensor(s) 106B (collectively sensor(s) 106) to guide or control operation of the vehicle 108. The vehicle 108 may additionally include a location sensor 110 such as, for example, a GPS sensor that detects the location of the vehicle 108 and, thus, the location of the item 102 being transported within.
The vehicle 108 is operated by a shipping agent. A “shipping agent” as used herein refers to an entity that is responsible for transporting the item 102 from its origination location 116 to its destination location 118. The shipping agent may be an individual or a business entity. For example, the shipping agent may be a commercial shipping service such as UPS, FedEx, DHL, a government shipping service such as the United States Postal Service, etc. As a further example, a shipping agent may be an individual working as a contracted service provider such as for Amazon Flex or Uber Freight. The shipping agent may be a human driver of the vehicle 108 or a different person or entity. The vehicle 108 may be implemented as a driverless vehicle, drone, or the like without a human driver.
The sensor(s) 106 may include, without limitation, thermocouples, thermometers, barometers, hygrometers, strain gauges, micro switches, fuses, photovoltaic cells, mercury levels, thermal sensors, microphones, seals, audiometers, electromagnetic monitors, chromatographers, etc. The sensor(s) 106 may measure one or more types of environmental conditions such as, but not limited to, temperature, barometric pressure, vacuum, humidity, orientation, pressure on the packaging, vibration, light, presence or absence of a chemical, ultraviolet radiation exposure, ionizing radiation exposure, atmospheric gas levels (e.g., oxygen, carbon dioxide, ozone), etc.
The sensors 106 may have the ability to provide measurement data to a network 112. Connection between the sensors 106 and the network 112 may be accomplished utilizing a variety of wired and wireless means, such as, for example and without limitation, direct connections by well-known electro-optical means, or indirect connections via radio frequency, microwaves, internet, acoustic coupling, laser, thermal, infrared, and other means well known to a person skilled in the art. The network 112 may be any type of communication networks such as the Internet, a wide area network, an ad hoc network, a peer-to-peer network, a cellular phone network, or the like.
Each of the sensors 106 may have its own sensing capabilities, electronics, memory, processor(s), software and/or firmware, and an antenna to provide network connectivity. Each sensor 106 may provide data continuously or intermittently. If equipped, the sensors 106 may use their memory to store or capture data for intermittent transmission. The sensors 106 may or may not be able to receive data from the network 112. Each sensor 106 may be associated with its own sensor identifier (ID). Measurement data provided by the sensors 106 may include metadata such as the sensor ID, a timestamp, and location obtained from the sensor 106 itself or the location sensor 110 on the vehicle 108.
In an implementation, one or more of the sensor(s) 106 may be a radio-frequency identification (RFID) sensor. An RFID sensor is an automated data collection device having an integrated environmental sensor. As is known in the art, RFID sensor technology provides for wireless, automated data collection without the need for a direct line of sight between a data reader and the RFID tag. This allows the RFID sensor to be placed anywhere on or in the item 102 or the container 104. In other words, an RFID sensor can be placed inside the container 104, it can be affixed to an outer surface of the container 104, or it can be positioned directly on the item 102 that is inside the container 104. The vehicle 108 may contain one or more RFID tag readers that can interrogate the RFID sensors and obtain measurement data to send to the network 112 using network connectivity provided by the vehicle 108.
If the sensors 106 are unable to access the network 112 to upload data, the data may be stored in the memory of the sensors 106 and uploaded when a network connection is reestablished. In an implementation, the measurement data may be captured intermittently (e.g., every five minutes) and uploaded intermittently at a less frequent interval (e.g., every hour). For example, an onboard sensor 106B connected to a power supply of the vehicle 108 may be used to send a temperature reading every minute to track the temperature of the item 102 during shipment in near real-time. A lower frequency of data capture and data transmission reduces energy consumption and can improve battery life for a battery-powered sensor such as, for example, an item sensor 106A.
Measurement data from the sensor 106 may be provided to a remote computing system 114 via the network 112. The remote computing system 114 may be implemented as any type of computing system such as, for example, a server, a server cluster, a cloud-based or distributed computing system, or the like. The remote computing system 114 may be operated or controlled by a sender of the item 102, a recipient of the item 102, a shipping agent, an insurer, or other entity. The remote computing system 114 may compare measurement data received from the sensors 106 with thresholds for the item 102 to determine if the environmental conditions deviate from acceptable thresholds. If so, the remote computing system 114 may provide shipping instructions that alter the delivery route and/or destination for the item 102.
The ability to modify shipping instruction en route based on sensor data collected from within the vehicle 108 allows for real-time or near real-time adaptation based on the environmental conditions encountered by the item 102. Real-time change to a delivery destination for an individual container 104 using sensors 106 and a remote computer system 114 without direct human intervention enables more efficient use of transportation resources such as the vehicle 108, fuel, and the like. This also allows for more efficient use of warehouse and other storage facilities because, for example, rather than storing a damaged item as part of a shipping process it may be disposed of making storage space available for other items that are not damaged.
In the system 100, transport of the item 102 begins at an origination location 116. The origination location 116 is the location that the item 102 shipped from. This may be the location at which the item 102 was created (e.g., a factory) or packaged (e.g., a warehouse) or where the item 102 entered the shipping stream. Alternatively, the origination location 116 may be the start of a portion but not the entire shipping route for the item 102. For example, the origination location 116 may be a port but the item 102 may have previously been transported from a factory on another continent to the port.
Transportation of the item 102 begins with a destination location 118 where the item 102 is intended is to be transported or delivered. The destination location 118 may be the final destination such as the residential address of a purchaser or end user. Alternatively, the destination location 118 may be the destination for only a portion of the route along which the item 102 is transported. For example, the destination location 118 may be a warehouse at a distribution hub even though the item 102 will be later shipped out from that warehouse. Although the item 102 is shipped out with the intent of delivery to the destination location 118, the location to which the item 102 is delivered may be changed to an alternate destination based on actual or suspected damage that occurs to the item 102 during transport.
In one implementation, the item 102 may be returned to the original location 116 if exposed to one or more environmental conditions that are outside the established thresholds for item 102. At the original location 116, the item 102 may be inspected and processed according to the type of damage, if any. For example, item 102 may be disposed of, it may be repackaged in a new container 104, it may be repaired, refurbished, or rebuilt.
In one implementation, item 102 may be sent to inspection facility 120 for inspection to determine the type and extent of damage. The item 102 may be dynamically routed to the nearest inspection facility 120, which may save time and transport expenses as compared to returning the item 102 to the origination location 116.
At the inspection facility 120, item 102 may be inspected to determine if the item 102 and/or the container 104 are in fact damage and any remediation necessary to address the damage. If the item 102 is not damaged, it may be forwarded on to the destination location 118. If, however, item 102 is damaged, it may be returned to the origination location 116 or, if unsuitable for repair or refurbishment, sent to a disposal facility 122 for recycling or disposal.
In one implementation, the item 102 may be sent directly to a nearby disposal facility 122 if it is determined that the item was exposed to environmental conditions outside of established thresholds. For example, perishable items such as frozen food may be unusable if exposed to high temperatures for prolonged periods of time. Thus, there may be no point in inspecting the item 102 and the decision to dispose of the item 102 may be made based on the sensor data alone.
The nearest disposal facility 122 may be identified in real time when the measurement data from the sensors 106 deviates from an established threshold. Using the nearest disposal facility 122 may reduce transportation costs and time. The disposal facility 122 may also be selected based on the type of item 102 and the appropriate way to dispose of that item 102. For example, food that must be disposed of may be sent to a composting facility while broken electronics may be sent to a disposal facility 122 that processes e-waste.
In any of the rerouting embodiments described herein, the item 102 may be removed from the vehicle 108 and placed on a different vehicle. Identifiers of the item 102 such as an RFID tag and/or labels placed on the item 102 or container 104 may be used to route the item 102 to the new destination. The new destination may be the origination location 116, an inspection facility 120, or a disposal facility 122.
If the item 102 is damaged or presumed damaged during transport because it was exposed to environmental conditions that deviated from the established thresholds for the item 102, a replacement item 124 may be sent out from the original location 116 (or other location such as an alternate warehouse). The replacement item 124 may be the same or similar to the original item 102 that was damaged. For example, the replacement item 124 may be the same model of item or the same type and weight of item. By shipping the replacement item 124 to the destinate location 118 shortly after damage is detected to the original item 102, the replacement item 124 will arrive sooner than if it was not shipped until the recipient discovered the damage and filed a claim.
FIG. 2 shows an illustrative architectural 200 of computing devices that may be present in the system 100 of FIG. 1. The vehicle 108 may include one or more onboard computing device(s) 202. The onboard computing device(s) 202 on the vehicle 108 may be implemented as built-in computing systems integrated into the vehicle 108 electronic systems. Alternatively, one or more of the on onboard computing device(s) 202 may be portable or mobile devices such as a GPS unit, a smartphone, a laptop computer, etc. that are not permanently coupled to the vehicle 108. The onboard computing device(s) 202 may include multiple different functionalities related to operation of the vehicle 108, communications, entertainment, and the like.
A navigation module 204 may be present in one or more of the onboard computing device(s) 202. The navigation module 204 may provide directions or navigation assistance to an operator of the vehicle 108. For some types of vehicles 108, the navigation module 204 may be responsible for operation and controlling movement of the vehicle 108. The navigation module 204 may receive shipping instructions 208 or directions from the remote computing system 114 indicating the destination location 118 for the item 102.
The onboard computing device(s) 202 may also include a tag reader 206 for reading an RFID, barcode, QR code, or other type of tag attached to the item 102 or the container 104. The tag reader 206 may be used to identify the item 102 so that the onboard computing device(s) 202 can communicate presence of the item 102 to the remote computing system 114. The tag reader 206 may also be used to query the sensors 106 (e.g., RFID sensors) and obtain measurement data 210.
The onboard computing device(s) 202 may in some implementations include a blockchain module 211 for maintaining records of measurement data 210 that is received from the sensors 106 that monitor the environmental conditions surrounding the item 102. For example, instances of the measurement data 210 that correspond to sensor measurements which deviate from defined threshold levels may be recorded in a plurality of distributed ledgers of a blockchain 222. The blockchain module 211 may be implemented as a program module running on the onboard computing device 202 and/or as interconnected machine logic circuits or circuit modules within the onboard computing device 202.
The remote computing system 114 may be communicating continuously or intermittently with the onboard computing device(s) 202 via the network 112 during transport of the item 102. The remote computing system 114 may provide a delivery routing service 212 that analyzes measurement data 210 provided from the sensors 106 in conjunction with the profile data 214 for the item 102 to determine if there has been a deviation from one or more threshold value(s) 216 predetermined for the item 102. The delivery routing service 212 can be implemented as any number of different types of computing resources and/or other distributed computing functionality that can be configured to execute any aspects of the components contained within the delivery routing service 212.
Depending on the type and nature of deviation, the delivery routing service 212 may use a shipping instruction module 218 to generate the shipping instructions 208 which can then be sent to the vehicle 108. The shipping instructions 208 may, for example, instruct the navigation module 204 to route the vehicle 108 and/or the item 102 to an alternate destination location, such as the origination location 116, an inspection facility 120, or a disposal facility 122.
The profile data 214 contains data about the item 102 including data defining one or more threshold value(s) 216. “Profile data” as used herein indicates one or more environmental conditions (e.g., temperature, humidity, moisture, barometric pressure, pressure on the container, orientation, vibration, shock, light, ultraviolet radiation, ionizing radiation, or atmospheric gas level) and one or more threshold values which that environmental condition must not deviate from. Deviation from the environmental condition may be recognized by a measurement value exceeding the threshold value, a measurement value dropping below the threshold value, or a measurement value falling outside a range of threshold values.
The profile data 214 may also include a description of the item 102 and a unique identifier for the item. The threshold value(s) 216 may be based on combinations of multiple environmental conditions and on time. For example, a problem with shipping may only be identified if two or more sensors 106 report measurement data 210 that deviates from their respective thresholds.
For example, temperature and humidity may both be measured to determine a dew point when condensation on the surface of the item 102 is likely. Thus, a triggering event may be a combination of temperature and humidity that indicates water in the air has condensed because the dew point was reached. A triggering event may also be initiated if a sensor 106 detects a particular environmental condition deviating from a threshold for more than a specified amount of time. For example, a triggering event may be temperature exceeding 37° C. for more than 10 minutes.
The measurement data 210 indicating the measurement of the environmental condition may be compared to the corresponding threshold value 216 for the environmental condition. This comparison may occur many thousands of times during transport of the item 102. For example, the comparison may occur every time measurement data 210 is received from the sensor 106. Depending on the environmental conditions that the item 102 is exposed to during transport, it may be determined that the value of the measurement data 210 deviates from the threshold value 216. For example, a thermometer may detect a temperature higher than the maximum threshold temperature set for the item 102.
The profile data 214 may also define rules for each threshold value 216 and corresponding environmental condition. For example, a frozen item 102 having freeze/thaw behavior similar to water may have a “frozen” range (from −40° to −1° C.), a “thaw” range (from +0° to +5° C.), a “warm” range (from +6° to +15° C.), and a “hot” range (from 16° C. and over). Depending on its type (meat, produce, and dairy, etc.), different products may have profile data 214 with one or more ranges of threshold values 216. Thus, for example, if the item 102 is frozen meat, then when it is at −5° C. or below it is in the “frozen” range, and thus, it is considered in a satisfactory state and there is no triggering event.
If the measurement data 210 is within acceptable parameters, the sensor 106 may take measurement data 210 less frequently such as only once every hour. In case the meat reaches a temperature of 3° C., then it is considered in the “thawed” range, and thus, the temperature may be reported more frequently such as every 10 minutes. At that point, the delivery routing service 212 may issue an alert. In case that meat reaches a temperature of 25° C. for more than a predetermined length of time, then the delivery routing service 212 may identify the item 102 or disposal. Shipping instructions 208 generated by the shipping instruction module 218 may instruct that the meat be taken to the nearest disposal facility 122.
As further illustrated, the delivery routing service 212 includes a blockchain module 220. The blockchain module 220, like the blockchain module 211 on the vehicle 108, is configured to access data stored on a blockchain 222 as well as to add additional data blocks to the blockchain 222. The blockchain 222, as a distributed ledger, does not exist wholly within the blockchain module 211 or the blockchain module 220 but is potentially distributed across many different blockchain modules on many different computing devices. Each of the blockchain module 211 and the blockchain module 220 may maintain updated copies of the blockchain 222.
Blockchain 222 can be a publicly available blockchain that supports scripting, such as the ETHEREUM blockchain, which supports a SOLIDITY scripting language, or BITCOIN, which supports a scripting language called SCRIPT. Blockchain 222 can also each be a private blockchain, or a combination of public and private blockchains can be utilized.
When measurement data 210 from a sensor 106 is uploaded it may be recorded in the blockchain 222. A unique blockchain may be created for each item 102 that is shipped. Alternatively, there may be one or more existing blockchains that store measurement data 210 from multiple items. For example, one shipping provider may have its own blockchain for recording sensor and other shipment data for all packages that it handles. As an additional example, a given shipping agent such as a retailer or a manufacturer may use a blockchain 22 for all its outgoing shipments. Also, blockchains 222 may be vehicle specific. Measurement data 210 and other data for all the items 106 shipped on the same vehicle 108 may be recorded in the same blockchain 222.
Each set of uploaded measurement data 210 may be identified by a timestamp and a sensor ID to enable later correlation with the specific item 102 that is monitored by the sensor 106. By recording raw sensor data in a blockchain 222 it provides many different parties access to the data because of the distributed nature of the blockchain record. It also prevents intentional or accidental modification or deletion of data due to the immutability of records recorded in a blockchain 222.
In some embodiments, each of the individual blockchain modules 211, 220 may maintain a corresponding ledger. In this way, the multiple instances of the ledger are decentralized and distributed so as to provide various interested parties with their own record of the measurement data 210. In this way, the record of the measurement data 210 is highly resistant to tampering (e.g., malicious modifications) and will persist even if any individual one of the ledgers becomes corrupted or otherwise unusable (e.g., via a catastrophic failure of a storage medium).
It will be appreciated that recording the “raw” measurement data 210 in a distributed fashion across the multiple ledgers provides multiple different parties with access to the “raw” measurement data 210 while also preventing intentional or accidental modification or deletion of the measurement data 210. A reliable record of environmental conditions to which the item 102 has been subjected that is stored in a blockchain 222 can be used to determine the entity at fault in subjecting the item 102 to an environmental condition rendering it unfit for use during shipment.
In some embodiments, a unique blockchain 222 may be created for the item 102. Alternatively, there may be one or more existing blockchains 222 that are used to store measurement data 210 that is received in association with multiple different items 102. For example, one shipping agent may have defined its own blockchain 222 for recording measurement data 210 received from various sensors 106 and other shipment data for all packages that it handles.
As an additional example, a retailer or a manufacturer may use its own blockchain 222 for all its outgoing shipments. As yet an additional example, the blockchain 222 may be vehicle specific such that all measurement data 210 for all the items 102 being shipped on the vehicle 108 may be recorded in the same set of ledgers. In some embodiments, each instance of measurement data 210 that is uploaded and/or stored in the blockchain 222 may be identified by a timestamp and a sensor ID. This can enable later correlation with the specific item 102 that is being monitored by the corresponding sensors 106.
The blockchain 222 may be implemented as one type of a system database 224 that records the measurement data 210 uploaded by the various sensors 106. The system database 224 may be implemented using other technologies besides blockchain 222 such as other distributed ledger technology or another database technology. Any or all of the information and data that is available to the delivery routing service 212 may additionally or alternatively be stored in the system database 224. Thus, the system database 224 may be thought of as a part of the remote computing system 114.
Reports on the environmental condition of the item 102 may be generated during transport based on the measurement data 210 sent from the sensors 106. In an implementation, the measurement data 210 from the sensors 106 may be recorded in the blockchain 222 first and then a report generated from the blockchain 222. The reports may function as alerts that indicate when measurement data 210 deviates from one of the set threshold value(s) 216. For example, a report may be generated when an item 102 becomes too hot or too cold. Thus, the reports may provide indications when environmental conditions for the item 102 are unfavorable.
The reports may be provided as email messages, text messages, alerts on a website, or by any other communication technology. In an implementation, the reports may be provided to a driver or operator of a vehicle 108 currently transporting the item 102. The reports may be provided to the shipping agent, recipient, insurer or other party associated with the item 102.
The blockchain 222 or an alternate blockchain may be used to register one or more of the sensors 106. Registering the sensors 106 that provide the measurement data 210 as approved devices in a blockchain protects the equipment that ultimately determines the quality of shipping from tampering and can be used to implement standards for sensor quality and reliability. Allowing certificates for sensors 106 to be issued only by approved vendors is a way to protect the integrity of the sensors 106 by using the blockchain 222 to govern the entre lifecycle including attested patching and updates. With this protection it will be difficult or impossible to inject a sensor 106 or binary module without having it attested and approved to be on the blockchain 222. The entire sensor 106 will thus be protected hardware and software throughout its use. Examples of using blockchain to secure a device are described in U.S. patent application Ser. No. 16/384,362 filed on Apr. 15, 2019 and titled “Resource Trust Model for Securing Component State Data for A Resource Using Blockchains” which is incorporated herein by reference in its entirety.
The blockchain 222 may include one or more smart contract(s) 226. Thus, the blockchain 222 may store additional information beyond simply being a repository for measurement data 210. The threshold value(s) 216 may also be recorded in the blockchain 222 in association with a unique ID for the item 102. Thus, the threshold value(s) 216 against which measurement data 210 is compared may be stored in the same blockchain 222 that records the measurement data 210 itself.
The blockchain 222 may include code for implementing one or more smart contracts 226 related to various environmental conditions that are suitable for the item 102, destination locations 118 and other information related to shipping of the item 102. Computer code in a smart contract 226 may cause implementation of any number of actions based on specific triggering data. For example, sending out a report to a specified email or other electronic communication address when an environmental condition exceeds a threshold value 216 may be implemented with a smart contract. Communicating shipping instructions that change the destination location for an item 102 in response to measurement data deviating from a threshold value may also be represented by a smart contract.
Smart contracts 226 may also be used to change the destination location 118 for an item 102. The triggering event can be a sensor 106 reading that exceeds a defined threshold value 216 for the environmental condition sensed by that sensor 106. A destination location 118 stored in the blockchain may be changed to a different location. For example, if the item 102 is to be returned to the sender after potential damage during transport, the original destination location 118 may be replaced with the origination location 116 so that the item 102 is dynamically rerouted back to the sender.
This dynamic change to delivery routing may be performed automatically in that the triggering condition and the new destination location are encoded in the smart contract 226 prior to the start of shipment and the change is implemented during transport without direct human intervention. The change may be implemented by replacing the current destination location in a record within the system database 224 with a different location. Thus, the navigation module 204 may still look to the same record in the system database 224, but the value of that record may be changed to indicate a different address.
Smart contracts 226 may be used to initiate other responses to sensed environmental conditions that deviate from specified threshold values 216. For example, a replacement item 124 may be shipped out following a determination that measurement data 210 indicates damage to the original item. Shipping instructions 208 may cause a second item to be shipped from the origination location 116 to the destination location 118. In this implementation, the shipping instructions 208 may be sent to the origination location 116. The second item may be sent out as a replacement for the item 102 that was damaged during transport.
The replacement item 124 may be sent out before transport of the original item 102 was scheduled to be complete. Thus, the replacement item 124 will arrive at the destination location 118 sooner than if it was not shipped out until after delivery of the damaged, first item 102. The replacement item 124 may be identical to the first item 102 or it may be similar such as a newer model of the same product.
Similarly, for certain types of items, if the sensed environmental conditions go outside of a set parameter, a smart contract may reduce the price to be paid for the item 102. For example, there may be certain types of food products that are not spoiled by being stored at temperatures that are higher or lower than optimal, but the variation in temperature may reduce the quality or flavor, and thus the ultimate market price of the item 102. This could be encoded in a smart contract 226 by associating values for environmental conditions with one or more different pricing levels.
Smart contracts 226 may also be used to implement a full refund of the purchase price, if paid in advance, for the item 102 based on measurement data 210 showing environmental conditions outside of the threshold values 216. Smart contracts 226 may also be associated with location data such that the payment for an item 102 may be collected automatically upon delivery of the item 102 to the destination location 118 of the purchaser. Other implementations are also possible, such as collection of payment once the item 102 has been placed on board the vehicle 108.
The measurement data 210, as well as other data such as delivery timeliness collected from the transport of multiple individual items, may be aggregated. The aggregated data may include the measurement data 210 and the threshold values 216 associated with transportation of multiple different items. This aggregated data may be analyzed to multiple different ways such as, for example, by shipping agent. Thus, a shipping agent, such as a freight transporting company, may have aggregated performance data that can include metrics for timeliness and/or compliance with specified thresholds for environmental conditions. A performance metric calculator 228 in the delivery routing service 212 may analyze the aggregate data for each of a plurality of different shipping agents in order to calculate a performance metric 230 for each one.
The performance metrics 230 may be used to compare one shipping agent to another on the basis of not only the speed of delivery but also on the quality of delivery and compliance with shipping requirements represented by environmental condition thresholds. The evaluation of a shipping agent may be represented in terms of a percentage of shipments delivered on time, a percentage of shipments delivered without deviation from the specified requirements for environmental conditions, a percentage of shipments for which the measurement data 210 deviated from one or more threshold value(s) 216, and the like. The metrics for a shipping agent may be reduced or abstracted to a quality rating such as high, medium, low, or a star rating such as from 1 to 5 stars.
Analysis of the performance by various shipping agents may identify which environmental conditions are difficult for one or more of the shipping agents to satisfy. For example, a first shipping agent may have difficulty maintaining the temperature of its shipments, and so environmental conditions related to temperature may be reported as exceeding the threshold more often than other shipping agents. While a second shipping agent may have difficulty isolating shipped items from vibration, so thresholds related to shaking or vibration of the items may be more frequently exceeded by this shipping agent than others. A third shipping agent may have a good record for complying with specified environmental conditions, but timeliness may be poor. Thus, individual ratings for shipping agents may be determined based on the aggregate performance data and a performance metric 230 may identify which environmental conditions the shipping agent has more difficulty maintaining for its shipments as compared to other shipping agents.
FIG. 3 is an architectural diagram showing an illustrative example of a system architecture 300 wherein a blockchain platform 302 maintains an environmental measurement data blockchain 304. The environmental measurement data blockchain 304 stores measurement data 210 from sensors 106A-C and binds the record of measurement data 210 to a specific item 102. The environmental measurement data blockchain 304 may be the blockchain 222 and it may be accessed by any blockchain module 211, 220 via the network 112. In this example, remote computing system 114 stores measurement data 210 in data blocks 306A-E of environmental measurement data blockchain 304.
When new measurement data 210 is received from one or more sensors 106A-C, a new data block 306 can be created and linked to the environmental measurement data blockchain 304 to store the most current measurement data 210. A data block 306 may store data from multiple sensors 106A-C and may also store measurement data 210 for multiple environmental conditions (e.g., temperature, humidity, and vibration).
In this example, the remote computing system 114 is a trusted entity that controls the environmental measurement data blockchain 304. The remote computing system 114 can add data blocks 306 to blockchain 304 that contain measurement data 210. The data blocks 306 require the cryptographic signature of the remote computing system 114 to be validated and added to the blockchain 304.
The remote computing system 114, such as one or more servers, is controlled by a trusted entity that creates the blockchain 304. The blockchain 304 can be established and maintained, for example, when an item is shipped out from an origination location 116. Also, when a sender purchases shipping services it can provide the profile data 214 for the item 102, which the remote computing system 114 maintains and encodes in the blockchain 304.
In the example of FIG. 3, the remote computing system 114 initiates an environmental measurement data blockchain 304 by creating genesis block 306A when a shipping order for an item 102 is created. In other examples, the data blocks 306 can be added to an existing blockchain (e.g., a blockchain associated with a shipping agent or a vehicle 108) when an item 102 is newly placed into a shipping network. A data block 306 can include methods or function calls that are executed by blockchain platform 302 to obtain access to the measurement data 210 stored on blockchain 304.
In some embodiments, the remote computing system 114 can be replaced by another computing node, such as a computer on a peer-to-peer network, or other computing device controlled by a trusted entity. Although the remote computing system 114 can maintain control over the environmental measurement data blockchain 304, the blockchain 304 can be made accessible to other entities, such as the onboard computing device(s) 202. These entities can obtain, trace, or audit the relevant environmental measurement data stored in the data blocks 306 in the blockchain 304.
FIG. 4 is a data architecture diagram illustrating a simplified example of an environmental measurement data blockchain ledger 400 based on the blocks 306A-E of the environmental measurement data blockchain 304 of FIG. 3. The environmental measurement data blockchain ledger 400 of FIG. 4 is simplified to show block headers, metadata, and signatures of blocks 410A-E in order to demonstrate storage of environmental measurement data using a blockchain. In outline, a blockchain ledger may be a globally shared transactional database. Signatures can, in some examples, involve all or part of the data stored in the data the blocks 306A-E and can also involve public key addresses corresponding to sensors 106 involved in the creation of the measurement data 210.
The blockchain ledger 400 may be arranged as a Merkle tree data structure, as a linked list, or as any similar data structure that allows for cryptographic integrity. The blockchain ledger 400 allows for verification that the environmental measurement data has not been corrupted or tampered with because any attempt to tamper will change a Message Authentication Code (or hash) of a block, and other blocks pointing to that block will be out of correspondence. In one embodiment, illustrated in FIG. 4, each block may point to another block. Each block may include a pointer to the other block and a hash (or Message Authentication Code function) of the other block.
Each block in the blockchain ledger 400 may optionally contain a proof data field. The proof data field may indicate a reward that is due. The proof may be a proof of work, a proof of stake, a proof of research, or any other data field indicating a reward is due. For example, a proof of work may indicate that computational work was performed. Transportation of an item 102 may also be used as a proof of work. Identifying an item 102 by its unique item ID and a geographic location such as generated by GPS at a first time point and then identifying the same unique item ID at a different geographical location at a second time point may be used as a proof of work for an onboard computing device 202 of a vehicle 108 transporting the item 102.
As another example, a proof of stake may indicate that an entity has held an amount of cryptocurrency for a certain amount of time. For example, if 10 units of cryptocurrency have been held for 10 days, a proof of stake may indicate 10*10=100 time units have accrued. A proof of research may indicate that research was performed. In one example, a proof of research may indicate that a certain amount of computational work was performed—such as exploring whether molecules interact a certain way during a computational search for an efficacious drug compound.
The blocks 410 of environmental measurement data blockchain ledger 400 in the example of FIG. 4 may store data that specifies one or more thresholds for environmental conditions. The thresholds may be limit on temperature being within the range equal to or greater than 4° C. and less than equal to 30° C., in a genesis data block 410A. The remote computing system 114 may sign the genesis data block 410A and the blockchain system within which blockchain ledger 400 is created verifies that each data block 410 based on a proof function.
Alternatively, the onboard computing device 202 may provide a digital certificate independently or in conjunction with data such as a code provided by one of the sensor(s) 106 that generated a specific instance of measurement data 210. Measurement data blocks 410B-E for successive additions of environmental measurement data can be created and linked to genesis data block 410A such that a history of the environmental measurements is immutably and traceably stored using the blockchain ledger 400.
It is to be appreciated that a variety of approaches may be utilized that remain consistent with the disclosed technology. In some examples relating to environmental measurement, a trusted entity other than the remote computing system 114, such as the onboard computing device 202 and or one or more sensors 106 that generate environmental measurement data, can create, verify or validate measurement data blocks 410A-E. In other examples, multiple entities can be involved in verifying measurement data blocks 410, such as by requiring signatures from the remote computing system 114 and the onboard computing device 202 of the vehicle 108 transporting the item 102 to verify or validate measurement data blocks 410A-E.
In the example of FIG. 4, measurement data blocks 410 of measurement data blockchain ledger 400 includes sensor identifiers and measurement data along with a signature. To add another data block for the same or a different item 102, the remote computing system 114 creates data block 410B, which identifies the sensor SENSOR_ID_1 and includes the measurement data, temperature in this example, TEMP_data_2. The remote computing system 114 signs data block 410B and commits block 410B to the blockchain ledger 400 for verification by the blockchain platform 302. To add a data block for an additional temperature measurement, remote computing system 114 creates measurement data block 410C to add measurement data TEMP_data_3 for sensor SENSOR_ID_1.
Measurement data from multiple sensors may be added to the same blockchain ledger 400. In the example of FIG. 4, remote computing system 114 adds data block 410D to store temperature data TEMP_data_4 obtained from a second sensor SENSOR_ID_2. Likewise, measurements of different types of environmental conditions such as temperature, and humidity, as well as other conditions may be added to the same blockchain ledger 400.
FIGS. 5A-E illustrate flow diagrams of multiple variations of processes 500 which may be implemented in conjunction with elements of FIGS. 1-4. The processes are illustrated as a collection of blocks in a logical flow graph, which represent a sequence of operations that can be implemented in hardware, software, or a combination thereof. In the context of software, the blocks represent computer-executable instructions that, when executed by one or more processors, perform the recited operations.
Generally, computer-executable instructions include routines, programs, objects, components, data structures, and the like that perform or implement particular functions. The order in which operations are described is not intended to be construed as a limitation, and any number of the described blocks can be combined in any order and/or in parallel to implement the process. Processes described throughout this disclosure shall be interpreted accordingly.
FIG. 5A illustrates a variation of process 500 in which an item is returned to its origination location 116. At 502, profile data 214 defining a threshold value 216 for an environmental condition associated with the item 102 is received. The profile data 214 may be received by the delivery routing service 212 of FIG. 2 at or around the time shipment of the item 102 begins. The environmental condition may comprise temperature, humidity, moisture, barometric pressure, pressure on a container 104 holding the item, orientation, vibration, shock, light, ultraviolet radiation, ionizing radiation, atmospheric gas level, or any other type of measurable environmental condition that may negatively affect an item 102 during transport. The environmental condition is measured by a sensor 106 that is a sensor 106A that is located on the item 102 or on a container 104 or an onboard sensor 106B that is located on or within a vehicle 108 transporting the item 102.
The profile data 214 defining the threshold value 216 for the environmental condition may be stored in a blockchain such as the blockchain 222 in the database system 224 of FIG. 2. For example, the profile data 214 may be stored in a data block 410A in a blockchain ledger 400 as shown in FIG. 4. The item 102 itself may be associated with radio-frequency identification (RFID) tag encoding a blockchain address of the data block 410A that provides the profile data 214.
At 504, measurement data 210 indicating a measurement of the environmental condition from a sensor 106 associated with the item 102 while the item 102 is en route from an origination location 116 to a destination location 118 is received. The measurement data 210 may be received by the delivery routing service 212 as shown in FIG. 2. The frequency with which the sensor 106 samples and provides the measurement data 210 may depend upon the nature of the item 102 and its sensitivity to exposure to the environmental condition.
In general, the sampling period of the sensor 106 is less than the time required for the item 102 to become damaged or destroyed when exposed to the environmental condition. Thus, for example, if the item 102 will be spoiled by exposure to an unacceptable environmental condition for a few seconds, then the sensor should be capable of taking environment data readings at least every second or less. Similarly, if the item 102 will spoil if exposed to an unacceptable environmental condition continuously over several hours, then the sensor 106 may be configured to take environment data readings on an hourly or minutely basis, for example.
At 506, the measurement data 210 is determined to deviate from the threshold value 216. The measurement data 210 may deviate from the threshold value 216 by exceeding the threshold value 216, falling below the threshold value 216, or otherwise varying in magnitude and/or direction that is contrary to the pre-established threshold value 216. The determination that the measurement data 210 deviates from the threshold value 216 may be made by a sensor 106, the onboard computing device 202, or the remote computing system 114. Determining that the measurement data 210 deviates from the threshold value 216 is an example of a triggering event.
At 508, a shipping instruction 208 causing a system database 224 to change the destination location 118 to the origination location 116 is communicated directly or indirectly to the vehicle 108 transporting item 102. The change may be first communicated to the system database 224 which is then accessed by the onboard computing device 202 to receive the updated destination for the item 102. The system database 224 may be implemented with a blockchain 222 as shown in FIG. 2. Thus, a change to the destination location 118 may be implemented by adding an additional block to the blockchain 222 with the new destination location.
Additionally, a smart contract 226 in the blockchain 222 may store logic that causes the system database 224 to change the destination location 118 to the origination location 116 when the measurement data 210 deviates from the threshold value 216. Thus, the change of the delivery route for the item 102 may happen automatically based on readings detected by the sensors 106 and logic encoded in the blockchain 222.
FIG. 5B illustrates a variation of process 500 in which a replacement item 124 is shipped out upon detecting that an original item was exposed to unfavorable environmental conditions. Steps 502, 504, and 506 of process 500 are the same as described for FIG. 5A.
At 510, a shipping instruction 208 causing initiation of shipment of a replacement item 124 from the origination location 116 to the destination location 118 are communicated. The shipping instructions 208 in this instance may be communicated to the remote computing system 114, the origination location 116, the sender of the item 102, and/or another entity or system capable of initiating a second shipment. In an implementation, the shipping instruction 208 causing the initiation of shipment of the replacement item 124 from the origination location 116 to the destination location 118 are stored in a smart contract 226 in a blockchain 222.
FIG. 5C illustrates a variation of process 500 in which a performance metric 230 for a shipping agent is determined based on aggregate performance data. Steps 502, 504, and 506 of process 500 are the same as described for FIG. 5A. At 512, shipping instructions 208 modifying delivery of the item 102 are communicated. The shipping instructions 208 may be communicated, for example, to a navigation module 204 onboard a vehicle 108 transporting the item 102.
At 514, the measurement data 210 indicating the measurement of the environmental condition is aggregated with other measurement data obtained from other sensors associated with other items to create aggregated performance data. All of the measurement data may be obtained from sensors that are associated with items being transported by the same shipping agent. Thus, the aggregated performance data is a record of the environmental conditions experienced by many different items transported by the same shipping agent. Aggregating the measurement data 210 in this way provides insights into trends and commonalities in the way that a particular shipping agent handles items in its care. The aggregation of the various measurement data 210 may be performed by the delivery routing service 212.
At 516, a performance metric 230 for a shipping agent is determined based on the aggregated performance data. This determination may be made by the performance metric calculator 228. The performance metric 230 may be used to represent a quality of shipping provided by the shipping agent. This type of performance metric 230 is not based merely on timeliness of delivery or subjective evaluations provided by customers but is based on objective data collected by numerous sensors during the transportation of many different items.
FIG. 5D illustrates a variation of process 500 in which measurement data 210 of environmental conditions is stored in a blockchain 222 and delivery of an item 102 is modified based on the measurement data 210. Steps 502, 504, and 506 of process 500 are the same as described for FIG. 5A and step 512 is the same as described for FIG. 5C. At 518, a new data block 306, 410 that stores the measurement data 210 indicating the measurement of the environmental condition is created. The new data block 306, 410 may include measurement data 210 from multiple different sensors 106 and may even include data associated with multiple different items 102. For example, a vehicle 108 transporting a large number of items 102 each with multiple associated sensors 106, may create a new data block 306, 410 at a regular frequency (e.g., every five minutes) that includes all of the data from all of the sensors 106 in the vehicle 108.
At 520, the new data block 306, 410 is linked to a previous data block in a blockchain 222, 304, 400 associated with the item 102. The linking may be performed by any conventional technique for linking data blocks in a blockchain.
At 506, is determined that the measurement data 210, which is now recorded in a data block of the blockchain 222, 304, 400, deviates from the threshold value 216. At 512, shipping instructions 208 modifying delivery of the item 102 are communicated. As described above, the shipping instructions 208 may be generated based on logic or rules encoded in a smart contract 226 in the blockchain 222, 304, 400.
FIG. 5E illustrates a variation of process 500 in which an item 102 is sent to a disposal facility 122 after exposure to unfavorable environmental conditions. Steps 502, 504, and 506 of process 500 are the same as described for FIG. 5A. At 522, a disposal facility 122 closest to a location of a vehicle 108 transporting the item 102 is identified.
The location of the disposal facility 122 may be identified by the navigation module 204 in the onboard computing device 202. The onboard computing device 202, or a different computing device such as the remote computing system 114, may have access to a database (e.g., system database 224) that includes locations of disposal facilities 122 and indications of the types of items that can be disposed of at those facilities. Reference to this database and to a location obtained by the location sensor 110 on the vehicle 108 may be used to identify the closest disposal facility 122 capable of disposing of the item 102.
At 524, once the closest disposal facility 122 has been identified, an additional shipping instruction 208 causing a system database 224 to change the destination location 118 to the disposal facility 122 may be communicated. The shipping instructions 208 may be communicated to the navigation module 204 of the onboard computing device 202.
FIG. 5F illustrates a variation of process 500 in which an item 102 is sent to an inspection facility 120 after exposure to unfavorable environmental conditions. Steps 502, 504, and 506 of process 500 are the same as described for FIG. 5A. At 526, an inspection facility 120 closest to a location of a vehicle 108 transporting the item 102 is identified.
The location of the inspection facility 120 may be identified by the navigation module 204 in the onboard computing device 202. The onboard computing device 202, or a different computing device such as the remote computing system 114, may have access to a database (e.g., system database 224) that includes locations of inspection facilities 120 and indications of the types of items that can be inspected of at those facilities. Reference to this database and to a location obtained by the location sensor 110 on the vehicle 108 may be used to identify the closest disposal facility 122 capable of disposing of the item 102. In some instances, the origination location 116 may be the closest inspection facility 120.
At 528, once the closest inspection facility 120 has been identified, an additional shipping instruction 208 causing a system database 224 to change the destination location 118 to the inspection facility 120 may be communicated. The shipping instructions 208 may be communicated to the navigation module 204 of the onboard computing device 202. The inspection facility 120 may also be notified to expect that item 102 to be delivered and to prepare for inspection. The routing of the item 102 to an inspection facility 120 may be included in a blockchain 222 associated with that item 102 so that there is a permanent record that item 102 was inspected.
At the inspection facility 120, the item 102 may be inspected to determine if it is in fact damaged. For example, electronics that were exposed to vibration which exceeds a predetermined threshold level may be inspected by powering on and test usage. If the electronics still function correctly, they may be returned to the shipping agent and sent on to the original destination location 118. If the item 102 was damaged but can be repaired, item 102 may be repaired or refurbished at the inspection facility 120.
FIG. 6 is a data architecture diagram 600 showing an illustrative example of an interface for modifying a delivery route based on data recorded in an environmental measurement blockchain on a blockchain platform 602, such as the data blocks 306, 410 in FIGS. 3 and 4. In this example, a smart contract Application Program Interface (API) 604 provides an interface to the blockchain platform 602 that supports the environmental measurement blockchain. The blockchain platform 602 supports a smart contract 606, such as the smart contract 226 in FIG. 2. The smart contract 606 includes a Change_Destination( ) script 608 with code that, when executed by the blockchain platform 602, operates to change a destination location for delivery of an item in a database system such as the system database 224 of FIG. 2.
The Change_Destination( ) script 608 may, for example, change the destination location in response to an indication of a threshold deviation 610 from a computing device 612 which indicates that measurement data from a sensor deviates from a threshold value set for an item monitored by that sensor. The computing device 612 may be the delivery routing service 212 or the onboard computing device 202 of FIG. 2. The Change_Destination( ) script 608 communicates the new destination back to the communication device 612 as shown by path 614. The path 614 may carry shipping instructions 208 with the modified delivery route and destination to a navigation module 204 onboard a vehicle 108 as shown in FIG. 2. For example, an original destination location 118 may be changed to a disposal facility 122 if measurement data added to the environmental measurement blockchain indicates that the temperature of an item has exceeded a threshold temperature.

Blockchain Ledger Data Structure

FIG. 7A is a data architecture diagram illustrating a simplified example of a blockchain ledger 700 based on the blocks 306A-E of the environmental measurement data blockchain 304 of FIG. 3. The blockchain ledger 700 example of FIG. 7A is simplified to show block headers, metadata, and signatures of blocks 306A-E in order to demonstrate an environmental measurement ledger using a blockchain. In outline, a blockchain ledger may be a globally shared transactional database.
FIG. 7A is an illustrative example of a blockchain ledger 700 with a data tree holding permission data that is verified using cryptographic technologies. In FIG. 7A, each block 710 includes a block header 712 with information regarding previous and subsequent blocks and stores a transaction root node 714 to a data tree 720 holding transactional data. Permission data may store smart contracts, data related to transactions, or any other data. The elements of smart contracts may also be stored within transaction nodes of the blocks.
In the example of FIG. 7A, a data tree 720 such as a Merkle tree is used to cryptographically secure the permission data. For example, Transaction Tx1 node 734A of data tree 720A of block 710A can be hashed to Hash1 node 732A, Transaction Tx2 node 738A may be hashed to Hash2 node 736A. Hash1 node 732A and Hash2 node 736A may be hashed to Hash12 node 730A. A similar subtree may be formed to generate Hash34 node 740A. Hash12 node 730A and Hash34 node 740A may be hashed to Transaction Root 714A hash sorted in the data block 710A. By using a Merkle tree, or any similar data structure, the integrity of the transactions may be checked by verifying the hash is correct.
FIG. 7B is a data architecture diagram 750 showing an illustrative example of smart contract code, transactions, and messages that are bundled into a block so that their integrity is cryptographically secure and so that they may be appended to a blockchain ledger. In FIG. 7B, smart contracts 742 are code that executes on a computer. More specifically, the code of a smart contract may be stored in a blockchain ledger and executed by nodes of a distributed blockchain platform at a given time. The result of the smart code execution may be stored in a blockchain ledger. Optionally, a currency may be expended as smart contract code is executed. In the example of FIG. 7B, smart contracts 742 are executed in a virtual machine environment 760, although this is optional.
In FIG. 7B, the aspects of smart contracts 742 are stored in data nodes in data tree 720 in the blocks 710 of the blockchain ledger of FIG. 7A. In the example of FIG. 7B, Smart Contract 742A is stored in data block Tx1 node 734A of data tree 720A in block 710A, Smart Contract 742B is stored in Tx2 node 738A, Contract Account 754 associated with Smart Contract 742B is stored in Tx3 node 744A, and External Account is stored in Tx4 node 748B.

Storage of Smart Contracts and Permission Data in the Blockchain Ledger

To ensure the smart contracts are secure and generate secure data, the blockchain ledger must be kept up to date. For example, if a smart contract is created, the code associated with a smart contract must be stored in a secure way. Similarly, when smart contract code executes and generates permission data, the permission data must be stored in a secure way.
In the example of FIG. 7B, two possible embodiments for maintenance of the blockchain ledger are shown. In one embodiment, untrusted miner nodes (miners) 780 may be rewarded for solving a cryptographic puzzle and thereby be allowed to append a block to the blockchain. Alternatively, a set of trusted nodes 790 may be used to append the next block to the blockchain ledger. Nodes may execute smart contract code, and then one winning node may append the next block to a blockchain ledger.
Though aspects of the technology disclosed herein resemble a smart contract, in the present technologies, the policy of the contract may determine the way that the blockchain ledger is maintained. For example, the policy may require that the validation or authorization process for blocks on the ledger is determined by a centralized control of a cluster of trusted nodes. In this case, the centralized control may be a trusted node, such as the remote computing system 114, authorized to attest and sign the transaction blocks to validate them and validation by miners may not be needed.
Alternatively, the policy may provide for validation process decided by a decentralized cluster of untrusted nodes. In the situation where the blockchain ledger is distributed to a cluster of untrusted nodes, mining of blocks in the chain may be employed to validate the blockchain ledger.
Blockchains may use various time-stamping schemes, such as proof-of-work, to serialize changes. Alternate consensus methods include proof-of-stake, proof-of-burn, proof-of-research may also be utilized to serialize changes.
As noted above, in some examples, a blockchain ledger may be validated by miners to secure the blockchain. In this case, miners may collectively agree on a validation solution to be utilized. However, if a small network is utilized, e.g. private network, then the solution may be a Merkle tree and mining for the validation solution may not be required. When a transaction block is created, e.g. a data block 306 for environmental measurement data blockchain 304 or data block 410, the block is an unconfirmed and unidentified entity. To be part of the acknowledged “currency,” it may be added to the blockchain, and therefore relates to the concept of a trusted cluster.
In a trusted cluster, when a data block 306, 410 is added, every node competes to acknowledge the next “transaction” (e.g. a new environmental measurement data or delivery destination). In one example, the nodes compete to mine and get the lowest hash value: min{previous_hash, contents_hash, random_nonce_to_be_guessed}→result. Transaction order is protected by the computational race (faith that no one entity can beat the collective resources of the blockchain network). Mutual authentication parameters are broadcast and acknowledged to prevent double entries in the blockchain.
Alternatively, by broadcasting the meta-data for authenticating a secure ledger across a restricted network, e.g. only the signed hash is broadcast, the blockchain may reduce the risks that come with data being held centrally. Decentralized consensus makes blockchains suitable for the recording of secure transactions or events. The meta-data, which may contain information related to the data file, may also be ciphered for restricted access so that the meta-data does not disclose information pertaining to the data file.
The mining process may be utilized to deter double accounting, overriding or replaying attacks, with the community arrangement on the agreement based on the “good faith” that no single node can control the entire cluster. A working assumption for mining is the existence of equivalent power distribution of honest parties with supremacy over dishonest or compromised ones. Every node or miner in a decentralized system has a copy of the blockchain.
No centralized “official” copy exists, and no user is “trusted” more than any other. Transactions are broadcast to the network 112 using software. Mining nodes compete to compute a validation solution to validate transactions, and then broadcast the completed block validation to other nodes. Each node adds the block to its copy of the blockchain with transaction order established by the winning node.
Note that in a restricted network, stakeholders who are authorized to check or mine for the data file may or may not access the transaction blocks themselves, but would need to have keys to the meta-data (since they are members of the restricted network, and are trusted) to get the details. As keys are applied on data with different data classifications, the stakeholders can be segmented.
A decentralized blockchain may also use ad-hoc secure message passing and distributed networking. In this example, the environmental measurement data blockchain ledger may be different from a conventional blockchain in that there is a centralized clearinghouse, e.g. authorized central control for validation. Without the mining process, the trusted cluster can be contained in a centralized blockchain instead of a public or democratic blockchain. One way to view this is that a decentralized portion is as “democratic N honest parties” (multiparty honest party is a cryptography concept), and a centralized portion as a “trusted monarchy for blockchain information correction.” For example, there may be advantages to maintaining the data file as centrally authorized and kept offline.
In some examples, access to a resource and access control rule on a blockchain can be restricted by cryptographic means to be only open to authorized servers. Since the permission data or environmental measurement data blockchain ledgers are distributed, the authorized servers can validate it. A public key may be used as an address on a public blockchain ledger.
Note that growth of a decentralized blockchain may be accompanied by the risk of node centralization because the computer resources required to operate on bigger data become increasingly expensive.
The present technologies may involve operations occurring in one or more machines. As used herein, “machine” means physical data-storage and processing hardware programed with instructions to perform specialized computing operations. It is to be understood that two or more different machines may share hardware components. For example, the same integrated circuit may be part of two or more different machines.
One of ordinary skill in the art will recognize that a wide variety of approaches may be utilized and combined with the present approach involving an environmental measurement data blockchain ledger. The specific examples of different aspects of an environmental measurement data blockchain ledger described herein are illustrative and are not intended to limit the scope of the present disclosure.

Smart Contracts

Smart contracts are defined by code. As described previously, the terms and conditions of the smart contract may be encoded (e.g., by hash) into a blockchain ledger. Specifically, smart contracts may be compiled into bytecode (if executed in a virtual machine), and then the bytecode may be stored in a blockchain ledger as described previously. Similarly, permission data executed and generated by smart contracts may be stored in the blockchain ledger in the ways previously described.

Computer Architectures for Use of Smart Contracts and Blockchain Ledgers

Note that at least parts of processes of FIGS. 5A-F, smart contract 226 of FIG. 2, smart contract 606 of FIG. 6, smart contracts 742 of FIG. 7B and other processes and operations pertaining to blockchain distributed ledger technology described herein may be implemented in one or more servers, such as computer architecture 800 in FIG. 8 or the cloud. Data defining the results of user control input signals translated or interpreted as discussed herein may be communicated to a user device for display. Alternatively, the environmental measurement blockchain ledger processes may be implemented in a client device. In still other examples, some operations may be implemented in one set of computing resources, such as servers, and other steps may be implemented in other computing resources, such as a client device.
It should be understood that the methods described herein can be ended at any time and need not be performed in their entireties. Some or all operations of the methods described herein, and/or substantially equivalent operations, can be performed by execution of computer-readable instructions included on a computer-storage media, as defined below. The term “computer-readable instructions,” and variants thereof, as used in the description and claims, is used expansively herein to include routines, applications, application modules, program modules, programs, components, data structures, algorithms, and the like. Computer-readable instructions can be implemented on various system configurations, including single-processor or multiprocessor systems, minicomputers, mainframe computers, personal computers, hand-held computing devices, microprocessor-based, programmable consumer electronics, combinations thereof, and the like.
Thus, it should be appreciated that the logical operations described herein are implemented (1) as a sequence of computer implemented acts or program modules running on a computing system and/or (2) as interconnected machine logic circuits or circuit modules within the computing system. The implementation is a matter of choice dependent on the performance and other requirements of the computing system. Accordingly, the logical operations described herein are referred to variously as states, operations, structural devices, acts, or modules. These operations, structural devices, acts, and modules may be implemented in software, in firmware, in special purpose digital logic, and any combination thereof.
As described herein, in conjunction with the FIGURES described herein, the operations of the routines (e.g. processes of FIGS. 5A-F, smart contract 226 of FIG. 2, smart contract 606 of FIG. 6, smart contracts 742 of FIG. 7B) are described herein as being implemented, at least in part, by an application, component, and/or circuit. Although the following illustration refers to the components of FIGS. 5A-F, 6, and 7B, it can be appreciated that the operations of the routines may be also implemented in many other ways. For example, the routines may be implemented, at least in part, by a computer processor or a processor or processors of another computer. In addition, one or more of the operations of the routines may alternatively or additionally be implemented, at least in part, by a computer working alone or in conjunction with other software modules.
For example, the operations of routines are described herein as being implemented, at least in part, by an application, component and/or circuit, which are generically referred to herein as modules. In some configurations, the modules can be a dynamically linked library (DLL), a statically linked library, functionality produced by an application programming interface (API), a compiled program, an interpreted program, a script or any other executable set of instructions. Data and/or modules, such as the data and modules disclosed herein, can be stored in a data structure in one or more memory components. Data can be retrieved from the data structure by addressing links or references to the data structure.
Although the following illustration refers to the components of the FIGURES discussed above, it can be appreciated that the operations of the routines (e.g. processes of FIGS. 5A-F, smart contract 226 of FIG. 2, smart contract 606 of FIG. 6, smart contracts 742 of FIG. 7B) may be also implemented in many other ways. For example, the routines may be implemented, at least in part, by a processor of another remote computer or a local computer or circuit. In addition, one or more of the operations of the routines may alternatively or additionally be implemented, at least in part, by a chipset working alone or in conjunction with other software modules. Any service, circuit or application suitable for providing the technologies disclosed herein can be used in operations described herein.
FIG. 8 shows additional details of an example computer architecture 800 for a computer, such as the computing devices 114 and computing systems 202 of FIGS. 1 and 2, capable of executing the program components described herein. Thus, the computer architecture 800 illustrated in FIG. 8 illustrates an architecture for a server computer, mobile phone, a PDA, a smartphone, a desktop computer, a netbook computer, a tablet computer, an onboard computer, a game console, and/or a laptop computer. The computer architecture 800 may be utilized to execute any aspects of the software components presented herein.
The computer architecture 800 illustrated in FIG. 8 includes a central processing unit 802 (CPU), a system memory 804, including a random access memory 806 (RAM) and a read-only memory (ROM) 808, and a system bus 810 that couples the memory 804 to the CPU 802. A basic input/output system containing the basic routines that help to transfer information between sub-elements within the computer architecture 800, such as during startup, is stored in the ROM 808. The computer architecture 800 further includes a mass storage device 812 for storing an operating system 813, data (such as a copy of measurement data blockchain data 820 or permissions data store 822), and one or more application programs.
The mass storage device 812 is connected to the CPU 802 through a mass storage controller (not shown) connected to the bus 810. The mass storage device 812 and its associated computer-readable media provide non-volatile storage for the computer architecture 800. Although the description of computer-readable media contained herein refers to a mass storage device, such as a solid-state drive, a hard disk or CD-ROM drive, it should be appreciated by those skilled in the art that computer-readable media can be any available computer storage media or communication media that can be accessed by the computer architecture 800.
Communication media includes computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics changed or set in a manner so as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media.
By way of example, and not limitation, computer-readable storage media may include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. For example, computer-readable storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, digital versatile disks (DVD), HD-DVD, BLU-RAY, Ultra HD 4K BLU-RAY, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer architecture 800. For purposes the claims, the phrase “computer-readable storage media,” “computer-readable storage medium” and variations thereof, does not include waves, signals, and/or other transitory and/or intangible communication media, per se.
According to various configurations, the computer architecture 800 may operate in a networked environment using logical connections to remote computers through the network 856 and/or another network (not shown). The computer architecture 800 may connect to the network 856 through a network interface unit 814 connected to the bus 810. It should be appreciated that the network interface unit 814 also may be utilized to connect to other types of networks and remote computer systems. The computer architecture 800 also may include an input/output controller 816 for receiving and processing input from a number of other devices, including a keyboard, mouse, game controller, television remote or electronic stylus (not shown in FIG. 8). Similarly, the input/output controller 816 may provide output to a display screen, a printer, or other type of output device (also not shown in FIG. 8).
It should be appreciated that the software components described herein may, when loaded into the CPU 802 and executed, transform the CPU 802 and the overall computer architecture 800 from a general-purpose computing system into a special-purpose computing system customized to facilitate the functionality presented herein. The CPU 802 may be constructed from any number of transistors or other discrete circuit elements, which may individually or collectively assume any number of states. More specifically, the CPU 802 may operate as a finite-state machine, in response to executable instructions contained within the software modules disclosed herein. These computer-executable instructions may transform the CPU 802 by specifying how the CPU 802 transitions between states, thereby transforming the transistors or other discrete hardware elements constituting the CPU 802.
Encoding the software modules presented herein also may transform the physical structure of the computer-readable media presented herein. The specific transformation of physical structure may depend on various factors, in different implementations of this description. Examples of such factors may include, but are not limited to, the technology used to implement the computer-readable media, whether the computer-readable media is characterized as primary or secondary storage, and the like. For example, if the computer-readable media is implemented as semiconductor-based memory, the software disclosed herein may be encoded on the computer-readable media by transforming the physical state of the semiconductor memory. For example, the software may transform the state of transistors, capacitors, or other discrete circuit elements constituting the semiconductor memory. The software also may transform the physical state of such components in order to store data thereupon.
As another example, the computer-readable media disclosed herein may be implemented using magnetic or optical technology. In such implementations, the software presented herein may transform the physical state of magnetic or optical media, when the software is encoded therein. These transformations may include altering the magnetic characteristics of particular locations within given magnetic media. These transformations also may include altering the physical features or characteristics of particular locations within given optical media, to change the optical characteristics of those locations. Other transformations of physical media are possible without departing from the scope and spirit of the present description, with the foregoing examples provided only to facilitate this discussion.
In light of the above, it should be appreciated that many types of physical transformations take place in the computer architecture 800 in order to store and execute the software components presented herein. It also should be appreciated that the computer architecture 800 may include other types of computing devices, including hand-held computers, embedded computer systems, personal digital assistants, and other types of computing devices known to those skilled in the art. It is also contemplated that the computer architecture 800 may not include all of the components shown in FIG. 8, may include other components that are not explicitly shown in FIG. 8, or may utilize an architecture completely different than that shown in FIG. 8.
FIG. 9 depicts an illustrative distributed computing environment 900 capable of executing the software components described herein for maintaining a blockchain ledger. Thus, the distributed computing environment 900 illustrated in FIG. 9 can be utilized to execute many aspects of the software components presented herein. Also, the distributed computing environment 900 may represent components of the distributed blockchain platform discussed above.
According to various implementations, the distributed computing environment 900 includes a computing environment 902 operating on, in communication with, or as part of the network 904. The network 904 may be or may include the network 856, described above. The network 904 also can include various access networks. One or more client devices 906A-806N (hereinafter referred to collectively and/or generically as “clients 906) can communicate with the computing environment 902 via the network 904 and/or other connections (not illustrated in FIG. 9).
In one illustrated configuration, the clients 906 include a computing device 906A, such as a laptop computer, a desktop computer, or other computing device; a slate or tablet computing device (tablet computing device) 906B; a mobile computing device 906C such as a mobile telephone, a smartphone, an onboard computer, or other mobile computing device; a server computer 906D; and/or other devices 906N, which can include a hardware security module. It should be understood that any number of devices 906 can communicate with the computing environment 902. Two example computing architectures for the devices 906 are illustrated and described herein with reference to FIGS. 8 and 9. It should be understood that the illustrated devices 906 and computing architectures illustrated and described herein are illustrative only and should not be construed as being limited in any way.
In the illustrated configuration, the computing environment 902 includes application servers 908, data storage 910, and one or more network interfaces 912. According to various implementations, the functionality of the application servers 908 can be provided by one or more server computers that are executing as part of, or in communication with, the network 904. The application servers 908 can host various services, virtual machines, portals, and/or other resources.
In the illustrated configuration, the application servers 908 host one or more virtual machines 914 for hosting applications or other functionality. According to various implementations, the virtual machines 914 host one or more applications and/or software modules for a data management blockchain ledger. It should be understood that this configuration is illustrative only and should not be construed as being limiting in any way. The blockchain services 922 can include services for participating in management of one or more blockchains, such as by creating genesis blocks or data blocks, and performing validation.
As shown in FIG. 9, the application servers 908 also can host other services, applications, portals, and/or other resources (other resources) 924. The other resources 924 can include, but are not limited to, data encryption, data sharing, or any other functionality.
As mentioned above, the computing environment 902 can include data storage 910. According to various implementations, the functionality of the data storage 910 is provided by one or more databases or data stores operating on, or in communication with, the network 904. The functionality of the data storage 910 also can be provided by one or more server computers configured to host data for the computing environment 902. The data storage 910 can include, host, or provide one or more real or virtual data stores 926A-926N (hereinafter referred to collectively and/or generically as “datastores 926). The datastores 926 are configured to host data used or created by the application servers 908 and/or other data. Aspects of the datastores 926 may be associated with services for an environmental measurement data blockchain. Although not illustrated in FIG. 9, the datastores 926 also can host or store web page documents, word documents, presentation documents, data structures, algorithms for execution by a recommendation engine, and/or other data utilized by any application program or another module.
The computing environment 902 can communicate with, or be accessed by, the network interfaces 912. The network interfaces 912 can include various types of network hardware and software for supporting communications between two or more computing devices including, but not limited to, the clients 906 and the application servers 908. It should be appreciated that the network interfaces 912 also may be utilized to connect to other types of networks and/or computer systems.
It should be understood that the distributed computing environment 900 described herein can provide any aspects of the software elements described herein with any number of virtual computing resources and/or other distributed computing functionality that can be configured to execute any aspects of the software components disclosed herein. According to various implementations of the concepts and technologies disclosed herein, the distributed computing environment 900 may provide the software functionality described herein as a service to the clients using devices 906.
It should be understood that the devices 906 can include real or virtual machines including, but not limited to, server computers, web servers, personal computers, mobile computing devices, smartphones, and/or other devices, which can include user input devices. As such, various configurations of the concepts and technologies disclosed herein enable any device configured to access the distributed computing environment 900 to utilize the functionality described herein for creating and supporting an environmental measurement data blockchain ledger, among other aspects.
Turning now to FIG. 10, an illustrative computing device architecture 1000 for a computing device that is capable of executing various software components is described herein for supporting a blockchain ledger and applying environmental measurement data to the blockchain ledger. The computing device architecture 1000 is applicable to computing devices that can manage a blockchain ledger. In some configurations, the computing devices include, but are not limited to, mobile telephones, onboard computers, tablet devices, slate devices, portable video game devices, traditional desktop computers, portable computers (e.g., laptops, notebooks, ultra-portables, and netbooks), server computers, game consoles, and other computer systems. The computing device architecture 1000 is applicable to the remote computing system 114 shown in FIG. 1, the onboard computing device 202 shown in FIG. 2, and computing device 906A-N shown in FIG. 9.
The computing device architecture 1000 illustrated in FIG. 10 includes a processor 1002, memory components 1004, network connectivity components 1006, sensor components 1008, input/output components 1010, and power components 1012. In the illustrated configuration, the processor 1002 is in communication with the memory components 1004, the network connectivity components 1006, the sensor components 1008, the input/output (I/O) components 1010, and the power components 1012. Although no connections are shown between the individual components illustrated in FIG. 10, the components can interact to carry out device functions. In some configurations, the components are arranged so as to communicate via one or more busses (not shown).
The processor 1002 includes a central processing unit (CPU) configured to process data, execute computer-executable instructions of one or more application programs, and communicate with other components of the computing device architecture 1000 in order to perform various functionality described herein. The processor 1002 may be utilized to execute aspects of the software components presented herein and, particularly, those that utilize, at least in part, secure data.
In some configurations, the processor 1002 includes a graphics processing unit (GPU) configured to accelerate operations performed by the CPU, including, but not limited to, operations performed by executing secure computing applications, general-purpose scientific and/or engineering computing applications, as well as graphics-intensive computing applications such as high-resolution video (e.g., 620P, 1080P, and higher resolution), video games, three-dimensional (3D) modeling applications, and the like. In some configurations, the processor 1002 is configured to communicate with a discrete GPU (not shown). In any case, the CPU and GPU may be configured in accordance with a co-processing CPU/GPU computing model, wherein a sequential part of an application executes on the CPU and a computationally-intensive part is accelerated by the GPU.
In some configurations, the processor 1002 is, or is included in, a system-on-chip (SoC) along with one or more of the other components described herein below. For example, the SoC may include the processor 1002, a GPU, one or more of the network connectivity components 1006, and one or more of the sensor components 1008. In some configurations, the processor 1002 is fabricated, in part, utilizing a package-on-package (PoP) integrated circuit packaging technique. The processor 1002 may be a single core or multi-core processor.
The processor 1002 may be created in accordance with an ARM architecture, available for license from ARM HOLDINGS of Cambridge, United Kingdom. Alternatively, the processor 1002 may be created in accordance with an x86 architecture, such as is available from INTEL CORPORATION of Mountain View, Calif. and others. In some configurations, the processor 1002 is a SNAPDRAGON SoC, available from QUALCOMM of San Diego, Calif., a TEGRA SoC, available from NVIDIA of Santa Clara, California, a HUMMINGBIRD SoC, available from SAMSUNG of Seoul, South Korea, an Open Multimedia Application Platform (OMAP) SoC, available from TEXAS INSTRUMENTS of Dallas, Tex., a customized version of any of the above SoCs, or a proprietary SoC.
The memory components 1004 include a random-access memory (RAM) 1014, a read-only memory (ROM) 1016, an integrated storage memory (integrated storage) 1018, and a removable storage memory (removable storage) 1020. In some configurations, the RAM 1014 or a portion thereof, the ROM 1016 or a portion thereof, and/or some combination of the RAM 1014 and the ROM 1016 is integrated in the processor 1002. In some configurations, the ROM 1016 is configured to store a firmware, an operating system or a portion thereof (e.g., operating system kernel), and/or a bootloader to load an operating system kernel from the integrated storage 1018 and/or the removable storage 1020.
The integrated storage 1018 can include a solid-state memory, a hard disk, or a combination of solid-state memory and a hard disk. The integrated storage 1018 may be soldered or otherwise connected to a logic board upon which the processor 1002 and other components described herein also may be connected. As such, the integrated storage 1018 is integrated into the computing device. The integrated storage 1018 is configured to store an operating system or portions thereof, application programs, data, and other software components described herein. For example, the integrated storage 1018 may include a blockchain module 1019 for accessing data stored on a blockchain and for generating new data blocks for addition to the blockchain. The blockchain module 1019 may be the same or similar to the blockchain modules 211 and 220 shown in FIG. 2.
The removable storage 1020 can include a solid-state memory, a hard disk, or a combination of solid-state memory and a hard disk. In some configurations, the removable storage 1020 is provided in lieu of the integrated storage 1018. In other configurations, the removable storage 1020 is provided as additional optional storage. In some configurations, the removable storage 1020 is logically combined with the integrated storage 1018 such that the total available storage is made available as a total combined storage capacity. In some configurations, the total combined capacity of the integrated storage 1018 and the removable storage 1020 is shown to a user instead of separate storage capacities for the integrated storage 1018 and the removable storage 1020.
The removable storage 1020 is configured to be inserted into a removable storage memory slot (not shown) or other mechanism by which the removable storage 1020 is inserted and secured to facilitate a connection over which the removable storage 1020 can communicate with other components of the computing device, such as the processor 1002. The removable storage 1020 may be embodied in various memory card formats including, but not limited to, PC card, CompactFlash card, memory stick, secure digital (SD), miniSD, microSD, universal integrated circuit card (UICC) (e.g., a subscriber identity module (SIM) or universal SIM (USIM)), a proprietary format, or the like.
It can be understood that one or more of the memory components 1004 can store an operating system. According to various configurations, the operating system may include, but is not limited to, server operating systems such as various forms of UNIX certified by The Open Group and LINUX certified by the Free Software Foundation, or aspects of Software-as-a-Service (SaaS) architectures, such as MICROSFT AZURE from Microsoft Corporation of Redmond, Wash. or AWS from Amazon Corporation of Seattle, Washington. The operating system may also include WINDOWS MOBILE OS from Microsoft Corporation of Redmond, Wash., WINDOWS PHONE OS from Microsoft Corporation, WINDOWS from Microsoft Corporation, MAC OS or IOS from Apple Inc. of Cupertino, Calif., and ANDROID OS from Google Inc. of Mountain View, Calif. Other operating systems are contemplated.
The network connectivity components 1006 include a wireless wide area network component (WWAN component) 1022, a wireless local area network component (WLAN component) 1024, and a wireless personal area network component (WPAN component) 1026. The network connectivity components 1006 facilitate communications to and from the network 1056 or another network, which may be a WWAN, a WLAN, or a WPAN. Although only the network 1056 is illustrated, the network connectivity components 1006 may facilitate simultaneous communication with multiple networks, including the network 1056 of FIG. 10. For example, the network connectivity components 1006 may facilitate simultaneous communications with multiple networks via one or more of a WWAN, a WLAN, or a WPAN.
The network 1056 may be or may include a WWAN, such as a mobile telecommunications network utilizing one or more mobile telecommunications technologies to provide voice and/or data services to a computing device utilizing the computing device architecture 1000 via the WWAN component 1022. The mobile telecommunications technologies can include, but are not limited to, Global System for Mobile communications (GSM), Code Division Multiple Access (CDMA) ONE, CDMA7000, Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and Worldwide Interoperability for Microwave Access (WiMAX). Moreover, the network 1056 may utilize various channel access methods (which may or may not be used by the aforementioned standards) including, but not limited to, Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), CDMA, wideband CDMA (W-CDMA), Orthogonal Frequency Division Multiplexing (OFDM), Space Division Multiple Access (SDMA), and the like.
Data communications may be provided using General Packet Radio Service (GPRS), Enhanced Data rates for Global Evolution (EDGE), the High-Speed Packet Access (HSPA) protocol family including High-Speed Downlink Packet Access (HSDPA), Enhanced Uplink (EUL) or otherwise termed High-Speed Uplink Packet Access (HSUPA), Evolved HSPA (HSPA+), LTE, and various other current and future wireless data access standards. The network 1056 may be configured to provide voice and/or data communications with any combination of the above technologies. The network 1056 may be configured to or be adapted to provide voice and/or data communications in accordance with future generation technologies.
In some configurations, the WWAN component 1022 is configured to provide dual-multi-mode connectivity to the network 1056. For example, the WWAN component 1022 may be configured to provide connectivity to the network 1056, wherein the network 1056 provides service via GSM and UMTS technologies, or via some other combination of technologies. Alternatively, multiple WWAN components 1022 may be utilized to perform such functionality, and/or provide additional functionality to support other non-compatible technologies (i.e., incapable of being supported by a single WWAN component). The WWAN component 1022 may facilitate similar connectivity to multiple networks (e.g., a UMTS network and an LTE network).
The network 1056 may be a WLAN operating in accordance with one or more Institute of Electrical and Electronic Engineers (IEEE) 802.11 standards, such as IEEE 802.11a, 802.11b, 802.11g, 802.11n, and/or future 802.11 standards (referred to herein collectively as WI-FI). Draft 802.11 standards are also contemplated. In some configurations, the WLAN is implemented utilizing one or more wireless WI-FI access points.
In some configurations, one or more of the wireless WI-FI access points are another computing device with connectivity to a WWAN that are functioning as a WI-FI hotspot. The WLAN component 1024 is configured to connect to the network 1056 via the WI-FI access points. Such connections may be secured via various encryption technologies including, but not limited to, WI-FI Protected Access (WPA), WPA2, Wired Equivalent Privacy (WEP), and the like.
The network 1056 may be a WPAN operating in accordance with Infrared Data Association (IrDA), BLUETOOTH, wireless Universal Serial Bus (USB), Z-Wave, ZIGBEE, or some other short-range wireless technology. In some configurations, the WPAN component 1026 is configured to facilitate communications with other devices, such as peripherals, computers, or other computing devices via the WPAN.
The sensor components 1008 include a magnetometer 1028, an ambient light sensor 1030, a proximity sensor 1032, an accelerometer 1034, a gyroscope 1036, and a Global Positioning System sensor (GPS sensor) 1038. It is contemplated that other sensors, such as, but not limited to, temperature sensors or shock detection sensors, also may be incorporated in the computing device architecture 1000.
The I/O components 1010 include a display 1040, a touchscreen 1042, a data I/O interface component (data I/O) 1044, an audio I/O interface component (audio I/O) 1046, a video I/O interface component (video I/O) 1048, and a camera 1050. In some configurations, the display 1040 and the touchscreen 1042 are combined. In some configurations, two or more of the data I/O component 1044, the audio I/O component 1046, and the video I/O component 1048 are combined. The I/O components 1010 may include discrete processors configured to support the various interfaces described below or may include processing functionality built-in to the processor 1002.
The illustrated power components 1012 include one or more batteries 1052, which can be connected to a battery gauge 1054. The batteries 1052 may be rechargeable or disposable. Rechargeable battery types include, but are not limited to, lithium polymer, lithium ion, nickel cadmium, and nickel metal hydride. Each of the batteries 1052 may be made of one or more cells.
The power components 1012 may also include a power connector, which may be combined with one or more of the aforementioned I/O components 1010. The power components 1012 may interface with an external power system or charging equipment via an I/O component.

Illustrative Embodiments

The following examples described multiple possible embodiments for implementing the features described in this disclosure. The various embodiments described herein are not limiting nor is every feature from any given embodiment required to be present in another embodiment. Any two or more of the embodiments may be combined together unless context clearly indicates otherwise. As used herein in this document “or” means and/or. For example, “A or B” means A without B, B without A, or A and B. As used herein, “comprising” means including all listed features and potentially including addition of other features that are not listed. “Consisting essentially of” means including the listed features and those additional features that do not materially affect the basic and novel characteristics of the listed features. “Consisting of” means only the listed features to the exclusion of any feature not listed.
Clause 1. A computer-implemented method comprising: receiving profile data (214) defining a threshold value (216) for an environmental condition associated with an item (102); receiving measurement data (210) indicating a measurement of the environmental condition from a sensor (106) associated with the item (102) while the item (102) is en route from an origination location (116) to a destination location (118); determining that the measurement data (210) deviates from the threshold value (216); and communicating a shipping instruction (208) causing a system database (224) to change the destination location (118) to the origination location (116).
Clause 2. The computer-implemented method of clause 1, wherein the environmental condition comprises temperature, humidity, moisture, barometric pressure, pressure on a container holding the item, orientation, vibration, shock, light, ultraviolet radiation, ionizing radiation, or atmospheric gas level.
Clause 3. The computer-implemented method of any of clauses 1-2, wherein the system database comprises a blockchain and wherein causing the system database to change the destination location to the origination location comprises adding as a data block to the blockchain.
Clause 4. The computer-implemented method of claim 3, wherein the profile data defining the threshold value for the environmental condition is stored in the blockchain.
Clause 5. The computer-implemented method of claim 3, wherein causing the system database to change the destination location to the origination location is based on logic stored in a smart contract in the blockchain.
Clause 6. The computer-implemented method of any of clauses 1-5, further comprising: aggregating the measurement data indicating the measurement of the environmental condition with other measurement data obtained from other sensors associated with other items to create aggregated performance data; and determining a performance metric for a shipping agent based on the aggregated performance data.
Clause 7. The computer-implemented method of clause 6, wherein the performance metric identifies the environmental condition as deviating from the threshold value more frequently than a second environmental condition deviates from a second threshold value.
Clause 8. A computer-implemented method comprising: receiving profile data (214) defining a threshold value (216) for an environmental condition associated with an item (102); receiving measurement data (210) indicating a measurement of the environmental condition from a sensor (106) associated with the item (102) while the item (102) is en route from an origination location (116) to a destination location (118); determining that the measurement data (210) deviates from the threshold value (216); and communicating a shipping instruction (208) causing initiation of shipment of a replacement item (124) from the origination location (116) to the destination location (118).
Clause 9. The computer-implemented method of clause 8, wherein the environmental condition comprises temperature, humidity, moisture, barometric pressure, pressure on a container holding the item, orientation, vibration, shock, light, ultraviolet radiation, ionizing radiation, or atmospheric gas level.
Clause 10. The computer-implemented method of any of clauses 8-9, wherein the profile data is stored in a data block in a blockchain and wherein the item is associated with a radio-frequency identification (RFID) tag encoding a blockchain address of the data block.
Clause 11. The computer-implemented method of any of clauses 8-10, wherein the shipping instruction causing the initiation of shipment of the replacement item from the origination location to the destination location are stored in a smart contract in a blockchain.
Clause 12. The computer-implemented method of any of clauses 8-11, further comprising: creating a new data block that stores the measurement data indicating the measurement of the environmental condition; and linking the new data block to a previous data block in a blockchain associated with the item.
Clause 13. The computer-implemented method of any of clauses 8-12, further comprising: identifying a disposal facility closest to a location of a vehicle transporting the item; and communicating an additional shipping instruction causing a system database to change the destination location to the disposal facility.
Clause 14. A system comprising: a sensor (106) associated with an item (102), the sensor (106) configured to collect measurement data (210) indicating a measurement of an environmental condition; one or more processors (1002); and one or more memory components (1004) in communication with the one or more processors (1002), the memory components (1004) having computer-readable instructions stored thereupon that, when executed by the one or more processors (1002), cause the one or more processors (1002) to perform operations comprising: retrieving, from a data block (410A) associated with a blockchain, profile data (214) defining a threshold value (216) for the environmental condition; receiving the measurement data (210) from the sensor (106) while the item (102) is en route from an origination location (116) to a destination location (118); determining that the measurement data (210) of the environmental condition deviates from the threshold value (216); and initiating, based on a smart contract (226) in the blockchain (222), a response.
Clause 15. The system of clause 14, wherein the sensor associated with the item is attached to the item, included in a container holding the item, or present on a vehicle transporting the item.
Clause 16. The system of any of clauses 14-15, wherein the response includes generating a shipping instruction indicating an alternate destination location.
Clause 17. The system of clause 16, wherein the response further comprises communicating an alternate destination location to a vehicle transporting the item.
Clause 18. The system of any of clauses 14-17, wherein the response includes communicating a shipping instruction causing initiation of shipment of a replacement item from the origination location to the destination location.
Clause 19. The system of any of clauses 14-18, wherein the operations further comprise: creating a new data block that stores a record indicating the measurement data of the environmental condition deviated from the threshold value; and linking the new data block to a previous data block in a blockchain associated with a performance metric of a shipping agent.
Clause 20. The system of any of clauses 14-19, wherein the response comprises communicating a blockchain address of the smart contract to a vehicle transporting the item.

CONCLUSION

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts are disclosed as example forms of implementing the claims.
The terms “a,” “an,” “the” and similar referents used in the context of describing the invention are to be construed to cover both the singular and the plural unless otherwise indicated herein or clearly contradicted by context. The terms “based on,” “based upon,” and similar referents are to be construed as meaning “based at least in part” which includes being “based in part” and “based in whole,” unless otherwise indicated or clearly contradicted by context. The terms “portion,” “part,” or similar referents are to be construed as meaning at least a portion or part of the whole including up to the entire noun referenced. As used herein, “approximately” or “about” or similar referents denote a range of ±10% of the stated value.
Certain embodiments are described herein, including the best mode known to the inventors for carrying out the invention. Of course, variations on these described embodiments will become apparent to those of ordinary skill in the art upon reading the foregoing description. Skilled artisans will know how to employ such variations as appropriate, and the embodiments disclosed herein may be practiced otherwise than specifically described. Accordingly, all modifications and equivalents of the subject matter recited in the claims appended hereto are included within the scope of this disclosure. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the invention unless otherwise indicated herein or otherwise clearly contradicted by context.

Claims

What is claimed is:

1. A computer-implemented method comprising:

receiving profile data defining a threshold value for an environmental condition associated with an item;

receiving measurement data indicating a measurement of the environmental condition from a sensor associated with the item while the item is en route from an origination location to a destination location;

determining that the measurement data deviates from the threshold value; and

communicating a shipping instruction causing a system database to change the destination location to the origination location.

2. The computer-implemented method of claim 1, wherein the environmental condition comprises temperature, humidity, moisture, barometric pressure, pressure on a container holding the item, orientation, vibration, shock, light, ultraviolet radiation, ionizing radiation, or atmospheric gas level.

3. The computer-implemented method of claim 1, wherein the system database comprises a blockchain and wherein causing the system database to change the destination location to the origination location comprises adding as a data block to the blockchain.

4. The computer-implemented method of claim 3, wherein the profile data defining the threshold value for the environmental condition is stored in the blockchain.

5. The computer-implemented method of claim 3, wherein causing the system database to change the destination location to the origination location is based on logic stored in a smart contract in the blockchain.

6. The computer-implemented method of claim 1, further comprising:

aggregating the measurement data indicating the measurement of the environmental condition with other measurement data obtained from other sensors associated with other items to create aggregated performance data; and

determining a performance metric for a shipping agent based on the aggregated performance data.

7. The computer-implemented method of claim 6, wherein the performance metric identifies the environmental condition as deviating from the threshold value more frequently than a second environmental condition deviates from a second threshold value.

8. A computer-implemented method comprising:

determining that the measurement data deviates from the threshold value; and

communicating a shipping instruction causing initiation of shipment of a replacement item from the origination location to the destination location.

9. The computer-implemented method of claim 8, wherein the environmental condition comprises temperature, humidity, moisture, barometric pressure, pressure on a container holding the item, orientation, vibration, shock, light, ultraviolet radiation, ionizing radiation, or atmospheric gas level.

10. The computer-implemented method of claim 8, wherein the profile data is stored in a data block in a blockchain and wherein the item is associated with a radio-frequency identification (RFID) tag encoding a blockchain address of the data block.

11. The computer-implemented method of claim 8, wherein the shipping instruction causing the initiation of shipment of the replacement item from the origination location to the destination location are stored in a smart contract in a blockchain.

12. The computer-implemented method of claim 8, further comprising:

creating a new data block that stores the measurement data indicating the measurement of the environmental condition; and

linking the new data block to a previous data block in a blockchain associated with the item.

13. The computer-implemented method of claim 8, further comprising:

identifying a disposal facility closest to a location of a vehicle transporting the item; and

communicating an additional shipping instruction causing a system database to change the destination location to the disposal facility.

14. A system comprising:

a sensor associated with an item, the sensor configured to collect measurement data indicating a measurement of an environmental condition;

one or more processors; and

one or more memory components in communication with the one or more processors, the memory components having computer-readable instructions stored thereupon that, when executed by the one or more processors, cause the one or more processors to perform operations comprising:

retrieving, from a data block associated with a blockchain, profile data defining a threshold value for the environmental condition;

receiving the measurement data from the sensor while the item is en route from an origination location to a destination location;

determining that the measurement data of the environmental condition deviates from the threshold value; and

initiating, based on a smart contract in the blockchain, a response.

15. The system of claim 14, wherein the sensor associated with the item is attached to the item, included in a container holding the item, or present on a vehicle transporting the item.

16. The system of claim 14, wherein the response includes generating a shipping instruction indicating an alternate destination location.

17. The system of claim 16, wherein the response further comprises communicating an alternate destination location to a vehicle transporting the item.

18. The system of claim 14, wherein the response includes communicating a shipping instruction causing initiation of shipment of a replacement item from the origination location to the destination location.

19. The system of claim 14, wherein the operations further comprise:

creating a new data block that stores a record indicating the measurement data of the environmental condition deviated from the threshold value; and

linking the new data block to a previous data block in a blockchain associated with a performance metric of a shipping agent.

20. The system of claim 14, wherein the response comprises communicating a blockchain address of the smart contract to a vehicle transporting the item.