DYNAMICALLY ADJUSTING TRANSPORTATION PROVIDER POOL SIZE
The disclosed systems can regulate access to an online mode for a dynamic transportation matching system. For example, based on a provider efficiency parameter associated with the dynamic transportation matching system, the disclosed systems can prevent a transportation provider device from switching to the online mode within a geographic area. In addition, the disclosed systems can detect a pattern of behavior and, based on a comparison between the pattern of behavior and a behavioral threshold, cause a transportation provider device to switch from the online mode to an offline mode. Further, the disclosed systems can provide a map interface that indicates where a transportation provider device can switch from the offline mode to the online mode. Additionally, the disclosed systems can determine priorities associated with transportation provider devices and, based on the prioritization, selectively allow the transportation provider devices to switch from the offline mode to the online mode.
This application claims the benefit of U.S. Provisional Application No. 62/867,174, filed Jun. 26, 2019, entitled DYNAMICALLY ADJUSTING TRANSPORTATION PROVIDER POOL SIZE, the contents of which are herein expressly incorporated by reference in their entirety.
BACKGROUNDRecent years have seen significant improvements in computer systems and software applications for implementing solutions relevant to transportation matching systems. For example, conventional transportation matching systems can dynamically assign transportation requests among a pool of available transportation providers. However, an unmet need exists with conventional transportation matching systems, particularly in relation to dynamically sizing the pool of available transportation providers associated with mobile application-based transportation matching systems that match transportation providers to transportation requests received from requesting users.
SUMMARYThis disclosure describes one or more embodiments of methods, non-transitory computer-readable media, and systems that solve problems in the art in addition to providing other benefits. In some embodiments, the disclosed systems regulate access to an online mode for a dynamic transportation matching system. For example, based on a provider efficiency parameter associated with a dynamic transportation matching system, the disclosed systems can prevent one or more transportation provider devices from switching to the online mode within a geographic area. Additionally or alternatively, in some embodiments, the disclosed systems can detect a pattern of behavior (e.g., an amount of idle time, a number of ride cancellations or ride-assignment lapses, etc.). In turn, the disclosed systems can compare the pattern of behavior to a threshold and, based on the comparison, cause a transportation provider device to switch from the online mode to an offline mode. Additionally or alternatively, in some embodiments, the disclosed systems can provide a map interface for display by the transportation provider device that indicates where the transportation provider device can switch from the offline mode to the online mode. Additionally or alternatively, in some embodiments, the disclosed systems can determine a priority associated with one or more transportation provider devices and, based on the prioritization, selectively allow the one or more transportation provider devices to switch from the offline mode to the online mode.
Additional features and advantages of one or more embodiments of the present disclosure will be set forth in the description which follows.
As mentioned above, conventional systems fall short in variety of ways. For example, conventional transportation matching systems optimize (to the extent possible) the matching of transportation requests with an available pool of transportation providers (hereafter, “providers”), regardless of how that available pool of providers looks like. Accordingly, conventional transportation matching systems can face overly-complex matching scenarios that lead to increased computation and system processing. In addition to longer processing times, conventional transportation matching systems can improperly match transportation requests to providers by generating inefficient matchings of transportation requests and providers. Further, conventional transportation matching systems have difficulty accounting for variables presented by human behavior. For example, many variables are introduced upon a provider's decision to begin or end transportation services (e.g., go online/offline), accept or decline a transportation request, and/or drive to or idle at a certain location versus another location.
This disclosure describes one or more embodiments to regulate provider access to a dynamic transportation matching system that matches providers with transportation requests. Further, in one or more example embodiments, this disclosure describes a provider efficiency control system that can dynamically size a pool of available providers across one or more geographic areas (e.g., a geohash or combination of geohashes), thereby solving the above example problems and/or other problems not necessarily inferred or expressly recited. For example, by dynamically sizing the pool of available providers across one or more geographic areas, the provider efficiency control system can reduce and/or simplify an amount of computation and processing for a dynamic transportation matching system to match providers with transportation requests. Additionally, by creating an appropriately sized pool of available providers, the provider efficiency control system of the present disclosure can enable the dynamic transportation matching system to more accurately match transportation requests and providers with improved efficiencies (e.g., less estimated time to arrival or “ETA,” less idle time, etc.). Further, the provider efficiency control system can reduce human decision variables introduced to the dynamic transportation matching system by providing dynamic responses or dynamic recommendations to transportation providers that generate more predictable results.
In turn, the provider efficiency control system can lend to improved experiences for providers. For example, providers can experience more predictability and generate increased earnings by better understanding ways to achieve and maintain online status for completing transportation requests. In particular, the provider efficiency control system can dynamically respond to flux in transportation requests by selectively adjusting a pool size of providers in a manner that optimizes provider efficiency and cuts provider downtime that would otherwise negatively affect provider earnings. Accordingly, the provider efficiency control system can help some providers consolidate time spent in an online status while also achieving similar earnings, if not better earnings than heretofore achieved under other systems.
Additional features and advantages of one or more embodiments of the present disclosure are outlined in the description which follows, and in part will be obvious from the description, or may be learned by the practice of such example embodiments.
Turning to the figures,
As shown, in one or more embodiments, the provider efficiency control system 102 can be a component of the dynamic transportation matching system 103 implemented on one or more server(s) 104. In these or other embodiments, the provider efficiency control system 102 may perform one or more acts of the present disclosure described in conjunction with the dynamic transportation matching system 103. Additionally or alternatively, the dynamic transportation matching system 103 may perform one or more acts of the present disclosure described in conjunction with the provider efficiency control system 102. Furthermore, although
In one or more embodiments, the network 112 shown in
As mentioned above, the dynamic transportation matching system 103 includes the provider efficiency control system 102.
In more detail, the process flow 200 illustrates the inputs 201 as including geohash conditions 202. In some embodiments, the geohash conditions 202 can include any data associated with one or more geographic areas. For example, the geohash conditions 202 can include a number of open transport requests, a number of matched transport requests, a number of completed transport requests, a forecast of transport requests, a queue of transport requests, a duration of open transport requests, etc. In another example, the geohash conditions 202 can include a number of online providers that are available to accept new matches to transportation requests (e.g., in idle) and/or are currently matched to a transportation request (e.g., en route to pickup or currently in service). Additionally or alternatively, the geohash conditions 202 can include a number of offline providers that are neither available to accept matches to transportation requests and are not currently matched to a transportation request.
In some embodiments, the geohash conditions 202 can include geohash boundary information and/or positional relationship data between two or more geohashes, including various combinations of geohashes. Further, the geohash conditions 202 can include any positional relationship data of any of the provider devices 105a-105n relative to each other, relative to one or more transport requests, relative to one or more geohashes, relative to external factors like current/forecasted traffic conditions and construction, etc. and/or relative to any combination thereof. For example, the geohash conditions 202 can include estimated time to arrival (ETA) metric data for any of the provider devices 105a-105n, in which the ETA is a predicted amount of time until a vehicle position associated with a provider device 105 arrives at a certain location or area (e.g., of a requestor associated with a transport request for pickup, a busy geohash with open transport requests, etc.).
In other examples, the geohash conditions 202 can include an assortment of metrics and data combinations. For instance, the geohash conditions 202 can include: a mean driver idle time in which a provider device is in the online mode 210 but not matched with a transportation request; a mean pickup time in which a provider device 105 takes to respond to a transport request; a mean service time in which a provider device 105 is associated with transporting a requestor; or any other suitable metric or derivative thereof. In these or other embodiments, one or more metrics comprising the geohash conditions 202 may be combined across any number of the provider devices 105a-105n and/or across one or more geohashes, and/or otherwise mathematically combined, smoothed, normalized, optimized, compared, predicted, etc.
Additionally,
Based on the inputs 201, the provider efficiency control system 102 may determine to activate an online mode control condition to decrease a number of the provider devices 105a-105n that are in the online mode 210 in one or more geohashes. In response to activating the online mode control condition, the provider efficiency control system 102 generates the dynamic responses 208 for sending to one or more of the provider devices 105a-105n via the respective dynamic transportation applications 107a-107n. Responses to the dynamic responses 208 from the provider devices 105a-105n feed into the inputs 201 and can help the provider efficiency control system 102 determine in real-time how to allocate the provider devices 105a-105n between the online mode 210 and the offline mode 212 when the online mode control condition is active. Specifically, the dynamic responses 208 provide recommendations, instructions, selectable options, etc. that when followed guarantee or at least increase a likelihood of a provider device 105 staying in the online mode 210, if already there (e.g., the provider device 105c shown as an example in
In some embodiments, the provider efficiency control system 102 may send one or more of the dynamic responses 208 to a provider device 105 based on whether the provider device 105 is currently within the online mode 210 or the offline mode 212. For example, according to
Similarly, to remain in the online mode 210, the provider efficiency control system 102 may send to the provider devices 105a, 105c in the online mode 210 some of the dynamic responses 208 that can include: accepting one or more of the next transportation requests received at the respective provider devices 105a, 105c, relocating the respective vehicle positions associated with the provider devices 105a, 105c to a busier location, or any other suitable dynamic response.
As mentioned above, the provider efficiency control system 102 can dynamically size a pool of available providers to decrease a number of the provider devices 105a-105n in the online mode 210.
In particular,
As one example factor analyzed at act 302, the provider efficiency control system 102 analyzes a provider efficiency parameter for the first geohash to determine if within a target range. The provider efficiency parameter as referred to herein includes a ratio of mean idle time (“P1”) to mean pickup time (“P2”), which can be expressed as:
where ϵ refers to the elasticity of an ETA function. In other terms, the provider efficiency parameter describes the percentage change in ETA for a 1% change in P1. In some cases, an efficient P1/P2 level can be in the range of about 0.2 to about 0.4, though other ranges are herein contemplated. When P1/P2 drops below the efficient level, there are fewer idle P1 providers, but the P2 time for pickups increases and providers spend more time driving to pick up passengers, so much so that the sum of P1 and P2 providers increases. Alternatively, when P1/P2 increases above the efficient level, there are more idle P1 providers, and P2 pick up times decrease. In this case, the sum of P1 and P2 providers again increases relative to the efficient level because of the excess P1 providers.
In some embodiments, P1 and P2 can be measured as the time-average number of providers in each state (P1 or P2) per geohash. In this sense, the measurements can represent a time-average density of providers in each state, where the unit of area is a geohash. References to the P1 and P2 measures as P1 density and P2 density are also acceptable.
To determine the P1 and P2 densities, the provider efficiency control system 102 can use geo-aggregation and kernel smoothing techniques. Specifically, the P1 and P2 densities can be measured over a geohash neighborhood using the existing geohash boundaries and definitions together with kernel smoothing weights based on ETA to convert geohash counts to neighborhood densities. Further, the P1 and P2 densities can be measured at intervals (e.g., every minute) for one or more geohashes. In some embodiments, the P1 and P2 densities can include sub-categories of data, like different ride types (e.g., standard, wheel-chair accessible, premium, luxury, etc.).
Additionally or alternatively, P1 and P2 can be measured in a variety of ways. As one example way, the provider efficiency control system 102 can take a count of P1 and P2 minutes in a geohash over a given observation interval (e.g., ten seconds, thirty seconds, one minute, etc.). This approach can be referred to as a count-based average. As another example way to measure P1 and P2, the provider efficiency control system 102 can identify the number of providers dispatched to a geohash and measure surplus providers in the same geohash.
With the raw data points of P1 and P2 densities measured, the provider efficiency control system 102 performs a time-smoothing algorithm in some embodiments. For example, let {circumflex over (R)}(t) denote the P1/P2 ratio metric for a given geo g in minute t. To simplify notation, the geo index is emitted in the expressions that follow. Letting P1(t) and P2(t) denote the raw count of P1 and P2 densities in a geohash in a given minute t. Then the smoothed P1 and P2 density metrics can be represented by the exponential smoothing process:
{circumflex over (P)}1(t)=αP1(t)+(1−α){circumflex over (P)}1(t−1)
{circumflex over (P)}2(t)=αP2(t)+(1−α){circumflex over (P)}2(t−1)
The smoothing constant α is chosen to balance smoothness versus lag in the P1/P2 ratio signal. If time is measured in minutes, then a value of a 0.2 can correspond roughly to averaging the ratio over a five minute interval. Smaller values of the smoothing constant may result in a less volatile metric but one that might be slower to track changes in the P1 and P2 density.
The provider efficiency control system 102 may then use the smoothed P1 and P2 densities to generate an estimate of the provider efficiency parameter, denoted {circumflex over (R)}(t), by simply taking the ratio expressed as follows:
The individual P1 and P2 smoothed density estimates can also be used to generate a “slot limit” referring to a number of drivers that can be permitted in the online mode 210.
Once the provider efficiency control system 102 determines the P1/P2 ratio metric {circumflex over (R)}(t), the provider efficiency control system 102 may determine to activate the online mode control condition if:
{circumflex over (R)}(t)>{umlaut over (R)},
where the threshold
{circumflex over (σ)}R(t)=√{square root over ({circumflex over (R)}2(t)−[{circumflex over (R)}(t)]2)}
Accordingly, modifying relative to the above logic rule, the provider efficiency control system 102 can determine to activate the online mode control condition if:
{circumflex over (R)}(t)>
where k>0 is a safety factor (i.e., a number of standard deviations above the target threshold).
Further, the provider efficiency control system 102 can provide additional control layers for determining whether the provider efficiency parameter is within a target range. For example, the provider efficiency control system 102 may implement hysteresis logic for determining whether to activate or deactivate the online mode control condition, (e.g., using a lower threshold R<
Additionally, the provider efficiency control system 102 at act 302 analyzes another factor that includes an ETA metric in determining whether to activate the online mode control condition. For example, the provider efficiency control system 102 may determine to activate the online mode control condition if the following ETA metric is within some upper limit of ETA (e.g., five minutes). Specifically, if E(t) is the raw ETA measurement in a given neighborhood in minute l and Ê(t) is the ETA metric, then the follow expression can apply:
Ê(t)=αE(t)+(1−α)Ê(t−1)
In some cases, the provider efficiency control system 102 may determine to not activate (or deactivate) the online mode control condition if the ETA metric exceeds the upper limit, even if the provider efficiency parameter has exceeded its upper bound of the target range. In this manner, the provider efficiency control system 102 uses the ETA metric to ensure service levels are not negatively impacted in a significant way, and therefore, in some cases may be prioritized over a better provider efficiency ratio.
Further, the provider efficiency control system 102 at act 302 analyzes another factor that includes a prime-time status in determining whether to activate the online mode control condition. In particular, the provider efficiency control system 102 may determine not to activate the online mode control condition if the level of primetime in the geohash exceeds a threshold (e.g., is positive or is otherwise active). As used herein, the term “primetime” refers to a period of time designated as distinct from other periods of time in which riders may submit transport requests. In particular, primetime refers to a period of time in which the number of transport requests is greater than the number of providers available to fulfill the transport requests. For example, a period of time encapsulating the time leading up to or immediately after a special event, such as a convention or a sporting event, may be designated as primetime if the number of attendees requesting a ride is larger than the number of providers in the area in the online mode 210.
Thus, in some embodiments, the provider efficiency control system 102 may determine at act 302 to activate the online mode control condition if: primetime is not active, if the ETA metric is within bounds, and the provider efficiency parameter (P1/P2) is above the target range. This example logic implemented by the provider efficiency control system 102 is also represented in the following example pseudocode:
At act 304, the provider efficiency control system 102 activates the online mode control condition for the first geohash. For example, in response to one or more determinations at act 302, the provider efficiency control system 102 activates the online mode control condition.
Further, in some embodiments, the provider efficiency control system 102 at act 304 determines for the first geohash a number of online mode slots that correspond to a number of the provider devices 105a-105n that can be in the online mode 210 in the first geohash under the active online mode control condition and according to real-time conditions (e.g., the inputs 201). In these or other embodiments, the provider efficiency control system 102 determines one or more slot limits for online mode slots, including for the first geohash, to regulate in real-time increases or decreases in the number of transport requests.
To determine the number of online mode slots available for the first geohash, the provider efficiency control system 102 may first determine a total number of the provider devices 105a-105n that the provider efficiency control system 102 can allow in the online mode 210 across a group of geohashes or a region, represented as the total slot limit y in the following expression:
where the right-hand side includes: the smoothed P1 density {circumflex over (P)}1(t) described above as a function of time t, {circumflex over (R)}(t) representing the provider efficiency parameter described above as a function of time t, ϵ representing the elasticity of the ETA function, and θ* representing a value θ*>1 such that if the number of providers is scaled by this value, R(θ*)=
where
Once the provider efficiency control system 102 determines the total number of the provider devices 105a-105n that are able to be in the online mode 210 for a region, the provider efficiency control system 102 can then determine how the total number of the provider devices 105a-105n translates to a local level (e.g., a geohash level). To do so, the provider efficiency control system 102 solves the following linear system for the vector x:
or in matrix form: Wx=y, where xi represents a local slot limit for geohash i; yi represents a neighborhood slot limit for the neighborhood centered around geohash i; and wij represents a weight (e.g., a kernel smoothing coefficient) of geohash i that contributes to neighborhood j. Additionally or alternatively, the provider efficiency control system 102 may solve for the vector x using a least squares problem expressed, for example, as follows:
minx≥0∥y−Wx∥2
In some embodiments, however, the local slot limit can have a greater impact to the inputs 201 than may be initially expected. For example, a single provider can often amount to a large unit of supply and impacts density over a wider neighborhood around their respective geohash. Accordingly, the provider efficiency control system 102 can make real-time adjustments to the number of providers admitted into the online mode 210 using the following example expression. Let (j) denote the set of geohashes in a neighborhood region of geohashes j. Then the updated number of additional providers that the provider efficiency control system 102 may allow in the online mode 210 in j is the sum of local slot limits in j, denoted as follows:
Further, the provider efficiency control system 102 can make additional adjustments on the fly after adding each new provider into the online mode 210. For example, each new provider admitted into the online mode 210 in the neighborhood region of geohashes j can reduce the allocations of providers according to the expression: x←x−wj, where wj=(w1j, w2j, . . . , wnj) is the j-th row of the kernel weight matrix W. The provider efficiency control system 102 can perform this updated process iteratively until new slot limits x are recalculated after updating the P1 and P2 density metrics. Additionally or alternatively, the provider efficiency control system 102 may aggregate the local slot limits x in other ways to communicate or selectively restrict providers from switching to the online mode 210. For example, the provider efficiency control system 102 may aggregate the geohash local slot limits over other types of geohash zones to produce corresponding zonal slot limits.
Additionally or alternatively to determining slot limits, in some embodiments, the provider efficiency control system 102 may forecast how many providers will be needed in a given geographic area based on a forecast. For example, the provider efficiency control system 102 may predict or otherwise generate a static forecast of the number of needed providers based on historical data of needed providers (e.g., by geographic area) and current date/time information.
In some embodiments, the provider efficiency control system 102 may set a priority for filling the available slots within the online mode 210, and in turn, a priority for notifying (i.e., transmitting a notification to) one or more of the provider devices 105a-105n that can switch to the online mode 210. For example, the provider efficiency control system 102 may prioritize filling available slots within the online mode 210 and/or notifying one or more of the provider devices 105a-105n based on an acceptance rate of ride assignments (e.g., an acceptance rate of ninety percent or above), a number of completed rides within a given time period (e.g., at least one hundred completed rides in thirty days), a provider rating (e.g., 4.85+), a queue position (e.g., a wait time for switching to the online mode 210), a proximity to where the transport requests begin and/or end (e.g., a pickup/drop-off location), and/or a ride type (e.g., standard, wheel-chair accessible, premium, luxury, shared, shared saver, etc.)
At act 306, the provider efficiency control system 102 receives a request submitted from the provider device 105a via the dynamic transportation matching application 107a to switch from the offline mode 212 to the online mode 210. For example, the provider may be starting out for the day and opens the dynamic transportation matching application 107a to go into the online mode 210. As another example, the provider efficiency control system 102 may have recently switched the provider from the online mode 210 to the offline mode 212, and the provider now wishes to switch back to the online mode 210. In these or other embodiments, the request to switch from the offline mode 212 to the online mode 210 may include opening the dynamic transportation matching application 107a, which pings the provider efficiency control system 102. Additionally or alternatively, the request to switch from the offline mode 212 to the online mode 210 may include receiving the request to switch in response to a user input at the dynamic transportation matching application 107a (e.g., a selected button, interface touch gesture, voice command, etc.). In these or other embodiments, the request to switch may include metadata indicative of one or more aspects of the ride performance data 204 and the driver behavior 206, such as current location/geohash, direction, speed, destination.
At act 308, the provider efficiency control system 102 determines the provider device 105a is within the first geohash based on the received request to switch from the offline mode 212 to the online mode 210. For example, using the metadata associated with the request, the provider efficiency control system 102 may determine the provider device 105a is within the first geohash.
At act 310, the provider efficiency control system 102 determines the online mode control condition is active for the first geohash. For example, the provider efficiency control system 102 can identify that the current logic condition for the provider efficiency control system 102 includes the online mode control condition is still active. Additionally or alternatively, the provider efficiency control system 102 may rerun one or more logic rules described above with respect to act 302 to determine that the online mode control condition for the first geohash is still properly instated according to the steps and algorithms outlined in act 302.
At act 312, the provider efficiency control system 102 sends a request-denial notification with one or more of the dynamic responses 208 to the provider device 105a via the dynamic transportation matching application 107a. The request-denial notification may include digital content that when displayed at the dynamic transportation matching application 107a indicates to the provider a current inability to switch the provider device 105a from the offline mode 212 to the online mode 210 and/or a reason for the request-denial notification (e.g., too many providers in the currently-located geohash, too few transportation requests in the currently-located geohash, etc.).
At act 314, the provider device 105a receives the request-denial notification along with one or more of the dynamic responses 208 via the dynamic transportation matching application 107a. To switch, or at least increase a likelihood of switching from the offline mode 212 to the online mode 210, the provider may choose to select one or more of the dynamic responses 208 displayed at the dynamic transportation matching application 107a.
For example, the provider efficiency control system 102 may cause to display at the dynamic transportation matching application 107a some of the dynamic responses 208 that can include: relocating the vehicle position associated with the provider device 105a to a busier location; reserving a future time slot for the provider device 105a to be in the online mode 210 at a particular geographic area; repeating a request to switch from the offline mode 212 to the online mode 210 at a later time (e.g., at a driving time recommended by the dynamic transportation matching system 103); requesting an availability notification from the provider efficiency control system 102 that notifies the provider device 105a of a future availability to switch from the offline mode 212 to the online mode 210, using exemption tokens (described later in this disclosure), and/or any other suitable dynamic response for switching to the online mode 210. In other embodiments, the dynamic responses 208 may include repurposing efforts to contribute to the dynamic transportation matching system 103 (e.g., collecting scooters, attending to maintenance service of a vehicle, etc.).
As mentioned above, the provider efficiency control system 102 can dynamically size a pool of available providers to decrease a number of the provider devices 105a-105n in the online mode 210.
At act 406, the provider efficiency control system 102 determines that a first provider device (in this example, provider device 105a) and a second provider device (in this example, provider device 105b) satisfy an idle condition for a first threshold period of time. As mentioned above, the idle condition refers to P1 time, and therefore, the provider device 105a and the provider device 105b are associated with a designation as P1 providers because they are in the online mode 210 but are idling (i.e., not matched with a transportation request). In some embodiments, the idle condition begins at the end of fulfilling a transportation request (e.g., at drop-off, upon selection of an “end trip” button, etc.). Additionally or alternatively, the idle condition can be measured from the time of the last “accept” screen presented at the dynamic transportation matching application 107.
Furthermore, thresholds of the idle condition can be consecutive time periods in which the provider devices 105a-105n are in the idle condition. For example, the first threshold period of time may include ten consecutive minutes, thirty consecutive minutes, sixty consecutive minutes, ninety consecutive minutes, etc. Alternatively, the thresholds of the idle condition can be accumulated time periods over a predefined interval in which the provider devices 105a-105n are in the idle condition. Accordingly, in some embodiments, the first threshold period of time may, for example, include an aggregated two hours in the idle condition for a consecutive four-hour period of time, an aggregated three hours in the idle condition for a consecutive five-hour period of time, etc. Accordingly, a variety of ways of determining the first threshold are herein contemplated.
At act 408, the provider efficiency control system 102 sends an idle notification with one or more dynamic response recommendations to the provider devices 105a, 105b via the respective dynamic transportation matching applications 107a, 107b. The idle notification may include digital content that, when displayed at the dynamic transportation matching applications 107a, 107b, indicates to the respective providers the possibility that the provider efficiency control system 102 may switch their provider device from the online mode 210 to the offline mode 212. Additionally or alternatively, the idle notification may include digital content explaining why the provider efficiency control system 102 may switch their provider device from the online mode 210 to the offline mode 212 (e.g., too many providers in the currently-located geohash, too few transportation requests in the currently-located geohash, etc.).
In some embodiments, the provider efficiency control system 102 may cause to display the idle notification at the dynamic transportation matching applications 107a, 107b with some of the dynamic response recommendations that can include, for example: driving to a busier area, relocating a vehicle position associated with the provider devices 105a, 105b to another geohash, reserving a future time slot for the provider devices 105a, 105b to be guaranteed in the online mode 210 for a particular geographic area; using exemption tokens (described later in this disclosure), driving at a time and/or place recommended by the dynamic transportation matching system 103; requesting an availability notification from the provider efficiency control system 102 that notifies the provider devices 105a, 105b of a future availability to switch from the offline mode 212 to the online mode 210, and/or any other suitable dynamic response for remaining in the online mode 210 or later switching back to the online mode 210 from the offline mode 212. In other embodiments, the dynamic response recommendations may include repurposing efforts to contribute to the dynamic transportation matching system 103 (e.g., collecting scooters, attending to maintenance service of a vehicle, etc.).
At act 410, the provider device 105a sends, via the dynamic transportation matching application 107a, at least one of the dynamic response recommendations and/or indicates performance of at least one of the dynamic response recommendations. For example, the provider device 105a may begin to proceed towards a recommended driving area, request navigation to a certain busy geohash, redeem exemption tokens, etc. As referred to herein, “exemption tokens” or “tokens” can exempt a provider device from restrictions set according to the online mode control condition. For example, a token associated with the provider device permits a time-based or use-based exemption period from the online mode control condition such that the provider device can toggle between the online mode and the offline mode without restriction during the exemption period. In these or other embodiments, the provider efficiency control system 102 may selectively associate tokens with the provider devices 105a-105n for use during an active online mode control condition. For example, the provider efficiency control system 102 may selectively associate tokens with the provider devices 105a-105n according to a reward system, a loyalty system, a bonus system, a retention system, etc. Additionally or alternatively, the provider efficiency control system 102 can consider other types of exemption to the active online mode control condition. For example, an initial amount of time (e.g., the first thirty minutes, hour, two hours, etc.) in the online mode 210 for any of the provider devices 105a-105n may be exempt from the idle condition.
At act 412, the provider device 105b fails to select and/or indicate performance at least one of the dynamic response recommendations sent from the provider efficiency control system 102.
At act 414, the provider efficiency control system 102 determines for the provider device 105a, performance of the at least one dynamic response recommendation. For example, the provider efficiency control system 102 may receive the selection of the dynamic response recommendation (e.g., requesting navigation assistance to a busy geohash or hotspot). Additionally or alternatively, the provider efficiency control system 102 may receive one or more updated inputs 201 that indicate the user is attempting to navigate to another geohash (e.g., based on vehicle position associated with the provider device 105a).
At act 416, in response to the determination at act 414, the provider efficiency control system 102 permits the provider device 105a to remain in the online mode 210 such that the dynamic transportation matching system 103 and/or the provider efficiency control system 102 can send a transportation request matched to the provider device 105a, which ends the idle condition for the provider device 105a.
At act 418, in response to act 412, the provider efficiency control system 102 determines for the provider device 105b a condition of non-performance of a dynamic response recommendation. In particular, the provider efficiency control system 102 determines that the 105b fails to perform at least one dynamic response recommendation for a period of time satisfying a second threshold period of time. The second threshold period of time can be consecutive time periods in which the provider devices 105a-105b is in the idle condition. For example, the second threshold period of time may include thirty consecutive minutes, sixty consecutive minutes, ninety consecutive minutes, one hundred twenty consecutive minutes, etc. Alternatively, the thresholds of the idle condition can be accumulated time periods over a predefined interval in which the provider devices 105a-105b is in the idle condition. Accordingly, in some embodiments, the second threshold period of time may, for example, include an aggregated two hours in the idle condition for a consecutive four-hour period of time, an aggregated three hours in the idle condition for a consecutive five-hour period of time, etc. Accordingly, a variety of ways of determining the second threshold (including different ways from the first threshold) are herein contemplated.
At act 420, the provider efficiency control system 102 in response to the determination at act 418 switches the provider device 105b to the offline mode 212. At act 422, the provider efficiency control system 102 sends an offline notification to the provider device 105b via the dynamic transportation matching application 107b. In some embodiments, the offline notification may include digital content that when displayed at the dynamic transportation matching application 107b indicates to the provider a current status of the offline mode 212 and/or a reason for the offline notification (e.g., too many providers in the currently-located geohash, too few transportation requests in the currently-located geohash, etc.).
As mentioned above, the provider efficiency control system 102 can dynamically size a pool of available providers to decrease a number of the provider devices 105a-105n in the online mode 210.
At act 506, the provider efficiency control system 102 determines that a first vehicle (e.g., the provider device 105a) and a second vehicle (e.g., the provider device 105b) have exceeded a first threshold of consecutive ride cancellations or ride-assignment lapses. As referred to herein, the terms “cancellation” or “ride cancellation” refer to a transport request that a provider device accepts and subsequently aborts. Additionally, as referred to herein, the terms “lapse” or “ride-assignment lapse” refer to a transport request sent to the provider device for acceptance, to which the provider device does not indicate a response or otherwise denies acceptance.
Furthermore, thresholds of ride cancellations or ride-assignment lapses can account for scenarios involving ride cancellations only, ride-assignment lapses only, or a combination of ride cancellations and ride-assignment lapses. Thus, in some embodiments, the first threshold may include any of the following examples or other potential examples: one cancellation or lapse, two cancellations, one lapse and one cancellation, two lapses, two lapses and one cancellation, two cancellations and one lapse, three lapses, three cancellations, and so forth. In other embodiments, the first threshold of ride cancellations or ride-assignment lapses is not necessarily consecutive in nature. For example, the provider efficiency control system 102 may set the first threshold of ride cancellations or ride-assignment lapses as an aggregate number of ride cancellations or ride-assignment lapses over a period of time. Accordingly, a variety of ways of determining the first threshold of ride cancellations or ride-lapses are herein contemplated.
At act 508, the provider efficiency control system 102 sends a warning notification with one or more dynamic response recommendations to the provider devices 105a, 105b via the respective dynamic transportation matching applications 107a, 107b. The warning notification may include digital content that, when displayed at the dynamic transportation matching applications 107a, 107b, indicates to the respective providers the possibility that the provider efficiency control system 102 may switch their provider device from the online mode 210 to the offline mode 212. Additionally or alternatively, the warning notification may include digital content explaining why the provider efficiency control system 102 may switch their provider device from the online mode 210 to the offline mode 212 (e.g., too many ride cancellations or too many ride-lapses).
In some embodiments, the provider efficiency control system 102 may cause to display the warning notification at the dynamic transportation matching applications 107a, 107b with some of the dynamic response recommendations that can include, for example: accepting and completing one or more of the next few ride assignments, relocating a vehicle position for the provider devices 105a, 105b to another geohash, reserving a future time slot for the provider devices 105a, 105b to be guaranteed in the online mode 210 for a particular geographic area; using exemption tokens, driving at a time and/or place recommended by the dynamic transportation matching system 103; requesting an availability notification from the provider efficiency control system 102 that notifies the provider devices 105a, 105b of a future availability to switch from the offline mode 212 to the online mode 210, and/or any other suitable dynamic response for remaining in the online mode 210 or later switching back to the online mode 210 from the offline mode 212. In other embodiments, the dynamic response recommendations may include repurposing efforts to contribute to the dynamic transportation matching system 103 (e.g., collecting scooters, attending to maintenance service of a vehicle, etc.).
At act 510, the provider device 105a sends, via the dynamic transportation matching application 107a, at least one of the dynamic response recommendations and/or performs at least one of the dynamic response recommendations. For example, the provider device 105a may indicate acceptance and completion of the next transportation request, begin to proceed towards a recommended driving area, request navigation to a certain busy geohash, redeem exemption tokens, etc.
At act 512, the provider device 105b fails to select and/or indicate performance of at least one of the dynamic response recommendations sent from the provider efficiency control system 102.
At act 514, the provider efficiency control system 102 determines for the provider device 105a, performance of the at least one dynamic response recommendation. For example, the provider efficiency control system 102 may receive the selection of the dynamic response recommendation (e.g., accepting the next ride assignment, requesting navigation assistance to a busy geohash or hotspot, etc.). Additionally or alternatively, the provider efficiency control system 102 may receive one or more updated inputs 201 that indicate the user is en route with the requestor to a drop-off point for the accepted transport request (e.g., based on vehicle position associated with the provider device 105a).
At act 516, in response to the determination at act 514, the provider efficiency control system 102 permits the provider device 105a to remain in the online mode 210 such that the dynamic transportation matching system 103 and/or the provider efficiency control system 102 can send another transportation request matched to the provider device 105a.
At act 518, in response to act 512, the provider efficiency control system 102 determines for the provider device 105b a condition of non-performance of a dynamic response recommendation. In particular, the provider efficiency control system 102 determines that the provider device 105b fails to indicate performance of at least one dynamic response recommendation such that the provider device 105b satisfies a second threshold of ride cancellations or ride-assignment lapses. The second threshold of ride cancellations or ride-assignment lapses may include any of the following examples or other potential examples: two cancellations, one lapse and one cancellation, two lapses, two lapses and one cancellation, two cancellations and one lapse, three lapses, three cancellations, four lapses, two cancellations and two lapses, and so forth. In other embodiments, the second threshold of ride cancellations or ride-assignment lapses is not necessarily consecutive in nature. For example, the provider efficiency control system 102 may set the second threshold of ride cancellations or ride-assignment lapses as an aggregate number of ride cancellations or ride-assignment lapses over a period of time. Accordingly, a variety of ways of determining the second threshold of ride cancellations or ride-lapses are herein contemplated.
At act 520, the provider efficiency control system 102 in response to the determination at act 518 switches the provider device 105b to the offline mode 212. At act 522, the provider efficiency control system 102 sends an offline notification to the provider device 105b via the dynamic transportation matching application 107b. In some embodiments, the offline notification may include digital content that when displayed at the dynamic transportation matching application 107b indicates to the provider a current status of the offline mode 212 and/or a reason for the offline notification (e.g., too many ride cancellations or too many ride-lapses).
As mentioned above, the provider efficiency control system 102 can prohibit a provider device 105 from switching from the offline mode 212 to the online mode 210.
For example, GUI 604 includes a guidance string that recites “Can't go online now” with an explanation and prompt to be notified at a later time when the provider device can switch to the online mode 210. The prompt also includes a notification element (e.g., a “Notify me” button) by which a user can request such a notification from the provider efficiency control system 102. At the GUI 608, in response to a user input selecting the “Notify me” button at the GUI 606, the provider efficiency control system 102 causes to display a confirmation screen that confirms to the provider that the request to be notified at a better time to drive has been logged. For example, the guidance string in the GUI 608 recites “We'll notify you.”
In these or other embodiments, one or more of the GUIs 604-614 may include a link and/or expandable element that when selected describes why the provider cannot currently switch to the online mode 210 from the offline mode 212 (e.g., as displayed at the bottom of the GUI 608). For example, the GUI 614 may open, in response to a user input selection of the link in the GUI 608, the GUI 614 with an example set of user interface elements and digital content explaining why the provider is unable to switch to the online mode 210, tips for switching to the online mode 210, and/or tips for remaining in the online mode 210 once there.
At GUIs 610-612, the provider efficiency control system 102 causes to display at the dynamic transportation matching application 107 a set of recommended times and/or locations for driving that will increase a likelihood of being able to switch to the online mode 210. For some of the recommended times and/or locations, the provider efficiency control system 102 provides a selection element that the user can tap or swipe to turn on (e.g., to reserve a spot in that corresponding time frame, set a reminder alarm for, etc.). In some embodiments, the recommended times and/or locations may not necessarily guarantee the opportunity to switch to the online mode 210 at the reserved time (e.g., due to interim changes in the inputs 201). Additionally or alternatively, the provider efficiency control system 102 in some embodiments may accept tokens from the provider device 105 by which the provider can guarantee a reserved time slot (e.g., morning commute), event slot (e.g., DET vs. NYK at Madison Square Garden), or airport queue.
As mentioned above, the provider efficiency control system 102 can notify a provider device 105 upon determining an available opportunity to switch to the online mode 210.
In some embodiments, the provider efficiency control system 102 can cause the computing device 602 to display a notification, even when the computing device 602 does not currently have the dynamic transportation matching application 107 open. For example, GUI 702 indicates a banner notification from the provider efficiency control system 102 overlaying another opened application different from the dynamic transportation matching application 107, in which the banner notification indicates to the provider that now is a good time to switch to the online mode 210. Additionally or alternatively, the notification may include a time limit and/or a timer element indicating an amount of time for which the provider device 105 has to send to the provider efficiency control system 102 a response to the notification.
For instance, upon opening the dynamic transportation matching application 107 (e.g., by selecting the notification presented in the GUI 702), the provider efficiency control system 102 may cause the computing device 602 to display a countdown for which the user has to switch to the online mode 210 as shown for example in the GUI 704 with the countdown timer and associated “Go online” button. After receiving the user input selecting the “Go online” button of GUI 704, the provider efficiency control system 102 causes the computing device 602 to display a confirmation screen and/or tips to stay in the online mode 210 as shown for example in the GUI 706.
Further, after the provider device 105 is in the online mode 210, the provider efficiency control system 102 may cause the computing device 602 to display one or more statistics, goals, and/or other dashboard items, like the weekly goal shown in the GUI 708. Additionally, once in the online mode 210, the dynamic transportation matching system 103 may send a transport request for display and acceptance at the GUI 710.
As mentioned above, the provider efficiency control system 102 can prohibit a provider device 105 from switching from the offline mode 212 to the online mode 210.
Similar to
As shown in the GUIs 902-904, in some embodiments, the provider efficiency control system 102 can cause the dynamic transportation matching application 107 to display a pre-selected pinned hotspot (e.g., based on a closest proximity to the provider device 105). Additionally or alternatively, the provider efficiency control system 102 can reserve a spot for the provider device 105 in the online mode 210 at a pinned hotspot in response to receiving a user selection at a reserve button (e.g., “Save my spot”), which is also shown in the GUIs 902-904. However, in some embodiments, the reserved spot for the provider device 105 in the online mode 210 at the pinned hotspot may be time-limited. For example, the provider device 105 may have a finite period of time to navigate to the pinned hotspot as shown in the GUI 906. Further, in some embodiments, the provider efficiency control system 102 may cause the computing device 602 to display a countdown timer (not shown) indicating an amount of time remaining to relocate to the pinned hotspot, in which the countdown timer updates in real-time.
In these or other embodiments, the provider efficiency control system 102 can cause the dynamic transportation matching application 107 to present for user selection a pinned hotspot, which when selected, automatically reserves a spot for the provider device 105 in the online mode 210 at the pinned hotspot as selected (shown in GUIs 1002-1004). Additionally or alternatively, the provider efficiency control system 102 can reserve a spot for the provider device 105 in the online mode 210 at a pinned hotspot in response to receiving a user selection at a reserve button (e.g., “Save my spot”) as shown in the GUI 1006.
After the provider device 105 reaches a particular location within the pinned hotspot or is otherwise positioned within the boundaries of the pinned hotspot, the provider efficiency control system 102 may cause the dynamic transportation application 107 to prompt the provider to switch to the online mode 210 (e.g., via the “Go online” button) as shown in GUI 1010.
Similar to
If the dynamic transportation matching application 107 is open, the idle notification may appear as illustrated for example in the GUI 1302. If the dynamic transportation matching application 107 is not open, the idle notification may appear as illustrated for example in the GUI 1304. In either embodiment, the provider efficiency control system 102 indicates with the idle notification a dynamic response recommendation to drive to a busier area to keep receiving assigned transportation requests (i.e., to remain in the online mode 210). Additionally or alternatively to the idle notification, the provider efficiency control system 102 may prompt the provider to switch to the offline mode 212 as shown in the GUI 1306.
If the provider efficiency control system 102 determines that the provider device 105 did not relocate to a busier area (e.g., within a threshold period of time), the provider efficiency control system 102 may switch the provider device 105 to the offline mode 212 and send an offline notification as shown in one or both of the GUIs 1314-1316. In these or other embodiments, the offline notification may explain the reason for switching the provider device 105 to the offline mode 212 (e.g., too few transportation requests in the currently located geohash, too many of the provider devices 105a-105n in the online mode 210 in the currently located geohash, etc.). To get back into the online mode 210, the provider efficiency control system 102 provides at the GUI 1318 of the dynamic transportation matching application 107 opportunities to do so as described above in conjunction with the GUIs 604-614 of
The GUIs 1402-1404 illustrate a first lapsed ride-assignment, and the GUI 1406 illustrates a second lapsed ride-assignment. In response to one or more lapsed or cancelled ride-assignments, the provider efficiency control system 102 may cause the computing device 602 to display the warning notification shown for example in the GUIs 1408 or 1410 of the dynamic transportation matching application 107. As also indicated in the warning notification, the provider efficiency control system 102 can, in a dynamic response recommendation, expressly or implicitly instruct the provider to accept one or more of the next few ride assignments, or else risk being switched to the offline mode 212. The GUI 1412 illustrates a third lapsed ride-assignment, and as a result, the provider efficiency control system 102 switches the provider device 105 into the offline mode 212 and provides an offline notification to the dynamic transportation matching application 107 as shown in the example GUIs 1414-1416.
Each of the components 1602-1618 of the provider efficiency control system 102 can be implemented using a computing device including at least one processor executing instructions that cause the performance of the processes described herein. In some embodiments, the components 1602-1618 of the provider efficiency control system 102 can be implemented on a single server or across multiple servers. Additionally or alternatively, a combination of one or more server devices and one or more computing devices can implement the components described herein in a different arrangement than illustrated in
As illustrated in
Further, in some embodiments, the provider efficiency data manager 1606 handles the sending, receiving, storing, requesting, analyzing, and/or determining of provider efficiency data. For example, the provider efficiency data manager 1606 can determine a provider efficiency parameter for one or more geohashes, determine a number of online mode slots for one or more geohashes, prioritize filling the online mode slots with the provider devices 105a-105n, and make real-time adjustments to the provider efficiency data and associated online mode slots. Additionally, the provider efficiency data manager 1606 can execute logic for determining whether an online mode control condition is active and/or should be activated (e.g., due to the provider efficiency parameter being outside a target range).
Further, in some embodiments, the ETA data manager 1608 handles the sending, receiving, storing, requesting, analyzing, and/or determining of ETA data. For example, the ETA data manager 1608 can determine ETA metrics for one or more geohashes and determine ETA relationships between geohashes, providers and/or requestors. Additionally, the ETA data manager 1608 can execute logic for determining whether an online mode control condition is active and/or should be activated (e.g., due to an ETA constraint being within an upper bound).
As further illustrated, the provider efficiency control system 102 includes the provider device manager 1610, which handles a ride performance data manager 1612 and a driver behavior data manager 1614. In some embodiments, the ride performance data manager 1612 handles the sending, receiving, storing, requesting, analyzing, and/or determining of the metrics discussed above for the geohash conditions 202 that relate to the provider devices 105a-105n (e.g., position, direction, speed, idle time, pickup time, service time, etc.). In these or other embodiments, the ride performance data manager 1612 can handle driver ratings and reviews, vehicle type, service category type (e.g., standard, wheel-chair accessible, premium, luxury, shared, shared saver, etc.), driver preferences, and/or any other suitable data.
Further, the driver behavior data manager 1614 handles the sending, receiving, storing, requesting, analyzing, and/or determining of any decisions, selections, patterns, and any information derivative therefrom as related to the provider devices 105a-105n and their associated providers. For example, the driver behavior data manager 1614 may track accepted transport requests, lapsed transport requests (i.e., gone unaccepted), cancelled transport requests (i.e., accepted and then aborted), etc. Additionally or alternatively, the driver behavior data manager 1614 may track usual driving hours, routes, areas, and patterns of activity for the provider devices 105a-105n while in the online mode 210.
Additionally illustrated in
As shown in
It is understood that the outlined acts in the series of acts 1700a are only provided as examples, and some of the acts may be optional, combined into fewer acts, or expanded into additional acts without detracting from the essence of the disclosed embodiments. As an example of one or more additional or alternative acts not shown in
In yet another example of one or more additional or alternative acts not shown in
With respect to
In addition, the series of acts 1700b includes an act 1725 of detecting a pattern of behavior associated with a transportation provider device within the geographic area. In some embodiments, detecting the pattern of behavior comprises detecting an amount of idle time for the transportation provider device. Additionally or alternatively, in some embodiments, detecting the pattern of behavior comprises detecting a number of ride cancellations or ride-assignment lapses for the transportation provider device.
Further, the series of acts 1700b includes an act 1730 of comparing the pattern of behavior to a threshold. In some embodiments, comparing the pattern of behavior to the threshold comprises comparing the amount of idle time to a threshold idle time. Additionally or alternatively, in some embodiments, comparing the pattern of behavior to the threshold comprises comparing the number of ride cancellations or ride-assignment lapses to a threshold number of ride cancellations or ride-assignment lapses.
In addition, the series of acts 1700b includes an act 1735 of, based on the provider efficiency parameter and the comparison of the pattern of behavior to the threshold, causing the transportation provider device to switch from an online mode to an offline mode.
It is understood that the outlined acts in the series of acts 1700b are only provided as examples, and some of the acts may be optional, combined into fewer acts, or expanded into additional acts without detracting from the essence of the disclosed embodiments. As an example of one or more additional or alternative acts not shown in
With respect to
It is understood that the outlined acts in the series of acts 1700c are only provided as examples, and some of the acts may be optional, combined into fewer acts, or expanded into additional acts without detracting from the essence of the disclosed embodiments. As an example of one or more additional or alternative acts not shown in
As a further example, act(s) in the series of acts 1700c may include: determining a priority for transportation provider devices; and selectively filling online mode slots within the first geographic area and the second geographic area based at least in part on the priority for the transportation provider devices. Additionally or alternatively, act(s) in the series of acts 1700c may include determining the priority for the transportation provider devices based on historical data associated with the transportation provider devices. Further, act(s) in the series of acts 1700c may include, in response to determining that the transportation provider device has relocated to the second geographic area, allowing the transportation provider device to switch from the offline mode to the online mode within the second geographic area.
With respect to
Further, the series of acts 1700d includes an act 1770 of determining a priority associated with the one or more transportation provider devices. In some embodiments, the priority is based on historical data associated with the one or more transportation provider devices. Additionally or alternatively, in some embodiments, the priority is based on at least one of an acceptance rate for each of the one or more transportation provider devices, a number of completed rides for each of the one or more transportation provider devices, a rating for each of the one or more transportation provider devices, or available ride types for each of the one or more transportation provider devices. Additionally or alternatively, in some embodiments, the priority regulates access for filling available slots within the geographic area for the dynamic transportation matching system.
Additionally, the series of acts 1700d includes an act 1775 of selectively allowing the one or more transportation providers to switch from the offline mode to the online mode based on the provider efficiency parameter and the prioritization. In some embodiments, selectively allowing the one or more transportation providers to switch from the offline mode to the online mode comprises allowing a first transportation provider device to switch to the online mode and initially preventing a second transportation provider device from switching to the online mode. Additionally or alternatively, in some embodiments, selectively allowing the one or more transportation providers to switch from the offline mode to the online mode further comprises subsequently allowing the second transportation provider device to switch to the online mode.
Further, as with
As shown in
In particular embodiments, the processor(s) 1802 includes hardware for executing instructions, such as those making up a computer program. As an example, and not by way of limitation, to execute instructions, the processor(s) 1802 may retrieve (or fetch) the instructions from an internal register, an internal cache, memory 1804, or a storage device 1806 and decode and execute them.
The computing device 1800 includes memory 1804, which is coupled to the processor(s) 1802. The memory 1804 may be used for storing data, metadata, and programs for execution by the processor(s). The memory 1804 may include one or more of volatile and non-volatile memories, such as Random-Access Memory (“RAM”), Read-Only Memory (“ROM”), a solid-state disk (“SSD”), Flash, Phase Change Memory (“PCM”), or other types of data storage. The memory 1804 may be internal or distributed memory.
The computing device 1800 includes a storage device 1806 includes storage for storing data or instructions. As an example, and not by way of limitation, the storage device 1806 can include a non-transitory storage medium described above. The storage device 1806 may include a hard disk drive (HDD), flash memory, a Universal Serial Bus (USB) drive or a combination these or other storage devices.
As shown, the computing device 1800 includes one or more I/O interfaces 1808, which are provided to allow a user to provide input to (such as user strokes), receive output from, and otherwise transfer data to and from the computing device 1800. These I/O interfaces 1808 may include a mouse, keypad or a keyboard, a touch screen, camera, optical scanner, network interface, modem, other known I/O devices or a combination of such I/O interfaces 1808. The touch screen may be activated with a stylus or a finger.
The I/O interfaces 1808 may include one or more devices for presenting output to a user, including, but not limited to, a graphics engine, a display (e.g., a display screen), one or more output drivers (e.g., display drivers), one or more audio speakers, and one or more audio drivers. In certain embodiments, I/O interfaces 1808 are configured to provide graphical data to a display for presentation to a user. The graphical data may be representative of one or more graphical user interfaces and/or any other graphical content as may serve a particular implementation.
The computing device 1800 can further include a communication interface 1810. The communication interface 1810 can include hardware, software, or both. The communication interface 1810 provides one or more interfaces for communication (such as, for example, packet-based communication) between the computing device and one or more other computing devices or one or more networks. As an example, and not by way of limitation, communication interface 1810 may include a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wire-based network or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network, such as a WI-FI. The computing device 1800 can further include a bus 1818. The bus 1818 can include hardware, software, or both that connects components of the computing device 1800 to each other.
This disclosure contemplates any suitable network 1904. As an example, and not by way of limitation, one or more portions of the network 1904 may include an ad hoc network, an intranet, an extranet, a virtual private network (VPN), a local area network (LAN), a wireless LAN (WLAN), a wide area network (WAN), a wireless WAN (WWAN), a metropolitan area network (MAN), a portion of the Internet, a portion of the Public Switched Telephone Network (PSTN), a cellular telephone network, or a combination of two or more of these. The network 1904 may include one or more networks 1904.
Links may connect the client device 1906, the transportation matching system 1902, and the vehicle subsystem 1908 to the communication network 1904 or to each other. This disclosure contemplates any suitable links. In particular embodiments, one or more links include one or more wireline (such as for example Digital Subscriber Line (DSL) or Data Over Cable Service Interface Specification (DOCSIS), wireless (such as for example Wi-Fi or Worldwide Interoperability for Microwave Access (WiMAX), or optical (such as for example Synchronous Optical Network (SONET) or Synchronous Digital Hierarchy (SDH) links. In particular embodiments, one or more links each include an ad hoc network, an intranet, an extranet, a VPN, a LAN, a WLAN, a WAN, a WWAN, a MAN, a portion of the Internet, a portion of the PSTN, a cellular technology-based network, a satellite communications technology-based network, another link, or a combination of two or more such links. Links need not necessarily be the same throughout the network environment 1900. One or more first links may differ in one or more respects from one or more second links.
In particular embodiments, the client device 1906 may be an electronic device including hardware, software, or embedded logic components or a combination of two or more such components and capable of carrying out the appropriate functionalities implemented or supported by the client device 1906. As an example, and not by way of limitation, a client device 1906 may include any of the computing devices discussed above in relation to
In particular embodiments, the client device 1906 may include a transportation service application or a web browser, such as MICROSOFT INTERNET EXPLORER, GOOGLE CHROME or MOZILLA FIREFOX, and may have one or more add-ons, plug-ins, or other extensions, such as TOOLBAR or YAHOO TOOLBAR. A user at the client device 1906 may enter a Uniform Resource Locator (URL) or other address directing the web browser to a particular server (such as server), and the web browser may generate a Hyper Text Transfer Protocol (HTTP) request and communicate the HTTP request to server. The server may accept the HTTP request and communicate to client device 1906 one or more Hyper Text Markup Language (HTML) files responsive to the HTTP request. The client device 1906 may render a webpage based on the HTML files from the server for presentation to the user. This disclosure contemplates any suitable webpage files. As an example, and not by way of limitation, webpages may render from HTML files, Extensible Hyper Text Markup Language (XHTML) files, or Extensible Markup Language (XML) files, according to particular needs. Such pages may also execute scripts such as, for example and without limitation, those written in JAVASCRIPT, JAVA, MICROSOFT SILVERLIGHT, combinations of markup language and scripts such as AJAX (Asynchronous JAVASCRIPT and XML), and the like. Herein, reference to a webpage encompasses one or more corresponding webpage files (which a browser may use to render the webpage) and vice versa, where appropriate.
In particular embodiments, the transportation matching system 1902 may be a network-addressable computing system that can host a ride share transportation network. The transportation matching system 1902 may generate, store, receive, and send data, such as, for example, user-profile data, concept-profile data, text data, ride request data, GPS location data, provider data, requester data, vehicle data, or other suitable data related to the ride share transportation network. This may include authenticating the identity of providers and/or vehicles who are authorized to provide ride services through the transportation matching system 1902. In addition, the transportation service system may manage identities of service requestors such as users/requesters. In particular, the transportation service system may maintain requester data such as driving/riding histories, personal data, or other user data in addition to navigation and/or traffic management services or other location services (e.g., GPS services).
In particular embodiments, the transportation matching system 1902 may manage ride matching services to connect a user/requester with a vehicle and/or provider. By managing the ride matching services, the transportation matching system 1902 can manage the distribution and allocation of vehicle subsystem resources and user resources such as GPS location and availability indicators, as described herein.
The transportation matching system 1902 may be accessed by the other components of the network environment 1900 either directly or via network 1904. In particular embodiments, the transportation matching system 1902 may include one or more servers. Each server may be a unitary server or a distributed server spanning multiple computers or multiple datacenters. Servers may be of various types, such as, for example and without limitation, web server, news server, mail server, message server, advertising server, file server, application server, exchange server, database server, proxy server, another server suitable for performing functions or processes described herein, or any combination thereof. In particular embodiments, each server may include hardware, software, or embedded logic components or a combination of two or more such components for carrying out the appropriate functionalities implemented or supported by server. In particular embodiments, the transportation matching system 1902 may include one or more data stores. Data stores may be used to store various types of information. In particular embodiments, the information stored in data stores may be organized according to specific data structures. In particular embodiments, each data store may be a relational, columnar, correlation, or other suitable database. Although this disclosure describes or illustrates particular types of databases, this disclosure contemplates any suitable types of databases. Particular embodiments may provide interfaces that enable a client device 1906, or a transportation matching system 1902 to manage, retrieve, modify, add, or delete, the information stored in data store.
In particular embodiments, the transportation matching system 1902 may provide users with the ability to take actions on various types of items or objects, supported by the transportation matching system 1902. As an example, and not by way of limitation, the items and objects may include ride share networks to which users of the transportation matching system 1902 may belong, vehicles that users may request, location designators, computer-based applications that a user may use, transactions that allow users to buy or sell items via the service, interactions with advertisements that a user may perform, or other suitable items or objects. A user may interact with anything that is capable of being represented in the transportation matching system 1902 or by an external system of a third-party system, which is separate from the transportation matching system 1902 and coupled to the transportation matching system 1902 via a network 1904.
In particular embodiments, the transportation matching system 1902 may be capable of linking a variety of entities. As an example, and not by way of limitation, the transportation matching system 1902 may enable users to interact with each other or other entities, or to allow users to interact with these entities through an application programming interfaces (API) or other communication channels.
In particular embodiments, the transportation matching system 1902 may include a variety of servers, sub-systems, programs, modules, logs, and data stores. In particular embodiments, the transportation matching system 1902 may include one or more of the following: a web server, action logger, API-request server, relevance-and-ranking engine, content-object classifier, notification controller, action log, third-party-content-object-exposure log, inference module, authorization/privacy server, search module, advertisement-targeting module, user-interface module, user-profile store, connection store, third-party content store, or location store. The transportation matching system 1902 may also include suitable components such as network interfaces, security mechanisms, load balancers, failover servers, management-and-network-operations consoles, other suitable components, or any suitable combination thereof. In particular embodiments, the transportation matching system 1902 may include one or more user-profile stores for storing user profiles. A user profile may include, for example, biographic information, demographic information, behavioral information, social information, or other types of descriptive information, such as work experience, educational history, hobbies or preferences, interests, affinities, or location.
The web server may include a mail server or other messaging functionality for receiving and routing messages between the transportation matching system 1902 and one or more client devices 1906. An action logger may be used to receive communications from a web server about a user's actions on or off the transportation matching system 1902. In conjunction with the action log, a third-party-content-object log may be maintained of user exposures to third-party-content objects. A notification controller may provide information regarding content objects to a client device 1906. Information may be pushed to a client device 1906 as notifications, or information may be pulled from the client device 1906 responsive to a request received from the client device 1906. Authorization servers may be used to enforce one or more privacy settings of the users of the transportation matching system 1902. A privacy setting of a user determines how particular information associated with a user can be shared. The authorization server may allow users to opt in to or opt out of having their actions logged by the transportation matching system 1902 or shared with other systems, such as, for example, by setting appropriate privacy settings. Third-party-content-object stores may be used to store content objects received from third parties. Location stores may be used for storing location information received from the client devices 1906 associated with users.
In addition, the vehicle subsystem 1908 can include a human-operated vehicle or an autonomous vehicle. A provider of a human-operated vehicle can perform maneuvers to pick up, transport, and drop off one or more requesters according to the embodiments described herein. In certain embodiments, the vehicle subsystem 1908 can include an autonomous vehicle—i.e., a vehicle that does not require a human operator. In these embodiments, the vehicle subsystem 1908 can perform maneuvers, communicate, and otherwise function without the aid of a human provider, in accordance with available technology.
In particular embodiments, the vehicle subsystem 1908 may include one or more sensors incorporated therein or associated thereto. For example, sensor(s) can be mounted on the top of the vehicle subsystem 1908 or else can be located within the interior of the vehicle subsystem 1908. In certain embodiments, the sensor(s) can be located in multiple areas at once—i.e., split up throughout the vehicle subsystem 1908 so that different components of the sensor(s) can be placed in different locations in accordance with optimal operation of the sensor(s). In these embodiments, the sensor(s) can include a LIDAR sensor and an inertial measurement unit (IMU) including one or more accelerometers, one or more gyroscopes, and one or more magnetometers. The sensor suite can additionally or alternatively include a wireless IMU (WIMU), one or more cameras, one or more microphones, or other sensors or data input devices capable of receiving and/or recording information relating to navigating a route to pick up, transport, and/or drop off a requester.
In particular embodiments, the vehicle subsystem 1908 may include a communication device capable of communicating with the client device 1906 and/or the transportation matching system 1902. For example, the vehicle subsystem 1908 can include an on-board computing device communicatively linked to the network 1904 to transmit and receive data such as GPS location information, sensor-related information, requester location information, or other relevant information.
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. Various embodiments and aspects of the invention(s) are described with reference to details discussed herein, and the accompanying drawings illustrate the various embodiments. The description above and drawings are illustrative of the invention and are not to be construed as limiting the invention. Numerous specific details are described to provide a thorough understanding of various embodiments of the present invention.
The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. For example, the methods described herein may be performed with less or more steps/acts or the steps/acts may be performed in differing orders. Additionally, the steps/acts described herein may be repeated or performed in parallel with one another or in parallel with different instances of the same or similar steps/acts. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. Various embodiments and aspects of the invention(s) are described with reference to details discussed herein, and the accompanying drawings illustrate the various embodiments. The description above and drawings are illustrative of the invention and are not to be construed as limiting the invention. Numerous specific details are described to provide a thorough understanding of various embodiments of the present invention.
The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. For example, the methods described herein may be performed with less or more steps/acts or the steps/acts may be performed in differing orders. Additionally, the steps/acts described herein may be repeated or performed in parallel with one another or in parallel with different instances of the same or similar steps/acts. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.
Claims
1. A computer-implemented method comprising:
- determining, for a first geographic area, a provider efficiency parameter associated with a dynamic transportation matching system;
- receiving, from a transportation provider device within the first geographic area, a request to switch from an offline mode to an online mode for the dynamic transportation matching system;
- based on the provider efficiency parameter associated with the first geographic area, preventing the transportation provider device from switching to the online mode within the first geographic area; and
- providing, for display by the transportation provider device, a map interface indicating a second geographic area different from the first geographic area, where the transportation provider device can switch from the offline mode to the online mode.
2. The computer-implemented method of claim 1, further comprising providing, for display by the transportation provider device, a selectable option for reserving an online mode slot for the second geographic area.
3. The computer-implemented method of claim 2, further comprising reserving, based on a selection of the selectable option, the online mode slot for the transportation provider device for the second geographic area.
4. The computer-implemented method of claim 3, further comprising canceling the reservation of the online mode slot for the transportation provider device for the second geographic area if the transportation provider device does not relocate to the second geographic area within a predetermined amount of time.
5. The computer-implemented method of claim 1, further comprising:
- determining a priority for transportation provider devices; and
- selectively filling online mode slots within the first geographic area and the second geographic area based at least in part on the priority for the transportation provider devices.
6. The computer-implemented method of claim 5, further comprising determining the priority for the transportation provider devices based on historical data associated with the transportation provider devices.
7. The computer-implemented method of claim 1, further comprising, in response to determining that the transportation provider device has relocated to the second geographic area, allowing the transportation provider device to switch from the offline mode to the online mode within the second geographic area.
8. A dynamic transportation matching system comprising:
- one or more memory devices; and
- one or more computing devices configured to: determine, for a first geographic area, a provider efficiency parameter associated with a dynamic transportation matching system; receive, from a transportation provider device within the first geographic area, a request to switch from an offline mode to an online mode for the dynamic transportation matching system; based on the provider efficiency parameter associated with the first geographic area, prevent the transportation provider device from switching to the online mode within the first geographic area; and provide, for display by the transportation provider device, a map interface indicating a second geographic area different from the first geographic area, where the transportation provider device can switch from the offline mode to the online mode.
9. The dynamic transportation matching system of claim 8, wherein the one or more computing devices are further configured to provide, for display by the transportation provider device, a selectable option for reserving an online mode slot for the second geographic area.
10. The dynamic transportation matching system of claim 9, wherein the one or more computing devices are further configured to reserve, based on a selection of the selectable option, the online mode slot for the transportation provider device for the second geographic area.
11. The dynamic transportation matching system of claim 10, wherein the one or more computing devices are further configured to cancel the reservation of the online mode slot for the transportation provider device for the second geographic area if the transportation provider device does not relocate to the second geographic area within a predetermined amount of time.
12. The dynamic transportation matching system of claim 8, wherein the one or more computing devices are further configured to:
- determine a priority for transportation provider devices; and
- selectively fill online mode slots within the first geographic area and the second geographic area based at least in part on the priority for the transportation provider devices.
13. The dynamic transportation matching system of claim 12, wherein the one or more computing devices are further configured to determine the priority for the transportation provider devices based on historical data associated with the transportation provider devices.
14. The dynamic transportation matching system of claim 8, wherein the one or more computing devices are further configured to, in response to determining that the transportation provider device has relocated to the second geographic area, allow the transportation provider device to switch from the offline mode to the online mode within the second geographic area.
15. A non-transitory computer-readable medium comprising instructions that, when executed by at least one processor, cause a computing system to:
- determine, for a first geographic area, a provider efficiency parameter associated with a dynamic transportation matching system;
- receive, from a transportation provider device within the first geographic area, a request to switch from an offline mode to an online mode for the dynamic transportation matching system;
- based on the provider efficiency parameter associated with the first geographic area, prevent the transportation provider device from switching to the online mode within the first geographic area; and
- provide, for display by the transportation provider device, a map interface indicating a second geographic area different from the first geographic area, where the transportation provider device can switch from the offline mode to the online mode.
16. The non-transitory computer-readable medium of claim 15, further comprising instructions that, when executed by the at least one processor, cause the computing system to provide, for display by the transportation provider device, a selectable option for reserving an online mode slot for the second geographic area.
17. The non-transitory computer-readable medium of claim 16, further comprising instructions that, when executed by the at least one processor, cause the computing system to reserve, based on a selection of the selectable option, the online mode slot for the transportation provider device for the second geographic area.
18. The non-transitory computer-readable medium of claim 17, further comprising instructions that, when executed by the at least one processor, cause the computing system to cancel the reservation of the online mode slot for the transportation provider device for the second geographic area if the transportation provider device does not relocate to the second geographic area within a predetermined amount of time.
19. The non-transitory computer-readable medium of claim 15, further comprising instructions that, when executed by the at least one processor, cause the computing system to:
- determine a priority for transportation provider devices; and
- selectively fill online mode slots within the first geographic area and the second geographic area based at least in part on the priority for the transportation provider devices.
20. The non-transitory computer-readable medium of claim 19, further comprising instructions that, when executed by the at least one processor, cause the computing system to determine the priority for the transportation provider devices based on historical data associated with the transportation provider devices.
Type: Application
Filed: Nov 1, 2019
Publication Date: Dec 31, 2020
Inventors: Helen Wai-Quen Bentley (San Francisco, CA), Aidan Church (San Francisco, CA), John Torres Fremlin (New York City, NY), Matthew Lawrence Green (San Francisco, CA), Mayank Gulati (San Francisco, CA), Yilei Li (Redwood City, CA), Demitri Nava (New York City, NY), Mengqi Niu (San Francisco, CA), Daniel Allen Sullivan (San Francisco, CA), Garrett van Ryzin (Brooklyn, NY), Rachel Marie Wasko (San Francisco, CA), Shashi Kant Sharma (Redwood City, CA)
Application Number: 16/672,250
