NETWORK SYSTEM

TECHNICAL FIELD

[0001] The subject matter described herein generally relates to the field of network systems, and, more particularly, to optimizing resource allocation among different regions.

BACKGROUND

[0002] Network systems, such as transport management systems, provide support for the logistical issues in managing the transportation of persons, cargo, or the like. In some systems, a provider provides transportation services to a user to a location selected by the user in exchange for a fee. In typical systems, a user checking a price or fare or requesting service is matched with one of a plurality of available providers. Typically, the provider with whom the user is matched is the provider who has the shortest estimated time of arrival to the user's pickup location or the origin location. This may lead to inefficient allocation of resources, particularly in instances where there is high user demand concentrated in a geographic region ("geo"). For example, vehicles located in geos of low demand may be sitting idle, polluting the air and crowding the street instead of providing service in nearby regions with lower provider supply and higher user demand.

SUMMARY

[0003] To enable a more efficient allocation of resources among different geos and a higher rate of user conversion, a network system uses global optimization across geos to calculate and provide multiple service options to users that may want to request services (e.g., transport or delivery services, also referred to as a trip) through a user application. In one embodiment, the network system provides multiple service options each time that a user transmits a set of service data indicating an interest in potentially requesting service facilitated by the network system (regardless of predicted demand). In other embodiments, the network system provides multiple service options responsive to predicting a period of high user demand or predicting that user demand will be greater than a threshold amount or volume. A demand prediction module predicts upcoming demand for services within a specified vicinity or geography and during a time period.

[0004] According to an example, a trip management module receives, through a user application, user input including a set of service data. In one embodiment, the service data includes at least an origin location, a destination location, a desired departure time, and/or a request for an estimated value. In one embodiment, in response to predicting that user demand will be greater than a threshold volume at these origin locations, the demand prediction module instructs an option selection module (also called a geo selection module) to request pricing information (e.g., price multiplier data) for geographic regions within a threshold distance of the origin location or the origin geographic region of the user. The option selection module uses the price multiplier data to select geographic regions for inclusion in a set of service options (also called trip options) that can be presented to the user via the user application. In another embodiment, in response to receiving the service data, the option selection module selects geos within a threshold distance of the origin location or the origin geo of the user for inclusion in a set of service options that can be presented to the user via the user application.

[0005] In some examples, the option selection module queries a provider inventory data store for available providers located in the selected geographic regions and selects candidate providers based in part on user input regarding order time (e.g., time when the service is desired). In some embodiments, the option selection module determines the threshold distance based in part on the desired departure time. For example, if the desired departure time is in 30 minutes, the option selection module might include geos 1, 2, and 3, but if the desired departure time is in 35 minutes, the option selection might also include geo 4 when determining the set of service options to be presented to the user. The option selection module then queries a geo data store for pricing information (e.g., price multiplier data) for the selected geos and sends the received data to an option selection module for selection of the service options.

[0006] In one embodiment, for each of the selected geographic regions, the option selection module selects the provider with the shortest estimated time of pickup (ETP) to the origin location or the shortest estimated time to destination (ETD) to the destination location (e.g., a total time of estimated time of pickup to the origin location from the provider location and estimated time of travel from the origin location to the destination location).

Alternatively, for each of the selected geographic regions, the option selection module determines the ETP for a set of providers in that geographic region (e.g., the shortest ETP or average ETP of the set of providers). In another embodiment, if the option selection module determines that the ETP to the origin location is the same for multiple providers in the different geographic regions, the option selection module selects the provider located in the region with the lowest price multiplier. While examples herein describe selections based on ETP for purposes of simplicity, in other examples, the selections can be based on ETD.

[0007] Still further, in one example, the option selection module selects service options to present through the user application to optimize the matching of users and providers across geos. In one embodiment, the option selection module receives as input a number of market status factors in selecting the service options, including the origin and destination locations, the desired departure time, the current user demand for service, predictions of future demand, number and location of available providers, and/or pricing information in geos within a threshold distance of the origin location or the origin geo of the user. Additionally, the market status factors may include, for each of the available providers located within a threshold distance of the origin location or the origin geo of the user, the distance and estimated time from the provider's current location to the origin location.

[0008] After selecting service options to present to the user, the option selection module queries a trip price estimation module to obtain trip estimate values (e.g., estimated prices or costs). The trip price estimation module calculates or computes an estimated value (e.g., estimated trip cost) for each of the selected service options and sends the estimate values to the option selection module for display on the user client device. The estimated value can be based on an estimated distance to be traveled along a predicted or proposed route(s), and/or estimated duration of time of travel. In some embodiments, the service options and associated estimates are pushed to the user client device if the user subscribes to a real-time information push. In other embodiments, the service options and associated estimates are displayed on the user client device responsive to the user checking prices or requesting a service or through the user application.

[0009] In response to a user selecting a service option via the user application, the user application can generate data corresponding to a request for a service through the network system (e.g., also referred to herein as a "trip request"). In some embodiments, the network system uses information from the trip request to match the user with one of a plurality of available drivers based on the market status factors.

[0010] The network system also uses the information from trip requests to predict future demand across geos and time periods and to position providers based on predicted demand. In some embodiments, a demand prediction module generates and trains an optimization model to predict user demand over upcoming time periods using stored data including historical trip data and data regarding service options presented to and selected by users. The trained optimization model is used to position providers across and within geos to optimize the number of trip requests that the network system is able to fulfill and improve the performance of the network system by reducing inefficiencies and providing additional benefits such as a reduction in pollution and wasted energy

BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1 illustrates the system environment for an example network system, in accordance with an embodiment.

[0012] FIG. 2 is an interaction diagram for optimizing resource allocation based on demand prediction, in accordance with a first embodiment.

[0013] FIG. 3 is an interaction diagram for optimizing resource allocation based on demand prediction, in accordance with a second embodiment.

[0014] FIG. 4 illustrates an example map depicting price multipliers and available providers in different geos, in accordance with an embodiment.

[0015] FIG. 5 illustrates an example map depicting a service that is assigned to a provider and in which the provider is traveling from the provider's current location to an origin location, in accordance with an embodiment.

[0016] FIG. 6 is an example user interface on a user application for displaying alternative service options, in accordance with an embodiment.

[0017] FIG. 7 is an example user interface on a provider application for displaying alternative service options, in accordance with an embodiment.

[0018] FIG. 8 illustrates example components of a computer used as part or all of the network system, the user client device, and/or the provider client device, in accordance with an embodiment.

[0019] FIG. 9 is a flow chart illustrating the selection of alternative service options based on market status factors, in accordance with an embodiment.

DETAILED DESCRIPTION

[0020] The Figures and the following description describe certain embodiments by way of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein. Reference will now be made to several embodiments, examples of which are illustrated in the accompanying figures. It is noted that wherever practicable similar or like reference numbers may be used in the figures and may indicate similar or like functionality. [0021] Turning now to the specifics of the system architecture, FIG. 1 illustrates a system environment for an example network system 130. The network system 130 coordinates the transportation of persons and/or goods/items for a user (e.g., such as a rider) by a service provider (e.g., a provider of a vehicle). The provider uses a vehicle to provide the transportation to the user. In this example embodiment, the network system 130 includes a trip management module 140, a trip monitoring module 145, a geo monitoring module 150, a demand prediction module 155, a geo or option selection module 160, a trip price estimation module 165, and various data stores including a trip data store 180, a user data store 182, a provider data store 184, a provider inventory data store 186, and a geo data store 188. These modules and data stores are not native components of a generic computer system, and provide structures and functions beyond generic functions of a computer system, as further described below.

[0022] A user operates a client device 100 that executes a user application 102 that communicates with the network system 130. The user operates the user application 102 to view information about the network system 130, and to make a request for service from the network system 130 for a delivery or transport service ("a trip") of the user (and, optionally, additional persons) and/or items, for example cargo needing transport. The user application 102 determines an origin location or enables the user to specify an origin location and/or a destination location associated with the trip. An origin location and/or a destination location may be a location inputted by the user or may correspond to the current location of the user client device 100 as determined automatically by a location determination module (not shown) in the user client device 100, e.g., a global positioning system (GPS) component, a wireless networking system, or a combination thereof. For purposes of simplicity, as described herein, an origin location can correspond to a start location for service (i) determined by the user application 102 (e.g., based on the current location of the user client device 100 using a GPS component), (ii) specified or selected by the user, or (iii) determined by the network system 130.

