US20230162114A1 - Generating and communicating device balance graphical representations for a dynamic transportation system - Google Patents
Generating and communicating device balance graphical representations for a dynamic transportation system Download PDFInfo
- Publication number
- US20230162114A1 US20230162114A1 US18/157,655 US202318157655A US2023162114A1 US 20230162114 A1 US20230162114 A1 US 20230162114A1 US 202318157655 A US202318157655 A US 202318157655A US 2023162114 A1 US2023162114 A1 US 2023162114A1
- Authority
- US
- United States
- Prior art keywords
- provider
- metrics
- earnings
- computing devices
- generate
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000009826 distribution Methods 0.000 claims abstract description 58
- 238000000034 method Methods 0.000 claims abstract description 24
- 238000004891 communication Methods 0.000 claims description 25
- 238000010801 machine learning Methods 0.000 claims description 5
- 238000013507 mapping Methods 0.000 claims description 2
- 238000012544 monitoring process Methods 0.000 claims 1
- 230000001186 cumulative effect Effects 0.000 description 32
- 230000015654 memory Effects 0.000 description 17
- 239000003607 modifier Substances 0.000 description 12
- 230000001932 seasonal effect Effects 0.000 description 9
- 230000009471 action Effects 0.000 description 8
- 230000008901 benefit Effects 0.000 description 7
- 230000005540 biological transmission Effects 0.000 description 6
- 230000003993 interaction Effects 0.000 description 6
- 230000008569 process Effects 0.000 description 6
- 238000012800 visualization Methods 0.000 description 6
- 230000000007 visual effect Effects 0.000 description 5
- 238000010586 diagram Methods 0.000 description 4
- 238000005516 engineering process Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 230000003287 optical effect Effects 0.000 description 4
- 238000013459 approach Methods 0.000 description 3
- 238000013528 artificial neural network Methods 0.000 description 3
- 238000013475 authorization Methods 0.000 description 3
- 238000005259 measurement Methods 0.000 description 3
- 230000004044 response Effects 0.000 description 3
- 230000001413 cellular effect Effects 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 229920001690 polydopamine Polymers 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 238000013515 script Methods 0.000 description 2
- 238000013403 standard screening design Methods 0.000 description 2
- 230000001360 synchronised effect Effects 0.000 description 2
- 238000012546 transfer Methods 0.000 description 2
- 230000003442 weekly effect Effects 0.000 description 2
- VYZAMTAEIAYCRO-UHFFFAOYSA-N Chromium Chemical compound [Cr] VYZAMTAEIAYCRO-UHFFFAOYSA-N 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 230000003542 behavioural effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000013527 convolutional neural network Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000012417 linear regression Methods 0.000 description 1
- 238000007477 logistic regression Methods 0.000 description 1
- 230000014759 maintenance of location Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 238000011176 pooling Methods 0.000 description 1
- 230000035755 proliferation Effects 0.000 description 1
- 230000000306 recurrent effect Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/02—Reservations, e.g. for tickets, services or events
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
- G06Q10/06315—Needs-based resource requirements planning or analysis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
- G06Q50/30—Transportation; Communications
-
- G06Q50/40—
Definitions
- Embodiments of the present disclosure provide benefits and/or solve one or more of the foregoing or other problems in the art with systems, non-transitory computer-readable media, and methods for generating provider device balance graphs reflecting device utilization ratios between provider devices and requester devices.
- the disclosed systems can determine market balance measures over a target time period based on driver supply hours and requester device application sessions within the target time period. Further, the disclosed systems can utilize the market balance measures to generate and display provider device balance graphs to provider devices.
- the disclosed system can apply various scaling models to create an intuitive visual scale to address seasonality, special events, and/or differences between regions.
- the disclosed systems can also apply thresholds to generate smooth visual scales that allow driver devices to more accurately determine driving schedules. In this manner, the disclosed systems can avoid distortions that result from large fluctuations in requestor device demand and provide a more accurate reflection of provider device incentives across a transportation matching system.
- the disclosed systems determine device utilization ratios for a period of time based on projections for device utilization for requester computing devices and device utilization for provider computer devices across time periods. Then, the disclosed systems can utilize a probability distribution for a representative time period to determine probabilities for the device utilization ratios. In one or more embodiments, the disclosed systems map device utilization rations and/or probabilities to “bins” and utilize those bins to generate a provider device balance graph. By utilizing device utilization ratios between utilization of provider devices and requester devices, the disclosed systems can display provider device balance graphs that more accurately reflect transportation times for provider devices, that allow for more efficient scheduling of provider devices, and that lead to more efficient operation of implementing computer systems.
- FIG. 1 illustrates a diagram of an environment in which a provider balance system can operate in accordance with one or more embodiments.
- FIGS. 2 A- 2 C illustrate example graphical user interfaces for a provider balance system in accordance with one or more embodiments.
- FIG. 3 illustrates an overview of generating a provider device balance graph in accordance with one or more embodiments.
- FIG. 4 illustrates utilizing a probability distribution to generate probabilities in accordance with one or more embodiments.
- FIG. 5 illustrates binning probabilities according to determined bin ranges in accordance with one or more embodiments.
- FIG. 6 illustrates generating and utilizing an earnings-ridership metric for a provider balance system in accordance with one or more embodiments.
- FIG. 7 illustrates a provider scheduling graphical user interface in accordance with one or more embodiments.
- FIG. 8 illustrates applying event and seasonal adjustments to provider incentive graphs in accordance with one or more embodiments.
- FIG. 9 illustrates a flowchart of a series of acts for a provider balance system in accordance with one or more embodiments.
- FIG. 10 illustrates a block diagram of an example computing device for implementing one or more embodiments of the present disclosure.
- FIG. 11 illustrates a block diagram of an example transportation matching system in accordance with one or more embodiments.
- This disclosure describes one or more embodiments of a provider balance system that generates provider device balance graphs reflecting device utilization ratios between provider devices and requester devices. More specifically, the provider balance system can determine device utilization ratios for various time periods based on projections for utilization of provider devices and requester devices. The provider balance system can utilize the device utilization ratios to generate a provider device balance graph. By utilizing a provider device balance graph that reflects such market balance metrics, the provider balance system can more accurately represent provider device utilization rate and earnings relative to conventional systems. Indeed, the provider balance system can avoid distortions in driver device incentives and reduce inefficiencies across transportation matching systems that result from pure demand metrics.
- the provider balance system can determine predicted requester computing device application sessions and predicted computing device availability within a given region and within a given time period. Then, the provider balance system can determine device utilization ratios for the given time period based on the forecast measures. Further, the provider balance system can determine probabilities of the device utilization ratios. The provider balance system can then generate and provide a provider device balance graph portraying the probabilities for efficient communication of provider incentives and deployment of provider devices.
- the provider balance system can generate and utilize various predicted device utilization measures for provider devices and requestor devices.
- the provider balance system utilizes a number driver supply hours to forecast driver device utilization and utilizes a number of requester device application sessions to forecast requester device utilization.
- the provider balance system can utilize a variety of particular metrics to predicted device utilization. For example, the provider balance system can forecast a number of requests, a number of hours required to fulfil requests, or a cumulative distance needed to be driven to fulfil requests. Further, the provider balance system can forecast a number of providers, a number of provider miles, or a number of transportation services (e.g., rides).
- the provider balance system can utilize forecast metrics to generate device utilization ratios. More specifically, in one or more embodiments, the provider balance system can generate the device utilization ratios as a ratio of requester device application sessions and provider device availability. For example, the provider balance system can generate the device utilization ratios by determining the ratio of the number of application sessions over a time period to a number of driver supply hours for the same time period.
- the provider balance system can also determine probabilities.
- the provider balance system can determine probabilities by applying a probability distribution to forecasted device utilization ratios. For example, the provider balance system can determine a probability distribution that reflects probabilities of device utilization ratios for a representative time period (e.g., an average week). The provider balance system can then utilize the probability distribution to determine probabilities.
- the provider balance system can utilize a probability distribution to determine percentile bins that reflect ranges of cumulative probabilities and corresponding ranges of device utilization ratios. The provider balance system can then map forecast device utilization ratios to the appropriate percentile bins to generate probabilities.
- the provider balance system can also generate device utilization ratios by applying device balance thresholds. Indeed, the provider balance system can further avoid distortion by applying upper and/or lower thresholds of device utilization ratios. For example, in some embodiments, the provider balance system can constrain the minimum device utilization ratio (or probability) to a lower threshold (e.g., a 10 percent lower bound). Similarly, the provider balance system can map the maximum device utilization ratio (or probability) to an upper threshold (e.g., a 100 percent upper bound).
- the provider balance system can also apply various scales to device utilization ratios. For instance, in some embodiments, the provider balance system can apply a seasonal scaling to reflect variations in device utilization ratios across seasons. In addition, the provider balance system can apply an event scaling (e.g., multiplicatively) to reflect variations in device utilization ratios specific to particular events.
- event scaling e.g., multiplicatively
- the provider balance system can also generate and utilize provider device ridership metrics. For example, in some embodiments, the provider balance system generates provider device ridership metrics that reflect projected earnings corresponding to provider devices in light of ridership corresponding to requestor devices. Specifically, the provider balance system can generate ridership metrics based on a projected earnings metric and the radical of a projected number of rides. The provider balance system can utilize these earnings-ridership metrics to generate one or more provider device balance graphs.
- the provider balance system can generate provider device balance graphs and can provide these provider device balance graphs for display in graphical user interfaces via provider devices. For example, the provider balance system can generate a timeline of probabilities and provide the timeline for display to provider devices to more efficiently distribute provider devices across different times (e.g., hours) within a target time period (e.g., a day). The provider balance system can also generate and provide recommend transportation schedules for provider devices based on device utilization ratios.
- the provider balance system provides many advantages and benefits over conventional systems and methods. For example, by utilizing device balance metrics and/or probability distributions the provider balance system can improve accuracy relative to conventional systems. Specifically, the provider balance system can generate and display provider device balance graphs that accurately communicate provider device incentives without undue distortion caused by spikes or other fluctuations in requester device demand. The provider balance system can utilize probability distributions to determine provider device balance graphs that are smoother and easier to understand and that more accurately convey transportation times to provider devices.
- the provider balance system improves efficiency for the implementing transportation matching system. Indeed, the provider balance system more accurately conveys incentives across provider device transportation times and therefore reduces imbalances across provider devices and requester devices.
- the provider balance system can thus reduce spike imbalances between provider devices and requester devices and reduce the burdens on implementing computing systems in seeking to matching provider devices and requester devices under such circumstances.
- the provider incentive system can reduce the number of repeat requests for providers and/or requesters, queries for updates, and/or queries for transportation provider status reports that result from device imbalances.
- the provider balance system also provides better projections and yields better requester and provider experience by ensuring that provider devices align to demands from requester devices.
- the term “transportation request” refers to a query, demand, or invitation for transportation services.
- a requester can interact with one or more user interfaces of a requester application on a requester device to configure a transportation request (e.g., to indicate a requested pickup location, a requested drop-off location, a requested type of transportation, and/or a requested time of transportation), and then submit the transportation request to the transportation matching system.
- a “requester” refers to an individual that has submitted (or will submit) a transportation request.
- a “requester device” (or “requester computing device”) refer to a computing device that submits (or has submitted) a request (e.g., a computing device associated with a requestor).
- provider refers to an individual, entity, or vehicle that provides transportation services.
- provider device or “provider computing device” refer to a computing device associated with a provider (e.g., a computing device associated with a driver or automated vehicle). Additional detail regarding provider devices and requester devices is provided below (e.g., in relation to FIG. 1 ).
- predicted device utilization refers to a forecast metric or measurement reflecting an extent that one or more devices will be used.
- a predicted device utilization can include a metric that conveys a predicted supply, and/or demand of requester devices and/or provider devices.
- the provider balance system can generate a predicted device utilization for requester computing devices as a forecast measure of requester computing device application sessions.
- a predicted device utilization for provider computing device can include a predicted metric of a supply of transportation services or provider device availability.
- predicted device utilization for provider computing devices can include a number of hours utilized to provide transportation services during a specified time (e.g., a predicted number of driver hours available to provide transportation services during a specified time).
- a device utilization ratio refers to a metric reflecting both predicted device utilization for provider computing devices and requester computing devices.
- a device utilization ratio can include a ratio of the number of application sessions over a time period to a number of driver supply hours for the same time period.
- the term “probabilities” refers to a likelihood of a particular result (e.g., a probability of a utilization ration determined based on a probability distribution).
- the provider balance system can determine a probability distribution (e.g., a correlation between probabilities and values of a variable) of device utilization ratios.
- the provider balance system can then map device utilization ratios to probabilities utilizing the probability distribution. For example, a device utilization ratio of 0.5 may map to a probability of 15 (e.g., a 15% inverse cumulative probability of achieving a 0.5 device utilization ratio or lower during the time period).
- provider device balance graph refers to a visual representation of relative supply and/or demand.
- provider device balance graph can include a graphical representation of device utilization ratios, probabilities, and/or provider device earnings-ridership metrics.
- a provider balance system can include provider device balance graph in a graphical user interface within a provider application.
- the term “bins” refers to a grouping or range of data.
- the term “bins” can include a range of device utilization ratios corresponding to a range of probabilities.
- the provider balance system 116 can identify an 80%-90% probability bin defined by a range of device utilization ratios corresponding to an 80% inverse cumulative probability and a 90% inverse cumulative probability.
- the term “provider device ridership metric” refers to a metric based on earnings for a provider and ridership.
- the term “provider device ridership metric” can include metric based on a projected earnings metric and the radical of a projected number of rides.
- the term “radical” refers to the root of a number or quantity. In particular, the term “radical” can include a square root, a cube root, or a root with another radicand.
- the term “event modifier” refers to a metric corresponding to an event.
- the term “event modifier” can include a value corresponding to a scale at which an event will escalate demand in a given time and/or location.
- an event modifier can include a variety of metrics and/or measures corresponding to increased demand expected and/or experienced as a result of an event such as a concert, sporting event, performance, etc.
- a “seasonal modifier” can include a metric corresponding to a particular season (e.g., increased demand expected due to a particular month, week, or other time of year).
- FIG. 1 illustrates an environment 100 including requester device(s) 102 , each implementing a requester application 104 , and provider device(s) 106 , implementing a provider application 108 .
- the requester device(s) 102 communicate, via a network 110 , with server device(s) 112 .
- the server device(s) 112 can implement a transportation matching system 114 , which in turn can include a provider balance system 116 .
- FIG. 1 illustrates the provider balance system 116 implemented via the server device(s) 112
- the provider balance system 116 can be implemented via other components.
- the provider balance system 116 can be implemented in whole, or in part, by the requester device(s) 102 and/or the provider device(s) 106 .
- the requester device(s) 102 can include various types of computing devices.
- the requester device(s) 102 can include smart phones, tablets, smart watches, laptop computers, or other mobile computing devices, such as further explained below with reference to FIG. 10 .
- the requester application 104 can include various types of requester applications.
- the requester application 104 can be a web application (e.g., accessed using a web browser) or a native application provided by the transportation matching system 114 for communicating with and accessing the services of the transportation matching system 114 (e.g., to request transportation).
- the provider device(s) 106 can include various types of computing devices (e.g., a smartphone or integrated computing device within an autonomous vehicle), and the provider application 108 can include a web or native application for communicating with and accessing the services of the transportation matching system 114 (e.g., to provide transportation services to one or more requesters). Additionally, the server device(s) 112 can include one or more computing devices, such as those explained below with reference to FIG. 10 .
- the requester device(s) 102 , the provider device(s) 106 , and the transportation matching system 114 may communicate by way of the network 110 , which can include one or more communications networks using communication platforms and technologies suitable for transporting data and/or communication signals, examples of which are described with reference to FIG. 10 .
- the transportation matching system 114 dynamically matches transportation requests received from requesters (e.g., requesters associated with requester device(s) 102) with available transportation service providers (e.g., transportation providers associated with the provider device(s) 106 ).
- a transportation matching system can identify transportation requests, identify potential transportation provider devices, determine locations of requester devices and provider devices, and match provider devices and requester devices based on a variety of criteria.
- the transportation matching system 114 can perform various actions for determining and communicating supply and demand to providers so that providers can drive at appropriate/optimal times.
- the transportation matching system 114 utilizes the provider balance system 116 to determine, visualize, and communicate supply and demand information.
- FIGS. 2 A- 2 C illustrate example graphical user interfaces utilized by one or more transportation matching systems.
- FIG. 2 A illustrates a user interface generated in accordance with one or more conventional systems described above.
- FIG. 2 A illustrates a user interface 200 that visualizes demand only.
- FIGS. 2 B- 2 C illustrate provider device balance graphs generated by the provider balance system 116 in accordance with one or more embodiments.
- FIG. 2 B illustrates a provider device balance graphical user interface 202 with a provider device balance graph 210 visualizing device utilization ratios
- FIG. 2 C illustrates a provider device balance graphical user interface 204 with a provider device balance graph 220 visualizing probabilities.
- the provider balance system 116 can generate device incentive graphs that more accurately and efficiently distribute provider devices.
- the provider device balance graph 210 visualizes device utilization ratios over the same time period visualized in FIG. 2 A . More specifically, the provider device balance graph 210 visualizes device utilization ratios determined based on forecasted requester device sessions and driver supply hours. As shown, the provider device balance graph 210 is much less distorted and avoids drastic spikes throughout the target time period.
- the provider device balance graph 210 in FIG. 2 B is much more efficient in distributing provider devices because it illustrates relative balance between requester devices and provider devices over the time period rather than raw demand.
- FIG. 2 C illustrates a provider device balance graph 220 that reflects probabilities. That is, the provider device balance graph 220 reflects device utilization ratios that have been modified utilizing a probability distribution. Specifically, each of the bars in the provider device balance graph 220 reflect a cumulative probability (e.g., an inverse cumulative probability) of a corresponding forecast measure. In one or more embodiments, the provider balance system 116 utilizes a probability distribution to determine bins for device utilization ratios. As shown in FIG. 2 C , the visualization of probabilities further smooths the device incentive graph in order to communicate to the provider the relative benefit of providing transportation services at various times.
- a cumulative probability e.g., an inverse cumulative probability
- the provider balance system 116 can provide a variety of user interface elements for interacting with device incentive graphs.
- the provider device balance graphical user interface 204 can include a time selection element 222 .
- a time selection element 222 can include a user interface element for selecting time periods.
- the provider balance system 116 can include a provider device balance graph for a different time period. For example, upon user interaction with the time selection element 222 the provider balance system 116 can generate a provider device balance graph for a specified week rather than a specified day.
- the provider device balance graphical user interface 204 can also include a set goal button 224 .
- the provider balance system 116 can present the provider device with a scheduling graphical user interface.
- the provider balance system 116 can generate scheduling elements that automatically assist the provider to select times to provide transportation services. Additional detail regarding suggesting a transportation service schedule via a scheduling graphical user interface is provided below (e.g., in relation to FIG. 7 ).
- the provider device balance graphical user interface 204 can also include other user interface elements, such as a home tab 226 , an earnings tab 228 , and a scheduling tab 230 .
- the provider balance system 116 can display a default or home screen in response to detecting selection of the home tab 226 .
- the provider balance system 116 can also present the provider device balance graphical user interface 204 in response to detecting selection of the earnings tab 228 .
- the provider balance system 116 can present a scheduling graphical user interface upon detecting selection of the scheduling tab 230 (e.g., a scheduling interface that includes scheduled transportation times to achieve a particular goal).
- the provider balance system 116 can determine device utilization ratios and probabilities and generate provider device balance graphs.
- FIG. 3 illustrates a series of acts 302 - 310 utilized to generate a provider device balance graph in accordance with one or more embodiments.
- the provider balance system 116 performs an act 302 of detecting requester devices and provider devices at a location.
- the provider balance system 116 can track historical and current data as to the volume and type of interactions of both requester device(s) 102 and provider device(s) 106 over various locations where the transportation matching systems offers transportation services.
- the provider balance system 116 can monitor the number of application sessions from requester devices over time for different geographic regions.
- the provider balance system 116 can monitor the number of provider devices (or provider device hours) over time for different geographic regions.
- the provider balance system 116 can monitor a variety of other metrics, such as the number of rides, number of application sessions, miles of transportation provided, earnings received (e.g., earnings per driver device), number of requests received, number of riders, etc. Accordingly, the provider balance system 116 can actively monitor activity across the transportation matching system and determine various metrics with regard to requester devices and provider devices.
- the provider balance system 116 also performs an act 304 of generating predicted device utilization for requester computing devices and provider computing devices. For instance, the provider balance system 116 can determine forecast measures of provider computing device availability and forecast measures of requester computing device application sessions. In one or more embodiments, the provider balance system 116 generates these forecasts based on historical data from requester device(s) 102 and/or provider device(s) 106 (e.g., from the act 304 ). The provider balance system 116 can utilize various historical data, including ride data, seasonal data, and/or event data. As will be discussed in greater detail below, in one or more embodiments, the provider balance system 116 can also apply seasonal and/or event scaling to a provider device balance graph.
- the provider balance system 116 can utilize a variety of analytical techniques to determine forecast measures. For example, in some embodiments, the provider balance system 116 can analyze historical metrics (e.g., historical application sessions or historical provider device availability) utilizing regression techniques to determine typical or average provider device availability or requester device application sessions. The provider balance system 116 can also train and utilize machine learning models to generate these forecast measures, such as neural networks (e.g., a convolutional neural network), autoencoders, linear regression models, logistic regression models, vector machines, decision tress, Bayesian networks, conditional random fields, or Hidden Markov models.
- neural networks e.g., a convolutional neural network
- autoencoders e.g., linear regression models
- logistic regression models e.g., vector machines
- decision tress e.g., Bayesian networks
- Bayesian networks e.g., Markov models
- the provider balance system 116 can generate predicted device utilization for requester computing devices and provider computing devices (e.g., forecast measures of provider computing device availability and requester computing device application sessions). These measures can take a variety of specific forms. For example, the provider balance system 116 can forecast a number of times an application connects to a server, a number of requests from a transportation application, a number of application executions (e.g., a number of times an application is opened), payments received via a transportation application, or a number of completed rides arranged via a transportation application.
- provider computing devices e.g., forecast measures of provider computing device availability and requester computing device application sessions. These measures can take a variety of specific forms. For example, the provider balance system 116 can forecast a number of times an application connects to a server, a number of requests from a transportation application, a number of application executions (e.g., a number of times an application is opened), payments received via a transportation application, or a number of completed rides arranged via a transportation application.
- the provider balance system 116 can forecast a number of provider devices during a particular time, a number of provider device supply hours (e.g., a number of hours that provider devices are available), a number of miles of transportation services provided by provider devices, or an amount of earnings (e.g., dollars received per driver device).
- a number of provider device supply hours e.g., a number of hours that provider devices are available
- a number of miles of transportation services provided by provider devices e.g., dollars received per driver device.
- the provider balance system 116 can also receive forecast measures (e.g., from the transportation matching system 114 , or from another source via the network 110 ). As discussed above, the forecast measures can reflect various measurements of supply and demand for the transportation matching system 114 .
- the provider balance system 116 can perform an act 306 of generating device utilization ratios.
- the provider balance system 116 determines device utilization ratios based on a supply forecast measure with respect to requester devices (e.g., demand) and a forecast measure with respect to provider devices (e.g., supply). More specifically, the provider balance system 116 can generate the device utilization ratios based on a ratio of a device utilization for requester computing devices and device utilization for provider computing devices (e.g., a ratio of a demand forecast measure to a supply forecast measure). As shown in FIG. 3 ., the provider balance system 116 can determine the device utilization ratios based on a ratio of requester device application sessions for a given time period to driver supply hours over the time period.
- the provider balance system 116 can perform an act 308 of generating probabilities.
- the provider balance system 116 can determine a probability distribution that reflects the probability across forecast measures.
- the provider balance system 116 can determine a probability distribution reflecting probabilities of different device utilization ratios for any particular time period and/or location.
- the provider balance system 116 can utilize a probability distribution to generate the probabilities.
- the provider balance system 116 can generate a probability distribution by analyzing historical measures with regard to provider devices and requester devices. For instance, the provider balance system 116 can determine historical device utilization ratios for a particular location for a given time period (e.g., an hour, a day, or a week). The provider balance system 116 can analyze the historical device utilization ratios and determine the mean, variance, and/or standard deviation defining the probability distribution. In this manner, the provider balance system 116 can generate probability distributions for various locations (e.g., geographic regions) and times (e.g., hours, days, weeks or months).
- locations e.g., geographic regions
- times e.g., hours, days, weeks or months
- the provider balance system 116 can then utilize the probability distribution to determine probabilities. Specifically, the provider balance system 116 can determine individual probabilities of device utilization ratios, cumulative probabilities of device utilization ratios, and/or cumulative percentile bins corresponding to device utilization ratios. The provider balance system 116 can then utilize one or more of these metrics as probabilities.
- the provider balance system 116 can perform an act 310 of generating a provider device balance graph.
- the provider balance system 116 generates the provider device balance graph based on the probabilities. For example, the provider balance system 116 can plot cumulative probabilities (e.g., inverse cumulative probabilities) for a plurality of times within a time period. To illustrate, the provider balance system 116 can map a device utilization ratio for a time period to a cumulative probability bin (e.g., 90-95% probability of having a device utilization ratio at or below the determined value) and then plot a representation of the cumulative probability bin for the time period.
- cumulative probabilities e.g., inverse cumulative probabilities
- the provider balance system 116 can also generate the provider device balance graph 210 based on a variety of other measures and/or metrics. For example, as will be discussed below with regard to FIG. 6 , the provider balance system 116 can generate a provider device balance graph that reflects earnings-ridership metrics.
- the provider balance system 116 can select which metric and/or measure to visualize via the provider device balance graph. For example, the provider balance system 116 can select between provider device measures or earnings-ridership measures based at least in part on the readability (i.e., the ease with which a user can understand the meaning of a visualization) of each potential visualization. The provider balance system 116 can determine the readability of a potential visualization based on the scale of a given visualization (e.g., select the metric with the smallest range shown in the provider device balance graph to reduce spikes). Further, the provider balance system 116 can select a measure to illustrate in a provider device balance graph based on provider device preferences and/or previous provider device(s) 106 interactions with provider device balance graphs.
- the provider balance system 116 can apply thresholds to device utilization ratios to further smooth provider device balance graphs.
- the provider balance system 116 can apply a lower probability distribution device balance threshold and/or an upper probability distribution device balance threshold.
- FIG. 4 provides additional detail regarding a process for determining probabilities and applying minimum or maximum thresholds in accordance with one or more embodiments.
- the provider balance system 116 can utilize the device utilization ratios 402 and a probability distribution 404 for a representative week (or other representative time period) to determine the probabilities 406 . More specifically, the provider balance system 116 can determine a probability 406 corresponding to a particular device utilization ratio by determining the inverse cumulative probability (from the probability distribution) for the device utilization ratios 402 that device utilization ratio.
- the provider balance system 116 can determine a probability distribution based on historical or forecasted measures. For example, the provider balance system 116 can determine a probability distribution by analyzing historical device utilization ratios from a representative time period (e.g., a “normal” or “average” week or month). In some embodiments, the provider balance system 116 can determine forecast measures for a time period (e.g., a week) and generate a probability distribution based on the forecast measures (e.g., determine a mean and standard deviation of the forecast measures).
- the provider balance system 116 can utilize various approaches to determine probabilities 406 .
- the provider balance system 116 can rank and bin device utilization ratios 402 by percentile to generate probabilities 406 .
- the provider balance system 116 determines a percentile for each of the device utilization ratios 402 and assigns the device utilization ratios 402 to bins based on their percentile rank.
- the provider balance system 116 can utilize the binned values as the probabilities 406 .
- the provider balance system 116 generates probabilities 406 based on a cumulative distribution.
- the provider balance system 116 can generate an inverse cumulative probability distribution and utilize the inverse cumulative probability distribution to generate the probabilities 406 . That is, the provider balance system 116 can determine probabilities 406 by determining from the inverse cumulative probability distribution that a random value takes a value less than or equal to the corresponding device utilization ratios 402 .
- he provider balance system 116 can utilize an inverse cumulative probability distribution to map device utilization ratios to corresponding probability bins.
- the provider balance system 116 can utilize an inverse cumulative probability distribution to identify ranges of device utilization ratios that corresponding to inverse cumulative distribution ranges.
- the provider balance system 116 can then bin the device utilization ratios 402 according to each of the determined probability ranges and utilize those binned values as the probabilities 406 .
- the provider balance system 116 can also perform an act 408 of imposing minimum and/or maximum thresholds on the probabilities 406 . That is, upon generating the probabilities 406 , the provider balance system 116 can impose thresholds before generating the provider device balance graph. For example, as illustrated in FIG. 4 , the provider balance system 116 can impose a lower device balance threshold 410 and an upper device balance threshold 412 . The provider balance system 116 can map values that fall below the lower device balance threshold 410 to values at or above the lower device balance threshold 410 . Similarly, the provider balance system 116 can map values that fall above the upper device balance threshold 412 to at or below the upper device balance threshold 412 .
- the provider balance system 116 can map the largest value (e.g., the largest probabilities) to the upper device balance threshold 412 .
- the provider balance system 116 can require the largest value to the upper device balance threshold (and redistribute the remaining values) to more clearly articulate differences between measures shown on the graph
- the provider balance system 116 imposes a lower device balance threshold of 10 and an upper device balance threshold of 100 .
- the provider balance system 116 can then distribute (or normalize) probabilities between the lower device balance threshold and the upper device balance threshold. For example, the provider balance system 116 can multiply each probabilities 406 by 0.9 and add 10. However, it will be appreciated that the provider balance system 116 can adjust the probabilities within a variety of selected ranges.
- the provider balance system 116 can determine probabilities 406 based on a binning procedure and/or can bin probabilities 406 before generating the provider device balance graph.
- FIG. 5 illustrates a binning procedure for probabilities in accordance with one or more embodiments.
- the provider balance system 116 can rank the probabilities and can map each probabilities onto a bin and corresponding bin value based on its bin range. Specifically, upon ranking the probabilities, the provider balance system 116 can determine a probability distribution. For example, in relation to FIG. 5 , the provider balance system 116 determines that the top two measures (4.8, 5.1 reflecting the top 10% of values) corresponding to a first bin (e.g., labeled 100) corresponding to an inverse cumulative probability range of 91-100%. Similarly, the provider balance system 116 determines that the next two measures (3.2, 4.45) correspond to a second bin (e.g., labeled 90) corresponding to an inverse cumulative probability range of 81%-90%.
- a probability distribution For example, in relation to FIG. 5 , the provider balance system 116 determines that the top two measures (4.8, 5.1 reflecting the top 10% of values) corresponding to a first bin (e.g., labeled 100) corresponding to an inverse cumulative probability range of 91-100%.
- the provider balance system 116 can also assign measures to bins based on a bin range.
- FIG. 5 shows the bin ranges corresponds to the probability distribution device measures as ranked, in some embodiments, the bin ranges are determined separately from the ranked device utilization ratios.
- the provider balance system 116 can determine a probability distribution based on historical values and determine bin ranges based on the probability distribution. For instance, the provider balance system 116 can determine that a 91% inverse cumulative probability corresponds to a first value and use the first value to define the lower range for the first bin (labeled “100”). Similarly, the provider balance system 116 can determine that an 81% inverse cumulative probability corresponds to a second value and that a 90% inverse cumulative probability corresponds to a third value.
- the provider balance system 116 can determine a range for the second bin utilizing the second value and the third value. More specifically, the provider balance system 116 can utilize the second value as the lower range for the second bin (labeled “90”) and the third value as the upper range for the second bin.
- the provider balance system 116 can determine a number of bins and can assign a value to probabilities assigned to that bin. Further, the provider balance system 116 can determine a range of probabilities for each bin based on a probability distribution (e.g., based on an inverse cumulative distribution as discussed above). Then, the provider balance system 116 can utilize the bin values to visualize the probabilities 406 in the provider device balance graph. Accordingly, in relation to FIG. 5 , the provider balance system 116 maps the device utilization ratio 5.1 to a probability of 100 . Similarly, the provider balance system 116 maps the device utilization ratio 0.8 to a probability of 20.
- the provider balance system 116 can generate and utilize earnings-ridership metrics to utilize in an earnings-ridership graph within a provider incentive graphical user interface.
- FIG. 6 illustrates generating and utilizing an earnings-ridership metric.
- the provider balance system 116 performs an act 602 of determining projected earning metrics and projected number of rides. Similar to the discussion above with regard to forecast measures, the provider balance system 116 can generate the projected earning metrics and projected number of rides based on data monitored from the requester device(s) 102 and the provider device(s) 106 . The provider balance system 116 can also receive the projected earning metrics and projected number of rides from the transportation matching system 114 and/or from another source via the network 110 .
- the provider balance system 116 can perform an act 604 of generating an earnings-ridership metric.
- the provider balance system 116 can generate the earnings-ridership metric based on the projected earning metrics and the projected number of rides for a specified time period. More specifically, in one or more embodiments, the provider balance system 116 generates the earnings-ridership metric by multiplying the projected earning metrics for a given time period and a radical of the projected number of rides for the given time period.
- the provider balance system 116 can utilize a projected earnings metric per ride and/or per time interval. For example, the provider balance system 116 can utilize the square root or the cube root of the number of projected rides to determine the earnings-ridership metric.
- the provider balance system 116 can perform an act 606 of generating a driver device incentive graph that reflects the earnings-ridership metrics.
- the provider balance system 116 can generate a driver device incentive graph with a visual representation for individual earning-ridership metrics for individual times within a target time period.
- the provider balance system 116 can apply thresholds to the earning-ridership metrics and/or determine probability distribution earning-ridership metrics.
- the earnings-ridership graph can accurately communicate relative benefit of driving at various times by utilizing both earnings and ride frequency rather than raw demand.
- the provider balance system 116 can present a scheduling graphical user interface including a provider device balance graph to communicate to provider device(s).
- FIG. 7 shows an example embodiment of a scheduling graphical user interface presented in accordance with one or more embodiments.
- the scheduling graphical user interface 700 can include a provider device balance graph 702 .
- the provider device balance graph 702 that includes scheduling indicators 703 .
- the scheduling indicators 703 identify suggested time periods for providing transportation services.
- the provider balance system 116 can generate the scheduling indicators 703 based on a particular goal for the provider device. For instance, the provider balance system 116 can suggest a schedule to satisfy a monetary goal or other goals (e.g., a goal for a number of rides or a goal for an amount of time spent driving). For example, as shown in FIG. 7 , the scheduling indicators 703 bracket two time periods at which the driver can drive during the visualized day in order to meet a weekly goal. However, the provider balance system 116 can present the scheduling indicators 703 in accordance with a variety of designs that communicate selected time periods.
- a monetary goal or other goals e.g., a goal for a number of rides or a goal for an amount of time spent driving.
- the scheduling indicators 703 bracket two time periods at which the driver can drive during the visualized day in order to meet a weekly goal.
- the provider balance system 116 can present the scheduling indicators 703 in accordance with a variety of designs that communicate selected time periods.
- the scheduling indicators 703 can be highlighted portions of the provider device balance graph, portions of the provider device balance graph with an alternate color, a circled or boxed portion of the provider device balance graph, or any other indication of a selected portion.
- the provider balance system 116 can suggest a transportation schedule utilizing a variety of different interface elements (e.g., by providing a calendar with drive times highlighted).
- the provider balance system 116 can generate suggested schedules based on a variety of factors. In some embodiments, the provider balance system 116 generates suggestions based on the highest device utilization ratios (or highest probabilities). In some embodiments, the provider balance system 116 suggests transportation times with the highest device utilization ratios until satisfying a particular goal. For instance, in relation to FIG. 7 , the provider balance system 116 generates suggested transportation times until projected earnings during the suggested times exceed $800.
- the provider balance system 116 can generate a suggested schedule based on preferred or historical transportation times of the provider device (e.g., emphasize night times for a provider device that is typically available at nights). Similarly, the provider balance system 116 can generate a schedule based on a minimum consecutive drive time (e.g., group drive times into a minimum of two hour drive times).
- the provider balance system 116 can utilize heuristic approaches to generate suggested schedules.
- the provider balance system 116 can utilize a machine learning model to generate suggested schedules.
- the provider balance system 116 can utilize a neural network (e.g., a recurrent neural network) to analyze input parameters (e.g., goals, historical drive times, etc.), and generate suggested drive times.
- a neural network e.g., a recurrent neural network
- the provider balance system 116 can also generate suggestions for particular locations. For instance, the provider balance system 116 can analyze device utilization ratios for a plurality of locations and suggest a location based on the device utilization ratios (e.g., suggest the locations and times with the highest device utilization ratios).
- the scheduling graphical user interface 700 can include a scheduling explanation 704 .
- the scheduling explanation 704 can display the goal corresponding to the provider device 106 and the duration of the goal. For example, as shown in FIG. 7 , the scheduling explanation 704 indicates that the goal is a “Weekly Goal” and recites “Drive at these time to earn your goal of $800.” As also shown in FIG. 7 , the scheduling explanation 704 can include the goal input area 706 .
- the goal input area 706 can receive provider input indicating the provider’s target earnings.
- the provider balance system 116 can generate and/or update the placement of the scheduling indicators 703 to reflect the provided goal.
- FIG. 7 shows a weekly goal and a day view of a provider device balance graph
- the scheduling graphical user interface 700 can present provider device balance graphs and scheduling indicators 703 corresponding to a variety of goals and goal durations.
- the scheduling graphical user interface 700 can include daily, monthly, or yearly goals.
- the scheduling graphical user interface 700 can include provider device balance graphs visualizing relative supply and demand over various time periods, including a week or month.
- the provider balance system 116 can apply event modifiers and/or seasonal scaling .
- FIG. 8 illustrates applying these adjustments to an example provider device balance graph.
- the provider balance system 116 can start with a generated provider device balance graph 802 .
- the provider balance system 116 can perform an act 804 of generating and applying an event modifier.
- the provider balance system 116 can generate the event modifier based on historical data and/or data received from the transportation matching system 114 and/or via the network 110 . That is, the provider balance system 116 can utilize both historical data from a variety of sources and data regarding an upcoming event received from an administrator or from another source. Then, based on the event data, including based on data from similar events, the provider balance system 116 can generate an event modifier for a provider device balance graph 802 . Then, the provider balance system 116 can apply the event modifier to the relevant portions (i.e. times) on the provider device balance graph 802 .
- the provider balance system 116 can analyze historical data and determine that a professional basketball game increases device utilization ratios by a factor of 1.4 (on average).
- the provider balance system 116 can analyze a repository of upcoming events and identify that a professional basketball is scheduled.
- the provider balance system 116 can the apply the event modifier (e.g., 1.4) to the device utilization ratios.
- the provider balance system 116 can apply scaling metrics to a variety of time periods. For example, the provider balance system 116 can perform scaling on a per day or per week basis. Thus, for instance, the provider balance system 116 can apply a Christmas Day event scaling metric to an entire day or a basketball event scaling metric to a particular hour.
- the provider balance system 116 can perform an act 806 of applying a seasonal adjustment based on historical data.
- the provider balance system 116 can determine historical data via requester device(s) 102 and provider device(s) 106 , via the transportation matching system 114 , and/or from other sources via the network 110 .
- the provider balance system 116 can determine a seasonal adjustment for a provider device balance graph 802 based on the time of year applicable to the graph. For example, the provider balance system 116 can determine that a geographical area around a university experiences increased requests on weekdays in the afternoon during the school year, but not during summer break. That is, the provider balance system 116 can determine that during the season applicable to a provider device balance graph 802 , the transportation matching system 114 experiences increased demand during a particular time of day and can scale the provider device balance graph 802 accordingly.
- the provider balance system 116 can also apply other scaling metrics.
- the provider balance system 116 can apply geographic scaling metrics.
- the provider balance system 116 can apply a particular scaling metric (e.g., a 2.0 multiplier) to a first geographic location relative to a second geographic location.
- FIGS. 1 - 8 the corresponding text, and the examples provide a number of different methods, systems, devices, and non-transitory computer-readable media of the provider balance system 116 .
- FIG. 9 may be performed with more or fewer acts. Further, the acts may be performed in differing orders. Additionally, the acts described herein may be repeated or performed in parallel with one another or parallel with different instances of the same or similar acts.
- FIG. 9 illustrates a flowchart of a series of acts 900 for the provider balance system 116 in accordance with one or more embodiments. While FIG. 9 illustrates acts according to one embodiment, alternative embodiments may omit, add to, reorder, and/or modify any of the acts shown in FIG. 9 .
- the acts of FIG. 9 can be performed as part of a method.
- a non-transitory computer-readable medium can comprise instructions that, when executed by one or more processors, cause a computing device to perform the acts of FIG. 9 .
- a system can perform the acts of FIG. 9 .
- the series of acts 900 includes an act 902 for determining a forecast measure for requester computing devices within a time period.
- the act 902 can include determining a forecast measure of requester computing device application sessions for a plurality of requester computing devices of a transportation matching system for a plurality of times within a time period.
- the series of acts 900 includes an act 904 for determining a forecast measure of provider computing device availability for a plurality of provider computing devices within the time period.
- the act 904 can include determining a forecast measure of provider computing device availability for a plurality of provider computing devices of the transportation matching system for the plurality of times within the time period.
- the series of acts 900 includes an act 906 for based on the forecast measure of requester computing device application sessions and the forecast measure of provider computing device availability, generating device utilization ratios.
- the act 906 can include, based on the forecast measure of requester computing device application sessions and the forecast measure of provider computing device availability, generating device utilization ratios for the plurality of times within the time period.
- the act 906 can include generating projected provider device earnings-ridership metrics for the plurality of times based on projected provider device earnings metrics for the plurality of times and a radical of a projected number of rides for the plurality of times.
- the series of acts 900 also includes an act 908 for generating probabilities from the device utilization ratios based on cumulative probabilities of the market balance measures.
- the act 908 can include generating probabilities from the device utilization ratios based on cumulative probabilities of the market balance measures.
- the act 908 can include determining ratios of the forecast measures of provider computing device application sessions to the forecast measure of provider computing device availability measures.
- the act 908 can include organizing the device utilization ratios for the plurality of times into a plurality of bins based on the cumulative probabilities, wherein the plurality of bins reflect cumulative probability ranges.
- the act 908 can include determining a lower probability distribution device balance threshold and generating the probabilities by mapping the device utilization ratios above the lower probability distribution device balance threshold.
- the act 908 can also include identifying a standardized probability distribution device balance distribution based on historical provider computing device availability and historical requester computing device application sessions for a test time period and determining the cumulative probabilities of the market balance measures based on the standardized probability distribution device balance distribution.
- the series of acts 900 further includes an act 910 for providing a provider device balance graph portraying the probability distribution device balance metrics with respect to the time period.
- the act 910 can include providing, for display via a provider computing device, a provider device balance graph portraying the probability distribution device balance metrics with respect to the plurality of times.
- the act 910 can include displaying visual representations of the plurality of bins with respect to the plurality of time.
- the act 908 can include generating one or more provider device balance graphs portraying the provider device earnings-ridership metrics with respect to the plurality of times.
- the act 908 can include identifying an event corresponding to a time range within the time period, determining an event modifier corresponding to the event, identifying a set of probabilities corresponding to the time range from the probabilities, and adjusting the set of probabilities corresponding to the time range utilizing the event modifier.
- Embodiments of the present disclosure may comprise or utilize a special purpose or general-purpose computer including computer hardware, such as, for example, one or more processors and system memory, as discussed in greater detail below.
- Embodiments within the scope of the present disclosure also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures.
- one or more of the processes described herein may be implemented at least in part as instructions embodied in a non-transitory computer-readable medium and executable by one or more computing devices (e.g., any of the media content access devices described herein).
- a processor receives instructions, from a non-transitory computer-readable medium, (e.g., memory), and executes those instructions, thereby performing one or more processes, including one or more of the processes described herein.
- a non-transitory computer-readable medium e.g., memory
- Computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system.
- Computer-readable media that store computer-executable instructions are non-transitory computer-readable storage media (devices).
- Computer-readable media that carry computer-executable instructions are transmission media.
- embodiments of the disclosure can comprise at least two distinctly different kinds of computer-readable media: non-transitory computer-readable storage media (devices) and transmission media.
- Non-transitory computer-readable storage media includes RAM, ROM, EEPROM, CD-ROM, solid state drives (“SSDs”) (e.g., based on RAM), Flash memory, phase-change memory (“PCM”), other types of memory, other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.
- SSDs solid state drives
- PCM phase-change memory
- a “network” is defined as one or more data links that enable the transport of electronic data between computer systems and/or modules and/or other electronic devices.
- a network or another communications connection can include a network and/or data links which can be used to carry desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer-readable media.
- program code means in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to non-transitory computer-readable storage media (devices) (or vice versa).
- computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a “NIC”), and then eventually transferred to computer system RAM and/or to less volatile computer storage media (devices) at a computer system.
- a network interface module e.g., a “NIC”
- non-transitory computer-readable storage media (devices) can be included in computer system components that also (or even primarily) utilize transmission media.
- Computer-executable instructions comprise, for example, instructions and data which, when executed by a processor, cause a general-purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions.
- computer-executable instructions are executed by a general-purpose computer to turn the general-purpose computer into a special purpose computer implementing elements of the disclosure.
- the computer-executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code.
- the disclosure may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, pagers, routers, switches, and the like.
- the disclosure may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks.
- program modules may be located in both local and remote memory storage devices.
- Embodiments of the present disclosure can also be implemented in cloud computing environments.
- the term “cloud computing” refers to a model for enabling on-demand network access to a shared pool of configurable computing resources.
- cloud computing can be employed in the marketplace to offer ubiquitous and convenient on-demand access to the shared pool of configurable computing resources.
- the shared pool of configurable computing resources can be rapidly provisioned via virtualization and released with low management effort or service provider interaction, and then scaled accordingly.
- a cloud-computing model can be composed of various characteristics such as, for example, on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service, and so forth.
- a cloud-computing model can also expose various service models, such as, for example, Software as a Service (“SaaS”), Platform as a Service (“PaaS”), and Infrastructure as a Service (“IaaS”).
- SaaS Software as a Service
- PaaS Platform as a Service
- IaaS Infrastructure as a Service
- a cloud-computing model can also be deployed using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, and so forth.
- the term “cloud-computing environment” refers to an environment in which cloud computing is employed.
- FIG. 10 illustrates a block diagram of an example computing device 1000 that may be configured to perform one or more of the processes described above.
- the computing device 1000 may represent the computing devices described above (e.g., computing requester device(s) 102 , provider device(s) 106 , and/or server device(s) 112 ).
- the computing device 1000 may be a mobile device (e.g., a mobile telephone, a smartphone, a PDA, a tablet, a laptop, a camera, a tracker, a watch, a wearable device, etc.).
- the computing device 1000 may be a non-mobile device (e.g., a desktop computer or another type of client device).
- the computing device 1000 may be a server device that includes cloud-based processing and storage capabilities.
- the computing device 1000 can include one or more processor(s) 1002 , memory 1004 , a storage device 1006 , input/output interfaces 1008 (or “I/O interfaces 1008”), and a communication interface 1010 , which may be communicatively coupled by way of a communication infrastructure (e.g., bus 1012 ). While the computing device 1000 is shown in FIG. 10 , the components illustrated in FIG. 10 are not intended to be limiting. Additional or alternative components may be used in other embodiments. Furthermore, in certain embodiments, the computing device 1000 includes fewer components than those shown in FIG. 10 . Components of the computing device 1000 shown in FIG. 10 will now be described in additional detail.
- the processor(s) 1002 includes hardware for executing instructions, such as those making up a computer program.
- the processor(s) 1002 may retrieve (or fetch) the instructions from an internal register, an internal cache, memory 1004 , or a storage device 1006 and decode and execute them.
- the computing device 1000 includes memory 1004 , which is coupled to the processor(s) 1002 .
- the memory 1004 may be used for storing data, metadata, and programs for execution by the processor(s).
- the memory 1004 may include one or more of volatile and nonvolatile 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.
- RAM Random-Access Memory
- ROM Read-Only Memory
- SSD solid-state disk
- PCM Phase Change Memory
- the memory 1004 may be internal or distributed memory.
- the computing device 1000 includes a storage device 1006 includes storage for storing data or instructions.
- the storage device 1006 can include a non-transitory storage medium described above.
- the storage device 1006 may include a hard disk drive (HDD), flash memory, a Universal Serial Bus (USB) drive or a combination these or other storage devices.
- HDD hard disk drive
- USB Universal Serial Bus
- the computing device 1000 includes one or more I/O interfaces 1008 , 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 1000 .
- I/O interfaces 1008 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 1008 .
- the touch screen may be activated with a stylus or a finger.
- the I/O interfaces 1008 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.
- I/O interfaces 1008 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 1000 can further include a communication interface 1010 .
- the communication interface 1010 can include hardware, software, or both.
- the communication interface 1010 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.
- communication interface 1010 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.
- NIC network interface controller
- WNIC wireless NIC
- the computing device 1000 can further include a bus 1012 .
- the bus 1012 can include hardware, software, or both that connects components of computing device 1000 to each other.
- FIG. 11 illustrates an example network environment 1100 of a transportation matching system (e.g., the transportation matching system 114 ).
- the network environment 1100 includes a client device 1106 , a transportation matching system 114 , and a vehicle subsystem 1108 connected to each other by a network 1104 .
- FIG. 11 illustrates a particular arrangement of the client device 1106 , the transportation matching system 114 , the vehicle subsystem 1108 , and the network 1104
- this disclosure contemplates any suitable arrangement of the client device 1106 , the transportation matching system 114 , the vehicle subsystem 1108 , and the network 1104 .
- two or more of the client device 1106 , the transportation matching system 114 , and the vehicle subsystem 1108 communicate directly, bypassing the network 1104 .
- two or more of the client device 1106 , the transportation matching system 114 , and the vehicle subsystem 1108 may be physically or logically co-located with each other in whole or in part.
- FIG. 11 illustrates a particular number of the client devices 1106 , the transportation matching systems 114 , the vehicle subsystems 1108 , and the networks 1104
- this disclosure contemplates any suitable number of the client devices 1106 , the transportation matching systems 114 , the vehicle subsystems 1108 , and the networks 1104 .
- the network environment 1100 may include multiple client devices 1106 , the transportation matching systems 114 , the vehicle subsystems 1108 , and the networks 1104 .
- the network 1104 may include any suitable network 1104 .
- one or more portions of the network 1104 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 1104 may include one or more networks 1104 .
- Links may connect the client device 1106 , the transportation matching system 114 , and the vehicle subsystem 1108 to the communication network 1104 or to each other.
- This disclosure contemplates any suitable links.
- 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.
- 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)
- optical such as for example Synchronous Optical Network (SONET) or Synchronous Digital Hierarchy (SDH) links.
- SONET Synchronous Optical Network
- SDH Synchronous Digital Hierarchy
- 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 1100 .
- One or more first links may differ in one or more respects from one or more second links.
- the client device 1106 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 1106 .
- a client device 1106 may include any of the computing devices discussed above in relation to FIG. 7 .
- a client device 1106 may enable a network user at the client device 1106 to access a network.
- a client device 1106 may enable its user to communicate with other users at other client systems 1106 .
- the client device 1106 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 1106 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 1106 one or more Hyper Text Markup Language (HTML) files responsive to the HTTP request.
- HTTP Hyper Text Transfer Protocol
- the client device 1106 may render a webpage based on the HTML files from the server for presentation to the user.
- This disclosure contemplates any suitable webpage files.
- 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 SIL VERLIGHT, combinations of markup language and scripts such as AJAX (Asynchronous JAVASCRIPT and XML), and the like.
- AJAX Asynchronous JAVASCRIPT and XML
- the transportation matching system 114 may be a network-addressable computing system that can host a ride share transportation network.
- the transportation matching system 114 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 114 .
- the transportation service system may manage identities of service requestors such as users/requesters.
- 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).
- the transportation matching system 114 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 114 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 114 may be accessed by the other components of the network environment 1100 either directly or via network 1104 .
- the transportation matching system 114 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.
- 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.
- the transportation matching system 114 may include one or more data stores.
- Data stores may be used to store various types of information.
- the information stored in data stores may be organized according to specific data structures.
- each data store may be a relational, columnar, correlation, or other suitable database.
- 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 1106 , or a transportation matching system 114 to manage, retrieve, modify, add, or delete, the information stored in data store.
- the transportation matching system 114 may provide users with the ability to take actions on various types of items or objects, supported by the transportation matching system 114 .
- the items and objects may include ride share networks to which users of the transportation matching system 114 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 114 or by an external system of a third-party system, which is separate from the transportation matching system 114 and coupled to the transportation matching system 114 via a network 1104 .
- the transportation matching system 114 may be capable of linking a variety of entities.
- the transportation matching system 114 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.
- API application programming interfaces
- the transportation matching system 114 may include a variety of servers, sub-systems, programs, modules, logs, and data stores.
- the transportation matching system 114 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 114 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.
- the transportation matching system 114 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 114 and one or more client systems 1106 .
- 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 114 .
- 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 1106 .
- Information may be pushed to a client device 1106 as notifications, or information may be pulled from the client device 1106 responsive to a request received from the client device 1106 .
- Authorization servers may be used to enforce one or more privacy settings of the users of the transportation matching system 114 .
- 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 114 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 systems 1106 associated with users.
- the vehicle subsystem 1108 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.
- the vehicle subsystem 1108 can include an autonomous vehicle—i.e., a vehicle that does not require a human operator.
- the vehicle subsystem 1108 can perform maneuvers, communicate, and otherwise function without the aid of a human provider, in accordance with available technology.
- the vehicle subsystem 1108 may include one or more sensors incorporated therein or associated thereto.
- sensor(s) can be mounted on the top of the vehicle subsystem 1108 or else can be located within the interior of the vehicle subsystem 1108 .
- the sensor(s) can be located in multiple areas at once— i.e., split up throughout the vehicle subsystem 1108 so that different components of the sensor(s) can be placed in different locations in accordance with optimal operation of the sensor(s).
- 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.
- IMU inertial measurement unit
- 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.
- WIMU wireless IMU
- 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.
- the vehicle subsystem 1108 may include a communication device capable of communicating with the client device 1106 and/or the transportation matching system 114 .
- the vehicle subsystem 1108 can include an on-board computing device communicatively linked to the network 1104 to transmit and receive data such as GPS location information, sensor-related information, requester location information, or other relevant information.
Abstract
The present disclosure relates to systems, non-transitory computer-readable media, and methods for generating and utilizing provider device balance graphs reflecting device utilization ratio between provider devices and requester devices. In particular, in one or more embodiments, the disclosed systems determine and utilize probabilities to generate and provide provider device balance graphs based on probability distributions for device utilization ratios. The disclosed systems can apply various scaling models to address seasonality, special events, and/or differences between regions. The disclosed systems can also apply thresholds to generate device incentive graphs that more efficiently deploy provider devices across a transportation matching system.
Description
- This application is a continuation of U.S. Application No. 16/543,368, filed on Aug. 16, 2019, the contents of which are herein incorporated by reference in their entirety.
- In recent years, the popularity and usage of on-demand transportation matching systems have steadily increased. Indeed, the proliferation of web and mobile applications enable requesting devices to submit transportation requests via on-demand transportation matching systems and identify available provider devices that can provide transportation services from one geographic location to another. In many circumstances, conventional transportation matching systems also provide digital communications regarding fluctuations in requesting device demand to allow provider devices to select times for providing transportation services. For example, conventional transportation matching systems can provide a graph reflecting requester device demand over time in an effort to forecast times for provider devices to provide transportation services. However, conventional transportation matching systems suffer from a number of disadvantages with respect to accuracy and efficiency of implementing computing systems.
- For instance, although many conventional transportation systems generate and transmit fluctuations in demand to provider devices, conventional systems often provide these digital communications in a manner that is misleading to provider devices. For example, communicating linear demand can provide inaccurate, misleading, and unhelpful information when there is a large spike in demand within a communicated time period. In such circumstances, for instance, demand for other time periods becomes distorted, which leads driver devices to over-commit during some time periods (e.g., during a time period corresponding to a large spike) and under-commit at other time periods. For example, when there is a large event or a holiday weekend rush hour, conventional systems do not provide an accurate indication to provider devices as to when to provide transportation services within a particular target time period.
- In addition, this inaccurate communication of provider device incentives can also lead to inefficiencies in conventional transportation matching systems. Indeed, because digital communications fail to accurately convey transportation opportunities, conventional transportation matching systems often experience requester device imbalances (e.g., excessive levels of demand from requesting devices relative to transportation devices) or provider device imbalances (e.g., excessive levels of transportation devices relative to demand from requesting devices). These imbalances often lead to high wait times (for requesting devices and/or provider devices) and excessive burdens on computing resources (e.g., inefficiencies at the server in responding to requesting devices and provider devices due to unbalanced availability relative to demand). For example, conventional systems often face excessive computational overhead due to an imbalance in requester devices or provider devices as these devices repeatedly query servers for transportation matches, transportation updates, or other information due to lag resulting from uneven distribution across the transportation matching system. In addition, this can negatively affect both user experience and provider experience, yielding retention problems for conventional systems.
- These along with additional problems and issues exist with regard to conventional transportation matching systems.
- Embodiments of the present disclosure provide benefits and/or solve one or more of the foregoing or other problems in the art with systems, non-transitory computer-readable media, and methods for generating provider device balance graphs reflecting device utilization ratios between provider devices and requester devices. For example, the disclosed systems can determine market balance measures over a target time period based on driver supply hours and requester device application sessions within the target time period. Further, the disclosed systems can utilize the market balance measures to generate and display provider device balance graphs to provider devices. Moreover, the disclosed system can apply various scaling models to create an intuitive visual scale to address seasonality, special events, and/or differences between regions. The disclosed systems can also apply thresholds to generate smooth visual scales that allow driver devices to more accurately determine driving schedules. In this manner, the disclosed systems can avoid distortions that result from large fluctuations in requestor device demand and provide a more accurate reflection of provider device incentives across a transportation matching system.
- For example, in one or more embodiments, the disclosed systems determine device utilization ratios for a period of time based on projections for device utilization for requester computing devices and device utilization for provider computer devices across time periods. Then, the disclosed systems can utilize a probability distribution for a representative time period to determine probabilities for the device utilization ratios. In one or more embodiments, the disclosed systems map device utilization rations and/or probabilities to “bins” and utilize those bins to generate a provider device balance graph. By utilizing device utilization ratios between utilization of provider devices and requester devices, the disclosed systems can display provider device balance graphs that more accurately reflect transportation times for provider devices, that allow for more efficient scheduling of provider devices, and that lead to more efficient operation of implementing computer 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.
- The detailed description provides one or more embodiments with additional specificity and detail through the use of the accompanying drawings, as briefly described below.
-
FIG. 1 illustrates a diagram of an environment in which a provider balance system can operate in accordance with one or more embodiments. -
FIGS. 2A-2C illustrate example graphical user interfaces for a provider balance system in accordance with one or more embodiments. -
FIG. 3 illustrates an overview of generating a provider device balance graph in accordance with one or more embodiments. -
FIG. 4 illustrates utilizing a probability distribution to generate probabilities in accordance with one or more embodiments. -
FIG. 5 illustrates binning probabilities according to determined bin ranges in accordance with one or more embodiments. -
FIG. 6 illustrates generating and utilizing an earnings-ridership metric for a provider balance system in accordance with one or more embodiments. -
FIG. 7 illustrates a provider scheduling graphical user interface in accordance with one or more embodiments. -
FIG. 8 illustrates applying event and seasonal adjustments to provider incentive graphs in accordance with one or more embodiments. -
FIG. 9 illustrates a flowchart of a series of acts for a provider balance system in accordance with one or more embodiments. -
FIG. 10 illustrates a block diagram of an example computing device for implementing one or more embodiments of the present disclosure. -
FIG. 11 illustrates a block diagram of an example transportation matching system in accordance with one or more embodiments. - This disclosure describes one or more embodiments of a provider balance system that generates provider device balance graphs reflecting device utilization ratios between provider devices and requester devices. More specifically, the provider balance system can determine device utilization ratios for various time periods based on projections for utilization of provider devices and requester devices. The provider balance system can utilize the device utilization ratios to generate a provider device balance graph. By utilizing a provider device balance graph that reflects such market balance metrics, the provider balance system can more accurately represent provider device utilization rate and earnings relative to conventional systems. Indeed, the provider balance system can avoid distortions in driver device incentives and reduce inefficiencies across transportation matching systems that result from pure demand metrics.
- To illustrate, the provider balance system can determine predicted requester computing device application sessions and predicted computing device availability within a given region and within a given time period. Then, the provider balance system can determine device utilization ratios for the given time period based on the forecast measures. Further, the provider balance system can determine probabilities of the device utilization ratios. The provider balance system can then generate and provide a provider device balance graph portraying the probabilities for efficient communication of provider incentives and deployment of provider devices.
- As mentioned, the provider balance system can generate and utilize various predicted device utilization measures for provider devices and requestor devices. In one or more embodiments, the provider balance system utilizes a number driver supply hours to forecast driver device utilization and utilizes a number of requester device application sessions to forecast requester device utilization. However, the provider balance system can utilize a variety of particular metrics to predicted device utilization. For example, the provider balance system can forecast a number of requests, a number of hours required to fulfil requests, or a cumulative distance needed to be driven to fulfil requests. Further, the provider balance system can forecast a number of providers, a number of provider miles, or a number of transportation services (e.g., rides).
- As discussed above, the provider balance system can utilize forecast metrics to generate device utilization ratios. More specifically, in one or more embodiments, the provider balance system can generate the device utilization ratios as a ratio of requester device application sessions and provider device availability. For example, the provider balance system can generate the device utilization ratios by determining the ratio of the number of application sessions over a time period to a number of driver supply hours for the same time period.
- In addition, as mentioned, the provider balance system can also determine probabilities. In particular, the provider balance system can determine probabilities by applying a probability distribution to forecasted device utilization ratios. For example, the provider balance system can determine a probability distribution that reflects probabilities of device utilization ratios for a representative time period (e.g., an average week). The provider balance system can then utilize the probability distribution to determine probabilities. To illustrate, the provider balance system can utilize a probability distribution to determine percentile bins that reflect ranges of cumulative probabilities and corresponding ranges of device utilization ratios. The provider balance system can then map forecast device utilization ratios to the appropriate percentile bins to generate probabilities.
- In some embodiments, the provider balance system can also generate device utilization ratios by applying device balance thresholds. Indeed, the provider balance system can further avoid distortion by applying upper and/or lower thresholds of device utilization ratios. For example, in some embodiments, the provider balance system can constrain the minimum device utilization ratio (or probability) to a lower threshold (e.g., a 10 percent lower bound). Similarly, the provider balance system can map the maximum device utilization ratio (or probability) to an upper threshold (e.g., a 100 percent upper bound).
- As mentioned above, the provider balance system can also apply various scales to device utilization ratios. For instance, in some embodiments, the provider balance system can apply a seasonal scaling to reflect variations in device utilization ratios across seasons. In addition, the provider balance system can apply an event scaling (e.g., multiplicatively) to reflect variations in device utilization ratios specific to particular events.
- The provider balance system can also generate and utilize provider device ridership metrics. For example, in some embodiments, the provider balance system generates provider device ridership metrics that reflect projected earnings corresponding to provider devices in light of ridership corresponding to requestor devices. Specifically, the provider balance system can generate ridership metrics based on a projected earnings metric and the radical of a projected number of rides. The provider balance system can utilize these earnings-ridership metrics to generate one or more provider device balance graphs.
- As just mentioned, the provider balance system can generate provider device balance graphs and can provide these provider device balance graphs for display in graphical user interfaces via provider devices. For example, the provider balance system can generate a timeline of probabilities and provide the timeline for display to provider devices to more efficiently distribute provider devices across different times (e.g., hours) within a target time period (e.g., a day). The provider balance system can also generate and provide recommend transportation schedules for provider devices based on device utilization ratios.
- The provider balance system provides many advantages and benefits over conventional systems and methods. For example, by utilizing device balance metrics and/or probability distributions the provider balance system can improve accuracy relative to conventional systems. Specifically, the provider balance system can generate and display provider device balance graphs that accurately communicate provider device incentives without undue distortion caused by spikes or other fluctuations in requester device demand. The provider balance system can utilize probability distributions to determine provider device balance graphs that are smoother and easier to understand and that more accurately convey transportation times to provider devices.
- Additionally, the provider balance system improves efficiency for the implementing transportation matching system. Indeed, the provider balance system more accurately conveys incentives across provider device transportation times and therefore reduces imbalances across provider devices and requester devices. The provider balance system can thus reduce spike imbalances between provider devices and requester devices and reduce the burdens on implementing computing systems in seeking to matching provider devices and requester devices under such circumstances. For example, the provider incentive system can reduce the number of repeat requests for providers and/or requesters, queries for updates, and/or queries for transportation provider status reports that result from device imbalances. The provider balance system also provides better projections and yields better requester and provider experience by ensuring that provider devices align to demands from requester devices.
- As illustrated by the foregoing discussion, the present disclosure utilizes a variety of terms to describe features and advantages of the provider balance system. Additional detail is now provided regarding the meaning of such terms. For example, as used herein, the term “transportation request” (or “request”) refers to a query, demand, or invitation for transportation services. To illustrate, a requester can interact with one or more user interfaces of a requester application on a requester device to configure a transportation request (e.g., to indicate a requested pickup location, a requested drop-off location, a requested type of transportation, and/or a requested time of transportation), and then submit the transportation request to the transportation matching system. As used herein, the terms “requester” refers to an individual that has submitted (or will submit) a transportation request. Similarly, a “requester device” (or “requester computing device”) refer to a computing device that submits (or has submitted) a request (e.g., a computing device associated with a requestor).
- Further, as used herein, the term “provider” refers to an individual, entity, or vehicle that provides transportation services. Moreover, the term “provider device” (or “provider computing device”) refer to a computing device associated with a provider (e.g., a computing device associated with a driver or automated vehicle). Additional detail regarding provider devices and requester devices is provided below (e.g., in relation to
FIG. 1 ). - In addition, as used herein, the term “predicted device utilization” refers to a forecast metric or measurement reflecting an extent that one or more devices will be used. To illustrate, a predicted device utilization can include a metric that conveys a predicted supply, and/or demand of requester devices and/or provider devices. As mentioned, the provider balance system can generate a predicted device utilization for requester computing devices as a forecast measure of requester computing device application sessions.
- In addition, as used herein, a predicted device utilization for provider computing device can include a predicted metric of a supply of transportation services or provider device availability. In particular, predicted device utilization for provider computing devices can include a number of hours utilized to provide transportation services during a specified time (e.g., a predicted number of driver hours available to provide transportation services during a specified time).
- Further, as used herein, the term “device utilization ratios” refers to a metric reflecting both predicted device utilization for provider computing devices and requester computing devices. In particular, a device utilization ratio can include a ratio of the number of application sessions over a time period to a number of driver supply hours for the same time period.
- Also, as used herein, the term “probabilities” refers to a likelihood of a particular result (e.g., a probability of a utilization ration determined based on a probability distribution). In particular, the provider balance system can determine a probability distribution (e.g., a correlation between probabilities and values of a variable) of device utilization ratios. The provider balance system can then map device utilization ratios to probabilities utilizing the probability distribution. For example, a device utilization ratio of 0.5 may map to a probability of 15 (e.g., a 15% inverse cumulative probability of achieving a 0.5 device utilization ratio or lower during the time period).
- In addition, as used herein, the term “provider device balance graph” refers to a visual representation of relative supply and/or demand. In particular, the term “provider device balance graph” can include a graphical representation of device utilization ratios, probabilities, and/or provider device earnings-ridership metrics. To illustrate, a provider balance system can include provider device balance graph in a graphical user interface within a provider application.
- Additionally, as used herein, the term “bins” refers to a grouping or range of data. In particular, the term “bins” can include a range of device utilization ratios corresponding to a range of probabilities. For example, the
provider balance system 116 can identify an 80%-90% probability bin defined by a range of device utilization ratios corresponding to an 80% inverse cumulative probability and a 90% inverse cumulative probability. - Further, as used herein, the term “provider device ridership metric” (or “earnings-ridership metric”) refers to a metric based on earnings for a provider and ridership. In particular, the term “provider device ridership metric” can include metric based on a projected earnings metric and the radical of a projected number of rides. Additionally, as used herein, the term “radical” refers to the root of a number or quantity. In particular, the term “radical” can include a square root, a cube root, or a root with another radicand.
- Further, as used herein, the term “event modifier” refers to a metric corresponding to an event. In particular, the term “event modifier” can include a value corresponding to a scale at which an event will escalate demand in a given time and/or location. To illustrate, an event modifier can include a variety of metrics and/or measures corresponding to increased demand expected and/or experienced as a result of an event such as a concert, sporting event, performance, etc. Similarly, a “seasonal modifier” can include a metric corresponding to a particular season (e.g., increased demand expected due to a particular month, week, or other time of year).
- Additional detail will now be provided regarding the provider balance system in relation to illustrative figures portraying exemplary embodiments. In particular,
FIG. 1 illustrates anenvironment 100 including requester device(s) 102, each implementing arequester application 104, and provider device(s) 106, implementing aprovider application 108. The requester device(s) 102 communicate, via anetwork 110, with server device(s) 112. The server device(s) 112 can implement atransportation matching system 114, which in turn can include aprovider balance system 116. - Although
FIG. 1 illustrates theprovider balance system 116 implemented via the server device(s) 112, theprovider balance system 116 can be implemented via other components. For example, theprovider balance system 116 can be implemented in whole, or in part, by the requester device(s) 102 and/or the provider device(s) 106. - The requester device(s) 102 can include various types of computing devices. For example, the requester device(s) 102 can include smart phones, tablets, smart watches, laptop computers, or other mobile computing devices, such as further explained below with reference to
FIG. 10 . Additionally, therequester application 104 can include various types of requester applications. For example, therequester application 104 can be a web application (e.g., accessed using a web browser) or a native application provided by thetransportation matching system 114 for communicating with and accessing the services of the transportation matching system 114 (e.g., to request transportation). Similarly, the provider device(s) 106 can include various types of computing devices (e.g., a smartphone or integrated computing device within an autonomous vehicle), and theprovider application 108 can include a web or native application for communicating with and accessing the services of the transportation matching system 114 (e.g., to provide transportation services to one or more requesters). Additionally, the server device(s) 112 can include one or more computing devices, such as those explained below with reference toFIG. 10 . - The requester device(s) 102, the provider device(s) 106, and the
transportation matching system 114 may communicate by way of thenetwork 110, which can include one or more communications networks using communication platforms and technologies suitable for transporting data and/or communication signals, examples of which are described with reference toFIG. 10 . - The
transportation matching system 114 dynamically matches transportation requests received from requesters (e.g., requesters associated with requester device(s) 102) with available transportation service providers (e.g., transportation providers associated with the provider device(s) 106). To illustrate, a transportation matching system can identify transportation requests, identify potential transportation provider devices, determine locations of requester devices and provider devices, and match provider devices and requester devices based on a variety of criteria. One will appreciate that the supply of transportation providers does not always match the demand of transportation requesters. Accordingly, thetransportation matching system 114 can perform various actions for determining and communicating supply and demand to providers so that providers can drive at appropriate/optimal times. In accordance with one or more embodiments disclosed herein, thetransportation matching system 114 utilizes theprovider balance system 116 to determine, visualize, and communicate supply and demand information. - As discussed above, the
provider balance system 116 can generate provider device balance graphs.FIGS. 2A-2C illustrate example graphical user interfaces utilized by one or more transportation matching systems. In particular,FIG. 2A illustrates a user interface generated in accordance with one or more conventional systems described above. Specifically,FIG. 2A illustrates auser interface 200 that visualizes demand only. Moreover,FIGS. 2B-2C illustrate provider device balance graphs generated by theprovider balance system 116 in accordance with one or more embodiments. In particular,FIG. 2B illustrates a provider device balancegraphical user interface 202 with a providerdevice balance graph 210 visualizing device utilization ratios andFIG. 2C illustrates a provider device balancegraphical user interface 204 with a providerdevice balance graph 220 visualizing probabilities. - As shown in
FIG. 2A , conventional systems generate user interfaces with avisualization 206 that portrays demand. However, because the visualized time period includes some demand “spikes” (where some hours have a much higher demand than others), it appears as if the demand is very low for most of the displayed time period. Accordingly, this approach can mislead providers, causing an over-supply of driver devices during these “spike” time periods and an under-supply of driver devices during other time periods. - In contrast, the
provider balance system 116 can generate device incentive graphs that more accurately and efficiently distribute provider devices. As shown inFIG. 2B , the providerdevice balance graph 210 visualizes device utilization ratios over the same time period visualized inFIG. 2A . More specifically, the providerdevice balance graph 210 visualizes device utilization ratios determined based on forecasted requester device sessions and driver supply hours. As shown, the providerdevice balance graph 210 is much less distorted and avoids drastic spikes throughout the target time period. The providerdevice balance graph 210 inFIG. 2B is much more efficient in distributing provider devices because it illustrates relative balance between requester devices and provider devices over the time period rather than raw demand. - As mentioned above, the
provider balance system 116 can also generate device incentive graphs that reflect probabilities.FIG. 2C illustrates a providerdevice balance graph 220 that reflects probabilities. That is, the providerdevice balance graph 220 reflects device utilization ratios that have been modified utilizing a probability distribution. Specifically, each of the bars in the providerdevice balance graph 220 reflect a cumulative probability (e.g., an inverse cumulative probability) of a corresponding forecast measure. In one or more embodiments, theprovider balance system 116 utilizes a probability distribution to determine bins for device utilization ratios. As shown inFIG. 2C , the visualization of probabilities further smooths the device incentive graph in order to communicate to the provider the relative benefit of providing transportation services at various times. - It will be appreciated that the
provider balance system 116 can provide a variety of user interface elements for interacting with device incentive graphs. For example, as shown inFIG. 2C , the provider device balancegraphical user interface 204 can include atime selection element 222. For example, atime selection element 222 can include a user interface element for selecting time periods. Upon detecting user interaction with thetime selection element 222, theprovider balance system 116 can include a provider device balance graph for a different time period. For example, upon user interaction with thetime selection element 222 theprovider balance system 116 can generate a provider device balance graph for a specified week rather than a specified day. - As also shown in
FIG. 2C , the provider device balancegraphical user interface 204 can also include aset goal button 224. Upon detecting selection of the set goal button, theprovider balance system 116 can present the provider device with a scheduling graphical user interface. In particular theprovider balance system 116 can generate scheduling elements that automatically assist the provider to select times to provide transportation services. Additional detail regarding suggesting a transportation service schedule via a scheduling graphical user interface is provided below (e.g., in relation toFIG. 7 ). - As shown, the provider device balance
graphical user interface 204 can also include other user interface elements, such as ahome tab 226, anearnings tab 228, and ascheduling tab 230. In one or more embodiments, theprovider balance system 116 can display a default or home screen in response to detecting selection of thehome tab 226. Theprovider balance system 116 can also present the provider device balancegraphical user interface 204 in response to detecting selection of theearnings tab 228. Further, theprovider balance system 116 can present a scheduling graphical user interface upon detecting selection of the scheduling tab 230 (e.g., a scheduling interface that includes scheduled transportation times to achieve a particular goal). - As discussed above, the
provider balance system 116 can determine device utilization ratios and probabilities and generate provider device balance graphs. For example,FIG. 3 illustrates a series of acts 302-310 utilized to generate a provider device balance graph in accordance with one or more embodiments. - Specifically, as shown in
FIG. 3 , theprovider balance system 116 performs anact 302 of detecting requester devices and provider devices at a location. In particular, theprovider balance system 116 can track historical and current data as to the volume and type of interactions of both requester device(s) 102 and provider device(s) 106 over various locations where the transportation matching systems offers transportation services. For example, theprovider balance system 116 can monitor the number of application sessions from requester devices over time for different geographic regions. Similarly, theprovider balance system 116 can monitor the number of provider devices (or provider device hours) over time for different geographic regions. In addition theprovider balance system 116 can monitor a variety of other metrics, such as the number of rides, number of application sessions, miles of transportation provided, earnings received (e.g., earnings per driver device), number of requests received, number of riders, etc. Accordingly, theprovider balance system 116 can actively monitor activity across the transportation matching system and determine various metrics with regard to requester devices and provider devices. - As shown in
FIG. 3 , theprovider balance system 116 also performs anact 304 of generating predicted device utilization for requester computing devices and provider computing devices. For instance, theprovider balance system 116 can determine forecast measures of provider computing device availability and forecast measures of requester computing device application sessions. In one or more embodiments, theprovider balance system 116 generates these forecasts based on historical data from requester device(s) 102 and/or provider device(s) 106 (e.g., from the act 304). Theprovider balance system 116 can utilize various historical data, including ride data, seasonal data, and/or event data. As will be discussed in greater detail below, in one or more embodiments, theprovider balance system 116 can also apply seasonal and/or event scaling to a provider device balance graph. - The
provider balance system 116 can utilize a variety of analytical techniques to determine forecast measures. For example, in some embodiments, theprovider balance system 116 can analyze historical metrics (e.g., historical application sessions or historical provider device availability) utilizing regression techniques to determine typical or average provider device availability or requester device application sessions. Theprovider balance system 116 can also train and utilize machine learning models to generate these forecast measures, such as neural networks (e.g., a convolutional neural network), autoencoders, linear regression models, logistic regression models, vector machines, decision tress, Bayesian networks, conditional random fields, or Hidden Markov models. - Using one or more forecasting models, the
provider balance system 116 can generate predicted device utilization for requester computing devices and provider computing devices (e.g., forecast measures of provider computing device availability and requester computing device application sessions). These measures can take a variety of specific forms. For example, theprovider balance system 116 can forecast a number of times an application connects to a server, a number of requests from a transportation application, a number of application executions (e.g., a number of times an application is opened), payments received via a transportation application, or a number of completed rides arranged via a transportation application. Similarly, theprovider balance system 116 can forecast a number of provider devices during a particular time, a number of provider device supply hours (e.g., a number of hours that provider devices are available), a number of miles of transportation services provided by provider devices, or an amount of earnings (e.g., dollars received per driver device). - In addition to generating predicted device utilization for requester computing devices and provider computing devices, the
provider balance system 116 can also receive forecast measures (e.g., from thetransportation matching system 114, or from another source via the network 110). As discussed above, the forecast measures can reflect various measurements of supply and demand for thetransportation matching system 114. - Additionally, the
provider balance system 116 can perform an act 306 of generating device utilization ratios. In one or more embodiments, theprovider balance system 116 determines device utilization ratios based on a supply forecast measure with respect to requester devices (e.g., demand) and a forecast measure with respect to provider devices (e.g., supply). More specifically, theprovider balance system 116 can generate the device utilization ratios based on a ratio of a device utilization for requester computing devices and device utilization for provider computing devices (e.g., a ratio of a demand forecast measure to a supply forecast measure). As shown inFIG. 3 ., theprovider balance system 116 can determine the device utilization ratios based on a ratio of requester device application sessions for a given time period to driver supply hours over the time period. - Then, as shown in
FIG. 3 , theprovider balance system 116 can perform anact 308 of generating probabilities. In particular, theprovider balance system 116 can determine a probability distribution that reflects the probability across forecast measures. For instance, theprovider balance system 116 can determine a probability distribution reflecting probabilities of different device utilization ratios for any particular time period and/or location. As will be discussed in greater detail below with regard toFIG. 4 , theprovider balance system 116 can utilize a probability distribution to generate the probabilities. - The
provider balance system 116 can generate a probability distribution by analyzing historical measures with regard to provider devices and requester devices. For instance, theprovider balance system 116 can determine historical device utilization ratios for a particular location for a given time period (e.g., an hour, a day, or a week). Theprovider balance system 116 can analyze the historical device utilization ratios and determine the mean, variance, and/or standard deviation defining the probability distribution. In this manner, theprovider balance system 116 can generate probability distributions for various locations (e.g., geographic regions) and times (e.g., hours, days, weeks or months). - The
provider balance system 116 can then utilize the probability distribution to determine probabilities. Specifically, theprovider balance system 116 can determine individual probabilities of device utilization ratios, cumulative probabilities of device utilization ratios, and/or cumulative percentile bins corresponding to device utilization ratios. Theprovider balance system 116 can then utilize one or more of these metrics as probabilities. - Upon determining the probabilities, the
provider balance system 116 can perform anact 310 of generating a provider device balance graph. In one or more embodiments, theprovider balance system 116 generates the provider device balance graph based on the probabilities. For example, theprovider balance system 116 can plot cumulative probabilities (e.g., inverse cumulative probabilities) for a plurality of times within a time period. To illustrate, theprovider balance system 116 can map a device utilization ratio for a time period to a cumulative probability bin (e.g., 90-95% probability of having a device utilization ratio at or below the determined value) and then plot a representation of the cumulative probability bin for the time period. - The
provider balance system 116 can also generate the providerdevice balance graph 210 based on a variety of other measures and/or metrics. For example, as will be discussed below with regard toFIG. 6 , theprovider balance system 116 can generate a provider device balance graph that reflects earnings-ridership metrics. - Accordingly, the
provider balance system 116 can select which metric and/or measure to visualize via the provider device balance graph. For example, theprovider balance system 116 can select between provider device measures or earnings-ridership measures based at least in part on the readability (i.e., the ease with which a user can understand the meaning of a visualization) of each potential visualization. Theprovider balance system 116 can determine the readability of a potential visualization based on the scale of a given visualization (e.g., select the metric with the smallest range shown in the provider device balance graph to reduce spikes). Further, theprovider balance system 116 can select a measure to illustrate in a provider device balance graph based on provider device preferences and/or previous provider device(s) 106 interactions with provider device balance graphs. - As mentioned above, in some embodiments, the
provider balance system 116 can apply thresholds to device utilization ratios to further smooth provider device balance graphs. For example, theprovider balance system 116 can apply a lower probability distribution device balance threshold and/or an upper probability distribution device balance threshold.FIG. 4 provides additional detail regarding a process for determining probabilities and applying minimum or maximum thresholds in accordance with one or more embodiments. - For example, as shown in
FIG. 4 , theprovider balance system 116 can utilize thedevice utilization ratios 402 and aprobability distribution 404 for a representative week (or other representative time period) to determine theprobabilities 406. More specifically, theprovider balance system 116 can determine aprobability 406 corresponding to a particular device utilization ratio by determining the inverse cumulative probability (from the probability distribution) for thedevice utilization ratios 402 that device utilization ratio. - The
provider balance system 116 can determine a probability distribution based on historical or forecasted measures. For example, theprovider balance system 116 can determine a probability distribution by analyzing historical device utilization ratios from a representative time period (e.g., a “normal” or “average” week or month). In some embodiments, theprovider balance system 116 can determine forecast measures for a time period (e.g., a week) and generate a probability distribution based on the forecast measures (e.g., determine a mean and standard deviation of the forecast measures). - As mentioned, the
provider balance system 116 can utilize various approaches to determineprobabilities 406. For example, theprovider balance system 116 can rank and bindevice utilization ratios 402 by percentile to generateprobabilities 406. In one or more embodiments, theprovider balance system 116 determines a percentile for each of thedevice utilization ratios 402 and assigns thedevice utilization ratios 402 to bins based on their percentile rank. In one or more embodiments, theprovider balance system 116 can utilize the binned values as theprobabilities 406. - Further, in one or more embodiments, the
provider balance system 116 generatesprobabilities 406 based on a cumulative distribution. In particular, theprovider balance system 116 can generate an inverse cumulative probability distribution and utilize the inverse cumulative probability distribution to generate theprobabilities 406. That is, theprovider balance system 116 can determineprobabilities 406 by determining from the inverse cumulative probability distribution that a random value takes a value less than or equal to the correspondingdevice utilization ratios 402. - As mentioned, in one or more embodiments, he
provider balance system 116 can utilize an inverse cumulative probability distribution to map device utilization ratios to corresponding probability bins. To illustrate, theprovider balance system 116 can utilize an inverse cumulative probability distribution to identify ranges of device utilization ratios that corresponding to inverse cumulative distribution ranges. Theprovider balance system 116 can then bin thedevice utilization ratios 402 according to each of the determined probability ranges and utilize those binned values as theprobabilities 406. - As shown in
FIG. 4 , theprovider balance system 116 can also perform anact 408 of imposing minimum and/or maximum thresholds on theprobabilities 406. That is, upon generating theprobabilities 406, theprovider balance system 116 can impose thresholds before generating the provider device balance graph. For example, as illustrated inFIG. 4 , theprovider balance system 116 can impose a lowerdevice balance threshold 410 and an upperdevice balance threshold 412. Theprovider balance system 116 can map values that fall below the lowerdevice balance threshold 410 to values at or above the lowerdevice balance threshold 410. Similarly, theprovider balance system 116 can map values that fall above the upperdevice balance threshold 412 to at or below the upperdevice balance threshold 412. - In some embodiments, the
provider balance system 116 can map the largest value (e.g., the largest probabilities) to the upperdevice balance threshold 412. In particular, theprovider balance system 116 can require the largest value to the upper device balance threshold (and redistribute the remaining values) to more clearly articulate differences between measures shown on the graph - To illustrate, in some embodiments, the
provider balance system 116 imposes a lower device balance threshold of 10 and an upper device balance threshold of 100. Theprovider balance system 116 can then distribute (or normalize) probabilities between the lower device balance threshold and the upper device balance threshold. For example, theprovider balance system 116 can multiply eachprobabilities 406 by 0.9 and add 10. However, it will be appreciated that theprovider balance system 116 can adjust the probabilities within a variety of selected ranges. - As discussed above, in one or more embodiments, the
provider balance system 116 can determineprobabilities 406 based on a binning procedure and/or canbin probabilities 406 before generating the provider device balance graph.FIG. 5 illustrates a binning procedure for probabilities in accordance with one or more embodiments. - Specifically, as shown in
FIG. 5 , theprovider balance system 116 can rank the probabilities and can map each probabilities onto a bin and corresponding bin value based on its bin range. Specifically, upon ranking the probabilities, theprovider balance system 116 can determine a probability distribution. For example, in relation toFIG. 5 , theprovider balance system 116 determines that the top two measures (4.8, 5.1 reflecting the top 10% of values) corresponding to a first bin (e.g., labeled 100) corresponding to an inverse cumulative probability range of 91-100%. Similarly, theprovider balance system 116 determines that the next two measures (3.2, 4.45) correspond to a second bin (e.g., labeled 90) corresponding to an inverse cumulative probability range of 81%-90%. - As shown, the
provider balance system 116 can also assign measures to bins based on a bin range. AlthoughFIG. 5 shows the bin ranges corresponds to the probability distribution device measures as ranked, in some embodiments, the bin ranges are determined separately from the ranked device utilization ratios. For example, theprovider balance system 116 can determine a probability distribution based on historical values and determine bin ranges based on the probability distribution. For instance, theprovider balance system 116 can determine that a 91% inverse cumulative probability corresponds to a first value and use the first value to define the lower range for the first bin (labeled “100”). Similarly, theprovider balance system 116 can determine that an 81% inverse cumulative probability corresponds to a second value and that a 90% inverse cumulative probability corresponds to a third value. Theprovider balance system 116 can determine a range for the second bin utilizing the second value and the third value. More specifically, theprovider balance system 116 can utilize the second value as the lower range for the second bin (labeled “90”) and the third value as the upper range for the second bin. - Thus, the
provider balance system 116 can determine a number of bins and can assign a value to probabilities assigned to that bin. Further, theprovider balance system 116 can determine a range of probabilities for each bin based on a probability distribution (e.g., based on an inverse cumulative distribution as discussed above). Then, theprovider balance system 116 can utilize the bin values to visualize theprobabilities 406 in the provider device balance graph. Accordingly, in relation toFIG. 5 , theprovider balance system 116 maps the device utilization ratio 5.1 to a probability of 100. Similarly, theprovider balance system 116 maps the device utilization ratio 0.8 to a probability of 20. - As also discussed briefly above, the
provider balance system 116 can generate and utilize earnings-ridership metrics to utilize in an earnings-ridership graph within a provider incentive graphical user interface.FIG. 6 illustrates generating and utilizing an earnings-ridership metric. For example, as shown inFIG. 6 , theprovider balance system 116 performs anact 602 of determining projected earning metrics and projected number of rides. Similar to the discussion above with regard to forecast measures, theprovider balance system 116 can generate the projected earning metrics and projected number of rides based on data monitored from the requester device(s) 102 and the provider device(s) 106. Theprovider balance system 116 can also receive the projected earning metrics and projected number of rides from thetransportation matching system 114 and/or from another source via thenetwork 110. - Further, as shown in
FIG. 6 , theprovider balance system 116 can perform anact 604 of generating an earnings-ridership metric. Theprovider balance system 116 can generate the earnings-ridership metric based on the projected earning metrics and the projected number of rides for a specified time period. More specifically, in one or more embodiments, theprovider balance system 116 generates the earnings-ridership metric by multiplying the projected earning metrics for a given time period and a radical of the projected number of rides for the given time period. Theprovider balance system 116 can utilize a projected earnings metric per ride and/or per time interval. For example, theprovider balance system 116 can utilize the square root or the cube root of the number of projected rides to determine the earnings-ridership metric. - Then, the
provider balance system 116 can perform anact 606 of generating a driver device incentive graph that reflects the earnings-ridership metrics. In particular, theprovider balance system 116 can generate a driver device incentive graph with a visual representation for individual earning-ridership metrics for individual times within a target time period. As discussed above (in relation toFIG. 4 ), theprovider balance system 116 can apply thresholds to the earning-ridership metrics and/or determine probability distribution earning-ridership metrics. The earnings-ridership graph can accurately communicate relative benefit of driving at various times by utilizing both earnings and ride frequency rather than raw demand. - As discussed briefly above, the
provider balance system 116 can present a scheduling graphical user interface including a provider device balance graph to communicate to provider device(s).FIG. 7 shows an example embodiment of a scheduling graphical user interface presented in accordance with one or more embodiments. - As shown in
FIG. 7 , the schedulinggraphical user interface 700 can include a providerdevice balance graph 702. In one or more embodiments, the providerdevice balance graph 702 that includes scheduling indicators 703. The scheduling indicators 703 identify suggested time periods for providing transportation services. - As illustrated, in some embodiments, the
provider balance system 116 can generate the scheduling indicators 703 based on a particular goal for the provider device. For instance, theprovider balance system 116 can suggest a schedule to satisfy a monetary goal or other goals (e.g., a goal for a number of rides or a goal for an amount of time spent driving). For example, as shown inFIG. 7 , the scheduling indicators 703 bracket two time periods at which the driver can drive during the visualized day in order to meet a weekly goal. However, theprovider balance system 116 can present the scheduling indicators 703 in accordance with a variety of designs that communicate selected time periods. For example, the scheduling indicators 703 can be highlighted portions of the provider device balance graph, portions of the provider device balance graph with an alternate color, a circled or boxed portion of the provider device balance graph, or any other indication of a selected portion. In some embodiments, theprovider balance system 116 can suggest a transportation schedule utilizing a variety of different interface elements (e.g., by providing a calendar with drive times highlighted). - The
provider balance system 116 can generate suggested schedules based on a variety of factors. In some embodiments, theprovider balance system 116 generates suggestions based on the highest device utilization ratios (or highest probabilities). In some embodiments, theprovider balance system 116 suggests transportation times with the highest device utilization ratios until satisfying a particular goal. For instance, in relation toFIG. 7 , theprovider balance system 116 generates suggested transportation times until projected earnings during the suggested times exceed $800. - In one or more embodiments, the
provider balance system 116 can generate a suggested schedule based on preferred or historical transportation times of the provider device (e.g., emphasize night times for a provider device that is typically available at nights). Similarly, theprovider balance system 116 can generate a schedule based on a minimum consecutive drive time (e.g., group drive times into a minimum of two hour drive times). - The
provider balance system 116 can utilize heuristic approaches to generate suggested schedules. In some embodiments, theprovider balance system 116 can utilize a machine learning model to generate suggested schedules. For instance, theprovider balance system 116 can utilize a neural network (e.g., a recurrent neural network) to analyze input parameters (e.g., goals, historical drive times, etc.), and generate suggested drive times. - Although
FIG. 7 illustrates suggestions for particular times, theprovider balance system 116 can also generate suggestions for particular locations. For instance, theprovider balance system 116 can analyze device utilization ratios for a plurality of locations and suggest a location based on the device utilization ratios (e.g., suggest the locations and times with the highest device utilization ratios). - Further, as shown in
FIG. 7 , the schedulinggraphical user interface 700 can include ascheduling explanation 704. Thescheduling explanation 704 can display the goal corresponding to theprovider device 106 and the duration of the goal. For example, as shown inFIG. 7 , thescheduling explanation 704 indicates that the goal is a “Weekly Goal” and recites “Drive at these time to earn your goal of $800.” As also shown inFIG. 7 , thescheduling explanation 704 can include thegoal input area 706. Thegoal input area 706 can receive provider input indicating the provider’s target earnings. In response to receiving input at thegoal input area 706, theprovider balance system 116 can generate and/or update the placement of the scheduling indicators 703 to reflect the provided goal. - Though
FIG. 7 shows a weekly goal and a day view of a provider device balance graph, it will be appreciated that the schedulinggraphical user interface 700 can present provider device balance graphs and scheduling indicators 703 corresponding to a variety of goals and goal durations. For example, the schedulinggraphical user interface 700 can include daily, monthly, or yearly goals. Additionally, the schedulinggraphical user interface 700 can include provider device balance graphs visualizing relative supply and demand over various time periods, including a week or month. - Additionally, as briefly mentioned above, the
provider balance system 116 can apply event modifiers and/or seasonal scaling .FIG. 8 illustrates applying these adjustments to an example provider device balance graph. First, as shown inFIG. 8 , theprovider balance system 116 can start with a generated providerdevice balance graph 802. - Then, as also shown in
FIG. 8 , theprovider balance system 116 can perform anact 804 of generating and applying an event modifier. Theprovider balance system 116 can generate the event modifier based on historical data and/or data received from thetransportation matching system 114 and/or via thenetwork 110. That is, theprovider balance system 116 can utilize both historical data from a variety of sources and data regarding an upcoming event received from an administrator or from another source. Then, based on the event data, including based on data from similar events, theprovider balance system 116 can generate an event modifier for a providerdevice balance graph 802. Then, theprovider balance system 116 can apply the event modifier to the relevant portions (i.e. times) on the providerdevice balance graph 802. - For example, the
provider balance system 116 can analyze historical data and determine that a professional basketball game increases device utilization ratios by a factor of 1.4 (on average). Theprovider balance system 116 can analyze a repository of upcoming events and identify that a professional basketball is scheduled. Theprovider balance system 116 can the apply the event modifier (e.g., 1.4) to the device utilization ratios. - The
provider balance system 116 can apply scaling metrics to a variety of time periods. For example, theprovider balance system 116 can perform scaling on a per day or per week basis. Thus, for instance, theprovider balance system 116 can apply a Christmas Day event scaling metric to an entire day or a basketball event scaling metric to a particular hour. - Additionally, as shown in
FIG. 8 , theprovider balance system 116 can perform an act 806 of applying a seasonal adjustment based on historical data. As discussed above, theprovider balance system 116 can determine historical data via requester device(s) 102 and provider device(s) 106, via thetransportation matching system 114, and/or from other sources via thenetwork 110. Theprovider balance system 116 can determine a seasonal adjustment for a providerdevice balance graph 802 based on the time of year applicable to the graph. For example, theprovider balance system 116 can determine that a geographical area around a university experiences increased requests on weekdays in the afternoon during the school year, but not during summer break. That is, theprovider balance system 116 can determine that during the season applicable to a providerdevice balance graph 802, thetransportation matching system 114 experiences increased demand during a particular time of day and can scale the providerdevice balance graph 802 accordingly. - In addition to event or seasonal scaling, the
provider balance system 116 can also apply other scaling metrics. For example, theprovider balance system 116 can apply geographic scaling metrics. To illustrate, theprovider balance system 116 can apply a particular scaling metric (e.g., a 2.0 multiplier) to a first geographic location relative to a second geographic location. -
FIGS. 1-8 , the corresponding text, and the examples provide a number of different methods, systems, devices, and non-transitory computer-readable media of theprovider balance system 116. In addition to the foregoing, one or more embodiments can also be described in terms of flowcharts comprising acts for accomplishing a particular result, as shown inFIG. 9 .FIG. 9 may be performed with more or fewer acts. Further, the acts may be performed in differing orders. Additionally, the acts described herein may be repeated or performed in parallel with one another or parallel with different instances of the same or similar acts. - As mentioned,
FIG. 9 illustrates a flowchart of a series ofacts 900 for theprovider balance system 116 in accordance with one or more embodiments. WhileFIG. 9 illustrates acts according to one embodiment, alternative embodiments may omit, add to, reorder, and/or modify any of the acts shown inFIG. 9 . The acts ofFIG. 9 can be performed as part of a method. Alternatively, a non-transitory computer-readable medium can comprise instructions that, when executed by one or more processors, cause a computing device to perform the acts ofFIG. 9 . In some embodiments, a system can perform the acts ofFIG. 9 . - As shown in
FIG. 9 , the series ofacts 900 includes anact 902 for determining a forecast measure for requester computing devices within a time period. In particular, theact 902 can include determining a forecast measure of requester computing device application sessions for a plurality of requester computing devices of a transportation matching system for a plurality of times within a time period. - Additionally, as shown in
FIG. 9 , the series ofacts 900 includes anact 904 for determining a forecast measure of provider computing device availability for a plurality of provider computing devices within the time period. In particular, theact 904 can include determining a forecast measure of provider computing device availability for a plurality of provider computing devices of the transportation matching system for the plurality of times within the time period. - Further, as shown in
FIG. 9 , the series ofacts 900 includes anact 906 for based on the forecast measure of requester computing device application sessions and the forecast measure of provider computing device availability, generating device utilization ratios. In particular, theact 906 can include, based on the forecast measure of requester computing device application sessions and the forecast measure of provider computing device availability, generating device utilization ratios for the plurality of times within the time period. In one or more embodiments, theact 906 can include generating projected provider device earnings-ridership metrics for the plurality of times based on projected provider device earnings metrics for the plurality of times and a radical of a projected number of rides for the plurality of times. - The series of
acts 900 also includes anact 908 for generating probabilities from the device utilization ratios based on cumulative probabilities of the market balance measures. In particular, theact 908 can include generating probabilities from the device utilization ratios based on cumulative probabilities of the market balance measures. Specifically, theact 908 can include determining ratios of the forecast measures of provider computing device application sessions to the forecast measure of provider computing device availability measures. Further, theact 908 can include organizing the device utilization ratios for the plurality of times into a plurality of bins based on the cumulative probabilities, wherein the plurality of bins reflect cumulative probability ranges. - Additionally, the
act 908 can include determining a lower probability distribution device balance threshold and generating the probabilities by mapping the device utilization ratios above the lower probability distribution device balance threshold. Theact 908 can also include identifying a standardized probability distribution device balance distribution based on historical provider computing device availability and historical requester computing device application sessions for a test time period and determining the cumulative probabilities of the market balance measures based on the standardized probability distribution device balance distribution. - As shown in
FIG. 9 , the series ofacts 900 further includes anact 910 for providing a provider device balance graph portraying the probability distribution device balance metrics with respect to the time period. In particular, theact 910 can include providing, for display via a provider computing device, a provider device balance graph portraying the probability distribution device balance metrics with respect to the plurality of times. Specifically, theact 910 can include displaying visual representations of the plurality of bins with respect to the plurality of time. In one or more embodiments, theact 908 can include generating one or more provider device balance graphs portraying the provider device earnings-ridership metrics with respect to the plurality of times. Further, theact 908 can include identifying an event corresponding to a time range within the time period, determining an event modifier corresponding to the event, identifying a set of probabilities corresponding to the time range from the probabilities, and adjusting the set of probabilities corresponding to the time range utilizing the event modifier. - Embodiments of the present disclosure may comprise or utilize a special purpose or general-purpose computer including computer hardware, such as, for example, one or more processors and system memory, as discussed in greater detail below. Embodiments within the scope of the present disclosure also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. In particular, one or more of the processes described herein may be implemented at least in part as instructions embodied in a non-transitory computer-readable medium and executable by one or more computing devices (e.g., any of the media content access devices described herein). In general, a processor (e.g., a microprocessor) receives instructions, from a non-transitory computer-readable medium, (e.g., memory), and executes those instructions, thereby performing one or more processes, including one or more of the processes described herein.
- Computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system. Computer-readable media that store computer-executable instructions are non-transitory computer-readable storage media (devices). Computer-readable media that carry computer-executable instructions are transmission media. Thus, by way of example, and not limitation, embodiments of the disclosure can comprise at least two distinctly different kinds of computer-readable media: non-transitory computer-readable storage media (devices) and transmission media.
- Non-transitory computer-readable storage media (devices) includes RAM, ROM, EEPROM, CD-ROM, solid state drives (“SSDs”) (e.g., based on RAM), Flash memory, phase-change memory (“PCM”), other types of memory, other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.
- A “network” is defined as one or more data links that enable the transport of electronic data between computer systems and/or modules and/or other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a transmission medium. Transmissions media can include a network and/or data links which can be used to carry desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer-readable media.
- Further, upon reaching various computer system components, program code means in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to non-transitory computer-readable storage media (devices) (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a “NIC”), and then eventually transferred to computer system RAM and/or to less volatile computer storage media (devices) at a computer system. Thus, it should be understood that non-transitory computer-readable storage media (devices) can be included in computer system components that also (or even primarily) utilize transmission media.
- Computer-executable instructions comprise, for example, instructions and data which, when executed by a processor, cause a general-purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. In some embodiments, computer-executable instructions are executed by a general-purpose computer to turn the general-purpose computer into a special purpose computer implementing elements of the disclosure. The computer-executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.
- Those skilled in the art will appreciate that the disclosure may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, pagers, routers, switches, and the like. The disclosure may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. In a distributed system environment, program modules may be located in both local and remote memory storage devices.
- Embodiments of the present disclosure can also be implemented in cloud computing environments. As used herein, the term “cloud computing” refers to a model for enabling on-demand network access to a shared pool of configurable computing resources. For example, cloud computing can be employed in the marketplace to offer ubiquitous and convenient on-demand access to the shared pool of configurable computing resources. The shared pool of configurable computing resources can be rapidly provisioned via virtualization and released with low management effort or service provider interaction, and then scaled accordingly.
- A cloud-computing model can be composed of various characteristics such as, for example, on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service, and so forth. A cloud-computing model can also expose various service models, such as, for example, Software as a Service (“SaaS”), Platform as a Service (“PaaS”), and Infrastructure as a Service (“IaaS”). A cloud-computing model can also be deployed using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, and so forth. In addition, as used herein, the term “cloud-computing environment” refers to an environment in which cloud computing is employed.
-
FIG. 10 illustrates a block diagram of anexample computing device 1000 that may be configured to perform one or more of the processes described above. One will appreciate that one or more computing devices, such as thecomputing device 1000 may represent the computing devices described above (e.g., computing requester device(s) 102, provider device(s) 106, and/or server device(s) 112). In one or more embodiments, thecomputing device 1000 may be a mobile device (e.g., a mobile telephone, a smartphone, a PDA, a tablet, a laptop, a camera, a tracker, a watch, a wearable device, etc.). In some embodiments, thecomputing device 1000 may be a non-mobile device (e.g., a desktop computer or another type of client device). Further, thecomputing device 1000 may be a server device that includes cloud-based processing and storage capabilities. - As shown in
FIG. 10 , thecomputing device 1000 can include one or more processor(s) 1002,memory 1004, astorage device 1006, input/output interfaces 1008 (or “I/O interfaces 1008”), and acommunication interface 1010, which may be communicatively coupled by way of a communication infrastructure (e.g., bus 1012). While thecomputing device 1000 is shown inFIG. 10 , the components illustrated inFIG. 10 are not intended to be limiting. Additional or alternative components may be used in other embodiments. Furthermore, in certain embodiments, thecomputing device 1000 includes fewer components than those shown inFIG. 10 . Components of thecomputing device 1000 shown inFIG. 10 will now be described in additional detail. - In particular embodiments, the processor(s) 1002 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) 1002 may retrieve (or fetch) the instructions from an internal register, an internal cache,
memory 1004, or astorage device 1006 and decode and execute them. - The
computing device 1000 includesmemory 1004, which is coupled to the processor(s) 1002. Thememory 1004 may be used for storing data, metadata, and programs for execution by the processor(s). Thememory 1004 may include one or more of volatile and nonvolatile 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. Thememory 1004 may be internal or distributed memory. - The
computing device 1000 includes astorage device 1006 includes storage for storing data or instructions. As an example, and not by way of limitation, thestorage device 1006 can include a non-transitory storage medium described above. Thestorage device 1006 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 1000 includes one or more I/O interfaces 1008, 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 thecomputing device 1000. These I/O interfaces 1008 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 1008. The touch screen may be activated with a stylus or a finger. - The I/
O interfaces 1008 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 1008 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 1000 can further include acommunication interface 1010. Thecommunication interface 1010 can include hardware, software, or both. Thecommunication interface 1010 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 1010 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. Thecomputing device 1000 can further include abus 1012. Thebus 1012 can include hardware, software, or both that connects components ofcomputing device 1000 to each other. - In the foregoing specification, the invention has been described with reference to specific example 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 to one another or in parallel to 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.
-
FIG. 11 illustrates anexample network environment 1100 of a transportation matching system (e.g., the transportation matching system 114). Thenetwork environment 1100 includes aclient device 1106, atransportation matching system 114, and avehicle subsystem 1108 connected to each other by anetwork 1104. AlthoughFIG. 11 illustrates a particular arrangement of theclient device 1106, thetransportation matching system 114, thevehicle subsystem 1108, and thenetwork 1104, this disclosure contemplates any suitable arrangement of theclient device 1106, thetransportation matching system 114, thevehicle subsystem 1108, and thenetwork 1104. As an example, and not by way of limitation, two or more of theclient device 1106, thetransportation matching system 114, and thevehicle subsystem 1108 communicate directly, bypassing thenetwork 1104. As another example, two or more of theclient device 1106, thetransportation matching system 114, and thevehicle subsystem 1108 may be physically or logically co-located with each other in whole or in part. Moreover, althoughFIG. 11 illustrates a particular number of theclient devices 1106, thetransportation matching systems 114, thevehicle subsystems 1108, and thenetworks 1104, this disclosure contemplates any suitable number of theclient devices 1106, thetransportation matching systems 114, thevehicle subsystems 1108, and thenetworks 1104. As an example, and not by way of limitation, thenetwork environment 1100 may includemultiple client devices 1106, thetransportation matching systems 114, thevehicle subsystems 1108, and thenetworks 1104. - This disclosure contemplates any
suitable network 1104. As an example, and not by way of limitation, one or more portions of thenetwork 1104 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. Thenetwork 1104 may include one ormore networks 1104. - Links may connect the
client device 1106, thetransportation matching system 114, and thevehicle subsystem 1108 to thecommunication network 1104 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 thenetwork environment 1100. One or more first links may differ in one or more respects from one or more second links. - In particular embodiments, the
client device 1106 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 theclient device 1106. As an example, and not by way of limitation, aclient device 1106 may include any of the computing devices discussed above in relation toFIG. 7 . Aclient device 1106 may enable a network user at theclient device 1106 to access a network. Aclient device 1106 may enable its user to communicate with other users atother client systems 1106. - In particular embodiments, the
client device 1106 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 theclient device 1106 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 toclient device 1106 one or more Hyper Text Markup Language (HTML) files responsive to the HTTP request. Theclient device 1106 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 SIL VERLIGHT, 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 114 may be a network-addressable computing system that can host a ride share transportation network. Thetransportation matching system 114 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 thetransportation matching system 114. 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 114 may manage ride matching services to connect a user/requester with a vehicle and/or provider. By managing the ride matching services, thetransportation matching system 114 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 114 may be accessed by the other components of thenetwork environment 1100 either directly or vianetwork 1104. In particular embodiments, thetransportation matching system 114 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, thetransportation matching system 114 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 aclient device 1106, or atransportation matching system 114 to manage, retrieve, modify, add, or delete, the information stored in data store. - In particular embodiments, the
transportation matching system 114 may provide users with the ability to take actions on various types of items or objects, supported by thetransportation matching system 114. As an example, and not by way of limitation, the items and objects may include ride share networks to which users of thetransportation matching system 114 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 thetransportation matching system 114 or by an external system of a third-party system, which is separate from thetransportation matching system 114 and coupled to thetransportation matching system 114 via anetwork 1104. - In particular embodiments, the
transportation matching system 114 may be capable of linking a variety of entities. As an example, and not by way of limitation, thetransportation matching system 114 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 114 may include a variety of servers, sub-systems, programs, modules, logs, and data stores. In particular embodiments, thetransportation matching system 114 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. Thetransportation matching system 114 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, thetransportation matching system 114 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 114 and one ormore client systems 1106. An action logger may be used to receive communications from a web server about a user’s actions on or off thetransportation matching system 114. 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 aclient device 1106. Information may be pushed to aclient device 1106 as notifications, or information may be pulled from theclient device 1106 responsive to a request received from theclient device 1106. Authorization servers may be used to enforce one or more privacy settings of the users of thetransportation matching system 114. 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 thetransportation matching system 114 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 theclient systems 1106 associated with users. - In addition, the
vehicle subsystem 1108 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, thevehicle subsystem 1108 can include an autonomous vehicle—i.e., a vehicle that does not require a human operator. In these embodiments, thevehicle subsystem 1108 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 1108 may include one or more sensors incorporated therein or associated thereto. For example, sensor(s) can be mounted on the top of thevehicle subsystem 1108 or else can be located within the interior of thevehicle subsystem 1108. In certain embodiments, the sensor(s) can be located in multiple areas at once— i.e., split up throughout thevehicle subsystem 1108 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 1108 may include a communication device capable of communicating with theclient device 1106 and/or thetransportation matching system 114. For example, thevehicle subsystem 1108 can include an on-board computing device communicatively linked to thenetwork 1104 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 example 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 to one another or in parallel to 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 (20)
1. A computer-implemented method comprising:
monitoring, by one or more servers of a transportation matching system, historical metrics from a plurality of requester computing devices and a plurality of provider computing devices via a communications network;
generating, by the one or more servers and based on the historical metrics:
forecasted numbers of requester computing devices across time periods, and
projected earnings metrics for provider computing devices across the time periods;
generating, by the one or more servers and based on the forecasted numbers of requester computing devices and the projected earnings metrics, combined earnings-ridership metrics for the time periods; and
providing, for display to a user interface of a provider computing device, a provider device incentive graph comprising the combined earnings-ridership metrics for the time periods.
2. The computer-implemented method of claim 1 , wherein generating the forecasted numbers of requester computing devices and the projected earnings metrics comprises utilizing one or more machine learning models to generate the forecasted numbers of requester computing devices and the projected earnings metrics based on the historical metrics.
3. The computer-implemented method of claim 1 , further comprising generating the forecasted numbers of requester computing devices across the time periods and the projected earnings metrics across the time periods by generating a first forecasted number of requester computing devices for a first time period and generating a first projected earnings metrics for the first time period.
4. The computer-implemented method of claim 3 , wherein generating the combined earnings-ridership metrics comprises, for a first time period of the time periods combining the first projected earnings metrics with a radical of the first forecasted number of requester computing devices.
5. The computer-implemented method of claim 1 , further comprising:
generating a probability distribution of the combined earnings-ridership metrics;
mapping the combined earnings-ridership metrics to probability ranges based on the probability distribution; and
generating the provider device incentive graph from the probability ranges.
6. The computer-implemented method of claim 5 , further comprising generating the provider device incentive graph by applying a minimum threshold or a maximum threshold to the probability ranges.
7. The computer-implemented method of claim 1 , further comprising generating a suggested provider schedule for the provider computing device based on the combined earnings-ridership metrics.
8. The computer-implemented method of claim 7 , further comprising providing, for display via the user interface of the provider computing device, a scheduling indicator via the provider device incentive graph indicating the suggested provider schedule.
9. A non-transitory computer-readable medium storing instructions that, when executed by at least one processor, cause a computer system to:
monitor historical metrics from a plurality of requester computing devices and a plurality of provider computing devices via a communications network;
generate, based on the historical metrics:
forecasted numbers of requester computing devices across time periods, and
projected earnings metrics for provider computing devices across the time periods;
generate, based on the forecasted numbers of requester computing devices and the projected earnings metrics, combined earnings-ridership metrics for the time periods; and
provide, for display to a user interface of a provider computing device, a provider device incentive graph comprising the combined earnings-ridership metrics for the time periods.
10. The non-transitory computer-readable medium of claim 9 , further comprising instructions that, when executed by at least one processor, cause the computer system to generate the forecasted numbers of requester computing devices and the projected earnings metrics by utilizing one or more machine learning models to generate the forecasted numbers of requester computing devices and the projected earnings metrics based on the historical metrics.
11. The non-transitory computer-readable medium of claim 9 , further comprising instructions that, when executed by at least one processor, cause the computer system to generate the combined earnings-ridership metrics by combining the projected earnings metrics with radicals of the forecasted numbers of requester computing devices.
12. The non-transitory computer-readable medium of claim 9 , further comprising instructions that, when executed by at least one processor, cause the computer system to:
generate a probability distribution of the combined earnings-ridership metrics;
map the combined earnings-ridership metrics to probability ranges based on the probability distribution; and
generate the provider device incentive graph from the probability ranges.
13. The non-transitory computer-readable medium of claim 9 , further comprising instructions that, when executed by at least one processor, cause the computer system to generate a suggested provider schedule for the provider computing device based on the combined earnings-ridership metrics.
14. The non-transitory computer-readable medium of claim 13 , further comprising instructions that, when executed by at least one processor, cause the computer system to provide, for display via the user interface of the provider computing device, a scheduling indicator via the provider device incentive graph indicating the suggested provider schedule.
15. A system comprising:
at least one processor; and
at least one non-transitory computer-readable storage medium storing instructions that, when executed by the at least one processor, cause the system to:
monitor historical metrics from a plurality of requester computing devices and a plurality of provider computing devices via a communications network;
generate, based on the historical metrics:
forecasted numbers of requester computing devices across time periods, and
projected earnings metrics for provider computing devices across the time periods;
generate, based on the forecasted numbers of requester computing devices and the projected earnings metrics, combined earnings-ridership metrics for the time periods; and
provide, for display to a user interface of a provider computing device, a provider device incentive graph comprising the combined earnings-ridership metrics for the time periods.
16. The system of claim 15 , further comprising instructions that, when executed by the at least one processor, cause the system to generate the forecasted numbers of requester computing devices and the projected earnings metrics by utilizing one or more machine learning models to generate the forecasted numbers of requester computing devices and the projected earnings metrics based on the historical metrics.
17. The system of claim 15 , further comprising instructions that, when executed by the at least one processor, cause the system to generate the combined earnings-ridership metrics by combining the projected earnings metrics with radicals of the forecasted numbers of requester computing devices.
18. The system of claim 15 , further comprising instructions that, when executed by the at least one processor, cause the system to:
generate a probability distribution of the combined earnings-ridership metrics;
map the combined earnings-ridership metrics to probability ranges based on the probability distribution; and
generate the provider device incentive graph from the probability ranges.
19. The system of claim 15 , further comprising instructions that, when executed by the at least one processor, cause the system to generate a suggested provider schedule for the provider computing device based on the combined earnings-ridership metrics.
20. The system of claim 19 , further comprising instructions that, when executed by the at least one processor, cause the system to provide, for display via the user interface of the provider computing device, a scheduling indicator via the provider device incentive graph indicating the suggested provider schedule.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US18/157,655 US20230162114A1 (en) | 2019-08-16 | 2023-01-20 | Generating and communicating device balance graphical representations for a dynamic transportation system |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US16/543,368 US11568342B1 (en) | 2019-08-16 | 2019-08-16 | Generating and communicating device balance graphical representations for a dynamic transportation system |
US18/157,655 US20230162114A1 (en) | 2019-08-16 | 2023-01-20 | Generating and communicating device balance graphical representations for a dynamic transportation system |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/543,368 Continuation US11568342B1 (en) | 2019-08-16 | 2019-08-16 | Generating and communicating device balance graphical representations for a dynamic transportation system |
Publications (1)
Publication Number | Publication Date |
---|---|
US20230162114A1 true US20230162114A1 (en) | 2023-05-25 |
Family
ID=85040503
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/543,368 Active US11568342B1 (en) | 2019-08-16 | 2019-08-16 | Generating and communicating device balance graphical representations for a dynamic transportation system |
US18/157,655 Pending US20230162114A1 (en) | 2019-08-16 | 2023-01-20 | Generating and communicating device balance graphical representations for a dynamic transportation system |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/543,368 Active US11568342B1 (en) | 2019-08-16 | 2019-08-16 | Generating and communicating device balance graphical representations for a dynamic transportation system |
Country Status (1)
Country | Link |
---|---|
US (2) | US11568342B1 (en) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11645685B2 (en) * | 2019-06-26 | 2023-05-09 | Lyft, Inc. | Dynamically adjusting transportation provider pool size |
US11568342B1 (en) * | 2019-08-16 | 2023-01-31 | Lyft, Inc. | Generating and communicating device balance graphical representations for a dynamic transportation system |
US20220122212A1 (en) * | 2020-10-21 | 2022-04-21 | Sameh Mosa Kryakos | Rideshare management method, device and mobile application with selectable driver programs |
Citations (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100185486A1 (en) * | 2009-01-21 | 2010-07-22 | Disney Enterprises, Inc. | Determining demand associated with origin-destination pairs for bus ridership forecasting |
US20160129787A1 (en) * | 2014-11-10 | 2016-05-12 | Streetsmart Ltd. | Methods, Circuits, Devices, Systems & Associated Computer Executable Code for Driver Decision Support |
US20180121847A1 (en) * | 2016-11-01 | 2018-05-03 | Uber Technologies, Inc. | Pre-Selection of Drivers in a Passenger Transport System |
US20180322420A1 (en) * | 2017-05-04 | 2018-11-08 | Gt Gettaxi Limited | System and method for reserving drivers with minimum fare offers and navigating drivers to service transportation requests |
US20180342033A1 (en) * | 2017-05-23 | 2018-11-29 | Uber Technologies, Inc. | Trip classification system for on-demand transportation services |
US20190244318A1 (en) * | 2018-02-03 | 2019-08-08 | Driver Partners Inc. | Automation technology for on-demand drivers |
US20200034772A1 (en) * | 2018-07-27 | 2020-01-30 | Rocky Mountain Innovations Insights LLC | Cloud-based, data-driven artificial intelligence and machine learning financial planning and analysis visualization platform |
US20200081436A1 (en) * | 2017-06-02 | 2020-03-12 | Honda Motor Co., Ltd. | Policy generation device and vehicle |
US20200175635A1 (en) * | 2018-03-28 | 2020-06-04 | Beijing Didi Infinity Technology And Development Co., Ltd. | System and method for determining passenger-seeking ride-sourcing vehicle navigation |
US10706487B1 (en) * | 2017-11-11 | 2020-07-07 | Lyft, Inc. | Dynamically generating and updating multipliers for a transportation matching system using machine learning |
US20210233196A1 (en) * | 2018-06-05 | 2021-07-29 | Beijing Didi Infinity Technology And Development Co., Ltd. | System and method for ride order dispatching |
US20220261833A1 (en) * | 2019-06-14 | 2022-08-18 | Beijing Didi Infinity Technology And Development Co., Ltd. | Reinforcement Learning Method For Driver Incentives: Generative Adversarial Network For Driver-System Interactions |
US11568342B1 (en) * | 2019-08-16 | 2023-01-31 | Lyft, Inc. | Generating and communicating device balance graphical representations for a dynamic transportation system |
Family Cites Families (37)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6577304B1 (en) * | 1998-08-14 | 2003-06-10 | I2 Technologies Us, Inc. | System and method for visually representing a supply chain |
US6947905B1 (en) * | 1998-09-18 | 2005-09-20 | I2 Technologies Us, Inc. | System and method for displaying planning information associated with a supply chain |
US7243074B1 (en) * | 1999-12-30 | 2007-07-10 | General Electric Company | Capacity monitoring process for a goods delivery system |
US7313530B2 (en) * | 2001-04-10 | 2007-12-25 | General Electric Company | Methods and systems for generating and displaying the capacity of a delivery management system |
US20030014288A1 (en) * | 2001-07-12 | 2003-01-16 | Lloyd Clarke | System and method for managing transportation demand and capacity |
US20030084125A1 (en) * | 2001-10-31 | 2003-05-01 | Nagda Paresh L. | Integrated information exchange system for matching shipping demands and carrier availability |
US8639551B1 (en) * | 2006-07-31 | 2014-01-28 | Hewlett-Packard Development Company, L.P. | Method and system for workforce related resource planning |
US20080114629A1 (en) * | 2006-11-09 | 2008-05-15 | Yahoo! Inc. | System for matching users and transportation providers |
US7840427B2 (en) * | 2007-02-12 | 2010-11-23 | O'sullivan Sean | Shared transport system and service network |
US20100082410A1 (en) * | 2008-09-29 | 2010-04-01 | Catherine Baudin | Method and apparatus for a data processing system |
US8108248B2 (en) * | 2009-03-06 | 2012-01-31 | Microsoft Corporation | Market design for a resource exchange system |
US9378511B2 (en) * | 2009-07-15 | 2016-06-28 | International Business Machines Corporation | Real-time appointment of enterprise mobile agents in response to customer requests |
US9424515B2 (en) * | 2011-12-05 | 2016-08-23 | FasterFare, LLC | Predicting taxi utilization information |
US20150242944A1 (en) * | 2013-09-20 | 2015-08-27 | Eugene S. Willard | Time dependent inventory asset management system for industries having perishable assets |
KR101994631B1 (en) * | 2014-04-24 | 2019-09-30 | 베이징 디디 인피니티 테크놀로지 앤드 디벨럽먼트 컴퍼니 리미티드 | System and method for managing supply of service |
WO2016035091A1 (en) * | 2014-09-03 | 2016-03-10 | Meru Cab Company Private Limited | Dynamic forecasting for forward reservation of cab |
US20170193625A1 (en) * | 2015-12-21 | 2017-07-06 | Lyft, Inc. | Driver supply control |
CN107153882B (en) * | 2016-03-03 | 2021-10-15 | 北京嘀嘀无限科技发展有限公司 | Method and system for predicting passenger taxi taking time distribution interval |
US11049124B2 (en) * | 2016-04-07 | 2021-06-29 | Lyft, Inc. | System and method for navigating drivers to service transportation requests having surge pricing multipliers and surge pricing caps |
US10460411B2 (en) * | 2016-08-30 | 2019-10-29 | Uber Technologies, Inc. | Real-time resource management for on-demand services |
US10636108B2 (en) * | 2016-09-30 | 2020-04-28 | Lyft, Inc. | Identifying matched requestors and providers |
US20180101878A1 (en) * | 2016-10-11 | 2018-04-12 | Gt Gettaxi Limited | System for navigating drivers to passengers based on arrival times and surge pricing information |
US20180137594A1 (en) * | 2016-11-17 | 2018-05-17 | Gt Gettaxi Limited | System and method for reserving drivers for a transportation service and navigating drivers to service transportation requests |
US20180314998A1 (en) * | 2017-04-26 | 2018-11-01 | Uber Technologies, Inc. | Resource Allocation in a Network System |
JP6810786B2 (en) * | 2017-02-27 | 2021-01-06 | 株式会社Nttドコモ | Demand forecaster |
US20180315148A1 (en) * | 2017-04-28 | 2018-11-01 | Lyft, Inc. | Dynamic optimized reassignment of providers at a geohash level |
WO2018228110A1 (en) * | 2017-06-14 | 2018-12-20 | Beijing Didi Infinity Technology And Development Co., Ltd. | Systems and methods for transport capacity scheduling |
AU2018102228A4 (en) * | 2017-06-28 | 2021-11-18 | Beijing Didi Infinity Technology And Development Co., Ltd. | Artificial intelligent systems and methods for presenting prompting message on mobile device |
US11300416B2 (en) * | 2017-11-22 | 2022-04-12 | Uber Technologies, Inc. | Dynamic route recommendation and progress monitoring for service providers |
US11704608B2 (en) * | 2017-12-29 | 2023-07-18 | Lyft, Inc. | Session-based transportation dispatch |
WO2019154398A1 (en) * | 2018-02-06 | 2019-08-15 | Beijing Didi Infinity Technology And Development Co., Ltd. | Systems and methods for recommending transportation services |
US20190311453A1 (en) * | 2018-04-10 | 2019-10-10 | Massachusetts lnstitute of Technology | System and Method for Between-Ride Routing for Transportation Providers |
US20200005198A1 (en) * | 2018-05-22 | 2020-01-02 | Uber Technologies, Inc. | Network computer system to implement additive service values for service providers |
US20200226694A1 (en) * | 2019-01-16 | 2020-07-16 | Microsoft Technology Licensing, Llc | Reducing supply-demand gap |
US11681955B2 (en) * | 2019-02-28 | 2023-06-20 | Lyft, Inc. | Systems and methods for immediate matching of requestor devices to provider devices |
US20200286106A1 (en) * | 2019-03-04 | 2020-09-10 | Lyft, Inc. | Optimization of on-demand transportation systems |
US20200356927A1 (en) * | 2019-05-06 | 2020-11-12 | Lyft, Inc. | Balancing acquisition and engagement for transportation providers and transportation requesters over multiple time horizons |
-
2019
- 2019-08-16 US US16/543,368 patent/US11568342B1/en active Active
-
2023
- 2023-01-20 US US18/157,655 patent/US20230162114A1/en active Pending
Patent Citations (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100185486A1 (en) * | 2009-01-21 | 2010-07-22 | Disney Enterprises, Inc. | Determining demand associated with origin-destination pairs for bus ridership forecasting |
US20160129787A1 (en) * | 2014-11-10 | 2016-05-12 | Streetsmart Ltd. | Methods, Circuits, Devices, Systems & Associated Computer Executable Code for Driver Decision Support |
US9776512B2 (en) * | 2014-11-10 | 2017-10-03 | Streetsmart Ltd. | Methods, circuits, devices, systems and associated computer executable code for driver decision support |
US20180121847A1 (en) * | 2016-11-01 | 2018-05-03 | Uber Technologies, Inc. | Pre-Selection of Drivers in a Passenger Transport System |
US20180322420A1 (en) * | 2017-05-04 | 2018-11-08 | Gt Gettaxi Limited | System and method for reserving drivers with minimum fare offers and navigating drivers to service transportation requests |
US20180342033A1 (en) * | 2017-05-23 | 2018-11-29 | Uber Technologies, Inc. | Trip classification system for on-demand transportation services |
US20200081436A1 (en) * | 2017-06-02 | 2020-03-12 | Honda Motor Co., Ltd. | Policy generation device and vehicle |
US10706487B1 (en) * | 2017-11-11 | 2020-07-07 | Lyft, Inc. | Dynamically generating and updating multipliers for a transportation matching system using machine learning |
US20190244318A1 (en) * | 2018-02-03 | 2019-08-08 | Driver Partners Inc. | Automation technology for on-demand drivers |
US20200175635A1 (en) * | 2018-03-28 | 2020-06-04 | Beijing Didi Infinity Technology And Development Co., Ltd. | System and method for determining passenger-seeking ride-sourcing vehicle navigation |
US20210233196A1 (en) * | 2018-06-05 | 2021-07-29 | Beijing Didi Infinity Technology And Development Co., Ltd. | System and method for ride order dispatching |
US20200034772A1 (en) * | 2018-07-27 | 2020-01-30 | Rocky Mountain Innovations Insights LLC | Cloud-based, data-driven artificial intelligence and machine learning financial planning and analysis visualization platform |
US20220261833A1 (en) * | 2019-06-14 | 2022-08-18 | Beijing Didi Infinity Technology And Development Co., Ltd. | Reinforcement Learning Method For Driver Incentives: Generative Adversarial Network For Driver-System Interactions |
US11568342B1 (en) * | 2019-08-16 | 2023-01-31 | Lyft, Inc. | Generating and communicating device balance graphical representations for a dynamic transportation system |
Non-Patent Citations (8)
Title |
---|
Chaudhari, Harshal et al, Putting Data in the Driver's Seat: Optimizing Earnings for On-Demand Ride-Hailing ACM, WSDM;18; February 2018 (Year: 2018) * |
SherpaShare Member Success Manual SherpaShare, 2018, Retrieved from Archive.org January 18, 2024 (Year: 2018) * |
SherpaShare.com - web pages SherpaShare, June 2015, Retrieved from Archive.org January 18, 2024 (Year: 2015) * |
Singer, Natasha et al., An App That Helps Drivers Earn the Most From Their Trips The New York Times, May 9, 2015 (Year: 2015) * |
Singer, Natasha et al., Helping drivers run the numbers: Analytics service shows Uber and Lyft workers how to increase earnings The New York Times, May 11, 2015 (Year: 2015) * |
TaraC, A Lyft Driver Uses Linear Regression to Predict Their Next Fair Amount Alteryx Community, August 16, 2018 (Year: 2018) * |
Uber Driver Fare Calculator RideShare Drivers United, RideShareDriversUnited.com 2018 (Year: 2018) * |
Zhou, Ivan, Uber Driver Schedule Optimization Towards Data Science, January 20, 2018 (Year: 2018) * |
Also Published As
Publication number | Publication date |
---|---|
US11568342B1 (en) | 2023-01-31 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11763411B1 (en) | Dynamically generating and updating multipliers for a transportation matching system using machine learning | |
US20230162114A1 (en) | Generating and communicating device balance graphical representations for a dynamic transportation system | |
US11310331B2 (en) | Optimizing user interface data caching for future actions | |
US11494714B2 (en) | Efficiency of a transportation matching system using geocoded provider models | |
US11868929B2 (en) | Optimizing engagement of transportation providers | |
US20240127697A1 (en) | Using a predictive request model to optimize provider resources | |
US20200286106A1 (en) | Optimization of on-demand transportation systems | |
US20160125083A1 (en) | Information sensors for sensing web dynamics | |
US10970338B2 (en) | Performing query-time attribution channel modeling | |
US20200082315A1 (en) | Efficiency of a transportation matching system using geocoded provider models | |
US20200082314A1 (en) | Efficiency of a transportation matching system using geocoded provider models | |
US20200082313A1 (en) | Efficiency of a transportation matching system using geocoded provider models | |
US20220101473A1 (en) | Providing dynamic alternate location transportation modes and user interfaces within multi-pickup-location area geofences | |
US20200356927A1 (en) | Balancing acquisition and engagement for transportation providers and transportation requesters over multiple time horizons | |
US20220084155A1 (en) | Providing interfaces with scheduled transportation options to intelligently generate transportation groups | |
US20210256576A1 (en) | Utilizing a directional filter for a geotemporal destination mode of a dynamic transportation matching system | |
US20220076170A1 (en) | Utilizing provider device efficiency metrics to select a provider device for a future time window | |
US20220164912A1 (en) | Dynamically adjusting a pool of transportation provider devices in a prioritized-dispatch mode using availability indicators | |
US11530927B2 (en) | Customizing user interface experiences for requesters of transportation services | |
US20210035252A1 (en) | Determining disutility of shared transportation requests for a transportation matching system | |
US20230076582A1 (en) | Transmitting digital transportation requests across modes to limited-eligibility provider devices to improve network coverage and system efficiency | |
US20170132542A1 (en) | Predictive and corrective reporting of venue operating hours | |
US20210295224A1 (en) | Utilizing a requestor device forecasting model with forward and backward looking queue filters to pre-dispatch provider devices | |
US20230068492A1 (en) | Generating user interfaces comprising dynamic accordion-based transportation user interface elements to improve computer system efficiency | |
US20230196492A1 (en) | Generating network coverage improvement metrics utilizing machine-learning to dynamically match transportation requests |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: LYFT, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FREMLIN, JOHN TORRES;LIU, YUNSHU;SIGNING DATES FROM 20190828 TO 20191007;REEL/FRAME:062443/0393 |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |