BACKGROUND

In recent years, popularity and usage of on-demand transportation matching systems have significantly grown. Indeed, the proliferation of web and mobile applications easily enable requesting individuals to request transportation from one geographic area to another geographic area. For instance, an on-demand transportation matching system receives transportation requests and pairs the requests with providers that can transport requesting individuals to the destination locations. In addition, the on-demand transportation matching system provides tools to providers to pick up requesting individuals as well as transport them to the destination locations.

Typically, on-demand transportation matching systems use computational models to match requests with nearby providers of transportation vehicles. As on-demand transportation matching systems can receive large numbers of transportation requests within a short timeframe across the entirety of serviced areas or within any given region, the on- demand transportation matching systems can perform a large number of matching operations/processes at any given time, particularly during peak/busy times. Additionally, it is typical for the number of received transportation requests for an area to exceed the number of available providers, while at the same time, other areas may have more providers than requests.

Some on-demand transportation matching systems attempt to balance the supply and demand by matching providers with requests in different areas, resulting in providers being required to travel greater distances to reach pickup locations for some requests than for others. Often, once providers have received requests to transport requesters, the providers can still cancel the request prior to the provider fulfilling the request (e.g., based on a provider not wanting to travel to a pickup location) and instead opt to accept other requests (e.g., requests that are closer to the provider’s current location). When a provider cancels a request, the on-demand transportation matching systems re-process the request to match the request with a new provider, resulting in additional, unplanned operations by the systems. A large number of cancelations can significantly impact the performance of the systems by increasing the number of matches the systems process, as well as delay matching/processing of other transportation requests.

These and other problems exist with conventional transportation matching systems.

SUMMARY

This disclosure describes one or more embodiments of methods, non-transitory computer readable media, and systems that solve the foregoing problems in addition to providing other benefits. While this summary refers to systems for simplicity, the summary also applies to certain disclosed methods and non-transitory computer readable media. To solve the foregoing and other problems, the disclosed systems determine whether to generate a modifier for each transportation request after a provider has fulfilled the transportation request. Specifically, the disclosed systems determine a surplus metric for a transportation request based on a combination of a response time period and a service time period of a transportation provider device in connection with the transportation request. In response to determining that the surplus metric fails to meet a predetermined threshold, the disclosed systems can then use the surplus metric to generate a modifier to apply to the transportation request. Furthermore, the disclosed systems then generate a message to send to a transportation provider device based on the modifier for display to the transportation provider.

Additional features and advantages of one or more embodiments of the present disclosure will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of such example embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

The detailed description refers to the drawings briefly described below.

FIG. 1 illustrates a block diagram of an environment for implementing a transportation matching system in accordance with one or more embodiments.

FIGS. 2A-2C illustrate embodiments of a plurality of transportation requests in accordance with one or more embodiments.

FIGS. 3A-3C illustrate a graphical user interface of a provider client device presenting a transportation request in accordance with one or more embodiments.

FIG. 4 illustrates a flowchart of a series of acts in a method of modifying transaction requests based on surplus metrics in accordance with one or more embodiments.

FIG. 5 illustrates a block diagram of a computing device in accordance with one or more embodiments.

FIG. 6 illustrates an example environment for a transportation matching system in accordance with one or more embodiments.

DETAILED DESCRIPTION

One or more embodiments of the present disclosure include a transportation matching system that modifies transportation requests that do not meet a surplus threshold. In particular, the transportation matching system dynamically generates a modifier to apply to fulfilled transportation requests based on surplus metrics for the requests not meeting a predetermined threshold. The transportation matching system can determine a surplus metric for a transportation request based on a response time period and a service time period for the transportation request. Furthermore, the transportation matching system can determine whether the surplus metric meets a predetermined threshold and, in response to the surplus metric not meeting the predetermined threshold, generating a modifier to apply to the transportation request. By generating modifiers for transportation requests with surplus metrics that do not meet a predetermined threshold, the transportation matching system can reduce a cancelation rate of transportation requests by providers, reduce processing loads on the system, and reduce delays in fulfilling transportation requests.

In one or more embodiments, the transportation matching system communicates with transportation provider devices to obtain information about transportation requests fulfilled using the transportation provider devices. Specifically, after a transportation provider fulfills a transportation request, a transportation provider device of the transportation provider can send transportation data about the transportation request to the transportation matching system. The transportation data can include information related to a response time period and a service time period for the transportation request. Accordingly, the transportation data includes information for time required for the transportation provider to travel (e.g., drive) to a pickup location and from the pickup location to a destination location associated with the transportation request. According to one or more embodiments, the transportation matching system uses the transportation data to determine a surplus metric for the transportation request. In particular, the surplus metric is based on the amount of time associated with movement of the transportation provider device during the response time period and the amount of time associated with movement of the transportation provider device during the service time period. More specifically, the transportation matching system determines the surplus metric using a surplus baseline metric in connection with the response time period and the service time period (e.g., in combination with the amounts of time corresponding to movement of the transportation provider device). Furthermore, the transportation matching system also determines the surplus metric based on an expense metric associated with the transportation request.

In one or more embodiments, the transportation matching system uses a surplus metric for a transportation request to determine whether to modify the transportation request. The transportation matching system can determine whether the surplus metric of the transportation request meets a predetermined threshold. For instance, the predetermined threshold can indicate that the surplus metric for the transportation request has a particular value indicating that the transportation matching system should modify the transportation request. To illustrate, the predetermined threshold can indicate whether the surplus metric for the transportation request has a negative value.

Once the transportation matching system has determined that the surplus metric does not meet the predetermined threshold, the transportation matching system can generate a modifier to apply to the transportation request. In particular, the transportation matching system can generate the modifier based on the surplus metric. For example, the transportation matching system can determine a difference between the surplus metric and the predetermined threshold. The transportation matching system can then use the difference to generate a modifier to apply to the transportation request, which can include modifying the surplus metric to meet the predetermined threshold. Alternatively, the transportation matching system can generate the modifier in another way, such as by using a predetermined modifier value, information about the transportation request (e.g., amount of time, geographic location, time of day/week, number of requests).

After generating the modifier, the transportation matching system provides a message to the transportation provider device based on the modifier. In one or more embodiments, the transportation matching system generates a message in response to generating a modifier to apply to a transportation request. The message can include an indication of the modifier for the transportation request. The transportation provider device can display the message within a provider application used to provide transportation services in connection with transportation requests.

As previously mentioned, the transportation matching system described herein provides advantages over conventional transportation matching systems. In particular, the transportation matching system improves the efficiency of a computing system implementing a transportation matching system by dynamically modifying transportation requests based on a plurality of separate time periods associated with each transportation request. The transportation matching system applies modifiers to transportation requests that do not have a threshold surplus metric, which reduces cancelation rates of transportation requests by transportation providers.

As described above, reducing cancelation rates of transportation requests reduces processing loads on the computing system. Specifically, reducing cancelation prevents unnecessary re-matching of previously matched transportation requests. Because transportation matching systems can service many areas by communicating with many transportation provider devices, a high number of cancelations results in a high number of re- processed transportation requests. Reducing the number of cancelations therefore reduces the number of re-processed transportation requests and messages/notifications sent to transportation provider devices.

Turning now to the figures, FIG. 1 illustrates a schematic diagram of an environment 100 for implementing a transportation matching system 102 in accordance with one or more embodiments. This disclosure provides an overview of the transportation matching system 102 with reference to FIG. 1. After providing an overview, the disclosure describes components and processes of the transportation matching system 102 in further detail with reference to subsequent figures.