[0023] According to examples herein, the user client device 100 can transmit a set of data (e.g., referred to herein as "service data") to the network system 130 over the network(s) 120 in response to user input or operation of the user application 102. Such service data can be indicative of the user's interest in potentially requesting service (e.g., before actually confirming or requesting the service). For example, the user may launch the user application 102 and specify an origin location and/or a destination location to view information about the network service before making a decision on whether to request service. In some embodiments, the user operates the user application 102 in a default mode in which the user application 102 presents a single service option in response to receiving the service data. In other embodiments, the user application 102 provides a feature to enable the user to operate the user application 102 in an option-spectrum feature mode in which the user application 102 presents various service options in response to receiving service data from the user.

[0024] The user may want to view information about the average or estimated time of arrival for pick up by a provider, the estimated time to the destination, the price, the available service types, etc. Depending on implementation, the service data can include the origin and/or destination location information, user information (e.g., identifier), application information (e.g., version number), device identifier or type, etc. According to some examples, each time the user modifies the origin and/or destination location, the user application 102 can generate and transmit the service data to the network system 130. Still further, in one example, the service data can include data used by the demand prediction module 155 to predict user demand in geos. In some embodiments, the service data comprises a request for an estimated cost or price (or fare) for the service and includes at least the origin location and the destination location specified by the user. Additionally, in one example, in response to transmitting the service data, the user application 102 can receive a set of service options from the network system 130 to be displayed on the user client device 100.

[0025] Once the user confirms or orders a service via the user application 102, the user application 102 can generate data corresponding to a request for the service through the network system 130 (e.g., also referred to herein as a "trip request"). In some embodiments, the network system 130 uses information from the trip request to match the user with one of a plurality of available providers. Depending on implementation, the trip request can include user or device information (e.g., a user identifier, a device identifier), a service type (e.g., vehicle type) and/or selected service option (such as described herein), an origin location, a destination location, a payment profile identifier, and/or other data. The network system 130 selects a provider from a set of providers, such as based on the provider's current location and status (e.g., offline, online, available, etc.) and/or information from the trip request (e.g., service type, origin location, and/or destination location), to provide the service for the user and transport the user from the origin location to the destination location. In other embodiments, responsive to predicting that user demand will be over a threshold volume in a given geographic region, the network system 130 provides multiple service options to the user, as discussed below. The user application 102 further enables a user to provide a performance rating for a provider upon completion of a trip. In one embodiment, the rating is provided on a scale of one to five, five being the maximal (best) rating. In an alternative embodiment, the rating is a thumbs up or thumbs down rating indicating either a positive or negative experience.

[0026] The provider operates a client device 110 executing a provider application 104 that communicates with the network system 130 to provide information indicating whether the provider is available or unavailable to provide transportation services to users. The provider application 104 can also present information about the network service to the provider, such as invitations to provide service, navigation instructions, map data, etc. In one embodiment, the provider application 104 enables the provider to provide information regarding availability of the provider by logging into the network system 130 and activating a setting indicating that they are currently available to provide service. The provider application 104 also provides the current location of the provider or the provider client device 110 to the network system 130. Depending on implementation, the current location may be a location inputted by the provider or may correspond to the current location of the provider client device 110 as determined automatically by a location determination module (not shown) in the provider client device 110, e.g., a GPS component, a wireless networking system, or a combination thereof. The provider application 104 further allows a provider to receive, from the trip management module 140, an invitation message to provide a service for a requesting user, and if the provider accepts via input, the provider application 104 can transmit an acceptance message to the trip management module 140. The trip management module 140 can subsequently provide information about the provider to the user application 102. As another embodiment, the provider application 104 can enable the provider to view a list or spectrum of current service options corresponding to received trip requests and to select particular trip request(s) to fulfill. The trip management module 140 selects service options for display to the provider based on predicted demand over a specified time period within a threshold distance of the provider's current location or geo, as discussed below with respect to FIG. 7.

[0027] In some embodiments, the service options presented through the provider application 104 include a guaranteed price multiplier (and thus a higher total trip price) if the provider accepts and fulfills a trip request during an upcoming period of predicted high demand. For example, a service option might include a guaranteed 1.8 price multiplier if the provider accepts and fulfills a trip request from geo 1 between 5:00 and 6:00 pm on a particular Saturday. In some embodiments, the provider incurs a financial penalty if the provider accepts a service, but does not fulfill the corresponding trip request (e.g., subsequently cancels). Additionally or alternatively, the pricing of a provider service option might change over time as the desired departure time approaches. For example, the demand prediction module 155 might predict on Thursday morning a period of high user demand the following evening between 7:00 and 8:00 pm. A provider who commits on Thursday to accepting and fulfilling trip requests during this time period might receive a higher guaranteed price multiplier than a provider who commits on Friday afternoon.

[0028] The provider application 104 can also receive routing information from the trip management module 140. The provider application 104 enables a provider to provide a rating for a user upon completion of a trip. In one embodiment, the rating is provided on a scale of one to five, five being the maximal (best) rating.

[0029] The user client device 100 and provider client device 110 are portable electronic devices such as smartphones, tablet devices, wearable computing devices (e.g.,

smartwatches) or similar devices. Alternatively, the provider client device 110 can correspond to an on-board computing system of a vehicle. Client devices typically have one or more processors, memory, touch screen displays, wireless networking system (e.g., IEEE 802.11), cellular telephony support (e.g., LTE/ GSM/UMT S/ CDM A/HSDP A, etc.), and location determination capabilities.

[0030] The user client device 100 and the provider client device 110 interact with the network system 130 through client applications configured to interact with the network system 130. The applications 102 and 104 of the user client device 100 and the provider client device 110, respectively, can present information received from the network system 130 on a user interface, such as a map of the geo, and the current location of the user client device 100 or the provider client device 110. The applications 102 and 104 running on the user client device 100 and the provider client device 110 can determine the current location of the device and provide the current location to the network system 130.

[0031] In one embodiment, the trip management module 140 can be configured as a communicative interface between the user application 102, the provider application 104, and/or the various modules and data stores in the network system 130, and is one means for performing this function. The trip management module 140 can receive provider availability status information and current location information from the provider application 104 and update the provider inventory data store 186 with the availability status. The trip

management module 140 can also receive trip requests from the user application 102 and creates corresponding trip records in the trip data store 180. According to an example, a trip record corresponding to a trip request can include or be associated with a trip ID, a user ID, an origin location, a destination location, a service type, pricing information, and/or a status indicating that the corresponding trip request has not been processed. According to one example, when a provider accepts the invitation message to service the trip request for the user, the trip record can be updated with the provider's information as well as the provider's location and the time when the trip request was accepted. Similarly, location and time information about the service as well as the cost for the service can be associated with the trip record.

[0032] The trip management module 140 can also send an invitation message to an available provider via the provider client device 110 responsive to receiving user input comprising selection of a service option, and receives a response to the invitation message from the provider through the provider application 104. In one example, the trip management module 140 can also send information to the provider client device 110 at a particular time based on estimated travel times computed by the option selection module 160. In one embodiment, the trip management module 140 optimizes resource redistribution by computing the time it takes for a provider to initiate the service for a user based on an estimated travel time and/or distance from the provider's current location to the origin location and the requested departure time of the trip. For example, if the estimated travel time to the origin location is ten minutes and the requested departure time is in twenty minutes, the trip management module 140 can select a provider from the geo associated with the selected service option and transmit the invitation message to the selected provider in ten minutes.

[0033] In some embodiments, the provider's current location is in a different geographic region than the origin location. The trip management module 140 can transmit provider incentives to the provider application 104 to incentivize the provider to travel from the provider's current location towards a geo nearby or a geo of the origin location. For example, the provider is paid to travel from the provider's current location to the origin location even before the provider is selected to provide a service. The trip management module 140 can display the payment as a standalone incentive or as a component of the provider's income from a specific trip.

[0034] In one embodiment, during the trip, the trip monitoring module 145 receives information (e.g., periodically) from the provider application 104 indicating the location of the provider's vehicle and/or telematics information (e.g., indications of current speed, acceleration/deceleration, events, stops, and so forth). The trip monitoring module 145 stores the information in the trip data store 180 and can associate the information with the trip record.

[0035] The geo monitoring module 150 determines price multipliers in specified geos as determined by the network system 130, and sends the price multiplier data to the geo data store 188 for storage. Depending on implementation, a geo can be one of many geos that can be user-defined regions, overlapping regions, regions of different sizes or dimensions, and/or regions defined by a coordinate system or array of shapes (e.g., squares, hexagons, etc.). In one example, a geo can be a smaller geo or sub-geo of a larger geo. Each geo can have an identifier, be defined by a set of location data points or coordinates, and/or be associated with additional geos (e.g., with nearby geos or overlapping geos, etc.). For purposes of the description, in various embodiments, a price multiplier is a scaling modifier based on resource supply and user demand that is applied to an initial or default trip price to determine a final trip price. For example, the geo monitoring module 150 determines a price multiplier for a geo by querying the trip data store 180 for the number of trips requested with an origin location in the geo and by querying the provider inventory data store 186 for the number of available providers located in a geo (e.g., based on location and provider state). As an addition or an alternative, in another example, the geo monitoring module 150 can determine the price multiplier for a geo based on the number of users that are operating the user application 102 but have not yet requested service in the geo. The geo monitoring module 150 can update the price multiplier for a geo periodically (e.g., perform the computation every three minutes or five minutes, etc.) or based on a schedule.

[0036] According to an example, the geo monitoring module 150 computes the price multiplier for a geo based, at least in part, on the number of requested trips that originated in the geo, the number of users operating the client application 102 in the geo, and/or the number of available providers located in the geo. In one example, the geo monitoring module 150 can determine a ratio of requested trips and available providers, and if the ratio of requested trips to available providers is over a threshold, the geo monitoring module 150 computes a price multiplier based on the ratio and applies it to the geo. In some

embodiments, the geo monitoring module 150 applies progressively higher price multipliers as the ratio of trip requests to available providers increases.

[0037] In some examples, the demand prediction module 155 predicts the volume and timing of an upcoming demand peak at or near the vicinity of an origin location. In one embodiment, the demand prediction module 155 predicts volume and timing responsive to the trip management module 140 detecting that user interest or demand will be over a threshold volume. User interest in a geo can be determined by determining the number of users who operate the user application 102 and/or specify service data having an origin location in the geo or set of adjacent or nearby geos during a time period. In another embodiment, the demand prediction module 155 predicts volume and timing based on the number of trip arrivals at the origin location or near the origin location within a specified time period. For example, the demand prediction module 155 can predict user demand at the end of a baseball game based on the arrival volume at the stadium at a time period before the beginning of the game. In other embodiments, the demand prediction module 155 considers both trip arrivals and the number of trip requests when predicting the volume and timing of an upcoming demand peak.

[0038] In some embodiments, the demand prediction module 155 generates data regarding the volume and timing of future demand based on future trip requests— that is, requests for trips where the requestor is not seeking to be picked up at the time the request is being made. The demand prediction module 155 generates data regarding trip origins, trip destinations, trip timing, and/or trip length, and uses the data to forecast future demand for trips and the need to provide supply to meet that demand. In some embodiments, the demand prediction module 155 sends the data to the geo monitoring module 150, which uses the data to estimate future prices.

[0039] In some embodiments, the demand prediction module 155 considers periodic and non-periodic events when gauging user interest. For example, if the trip management module 140 receives service data from a number of user client devices 100 (e.g., detects a number of users viewing the service information or indicating an intent to request service) and determines that the user client devices 100 are located at or within a baseball stadium or in a geo that the baseball stadium is located in, the trip management module 140 will instruct the demand prediction module 155 to a monitor a feed of the current score and/or estimated time remaining in the game to predict when the demand is likely to be high. The effect of different scores at different times in a game can then be correlated with demand (e.g., demand is low before the end of a tight game because spectators want to stay, but higher if the game is a blow-out with many fans leaving early to beat the rush).

[0040] In one embodiment, the demand prediction module 155 employs a machine learning module to improve predictions of demand over time. In response to receiving user input comprising a request for information from the network system 130, the trip

management module 140 sends an instruction to an option selection module 160 to select geos and available providers for inclusion as service options to present to the user. In various embodiments, for each set of received service data, the option selection module 160 selects multiple geos for inclusion as service options, such that each geo serves and is served by multiple other geos.

[0041] The option selection module 160 selects service options based on global optimization across geos within a threshold distance of the origin location or the origin geo of the user. In some embodiments, the option selection module 160 determines the threshold distance based on the desired departure time. For example, if the desired departure time is in 30 minutes, the option selection module 160 might include geos 1, 2, and 3, but if the desired departure time is in 35 minutes, the option selection module 160 might also include geo 4 when determining the set of service options to be presented to the user.

[0042] The option selection module 160 uses a number of market status factors in selecting service options, including the origin and destination locations, the desired departure time, the current demand for user service, predictions of future demand calculated by the demand prediction module 155, the number and location of available providers, and/or pricing information in geos within a threshold distance of the origin location or the origin geo of the user. In some embodiments, the market status factors also include, for each of the available providers located with a threshold distance of the origin location or the origin geo of the user, the distance and estimated time from the provider's current location to the origin location.

[0043] After any given time period, the estimated demand for that period is compared to the actual demand (i.e., how many trips were actually requested). The difference between the predicted and actual demand can correspond to an error margin that is inputted into the model. If the predicted demand is less than the actual demand, the model is adjusted such that future predictions of demand for similar time periods are larger. Conversely, if the predicted demand exceeded the actual demand, future predictions will be lower. Thus, the model is improved over time to more accurately predict the true demand. The model can also respond dynamically to changes in demand pattern.

[0044] To select service options to present to the user, the option selection module 160 uses the market status factors to select geos and available providers. For example, in response to predicting that a period of user demand in a geo will be over a threshold volume, the demand prediction module 155 sends an instruction to the option selection module 160 to query the geo data store 188 for the price multipliers of geos that are within a threshold distance of the origin location or the geo of the origin location (e.g., within a predefined distance, such as one mile or two miles away from the origin location or the geo of the origin location, or within a predefined number of adjacent geos, such as two or three geos away from the origin location or the geo of the origin location). After receiving the requested data about these nearby geos from the geo data store 188, the option selection module 160 analyzes the data and selects a set of geos for inclusion in the spectrum (or a set or list) of service options that will be presented to the user. In one embodiment, the option selection module 160 selects all nearby geos. In another embodiment, the option selection module 160 selects the geo of the origin location and all adjacent geos. In still other embodiments, the option selection module 160 selects geos with varying price multipliers or modifiers. For example, the option selection module 160 might select geos with price multipliers of l .Ox, 2.5x, and 3. Ox, respectively. In the various embodiments, the option selection module 160 considers the current (or alternatively, the forecasted) ratio of supply and demand and the applicable price modifiers in nearby geos when selecting geos for inclusion in the set of service options. For example, if the option selection module 160 determines that there is high demand for service relative to the number of available providers in geo 3 and that the ratio is lower in other nearby geos, the option selection module 160 might include fewer or no service options from geo 3 in response to receiving a set of service data with an origin location in geo 1. In some embodiments, the option selection module 160 also queries the demand prediction module 155 for the predicted user demand in the selected geos within a threshold amount of time of the desired departure time.

[0045] The option selection module 160 also queries the provider inventory data store 186 for a list of available providers in the selected geos, including the locations of the available providers in the geos. For each selected geo, the option selection module 160 calculates the average distance and/or estimated time from the current locations of available providers to the origin location. In response to receiving the data regarding these candidate providers from the provider inventory data store 186, the option selection module 160 selects the available rides for inclusion in the spectrum of service options presented on the user client device 100 based on user input regarding order time. For example, if the user is checking service options and costs with an order time of "now," the option selection module 160 will select different service options than if the user selected an order time of "20 minutes from now."

[0046] In some embodiments, the option selection module 160 also queries the trip data store 180 for trip data associated with trip requests made by other users of the network system 130 within a threshold amount of time of the user's trip request. Additionally or

alternatively, the option selection module 160 queries the trip data store 180 for trip data associated with trip requests with origin locations within a threshold distance of the origin location or the origin geo of the user. In some embodiments, the trip data includes the origin locations, destination locations, route information, desired departure times, and/or user- provider matching information associated with the trip requests.

