Patent Application
20190303853
The present disclosure relates to supply chain verification, and more specifically to identifying changes to a package, or how a package is being transported, based on differences between data stored in a blockchain and data detected from sensors.
Blockchain is a shared and distributed ledger that may facilitate the process of recording transactions and tracking assets in a peer-to-peer network. An asset may be tangible (e.g., a house, a car, and so on). An asset may also be intangible like intellectual property (IP), such as patents, copyrights, or branding. For example, a blockchain-based supply chain system may facilitate transferring products and reduce disputes among the parties.
An exemplary method which can be performed using concepts disclosed herein can include: receiving, at a processor, a notification that a package is near a sensor having a sensor type; receiving, at the processor from a database, a blockchain record for the package, wherein the processor has access to a private key necessary to amend the blockchain record; identifying, via the processor, most recent data within the blockchain record for the sensor type; comparing, via the processor, the most recent data within the blockchain to current data produced by the sensor, to yield a comparison; identifying, via the processor and based on the comparison, a difference in the most recent data within the blockchain and the current data produced by the sensor; generating, via the processor, a block comprising the difference; adding, via the processor, the block to the blockchain, to yield an updated blockchain; and storing the updated blockchain in the database.
An exemplary system configured according to the concepts disclosed herein can include: a processor; and a computer-readable storage medium having instructions stored which, when executed by the processor, cause the processor to perform operations comprising: receiving a notification that a package is near a sensor having a sensor type; receiving, from a database, a blockchain record for the package, wherein the processor has access to a private key necessary to amend the blockchain record; identifying most recent data within the blockchain record for the sensor type; comparing the most recent data within the blockchain to current data produced by the sensor, to yield a comparison; identifying, based on the comparison, a difference in the most recent data within the blockchain and the current data produced by the sensor; generating a block comprising the difference; adding the block to the blockchain, to yield an updated blockchain; and storing the updated blockchain in the database.
An exemplary non-transitory computer-readable storage medium configured as disclosed herein can have instructions stored which, when executed by a computing device, can cause the computing device to perform operations which include: receiving a notification that a package is near a sensor having a sensor type; receiving, from a database, a blockchain record for the package, wherein the processor has access to a private key necessary to amend the blockchain record; identifying most recent data within the blockchain record for the sensor type; comparing the most recent data within the blockchain to current data produced by the sensor, to yield a comparison; identifying, based on the comparison, a difference in the most recent data within the blockchain and the current data produced by the sensor; generating a block comprising the difference; adding the block to the blockchain, to yield an updated blockchain; and storing the updated blockchain in the database.
Additional features and advantages of the disclosure will be set forth in the description which follows, and in part will be obvious from the description, or can be learned by practice of the herein disclosed principles. The features and advantages of the disclosure can be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. These and other features of the disclosure will become more fully apparent from the following description and appended claims, or can be learned by the practice of the principles set forth herein.
Various embodiments of the disclosure are described in detail below. While specific implementations are described, it should be understood that this is done for illustration purposes only. Other components and configurations may be used without parting from the spirit and scope of the disclosure.
When packages are transported, they are subjected to a wide variety of conditions and circumstances which may affect the condition or viability of the package. A record of how the package is transported is often used to confirm inspections, conditions, etc. For example, a package may need to be refrigerated during transport, and a record of the temperature of the carrier (e.g., within the refrigerated truck) may be required by a buyer of that package. Likewise, a record of when a seal has been inspected or verified may be required by the buyer of a package. However, ensuring accuracy of such records can be difficult. Specifically, ensuring that the records are (1) accurate, and (2) unaltered, requires a technical solution such as that disclosed herein. Such accuracy cannot, for example, be accomplished by a human being because human beings can record incorrect values, alter records, or otherwise render the record inaccurate, false, or corruptible.
To counter those detriments, a record of the package is created in a manner which is independent of human influence. As sensors record data about a package, that data is added to a record which is specific to that package. Permission is required to add information to the record, such that unauthorized sensor data is not added. Likewise, once data has been added to the record, removing the data (or altering the data) is difficult, if not impossible. Preferably, this is done through the use of a blockchain using asymmetrical encryption, where private keys are required to add blocks of data to the blockchain for a package. Consider the following example.
A package is sealed at a distribution center and prepared for transit to a retail center. As instructions are received at the distribution center to prepare and ship the package, a blockchain is generated for that package. The blockchain is stored on a distributed ledger which includes a backend database. As the package is sealed or otherwise prepared for transit, sensors record initial data about the package and transmit that initial data to a server. The server adds that initial data (as a new block) to the newly generated blockchain for the package.
As the package is in transit to the retail center, additional sensors can detect the environment of the package, the condition of the package, or other information about the package. For example, a camera, video, or other optical sensor may perform a visual inspection of the package seal and report a quality or condition of the seal back to a central server. Likewise, temperature sensors, vibration sensors, humidity sensors, and other sensor types may report data back to the central server. The central server, upon receiving the data associated with a package, can retrieve the package's blockchain from a database, compare the newly received data to the data stored in the most recent block of the blockchain, and determine if there is a change.
If there is a change between the newly reported data and the stored data, the central server can generate a new block which refers to the previous block, but which contains the new data (or the changes to the previous data). For example, if a first camera checks the seal on the package and determines that the seal has been tampered with, the first camera sensor can send a picture or other sensor data to the central server. The central server can compare that data to data previously saved on the blockchain for that package. If the tampering had been previously identified, no additional data may be saved to the blockchain, whereas if this is the first time the tampering has been identified for that specific package, the blockchain can be modified to include the data.
In addition, the picture or video of the tampered seal may be included as a sidechain to the blockchain. This sidechain can include the data which prompted additions to the blockchain. Examples of the sidechain data can include “raw,” unprocessed sensor data, such as the picture or video of the tampered seal, temperature data, etc. The sidechains can vary from the package specific blockchains in terms of the permissions needed to read the data in a given blockchain, permissions to write to the blockchain, encryption, etc. However, in some configurations, the sidechain, or parts of the sidechain, can be “locked down” when the sidechain contains data which prompted a specific addition of a block to the blockchain.
In some instances, the ability to communicate the sensor data to the central server, or to access a database, may be restricted. For example, the package may be in transit when a temperature sensor in the refrigerated truck detects a temperature spike which needs to be recorded for a package. In some configurations, this can be remedied by the package having a smart seal applied to the package. The smart seal can contain a basic processor, memory, and communications equipment. The smart seal may have power for these computing/communication elements, or the smart seal may be remotely powered (using near field communications, induction, RFID (Radio Frequency Identification), UHF (Ultra High Frequency), etc.). In such configurations, the truck thermometer can register the temperature change, then communicate the data to the package's smart seal. In one example, the smart seal can record the temperature data within the smart seal memory, which can then be communicated to the central server when the package is capable of communicating with a network and the central server. As another example, the smart seal can store a copy of the package's blockchain, compare the sensor data to values stored on the blockchain, and determine if the values are sufficiently different that a new block needs to be generated. If a new block does need to be generated, the package's smart seal can then generate the new block based on the differences between the current sensor data to previous values, then add that block to the stored blockchain within the smart seal. When the package is within range of a network and the central server, the package can communicate the updated blockchain to the central server, where it can replace the stored blockchain for that package with the updated version.
As described, in some configurations, the disclosed systems and methods may be applied to track the physical status of a product, such as temperature, vibration, shock, etc. In some cases, the shipping box/package may include a temperature monitoring device (e.g., a temperature sensor or thermometer). As described above, as long as the temperatures are in compliance with package requirements, no action may be taken. However, once a temperature threshold is crossed, the system or the temperature device can begin logging the over- or under-temperature (and the corresponding time), then add this to the blockchain record. The actual temperature and time data may be recorded in an unencrypted “side-chain,” linked to the blockchain record, but available for inspection without use of a private key. This can allow for identifying trends in the data and comparing carriers or couriers, etc. The system may also compare the “ideal” or “intended” temperatures vs. the actually measured temperatures.
In some configurations, the smart label may be used to record data of time and temperature of a product/package containing the product while the product is in route. The data may be added to the blockchain ledger periodically (i.e., every ten minutes, or other period of time). The smart labels may also be able to track items/products and identify products which have been exposed to temperatures outside of their requirements. This information can then be used to recall certain products.
In some configurations, the smart label may communicate with the point of sale (POS) and self-checkout system (SCO) devices to indicate that the product is temperature compliant at the sale point. Similarly, the smart label (or seal) may communicate with refrigerators, scales, humidity sensors, etc., which can detect information about the package and otherwise provide information about the status of the product.
In some configurations, a smart seal, or label, may be affixed to the case/box/package of products at the manufacturer. The smart seal may track the time and temperature exposure of the case until it is unpacked. Once unpacked, the smart seal can communicate with the individual product seals and download the time/temperature data to those individual smart seals. That is, the smart seal for the case can then communicate the data to the individual smart seals for the individual products stored in the case.
In some configurations, if a peer-to-peer network is permissioned, it can enable the creation of a parties-only network with proof that parties are who they say they are and that background documents are exactly as represented. This may further protect the system against tampering, fraud, and/or cybercrime.
In some configurations, through the use of IDs, private keys, and permissions, parties can specify which sensor details they want other parties/participants to be permitted to view. Permissions can be expanded or limited on an individual or group basis. For example, some groups may be limited as to what aspects of sensor data, stored in a blockchain or other secure format, they may see. However, some individuals within that group may be less restricted than the overall group.
In some configurations, permissions and cryptography may be used to prevent unauthorized access to the database and blockchains, and thereby ensure (1) that parties/participants are who they claim to be and (2) that only authorized parties are looking at, or modifying, the package records. Privacy can be maintained through cryptographic techniques (such as asymmetric cryptography) and/or data partitioning techniques to give parties/participants selective visibility into the ledger. In some configurations, the identity of parties making additions or modifications to the blockchain can be masked.
In some configurations, the package data can be recorded in a fob, smart seal, RFID, or other device which is associated with the package. Such devices can have memory, a processing unit, the ability to communicate with the Internet, the ability to communicate with other packages or Internet of Things (IOT) devices, etc. In some cases, the memory device can include a destination address (such as a residential address for a package being delivered, or a retail store number for a package in transit between a distribution center and a retail store). The destination address can, however, be modified as necessary by the system, thereby enabling smart package routing while simultaneously maintaining a complete and accurate record of where the package has gone, and to what conditions the package has been exposed. The destination address, recipient and other delivery information may be stored or coded in the blockchain for the package. This makes it difficult to re-route the package. Nay entity with access to the blockchain can determine if the package is being properly routed, or if it has been improperly re-routed.
In some cases, the sensor data received can be close to previous values, but not exactly identical. In such cases, the processor can compare the stored data to the current sensor data and determine if the current sensor data is outside of a predefined range, or threshold range. If so, the processor can initiate the generation of a new block to the added to the blockchain, whereas if the sensor data is different, but within the threshold range, the processor may ignore the identified change.
As described above, preferably, the determination regarding whether to generate a new block and add that block to the blockchain is made either by the processor co-located with the package as part of a smart seal/label, or by a central computing system, such as a server. However, in some cases the computing can be allocated out to other processors which have greater access to power or processing capacity. For example, if a package is being transported in a truck, the truck may have a separate computing system which can read the blockchain information associated with a package, receive the sensor data, and make the updates to the blockchain. In another example, the package may make the initial determination that a block needs to be generated, then transmit a request to the truck to generate the block. Likewise, distribution of computing can be done with other nearby packages or IOT devices.
The disclosure now turns to the exemplary configurations depicted in the Figures. The features and steps outlined herein are exemplary and can be implemented in any combination thereof, including combinations that exclude, add, or modify certain features or steps.
In some configurations, the optical sensor/camera 106 can provide data regarding the condition of a seal 104. For example, the seal 104 may, when first applied, be considered perfect, a “10”, and later the camera 106 may detect a small tear in the seal 104, such that the seal is compromised—a “6”. The system can then update the database 112 with the new seal condition “6”, or the change (“−4”).
Another exemplary sensor is a scale 108 which can detect information about the weight of the package 102. If the scale 108 reports data to the server 110 which is different than previously stored data about the package 102, the server 110 can similarly update the package-specific data. Other exemplary sensors can include vibration sensors, shock sensors, temperature sensors, humidity sensors, infrared sensors, etc.
In some configurations, the seal 104 can store data (either a portion or a complete copy) of the data stored in the database 112. For example, the database 112 can store a blockchain specific to the package 102, and the seal 104 can have memory which stores either a copy of the blockchain, or a copy of a portion of the blockchain. If the sensors 106, 108 are unable to communicate with the server 110, the sensors 106, 108 may wirelessly communicate with the smart seal 104 to store the sensor data or differences within the smart seal 104 memory. This distributed ledger can then be propagated to the server 110 when the package 102 is within network range.
The communications equipment 206 can include one or more antennas, amplifiers, etc., configured to transmit and/or receive data from outside (non-contiguous) resources. The power 208 can be a battery, or can be a mechanism to receive power through outside mechanisms, such as induction, RF power, UHF power, or other near-field power mechanisms.
In addition, the smart seal 200 may communicate via WIFI with blockchain, for example, to receive the supply chain requirements for the products and/or send the processed sensory data to the blockchain. Also the smart seal 200 may be configured to activate and/or deactivate some sensors based on the requirements for each product, package or case. For example, if all items in the package or case are temperature-controlled, then no vibration sensors are required, so the vibration sensors can be deactivated. The smart seal 200 may be activated when items are loaded into the package or case. The activation signal may include instruction to obtain the logic for the mission from a blockchain location. The logic may be loaded into and run by the smart seal 200. The logic may define the sensors to be activated, the parameters to be monitored, threshold levels or ranges. The logic may also provide the smart seal a ledger location to use in storing information associated with the present mission.
When changes to the package data 308, 316 are detected, a new block can be generated and added to the blockchain, with updated package data 308, 316 (or the detected differences). In the illustrated example, the condition of a seal has changed from “10” in the first package data 308, to a “6” 318 in the second package data 316. In addition, the cause for a new block being added to the blockchain can be added as a sidechain 320. In this case, the cause is a photograph, or a video, of the seal, whereas in other cases it may be raw sensor data, processed sensor data, etc. In some configurations, the sidechain 320 can be subject to the same encryption as the remainder of the blockchain, whereas in other configurations the sidechain 320 may be publically available (i.e., not subject to encryption).
In some configurations, both the processor and the database can be part of a smart seal attached to the package. In such configurations, the method can further include identifying the package as within a communications range of a network; and transmitting the updated blockchain from the database to the network.
In some configurations, the processor and the database can be part of a non-mobile computing system.
Exemplary sensors can include one or more of a scale, a thermometer, a camera, a humidity sensor, an accelerometer, a light sensor, and GPS (Global Positioning System) receiver. In some configurations, the difference must be above a threshold to be considered, and that threshold can vary according to a package type and the sensor type. For example, humidity may matter less for a refrigerated package versus an electronics package, and so the threshold range for requiring a modification due to a change in humidity for a refrigerated package may be larger than a similar range for an electronics package. Similar variations in food packages, clothing packages, outdoor packages, etc., may result in a wide variety of thresholds and ranges.
In some configurations, the method can further include storing the current data in a non-encrypted side chain associated with the blockchain.
With reference to
The system bus 510 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. A basic input/output (BIOS) stored in ROM 540 or the like, may provide the basic routine that helps to transfer information between elements within the computing device 500, such as during start-up. The computing device 500 further includes storage devices 560 such as a hard disk drive, a magnetic disk drive, an optical disk drive, tape drive or the like. The storage device 560 can include software modules 562, 564, 566 for controlling the processor 520. Other hardware or software modules are contemplated. The storage device 560 is connected to the system bus 510 by a drive interface. The drives and the associated computer-readable storage media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the computing device 500. In one aspect, a hardware module that performs a particular function includes the software component stored in a tangible computer-readable storage medium in connection with the necessary hardware components, such as the processor 520, bus 510, display 570, and so forth, to carry out the function. In another aspect, the system can use a processor and computer-readable storage medium to store instructions which, when executed by the processor, cause the processor to perform a method or other specific actions. The basic components and appropriate variations are contemplated depending on the type of device, such as whether the device 500 is a small, handheld computing device, a desktop computer, or a computer server.
Although the exemplary embodiment described herein employs the hard disk 560, other types of computer-readable media which can store data that are accessible by a computer, such as magnetic cassettes, flash memory cards, digital versatile disks, cartridges, random access memories (RAMs) 550, and read-only memory (ROM) 540, may also be used in the exemplary operating environment. Tangible computer-readable storage media, computer-readable storage devices, or computer-readable memory devices, expressly exclude media such as transitory waves, energy, carrier signals, electromagnetic waves, and signals per se.
To enable user interaction with the computing device 500, an input device 590 represents any number of input mechanisms, such as a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, speech and so forth. An output device 570 can also be one or more of a number of output mechanisms known to those of skill in the art. In some instances, multimodal systems enable a user to provide multiple types of input to communicate with the computing device 500. The communications interface 580 generally governs and manages the user input and system output. There is no restriction on operating on any particular hardware arrangement and therefore the basic features here may easily be substituted for improved hardware or firmware arrangements as they are developed.
Use of language such as “at least one of X, Y, and Z” or “at least one or more of X, Y, or Z” are intended to convey a single item (just X, or just Y, or just Z) or multiple items (i.e., {X and Y}, {Y and Z}, or {X, Y, and Z}). “At least one of” is not intended to convey a requirement that each possible item must be present.
The various embodiments described above are provided by way of illustration only and should not be construed to limit the scope of the disclosure. Various modifications and changes may be made to the principles described herein without following the example embodiments and applications illustrated and described herein, and without departing from the spirit and scope of the disclosure.
The present application claims priority to U.S. Provisional Patent Application No. 62/649,983, filed Mar. 29, 2018, the contents of which are incorporated herein in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62649983 | Mar 2018 | US |
