BR122025008790A2 - NETWORK SYSTEM TO FILTER REQUESTS BY DESTINATION AND DEADLINE - Google Patents

Abstract

A method and system for filtering service requests by destination and deadline are described. A computer network system receives data from the provider corresponding to a specified destination and deadline from a service provider. The computer network system tracks the current location of the service provider through a device equipped with one or more location-based capabilities and receives request data corresponding to user service requests. The computer network system analyzes the request data for each of the service requests to identify a subset of the requests that can be assigned to the service provider based on whether the service provider is capable of fulfilling the request and traveling to the desired destination before the deadline. The computer network system transmits a message to the service provider device requesting that the service provider fulfill one of the service requests from the identified subset.

Description

Cross-reference to related orders

[001] This application claims the benefit of priority to each of (i) U.S. Patent Application No. 15/432,766, filed on February 14, 2017, and (ii) U.S. Patent Application No. 15/866,284, filed on January 9, 2018; in which the aforementioned applications are incorporated by reference in their respective entireties.

Background

[002] A network service may allow users to request and receive various services through applications on mobile computing devices. The network service typically selects a service provider to fulfill the service request based on user-specified data from the request. These service providers may interact with the network service to accept or reject service requests, receive data about the requesting users, and adjust various status modes, such as whether the provider is online and available to fulfill requests or offline.

Brief description of the drawings

[003] Figure 1 is a block diagram illustrating an exemplary network computer system in communication with service requester and service provider devices, in accordance with the examples described herein.

[004] Figure 2 is a timeline illustrating examples of events that may occur during the provision of services in a deadline filter mode, according to examples described herein.

[005] Figure 3 is a flowchart depicting an exemplary method for filtering service requests by destination and deadline, in accordance with examples described herein.

[006] Figure 4 is a flowchart describing an exemplary method for persisting target and deadline settings when a service provider goes offline, in accordance with examples described herein.

[007] Figure 5 is a flowchart depicting an exemplary method for filtering service or destination requests, in accordance with examples described herein.

[008] Figures 6A and 6B illustrate exemplary user interfaces on a service provider device, in accordance with examples described herein.

[009] Figure 7 is a block diagram illustrating an exemplary service provider device running a service provider application designated for an on-demand service as described herein.

[0010] Figure 8 is a block diagram illustrating a computer system in which the aspects described in this document may be implemented.

Detailed description

[0011] A computer networking system is provided herein that manages a service-based on-demand network that links available service providers with service requesters throughout a given region (e.g., a metroplex such as the San Francisco Bay Area). According to examples, the computer networking system may receive service requests for on-demand services (e.g., transportation service or delivery service) from requesting users (e.g., a passenger) via a designated service requester application running on the users' mobile computing devices. Based at least in part on a service start location, the computer networking system may identify a number of available nearby service providers (e.g., a driver) and broadcast a service invitation message to one or more service provider devices of the available nearby service providers to fulfill the service request (e.g., provide or perform the corresponding service). In many examples, service providers may either accept or reject the invitation based on, for example, whether the service start location or the service destination is impractical for the service provider.

[0012] In some examples, when selecting a service provider to fulfill a given service request, the computer networking system may identify a plurality of candidate service providers to fulfill the service request based on a service start location indicated in the service request. For example, the network computer system may determine a geofence (e.g., a region specified by three or more location points or a defined area, such as a hexagon from an array of hexagons) surrounding the service start location (or a geofence defined by a radius away from the service start location), identify a set of candidate service providers (e.g., twenty or thirty service providers within the geofence), and select an optimal service provider (e.g., the service provider closest to the service start location, the service provider with the shortest estimated travel time from the service start location, the service provider traveling to a location within a specified distance or travel time to the destination location, etc.) from the candidate service providers to fulfill the service request. In accordance with the examples provided herein, the network computer system may compile historical data for individual service requesters, regarding the network-based service. Thus, the network computer system may manage a service requester profile for each service requester, indicating routine start and/or end locations (or regions), and/or routine routes (e.g., for a transportation service from home to work and/or vice versa), and preferred service types (e.g., transportation, delivery, email, etc.). In some examples, the network computer system may automatically synchronize with a service requester device, e.g., to identify the service requester's contacts, the service requester's schedule and notes, travel plans (e.g., a scheduled trip), and the like.

[0013] In conventional service requester applications used with on-demand service systems, service providers may be reluctant to go online or remain online when they have limited time due to the fear that travel will take them far from a desired destination, such as home or work. If the provider needs to be at a specified destination by a given deadline, the provider may choose to play it safe and not risk providing services.

[0014] In various implementations described herein, the service provider may specify by what time it wishes to arrive at a specific destination. With such data, an exemplary computer networking system may operate to filter service requests to comply with a set of constraints that allow a service provider to be at a desired or specified destination by a deadline time. Additionally or alternatively, in one example, when the computer networking system receives a service request, the computer networking system may determine whether to include the service provider (who specified a desired destination and deadline) in the set of candidate service providers to fulfill the service request based on the data provided. The computer networking system may then select a service provider from that set. Thus, the computer networking system may ensure that the service provider is not chosen to receive service invitations or assigned to services that would take the service provider too far from the desired destination such that he or she could not arrive before the requested deadline. Additionally, the computer networking system ensures that the service provider can not only arrive at the desired destination before the deadline, but also that the provider has sufficient time to provide service to requesting users near the estimated route from the provider's current location to the desired destination. Furthermore, once the computer networking system determines that it is time for the service provider to travel to the destination, it confirms with the service provider that they still want to be at the specified destination by the deadline. Once confirmed, the computer networking system filters out any service requests in which the service start location and service destination are not approximately along a travel route from the provider's current location to the desired destination. That is, the computer networking system can filter the service provider from a pool of candidate drivers for any service invitations that are not in a direction similar to the travel route. In some aspects, the computer network system 100 may determine that a service request is along a travel route when the request has a service start location and/or service destination that are within a threshold distance from a point along the travel route.

[0015] Among other benefits, the examples described in this document achieve a technical effect of providing service providers based on on-demand networks (e.g., an on-demand transportation service) with increased control and scheduling stability. By programmatically filtering service requests by destination and deadline, the computer networking system prevents service providers from providing services that would otherwise take them too far to arrive on time at their desired destinations within the specified deadline times. This gives service providers greater peace of mind and flexibility when providing services over the computer networking system, which can increase average system utilization and reduce wait times for users.

[0016] In accordance with examples described herein, a computer networking system receives provider data corresponding to a desired destination and a deadline from a service provider. The computer networking system tracks a current location of the service provider through a device equipped with one or more location-based capabilities and receives request data corresponding to service requests from users. The computer networking system analyzes the request data for each of the service requests to identify a subset of the requests, in which it is determined that the service provider has the capacity to fulfill the request and travel to the desired destination before the deadline. In other words, the computer networking system may identify, from the plurality of requests, one or more requests that are assignable to the service provider based on a determination that the service provider has the capacity to provide the service and travel to the specified destination before the deadline. The computer networking system broadcasts an invitation to the service provider to fulfill one of the service requests from the identified subset.

[0017] As provided herein, the terms “user” and “service requester” are used throughout this application interchangeably to describe a person or group of persons who utilize a requester application on a computing device to request, via one or more networks, on-demand services from a networked computer system. The term “service provider” is used to describe a person who utilizes a provider application on a computing device to provide on-demand services to service requesters.

[0018] One or more aspects described herein ensure that methods, techniques, and actions performed by a computing device are performed programmatically, or as a computer-implemented method. Programmatically means through the use of computer executable code or instructions. A step performed programmatically may or may not be automatic.

[0019] One or more aspects described herein may be implemented using programmatic modules or components. A programmatic module or component may include a program, a subroutine, a portion of a program, a software component, or a hardware component capable of performing one or more stated tasks or functions. In addition, a module or component may exist in a hardware component independently of other modules or components. Alternatively, a module or component may be a shared element or process of other modules, programs, or machines.