As shown, FIG. 1 illustrates an example environment 100 for a transportation matching system 102 implemented on one or more server(s) 104. The environment 100 further includes requester client device 106a-106n associated with requesters 108a-108n and provider client devices 110a - 110h associated with transportation providers 112a - 112n. As further shown in FIG. 1, the requester client devices 106a-106n and the provider client devices 110a - 11 On communicate with the transportation matching system 102 and/or each other via a network 114. Furthermore, as illustrated, the requester client devices 106a-106n include requester applications 116a-116n, and the provider client devices l lOa-l lOn include provider applications 118a-l 18n.

As used herein, the term“requester” refers to person (or group of people) who request a ride or other form of transportation from a transportation matching system. A requester may refer to a person who requests a ride or other form of transportation but who is still waiting for pickup. A requester may also refer to a person whom a transportation vehicle has picked up and who is currently riding within the transportation vehicle to a destination (e.g., a destination indicated by a requester). As shown in FIG. 1, each of the requesters 108a-108n are respectively associated with the requester client devices 106a-106n. Accordingly, the terms“requester client device” and“requester device” refer to a computing device associated with a requester and which allows the requester to send a transportation request to the transportation matching system 102. A requester client device can include a mobile device such as a laptop, smartphone, or tablet associated with a requester, though the requester client devices 106a-106n may be any type of computing device, as further explained below with reference to FIG. 5. Each of the requester client devices 106a-106n respectively include requester applications 116a-116n to facilitate a transportation request. As used herein, the term“transportation request” refers to a request by a requester to transport the requester from a first location to a second location. Additionally, a transportation request can include any number of additional locations intermediate the first and second locations. In one or more embodiments, the requester applications 116a-116n include web browsers, applets, or other software applications (e.g., native applications) available to the requester client devices 106a-106n.

As shown in FIG. 1, a requester (e.g., requester 108a) may use a requester application 116a on requester client device 106a to request transportation services, receive a price or a price estimate for the transportation service, and access other transportation-related services. For example, the requester 108a may interact with the requester client device 106a through graphical user interfaces of the requester application 116a to enter a pickup location and a destination for transportation. The transportation matching system 102 can in turn provide, via the network 114, the requester client device 106a with a message including, for example, a price (or price estimate) for the transportation and an estimated time of arrival of a provider (or transportation vehicle) through the requester application 116a. Having received the message from the transportation matching system 102, the requester 108a may then select an option to request transportation services from the transportation matching system 102. In one or more embodiments, the network 114 shown in FIG. 1 may include one or more networks and may use one or more communication platforms or technologies suitable for transmitting data and/or communication signals. In one or more embodiments, the network 114 includes a cellular network. Additionally, or alternatively, the network 114 can include the Internet or World Wide Web. Additionally, or alternatively, the network 114 can include various other types of networks that use various communication technologies and protocols, such as a corporate intranet, a virtual private network (“VPN”), a local area network (“LAN”), a wireless local network (“WLAN”), a wide area network (“WAN”), a metropolitan area network (“MAN”), or a combination of two or more such networks.

After receiving a transportation request from a requester client device, the transportation matching system 102 performs an operation to match the transportation request to a transportation provider. In particular, the transportation matching system 102 can determine a plurality of available transportation providers by communicating with the provider client devices 110a- 110. For example, the transportation matching system 102 communicates with the provider client devices l lOa-l lOn and the requester client devices 106a-106n via the network 120 to determine locations of the provider client devices 110a- l lOn and the requester client devices 114a-114n, respectively. The transportation matching system 102 can then select a provider client device (e.g., based on geographic proximity, requester preferences, transportation type) from the plurality of provider client devices 110a- 110 and send the transportation request to the selected provider client device.

As used herein, the terms“transportation provider” and“provider” refer to a driver, other person, or automated system that operates a transportation vehicle and/or who interacts with a provider client device. For instance, a provider includes a person who drives a transportation vehicle along various routes to pick up and drop off requesters. Alternatively, a provider can include an autonomous transportation vehicle— that is, a self-driving vehicle that includes computer components and accompanying sensors for driving without manual- provider input from a human operator. When a transportation vehicle is an autonomous vehicle, the transportation vehicle may include additional components such as location components, one or more sensors by which the autonomous vehicle navigates, and/or other components necessary to navigate without a human operator (or with minimal interactions by a human operator).

Also as used herein, the terms“provider client device” and“provider device” refer to a computing device associated with a provider and which allows the provider to receive transportation requests from the transportation matching system 102. For example, a provider device may refer to a separate mobile device, such as a laptop, smartphone, or tablet associated with the transportation provider, though the provider client devices 110a- 11 On may be any type of computing device as further explained below with reference to FIG. 5. Additionally, or alternatively, a provider device may be a subcomponent of a vehicle computing system, such as a vehicle computing system for autonomous vehicles. Regardless of its form, the provider client devices 1 lOa-110h may include various sensors, such as a GPS locator, an inertial measurement unit, an accelerometer, a gyroscope, a magnetometer, and/or other sensors that the transportation matching system 102 can access to obtain information (e.g., location information).

As mentioned previously, the provider client devices 110a- 11 On respectively include provider applications 118a-l 18n. In some embodiments, the provider applications 118a-l 18n comprise web browsers, applets, or other software applications (e.g., native applications) available to the provider client devices l lOa-l lOn. Additionally, in some instances, the transportation matching system 102 provides data packets including instructions that, when executed by the provider client devices 110a- 11 On, create or otherwise integrate provider applications 118a-l 18n within an application or webpage. As mentioned, the server(s) 104 can include the transportation matching system 102. In particular, the transportation matching system 102 provides functionality to match transportation requests received from requester client devices to provider computing devices. Additionally, as discussed in more detail below, the transportation matching system 102 analyzes each fulfilled (e.g., completed) transportation request to determine whether to apply a modifier to the transportation request. Indeed, the transportation matching system 102 communicates with each provider client device (e.g., provider client device 110a) to obtain transportation data from a fulfilled transportation request to generate a surplus metric for each transportation request. Furthermore, the transportation matching system 102 can also determine whether each surplus metric meets a predetermined threshold and then generate a modifier to apply to transportation requests with surplus metrics that do not meet the predetermined threshold, as will be explained in more detail below.

As used herein, the term“surplus metric” refers to a value for a transportation request indicating a difference between a payment amount for the transportation request and a payment amount based on a predetermined baseline metric. In particular, a surplus metric represents an amount that a transportation provider makes on the transportation request relative to what the transportation provider might have made if the transportation provider had opted to choose another transportation request. The transportation matching system 102 can generate a surplus metric for a transportation request based on a payment amount of the transportation request, a surplus baseline metric, an amount of time of the transportation request (e.g., for a response time period and a service time period), and an expense metric for the transportation request.

Also as used herein, the term“surplus baseline metric” refers to a predetermined payment amount for a given time period. For instance, a surplus baseline metric can be a predetermined dollar amount per hour (e.g.,“$12 per hour”) and may be based on geometric region, time of day, how busy the transportation matching system 102 is for the geometric region, or other criteria that may affect surplus for transportation requests. The transportation matching system 102 can thus determine different surplus baseline metrics for different locations or times, resulting in different surplus metrics for similar amounts of time/distance of different transportation requests. Furthermore, the term “expense metric” refers to expenses associated with a transportation request. Expenses can include gas and depreciation of assets.

As used herein, the term“response time period” refers to a time associated with responding to a transportation request. In one or more embodiments, a response time period for a transportation request begins when a provider client device accepts a transportation request and ends when the provider client device arrives at a pickup location associated with the transportation request. Accordingly, the response time period can include an amount of time for a provider to respond to a transportation request by driving (or otherwise moving) from a location when the provider accepted the transportation request to a pickup location associated with the transportation request. Also as used herein, the term“pickup location” refers to a location of pickup of a requester of a transportation request. For instance, a pickup location can include a location where a requester enters a vehicle of a transportation provider.

