Patent Application
20230195816
In recent years, transportation matching systems have introduced significant technological improvements in mobile app-based matching of transportation providers and requesters. Indeed, the proliferation of web and mobile applications enable requesting computer devices to submit transportation requests via on-demand transportation matching systems. On-demand transportation matching systems can identify available provider computing devices that can provide transportation services from one geographic location to another and identify digital matches between provider computing devices and requester computing devices. Although conventional transportation matching systems can match requesting computing devices with provider computing devices, conventional systems often face a number of technical problems, particularly with respect to flexibility of operation and efficiency of implementing computing devices.
One or more embodiments provide benefits and/or solve one or more of the foregoing or other problems in the art with systems, methods, and non-transitory computer readable storage media that generate region-based metrics for provider devices based on movement of provider devices through various regions and transportation requests within the various regions. In particular, the disclosed systems can improve network coverage and computing efficiency by providing an accumulating regional metric map including one or more regions with pins indicating one or more region-based metrics to a provider device. The disclosed systems can then determine whether the provider device passes through (or otherwise enters) a region with a pin and determine the corresponding region-based metric of the region for the provider device. Furthermore, in response to generating a transportation match between the provider device and a requester device, the disclosed systems can provide a notification of the region-based metric to the provider device in connection with the transportation match. The disclosed systems can utilize the region-based metrics to improve throughput, network coverage, and computational resources of a transportation matching system.
The detailed description refers to the drawings briefly described below.
This disclosure describes one or more embodiments of a regional accumulation system that determines accumulating regional metrics for provider devices based on movement of the provider devices relative to an accumulating regional metric map. In particular, the regional accumulation system determines values and placement of accumulating metric pins within an accumulating regional metric map including a plurality of regions in connection with a transportation matching system. For example, as the number of unmatched transportation requests within various regions or sub-regions increases, the regional accumulation system utilizes cumulative events metrics within regional (or sub-regional) repositories to manage network coverage and provider device utilization.
To illustrate, the regional accumulation system can determine an accumulating regional metric for a particular provider device when the provider device moves through a region to another region based on the cumulative events metrics. The regional accumulation system can then generate a notification of the accumulating regional metric to provide to the provider device in connection with a transportation match involving the provider device, even when the provider device is offline or otherwise unavailable (e.g., not currently servicing transportation requests). By leveraging information about provider/requester device imbalances across a plurality of regions to provide notifications to provider devices, the regional accumulation system can more efficiently utilize available or unavailable provider devices, increase network coverage, improve throughput, and reduce computational resources.
In one or more embodiments, the regional accumulation system provides an accumulating regional metric map for display at a provider device. For instance, the regional accumulation system is part of a transportation matching system that matches transportation requests from transportation requester devices to transportation provider devices in one or more regions or sub-regions. In one or more embodiments, in connection with generating transportation matches for requests, the regional accumulation system provides a map of the region(s) to a provider device. To illustrate, the regional accumulation system provides the accumulating regional metric map including a plurality of accumulating metric pins according to region-based data for one or more regions (or sub-regions).
According to one or more embodiments, the regional accumulation system determines a plurality of cumulative events metrics for a plurality of regions based on transportation requests in the plurality of regions. Specifically, the regional accumulation system determines a number of requests located within each region (e.g., within each geocoded area) and/or transportation values associated with the requests. The regional accumulation system then determines the cumulative events metrics for the regions based on the number of requests and/or the transportation values of the requests within each region. The regional accumulation system also determines the accumulating metric pins according to the cumulative events metrics.
In one or more additional embodiments, the regional accumulation system determines an accumulating regional metric for a provider device based on movement of the provider device. For example, the regional accumulation system monitors movement of the provider device to a first region associated with an accumulating metric pin in the accumulating regional metric map. The regional accumulation system then determines an accumulating regional metric for the provider device based on the accumulating metric pin of the first region. In some embodiments, the regional accumulation system determines the accumulating regional metric for the provider device according to transportation requests in neighboring regions that are expected to convert (e.g., match with other provider devices).
Furthermore, the regional accumulation system provides a notification of the accumulating regional metric to the provider device in connection with a transportation request. In particular, the regional accumulation system can generate a transportation match for the provider device to a transportation request within a second region different from the first region. In connection with the transportation match, the regional accumulation system can provide a transportation match notification that includes the accumulating regional metric. To illustrate, the regional accumulation system can apply the accumulating regional metric to the transportation request upon the provider device fulfilling the transportation request.
As mentioned, although conventional transportation matching systems can match requesting computing devices with provider computing devices, conventional systems often face a number of technical problems, particularly with respect to flexibility of operation and efficiency of implementing computing devices. In particular, conventional transportation matching systems provide user interfaces that illustrate personalized transportation incentive values for small regional areas to encourage repositioning of online provider devices. This approach, however, is often inefficient because it requires individualized determinations for particular provider devices. Indeed, this approach can require significant computational resources to generate individual user interfaces and corresponding values across hundreds or thousands of provider devices.
Moreover, conventional systems are often rigid and inflexible in responding to provider device imbalances. For instance, many conventional systems can utilize user interfaces to reposition provider devices through incentive repositioning elements but fail to address provider device imbalances where the number of requester devices outpaces provider devices. As outlined in greater detail below, such imbalances can result in significant system inefficiencies and the inflexibility of conventional approaches cannot address such circumstances other than to reposition existing provider devices in particular locations.
As just mentioned, conventional transportation matching systems often operate inefficiently in matching provider devices and requester devices. In particular, conventional systems often inefficiently utilize time, communication, and computing resources when matching provider vehicles with requesters. These inefficiencies are exacerbated by poor network coverage resulting from device imbalances, such as a shortfall in provider devices relative to the number of requestor devices. For instance, many conventional transportation matching systems generate inefficient matches that require significant time for provider devices to travel to requester devices and significant time for servers, provider devices, and requester devices to operate in managing a transportation match. This additional waiting time translates to additional and excessive network bandwidth and utilization of computational resources. Indeed, each additional minute of inefficient time translates to multiple different queries from requester devices (e.g., updates regarding provider device locations, duplicate digital transportation requests, queries regarding other transportation options, etc.), and provider devices (e.g., navigational queries, queries regarding alternative pick-up options, etc.).
Moreover, excessive travel/waiting time often results in additional digital cancellations, which leads to duplicate network traffic and computational processing (e.g., additional requests from requester devices, communication with provider devices, and server resources in identifying duplicate matches and coordinating transportation services). To illustrate, due at least in part to the inflexibility of the conventional systems, the conventional systems are also unable to efficiently handle imbalances in network coverage for a given area. These imbalances result in matches with long wait times that inefficiently dispatch provider devices, which further results in letting other transportation requests lapse due to long wait times without matching the requests.
The regional accumulation system provides several technical benefits relative to conventional systems. For example, the regional accumulation system can improve the flexibility of operation relative to conventional systems. In particular, the regional accumulation system utilizes a flexible computational model that generates accurate accumulating regional metrics for provider devices and provides accumulating regional metric maps across large regions applicable to a large population of online and offline provider devices. Rather than generating individualized small-region incentive values, the regional accumulation system can generate accumulating regional metric maps that are applicable across a population of provider devices, thus significantly reducing computational resources and bandwidth.
In addition, rather than focusing on repositioning of existing provider devices, the regional accumulation system can improve device imbalances by increasing the provider device pool in areas with excessive requester device numbers relative to the number of provider devices. Indeed, the regional accumulation system can provide an accumulating regional metric map to online and offline drivers. The accumulation regional metric map can include accumulating metric pins that reflect accumulating regional metrics that provider devices can attain by traveling to or through a corresponding region. Thus, even when transportation requests originate outside of a particular region, the regional accumulation system can apply accumulating regional metrics to provider devices, which results in increased provider device coverage within the network. Indeed, provider devices that are offline increase coverage by coming online to attain and achieve accumulating regional metrics and online provider devices continue providing coverage to complete accumulating regional metrics that they have attained. Accordingly, rather than focusing on repositioning, the regional accumulation system identifies device imbalances and generates an accumulating regional metric map that focuses on addressing the underlying device imbalances.
As just mentioned, the regional accumulation system, in connection with a transportation matching system, integrates location data (e.g., GPS signals from GPS devices) of provider devices and requester devices into a single computational model. The computational model provides provider device allocations that are adaptable to changing device-request balances for improved network coverage of the computing systems implementing the transportation matching system.
Additionally, the regional accumulation system also improves the efficiency of computing systems implementing a transportation matching system. Specifically, the regional accumulation system provides accumulating regional metric maps even when provider devices are offline (e.g., not waiting for transportation requests or servicing transportation requests). In particular, by providing accurate accumulating regional metric maps for display at provider devices that are offline, the regional accumulation system can address underlying device imbalances in addition to locating those provider devices to areas of greater network coverage. The regional accumulation system thus improves the network coverage across a plurality of areas, which reduces computing inefficiencies resulting from unnecessary travel time, unexpected wait times, and request submissions and processing. Specifically, improved network coverage significantly reduces the number of digital rejections/cancellations from requester devices and provider devices, which further reduces the numbers of queries, status update requests, and other digital communication that strain network bandwidth and processing resources. In addition, by reducing cancellations, the regional accumulation system can further improve utilization of computational resources required to determine transportation matches by avoiding duplicate and unnecessary computer matching processes.
Turning now to the figures,
As shown in
In addition to communicating with requester devices 106a-106n, the transportation matching system 112 also communicates with the provider devices 108a-108n in connection with transportation requests. Specifically, the transportation matching system 112 generates transportation matches for transportation requests by assigning specific provider devices to the transportation requests based on a variety of match criteria. To illustrate, the transportation matching system 112 utilizes location data, availability (e.g., whether a provider device is available for transportation requests), and other data associated with provider devices and/or of a region in which the transportation requests are located to assign provider devices to transportation requests. The transportation matching system 112 then communicates with the provider devices 108a-108n to send data associated with the transportation matches to the provider devices 108a-108n (e.g., for display within the provider applications 116a-116n). In one or more embodiments, the transportation matching system 112 also provides information associated with transportation requests (e.g., pick-up location, destination location, requester information, transportation value, estimated duration, estimated time of arrival).
Furthermore, as illustrated in
As illustrated in
Additionally, as used herein, the term “provider device” or “transportation provider device” refers to a computing device associated (or used by) a provider or a transportation vehicle. In some embodiments, a provider device includes a provider application comprising instructions that (upon execution) cause the provider device to perform various actions for a transportation matching system. A provider device can include a mobile computing device (e.g., a smartphone) or a computing device installed (or otherwise integrated) into a transportation vehicle for displaying information associated with a provider user and/or transportation requests. Such instructions may likewise cause a provider device to present a graphical user interface identifying one or more premium metrics for one or more target geocoded areas (e.g., within a heatmap). A provider device can also include functionality for indicating to the transportation matching system 112 that the provider device is online or offline.
As used herein, the term “transportation request” refers to a request from a requesting device (i.e., a requester device) for transport by a transportation vehicle. In particular, a transportation request includes a request for a transportation vehicle to transport a requester or a group of individuals from one geographic area to another geographic area. A transportation request can include information such as a pick-up location, a destination location (e.g., a location to which the requester wishes to travel), a request location (e.g., a location from which the transportation request is initiated), location profile information, a requester rating, or a travel history. As an example of such information, a transportation request may include an address as a destination location and the requester's current location as the pick-up location. A transportation request can also include a requester device initiating a session via a transportation matching application and transmitting a current location (thus, indicating a desire to receive transportation services from the current location).
Although not illustrated in
When a transportation vehicle is an autonomous vehicle or a hybrid self-driving vehicle, the transportation vehicle may include additional components not depicted in
As mentioned above, the provider devices 108a-108n may be separate or integral to transportation vehicles. Additionally, or alternatively, a provider device may be a subcomponent of a vehicle computing system. Regardless of its form, the provider devices 108a-108n may include various sensors, such as a GPS locator, an inertial measurement unit, an accelerometer, a gyroscope, a magnetometer, and/or other sensors, from which the transportation matching system 112 can access information, such as location information.
As previously mentioned, the regional accumulation system 102 can provide accumulating regional metric maps to provider devices. Specifically, the regional accumulation system 102 can provide the region-based information to provider devices to incentivize transportation vehicles to reposition to specific areas. For example,
In one or more embodiments, as illustrated in
As illustrated in
As mentioned, the regional accumulation system 102 provides an accumulating regional metric map to a provider device including a plurality of accumulating metric pins marking high demand areas.
As mentioned,
In one or more embodiments, a region includes a collection of sub-regions and/or geocoded areas (i.e., “geohashes”). Specifically, a geocoded area or geohash refers to a spatial subdivision or subunit of a sub-region or a larger geographic space. A geocoded area may be a subdivision of a geographic neighborhood as well as a subdivision of a city. As a subdivision, a geocoded area may include a segment of a street, a street, a set of bordering streets, a city block, a set of city blocks, or another portion of an area within a larger geographic space. For example, a set of bordering streets may define a geocoded area within a larger space, such as a set of streets around Times Square in New York City, N.Y. In certain embodiments, a geocoded area represents a geographic hash in a grid (or other polygon shape) of geohashes within a larger geographic space. Regardless of the form of a geocoded area, one or more requesters and corresponding requester devices or providers and corresponding provider devices may be located within a geocoded area.
According to one or more embodiments, the regional accumulation system 102 also determines provider device data 302 associated with a plurality of provider devices within the plurality of regions. For example, the regional accumulation system 102 obtains location data from GPS sensors or other location sensors of the provider devices. To illustrate, as provider devices (e.g., transportation vehicles) travel and move within and across one or more regions, the regional accumulation system 102 can track the locations of the provider devices. In particular, the regional accumulation system 102 can monitor movement of provider devices engaged in fulfilling transportation requests (e.g., traveling to a request location or transporting a requester from a pick-up location to a destination location). The regional accumulation system 102 can also monitor movement of provider devices waiting for transportation requests and/or provider devices that are unavailable for fulfilling requests.
In one or more embodiments, the provider device data 302 includes information about an availability of provider devices. Specifically, the provider device data 302 can include an indicator of an availability status of each provider device. For instance, the regional accumulation system 102 can determine whether each provider device has a “P0” status (i.e., offline, not servicing transportation requests, and/or not waiting for transportation requests), a “P1” status (i.e., online and waiting for transportation requests), a “P2” status (i.e., traveling to a pick-up location of a transportation request), or a “P3” status (i.e., transporting a requester from a pick-up location to a destination location). Accordingly, the regional accumulation system 102 can determine whether each provider device is offline or online in addition to a location of the provider device.
As illustrated in
As illustrated in
A cumulative events metric can also be based on an unrealized amount of a yet-to-be-completed transport or a realized amount of a completed transport. The regional accumulation system 102 can thus increment the value of the cumulative events metric as transportation events occur for a particular transportation request. Additionally, a cumulative-events metric can be further based on a predicted request metric (e.g., an anticipated net income) for a transportation request in the geocoded area. Accordingly, each geocoded area can be associated with a cumulative events metric, with each cumulative events metric being representative (directly or indirectly) of a number of transportation events occurring relative to a specific geocoded area for a period of time. In some embodiments, a cumulative events metric is further based on transportation requests predicted to occur within a period of time.
In additional embodiments, the regional accumulation system 102 determines the cumulative events metrics 306 for regions. For example, the regional accumulation system 102 can determine a number of transportation events occurring for the transportation requests 300 within a plurality of related geocoded areas. To illustrate, the regional accumulation system 102 can determine cumulative events metrics for a region based on the cumulative events metrics of geocoded areas within the region.
According to at least some embodiments, as illustrated in
As further illustrated in
As used herein, the term “estimated request conversion score” refers to a conversion probability for a transportation request given a particular transportation value for the transportation request. To illustrate, the regional accumulation system 102 utilizes the conversion learner model 310 to generate a plurality of different conversion probabilities (e.g., forecasted) for a single transportation request relative to a plurality of different price points. Accordingly, in one or more embodiments, the regional accumulation system 102 utilizes the conversion learner model 310 to generate the estimated request conversion scores 312 for the transportation requests 300 according to a plurality of different transportation values.
In one or more embodiments, the regional accumulation system 102 leverages the provider device data 302 and the region data 304 to generate the estimated request conversion scores 312 for the transportation requests 300. For instance, the regional accumulation system 102 can estimate the conversion probability for a transportation request within a time period based on a ratio of provider devices to transportation requests within a region or geocoded area of the transportation request. Additionally, the regional accumulation system 102 can utilize historical conversion rates associated with the region or geocoded area to determine the conversion probability given the current balance of provider devices and transportation requests. The regional accumulation system 102 can further utilize information about time of day, seasonality, regional events, demographics, and other data associated with a region or geocoded area to generate the estimated request conversion scores 312.
For example, if a first transportation request is located in a region with low historical rates of conversion, the conversion learner model 310 may return a low estimated request conversion score for the first transportation request at a first price point. Lowering the price point by a certain amount may cause the conversion learner model 310 to generate a higher estimated conversion score for the first transportation request. Additionally, for a second transportation request occurring in a different region with higher historical rates of conversion and a similar provider device-request ratio, the conversion learner model 310 may generate a higher estimated request conversion score at the first price point than the estimated request conversion score for the first transportation request.
In one or more embodiments, the regional accumulation system 102 utilizes the estimated request conversion scores 312 to determine target distributions to provider devices based on the cumulative events metrics 306 in the location-based repositories 308. For example, as illustrated in
The regional accumulation system 102 then generates the accumulating regional metrics 316 for a plurality of geocoded areas in a region. Specifically, as used herein, the term “accumulating regional metric” refers to an added transportation value that attaches to provider devices moving through a geographical area during a particular time period. For example, an accumulating regional metric can include a numerical value representing a bonus value, premium, or reward associated with a geocoded area or region for a time period. Additionally, an accumulating regional metric can be based on a balance of provider devices and transportation requests within the geocoded area and/or region for the time period. In connection with the cumulative events metrics 306 in the location-based repositories 308, the regional accumulation system 102 thus determines the accumulating regional metrics 316 based on the number and corresponding transportation values of the transportation requests 300 across a plurality of geocoded areas and regions.
According to one or more embodiments, the regional accumulation system 102 determines the accumulating regional metrics 316 by utilizing one or more objective functions. For instance, the regional accumulation system 102 can determine conversion probabilities adjusted according to transportation values of transportation requests (e.g., indicating requester device elasticity). In some embodiments, the regional accumulation system 102 can also consider provider device elasticity (e.g., time, location, and/or value based elasticity that will result in increasing or decreasing provider device response based on the accumulating regional metric and other regional features). For example, the regional accumulation system 102 can iteratively determine conversion probabilities as solving a first objective function subject to a plurality of constraints, as follows:
Maximize: fT(dºy)
Subject to: Mdºyβ1º(Ms−R−β0)
In one or more embodiments, the regional accumulation system 102 determines the first objective function based on a second objective function that modulates demand via a transportation value metric, as shown:
Maximize: fT(dºy(x))
Subject to: Mdºyβ1º(Ms−R−β0)
Additionally, as shown above, a transportation value metric constraint is represented as 0x
xmax. According to one or more embodiments, the transportation value metric constraint includes a constraint on the transportation value metric determined by the objective function. Specifically, the regional accumulation system 102 can set xmax∈
+n as the maximum transportation-value metric, which may be the same throughout a single region, and set the transportation-value metric x to greater than or equal to zero. The regional accumulation system 102 thus utilizes the second objective function to maintain a certain level of open supply that maximizes the network throughput in a given geocoded area. In one or more embodiments, the regional accumulation system 102 convexifies the second objective function to create the first objective function via y=y(x). The regional accumulation system 102 can thus utilize the first objective function to maximize over quantiles.
In one or more embodiments, as mentioned, the regional accumulation system 102 also utilizes a geospatial smoothing model to determine the expected contribution of each transportation request to other transportation requests in neighboring geocoded areas.
As shown in
In one or more embodiments, the regional accumulation system 102 determines an estimated-time-of-arrival (“ETA”)—based on an exponential smoothing function to apply to each transportation request expected to convert in a geocoded area i to determine its relative importance, proxied by proximity, relative to other transportation requests expected to convert in each neighboring geocoded area j. For example, the regional accumulation system 102 can determine ETA based on historic traffic information, speed limits, and road distance to determine the travel distance. In particular, the smoothing function can be represented as:
where α is a contribution decay constant, tETA(i,j) represents the ETA from geocoded area i to geocoded area j, and nbh(i, ) returns the neighboring geocoded areas of the input geocoded area i from
. According to some embodiments, these values are fixed with respect to the ETAs. The regional accumulation system 102 can precompute and cache the values to avoid the computational overhead associated with computing these values each time the regional accumulation system 102 generates the accumulating regional metrics.
Furthermore, the regional accumulation system 102 can further determine a weighting matrix representing the contributing weights associated with transportation requests in geocoded areas. More specifically, in one or more embodiments, the weighting matrix is represented as:
such that each entry Wij represents the contribution to an accumulating regional metric for a provider device in geocoded area i from the geocode-specific repository for geocoded area j. According to the contribution function above, the weights can further be represented as:
Accordingly, the contribution to the geocode-specific repository of geocoded area i from the geocode-specific repository of geocoded area j is the same as the proportional contribution weight (e.g., importance) of a transportation request expected to convert in geocoded area i relative to geocoded area j compared to the contribution weights of other transportation requests in the neighborhood of geocoded area j.
Given a vector of raw, non-negative values in geocode-specific repositories that the regional accumulation system 102 intends to distribute for a region during a time period, in one or more embodiments, represented as e∈+n, the regional accumulation system 102 determines the target accumulating regional metric at geohash i=1, . . . , n is:
b
i
tgt
=w
i
T
e
In one or more embodiments, the regional accumulation system 102 manages the cumulative events metrics and contributions of each location-based repository for a plurality of geocoded areas and a plurality of regions.
In one or more additional embodiments, the regional accumulation system 102 determines to distribute a proportion of values in location-based repositories as accumulating regional metrics to smooth incoming revenues in the location-based repositories. For instance, if the proportion is 20%, the proportion corresponds to smoothing the revenues over a 5-minute period (or other corresponding time period).
Furthermore, the regional accumulation system 102 can provide temporal smoothing to the accumulating regional metrics over time. For example, the regional accumulation system 102 can penalize differences accumulating regional metrics over time (e.g., as part of applying an objective function to determining accumulating regional metrics for individual regions). This approach can avoid large and rapid fluctuations in accumulating regional metrics over time. In some implementations, the regional accumulation system 102 penalizes or limits temporal fluctuations only in a certain direction (e.g., downward movement of accumulating regional metrics). For example, the regional accumulation system 102 allows for (e.g., does not punish) upward movement in accumulating regional metrics over time to provide rapid response to device imbalances, while penalizing downward movement to avoid undermining provider device confidence and expectations.
As mentioned, the regional accumulation system 102 generates accumulating regional metrics for provider devices based on transportation requests expected to convert in one or more regions, which can be distinct from the cumulative events metrics stored in the location-based repositories. In one or more embodiments, the regional accumulation system 102 determines a target accumulating regional metric btgt based on the values in the location-based repositories indicating a lack of supply relative to available supply s0. The regional accumulation system 102 can determine an optimal accumulating regional metric b∈+n to provide to provider devices in one or more regions for a current time period and the corresponding contributions of each location-based repository C∈
n×n, where Cij represents the contribution to an accumulating regional metric of a provider device in geohash i from the location-based repository of geohash j.
In one or more embodiments, the regional accumulation system 102 minimizes a difference between an accumulating regional metric and a target accumulating regional metric to prioritize funds for transportation requests expected to convert to the origination location of the corresponding cumulative events metric. Additionally, the regional accumulation system 102 can utilize a penalty function on differences between adjacent accumulating regional metrics in one or more regions to spatially smooth the accumulating regional metrics for consistency. This can allow the regional accumulation system 102 to ensure sufficient cumulative events metrics for each accumulating regional metric that corresponds to an expected request conversion. According to one or more embodiments, the regional accumulation system 102 utilizes an accumulating regional metric generation model represented as:
Minimize ∥b−btgt∥γdiff∥Db∥22+γprev∥(b−bprev)−∥1+γclear∥1Tdiag(dºy*)b−1TCe∥1
Subject to diag(dºy*)bCe
As further shown above, bmin, bmax∈+n represents minimum and maximum accumulating regional metrics. Additionally, Cmax∈
+n×n represents a cap (e.g., maximum value) of contributions by a geocode-specific repository, in which the regional accumulation system 102 sets Cijmax to 1 if j is a geohash j is within a specific proximity of geohash i, and 0 otherwise (e.g., a minimum contribution proportion). Furthermore, ydiff∈
++, γprev∈
++, and γclear∈
++ represent positive scalar parameters for the accumulating regional metric and target accumulating regional metric difference (e.g., the difference between a bonus value and target bonus value) for corresponding penalty terms.
Furthermore, in one or more embodiments, the regional accumulation system 102 provides a post-computation constraint diag(dºy*)bCe according to the contribution of each geocode-specific repository to an accumulating regional metric. In other words, the ith element:
indicates a budget amount allocated to geohash i. The proportion of the contribution from j to i is thus:
According to one or more embodiments, the regional accumulation system 102 provides a dictionary of the repository identifiers and their corresponding contribution portions for each accumulating regional metric for a specific template rather than the expected contribution in monetary value. The regional accumulation system 102 can thus standardize the contributions per accumulating regional metric to sum to unity. Any system referring to the template contributions can thus convert the standardized value of an expected contribution to a monetary value.
In additional embodiments, the above model minimizes penalty terms with scalar parameters. For example, ∥Db∥22 represents a spatial smoothing penalty that the model utilizes to reduce the difference between accumulating regional metrics in geographically adjacent locations. Additionally, ∥(b−bprev)−∥1 represents a temporal smoothing penalty that the model utilizes to reduce the difference between accumulating regional metrics b and the previous set of accumulating regional metrics bprev if the difference is negative. Thus, the regional accumulation system 102 can ignore value increases compared to previous values while preventing decreases relative to previous values in some regions. Furthermore, ∥1Tdiag(dºy*)b−1TCe∥1 represents a budget clearance penalty that the model utilizes to reduce the difference between the amount of money spent across all regions and the values stored in the location-based accounts.
In one or more embodiments, the regional accumulation system 102 also determines accumulating regional metrics for regions based on historical rates for P0-to-P1 conversion relative to accumulating regional metrics. For example, the regional accumulation system 102 can utilize a machine-learning model (e.g., a linear regression model) trained on historical data associated with provider devices (including provider device positioning, region distance, etc.) to determine specific accumulating regional metrics at which providers are most likely to go online.
As mentioned, the regional accumulation system 102 provides accumulating regional metric maps to provider device to address underlying device imbalances in improvement network coverage for transportation vehicles in geographical areas. In one or more embodiments, the regional accumulation system 102 inserts one or more accumulating metric pins into one or more regions of an accumulating regional metric map based on accumulating regional metrics for the region(s).
For example,
In one or more embodiments, the regional accumulation system 102 determines accumulating regional metrics for a plurality of sub-regions. For instance, the regional accumulation system 102 can determine a plurality of sub-regions that have accumulating regional metrics within a threshold range of values. Specifically, the regional accumulation system 102 can utilize a clustering model to group sub-regions having accumulating regional metrics that are above a minimum value and below a maximum value. To illustrate, the regional accumulation system 102 can utilize a clustering model that determines sub-regions that have accumulating regional metrics of greater than or equal to a first integer (e.g., 2) and less than a second integer (e.g., 3). In alternative embodiments, the regional accumulation system 102 utilizes a clustering model that groups sub-regions with the same accumulating regional metrics (e.g., the accumulating regional metrics for the sub-regions are the same value). For example, the regional accumulation system 102 can utilize a connected-component labeling algorithm (e.g., a 4-connectivity variant) to generate clusters of sub-regions.
In one or more embodiments, as used herein, the term “accumulating cluster metric” refers to a combined value representing accumulating regional metrics of a plurality of regions or sub-regions. Specifically, the regional accumulation system 102 determines an accumulating cluster metric for a cluster of sub-regions by determining a lowest threshold value associated with the accumulating regional metrics of the sub-regions. For example, in response to clustering sub-regions that have accumulating regional metrics between a first value and a second value, the regional accumulation system 102 can select the first value as the accumulating cluster value. Alternatively, the regional accumulation system 102 can select an average value (e.g., mean or median value), a maximum value, or other representative value for the accumulating regional metrics of the corresponding sub-regions. Additionally, if the representative value of the cluster changes based on one or more accumulating regional metrics and/or sub-regions within the cluster changing, the regional accumulation system 102 can update the accumulating cluster metric.
The regional accumulation system 102 can utilize a model for determining the accumulating regional metrics for sub-regions according to the selected clustering model. To illustrate, the regional accumulation system 102 can utilize a model that generates integer values of accumulating regional metrics or a model that generates float values (e.g., decimal) of accumulating regional metrics based on the selected clustering model. In alternative embodiments, the regional accumulation system 102 selects the clustering model based on whether the accumulating regional metrics are integer values or float values.
As illustrated in
In one or more embodiments, the regional accumulation system 102 determines to subdivide a region into a plurality of regions. Specifically, the regional accumulation system 102 can determine that a size or a shape of the region does not satisfy a threshold size or a threshold shape. For instance, the regional accumulation system 102 determines a threshold size including a maximum size of regions. The regional accumulation system 102 compares the region 400 to the threshold size and determines to subdivide the region 400 in response to the region 400 not meeting the threshold size. In alternative, the regional accumulation system 102 can compare the region 400 to a threshold shape (e.g., a convex shape or shape with a certain width/length ratio) to determine whether the region 400 is non-convex, long, etc. The regional accumulation system 102 can then determine to subdivide the region 400 if the region 400 does not meet the threshold shape.
As illustrated in
In some embodiments, the regional accumulation system 102 subdivides a region along an axis that passes through a centroid of the region until the smallest subdivision meets the threshold(s). For instance, the regional accumulation system 102 subdivides along a line intersecting centroids of a convex hull of the region and a shape of the region. To illustrate, the regional accumulation system 102 utilizes a subdivision model that generates a convex hull from a set of points in the region in O(n log n) time. In alternative embodiments, the regional accumulation system 102 subdivides a region along other subdivision lines based on approximate size, shape, and/or number of sub-regions of the subdivisions.
As illustrated in
In one or more embodiments, the regional accumulation system 102 determines an accumulating regional metric pin for a region at a point other than a centroid of the region.
In one or more embodiments, the regional accumulation system 102 determines the new placement position 412 of the accumulating regional metric pin at a point within the first region 408. For instance, the regional accumulation system 102 determines a pole of inaccessibility for the first region 408. In particular, as used herein, the term “pole of inaccessibility” refers to a point within a polygon that is farthest from any edges of the polygon. To illustrate, the regional accumulation system 102 can utilize a function (e.g., a grid-based algorithm) to determine the pole of inaccessibility by covering a polygon (e.g., defined by the region) with square cells and then iteratively splitting and pruning the square cells according to a maximum potential distance from a point inside each cell within the polygon. Thus, the regional accumulation system 102 determines the pole of inaccessibility to place the accumulating regional metric pin within a boundary of the region. This approach can assist in avoiding placement of an accumulating regional metric pin in a location that is not available to provide transportation services or that does not have an accumulating regional metric. For example, the regional accumulation system 102 can avoid providing accumulating regional metric pins or corresponding region designators on a runway/airstrip of an airport with areas of high demand nearby/surrounding the runway/airstrip.
In one or more additional embodiments, rather than determining a pole of inaccessibility via a grid-based algorithm based on a polygon defined by one or more regions, the regional accumulation system 102 utilizes predefined geocoded areas. For example, the regional accumulation system 102 can determine the pole of inaccessibility for a region as a geohash of inaccessibility. Specifically, the regional accumulation system 102 finds one or more geohashes within a cluster that is farthest from edges of the region. The regional accumulation system 102 can then find the center of the geohash of inaccessibility in the cluster. Additionally, the regional accumulation system 102 can jitter the location for pin placement (e.g., via slight movement of a pin) to reduce a grid-like appearance of the pin placement and/or region.
As illustrated in
In one or more embodiments, each of the regions may be associated with different accumulating regional metrics. For example, as illustrated in
In various embodiments, the provider device 500 displays the region markers with different visual characteristics to distinguish the regions. For example, the provider device 500 can display the region markers with a specific color based on the values of the corresponding accumulating regional metric pins. Additionally, while
According to one or more embodiments, the provider device 500 includes a position marker 508 of the provider device 500. To illustrate, the provider device 500 includes a location sensor (e.g., GPS) to determine a location of the provider device 500. The provider device 500 can then display the position marker 508 within the accumulating regional metric map 502. As the provider device 500 moves within or through regions, the provider device 500 can update the position marker 508 within the accumulating regional metric map 502.
In some embodiments, the regional accumulation system 102 monitors movement of the provider device 500 to determine whether the provider device 500 enters or is otherwise located within a region having an accumulating regional metric. In response to determining that the provider device 500 is located within a region with an accumulating regional metric, the regional accumulation system 102 can provide a notification 510 for display at the provider device 500. For instance, the regional accumulation system 102 can provide the notification 510 including a message indicating that the provider device 500 is within a region with an accumulating regional metric. The notification 510 can also include a message indicating for the provider device 500 to go online (e.g., sign into the transportation matching system) to unlock a bonus based on the accumulating regional metric of the region. Furthermore,
As mentioned above, the regional accumulation system 102 can provide the accumulating regional metric map 502 across an entire population of provider devices. Indeed, the regional accumulation system 102 can reduce computational resources by determining accumulating regional values and then providing the accumulating regional metric map 502 for a population of provider devices within a distance radius of a particular region.
The regional accumulation system 102 can also reduce computational resources by generating the accumulating regional metric map 502 at a server device and then transmitting the accumulating regional metric map 502 to the provider device 500. For example, the regional accumulation system 102 can determine accumulating metric values (and corresponding regions) of the accumulating regional metric map 502, flatten the information to a single digital image (e.g., an image of different fog areas outlining the regions and values), compress the digital image, and ship the digital image to a plurality of provider devices. The provider devices can then fetch the digital image (e.g., of the regional fog areas indicating different accumulating regional metrics) and provide the digital image as an overlay to an underlying street map.
In response to determining that the provider device 500 is online within a region with an accumulating regional metric, the regional accumulation system 102 can determine an accumulating regional metric for the provider device 500. Specifically, the regional accumulation system 102 can determine the accumulating regional metric for the provider device 500 according to an accumulating regional metric indicated within an accumulating regional metric pin of a region in which the provider device 500 is located. To illustrate, in response to determining that the provider device 500 enters the fourth region corresponding to the fourth region marker 504d, the regional accumulation system 102 can determine the accumulating regional metric equal to a value indicated by the first accumulating regional metric pin 506a (e.g., $8).
In one or more embodiments, the accumulating regional metric pin for each region displays an exact value of the accumulating regional metric for the region. Accordingly, if the accumulating regional metric has a value of “8,” the corresponding accumulating regional metric pin can display “8.” In alternative embodiments, the regional accumulation system 102 can determine values for the accumulating regional metric pins that are different than the accumulating regional metrics (e.g., by rounding the accumulating regional metrics down to the nearest integer.) Thus, if the accumulating regional metric for a region is “8.35,” the regional accumulation system 102 can round the value of the accumulating regional metric pin down to 8 and display the accumulating regional metric pin at the provider device 500 with the rounded value. In some embodiments, the regional accumulation system 102 can thus determine a value for an accumulating regional metric pin for a plurality of sub-regions between a first value (e.g., “8” to “9”) and then display the lower value for the accumulating regional metric pin.
In one or more embodiments, the regional accumulation system 102 applies a time threshold to accumulating regional metrics for regions. For example, the regional accumulation system 102 can determine an accumulating regional metric for a region and then cause the provider device 500 to display an accumulating regional metric pin with a value based on the accumulating regional metric. The regional accumulation system 102 can apply the time threshold (e.g., by freezing the accumulating regional metric) to the accumulating regional metric to maintain the value of the accumulating regional metric pin at the same accumulating regional metric until at least a certain amount of time passes to prevent rapidly changing values of accumulating regional metric pins displayed to provider devices. Additionally, the regional accumulation system 102 can update an accumulating regional metric in response to a provider device entering the region and after applying the accumulating regional metric to the provider device. In some embodiments, the regional accumulation system 102 continuously updates accumulating regional metrics for regions until the provider device 500 displays an accumulating regional metric pin for a region. The regional accumulation system 102 can then apply the time threshold only in response to the provider device 500 displaying the accumulating regional metric pin.
In some embodiments, the regional accumulation system 102 also applies a minimum accumulating regional metric threshold for displaying region markers and corresponding accumulating regional metric pins. For instance, the regional accumulation system 102 utilizes the minimum accumulating regional metric threshold to filter out regions that do not have accumulating regional metrics above the threshold. In one or more embodiments, the regional accumulation system 102 determines the minimum accumulating regional metric threshold based on historical data associated with responses of provider devices to marked regions.
According to one or more embodiments, the regional accumulation system 102 also modifies the accumulating regional metric map 502 in response to a change in position or zoom level within the provider application. To illustrate, in response to an input to zoom in on the accumulating regional metric map 502, the provider device 500 can update the accumulating regional metric map 502. Updating the accumulating regional metric map 502 can involve the regional accumulation system 102 modifying one or more clusters associated with accumulating regional metric pins. Specifically, the regional accumulation system 102 can subdivide a region into a plurality of subdivisions with a plurality of different accumulating regional metric pins based on the zoom level. The regional accumulation system 102 can update the accumulating regional metric pin values and locations according to the subdivisions.
Similarly, the regional accumulation system 102 can combine regions by utilizing a clustering model to generate a combined cluster of regions in response to zooming out on the accumulating regional metric map 502. For instance, the regional accumulation system 102 can combine a plurality of regions with different accumulating regional metric pin values. In such cases, the regional accumulation system 102 can display a single accumulating regional metric pin for the combined region with a single value. To illustrate, the regional accumulation system 102 can display the lowest accumulating regional metric of the plurality of regions initially. As the provider device 500 moves into the region, the regional accumulation system 102 can provide more detailed information to the provider device 500 with more accurate accumulating regional metric pin values.
The regional accumulation system 102 can provide a variety of user interface elements illustrating notifications or guidance related to accumulating regional metric maps and accumulating regional values. For example, the regional accumulation system 102 can provide notifications/guidance prompting a provider device to drive to a region (with an indication of the corresponding accumulating regional values available in the region). Similarly, the regional accumulation system 102 can provide notifications when an accumulating regional metric has been attributed to the provider device.
In response to the provider device 500 entering into a region with an accumulating regional metric or going online, the regional accumulation system 102 can apply the accumulating regional metric to the provider device 500.
After the regional accumulation system 102 determines an accumulating regional metric for a provider device, the regional accumulation system 102 can apply the accumulating regional metric to the next transportation request fulfilled by the provider device. As illustrated in
Furthermore,
After the provider device 500 completes the transportation request, the regional accumulation system 102 can apply the accumulating regional metric to a transportation value associated with the transportation request. For example, the regional accumulation system 102 can add the accumulating regional metric to the transportation value of the transportation request. By providing accumulating regional metrics to provider devices in connection with the provider devices moving through regions of high demand, the regional accumulation system 102 can incentivize provider devices to go online and become available for transportation requests. In some embodiments, the regional accumulation system 102 applies accumulating regional metrics to transportation matches only if the provider devices remain online between obtaining the accumulating regional metric and fulfilling a transportation request.
In one or more embodiments, the regional accumulation system 102 determines a final accumulating regional metric to apply to a transportation match based on an initial accumulating regional metric corresponding to a location/movement of a provider device. In additional embodiments, the regional accumulation system 102 determines the final accumulating regional metric as a higher value of an initial accumulating regional metric corresponding to a provider device location/movement and a value based on a location of a requester device. In alternative embodiments, the regional accumulation system 102 determines the final accumulating regional metric as a higher value of an initial accumulating regional metric based on a provider device location/movement and a midpoint (e.g., average value) associated with a requester device location.
In additional embodiments, the regional accumulation system 102 determines a final accumulating regional metric for a provider device from a plurality of accumulating regional metrics associated with movement of the provider device. For example, the regional accumulation system 102 can detect that a provider device passes through a plurality of regions with accumulating regional metrics. The regional accumulation system 102 can determine the final accumulating regional metric for the provider device based on a highest value of the accumulating regional metrics of the regions through which the provider device moved.
According to real-world experimental results performed by experimenters, the regional accumulation system 102 provides improved network coverage via the use of accumulating regional metrics. For instance, the table below illustrates differences in network coverage results over a time period for a plurality of areas. In particular, as shown, the regional accumulation system 102 provides improved network coverage for most areas by increasing the number of provider devices going online (e.g., converting from P0-to-P1) as a result of the accumulating regional metrics. Additionally, the results indicate increased usage of client applications at the provider devices.
In addition, the experimental results indicated that by utilizing accumulating regional metrics, the regional accumulation system 102 increased network coverage most significantly during times of undersupply (e.g., when the number of provider devices available is insufficient to fulfill the number of forecasted transportation requests for one or more regions). Specifically, the experimental results indicated that the provider time increased by as low as <1% during times of oversupply and by up to 9% during times of undersupply. Accordingly, by utilizing accumulating regional metrics, the regional accumulation system 102 provides improved network coverage when most needed across various regions.
Turning now to
As shown in
Act 602 can involve determining that accumulating regional metrics corresponding to the plurality of accumulating metric pins meet an accumulating metric threshold. Act 602 can further involve displaying the plurality of accumulating metric pins within the accumulating regional metric map in response to the accumulating regional metrics meeting the accumulating metric threshold. Act 602 can also involve determining a placement location for an accumulating metric pin of the plurality of accumulating metric pins based on a size or a shape of a combined region for a subset of regions of the plurality of regions.
Act 602 can involve determining an accumulating cluster metric for a subset of the plurality of regions utilizing a clustering model based on accumulating regional metrics for the plurality of regions during a time period. Act 602 can also involve providing an accumulating cluster pin for the subset of the plurality of regions with the accumulating cluster metric within the accumulating regional metric map. For example, act 602 can involve generating an accumulating metric pin of the plurality of accumulating metric pins corresponding to the first region and an additional region adjacent to the first region based on the cumulative events metric for the first region and an additional cumulative events metric for the additional region. Act 602 can then involve determining a placement location for the accumulating metric pin based on a size and a position of a combined region comprising the first region and the additional region.
Act 602 can also involve determining that a size or a shape of the subset of the plurality of regions does not meet a threshold size or a threshold shape. Act 602 can involve recursively dividing the subset of the plurality of regions into a plurality of subdivisions until a particular subdivision of the plurality of subdivisions meets the threshold size or the threshold shape. Act 602 can further involve providing subdivision accumulating metric pins for the plurality of subdivisions within the accumulating regional metric map.
Act 602 can also involve determining that a centroid of the subset of the plurality of regions is located outside a boundary of the subset of the plurality of regions. For example, act 602 can involve determining that a centroid of the combined region is outside a boundary of the combined region. Act 602 can then involve placing, within the boundary of the subset of the plurality of regions, the accumulating cluster pin at a position based on distances from edges of the subset of the plurality of regions. For example, act 602 can involve determining a pole of inaccessibility based on distances from edges of the combined region within the boundary of the combined region. Act 602 can then involve determining the placement location for the accumulating metric pin at the pole of inaccessibility.
Furthermore, the series of acts 600 can include generating estimated request conversion scores for the plurality of transportation requests during the time period relative to the plurality of regions based on the locations of the plurality of transportation requests. The series of acts 600 can then include determining the accumulating regional metric for the provider device based on the estimated request conversion scores and the cumulative events metrics.
Act 602, or an additional act, can also involve generating the plurality of accumulating metric pins according to the cumulative events metrics and a plurality of accumulating regional metrics for the plurality of regions during the time period. The series of acts 600 can include placing the plurality of accumulating metric pins within corresponding regions of the accumulating regional metric map.
The series of acts 600 also includes an act 604 of monitoring movement of the provider device to a first region. For example, act 604 involves monitoring movement of the provider device to a first region of the plurality of regions. Act 604 can involve obtaining provider device location data from a location sensor of the provider device. Act 604 can involve determining that the provider device enters the first region.
Additionally, the series of acts 600 includes an act 606 of determining an accumulating regional metric for the provider device. For example, act 606 involves determining an accumulating regional metric for the provider device corresponding to an accumulating metric pin of the first region. Act 606 can involve determining the accumulating regional metric for the provider device utilizing a geospatial smoothing model in connection with a subset of cumulative events metrics corresponding to a plurality of neighboring regions comprising the first region. For example, act 606 can involve utilizing a geospatial smoothing model to determine a contribution of a plurality of cumulative events metrics for a plurality of adjacent regions based on relative predicted conversion probabilities of a set of transportation requests in the plurality of adjacent regions.
Act 606 can involve determining that the provider device moves to an additional region of the plurality of regions. Act 606 can also involve determining that the accumulating regional metric corresponding to the accumulating metric pin of the first region is greater than an additional accumulating regional metric corresponding to an additional accumulating regional metric pin of the additional region. Act 606 can involve selecting the accumulating regional metric corresponding to the accumulating metric pin of the first region for the provider device.
The series of acts 600 can include determining locations of a plurality of transportation requests within the first region for a time period. The series of acts 600 can include generating a cumulative events metric for the first region during the time period based on the locations of the plurality of transportation requests. The series of acts 600 can also include generating estimated request conversion scores for the plurality of transportation requests during the time period. Act 606 can then involve determining the accumulating regional metric for the provider device based on the cumulative events metric for the first region and the estimated request conversion scores.
As part of act 602, or as an additional act, the series of acts 600 include determining a plurality of transportation requests and corresponding locations of the plurality of transportation requests across the plurality of regions for a time period. The series of acts 600 also include generating cumulative events metrics for the plurality of regions during the time period based on plurality of transportation requests and the corresponding locations of the plurality of transportation requests relative to the plurality of regions. Act 606 can then involve determining the accumulating regional metric for the provider device based on the cumulative events metrics for the plurality of regions.
For example, the series of acts 600 can involve generating a cumulative events metric for the first region based on a plurality of transportation requests within the first region for a time period. The series of acts 600 can also involve generating additional cumulative events metrics for additional regions within a proximity of the first region. Act 606 can involve determining the accumulating regional metric for the provider device based on the cumulative events metric for the first region. Act 606 can also involve determining the accumulating regional metric for the provider device based further on the additional cumulative events metrics for the additional regions according to a geospatial smoothing model.
The series of acts 600 further includes an act 608 of providing a transportation match notification including the accumulating regional metric to the provider device. For example, act 608 involves, based on generating a transportation match between the provider device and a requester device located in a second region different from the first region, providing a transportation match notification to the provider device that comprises the accumulating regional metric.
Act 608 can involve generating the transportation match for the provider device involving a transportation request associated with the requester device after determining the accumulating regional metric for the provider device. Act 608 can also involve modifying a transportation provider metric associated with the transportation request based on the accumulating regional metric.
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. Computer-readable media that store computer-executable instructions are non-transitory computer-readable storage media (devices). Computer-readable media that carry computer-executable instructions are transmission media. Thus, by way of example, and not limitation, embodiments of the disclosure can comprise at least two distinctly different kinds of computer-readable media: non-transitory computer-readable storage media (devices) and transmission media.
Non-transitory computer-readable storage media (devices) includes RAM, ROM, EEPROM, CD-ROM, solid state drives (“SSDs”) (e.g., based on RAM), Flash memory, phase-change memory (“PCM”), other types of memory, other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer.
A “network” is defined as one or more data links that enable the transport of electronic data between computer systems and/or generators and/or other electronic devices. When information is transferred, or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer, the computer properly views the connection as a transmission medium. Transmissions media can include a network and/or data links which can be used to carry desired program code means in the form of computer-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer. Combinations of the above should also be included within the scope of computer-readable media.
Further, upon reaching various computer system components, program code means in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to non-transitory computer-readable storage media (devices) (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface generator (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 one or more 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 marketing 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 marketing features or acts described above. Rather, the described marketing features and acts are disclosed as example forms of implementing the claims.
Those skilled in the art will appreciate that the disclosure may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, 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 generators 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 subscription 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 subscription 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 subscription model can also expose various service subscription models, such as, for example, Software as a Service (“SaaS”), a web service, Platform as a Service (“PaaS”), and Infrastructure as a Service (“IaaS”). A cloud-computing subscription model can also be deployed using different deployment subscription 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.
As shown in
In particular embodiments, the processor(s) 702 includes hardware for executing instructions, such as those making up a computer program. As an example, and not by way of limitation, to execute instructions, the processor(s) 702 may retrieve (or fetch) the instructions from an internal register, an internal cache, memory 704, or a storage device 706 and decode and execute them.
The computing device 700 includes the memory 704, which is coupled to the processor(s) 702. The memory 704 may be used for storing data, metadata, and programs for execution by the processor(s). The memory 704 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 704 may be internal or distributed memory.
The computing device 700 includes the storage device 706 for storing data or instructions. As an example, and not by way of limitation, the storage device 706 can include a non-transitory storage medium described above. The storage device 706 may include a hard disk drive (“HDD”), flash memory, a Universal Serial Bus (“USB”) drive or a combination these or other storage devices.
As shown, the computing device 700 includes one or more I/O interfaces 708, which are provided to allow a user to provide input to (such as user strokes), receive output from, and otherwise transfer data to and from the computing device 700. These I/O interfaces 708 may include a mouse, keypad or a keyboard, a touch screen, camera, optical scanner, network interface, modem, other known I/O devices or a combination of such I/O interfaces 708. The touch screen may be activated with a stylus or a finger.
The I/O interfaces 708 may include one or more devices for presenting output to a user, including, but not limited to, a graphics engine, a display (e.g., a display screen), one or more output drivers (e.g., display drivers), one or more audio speakers, and one or more audio drivers. In certain embodiments, I/O interfaces 708 are configured to provide graphical data to a display for presentation to a user. The graphical data may be representative of one or more graphical user interfaces and/or any other graphical content as may serve a particular implementation.
The computing device 700 can further include a communication interface 710. The communication interface 710 can include hardware, software, or both. The communication interface 710 provides one or more interfaces for communication (such as, for example, packet-based communication) between the computing device and one or more other computing devices or one or more networks. As an example, and not by way of limitation, communication interface 710 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 700 can further include the bus 712. The bus 712 can include hardware, software, or both that connects components of computing device 700 to each other.
This disclosure contemplates any suitable network 804. As an example, and not by way of limitation, one or more portions of the network 804 may include an ad hoc network, an intranet, an extranet, a virtual private network (“VPN”), a local area network (“LAN”), a wireless LAN (“WLAN”), a wide area network (“WAN”), a wireless WAN (“WWAN”), a metropolitan area network (“MAN”), a portion of the Internet, a portion of the Public Switched Telephone Network (“PSTN”), a cellular telephone network, or a combination of two or more of these. The network 804 may include one or more networks 804.
Links may connect the client device 806, the transportation matching system 802, and the vehicle subsystem 808 to the network 804 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 the network environment 800. One or more first links may differ in one or more respects from one or more second links.
In particular embodiments, the client device 806 may be an electronic device including hardware, software, or embedded logic components or a combination of two or more such components and capable of carrying out the appropriate functionalities implemented or supported by the client device 806. As an example, and not by way of limitation, a client device 806 may include any of the computing devices discussed above in relation to
In particular embodiments, the client device 806 may include a transportation service application or a web browser, such as MICROSOFT INTERNET EXPLORER, GOOGLE CHROME or MOZILLA FIREFOX, and may have one or more add-ons, plug-ins, or other extensions, such as TOOLBAR or YAHOO TOOLBAR. A user at the client device 806 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 806 one or more Hyper Text Markup Language (“HTML”) files responsive to the HTTP request. The client device 806 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, the transportation matching system 802 may be a network-addressable computing system that can host a ride share transportation network. The transportation matching system 802 may generate, store, receive, and send data, such as, for example, user-profile data, concept-profile data, text data, ride request data, GPS location data, provider data, requester data, vehicle data, or other suitable data related to the ride share transportation network. This may include authenticating the identity of providers and/or vehicles who are authorized to provide ride services through the transportation matching system 802. In addition, the transportation service system may manage identities of service requesters such as users/requesters. In particular, the transportation service system may maintain requester data such as driving/riding histories, personal data, or other user data in addition to navigation and/or traffic management services or other location services (e.g., GPS services).
In particular embodiments, the transportation matching system 802 may manage ride matching services to connect a user/requester with a vehicle and/or provider. By managing the ride matching services, the transportation matching system 802 can manage the distribution and allocation of vehicle subsystem resources and user resources such as GPS location and availability indicators, as described herein.
The transportation matching system 802 may be accessed by the other components of the network environment 800 either directly or via network 804. In particular embodiments, the transportation matching system 802 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, the transportation matching system 802 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 the client device 806 or the transportation matching system 802 to manage, retrieve, modify, add, or delete, the information stored in data storage.
In particular embodiments, the transportation matching system 802 may provide users with the ability to take actions on various types of items or objects, supported by the transportation matching system 802. As an example, and not by way of limitation, the items and objects may include ride share networks to which users of the transportation matching system 802 may belong, vehicles that users may request, location designators, computer-based applications that a user may use, transactions that allow users to buy or sell items via the service, interactions with advertisements that a user may perform, or other suitable items or objects. A user may interact with anything that is capable of being represented in the transportation matching system 802 or by an external system of a third-party system, which is separate from the transportation matching system 802 and coupled to the transportation matching system 802 via the network 804.
In particular embodiments, the transportation matching system 802 may be capable of linking a variety of entities. As an example, and not by way of limitation, the transportation matching system 802 may enable users to interact with each other or other entities, or to allow users to interact with these entities through an application programming interfaces (“API”) or other communication channels.
In particular embodiments, the transportation matching system 802 may include a variety of servers, sub-systems, programs, modules, logs, and data stores. In particular embodiments, the transportation matching system 802 may include one or more of the following: a web server, action logger, API-request server, relevance-and-ranking engine, content-object classifier, notification controller, action log, third-party-content-object-exposure log, inference module, authorization/privacy server, search module, advertisement-targeting module, user-interface module, user-profile store, connection store, third-party content store, or location store. The transportation matching system 802 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, the transportation matching system 802 may include one or more user-profile stores for storing user profiles. A user profile may include, for example, biographic information, demographic information, behavioral information, social information, or other types of descriptive information, such as work experience, educational history, hobbies or preferences, interests, affinities, or location.
The web server may include a mail server or other messaging functionality for receiving and routing messages between the transportation matching system 802 and one or more client devices 806. An action logger may be used to receive communications from a web server about a user's actions on or off the transportation matching system 802. 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 the client device 806. Information may be pushed to the client device 806 as notifications, or information may be pulled from the client device 806 responsive to a request received from the client device 806. Authorization servers may be used to enforce one or more privacy settings of the users of the transportation matching system 802. A privacy setting of a user determines how particular information associated with a user can be shared. The authorization server may allow users to opt in to or opt out of having their actions logged by the transportation matching system 802 or shared with other systems, such as, for example, by setting appropriate privacy settings. Third-party-content-object stores may be used to store content objects received from third parties. Location stores may be used for storing location information received from the client devices 806 associated with users.
In addition, the vehicle subsystem 808 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 808 can include an autonomous vehicle—i.e., a vehicle that does not require a human operator. In these embodiments, the vehicle subsystem 808 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 808 may include one or more sensors incorporated therein or associated thereto. For example, sensor(s) can be mounted on the top of the vehicle subsystem 808 or else can be located within the interior of the vehicle subsystem 808. In certain embodiments, the sensor(s) can be located in multiple areas at once—i.e., split up throughout the vehicle subsystem 808 so that different components of the sensor(s) can be placed in different locations in accordance with optimal operation of the sensor(s). In these embodiments, the sensor(s) can include a LIDAR sensor and an inertial measurement unit (“IMU”) including one or more accelerometers, one or more gyroscopes, and one or more magnetometers. The sensor suite can additionally or alternatively include a wireless IMU (“WIMU”), one or more cameras, one or more microphones, or other sensors or data input devices capable of receiving and/or recording information relating to navigating a route to pick up, transport, and/or drop off a requester.
In particular embodiments, the vehicle subsystem 808 may include a communication device capable of communicating with the client device 806 and/or the transportation matching system 802. For example, the vehicle subsystem 808 can include an on-board computing device communicatively linked to the network 804 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.