[0020] Furthermore, one or more aspects described herein may be implemented through the use of instructions that are executable by one or more processors. These instructions may be loaded onto a computer-readable medium. The machines shown or described with the figures below provide examples of processing resources and computer-readable media on which instructions to implement some aspects may be carried and/or executed. In particular, the numerous machines shown in some examples include a processor(s) and various forms of memory for holding data and instructions. Examples of computer-readable media include permanent memory storage devices, such as hard drives in personal computers or servers. Other examples of computer storage media include portable storage drives, such as CD or DVD drives, flash or solid-state memory (as carried in many cell phones and consumer electronics devices), and magnetic memory. Computers, terminals, and network-enabled devices (e.g., mobile devices such as cell phones) are all examples of machines and devices that utilize processors, memory, and instructions stored on computer-readable media.

[0021] Alternatively, one or more examples described herein may be implemented using dedicated hardware logic circuits that are comprised of an interconnection of logic gates. Such circuits are typically designed using a hardware description language (HDL), such as Verilog and VHDL. These languages contain instructions that ultimately define the layout of the circuit. However, once the circuit is fabricated, there are no instructions. All processing is performed through interconnected gates.

System Overview

[0022] Figure 1 is a block diagram illustrating an exemplary network computer system in communication with service requester and service provider devices, in accordance with the examples described herein. The computer networking system 100 may implement or manage a networking service (e.g., an on-demand transportation service or on-demand delivery service) that connects service requesters 174 with service providers 184 that are available to fulfill the service requests 171 that service requesters 174 transmit to the computer networking system 100. The networking service may enable services to be requested by service requesters 174 and provided by available service providers 184 through a service requester application 175 running on the service requester devices 170 and a service provider application 185 running on the service provider devices 180. As used herein, a service requester device 170 and a service provider device 180 may comprise computing devices with functionality to execute designated applications that correspond to the on-demand services managed by the computer networking system 100. In many examples, service requester devices 170 and service provider devices 180 may include mobile computing devices, such as smartphones, tablet computers, virtual reality or augmented reality headsets, vehicle embedded computing systems, and the like. Exemplary network services may include food or product delivery, package shipping, shopping, construction, plumbing, home repairs, housing or apartment sharing, etc., or may include transportation arrangement services.

[0023] The computer network system 100 may include a provider management interface 115 for communicating over one or more networks 160 with the service provider application 185 running on the service provider devices 180. According to examples, service providers 184 register with the computer network system 100 to receive service invitations 132 through the service provider application 185 to fulfill service requests 171 submitted by the service requesters 174. In an example using transportation services, the service requesters 174 are potential passengers who want to be picked up and transported, and the service providers 184 are drivers who transport the service requesters 174.

[0024] Service providers 184 may select various states or modes within service provider application 185, such as an online mode that indicates that service provider 184 is available and willing to fulfill service invitations 132. Service providers 184 may also select from various types of transportation service that the provider offers, including passenger pooling, a ride-sharing type of service, a luxury vehicle type of service, etc. Additionally, service providers 184 may configure one or more constraints on their schedules, such as a desired destination 114 and/or deadline 116.

[0025] In some situations, service providers 184 make themselves available to perform services for a block of time in a manner similar to a workday or at sporadic times when it is convenient for the provider. For example, a driver providing transportation services may choose to only pick up passengers during a morning commute or on the way home in the evening. In the normal course of providing on-demand services, service providers 184 may either park and wait, or drive around a region while waiting for nearby users to request services. However, service providers 184 may be reluctant to go online or remain online when they have limited time, due to the fear that travel may take them away from a desired destination, such as home or work. Therefore, computer network system 100 may operate to filter service requests 171 to comply with a set of constraints that allow a service provider 184 to be at a desired destination 114 by a deadline 116.

[0026] According to various examples, service provider device 180 transmits a provider status 113, which may include any selected modes, the service provider's current location 184, and other provider information, over network 160 to provider management interface 115. Additionally, service provider device 180 may transmit a desired destination 114 and deadline 116 to provider management interface 115 when service provider 184 chooses to enter a filtering mode. In some implementations, service provider devices 180 may determine the current location of service provider 184 by using location-based resources of service provider devices 180 (e.g., Global Positioning System (GPS) resources). The service provider application 185 may continuously update the provider status 113 on a regular schedule or in response to information input by the provider into the service provider device 180, location changes determined by GPS, service steps performed, etc. The provider management interface 115 stores the provider status 113 in a provider data store 190 (e.g., a database or data structure) accessible by a selection engine 130 that processes incoming service requests 171 so as to select service providers 184 to fulfill the service requests 171.

[0027] The computer networking system 100 may include a service requester interface 125 for communicating with service requesting devices 170 over one or more networks 160 via a service requester application 175. According to examples, a service requester 174 that wishes to utilize on-demand services may launch the service requester application 175 and transmit a service request 171 over the network 160 to the computer networking system 100. In certain implementations, the service requester 174 may view multiple different service types managed by the computer networking system 100, such as ride sharing, a ride sharing type of service, a luxury vehicle type of service, a van or large vehicle type of service, professional services (e.g., where the service provider is certified), an on-demand autonomous vehicle service, and the like. The computer network system 100 may utilize service provider locations to provide service requesting devices 170 with estimated time of arrival (ETA) data of nearby service providers 184 for each respective service. In one implementation, the service requesting application 175 may allow the service requester 174 to scroll through each service type. In response to a soft selection of a particular service type, the computer network system 100 may provide ETA data in a user interface of the service requesting application 175 that indicates an ETA of the nearest service provider 184 for the service type and/or the locations of all available nearby service providers 184 for such service type. As the service requester 174 scrolls through each service type, the user interface may update to show visual representations of the service providers 184 for that service type on a map centered on the service requester 174 or a chosen service start location 173. The service requester 174 may interact with the service requester application user interface 175 to select a particular service type and transmit a service request 171.

[0028] In some examples, service request 171 may include a service start location 173 within a given region (e.g., a metropolitan area managed by one or more data centers corresponding to computer network system 100) where a matched service provider is to meet service requester 174. Service requester 174 may input service start location 173 by setting a location pin in a user interface of service requester application 175, or service start location 173 may be determined by a current location of service requester 174 (e.g., utilizing the location-based capabilities of service requester device 170). Additionally, service requester 174 may input a service destination 172 during or after submitting service request 171. In an example using transportation services, service requester 174 is a potential passenger who wants to be picked up at service start location 173 and dropped off at service destination 172.

[0029] The computer networking system 100 may include a mapping engine 135, or may utilize a third-party mapping service, to generate map data 137 and/or traffic data in the environment surrounding the service start location 173. The mapping engine 135 may retrieve service provider locations 118 from the provider data store 190 and insert them into the map data 137. The selection engine 130 may utilize the provider locations 118 to select an optimal service provider 189 to fulfill the service request 171. As provided herein, the optimal service provider 189 may be a provider that is closest to the service requester 174 with respect to distance or time, or may be a nearby provider that is optimal for other reasons, such as the provider's experience, the amount of time the provider has been working, the provider's current earnings, and the like.

[0030] In some aspects, selection engine 130 may implement filters, including destination filter 138 and deadline filter 139, to ensure that service providers 184 are not chosen to receive service invitations 132 that would take them too far from a desired destination 114 such that they could not arrive at the location before a deadline 116. When using service provider application 185, service providers 184 may input a deadline 116 that specifies at what time they would like to stop providing the service and a destination 114 that specifies where they would like to be at that time. The service provider device 180 may send provider data corresponding to the desired destination 114 and deadline 116 to the provider management interface 115. For example, a driver providing transportation services could select that he or she wants to be home by 7 p.m. In this example, the destination is the provider's home address and the deadline is 7 p.m. In an alternative implementation, the provider management interface 115 may programmatically determine the destination 114 and deadline 116 for use cases such as hourly rentals.

