US20210304137A1 - Systems and methods for dynamic crowdsourced delivery - Google Patents

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 crowdsourcedparcel delivery system100 according to the disclosed embodiments. As will be discussed further below, the crowdsourcedparcel delivery system100 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 crowdsourcedparcel delivery system100 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 toFIG. 1, in one or more embodiments the crowdsourcedparcel delivery system100 can receive adelivery request111 from a user, e.g., aretailer110. Thedelivery request111 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 thedelivery request111, the crowdsourcedparcel delivery system100 can analyze a network ofparticipants130 to automatically identify, select, and manage a plurality ofparticipants130 to complete thedelivery request111 according to the delivery criteria.
• At an operational level, the crowdsourcedparcel delivery system100 provides multiple functions that may generally be categorized asmatching management101,access management102, andparticipant management103. Theparticipants130 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 crowdsourcedparcel delivery system100. For example, as will be discussed further below, aparticipant130 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 ofFIG. 1, theparticipants130 provide the crowdsourcedparcel delivery system100 with information, includingtravel information131 anddelivery capacity132.Travel information131 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 participant130), and real-time location of theparticipant130. Providing real-time location enables the crowdsourcedparcel delivery system100 to determine whichparticipant130 or combination ofparticipants130, through a series of handoffs along a particular route, are able to fulfill thedelivery request111 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 crowdsourcedparcel delivery system100 determines real-time location by trackingparticipants130 based on theparticipants130 frequently reporting GPS coordinates transmitted over a network (e.g., cellular data) to thesystem100. In other embodiments, thesystem100 tracks the real-time location ofparticipants130 based on receiving a reported location of a mobile computing device (e.g., a smartphone) carried by an owner/driver. In any case,participants130 agree to tracking terms prior to participating in the crowdsourcedparcel delivery system100, 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 information131 aparticipant130 can also inform the crowdsourcedparcel delivery system100 of adelivery capacity132 of the participant.Delivery capacity132 can include a report on the availability of aparticipant130 to take part in a delivery as well as the availability and features of compartments within a storage area of theparticipant130. In one or more embodiments, vehicles that operate asparticipants130 may include original or aftermarket enhancements that are designed for providing specific services within the crowdsourcedparcel delivery system100. Example enhancements, such as multiple secured and climate-controlled compartments within a vehicle's trunk, are discussed in greater detail below.Delivery capacity132 can convey the status and features of such compartments.
• Referring to the crowdsourcedparcel delivery system100, matchingmanagement101 generally handles identifying and selectingparticipants130 to convey the parcel while attempting to meet requirements established by delivery criteria included in thedelivery request111. In one or more embodiments, matchingmanagement101 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 ormore participants130 based on historical data that indicates driving habits of theparticipants130. 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 selectsparticipants130 to include in the delivery process based on the predicted travel plans, travel information and delivery capacity obtained from theparticipants130, as well as the delivery criteria indicated in thedelivery request111. These two functions, predictive destination and participant selection, are discussed in greater detail below.
• Access management102 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 throughmultiple participants130 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 management102 can include utilizing a machine learning model for determining a number of handoffs, access times, etc.
• Participant management103 includes functions to manage compensation/rewards forparticipants130 and software/hardware interfaces between the crowdsourcedparcel delivery system100 and: (1) users, such as nation-wide stores, on-line stores, resellers, small local retailers, individuals, consumers, etc. and (2)participants130 who participate in the system by storing and/or transporting parcels.
• Regarding the interface with users, the crowdsourcedparcel delivery system100 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 crowdsourcedparcel delivery system100 described herein. Regarding the interface withparticipants130, thesystem100 can include, for example, a website and/or a mobile app (e.g., for smartphones, tablet computers, etc.) forparticipants130 to access that allows the crowdsourcedparcel delivery system100 to communicate with theparticipants130. For example, thesystem100 can send participants130: invitations (e.g., via text message, app-notification, etc.) to accept delivery tasks, updates regarding handoffs toother participants130, updates regarding changes to the delivery route, updates regarding earned rewards/compensation, and other communications.
• The compensation function ofparticipant management103 operates to dispense rewards (e.g., monetary rewards, points, etc.) toparticipants130 for completing delivery tasks. For example, in one or more embodiments, aparticipant130 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 crowdsourcedparcel delivery system100 can dispense rewards in the form of a gift card, a discount on future purchases, or other incentives.
• In one or moreembodiments participant management103 dispenses cash payments (e.g., a direct deposit in a bank account) toparticipants130 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 crowdsourcedparcel delivery system100 may receive a percentage of the delivery fee and theparticipants130 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 crowdsourcedparcel delivery system100 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, aparticipant130 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 crowdsourcedparcel delivery system100. The crowdsourcedparcel delivery system100 is shown including one ormore processors210, amemory220,database230, and anetwork interface240. In other embodiments, more or fewer components than those shown can be included according to a given implementation. Generally, the crowdsourcedparcel delivery system100 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 anetwork interface240 configured to connect theprocessor210 to the network, such as the Internet or a cellular telephone network.
• Thememory220 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, amatching module250,access module260 and aparticipant management module270. Themodules250,260 and270 will be described further below.
• Thedatabase230 can store, among other information,delivery request data280,map data285,participant data290, andhistorical data295 which will be also described further below. Thedatabase230 is, in one or more embodiments, an electronic data structure that can be a data store. Thedatabase230 is configured with routines that can be executed by theprocessor210 for analyzing stored data, accessing and providing stored data, organizing stored data, and so on. Thus, in one embodiment, thedatabase230 stores and manages/updates data, suchdelivery request data280,map data285,participant data290,historical data295, as well as other types of data that is used bymodules250,260 and270 in executing various functions.
• In one or more embodiments, the crowdsourcedparcel delivery system100 can store incoming delivery requests as part ofdelivery request data280 in thesystem database230. In one or more embodiments, thedelivery request data280 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 crowdsourcedparcel delivery system100 can store and updatemap data285 that provides regional maps (e.g., street maps) that the crowdsourcedparcel delivery system100 can analyze to determine delivery routes. The crowdsourcedparcel delivery system100 can store supplemental data associated with themap data285, such as traffic reports, accident reports, weather reports, etc., and utilize the supplemental data to aid in determining optimal routes and dynamic adjustments.
• Aparticipant130 may register an account with the crowdsourcedparcel delivery system100 as a prerequisite for accepting jobs. In response, thesystem100 can create a profile for theparticipant130 and store the profile asparticipant data290, which may be stored in one or more tables or databases within thesystem database230. 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 crowdsourcedparcel delivery system100 to transmit job invitations to theparticipant130 and to receive travel information and delivery capacity information from theparticipant130. 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 inFIG. 2, the crowdsourcedparcel delivery system100 can receive adelivery request111 from a user, for example, aretailer110. Thedelivery request111 can include various types of information, such as a description of the parcel to be delivered, a pickup location (e.g., address of the retailer110), 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).
• Thematching module250 generally includes instructions that function to control theprocessor210 to determine a delivery route for the parcel and to select a plurality ofparticipants130,135 to execute delivery of the parcel along the delivery route. Although only twoparticipants130,135 are shown inFIG. 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 theparticipants130,135 transports the parcel in a secure inner compartment of a secure storage locker. Theaccess module260 generally includes instructions that function to control theprocessor210 to generate, for at least one of the plurality ofparticipants130,135, access keys that allow access to the secure storage locker and the secure compartment to facilitate a handoff of the parcel. Theparticipant management module270 generally includes instructions that function to control theprocessor210 to distributedelivery tasks112, based on the delivery route, to the plurality ofparticipants130,135, transmit the access keys, and monitor completion of thedelivery tasks112.
• To select the participants for a given delivery, in one or more embodiments thematching module250 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 acceptdelivery tasks112 and thereby cooperatively execute delivery of the parcel.
• FIG. 3 shows an example scenario of the crowdsourcedparcel delivery system100 identifying candidates for a delivery. For example, in one or more embodiments thematching module250 can examine aregion300 to identify a plurality ofparticipants130,135,140,145 as candidates. Thematching module250 can identify theparticipants130,135,140,145 as being within theregion300, for example, based on travel information (e.g., location, current route, etc.) stored in theparticipant data290.
• For a delivery route having a first segment that begins at the delivery pickup location (e.g., of retailer110), thematching module250 can analyzeparticipant data290 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 retailer110). In one or more embodiments, thematching module250 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 afirst participant130 and asecond participant135. In determining a delivery route, thematching module250 can create one or more potential delivery routes and select an optimal route to execute. In one or more embodiments, thematching module250 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 thematching module250 according to the disclosed embodiments. For example, thematching module250 may receive a delivery request indicating a pickup location400 (e.g., a retail store such asretailer110 fromFIG. 3) and a delivery destination410 (e.g., a user residence). Thematching module250 can analyze aregional map415 stored inmap data285 to determine a first route that proceeds from the pickup location400 (e.g. a retail store) alongsegment420 to ahandoff location425, then proceeds alongsegment430 to thedelivery destination410, and a second route that proceeds from thepickup location400 alongsegment440 to ahandoff location445, then proceeds alongsegment450 to thedelivery destination410.
• Since a route may have one or more handoffs between participants, to facilitate secure transfer of the parcel each of theparticipants130 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 toFIG. 2, theaccess module260 can generate, for each of theparticipants130,135,access keys114 that enable access to the secure storage locker, the secure compartment and, when applicable, the secure container used to transport the parcel. Theaccess keys114 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 theaccess keys114 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 theparticipants130,135, a code associated with a scannable image transmitted to and displayed on mobile devices belonging toparticipants130,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 toparticipants130,135, or another type of access key that can be provided to theparticipants130,135.
• Theaccess module260 can dynamically manage timing windows during which theaccess keys114 are valid based on a handoff/pickup schedule per route. For example, referring toFIG. 4, in one example scenario thematching module250 selects two participants to execute delivery of the parcel. Thematching module250 assigns a first participant the delivery tasks of picking up the parcel from thepickup location400 at12:00 and transporting the parcel from thepickup location400 to thehandoff location425 alongroute segment420. Thematching module250 assigns a second participant the delivery tasks of picking up the parcel from thehandoff location425 and transporting the parcel to thedelivery destination410. Thehandoff location425 may be, for example, a parking lot at a store or an office building that first participant is traveling to.
• Theaccess module260 can estimate a time that the first participant should arrive at the handoff location425 (e.g.,12:15) and estimate a time that the second participant should arrive at the handoff location425 (e.g.,12:30). Based on the estimated arrivals, theaccess module260 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 to12:40). Thus, the first participant can park at thehandoff location425 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 thehandoff location425 during the timing window.
• In one or more embodiments, theaccess module260 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), theaccess module260 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, thematching module250 and theaccess module260 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 crowdsourcedparcel delivery system100 could dynamically take the time of day into account in the operations of thematching module250 andaccess module260 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 system100 (e.g., matchingmodule250 and access module260) can automatically adjust the delivery route in response. That is, the system100 (e.g., participant management module270) 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 system100 (e.g., matchingmodule250 and access module260) 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 crowdsourcedparcel delivery system100 and thesystem100 can provide compensation to the participants for completed delivery tasks. Referring back toFIG. 2, theparticipant management module270 can manage completion ofdelivery tasks112, including transmittingdelivery tasks112 to participants based on a selected delivery route, transmitting access keys as part of the delivery task transmission, and monitoring completion of thedelivery tasks112, e.g., to determine whether a dynamic change in the delivery route should be implemented. Theparticipant management module270 can furthermore monitor travel patterns of participants, store a historical record of monitored participant travel patterns ashistorical data295 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 theparticipant management module270, thematching module250 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 thematching module250 in the participant selection process.
• As a further enhancement to matching and selection features, in one or more embodiments the crowdsourcedparcel delivery system100 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 thesystem100 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, theparticipant management module270 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 crowdsourcedparcel delivery system100 can predict the location, destinations, routes and dwell times of a given participant, based on thehistorical data295 associated with the participant.
• By rating drivers based on consistency, the crowdsourcedparcel delivery system100 can improve the efficiency of parcel transfer scheduling and other aspects of creating delivery routes. For example, the system100 (e.g., matching module250) 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 system100 (e.g., matching module250) 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 theparticipant management module270 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. Thesystem100 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 system100 (e.g., matching module250) 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, thesystem100 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 system100 (e.g., matchingmodule250 and/or participant management module270) may also determine how often a participant has selected toblackout system100 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 toFIGS. 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 crowdsourcedparcel delivery system100, 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.
• InFIG. 2, aretailer110 processes a consumer's purchase of an item. Theretailer110 transmits adelivery request111 to the crowdsourcedparcel delivery system100 for shipment of the item to the consumer according to the consumer's instructions. Thedelivery request111 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 thedelivery request111, the crowdsourced parcel delivery system100 (e.g., matching module250) determines one or more potential delivery routes.
• Thematching module250 can select one or more participants to execute delivery tasks and complete the delivery. InFIGS. 2 and 3, thematching module250 first checks the current location and availability status of vehicles (e.g., owned or driven by participants) in a relevantgeographic region300, for example, by analyzing location information for participants as indicated inparticipant data290 stored in thesystem database230 and analyzinghistorical data295. Thematching module250 can identify a pool of candidates that are available in thegeographic region300 to complete a delivery task. In one or more embodiments, thematching module250 can identify one or more candidates based on a predicted location of one or more participants based onhistorical data295. For example, a participant may currently be outside of thegeographic region300, however, based on trends inhistorical data295 associated with the participant thematching module250 can predict that the participant will be within thegeographic region300 at a relevant time with regards to the delivery being contemplated.
• Once thematching module250 has determined which participants are included in the candidate pool, thematching module250 then determines which participants are available to accept a delivery request, for example, based on status indicated inparticipant data290 or a prediction based onhistorical data295. Unavailable participants are removed from the candidate pool.
• Thematching module250 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, thematching module250 can consider the factor in a different order (e.g., availability first).
• With the candidate pool determined, in one or more embodiments thematching module250 can rank the candidates in terms of compatibility to the delivery and efficiency. For example, thematching module250 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 thematching module250 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 crowdsourcedparcel delivery system100 different parameters and more complex arithmetic formulation may be utilized.
• Accordingly, thematching module250 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 thematching module250 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, thematching module250 can identify the highest ranking candidates and assign the candidates delivery tasks according to a determined delivery route. Theparticipant module270 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, theaccess module260 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 thesystem100 to predict the participant's location and route for the duration of the delivery significantly increases. The disclosed crowdsourcedparcel delivery system100 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 thesystem100 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, thesystem100 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. Thematching module250 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, thesystem100 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, thesystem100 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, thesystem100 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 after12:00). As circumstances that impact completion of a delivery task occur, thesystem100 can respond
• Therefore, using real-time data and historical information, the crowdsourcedparcel delivery system100 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. Thesystem100 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 amethod500 of implementing and controlling a system for crowdsourced delivery of a parcel according to the disclosed embodiments.Method500 will be discussed from the perspective of the crowdsourcedparcel delivery system100 ofFIG. 2. Whilemethod500 is discussed in combination with the crowdsourcedparcel delivery system100, it should be understood that themethod500 is not limited to implementation within the crowdsourcedparcel delivery system100, which is merely one example of a system that may implement themethod500. It should further be understood that the order of operations can change in various implementations of themethod500.
• Atoperation510, the crowdsourcedparcel delivery system100 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.
• Atoperation515, the crowdsourced parcel delivery system100 (e.g., matching module250) 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.
• Atoperation520, the crowdsourced parcel delivery system100 (e.g., matching module250) identifies a candidate pool. In one or more embodiments, thematching module250 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, thematching module250 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 crowdsourcedparcel delivery system100 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.
• Atoperation525, the crowdsourced parcel delivery system100 (e.g., matching module250) selects participants to execute delivery of the parcel. For example, in one or more embodiments thematching module250 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.
• Atoperation530, the crowdsourced parcel delivery system100 (e.g., participant management module270) 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.
• Atoperation535, the crowdsourced parcel delivery system100 (e.g., access module260) generates or provides access keys for the selected participants. In one or more embodiments, theaccess module260 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 theaccess module260, 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 theaccess module260 generates at least a third access key that enables access to the secure container.
• Atoperation540, the crowdsourced parcel delivery system100 (e.g., participant management module270) transmits access keys to the selected participants according to their assigned delivery tasks.
• Atoperation545, the crowdsourced parcel delivery system100 (e.g., participant management module270) 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, theparticipant management module270 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).
• Atoperation550, the crowdsourced parcel delivery system100 (e.g., participant management module270) determines whether a delivery situation has changed beyond a threshold amount. For example, theparticipant management module270 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 system100 (e.g., participant management module270) determines that a delivery situation has changed beyond a threshold amount, atoperation555 the crowdsourced parcel delivery system100 (e.g., matching module250) dynamically modifies one or more delivery tasks. For example, thematching module250 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 tooperation540, where theaccess module260 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 tooperation545, and the crowdsourced parcel delivery system100 (e.g., participant management module270) continues to monitor completion of delivery tasks and operations.
• If the crowdsourced parcel delivery system100 (e.g., participant management module270) 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, atoperation560 the crowdsourced parcel delivery system100 (e.g., participant management module270) distributes contribution (e.g., cash, reward points, etc.) to the participants.
• Atoperation565, the crowdsourced parcel delivery system100 (e.g., participant management module270) updates profiles associated with the profiles, for example, to indicate performance, timeliness, number of completed tasks, user ratings/comments, etc. The process ends atoperation570.
• 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 crowdsourcedparcel delivery system100 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 inFIGS. 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 (20)

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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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 ofclaim 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

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

17. The method ofclaim 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 ofclaim 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 ofclaim 18, further comprising foregoing monitoring a given participant during a time period that the given participant blocks out.

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

Images