U.S. patent application number 17/348248 was filed with the patent office on 2022-04-07 for secure shipment receive apparatus with delegation-chain.
The applicant listed for this patent is Intel Corporation. Invention is credited to Mats Agerstam, Vijay Sarathi Kesavan, Ned Smith, Shilpa Sodani.
Application Number | 20220108266 17/348248 |
Document ID | / |
Family ID | |
Filed Date | 2022-04-07 |
United States Patent
Application |
20220108266 |
Kind Code |
A1 |
Smith; Ned ; et al. |
April 7, 2022 |
SECURE SHIPMENT RECEIVE APPARATUS WITH DELEGATION-CHAIN
Abstract
Methods, apparatus, systems and articles of manufacture are
disclosed to coordinate and manage secure shipment of a package. An
example shipment coordination apparatus includes an address
generator and a verification engine. The example apparatus includes
a shipping group coordinator to generate a group including a sender
and a receiver based on a) a first digital address associated with
the sender, b) a second digital address associated with the
receiver, and c) at least one encryption key associated with the
first digital address and/or the second digital address, the
shipping group coordinator to initiate delivery instruction and
manage receipt confirmation of a package at a second physical
address corresponding to the second digital address based on
verification of a token identifying the receiver and to provide
messaging between the sender and the receiver in the group using a
group encryption key to keep messages private in the group.
Inventors: |
Smith; Ned; (Beaverton,
OR) ; Agerstam; Mats; (Portland, OR) ;
Kesavan; Vijay Sarathi; (Portland, OR) ; Sodani;
Shilpa; (Santa Clara, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Intel Corporation |
Santa Clara |
CA |
US |
|
|
Appl. No.: |
17/348248 |
Filed: |
June 15, 2021 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
16023892 |
Jun 29, 2018 |
11068834 |
|
|
17348248 |
|
|
|
|
International
Class: |
G06Q 10/08 20120101
G06Q010/08; G06K 19/07 20060101 G06K019/07; H04L 9/32 20060101
H04L009/32; H04L 9/08 20060101 H04L009/08; H04L 9/30 20060101
H04L009/30 |
Claims
1. (canceled)
2. A shipment coordination apparatus comprising: at least one
memory; instructions in the apparatus; and processor circuitry to
execute the instructions to at least: electronically generate a
communication group including a sender and a first receiver based
on a) a first digital address associated with the sender, b) a
second digital address associated with the first receiver, and c)
at least one encryption key associated with at least one of the
first digital address or the second digital address; generate a
token identifying the first receiver, the first receiver associated
with a delivery instruction for a package to a delivery address
corresponding to the second digital address, confirmation of
delivery to be based on verification of the token; facilitate
messaging between the sender and the first receiver in the
communication group using a group encryption key to keep messages
private in the communication group; adjust, using at least in a
part a notification from the first receiver, the delivery address
from corresponding to the second digital address to corresponding
to a third digital address, the third digital address associated
with a second receiver; and update the token to form an updated
token to identify the second receiver and to invite the second
receiver to join the communication group to message and receive the
package at the delivery address using the updated token and a chain
of authorization including the first receiver and the second
receiver.
3. The shipment coordination apparatus of claim 2, wherein the
second digital address is generated from a physical address using
the at least one encryption key.
4. The shipment coordination apparatus of claim 3, wherein the
second digital address is registered with the communication
group.
5. The shipment coordination apparatus of claim 2, wherein the
processor circuitry is to verify the second receiver using the at
least one encryption key.
6. The shipment coordination apparatus of claim 2, wherein the
processor circuitry is to store the chain of authorization using a
ledger as a delegation-chain.
7. The shipment coordination apparatus of claim 2, wherein the at
least one encryption key includes a private encryption key, a
private signing key, a public encryption key, and a public signing
key.
8. The shipment coordination apparatus of claim 2, wherein the
processor circuitry is to interact with a sending application and a
receiving application to register the first digital address and the
second digital address.
9. The shipment coordination apparatus of claim 2, wherein the
processor circuitry is to facilitate communication of messages in
the communication group to be verified using a nonce word and a
digital signature.
10. The shipment coordination apparatus of claim 2, wherein the
processor circuitry is to communicate with a low power tag
associated with the package.
11. A tangible computer-readable storage medium comprising
instructions which, when executed, cause processor circuitry to at
least: electronically generate a communication group including a
sender and a first receiver based on a) a first digital address
associated with the sender, b) a second digital address associated
with the first receiver, and c) at least one encryption key
associated with at least one of the first digital address or the
second digital address; generate a token identifying the first
receiver, the first receiver associated with a delivery instruction
for a package to a delivery address corresponding to the second
digital address, confirmation of delivery to be based on
verification of the token; facilitate messaging between the sender
and the first receiver in the communication group using a group
encryption key to keep messages private in the communication group;
adjust, using at least in a part a notification from the first
receiver, the delivery address from corresponding to the second
digital address to corresponding to a third digital address, the
third digital address associated with a second receiver; and update
the token to form an updated token to identify the second receiver
and to invite the second receiver to join the communication group
to message and receive the package at the delivery address using
the updated token and a chain of authorization including the first
receiver and the second receiver.
12. The computer-readable storage medium of claim 11, wherein the
instructions, when executed generate the second digital address
from a physical address using the at least one encryption key.
13. The computer-readable storage medium of claim 11, wherein the
at least one encryption key includes a private encryption key, a
private signing key, a public encryption key, and a public signing
key, and wherein the instructions, when executed, cause the
processor circuitry to verify the second receiver using the at
least one encryption key.
14. The computer-readable storage medium of claim 11, wherein the
instructions, when executed, cause the processor circuitry to store
the chain of authorization using a ledger as a
delegation-chain.
15. The computer-readable storage medium of claim 11, wherein the
instructions, when executed, cause the processor circuitry to
interact with a sending application and a receiving application to
register the first digital address and the second digital
address.
16. The computer-readable storage medium of claim 11, wherein the
instructions, when executed, cause the processor circuitry to
facilitate communication of messages in the communication group to
be verified using a nonce word and a digital signature.
17. A method comprising: electronically generating a communication
group including a sender and a first receiver based on a) a first
digital address associated with the sender, b) a second digital
address associated with the first receiver, and c) at least one
encryption key associated with at least one of the first digital
address or the second digital address; generating a token
identifying the first receiver, the first receiver associated with
a delivery instruction for a package to a delivery address
corresponding to the second digital address, confirmation of
delivery to be based on verification of the token; facilitating
messaging between the sender and the first receiver in the
communication group using a group encryption key to keep messages
private in the communication group; adjusting, using at least in a
part a notification from the first receiver, the delivery address
from corresponding to the second digital address to corresponding
to a third digital address, the third digital address associated
with a second receiver; and updating the token to form an updated
token to identify the second receiver and to invite the second
receiver to join the communication group to message and receive the
package at the delivery address using the updated token and a chain
of authorization including the first receiver and the second
receiver.
18. The method of claim 17, further including generating the second
digital address from a physical address using the at least one
encryption key.
19. The method of claim 17, wherein the at least one encryption key
includes a private encryption key, a private signing key, a public
encryption key, and a public signing key, and further including
verifying the second receiver using the at least one encryption
key.
20. The method of claim 17, further including facilitating
communication of messages in the communication group to be verified
using a nonce word and a digital signature.
21. The method of claim 17, further including manage confirmation
of receipt of the package based on verification of the updated
token.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This patent arises from U.S. Non-Provisional patent
application Ser. No. 16/023,892, which was filed on Jun. 29, 2018.
U.S. Non-Provisional patent application Ser. No. 16/023,892 is
hereby incorporated herein by reference in its entirety. Priority
to U.S. Non-Provisional patent application Ser. No. 16/023,892 is
hereby claimed.
FIELD OF THE DISCLOSURE
[0002] This disclosure relates generally to secure shipment receipt
coordination, and, more particularly, to a secure shipment receive
apparatus and associated methods for secure shipment receipt
coordination.
BACKGROUND
[0003] Traditionally, packaging and courier delivery service either
drops-off a package outside a delivery address or executes multiple
attempts to deliver the package when a receiver's signature is
needed. If the receiver cannot be at the delivery address during
delivery time and wishes to change the delivery address of
time-sensitive, information-sensitive, and/or otherwise valuable
shipment, then major courier services in United States provide an
option to contact a sender of the package and ask the sender to
assign a new delivery address.
[0004] However, with existing solutions, when the receiver is
unable to be at home to receive a shipment, involving the sender to
change the delivery address is not only cumbersome but also
introduces logistic problems when the shipment is from an online
shopping platform. Additionally, for packages that require the
receiver's signature, changing the delivery address option is not
offered by major courier services. As a result, the receiver must
either "be at home" or pick up the package from a local
distribution center. Both options may not work in some situations
such as an unplanned international trip, leading to a huge
inconvenience for the receiver. Further, no verification is done
for the receiver. For example, prior systems accept a signature
from anyone opening the door without checking a form of receiver's
identification. A more assertive mechanism is needed in a public
environment to deliver the package to the appropriate receiver.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] FIG. 1 shows an example of a shipment coordination
system.
[0006] FIGS. 2-6 illustrate flow diagrams representative of example
machine readable instructions that can be executed to implement the
example system of FIG. 1.
[0007] FIG. 7 is a schematic illustration of an example processor
platform that can execute the instructions of FIGS. 2-6 to
implement the example system of FIG. 1.
[0008] FIG. 8 illustrates an example domain topology for respective
internet-of-things (IoT) networks coupled through links to
respective gateways.
[0009] FIG. 9 illustrates a cloud computing network in
communication with a mesh network of IoT devices operating as a fog
device at the edge of a cloud computing network.
DETAILED DESCRIPTION
[0010] In the following detailed description, reference is made to
the accompanying drawings that form a part hereof, and in which is
shown by way of illustration specific examples that may be
practiced. These examples are described in sufficient detail to
enable one skilled in the art to practice the subject matter, and
it is to be understood that other examples may be utilized and that
logical, mechanical, electrical and/or other changes may be made
without departing from the scope of the subject matter of this
disclosure. The following detailed description is, therefore,
provided to describe example implementations and not to be taken as
limiting on the scope of the subject matter described in this
disclosure. Certain features from different aspects of the
following description may be combined to form yet new aspects of
the subject matter discussed below.
[0011] When introducing elements of various embodiments of the
present disclosure, the articles "a," "an," "the," and "said" are
intended to mean that there are one or more of the elements. The
terms "comprising," "including," and "having" are intended to be
inclusive and mean that there may be additional elements other than
the listed elements.
[0012] Certain examples provide systems and associated methods for
improved package shipment, tracking, and dynamic adjustment.
Certain examples enable electronic package sign-off to provide a
stronger way to approve, authorize, and/or vouch for package
delivery.
[0013] In certain examples, a receiver of time-sensitive,
information-sensitive, and/or otherwise valuable shipment can
delegate receiving and/or signing authority to another by changing
the delivery address without involving a sender of the shipment. In
prior systems, any change in delivery address for a
signature-required package must involve the sender and often may
not be permissible after the package has been shipped. Certain
examples enable dynamic adjustment of delivery address, signatory
authority, and/or other delivery parameter by the recipient without
requiring participation and/or authorization of the sender. The
dynamic adjustment can be secured through use of a communication
group with encryption, tokens, and a ledger of transactions or
changes, for example.
[0014] Certain examples provide a system that does not need central
trust authority to authenticate a receiver of a package. The
receiver of the package can be authenticated using a digital
address (DA) presented by a sender at a time of shipment initiation
along with a physical address (PA). The sender of the shipments
verifies both DA and PA. The DA links secure encryption keys to the
verified PA, so a central trust authority is not needed to
authenticate the receiver.
[0015] In certain examples, identity and evolution of the receiver
can be tracked via a ledger or a chain of authorization from an
original receiver to an actual receiver of a package being shipped.
The chain (also referred to herein as a "delegation-chain") can be
used to audit, verify, and authorize receiver(s) and track a
progression of receivers if shipment breaks down, receipt is not
verified, fraudulent receipt is detected, etc. Certain examples
provide the delegation-chain to authenticate chain of custody in
the delivery process.
[0016] In certain examples, a package can be equipped with a low
power (LP) tag (e.g., a Bluetooth Low Energy (BLE) tag, radio
frequency identification (RFID) tag, other radio tag, etc.), that
embeds the DA for delivery and PA and/or DA verification. Such a
package and associated tracking systems and methods provide
improved security of prior package tracking and delivery systems
and methods, for example. Such a package and associated tracking
systems and methods also reduce delivery time.
[0017] In contrast, prior systems and methods require involvement
of the sender to reroute a package. Additionally, the receiver is
not verified when delivering a package that is to include signature
confirmation. Rerouting of packages needing signature conformation
is not possible without involving the sender in prior systems and
associated methods.
[0018] Further, in-home delivery presents privacy and trust issues.
For example, people may not feel comfortable giving home access to
a shipment company or allowing a delivery driver to enter their
unattended home.
[0019] In certain examples, when the receiver is unable to
personally be at home to either sign-off for the shipment delivery
or to receive a time-sensitive, information-sensitive, and/or
valuable shipment, alternatives are provided. For example, a
recipient can electronically sign off and/or otherwise approve to
leave a package outside a door. Alternatively or in addition, the
recipient can designate a delegate at the same and/or different
location without involvement of the sender and authorize the
delegate to receive and sign for the package. Senders and receivers
can send and/or receive packages from any point on the globe to any
other point on the globe, for example.
[0020] Certain examples provide an apparatus and associated methods
including secure shipment reception with delegation chain. In
operation, the example apparatus facilitates registration of sender
and receiver with a shipping company system. The sender can then
initiate secure delivery of a package using the apparatus. The
receiver provides proof that he/she/it is an authorized receiver to
a delivery person/device and/or delegates receipt of shipment to
someone/something else.
[0021] FIG. 1 illustrates an example shipment coordination system
100 including a shipping group coordinator 110, a register 115, an
address generator 120, a shipment tracker 130, a change processor
140, and a verification engine 150. The example shipment
coordination system 100 communicates with a shipping company server
160 and one or more delivery acknowledgement devices 170, for
example. In certain examples, the shipment coordination system 100
is included in the shipping server 160.
[0022] In certain examples, a sending application 180 and a
receiving application 190 each register a digital address (DA)
corresponding to a physical address (PA) associated with the sender
and receiver, respectively, with the register/data storage 115. For
example, the sending application 180 and/or the receiving
application 190 enters a PA, such as a postal address, a what3words
location descriptor, a naviaddress, other locator, etc., into the
address generator 120. The address generator 120 transforms the PA
into a DA using, for example, an encrypted hash of the PA. The DA
is associated with the PA and is stored in the register 115.
[0023] For example, suppose E represents an encryption function,
SHA512 is a 64-byte hash function, SHA256 is a 32-byte hash
function, Base-64 is a Base-64 encoding function, and Se is a
Private encryption key. Then the DA can be calculated as
follows:
[0024] E{PA}Se=>EPA
[0025] SHA512{EPA}=>H64 [0026]
(DD8C62158BB994000C74F80BDB021F245F5B25CB5EB3F
7E7C4E0441311AEDEF127351E6411D29E39E34A9C386206
DB61D58B525B82B21B5F149646B12870DD56)
[0027] SHA256{H64}=>H32 [0028]
(68ab11f3e67b4ac1b0d1f6662089b6f208e81c30830d87ca624b
9311a2222fc1)
[0029] DA=base64 {H32}
[0030] NjhhYjExZjNlNjdiNGFjMWIwZDFmNjY2MjA4OWI2ZjIwOGU4M
[0031] WMzMDgzMGQ4N2NhNj I0Yj kzMTFhMj IyMmZj MQ==
In the example above, a private encryption key is used to generate
the DA as well as to verify the encryption keys, which eliminates a
need for a central trusted authority to generate and verify a DA
from a PA. The PA is encrypted and then hashed to generate a 64-bit
hash. The 64-bit hash is hashed to generate a 32-bit hash, which is
then converted to base-64 to provide the DA.
[0032] In certain examples, to address multiple authorized
receivers at the same PA (e.g., a corporate office, dormitory,
etc.), the address generator 120 can generate the same DA for a
given PA on different devices associated with different users using
deterministic public/private key generation from a passphrase. Each
user that is registered has its own signing keys to distinguish
between different receivers at the same PA, for example.
[0033] When a sender initiates a secure delivery, the shipment
coordination system 100 initiates delivery instructions and/or
parameters for delivery of a package to an intended receiver. For
example, the sending application 180 receives input parameters for
the package and presents a PA and DA associated with the sender
along with a PA and DA associated with the receiver to the register
115. The register 115 can include and/or be associated with an
application on the shipping server 160, for example. The sending
application 180, alone or in conjunction with the receiving
application 190, triggers creation of a secure group and a
proof-of-authorized-receiver token. The token can be used to
identify the correct receiver of a shipment, for example.
[0034] Once the sender and receiver PA/DA have been input into the
system 100, the verification engine 150 verifies whether the sender
and receiver PA and DA are stored in the register 115. If one or
both the sender and receiver do not have a PA/DA pair in the
register 115, then the register 115 and address generator 120 work
to add the missing information to the register 115. If both the
sender and receiver are in the register 115, then the shipping
group coordinator 110 creates a secure group for the shipment. The
secure group has a group encryption key (Ge) and a
proof-of-authorized-receiver token (T). For example, the token is a
light-weight JavaScript Object Notation (JSON) Web token
identifying the receiver of the shipment. For example, a JSON Web
token can be represented as follows:
TABLE-US-00001 { ''recv'': ''1234567'', //receiver Id ''name'':
''John Doe'', ''exp'': 1426420800 }
[0035] The shipping group coordinator 110 can register sender and
receiver and initiate delivery instructions and/or delivery
parameters for a package. For example, the shipping group
coordinator 110 sends a digitally signed invitation to both sender
(e.g., sending application 180) and receiver (e.g., receiving
application 190) to join the group (G), for example. The sending
application 180 and receiving application 190 verify a digital
signature of the invitation to join the group (G), for example.
[0036] The shipping group coordinator 110 then requests public keys
from the sending application 180 and the receiving application 190.
The sending application 180 and the receiving application 190 share
message(s) including their DA, encrypted PA (E{PA}se), public
encryption key (Pe), and public signing key (Ps) along with a nonce
word representing a freshness of the message and the digital
signature, for example. The verification engine 150 works with the
shipping group coordinator 110 to verify the keys corresponding to
each DA and save the keys in the register 115, for example. The
shipping group coordinator 110 digitally signs and encrypts the
token (T) and the group encryption key (Ge) and sends the token and
key to the sending application 180 and the receiving application
190. Messages exchanged in the group (G) are encrypted using the
group encryption key (Ge), for example.
[0037] A receiver then provides (e.g., via the receiving
application 190 on a delivery acknowledgement device 180 such as a
tablet computer, smartphone, etc.) proof-of-authorized-receiver to
a delivery person, device, etc., and/or delegates shipment receipt
to someone else. For example, the receiver is present at home
and/or other target delivery location and electronically presents
the token (T) to the delivery person/device as a
"Proof-of-Authorized-Receiver". The delivery person/device verifies
the token (e.g., using the verification engine 150 and/or register
115, etc.), accepts the digital signature of the receiver, and
delivers an associated package to the receiver. Thus, the delivery
acknowledgement device 180 and/or the receiving application 190
provide receipt confirmation associated with delivery of the
package to an authorized receiver at the target address based on
verification of the token and the digital signature of the
receiver, for example.
[0038] In another example, the receiver is not present at the
target delivery location (e.g., home, work, school, etc.) and
shares the token with the delivery person/device remotely via a
cloud service. The receiver then authorizes the delivery
person/device to leave the package outside the target delivery
location by digitally signing for the package.
[0039] In another example, the receiver is not present at the
target PA delivery location (e.g., home, work, school, etc.) to
receive delivery and delegates someone else to receive the package
by changing the delivery address of the shipment. For example, the
receiver informs the group that it wishes to delegate receiving of
the shipment to someone else by providing the delegate PA and DA to
the change processor 140 as a new shipment address. The
verification engine 150, alone or in conjunction with the shipping
server 160, verifies the delegate PA and DA and updates the JSON
Web Token with the new receiver information. The shipping group
coordinator 110 invites the receiving application 190 associated
with the new receiver to join the group. The new receiving
application 190 joins the group and share its keys with the
shipping group coordinator 110. The shipping group coordinator 110,
alone or in conjunction with the verification engine 150, verifies
the keys shared by the new receiving application 190 for a
corresponding DA and saves them in its database. The shipping group
coordinator 110 then shares the new token with the group and group
key with the new receiving application 190. The updated receiving
application 190 facilitates acknowledgement/confirmation of receipt
of the shipment as the original receiver would have as outlined
above.
[0040] Thus, an original intended receiver can delegate or specify
an alternate receiver. Rather than withholding delivery of the
package, the shipping server 160 works with the shipment
coordination system 100 to facilitate update and delivery to an
authorized actual receiver who is different than the original,
intended receiver, for example.
[0041] In certain examples, a tracking and/or identification
device, such as a BLE tag, RFID tag, other LP tag, etc., can be
placed on and/or embedded in a package to be shipped. The tag can
be used for sensing, computing, and/or communication with respect
to the package, for example. The tag can be used to track shipment
(e.g., track a high-value shipment, etc.), monitor an environmental
condition (e.g., temperature and/or humidity of perishables,
medicine, etc.), sense vibration, determine orientation, etc. In
certain examples, tags can be used to enable chain-of-custody to
show a chronological audit trail of custody, control, and transfer
of a package, etc.
[0042] The tag can be provisioned with the DA of sender and
receiver, for example, which enables the shipment tracker 130 to
verify that the receiver is getting the intended package (e.g., by
comparing the receiver DA information of a recipient and the tag,
etc.). If the receiver is changed during shipment, the receiver DA
on the tag can be updated (e.g., by the change processor 140 in
communication with the shipment tracker 130, shipping server 160, a
gateway, etc.). For example, when a package traverses multiple
intermediate shipping companies, the intermediate DAs are included
in the tag, and each time a shipper transfers custody to another
shipper, the DA on the tag is compared to the receiver DA for
verification and tracking.
[0043] In certain examples, the sender and/or receiver can
dynamically change their PA (e.g., referred to as a "follow-me" use
case). For example, a receiver may wish to have a package delivered
while she is at work or at a flea market. The sender can re-route
deliveries efficiently using drivers, robots, drones, and/or other
autonomous delivery vehicle. The receiving application 190 can
broadcast a dynamic PA by computer E{PA'}Se, where PA' is a revised
delivery target, for example. In certain examples, given that the
token (T) exists, the Web token (T) can be used to efficiently
broadcast the revised PA' by computing E{PA'}Ge or E{PA', Nonce}GE,
etc., if a replay attack is a concern.
[0044] A most current location can then be saved in the register
115, shipping server 160 database, etc., as the receiver DA, for
example. The most current location is used to inform delivery
vehicle(s) regarding intended receiver location. In certain
examples, where the PA is other than a postal address, such as
What-Three-Words address, etc., the package can be delivered to any
geographical location with one-meter accuracy, even if there are no
defined postal addresses. Thus, the receiver can receive timely
deliveries regardless of location, choice of activity, etc.
[0045] In certain examples, a blockchain can be used to create an
immutable log of dynamic "follow-me" addresses. Blockchain
technology is a distributed computing mechanism designed to provide
a degree of fairness such that one entity is not advantaged while
another entity is disadvantaged. A blockchain is a distributed,
public ledger of transactions (e.g., financial transactions, data
transactions, etc.) in which the transactions are recorded publicly
and chronologically and can be verified by participants without a
central authority. Blockchain applies cryptographic algorithms to a
shared or distributed database to allow any user to read the
database, add to the database, and to help ensure no single user
can control what is written to the distributed database. Any
blockchain user can view all transactions with respect to the
distributed database. Blockchain technology provides
disintermediation to reduce intermediaries in communication between
data producers and data consumers, for example. That is, rather
than engaging a middleman to facilitate a transaction, two entities
(e.g., a data consumer and a data supplier) can connect and engage
in a transaction directly. Other entities can see the transaction,
so the blockchain serves as a distributed consensus engine for the
entities to verify and/or otherwise agree to the existence of the
transaction.
[0046] In blockchain-based technology, a log of transactions is
processed by a distributed system of message brokers. The message
brokers are a set of distributed entities that agree on a present
state of transaction processing and a historical state of
transaction processing. A transaction processing log is protected
with a cryptographic hash, for example, and each broker has a copy
of the transaction processing log. The blockchain of distributed
entities also provides an algorithm to synchronize processing of
each transaction. Synchronized processing helps to ensure fairness
among brokers.
[0047] For example, when an entity seeks to add information to the
blockchain, participating entities, which all have copies of the
existing blockchain, run algorithms to evaluate and verify the
proposed addition (e.g., the proposed transaction). If a majority
of participating entities agree that the addition is valid (e.g.,
matches the blockchain's history, etc.), then the addition becomes
a new block in the blockchain, viewable by the participating
entities. A copy of the updated blockchain is conveyed to each
participating entity so each entity can see the transaction and has
an up-to-date copy of the blockchain log of transactions.
[0048] The shipping server 160 and/or shipping coordination system
100 commits DAs to the blockchain and/or other digital ledger, for
example, to protect sender and receiver privacy, but any
participant can, in an appropriate legal context, disclose the Ge
or Se values to reveal actual physical addresses, for example.
Blockchain DA values can be used to establish a sequence of
"follow-me" addresses (e.g., a chain of authorization) for delivery
sign-off requirements, checkpoint requirements, etc.
[0049] While an example implementation of the shipment coordination
system 100 is illustrated in FIG. 1, one or more of the elements,
processes and/or devices illustrated in FIG. 1 can be combined,
divided, re-arranged, omitted, eliminated and/or implemented in any
other way. Further, the example shipping group coordinator 110, the
example register 115, the example address generator 120, the
example shipment tracker 130, the example change processor 140, the
example verification engine 150, and/or, more generally, the
example shipment coordination system 100 of FIG. 1 can be
implemented by hardware, software, firmware and/or any combination
of hardware, software and/or firmware. Thus, for example, any of
the example shipping group coordinator 110, the example register
115, the example address generator 120, the example shipment
tracker 130, the example change processor 140, the example
verification engine 150, and/or, more generally, the example
shipment coordination system 100 of FIG. 1 can be implemented by
one or more analog or digital circuit(s), logic circuits,
programmable processor(s), application specific integrated
circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)) and/or
field programmable logic device(s) (FPLD(s)). When reading any of
the apparatus or system claims of this patent to cover a purely
software and/or firmware implementation, at least one of the
example shipping group coordinator 110, the example register 115,
the example address generator 120, the example shipment tracker
130, the example change processor 140, the example verification
engine 150, and/or, more generally, the example shipment
coordination system 100 of FIG. 1 is/are hereby expressly defined
to include a non-transitory computer-readable storage device or
storage disk such as a memory, a digital versatile disk (DVD), a
compact disk (CD), a Blu-ray disk, etc. including the software
and/or firmware. Further still, the example shipment coordination
system 100 of FIG. 1 can include one or more elements, processes
and/or devices in addition to, or instead of, those illustrated in
FIG. 1, and/or may include more than one of any or all of the
illustrated elements, processes and devices.
[0050] Flowcharts representative of example machine readable
instructions for implementing the example shipment coordination
system 100 of FIG. 1 are shown in FIGS. 2-6. In these examples, the
machine-readable instructions include a program for execution by a
processor such as a processor 712 shown in the example processor
platform 700 discussed below in connection with FIG. 7. The program
can be embodied in software stored on a non-transitory computer
readable storage medium such as a CD-ROM, a floppy disk, a hard
drive, a DVD, a Blu-ray disk, or a memory associated with the
processor 712, but the entire program and/or parts thereof can
alternatively be executed by a device other than the processor 712
and/or embodied in firmware or dedicated hardware. Further,
although the example program is described with reference to the
flowcharts illustrated in FIGS. 2-6, many other methods of
implementing the example shipment coordination system 100 of FIG. 1
can alternatively be used. For example, the order of execution of
the blocks may be changed, and/or some of the blocks described can
be changed, eliminated, or combined. Additionally or alternatively,
any or all of the blocks can be implemented by one or more hardware
circuits (e.g., discrete and/or integrated analog and/or digital
circuitry, a Field Programmable Gate Array (FPGA), an Application
Specific Integrated circuit (ASIC), a comparator, an
operational-amplifier (op-amp), a logic circuit, etc.) structured
to perform the corresponding operation without executing software
or firmware.
[0051] As mentioned above, the example processes of FIGS. 2-6 can
be implemented using coded instructions (e.g., computer and/or
machine readable instructions) stored on a non-transitory computer
and/or machine readable medium such as a hard disk drive, a flash
memory, a read-only memory, a CD, a DVD, a cache, a random-access
memory and/or any other storage device or storage disk in which
information is stored for any duration (e.g., for extended time
periods, permanently, for brief instances, for temporarily
buffering, and/or for caching of the information). As used herein,
the term non-transitory computer readable medium is expressly
defined to include any type of computer readable storage device
and/or storage disk and to exclude propagating signals and to
exclude transmission media. "Including" and "comprising" (and all
forms and tenses thereof) are used herein to be open ended terms.
Thus, whenever a claim lists anything following any form of
"include" or "comprise" (e.g., comprises, includes, comprising,
including, etc.), it is to be understood that additional elements,
terms, etc., can be present without falling outside the scope of
the corresponding claim. As used herein, when the phrase "at least"
is used as the transition term in a preamble of a claim, it is open
ended in the same manner as the term "comprising" and "including"
are open ended.
[0052] Example machine readable instructions for implementing the
shipment coordination system 100 of FIG. 1 and that can be executed
to manage package shipment and delivery are illustrated in FIGS.
2-6. With reference to the preceding figures and associated
descriptions, the example machine readable instructions 200 to
manage package shipment and delivery begin at block 202.
[0053] At block 202, a sender and receiver register for shipment
with the shipment coordination system 100. For example, the
shipping group coordinator 110 and the register 115 work with the
address generator 120 to generate a DA for each PA provided to the
system 100 (e.g., a shipping PA and a receiving PA, etc.). For
example, encrypted, hashed DA values can be formed by the address
generator 120 from address information such as a postal address, a
What-Three-Words address, a naviaddress, and/or other geographic
locator and stored with the register 115. In certain examples, a PA
having multiple potential receivers can employ a DA with a
different signing key associated with each receiver at that DA.
[0054] At block 204, a secure delivery of a shipment is initiated.
For example, a sender uses the sending application 180 to initiate
secure shipment of a package. For example, the sending application
180 provides PA and DA of the sender and receiver to the shipment
coordination system 100 to trigger verification by the verification
engine 150 and generation of a secure shipping group by the
shipping group coordinator 110. The sending application 180 and
receiving application 190 then have a group encryption key (Ge) to
use when communicating regarding the shipment, for example. The
shipping group coordinator 110 initiates generation of delivery
instructions/parameters for delivery of the shipment to the PA of
the receiver.
[0055] At block 206, receipt of the shipment is managed. For
example, the receiving application 190 can leverage a delivery
acknowledgement device 170, in person and/or remotely via a network
such as "the cloud", to verify a token (T) as a proof of authorized
receiver. Alternatively, the change processor 140 can work with the
receiving application 190 and/or the delivery acknowledgement
device 170 to invite a new receiver to the group (e.g., via the
shipping group coordinator 110) and confirm delivery and receipt of
the shipment to the new receiver at a new delivery address (e.g.,
using the address generator 120 and shipment tracker 130) by
verifying the token (T), for example.
[0056] Thus, physical addresses, digital addresses, sender, and
recipient(s) can be associated using public/private key association
with a group for communication and token verification. All members
of the group have access to the token and communication within the
group occurs in association with the token. Any member of the group
can change an address, delegate a new receiver, etc., using the
token. The token may be modified, re-generated, etc., when a
receiver is added and/or subtracted from the group, for
example.
[0057] In certain examples, sender and receiver can be identified
using a self-sovereign identity rather than relying on a shipping
company and/or other external source for identification. For
example, a sender and/or receiver can self-assert an identity and
use a blockchain to establish properties of their identity to
assert uniqueness of that identity. Key(s) can be associated with
the self-sovereign identity as well to allow members of the
shipping communication group to verify and communicate with each
other, for example.
[0058] In certain examples, exchange of data flows can be viewed as
transactions and can be placed in a ledger to track and be used in
an audit. For example, a ledger and blockchain can be used to track
who did what when, what keys were used, etc., to monitor (e.g.,
using the shipment tracker 130) the status and progress of a
shipment, etc.
[0059] In certain examples, a shipping company hosts the shipping
server 160 and an associated service providing the shipment
coordination system 100. Interaction between a sender and
receiver(s) goes through the shipping server 160, and each sender
and receiver has an application/user interface such as the sending
application 180, receiving application 190, etc. Proof of
authorized receiver is provided to a delivery person/device to
complete the shipment cycle for the shipping communication
group.
[0060] FIG. 3 illustrates a flow diagram representing example
machine readable instructions to facilitate registration for
shipment (e.g., block 202 of the example method of FIG. 2). At
block 302, a PA is determined for the sender or receiver. For
example, a postal address, what-three-words address, naviaddress,
and/or other geolocation is provided to the address generator
120.
[0061] At block 304, keys are generated from the PA. For example,
the address generator 120 generates public/private encryption keys
and signing keys (Pe, Ps, Se, Ss) associated with the PA.
[0062] At block 306, a DA is generated for the PA. For example, the
address generator 120 employs an encryption function (E), which
uses a hash function (e.g., SHA512, SHA256, etc.) and an encoding
function (e.g., Base-64, etc.) to generate a DA corresponding to
the input PA.
[0063] At block 308, the DA is registered with the register 115 so
that the shipping group coordinator 110 can associate the DA with a
shipment, for example. In certain examples, the private encryption
key used to generate the DA can be used to verify the encryption
keys, and an entity associated with the DA receives a signing key
for its communication. If multiple receivers are at a same DA, each
receiver can be associated with its own signing key to
differentiate among the receivers at the DA, for example.
[0064] FIG. 4 illustrates a flow diagram representing example
machine readable instructions to facilitate registration for
shipment (e.g., block 204 of the example method of FIG. 2). At
block 402, the PA and DA associated with the sender and receiver
are verified. For example, the shipping group coordinator 110
verifies that both the sender and receiver have a PA and DA saved
in the register 115. If the sender or receiver does not have a
PA/DA pair in the register 1115, then, at block 404, the PA and DA
are registered with the shipment coordination system 100 and stored
in the register 115. For example, the DA is generated from the PA
and stored in the register 115 as disclosed above with respect to
FIGS. 1-3.
[0065] At block 406, a shipping communication group is created for
the sender and receiver by the shipping group coordinator 110. The
group (51) is created for the particular shipment, for example. The
shipping group coordinator 110 creates a group encryption key (Ge)
for group communication. The group encryption key can be used by
sending application 180, receiving application 190, and shipping
server 160 to communicate regarding PA, DA, changes in PA/DA,
change in authorized receiver, shipment/delivery status, other
delivery instructions/parameters, receipt confirmation, etc. At
block 408, the shipping group coordinator 110 generates a token (T)
for the group (51) which serves as proof of authorized receiver for
the shipment. Thus, the shipping group coordinator 110 facilitates
messaging between the sender and the receiver in the group by
providing a channel for message communicates within the group as
well as the encryption key to help ensure only authorized group
members can read and process the messages. Non-group members
without the key Ge are unable to read and act on the messages and
message content.
[0066] At block 410, the shipping group coordinator 110 verifies
the sender and receiver to join the group (S1). For example, the
shipping group coordinator 110 verifies a DA, encrypted PA, public
encryption key, public signing key, nonce word, and digital
signature from each sender and/or receiver for the group (S1) and
saves the information to the register 115. For example, for a
message (M) to be signed, the message (M) can be encoded as
H32=SHA256 (M) using hash function SHA256. The digital signature
can then be generated by Digital Signature=E{H32}Ss, which provides
an encrypted one-way hash using a signing key (Ss), for
example.
[0067] At block 412, the token (T) and group encryption key (Ge)
are sent by the shipping group coordinator 110 to the sender and
receiver to enable communication and authorization in relation to
the shipment. For example, the shipping group coordinator 110 sends
the group encryption key (Ge) encrypted by the public encryption
key (Pe) in conjunction with the token (T) encrypted by the group
encryption key (Ge), a nonce word to verify freshness of the
message, and a digital signature to the sender and receiver. The
sending application 180 and receiving application 190 verify the
digital signature from the shipment coordination system 100 and
decrypt and save the group encryption key (Ge) and the token (T).
The applications 180, 190 can use the group encryption key (Ge) in
message exchange in the group via the shipping group coordinator
110 and can use the token (T) to provide proof of authorized
recipient to the receiving application 190 and/or delivery
acknowledgement device 170 for confirmation of package
delivery/receipt by an authorized receiver, for example.
[0068] FIG. 5 illustrates a flow diagram representing example
machine readable instructions to verify a sender and/or receiver
for a shipping communication group (e.g., block 410 of the example
method of FIG. 4). At block 502, the shipping group coordinator 110
sends an invitation to the sender and/or receiver to join the group
(S1). For example, the shipping group coordinator 110 transmits an
invitation message to the sending application 180 and/or the
receiving application 190. The example process occurs equivalently
for the sender and the receiver to verify and join the group
(S1).
[0069] At block 504, the shipping group coordinator 110 verifies
key information from the invitee (e.g., the sender or receiver).
For example, in response to the invitation from the shipping group
coordinator 110, the sender/receiver acknowledges the invitation
upon verifying the coordinator's digital signature and responds by
sending its public encryption key and public signing key with DA to
the shipping group coordinator 110 for verification. For example,
the invitee can transmit a message including the DA with encrypted
PA (E{PA}Se), public encryption key (Pe), public signing key (Ps),
nonce word, and digital signature to the shipping group coordinator
110 for group (S1).
[0070] At block 506, registration information is saved for the
invitee. For example, the shipping group coordinator 110 verifies
that the public encryption key (Pe) and public signing key (Ps)
correspond to the DA and saves the keys (Pe, Ps) in the register
115, for example.
[0071] At block 508, the invitee is accepted into the group by the
shipping group coordinator 110. For example, the shipping group
coordinator 110 adds the sender and/or receiver to the group (S1)
and sends a message (e.g., returning to block 412) including the
group encryption key (Ge) encrypted using the public encryption key
(Pe) (e.g., E{Ge}Pe) with the token (T) encrypted using the group
encryption key (Ge) (e.g., E{T}Ge), a nonce word, and a digital
signature. The sending application 180 and/or the receiving
application 190 verifies the digital signature and decrypts and
saves the token (T), for example.
[0072] FIG. 6 illustrates a flow diagram representing example
machine readable instructions to verify keys with respect to the
digital address (e.g., block 504 of the example method of FIG. 5).
At block 602, key information is received. For example, the
shipping group coordinator 110 receives a message including the DA,
Encrypted PA (E{PA}se), Public Encryption Key (Pe), and Public
Signing Key (Ps) along with a Nonce to verify the freshness of the
message and a digital signature to verify the source of the
message.
[0073] At block 604, the nonce word is examined to verify that the
message is not a replay or tempered message. If the message is a
replay (e.g., is repeated or has already been processed), then the
process ends as the message has already been handled. Otherwise,
control proceeds to block 606 to associate the public encryption
key with a private key (e.g., by decrypting (D) of
D{E{PA}Se}Pe=>PA). At block 608, the DA corresponding to the PA
is associated with the public encryption key. For example, the PA
can be processed to identify and associate the DA with the public
encryption key as follows:
[0074] SHA512{E{PA}Se}=Hash64
[0075] SHA256{Hash64}=Hash32
[0076] Base64{Hash32}=>DA
Thus, a 64-byte hash function is applied to the encrypted PA with
the private encryption key, and the result is provided to a 32-byte
hash function, which is then encoded with a base-64 encoding
function to produce the DA, for example. In certain examples, if a
first receiver delegates receiving authority to a second receiver,
an updated DA can be generated to include the second receiver in
the group with authorization and delivery information. At block
610, the register 115 is updated with the PA, DA, public encryption
key (Pe), public signing key (Ps), etc. In certain examples, a
chain of receivers can be maintained in the register 115.
[0077] At block 612, the group encryption key (Ge) is generated.
For example, the shipping group coordinator 110 generates the group
encryption key (Ge) based on the sender and receiver information
for the group. At block 614, the group encryption key (Ge) is sent
to the members of the group (e.g., the sending application 180, the
receiving application 190, the shipping server 160, etc.). For
example, the shipping group coordinator 110 sends the group
encryption key (Ge) encoded by the public encryption key (Pe)
(e.g., E{Ge}Pe) and the token (T) encrypted by the group encryption
key (Ge) (e.g., E{T}Ge), along with a nonce word and digital
signature to members of the group.
[0078] At block 616, the group is updated with the current DA and
public signing key (Ps). For example, the shipping group
coordinator 110 updates the group (S1) by broadcasting to group
members (e.g., the sending application 180, the receiving
application 190, the shipping server 160, etc.) the DA, Ps, nonce
word, and digital signature.
[0079] Thus, certain examples provide a shipment coordination
system with a shipping group coordinator to
enable/provide/facilitate initiation of delivery instructions
and/or other setting of delivery parameters (e.g., target PA and
associated DA, identity of authorized receiver, token information,
group messaging key information, etc.) to trigger delivery of a
shipment to an authorized receiver. The shipping group coordinator
establishes a group including sender and receiver and helps ensure
that the sender and receiver can message each other via the
shipping group coordinator using a group encryption key to help
ensure privacy and targeted delivery to its intended recipient(s)
(e.g., shipping application 180, receiving application 190,
shipping server 160, delivery acknowledgment device 170, etc.). The
shipping group coordinator can facilitate messaging by providing
the group encryption key as well as a channel/conduit/medium/etc.
for exchange of messages among the group members, for example. The
group encryption key can be used to verify that a message received
by an application or device is intended for that application/device
and can be read and/or otherwise processed by the
application/device as a member of the group, for example.
[0080] FIG. 7 is a block diagram of an example processor platform
700 capable of executing the instructions of FIGS. 2-6 to implement
the systems of FIG. 1. The processor platform 700 can be, for
example, a server, a personal computer, a mobile device (e.g., a
cell phone, a smart phone, a tablet such as an iPad.TM.), a
personal digital assistant (PDA), an Internet appliance, a DVD
player, a CD player, a digital video recorder, a Blu-ray player, a
gaming console, a personal video recorder, a set top box, or any
other type of computing device.
[0081] The processor platform 700 of the illustrated example
includes a processor 712. The processor 712 of the illustrated
example is hardware. For example, the processor 712 can be
implemented by one or more integrated circuits, logic circuits,
microprocessors or controllers from any desired family or
manufacturer. In the illustrated example, the processor 712 is
structured to include the example shipment coordination system 100
including the example shipping group coordinator 110, the example
register 115, the example address generator 120, the example
shipment tracker 130, the example change processor 140, the example
verification engine 150, etc.
[0082] The processor 712 of the illustrated example includes a
local memory 713 (e.g., a cache). The processor 712 of the
illustrated example is in communication with a main memory
including a volatile memory 714 and a non-volatile memory 716 via a
bus 718. The volatile memory 714 may be implemented by Synchronous
Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory
(DRAM), RAMBUS Dynamic Random Access Memory (RDRAM), 3D XPoint
(such as Intel Optane.TM., Micron QuantX.TM., etc.) and/or any
other type of random access memory device. The non-volatile memory
716 may be implemented by flash memory and/or any other desired
type of memory device. Access to the main memory 714, 716 is
controlled by a memory controller.
[0083] The processor platform 700 of the illustrated example also
includes an interface circuit 720. The interface circuit 720 may be
implemented by any type of interface standard, such as an Ethernet
interface, a universal serial bus (USB), and/or a peripheral
component interconnect (PCI) express interface.
[0084] In the illustrated example, one or more input devices 722
are connected to the interface circuit 720. The input device(s) 722
permit(s) a user to enter data and commands into the processor 712.
The input device(s) 722 can be implemented by, for example, an
audio sensor, a microphone, a keyboard, a button, a mouse, a
touchscreen, a track-pad, a trackball, isopoint and/or a voice
recognition system.
[0085] One or more output devices 724 are also connected to the
interface circuit 720 of the illustrated example. The output
devices 724 can be implemented, for example, by display devices
(e.g., a light emitting diode (LED), an organic light emitting
diode (OLED), a liquid crystal display, a cathode ray tube display
(CRT), a touchscreen, a tactile output device). The interface
circuit 720 of the illustrated example, thus, typically includes a
graphics driver card, a graphics driver chip or a graphics driver
processor. Shipping information, delivery instructions, package
tracking information, delivery status, receipt confirmation, etc.,
can be displayed and/or otherwise output via one or more output
devices 724, for example.
[0086] An output/display device 724 can be used with or as part of
the shipping server 160, the delivery acknowledgement device 170,
the sending application 180, and/or the receiving application 190
to display information regarding shipping/delivery parameters,
status, chain of authorization, PA/DA of sender and/or receiver,
receipt confirmation, etc. The display device can be an interactive
display device facilitating interaction by providing an output and
receiving an input (e.g., a touchscreen and/or keyboard/keypad
input, etc.) via the display device, such as the delivery
acknowledgement device 170 and/or a computing device executing the
sending application 180 and/or the receiving application 190, for
example.
[0087] The interface circuit 720 of the illustrated example also
includes a communication device such as a transmitter, a receiver,
a transceiver, a modem and/or network interface card to facilitate
exchange of data with external machines (e.g., computing devices of
any kind) via a network 726 (e.g., an Ethernet connection, a
digital subscriber line (DSL), a telephone line, coaxial cable, a
cellular telephone system, etc.).
[0088] The processor platform 700 of the illustrated example also
includes one or more mass storage devices 728 for storing software
and/or data. Examples of such mass storage devices 728 include
floppy disk drives, hard drive disks, compact disk drives, Blu-ray
disk drives, RAID systems, and digital versatile disk (DVD)
drives.
[0089] The coded instructions 732 of FIGS. 2-6 can be stored in the
mass storage device 728, in the volatile memory 714, in the
non-volatile memory 716, and/or on a removable tangible computer
readable storage medium such as a CD or DVD.
[0090] FIG. 8 illustrates an example domain topology for respective
internet-of-things (IoT) networks coupled through links to
respective gateways. In certain examples, the IoT involves a large
number of computing devices interconnected to each other and to the
Internet to provide functionality and data acquisition at very low
levels. Thus, as used herein, an IoT device may include a
semiautonomous device performing a function, such as sensing or
control, among others, in communication with other IoT devices and
a wider network, such as the Internet. For example, IoT devices can
include the delivery acknowledgement device 170, a tag associated
with a package to track the shipment in communication with the
shipment tracker 130, a device executing the sending application
180, a device executing the receiving application 190, etc. A
package delivery involving multiple transfers, for example, can
leverage a plurality of IoT devices in an IoT network to track
package location, current DA/PA, delegation chain of authorized
receiver(s), etc.
[0091] Often, IoT devices are limited in memory, size, or
functionality, allowing larger numbers to be deployed for a similar
cost to smaller numbers of larger devices. However, an IoT device
may be a smart phone, laptop, tablet, or PC, or other larger
device. Further, an IoT device may be a virtual device, such as an
application on a smart phone or other computing device. IoT devices
may include IoT gateways, used to couple IoT devices to other IoT
devices and to cloud applications, for data storage, process
control, and the like.
[0092] Networks of IoT devices may include commercial and home
automation devices, such as water distribution systems, electric
power distribution systems, pipeline control systems, plant control
systems, light switches, thermostats, locks, cameras, alarms,
motion sensors, and the like. The IoT devices may be accessible
through remote computers, servers, and other systems, for example,
to control systems or access data.
[0093] The future growth of the Internet and like networks may
involve very large numbers of IoT devices. Accordingly, in the
context of the techniques discussed herein, a number of innovations
for such future networking will address the need for all these
layers to grow unhindered, to discover and make accessible
connected resources, and to support the ability to hide and
compartmentalize connected resources. Any number of network
protocols and communications standards may be used, wherein each
protocol and standard is designed to address specific objectives.
Further, the protocols are part of the fabric supporting human
accessible services that operate regardless of location, time or
space. The innovations include service delivery and associated
infrastructure, such as hardware and software; security
enhancements; and the provision of services based on Quality of
Service (QoS) terms specified in service level and service delivery
agreements. As will be understood, the use of IoT devices and
networks, such as those introduced herein, present a number of new
challenges in a heterogeneous network of connectivity comprising a
combination of wired and wireless technologies. Components, such as
the system 100 and other components of FIG. 1, can be implemented
as devices in wireless communication, devices wired together and
transmitting instructions and data via connecting wires, and/or a
combination of wireless and wired connectivity, for example.
[0094] FIG. 8 provides a simplified drawing of a domain topology
that can be used for a number of IoT networks including IoT devices
804 (e.g., an example of the processor platform 1100, etc.), with
the IoT networks 856, 858, 860, 862, coupled through backbone links
802 to respective gateways 854. As discussed above with respect to
FIG. 7, a package delivery involving multiple transfers, for
example, can leverage a plurality of IoT devices 804 in IoT
network(s) 856-862 to track package location, determine current
DA/PA, verify a delegation chain of authorized receiver(s),
etc.
[0095] For example, a number of IoT devices 804 can communicate
with a gateway 854, and with each other through the gateway 854. To
simplify the drawing, not every IoT device 804, or communications
link (e.g., link 816, 822, 828, or 832) is labeled. The backbone
links 802 may include any number of wired or wireless technologies,
including optical networks, and may be part of a local area network
(LAN), a wide area network (WAN), or the Internet. Additionally,
such communication links facilitate optical signal paths among both
IoT devices 804 and gateways 854, including the use of
MUXing/deMUXing components that facilitate interconnection of the
various devices.
[0096] The network topology may include any number of types of IoT
networks, such as a mesh network provided with the network 856
using Bluetooth low energy (BLE) links 822. Other types of IoT
networks that may be present include a wireless local area network
(WLAN) network 858 used to communicate with IoT devices 804 through
IEEE 802.11 (Wi-Fi.RTM.) links 828, a cellular network 860 used to
communicate with IoT devices 804 through an LTE/LTE-A (4G) or 5G
cellular network, and a low-power wide area (LPWA) network 862, for
example, a LPWA network compatible with the LoRaWan specification
promulgated by the LoRa alliance, or a IPv6 over Low Power
Wide-Area Networks (LPWAN) network compatible with a specification
promulgated by the Internet Engineering Task Force (IETF). Further,
the respective IoT networks may communicate with an outside network
provider (e.g., a tier 2 or tier 3 provider) using any number of
communications links, such as an LTE cellular link, an LPWA link,
or a link based on the IEEE 802.15.4 standard, such as Zigbee.RTM..
The respective IoT networks may also operate with use of a variety
of network and internet application protocols such as Constrained
Application Protocol (CoAP). The respective IoT networks can also
be integrated with coordinator devices that provide a chain of
links that forms cluster tree of linked devices and networks.
[0097] Each of these IoT networks can provide opportunities for new
technical features, such as those as described herein. The improved
technologies and networks may enable the exponential growth of
devices and networks, including the use of IoT networks into as fog
devices or systems. As the use of such improved technologies grows,
the IoT networks may be developed for self-management, functional
evolution, and collaboration, without needing direct human
intervention. The improved technologies may even enable IoT
networks to function without centralized controlled systems.
Accordingly, the improved technologies described herein may be used
to automate and enhance network management and operation functions
far beyond current implementations.
[0098] In an example, communications between IoT devices 804, such
as over the backbone links 802, can be protected by a decentralized
system for authentication, authorization, and accounting (AAA). In
a decentralized AAA system, distributed payment, credit, audit,
authorization, and authentication systems may be implemented across
interconnected heterogeneous network infrastructure. This allows
systems and networks to move towards autonomous operations. In
these types of autonomous operations, machines may even contract
for human resources and negotiate partnerships with other machine
networks. This can allow the achievement of mutual objectives and
balanced service delivery against outlined, planned service level
agreements as well as achieve solutions that provide metering,
measurements, traceability and trackability. The creation of new
supply chain structures and methods may enable a multitude of
services to be created, mined for value, and collapsed without any
human involvement.
[0099] Such IoT networks can be further enhanced by the integration
of sensing technologies, such as sound, light, electronic traffic,
facial and pattern recognition, smell, vibration, into the
autonomous organizations among the IoT devices. The integration of
sensory systems can allow systematic and autonomous communication
and coordination of service delivery against contractual service
objectives, orchestration and quality of service (QoS) based
swarming and fusion of resources. Some of the individual examples
of network-based resource processing include the following.
[0100] The mesh network 856, for instance, can be enhanced by
systems that perform inline data-to-information transforms. For
example, self-forming chains of processing resources comprising a
multi-link network may distribute the transformation of raw data to
information in an efficient manner, and the ability to
differentiate between assets and resources and the associated
management of each. Furthermore, the proper components of
infrastructure and resource-based trust and service indices may be
inserted to improve the data integrity, quality, assurance and
deliver a metric of data confidence.
[0101] The WLAN network 858, for instance, can use systems that
perform standards conversion to provide multi-standard
connectivity, enabling IoT devices 804 using different protocols to
communicate. Further systems may provide seamless interconnectivity
across a multi-standard infrastructure comprising visible Internet
resources and hidden Internet resources.
[0102] Communications in the cellular network 860, for instance,
may be enhanced by systems that offload data, extend communications
to more remote devices, or both. The LPWA network 862 can include
systems that perform non-Internet protocol (IP) to IP
interconnections, addressing, and routing. Further, each of the IoT
devices 804 may include the appropriate transceiver for wide area
communications with that device. Further, each IoT device 804 can
include other transceivers for communications using additional
protocols and frequencies.
[0103] Finally, clusters of IoT devices can be equipped to
communicate with other IoT devices as well as with a cloud network.
This can allow the IoT devices to form an ad-hoc network between
the devices, allowing them to function as a single device, which
may be termed a fog device. This configuration is discussed further
with respect to FIG. 9 below.
[0104] FIG. 9 illustrates a cloud computing network in
communication with a mesh network of IoT devices (devices 902)
operating as a fog device at the edge of the cloud computing
network. The mesh network of IoT devices may be termed a fog 920,
operating at the edge of the cloud 900. To simplify the diagram,
not every IoT device 902 is labeled.
[0105] The fog 920 can be considered to be a massively
interconnected network wherein a number of IoT devices 902 are in
communications with each other, for example, by radio links 922. As
an example, this interconnected network may be facilitated using an
interconnect specification released by the Open Connectivity
Foundation.TM. (OCF). This standard allows devices to discover each
other and establish communications for interconnects. Other
interconnection protocols may also be used, including, for example,
the optimized link state routing (OLSR) Protocol, the better
approach to mobile ad-hoc networking (B.A.T.M.A.N.) routing
protocol, or the OMA Lightweight M2M (LWM2M) protocol, among
others.
[0106] Three types of IoT devices 902 are shown in this example,
gateways 904, data aggregators 926, and sensors 928, although any
combinations of IoT devices 902 and functionality may be used. The
gateways 904 may be edge devices that provide communications
between the cloud 900 and the fog 920 and can also provide the
backend process function for data obtained from sensors 928, such
as motion data, flow data, temperature data, and the like. The data
aggregators 926 can collect data from any number of the sensors 928
and perform the back end processing function for the analysis. The
results, raw data, or both can be passed along to the cloud 900
through the gateways 904. The sensors 928 can be full IoT devices
902, for example, capable of both collecting data and processing
the data. In some cases, the sensors 928 can be more limited in
functionality, for example, collecting the data and allowing the
data aggregators 926 or gateways 904 to process the data.
[0107] Communications from any IoT device 902 can be passed along a
convenient path (e.g., a most convenient path) between any of the
IoT devices 902 to reach the gateways 904. In these networks, the
number of interconnections provide substantial redundancy, allowing
communications to be maintained, even with the loss of a number of
IoT devices 902. Further, the use of a mesh network can allow IoT
devices 902 that are very low power or located at a distance from
infrastructure to be used, as the range to connect to another IoT
device 902 can be much less than the range to connect to the
gateways 904.
[0108] The fog 920 provided from these IoT devices 902 can be
presented to devices in the cloud 900, such as a server 906, as a
single device located at the edge of the cloud 900, e.g., a fog
device. In this example, the alerts coming from the fog device may
be sent without being identified as coming from a specific IoT
device 902 within the fog 920. In this fashion, the fog 920 can be
considered a distributed platform that provides computing and
storage resources to perform processing or data-intensive tasks
such as data analytics, data aggregation, and machine-learning,
among others.
[0109] In some examples, the IoT devices 902 can be configured
using an imperative programming style, e.g., with each IoT device
902 having a specific function and communication partners. However,
the IoT devices 902 forming the fog device can be configured in a
declarative programming style, allowing the IoT devices 902 to
reconfigure their operations and communications, such as to
determine needed resources in response to conditions, queries, and
device failures. As an example, a query from a user located at a
server 906 about the operations of a subset of equipment monitored
by the IoT devices 902 can result in the fog 920 device selecting
the IoT devices 902, such as particular sensors 928, needed to
answer the query. The data from these sensors 928 can then be
aggregated and analyzed by any combination of the sensors 928, data
aggregators 926, or gateways 904, before being sent on by the fog
920 device to the server 906 to answer the query. In this example,
IoT devices 902 in the fog 920 can select the sensors 928 used
based on the query, such as adding data from flow sensors or
temperature sensors. Further, if some of the IoT devices 902 are
not operational, other IoT devices 902 in the fog 920 device can
provide analogous data, if available.
[0110] From the foregoing, it will be appreciated that the above
disclosed methods, apparatus and articles of manufacture facilitate
improved shipment coordination and dynamic modification to enable
adjustment of receiver, tracking, and authenticating chain of
custody through automated, electronic shipment management.
[0111] Certain examples provide improved tracking of a shipment and
dynamic verification of a receiver receiving that shipment.
Identity and evolution of the receiver can be tracked via the
shipment coordination system 100 and its register 115 to provide a
ledger or blockchain of receivers maintain a chain of authorization
from an actual receiver of the package back to a receiver
authorized by the sender to receive the shipment. This
delegation-chain can be used to audit, verify, and authorize
receiver(s) and track a progression of receivers if shipment breaks
down, receipt is not verified, fraudulent receipt is detected, etc.
Certain examples provide the delegation-chain to authenticate chain
of custody in the delivery process. Thus, each time a receiver
delegates receiving and signing authority to another receiver, a
link is added to the delegation-chain representing that transfer of
control and ownership to the new receiver and informing the group
of the transfer and chain of custody/authorization.
[0112] Once both sender and receiver (and/or their association
applications/devices) are registered, the shipping group
coordinator creates a secure group for the shipment. The secure
group has a group encryption key and a proof-of-authorized receiver
token. The shipping group coordinator facilitates messaging and/or
other communication between group members such as sender and
receiver, by providing a conduit, channel, or other medium for
messaging communication, for example. The shipping group
coordinator can facilitate messaging by relaying or exchanging
messages and/or by moderating message communication between the
sender and receiver using the group encryption key to help ensure
privacy of the message content between intended recipient(s) in the
group, for example. Thus, receiver, location, status, and/or other
updates, delivery instructions, receipt confirmation, etc., can be
securely and privately exchanged among members of the group via the
shipping group coordinator. The delivery acknowledgement device
and/or the receiving application work to provide receipt
confirmation associated with delivery of the package to an
authorized receiver at the target address based on verification of
the token and the digital signature of the receiver, for
example.
[0113] Example 1 includes shipment coordination apparatus including
an address generator to generate a digital address based on a
physical address; a verification engine to verify information
including the digital address and at least one encryption key
associated with the digital address; and a shipping group
coordinator to generate a group including a sender and a receiver
based on a) a first digital address associated with the sender, b)
a second digital address associated with the receiver, and c) at
least one encryption key associated with at least one of the first
digital address or the second digital address, the shipping group
coordinator to initiate delivery instruction and manage receipt
confirmation of a package at a second physical address
corresponding to the second digital address based on verification
of a token identifying the receiver and to provide messaging
between the sender and the receiver in the group using a group
encryption key to keep messages private in the group.
[0114] Example 2 includes Example 1 and further includes a storage
to save the first digital address, the second digital address, the
at least one encryption key associated with at least one of the
first digital address or the second digital address, the token, and
the group encryption key in association with at least the
receiver.
[0115] Example 3 includes Example 1, wherein the at least one
encryption key includes a private encryption key, a private signing
key, a public encryption key, and a public signing key.
[0116] Example 4 includes Example 1, wherein the shipping group
coordinator is to communicate with a sending application and a
receiving application to register the first digital address and the
second digital address.
[0117] Example 5 includes Example 1, wherein the second physical
address includes a postal address.
[0118] Example 6 includes Example 1, wherein the address generator
is to apply an encrypted hash of the second physical address to
form the second digital address.
[0119] Example 7 includes Example 1, wherein the address generator
is to generate the second digital address and a plurality of
signing keys for a plurality of receivers at the second digital
address.
[0120] Example 8 includes Example 1, wherein the shipping group
coordinator is to facilitate communication of messages in the group
to be verified using a nonce word and a digital signature.
[0121] Example 9 includes Example 1, further including a shipment
tracker to communicate with a low power tag associated with the
package.
[0122] Example 10 includes Example 1, wherein the shipping group
coordinator is to work with a change processor to form a
delegation-chain of receivers in which a first receiver is to
delegate receiving authority for the package at the second digital
address to a second receiver at a third digital address, the
delegation-chain to maintain a record of the chain of authorization
from the first receiver to the second receiver.
[0123] Example 11 includes a tangible computer-readable storage
medium comprising computer readable instructions which, when
executed, cause at least one processor to implement at least: an
address generator to generate a digital address based on a physical
address; a verification engine to verify information including the
digital address and at least one encryption key associated with the
digital address; and a shipping group coordinator to generate a
group including a sender and a receiver based on a) a first digital
address associated with the sender, b) a second digital address
associated with the receiver, and c) at least one encryption key
associated with at least one of the first digital address or the
second digital address, the shipping group coordinator to initiate
delivery instruction and manage receipt confirmation of a package
at a second physical address corresponding to the second digital
address based on verification of a token identifying the receiver
and to provide messaging between the sender and the receiver in the
group using a group encryption key to keep messages private in the
group.
[0124] Example 12 includes Example 11, wherein the instructions,
when executed, further cause the at least one processor to
implement a storage to save the first digital address, the second
digital address, the at least one encryption key associated with at
least one of the first digital address or the second digital
address, the token, and the group encryption key in association
with at least the receiver.
[0125] Example 13 includes Example 11, wherein the at least one
encryption key includes a private encryption key, a private signing
key, a public encryption key, and a public signing key.
[0126] Example 14 includes Example 11, wherein the shipping group
coordinator is to communicate with a sending application and a
receiving application to register the first digital address and the
second digital address.
[0127] Example 15 includes Example 11, wherein the second physical
address includes a postal address.
[0128] Example 16 includes Example 11, wherein the address
generator is to apply an encrypted hash of the second physical
address to form the second digital address.
[0129] Example 17 includes Example 11, wherein the address
generator is to generate the second digital address and a plurality
of signing keys for a plurality of receivers at the second digital
address.
[0130] Example 18 includes Example 11, wherein the shipping group
coordinator is to facilitate communication of messages in the group
to be verified using a nonce word and a digital signature.
[0131] Example 19 includes Example 11, wherein the instructions,
when executed, further cause the at least one processor to
implement a shipment tracker to communicate with a low power tag
associated with the package.
[0132] Example 20 includes Example 11, wherein the shipping group
coordinator is to work with a change processor to form a
delegation-chain of receivers in which a first receiver is to
delegate receiving authority for the package at the second digital
address to a second receiver at a third digital address, the
delegation-chain to maintain a record of the chain of authorization
from the first receiver to the second receiver.
[0133] Example 21 includes a computer-implemented method including:
generating, by executing an instruction with at least one
processor, a first digital address based on a first physical
address; generating, by executing an instruction with the at least
one processor, a second digital address based on a second physical
address; verifying, by executing an instruction with the at least
one processor, the second digital address and at least one
encryption key associated with the second digital address;
generating, by executing an instruction with the at least one
processor, a group including a sender and a receiver based on a)
the first digital address associated with the sender, b) the second
digital address associated with the receiver, and c) the at least
one encryption key associated with the second digital address;
facilitating, by executing an instruction with the at least one
processor, messaging between the sender and the receiver in the
group using a group encryption key to keep messages private within
the group; and managing, by executing an instruction with the at
least one processor, confirmation of receipt of a package at the
second physical address based on verification of a token
identifying the receiver.
[0134] Example 22 includes Example 21, further including storing
the first digital address, the second digital address, the at least
one encryption key associated with at least one of the first
digital address or the second digital address, the token, and the
group encryption key in a storage in association with at least the
receiver.
[0135] Example 23 includes Example 21, wherein the at least one
encryption key includes a private encryption key, a private signing
key, a public encryption key, and a public signing key.
[0136] Example 24 includes Example 21, further including
communicating with a sending application and a receiving
application to register the first digital address and the second
digital address.
[0137] Example 25 includes Example 21, wherein the second physical
address includes a postal address.
[0138] Example 26 includes Example 21, further including applying
an encrypted hash of the second physical address to form the second
digital address.
[0139] Example 27 includes Example 21, further including generating
the second digital address and a plurality of signing keys for a
plurality of receivers at the second digital address.
[0140] Example 28 includes Example 21, further including
facilitating communication of messages in the group to be verified
using a nonce word and a digital signature.
[0141] Example 29 includes Example 21, further including
communicating with a low power tag associated with the package to
track a location of the package.
[0142] Example 30 includes Example 21, further including form a
delegation-chain of receivers in which a first receiver is to
delegate receiving authority for the package at the second digital
address to a second receiver at a third digital address, the
delegation-chain to maintain a record of the chain of authorization
from the first receiver to the second receiver.
[0143] Example 31 includes an apparatus including means for
generating a first digital address based on a first physical
address; means for generating a second digital address based on a
second physical address; means for verifying the second digital
address and at least one encryption key associated with the second
digital address; means for generating a group including a sender
and a receiver based on a) the first digital address associated
with the sender, b) the second digital address associated with the
receiver, and c) the at least one encryption key associated with
the second digital address; means for facilitating messaging
between the sender and the receiver in the group using a group
encryption key; and means for managing confirmation of receipt of a
package at the second physical address based on verification of a
token identifying the receiver.
[0144] Example 32 includes a system that includes a shipment
coordination apparatus to at least: generate a digital address
based on a physical address; verify information including the
digital address and at least one encryption key associated with the
digital address; generate a group including a sender and a receiver
based on a) a first digital address associated with the sender, b)
a second digital address associated with the receiver, and c) at
least one encryption key associated with at least one of the first
digital address or the second digital address; initiate delivery
instructions and manage receipt confirmation of a package at a
second physical address corresponding to the second digital address
based on verification of a token identifying the receiver; and
facilitate messaging between the sender and the receiver in the
group using a group encryption key. The system of Example 32
includes a shipping server to commit digital addresses to a digital
ledger to track a chain of authorization for authorized receivers
of the shipment; and a delivery acknowledgement device to obtain
receipt confirmation for the package at the target delivery
location based on the token.
[0145] Although certain example methods, apparatus and articles of
manufacture have been disclosed herein, the scope of coverage of
this patent is not limited thereto. On the contrary, this patent
covers all methods, apparatus and articles of manufacture fairly
falling within the scope of the claims of this patent.
* * * * *