Additionally, as used herein, the term“service time period” refers to a time associated with servicing a transportation request. In one or more embodiments, a service time period for a transportation request begins when a provider client device arrives at a pickup location associated with the transportation request and ends when the provider client device arrives at a destination location associated with the transportation request. The service time period can thus include an amount of time for a provider to drive (or otherwise move) from a pickup location associated with a transportation request to a destination location associated with the transportation request. As used herein, the terms “destination location” and “dropoff location” refer to a location for completing a transportation request. For example, a destination location can include a location where a requester exits a vehicle of a transportation provider.

Furthermore, as used herein, the term“modifier” refers to a numerical value applied to a transportation request based on a surplus metric of the transportation request. In particular, a modifier can include a payment amount that the transportation matching system 102 provides to a transportation provider after determining that a surplus metric of the transportation request does not meet a predetermined threshold. As used herein, the term “predetermined threshold” refers to a value for determining whether to modify a transportation request. For instance, a predetermined threshold can include a value that the transportation matching system 102 sets to determine whether to supplement a payment amount to a provider for a transportation request. For instance, the predetermined threshold can allow the transportation matching system 102 to determine whether a surplus metric is negative, positive, or zero.

To illustrate, the provider client device 110a can provide transportation data for a transportation request involving the requester 108a. When the provider client device 110a indicates to the transportation matching system 102 that the transportation request is fulfilled (e.g., by sending a message to the transportation matching system 102), the transportation matching system 102 can determine whether to apply a modifier to the transportation request. Specifically, the transportation matching system 102 can determine a surplus metric for the transportation request based on a response time period and a service time period associated with the transportation request. The transportation matching system 102 can determine whether the surplus metric meets a predetermined threshold (e.g., determine whether the surplus metric is negative or positive) and generate a modifier if the surplus metric does not meet the predetermined threshold. The transportation matching system 102 then generates and sends a message indicating the modifier to the provider client device 110a.

As described briefly above, the transportation matching system 102 uses information about fulfilled transportation requests to determine whether to apply a modifier to each transportation request. FIGS. 2A-2C illustrate embodiments of a plurality of transportation requests with different response time periods and service time periods. In particular, the plurality of transportation requests represents different requests that the transportation matching system 102 may provide to a provider device. Accordingly, FIG. 2 A illustrates a first transportation request for a first requester, and FIG. 2B illustrates a second transportation request for a second requester. FIG. 2C illustrates a comparison of movement/transport time associated with the first transportation request and the second transportation request.

As mentioned, FIG. 2A illustrates an embodiment of a first transportation request. Specifically, the transportation matching system 102 receives a request from a first requester (e.g., from a first requester device associated with the first requester) to transport the second requester from a first pickup location 200a of the first requester to a first dropoff location 202a. When the transportation matching system 102 sends the first transportation request to the provider device, the provider can accept the first transportation request. The transportation provider performs the transportation request by driving from a current location 204 of the provider device to the first pickup location 200a and transporting the first requester from the first pickup location 200a to the first dropoff location 202a.

In one or more embodiments, a transportation request involves a plurality of stages. In particular, each transportation request includes a response time period and a service time period. As previously described, the response time period for a transportation request includes an amount of time from acceptance of a transportation request until the transportation provider arrives at a pickup location. Accordingly, in the embodiment of FIG. 2A, the response time period 206a for the first transportation request includes an amount of time for the transportation provider to move from the current location 204 to the first pickup location 200a. Additionally, the service time period 208b for the first transportation request includes an amount of time for the transportation provider to move from the first pickup location 200a to the first dropoff location 202a. As shown in FIG. 2A, and as described in more detail below with respect to FIG. 2C, the response time period is sometimes referred to as“P2,” and the service time period is sometimes referred to as“P3”

The response time period and the service time period depending on the current location of the transportation provider, the location of the requester, and the destination location of the requester. Additionally, the response time period and the service time period can further depend on other criteria such as, but not limited to, time of day, traffic, navigation route, or number of stops (e.g., for transportation requests including more than one stop). As described in more detail below with respect to FIGS. 2B-2C, transportation requests that have similar distances can have different response time periods and service time periods.

For example, FIG. 2B illustrates an embodiment of a second transportation request involving a second requester. Additionally, FIG. 2B illustrates that the current location of the provider device at the time of accepting the second transportation request is the same as the current location 204 of the provider device in FIG. 2A. The transportation matching system 102 receives a request from the second requester (e.g., from a second requester device associated with the second requester) to transport the second requester from a second pickup location 200b to a second dropoff location 202b. As shown, the second pickup location 200b and the second dropoff location 202b of the second transportation request are different than the first pickup location 200a and the first dropoff location 202a of the first transportation request, respectively. Accordingly, the response time period 206b and the service time period 208b for the second transportation request are different than the response time period 206a and the service time period 208a for the first transportation request.

FIG. 2C illustrates a comparison between stages of two different completed transportation requests with equal total times. Specifically, the transportation matching system 102 can determine that a first completed request 210 includes a response time period 212a and a service time period 214a based on a starting location, pickup location, and dropoff location corresponding to the first completed request. The transportation matching system 102 can determine that a second completed request 216 includes a response time period 212b and a service time period 214b based on a starting location, pickup location, and dropoff location corresponding to the second completed request. As previously mentioned, a response time period is also referred to as“P2,” and a service time period is also referred to as“P3” “PI” indicates a waiting period for a transportation provider (e.g., the transportation provider is not currently fulfilling a transaction request and/or has not yet accepted the transaction request).

As shown, the response time period 212a of the first completed request 210 is longer than the response time period 212b of the second completed request 216. In particular, longer response time periods may be due to a longer distance to travel from a starting location (e.g., location of acceptance of the request) to a pickup location for the first completed request 210 than for the second completed request 216. A longer response time period may also be due to traffic conditions or other delays that cause the transportation provider to respond more slowly for the first completed request 210.

Additionally, the service time period 214a of the first completed request 210 is shorter than the service time period 214b of the second completed request 216. Specifically, a longer service time period may be due to a longer distance to travel from a pickup location of the corresponding request to a dropoff location for the first completed request 210 than for the second completed request 216. Furthermore, as with response time periods, a service time period may be longer for a given request based on traffic conditions or other delays.

Conventionally, transportation providers may sometimes be inclined to cancel a transportation request based on an estimated response time period relative to an estimated service time period. For a given transportation request, if the distance between the current location of the provider device and the pickup location is greater than the distance between the pickup location and the dropoff location, a transportation provider may decide to cancel the transportation request. In particular, transportation providers typically only receive payment from requesters for the service time period (i.e., while the requesters are passengers or otherwise being transported). Thus, traveling a greater distance to reach the requester than to transport the requester from the pickup location to the dropoff location can result in a transportation provider not wanting to take a transportation request because the transportation provider may miss other, more profitable requests.

