US20210304137A1

US20210304137A1 - Systems and methods for dynamic crowdsourced delivery

Info

Publication number: US20210304137A1
Application number: US16/938,289
Authority: US
Inventors: Brian M. Kursar
Original assignee: Toyota Connected North America Inc
Current assignee: Toyota Connected North America Inc
Priority date: 2020-03-27
Filing date: 2020-07-24
Publication date: 2021-09-30
Also published as: US20210300297A1

Abstract

System and methods described herein relate to crowdsourced delivery, including receiving a delivery request, selecting a plurality of participants, determining a delivery route including at least one transfer of the parcel between a first participant and a second participant of the plurality of participants, with at least the first participant operating a vehicle having a secure storage locker that includes at least one secure compartment to hold the parcel, generating access keys including at least a first access key that enables access to the secure storage locker and a second access key that enables access to a secure compartment in the storage locker, transmitting the access keys to the second participant, distributing delivery tasks, based on the delivery route, to the plurality of participants, wherein completion of the delivery tasks results in delivery of the parcel to the delivery destination, and monitoring completion of the delivery tasks by the plurality of participants.

Description

TECHNICAL FIELD

The subject matter described herein relates, in general, to delivering goods from place to place, and, more particularly, to systems and methods for implementing and controlling crowdsourced delivery of goods.

BACKGROUND

Retailers, whether on-line or local, are constantly looking for faster and more efficient ways to deliver their products to consumers. Traditionally, the bulk of such deliveries has been handled by major common carriers such as the United States Postal Service (USPS), United Parcel Service (UPS), FedEx, etc. Vehicles that are owned by individuals or entities (e.g., businesses, restaurants, etc.) who use them to travel from place to place and are not employed by a common carrier represent a large untapped resource for carrying parcels from a starting point (e.g., a retail store or a warehouse) to a consumer.

SUMMARY

Example systems and methods are disclosed for implementing and controlling crowdsourced dynamic delivery of goods. In one approach, the disclosed embodiments can implement and control a flexible and dynamic crowdsource delivery service that monitors and selects participant vehicles to create delivery routes that meet predefined delivery criteria.
In one embodiment, a system for implementing and controlling crowdsourced delivery of a parcel is disclosed. The system can include a network interface configured to communicate wirelessly and to receive, from a user, a delivery request for the parcel, the delivery request indicating at least a pick-up location and a delivery destination. The system can include one or more processors and a memory communicably coupled to the one or more processors.
The memory can store a matching module including instructions that when executed by the one or more processors cause the one or more processors to determine a delivery route for the parcel and select a plurality of participants to execute delivery of the parcel the delivery route including at least one transfer of the parcel between a first participant and a second participant of the plurality of participants, with at least the first participant operating a vehicle having a secure storage locker that includes at least one secure compartment to hold the parcel.
The memory can also store an access module including instructions that when executed by the one or more processors cause the one or more processors to generate access keys including at least a first access key that enables access to the secure storage locker and a second access key that enables access to a secure compartment in the storage locker.
The memory can further store a participant management module including instructions that when executed by the one or more processors cause the one or more processors to distribute delivery tasks, based on the delivery route, to the plurality of participants, transmit the access keys to the second participant, and monitor completion of the delivery tasks by the plurality of participants. Completion of the delivery tasks results in delivery of the parcel to the delivery destination.
In another embodiment, a method for implementing and controlling crowdsourced delivery of a parcel is disclosed. The method includes receiving, from a user, a delivery request for the parcel, the delivery request indicating at least a pick-up location and a delivery destination, selecting a plurality of participants to execute delivery of the parcel, and determining a delivery route for the parcel, the delivery route including at least one transfer of the parcel between a first participant and a second participant of the plurality of participants, with at least the first participant operating a vehicle having a secure storage locker that includes at least one secure compartment to hold the parcel.
The method further includes generating access keys including at least a first access key that enables access to the secure storage locker and a second access key that enables access to a secure compartment in the storage locker, transmitting the access keys to the second participant, distributing delivery tasks, based on the delivery route, to the plurality of participants, wherein completion of the delivery tasks results in delivery of the parcel to the delivery destination, and monitoring completion of the delivery tasks by the plurality of participants.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate various systems, methods, and other embodiments of the disclosure. It will be appreciated that the illustrated element boundaries (e.g., boxes, groups of boxes, or other shapes) in the figures represent one embodiment of the boundaries. In some embodiments, one element may be designed as multiple elements or multiple elements may be designed as one element. In some embodiments, an element shown as an internal component of another element may be implemented as an external component and vice versa. Furthermore, elements may not be drawn to scale.

FIG. 1 illustrates various aspects of a crowdsourced parcel delivery system, in accordance with an illustrative embodiment of the invention.

FIG. 2 illustrates one embodiment of a crowdsourced parcel delivery system according to the disclosed embodiments.

FIG. 3 illustrates an example of the crowdsourced parcel delivery system identifying candidates according to the disclosed embodiments.

FIG. 4 illustrates an example of the crowdsourced parcel delivery system generating routes according to the disclosed embodiments.

FIG. 5 illustrates a flowchart of a method of implementing and controlling a system for crowdsourced delivery of a parcel according to the disclosed embodiments.

DETAILED DESCRIPTION

