WO2018125858A1

WO2018125858A1 - Crowdsourced delivery based on a set of requirements

Info

Publication number: WO2018125858A1
Application number: PCT/US2017/068400
Authority: WO
Inventors: Bruce W. Wilkinson; Todd D. MATTINGLY; John J. O'brien
Original assignee: Walmart Apollo, Llc
Priority date: 2016-12-27
Filing date: 2017-12-26
Publication date: 2018-07-05
Also published as: US11605044B2; MX2019007716A; US20230177445A1; CA3048226A1; US20180181904A1

Abstract

In some embodiments, apparatuses and methods are provided herein useful to creating a crowdsourced delivery plan. In some embodiments, a system for creating a crowdsourced delivery plan for a package comprises a certification system configured to receive, from a retailer, an indication of items included in the package, determine, based on the indication of items included in the package, a set of requirements, and transmit, to a plurality of portable devices, information regarding the delivery, each of the plurality of portable devices configured to receive, from the certification system, the information regarding the delivery, transmit, to the certification system, an acceptance of the delivery, wherein only ones of the plurality of portable devices associated with delivery agents meeting the set of requirements is capable of acceptance of the delivery, receive, in response to the transmission of the acceptance, an authorization, and present, at a pickup point, the authorization.

Description

CROWDSOURCED DELIVERY BASED ON A SET OF REQUIREMENTS

Cross-Reference to Related Application

[0001] This application claims the benefit of U.S. Provisional Application Number 62/439,329, filed December 27, 2016, which is incorporated by reference in its entirety herein.

Technical Field

[0002] This invention relates generally to package delivery and, more specifically, to crowdsourced package delivery.

Background

[0003] As an increasing number of customers shop remotely (e.g., online or over the phone), the number of packages delivered by retailers increases. Package delivery is not an insignificant cost to retailers. While retailers might prefer to pass these delivery costs on to the customers, customers often expect free or low-cost shipping options. Consequently, to remain competitive and encourage customers to shop more frequently, whether in a brick-and-mortar facility or remotely, retailers are seeking new low-cost shipping options. One such option is crowdsourced delivery. Crowdsourced delivery however poses problems that shipping with established carriers does not. For example, while it may be safe to assume that all employees of established carriers have proper certifications to deliver packages containing regulated or controlled items, such an assumption may not be as well-founded with crowdsourced delivery agents. Consequently, a need exists for a system that can create delivery plans with crowdsourced delivery agents which ensures that the crowdsourced delivery agents have the proper certifications.

Brief Description of the Drawings

[0004] Disclosed herein are embodiments of systems, apparatuses and methods pertaining to creating a crowdsourced delivery plan. This description includes drawings, wherein:

[0005] FIG. 1 depicts a portable device 102 presenting a user interface for a crowdsource delivery agent, according to some embodiments;

[0006] FIG. 2 depicts an illustration of blocks, according to some embodiments; [0007] FIG. 3 depicts an illustration of transactions, according to some embodiments; [0008] FIG. 4 depicts a flow diagram, according to some embodiments;

[0009] FIG. 5 depicts a process diagram, according to some embodiments;

[0010] FIG. 6 depicts an illustration of a delivery record, according to some embodiments;

[0011] FIG. 7 depicts a system diagram configured, according to some embodiments;

[0012] FIG. 8 is a block diagram of a system 800 for creating a crowdsourced delivery plan, according to some embodiments;

[0013] FIG. 9 is a flow diagram including example operations for creating a crowdsourced delivery plan, according to some embodiments;

[0014] FIG. 10 is a flow diagram depicting example operations for confirming a delivery agent's location, according to some embodiments; and

[0015] FIG. 11 is a flow diagram depicting example operations for confirming a customer's location, according to some embodiments.

[0016] Elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions and/or relative positioning of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of various embodiments of the present invention. Also, common but well- understood elements that are useful or necessary in a commercially feasible embodiment are often not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. Certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. The terms and expressions used herein have the ordinary technical meaning as is accorded to such terms and expressions by persons skilled in the technical field as set forth above except where different specific meanings have otherwise been set forth herein.

Detailed Description

[0017] Generally speaking, pursuant to various embodiments, systems, apparatuses, and methods are provided herein useful to creating a crowdsourced delivery plan. In some embodiments, a system for creating a crowdsourced delivery plan for a package comprises a certification system, the certification system configured to receive, from a retailer, an indication of items included in the package, determine, based on the indication of items included in the package, a set of requirements, and transmit, to a plurality of portable devices, information regarding the delivery, each of the plurality of portable devices configured to receive, from the certification system, the information regarding the delivery, transmit, to the certification system, an acceptance of the delivery, wherein only ones of the plurality of portable devices associated with delivery agents meeting the set of requirements is capable of acceptance of the delivery, receive, in response to the transmission of the acceptance of the delivery, an authorization, and present, at a pickup point, the authorization.

[0018] As previously discussed, the frequency with which customers shop remotely is increasing. Accordingly, shipping costs for retailers are increasing with the increased number of packages that must be delivered to the customers shopping remotely. While crowdsourced delivery may decrease some of these costs, it also poses new problems. For example, state or federal law may require that a delivery agent have certain certifications to deliver regulated items, such as alcohol, pharmaceuticals, firearms, etc. While established carriers (e.g., USPS, UPS, FedEx, etc.) may have plans and contingencies in place for delivery of such items, crowdsourced systems and methods lack many of these controls. Accordingly, embodiments described herein seek to minimize or eliminate these issues via a system that determines a set of requirements for delivery and ensures that only those crowdsourced delivery agents meeting those requirements are able to deliver the packages. The discussion of FIG. 1 provides an introduction to a system for creating a crowdsourced delivery plan for a package. In some embodiments, the system utilizes blockchain to maintain a list of certifications for delivery agents. Descriptions of some embodiments of blockchain technology are provided with reference to FIGS. 2 - 7 herein. Blockchain technology may be utilized to maintain a record of certifications for delivery agents. One or more of the certification systems described herein may comprise a node in a distributed blockchain system storing a copy of the blockchain record. Updates to the blockchain may comprise the transfer and/or recordation of certifications and one or more nodes on the system may be configured to incorporate one or more updates into blocks to add to the distributed database. The discussion of FIGS. 8 - 9 provides additional details regarding a system for creating a crowdsourced delivery plan for a package. Introduction:

[0019] FIG. 1 depicts a portable device 102 presenting a user interface for a crowdsource delivery agent, according to some embodiments. While FIG. 1 depicts the portable device 102 as a cellular phone, the portable device can be any suitable device (e.g., a computer, tablet, a dedicated device, etc.). The user interface is part of a system for creating a crowdsourced delivery plan for a package. When a retailer wants to find a crowdsourced delivery agent to deliver a package, the retailer transmits a notification to the system. The portable device 102 presents potential deliveries, from which a delivery agent can accept one or more of the potential deliveries. After accepting the delivery, the delivery agent receives an authorization on the portable device 102. The authorization can be a visual, audible, or transmittable code (e.g., via nearfield communication). In some embodiments, pickup of the package is automated such that the delivery agent simply presents the authorization at a pickup point and the package is delivered to the delivery agent.

[0020] Before the system presents delivery opportunities to delivery agents, the retailer transmits a notification informing the system of the delivery. The notification includes information regarding the package (i.e., the package to be delivered). The information can include an indication of items included in the package, as well as other delivery instructions, such as an address, timing requirements, etc. The items in the package may have restrictions on delivery agents that can deliver the package. The restrictions can be set by retailer policy, law, or any other suitable source. For example, if one of the items in the package is a firearm, the retailer, or law, may require that the person delivering the package have certain certifications, such as not being a convicted felon or having a special license (e.g., a license to carry a firearm or a license to deliver a firearm). The certifications can be of any suitable type or quality, such as age (i.e., age of the delivery agent), ratings (e.g., ratings received by previous customers, retailers, or certification systems), ability to use the item (e.g., a certification that the delivery agent is capable of demonstrating use of the item), ability to install the item (e.g., a certification that the delivery agent is capable of installing the item), criminal history, medical history, education, type of vehicle used for delivery, length of delivery experience, etc. As discussed in more detail with regard to FIGS. 2 - 7, the system can store credentials, as well as delivery agent identities, in a blockchain format. [0021] After receiving the indication of the items included in the package, the system determines a set of requirements for the delivery agent. As discussed in more detail below, dependent upon the embodiment, the certification system or the portable device 102 determines the set of requirements. The set of requirements is dependent upon the items in the package and specifies the type(s), if any, of certification required of the delivery agent. In either embodiment, the delivery agent associated with the portable device 102 is only capable of accepting the delivery if the delivery agent associated with the portable device 102 meets the set of requirements. For example, the certification may only transmit potential deliveries to portable devices associated with delivery agents that meet the set of requirements, or the portable device 102 may only present potential deliveries for which the delivery agent associated with the portable device 102 meets the set of requirements. The delivery agent can view and select deliveries via the portable device 102.

[0022] The user interface presented by the portable device 102 depicted in FIG. 1 is but an example of one suitable user interface. The user interface can have a different appearance and/or have greater, or fewer, features than the user interface depicted in FIG. 1. The user interface depicted in FIG. 1, includes windows for potential deliveries. As depicted in FIG. 1, the user interface includes a first window 106 for a first potential delivery ("Delivery 1") and a second window 122 for a second potential delivery ("Delivery 2"). The first window 106 is in the foreground and provides information and options related to the first potential delivery.

Specifically, the first window 106 includes address information 108, including a map option 110 to show the address on a map, restriction information 112 (i.e., the set of requirements required to deliver the package), timing requirements 114, and an accept option 116 (the selection of which accepts the delivery). The delivery agent can select the second window 122 to bring the second window 122, and the information and options related to the second potential delivery, to the foreground. The user interface also includes an "all deliveries" button 118 and a "deliveries near me" button 120. Selection of the "all deliveries" button 118 shows all potential deliveries, for example, in a grid, on a map, etc. Selection of the "deliveries near me" button 120 shows all deliveries near the portable device 102, for example, in a grid, on a map, etc.

[0023] While the discussion of FIG. 1 provides an introduction to a system for creating crowdsource delivery plans, the discussion of FIGS. 2 - 7 provides additional detail regarding blockchain. Blockchain Technology:

[0024] Distributed database and shared ledger database generally refer to methods of peer-to- peer record keeping and authentication in which records are kept at multiple nodes in the peer-to- peer network instead of kept at a trusted party. A blockchain may generally refer to a distributed database that maintains a growing list of records in which each block contains a hash of some or all previous records in the chain to secure the record from tampering and unauthorized revision. A hash generally refers to a derivation of original data. In some embodiments, the hash in a block of a blockchain may comprise a cryptographic hash that is difficult to reverse and/or a hash table. Blocks in a blockchain may further be secured by a system involving one or more of a distributed timestamp server, cryptography, public/private key authentication and encryption, proof standard (e.g. proof-of-work, proof-of-stake, proof-of-space), and/or other security, consensus, and incentive features. In some embodiments, a block in a blockchain may comprise one or more of a data hash of the previous block, a timestamp, a cryptographic nonce, a proof standard, and a data descriptor to support the security and/or incentive features of the system.

[0025] In some embodiments, a blockchain system comprises a distributed timestamp server comprising a plurality of nodes configured to generate computational proof of record integrity and the chronological order of its use for content, trade, and/or as a currency of exchange through a peer-to-peer network. In some embodiments, when a blockchain is updated, a node in the distributed timestamp server system takes a hash of a block of items to be timestamped and broadcasts the hash to other nodes on the peer-to-peer network. The timestamp in the block serves to prove that the data existed at the time in order to get into the hash. In some