Accordingly, the transportation matching system 102 improves upon conventional transportation matching systems by using a surplus metric to determine whether to apply a modifier to a transportation request. Ad mentioned, modifying transportation requests based on surplus metrics can result in lower cancelations, and therefore, reduce processing load on the transportation matching system 102. Specifically, transportation providers are more likely to keep transportation requests that would otherwise be inefficient if they know that they will be compensated fairly for the transportation requests. Accordingly, in one or more embodiments, the transportation matching system 102 modifies a transportation request by generating a payment amount to send to the transportation provider in response to determining that a surplus metric for the transportation request does not meet a predetermined threshold. In one or more embodiments, the transportation matching system 102 determines a surplus metric for a transportation request by first identifying a payment amount from a requester to a transportation provider. For instance, when a transportation provider fulfills a transportation request, the transportation matching system 102 can determine the payment amount based on the service time period. The transportation matching system 102 can determine the payment amount based on an established payment system that sets the payment amount in accordance with a time and/or distance associated with every transportation request. Accordingly, the transportation matching system 102 can determine the payment amount based on transportation provided to the transportation matching system 102 from the provider device during the transportation request. Alternatively, the provider device can provide the payment amount to the transportation matching system 102 after the requester finalizes a payment transaction with the transportation provider.

Furthermore, the transportation matching system 102 can also identify a surplus baseline metric for determining the surplus metric. In one or more embodiments, the surplus baseline metric is a dollar-per-hour value that the transportation matching system 102 determines according to the geographic region (e.g., city, state) of the transportation request. For instance, the transportation matching system 102 can determine a surplus baseline metric for a given state or city based on cost of living, cost of transportation services, gas prices, or other metrics determined in real time or based on historical data for the stage or city. To illustrate, the surplus baseline metric for a given region can be $12 per hour, $14 per hour, or other dollar-per-hour value. Additionally, the surplus baseline metric may also be based on additional factors such as the season such that the surplus baseline metric may be different for different times of month/year.

The transportation matching system 102 can also identify an expense metric associated with each transportation request for determining the surplus metric. In one or more embodiments, the transportation matching system 102 determines an expense metric according to a standard expense rate based on the distance traveled during the transportation request. Expenses can include gas, depreciation of assets (e.g., wear and tear on a transportation vehicle), or other expenses typically incurred to fulfill transportation requests (e.g., based on historical data). For instance, the transportation matching system 102 can determine that the expense metric is equal to 25 cents per mile for the transportation request to account for gas and vehicle depreciation.

When the transportation matching system 102 has identified the payment amount, the surplus baseline metric, and the expense metric for the transportation request, the transportation matching system 102 can determine (e.g., generate) the surplus metric for the transportation request. In one or more embodiments, the transportation matching system 102 determines the surplus metric as:

where S is the surplus metric, P is the payment amount for the transportation request, S _B is the surplus baseline metric, RT is the request time in terms of hours (or other time period corresponding to the surplus baseline metric), E is an expense metric, and RD is the request distance traveled. In particular, RT and RD correspond to the total time and distance corresponding to the transportation request, respectively, including the time and distance for the response time period and the service time period.

To illustrate, for the first completed request 210 of FIG. 2C, the transportation matching system 102 can determine that the transportation provider traveled five miles during the response time period 212a and two miles during the service time period 214a for a total of seven miles. Additionally, the transportation matching system 102 can determine that the transportation provider traveled for fifteen minutes during the response time period 212a and ten minutes during the service time period 214a for a total of twenty-five minutes. If the payment amount for the request is $10, the surplus baseline metric is $12 per hour, and the expense metric is 25 cents per mile, the surplus metric for the first completed request 210 is

5— ^12 * ^ + 0.25 * 7^ =— 1.75, or -$1.75. This can represent a surplus that the transportation provider achieved for the transportation request.

Service time periods that are longer than the response time periods can result in positive surplus and are therefore more conventionally more desirable to transportation providers. For instance, the second completed request 216 includes a much shorter response time period 212b than service time period 214b, even if the total distance and/or time is approximately equal. To illustrate, assume that the total time for the request is twenty-five minutes and seven miles, with a response time period 212b including six minutes and 1.3 miles and a service time period 214b including nineteen minutes and 6.7 miles. Furthermore, if the payment amount is $19 with the same surplus baseline metric and expense metric as the first completed request 210, the surplus metric for the second completed request 210 is 19— 0.25 * 7) = 12.25, or $12.25.

As shown, the surplus metric for the first completed request 210 is negative due to the long response time period 212a and the short service time period 214a, relative to each other. Conversely, the surplus metric for the second completed request 216 is positive due to the significantly shorter response time period 212b relative to the service time period 214b. Because of the large potential disparity between separate transportation requests that have similar times and distances traveled, the transportation matching system 102 can use the surplus metric for each transportation request to determine whether to modify the transportation requests to reduce the number of cancelations received from transportation providers.

In one or more embodiments, the transportation matching system 102 generates a modifier for a transportation request in response to determining that the surplus metric for the transportation request does not meet a predetermined threshold. Specifically, the predetermined threshold can include a value that allows the transportation matching system 102 to change the likelihood of cancelation of similar, future transportation requests. To illustrate, the transportation matching system 102 can set the predetermined threshold to allow the transportation matching system 102 to determine whether to generate a modifier based on the surplus metric being negative, positive, or zero. According to such an embodiment, the transportation matching system 102 can set the predetermined threshold to zero such that the transportation matching system 102 generates a modifier only if the surplus metric is negative. Alternatively, the transportation matching system 102 can set the predetermined threshold to another value to generate the modifier to modify some requests with negative surplus metrics, but not others (e.g., by setting the predetermined threshold to - 1) or even some requests with positive surplus metrics (e.g., by setting the predetermined threshold to 1).

In additional embodiments, the transportation matching system 102 sets the predetermined threshold to achieve a specific average value-per-time-unit for a plurality of transportation providers. For instance, the transportation matching system 102 can analyze the historical transportation request data to determine how much transportation providers are receiving per hour, on average. The transportation matching system 102 can then set the predetermined threshold to achieve a specific target amount per hour averaged across the plurality of providers (e.g., to achieve a mean or median amount per hour). The transportation matching system 102 can also regularly adjust/update the predetermined threshold based on seasonal changes, trends, or other influencing factors.

In response to a surplus baseline for a transportation request not meeting the predetermined threshold, the transportation matching system 102 generates a modifier for the transportation request. In one or more embodiments, the transportation matching system 102 generates the modifier based on a difference between the surplus metric and the predetermined threshold. For instance, the transportation matching system 102 can generate a modifier that equals the difference between the surplus metric and the predetermined threshold. To illustrate, if a surplus metric for a predetermined threshold is negative, the resulting modifier can essentially set the surplus metric for the transportation request to be zero. Thus, if the surplus metric is -1.75, the resulting modifier can be 1.75.

While the embodiments above include specific values for variables when determining the surplus metric, the transportation matching system 102 can utilize other values, depending on the implementation. The specific values used above are for illustration purposes only. Accordingly, the surplus baseline metric, payment amounts, and expense metrics can all be different than those shown above. More specifically, as previously mentioned, the specific values may depend on the geographic region, historical price data, historical cost data, number of requesters, region density, number of available providers, or any other factors that may affect revenues and costs associated with providing transportation services.

In one or more additional embodiments, the transportation matching system 102 uses additional information about the transportation request or other transportation requests in the region to generate the modifier. For example, the transportation matching system 102 can utilize information about whether other transportation requests are available in the area to generate the modifier. Specifically, if the region has a high volume of other transportation requests during, or near, the time of the transportation request, the transportation matching system 102 can generate a higher modifier. Similarly, if the region has a low volume of other transportation requests during, or near, the time of the transportation request, the transportation matching system 102 can generate a lower modifier.

In addition to using information about other available transportation requests, the transportation matching system 102 can use information about the destination in determining the modifier. In particular, if the transportation request results in the transportation provider being in a location with different cost/price dynamics than the origin location or the request load in the destination location, the transportation matching system 102 can generate a modifier to account for that change. To illustrate, if a transportation provider accepts a request with a low surplus metric, but which takes the provider to an area with a high percentage of requests with high surplus metrics (e.g., high earning potential for the provider), the transportation matching system 102 may generate a low-value modifier, or no modifier at all. In contrast, if the transportation provider accepts a request that takes the provider to an area with low earning potential for the provider, the transportation matching system 102 may generate a modifier with a high value to offset future requests.

Additionally, in one or more embodiments, the transportation matching system 102 generates modifiers to apply to transportation requests for a specific set of transportation providers. The transportation matching system 102 can use targeting to determine a subset of transportation providers that are allowed to receive modifiers for their transportation requests. For example, the transportation matching system 102 can generate modifiers for transportation requests with transportation providers who have a specific type of relationship with the transportation matching system 102, providers who have completed at least a specific number of requests, providers who have subscribed to a particular service, providers within a specific region or regions, randomly selected providers, or other criteria for selecting the targeted providers.

The transportation matching system 102 can further generate modifiers based on historical data associated with previously generated modifiers. Specifically, the transportation matching system 102 can analyze transportation requests with a transportation provider that occurred after applying a modifier to a transportation request with the transportation provider. For instance, the transportation matching system 102 can determine whether the transportation provider was more or less likely to accept and fulfill transportation requests with surplus metrics that do not meet the predetermined threshold after applying a modifier to a previous transportation request. The transportation matching system 102 can accordingly adjust future modifiers based on the request history associated with the transportation provider to increase the likelihood of the transportation provider accepting requests with low (e.g., negative) surplus metrics.

In addition to determining modifiers for applying to transportation requests based on historical request data, the transportation matching system 102 can also adjust other transportation prices or metrics based on modifier data. If the transportation matching system 102 determines that the system 102 is applying a high percentage of modifiers to requests, the transportation matching system 102 can adjust the prices for requests (i.e., by increasing payment amounts from requesters for each request). Increasing payment amounts can thus result in fewer requests with surplus metrics that do not meet the predetermined threshold. This can also reduce the loads on the system by reducing the number of modifiers that the system 102 generates to apply to requests. Similarly, the transportation matching system 102 can modify the surplus baseline or expense metric based on historical modifier data and/or other historical request data.

In one or more embodiments, after generating a modifier to apply to a transportation request, the transportation matching system 102 generates a message to send to the provider device indicating the modifier. In particular, the transportation matching system 102 can generate a message that indicates to the transportation provider that the transportation provider has received an additional payment amount for the transportation request. Specifically, the modifier can include a payment amount in addition to what the requester paid to the transportation provider for the transportation request. FIGS. 3A-3C illustrate embodiments of a graphical user interface allowing a transportation provider to fulfill a transportation request. For example, FIG. 3A illustrates a provider device 300 including a graphical user interface in a provider application 302 for receiving and accepting transportation requests. FIG. 3B illustrates the provider device 300 including a graphical user interface in the provider application 302 for viewing a transportation request after accepting the transportation request. FIG. 3C illustrates the provider device 300 including a graphical user interface in the provider application 302 for viewing a message indicating a modifier applied to a transportation request.

In one or more embodiments, as illustrated in FIG. 3A, the provider device 300 receives a transportation request from the transportation matching system 102 within the provider application 302. For instance, after a requester device has submitted a transportation request, the provider device 300 can receive the transportation request from the transportation matching system 102 and display an indication of the transportation request as a message or notification. To illustrate, the provider application 302 includes an update overlay 304 (e.g., on top of a navigation map) with a message indicating that at least one scheduled pickup is available for the transportation provider to claim. Additionally, the message can include a distance (or approximate distance) of the available transportation request from the current location of the provider device 300. Alternatively, the provider application 302 can display available pickups in a list of pickups or another interface within the provider application 302.

Furthermore, as shown, transportation matching system 102 can also provide, to the provider device 300, an indication that the transportation matching system 102 may modify the transportation request. Specifically, the transportation matching system 102 can indicate that fulfilling the transportation request will cause the transportation matching system 102 to provide a supplemental payment amount to the transportation provider if a surplus metric of the request does not meet a threshold. The transportation matching system 102 may provide such an indication, for instance, by indicating that the request“comes with a guarantee.” This allows the transportation matching system 102 to provide the indication without providing certain details to the transportation provider (e.g., without guaranteeing a specific payment amount) in case the request includes a surplus metric that meets the predetermined threshold. Alternatively, the transportation matching system 102 may provide an icon displayed within the provider application 302 indicating the likelihood of a modifier.

In one or more additional embodiments, the transportation matching system 102 generates an estimated surplus metric for each transportation request (e.g., before providing the transportation request to the provider device 300). Specifically, the transportation matching system 102 can generate an estimated response time period and an estimated service time period for the transportation request before providing the transportation request to the provider device 300. The transportation matching system 102 can use information about the current location of the provider device 300, pickup location, dropoff location, and/or traffic information to generate the estimated time periods. If the estimated surplus metric does not meet the predetermined threshold, the transportation matching system 102 provides the indication of the likelihood of a modifier to the provider device 300. Otherwise, the transportation matching system 102 does not provide the indication of the likelihood of a modifier to the provider device 300.

In one or more embodiments, rather than determining an estimated surplus metric, the transportation matching system 102 compares a distance associated with the response time period to a threshold. For instance, the transportation matching system 102 can determine, based on historical request data, that transportation providers are more likely (e.g., a given percentage of providers) to cancel transportation requests if the response time period is greater than a specific distance. Thus, the transportation matching system 102 can set the threshold at the identified distance and then compare the response time period distances for new requests to the threshold distance. The transportation matching system 102 can then provide the message indicating a likelihood of a modifier for requests having response time period distances that meet or exceed the threshold distance.

In one or more embodiments, the transportation matching system 102 does not provide any indication of a likelihood of a modifier in connection with the transportation request to the provider device 300. Instead, the transportation matching system 102 may provide only an indication of the modifier after the transportation request is fulfilled and the transportation matching system 102 has determined that the surplus metric does not meet the predetermined threshold, as described in more detail below with respect to FIG. 3C. Alternatively, the transportation matching system 102 may provide an indication of the likelihood of a modifier to a subset of providers (e.g., to some providers, but not to other providers) based on established relationships with the providers or other characteristics of the providers.

The transportation provider can accept a transportation request after receiving the transportation request. In particular, as illustrated in FIG. 3 A, the provider application 302 can include an option 306 to accept the transportation request with the message indicating the transportation request. For example, the transportation provider can select the option 306 to accept the transportation request by interacting with the option 306 via touch input. The transportation provider may accept transportation requests using any acceptable input for the provider application 302, including voice input or input via another input device (e.g., wireless controls or vehicle dashboard controls). In one or more alternative embodiments, the transportation matching system 102 provides a transportation request to a provider device, and the provider device automatically accepts the transportation request if the provider device is set to available. FIG. 3B illustrates the provider device 300 including the provider application 302 after the transportation provider has accepted the transportation request. As shown, after acceptance of the transportation request, the transportation matching system 102 provides details of the transportation request to the provider device 300. For instance, the transportation matching system 102 can provide a route 308 of the transportation request to the provider device 300, including a pickup location and a dropoff location. The provider application 302 can display the route 308 of the transportation request on a map interface. The details provided to the provider device 300 can also include information about the pickup location and dropoff location such as an address or general location of the pickup/dropoff locations within a route information overlay 310, for example.

In one or more embodiments, the transportation matching system 102 only provides partial details of the transportation request to the provider device 300. Specifically, the transportation matching system 102 may provide details about the pickup location when the provider device 300 indicates acceptance of the transportation request to the transportation matching system 102. The transportation matching system 102 can then provide details about the dropoff location when the transportation provider arrives at the pickup location. This may allow the transportation matching system 102 to maintain privacy of requesters until the transportation providers are ready to pick up the requester.

After the transportation provider has fulfilled the transportation request, the provider device 300 can send an indication of the completed request to the transportation matching system 102. For instance, the provider device 300 can continuously, or intermittently, provide the location of the provider device 300 to the transportation matching system 102 using GPS, wireless, or other location identification method. As illustrated in FIG. 3C, the transportation matching system 102 can identify the that the current location of the provider device 300 is at the dropoff location, indicated by a location marker 312 within the map interface of the provider application 302.

In one or more embodiments, when the provider device 300 arrives at the dropoff location and the requester provides payment for the request, the transportation matching system 102 begins determining the surplus metric for the transportation request. Specifically, the transportation matching system 102 uses a payment amount for the transportation request, a surplus metric, an expense metric, and transportation data (including data associated with the response time period and service time period) for the transportation request. The transportation matching system 102 then determines the surplus metric and compares the surplus metric to the predetermined threshold.

In response to determining that the surplus metric does not meet the predetermined threshold, the transportation matching system 102 generates a modifier to apply to the transportation request. As illustrated, the transportation matching system 102 determines that the transportation request of FIGS. 3A-3C has a surplus metric that does not meet the predetermined threshold. Accordingly, the transportation matching system 102 sends a message indicating the modifier to the provider device 300. The provider device 300 can then display the modifier within the provider application 302 as a popup message 314. Alternatively, the provider device 300 can present the message indicating the modifier in a notification area of the provider application 302, a notification tray of the operating system, or in any other manner suitable for the provider device 300.

Turning now to FIG. 4, this figure shows a flowchart of a series of acts 400 of modifying transaction requests based on surplus metrics. While FIG. 4 illustrates acts according to one embodiment, alternative embodiments may omit, add to, reorder, and/or modify any of the acts shown in FIG. 4. The acts of FIG. 4 can be performed as part of a method. Alternatively, a non-transitory computer readable storage medium can comprise instructions that, when executed by one or more processors, cause a computing device to perform the acts depicted in FIG. 4. In still further embodiments, a system can perform the acts of FIG. 4.

As shown, the series of acts 400 includes an act 402 of determining a response time period. For example, act 402 involves determining, by a transportation matching system comprising one or more servers, a response time period for a transportation request received from a requester device, the response time period comprising an amount of time associated with movement of a transportation provider device to a pickup location associated with the response time period and the service time period of the transportation request.

The series of acts 400 also includes an act 404 of determining a service time period. For example, act 404 involves determining, by the transportation matching system, a service time period for the transportation request comprising an amount of time associated with movement of the transportation provider device from the pickup location to a destination location associated with the response time period and the service time period of the transportation request.

The series of acts 400 further includes an act 406 of determining a surplus metric. For example, act 406 involves determining, by the transportation matching system, a surplus metric for the transportation request based on the response time period and the service time period. Act 406 can involve utilizing a surplus baseline metric in connection with the response time period and the service time period to determine the surplus metric. Act 406 can also involve determining an expense metric for the transportation request based on the movement of the transportation provider device in connection with the transportation request.

Additionally, the series of acts 400 includes an act 408 of generating a modifier. For example, act 408 involves generating, in response to determining that the surplus metric fails to meet a predetermined threshold, a modifier to apply to the transportation request based on the surplus metric. Act 408 can involve determining a difference between the surplus metric and the predetermined threshold, and generating the modifier based on the difference between the surplus metric and the predetermined threshold.

Additionally, act 408 can involve determining a density of a region in which the destination location is located and a volume of transportation requests in the region. Act 408 can then involve generating the modifier based on the density of the region and the volume of transportation requests. Act 408 can further involve determining a historical volume of transportation requests in the region for generating the modifier.

The series of acts 400 also includes an act 410 of providing a message based on the modifier. For example, act 410 involves providing, for display by the transportation provider device, a message based on the modifier to apply to the transportation request. Act 410 can involve providing the message to the transportation provider device after receiving an indication that a payment transaction from the requester device is completed. Act 410 can also involve utilizing location information from the transportation provider device to determine that the transportation provider device has arrived at the destination location prior to providing the message to the transportation provider device.

The series of acts 400 can also include determining, in connection with providing the transportation request to the transportation provider device and based on the response time period, that a distance associated with the response time period exceeds a predetermined distance threshold. The series of acts 400 can further include providing, to the transportation provider device in response to the distance meeting the predetermined distance threshold, an initial message with the transportation request indicating that the transportation request will be modified if the surplus metric fails to meet the predetermined threshold. For example, the initial message with the transportation request indicating that the transportation request will be modified if the surplus metric fails to meet the predetermined threshold can include an icon within a provider application.

Alternatively, the series of acts 400 can include generating, in connection with providing the transportation request to the transportation provider device, an estimated surplus metric for the transportation request. For example, the series of acts 400 can include generating an estimated response time period based on a distance between a current location of the transportation provider device and the pickup location. The series of acts 400 can also include generating an estimated service time period based on a distance between the pickup location and the destination location. In addition, the series of acts 400 can include providing, to the transportation provider device in response to the estimated surplus metric not meeting the predetermined threshold, an initial message with the transportation request indicating that the transportation request will be modified if the surplus metric fails to meet the predetermined threshold.

Embodiments of the present disclosure may comprise or utilize a special purpose or general-purpose computer including computer hardware, such as, for example, one or more processors and system memory, as discussed in greater detail below. Embodiments within the scope of the present disclosure also include physical and other computer-readable media for carrying or storing computer-executable instructions and/or data structures. In particular, one or more of the processes described herein may be implemented at least in part as instructions embodied in a non-transitory computer-readable medium and executable by one or more computing devices (e.g., any of the media content access devices described herein). In general, a processor (e.g., a microprocessor) receives instructions, from a non- transitory computer-readable medium, (e.g., a memory, etc.), and executes those instructions, thereby performing one or more processes, including one or more of the processes described herein. Computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer system, including by one or more servers. Computer-readable media that store computer-executable instructions are non-transitory computer-readable storage media (devices). Computer-readable media that carry computer- executable instructions are transmission media. Thus, by way of example, and not limitation, embodiments of the disclosure can comprise at least two distinctly different kinds of computer-readable media: non-transitory computer-readable storage media (devices) and transmission media.

Non-transitory computer-readable storage media (devices) includes RAM, ROM, EEPROM, CD-ROM, solid state drives (“SSDs”) (e.g., based on RAM), Flash memory, phase-change memory (“PCM”), other types of memory, other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.

Further, upon reaching various computer system components, program code means in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to non-transitory computer-readable storage media (devices) (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a“NIC”), and then eventually transferred to computer system RAM and/or to less volatile computer storage media (devices) at a computer system. Thus, it should be understood that non-transitory computer-readable storage media (devices) can be included in computer system components that also (or even primarily) utilize transmission media.

Computer-executable instructions comprise, for example, instructions and data which, when executed at a processor, cause a general-purpose computer, special purpose computer, or special purpose processing device to perform a certain function or group of functions. In some embodiments, computer-executable instructions are executed on a general-purpose computer to turn the general-purpose computer into a special purpose computer implementing elements of the disclosure. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code. Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above. Rather, the described features and acts are disclosed as example forms of implementing the claims.

Those skilled in the art will appreciate that the disclosure may be practiced in network computing environments with many types of computer system configurations, including, virtual reality devices, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, pagers, routers, switches, and the like. The disclosure may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. In a distributed system environment, program modules may be located in both local and remote memory storage devices.