[0031] The provider management interface 115 may process the destination 114 and deadline 116 request and update a mode assigned to the service provider 184 to reflect the new settings. In some aspects, the provider management interface 115 may verify the destination 114 and any restrictions on the minimum and maximum acceptable deadlines 116 to confirm the validity of the request. The provider management interface 115 may also determine whether the service provider 184 meets any conditions necessary to activate the deadline filter mode. For example, the features of the deadline filter mode, such as the ability to specify a destination, may be limited in frequency of use. Once verified, the provider management interface 115 may place the service provider 184 in the deadline filter mode. In this mode, the selection engine 130 attempts to ensure that the service provider 184 does not receive service invitations 132 that would take the provider too far from the destination 114 such that he or she would be unable to reach the desired destination 114 by the deadline 116. The provider management interface may also save the provider data in the provider data store 190 and retain that data even when the service provider 184 goes offline for breaks or other reasons.

[0032] In order to ensure that service provider 184 can reach desired destination 114 by deadline 116, computer network system 100 tracks the current location of service provider 184, and selection engine 130 estimates how long it should take service provider 184 to reach destination 114 while providing services to requesting users along the way. At periodic intervals while service provider 184 is in deadline filter mode, such as whenever the current location of service provider 184 changes, or once per minute, selection engine 130 adds the estimate to the current time and compares it to deadline 116 to determine whether the deadline limit has been reached.

[0033] The estimate of how long it should take service provider 184 to reach destination 114 includes estimates for the time it would take to reach destination 114 if service provider 184 went directly from the current location plus any time spent providing services to requesting users along the way. In one aspect, selection engine 130 may implement a destination filter mode that offers service providers 184 only those service requests 171 that the provider can fulfill along the way to specified destination 114. In an example where service provider 184 is a driver offering transportation services, the time spent providing services may account for expected delays arising from taking a detour to pick up and drop off passengers, as well as expected wait times for passengers to enter and exit the car. This time may be expressed as the expected_time_to_arrival_with_destination_filter. An exemplary estimate for such a time is:

[0034] direct_time_to_destination_from_current_location * 1.5 + 20 minutes

[0035] The direct_time_to_destination_from_current_location is estimated from mapping resources, such as the mapping engine 135, and the constants are configurable. The multiplier considers the fact that a longer distance tends to yield more intermittent service requests 171. The offset ensures sufficient buffer time when the destination 114 is nearby. In other aspects, historical travel time data 195 from a historical data store 194, which is collected from service providers 184 in destination filter mode, is used to estimate the expected_time_to_arrival_with_destination_filter.

[0036] Once the calculated duration is equal to or greater than the time remaining until the deadline 116 that the provider configured, the provider management interface 115 informs the service provider 184 that it is time to head to the destination 114 via a mode change request notice 117 displayed on the service provider device 180. If the service provider 184 is currently providing service to a user when the provider management interface 115 determines that it is time to head toward the destination 114, the service provider application 185 may wait until the service is completed and then inform the service provider 184 that he or she should head toward the destination 114.

[0037] In response to the prompt to head to destination 114, service provider 184 may choose to enter destination filter mode, set a new deadline 116, or remove deadline 116 altogether. Provider management interface 115 may then process service provider 184's response to the prompt. If service provider 184 chooses to enter destination filter mode (e.g., by providing an entry), provider management interface 115 sets provider mode and waits for the provider to proceed toward destination 114. Thereafter, selection engine 130 offers service provider 184 only service invitations 132 that are on the route from the current location to destination 114. Therefore, in destination filter mode, invitations offered to service provider 184 should not take service provider 184 too far off the route such that he or she cannot arrive at destination 114 before deadline 116. In some aspects, service provider 184 may configure destination filter mode settings such that service invitations 132 may cause deadline 116 to be missed by a correction factor (e.g., 5 minutes). Additionally, in some examples, while in destination filter mode, service provider 184 may receive preferential treatment (i.e., boosting) from computer networking system 100 and is considered to have higher priority than providers in normal mode for service invitations 132 that are along the route.

[0038] Before the deadline limit is reached, the selection engine 130 offers the service provider 184 service invitations 132 without any restrictions on direction. However, the offered service invitations 132 are restricted by a deadline filter 139 that checks whether the service provider 184 has time to fulfill the service invitation 132 and still reach the destination 114 while providing services to requesting users along the way. Therefore, when the requester interface 125 receives a service request 171 from a user, the selection engine 130 estimates the time required for the service provider 184 to travel from the current location to the service start location, from the service start location to the service destination, and from the service destination to the desired destination 114.

[0039] To determine the likelihood of an incoming service request 171 passing the deadline filter 139, the selection engine 130 may calculate an expected time for the service provider 184 to complete the service request 171. In one example, the expected time at completion is the current time plus an estimate for the travel time from the current location to the service start location and then from the service start location to the service destination, taking into account factors such as traffic conditions and time required at each location to perform aspects of the service. The deadline filter 139 may further estimate how long the service provider 184 should take to travel from the service destination to the desired destination 114, while still accepting and fulfilling service requests 171 along the way to the desired destination 114, expressed as the expected_time_to_arrival_with_destination_filter. An exemplary estimate for such a time is:

[0040] direct_time_to_destination_from_service_dest ination * 1.5 + 20 minutes

[0041] As with the deadline threshold, the deadline filter calculation may estimate direct_time_to_destination_from_service_destination from mapping resources, such as the mapping engine 135, and travel times 195 from a historical data store 194. In some implementations, the constants may be configured to estimate times with greater accuracy if the data shows that the default constants are suboptimal. The multiplier considers the fact that a longer distance tends to yield more bursty service requests 171. The offset ensures sufficient buffer time when the destination 114 is nearby. In other aspects, historical data collected from service providers 184 in destination filter mode is used to estimate the expected_time_to_arrival_with_destination_filter. As a result, the deadline filter 139 more aggressively filters service requests 171 as the deadline 116 approaches, and/or the service provider 184 travels further away from the desired destination 114.

[0042] The deadline filter 139 then adds the expected time at completion and the expected_time_to_arrival_with_destination_filter and compares the result with the deadline 116. If the result is on or before the deadline 116, the request passes the destination filter and the service provider 184 is a possible candidate to fulfill the service request 171. If the result is after the deadline 116, the computer networking system 100 filters the service provider 184 from a set of candidate providers and instead chooses a provider other than the candidate configured to fulfill the service request 171. In alternative implementations, the selection engine 130 may instead choose an optimal service provider 189 from the set of candidate providers before checking the possibility of the request passing any filters. In this case, if the chosen optimal service provider 189 is in deadline filter mode, the selection engine 130 then checks whether the request passes the deadline filter 139 and, if not, chooses the next available service provider 184.

[0043] Once the optimal service provider 189 has been selected, the selection engine 130 may generate a service invitation 132 to fulfill the service request 171 and transmit the service invitation 132 to the optimal service provider device via the service provider application 185. In addition to the service invitation 132, the computer network system 100 may transmit requester information 147, such as a name and photograph of the service requester 174, from a requester data store 192. Upon receipt of the service invitation 132, the optimal service provider 189 may accept or reject the invitation 132. Rejecting the invitation 132 may cause the selection engine 130 to determine another optimal service provider 189 from the set of candidate service providers 184 to fulfill the service request 171. However, if the optimal service provider 189 accepted (e.g., via an acceptance entry), then the acceptance entry is transmitted back to the selection engine 130, which generates and transmits an acknowledgment from the optimal service provider 189 to the service requester 174 via the service requester application 175 on the service requester device 170.

[0044] In some aspects, the provider management interface 115 may continue to monitor the deadline limit while the service provider 184 services a service request 171. If the service provider 184 is currently providing service to a user when the provider management interface 115 determines that it is time to head toward destination 114, the service provider application 185 may wait until the service is completed and then inform the service provider 184 that he or she should head toward destination 114. Once the request for the current service being performed has passed the deadline filter 139, this may only happen in situations where traffic conditions on the route worsen significantly, or other aspects of the service request 171 take significantly longer than estimated.

[0045] Before reaching destination 114, destination filter 138 in selection engine 130 filters service requests 171 so that the provider is only offered service invitations 132 that are along the route from the provider's current location to destination 114. Therefore, when computer networking system 100 receives a service request 171 from a user, computer networking system 100 checks the service start location and service destination, and determines whether paths from the provider's current location to the service start location and service destination are near or along the route from the current location to the desired destination 114. If they are not, selection engine 130 filters service provider 184.