In various embodiments described herein, a crowdsourced parcel delivery system provides a service through which a parcel may be carried for at least a portion of its delivery route by one or more participants who are willing to carry or store parcels in exchange for some kind of compensation (e.g., reward points or money). Crowdsourced shipping can be applied to the so-called “middle mile” between the retail store or warehouse and a hub (e.g., a distribution center) relatively close to the destination, to the so-called “last mile” from that final hub to the destination, or both.
Throughout this description, the term “parcel” means any item, including items products, food, living things such as animals or plants, etc., or other object that is transported from a point of origin (e.g., store or warehouse) to a destination (e.g., a residence or place of business). Also, for the purposes of this description, a “consumer” is a person who purchases an item, e.g., from an on-line or local retailer, and who specifies the location to which the item should be delivered. The term “user,” as in a user of the disclosed delivery system, is sometimes used interchangeably with “consumer.”
Herein, a “participant” is a person who owns and/or operates a vehicle and participates in the disclosed crowdsourced parcel delivery operation by storing and/or transporting a parcel in the vehicle in accordance with parameters determined by the crowdsourced parcel delivery system. The term “driver” is sometimes used interchangeably with “participant.” The term “vehicle” herein refers to any form of motorized transport, such as a pod, an automobile, e.g., a hybrid/electric automobile, an autonomous/semi-autonomous automobile, a combination thereof, etc. While arrangements will be described herein with respect to automobiles, it will be understood that embodiments are not limited to automobiles. Herein, a “common carrier” refers to a commercial delivery service such as USPS, UPS, FedEx, etc.
FIG. 1 illustrates a general overview of a crowdsourced parcel delivery system 100 according to the disclosed embodiments. As will be discussed further below, the crowdsourced parcel delivery system 100 may be implemented, for example, as one or more cloud/edge computing devices, a server, or other network connected computing device capable of storing data, executing instructions and communicating with multiple entities in carrying out the functions described herein. In one or more embodiments, the crowdsourced parcel delivery system 100 can be operated by a vehicle manufacturer that produces vehicles having features specifically designed to implement certain features discussed herein, but the disclosed embodiments are not limited to this type entity operating the disclosed system. Other entities may also implement the disclosed embodiments in different ways, for example, through after-market modifications and other products.
Referring to FIG. 1, in one or more embodiments the crowdsourced parcel delivery system 100 can receive a delivery request 111 from a user, e.g., a retailer 110. The delivery request 111 can include various types of information, including pickup/drop-off locations and delivery criteria, such as transport preferences (e.g., refrigerator, heated, ventilated, etc.), timing preferences, alternate drop-off locations, etc. In response to the delivery request 111, the crowdsourced parcel delivery system 100 can analyze a network of participants 130 to automatically identify, select, and manage a plurality of participants 130 to complete the delivery request 111 according to the delivery criteria.
At an operational level, the crowdsourced parcel delivery system 100 provides multiple functions that may generally be categorized as matching management 101, access management 102, and participant management 103. The participants 130 provide travel/traffic information and provide storage and/or transportation services.
Storage services and transportation services may be viewed as distinct services provided within the context of the crowdsourced parcel delivery system 100. For example, as will be discussed further below, a participant 130 may be operating a stationary unit (e.g., a parked vehicle) and provide only storage service or may be operating a mobile unit (e.g., a traveling vehicle) and provide both storage and transportation service.
Continuing the description of FIG. 1, the participants 130 provide the crowdsourced parcel delivery system 100 with information, including travel information 131 and delivery capacity 132. Travel information 131 can include travel status (i.e., currently stationary, upcoming scheduled route, currently moving, etc., as well as information regarding traffic conditions in a vicinity of the participant 130), and real-time location of the participant 130. Providing real-time location enables the crowdsourced parcel delivery system 100 to determine which participant 130 or combination of participants 130, through a series of handoffs along a particular route, are able to fulfill the delivery request 111 and convey the parcel to its ultimate destination or, for example, to a hub from which another carrier (e.g., a common carrier) can perform last-mile delivery.
In one or more embodiments, the crowdsourced parcel delivery system 100 determines real-time location by tracking participants 130 based on the participants 130 frequently reporting GPS coordinates transmitted over a network (e.g., cellular data) to the system 100. In other embodiments, the system 100 tracks the real-time location of participants 130 based on receiving a reported location of a mobile computing device (e.g., a smartphone) carried by an owner/driver. In any case, participants 130 agree to tracking terms prior to participating in the crowdsourced parcel delivery system 100, for example, to earn rewards such as points or cash. Real-time tracking of vehicles, in the context of the embodiments described herein, is, therefore, expected and does not result in privacy violation.
As previously stated, in addition to travel information 131 a participant 130 can also inform the crowdsourced parcel delivery system 100 of a delivery capacity 132 of the participant. Delivery capacity 132 can include a report on the availability of a participant 130 to take part in a delivery as well as the availability and features of compartments within a storage area of the participant 130. In one or more embodiments, vehicles that operate as participants 130 may include original or aftermarket enhancements that are designed for providing specific services within the crowdsourced parcel delivery system 100. Example enhancements, such as multiple secured and climate-controlled compartments within a vehicle's trunk, are discussed in greater detail below. Delivery capacity 132 can convey the status and features of such compartments.
Referring to the crowdsourced parcel delivery system 100, matching management 101 generally handles identifying and selecting participants 130 to convey the parcel while attempting to meet requirements established by delivery criteria included in the delivery request 111. In one or more embodiments, matching management 101 can include a predictive destination function and a participant selection function.
The predictive destination function is configured to intelligently generate predicted travel plans of one or more participants 130 based on historical data that indicates driving habits of the participants 130. The historical data can include, for example, past routes traveled by a given participant, dates and times of the past routes, and a time log of completed deliveries.
The participant selection function selects participants 130 to include in the delivery process based on the predicted travel plans, travel information and delivery capacity obtained from the participants 130, as well as the delivery criteria indicated in the delivery request 111. These two functions, predictive destination and participant selection, are discussed in greater detail below.
Access management 102 includes functions of scheduling (i.e., logistics, drop-off/pickup, transfers, etc.) and generating and/or managing access keys to facilitate secure movement of a parcel through multiple participants 130 along a delivery route. A delivery route can involve multiple parties and include a mixture of stationary hubs (e.g., a parked vehicle, a store, public locker facility, participant's place of business, etc.) and mobile hubs (e.g., moving vehicles), depending on the particular embodiment and the particular parcel being shipped. Key control refers to controlling who has access to the parcel as it is transported on a delivery route and at what times access is permitted. In one or more embodiments, access management 102 can include utilizing a machine learning model for determining a number of handoffs, access times, etc.
Participant management 103 includes functions to manage compensation/rewards for participants 130 and software/hardware interfaces between the crowdsourced parcel delivery system 100 and: (1) users, such as nation-wide stores, on-line stores, resellers, small local retailers, individuals, consumers, etc. and (2) participants 130 who participate in the system by storing and/or transporting parcels.
Regarding the interface with users, the crowdsourced parcel delivery system 100 can include backend communication systems that seamlessly communicate with a retailer's point-of-sale (POS) system such that when a consumer purchases an item from the retailer, the retailer's POS system, in presenting shipping options to the consumer, can include the option of shipment via the crowdsourced parcel delivery system 100 described herein. Regarding the interface with participants 130, the system 100 can include, for example, a website and/or a mobile app (e.g., for smartphones, tablet computers, etc.) for participants 130 to access that allows the crowdsourced parcel delivery system 100 to communicate with the participants 130. For example, the system 100 can send participants 130: invitations (e.g., via text message, app-notification, etc.) to accept delivery tasks, updates regarding handoffs to other participants 130, updates regarding changes to the delivery route, updates regarding earned rewards/compensation, and other communications.
The compensation function of participant management 103 operates to dispense rewards (e.g., monetary rewards, points, etc.) to participants 130 for completing delivery tasks. For example, in one or more embodiments, a participant 130 that repeatedly completes delivery points can earns points that accumulate over time. The points can have an associated value that can be spent or redeemed with a vehicle manufacturer, a retailer, or one or more other entities. In one or more embodiments, the crowdsourced parcel delivery system 100 can dispense rewards in the form of a gift card, a discount on future purchases, or other incentives.
In one or more embodiments participant management 103 dispenses cash payments (e.g., a direct deposit in a bank account) to participants 130 as compensation. For example, in one or more embodiments, for a given parcel delivery that the user pays a delivery fee to fulfill, the entity implementing the crowdsourced parcel delivery system 100 may receive a percentage of the delivery fee and the participants 130 who provide transportation and/or storage services to convey the parcel may also receive a percentage of the delivery fee.
In one or more embodiments, the crowdsourced parcel delivery system 100 can dispense rewards as a fixed amount per delivery or rewards that can vary depending on various factors such as distance, travel time, time of day, peak periods, day of the week, size or number of parcels in a single order, number of deliveries, etc. Accordingly, a participant 130 may be motivated to participate in the disclosed crowdsourced parcel delivery service by the opportunity to earn extra money or other rewards by carrying parcels for others as they travel from place to place along routes they frequently or incidentally travel (e.g., from home to work or vice versa).
FIG. 2 shows an example block diagram of an embodiment of a crowdsourced parcel delivery system 100. The crowdsourced parcel delivery system 100 is shown including one or more processors 210, a memory 220, database 230, and a network interface 240. In other embodiments, more or fewer components than those shown can be included according to a given implementation. Generally, the crowdsourced parcel delivery system 100 can be constructed as, for example, a central server, a cloud server, an edge server, a cloud-based computing device, or one or more network servers, particularly Internet accessible servers, including a network interface 240 configured to connect the processor 210 to the network, such as the Internet or a cellular telephone network.
The memory 220 can be implemented as a random-access memory (RAM), read-only memory (ROM), a hard-disk drive, a flash memory, or other suitable memory for storing, among other things, a matching module 250, access module 260 and a participant management module 270. The modules 250, 260 and 270 will be described further below.
The database 230 can store, among other information, delivery request data 280, map data 285, participant data 290, and historical data 295 which will be also described further below. The database 230 is, in one or more embodiments, an electronic data structure that can be a data store. The database 230 is configured with routines that can be executed by the processor 210 for analyzing stored data, accessing and providing stored data, organizing stored data, and so on. Thus, in one embodiment, the database 230 stores and manages/updates data, such delivery request data 280, map data 285, participant data 290, historical data 295, as well as other types of data that is used by modules 250, 260 and 270 in executing various functions.
In one or more embodiments, the crowdsourced parcel delivery system 100 can store incoming delivery requests as part of delivery request data 280 in the system database 230. In one or more embodiments, the delivery request data 280 can include one or more tables or databases that store records of each delivery request received and associated data such as current status (e.g., accepted, unassigned, assigned, in-progress, current segment of delivery, complete, etc.), agreed compensation for the delivery, timestamp data and other related data and metadata.
In one or more embodiments, the crowdsourced parcel delivery system 100 can store and update map data 285 that provides regional maps (e.g., street maps) that the crowdsourced parcel delivery system 100 can analyze to determine delivery routes. The crowdsourced parcel delivery system 100 can store supplemental data associated with the map data 285, such as traffic reports, accident reports, weather reports, etc., and utilize the supplemental data to aid in determining optimal routes and dynamic adjustments.
A participant 130 may register an account with the crowdsourced parcel delivery system 100 as a prerequisite for accepting jobs. In response, the system 100 can create a profile for the participant 130 and store the profile as participant data 290, which may be stored in one or more tables or databases within the system database 230. The profile can store, among other things, an identification code, biometric data for access to secure components in execution of a delivery, preferred compensation method and associated information (e.g., direct deposit account information), a consistency rating (discussed further below) and communication information (e.g., registered app, vehicle app, cellphone number, etc.) that allows the crowdsourced parcel delivery system 100 to transmit job invitations to the participant 130 and to receive travel information and delivery capacity information from the participant 130. The profile can also be mapped to an associated vehicle by VIN or license plate number. The profile can also include performance/satisfaction ratings from consumers and/or other drivers, which are separate and distinct from the consistency rating.
As shown in FIG. 2, the crowdsourced parcel delivery system 100 can receive a delivery request 111 from a user, for example, a retailer 110. The delivery request 111 can include various types of information, such as a description of the parcel to be delivered, a pickup location (e.g., address of the retailer 110), a drop-off location (e.g., address of the consumer that purchased the item being delivered) and delivery criteria (e.g., user preferences specific to each individual delivery).
The matching module 250 generally includes instructions that function to control the processor 210 to determine a delivery route for the parcel and to select a plurality of participants 130, 135 to execute delivery of the parcel along the delivery route. Although only two participants 130, 135 are shown in FIG. 2, it should be understood that this number was chosen merely for illustrative purposes and any number of participants can be selected. At least one of the participants 130, 135 transports the parcel in a secure inner compartment of a secure storage locker. The access module 260 generally includes instructions that function to control the processor 210 to generate, for at least one of the plurality of participants 130, 135, access keys that allow access to the secure storage locker and the secure compartment to facilitate a handoff of the parcel. The participant management module 270 generally includes instructions that function to control the processor 210 to distribute delivery tasks 112, based on the delivery route, to the plurality of participants 130, 135, transmit the access keys, and monitor completion of the delivery tasks 112.
To select the participants for a given delivery, in one or more embodiments the matching module 250 can identify a pool of candidates for the delivery, rate the candidates according to various factors (e.g., availability, consistency rating, current travel status, current location, current storage features/capability, alignment with potential delivery route, etc.) and invite one or more of the candidates to accept delivery tasks 112 and thereby cooperatively execute delivery of the parcel.
FIG. 3 shows an example scenario of the crowdsourced parcel delivery system 100 identifying candidates for a delivery. For example, in one or more embodiments the matching module 250 can examine a region 300 to identify a plurality of participants 130, 135, 140, 145 as candidates. The matching module 250 can identify the participants 130, 135, 140, 145 as being within the region 300, for example, based on travel information (e.g., location, current route, etc.) stored in the participant data 290.
For a delivery route having a first segment that begins at the delivery pickup location (e.g., of retailer 110), the matching module 250 can analyze participant data 290 to identify candidates that are available to participate, possess required delivery capacity (e.g., available inner compartments that meet the requirements of the delivery request) and are currently within a threshold distance of a delivery pickup location (e.g., of retailer 110). In one or more embodiments, the matching module 250 can generate a rating score to rank each candidate, transmit a delivery task invitation to the highest ranked candidate, and continue to advance down the rank until a candidate accepts.
Generally, a delivery route can include multiple segments and require at least one transfer of the parcel, for example, between a first participant 130 and a second participant 135. In determining a delivery route, the matching module 250 can create one or more potential delivery routes and select an optimal route to execute. In one or more embodiments, the matching module 250 can dynamically create new segments in a delivery route according to circumstances that arise during a delivery, as will be discussed further below.
FIG. 4 shows example routes generated by the matching module 250 according to the disclosed embodiments. For example, the matching module 250 may receive a delivery request indicating a pickup location 400 (e.g., a retail store such as retailer 110 from FIG. 3) and a delivery destination 410 (e.g., a user residence). The matching module 250 can analyze a regional map 415 stored in map data 285 to determine a first route that proceeds from the pickup location 400 (e.g. a retail store) along segment 420 to a handoff location 425, then proceeds along segment 430 to the delivery destination 410, and a second route that proceeds from the pickup location 400 along segment 440 to a handoff location 445, then proceeds along segment 450 to the delivery destination 410.
Since a route may have one or more handoffs between participants, to facilitate secure transfer of the parcel each of the participants 130 can operate a vehicle (or in some instances, a facility) that includes a secure storage locker that has multiple secure compartments. That is, the secure storage locker comprises an outer housing that may be locked to secure the inner compartments, and each of the inner compartments may be locked to secure individual parcels. The inner compartments may have different sizes/shapes and/or different features (e.g., refrigerated, disinfected, warmed, ventilated, etc.) to match different parcel transport needs. In this manner a participant may transport or store multiple parcels while only allowing authorized individuals to access any specific parcel. The access to a parcel is therefore protected by at least two layers of security, i.e., the secure storage locker itself and the secure inner compartment. In one or more embodiments, the parcel can be transported within a secure container that is placed inside of secure inner compartment, thereby providing a third layer of security.
Referring to FIG. 2, the access module 260 can generate, for each of the participants 130, 135, access keys 114 that enable access to the secure storage locker, the secure compartment and, when applicable, the secure container used to transport the parcel. The access keys 114 can be implemented in any of various ways depending on implementation of the locking mechanisms of the secure storage locker and the inner compartments. For example, in one or more embodiments the access keys 114 can be implemented as an access code to be entered (e.g., via touch screen, keypad, etc.), a code associated with biometric data (i.e., of the drivers) of the participants 130, 135, a code associated with a scannable image transmitted to and displayed on mobile devices belonging to participants 130, 135, a code associated with a wireless signal such as a Bluetooth or near field communication (NFC) signal to be transmitted to and broadcast from mobile devices belonging to participants 130, 135, or another type of access key that can be provided to the participants 130, 135.
The access module 260 can dynamically manage timing windows during which the access keys 114 are valid based on a handoff/pickup schedule per route. For example, referring to FIG. 4, in one example scenario the matching module 250 selects two participants to execute delivery of the parcel. The matching module 250 assigns a first participant the delivery tasks of picking up the parcel from the pickup location 400 at 12:00 and transporting the parcel from the pickup location 400 to the handoff location 425 along route segment 420. The matching module 250 assigns a second participant the delivery tasks of picking up the parcel from the handoff location 425 and transporting the parcel to the delivery destination 410. The handoff location 425 may be, for example, a parking lot at a store or an office building that first participant is traveling to.
The access module 260 can estimate a time that the first participant should arrive at the handoff location 425 (e.g., 12:15) and estimate a time that the second participant should arrive at the handoff location 425 (e.g., 12:30). Based on the estimated arrivals, the access module 260 can generate access keys for the second participant that are valid only for a timing window estimated to include both arrivals (e.g., 12:10 to 12:40). Thus, the first participant can park at the handoff location 425 and leave the vehicle (e.g., enter the store, enter the office building, etc.) as usual without waiting for the second participant. The second participant can utilize the access keys to retrieve the parcel from the vehicle of first participant at the handoff location 425 during the timing window.
In one or more embodiments, the access module 260 can issue access keys to participants on an only as-needed basis. For example, in a three-layer security implementation (i.e., secure storage locker, secure inner compartment, secure container), the access module 260 can issue access keys to only the first two layers for a participant that is transporting the parcel between handoff locations and therefore does not need to have access to the secure container.
In one or more embodiments, the matching module 250 and the access module 260 can include instructions to determine the delivery destination of a parcel dynamically within a given time frame or context. For example, the delivery criteria associated with a particular delivery request may specify that a parcel is to be delivered to the user's (or other recipient's) workplace if the parcel is delivered between 9 a.m. and 5 p.m., Monday through Friday, and otherwise the parcel is to be delivered at the user's (or other recipient's) residence. In this example, the crowdsourced parcel delivery system 100 could dynamically take the time of day into account in the operations of the matching module 250 and access module 260 to arrange for the parcel to be delivered at the destination in accordance with the delivery request instructions.
Furthermore, if delays occur over the course of a delivery that prevent the delivery or a handoff from being completed within the original time estimate, the crowdsourced parcel delivery system 100 (e.g., matching module 250 and access module 260) can automatically adjust the delivery route in response. That is, the system 100 (e.g., participant management module 270) can monitor the progress of completion of assigned delivery tasks for a delivery and determine that the original delivery criteria will no longer be met. When this occurs, the system 100 (e.g., matching module 250 and access module 260) can determine a new route optimized to the new circumstances. This feature may be referred to as “dynamic delivery.”
As described above, the participants can have associated profiles in the disclosed crowdsourced parcel delivery system 100 and the system 100 can provide compensation to the participants for completed delivery tasks. Referring back to FIG. 2, the participant management module 270 can manage completion of delivery tasks 112, including transmitting delivery tasks 112 to participants based on a selected delivery route, transmitting access keys as part of the delivery task transmission, and monitoring completion of the delivery tasks 112, e.g., to determine whether a dynamic change in the delivery route should be implemented. The participant management module 270 can furthermore monitor travel patterns of participants, store a historical record of monitored participant travel patterns as historical data 295 and calculate/update a consistency rating for participants that indicates a degree of consistency in travel, as will be discussed further below. In addition, based in part on the historical records maintained by the participant management module 270, the matching module 250 can predict a given participant's location, next destination, and/or dwell time at a particular destination, for a given time. These predictions may be incorporated into the candidate rating score by the matching module 250 in the participant selection process.
As a further enhancement to matching and selection features, in one or more embodiments the crowdsourced parcel delivery system 100 can implement a consistency rating system that indicates a participant's level of predictability and consistency in his or her driving habits. For example, a participant who the system 100 detects travels a relatively small number of routes (e.g., home to work, park for eight hours, back home again, home to church, park for two hours, and back home again, etc.) consistently at approximately the same times day after day and week after week would have a high consistency rating. On the other hand, a participant who the system detects driving varied, unpredictable routes at unpredictable times would have a low consistency rating. In one or more embodiments, the participant management module 270 can store one or more consistency ratings as part of the participant profile.
Note that the consistency rating as disclosed herein is distinct from the typical on-line driver ratings that focus on consumer satisfaction, courtesy, etc. In the disclosed embodiments, the consistency rating measures the degree of accuracy and reliability to which the crowdsourced parcel delivery system 100 can predict the location, destinations, routes and dwell times of a given participant, based on the historical data 295 associated with the participant.
By rating drivers based on consistency, the crowdsourced parcel delivery system 100 can improve the efficiency of parcel transfer scheduling and other aspects of creating delivery routes. For example, the system 100 (e.g., matching module 250) can rank participants with high consistency ratings higher in candidate selection pools or otherwise weight the consistency rating in a score calculated per candidate. Moreover, in one or more embodiments the system 100 (e.g., matching module 250) can use the consistency rating to select participants for delivery requests that do not interfere with their daily routines so they can drive their normal routes while delivering packages and earning money or other rewards.
In one or more embodiments, to determine a consistency rating for a participant the participant management module 270 can monitor participant driving-patterns continuously, discretely based on select days and/or time ranges, or selectively, in which monitoring may be suspended at times. For example, a participant may manually suspend certain days or non-routine trips (e.g., during a vacation or period of illness) from counting against his or her consistency rating. The participant may also select discrete monitoring days by identifying blackout days or time ranges within one or more days. For example, a participant may not work on Sundays, does not intend to accept delivery tasks on Sundays, and does not want Sunday trips with his family to count against his consistency rating. Therefore, he may block out all Sundays from counting in the rating. The system 100 may also detect such patterns and use that to factor in the driver's lack of availability for any deliveries on Sundays.
Also, the crowdsourced parcel delivery system 100 (e.g., matching module 250) may selectively count certain days or time frames from a participant historical record and use only the select time or day rating in a creating a predictability model. For example, when selecting candidates based in part on participant consistency ratings, the system 100 may determine a predictability model for a participant based on her driving history over the day and time the delivery is scheduled for (e.g., Tuesday between 3:00 and 6:00 p.m.). That is, the predictability model for candidate selection may take into account the participant consistency over past Tuesdays between 3:00 and 6:00 p.m.
The crowdsourced parcel delivery system 100 (e.g., matching module 250 and/or participant management module 270) may also determine how often a participant has selected to blackout system 100 monitoring. As the number of blackout selections increases, the participant's consistency rating may be adversely impacted. Unscheduled or irregular blackout selections may be weighed more heavily against a consistency rating than consistent, scheduled blackout days or times.
Further, previous delivery data may be used to factor in a driver's predictability model. For instance, timeliness, as in the number or percentage of late arrivals for a delivery or handoff, may be used as another factor in the driver predictability model.
Referring to FIGS. 2, 3 and 4, various features and aspects of a delivery scenario will now be discussed to provide a fuller picture of functions and operations of the disclosed crowdsourced parcel delivery system 100, as well as the cooperation among the various modules and data. It should be understood that this scenario is merely one example provided for illustrative purposes to aid in understanding the disclosed subject matter. The disclosed embodiments are not limited to the particulars of the scenario.
In FIG. 2, a retailer 110 processes a consumer's purchase of an item. The retailer 110 transmits a delivery request 111 to the crowdsourced parcel delivery system 100 for shipment of the item to the consumer according to the consumer's instructions. The delivery request 111 includes a pickup location (i.e., where the item must be picked up from), delivery location (i.e., where the item must be delivered to), and one or more delivery criteria (e.g., heated transport compartment). Based on the information in the delivery request 111, the crowdsourced parcel delivery system 100 (e.g., matching module 250) determines one or more potential delivery routes.
The matching module 250 can select one or more participants to execute delivery tasks and complete the delivery. In FIGS. 2 and 3, the matching module 250 first checks the current location and availability status of vehicles (e.g., owned or driven by participants) in a relevant geographic region 300, for example, by analyzing location information for participants as indicated in participant data 290 stored in the system database 230 and analyzing historical data 295. The matching module 250 can identify a pool of candidates that are available in the geographic region 300 to complete a delivery task. In one or more embodiments, the matching module 250 can identify one or more candidates based on a predicted location of one or more participants based on historical data 295. For example, a participant may currently be outside of the geographic region 300, however, based on trends in historical data 295 associated with the participant the matching module 250 can predict that the participant will be within the geographic region 300 at a relevant time with regards to the delivery being contemplated.
Once the matching module 250 has determined which participants are included in the candidate pool, the matching module 250 then determines which participants are available to accept a delivery request, for example, based on status indicated in participant data 290 or a prediction based on historical data 295. Unavailable participants are removed from the candidate pool.
The matching module 250 can then determine which of the candidates have available capacity (e.g., an available compartment in a trunk-based storage system that meets the requirements, if any, of the delivery criteria). In one or more embodiments, the foregoing factors may be all binary, i.e., resolved with either “Yes” or “No” determination. Furthermore, the factors discussed above do not necessarily need to be considered in the specific order indicated above. In one or more embodiments, the matching module 250 can consider the factor in a different order (e.g., availability first).
With the candidate pool determined, in one or more embodiments the matching module 250 can rank the candidates in terms of compatibility to the delivery and efficiency. For example, the matching module 250 can apply a ranking formula that weights various factors to determine a matching score for each candidate that indicates how suited a candidate is for the delivery. For example, in one or more embodiments the matching module 250 can determine a matching score S for each candidate as follows:
S=(w1)C+(w2)D+(w3)R Eq. 1
where C is a parameter indicating a consistency rating of the candidate, D is a number of delivery criteria met by the candidate, R is a distance value indicating how far the candidate is from the delivery route, and w1, w2 and w3 are weight values. It should be understood that the ranking formula presented in Eq. 1 is merely one example of a ranking formula according to the disclosed embodiments. In different implementations of the disclosed crowdsourced parcel delivery system 100 different parameters and more complex arithmetic formulation may be utilized.
Accordingly, the matching module 250 can account for the diversity of features and traits that may exist within a candidate pool and attempt to make a best selection based on the ranking the candidates by their matching score. For example, in a given candidate pool some of the candidates may have a climate-controlled compartment available, as preferred by a given delivery request, while others may not. Likewise, some candidates may be relatively close to the delivery route while others are relatively far from the delivery route. Lacking certain traits may not completely disqualify a candidate for delivery selection, but it may make a candidate less desirable than other candidates. The matching score can account for such differences and allow the matching module 250 to first pursue better matching candidates over less desirable but still qualified candidates, while still retaining identification of qualified candidates as backups in the event that better qualified candidates decline or otherwise become unavailable.
After ranking the candidates, the matching module 250 can identify the highest ranking candidates and assign the candidates delivery tasks according to a determined delivery route. The participant module 270 can transmit the delivery tasks to the candidates in the form of a job request, for example, via an app notification, text message, email, etc., that provides the candidate with details regarding the assigned delivery task. If the candidate accepts the job request, the access module 260 determines access keys required for the candidate to complete the delivery task, determines the timing windows of access, and transmits the access keys, as discussed above.
After a participant has accepted a delivery task, the ability of the system 100 to predict the participant's location and route for the duration of the delivery significantly increases. The disclosed crowdsourced parcel delivery system 100 can leverage increased prediction efficiency to offer the participant opportunities to take on one or more additional parcels while that participant is already engaged in carrying a parcel. Such an option is particularly attractive to participants who want to participate actively in crowdsourced shipping to earn additional rewards. Furthermore the system 100 can quantify the increased predictability, for example, as an increased predictability level for a given delivery as part of the service. For example, for a customer who desires increased predictability, the system 100 can attempt to utilize (e.g., weight more heavily in a ranking process) participants who are currently on delivery routes and are therefore highly predictable in terms of location and travel plans.
In one or more embodiments, some participants may elect to participate at a passive level only in which they merely provide storage space to third parties or other participants who drop off or pick up parcels wherever the passive participant's vehicle happens to be located at the time. The matching module 250 can detect the presence of such passive participants within a geographic region and utilize the vehicle or facility of a passive participant as a handoff point, allowing active participants to drop-off or pickup parcels at the location of the passive participant without waiting or actually needing to meet face to face with another participant to complete a handoff.
It should also be clear that participants may choose to participate at a mixed passive/active level in varying degrees. For example, such a participant might indicate in a profile setting that the participant is willing, for example, to carry a parcel to another location (e.g., another vehicle, a locker, a person's home) a limited distance from a passive location (e.g, the participant's place of work). The system can assign such a mixed active/passive participant delivery tasks that are within a scope of travel that a mixed participant indicates he or she is willing to accept.
At the other end of the spectrum, a fully active participant seeks and actively responds to opportunities to earn additional rewards and may indicate such status, for example, in the participant profile. Consequently, the system 100 can weight such status in determining a match score for the participant, as discussed above, and assign delivery tasks to a fully active participant, including possibly taking on additional parcels while the active participant is en route.
For example, a fully active participant already carrying a parcel might be standing in a checkout line at a retail store. While waiting in line, a mobile app on the participant's smartphone invites the participant to switch checkout lines to accept another parcel from the cashier at the other cash register. In this case, the system 100 can present such an opportunity based on the participant's known current location, predicted next destination (e.g., home), predicted dwell time at the retail store, currently incoming delivery requests, etc.
Furthermore, in one or more embodiments, the selection of participants and assignments of delivery tasks for a delivery can be fluid, flexible and highly dynamic. For example, as circumstances change, the system 100 can quickly select a different participant for a particular segment of a delivery route or even adjust a delivery route to remove segments and include different segments to be assigned to current participants or new participants. Such circumstances can include, for example, a candidate declining to accept a delivery task, a participant failing to complete a delivery task on time, a change in the delivery parameters based on the delivery criteria (e.g., deliver to a first address before 12:00 but to a second address after 12:00). As circumstances that impact completion of a delivery task occur, the system 100 can respond
Therefore, using real-time data and historical information, the crowdsourced parcel delivery system 100 is able to take a current snapshot of the network topology at the time of an entered delivery request, automatically calculate an optimal delivery route using, e.g., machine-learning algorithms (such as Dykstra's algorithm or other adaptive-learning methods), automatically identify a candidate pool, and rank/select participants from the candidate pool to assign one or more delivery tasks to execute the delivery. The system 100 is also able to monitor completion of detect deviations from the estimated delivery time/day through continuous network monitoring and updating using the crowdsourced data collection discussed above.
FIG. 5 illustrates a flowchart of a method 500 of implementing and controlling a system for crowdsourced delivery of a parcel according to the disclosed embodiments. Method 500 will be discussed from the perspective of the crowdsourced parcel delivery system 100 of FIG. 2. While method 500 is discussed in combination with the crowdsourced parcel delivery system 100, it should be understood that the method 500 is not limited to implementation within the crowdsourced parcel delivery system 100, which is merely one example of a system that may implement the method 500. It should further be understood that the order of operations can change in various implementations of the method 500.
At operation 510, the crowdsourced parcel delivery system 100 receives a delivery request for a parcel. The delivery request can indicate at least a pick-up location and a delivery destination. In one or more embodiments the delivery request can include one or more delivery criteria that indicate one or more requirements or preferences designated by the user or customer that submitted the delivery request. In one or more embodiments, the delivery criteria can include one or more of a preferred delivery time, preferred delivery route, and a preferred predictability level.
At operation 515, the crowdsourced parcel delivery system 100 (e.g., matching module 250) determines one or more potential delivery routes based on the delivery request. In one or more embodiments, the delivery route can include at least one including at least one transfer of the parcel between a first participant and a second participant.
At operation 520, the crowdsourced parcel delivery system 100 (e.g., matching module 250) identifies a candidate pool. In one or more embodiments, the matching module 250 can identify registered participants, currently within a geographic region defined based on the one or more delivery routes, that are currently available to accept a delivery task, and that currently have an inner compartment available that meets the requirements, if any, designated by the delivery request.
In one or more embodiments, the matching module 250 identifies the candidate pool by identifying a set of local participants within a geographic range of the pickup location or delivery destination, identifying, within the set of local participants, a subset of available participants that each have an available storage compartment that meets one or more requested features indicated in the delivery request and obtaining, for each available participant in the subset of available participants, travel information indicating at least a predicted route and profile information indicating at least a consistency rating.
It should be understood, again, that the order of operations may be changed with the disclosed subject matter. For example, in one or more embodiments, the crowdsourced parcel delivery system 100 determines the candidate pool before determining the delivery route, generates one or more potential delivery routes based at least in part on the travel information and profile information, each potential delivery route utilizing a combination of available participants from the subset of available participants, and selects the delivery route and the plurality of participants that meet a predefined delivery criteria.
At operation 525, the crowdsourced parcel delivery system 100 (e.g., matching module 250) selects participants to execute delivery of the parcel. For example, in one or more embodiments the matching module 250 can determine a matching score for candidates in the candidate pool, where the match score indicates a compatibility of a candidate for a delivery. The matching module can rank candidates in the candidate pool according to their matching scores and select top ranking candidates to be assigned delivery tasks to fulfill the delivery.
At operation 530, the crowdsourced parcel delivery system 100 (e.g., participant management module 270) distributes delivery tasks to the selected participants. In one or more embodiments, the selected participants include at least the first participant and the second participant, and the first participant operates a vehicle having a secure storage locker that includes at least one secure compartment to hold the parcel. In one or more embodiments, at least one delivery task requires at least one of the selected participants to function in a stationary capacity and complete at least one delivery task by holding the parcel at a stationary location until it is picked up by a different participant of the selected participants.
At operation 535, the crowdsourced parcel delivery system 100 (e.g., access module 260) generates or provides access keys for the selected participants. In one or more embodiments, the access module 260 generates at least a first access key that enables access to the secure storage locker and a second access key that enables access to a secure compartment in the storage locker. In one or more embodiments, the first access key and the second access key are functional for only a limited time window determined by the access module 260, based on an estimated timing of a handoff between the first participant and the second participant. In one or more embodiments, the parcel is delivered inside a secure container and the access module 260 generates at least a third access key that enables access to the secure container.
At operation 540, the crowdsourced parcel delivery system 100 (e.g., participant management module 270) transmits access keys to the selected participants according to their assigned delivery tasks.
At operation 545, the crowdsourced parcel delivery system 100 (e.g., participant management module 270) monitors the delivery, completion of the delivery tasks, the status of the selected participants and the status of the delivery tasks. In one or more embodiments, the participant management module 270 receives periodic updates from the selected participants indicating one or more of location, traffic status, map updates, weather updates and delivery task status (e.g., completed, pending).
At operation 550, the crowdsourced parcel delivery system 100 (e.g., participant management module 270) determines whether a delivery situation has changed beyond a threshold amount. For example, the participant management module 270 can determine whether an updated status received from a participant indicates that the participant will be late to an assigned handoff or drop off at a set location greater than a predetermined time threshold (e.g., 20 minutes).
If the crowdsourced parcel delivery system 100 (e.g., participant management module 270) determines that a delivery situation has changed beyond a threshold amount, at operation 555 the crowdsourced parcel delivery system 100 (e.g., matching module 250) dynamically modifies one or more delivery tasks. For example, the matching module 250 can dynamically change the set location for a handoff, adjust the delivery route, select one or more additional participants to join in completing the delivery, determine one or more additional delivery tasks, etc.
After modifying the delivery tasks, the process returns to operation 540, where the access module 260 transmits new access keys, if required, based on the adjustments applied to the delivery route (e.g., provide keys to newly introduced participants as required). The process then returns to operation 545, and the crowdsourced parcel delivery system 100 (e.g., participant management module 270) continues to monitor completion of delivery tasks and operations.
If the crowdsourced parcel delivery system 100 (e.g., participant management module 270) does not determine that a delivery situation has occurred the invokes a response but instead determines that all delivery tasks have been completed and the parcel has been delivered, at operation 560 the crowdsourced parcel delivery system 100 (e.g., participant management module 270) distributes contribution (e.g., cash, reward points, etc.) to the participants.
At operation 565, the crowdsourced parcel delivery system 100 (e.g., participant management module 270) updates profiles associated with the profiles, for example, to indicate performance, timeliness, number of completed tasks, user ratings/comments, etc. The process ends at operation 570.
The embodiments described herein therefore improve over the current technology by providing flexible route planning for delivering a parcel from retailer to consumer using a dynamic network of crowdsourced participants, handoff locations, and substantially real-time planning and updating of delivery routes and dynamic handoff locations, including dynamic delivery of the parcel to the consumer's destination. Further, the dynamic network of the present invention provides flexibility over conventional services that use a fixed number of drivers and transportation vehicles. Conventional systems are also limited to fixed drop-off, pickup, and/or parcel handoff locations, whereas the dynamic network provides flexible options, including handoff locations between drivers that optimize the network in minimizing cost, dwell time, distance traveled, and number of handoff events and other repeat handling of the cargo. The embodiments described herein not only use crowdsourced drivers and vehicles (e.g., participants) but also uses crowdsourced data collections between connected vehicles and a networked system to manage the collection and storage of real-time traffic data and map updates, historical data including trip history, and participant profiles, feedback, and performance ratings that include predictability and reliability metrics, as discussed further below.
The access management aspect of the crowdsourced parcel delivery system 100 remotely manages the logistics and scheduling of handoff location and handoff times. The flexibility is primarily provided by the use of mobile hubs (vehicles). The mobile hubs may also continuously monitor traffic and environmental conditions and update the network and mapping data to be used by other connected vehicles and to recalculate optimal handoff locations and handoff times as needed.
Such crowdsourced monitoring and real-time updating of topology data can uses a variety of methods in a unique manner. The embodiments described herein can accurately estimate the cost and duration of the final delivery while improving delivery planning by improving handoff events (including the security management to access the parcel when mobile hubs are left unattended by a driver).
In one or more arrangements, one or more of the modules described herein can include artificial or computational intelligence elements, e.g., neural network, fuzzy logic or other machine learning algorithms. Further, in one or more arrangements, one or more of the modules can be distributed among a plurality of the modules described herein. In one or more arrangements, two or more of the modules described herein can be combined into a single module.
Detailed embodiments are disclosed herein. However, it is to be understood that the disclosed embodiments are intended only as examples. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a basis for the claims and as a representative basis for teaching one skilled in the art to variously employ the aspects herein in virtually any appropriately detailed structure. Further, the terms and phrases used herein are not intended to be limiting but rather to provide an understandable description of possible implementations. Various embodiments are shown in FIGS. 1-5, but the embodiments are not limited to the illustrated structure or application.
The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved.
The systems, components and/or processes described above can be realized in hardware or a combination of hardware and software and can be realized in a centralized fashion in one processing system or in a distributed fashion where different elements are spread across several interconnected processing systems. Any kind of processing system or another apparatus adapted for carrying out the methods described herein is suited. A typical combination of hardware and software can be a processing system with computer-usable program code that, when being loaded and executed, controls the processing system such that it carries out the methods described herein. The systems, components and/or processes also can be embedded in a computer-readable storage, such as a computer program product or other data programs storage device, readable by a machine, tangibly embodying a program of instructions executable by the machine to perform methods and processes described herein. These elements also can be embedded in an application product which comprises all the features enabling the implementation of the methods described herein and, which when loaded in a processing system, is able to carry out these methods.
Furthermore, arrangements described herein may take the form of a computer program product embodied in one or more computer-readable media having computer-readable program code embodied, e.g., stored, thereon. Any combination of one or more computer-readable media may be utilized. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. The phrase “computer-readable storage medium” means a non-transitory storage medium. A computer-readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium would include the following: a portable computer diskette, a hard disk drive (HDD), a solid-state drive (SSD), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium may be any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.
Generally, modules as used herein include routines, programs, objects, components, data structures, and so on that perform particular tasks or implement particular data types. In further aspects, a memory generally stores the noted modules. The memory associated with a module may be a buffer or cache embedded within a processor, a RAM, a ROM, a flash memory, or another suitable electronic storage medium. In still further aspects, a module as envisioned by the present disclosure is implemented as an application-specific integrated circuit (ASIC), a hardware component of a system on a chip (SoC), as a programmable logic array (PLA), or as another suitable hardware component that is embedded with a defined configuration set (e.g., instructions) for performing the disclosed functions.
Program code embodied on a computer-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber, cable, RF, etc., or any suitable combination of the foregoing. Computer program code for carrying out operations for aspects of the present arrangements may be written in any combination of one or more programming languages, including an object-oriented programming language such as Java™ Smalltalk, C++ or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
The terms “a” and “an,” as used herein, are defined as one or more than one. The term “plurality,” as used herein, is defined as two or more than two. The term “another,” as used herein, is defined as at least a second or more. The terms “including” and/or “having,” as used herein, are defined as comprising (i.e., open language). The phrase “at least one of . . . and . . . ” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. As an example, the phrase “at least one of A, B, and C” includes A only, B only, C only, or any combination thereof (e.g., AB, AC, BC or ABC).
Aspects herein can be embodied in other forms without departing from the spirit or essential attributes thereof. Accordingly, reference should be made to the following claims, rather than to the foregoing specification, as indicating the scope hereof.

Claims

What is claimed is:

1. A system for implementing and controlling crowdsourced delivery of a parcel, comprising:

a network interface configured to communicate wirelessly and to receive, from a user, a delivery request for the parcel, the delivery request indicating at least a pickup location and a delivery destination;

one or more processors; and

a memory communicably coupled to the one or more processors and storing:

a matching module including instructions that when executed by the one or more processors cause the one or more processors to determine a delivery route for the parcel and select a plurality of participants to execute delivery of the parcel, the delivery route including at least one transfer of the parcel between a first participant and a second participant of the plurality of participants, with at least the first participant operating a vehicle having a secure storage locker that includes at least one secure compartment to hold the parcel;

an access module including instructions that when executed by the one or more processors cause the one or more processors to generate access keys including at least a first access key that enables access to the secure storage locker and a second access key that enables access to a secure compartment in the secure storage locker; and

a participant management module including instructions that when executed by the one or more processors cause the one or more processors to distribute delivery tasks, based on the delivery route, to the plurality of participants, transmit the access keys to the second participant, and monitor completion of the delivery tasks by the plurality of participants,

wherein completion of the delivery tasks results in delivery of the parcel to the delivery destination.

2. The system of claim 1, wherein at least one of the plurality of participants functions in a stationary capacity and completes its delivery task by holding the parcel at a stationary location until it is picked up by a different participant of the plurality of participants.

3. The system of claim 1, wherein the at least one transfer has a set transfer location determined by the matching module, and the matching module further includes instructions to, after execution of the delivery has been initiated, dynamically change at least one of:

the set transfer location, and

one or more of the participants executing the transfer.

4. The system of claim 1, wherein the parcel is delivered inside a secure container and the access module further includes instructions to generate at least a third access key that enables access to the secure container.

5. The system of claim 1, wherein the delivery request includes one or more delivery parameters that indicate one or more requested features of a storage compartment for the parcel and the matching module further includes instructions to determine the plurality of participants based at least in part on determining that each of the plurality of participants includes an available storage compartment that meets the one or more requested features.

6. The system of claim 1, wherein the matching module further includes instructions to determine the plurality of participants by:

identifying a set of local participants within a geographic range of the pickup location or delivery destination,

identifying, within the set of local participants, a subset of available participants that each have an available storage compartment that meets one or more requested features indicated in the delivery request,

obtaining, for each available participant in the subset of available participants, travel information indicating at least a predicted route and profile information indicating at least a consistency rating,

generating one or more potential delivery routes based at least in part on the travel information and profile information, each potential delivery route utilizing a combination of available participants from the subset of available participants, and

selecting the delivery route and the plurality of participants that meet a predefined delivery criteria.

7. The system of claim 6, wherein the delivery request defines the predefined delivery criteria as including one or more of:

preferred delivery time,

preferred predictability level, and

preferred route.

8. The system of claim 6, wherein the participant management module further includes instructions to:

monitor one or more travel patterns for each of the plurality of participants; and

update, periodically, the consistency rating for each of the plurality of participants to indicate a degree of consistency in travel.

9. The system of claim 8, wherein the participant management module further includes instructions to forego monitoring a given participant during a time period that the given participant blocks out.

10. The system of claim 1, wherein the participant management module further includes instructions to provide a compensation to each of the plurality of participants upon respective completion of their delivery tasks.

11. A method for implementing and controlling crowdsourced delivery of a parcel, comprising:

receiving, from a user, a delivery request for the parcel, the delivery request indicating at least a pickup location and a delivery destination;

selecting a plurality of participants to execute delivery of the parcel;

determining a delivery route for the parcel, the delivery route including at least one transfer of the parcel between a first participant and a second participant of the plurality of participants, with at least the first participant operating a vehicle having a secure storage locker that includes at least one secure compartment to hold the parcel;

generating access keys including at least a first access key that enables access to the secure storage locker and a second access key that enables access to a secure compartment in the secure storage locker;

transmitting the access keys to the second participant;

distributing delivery tasks, based on the delivery route, to the plurality of participants, wherein completion of the delivery tasks results in delivery of the parcel to the delivery destination; and

monitoring completion of the delivery tasks by the plurality of participants.

12. The method of claim 11, further comprising distributing at least one delivery task that requires at least one of the plurality of participants to function in a stationary capacity and complete the at least one delivery task by holding the parcel at a stationary location until it is picked up by a different participant of the plurality of participants.

13. The method of claim 11, further comprising:

determining a set transfer location for the transfer; and

after execution of the delivery has been initiated, dynamically changing at least one of:

the set transfer location, and

one or more of the participants executing the transfer.

14. The method of claim 11, wherein the parcel is delivered inside a secure container, further comprising:

generating at least a third access key that enables access to the secure container.

15. The method of claim 11, wherein the delivery request includes one or more delivery parameters that indicate one or more requested features of a storage compartment for the parcel, further comprising:

determining the plurality of participants based at least in part on determining that each of the plurality of participants includes an available storage compartment that meets the one or more requested features.

16. The method of claim 11, further comprising determining the plurality of participants by:

identifying a set of local participants within a geographic range of the pickup location or delivery destination;

identifying, within the set of local participants, a subset of available participants that each have an available storage compartment that meets one or more requested features indicated in the delivery request;

obtaining, for each available participant in the subset of available participants, travel information indicating at least a predicted route and profile information indicating at least a consistency rating;

generating one or more potential delivery routes based at least in part on the travel information and profile information, each potential delivery route utilizing a combination of available participants from the subset of available participants; and

17. The method of claim 16, wherein the delivery request defines the predefined delivery criteria as including one or more of:

preferred delivery time,

preferred predictability level, and

preferred route.

18. The method of claim 16, further comprising:

monitoring one or more travel patterns for each of the plurality of participants; and

updating, periodically, the consistency rating for each of the plurality of participants to indicate a degree of consistency in travel.

19. The method of claim 18, further comprising foregoing monitoring a given participant during a time period that the given participant blocks out.

20. The method of claim 11, further comprising providing a compensation to each of the plurality of participants upon respective completion of their delivery tasks.