Embodiments of the present disclosure can also be implemented in cloud computing environments. In this description,“cloud computing” is defined as a model for enabling on- demand network access to a shared pool of configurable computing resources. For example, cloud computing can be employed in the marketplace to offer ubiquitous and convenient on- demand access to the shared pool of configurable computing resources. The shared pool of configurable computing resources can be rapidly provisioned via virtualization and released with low management effort or service provider interaction, and then scaled accordingly.

A cloud-computing model can be composed of various characteristics such as, for example, on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service, and so forth. A cloud-computing model can also expose various service models, such as, for example, Software as a Service (“SaaS”), Platform as a Service (“PaaS”), and Infrastructure as a Service (“IaaS”). A cloud-computing model can also be deployed using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, and so forth. In this description and in the claims, a“cloud-computing environment” is an environment in which cloud computing is employed.

FIG. 5 illustrates, in block diagram form, an exemplary computing device 500 that may be configured to perform one or more of the processes described above. One will appreciate that the transportation matching system 102 can comprise implementations of the computing device 500, including, but not limited to, the server(s) 104, the provider client devices l lOa-l lOn, and the requester client devices 106a-106n. As shown by FIG. 5, the computing device can comprise a processor 502, memory 504, a storage device 506, an I/O interface 508, and a communication interface 510. In certain embodiments, the computing device 500 can include fewer or more components than those shown in FIG. 5. Components of computing device 500 shown in FIG. 5 will now be described in additional detail.

In particular embodiments, processor(s) 502 includes hardware for executing instructions, such as those making up a computer program. As an example, and not by way of limitation, to execute instructions, processor(s) 502 may retrieve (or fetch) the instructions from an internal register, an internal cache, memory 504, or a storage device 506 and decode and execute them. The computing device 500 includes memory 504, which is coupled to the processor(s) 502. The memory 504 may be used for storing data, metadata, and programs for execution by the processor(s). The memory 504 may include one or more of volatile and non-volatile memories, such as Random Access Memory (“RAM”), Read Only Memory (“ROM”), a solid-state disk (“SSD”), Flash, Phase Change Memory (“PCM”), or other types of data storage. The memory 504 may be internal or distributed memory.

The computing device 500 includes a storage device 506 includes storage for storing data or instructions. As an example, and not by way of limitation, storage device 506 can comprise a non-transitory storage medium described above. The storage device 506 may include a hard disk drive (“HDD”), flash memory, a Universal Serial Bus (“USB”) drive or a combination of these or other storage devices.

The computing device 500 also includes one or more input or output (“I/O”) interface 508, which are provided to allow a user (e.g., requester or provider) to provide input to (such as user strokes), receive output from, and otherwise transfer data to and from the computing device 500. These I/O interface 508 may include a mouse, keypad or a keyboard, a touch screen, camera, optical scanner, network interface, modem, other known I/O devices or a combination of such I/O interface 508. The touch screen may be activated with a stylus or a finger.

The I/O interface 508 may include one or more devices for presenting output to a user, including, but not limited to, a graphics engine, a display (e.g., a display screen), one or more output providers (e.g., display providers), one or more audio speakers, and one or more audio providers. In certain embodiments, interface 508 is configured to provide graphical data to a display for presentation to a user. The graphical data may be representative of one or more graphical user interfaces and/or any other graphical content as may serve a particular implementation. The computing device 500 can further include a communication interface 510. The communication interface 510 can include hardware, software, or both. The communication interface 510 can provide one or more interfaces for communication (such as, for example, packet-based communication) between the computing device and one or more other computing devices 500 or one or more networks. As an example, and not by way of limitation, communication interface 510 may include a network interface controller (“NIC”) or network adapter for communicating with an Ethernet or other wire-based network or a wireless NIC (“WNIC”) or wireless adapter for communicating with a wireless network, such as a WI-FI. The computing device 500 can further include a bus 512. The bus 512 can comprise hardware, software, or both that couples components of computing device 500 to each other.

FIG. 6 illustrates an example network environment 600 of a transportation matching system 602. The network environment 600 includes a client device 606, a transportation matching system 602, and a vehicle subsystem 608 connected to each other by a network 604. Although FIG. 6 illustrates a particular arrangement of the client device 606, transportation matching system 602, vehicle subsystem 608, and network 604, this disclosure contemplates any suitable arrangement of client device 606, transportation matching system 602, vehicle subsystem 608, and network 604. As an example, and not by way of limitation, two or more of client device 606, transportation matching system 602, and vehicle subsystem 608 communicate directly, bypassing network 604. As another example, two or more of client device 606, transportation matching system 602, and vehicle subsystem 608 may be physically or logically co-located with each other in whole or in part. Moreover, although FIG. 6 illustrates a particular number of client devices 606, transportation matching systems 602, vehicle subsystems 608, and networks 604, this disclosure contemplates any suitable number of client devices 606, transportation matching systems 602, vehicle subsystems 608, and networks 604. As an example, and not by way of limitation, network environment 600 may include multiple client device 606, transportation matching systems 602, vehicle subsystems 608, and networks 604.

This disclosure contemplates any suitable network 604. As an example, and not by way of limitation, one or more portions of network 604 may include an ad hoc network, an intranet, an extranet, a virtual private network (“VPN”), a local area network (“LAN”), a wireless LAN (“WLAN”), a wide area network (“WAN”), a wireless WAN (“WWAN”), a metropolitan area network (“MAN”), a portion of the Internet, a portion of the Public Switched Telephone Network (“PSTN”), a cellular telephone network, or a combination of two or more of these. Network 604 may include one or more networks 604.