[0046] According to examples provided herein, network computer system 100 may include a content engine 120 that manages a manner in which content is displayed on service requester devices 170 and/or service provider devices 180. With respect to service requester devices 170, content engine 120 may provide content updates based on user inputs 179 in a user interface generated by service provider application 185. For example, a user selection on a content resource of service provider application 185 may cause content engine 120 to generate a new screen in service provider application 185 or cause a current screen to pivot between certain displayed resources. When entering a particular destination 114, the service provider 184 may utilize a location pin and map content and place the location pin at a particular location on the map content to enter the destination 114. Additionally, the content engine 120 may adjust the appearance of a deadline input box to overlay the map content, which may allow the service provider 184 to select a time for the deadline 116.

[0047] In various implementations, the requester data store 192 may store service requester profiles specific to individual users of the on-demand service. Such information may include user preferences for service types, routine routes, service start locations 173 and service destinations 172, work addresses, home addresses, addresses of frequently visited locations (e.g., a gym, market, shopping mall, local airport, sports arena or stadium, concert hall, local parks, and the like). Additionally, the provider data store 190 may store service provider profiles that indicate information specific to individual providers, such as vehicle type, service metrics, earnings data, and provider experience. The database 140 may also store historical data 141 regarding the service requester and service provider liquidity for a given area, i.e., how often a new service provider 184 is expected to become available for on-demand services in the area.

[0048] Figure 2 is a timeline illustrating examples of events that may occur during the provision of services in a deadline filter mode, according to examples described herein. At the beginning of the timeline, the computer network system 100 may receive a destination and a deadline from a service provider that specifies when the service provider would like to stop providing services and where such service provider would like to be at such time. For example, a driver might select that he or she wants to be home by 7 p.m. In this example, the destination is the provider's home address and the deadline is 7 p.m.

[0049] At start time 201, a provider management interface 115 of the computer network system 100 may process the destination and deadline request and update the mode assigned to the service provider to reflect the received destination and deadline. In some aspects, the provider management interface 115 may verify the destination and any restrictions on the minimum and maximum acceptable deadlines to confirm the validity of the request. The provider management interface 115 may also determine whether the service provider meets any conditions necessary to activate the deadline filter mode. For example, the features of the deadline filter mode, such as the ability to specify a destination, may be limited in frequency of use. Once verified, the provider management interface 115 may place the service provider in the deadline filter mode. In this mode, the computer networking system 100 attempts to ensure that the service provider does not receive service invitations that would take the provider too far from the destination, such that he or she would not be able to reach the desired destination by the deadline.

[0050] Before the deadline limit is reached, the computer network system 100 offers the service provider service invitations without any restrictions on direction. However, the offered service invitations are restricted by a deadline filter that checks whether the service provider has time to fulfill the service invitation and still reach the destination while providing services to requesting users along the way (i.e., traveling to the destination in destination filter mode). For example, when the computer network system 100 receives a service request from a user, the computer network system 100 estimates the time required for the service provider to travel from the current location to the service start location, from the service start location to the service destination, and from the service destination to the desired destination. In an example using transportation services, the user is a potential passenger who wants to be picked up at the service start location and dropped off at the service destination.

[0051] To determine whether an incoming service request will pass the deadline filter, the computer network system 100 may calculate an expected time for the service provider to complete the service request. In one example, the expected time at completion is the current time plus an estimate for travel time from the current location to the service start location and then from the service start location to the service destination, taking into account factors such as traffic conditions and time required at each location to perform aspects of the service. The deadline filter may further estimate how long it would take the service provider to travel from the service destination to the desired destination while still accepting and fulfilling service requests along the way to the desired destination, expressed as the expected_time_to_arrival_with_destination_filter. An exemplary estimate for such a time is:

[0052] direct_time_to_destination_from_service_dest ination * 1.5 + 20 minutes

[0053] The deadline filter calculation may estimate direct_time_to_destination_from_service_destination from mapping resources, such as the mapping engine 135, and the constants are configurable. The multiplier considers the fact that a longer distance tends to yield more bursty service requests. The offset ensures sufficient buffering time when the destination is close. In other aspects, historical data collected from service providers in destination filter mode is used to estimate the expected_time_to_arrival_with_destination_filter.

[0054] The deadline filter then adds the expected time at the service destination and the expected_time_to_arrival_with_destination_filter, and compares the result with the deadline. If the result is on or before the deadline, the request passes the destination filter and the service provider is a possible candidate to fulfill the service request. If the result is after the deadline, the computer networking system 100 filters the service provider from a set of candidate providers and instead chooses a different provider from the set of candidates to fulfill the service request. In alternative implementations, the computer networking system 100 may instead choose an optimal service provider from the set of candidate providers before checking the possibility of the request passing any filters. In this case, if the chosen optimal service provider is in deadline filter mode, the computer networking system 100 then checks whether the request passes the deadline filter, and otherwise chooses the next available service provider.

[0055] To ensure that the service provider can reach the desired destination by the deadline, the computer network system 100 tracks the service provider's current location and estimates how long it would take the service provider to reach the destination while providing services to requesting users along the way (i.e., traveling to the destination in destination filter mode). At periodic intervals while the service provider is in deadline filter mode, such as whenever the service provider's current location changes or once per minute, the computer network system 100 adds the estimate to the current time and compares it to the deadline to determine whether the deadline limit has been reached.

[0056] Once the deadline limit has been reached at inflection point 210, the computer networking system 100 informs the service provider that it is time to head to the destination via a notice displayed on the service provider device 180. If the service provider is currently providing service to a user when the computer networking system 100 determines that it is time to head to the destination, the service provider application 185 may wait until the service is completed and then inform the service provider that he or she should head to the destination.

[0057] In response to the prompt to proceed to the destination, the service provider may choose to enter destination filter mode, set a new deadline, or remove the deadline altogether (e.g., by providing an input). The computer networking system 100 may then process the service provider's response to the prompt. If the service provider chooses to enter destination filter mode, the computer networking system 100 sets service provider mode and waits for the provider to travel toward the destination. From then on, the computer networking system 100 offers the service provider only service invitations that are along the route from the current location to the destination. Therefore, in destination filter mode, invitations offered to the service provider must not take the service provider too far from the route such that he or she cannot reach the destination before the deadline 216. In some aspects, the service provider may configure destination filter mode settings such that service invitations may cause the deadline to be missed by a correction factor (e.g., 5 minutes). Additionally, while in destination filter mode, the service provider may receive preferential treatment (i.e., boosting) from the computer networking system 100 and be given higher priority than providers in normal mode for service invitations that are along the route.

[0058] When the service provider is available to receive a new service invitation (or through the rejection of an invitation or service completion), the computer networking system 100 or the service provider device 180 itself may monitor the location of the service provider to determine whether the provider has arrived at the desired destination. Once the provider has arrived at the desired destination, the service provider application 185 may place the service provider in an offline mode in which the provider is not available to receive service invitations.

[0059] In an example use case, a service provider named Joe leaves his home at 10 a.m. to provide transportation services to local passengers. Since he leaves his home in the morning, he sets his desired destination to his home address in Palo Alto, California, and specifies an arrival deadline of 6 p.m. His provider status is updated to online (e.g., available to provide service), and he soon receives and accepts a service invitation 132 to transport a passenger to San Jose. While he is providing the service, the provider status is in the "busy" "traveling" state.

[0060] At 11 a.m. in San Jose, Joe receives and accepts a service invitation with a delivery location in San Francisco. At 1 p.m. in San Francisco, Joe goes offline using the service provider application 185 and takes a one-hour lunch break. While he is on the break, the computer network system 100 may retain Joe's destination and deadline settings so that they persist when he comes back online. At 2 p.m. in San Francisco, Joe goes online and receives a service invitation 132 that sends him to Oakland, where he receives multiple local service invitations 132 and drives around the Oakland area.