[0047] According to an example, after receiving the requested data from the geo data store 188, the provider inventory data store 186, the demand prediction module 155, and the trip data store 180, the option selection module 160 selects service options to present to the user. In one embodiment, for each of the selected geos, the option selection module 160 selects candidate providers for inclusion as service options. In some embodiments, the candidate provider is a representation of available providers located within a threshold distance of each other in a selected geo. For example, if provider A, provider B, and provider C are all available to provide service and are located within two blocks of each other in geo 1, the option selection module 160 treats the three providers as a single "candidate provider" for purposes of selecting service options to present to the user.

[0048] In some embodiments, for each of the selected geos, the option selection module 160 selects the candidate provider with the shortest estimated time of pickup (ETP) at the origin location responsive to a user requesting an order time or a desired departure time of "now." For example, assume that the option selection module 160 selects geo 3 for inclusion in the spectrum of service options presented to a user located in geo 1. If the provider inventory data store reports that, in geo 3, candidate provider 1 (representing providers A, B, and C) is approximately 4 minutes away from the origin location, candidate provider 2 (representing providers D, E, F, G, and H) is approximately 7 minutes away from the origin location, and candidate provider 3 (representing providers I and J) is approximately 10 minutes away from the origin location, the option selection module 160 will select candidate provider A for inclusion as a service option. In some embodiments, the option selection module 160 will also include provider B and/or provider C as service options if the option selection module 160 determines that there is limited provider availability in the other selected geos.

[0049] Similarly, in one example, if the option selection module 160 determines that the ETP at the origin location is similar or the same for providers in different geos, the option selection module 160 will select for inclusion the candidate provider located in the geo with the lowest price multiplier. For example, assume that candidate provider A (located in geo 2), candidate provider B (located in geo 4), and candidate provider C (located in geo 5) are all 15 minutes away from the user. If geo 5 has the lowest price multiplier of the three geos, the option selection module 160 will select candidate provider C for inclusion as a trip or service option.

[0050] The option selection module 160 determines a cut-off point for including candidate providers as service options based on the price multiplier in the provider' s geo and the ETP at the nearby origin location. In one embodiment, the option selection module 160 selects a ceiling or maximum threshold such that when the ETP at the nearby origin location is a specific multiplier of the ETP in the user's geo, the option selection module 160 stops searching for additional candidate providers to include in the service options presented to the user. In other embodiments, the option selection module 160 stops searching for additional candidate providers once the estimated trip price begins to increase after reaching its lowest point. After the option selection module 160 selects the service options to present to the user, the option selection module 160 queries the trip price estimation module 165 for estimated trip price for each of the selected service options.

[0051] The trip price estimation module 165 estimates or determines the cost for a trip based on data from the service data. In one embodiment the cost can be based on the origin location, the destination location, the route to travel, the estimated duration of the service, the service type, the price multiplier, and/or time when the service is to be provided (e.g., now or in twenty minutes).

[0052] In one embodiment, the following example illustrate how provider selection can be globally optimized. Let ? _ij;t be the trip flow (volume) from geo i to geo j (which is estimated based on selection of service options and usual on-demand request volume) at time t E T. Let C _i;t be the open cars (which is estimated based on the trip flow into a geo and usual driver login schedule) in geo i at time t E T. Let L _k . _t be the usual net open cars coming into the marketplace in geo k at time t E T. Let D _{k i} . _t be the provider selection decision for providers in geo k to fulfill trip requests from geo i at time t E T. Let τ _{ί ;;ί:} be the travel time from geo i to geo j at time t E T. Finally, let f(k, t) be the price (or fare) for a trip from geo i to geo j fulfilled by providers from geo k at time t E T. The global provider selection optimization problem can be formulated as follows:

Maximize: a∑fc _, ij _, t f(k, t) + MGV

Such that ∑ k,i;t Vi, Vt E T k,i t ≤ Cfc;t Vk, Vt E T

where Tis a time range in which the provider selection decisions are optimized, MGV is some definition of overall market-generated value, measuring the total values for the users, the providers, and the marketplace generated by responding to the given demand.

[0053] Thus, in this example, the option selection module 160 adds the sum (over geos k, i, j and times t) of the prices of trips going from geo i to geo j fulfilled by provider(s) in geo k at time t times a constant \alpha and the market-generated value times a constant \beta, such that the sum of the trip flow between geos i and j in time section t after the travel time between geos k and i equals the sum (over geos k) of the provider selection decisions on providers in geo k to fulfill trips from geo i for all of geo i and for all times, and such that the sum of the provider selection decisions on providers in geo k to fulfill trips from some geo i is less than or equal to the open cars in geo k for all of geo k and for all times, and such that the open cars in geo k equals the number of trips ending in geo k at time t minus the number of cars selected away from geo k plus the number of open cars moving or logging into geo k for all geo k and for all time t.

[0054] After the option selection module 160 selects the service options to present to the user, the option selection module 160 queries the trip price estimation module 165 for estimated trip price for each of the selected service options.

[0055] The trip price estimation module 165 estimates the price for a trip requested in a trip request. The trip price estimate represents an estimate of the trip price if a user was assigned to a provider at a point in time when the estimate was generated or at some future point in time. A cost or trip price estimate may be a single determined price or a range of prices within which the trip price might be. In some embodiments, the trip price estimation module 165 determines the probability that the actual cost or trip price will be less than or equal to the trip price estimate, or that the actual trip price will fall within a determined price range of the trip price estimate. The trip price estimation module 165 can also generate an estimate of the minimum trip price for a specified timeframe, and can estimate when that minimum cost or trip price might occur.

[0056] The trip price estimation module 165 uses models of the cost or trip price to generate a cost or trip price estimate within a geo. The trip price models can be based on underlying factors that can impact the trip price, such as the duration of the trip, the trip distance, the origin location, the destination, an approximate trip departure time, an estimated time of arrival ("ETA") at the destination, traffic conditions, the number of passengers on the trip, and/or the type of the provider (e.g., the type of vehicle) servicing the trip. The trip price estimation module 165 may also use historical trip price data to generate the trip price estimate. For example, the trip price estimation module 165 may use historical traffic condition data to predict traffic during the trip, and how that traffic impacts the trip price.

[0057] The trip price estimation module 165 may also generate the estimated trip price based on the supply of resources and the demand for trips in the geo of the nearby origin location. For example, if many providers are available to provide trips as compared to the number of potential users that may request trips, the estimated trip price may be lower.

Similarly, if many users are requesting trips as compared to the number of available providers, the estimated trip price may be higher. In some embodiments, the trip price estimation module 165 applies a price multiplier during periods of peak user demand.

[0058] The trip price estimation module 165 uses a price or fare calculation scheme to estimate a trip price for each of the selected service options. In one embodiment, the total estimated trip price comprises a trip price and a pickup price. The trip price includes or can be based on the estimated duration of the trip from the nearby origin location to the destination location and/or the estimated distance traveled, the length of the trip, and the price multiplier in the geo in which the provider is currently located. The pickup price includes the estimated duration and/or distance or length of the trip from the provider's current location to the nearby origin location and the price multiplier in the provider's geo. In some

embodiments, the pickup price is zero if the nearby origin location and provider location are within a small or predefined estimated travel time or provider selection radius (e.g., 5 minutes).

[0059] After the trip price estimation module 165 calculates the estimated trip prices for each of the selected service options, the trip price estimation module 165 returns the total estimated trip prices to the option selection module 160, which sends the service options with the associated trip price estimates for display on the user client device 100. In one embodiment, the service options are automatically pushed to the user client device 100 responsive to the user subscribing to a real-time information push. In other embodiments, the service options are displayed on the user client device 100 responsive to the user specifying the origin location and/or the destination location or providing user input comprising a request for information through the user application 102. In one embodiment, the option selection module 160 orders the list of service options from quickest (e.g., the earliest the user can receive service) to slowest. In another embodiment, the option selection module 160 orders the list from least expensive to most expensive. In still other embodiments, responsive to the demand prediction module 155 predicting that user demand will be over a threshold volume, the option selection module 160 orders the list of service options sent to the user client device 100 such that providers who are located further away are displayed first. For example, if the demand prediction module 155 determines that the demand at a geo will be over a threshold volume in twenty minutes, the option selection module 160 will order the list of service options presented to users considering making a trip request from the geo such that providers who are located approximately twenty minutes away are presented first.