Links may connect client device 606, transportation matching system 602, and vehicle subsystem 608 to network 604 or to each other. This disclosure contemplates any suitable links. In particular embodiments, one or more links include one or more wireline (such as for example Digital Subscriber Line (“DSL”) or Data Over Cable Service Interface Specification (“DOCSIS”), wireless (such as for example Wi-Fi or Worldwide Interoperability for Microwave Access (“WiMAX”), or optical (such as for example Synchronous Optical Network (“SONET”) or Synchronous Digital Hierarchy (“SDH”) links. In particular embodiments, one or more links each include an ad hoc network, an intranet, an extranet, a VPN, a LAN, a WLAN, a WAN, a WWAN, a MAN, a portion of the Internet, a portion of the PSTN, a cellular technology-based network, a satellite communications technology -based network, another link, or a combination of two or more such links. Links need not necessarily be the same throughout network environment 600. One or more first links may differ in one or more respects from one or more second links.

In particular embodiments, client device 606 may be an electronic device including hardware, software, or embedded logic components or a combination of two or more such components and capable of carrying out the appropriate functionalities implemented or supported by client device 606. As an example, and not by way of limitation, a client device 606 may include any of the computing devices discussed above in relation to FIG. 5. A client device 606 may enable a network user at client device 606 to access network 604. A client device 606 may enable its user to communicate with other users at other client devices 606.

In particular embodiments, client device 606 may include a requester application or a web browser, such as MICROSOFT INTERNET EXPLORER, GOOGLE CHROME or MOZILLA FIREFOX, and may have one or more add-ons, plug-ins, or other extensions, such as TOOLBAR or YAHOO TOOLBAR. A user at client device 606 may enter a Uniform Resource Locator (“URL”) or other address directing the web browser to a particular server (such as server), and the web browser may generate a Hyper Text Transfer Protocol (“HTTP”) request and communicate the HTTP request to server. The server may accept the HTTP request and communicate to client device 606 one or more Hyper Text Markup Language (“HTML”) files responsive to the HTTP request. Client device 606 may render a webpage based on the HTML files from the server for presentation to the user. This disclosure contemplates any suitable webpage files. As an example, and not by way of limitation, webpages may render from HTML files, Extensible Hyper Text Markup Language (“XHTML”) files, or Extensible Markup Language (“XML”) files, according to particular needs. Such pages may also execute scripts such as, for example and without limitation, those written in JAVASCRIPT, JAVA, MICROSOFT SILVERLIGHT, combinations of markup language and scripts such as AJAX (Asynchronous JAVASCRIPT and XML), and the like. Herein, reference to a webpage encompasses one or more corresponding webpage files (which a browser may use to render the webpage) and vice versa, where appropriate.

In particular embodiments, transportation matching system 602 may be a network- addressable computing system that can host a transportation matching network. Transportation matching system 602 may generate, store, receive, and send data, such as, for example, user-profile data, concept-profile data, text data, transportation request data, GPS location data, provider data, requester data, vehicle data, or other suitable data related to the transportation matching network. This may include authenticating the identity of providers and/or vehicles who are authorized to provide transportation services through the transportation matching system 602. In addition, the transportation matching system may manage identities of service requesters such as users/requesters. In particular, the transportation matching system 602 may maintain requester data such as driving/riding histories, personal data, or other user data in addition to navigation and/or traffic management services or other location services (e.g., GPS services).

In particular embodiments, the transportation matching system 602 may manage transportation matching services to connect a user/requester with a vehicle and/or provider. By managing the transportation matching services, the transportation matching system 602 can manage the distribution and allocation of resources from the vehicle subsystem 608 and user resources such as GPS location and availability indicators, as described herein.

Transportation matching system 602 may be accessed by the other components of network environment 600 either directly or via network 604. In particular embodiments, transportation matching system 602 may include one or more servers. Each server may be a unitary server or a distributed server spanning multiple computers or multiple datacenters. Servers may be of various types, such as, for example and without limitation, web server, news server, mail server, message server, advertising server, file server, application server, exchange server, database server, proxy server, another server suitable for performing functions or processes described herein, or any combination thereof. In particular embodiments, each server may include hardware, software, or embedded logic components or a combination of two or more such components for carrying out the appropriate functionalities implemented or supported by server. In particular embodiments, transportation matching system 602 may include one or more data stores. Data stores may be used to store various types of information. In particular embodiments, the information stored in data stores may be organized according to specific data structures. In particular embodiments, each data store may be a relational, columnar, correlation, or other suitable database. Although this disclosure describes or illustrates particular types of databases, this disclosure contemplates any suitable types of databases. Particular embodiments may provide interfaces that enable a client device 606, or a transportation matching system 602 to manage, retrieve, modify, add, or delete, the information stored in data store.

In particular embodiments, transportation matching system 602 may provide users with the ability to take actions on various types of items or objects, supported by transportation matching system 602. As an example, and not by way of limitation, the items and objects may include transportation matching networks to which users of transportation matching system 602 may belong, vehicles that users may request, location designators, computer-based applications that a user may use, transactions that allow users to buy or sell items via the service, interactions with advertisements that a user may perform, or other suitable items or objects. A user may interact with anything that is capable of being represented in transportation matching system 602 or by an external system of a third-party system, which is separate from transportation matching system 602 and coupled to transportation matching system 602 via a network 604.

In particular embodiments, transportation matching system 602 may be capable of linking a variety of entities. As an example, and not by way of limitation, transportation matching system 602 may enable users to interact with each other or other entities, or to allow users to interact with these entities through an application programming interfaces (“API”) or other communication channels. In particular embodiments, transportation matching system 602 may include a variety of servers, sub-systems, programs, modules, logs, and data stores. In particular embodiments, transportation matching system 602 may include one or more of the following: a web server, action logger, API-request server, relevance-and-ranking engine, content-object classifier, notification controller, action log, third-party-content-object-exposure log, inference module, authorization/privacy server, search module, advertisement-targeting module, user-interface module, user-profile store, connection store, third-party content store, or location store. Transportation matching system 602 may also include suitable components such as network interfaces, security mechanisms, load balancers, failover servers, management-and-network-operations consoles, other suitable components, or any suitable combination thereof. In particular embodiments, transportation matching system 602 may include one or more user-profile stores for storing user profiles. A user profile may include, for example, biographic information, demographic information, behavioral information, social information, or other types of descriptive information, such as work experience, educational history, hobbies or preferences, interests, affinities, or location.

The web server may include a mail server or other messaging functionality for receiving and routing messages between transportation matching system 602 and one or more client devices 606. An action logger may be used to receive communications from a web server about a user’s actions on or off transportation matching system 602. In conjunction with the action log, a third-party-content-object log may be maintained of user exposures to third-party-content objects. A notification controller may provide information regarding content objects to a client device 606. Information may be pushed to a client device 606 as notifications, or information may be pulled from client device 606 responsive to a request received from client device 606. Authorization servers may be used to enforce one or more privacy settings of the users of transportation matching system 602. A privacy setting of a user determines how particular information associated with a user can be shared. The authorization server may allow users to opt in to or opt out of having their actions logged by transportation matching system 602 or shared with other systems, such as, for example, by setting appropriate privacy settings. Third-party-content-object stores may be used to store content objects received from third parties. Location stores may be used for storing location information received from client devices 606 associated with users.

In addition, the vehicle subsystem 608 can include a human-operated vehicle or an autonomous vehicle. A provider of a human-operated vehicle can perform maneuvers to pick up, transport, and drop off one or more requesters according to the embodiments described herein. In certain embodiments, the vehicle subsystem 608 can include an autonomous vehicle— i.e., a vehicle that does not require a human operator. In these embodiments, the vehicle subsystem 608 can perform maneuvers, communicate, and otherwise function without the aid of a human provider, in accordance with available technology.

In particular embodiments, the vehicle subsystem 608 may include one or more sensors incorporated therein or associated thereto. For example, sensor(s) 610 can be mounted on the top of the vehicle subsystem 608 or else can be located within the interior of the vehicle subsystem 608. In certain embodiments, the sensor(s) 610 can be located in multiple areas at once— i.e., split up throughout the vehicle subsystem 608 so that different components of the sensor(s) 610 can be placed in different locations in accordance with optimal operation of the sensor(s) 610. In these embodiments, the sensor(s) 610 can include a LIDAR sensor and an inertial measurement unit (“IMU”) including one or more accelerometers, one or more gyroscopes, and one or more magnetometers. The sensor(s) 610 can additionally or alternatively include a wireless IMU (“WIMU”), one or more cameras, one or more microphones, or other sensors or data input devices capable of receiving and/or recording information relating to navigating a route to pick up, transport, and/or drop off a requester.

In particular embodiments, the vehicle subsystem 608 may include a communication device capable of communicating with the client device 606 and/or the transportation matching system 602. For example, the vehicle subsystem 608 can include an on-board computing device communicatively linked to the network 604 to transmit and receive data such as GPS location information, sensor-related information, requester location information, or other relevant information.

In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. Various embodiments and aspects of the invention(s) are described with reference to details discussed herein, and the accompanying drawings illustrate the various embodiments. The description above and drawings are illustrative of the invention and are not to be construed as limiting the invention. Numerous specific details are described to provide a thorough understanding of various embodiments of the present invention.

The present invention may be embodied in other specific forms without departing from its spirit or essential characteristics. The described embodiments are to be considered in all respects only as illustrative and not restrictive. For example, the methods described herein may be performed with less or more steps/acts or the steps/acts may be performed in differing orders. Additionally, the steps/acts described herein may be repeated or performed in parallel with one another or in parallel with different instances of the same or similar steps/acts. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are to be embraced within their scope.