[0061] At 4 p.m. in Oakland, a user near Joe requests a ride to San Jose. However, computer network system 100 estimates that it would take Joe 1.5 hours to pick up the user and drive him to San Jose under current traffic conditions. Computer network system 100 further estimates that Joe might not arrive from San Jose at 5:30 p.m. to his home in Palo Alto by the 6 p.m. deadline. Therefore, computer network system 100 filters out Joe and chooses a different driver to take the user to San Jose. Instead, Joe receives a 132 service invite back to San Francisco that meets the deadline.

[0062] At 4:30 p.m. in San Francisco, another user near Joe requests a ride to South San Francisco. Computer networking system 100 estimates that Joe would arrive by 5:15 p.m., and that the nonstop time from South San Francisco to Palo Alto is 40 minutes. Therefore, Joe's estimated expected time of arrival (ETA) would be 5:55 p.m. However, using the example destination filtering formula, computer networking system 100 estimates that it would take 80 minutes (1.5 * 40 minutes + 20 minutes) for Joe to drive from South San Francisco to Palo Alto while servicing service requests along the route in destination filter mode. Thus, despite having the capacity to service the South San Francisco service request and reach his desired destination by the deadline, Joe would not have time to service additional service requests while driving from South San Francisco to Palo Alto. As a result, the 100 computer network system filters out Joe and chooses a different driver to take the user to South San Francisco.

[0063] Instead, Joe receives a request from a user who wants a ride to Menlo Park with an ETA of 5:25 p.m. The computer networking system 100 estimates the time from Menlo Park to Joe's home as 6 minutes. Therefore, Joe's expected_time_to_arrival_with_destination_filter is 1.5 * 6 minutes + 20 minutes, which is 29 minutes. Since it is currently 5:25 p.m., Joe's expected arrival time at home while in destination filter mode is 5:54 p.m. This is before Joe's 6 p.m. deadline, so he receives the service invitation, which he accepts.

[0064] Joe drops off a passenger in Menlo Park at 5:25 p.m. The computer network system 100 determines that Joe should begin driving to his destination in order to reach it before the 6:00 p.m. deadline. A notice appears on his device telling Joe that it is time to go home. After Joe confirms, the computer network system 100 switches Joe to destination filter mode to ensure he only receives service invitations that are near or along the route from his current location in Menlo Park to his desired destination in Palo Alto. That is, the computer network system 100 filters Joe from a pool of candidate drivers for any service invitations that are not in a direction similar to his travel route. In some aspects, the computer network system 100 may determine that a service request is along a travel route when the request has a service start location and/or service destination that are within a threshold distance from a point along the travel route.

[0065] At 5:28 p.m. in Menlo Park, Joe receives a final service invitation to pick up a nearby passenger and drop her off at an address approximately 8 minutes away from Joe's home in Palo Alto. He receives the invitation because computer network system 100 estimates that he can reach the drop-off location by 5:50 p.m. At 5:50 p.m., Joe drops off the passenger and heads home, where he arrives and goes offline at 5:58 p.m.

Methodology

[0066] Figures 3-5 are flowcharts depicting exemplary methods used in filtering service requests by destination and deadline. Although the operations of the methods are described below as being performed by specific components of the computer networking system 100, it will be appreciated that these operations need not necessarily be performed by the specific components identified and may be performed by a variety of components and modules, potentially distributed across multiple machines. Accordingly, references may be made to elements of the computer networking system 100 for the purpose of illustrating components or elements suitable for performing a described step or substep. Alternatively, at least some of the variety of components and modules described in the computer networking system 100 may be arranged within a single hardware, software, or firmware component. It will also be appreciated that some of the steps of these methods may be performed in parallel or in a different order than illustrated.

[0067] Figure 3 is a flowchart depicting an exemplary method for filtering service requests by destination and deadline, in accordance with examples described herein. The computer network system 100 may receive a destination and deadline from a service provider that specifies what time the service provider would like to stop providing service and where the service provider would like to be at that time (310). For example, a driver might select that he or she wants to be home by 7 p.m. In this example, the destination is the provider's home address and the deadline is 7 p.m.

[0068] A provider management interface 115 of the computer network system 100 may process the destination and deadline request and update the mode assigned to the service provider to reflect the received destination and deadline. In some aspects, the provider management interface 115 may verify the destination and any restrictions on the minimum and maximum acceptable deadlines to confirm the validity of the request. The provider management interface 115 may also determine whether the service provider meets any conditions necessary to activate the deadline filter mode. For example, the features of the deadline filter mode, such as the ability to specify a destination, may be limited in frequency of use. Once verified, the provider management interface 115 may place the service provider in the deadline filter mode (312). In this mode, the computer networking system 100 attempts to ensure that the service provider does not receive service invitations that would take the provider too far from the destination, such that he or she would not be able to reach the desired destination by the deadline.

[0069] To ensure that the service provider can reach the desired destination by the deadline, the computer network system 100 tracks the service provider's current location and estimates how long it would take the service provider to reach the destination while providing services to requesting users along the way. At periodic intervals while the service provider is in deadline filter mode, such as whenever the service provider's current location changes or once per minute, the computer network system 100 adds the estimate to the current time and compares it to the deadline to determine whether the deadline limit has been reached (350).

[0070] The estimate of how long it would take the service provider to reach the destination includes estimates for the time it would take to reach the destination if the service provider went there directly from the current location, plus any time spent providing services to requesting users along the way. In one aspect, the computer network system 100 may implement a destination filter mode that offers service providers only those service requests that the provider can fulfill along the way to the specified destination. In an example where the service provider is a driver offering transportation services, the time spent providing services may account for expected delays arising from taking a detour to pick up and drop off passengers, as well as expected wait times for passengers to enter and exit the car. This time may be expressed as the expected_time_to_arrival_with_destination_filter. An exemplary estimate for such a time is:

[0071] direct_time_to_destination_from_current_location * 1.5 + 20 minutes

[0072] The direct_time_to_destination_from_current_location is estimated from mapping resources, such as the mapping engine 135, and the constants are configurable. The multiplier considers the fact that a longer distance tends to yield more bursty service requests. The offset ensures sufficient buffering time when the destination is nearby. In other aspects, historical data collected from service providers in destination filter mode is used to estimate the expected_time_to_arrival_with_destination_filter.

[0073] Once the calculated duration is equal to or greater than the time remaining until the deadline that the service provider configured, the computer network system 100 informs the service provider that it is time to head to the destination via a notice displayed on the service provider device 180 (360). If the service provider is currently providing service to a user when the computer network system 100 determines that it is time to head to the destination, the service provider application 185 may wait until the service is completed and then inform the service provider that he or she should head to the destination.

[0074] In response to the prompt to proceed to the destination, the service provider may choose to enter destination filter mode, set a new deadline, or remove the deadline altogether (e.g., by providing an input). The computer networking system 100 may then process the service provider's response to the prompt (361). If the service provider chooses to enter destination filter mode, the computer networking system 100 sets service provider mode and waits for the service provider to travel toward the destination. From then on, the computer networking system 100 offers the service provider only service invitations that are on the route from the current location to the destination. Therefore, in destination filter mode, invitations offered to the service provider must not take the service provider too far from the route such that he or she cannot reach the destination before the deadline. In some aspects, the service provider may configure destination filter mode settings such that service invitations may cause the deadline to be exceeded by a correction factor (e.g., 5 minutes). Additionally, while in destination filter mode, the service provider may receive preferential treatment (i.e., boosting) from the computer networking system 100 and be given higher priority than providers in normal mode for service invitations that are along the route.

[0075] Before the deadline limit is reached, the computer network system 100 offers the service provider service invitations without any restrictions on direction. However, the offered service invitations are restricted by a deadline filter that checks whether the service provider has time to fulfill the service invitation and still reach the destination while providing services to requesting users along the way. Therefore, when the computer network system 100 receives a service request from a user (320), the computer network system 100 estimates the time required for the service provider to travel from the current location to the service start location (322), from the service start location to the service destination (324), and from the service destination to the desired destination. In one example, the user is a potential passenger who wants to be picked up at the service start location and dropped off at the service destination.