[0060] In some embodiments, the service options are associated with single rider transportation services whereby a provider transports a single user from an origin location to a destination location. In other embodiments, the service options correspond to multiple rider transportation services, in which a single provider transports multiple users from origin locations to destination locations. In still other embodiments, the service options include both single rider and multiple rider transportation services based on user input. For example, a user may specify that he or she only wishes to view service options associated with single rider services or that multiple rider services should be presented first in the list of service options. Additionally, in some examples, the service options include transportation services already assigned to providers whereby the provider provides one or more single or multiple rider transportation services to one or more other user while traveling from the provider's current location to the origin location, as described below with respect to FIG. 5.

[0061] The option selection module 160 optimizes the order in which the service options are presented to the user through the user application 102. For example, if set of service data associated with a user has a desired departure time of 30 minutes from the current time, the option selection module 160 orders the list of service options such that service options associated with candidate providers who are roughly 30 minutes away from the origin location are presented first. As the current time becomes closer to the desired departure time, the option selection module 160 re-orders the service options such that service options associated with candidate providers who are closer in time to the desired departure time are presented first.

[0062] The demand prediction module 155 trains an optimization model to predict user demand over upcoming time periods using stored data including historical trip data and data regarding service options presented to and selected by users. The demand prediction module 155 forms a set of training data that serves as input to generate and train the optimization model. In some embodiments, the training data includes feature vectors of sets of service data from past trips taken by users, including origin locations, destination locations, desired departure times, service options presented to users, and service options selected by users. Additionally or alternatively, the training data includes sets of service data corresponding to requests for transportation services in the future - that is, requests for services where the requestor is not seeking to be picked up at the time the request is being made. In still other embodiments, the training data includes provider availability and location data (e.g., data regarding an available provider's relocation from one geo to another).

[0063] In one embodiment, the demand prediction module 155 uses the optimization model to improve predictions of demand over time (how may rides were actually requested). The difference between the predicted and actual demand is an error margin that is fed back into the optimization model. Thus, the optimization mode is improved over time to more accurately predict the true demand. The model can also respond dynamically to changes in demand pattern.

[0064] In some embodiments, the optimization model is used to optimize trip requests received over a time span (e.g., the next 30 minutes) over a range of geos within a threshold distance of each other. For example, as discussed above, in response to receiving a set of service data through the user application 102, the option selection module 160 applies the optimization model to determine which geos and candidate providers to include in the set of service options presented to the user.

[0065] In response to predicting user demand over time, the optimization model can also be used to predict pricing information. For example, the optimization model might predict pricing in a geo every three minutes for the next 30 minutes or might predict pricing for all geos within a threshold distance every 10 minutes for the next 24 hours.

[0066] In still other embodiments, the trip management module 140 uses the output of the optimization model to profile providers and users of the network system 130. For example, the trip management module 140 can use data about service options presented to and selected by users to determine the user's usual schedule and sketch user itineraries and trip patterns. Further, the trip management module 140 can use data regarding service options presented to and selected by providers and provider location data to determine a provider's performance in different geos and provider sensitivity to pricing, distance, and other trip-related properties.

[0067] The trip management module 140 uses predictions generated by the

optimization model to position providers across and within geos to optimize the number of trip requests that the network system 130 is able to fulfill. In some embodiments, the trip management module 140 sends provider incentives to the provider application 104 to incentivize the provider to travel from the provider's current location to other geos or other regions of the same geo during a predicted period of high demand. The trip management module 140 might display the payment as a standalone incentive or as a component of the provider's income from a specific trip.

[0068] The trip data store 180 maintains a record of each in-progress and/or each completed trip coordinated by the network system 130. More specifically, each trip provided by a provider to a user is characterized by a set of attributes (or variables), which together form a trip record that is stored in the trip data store 180. The attributes describe aspects of the provider, the user, and the trip. In one embodiment, each trip record includes or is associated with a trip identifier (ID), a user ID, a provider ID, the origin location, the destination location, the duration of the trip, the service type for the trip, estimated time of pick up, actual time of pickup, and provider rating by user, user rating by provider, price information, market information, and/or other environmental variables as described below. The variables for the trip record are thus drawn from multiple sources, including the user's master and usage records in the user data store 182, the provider's master and operational records in the provider data store 184, and specific variables captured and received during each trip.

[0069] The provider data store 184 stores account and operational information for each provider who participates in the network system 130. For each provider, the provider data store 184 stores one or more database records associated with the provider, including both master data and usage data. In some examples, master data for a provider includes or is associated with the provider's name, provider's license information, insurance information, vehicle information (year, make, model, vehicle ID, license plate), address information, cell phone number, payment information (e.g., credit card number), sign-up date, provider service type (regular, luxury, van, etc.), device type (e.g., type of cell phone), platform type (e.g., iOS, Android), application ID, and/or application version for the provider application 104. The usage data can correspond to historical information about the provider's services received, provided, canceled, and/or completed, such as the times, locations, and routes traveled associated with such services.

[0070] The provider inventory data store 186 stores provider availability status information received from the trip management module 140, including whether the provider is available for matching and the location of the provider (which gets updated periodically). When the trip management module 140 receives a trip request, the trip management module 140 determines, from the provider inventory data store 186, which providers are potential candidates to pick up the user for the newly created trip. When the network system 130 marks a trip record as complete, the network system 130 can add the provider back into the inventory of available providers in the provider inventory data store 186.

[0071] FIG. 2 is an interaction diagram for optimizing resource allocation based on demand prediction, according to a first embodiment. At 205, the geo monitoring module 150 determines price multipliers in geos and sends 210 the price multiplier data to the geo data store 188 for storage. In one embodiment, the geo monitoring module 150 determines price multipliers by comparing the ratio of trip requests in a geo with the number of available providers. If the ratio of trip requests to available providers is over a threshold, the geo monitoring module 150 applies a price multiplier to the geo. In some embodiments, the geo monitoring module 150 applies progressively higher price multipliers as the ratio of trip requests to available providers increases.

[0072] In response to receiving a set of service data from a user of a user client device 100, the trip management module 140 sends 215 the received service data to the option selection module 160, which selects geos and/or candidate providers for inclusion in a list of service options. At 220, the option selection module 160 queries the geo data store 188 for price multipliers in geos within a threshold distance of the origin location or the origin geo of the user. The option selection module 160 also queries 225 the provider inventory data store 186 for available providers in these nearby geos, including the locations of the available providers in the geos. For each selected geo, the option selection module 160 calculates the average distance and/or estimated time from the current locations of the available providers to the origin location. In some embodiments, the option selection module 160 further queries 230 the demand prediction module 155 for the predicted user demand in the selected geos within a threshold amount of time of the desired departure time.

[0073] In some examples, in response to the geo data store 188, the provider inventory data store 186, and the demand prediction module 155 returning 235, 240, and 245 the requested data, the option selection module 160 selects 250 geos for inclusion in the list of service options that will be presented to the user. In some embodiments, the option selection module 160 also uses trip data received from the trip data store 180 to determine the set of service options, as discussed above with respect to FIG. 1. In one embodiment, the option selection module 160 selects all nearby geos. In another embodiment, the option selection module 160 selects the geo in which the nearby origin location is located and all adjacent geos. In still other embodiments, the option selection module 160 selects geos with varying price multipliers. According to various examples, the option selection module 160 considers the current ratio of supply and demand and the applicable price modifiers in nearby geos when selecting geos for inclusion in the set of service options, as discussed above with respect to FIG. 1.

[0074] For each of the selected geos, the option selection module 160 selects 255 candidate providers for inclusion as service options. In one embodiment, the option selection module 160 selects the candidate provider for whom the ETP at the nearby origin location is the least. In another embodiment, if the option selection module 160 determines that the ETP at the nearby origin location is the same for candidate providers in different geos, the option selection module 160 selects the candidate provider located in the geo with the lowest price multiplier. In still other embodiments, the option selection module 160 selects candidate providers based on user input regarding desired departure time. In all embodiments, the option selection module 160 determines a cut-off point for including candidate providers as service options based on the price multiplier in the candidate provider's geo and the ETP at the nearby origin location.

[0075] After selecting the service options to present to the user, the option selection module 160 queries 260 the trip price estimation module 165 for trip price estimates. At 265, the trip price estimation module 165 calculates an estimated trip price for each of the selected service options. In one embodiment, the estimated trip price comprises a trip price and a pickup price, such as discussed above with respect to FIG. 1. After calculating the estimated trip prices, the trip price estimation module 165 returns 270 the estimates to the option selection module 160, which sends 275 the service options with associated trip price estimates for to the trip management module 140 display 280 on the user client device 100.

[0076] The trip management module 140 receives 285 user input comprising selection of one of the presented service options, and sends 290 data regarding the selected service option to the demand prediction module 155. The demand prediction module 155 uses training data including the presented service options, the selected service option, and sets of training data from past trips taken by users (including origin locations, destination locations, desired departure times, service options presented to users, and service options selected by users) to generate 295 an optimization model to predict user demand over upcoming time periods. In some embodiments, the training data includes sets of service data corresponding to requests for transportation services in the future. In other embodiments, the training data includes provider availability and location data (e.g., data regarding an available provider's relocation from one geo to another). The training data serves as input to generate and train the optimization model, as discussed above with respect to FIG. 1. Once trained, the demand prediction module 155 uses the optimization model to improve predictions over user demand and optimize trip requests received over a time span over a range of geos within a threshold distance of each other.

[0077] FIG. 3 illustrates an interaction diagram for optimizing resource allocation based on demand prediction, according to a second embodiment. At 305, the geo monitoring module 150 determines price multipliers of geos and sends 310 the price multiplier data to the geo data store 188 for storage. In one embodiment, the geo monitoring module 150 determines price multipliers by comparing the ratio of trip requests in a geo with the number of available providers. If the ratio of trip requests to available providers is over a threshold, the geo monitoring module 150 applies a price multiplier to the geo. In some embodiments, the geo monitoring module 150 applies progressively higher price multipliers as the ratio of trip requests to available providers increases.

[0078] The demand prediction module 155 predicts the volume and timing of an upcoming demand peak at or near the vicinity of an origin location. If the demand prediction module 155 predicts 315 that user demand will be over a threshold volume in the geo containing the origin location, the demand prediction module 155 sends 320 an instruction to the option selection module 160 to obtain price multiplier data for geos within a threshold distance of the origin location. In one embodiment, the demand prediction module 155 predicts volume and timing of an upcoming demand peak responsive to the trip management module 140 detecting that user interest will be over a threshold volume based on the number of users who make a trip request through the user application 102 within a specified vicinity or geography and during a time period. In another embodiment, the demand prediction module 155 predicts volume and timing based on the number of trip arrivals at the origin location within a specified time period. In still other embodiments, the demand prediction module 155 considers both trip arrivals and the number of users making trip requests when predicting the volume and timing of an upcoming demand peak.

[0079] At 325, the option selection module 160 queries the geo data store 188 for price multipliers in geos within a threshold distance of the origin location. Responsive to the geo data store 188 returning 330 the requested data regarding these nearby geos, the option selection module 160 selects 335 geos for inclusion in the list of service options that will be presented to the user. In one embodiment, the option selection module 160 selects all nearby geos. In another embodiment, the option selection module 160 selects the geo in which the origin location is located and all adjacent geos. In still other embodiments, the option selection module 160 selects geos with varying price multipliers.

[0080] After selecting the geos to be included in the spectrum of service options presented on the user client device 100, the option selection module 160 queries 340 the provider inventory data store 186 for a list of available providers in the selected geos and the location of the providers. At 345, the provider inventory data store 186 returns the requested data regarding these candidate providers, and the option selection module 160 selects 350 the service options. In one embodiment, for each of the selected geos, the option selection module 160 selects the candidate provider for whom the ETP to the origin location is the least. In another embodiment, if the option selection module 160 determines that the ETP to the origin location is the same for candidate providers in different geos, the option selection module 160 selects the candidate provider located in the geo with the lowest price multiplier. In still other embodiments, the option selection module 160 selects candidate providers based on user input regarding order time. As an addition or an alternative, the option selection module 160 determines a cut-off point for including candidate providers as service options based on the price multiplier in the candidate provider's geo and the ETP to the origin location, as discussed above with respect to FIG. 1.

[0081] After selecting the service options to present to the user, the option selection module 160 queries 355 the trip price estimation module 165 for cost estimates. At 360, the trip price estimation module 165 calculates an estimated cost for each of the selected service options. In one embodiment, the estimated cost comprises a trip cost and a pickup cost, as discussed above with respect to FIG. 1. After calculating the estimated costs, the trip price estimation module 165 provides 365 the estimates to the option selection module 160, which transmits the service options with associated cost estimates for display on the user client device 100. The user operating the user client device 100 can view the service options, the associated ETP, and the associated cost estimates, and select an option to make a request for service. When the user selects a service option, the user application 102 can generate and transmit data corresponding to a trip request to the network system 130. The trip request can include a user identifier, the service type, the origin location, the destination location, and/or information about the selected option.

[0082] In response to receiving the data corresponding to the trip request, the trip management module 140 creates a trip record in the trip data store 180 and selects a provider to provide the requested service from the list of candidate providers in the selected geos. In one embodiment, the trip management module 140 selects the candidate provider associated with the selected service option who is closest to the origin location. For example, assume that providers A, B, and C are all associated with a selected service option (e.g., a trip originating in geo 3 with an ETP to the origin location in geo 1 of approximately 20 minutes). If provider A has an ETP of 22 minutes, provider B has an ETP of 20 minutes, and provider C has an ETP of 19 minutes, the trip management module 140 will select provider C to provide the service. In other embodiments, the trip management module 140 selects a candidate provider who is traveling towards the origin location. In still other embodiments, when a candidate provider is providing a service to multiple users at the same time, the trip management module 140 selects the candidate provider who is traveling towards the user's destination.

[0083] FIG. 4 is a conceptual illustration of an example geo map depicting predicted price multipliers and candidate providers in different geos, in accordance with an

embodiment. Assume that a user of a user client device 100 is attending a baseball game at a stadium 400 located in geo 1 (or at another event, such as a movie, party, restaurant, etc.). In one embodiment, at a current time, e.g., twenty minutes before the end of the game, the user opens the user application 102 to make a trip request. In response to receiving a set of service data including at least an origin location, a destination location, and/or a desired departure time (or default departure time), the option selection module 160 selects a spectrum of available service options to present to the user.

[0084] In another embodiment, the user opens the user application 102 to view service information and potentially request a trip. The user can specify or select an origin location, a destination location, and/or a service type and view information about the service, such as the estimated time of arrival to the origin location, the estimated cost or calculated cost for the service, the estimated time to the destination location, etc. For example, in response to the user input, the network system 130 can receive the service data, determine the various service information, and transmit data corresponding to the service information to the user client device 100. In one example, in response to the demand prediction module 155 determining that user demand will be over a threshold volume at a current time or period of time, the option selection module 160 selects geos and candidate providers to present as one or more service options on the user client device 100. For example, the demand prediction module 155 can determine that user demand is likely to be high in twenty minutes (e.g., near the end of the game at the stadium) as a high number of users at or near that time may operate the user application 102 to view service information and/or to request rides near the stadium to their homes or other locations. Similarly, user demand can be predicted to be high during historically busy time periods (e.g., evening rush hour between 5 and 7pm). If the demand prediction module 155 predicts that user demand in a geo will be over a threshold volume, the network system 130 selects and presents a spectrum of available service options for users that have specified an origin location in the geo. In one use case example, if the demand prediction module 155 detects high user demand coinciding with the end of a baseball game, the network system presents a spectrum of available service options to both users who are at the game and users who are not at the game (e.g., a user who is requesting a ride home from a restaurant), provided that they are located in the same geo or have specified an origin location in the same geo.

[0085] As illustrated in FIG. 4, at an instance in time or period of time, price multipliers may be different across geos. For example, the demand prediction module 155 predicts that the price multiplier in geo 1, where the user is located at or has specified an origin location at, will be 3. Ox near the end of the game at the stadium, while the predicted price multipliers in neighboring geos 2 and 3 are 1.5x and l .Ox, respectively, where x is an initial trip price to which the price multiplier is applied to determine a final trip price estimate. The user located at the stadium 400 may be presented with a number of service options 405, 410, and 415 with varying price multipliers and ETPs at the nearby origin location. The estimated trip price associated with each service option can be based on the price multiplier in the geo in which the provider is located. For example, for service option 405, the provider is located five minutes away from the nearby origin location (has an ETP of five minutes from the origin location) (or alternatively, a group of providers in geo 3 have an averaged ETP or shortest ETP of five minutes from the origin location, i.e., the stadium 400), and the price multiplier is 3. Ox. For service option 410, the provider (or group of providers) is determined located ten minutes away from the nearby origin location (has an ETP, e.g., averaged or shortest ETP, of ten minutes), and the price multiplier is 1.5x. For service option 415, the provider (or group of providers) is located 20 minutes away from the nearby origin location (has an ETP of twenty minutes) and the price multiplier is l .Ox (i.e., there is no price multiplier in geo 3 is l .Ox). According to some examples, the predicted price multipliers at a time in the future can be provided to the user application 102 in conjunction with the service options so that the user may determine the benefit of requesting a service at a later time as compared to a current time.

[0086] The network system 130 can provide the service options and the respective costs and ETPs to the user client device 100. In one embodiment, the option selection module 160 orders the list of available options or rides from quickest to slowest (e.g., based on ETP) (i.e., service option 405, service option 410, service option 415). In another embodiment, the option selection module 160 orders the list from least expensive to most expensive based on the trip price estimates calculated by the trip price estimation module 165. For example, if the destination location is a short distance from the nearby origin location, service option 405 might be the least expensive, despite having the highest price. In still other embodiments, responsive to the demand prediction module 155 predicting that user demand will be over a threshold volume at or near a desired departure time, the option selection module 160 orders the list of service options such that providers who are located further away are displayed first. For example, if the desired departure time is approximately twenty minutes, the option selection module 160 will order the list of service options such that service option 315 is presented first.

[0087] FIG. 5 is a conceptual illustration of an example geo map depicting an already- assigned trip (e.g., a service that is previously assigned to a user to be provided by a provider, but the user has not yet been picked up), where the provider is traveling from a current location to the origin location, in accordance with an embodiment. Assume that user A is getting ready to leave work for the day and submits a set of service data including a request for a trip from the user's office 500 to the user's home and a desired departure time of 30 minutes from the current time. In response to receiving the set of service data, the option selection module 160 selects a spectrum of available service options to present to user A.

[0088] Assume that candidate provider 405, who is located approximately 20 minutes away from the origin location 500 is included as a service option. In one embodiment, in response to user A selecting service option 505, the trip management module 140 sends an invitation message to provide the requested service to a candidate provider associated with service option 505 in 10 minutes (i.e., such that the candidate provider will arrive at the origin location at the desired departure time). In other embodiments, however, in response to user A selecting service option 505, the trip management module 140 schedules one or more already-assigned trips whereby candidate provider 505 provides one or more transportation services to one or more other users while traveling from the current location to the origin location 500.

[0089] For example, assume that user A has selected service option 505 from the list of service options in which a candidate provider associated with the service option 505 is assigned to user A. In response to user B submitting a trip request with an origin location and a destination location located between candidate provider 505 's current location and the origin location 500 and a desired departure time of "now," the trip management module 140 schedules an already-assigned trip whereby the candidate provider associated with service option 505 travels to user B's origin location 510 (9 minutes) and transports user B from the origin location 510 to the destination location 515 (9 minutes) before traveling from destination location 515 to origin location 500 to pickup user A (9 minutes).

[0090] In some embodiments, the trip management module 140 schedules an already- assigned trip in response to determining that the total estimated time for the already-assigned trip is within a threshold amount of time of user A's desired departure time. In other embodiments, the trip management module 140 schedules an already-assigned trip in response to determining that user B's desired departure time is within a threshold amount of time of user A's desired departure time. For example, if user B's desired departure time is in 20 minutes and the total estimated time for trip B is 27 minutes (bringing the ETP at the origin location 500 to 47 minutes), the trip management module 140 will not schedule the already-assigned trip for user B.

[0091] The user application 102 presents the service options to the user and provides the user with the ability to select a service option from the presented service options. FIG. 6 illustrates an example user interface 602 on the user application 102 for displaying alternative service options. In the illustration, the user interface 602 displays the origin location, the destination location, the order time, and the service options 604, 606, and 608. In the illustration, the user interface 602 includes three service options. In other embodiments, more or fewer service options are included. The presentation of each of the service options 604, 606, and 608 includes information about the respective service options, for example, the ETP, the applicable price multiplier, and the estimated trip price or computed guaranteed cost. In some embodiments, the information further includes whether the service option is a one-to-one or a one-to-many service option. In some embodiments, the service options include trips with ETPs at the nearby origin location presented in minutes. Alternatively, the service options might include trips with ETPs presented in hours or days.

[0092] In embodiments where the order time is hours or days from the time the trip request is made (e.g., earlier than a threshold amount of time before), the demand prediction module 155 uses data from the trip requests to forecast scheduled demand including origin locations, destination locations, and timing. For example, if the number of users requesting rides to the airport in the next week exceeds a threshold, the demand prediction module 155 might infer that the real-time trip requests during the evening commute will be less than usual. [0093] Assume that a user attending a baseball game at a stadium in geo 1 opens the user application 102 at 4: 17 pm, roughly twenty minutes before the end of the game, to make a trip request. The user inputs or specifies the origin location, the destination location, and an order time of "now." The user can also specify a service option, not illustrated in FIG. 6 for purposes of simplicity. Depending on implementation, responsive to receiving the service data, or in response to the network system 130 predicting that user demand will be over a threshold volume, the option selection module 160 sends for display on the user client device 100 the service options 604, 606, and 608. Service option A includes a provider currently located in the same geo as the user and has an ETP at the origin location of 4:22 pm, 5 minutes from the order time. Because the current demand for rides is low, the price multiplier in geo 1 is l .Ox, and the total estimated cost to the destination location is $26. However, the network system 130 can determine that at a future time, such as in twenty minutes, the predicted price multiplier in geo 1 can be higher than l .Ox, such as 3. Ox, due to forecasted demand.

[0094] Service option B includes a provider located in neighboring geo 2 arriving at the origin location approximately ten minutes after the order time, at 4:27 pm. The price multiplier in geo 2 is currently 1. lx, and the total estimated price to the destination location is $31. Though service option B is more expensive and has a longer ETP than service option 1, the user might choose service option B if, for example, the score is close, and the user does not want to leave the game immediately, but may want to leave sometime after 5 minutes. If the user selects service option B (leave later as opposed to "now"), the network system 130 can select a provider from geo 2 so that the provider can travel from geo 2 to the origin location (e.g., it would take around the ETP time). This can be a better user experience for the user and cheaper than if the user waits eight more minutes before deciding to make a request for "now," (e.g., making a standard trip request) and if eight minutes later, the estimated price multiplier goes up significantly in geo 1 (e.g., from l . lx to 1.8x). In such an example, the network system 130 would select a provider closest to the origin location (e.g., select a provider in geo 1 with the price multiplier at 1.8x), but the user would receive the same or similar service at a higher cost than if the user had requested option B for a provider from geo 2 eight minutes before.

[0095] Service option C includes a provider located in geo 3 arriving at the origin location approximately twenty minutes after the order time, at 4:37 pm (i.e., the time the baseball game is estimated to end). The price multiplier in geo 3 is l .Ox, and the total estimated cost to the destination location is $35. In such an example, the total estimated cost for option C would be greater than the total estimated cost for option A (though both have a multiplier of l .Ox) due to the distance and/or duration traveled by the provider from geo 3 to the origin location. Service option C gives the user an option to remain at the game until its estimated end for a relatively low price. In such an example, if the user were to select option C (at the current time, 4: 17pm), the network system 130 can select a provider from geo 3, who can start traveling towards the origin location and arrive at the origin location around 4:37pm. By comparison, if the user waited until the end of the game to make a trip request, the price multipliers would likely increase as more spectators leave the stadium around the same time. In this example, the price multiplier at geo 1 once the game ends can increase (e.g., from l .Ox to 3. Ox due to the number of other users in geo 1 that are operating the client applications to potentially request service) so that the estimated cost may be much higher than $26 (e.g., $50), so that if the user were to request service at that time, a provider in geo 1 would be selected at the potentially higher cost. In this manner, the network system 130 can enable resources to be allocated from nearby geographic regions to fulfill demand in a geographic region where demand is higher than normal or forecasted to be higher than normal by providing service options, for services that start at a later time, to users.

[0096] FIG. 7 illustrates an example user interface on a provider application 104 showing service options for selection by a provider, in accordance with an embodiment. As discussed above with respect to FIG. 1, a provider can select from a number of service options representing various trip requests submitted by users of the network system 130. The trip management module 140 selects trip requests to display as service options to the provider based on predicted demand over a specified time period within a threshold distance of the provider's current location or geo, as determined by the demand prediction module 155.

[0097] For example, FIG. 7 displays three service options 704, 706, and 708 presented on user interface 702. In other embodiments, more or fewer service options are displayed depending on the number of trip requests and/or the predicted demand. The presentation of each of service options 704, 706, and 708 includes information about the respective service options, for example, the ETP, the applicable price multiplier, and the estimated trip price. In some embodiments, the information further includes optional already-assigned trips associated with one or more of the service options 704, 706, and 708. In some embodiments, the service options include trips with ETPs at the origin location presented in minutes.

Additionally or alternatively, the service options might include trips with ETPs presented in hours or days. [0098] Assume that a provider located in geo 2, where the current surge multiplier is 1.6, opens the provider application 104 at 4: 16pm to select one or more trip requests to fulfill. The provider application 104 displays one or more service options selected based application of the market status factors, including the origin and destination locations and desired departure times input by the users, the current user demand for service, predictions of future demand, number and locations of other available providers, and pricing information in geos within a threshold distance of the origin locations or the origin geos of the users.

[0099] Service option A 704 corresponds to a user whose origin and destination locations are in the same geo as the provider's current location. With the applicable price multiplier, the estimated total price for service option A 704 is $18, and the ETP by the provider at the origin location is 4:22pm. Service option B 706 corresponds to a user whose origin and destination locations are in geo 3. With the applicable price multiplier for geo 2 (the geo in which the provider is currently located), the estimated total price is $26, and the ETP by the provider is 4:29pm. In some embodiments, the estimated total price incorporates an incentive for the provider to travel from geo 2 to the origin location in geo 3. Finally, service option C 708 corresponds to a user whose origin location is in geo 3 and whose destination location is in geo 4. With the applicable price multiplier for geo 2, the estimated total price is $37 and the ETP by the provider is 4:37pm. In each of service options 704, 706, and 708, the applicable price multiplier is the current price multiplier in geo 2, the geo in which the provider is currently located. In some embodiments, one or more of the presented service options might include one or more already-assigned trips. For example, service option C 708 might include an already-assigned trip with an origin location in geo 2, a destination location in geo 3, and an estimated time of arrival at the already-assigned trip destination location before the desired departure time of the first user.

[0100] FIG. 8 is a block diagram illustrating physical components of a computer 800 used as part or all of the network system 130, user client device 100, or provider client device 110 from FIG. 1, in accordance with an embodiment. Illustrated are at least one processor 802 coupled to a chipset 804. Also coupled to the chipset 804 are a memory 806, a storage device 808, a graphics adapter 812, and a network adapter 816. A display 818 is coupled to the graphics adapter 812. In one embodiment, the functionality of the chipset 804 is provided by a memory controller hub 820 and an I/O controller hub 822. In another embodiment, the memory 806 is coupled directly to the processor 802 instead of the chipset 804.

[0101] The storage device 808 is any non-transitory computer-readable storage medium, such as a hard drive, compact disk read-only memory (CD-ROM), DVD, or a solid-state memory device. The memory 806 holds instructions and data used by the processor 802. The graphics adapter 812 displays images and other information on the display 818. The network adapter 816 couples the computer 800 to a local or wide area network.

[0102] As is known in the art, a computer 800 can have different and/or other

components than those shown in FIG. 8. In addition, the computer 800 can lack certain illustrated components. In one embodiment, a computer 800, such as a host or smartphone, may lack a graphics adapter 812, and/or display 818, as well as a keyboard 810 or external pointing device 814. Moreover, the storage device 808 can be local and/or remote from the computer 800 (such as embodied within a storage area network (SAN)).

[0103] As is known in the art, the computer 800 is adapted to execute computer program modules for providing functionality described herein. As used herein, the term "module" refers to computer program logic utilized to provide the specified functionality. Thus, a module can be implemented in hardware, firmware, and/or software. In one embodiment, program modules are stored on the storage device 808, loaded into the memory 806, and executed by the processor 802.

[0104] The foregoing description described an embodiment of the invention in which the network system 130 presents a spectrum of service options on the user client device 100 responsive to the demand prediction module 155 detecting that user demand will be over a threshold volume. In other embodiments, the trip management system 130 presents a spectrum of service options regardless of the demand forecasted by the demand prediction module 155.

[0105] FIG. 9 is a flow chart illustrating the selection of service options based on market status factors, in accordance with an embodiment. The option selection module 160 receives as input a set of service data 905 received from a user A, the set of service data including an origin location, a destination location, and a desired departure time. In some embodiments, the set of service data 905 includes a request for a single rider transportation service. In other embodiments, the set of service data 905 includes a request for a multiple rider transportation service.

[0106] The option selection module 160 also receives as input a number of market status factors 910, including the current user demand for service, predictions of future demand in geos within a threshold distance of the origin location or the origin geo of the user, the number and location of available providers, and pricing information in geos within a threshold distance of the origin location or the origin geo of the user. Additionally, the market status factors 910 may include, for each of the available providers located within a threshold distance of the origin location or the origin geo of the user, the distance and estimated time from the provider's current location to the origin location.

[0107] In some embodiments, the option selection module 160 queries the trip data store 180 for trip data associated with trip requests made within a threshold period of time of user A's trip request. Additionally or alternatively, the option selection module 160 queries the trip data store 180 for trip data associated with trip requests with origin locations within a threshold distance of the origin location or origin geo of user A. The trip data store 180 returns the requested trip data 915, including the origin locations, destination locations, route information, desired departure times, and user-provider matching information for each of the N trips and M providers associated with the trip requests. In some embodiments, the option selection module 160 uses the trip data 915 as input when selecting the service options for user A.

[0108] Responsive to receiving as input the service data for user A 905, the market status factors 910, and the trip data 915, the option selection module 160 selects geos and candidate providers, as discussed above with respect to FIG. 1 and outputs a set of service options for user A through the user application 102. In conjunction with selecting the set of service options for user A, the option selection module 160 recalculates the existing trip data, including the user-provider matching information, to account for user A's trip request.

Therefore, in some embodiments, the option selection module 160 also outputs updated trip data 925 including the origin locations, destination locations, route information, desired departure times, and user-provider matching information for each of the N+l trips and M providers.

[0109] The foregoing description has been presented for the purpose of illustration; it is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Persons skilled in the relevant art can appreciate that many modifications and variations are possible in light of the above disclosure.

[0110] Some portions of this description describe embodiments in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are commonly used by those skilled in the data processing arts to convey the substance of their work effectively to others skilled in the art. These operations while described functionally computationally or logically are understood to be implemented by computer programs or equivalent electrical circuits microcode or the like. Furthermore it has also proven convenient at times to refer to these arrangements of operations as modules without loss of generality. The described operations and their associated modules may be embodied in software firmware hardware or any combinations thereof.

[0111] Any of the steps operations or processes described herein may be performed or implemented with one or more hardware or software modules alone or in combination with other devices. In one embodiment a software module is implemented with a computer program product comprising a computer-readable medium containing computer program code which can be executed by a computer processor for performing any or all of the steps operations or processes described.

[0112] Embodiments may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes and/or it may comprise a general-purpose computing device selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a non-transitory tangible computer readable storage medium or any type of media suitable for storing electronic instructions which may be coupled to a computer system bus. Furthermore any computing systems referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.

[0113] Embodiments may also relate to a product that is produced by a computing process described herein. Such a product may comprise information resulting from a computing process where the information is stored on a non-transitory tangible computer readable storage medium and may include any embodiment of a computer program product or other data combination described herein.

[0114] Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description but rather by any claims that issue on an application based hereon. Accordingly, the disclosure of the embodiments of the invention is intended to be illustrative but not limiting of the scope of the invention which is set forth in the following claims.