Note: Descriptions are shown in the official language in which they were submitted.
<br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>1<br/>DYNAMIC SELECTION OF GEO-BASED SERVICE OPTIONS IN A<br/>NETWORK SYSTEM<br/>TECHNICAL FIELD<br/>[0001] The subject matter described herein generally relates to the field <br/>of network <br/>systems, and, more particularly, to optimizing resource allocation among <br/>different regions.<br/>BACKGROUND<br/>[0002] Network systems, such as transport management systems, provide <br/>support for <br/>the logistical issues in managing the transportation of persons, cargo, or the <br/>like. In some <br/>systems, a provider provides transportation services to a user to a location <br/>selected by the <br/>user in exchange for a fee. In typical systems, a user checking a price or <br/>fare or requesting <br/>service is matched with one of a plurality of available providers. Typically, <br/>the provider with <br/>whom the user is matched is the provider who has the shortest estimated time <br/>of arrival to the <br/>user's pickup location or the origin location. This may lead to inefficient <br/>allocation of <br/>resources, particularly in instances where there is high user demand <br/>concentrated in a <br/>geographic region ("geo"). For example, vehicles located in geos of low demand <br/>may be <br/>sitting idle, polluting the air and crowding the street instead of providing <br/>service in nearby <br/>regions with lower provider supply and higher user demand.<br/>SUMMARY<br/>[0003] To enable a more efficient allocation of resources among different <br/>geos and a <br/>higher rate of user conversion, a network system uses global optimization <br/>across geos to <br/>calculate and provide multiple service options to users that may want to <br/>request services (e.g., <br/>transport or delivery services, also referred to as a trip) through a user <br/>application. In one <br/>embodiment, the network system provides multiple service options each time <br/>that a user <br/>transmits a set of service data indicating an interest in potentially <br/>requesting service <br/>facilitated by the network system (regardless of predicted demand). In other <br/>embodiments, <br/>the network system provides multiple service options responsive to predicting <br/>a period of <br/>high user demand or predicting that user demand will be greater than a <br/>threshold amount or <br/>volume. A demand prediction module predicts upcoming demand for services <br/>within a <br/>specified vicinity or geography and during a time period.<br/>[0004] According to an example, a trip management module receives, through <br/>a user <br/>application, user input including a set of service data. In one embodiment, <br/>the service data<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>2<br/>includes at least an origin location, a destination location, a desired <br/>departure time, and/or a <br/>request for an estimated value. In one embodiment, in response to predicting <br/>that user <br/>demand will be greater than a threshold volume at these origin locations, the <br/>demand <br/>prediction module instructs an option selection module (also called a geo <br/>selection module) <br/>to request pricing information (e.g., price multiplier data) for geographic <br/>regions within a <br/>threshold distance of the origin location or the origin geographic region of <br/>the user. The <br/>option selection module uses the price multiplier data to select geographic <br/>regions for <br/>inclusion in a set of service options (also called trip options) that can be <br/>presented to the user <br/>via the user application. In another embodiment, in response to receiving the <br/>service data, the <br/>option selection module selects geos within a threshold distance of the origin <br/>location or the <br/>origin geo of the user for inclusion in a set of service options that can be <br/>presented to the user <br/>via the user application.<br/>[0005] In some examples, the option selection module queries a provider <br/>inventory data <br/>store for available providers located in the selected geographic regions and <br/>selects candidate <br/>providers based in part on user input regarding order time (e.g., time when <br/>the service is <br/>desired). In some embodiments, the option selection module determines the <br/>threshold <br/>distance based in part on the desired departure time. For example, if the <br/>desired departure <br/>time is in 30 minutes, the option selection module might include geos 1, 2, <br/>and 3, but if the <br/>desired departure time is in 35 minutes, the option selection might also <br/>include geo 4 when <br/>determining the set of service options to be presented to the user. The option <br/>selection <br/>module then queries a geo data store for pricing information (e.g., price <br/>multiplier data) for <br/>the selected geos and sends the received data to an option selection module <br/>for selection of <br/>the service options.<br/>[0006] In one embodiment, for each of the selected geographic regions, the <br/>option <br/>selection module selects the provider with the shortest estimated time of <br/>pickup (ETP) to the <br/>origin location or the shortest estimated time to destination (ETD) to the <br/>destination location <br/>(e.g., a total time of estimated time of pickup to the origin location from <br/>the provider location <br/>and estimated time of travel from the origin location to the destination <br/>location). <br/>Alternatively, for each of the selected geographic regions, the option <br/>selection module <br/>determines the ETP for a set of providers in that geographic region (e.g., the <br/>shortest ETP or <br/>average ETP of the set of providers). In another embodiment, if the option <br/>selection module <br/>determines that the ETP to the origin location is the same for multiple <br/>providers in the <br/>different geographic regions, the option selection module selects the provider <br/>located in the<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>3<br/>region with the lowest price multiplier. While examples herein describe <br/>selections based on <br/>ETP for purposes of simplicity, in other examples, the selections can be based <br/>on ETD.<br/>[0007] Still further, in one example, the option selection module selects <br/>service options <br/>to present through the user application to optimize the matching of users and <br/>providers across <br/>geos. In one embodiment, the option selection module receives as input a <br/>number of market <br/>status factors in selecting the service options, including the origin and <br/>destination locations, <br/>the desired departure time, the current user demand for service, predictions <br/>of future demand, <br/>number and location of available providers, and/or pricing information in geos <br/>within a <br/>threshold distance of the origin location or the origin geo of the user. <br/>Additionally, the <br/>market status factors may include, for each of the available providers located <br/>within a <br/>threshold distance of the origin location or the origin geo of the user, the <br/>distance and <br/>estimated time from the provider's current location to the origin location.<br/>[0008] After selecting service options to present to the user, the option <br/>selection module <br/>queries a trip price estimation module to obtain trip estimate values (e.g., <br/>estimated prices or <br/>costs). The trip price estimation module calculates or computes an estimated <br/>value (e.g., <br/>estimated trip cost) for each of the selected service options and sends the <br/>estimate values to <br/>the option selection module for display on the user client device. The <br/>estimated value can be <br/>based on an estimated distance to be traveled along a predicted or proposed <br/>route(s), and/or <br/>estimated duration of time of travel. In some embodiments, the service options <br/>and <br/>associated estimates are pushed to the user client device if the user <br/>subscribes to a real-time <br/>information push. In other embodiments, the service options and associated <br/>estimates are <br/>displayed on the user client device responsive to the user checking prices or <br/>requesting a <br/>service or through the user application.<br/>[0009] In response to a user selecting a service option via the user <br/>application, the user <br/>application can generate data corresponding to a request for a service through <br/>the network <br/>system (e.g., also referred to herein as a "trip request"). In some <br/>embodiments, the network <br/>system uses information from the trip request to match the user with one of a <br/>plurality of <br/>available drivers based on the market status factors.<br/>[0010] The network system also uses the information from trip requests to <br/>predict <br/>future demand across geos and time periods and to position providers based on <br/>predicted <br/>demand. In some embodiments, a demand prediction module generates and trains <br/>an <br/>optimization model to predict user demand over upcoming time periods using <br/>stored data <br/>including historical trip data and data regarding service options presented to <br/>and selected by <br/>users. The trained optimization model is used to position providers across and <br/>within geos to<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>4<br/>optimize the number of trip requests that the network system is able to <br/>fulfill and improve the <br/>performance of the network system by reducing inefficiencies and providing <br/>additional <br/>benefits such as a reduction in pollution and wasted energy<br/>BRIEF DESCRIPTION OF THE DRAWINGS<br/>[0011] FIG. 1 illustrates the system environment for an example network <br/>system, in <br/>accordance with an embodiment.<br/>[0012] FIG. 2 is an interaction diagram for optimizing resource allocation <br/>based on <br/>demand prediction, in accordance with a first embodiment.<br/>[0013] FIG. 3 is an interaction diagram for optimizing resource allocation <br/>based on <br/>demand prediction, in accordance with a second embodiment.<br/>[0014] FIG. 4 illustrates an example map depicting price multipliers and <br/>available <br/>providers in different geos, in accordance with an embodiment.<br/>[0015] FIG. 5 illustrates an example map depicting a service that is <br/>assigned to a <br/>provider and in which the provider is traveling from the provider's current <br/>location to an <br/>origin location, in accordance with an embodiment.<br/>[0016] FIG. 6 is an example user interface on a user application for <br/>displaying <br/>alternative service options, in accordance with an embodiment.<br/>[0017] FIG. 7 is an example user interface on a provider application for <br/>displaying <br/>alternative service options, in accordance with an embodiment.<br/>[0018] FIG. 8 illustrates example components of a computer used as part or <br/>all of the <br/>network system, the user client device, and/or the provider client device, in <br/>accordance with <br/>an embodiment.<br/>[0019] FIG. 9 is a flow chart illustrating the selection of alternative <br/>service options <br/>based on market status factors, in accordance with an embodiment.<br/>DETAILED DESCRIPTION<br/>[0020] The Figures and the following description describe certain <br/>embodiments by way <br/>of illustration only. One skilled in the art will readily recognize from the <br/>following <br/>description that alternative embodiments of the structures and methods <br/>illustrated herein may <br/>be employed without departing from the principles described herein. Reference <br/>will now be <br/>made to several embodiments, examples of which are illustrated in the <br/>accompanying figures. <br/>It is noted that wherever practicable similar or like reference numbers may be <br/>used in the <br/>figures and may indicate similar or like functionality.<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>[0021] Turning now to the specifics of the system architecture, FIG. 1 <br/>illustrates a <br/>system environment for an example network system 130. The network system 130 <br/>coordinates the transportation of persons and/or goods/items for a user (e.g., <br/>such as a rider) <br/>by a service provider (e.g., a provider of a vehicle). The provider uses a <br/>vehicle to provide <br/>the transportation to the user. In this example embodiment, the network system <br/>130 includes <br/>a trip management module 140, a trip monitoring module 145, a geo monitoring <br/>module 150, <br/>a demand prediction module 155, a geo or option selection module 160, a trip <br/>price <br/>estimation module 165, and various data stores including a trip data store <br/>180, a user data <br/>store 182, a provider data store 184, a provider inventory data store 186, and <br/>a geo data store <br/>188. These modules and data stores are not native components of a generic <br/>computer system, <br/>and provide structures and functions beyond generic functions of a computer <br/>system, as <br/>further described below.<br/>[0022] A user operates a client device 100 that executes a user application <br/>102 that <br/>communicates with the network system 130. The user operates the user <br/>application 102 to <br/>view information about the network system 130, and to make a request for <br/>service from the <br/>network system 130 for a delivery or transport service ("a trip") of the user <br/>(and, optionally, <br/>additional persons) and/or items, for example cargo needing transport. The <br/>user application <br/>102 determines an origin location or enables the user to specify an origin <br/>location and/or a <br/>destination location associated with the trip. An origin location and/or a <br/>destination location <br/>may be a location inputted by the user or may correspond to the current <br/>location of the user <br/>client device 100 as determined automatically by a location determination <br/>module (not <br/>shown) in the user client device 100, e.g., a global positioning system (GPS) <br/>component, a <br/>wireless networking system, or a combination thereof For purposes of <br/>simplicity, as <br/>described herein, an origin location can correspond to a start location for <br/>service (i) <br/>determined by the user application 102 (e.g., based on the current location of <br/>the user client <br/>device 100 using a GPS component), (ii) specified or selected by the user, or <br/>(iii) determined <br/>by the network system 130.<br/>[0023] According to examples herein, the user client device 100 can <br/>transmit a set of <br/>data (e.g., referred to herein as "service data") to the network system 130 <br/>over the network(s) <br/>120 in response to user input or operation of the user application 102. Such <br/>service data can <br/>be indicative of the user's interest in potentially requesting service (e.g., <br/>before actually <br/>confirming or requesting the service). For example, the user may launch the <br/>user application <br/>102 and specify an origin location and/or a destination location to view <br/>information about the <br/>network service before making a decision on whether to request service. In <br/>some<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>6<br/>embodiments, the user operates the user application 102 in a default mode in <br/>which the user <br/>application 102 presents a single service option in response to receiving the <br/>service data. In <br/>other embodiments, the user application 102 provides a feature to enable the <br/>user to operate <br/>the user application 102 in an option-spectrum feature mode in which the user <br/>application <br/>102 presents various service options in response to receiving service data <br/>from the user.<br/>[0024] The user may want to view information about the average or estimated <br/>time of <br/>arrival for pick up by a provider, the estimated time to the destination, the <br/>price, the available <br/>service types, etc. Depending on implementation, the service data can include <br/>the origin <br/>and/or destination location information, user information (e.g., identifier), <br/>application <br/>information (e.g., version number), device identifier or type, etc. According <br/>to some <br/>examples, each time the user modifies the origin and/or destination location, <br/>the user <br/>application 102 can generate and transmit the service data to the network <br/>system 130. Still <br/>further, in one example, the service data can include data used by the demand <br/>prediction <br/>module 155 to predict user demand in geos. In some embodiments, the service <br/>data <br/>comprises a request for an estimated cost or price (or fare) for the service <br/>and includes at <br/>least the origin location and the destination location specified by the user. <br/>Additionally, in <br/>one example, in response to transmitting the service data, the user <br/>application 102 can receive <br/>a set of service options from the network system 130 to be displayed on the <br/>user client device <br/>100.<br/>[0025] Once the user confirms or orders a service via the user application <br/>102, the user <br/>application 102 can generate data corresponding to a request for the service <br/>through the <br/>network system 130 (e.g., also referred to herein as a "trip request"). In <br/>some embodiments, <br/>the network system 130 uses information from the trip request to match the <br/>user with one of a <br/>plurality of available providers. Depending on implementation, the trip <br/>request can include <br/>user or device information (e.g., a user identifier, a device identifier), a <br/>service type (e.g., <br/>vehicle type) and/or selected service option (such as described herein), an <br/>origin location, a <br/>destination location, a payment profile identifier, and/or other data. The <br/>network system 130 <br/>selects a provider from a set of providers, such as based on the provider's <br/>current location <br/>and status (e.g., offline, online, available, etc.) and/or information from <br/>the trip request (e.g., <br/>service type, origin location, and/or destination location), to provide the <br/>service for the user <br/>and transport the user from the origin location to the destination location. <br/>In other <br/>embodiments, responsive to predicting that user demand will be over a <br/>threshold volume in a <br/>given geographic region, the network system 130 provides multiple service <br/>options to the <br/>user, as discussed below. The user application 102 further enables a user to <br/>provide a<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>7<br/>performance rating for a provider upon completion of a trip. In one <br/>embodiment, the rating is <br/>provided on a scale of one to five, five being the maximal (best) rating. In <br/>an alternative <br/>embodiment, the rating is a thumbs up or thumbs down rating indicating either <br/>a positive or <br/>negative experience.<br/>[0026] The provider operates a client device 110 executing a provider <br/>application 104 <br/>that communicates with the network system 130 to provide information <br/>indicating whether <br/>the provider is available or unavailable to provide transportation services to <br/>users. The <br/>provider application 104 can also present information about the network <br/>service to the <br/>provider, such as invitations to provide service, navigation instructions, map <br/>data, etc. In one <br/>embodiment, the provider application 104 enables the provider to provide <br/>information <br/>regarding availability of the provider by logging into the network system 130 <br/>and activating a <br/>setting indicating that they are currently available to provide service. The <br/>provider <br/>application 104 also provides the current location of the provider or the <br/>provider client device <br/>110 to the network system 130. Depending on implementation, the current <br/>location may be a <br/>location inputted by the provider or may correspond to the current location of <br/>the provider <br/>client device 110 as determined automatically by a location determination <br/>module (not <br/>shown) in the provider client device 110, e.g., a GPS component, a wireless <br/>networking <br/>system, or a combination thereof The provider application 104 further allows a <br/>provider to <br/>receive, from the trip management module 140, an invitation message to provide <br/>a service for <br/>a requesting user, and if the provider accepts via input, the provider <br/>application 104 can <br/>transmit an acceptance message to the trip management module 140. The trip <br/>management <br/>module 140 can subsequently provide information about the provider to the user <br/>application <br/>102. As another embodiment, the provider application 104 can enable the <br/>provider to view a <br/>list or spectrum of current service options corresponding to received trip <br/>requests and to <br/>select particular trip request(s) to fulfill. The trip management module 140 <br/>selects service <br/>options for display to the provider based on predicted demand over a specified <br/>time period <br/>within a threshold distance of the provider's current location or geo, as <br/>discussed below with <br/>respect to FIG. 7.<br/>[0027] In some embodiments, the service options presented through the <br/>provider <br/>application 104 include a guaranteed price multiplier (and thus a higher total <br/>trip price) if the <br/>provider accepts and fulfills a trip request during an upcoming period of <br/>predicted high <br/>demand. For example, a service option might include a guaranteed 1.8 price <br/>multiplier if the <br/>provider accepts and fulfills a trip request from geo 1 between 5:00 and 6:00 <br/>pm on a <br/>particular Saturday. In some embodiments, the provider incurs a financial <br/>penalty if the<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>8<br/>provider accepts a service, but does not fulfill the corresponding trip <br/>request (e.g., <br/>subsequently cancels). Additionally or alternatively, the pricing of a <br/>provider service option <br/>might change over time as the desired departure time approaches. For example, <br/>the demand <br/>prediction module 155 might predict on Thursday morning a period of high user <br/>demand the <br/>following evening between 7:00 and 8:00 pm. A provider who commits on Thursday <br/>to <br/>accepting and fulfilling trip requests during this time period might receive a <br/>higher <br/>guaranteed price multiplier than a provider who commits on Friday afternoon.<br/>[0028] The provider application 104 can also receive routing information <br/>from the trip <br/>management module 140. The provider application 104 enables a provider to <br/>provide a <br/>rating for a user upon completion of a trip. In one embodiment, the rating is <br/>provided on a <br/>scale of one to five, five being the maximal (best) rating.<br/>[0029] The user client device 100 and provider client device 110 are <br/>portable electronic <br/>devices such as smartphones, tablet devices, wearable computing devices (e.g., <br/>smartwatches) or similar devices. Alternatively, the provider client device <br/>110 can <br/>correspond to an on-board computing system of a vehicle. Client devices <br/>typically have one <br/>or more processors, memory, touch screen displays, wireless networking system <br/>(e.g., IEEE <br/>802.11), cellular telephony support (e.g., LTE/GSM/UMTS/CDMA/HSDPA, etc.), and <br/>location determination capabilities.<br/>[0030] The user client device 100 and the provider client device 110 <br/>interact with the <br/>network system 130 through client applications configured to interact with the <br/>network <br/>system 130. The applications 102 and 104 of the user client device 100 and the <br/>provider <br/>client device 110, respectively, can present information received from the <br/>network system <br/>130 on a user interface, such as a map of the geo, and the current location of <br/>the user client <br/>device 100 or the provider client device 110. The applications 102 and 104 <br/>running on the <br/>user client device 100 and the provider client device 110 can determine the <br/>current location <br/>of the device and provide the current location to the network system 130.<br/>[0031] In one embodiment, the trip management module 140 can be configured <br/>as a <br/>communicative interface between the user application 102, the provider <br/>application 104, <br/>and/or the various modules and data stores in the network system 130, and is <br/>one means for <br/>performing this function. The trip management module 140 can receive provider <br/>availability <br/>status information and current location information from the provider <br/>application 104 and <br/>update the provider inventory data store 186 with the availability status. The <br/>trip <br/>management module 140 can also receive trip requests from the user application <br/>102 and <br/>creates corresponding trip records in the trip data store 180. According to an <br/>example, a trip<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>9<br/>record corresponding to a trip request can include or be associated with a <br/>trip ID, a user ID, <br/>an origin location, a destination location, a service type, pricing <br/>information, and/or a status <br/>indicating that the corresponding trip request has not been processed. <br/>According to one <br/>example, when a provider accepts the invitation message to service the trip <br/>request for the <br/>user, the trip record can be updated with the provider's information as well <br/>as the provider's <br/>location and the time when the trip request was accepted. Similarly, location <br/>and time <br/>information about the service as well as the cost for the service can be <br/>associated with the trip <br/>record.<br/>[0032] The trip management module 140 can also send an invitation message <br/>to an <br/>available provider via the provider client device 110 responsive to receiving <br/>user input <br/>comprising selection of a service option, and receives a response to the <br/>invitation message <br/>from the provider through the provider application 104. In one example, the <br/>trip management <br/>module 140 can also send information to the provider client device 110 at a <br/>particular time <br/>based on estimated travel times computed by the option selection module 160. <br/>In one <br/>embodiment, the trip management module 140 optimizes resource redistribution <br/>by <br/>computing the time it takes for a provider to initiate the service for a user <br/>based on an <br/>estimated travel time and/or distance from the provider's current location to <br/>the origin <br/>location and the requested departure time of the trip. For example, if the <br/>estimated travel <br/>time to the origin location is ten minutes and the requested departure time is <br/>in twenty <br/>minutes, the trip management module 140 can select a provider from the geo <br/>associated with <br/>the selected service option and transmit the invitation message to the <br/>selected provider in ten <br/>minutes.<br/>[0033] In some embodiments, the provider's current location is in a <br/>different <br/>geographic region than the origin location. The trip management module 140 can <br/>transmit <br/>provider incentives to the provider application 104 to incentivize the <br/>provider to travel from <br/>the provider's current location towards a geo nearby or a geo of the origin <br/>location. For <br/>example, the provider is paid to travel from the provider's current location <br/>to the origin <br/>location even before the provider is selected to provide a service. The trip <br/>management <br/>module 140 can display the payment as a standalone incentive or as a component <br/>of the <br/>provider's income from a specific trip.<br/>[0034] In one embodiment, during the trip, the trip monitoring module 145 <br/>receives <br/>information (e.g., periodically) from the provider application 104 indicating <br/>the location of <br/>the provider's vehicle and/or telematics information (e.g., indications of <br/>current speed, <br/>acceleration/deceleration, events, stops, and so forth). The trip monitoring <br/>module 145 stores<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 <br/>PCT/IB2018/050795<br/>the information in the trip data store 180 and can associate the information <br/>with the trip <br/>record.<br/>[0035] The <br/>geo monitoring module 150 determines price multipliers in specified geos<br/>as determined by the network system 130, and sends the price multiplier data <br/>to the geo data <br/>store 188 for storage. Depending on implementation, a geo can be one of many <br/>geos that can <br/>be user-defined regions, overlapping regions, regions of different sizes or <br/>dimensions, and/or <br/>regions defined by a coordinate system or array of shapes (e.g., squares, <br/>hexagons, etc.). In <br/>one example, a geo can be a smaller geo or sub-geo of a larger geo. Each geo <br/>can have an <br/>identifier, be defined by a set of location data points or coordinates, and/or <br/>be associated with <br/>additional geos (e.g., with nearby geos or overlapping geos, etc.). For <br/>purposes of the <br/>description, in various embodiments, a price multiplier is a scaling modifier <br/>based on <br/>resource supply and user demand that is applied to an initial or default trip <br/>price to determine <br/>a final trip price. For example, the geo monitoring module 150 determines a <br/>price multiplier <br/>for a geo by querying the trip data store 180 for the number of trips <br/>requested with an origin <br/>location in the geo and by querying the provider inventory data store 186 for <br/>the number of <br/>available providers located in a geo (e.g., based on location and provider <br/>state). As an <br/>addition or an alternative, in another example, the geo monitoring module 150 <br/>can determine <br/>the price multiplier for a geo based on the number of users that are operating <br/>the user <br/>application 102 but have not yet requested service in the geo. The geo <br/>monitoring module <br/>150 can update the price multiplier for a geo periodically (e.g., perform the <br/>computation <br/>every three minutes or five minutes, etc.) or based on a schedule.<br/>[0036] <br/>According to an example, the geo monitoring module 150 computes the price<br/>multiplier for a geo based, at least in part, on the number of requested trips <br/>that originated in <br/>the geo, the number of users operating the client application 102 in the geo, <br/>and/or the <br/>number of available providers located in the geo. In one example, the geo <br/>monitoring <br/>module 150 can determine a ratio of requested trips and available providers, <br/>and if the ratio <br/>of requested trips to available providers is over a threshold, the geo <br/>monitoring module 150 <br/>computes a price multiplier based on the ratio and applies it to the geo. In <br/>some <br/>embodiments, the geo monitoring module 150 applies progressively higher price <br/>multipliers <br/>as the ratio of trip requests to available providers increases.<br/>[0037] In <br/>some examples, the demand prediction module 155 predicts the volume and<br/>timing of an upcoming demand peak at or near the vicinity of an origin <br/>location. In one <br/>embodiment, the demand prediction module 155 predicts volume and timing <br/>responsive to <br/>the trip management module 140 detecting that user interest or demand will be <br/>over a<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>11<br/>threshold volume. User interest in a geo can be determined by determining the <br/>number of <br/>users who operate the user application 102 and/or specify service data having <br/>an origin <br/>location in the geo or set of adjacent or nearby geos during a time period. In <br/>another <br/>embodiment, the demand prediction module 155 predicts volume and timing based <br/>on the <br/>number of trip arrivals at the origin location or near the origin location <br/>within a specified time <br/>period. For example, the demand prediction module 155 can predict user demand <br/>at the end <br/>of a baseball game based on the arrival volume at the stadium at a time period <br/>before the <br/>beginning of the game. In other embodiments, the demand prediction module 155 <br/>considers <br/>both trip arrivals and the number of trip requests when predicting the volume <br/>and timing of <br/>an upcoming demand peak.<br/>[0038] In some embodiments, the demand prediction module 155 generates data <br/>regarding the volume and timing of future demand based on future trip <br/>requests¨that is, <br/>requests for trips where the requestor is not seeking to be picked up at the <br/>time the request is <br/>being made. The demand prediction module 155 generates data regarding trip <br/>origins, trip <br/>destinations, trip timing, and/or trip length, and uses the data to forecast <br/>future demand for <br/>trips and the need to provide supply to meet that demand. In some embodiments, <br/>the demand <br/>prediction module 155 sends the data to the geo monitoring module 150, which <br/>uses the data <br/>to estimate future prices.<br/>[0039] In some embodiments, the demand prediction module 155 considers <br/>periodic <br/>and non-periodic events when gauging user interest. For example, if the trip <br/>management <br/>module 140 receives service data from a number of user client devices 100 <br/>(e.g., detects a <br/>number of users viewing the service information or indicating an intent to <br/>request service) <br/>and determines that the user client devices 100 are located at or within a <br/>baseball stadium or <br/>in a geo that the baseball stadium is located in, the trip management module <br/>140 will instruct <br/>the demand prediction module 155 to a monitor a feed of the current score <br/>and/or estimated <br/>time remaining in the game to predict when the demand is likely to be high. <br/>The effect of <br/>different scores at different times in a game can then be correlated with <br/>demand (e.g., demand <br/>is low before the end of a tight game because spectators want to stay, but <br/>higher if the game <br/>is a blow-out with many fans leaving early to beat the rush).<br/>[0040] In one embodiment, the demand prediction module 155 employs a <br/>machine <br/>learning module to improve predictions of demand over time. In response to <br/>receiving user <br/>input comprising a request for information from the network system 130, the <br/>trip <br/>management module 140 sends an instruction to an option selection module 160 <br/>to select <br/>geos and available providers for inclusion as service options to present to <br/>the user. In various<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>12<br/>embodiments, for each set of received service data, the option selection <br/>module 160 selects <br/>multiple geos for inclusion as service options, such that each geo serves and <br/>is served by <br/>multiple other geos.<br/>[0041] The option selection module 160 selects service options based on <br/>global <br/>optimization across geos within a threshold distance of the origin location or <br/>the origin geo of <br/>the user. In some embodiments, the option selection module 160 determines the <br/>threshold <br/>distance based on the desired departure time. For example, if the desired <br/>departure time is in <br/>30 minutes, the option selection module 160 might include geos 1, 2, and 3, <br/>but if the desired <br/>departure time is in 35 minutes, the option selection module 160 might also <br/>include geo 4 <br/>when determining the set of service options to be presented to the user.<br/>[0042] The option selection module 160 uses a number of market status <br/>factors in <br/>selecting service options, including the origin and destination locations, the <br/>desired departure <br/>time, the current demand for user service, predictions of future demand <br/>calculated by the <br/>demand prediction module 155, the number and location of available providers, <br/>and/or <br/>pricing information in geos within a threshold distance of the origin location <br/>or the origin geo <br/>of the user. In some embodiments, the market status factors also include, for <br/>each of the <br/>available providers located with a threshold distance of the origin location <br/>or the origin geo <br/>of the user, the distance and estimated time from the provider's current <br/>location to the origin <br/>location.<br/>[0043] After any given time period, the estimated demand for that period <br/>is compared <br/>to the actual demand (i.e., how many trips were actually requested). The <br/>difference between <br/>the predicted and actual demand can correspond to an error margin that is <br/>inputted into the <br/>model. If the predicted demand is less than the actual demand, the model is <br/>adjusted such <br/>that future predictions of demand for similar time periods are larger. <br/>Conversely, if the <br/>predicted demand exceeded the actual demand, future predictions will be lower. <br/>Thus, the <br/>model is improved over time to more accurately predict the true demand. The <br/>model can also <br/>respond dynamically to changes in demand pattern.<br/>[0044] To select service options to present to the user, the option <br/>selection module 160 <br/>uses the market status factors to select geos and available providers. For <br/>example, in <br/>response to predicting that a period of user demand in a geo will be over a <br/>threshold volume, <br/>the demand prediction module 155 sends an instruction to the option selection <br/>module 160 to <br/>query the geo data store 188 for the price multipliers of geos that are within <br/>a threshold <br/>distance of the origin location or the geo of the origin location (e.g., <br/>within a predefined <br/>distance, such as one mile or two miles away from the origin location or the <br/>geo of the origin<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>13<br/>location, or within a predefined number of adjacent geos, such as two or three <br/>geos away <br/>from the origin location or the geo of the origin location). After receiving <br/>the requested data <br/>about these nearby geos from the geo data store 188, the option selection <br/>module 160 <br/>analyzes the data and selects a set of geos for inclusion in the spectrum (or <br/>a set or list) of <br/>service options that will be presented to the user. In one embodiment, the <br/>option selection <br/>module 160 selects all nearby geos. In another embodiment, the option <br/>selection module 160 <br/>selects the geo of the origin location and all adjacent geos. In still other <br/>embodiments, the <br/>option selection module 160 selects geos with varying price multipliers or <br/>modifiers. For <br/>example, the option selection module 160 might select geos with price <br/>multipliers of 1.0x, <br/>2.5x, and 3.0x, respectively. In the various embodiments, the option selection <br/>module 160 <br/>considers the current (or alternatively, the forecasted) ratio of supply and <br/>demand and the <br/>applicable price modifiers in nearby geos when selecting geos for inclusion in <br/>the set of <br/>service options. For example, if the option selection module 160 determines <br/>that there is high <br/>demand for service relative to the number of available providers in geo 3 and <br/>that the ratio is <br/>lower in other nearby geos, the option selection module 160 might include <br/>fewer or no <br/>service options from geo 3 in response to receiving a set of service data with <br/>an origin <br/>location in geo 1. In some embodiments, the option selection module 160 also <br/>queries the <br/>demand prediction module 155 for the predicted user demand in the selected <br/>geos within a <br/>threshold amount of time of the desired departure time.<br/>[0045] The option selection module 160 also queries the provider inventory <br/>data store <br/>186 for a list of available providers in the selected geos, including the <br/>locations of the <br/>available providers in the geos. For each selected geo, the option selection <br/>module 160 <br/>calculates the average distance and/or estimated time from the current <br/>locations of available <br/>providers to the origin location. In response to receiving the data regarding <br/>these candidate <br/>providers from the provider inventory data store 186, the option selection <br/>module 160 selects <br/>the available rides for inclusion in the spectrum of service options presented <br/>on the user client <br/>device 100 based on user input regarding order time. For example, if the user <br/>is checking <br/>service options and costs with an order time of "now," the option selection <br/>module 160 will <br/>select different service options than if the user selected an order time of <br/>"20 minutes from <br/>now."<br/>[0046] In some embodiments, the option selection module 160 also queries <br/>the trip data <br/>store 180 for trip data associated with trip requests made by other users of <br/>the network system <br/>130 within a threshold amount of time of the user's trip request. Additionally <br/>or <br/>alternatively, the option selection module 160 queries the trip data store 180 <br/>for trip data<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>14<br/>associated with trip requests with origin locations within a threshold <br/>distance of the origin <br/>location or the origin geo of the user. In some embodiments, the trip data <br/>includes the origin <br/>locations, destination locations, route information, desired departure times, <br/>and/or user-<br/>provider matching information associated with the trip requests.<br/>[0047] According to an example, after receiving the requested data from the <br/>geo data <br/>store 188, the provider inventory data store 186, the demand prediction module <br/>155, and the <br/>trip data store 180, the option selection module 160 selects service options <br/>to present to the <br/>user. In one embodiment, for each of the selected geos, the option selection <br/>module 160 <br/>selects candidate providers for inclusion as service options. In some <br/>embodiments, the <br/>candidate provider is a representation of available providers located within a <br/>threshold <br/>distance of each other in a selected geo. For example, if provider A, provider <br/>B, and provider <br/>C are all available to provide service and are located within two blocks of <br/>each other in geo 1, <br/>the option selection module 160 treats the three providers as a single <br/>"candidate provider" for <br/>purposes of selecting service options to present to the user.<br/>[0048] In some embodiments, for each of the selected geos, the option <br/>selection module <br/>160 selects the candidate provider with the shortest estimated time of pickup <br/>(ETP) at the <br/>origin location responsive to a user requesting an order time or a desired <br/>departure time of <br/>"now." For example, assume that the option selection module 160 selects geo 3 <br/>for inclusion <br/>in the spectrum of service options presented to a user located in geo 1. If <br/>the provider <br/>inventory data store reports that, in geo 3, candidate provider 1 <br/>(representing providers A, B, <br/>and C) is approximately 4 minutes away from the origin location, candidate <br/>provider 2 <br/>(representing providers D, E, F, G, and H) is approximately 7 minutes away <br/>from the origin <br/>location, and candidate provider 3 (representing providers I and J) is <br/>approximately 10 <br/>minutes away from the origin location, the option selection module 160 will <br/>select candidate <br/>provider A for inclusion as a service option. In some embodiments, the option <br/>selection <br/>module 160 will also include provider B and/or provider C as service options <br/>if the option <br/>selection module 160 determines that there is limited provider availability in <br/>the other <br/>selected geos.<br/>[0049] Similarly, in one example, if the option selection module 160 <br/>determines that <br/>the ETP at the origin location is similar or the same for providers in <br/>different geos, the option <br/>selection module 160 will select for inclusion the candidate provider located <br/>in the geo with <br/>the lowest price multiplier. For example, assume that candidate provider A <br/>(located in geo <br/>2), candidate provider B (located in geo 4), and candidate provider C (located <br/>in geo 5) are all <br/>15 minutes away from the user. If geo 5 has the lowest price multiplier of the <br/>three geos, the<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>option selection module 160 will select candidate provider C for inclusion as <br/>a trip or service <br/>option.<br/>[0050] The option selection module 160 determines a cut-off point for <br/>including <br/>candidate providers as service options based on the price multiplier in the <br/>provider's geo and <br/>the ETP at the nearby origin location. In one embodiment, the option selection <br/>module 160 <br/>selects a ceiling or maximum threshold such that when the ETP at the nearby <br/>origin location <br/>is a specific multiplier of the ETP in the user's geo, the option selection <br/>module 160 stops <br/>searching for additional candidate providers to include in the service options <br/>presented to the <br/>user. In other embodiments, the option selection module 160 stops searching <br/>for additional <br/>candidate providers once the estimated trip price begins to increase after <br/>reaching its lowest <br/>point. After the option selection module 160 selects the service options to <br/>present to the user, <br/>the option selection module 160 queries the trip price estimation module 165 <br/>for estimated <br/>trip price for each of the selected service options.<br/>[0051] The trip price estimation module 165 estimates or determines the <br/>cost for a trip <br/>based on data from the service data. In one embodiment the cost can be based <br/>on the origin <br/>location, the destination location, the route to travel, the estimated <br/>duration of the service, the <br/>service type, the price multiplier, and/or time when the service is to be <br/>provided (e.g., now or <br/>in twenty minutes).<br/>[0052] In one embodiment, the following example illustrate how provider <br/>selection can <br/>be globally optimized. Let R1,1;t be the trip flow (volume) from geo i to geo <br/>j (which is <br/>estimated based on selection of service options and usual on-demand request <br/>volume) at time <br/>t E T. Let C'1;t be the open cars (which is estimated based on the trip flow <br/>into a geo and <br/>usual driver login schedule) in geo i at time t ET. Let Lk;t be the usual net <br/>open cars coming <br/>into the marketplace in geo k at time t ET. Let Dk,i;t be the provider <br/>selection decision for <br/>providers in geo k to fulfill trip requests from geo i at time t ET. Let -<br/>cii;t be the travel time <br/>from geo i to geo j at time t E T. Finally, let f(k,i,j;t) be the price (or <br/>fare) for a trip from <br/>geo i to geo j fulfilled by providers from geo k at time t ET. The global <br/>provider selection <br/>optimization problem can be formulated as follows:<br/>Maximize: aEk,ut f(k,i,j;t)+ f3MGV<br/>Such that Ei Rij;t+T(k,i,t) = Ek Dk,i;t Vi,Vt E T<br/>Dk,i;t Ck;t Vk,Vt E T<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>16<br/>Ck;t Ri,k;s Dk,j;s Lk;s Vk,Vt E T<br/>s<t-T(i,k;t) j s<t s<t<br/>where Tis a time range in which the provider selection decisions are <br/>optimized, MGV is some <br/>definition of overall market-generated value, measuring the total values for <br/>the users, the <br/>providers, and the marketplace generated by responding to the given demand.<br/>[0053] Thus, in this example, the option selection module 160 adds the sum <br/>(over <br/>geos k, i,j and times t) of the prices of trips going from geo /to geo j <br/>fulfilled by provider(s) <br/>in geo k at time t times a constant \alpha and the market-generated value <br/>times a constant <br/>\beta, such that the sum of the trip flow between geos! and j in time section <br/>t after the travel <br/>time between geos k and i equals the sum (over geos k) of the provider <br/>selection decisions on <br/>providers in geo k to fulfill trips from geo i for all of geo i and for all <br/>times, and such that the <br/>sum of the provider selection decisions on providers in geo k to fulfill trips <br/>from some geo i is <br/>less than or equal to the open cars in geo k for all of geo k and for all <br/>times, and such that the <br/>open cars in geo k equals the number of trips ending in geo k at time t minus <br/>the number of <br/>cars selected away from geo k plus the number of open cars moving or logging <br/>into geo k for <br/>all geo k and for all time t.<br/>[0054] After the option selection module 160 selects the service options to <br/>present to the <br/>user, the option selection module 160 queries the trip price estimation module <br/>165 for estimated <br/>trip price for each of the selected service options.<br/>[0055] The trip price estimation module 165 estimates the price for a trip <br/>requested in a <br/>trip request. The trip price estimate represents an estimate of the trip price <br/>if a user was <br/>assigned to a provider at a point in time when the estimate was generated or <br/>at some future <br/>point in time. A cost or trip price estimate may be a single determined price <br/>or a range of <br/>prices within which the trip price might be. In some embodiments, the trip <br/>price estimation <br/>module 165 determines the probability that the actual cost or trip price will <br/>be less than or <br/>equal to the trip price estimate, or that the actual trip price will fall <br/>within a determined price <br/>range of the trip price estimate. The trip price estimation module 165 can <br/>also generate an <br/>estimate of the minimum trip price for a specified timeframe, and can estimate <br/>when that <br/>minimum cost or trip price might occur.<br/>[0056] The trip price estimation module 165 uses models of the cost or trip <br/>price to <br/>generate a cost or trip price estimate within a geo. The trip price models can <br/>be based on <br/>underlying factors that can impact the trip price, such as the duration of the <br/>trip, the trip <br/>distance, the origin location, the destination, an approximate trip departure <br/>time, an estimated<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>17<br/>time of arrival ("ETA") at the destination, traffic conditions, the number of <br/>passengers on the <br/>trip, and/or the type of the provider (e.g., the type of vehicle) servicing <br/>the trip. The trip price <br/>estimation module 165 may also use historical trip price data to generate the <br/>trip price <br/>estimate. For example, the trip price estimation module 165 may use historical <br/>traffic <br/>condition data to predict traffic during the trip, and how that traffic <br/>impacts the trip price.<br/>[0057] The trip price estimation module 165 may also generate the estimated <br/>trip price <br/>based on the supply of resources and the demand for trips in the geo of the <br/>nearby origin <br/>location. For example, if many providers are available to provide trips as <br/>compared to the <br/>number of potential users that may request trips, the estimated trip price may <br/>be lower. <br/>Similarly, if many users are requesting trips as compared to the number of <br/>available <br/>providers, the estimated trip price may be higher. In some embodiments, the <br/>trip price <br/>estimation module 165 applies a price multiplier during periods of peak user <br/>demand.<br/>[0058] The trip price estimation module 165 uses a price or fare <br/>calculation scheme to <br/>estimate a trip price for each of the selected service options. In one <br/>embodiment, the total <br/>estimated trip price comprises a trip price and a pickup price. The trip price <br/>includes or can <br/>be based on the estimated duration of the trip from the nearby origin location <br/>to the <br/>destination location and/or the estimated distance traveled, the length of the <br/>trip, and the price <br/>multiplier in the geo in which the provider is currently located. The pickup <br/>price includes the <br/>estimated duration and/or distance or length of the trip from the provider's <br/>current location to <br/>the nearby origin location and the price multiplier in the provider's geo. In <br/>some <br/>embodiments, the pickup price is zero if the nearby origin location and <br/>provider location are <br/>within a small or predefined estimated travel time or provider selection <br/>radius (e.g., 5 <br/>minutes).<br/>[0059] After the trip price estimation module 165 calculates the estimated <br/>trip prices for <br/>each of the selected service options, the trip price estimation module 165 <br/>returns the total <br/>estimated trip prices to the option selection module 160, which sends the <br/>service options with <br/>the associated trip price estimates for display on the user client device 100. <br/>In one <br/>embodiment, the service options are automatically pushed to the user client <br/>device 100 <br/>responsive to the user subscribing to a real-time information push. In other <br/>embodiments, the <br/>service options are displayed on the user client device 100 responsive to the <br/>user specifying <br/>the origin location and/or the destination location or providing user input <br/>comprising a <br/>request for information through the user application 102. In one embodiment, <br/>the option <br/>selection module 160 orders the list of service options from quickest (e.g., <br/>the earliest the <br/>user can receive service) to slowest. In another embodiment, the option <br/>selection module 160<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>18<br/>orders the list from least expensive to most expensive. In still other <br/>embodiments, responsive <br/>to the demand prediction module 155 predicting that user demand will be over a <br/>threshold <br/>volume, the option selection module 160 orders the list of service options <br/>sent to the user <br/>client device 100 such that providers who are located further away are <br/>displayed first. For <br/>example, if the demand prediction module 155 determines that the demand at a <br/>geo will be <br/>over a threshold volume in twenty minutes, the option selection module 160 <br/>will order the list <br/>of service options presented to users considering making a trip request from <br/>the geo such that <br/>providers who are located approximately twenty minutes away are presented <br/>first.<br/>[0060] In some embodiments, the service options are associated with single <br/>rider <br/>transportation services whereby a provider transports a single user from an <br/>origin location to <br/>a destination location. In other embodiments, the service options correspond <br/>to multiple rider <br/>transportation services, in which a single provider transports multiple users <br/>from origin <br/>locations to destination locations. In still other embodiments, the service <br/>options include <br/>both single rider and multiple rider transportation services based on user <br/>input. For example, <br/>a user may specify that he or she only wishes to view service options <br/>associated with single <br/>rider services or that multiple rider services should be presented first in <br/>the list of service <br/>options. Additionally, in some examples, the service options include <br/>transportation services <br/>already assigned to providers whereby the provider provides one or more single <br/>or multiple <br/>rider transportation services to one or more other user while traveling from <br/>the provider's <br/>current location to the origin location, as described below with respect to <br/>FIG. 5.<br/>[0061] The option selection module 160 optimizes the order in which the <br/>service <br/>options are presented to the user through the user application 102. For <br/>example, if set of <br/>service data associated with a user has a desired departure time of 30 minutes <br/>from the <br/>current time, the option selection module 160 orders the list of service <br/>options such that <br/>service options associated with candidate providers who are roughly 30 minutes <br/>away from <br/>the origin location are presented first. As the current time becomes closer to <br/>the desired <br/>departure time, the option selection module 160 re-orders the service options <br/>such that <br/>service options associated with candidate providers who are closer in time to <br/>the desired <br/>departure time are presented first.<br/>[0062] The demand prediction module 155 trains an optimization model to <br/>predict user <br/>demand over upcoming time periods using stored data including historical trip <br/>data and data <br/>regarding service options presented to and selected by users. The demand <br/>prediction module <br/>155 forms a set of training data that serves as input to generate and train <br/>the optimization <br/>model. In some embodiments, the training data includes feature vectors of sets <br/>of service<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 <br/>PCT/IB2018/050795<br/>19<br/>data from past trips taken by users, including origin locations, destination <br/>locations, desired <br/>departure times, service options presented to users, and service options <br/>selected by users. <br/>Additionally or alternatively, the training data includes sets of service data <br/>corresponding to <br/>requests for transportation services in the future ¨ that is, requests for <br/>services where the <br/>requestor is not seeking to be picked up at the time the request is being <br/>made. In still other <br/>embodiments, the training data includes provider availability and location <br/>data (e.g., data <br/>regarding an available provider's relocation from one geo to another).<br/>[0063] In one embodiment, the demand prediction module 155 uses the <br/>optimization <br/>model to improve predictions of demand over time (how may rides were actually <br/>requested). <br/>The difference between the predicted and actual demand is an error margin that <br/>is fed back <br/>into the optimization model. Thus, the optimization mode is improved over time <br/>to more <br/>accurately predict the true demand. The model can also respond dynamically to <br/>changes in <br/>demand pattern.<br/>[0064] In some embodiments, the optimization model is used to optimize trip <br/>requests <br/>received over a time span (e.g., the next 30 minutes) over a range of geos <br/>within a threshold <br/>distance of each other. For example, as discussed above, in response to <br/>receiving a set of <br/>service data through the user application 102, the option selection module 160 <br/>applies the <br/>optimization model to determine which geos and candidate providers to include <br/>in the set of <br/>service options presented to the user.<br/>[0065] In response to predicting user demand over time, the optimization <br/>model can <br/>also be used to predict pricing information. For example, the optimization <br/>model might <br/>predict pricing in a geo every three minutes for the next 30 minutes or might <br/>predict pricing <br/>for all geos within a threshold distance every 10 minutes for the next 24 <br/>hours.<br/>[0066] In still other embodiments, the trip management module 140 uses the <br/>output of <br/>the optimization model to profile providers and users of the network system <br/>130. For <br/>example, the trip management module 140 can use data about service options <br/>presented to <br/>and selected by users to determine the user's usual schedule and sketch user <br/>itineraries and <br/>trip patterns. Further, the trip management module 140 can use data regarding <br/>service <br/>options presented to and selected by providers and provider location data to <br/>determine a <br/>provider's performance in different geos and provider sensitivity to pricing, <br/>distance, and <br/>other trip-related properties.<br/>[0067] The trip management module 140 uses predictions generated by the <br/>optimization model to position providers across and within geos to optimize <br/>the number of <br/>trip requests that the network system 130 is able to fulfill. In some <br/>embodiments, the trip<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>management module 140 sends provider incentives to the provider application <br/>104 to <br/>incentivize the provider to travel from the provider's current location to <br/>other geos or other <br/>regions of the same geo during a predicted period of high demand. The trip <br/>management <br/>module 140 might display the payment as a standalone incentive or as a <br/>component of the <br/>provider's income from a specific trip.<br/>[0068] The trip data store 180 maintains a record of each in-progress <br/>and/or each <br/>completed trip coordinated by the network system 130. More specifically, each <br/>trip provided <br/>by a provider to a user is characterized by a set of attributes (or <br/>variables), which together <br/>form a trip record that is stored in the trip data store 180. The attributes <br/>describe aspects of <br/>the provider, the user, and the trip. In one embodiment, each trip record <br/>includes or is <br/>associated with a trip identifier (ID), a user ID, a provider ID, the origin <br/>location, the <br/>destination location, the duration of the trip, the service type for the trip, <br/>estimated time of <br/>pick up, actual time of pickup, and provider rating by user, user rating by <br/>provider, price <br/>information, market information, and/or other environmental variables as <br/>described below. <br/>The variables for the trip record are thus drawn from multiple sources, <br/>including the user's <br/>master and usage records in the user data store 182, the provider's master and <br/>operational <br/>records in the provider data store 184, and specific variables captured and <br/>received during <br/>each trip.<br/>[0069] The provider data store 184 stores account and operational <br/>information for each <br/>provider who participates in the network system 130. For each provider, the <br/>provider data <br/>store 184 stores one or more database records associated with the provider, <br/>including both <br/>master data and usage data. In some examples, master data for a provider <br/>includes or is <br/>associated with the provider's name, provider's license information, insurance <br/>information, <br/>vehicle information (year, make, model, vehicle ID, license plate), address <br/>information, cell <br/>phone number, payment information (e.g., credit card number), sign-up date, <br/>provider service <br/>type (regular, luxury, van, etc.), device type (e.g., type of cell phone), <br/>platform type (e.g., <br/>i0S, Android), application ID, and/or application version for the provider <br/>application 104. <br/>The usage data can correspond to historical information about the provider's <br/>services <br/>received, provided, canceled, and/or completed, such as the times, locations, <br/>and routes <br/>traveled associated with such services.<br/>[0070] The provider inventory data store 186 stores provider availability <br/>status <br/>information received from the trip management module 140, including whether <br/>the provider <br/>is available for matching and the location of the provider (which gets updated <br/>periodically). <br/>When the trip management module 140 receives a trip request, the trip <br/>management module<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>21<br/>140 determines, from the provider inventory data store 186, which providers <br/>are potential <br/>candidates to pick up the user for the newly created trip. When the network <br/>system 130 <br/>marks a trip record as complete, the network system 130 can add the provider <br/>back into the <br/>inventory of available providers in the provider inventory data store 186.<br/>[0071] FIG. 2 is an interaction diagram for optimizing resource allocation <br/>based on <br/>demand prediction, according to a first embodiment. At 205, the geo monitoring <br/>module 150 <br/>determines price multipliers in geos and sends 210 the price multiplier data <br/>to the geo data <br/>store 188 for storage. In one embodiment, the geo monitoring module 150 <br/>determines price <br/>multipliers by comparing the ratio of trip requests in a geo with the number <br/>of available <br/>providers. If the ratio of trip requests to available providers is over a <br/>threshold, the geo <br/>monitoring module 150 applies a price multiplier to the geo. In some <br/>embodiments, the geo <br/>monitoring module 150 applies progressively higher price multipliers as the <br/>ratio of trip <br/>requests to available providers increases.<br/>[0072] In response to receiving a set of service data from a user of a user <br/>client device <br/>100, the trip management module 140 sends 215 the received service data to the <br/>option <br/>selection module 160, which selects geos and/or candidate providers for <br/>inclusion in a list of <br/>service options. At 220, the option selection module 160 queries the geo data <br/>store 188 for <br/>price multipliers in geos within a threshold distance of the origin location <br/>or the origin geo of <br/>the user. The option selection module 160 also queries 225 the provider <br/>inventory data store <br/>186 for available providers in these nearby geos, including the locations of <br/>the available <br/>providers in the geos. For each selected geo, the option selection module 160 <br/>calculates the <br/>average distance and/or estimated time from the current locations of the <br/>available providers <br/>to the origin location. In some embodiments, the option selection module 160 <br/>further queries <br/>230 the demand prediction module 155 for the predicted user demand in the <br/>selected geos <br/>within a threshold amount of time of the desired departure time.<br/>[0073] In some examples, in response to the geo data store 188, the <br/>provider inventory <br/>data store 186, and the demand prediction module 155 returning 235, 240, and <br/>245 the <br/>requested data, the option selection module 160 selects 250 geos for inclusion <br/>in the list of <br/>service options that will be presented to the user. In some embodiments, the <br/>option selection <br/>module 160 also uses trip data received from the trip data store 180 to <br/>determine the set of <br/>service options, as discussed above with respect to FIG. 1. In one embodiment, <br/>the option <br/>selection module 160 selects all nearby geos. In another embodiment, the <br/>option selection <br/>module 160 selects the geo in which the nearby origin location is located and <br/>all adjacent <br/>geos. In still other embodiments, the option selection module 160 selects geos <br/>with varying<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>22<br/>price multipliers. According to various examples, the option selection module <br/>160 considers <br/>the current ratio of supply and demand and the applicable price modifiers in <br/>nearby geos <br/>when selecting geos for inclusion in the set of service options, as discussed <br/>above with <br/>respect to FIG. 1.<br/>[0074] For each of the selected geos, the option selection module 160 <br/>selects 255 <br/>candidate providers for inclusion as service options. In one embodiment, the <br/>option selection <br/>module 160 selects the candidate provider for whom the ETP at the nearby <br/>origin location is <br/>the least. In another embodiment, if the option selection module 160 <br/>determines that the ETP <br/>at the nearby origin location is the same for candidate providers in different <br/>geos, the option <br/>selection module 160 selects the candidate provider located in the geo with <br/>the lowest price <br/>multiplier. In still other embodiments, the option selection module 160 <br/>selects candidate <br/>providers based on user input regarding desired departure time. In all <br/>embodiments, the <br/>option selection module 160 determines a cut-off point for including candidate <br/>providers as <br/>service options based on the price multiplier in the candidate provider's geo <br/>and the ETP at <br/>the nearby origin location.<br/>[0075] After selecting the service options to present to the user, the <br/>option selection <br/>module 160 queries 260 the trip price estimation module 165 for trip price <br/>estimates. At 265, <br/>the trip price estimation module 165 calculates an estimated trip price for <br/>each of the selected <br/>service options. In one embodiment, the estimated trip price comprises a trip <br/>price and a <br/>pickup price, such as discussed above with respect to FIG. 1. After <br/>calculating the estimated <br/>trip prices, the trip price estimation module 165 returns 270 the estimates to <br/>the option <br/>selection module 160, which sends 275 the service options with associated trip <br/>price <br/>estimates for to the trip management module 140 display 280 on the user client <br/>device 100.<br/>[0076] The trip management module 140 receives 285 user input comprising <br/>selection <br/>of one of the presented service options, and sends 290 data regarding the <br/>selected service <br/>option to the demand prediction module 155. The demand prediction module 155 <br/>uses <br/>training data including the presented service options, the selected service <br/>option, and sets of <br/>training data from past trips taken by users (including origin locations, <br/>destination locations, <br/>desired departure times, service options presented to users, and service <br/>options selected by <br/>users) to generate 295 an optimization model to predict user demand over <br/>upcoming time <br/>periods. In some embodiments, the training data includes sets of service data <br/>corresponding <br/>to requests for transportation services in the future. In other embodiments, <br/>the training data <br/>includes provider availability and location data (e.g., data regarding an <br/>available provider's <br/>relocation from one geo to another). The training data serves as input to <br/>generate and train<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>23<br/>the optimization model, as discussed above with respect to FIG. 1. Once <br/>trained, the demand <br/>prediction module 155 uses the optimization model to improve predictions over <br/>user demand <br/>and optimize trip requests received over a time span over a range of geos <br/>within a threshold <br/>distance of each other.<br/>[0077] FIG. 3 illustrates an interaction diagram for optimizing resource <br/>allocation based <br/>on demand prediction, according to a second embodiment. At 305, the geo <br/>monitoring <br/>module 150 determines price multipliers of geos and sends 310 the price <br/>multiplier data to <br/>the geo data store 188 for storage. In one embodiment, the geo monitoring <br/>module 150 <br/>determines price multipliers by comparing the ratio of trip requests in a geo <br/>with the number <br/>of available providers. If the ratio of trip requests to available providers <br/>is over a threshold, <br/>the geo monitoring module 150 applies a price multiplier to the geo. In some <br/>embodiments, <br/>the geo monitoring module 150 applies progressively higher price multipliers <br/>as the ratio of <br/>trip requests to available providers increases.<br/>[0078] The demand prediction module 155 predicts the volume and timing of <br/>an <br/>upcoming demand peak at or near the vicinity of an origin location. If the <br/>demand prediction <br/>module 155 predicts 315 that user demand will be over a threshold volume in <br/>the geo <br/>containing the origin location, the demand prediction module 155 sends 320 an <br/>instruction to <br/>the option selection module 160 to obtain price multiplier data for geos <br/>within a threshold <br/>distance of the origin location. In one embodiment, the demand prediction <br/>module 155 <br/>predicts volume and timing of an upcoming demand peak responsive to the trip <br/>management <br/>module 140 detecting that user interest will be over a threshold volume based <br/>on the number <br/>of users who make a trip request through the user application 102 within a <br/>specified vicinity <br/>or geography and during a time period. In another embodiment, the demand <br/>prediction <br/>module 155 predicts volume and timing based on the number of trip arrivals at <br/>the origin <br/>location within a specified time period. In still other embodiments, the <br/>demand prediction <br/>module 155 considers both trip arrivals and the number of users making trip <br/>requests when <br/>predicting the volume and timing of an upcoming demand peak.<br/>[0079] At 325, the option selection module 160 queries the geo data store <br/>188 for price <br/>multipliers in geos within a threshold distance of the origin location. <br/>Responsive to the geo <br/>data store 188 returning 330 the requested data regarding these nearby geos, <br/>the option <br/>selection module 160 selects 335 geos for inclusion in the list of service <br/>options that will be <br/>presented to the user. In one embodiment, the option selection module 160 <br/>selects all nearby <br/>geos. In another embodiment, the option selection module 160 selects the geo <br/>in which the<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>24<br/>origin location is located and all adjacent geos. In still other embodiments, <br/>the option <br/>selection module 160 selects geos with varying price multipliers.<br/>[0080] After selecting the geos to be included in the spectrum of service <br/>options <br/>presented on the user client device 100, the option selection module 160 <br/>queries 340 the <br/>provider inventory data store 186 for a list of available providers in the <br/>selected geos and the <br/>location of the providers. At 345, the provider inventory data store 186 <br/>returns the requested <br/>data regarding these candidate providers, and the option selection module 160 <br/>selects 350 the <br/>service options. In one embodiment, for each of the selected geos, the option <br/>selection <br/>module 160 selects the candidate provider for whom the ETP to the origin <br/>location is the <br/>least. In another embodiment, if the option selection module 160 determines <br/>that the ETP to <br/>the origin location is the same for candidate providers in different geos, the <br/>option selection <br/>module 160 selects the candidate provider located in the geo with the lowest <br/>price multiplier. <br/>In still other embodiments, the option selection module 160 selects candidate <br/>providers based <br/>on user input regarding order time. As an addition or an alternative, the <br/>option selection <br/>module 160 determines a cut-off point for including candidate providers as <br/>service options <br/>based on the price multiplier in the candidate provider's geo and the ETP to <br/>the origin <br/>location, as discussed above with respect to FIG. 1.<br/>[0081] After selecting the service options to present to the user, the <br/>option selection <br/>module 160 queries 355 the trip price estimation module 165 for cost <br/>estimates. At 360, the <br/>trip price estimation module 165 calculates an estimated cost for each of the <br/>selected service <br/>options. In one embodiment, the estimated cost comprises a trip cost and a <br/>pickup cost, as <br/>discussed above with respect to FIG. 1. After calculating the estimated costs, <br/>the trip price <br/>estimation module 165 provides 365 the estimates to the option selection <br/>module 160, which <br/>transmits the service options with associated cost estimates for display on <br/>the user client <br/>device 100. The user operating the user client device 100 can view the service <br/>options, the <br/>associated ETP, and the associated cost estimates, and select an option to <br/>make a request for <br/>service. When the user selects a service option, the user application 102 can <br/>generate and <br/>transmit data corresponding to a trip request to the network system 130. The <br/>trip request can <br/>include a user identifier, the service type, the origin location, the <br/>destination location, and/or <br/>information about the selected option.<br/>[0082] In response to receiving the data corresponding to the trip request, <br/>the trip <br/>management module 140 creates a trip record in the trip data store 180 and <br/>selects a provider <br/>to provide the requested service from the list of candidate providers in the <br/>selected geos. In <br/>one embodiment, the trip management module 140 selects the candidate provider <br/>associated<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>with the selected service option who is closest to the origin location. For <br/>example, assume <br/>that providers A, B, and C are all associated with a selected service option <br/>(e.g., a trip <br/>originating in geo 3 with an ETP to the origin location in geo 1 of <br/>approximately 20 minutes). <br/>If provider A has an ETP of 22 minutes, provider B has an ETP of 20 minutes, <br/>and provider <br/>C has an ETP of 19 minutes, the trip management module 140 will select <br/>provider C to <br/>provide the service. In other embodiments, the trip management module 140 <br/>selects a <br/>candidate provider who is traveling towards the origin location. In still <br/>other embodiments, <br/>when a candidate provider is providing a service to multiple users at the same <br/>time, the trip <br/>management module 140 selects the candidate provider who is traveling towards <br/>the user's <br/>destination.<br/>[0083] FIG. 4 is a conceptual illustration of an example geo map depicting <br/>predicted <br/>price multipliers and candidate providers in different geos, in accordance <br/>with an <br/>embodiment. Assume that a user of a user client device 100 is attending a <br/>baseball game at a <br/>stadium 400 located in geo 1 (or at another event, such as a movie, party, <br/>restaurant, etc.). In <br/>one embodiment, at a current time, e.g., twenty minutes before the end of the <br/>game, the user <br/>opens the user application 102 to make a trip request. In response to <br/>receiving a set of <br/>service data including at least an origin location, a destination location, <br/>and/or a desired <br/>departure time (or default departure time), the option selection module 160 <br/>selects a spectrum <br/>of available service options to present to the user.<br/>[0084] In another embodiment, the user opens the user application 102 to <br/>view service <br/>information and potentially request a trip. The user can specify or select an <br/>origin location, a <br/>destination location, and/or a service type and view information about the <br/>service, such as the <br/>estimated time of arrival to the origin location, the estimated cost or <br/>calculated cost for the <br/>service, the estimated time to the destination location, etc. For example, in <br/>response to the <br/>user input, the network system 130 can receive the service data, determine the <br/>various service <br/>information, and transmit data corresponding to the service information to the <br/>user client <br/>device 100. In one example, in response to the demand prediction module 155 <br/>determining <br/>that user demand will be over a threshold volume at a current time or period <br/>of time, the <br/>option selection module 160 selects geos and candidate providers to present as <br/>one or more <br/>service options on the user client device 100. For example, the demand <br/>prediction module <br/>155 can determine that user demand is likely to be high in twenty minutes <br/>(e.g., near the end <br/>of the game at the stadium) as a high number of users at or near that time may <br/>operate the <br/>user application 102 to view service information and/or to request rides near <br/>the stadium to <br/>their homes or other locations. Similarly, user demand can be predicted to be <br/>high during<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>26<br/>historically busy time periods (e.g., evening rush hour between 5 and 7pm). If <br/>the demand <br/>prediction module 155 predicts that user demand in a geo will be over a <br/>threshold volume, <br/>the network system 130 selects and presents a spectrum of available service <br/>options for users <br/>that have specified an origin location in the geo. In one use case example, if <br/>the demand <br/>prediction module 155 detects high user demand coinciding with the end of a <br/>baseball game, <br/>the network system presents a spectrum of available service options to both <br/>users who are at <br/>the game and users who are not at the game (e.g., a user who is requesting a <br/>ride home from a <br/>restaurant), provided that they are located in the same geo or have specified <br/>an origin location <br/>in the same geo.<br/>[0085] As illustrated in FIG. 4, at an instance in time or period of time, <br/>price multipliers <br/>may be different across geos. For example, the demand prediction module 155 <br/>predicts that <br/>the price multiplier in geo 1, where the user is located at or has specified <br/>an origin location at, <br/>will be 3.0x near the end of the game at the stadium, while the predicted <br/>price multipliers in <br/>neighboring geos 2 and 3 are 1.5x and 1.0x, respectively, where x is an <br/>initial trip price to <br/>which the price multiplier is applied to determine a final trip price <br/>estimate. The user located <br/>at the stadium 400 may be presented with a number of service options 405, 410, <br/>and 415 with <br/>varying price multipliers and ETPs at the nearby origin location. The <br/>estimated trip price <br/>associated with each service option can be based on the price multiplier in <br/>the geo in which <br/>the provider is located. For example, for service option 405, the provider is <br/>located five <br/>minutes away from the nearby origin location (has an ETP of five minutes from <br/>the origin <br/>location) (or alternatively, a group of providers in geo 3 have an averaged <br/>ETP or shortest <br/>ETP of five minutes from the origin location, i.e., the stadium 400), and the <br/>price multiplier is <br/>3.0x. For service option 410, the provider (or group of providers) is <br/>determined located ten <br/>minutes away from the nearby origin location (has an ETP, e.g., averaged or <br/>shortest ETP, of <br/>ten minutes), and the price multiplier is 1.5x. For service option 415, the <br/>provider (or group <br/>of providers) is located 20 minutes away from the nearby origin location (has <br/>an ETP of <br/>twenty minutes) and the price multiplier is 1.0x (i.e., there is no price <br/>multiplier in geo 3 is <br/>1.0x). According to some examples, the predicted price multipliers at a time <br/>in the future can <br/>be provided to the user application 102 in conjunction with the service <br/>options so that the <br/>user may determine the benefit of requesting a service at a later time as <br/>compared to a current <br/>time.<br/>[0086] The network system 130 can provide the service options and the <br/>respective costs <br/>and ETPs to the user client device 100. In one embodiment, the option <br/>selection module 160 <br/>orders the list of available options or rides from quickest to slowest (e.g., <br/>based on ETP) (i.e.,<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>27<br/>service option 405, service option 410, service option 415). In another <br/>embodiment, the <br/>option selection module 160 orders the list from least expensive to most <br/>expensive based on <br/>the trip price estimates calculated by the trip price estimation module 165. <br/>For example, if <br/>the destination location is a short distance from the nearby origin location, <br/>service option 405 <br/>might be the least expensive, despite having the highest price. In still other <br/>embodiments, <br/>responsive to the demand prediction module 155 predicting that user demand <br/>will be over a <br/>threshold volume at or near a desired departure time, the option selection <br/>module 160 orders <br/>the list of service options such that providers who are located further away <br/>are displayed first. <br/>For example, if the desired departure time is approximately twenty minutes, <br/>the option <br/>selection module 160 will order the list of service options such that service <br/>option 315 is <br/>presented first.<br/>[0087] FIG. 5 is a conceptual illustration of an example geo map depicting <br/>an already-<br/>assigned trip (e.g., a service that is previously assigned to a user to be <br/>provided by a provider, <br/>but the user has not yet been picked up), where the provider is traveling from <br/>a current <br/>location to the origin location, in accordance with an embodiment. Assume that <br/>user A is <br/>getting ready to leave work for the day and submits a set of service data <br/>including a request <br/>for a trip from the user's office 500 to the user's home and a desired <br/>departure time of 30 <br/>minutes from the current time. In response to receiving the set of service <br/>data, the option <br/>selection module 160 selects a spectrum of available service options to <br/>present to user A.<br/>[0088] Assume that candidate provider 405, who is located approximately 20 <br/>minutes <br/>away from the origin location 500 is included as a service option. In one <br/>embodiment, in <br/>response to user A selecting service option 505, the trip management module <br/>140 sends an <br/>invitation message to provide the requested service to a candidate provider <br/>associated with <br/>service option 505 in 10 minutes (i.e., such that the candidate provider will <br/>arrive at the <br/>origin location at the desired departure time). In other embodiments, however, <br/>in response to <br/>user A selecting service option 505, the trip management module 140 schedules <br/>one or more <br/>already-assigned trips whereby candidate provider 505 provides one or more <br/>transportation <br/>services to one or more other users while traveling from the current location <br/>to the origin <br/>location 500.<br/>[0089] For example, assume that user A has selected service option 505 from <br/>the list of <br/>service options in which a candidate provider associated with the service <br/>option 505 is <br/>assigned to user A. In response to user B submitting a trip request with an <br/>origin location and <br/>a destination location located between candidate provider 505's current <br/>location and the <br/>origin location 500 and a desired departure time of "now," the trip management <br/>module 140<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>28<br/>schedules an already-assigned trip whereby the candidate provider associated <br/>with service <br/>option 505 travels to user B's origin location 510(9 minutes) and transports <br/>user B from the <br/>origin location 510 to the destination location 515 (9 minutes) before <br/>traveling from <br/>destination location 515 to origin location 500 to pickup user A (9 minutes).<br/>[0090] In some embodiments, the trip management module 140 schedules an <br/>already-<br/>assigned trip in response to determining that the total estimated time for the <br/>already-assigned <br/>trip is within a threshold amount of time of user A's desired departure time. <br/>In other <br/>embodiments, the trip management module 140 schedules an already-assigned trip <br/>in <br/>response to determining that user B's desired departure time is within a <br/>threshold amount of <br/>time of user A's desired departure time. For example, if user B's desired <br/>departure time is in <br/>20 minutes and the total estimated time for trip B is 27 minutes (bringing the <br/>ETP at the <br/>origin location 500 to 47 minutes), the trip management module 140 will not <br/>schedule the <br/>already-assigned trip for user B.<br/>[0091] The user application 102 presents the service options to the user <br/>and provides <br/>the user with the ability to select a service option from the presented <br/>service options. FIG. 6 <br/>illustrates an example user interface 602 on the user application 102 for <br/>displaying alternative <br/>service options. In the illustration, the user interface 602 displays the <br/>origin location, the <br/>destination location, the order time, and the service options 604, 606, and <br/>608. In the <br/>illustration, the user interface 602 includes three service options. In other <br/>embodiments, <br/>more or fewer service options are included. The presentation of each of the <br/>service options <br/>604, 606, and 608 includes information about the respective service options, <br/>for example, the <br/>ETP, the applicable price multiplier, and the estimated trip price or computed <br/>guaranteed <br/>cost. In some embodiments, the information further includes whether the <br/>service option is a <br/>one-to-one or a one-to-many service option. In some embodiments, the service <br/>options <br/>include trips with ETPs at the nearby origin location presented in minutes. <br/>Alternatively, the <br/>service options might include trips with ETPs presented in hours or days.<br/>[0092] In embodiments where the order time is hours or days from the time <br/>the trip <br/>request is made (e.g., earlier than a threshold amount of time before), the <br/>demand prediction <br/>module 155 uses data from the trip requests to forecast scheduled demand <br/>including origin <br/>locations, destination locations, and timing. For example, if the number of <br/>users requesting <br/>rides to the airport in the next week exceeds a threshold, the demand <br/>prediction module 155 <br/>might infer that the real-time trip requests during the evening commute will <br/>be less than <br/>usual.<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>29<br/>[0093] Assume that a user attending a baseball game at a stadium in geo 1 <br/>opens the <br/>user application 102 at 4:17 pm, roughly twenty minutes before the end of the <br/>game, to make <br/>a trip request. The user inputs or specifies the origin location, the <br/>destination location, and an <br/>order time of "now." The user can also specify a service option, not <br/>illustrated in FIG. 6 for <br/>purposes of simplicity. Depending on implementation, responsive to receiving <br/>the service <br/>data, or in response to the network system 130 predicting that user demand <br/>will be over a <br/>threshold volume, the option selection module 160 sends for display on the <br/>user client device <br/>100 the service options 604, 606, and 608. Service option A includes a <br/>provider currently <br/>located in the same geo as the user and has an ETP at the origin location of <br/>4:22 pm, 5 <br/>minutes from the order time. Because the current demand for rides is low, the <br/>price <br/>multiplier in geo 1 is 1.0x, and the total estimated cost to the destination <br/>location is $26. <br/>However, the network system 130 can determine that at a future time, such as <br/>in twenty <br/>minutes, the predicted price multiplier in geo 1 can be higher than 1.0x, such <br/>as 3.0x, due to <br/>forecasted demand.<br/>[0094] Service option B includes a provider located in neighboring geo 2 <br/>arriving at the <br/>origin location approximately ten minutes after the order time, at 4:27 pm. <br/>The price <br/>multiplier in geo 2 is currently 1.1x, and the total estimated price to the <br/>destination location is <br/>$31. Though service option B is more expensive and has a longer ETP than <br/>service option 1, <br/>the user might choose service option B if, for example, the score is close, <br/>and the user does <br/>not want to leave the game immediately, but may want to leave sometime after 5 <br/>minutes. If <br/>the user selects service option B (leave later as opposed to "now"), the <br/>network system 130 <br/>can select a provider from geo 2 so that the provider can travel from geo 2 to <br/>the origin <br/>location (e.g., it would take around the ETP time). This can be a better user <br/>experience for <br/>the user and cheaper than if the user waits eight more minutes before deciding <br/>to make a <br/>request for "now," (e.g., making a standard trip request) and if eight minutes <br/>later, the <br/>estimated price multiplier goes up significantly in geo 1 (e.g., from 1.1x to <br/>1.8x). In such an <br/>example, the network system 130 would select a provider closest to the origin <br/>location (e.g., <br/>select a provider in geo 1 with the price multiplier at 1.8x), but the user <br/>would receive the <br/>same or similar service at a higher cost than if the user had requested option <br/>B for a provider <br/>from geo 2 eight minutes before.<br/>[0095] Service option C includes a provider located in geo 3 arriving at <br/>the origin <br/>location approximately twenty minutes after the order time, at 4:37 pm (i.e., <br/>the time the <br/>baseball game is estimated to end). The price multiplier in geo 3 is 1.0x, and <br/>the total <br/>estimated cost to the destination location is $35. In such an example, the <br/>total estimated cost<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>for option C would be greater than the total estimated cost for option A <br/>(though both have a <br/>multiplier of 1.0x) due to the distance and/or duration traveled by the <br/>provider from geo 3 to <br/>the origin location. Service option C gives the user an option to remain at <br/>the game until its <br/>estimated end for a relatively low price. In such an example, if the user were <br/>to select option <br/>C (at the current time, 4:17pm), the network system 130 can select a provider <br/>from geo 3, <br/>who can start traveling towards the origin location and arrive at the origin <br/>location around <br/>4:37pm. By comparison, if the user waited until the end of the game to make a <br/>trip request, <br/>the price multipliers would likely increase as more spectators leave the <br/>stadium around the <br/>same time. In this example, the price multiplier at geo 1 once the game ends <br/>can increase <br/>(e.g., from 1.0x to 3.0x due to the number of other users in geo 1 that are <br/>operating the client <br/>applications to potentially request service) so that the estimated cost may be <br/>much higher <br/>than $26 (e.g., $50), so that if the user were to request service at that <br/>time, a provider in geo 1 <br/>would be selected at the potentially higher cost. In this manner, the network <br/>system 130 can <br/>enable resources to be allocated from nearby geographic regions to fulfill <br/>demand in a <br/>geographic region where demand is higher than normal or forecasted to be <br/>higher than <br/>normal by providing service options, for services that start at a later time, <br/>to users.<br/>[0096] FIG. 7 illustrates an example user interface on a provider <br/>application 104 <br/>showing service options for selection by a provider, in accordance with an <br/>embodiment. As <br/>discussed above with respect to FIG. 1, a provider can select from a number of <br/>service <br/>options representing various trip requests submitted by users of the network <br/>system 130. The <br/>trip management module 140 selects trip requests to display as service options <br/>to the provider <br/>based on predicted demand over a specified time period within a threshold <br/>distance of the <br/>provider's current location or geo, as determined by the demand prediction <br/>module 155.<br/>[0097] For example, FIG. 7 displays three service options 704, 706, and 708 <br/>presented <br/>on user interface 702. In other embodiments, more or fewer service options are <br/>displayed <br/>depending on the number of trip requests and/or the predicted demand. The <br/>presentation of <br/>each of service options 704, 706, and 708 includes information about the <br/>respective service <br/>options, for example, the ETP, the applicable price multiplier, and the <br/>estimated trip price. In <br/>some embodiments, the information further includes optional already-assigned <br/>trips <br/>associated with one or more of the service options 704, 706, and 708. In some <br/>embodiments, <br/>the service options include trips with ETPs at the origin location presented <br/>in minutes. <br/>Additionally or alternatively, the service options might include trips with <br/>ETPs presented in <br/>hours or days.<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>31<br/>[0098] Assume that a provider located in geo 2, where the current surge <br/>multiplier is <br/>1.6, opens the provider application 104 at 4:16pm to select one or more trip <br/>requests to fulfill. <br/>The provider application 104 displays one or more service options selected <br/>based application <br/>of the market status factors, including the origin and destination locations <br/>and desired <br/>departure times input by the users, the current user demand for service, <br/>predictions of future <br/>demand, number and locations of other available providers, and pricing <br/>information in geos <br/>within a threshold distance of the origin locations or the origin geos of the <br/>users.<br/>[0099] Service option A 704 corresponds to a user whose origin and <br/>destination <br/>locations are in the same geo as the provider's current location. With the <br/>applicable price <br/>multiplier, the estimated total price for service option A 704 is $18, and the <br/>ETP by the <br/>provider at the origin location is 4:22pm. Service option B 706 corresponds to <br/>a user whose <br/>origin and destination locations are in geo 3. With the applicable price <br/>multiplier for geo 2 <br/>(the geo in which the provider is currently located), the estimated total <br/>price is $26, and the <br/>ETP by the provider is 4:29pm. In some embodiments, the estimated total price <br/>incorporates <br/>an incentive for the provider to travel from geo 2 to the origin location in <br/>geo 3. Finally, <br/>service option C 708 corresponds to a user whose origin location is in geo 3 <br/>and whose <br/>destination location is in geo 4. With the applicable price multiplier for geo <br/>2, the estimated <br/>total price is $37 and the ETP by the provider is 4:37pm. In each of service <br/>options 704, 706, <br/>and 708, the applicable price multiplier is the current price multiplier in <br/>geo 2, the geo in <br/>which the provider is currently located. In some embodiments, one or more of <br/>the presented <br/>service options might include one or more already-assigned trips. For example, <br/>service <br/>option C 708 might include an already-assigned trip with an origin location in <br/>geo 2, a <br/>destination location in geo 3, and an estimated time of arrival at the already-<br/>assigned trip <br/>destination location before the desired departure time of the first user.<br/>[0100] FIG. 8 is a block diagram illustrating physical components of a <br/>computer 800 used <br/>as part or all of the network system 130, user client device 100, or provider <br/>client device 110 <br/>from FIG. 1, in accordance with an embodiment. Illustrated are at least one <br/>processor 802 <br/>coupled to a chipset 804. Also coupled to the chipset 804 are a memory 806, a <br/>storage device <br/>808, a graphics adapter 812, and a network adapter 816. A display 818 is <br/>coupled to the <br/>graphics adapter 812. In one embodiment, the functionality of the chipset 804 <br/>is provided by <br/>a memory controller hub 820 and an I/O controller hub 822. In another <br/>embodiment, the <br/>memory 806 is coupled directly to the processor 802 instead of the chipset <br/>804.<br/>[0101] The storage device 808 is any non-transitory computer-readable <br/>storage medium, <br/>such as a hard drive, compact disk read-only memory (CD-ROM), DVD, or a solid-<br/>state<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>32<br/>memory device. The memory 806 holds instructions and data used by the <br/>processor 802. <br/>The graphics adapter 812 displays images and other information on the display <br/>818. The <br/>network adapter 816 couples the computer 800 to a local or wide area network.<br/>[0102] As is known in the art, a computer 800 can have different and/or <br/>other <br/>components than those shown in FIG. 8. In addition, the computer 800 can lack <br/>certain <br/>illustrated components. In one embodiment, a computer 800, such as a host or <br/>smartphone, <br/>may lack a graphics adapter 812, and/or display 818, as well as a keyboard 810 <br/>or external <br/>pointing device 814. Moreover, the storage device 808 can be local and/or <br/>remote from the <br/>computer 800 (such as embodied within a storage area network (SAN)).<br/>[0103] As is known in the art, the computer 800 is adapted to execute <br/>computer program <br/>modules for providing functionality described herein. As used herein, the term <br/>"module" <br/>refers to computer program logic utilized to provide the specified <br/>functionality. Thus, a <br/>module can be implemented in hardware, firmware, and/or software. In one <br/>embodiment, <br/>program modules are stored on the storage device 808, loaded into the memory <br/>806, and <br/>executed by the processor 802.<br/>[0104] The foregoing description described an embodiment of the invention <br/>in which the <br/>network system 130 presents a spectrum of service options on the user client <br/>device 100 <br/>responsive to the demand prediction module 155 detecting that user demand will <br/>be over a <br/>threshold volume. In other embodiments, the trip management system 130 <br/>presents a <br/>spectrum of service options regardless of the demand forecasted by the demand <br/>prediction <br/>module 155.<br/>[0105] FIG. 9 is a flow chart illustrating the selection of service options <br/>based on market <br/>status factors, in accordance with an embodiment. The option selection module <br/>160 receives <br/>as input a set of service data 905 received from a user A, the set of service <br/>data including an <br/>origin location, a destination location, and a desired departure time. In some <br/>embodiments, <br/>the set of service data 905 includes a request for a single rider <br/>transportation service. In other <br/>embodiments, the set of service data 905 includes a request for a multiple <br/>rider transportation <br/>service.<br/>[0106] The option selection module 160 also receives as input a number of <br/>market status <br/>factors 910, including the current user demand for service, predictions of <br/>future demand in <br/>geos within a threshold distance of the origin location or the origin geo of <br/>the user, the <br/>number and location of available providers, and pricing information in geos <br/>within a <br/>threshold distance of the origin location or the origin geo of the user. <br/>Additionally, the <br/>market status factors 910 may include, for each of the available providers <br/>located within a<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>33<br/>threshold distance of the origin location or the origin geo of the user, the <br/>distance and <br/>estimated time from the provider's current location to the origin location.<br/>[0107] In some embodiments, the option selection module 160 queries the <br/>trip data store <br/>180 for trip data associated with trip requests made within a threshold period <br/>of time of user <br/>A's trip request. Additionally or alternatively, the option selection module <br/>160 queries the <br/>trip data store 180 for trip data associated with trip requests with origin <br/>locations within a <br/>threshold distance of the origin location or origin geo of user A. The trip <br/>data store 180 <br/>returns the requested trip data 915, including the origin locations, <br/>destination locations, route <br/>information, desired departure times, and user-provider matching information <br/>for each of the <br/>N trips and M providers associated with the trip requests. In some <br/>embodiments, the option <br/>selection module 160 uses the trip data 915 as input when selecting the <br/>service options for <br/>user A.<br/>[0108] Responsive to receiving as input the service data for user A 905, <br/>the market status <br/>factors 910, and the trip data 915, the option selection module 160 selects <br/>geos and candidate <br/>providers, as discussed above with respect to FIG. 1 and outputs a set of <br/>service options for <br/>user A through the user application 102. In conjunction with selecting the set <br/>of service <br/>options for user A, the option selection module 160 recalculates the existing <br/>trip data, <br/>including the user-provider matching information, to account for user A's trip <br/>request. <br/>Therefore, in some embodiments, the option selection module 160 also outputs <br/>updated trip <br/>data 925 including the origin locations, destination locations, route <br/>information, desired <br/>departure times, and user-provider matching information for each of the N+1 <br/>trips and M <br/>providers.<br/>[0109] The foregoing description has been presented for the purpose of <br/>illustration; it is <br/>not intended to be exhaustive or to limit the invention to the precise forms <br/>disclosed. Persons <br/>skilled in the relevant art can appreciate that many modifications and <br/>variations are possible <br/>in light of the above disclosure.<br/>[0110] Some portions of this description describe embodiments in terms of <br/>algorithms <br/>and symbolic representations of operations on information. These algorithmic <br/>descriptions <br/>and representations are commonly used by those skilled in the data processing <br/>arts to convey <br/>the substance of their work effectively to others skilled in the art. These <br/>operations while <br/>described functionally computationally or logically are understood to be <br/>implemented by <br/>computer programs or equivalent electrical circuits microcode or the like. <br/>Furthermore it has <br/>also proven convenient at times to refer to these arrangements of operations <br/>as modules<br/><br/>CA 03053089 2019-08-08<br/>WO 2018/146622 PCT/IB2018/050795<br/>34<br/>without loss of generality. The described operations and their associated <br/>modules may be <br/>embodied in software firmware hardware or any combinations thereof.<br/>[0111] Any of the steps operations or processes described herein may be <br/>performed or <br/>implemented with one or more hardware or software modules alone or in <br/>combination with <br/>other devices. In one embodiment a software module is implemented with a <br/>computer <br/>program product comprising a computer-readable medium containing computer <br/>program <br/>code which can be executed by a computer processor for performing any or all <br/>of the steps <br/>operations or processes described.<br/>[0112] Embodiments may also relate to an apparatus for performing the <br/>operations <br/>herein. This apparatus may be specially constructed for the required purposes <br/>and/or it may <br/>comprise a general-purpose computing device selectively activated or <br/>reconfigured by a <br/>computer program stored in the computer. Such a computer program may be stored <br/>in a <br/>non-transitory tangible computer readable storage medium or any type of media <br/>suitable for <br/>storing electronic instructions which may be coupled to a computer system bus. <br/>Furthermore <br/>any computing systems referred to in the specification may include a single <br/>processor or may <br/>be architectures employing multiple processor designs for increased computing <br/>capability.<br/>[0113] Embodiments may also relate to a product that is produced by a <br/>computing <br/>process described herein. Such a product may comprise information resulting <br/>from a <br/>computing process where the information is stored on a non-transitory tangible <br/>computer <br/>readable storage medium and may include any embodiment of a computer program <br/>product <br/>or other data combination described herein.<br/>[0114] Finally, the language used in the specification has been principally <br/>selected for <br/>readability and instructional purposes, and it may not have been selected to <br/>delineate or <br/>circumscribe the inventive subject matter. It is therefore intended that the <br/>scope of the <br/>invention be limited not by this detailed description but rather by any claims <br/>that issue on an <br/>application based hereon. Accordingly, the disclosure of the embodiments of <br/>the invention is <br/>intended to be illustrative but not limiting of the scope of the invention <br/>which is set forth in <br/>the following claims.<br/>