[0076] To determine whether an incoming service request will pass the deadline filter, the computer network system 100 may calculate an expected time for the service provider to complete the service request. In one example, the expected time at completion is the current time plus an estimate for travel time from the current location to the service start location and then from the service start location to the service destination, taking into account factors such as traffic conditions and time required at each location to perform aspects of the service. The deadline filter may further estimate how long it would take the service provider to travel from the service destination to the desired destination while still accepting and fulfilling service requests along the way to the desired destination, expressed as the expected_time_to_arrival_with_destination_filter. An exemplary estimate for such a time is:

[0077] direct_time_to_destination_from_service_dest ination * 1.5 + 20 minutes

[0078] As with the deadline threshold, the deadline filter calculation may estimate direct_time_to_destination_from_service_destination from mapping resources, such as the mapping engine 135, and the constants are configurable. The multiplier considers the fact that a longer distance tends to yield more bursty service requests. The offset ensures sufficient buffering time when the destination is close. In other aspects, historical data collected from service providers in destination filter mode is used to estimate the expected_time_to_arrival_with_destination_filter.

[0079] The deadline filter then adds the expected time at the service destination and the expected_time_to_arrival_with_destination_filter and compares the result with the deadline. If the result is on or before the deadline, the request passes the destination filter and the service provider is a possible candidate to fulfill the service request (330). If the result is after the deadline, the computer networking system 100 filters the service provider from a set of candidate providers and instead chooses a different provider from the set of candidates to fulfill the service request (332). In alternative implementations, the computer networking system 100 may instead choose an optimal service provider from the set of candidate providers before checking the possibility of the request passing any filters. In this case, if the chosen optimal service provider is in deadline filter mode, the computer networking system 100 then checks whether the request passes the deadline filter, and otherwise, chooses the next available service provider. In another example, when the computer networking system receives a service request, the computer networking system may identify a set of candidate providers based on their locations and the originating location of the service request. If the set of candidate providers includes a service provider in deadline filter mode, the computer networking system may determine, based on the computations described, whether the service provider should be included in the set of candidate providers. If such a service provider is included in the set, the computer networking system may perform a standard selection process to select a service provider from this set or select such a service provider (e.g., given a boost), depending on the implementation.

[0080] If the service provider is chosen to fulfill the service request, the computer networking system 100 sends a service invitation to the provider, which may accept or reject the invitation. If the service provider accepts and performs the service or rejects the invitation, the computer networking system 100 processes the service provider selection and any results (334). When the service provider is available to receive a new service invitation, the computer networking system 100 may resume monitoring for the possibility that the deadline limit has been reached (350).

[0081] In some aspects, the computer network system 100 may continue to monitor the deadline limit while the service provider fulfills a service request. If the service provider is currently providing service to a user when the computer network system 100 determines that it is time to proceed to the destination, the service provider application 185 may wait until the service is completed and then inform the service provider that he or she should proceed to the destination. Since the request for the current service being performed has passed the deadline filter, this may only happen in situations where traffic conditions on the route significantly worsen or other aspects of the service request take significantly longer than estimated.

[0082] Figure 4 is a flowchart describing an exemplary method for persisting destination and deadline settings when a service provider goes offline, in accordance with examples described herein. The computer network system 100 may receive a destination and deadline from a service provider that specifies what time the service provider would like to stop providing services and where the service provider would like to be at that time (410). For example, a driver might select that he or she wants to be at a restaurant at 7 p.m. In this example, the destination is the restaurant specified by the service provider and the deadline is 7 p.m.

[0083] A provider management interface 115 of the computer network system 100 may process the destination and deadline request and update the mode assigned to the service provider to reflect the received destination and deadline. In some aspects, the provider management interface 115 may verify the destination and any restrictions on the minimum and maximum acceptable deadlines to confirm the validity of the request. The provider management interface 115 may also determine whether the service provider meets any conditions necessary to activate the deadline filter mode. For example, the features of the deadline filter mode, such as the ability to specify a destination, may be limited in frequency of use. Once verified, the provider management interface 115 may place the service provider in the deadline filter mode (412). In this mode, the computer networking system 100 attempts to ensure that the service provider does not receive service invitations that would take the provider too far from the destination, such that he or she would not be able to reach the desired destination by the deadline.

[0084] In some aspects, a service provider may switch to an offline mode in which he or she is not available to receive service invitations (420). For example, the service provider may go offline at the end of a planned business day or at the end of the day. In other examples, the service provider takes a short break with the intention of resuming accepting service invitations after the break. When a service provider in deadline filter mode goes offline, the computer networking system 100 may retain the target and deadline settings so that the service provider can resume operation in deadline filter mode when he or she comes back online.

[0085] In one implementation, the service provider application 185 or other background process on the service provider device 180 may continuously monitor for the possibility of the deadline passing or expiring while the service provider is offline (430). If the deadline passes, the service provider application 185 may remove the target and deadline settings and update the computer networking system 100 accordingly. In an alternative implementation, the computer networking system 100 may continue to monitor the deadline even when the service provider is offline. If the deadline passes, the computer networking system 100 may remove the target and deadline settings from the provider data 190 (435).

[0086] Once the service provider has chosen to resume receiving service requests through the service provider application 185, the computer networking system 100 receives an indication that the provider is back online (440). To ensure that the service provider can reach the desired destination by the deadline, the computer networking system 100 checks the service provider's current location and estimates how long it would take the service provider to reach the destination while providing services to requesting users along the way. The computer networking system 100 adds the estimate to the current time and compares it to the deadline to determine whether the deadline limit has been reached (450).

[0087] The estimate of how long it would take the service provider to reach the destination includes estimates for the time it would take to reach the destination if the service provider went there directly from the current location, plus any time spent providing services to requesting users along the way. In one aspect, the computer network system 100 may implement a destination filter mode that offers service providers only those service requests that the provider can fulfill along the way to the specified destination. In an example where the service provider is a driver, the time spent providing services may account for expected delays arising from taking a detour to pick up and drop off passengers, as well as expected wait times for passengers to enter and exit the car. This time may be expressed as the expected_time_to_arrival_with_destination_filter. An exemplary estimate for such a time is:

[0088] direct_time_to_destination_from_current_location * 1.5 + 20 minutes

[0089] The direct_time_to_destination_from_current_location is estimated from mapping resources, such as the mapping engine 135, and the constants are configurable. The multiplier considers the fact that a longer distance tends to yield more bursty service requests. The offset ensures sufficient buffering time when the destination is nearby. In other aspects, historical data collected from service providers in destination filter mode is used to estimate the expected_time_to_arrival_with_destination_filter.

[0090] Once the calculated duration is equal to or greater than the time remaining until the deadline that the service provider configured, the computer networking system 100 informs the service provider that it is time to travel to the destination via a notice displayed on the service provider device 180 (460). In some implementations, the computer networking system 100 may continue to monitor the current location of the service provider and determine whether the deadline limit has been reached even while the provider is offline. In such a case, the computer networking system 100 may advise the offline service provider to travel to the destination, and/or come online and switch to destination filter mode, so as to reach the destination by the deadline.

[0091] In one implementation, the notice generated in response to the deadline limit being reached is a modal window displayed through the service provider application 185. This modal window may offer the service provider three options.

[0092] In a first option, the service provider may choose to enter destination filter mode (462). The computer networking system 100 places the provider in destination filter mode and begins filtering service invitations to only those that are on the route between the service provider's current location and the configured destination (470). When choosing this option, the service provider application 185 may also display information related to the destination filter mode, such as special conditions that may apply to such mode.

[0093] In a second option, the service provider may choose to delay entering destination filter mode and remain in deadline filter mode longer by setting a new, later deadline (464).

[0094] In a third option, the service provider may choose to cancel the deadline and remove the destination (466). With this option, the provider is no longer in deadline filter mode and does not enter destination filter mode. Instead, the computer networking system 100 places the service provider in common mode, indicating a normal online situation (475).

