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.
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.
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.
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.
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.
Referring to
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
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).
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
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
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.
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.
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
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
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
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
In
The matching module 250 can select one or more participants to execute delivery tasks and complete the delivery. In
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.
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
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.
Number | Date | Country | |
---|---|---|---|
63001220 | Mar 2020 | US |