embodiments, each block includes the previous timestamp in its hash, forming a chain, with each additional block reinforcing the ones before it. In some embodiments, the network of timestamp server nodes performs the following steps to add a block to a chain: 1) new activities are broadcasted to all nodes, 2) each node collects new activities into a block, 3) each node works on finding a difficult proof-of-work for its block, 4) when a node finds a proof-of-work, it broadcasts the block to all nodes, 5) nodes accept the block only if activities are authorized, and 6) nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash. In some embodiments, nodes may be configured to consider the longest chain to be the correct one and work on extending it. A digital currency implemented on a blockchain system is described by Satoshi Nakamoto in "Bitcoin: A Peer-to-Peer Electronic Cash System" (http://bitcoin.org/bitcoin. pdf), the entirety of which is incorporated herein by reference.

[0026] Now referring to FIG. 2, an illustration of a blockchain according to some embodiments is shown. In some embodiments, a blockchain comprises a hash chain or a hash tree in which each block added in the chain contains a hash of the previous block. In FIG. 2, block 0 200200 represents a genesis block of the chain. Block 1 210 contains a hash of block 0 200, block 2 220 contains a hash of block 1 210, block 3 230 contains a hash of block 2 220, and so forth.

Continuing down the chain, block N 290 contains a hash of block N-l . In some embodiments, the hash may comprise the header of each block. Once a chain is formed, modifying or tampering with a block in the chain would cause detectable disparities between the blocks. For example, if block 1 is modified after being formed, block 1 would no longer match the hash of block 1 in block 2. If the hash of block 1 in block 2 is also modified in an attempt to cover up the change in block 1 , block 2 would not then match with the hash of block 2 in block 3. In some embodiments, a proof standard (e.g. proof-of-work, proof-of-stake, proof-of-space, etc.) may be required by the system when a block is formed to increase the cost of generating or changing a block that could be authenticated by the consensus rules of the distributed system, making the tampering of records stored in a blockchain computationally costly and essentially impractical. In some embodiments, a blockchain may comprise a hash chain stored on multiple nodes as a distributed database and/or a shared ledger, such that modifications to any one copy of the chain would be detectable when the system attempts to achieve consensus prior to adding a new block to the chain. In some embodiments, a block may generally contain any type of data and record. In some embodiments, each block may comprise a plurality of transaction and/or activity records.

[0027] In some embodiments, blocks may contain rules and data for authorizing different types of actions and/or parties who can take action. In some embodiments, transaction and block forming rules may be part of the software algorithm on each node. When a new block is being formed, any node on the system can use the prior records in the blockchain to verify whether the requested action is authorized. For example, a block may contain a public key of an owner of an asset that allows the owner to show possession and/or transfer the asset using a private key. Nodes may verify that the owner is in possession of the asset and/or is authorized to transfer the asset based on prior transaction records when a block containing the transaction is being formed and/or verified. In some embodiments, rules themselves may be stored in the blockchain such that the rules are also resistant to tampering once created and hashed into a block. In some embodiments, the blockchain system may further include incentive features for nodes that provide resources to form blocks for the chain. For example, in the Bitcoin system, "miners' are nodes that compete to provide proof-of-work to form a new block, and the first successful miner of a new block earns Bitcoin currency in return.

[0028] Now referring to FIG. 3, an illustration of blockchain-based transactions according to some embodiments is shown. In some embodiments, the blockchain illustrated in FIG. 3 comprises a hash chain protected by private/public key encryption. Transaction A 310 represents a transaction recorded in a block of a blockchain showing that owner 1 (recipient) obtained an asset from owner 0 (sender). Transaction A 310 contains owner's 1 public key and owner 0's signature for the transaction and a hash of a previous block. When owner 1 transfers the asset to owner 2, a block containing transaction B 320 is formed. The record of transaction B 320 comprises the public key of owner 2 (recipient), a hash of the previous block, and owner 1 's signature for the transaction that is signed with the owner 1 's private key 325 and verified using owner l 's public key in transaction A 310. When owner 2 transfers the asset to owner 3, a block containing transaction C 330 is formed. The record of transaction C 330 comprises the public key of owner 3 (recipient), a hash of the previous block, and owner 2's signature for the transaction that is signed by owner 2's private key 335 and verified using owner 2's public key from transaction B 220. In some embodiments, when each transaction record is created, the system may check previous transaction records and the current owner's private and public key signature to determine whether the transaction is valid. In some embodiments, transactions are be broadcasted in the peer-to-peer network and each node on the system may verify that the transaction is valid prior to adding the block containing the transaction to their copy of the blockchain. In some embodiments, nodes in the system may look for the longest chain in the system to determine the most up-to-date transaction record to prevent the current owner from double spending the asset. The transactions in FIG. 3 are shown as an example only. In some embodiments, a blockchain record and/or the software algorithm may comprise any type of rules that regulate who and how the chain may be extended. In some embodiments, the rules in a blockchain may comprise clauses of a smart contract that is enforced by the peer-to-peer network.

[0029] Now referring to FIG. 4, a flow diagram according to some embodiments is shown. In some embodiments, the steps shown in FIG. 4 may be performed by a processor-based device, such as a computer system, a server, a distributed server, a timestamp server, a blockchain node, and the like. In some embodiments, the steps in FIG. 4 may be performed by one or more of the nodes in a system using blockchain for record keeping.

[0030] In step 401 , a node receives a new activity. The new activity may comprise an update to the record being kept in the form of a blockchain. In some embodiments, for blockchain supported digital or physical asset record keeping, the new activity may comprise a asset transaction. In some embodiments, the new activity may be broadcasted to a plurality of nodes on the network prior to step 401. In step 402, the node works to form a block to update the blockchain. In some embodiments, a block may comprise a plurality of activities or updates and a hash of one or more previous block in the blockchain. In some embodiments, the system may comprise consensus rules for individual transactions and/or blocks and the node may work to form a block that conforms to the consensus rules of the system. In some embodiments, the consensus rules may be specified in the software program running on the node. For example, a node may be required to provide a proof standard (e.g. proof of work, proof of stake, etc.) which requires the node to solve a difficult mathematical problem for form a nonce in order to form a block. In some embodiments, the node may be configured to verify that the activity is authorized prior to working to form the block. In some embodiments, whether the activity is authorized may be determined based on records in the earlier blocks of the blockchain itself.

[0031] After step 402, if the node successfully forms a block in step 405 prior to receiving a block from another node, the node broadcasts the block to other nodes over the network in step 406. In some embodiments, in a system with incentive features, the first node to form a block may be permitted to add incentive payment to itself in the newly formed block. In step 420, the node then adds the block to its copy of the blockchain. In the event that the node receives a block formed by another node in step 403 prior to being able to form the block, the node works to verify that the activity recorded in the received block is authorized in step 404. In some embodiments, the node may further check the new block against system consensus rules for blocks and activities to verify whether the block is properly formed. If the new block is not authorized, the node may reject the block update and return to step 402 to continue to work to form the block. If the new block is verified by the node, the node may express its approval by adding the received block to its copy of the blockchain in step 420. After a block is added, the node then returns to step 401 to form the next block using the newly extended blockchain for the hash in the new block.

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

[0033] Now referring to FIG. 5, a process diagram a blockchain update according to some implementations in shown. In step 501 , party A initiates the transfer of a digitized item to party B. In some embodiments, the digitized item may comprise a digital currency, a digital asset, a document, rights to a physical asset, etc. In some embodiments, Party A may prove that he has possession of the digitized item by signing the transaction with a private key that may be verified with a public key in the previous transaction of the digitized item. In step 502, the exchange initiated in step 501 is represented as a block. In some embodiments, the transaction may be compared with transaction records in the longest chain in the distributed system to verify part A's ownership. In some embodiments, a plurality of nodes in the network may compete to form the block containing the transaction record. In some embodiments, nodes may be required to satisfy proof-of-work by solving a difficult mathematical problem to form the block. In some embodiments, other methods of proof such as proof-of-stake, proof-of-space, etc. may be used in the system. In some embodiments, the node that is first to form the block may earn a reward for the task as incentive. For example, in the Bitcoin system, the first node to provide prove of work to for block the may earn a Bitcoin. In some embodiments, a block may comprise one or more transactions between different parties that are broadcasted to the nodes. In step 503, the block is broadcasted to parties in the network. In step 504, nodes in the network approve the exchange by examining the block that contains the exchange. In some embodiments, the nodes may check the solution provided as proof-of-work to approve the block. In some embodiments, the nodes may check the transaction against the transaction record in the longest blockchain in the system to verify that the transaction is valid (e.g. party A is in possession of the asset he/she s seeks to transfer). In some embodiments, a block may be approved with consensus of the nodes in the network. After a block is approved, the new block 506 representing the exchange is added to the existing chain 505 comprising blocks that chronologically precede the new block 506. The new block 506 may contain the transaction(s) and a hash of one or more blocks in the existing chain 505. In some embodiments, each node may then update their copy of the blockchain with the new block and continue to work on extending the chain with additional transactions. In step 507, when the chain is updated with the new block, the digitized item is moved from party A to party B.

[0034] Now referring to FIG. 6, a diagram of a blockchain according to some embodiments in shown. FIG. 6 comprises an example of an implementation of a blockchain system for delivery service record keeping. The delivery record 600 comprises digital currency information, address information, transaction information, and a public key associated with one or more of a sender, a courier, and a buyer. In some embodiments, nodes associated the sender, the courier, and the buyer may each store a copy of the delivery record 610, 620, and 630 respectively. In some embodiments, the delivery record 600 comprises a public key that allows the sender, the courier, and/or the buyer to view and/or update the delivery record 600 using their private keys 615, 625, and the 635 respectively. For example, when a package is transferred from a sender to the courier, the sender may use the sender's private key 615 to authorize the transfer of a digital asset representing the physical asset from the sender to the courier and update the delivery record with the new transaction. In some embodiments, the transfer from the seller to the courier may require signatures from both the sender and the courier using their respective private keys. The new transaction may be broadcasted and verified by the sender, the courier, the buyer, and/or other nodes on the system before being added to the distributed delivery record blockchain. When the package is transferred from the courier to the buyer, the courier may use the courier's private key 625 to authorize the transfer of the digital asset representing the physical asset from the courier to the buyer and update the delivery record with the new transaction. In some embodiments, the transfer from the courier to the buyer may require signatures from both the courier and the buyer using their respective private keys. The new transaction may be broadcasted and verified by the sender, the courier, the buyer, and/or other nodes on the system before being added to the distributed delivery record blockchain.

[0035] With the scheme shown in FIG. 6, the delivery record may be updated by one or more of the sender, courier, and the buyer to form a record of the transaction without a trusted third party while preventing unauthorized modifications to the record. In some embodiments, the blockchain based transactions may further function to include transfers of digital currency with the completion of the transfer of physical asset. With the distributed database and peer-to-peer verification of a blockchain system, the sender, the courier, and the buyer can each have confidence in the authenticity and accuracy of the delivery record stored in the form of a blockchain.

[0036] Now referring to FIG. 7, a system according to some embodiments is shown. A distributed blockchain system comprises a plurality of nodes 710710 communicating over a network 720. In some embodiments, the nodes 710710 may be comprise a distributed blockchain server and/or a distributed timestamp server. In some embodiments, one or more nodes 710710 may comprise or be similar to a "miner" device on the Bitcoin network. Each node 710710 in the system comprises a network interface 711, a control circuit 712, and a memory 713.

[0037] The control circuit 712 may comprise a processor, a microprocessor, and the like and may be configured to execute computer readable instructions stored on a computer readable storage memory 713. The computer readable storage memory may comprise volatile and/or nonvolatile memory and have stored upon it a set of computer readable instructions which, when executed by the control circuit 712, causes the node 710710 update the blockchain 714 stored in the memory 713 based on communications with other nodes 710710 over the network 720. In some embodiments, the control circuit 712 may further be configured to extend the blockchain 714 by processing updates to form new blocks for the blockchain 714. Generally, each node may store a version of the blockchain 714, and together, may form a distributed database. In some embodiments, each node 710710 may be configured to perform one or more steps described with reference to FIGS. 6-7 herein. [0038] The network interface 71 1 may comprise one or more network devices configured to allow the control circuit to receive and transmit information via the network 720. In some embodiments, the network interface 711 may comprise one or more of a network adapter, a modem, a router, a data port, a transceiver, and the like. The network 720 may comprise a communication network configured to allow one or more nodes 710710 to exchange data. In some embodiments, the network 720 may comprise one or more of the Internet, a local area network, a private network, a virtual private network, a home network, a wired network, a wireless network, and the like. In some embodiments, the system does not include a central server and/or a trusted third party system. Each node in the system may enter and leave the network at any time.

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

[0040] In some embodiments, blockchain may be used to support a payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party. Bitcoin is an example of a blockchain backed currency. A blockchain system uses a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. Generally, a blockchain system is secure as long as honest nodes collectively control more processing power than any cooperating group of attacker nodes. With a blockchain, the transaction records are

computationally impractical to reverse. As such, sellers are protected from fraud and buyers are protected by the routine escrow mechanism.

[0041] In some embodiments, a blockchain may use to secure digital documents such as digital cash, intellectual property, private financial data, chain of title to one or more rights, real property, digital wallet, digital representation of rights including, for example, a license to intellectual property, digital representation of a contractual relationship, medical records, security clearance rights, background check information, passwords, access control information for physical and/or virtual space, and combinations of one of more of the foregoing that allows online interactions directly between two parties without going through an intermediary. With a blockchain, a trusted third party is not required to prevent fraud. In some embodiments, a blockchain may include peer-to-peer network timestamped records of actions such as accessing documents, changing documents, copying documents, saving documents, moving documents, or other activities through which the digital content is used for its content, as an item for trade, or as an item for remuneration by hashing them into an ongoing chain of hash-based proof-of-work to form a record that cannot be changed in accord with that timestamp without redoing the proof- of-work.

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

[0043] In some embodiments, a blockchain based system allows content use, content exchange, and the use of content for remuneration based on cryptographic proof instead of trust, allowing any two willing parties to employ the content without the need to trust each other and without the need for a trusted third party. In some embodiments, a blockchain may be used to ensure that a digital document was not altered after a given timestamp, that alterations made can be followed to a traceable point of origin, that only people with authorized keys can access the document, that the document itself is the original and cannot be duplicated, that where duplication is allowed and the integrity of the copy is maintained along with the original, that the document creator was authorized to create the document, and/or that the document holder was authorized to transfer, alter, or otherwise act on the document.

[0044] As used herein, in some embodiments, the term blockchain may refer to one or more of a hash chain, a hash tree, a distributed database, and a distributed ledger. In some embodiments, blockchain may further refer to systems that uses one or more of cryptography, private/public key encryption, proof standard, distributed timestamp server, and inventive schemes to regulate how new blocks may be added to the chain. In some embodiments, blockchain may refer to the technology that underlies the Bitcoin system, a "sidechain" that uses the Bitcoin system for authentication and/or verification, or an alternative blockchain ("altchain") that is based on bitcoin concept and/or code but are generally independent of the Bitcoin system.

[0045] Descriptions of embodiments of blockchain technology are provided herein as illustrations and examples only. The concepts of the blockchain system may be variously modified and adapted for different applications.

[0046] While the discussion of FIGS. 2 - 7 provides additional detail regarding blockchain technology, the discussion of FIG. 8 describes a system for creating a crowdsourced delivery plan.

Additional Details Regarding a System for Creating Crowdsourced Delivery Plans:

[0047] FIG. 8 is a block diagram of a system 800 for creating a crowdsourced delivery plan, according to some embodiments. The system 800 includes a retailer 802 (or multiple retailers), a certification system 804 (or multiple certification systems), and portable devices 806. The certification system 804 can be backend system that includes one or more control circuits 808. The control circuit 808 can comprise a fixed-purpose hard-wired hardware platform (including but not limited to an application-specific integrated circuit (ASIC) (which is an integrated circuit that is customized by design for a particular use, rather than intended for general-purpose use), a field-programmable gate array (FPGA), and the like) or can comprise a partially or wholly- programmable hardware platform (including but not limited to microcontrollers,

microprocessors, and the like). These architectural options for such structures are well known and understood in the art and require no further description here. The control circuit 808 is configured (for example, by using corresponding programming as will be well understood by those skilled in the art) to carry out one or more of the steps, actions, and/or functions described herein.

[0048] By one optional approach the control circuit 808 operably couples to a memory. The memory may be integral to the control circuit 808 or can be physically discrete (in whole or in part) from the control circuit 808 as desired. This memory can also be local with respect to the control circuit 808 (where, for example, both share a common circuit board, chassis, power supply, and/or housing) or can be partially or wholly remote with respect to the control circuit 808 (where, for example, the memory is physically located in another facility, metropolitan area, or even country as compared to the control circuit 808).

[0049] This memory can serve, for example, to non-transitorily store the computer instructions that, when executed by the control circuit 808, cause the control circuit 808 to behave as described herein. As used herein, this reference to "non-transitorily" will be understood to refer to a non-ephemeral state for the stored contents (and hence excludes when the stored contents merely constitute signals or waves) rather than volatility of the storage media itself and hence includes both non-volatile memory (such as read-only memory (ROM) as well as volatile memory (such as an erasable programmable read-only memory (EPROM).

[0050] When the retailer 802 wishes to ship a package via crowdsourced delivery agent, the retailer 802 transmits a notification to the certification system 804. The notification contains an indication of items included in the package. Additionally, the notification can include other delivery information, such as delivery addresses, delivery instructions, timing requirements, retailer and/or customer preferences, etc. The certification system 804 transmits this

information, as information regarding the delivery, to the portable devices 806.

[0051] In a first embodiment, the certification system 804 ensures that only delivery agents capable of delivering the package (i.e., those that meet the set of requirements for the package) can accept the delivery. In such embodiments, the certification system 804 determines a set of requirements. The set of requirements is based on the items included in the package and indicate the certifications required of the delivery agent. After determining the set of requirements, the certification system 804 transmits the information regarding the delivery only to ones of the portable devices 806 that are associated with delivery agents meeting the set of requirements. Accordingly, only the ones of the portable devices 806 that are associated with delivery agents that meet the set of requirements will receive the information. Because only the ones of the portable devices 806 that are associated with delivery agents that meet the set of requirements will receive the information, only delivery agents that meet the set of requirements can accept the delivery. The certification system 804 determines which delivery agents (and associated portable devices 806) are capable of delivering the package by referencing a list, or in some embodiments, a blockchain, or both. For example, the list can include indications of delivery agents and associated portable devices 806 and the blockchain can include certifications for each of the delivery agents.

[0052] In a second embodiment, the certification system transmits the information regarding the delivery to all of the portable devices 806. In such embodiments, the portable devices 806 ensure that only delivery agents meeting the set of requirements can accept the delivery. That is, an application running on the portable devices 806 ensures that only delivery agents meeting the set of requirements can accept the delivery. The portable devices 806, after receiving the information regarding the delivery, determine whether the delivery agent associated with the portable device 806 is capable of delivering the package. For example, the portable devices 806 can reference a list or blockchain to determine if the delivery agent associated with the portable device 806 meets the set of requirements. The portable devices 806 can prevent delivery agents that are not capable of delivering the package from accepting the delivery in any suitable manner. For example, the portable devices 806 may only present the delivery to the delivery agents that are capable of delivering the package (i.e., if a delivery agent does not meet the set of requirements, the portable device 806 associated with the delivery agent will not present the potential delivery), can make deliveries for which delivery agents are not capable unselectable, etc.

[0053] After receiving the information regarding the delivery, the portable devices 806 presents the potential deliveries to the delivery agents. As one example, the portable devices 806 can present the potential deliveries to the delivery agents via a user interface, such as a touchscreen graphical user interface (GUI). An application running on the portable devices 806 can generate the user interface. From the user interface, the delivery agents can view different potential deliveries, view information about the potential deliveries, and accept potential deliveries. When a delivery agent selects a potential delivery, the portable device 806 transmits an acceptance of the delivery. The portable device 806 can transmit the acceptance of the delivery to the certification system 804 and/or the retailer 802.

[0054] After transmitting the acceptance, the portable device 806 receives an authorization. The portable device 806 receives the authorization from the certification system 804 and/or the retailer 802, dependent upon where the acceptance was sent. The authorization is a code or identifier that allows the delivery agent to retrieve the package. For example, the authorization can be a code (an alphabetic code, a numeric code, an alphanumeric code, a two- or three- dimensional barcode (i.e., a quick response ("QR") code), an auditory code, or a transmittable code (e.g., a radiofrequency ("RF") code). The authorization can include information identifying the delivery agent, the retailer, certifications required to deliver the package, delivery information for the package, etc. Additionally, the authorization can be unique to the delivery agent and/or the portable device 806 so that only a portable device 806 containing the correct authorization can retrieve the package. In some embodiments, the authorizations can also be tracked in a blockchain.

[0055] While the discussion of FIG. 8 provides additional information regarding a system for creating a crowdsourced delivery plan, the discussion FIG. 9 describes example operations for creating a crowdsourced delivery plan.

[0056] FIG. 9 is a flow diagram including example operations for creating a crowdsourced delivery plan, according to some embodiments. The flow continues at block 902.

[0057] At block 902, an indication of items in a package is received. For example, a system comprising a certification system and portable devices can receive the indication of the items. Specifically, the certification system can receive the indication of the items from a retailer seeking a crowdsourced delivery agent. The indication of the items can be included in a notification of a delivery request. In addition to the indication of the items, the certification system can receive delivery information, such as addresses, timing requirements, delivery instructions, etc. The flow continues at block 904.

[0058] At block 904, a set of requirements is determined. For example, the certification system and/or portable devices can determine the set of requirements. The system determines the set of requirements based on the items included in the package. The set of requirements is based on certifications required to deliver the items in the package. The certifications can be of any suitable type or quality, such as age (i.e., age of the delivery agent), ratings (e.g., ratings received by previous customers, retailers, or certification systems), ability to use the item (e.g., a certification that the delivery agent is capable of demonstrating use of the item), ability to install the item (e.g., a certification that the delivery agent is capable of installing the item), criminal history, medical history, education, etc. The flow continues at block 906. [0059] At block 906, information regarding the delivery is transmitted. For example, the certification system transmits the information regarding the delivery to the portable devices. The information regarding the delivery includes the set of restrictions (if determined by the certification system) as well as information relevant to delivery of the package (e.g., addresses, timing requirements, preferences, etc.). The flow continues at block 908.

[0060] At block 908, information regarding the delivery is received. For example, the portable devices can receive the information regarding the delivery. The flow continues at block 910.

[0061] At block 910, acceptance of the delivery is transmitted. For example, one, or more, of the portable devices transmits the acceptance of the delivery. The acceptance can be delivered to the certification system, the retailer, or both. After receiving the information regarding the delivery, the portable device presents the delivery agent with information about the delivery. The delivery agent reviews the information about the delivery and can choose whether to accept the delivery. In some embodiments, the delivery agent can only accept the delivery if he or she meets the set of requirements (i.e., has the requisite certifications to deliver the package). The flow continues at block 912.

[0062] At block 912, an authorization is received. For example, the portable device receives the authorization. The portable device receives the authorization from the certification system and/or the retailer. The authorization is a code or identifier that allows the delivery agent to retrieve the package. For example, the authorization can be a code (an alphabetic code, a numeric code, an alphanumeric code, a two- or three-dimensional barcode (i.e., a quick response ("QR") code), an auditory code, or a transmittable code (e.g., a radiofrequency ("RF") code). The authorization can include information identifying the delivery agent, the retailer, certifications required to deliver the package, delivery information for the package, etc. In some embodiments, the authorization is based on a cryptographic hash. Additionally, the authorization can be unique to the delivery agent and/or the portable device so that only a portable device containing the correct authorization can retrieve the package. The flow continues at block 914.

[0063] At block 914, the authorization is presented at a pickup point. For example, the delivery agent can present, via the portable device, the authorization. In some embodiments, the pickup is automated and presentation of the authorization causes delivery of the package to the delivery agent. [0064] FIG. 10 is a flow diagram depicting example operations for confirming a delivery agent's location, according to some embodiments. In some embodiments, a system for creating a crowdsourced delivery plan for a package includes additional security features. On such feature ensures that a crowdsource delivery agent is in a location suitable to retrieve the item. For example, if the delivery is for a prescription medication, the delivery agent will not be able to retrieve the prescription medication unless he or she is at a specified location, such as a pharmacy. Such authentication may prevent unauthorized persons from electronically imitating a delivery agent (e.g., presenting an authorization that was fraudulently obtained) and retrieving a delivery. The flow begins at block 1002.

[0065] At block 1002, a presentation of an authorization is received. For example, a delivery agent can present, via his or her mobile device, the authorization. Because the authorization allows the delivery agent to retrieve the item, it is important to ensure that the person presenting the authorization is indeed the delivery agent. While the authorization provides a certain level of security (i.e., the authorization is only provided to a delivery agent capable of delivering the items), it may be susceptible to imitation. For example, an unauthorized person may steal or otherwise acquire the authorization. The flow continues at block 1004.

[0066] At block 1004, the location of the delivery agent to whom the authorization was transmitted is determined. For example, if Delivery Agent A accepted the delivery and in turn received the authorization, the system determines the location of Delivery Agent A. The flow continues at decision diamond 1006.

[0067] At decision diamond 1006, the location of the delivery agent to whom the authorization was transmitted is determined. If the location of the delivery agent to whom the authorization was transmitted is confirmed (i.e., the delivery agent is in the proper location to retrieve the item), the flow continues at block 1008. However, if at decision diamond 1006, the location of the delivery agent to whom the authorization was transmitted is not confirmed, the flow continues at block 1010.

[0068] At block 1008, retrieval of the item is allowed. Because the location of the delivery agent to whom the authorization was transmitted was confirmed, the delivery agent will be permitted to retrieve the item. [0069] As previously discussed, if at decision diamond 1006, the location of the delivery agent to whom the authorization was transmitted is not confirmed, the flow continues at block 1010. At block 1010, retrieval of the item is not allowed. For example, when the authorization is presented at the pharmacy, Delivery Agent A (from the example above) is not at the pharmacy. Because Delivery Agent A is not at the pharmacy, it is assumed that whoever is presenting the authorization is doing so fraudulently. Consequently, this person will not be permitted to retrieve the item.

[0070] FIG. 1 1 is a flow diagram depicting example operations for confirming a customer's location, according to some embodiments. As discussed above with respect to FIG. 10, location determination can be used in increase the security, and accuracy, of item delivery. In some embodiments, enhanced security can be provided by ensuring that the customer is near the item when the item is delivered. Such a location determination may prevent packages from being stolen, as well as ensure that the delivery agent is in the correct location when delivering an item. The flow begins at block 1102.

[0071] At block 1 102, a request to deliver an item is received. For example, a delivery agent can transmit the request to deliver the item via a mobile device. The request can be explicit or implicit (e.g., the request is triggered when an item is scanned for delivery). The flow continues at block 1104.

[0072] At block 1 104, a location of a recipient is determined. For example, the system determines the location of the person to whom the item is to be delivered. The system can make this determination based, for example, on a location of the recipient's mobile device. The flow continues at decision diamond 1106.

[0073] At decision diamond 1106, it is determined whether the recipient is in the delivery location. That is, it is determined whether the recipient's location can be confirmed. The recipient's location is confirmed if the recipient is in the correct location for the delivery (e.g., at his or her home or office, at the delivery location, etc.). If the recipient's location is confirmed, the flow continues at block 1 108. However, if the recipient's location is not confirmed, the flow continues at block 1 110.

[0074] At block 1 108, a confirmation is transmitted to the delivery agent. For example, the system can transmit the confirmation to the delivery agent's mobile device. The confirmation indicates that the recipient's location has been confirmed and that the delivery agent can deliver the item.

[0075] As previously discussed, if the recipient's location is not confirmed, the flow continues at block 1110. At block 11 10, an instruction to refuse delivery is transmitted to the delivery agent. For example, the system can transmit the instruction to refuse delivery to the delivery agent's mobile device. Because the recipient's location has not been confirmed, the delivery agent should not deliver the item.

[0076] While the discussion thus far describes retailers delivering to customers, in some embodiments, the system described herein can be used to facilitate deliveries from the customers to the retailer. In other words, the customer takes the role of the retailer in that the customer, for example, via a computer transmits a notification to the system indicating that the customer would like a package to be delivered to the retailer. Such embodiments are useful for returning purchased items, disposing of materials (e.g., hazardous materials), etc.

[0077] Those skilled in the art will recognize that a wide variety of other modifications, alterations, and combinations can also be made with respect to the above described embodiments without departing from the scope of the invention, and that such modifications, alterations, and combinations are to be viewed as being within the ambit of the inventive concept.

[0078] In some embodiments, a system for creating a crowdsourced delivery plan for a package comprises a certification system, the certification system configured to receive, from a retailer, an indication of items included in the package, determine, based on the indication of items included in the package, a set of requirements, and transmit, to a plurality of portable devices, information regarding the delivery, each of the plurality of portable devices configured to receive, from the certification system, the information regarding the delivery, transmit, to the certification system, an acceptance of the delivery, wherein only ones of the plurality of portable devices associated with delivery agents meeting the set of requirements is capable of acceptance of the delivery, receive, in response to the transmission of the acceptance of the delivery, an authorization, and present, at a pickup point, the authorization.

[0079] In some embodiments, a system and a corresponding method performed by the system comprises receiving, at a certification system from a retailer, an indication of items included in a package, determining, based on the indication of the items included in the package, a set of requirements, transmitting, to a plurality of portable devices, information regarding a delivery, receiving, from the certification system, the information regarding the delivery, transmitting, to the certification system, an acceptance of the delivery, wherein only ones of the plurality of portable devices associated with delivery agents meeting the set of requirements is capable of acceptance of the delivery, receiving, in response to the transmission of the acceptance of the delivery, an authorization, and presenting, at a pickup point, the authorization.

Claims

CLAIMS What is claimed is:

1. A system for creating a crowdsourced delivery plan for a package, the system

comprising:

a certification system, the certification system configured to:

receive, from a retailer, an indication of items included in the package;

determine, based on the indication of items included in the package, a set of requirements; and

transmit, to a plurality of mobile devices, information regarding the delivery; each of the plurality of mobile devices configured to:

receive, from the certification system, the information regarding the delivery; transmit, to the certification system, an acceptance of the delivery, wherein only ones of the plurality of mobile devices associated with delivery agents meeting the set of requirements is capable of acceptance of the delivery; receive, in response to the transmission of the acceptance of the delivery, an authorization; and

present, at a pickup point, the authorization.

2. The system of claim 1, wherein the certification system is further configured to:

determine, from a list of delivery agents based on the set of requirements, the delivery agents meeting the set of requirements, wherein the transmission of the information regarding the delivery is only to the ones of the plurality of mobile devices associated with the delivery agents meeting the set of requirements.

3. The system of claim 1, wherein each of the plurality of mobile devices is further configured to:

determine whether a delivery agent associated with one of the plurality of mobile devices meets the set of requirements; and if the delivery agent associated with the one of the plurality of mobile devices meets the set of requirements, present, via the one of the plurality of mobile devices, the information regarding the delivery; and

if the delivery agent associated with the one of the plurality of mobile devices does not meet the set of requirements, not present the information regarding the delivery.

4. The system of claim 1, wherein each of the delivery agent has one or more certifications, and wherein the set of requirements included specific required certifications.

5. The system of claim 4, wherein indications of each of the delivery agents and the one or more certifications are maintained as data in one or more blocks of a blockchain system, wherein each of the one or more blocks contains a hash of at least some of the data, and wherein the one or more blocks are accessible by at least one of the certification system and the plurality of mobile devices.

6. The system of claim 4, wherein the certifications include one or more of age, ratings, ability to use one or more of the items, ability to install one or more of the items, criminal history, medical history, type of vehicle used for delivery, length of delivery experience, and education.

7 The system of claim 1, wherein the authorization is based on a hash.

8. The system of claim 7, wherein the authorization is a code.

9. The system of claim 1, wherein each of the plurality of mobile devices includes an application associated with the certification system.

10. The system of claim 1, wherein the retailer includes a customer of the retailer.

11. The system of claim 1, wherein the control circuit is further configured to:

receive presentation of the authorization; and determine a location of the delivery agent, wherein

if the location of the delivery agent is confirmed, allow retrieval of the package; if the location of the delivery agent is not confirmed, not allow retrieval of the package

12. The system of claim 1, wherein the control circuit is further configured to:

receive, from the delivery agent, a request to deliver the package; and

determine a location of the delivery agent, wherein

if the location of the delivery agent is confirmed, transmit, to the delivery agent, a confirmation;

if the location of the delivery agent is not confirmed, transmit, to the delivery agent, an instruction to refuse delivery.

13. A method for creating a crowdsourced delivery plan for a package, the method comprising:

receiving, at a certification system from a retailer, an indication of items included in the package;

determining, based on the indication of items included in the package, a set of

requirements;

transmitting, to a plurality of mobile devices, information regarding the delivery;

receiving, from the certification system, the information regarding the delivery;

transmitting, to the certification system, an acceptance of the delivery, wherein only ones of the plurality of mobile devices associated with delivery agents meeting the set of requirements is capable of acceptance of the delivery;

receiving, in response to the transmission of the acceptance of the delivery, an

authorization; and

presenting, at a pickup point, the authorization.

14. The method of claim 13, further comprising:

determining, by the certification system from a list of delivery agents based on the set of requirements, the delivery agents meeting the set of requirements, wherein the information regarding the delivery is only transmitted to the ones of the ones of the plurality of mobile devices associated with the delivery agents meeting the meeting the set of requirements.

15. The method of claim 13, further comprising:

determining, by each of the plurality of mobile devices, whether a delivery agent

associated with one of the plurality of mobile devices meets the set of requirements; and

if the delivery agent associated with the one of the plurality of mobile devices meets the set of requirements, presenting, via the one of the plurality of mobile devices, the information regarding the delivery; and

if the delivery agent associated with the one of the plurality of mobile devices does not meet the set of requirements, not presenting the information regarding the delivery.

16. The method of claim 13, wherein each of the delivery agents has one or more certifications, and wherein the set of requirements includes specific required certifications.

17. The method of claim 16, wherein indications of each delivery agent and the one or more certifications are maintained as data in one or more blocks of a blockchain system, wherein each of the one or more blocks contains a hash of at least some of the data, and wherein the one or more blocks are accessible by at least one of the certification system and the plurality of mobile devices.

18. The method of claim 16, wherein the certifications include one or more of age, ratings, ability to use one or more of the items, ability to install one or more of the items, criminal history, medical history, type of vehicle used for delivery, length of delivery experience, and education.

19. The method of claim 13, wherein the authorization is based on a hash.

20. The method of claim 19, wherein the authorization is a code.

21. The method of claim 13, wherein each of the plurality of mobile devices includes an application associated with the certification system.

22. The method of claim 13, wherein the retailer includes a customer of the retailer.

23. The method of claim 13, further comprising:

receiving presentation of the authorization; and

determining a location of the delivery agent, wherein

if the location of the delivery agent is confirmed, allowing retrieval of the

package;

if the location of the delivery agent is not confirmed, not allowing retrieval of the package.

24. The method of claim 13, further comprising:

receiving, from the delivery agent, a request to deliver the package; and

determining a location of the delivery agent, wherein

if the location of the delivery agent is confirmed, transmitting, to the delivery agent, a confirmation;

if the location of the delivery agent is not confirmed, transmitting, to the delivery agent, an instruction to refuse delivery.