[0095] Figure 5 is a flowchart depicting an exemplary method for filtering service or destination requests, according to examples described herein. In one aspect, the computer networking system 100 may receive a destination from a service provider that specifies where the provider is traveling (510). In another aspect, the computer networking system 100 has a stored destination for a service provider that is in deadline filter mode. Once the deadline limit for the deadline filter mode has been reached, the computer networking system 100 may transition the service provider to destination filter mode. For example, a driver may set a home address as the destination when the driver is traveling home.

[0096] A provider management interface 115 of the computer networking system 100 may process the destination request and update the mode assigned to the service provider to reflect the destination. In some aspects, the provider management interface 115 may verify the destination and any restrictions on the destination to confirm the validity of the request. The provider management interface 115 may also determine whether the service provider meets any conditions necessary to activate the destination filter mode. For example, features of the destination filter mode may be limited in frequency of use. Once verified, the provider management interface 115 may place the service provider in the destination filter mode (512).

[0097] Before reaching the destination, the computer network system 100 filters service requests so that the provider is offered only service invitations that are along the route from the provider's current location to the destination. Therefore, when the computer network system 100 receives a service request from a user (520), the computer network system 100 checks the service start location (522) and service destination (524) and determines whether paths from the provider's current location to the service start location and service destination are near or along the route from the current location to the desired destination (530). In one example, the user is a potential passenger who wants to be picked up at the service start location and dropped off at the service destination. If the service start location and service destination location are not near or along the provider's route from the current location to the desired destination (e.g., the service start location and/or service destination are not within a threshold distance from a point along the travel route), the computer networking system 100 filters the service provider from a pool of provider candidates and instead chooses a different provider from the pool of candidates to fulfill the service request (532). Conversely, if the service start location and service destination location are near or along the provider's route from the current location to the desired destination, the service provider is a viable candidate to fulfill the service request, and the computer networking system 100 may proceed with processing the service provider selection and results (534).

[0098] The computer networking system 100 may utilize the current locations of service providers in a region to choose an optimal service provider to fulfill the service request (535). As provided herein, the optimal service provider may be a service provider that is closest to the service requester with respect to distance or time, or may be a nearby service provider that is optimal for other reasons, such as the service provider's experience, the amount of time the service provider has been working, the service provider's current earnings, and the like. In some implementations, the computer networking system 100 may prioritize service providers in a destination filter fashion for service requests that are near or along the provider's route from the current location to the desired destination.

[0099] Once the optimal service provider is selected, the computer networking system 100 may generate a service invitation to fulfill the service request and transmit the service invitation to the optimal service provider device via the service provider application 185 (540). Upon receiving the service invitation, the optimal service provider may either accept or reject the invitation. Rejecting the invitation may cause the computer networking system 100 to select a next available service provider from the set of candidate service providers to fulfill the service request (542). However, if the optimal service provider accepts (e.g., via an acceptance input in a user interface of the service provider application 185), then the acceptance input may be transmitted back to the computer networking system 100, which may generate and transmit information identifying the optimal service provider to the service requester via the service requester application 175 on the service requester device 170 (544). The service provider then fulfills the service request at the service start location and/or service destination (545). In an example using transport services, the service provider picks up the service requester at the service start location and drops off the service requester at the service destination.

[00100] When the service provider is available to receive a new service invitation (or through the rejection of an invitation or completion of a service), the computer network system 100 or the service provider device 180 itself may resume monitoring and verifying the service provider's location to determine whether the provider has arrived at the desired destination (550). Once the provider has arrived at the desired destination, the service provider application 185 may place the service provider into an offline mode in which the provider is not available to receive service invitations (560). Alternatively, the service provider application 185 may prompt the provider to choose whether to go offline or return to a regular service mode.

User Interface Examples

[00101] Figures 6A and 6B illustrate exemplary user interfaces on a service provider device, according to examples described herein. In one example, execution of service provider application 185 on service provider device 180 may cause the device to generate an application interface on the device's touch display.

[00102] In the exemplary user interface illustrated in Figure 6A, a service provider may enter deadline filtering mode by choosing a destination and a deadline that specifies at what time the service provider would like to stop providing services and where such service provider would like to be at such time (e.g., by providing input). For example, a driver providing transportation services could select that he or she wants to be home by 7 p.m. In this example, the destination is the provider's home address and the deadline is 7 p.m. Once in deadline filtering mode, the computer networking system 100 attempts to ensure that the service provider does not receive service invitations that would take the provider too far from the destination such that he or she would not be able to reach the desired destination by the deadline.

[00103] In one implementation, when not currently providing service to a user, the service provider may select a menu icon in the service provider application 185 to request deadline filtering mode. In response, the service provider application 185 may display the interface shown in Figure 6A to allow the provider to set a destination and deadline. The service provider may choose the destination from saved locations or search for a new address to use as the destination. The earliest selectable deadline, or arrival time, that the service provider is permitted to select is the shortest time such that the computer networking system 100 is confident that it can direct the service provider from the current location to the destination in time, while the service provider services service requests along the way. Additionally, the user interface may limit the selectable latest arrival time to a longer reasonable length of a business day (e.g., 12 hours). Once the service provider has selected a destination and deadline, the provider may press the DONE button to transmit the request to the computer networking system 100.

[00104] In some aspects, the computer network system 100 may verify the destination and any restrictions on the minimum and maximum acceptable deadlines to confirm the validity of the request. The computer network system 100 may also determine whether the service provider meets any conditions necessary to activate the deadline filter mode. For example, the features of the deadline filter mode, such as the ability to specify a destination, may be limited in frequency of use. Once verified, the computer network system 100 may place the service provider in the deadline filter mode.

[00105] Figure 6B illustrates an exemplary modal window displayed when the deadline limit has been reached. To ensure that the service provider can reach the desired destination by the deadline, the computer network system 100 tracks the service provider's current location and estimates how long it would take the service provider to reach the selected destination while providing services to requesting users along the way. At periodic intervals while the service provider is in deadline filter mode, such as whenever the service provider's current location changes or once per minute, the computer network system 100 adds the estimate to the current time and compares it to the deadline to determine whether the deadline limit has been reached.

[00106] Once the deadline limit is reached, the computer networking system 100 informs the service provider that it is time to head to the destination via a notice displayed on the service provider device 180 via the service provider application 185. If the service provider is currently providing service to a user when the computer networking system 100 determines that it is time to head to the destination, the service provider application 185 may wait until the service is completed and then inform the service provider that he or she should head to the destination.

[00107] When presented with the modal window shown in Figure 6B, the service provider may choose to enter destination filter mode by selecting OK. From then on, the computer networking system 100 offers the service provider only service invitations that are on the route from the current location to the destination. Therefore, in destination filter mode, invitations offered to the service provider must not take the service provider too far from the route such that he or she cannot reach the destination before the deadline. Alternatively, the service provider may select REMOVE to ignore the deadline and return to a normal online status mode. In an additional alternative not illustrated, the service provider may choose a new deadline using an interface such as that illustrated in Figure 6A.

[00108] In some aspects, the service provider application user interface 185 may display an indication to the service provider that the provider is in deadline filter mode. This indication may also include the selected deadline. For example, the top portion of the user interface may display that the provider is online and that he or she has a "scheduled destination for 7:00 p.m." Further, when the service provider is offline, the user interface may retain the deadline and continue to display the deadline in the illustrated status bar. Additionally, a map displayed as part of the user interface may indicate the selected destination with an icon, such as a star at the destination.

Service Provider Device

[00109] Figure 7 is a block diagram illustrating an exemplary service provider device executing a service provider application designed for an on-demand service as described herein. In many implementations, the service provider device 780 may comprise a mobile computing device, such as a smartphone, tablet computer, laptop computer, VR or AR headset device, and the like. Thus, the service provider device 780 may include typical telephony features such as a microphone 745, a camera 750, and a communication interface 710 for communicating with external entities using any number of wireless communication protocols. In certain aspects, the service provider device 780 may store a designated application (e.g., a service provider application 732) in a local memory 730. In many aspects, the service provider device 780 additionally stores information corresponding to a contact list 734 and calendar appointments 736 in the local memory 730. In variations, the memory 730 may store additional applications executable by one or more processors 740 of the service provider device 780, allowing access to and interaction with one or more host servers via one or more networks 760.

[00110] In response to user input 718, service provider application 732 may be executed by a processor 740, which may cause an application interface to be generated on a display screen 720 of service provider device 780. The application interface may allow the service provider to, for example, check current pricing and availability levels for on-demand ride services. In various implementations, the application interface may further allow the service provider to select from multiple ride service types, such as a car pool service type, a common ride sharing service type, a professional ride service type, an on-demand van service type, a luxury ride service type, and the like.

[00111] The provider may enter various states or modes, such as online mode, destination filter mode, and deadline filter mode, via user inputs 718 provided in the application interface. For example, the provider may select which types of service he or she is available to provide, as well as a desired destination 714 and deadline 716 to be at such destination. As provided herein, the service provider application 732 may further enable a communication link with a computer networking system 700 over network 760, such as the computer networking system 100 as shown and described in connection with Figure 1. Furthermore, as discussed herein, the service provider application 732 may display requester information 742 in the application interface that includes data regarding a service requester, so that the provider may choose whether to accept or reject a service invitation received from the computer networking system 700.

[00112] Processor 740 may transmit provider status 713 (i.e., modes the provider is in) via a communication interface 710 to backend computer networking system 700 over a network 760. In various examples, service provider device 780 may further include a GPS module 755, which may provide location data 762 indicating the current location of the provider to computer networking system 700 to, for example, select an optimal service provider or filter the provider based on destination 714 and deadline 716. In alternative aspects, hardwired circuitry may be used in place of, or in combination with, software instructions to implement examples described herein. Thus, the described aspects are not limited to any particular combination of hardware and software circuitry.

Hardware Diagram

[00113] Figure 8 is a block diagram illustrating a computer system upon which examples described herein may be implemented. A computer system 800 may be deployed on, for example, a server or combination of servers. For example, the computer system 800 may be implemented as part of a service network to provide service services. In the context of Figure 1, the computer network system 800 may be implemented using a computer system 800 such as that described by Figure 8. The computer network system 100 may also be implemented using a combination of multiple computer systems, as described in connection with Figure 8.

[00114] In one implementation, the computer system 800 comprises processing resources 810, a main memory 820, a read-only memory (ROM) 830, a storage device 840, and a communication interface 850. The computer system 800 comprises at least one processor 810 for processing information stored in the main memory 820, such as provided by a random access memory (RAM) or other dynamic storage device, to store information and instructions that are executable by the processor 810. The main memory 820 may also be used to store temporary variables or other intermediate information during the execution of instructions to be executed by the processor 810. The computer system 800 may also include ROM 830 or other static storage device for storing static information and instructions for the processor 810. A storage device 840, such as a magnetic disk or optical disk, is provided for storing information and instructions.

[00115] Communication interface 850 allows computer system 800 to communicate with one or more networks 880 (e.g., cellular network) through use of the network link (wireless or wired). Using the network link, computer system 800 may communicate with one or more computing devices, one or more servers, and/or one or more autonomous vehicles. Examples include computer system 800 receiving service requests 882 from individual users' mobile computing devices. Executable instructions stored in memory 830 may have destination filtering instructions 824 and deadline filtering instructions 826, which processor 810 executes to determine whether to filter a service provider based on destination and/or deadline. In doing so, the computer system may receive a provider status 884 for service providers operating throughout the given region, and the processor may select an optimal service provider from a set of available service providers and transmit a service invitation 852 to allow the service provider to accept or reject the service offer.

[00116] By way of example, instructions and data stored in memory 820 may be executed by processor 810 to implement an example computer networking system 100 of Figure 1. In performing operations, processor 810 may receive service requests 882 and provider status 884 and send service invitations 852 to facilitate fulfillment of service requests 882.

[00117] Processor 810 is configured with software and/or other logic to perform one or more processes, steps, and other functions described with implementations as described by Figures 1-6, and elsewhere in this application.

[00118] The examples described herein relate to the use of computer system 800 to implement the techniques described herein. According to one embodiment, these techniques are performed by computer system 800 in response to processor 810 executing one or more sequences of one or more instructions contained in main memory 820. Such instructions may be read into main memory 820 from another machine-readable medium, such as storage device 840. Execution of the sequences of instructions contained in main memory 820 causes processor 810 to perform the process steps described herein. In alternative implementations, hardwired circuitry may be used in place of or in combination with software instructions to implement the examples described herein. Thus, the described examples are not limited to any particular combination of hardware and software circuitry.

[00119] It is contemplated by examples described herein to extend to individual elements and concepts described herein, independently of other concepts, ideas, or systems, as well as by examples to include combinations of elements recited elsewhere in this application. Although the examples are described in detail herein with reference to the accompanying drawings, it should be understood that the concepts are not limited to these precise examples. As such, many modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended that the scope of the concepts be defined by the following claims and their equivalents. Furthermore, it is contemplated that a specific feature described individually or as part of an example may be combined with other individually described features, or parts of other examples, even if the other features and examples do not mention the specific feature. Thus, the absence of descriptive combinations should not preclude the claiming of rights to such combinations.

Claims (10)

1. A networked computer system comprising: one or more processors; and one or more memory resources storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations that include: receiving, via the network, request data corresponding to a plurality of service requests from a plurality of user devices, the plurality of service requests each including a service start location and a service destination; tracking the current location of a service provider that is traveling to a specified destination; determining whether a time for the service provider to reach the specified destination is within a deadline boundary; upon determining that the travel time is within the deadline boundary, for each service request among the plurality of service requests: (i) consulting one or more mapping resources to determine a first expected travel time from the current location of the service provider to the service start location, a second expected travel time from the service start location to the service destination, and a third expected travel time from the service destination to the specified destination; (ii) determining whether the service provider is able to fulfill the service request and travel to the specified destination before the deadline, based at least in part on the first expected travel time, the second expected travel time, and the third expected travel time; and (iii) based at least in part on the determination that the service provider is able to fulfill the service request and travel to the specified destination before the deadline, match the service provider with one or more service requesters, wherein the match of the service provider with one or more service requesters is also, in part, based on a service request from each of the one or more service requesters being within a corresponding threshold distance of a point on the route between the service provider's current location and the specified destination. 2. The networked computer system of claim 1, wherein the operations further comprise: for each service request of the plurality of service requests, determining the expected additional time for the service provider to provide services related to fulfilling the service request; and wherein determining that the service request is capable of fulfilling it and traveling to the specified destination before the deadline is based, at least in part, on the expected additional time. 3. The networked computer system of claim 1 or 2, wherein the operations further comprise: for each service request of the plurality of service requests, identifying the service provider as a candidate to fulfill that service request. 4. The networked computer system of claim 3, wherein the operations further comprise: for each service request of the plurality of service requests, prioritizing the service provider's matching of that service request in response to determining that the service provider is the candidate. 5. The networked computer system of claim 1, wherein the operations, when executed by one or more processors, cause the networked computer system to: prioritize the service provider for service requests along the route between the service provider's current location and the specified destination. 6. The networked computer system of claim 1, wherein the operations further comprise: determining the first expected travel time, the second expected travel time, the third expected travel time, and the fourth expected travel time, based in part on historical data from the service provider. 7. The networked computer system of claim 1, wherein the operations, when executed by one or more processors, cause the system to: receive data from a service provider's device indicating that the service provider has gone offline; and upon receiving data indicating that the service provider has gone offline, store the specified destination and deadline, and the determination that the travel time is within the deadline limit. 8. The networked computer system of claim 7, wherein the operations further comprise: upon receiving data that the service provider has gone offline, monitoring the time period while the service provider is offline. 9. The networked computer system of claim 7, wherein the operations further comprise: upon receiving data that the service provider has returned online after the time limit has expired, removing the specified target and time limit. 10. The networked computer system of claim 1, wherein the operations, when executed by one or more processors, cause the system to: upon determining that the travel time is within the deadline limit, periodically determine whether the deadline limit has been reached each time the current location of the service provider changes.