WO2019203805A1

WO2019203805A1 - Filtering for efficient routing data

Info

Publication number: WO2019203805A1
Application number: PCT/US2018/027928
Authority: WO
Inventors: Alexander Balva
Original assignee: Ford Global Technologies, Llc
Priority date: 2018-04-17
Filing date: 2018-04-17
Publication date: 2019-10-24

Abstract

Systems and methods are disclosed for efficient rideshare routing by removing redundant data and latency issues using a server-side filter. The method to configure a system and a system so configured include steps to receive a request for a trip. A determination is made for route offerings for the trip based at least in part on a time to complete the trip. Profile information associated with the request is accessed. A filtering action, using the profile information and using a filter at a location remote from an origin of the request, is performed for the route offerings based at least in part on restrictions from the profile information to provide filtered route offerings. Portions from the filtered route offerings are provided as computer-readable instructions in response to the request.

Description

FILTERING FOR EFFICIENT ROUTING DATA

BACKGROUND

[0001] Rideshares are an increasingly popular option over traditional vehicle ownership. A rideshare may involve one or more riders - not necessarily known to each other - sharing an allocated vehicle to one or more destinations. While individually allocated cars may be beneficial in certain circumstances, rideshares may provide more cost efficiency with reliable certainty on scheduling. Often, to pass such cost efficiencies to consumers, utilization of rideshare vehicles is monitored and improved. When determining a vehicle to assign for a particular ride or route, approaches look to the vehicles that are available at that time and provide multiple options for selection. Such an approach can be less than optimal and require high data usage for mobile devices and high data buffering locally and on the server side.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Various embodiments in accordance with the present disclosure will be described with reference to the drawings, in which:

[0003] FIGS. 1 A, 1B, and 1C illustrate an example ride request environment in which various embodiments can be implemented.

[0004] FIGS. 2 A and 2B illustrate example origin and destination locations, and routes for serving those locations, that can be determined for a service area over a period of time in accordance with various aspects of this disclosure.

[0005] FIG. 3 illustrates example data units generated to comprise route offerings and filtering of the route offerings using system criteria and profile information, in accordance with various embodiments.

[0006] FIGS. 4 A, 4B, 4C, and 4D illustrate example systems, including interface on the user’s side, utilizing the efficient routing data according to aspects of this disclosure.

[0007] FIGS. 5 A and 5B illustrate example systems that can be utilized to implement aspects of the various embodiments.

[0008] FIG. 6 illustrates an example process of filtering for efficient routing data in accordance with various embodiments.

[0009] FIGS. 7 A, 7B, and 7C illustrate example request and capacity data that can be provided in accordance with various embodiments.

[0010] FIGS. 8 A, 8B, 8C, and 8D provide approaches for proactively positioning capacity based upon anticipated demand that can be utilized in accordance with various embodiments.

[0011] FIG. 9 illustrates an example computing device that can be utilized to submit trip requests and receive route options in accordance with various embodiments.

[0012] FIG. 10 illustrates example components of a computing device that can be utilized to implement aspects of the various embodiments.

DETAILED DESCRIPTION

[0013] In the following description, various embodiments will be described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will also be apparent to one skilled in the art that the embodiments may be practiced without the specific details. Furthermore, well-known features may be omitted or simplified in order not to obscure the embodiment being described.

[0014] Approaches described and suggested herein relate to the providing of transportation in response to various requests. In particular, various aspects are provided, including systems and methods to configure systems, for efficient filtering of routing data. The present disclosure describes a filter placed remote from the requesting device and providing data reduction to provide the best route or routes available for a trip requested by the requesting device. Such an approach can have benefits including filtering out trip or route options that are not practical, for example, as well as to order the remaining options by convenience or another such metric. The convenience of an option might be measured by, for example, one or more objective functions that can optimize for factors such as cost, time, or an amount of walking required, among other such options. In some embodiments a small number (e.g., 3-5) of options can then be presented to a user or entity that provide the most appropriate options for overall user ability or desirability. Such approaches can provide other benefits as well, such as to avoid high data usage and data storage issues in devices with limited capacity. Providing fewer ride options can also allow a router to reduce the state it needs to care for (as in various embodiments it needs to remember all options given) and, most importantly, because each of the ride options provided to the rider may require conditional capacity reservation, eliminates excessive capacity booking and release, which would otherwise be a computationally intensive process.

[0015] In one example, user preferences are stored in a user profile associated with the requesting device. A server receiving a request for the trip generates route offerings including routing information and vehicle information. Filtering is then performed using the user profile information for the multiple users to select at last an appropriate route offering from the available route offerings to provide the multiple users. This process removes redundancies in from providing all the available route offerings to the users, with added benefits of reducing data transmission and data storage requirements. Such approaches may also improve performance of the underlying rideshare application by removing latencies that may exist from data overload. Moreover, the use of the filter located on the server removes from multiple back-and-forth transmissions seeking user inputs and causing delays in the selection or provision of a route offering most appropriate to the users.

[0016] Various other such functions can be used as well within the scope of the various embodiments as would be apparent to one of ordinary skill in the art in light of the teachings and suggestions contained herein.

[0017] FIGS. 1 A, 1B, and 1C illustrate an example environment 100, 120, and 140 in which aspects of the various embodiments can be implemented. In this example, a user can request transportation 100 from an origin to a destination location using, for example, an application 126, 146 executing on a client computing device 132, 152. Various other approaches for submitting requests, such as by messaging or telephonic mechanisms, can be used as well within the scope of the various embodiments. Further, at least some of the requests can be received from, or on behalf of, an object being transported or scheduled to be transported. For example, a client device 120, 140 might be used to submit an initial request for an object, offering, or other deliverable, and then subsequent requests might be received from the object, for example, or a device or mechanism associated with the device. Other communications can be used in place of requests, as may relate to instructions, calls, commands, and other data transmissions. For various embodiments discussed herein a“client device” should not narrowly be construed as a conventional computing device unless otherwise stated, and any device or component capable of receiving, transmitting, or processing data and communications can function as a client device in accordance with various embodiments. Particularly, configuration is provided in software and firmware form for improvements or operations different from conventional computing devices, as described throughout this disclosure.

[0018] The transportation can be provided using a vehicle 100 (or other object) capable of concurrently transporting one or more riders. While riders as used herein will often refer to human passengers, it should be understood that a“rider” in various embodiments can also refer to a non-human rider or passenger, as may include an animal or an inanimate object, such as an offering for delivery. In this example, a rideshare service offers routes using at least one type of vehicle that includes space for a driver 104 and seats or other capacity 102, 106, 108 for up to a maximum number of riders. It should be understood that various types of vehicles can be used with different numbers or configurations of capacity, and that autonomous vehicles without dedicated drivers can be utilized as well within the scope of the various embodiments. Vehicles such as smart bicycles or personal transport vehicles may be used as well, which may include seating capacity for only a single rider or limited number of passengers. For a given vehicle on a given route, a number of available seats 106 (or other rider locations) may be occupied by riders, while another number of seats 108 may be unoccupied. In some embodiments objects such as offerings or deliveries may also occupy available space for a ride as well. In order to improve the economics of the rides offered, at least some embodiments allow occupancy as close to full as possible during the entire length of the trip. Such a situation results in very few unsold seats, which improves operational efficiency. One way to achieve high occupancy might be to offer only fixed routes where all passengers board at a fixed origin location and off-board at a fixed destination location, with no passengers onboarding or off-boarding at intermediate locations.

[0019] In the present example, a given user can enter an origin location 122, 142 and a destination location 124, 144, either manually or from a set of suggested locations 130 that may be available by a predictive analysis of the entered location information. Other such options for input are also available, such as by selecting from a map 128, 148 or other interface element. In other embodiments, the predictive analysis may rely on a machine learning algorithm or artificial intelligence system to propose the appropriate locations based on relevant information, such as historical user activity, current location, and likelihood of an entry being semantically similar to other words in an address database. The semantic similarity process may rely on generation of one or multidimensional vectors and then a spatial analysis using Euclidean or cosine variation to recognize words typically found close to an entered word. The words may include numbers - such as a door numbers, street numbers, etc. Such a system can also be trained using historical ride data constantly updated to the address database, and can learn and improve over time using more recent ride and rider data, among other such options.

[0020] A backend system, or other provider service, can take this information and attempt to match the request with a specific vehicle having capacity at the appropriate time. As known for such purposes, selection of a vehicle may be by the proximity of the vehicle to the origin location at that time of a trip request in order to minimize overhead such as fuel and driver costs, and to provide a feel of on-demand availability. As described previously, the capacity can include a seat for a human rider or sufficient available volume for an offering or object to be transported, among other such measures of capacity.

[0021] In some instances, it may be difficult to get enough users or object providers to agree to be at a specific origin location at a specific time, or within a particular time window, which can lead to relatively low occupancy or capacity utilization, and thus low operational efficiency.

Such an approach, as in the use of application in the manner of Fig. 1C, may result in fewer rides being provided as the data communication delays the specific rideshare selection, and which may reduce overall system efficiency. Further, requiring multiple users to travel to a specific, fixed origin location may cause those users to utilize other means of transportation, as may involve taxis or dedicated rideshare vehicles that do not require the additional effort. Accordingly, embodiments herein factor rider convenience at the server location, via a filter, for the selection of route offerings to be provided to the client or user device 152. What may be convenient for one rider, however, may not be convenient for other riders. For example, picking up one rider in front of his or her house might add an additional stop, and additional route distance, to an existing route that might not be acceptable to the riders already on, or assigned to, that route.

[0022] In addition, different riders may prefer to leave at different times from different locations, as well as to get to their destinations within a maximum allowable amount of time - including detour time for other rides. The interests of the various riders are at least somewhat competing, against each other and those of the ride provider. Therefore, embodiments herein balance the relative experience of the various riders with the economics of the rideshare service for specific rides, routes, or other transportation options using a server-side filter. Such an approach can improve the rider experience in using the application 126, 146, and result in higher ridership levels, which can increase revenue and profit if managed appropriately.

[0023] FIGS. 2 A and 2B illustrate one example approach that can be utilized to provide such service in accordance with various embodiments. In the example mapping 200 of FIG. 2A, a set of origin points 202 and destination points 204 indicate locations, over a determined period of time, between which one or more users would like to travel. As illustrated, there are clusters of locations 206 where users may want to be delivered, or objects are to be delivered, as may correspond to town centers, urban locations, or other regions where a number of different businesses or other destinations are located. The origin locations 202, however, may be less clustered, such as may relate to suburbs or rural areas where rider homes may be located. The clustering can also vary throughout the day, such as where people travel from their homes to their places of employment in the mornings, and generally travel in the reverse directions in the evening. There may be little clustering between these periods, or the clustering may be primarily to locations within an urban area. Economically, it may not be practical for a multi-rider vehicle service to provide each person a dedicated vehicle for the determined route, as the overall occupancy per vehicle would be very low. Ensuring full occupancy for each vehicle, however, can negatively impact the experience of the individual riders who may then have to have longer routes and travel times in order to accommodate the additional riders, which may cause them to select other means of transportation. Similarly, requiring a large number of passengers to meet at the same origin location may be inconvenient for at least some of those passengers, who may then choose alternate travel options.

[0024] Embodiments are described herein to provide routes and transportation options that balance, or at least take into consideration, these and other such factors. As an example, the mapping 250 of FIG. 2B illustrates a selection of routes 252 that can be provided over a period of time in order to satisfy various rider requests. The routes may not include or correspond to each precise origin and destination location, but can come within an acceptable distance of those locations in most instances - so due consideration is made to the desire or ability of users to walk to meet the rideshare. There may be situations where origin or destination locations are not served, or served at particular times, where route options may not be available, although in some embodiments a dedicated, limited capacity vehicle may be offered at a determined price, among other such options. Further, while the routes may not enable every vehicle to have full occupancy, the number of passengers per vehicle can be sufficient to provide at least adequate profitability or efficiency to the ridesharing service. The routes 252, 254 provided by such a service may change over time, or even at different times of day, but can be sufficiently set such that riders can have at least some level of certainty over their commute or travel based on their ability to walk a limited or predefined distance in one or more different directions. While this may not offer the flexibility of other travel options, it can provide certainty of travel at a potentially lower cost point, which can be desirable to many potential users of the service. As mentioned, however, such a service can also provide added flexibility with other ride options, which may come with a higher price to the potential rider. However, providing rideshares based on individual rider preferences filtered at the server removes the multiple notification and input requirement processes, and makes a rideshare system more efficient, convenient, fast, and personalized.

[0025] In order to determine the routes to provide, as well as the vehicles (or types of vehicles) to use to provide those routes, various factors can be considered as discussed and suggested herein. The rideshare system may rely on a grid 254 of coordinate blocks or unique blocks to represent the geographic maps. Thereafter, a line or route 254 through a geographic area may be represented or understood by the rideshare system as vertices of the blocks, shapes formed from the blocks, or lines through the blocks - connecting the blocks of the grid 254. A function of the various factors to provide the routes for multiple users is provided via a filter on the server side that improves customer experience by reducing requirements for multiple inputs from the user.

[0026] The rideshare system may incorporate system criteria for providing generic route offerings based in part on historical trips performed over the same origin and destination locations. However, an optimization approach may be available to reduce the route offerings or offerings using current data that may be updateable over time based on recent ride data, ridership requests, traffic patterns, construction updates, and the like. In some embodiments an artificial intelligence-based approach, as may include machine learning or a trained neural network, for example, can be used to further optimize the route offerings initially generated for each trip. For example, based upon various trends and relationships determined from prior and current data, as discussed elsewhere herein, criteria may be set to combine the route offerings into two or more route offerings without initial concern for user preferences. In an instance of such an application, the combination of the route offerings generates first data that comprises one or more of a starting time, an ending time, a wait time, a detour time, a number of stops, a vehicle type, vehicle occupancy information, and time units associated with traffic for the trip. Such data may then be provided to the client or user device for user selection.

[0027] Approaches in accordance with various embodiments can utilize a further filter function to determine route offerings or options from the first data for a set of vehicles, or other transportation mechanisms, for one or more regions of service or coverage. At least one filter is applied to the above-determined route offerings to determine the route offerings best suitable for users requesting trip and for which the above-determined route offerings were first determined. The filtered route offerings become second data, which reduces redundancies in the system determined route offerings.

[0028] FIG. 3 illustrates example data units 300 generated to comprise route offerings and filtering of the route offerings using system criteria and profile information, in accordance with various embodiments. In Fig. 3, available routes for trips 302 and 304, based in part on user requests are generated. Such available routes for trips 302 and 304 may include TRIP IDs for the respective trip requests - e.g., TRIPID1 and TRIPID2. TRIP ID 1 and TRIPID2 may include respective information for ROUTEIDs available for each TRIP ID. For example, TRIPID1 may be completed using ROUTEID1, ROUTEID2, . . . ROUTEIDN. Each ROUTEID may include reference or relationship to corresponding STOPID and STARTID. In an example, the STOPID and STARTID may be system metrics that may vary from the user requested origin and destination locations. In an alternate implementation, the STARTID and the STOPID are the origin and the destination locations respectively. STARTTIME and ENDTIME them become the proposed times to start and complete respective trips. A LINEID may provide the routing from a separate referenced table for corresponding ROUTEID. For example, the LINEID may be a unique identifier for a combination of blocks or vertices as illustrated in FIG.2B. Instead of a LINEID, a SHAPEID may provide a similar process for uniquely identifying a combination of blocks forming a route under the ROUTEID. The implementation herein also stores the unique identifier underlying the LINEID or SHAPEID, such that the corresponding route may be added to other segments to create a continuous route for on-going rideshare operations after dropping off individual riders.

[0029] From the system-determined route offerings that are generated for each TRIPID, a combination is performed for finding a common route sections or features between TRIPID 1 and TRIPID2 so that one or more ROUTEIDs may be determined as applicable commonly between the two TRIPIDs. As demonstrated in FIG. 3, available routes offerings for TRIPIDs 1 and 2 304 are determined and indexed in TRIPID3 306 based on system criteria from the route offerings 302 and 304. For example, common route sections may be determined used the blocks corresponding to geographical closeness between ROUTIDs from the TRIPIDs. The ROUTEIDs of one TRIPID may reference an indexed table that includes unique identifiers to the blocks, vertices, or lines that define an underlying geographical route. Then the unique identifiers may be sorted and compared to other sorted unique identifiers for other ROUTEIDs of another TRIPID. When more than a threshold number of blocks, vertices, or lines match, the two TRIPIDs are deemed as available for combination in a rideshare. Further, the ROUTEIDs may be combined for to create a single new TRIPDID.

[0030] The available route offerings 306 is based in part the above-references common requirements for trip sections, but may also include a determination of common starting time, an ending time, a wait time, a detour time, a number of stops, a vehicle type, vehicle occupancy information, and/or time units associated with traffic for the TRIPIDs 1 and 2. The available route offerings 306 are referenced as first data herein. In an alternative implementation, the route offerings 306 for TRIPID3 is determined directly without the need for entering information for separate TRIPIDs 1 and 2, therefore saving additional data units in storage and saving additional time to determine route offerings for requested TRIPIDs 1 and 2.

[0031] Redundancies in the available route offerings 306 may refer to excess data units to describe routes to a requested, when the routes include similar cluster of an origin location or similar cluster of a destination location. In an example, the available route offerings 306 include ROUTEID1 and ROUTEIDN, and are indexed as a new trip - TRIPID3 for a driver hosting the requesters of TRIP IDs 1 and 2. A filter with user preferences (from a profile information data store) 308, for one or both requesters of TRIP IDs 1 and 2, is applied to determine which ROUTEID from first data 306 (TRIPID3) meets the filter requirements associated with the requester of TRIPIDs 1 and 2. To meet the filter requirements, the first data is either the same or meets threshold requirements defined in the filter. For example, ROUTEID 1 may be of a different STARTED than that of ROUTEIDN and may require more walking for one or both requesters.

[0032] In an alternative aspect, STOP ID for ROUTEID 1 may require more walking to the destinations defined by TRIPIDs 1 and/or 2. Based in part on the common routes, it may be determined that ROUTEID 1 and ROUTEIDN in TRIPID3 provide reasonable accommodation for TRIPIDs 1 and 2. However, based in part on the filter via profile information 308, it may be determined that ROUTEID 1 is best suited to both requesters as both requesters indicated a preference to walk from a drop-off point to their respective destinations. This is illustrated in the flow of FIG. 3, with the filtered route offering 310 obtained from the filter of profile information 308 for transmission to the requesters. Further, even though filtered route offering 310 is illustrated as a single route offering, multiple route offerings may be provided with variations that are supported in the filter. For example, a variation in preferences of the requesters may require a common filter to include broad allowances for certain factors. As such, multiple route offerings may be provided, but that are still more relevant and including less redundancies than providing all the available route offerings 306 to the requesters. For this reason, the redundant available route offerings are eliminated by the one or more filters. For example, ROUTEIDN may be seen as redundant for including redundant data units - e.g., portions in a respective LINEID of ROUTEIDN to that of ROUTEID 1. A ROUTEIDN is non-preferential and now includes redundant data units in view of the one or more filters, it is not provided to the requesters.

[0033] Such a redundant option may only serve to increase data transmission requirements and data storage requirements to present to the requester an option that is most likely going to be rejected by the user. In an implementation, the filter at the server uses profile information comprising user preferences which may be scored to select from the above-determined routes. This is demonstrated, for example, in the length of walking required to a pickup location in each route determined for two requested trips may be taken into consideration in an open-ended filter. However, the filter may also apply internal limits to the consideration as closed filter. As such, only the route offering filtered in this manner is provided to the user, thereby improving an application that interfaces with the user. For example, such an improvement may be observed in the form of reduced latency and improving the response time - from the user requesting a trip to the system proposing a route offering.

[0034] As such, each of the routes 308, once filtered, to provide filtered route offerings 310, may be scored using a mode statistical requirement - to ensure that there is no bias to an individual user among other users request trips within the route. For example, route offerings, once filtered, provide to the users may not be ranked in any way, but may be the best options available to the users at the present time. This process eliminates the need to perform further filtering on the client device, or may reduce the requirement for further filtering. The reduction or elimination of further filtering significantly reduces data usage in transmission, data usage in storage, and delays caused by latency in round-trip communications while coordinating between multiple users requesting rideshare trips.

[0035] The above filtering can apply not only to particular routes and vehicles, for example, but also to future planned routes, individual riders or offerings, and other such factors. The filter may provide information that is later used for suggestions to the user, during non-use periods, to seek user input to improve filtered route offerings that may then customize subsequent ridesharing requests for the user. As such, the suggestions may be based in part on an overall measure of quality of a previously filtered routing offering provided to the user, or from a set of proposed routing offerings provided to other users sharing a significant portion of a trip with the user. The filter serves as a process to balance various factors of importance to the user and that may not be part of the system criteria. For example, the system criteria may focus more on the drivers and the traffic or route conditions, while the user preference used in the filter may include the rider’s convenience or experience, which may ultimately serve to improve service delivery efficiency for a given area and the quality of service (QoS) compliance for specific trips, among other such options.

[0036] For a number of given origin and destination locations over a given period of time, the filter may be applied and each filtered routing offering given a score, such as an optimized route score, which can be used to filter future routing offerings as part of the system criteria. In some embodiments the routing offerings with the highest route score will be selected for an individual user, but not necessarily among multiple users to prevent bias in routing. In embodiments of use herein, there may be approaches to maximize or minimize the given score, or generate a ranking, among various other scoring, ranking, or selection criteria. Routing offerings with the lowest score may be selected for the filtering in some embodiments. Such routing offerings may also take into consideration a measure of cost, which may be desirable to be as low as possible, versus a factor such as a measure of benefit, which may be more open-ended on the user preferences, irrespective of the cost. In other embodiments, the filtering may not have the optimal score or rank for an individual user, but has an acceptable score - e.g., a mode scoring value or variation - while satisfying one or more other ride user preferences for the individual user. As such, the use of an acceptable score may relate to operational efficiency or minimum rider experience, among others. In one embodiment, the filter accepts, as inputs, the rider’s convenience to walk from an intended location to a system preferred location for the origin or the destination locations. The ability to deliver confirmed trips, the fleet operational efficiency, and the current demand is greatly improved using the filter before relying on inputs for many route offerings provided based solely on the system criteria. In some embodiments, there will be weights attached to each of the locations or user preferences learned over time - such as some preferences being more important than others - such as through machine learning. The factors or data making up each of these terms or value can also change or be updated over time.

[0037] Component metrics, such as the rider’s convenience, QoS compliance, and service delivery efficiency can serve at least two purposes. For example, the metrics can help to determine key performance indicator (KPI) values useful for, in some embodiments, planning service areas and measuring their operational performance. Performance metrics such as KPIs can help to evaluate the success of various activities, where the relevant KPIs might be selected based upon various goals or targets of the particular organization. Various other types of metrics can be used as well. For instance, locations for which to select service deployment can be considered, such as where a service area (e.g, a city) can be selected, and it may be desired to develop or apply a deployment or selection approach that is determined to be optimal, or at least customized for, the particular service area. Further, these metrics can help to provide real-time optimization goals for the routing system, which can be used to propose or select routes for the various requests. The optimization may require the metrics in some embodiments to be calculated for partial data sets for currently active service windows, which may correspond to a fixed or variable period of time in various embodiments.

[0038] As an example, a rider’s convenience score - applicable to inform user preferences in a user profile - can take into account various factors. One factor can be the distance from the rider’s requested origin point to the origin point of the selected route. A scoring process makes this factor measurable so that a filter may be applied without bias. For example, the scoring may be performed using a relevant approach, such as where an exact match is a score of 1.0 and any distance greater than a maximum or specified distance achieves a score of 0.0. The maximum distance may correspond to the maximum distance, defined in the user profile, that a user is willing to walk or travel to an origin location, or the average maximum distance of all users, among other such options. For offerings, this may include the distance that a provider is willing to travel to have those offerings transported to their respective destinations. The function between these factors can vary as well, such as may utilize a linear or exponential function. For instance, in some embodiments an origin location halfway between the requested and proposed origin locations might be assigned a convenience score of 0.5, while in other approaches is might earn 0.3 or less. A similar approach may be taken for time, where the length of time between the requested and proposed pickups can be inversely proportional to the convenience score applied. However, the use of a server side filter is able to account for such inclinations across multiple users by a standardized process that incorporate the user preference inputs from the multiple users. Various other factors may be taken into account as well, as part of the user preference, but more as part of the system criteria as required - including ride length, number of stops, destination time, anticipated traffic, and other such factors. The convenience value itself may be a weighted combination of these and other such factors.

[0039] A filter, as applicable, is configured to include convenience metrics for individual riders to make user preferences measurable over the rider spectrum. As such, riders’

conveniences may be different - some may prefer to walk to an origin, others may prefer to walk to the destination from respective drop-off points. A rider, as per set preferences in the user profile, can help to ensure that trips offered are at least competitively convenient. While rider convenience may be subjective, the metric can look at objective metrics to determine whether the convenience is competitive with respect to other means of transportation available. For example, weather or temperature preferences may affect the preference to walk. An appropriate discount to the distance may be applied via a system criteria over the filter to restrict the walking involved in a route beyond the normal restriction available in the user preference. Any appropriate factors can be considered that can be used in the filter as proposed to a user to determine or calculate variations to system determined route offerings. These factors can include, for example, an ability (or inability) to provide various trip options. The factors can also include a difference in the departure or arrival time with respect to the time(s) requested by the riders for the route. In an aspect of the present ridesharing system, a rider can provide a target time, while in others the riders can provide time windows or acceptable ranges, among other such options. As a result, the riders with user preferences that include a time widow or acceptable range make it easier for other riders with the target time to be included in their rides.

[0040] Another factor that is more a part of the system criteria can relate to the relative trip delay, either as expected or based upon historical data for similar routes. For example certain routes through certain high traffic locations may have variable arrival times, which can be factored into the convenience score. Thereafter, the filter may filter the available routes to remove the high traffic routes for a longer, but more predictable route to arrive by the target time. Another factor may relate to the walking (or non-route travel) required of the user for a given route. This may be, however, part of the user preferences, and may be applied by the filter to system-determined route offerings. Once applied, selected route offerings are based in part on a limited distance between the requested origin and the proposed origin, as well as the distance between the requested destination and the proposed destination. Any walking required to transfer vehicles (as defined by the user preferences) may also be considered if appropriate.

[0041] Various other factors can be considered as well, where the impact on convenience may be difficult to determine but the metrics themselves are relatively straightforward to determine. The use of the user profile including the user preferences may it possible to construct a filter by finding a measureable system across multiple user preferences, across multiple user profiles. For example, if in a single factor - walking - options are provided for distances walkable by a user, the inputs are merely one of the options. As such, a value may be assigned to each option and a statistical measure is derived from the values to measure convenience across the user profiles. In an instance, it is most likely the case that the option within the highest selection is the basic convenience that the users are able to endure. Longer walk options selected will be considered atypical and the system will attempt to reduce longer walks from occurring. A similar measurable process may be applied across all factors, and then a further statistical determination may be performed to determine if some factors affect the other factors. For example, walks to the origin may be more acceptable as convenient than walks at the destination location. As such, a filter built for each user may be more robust using measurable values that previously relied on multiple user communications required at the time of the trip to arrange the trip in the first place.

[0042] Another example of a system criterion may be current planned seating or object capacity utilization for vehicles provided from the rideshare system. While it can be desirable to have full occupancy or capacity utilization from a provider standpoint, riders might be more comfortable if they have some ability to spread out, or if not every seat in the vehicle is occupied. As a result, this specific system criterion may be affected by a filter that removes the route offerings with full capacity utilization in favor of route offerings that have more walking options. This removes a redundant data unit corresponding to the additional route offerings that may offer walk options but also require full capacity. Redundancy as used herein stems from any shared data units - such as route lines, shapes, or blocks that is common between two route offerings, and is not to be confused with fully redundant route offerings that are seen as duplicates, for instance. A user preference for generation of such a filter is provided, but the user options may be converted to measurable quantities based on a valuation across user profiles. However, it may also be the case that certain users are inclined more towards a feature for a less crowded commute than for other features - such as walking and range of arrival times at the destination location. As such, a filter generated for users may include a valuation for a spaced commute that is skewed based on the other measurable factors if the other factors are seen as influencing the present factor. Similarly, while such an approach may not affect the overall ride length, any backtracking or additional stops at a prior location along the route may be frustrating for various riders, such that these factors may be considered in the rider’s convenience, as well as the total number of stops ( e.g detours) and other such factors. Other system criteria such as deviation of a path can also be factored in, but many times it may be preferential to leave this as a filter feature than a system criteria so that there may be benefits to taking a specific path around a location for traffic, toll, or other purposes, but also to reduce frustrating the user in certain circumstances.

[0043] In an aspect of the present disclosure, the filter is able to be adapted in real time to allowances over the user preferences. For example, when it is difficult to support multiple rides simultaneously for a spike in usage, it may be the case that a filter incorporating the spacious commute has to be removed to prevent any route offerings from reaching a requesting rider. The requesting rider may be then informed that the route offering is the best available route offering that is in place because of excessive demand. A discount or credit may be applied in each instance of superseding a part of the user preferences using a specific override to the filter. In an implementation, the override to the filter is provided via a flag asserted as the filter is applied to the route offerings. The flag temporarily removes the effect of a part of the filter to the specific factor determined as at-issue at a particular time of a requested trip.

[0044] Another factor that may be considered with rider convenience metrics in the user preference, but that may be more difficult to measure, is the desirability of a particular location.

In some embodiments a score may be determined based on reviews or feedback of the various riders, among other such options. Various factors can be considered when evaluating the desirability of a location, as may relate to the type of terrain or traffic associated with a spot. For example, a flat location may get a higher score than a location on a steep hill as to user preferences for walking after a drop-off may be affected depending on the topography of the destination. A similar issue is applicable for the origin. Further, the availability, proximity, and type of smart infrastructure can impact the score as well, as locations proximate or managed by smart infrastructure may be scored higher than areas locations without such proximity, as these areas can provide for more efficient and environmentally friendly transport options, among other such advantages. Similarly, a location with little foot traffic might get a higher score than near a busy intersection or street car tracks. In some embodiments a safety metric may be considered, as may be determined based upon data such as crime statistics, visibility, lighting, and customer reviews, among other such options. Various other factors may be considered as well, as may relate to proximity of train lines, retail shops, coffee shops, and the like. In at least some embodiments, a weighted function of these and other factors can be used to determine a rider’s convenience score to affect a filter that can then provide the filtered route offerings.

[0045] Other component metrics that can be utilized in various embodiments relates to the quality of service (QoS) compliance. As mentioned, a QoS compliance or similar metric can be used to ensure that convenience remains uncompromised throughout the delivery of a route offering. There may be various QoS parameters that apply to a given route, and any deviation from those parameters can negatively impact the quality of service determined for the route offering. Some factors may be binary in their impact, such as the cancelation of a trip by the system. A trip is either canceled or performed, at least in part, which can indicate compliance with QoS terms. Modification of a route from the filtered route offering can also impact the QoS compliance score if other aspects of the trip are impacted, such as the arrival time or length of travel. Other factors to be considered are whether the arrival time exceeded the latest committed arrival time, and by how much. The QoS helps determine if the filter requires update that the user is requested to provide if the QoS indicates several deviations from the set user preferences. Further, factors can relate to whether origin or destination locations were reassigned, as well as whether riders had to wait for an excessive period of time at any of the stops. Reassignment of vehicles, overcapacity, vehicle performance issues, and other factors may also be considered when determining the QoS compliance score. In some embodiments the historical performance of a route based on these factors can be considered when proposing filter updates to individual users.

[0046] With respect to service delivery efficiency, which may be a system criterion for the route offerings, the efficiency can be determined for a specific service area (or set of service areas). Such a factor can help to ensure that fleet operations are efficient, at least from a cost or resource standpoint, and can be used to propose or generate different solutions for various principal operational models. The efficiency in some embodiments can be determined based on a combination of vehicle assignment factors, as may related to static and dynamic assignments.

For a static vehicle assignment, vehicles can be committed to a service area for the entire duration of a service window, with labor cost being assumed to be fixed. For dynamic vehicle assignment, vehicles can be brought in and out of service as needed. This can provide for higher utilization of vehicles in service, but can result in a variable labor cost. Such an approach can, however, minimize driving distance and time in service, which can reduce fuel and maintenance costs, as well as wear on the vehicles. Such an approach can also potentially increase complexity in managing vehicles, drivers, and other such resources needed to deliver the service.

[0047] Various factors can be considered with respect to a service efficiency (or equivalent) metric. These can include, for example, rider miles (or other distance) planned by not yet driven, which can be compared with vehicle miles planned but not yet driven. The comparison can provide a measure of seating density. The vehicle miles can also be compared with a measure of “optimal” rider miles, which can be prorated based upon anticipated capacity and other such values. The comparison between vehicle miles and optimal rider miles can provide a measure of routing efficiency. For example, vehicles not only travel along the passenger routes, but also have to travel to the origin location and from the destination location, as well as potentially to and from a parking location and other such locations as part of the service. The miles traveled by a vehicle in excess of the optimal rider miles can provide a measure of inefficiency. Comparing the optimal rider miles to a metric such as vehicle hours, which are planned but not yet drive, can provide a measure of service efficiency. As opposed to simply distance, the service efficiency metric takes into account driver time (and thus salary, as well as time in traffic and other such factors, which reduce overall efficiency. Thus, in at least some embodiments the efficiency metrics can include factors such as the time needed to prepare for a ride, including getting the vehicle ready (cleaning, placing water bottles or magazines, filling with gas, etc.) as well as driving to the origin location and waiting for the passengers to board.

[0048] Similarly, the metric can take into account the time needed to finish the ride, such as to drive to a parking location and park the vehicle, clean and check the vehicle, etc. The efficiency can also potentially take into account other maintenance related factors for the vehicle, such as a daily or weekly washing, interior cleaning, maintenance checks, and the like. The vehicle hours can also be compared against the number of riders, which can be prorated to the planned number of riders over a period of time for a specific service area. This comparison can provide a measure of fleet utilization, as the number of available seats for the vehicle hours can be compared against the number of riders to determine occupancy and other such metrics. These and other values can then be combined into an overall service efficiency metric, using weightings and functions for combining these factors, which can be used to score or rank various options provided using other metrics, such as a system-side convenience or QoS metric. This may be different from the user-side convenience of QoS metric based on user deviation from filter settings that the user provided in their user preferences.

[0049] On the system-side, certain metrics, such as optimal rider miles and optimal distance, can be problematic to use as a measure of efficiency in some situations. For example, relying on the planned or actual distance of trips as a quantization of the quality of service provided can potentially result in degradation in the rider experience. This can result from the fact that requiring the average rider to travel greater distances may result in better vehicle utilization, but can be less optimal for users that shorter trips. Optimization of distance metrics may then have the negative impact of offsetting any gains in service quality metrics. As a result, the filter is used to balance the system-side metrics and the user-side metrics. Approaches in accordance with various embodiments can utilize a metric invariant of the behavior of the routing system if the user-side metrics is unavailable. In some embodiments, the ideal mileage for a requested trip can be computed. This can assume driving a specific type of vehicle from the origin to the destination without any additional stops or deviations. The“optimal” route can then be determined based at least in part upon the predicted traffic or delays at the requested time of the trip for the ideal route. This can then be advantageously used as a measure of the service that is provided.

[0050] An example route determination system can consider trips that are already planned or being planned, as well as trips that are currently in progress. The system can also rely on routes and trips that occurred in the past, for purposes of determining the impact of various options. For trips that are in progress, information such as the remaining duration and distance can be utilized. Using information for planned routes enables the routing system to focus on a part of the service window that can still be impacted, typically going forward in time. For prorated and planned but not yet driven routes, the optimal distance may be difficult to assess directly since the route is not actually being driven. To approximate the optimal distance not yet driven, the routing system can prorate the total optimal distance in some embodiments to represent a portion of the planned distance not yet driven.

[0051] FIGS. 4A, 4B, 4C, and 4D illustrate example systems 400, 420, 440, and 460, including interfaces on the user’s side, utilizing the efficient routing data according to aspects of this disclosure. For example, in contrast to the case of FIGS. 1B and 1C, FIGS. 4A, 4B, and 4C include user interface aspects that are dynamic and accurate, but also faster and with improver information disclosure. For example, a user of the device 410 requests a rideshare by providing the origin in field 412, and the destination in field 414. As in the case of FIGS. 1 A and 1B, such information may be entered manually or may be generated from historical information from prior destinations 416, and from current location via Global Positioning System (GPS), or WiFi® or cellular signal triangulation for field 414. Alternatively, a map 418 is provided for a user to select or drop a pin to choose a destination. FIG. 4B demonstrates an example system 420 of a user device 430 that provides an immediate indication 426 of a portion of a ride offering - e.g., basic arrival information for the requested rideshare to the origin location 422 to take the user to intended destination 424. The map 428 provides information of the current location of the driver hosting the rideshare till the rider is picked up and the provides information as the driver drives to the intended destination. When a selection is made on the portion of the route offering 426, an interface as in system 440 is displayed.

[0052] FIG. 4C provides the user device 450 with an interface including the origin 442 and destination 444, along with additional information from the ride offering 446. Such additional information may include the car information, the driver information, other passenger

information, number of seats available, and may include a graphical representation of the seating chart as the passengers are presented seated. The map 448 continues to display information similar to map 428. In an example implementation, the interface of system 400, 420, and 440 are similar with dynamic changes to only select portions - e.g, the ride offering portions of the interface. This use case enables fast interfacing for ridesharing by removal of redundant data units from transmission or storage requirements.

[0053] FIG. 4D illustrates an example system 4D including user interfaces for providing user preferences 468 to adjust the server side filter for ridesharing in accordance with aspects of this disclosure. A user’s electronic account 462 is provided for access via the client device 470. The user’s electronic account may be used to change user preferences by a selection of soft button 464 or to change user profile setting by selection of soft button 466. In addition section 472 allows the user to change default addresses, such as addresses for work, home, and other often used origins or destinations. Further, the selection of each soft button 464 and 466 causes a section of the interface to clear and causes the display of options specific to the selected soft button. For example CHANGE User Preferences 468 is provided in space of the interface with options and entry fields. As can be readily understood upon review of the present disclosure, the settings in the user preferences determine the final ride offering provided to the user as illustrated in FIG. 4C via text in ride offering section 446.

[0054] The example systems 400, 420, 440, and 460 can be utilized to determine and manage trip requests in accordance with various embodiments. FIG. 5 A demonstrates an example architecture 500 for use with the example systems of FIGS. 4A-D. In this example architecture 500, various users can use applications executing on various types of computing devices 502 to submit trip requests over at least one network 504 to be received by an interface layer 506 of a service provider environment 508. The computing devices 502 can be any appropriate devices known or used for submitting electronic requests, as may include desktop computers, notebook computers, smartphones, tablet computers, and wearable computers, among other such options. The network(s) can include any appropriate network for transmitting the request, as may include any selection or combination of public and private networks using wired or wireless connections, such as the Internet, a cellular data connection, a WiFi connection, a local area network connection (LAN), and the like. The service provider environment can include any resources known or used for receiving and processing electronic requests, as may include various computer servers, data servers, and network infrastructure as discussed elsewhere herein. The interface layer can include interfaces (such as application programming interfaces), routers, load balancers, and other components useful for receiving and routing requests or other

communications received to the service provider environment. The interfaces, and content to be displayed through those interfaces, can be provided using one or more content servers capable of serving content (such as web pages or map tiles) stored in a content repository 412 or other such location.

[0055] Information for the request can be directed to a route or trip manager 510, such as may include code executing on one or more computing resources, configured to manage aspects of routes to be provided using various vehicles of a vehicle pool or fleet associated with the transport service. The route manager 510 can analyze information for the request, determine available planned routes from a route data store 518 that have capacity can match the criteria of the request, and can provide one or more options back to the corresponding device 502 for selection by the potential rider. The appropriate routes to suggest can be based upon various factors, such as proximity to the origin and destination locations of the request, availability within a determined time window, and the like. In some embodiments, an application on a client device 502 may instead present the available options from which a user can select, and the request can instead involve obtaining a seat for a specific trip a specific time.

[0056] As mentioned previously, however, users may also suggest route information or provide information that corresponds to a route that would be desired by the user. While this is more possible on the user preferences option to filter unwanted route offerings, this may be provided as feedback after a trip to improve the filter or automatically update the user preferences. Such feedback can include, for example, an origin location, a destination location, a desired pickup time, and a desired drop-off time. Other values can be provided as well, as may relate to a maximum duration or trip length, maximum number of stops, allowable deviations, and the like. In some embodiments at least some of these values may have maximum or minimum values, or allowable ranges, specified by one or more route criteria. There can also be various rules or policies in place that dictate how these values are allowed to change with various circumstances or situations, such as for specific types of users or locations. The route manager 510 can receive several such requests, and can attempt to determine the best selection of routes to satisfy the various requests.

[0057] In an example the route manager 510 can work with a route generation module 520 that can take the inputs from the various requests and provide a set of route offerings that can satisfy those requests. These may form the first data as available route offerings with current traffic and other conditions considered. Alternatively, this may be a set of all route offerings to which current traffic and other conditions are applied to secure the first data that includes the available router offerings. This can include options with different numbers of vehicles, different vehicle selections or placements, and different options for getting the various customers to their approximate destinations at or near the desired times. At this point a filter may be applied via the route optimization module 522 using user preferences previously provided to the provider environment 508. For example, user preferences may be provided via the content server 514 and may be stored via the account manager module 524 to the user database 532. Customers, via the user preferences, may also request for specific locations and times where deviation is not permissible, and the route manager 510 may either determine filtered routing offerings or may deny that request if minimum criteria in the user preferences are not met. In some embodiments an option can be provided for each request, and a pricing manager 526 can determine the cost for a specific request using pricing data and guidelines from a price repository 528, which the user can then accept or reject.

[0058] In this example, the route generation module 520 can generate a set of route offerings based on the received requests for a specified area over a specified period of time. The route optimization module 522 can perform its filtering and other optimization, if required, to filter the available routes initially provided from route generation 520 to now provide filtered route offerings. The filtered route offerings are an appropriate set of routes to provide in response to the various requests as a rideshare. Such filtering may be performed for each received request or a group of requests, if they are determined as incoming from a same general area. This may be a dynamic routing system, in the alternative, where users submit requests and then receive routing options immediately based on existing routes being detoured to meet the request. This may be useful for situations where the vehicle service attempts to have at least a minimum occupancy of vehicles or wants to provide the user with certainty regarding the route, which may require a quorum of riders for each specific planned route in some embodiments. Various other approaches can be used as well as would be understood to one of ordinary skill in the art in light of the teachings and suggestions contained herein.

[0059] Further, the use of a filter in the service provider environment 508 enables machine learning algorithms to evolve automatically over time to improve the user preferences or to provide variation thresholds so that the user is not confused by any displayable changes to the user preferences not applied by the user. For example, even though the user has provided an ability to walk 100 meters, it may be the case that the user has consistently been picked up at a location less than 100 meters from a desired location, then the 100 meters may be changed during application to 80 meters, by a system variation, but is not disclosed as changed in the user preferences. As may be done using random experimentation or based on various heuristics, other such changes may be effected to best suit the customer’s perception of QoS. As these algorithms evolve, the value of the objective function can serve as a measure of fitness or value of a new generation of algorithms. Algorithms can change over time as the service areas and ridership demands change, as well as to improve given the same or similar conditions. Such an approach may also be used to anticipate future changes and their impact on the service, as well as how the various factors will change. This can help to determine the need to add more vehicles, reposition parking locations, etc. Signals 534 provide the filtered route offerings to select vehicles 536 depending on the computer-readable instructions in the respective filtered route offerings.

Further, the filtered route offerings may be of two versions - one for devices 502 (rider/user-side devices) and one for devices in vehicles 536 (driver-side). The computer-readable instructions render in the application of the client device and a display of portions of the filtered route offerings appears in the application. A selection of the portions retrieves more information for the selected filtered router offering.

[0060] In some embodiments artificial intelligence-inclusive approaches, such as those that utilize machine learning, can be used with the optimization algorithms to further improve the performance over time. For example, the raising and lowering of various factors may result in a change in ridership levels, customer reviews, and the like, as well as actual costs and timing, for example, which can be fed back into a machine learning algorithm to learn the appropriate weightings, values, ranges, or factors to be used with an optimization function. In some embodiments the optimization function itself may be produced by a machine learning process that takes into account the various factors and historical information to generate an appropriate function and evolve that function over time based upon more recent result and feedback data, as the machine learning model is further trained and able to develop and recognize new

relationships.

[0061] Various pricing methods can be used in accordance with the various embodiments, and in at least some embodiments the pricing can be used as a metric for the optimization. For example, the cost factors in some embodiments can be evaluated in combination with one or more revenue or profitability factors. For example, a first ride option might have a higher cost than a second ride option, but might also be able to recognize higher revenue and generate higher satisfaction. Certain routes for dedicated users with few to no intermediate stops might have a relatively high cost per rider, but those riders might be willing to pay a premium for the service. Similarly, the rider experience values generated may be higher as a result. Further, specific user preference settings may be charged differently to the user to discourage or encourage more participation in a rideshare community. Thus, the fact that this ride option has a higher cost should not necessarily have it determined to be a lower value option than others with lower cost but also lower revenue. In some embodiments there can be pricing parameters and options that are factored into the objective function and optimization algorithms as well. Various pricing algorithms may exist that determine how much a route option would need to have charged to the individual riders. The pricing can be balanced with consumer satisfaction and willingness to pay those rates, among other such factors. The pricing can also take into various other factors as well, such as tokens, credits, discounts, monthly ride passes, and the like. In some embodiments there might also be different types of riders, such as customer who pay a base rate and customers who pay a premium for a higher level of service. These various factors can be considered in the evaluation and optimization of the various route options.

[0062] FIG. 5B illustrates an example system 550 similar to that of FIG. 5A, but which includes additional component configured to predict demand and provide for proactive vehicle movement in accordance with various embodiments. In this example, the system can include at least one demand simulation sub-system 590, device, or component, which can attempt to predict demand for a specific service area as discussed and suggested herein. The demand simulator can determine simulation parameters, such as the time of day ( e.g ., a fifteen minute window), a day of the week, a season, and special events or planned occurrences (e.g., construction), which can be used to run the simulation. The simulator 580 can obtain relevant data from a historical demand data repository 588, and can analyze that data using one or more predictive algorithms or processes to predict demand (and potentially other values discussed herein) for that particular time and location. As mentioned, in some embodiments machine learning or a trained model can be used instead, which can accept the time and condition input and provide predicted demand and related values accordingly.

[0063] In some embodiments the demand simulator 580 can provide the prediction information to the route generation and/or optimization components 568, 570, which can utilize this information to determine routing of vehicle based at least in part upon the predicted demand.

This includes proactively moving vehicles, assigning routes and vehicles based on predicted destinations, and the like. In some embodiments this functionality can be injected into an existing system using a false request generator 582, or other such system or service, which can submit user requests corresponding to the predicted demand. This can cause the system to consider the predicted demand when making routing (and other) decisions because these requests will be treated by the system as actual requests. In this example, the route generation module 568 can generate a set of route offerings based on the received and speculative requests for a specified area over a specified period of time. The route generation module 568 can also determine how to change the state of the available capacity as measured by the objective function.

[0064] In some embodiments, the false request generator 582 or other such sub-system can be configured to then cancel the ride at an appropriate time, such as when a cancelation criterion is satisfied, in order to prevent the system from attempting to deliver on the speculative route.

There may be various cancelation criteria utilized, such as may relate to a distance from the speculative route origin location, an amount of time before the start time for the speculative route, a scheduled time, or the receiving of an actual trip request, among other such options. The criteria used can depend at least in part upon the type of location or amount of available capacity, and the values or thresholds for those criteria can be learned or updated dynamically over time, such as by using machine learning or other such approaches. The vehicle can be proactively placed, and then when the route is canceled the system can direct the vehicle to an appropriate, nearby location using other vehicle placement logic already utilized by the system. In some embodiments there can also be a mechanism for ensuring that actual ride requests take priority over these speculative ride requests used for vehicle positioning and other such purposes. For example, a special code or identifier can be used that can cause the request to be treated as low priority, such that other requests or types of routes can take precedence. In other embodiments, the false request generator 582 or route manager 560 can monitor the actual requests, and if necessary can submit a request to cancel the speculative request. Various other options can be utilized as well within the scope of the various embodiments. The routing and placement can also be monitored and updated over time, such as to account for variations in actual demand across the service area. The instructions or information sent from a fleet manager 584 to the various vehicles 594 via signals 592 can, in many cases, be the same as for actual ride requests, while in other embodiments the information may indicate that the route is for proactive placements, such that the driver can be aware that timing and other issues may not be as critical as for other types of requests.

[0065] Projection and analysis, for general route offerings, are useful for a variety of different service areas, which can be quite large in size or may take a significant time to traverse due to traffic or other conditions. In some locations there may be a limited number of parking facilities available for the vehicles for a service provider, such that the proactive positioning may be at least somewhat limited to selecting the optimal parking facility based upon the predictions. In some embodiments where the facilities are far (time or distance wise) from the predicted origin location, there can be various other factors or options considered as well. These can include, for example, paid street parking, employee residence parking, continual driving for autonomous vehicles, and other such options. For options such as paid parking that involve an additional cost, that cost can be figured into the optimization and routing process. In some embodiments it may be more cost effective to not proactively position a vehicle, where the proactive positioning would involve additional cost, driver overtime, etc. Various approaches can attempt to determine a preferable end-to-end solution with a better vehicle rest location based at least in part upon the projected demand.

[0066] In various embodiments an attempt can also be made to maintain a consistency of capacity density over time. For example, in some embodiments the demand is analyzed for periods of time of specific length, such as for 15 minute intervals. Such an approach can mean that there might be four very different demand densities or distributions within a single hour. While it may be desirable to match demand to capacity density, it may not be cost effective to cause some of the vehicles to move up to four times an hour to achieve density matching. Thus, approaches can look to demand density over a period of time and attempt to place vehicles in such a way that, over an extended period of time, the density of capacity may correspond to the density of demand. For example, there might be high demand downtown near the top of the hour as people get off work, but low demand at other times. It may not be practical to move cars in and out of the area every hour based on this fluctuation in demand. Based on cost, however, it may be beneficial to move some of the vehicles from that area if it is anticipated that there will be little demand for the next 45 minutes, and there may be demand in a nearly region. These and other factors can be considered in the optimization and routing approaches, such that the proactive positioning and density matching does not result in excessive vehicle movement and additional cost. Vehicles in many embodiments will only be proactively placed where the benefit justifies the placement, as may be determined using an objective function or other process or algorithm as discussed herein that can take into account metrics such as operational efficiency.

As mentioned, in at least some embodiments there may be minimum distances or benefits required before proactively moving a vehicle as well, as moving a vehicle a couple blocks based on a small fluctuation in predicted demand may not justify the action. Factors such as wear to the vehicle and risk of damage or accidents may also be considered, such that there may need to be at least a minimum amount of benefit predicted before moving any specific vehicle. Every mile that a vehicle drives unoccupied can generate additional cost.

[0067] As described previously, the various destinations and time windows of the predicted demand can be considered as well. For example, a predicted demand on a particular block of nine people does not necessarily mean that a single van with nine available seats should be proactively positioned, as the requested routes may be significantly different and unable to practically be served by a single vehicle. Similarly, it may not be cost effective to proactively position nine different vehicles in that location. Accordingly, the proactive placement and routing can be performed based at least in part upon the predicted number of routes to be required from that location, in addition to the seat density or vehicle density used for proactive placement determinations. Thus, density matching may attempt to place the appropriate seating capacity at a location to match the demand capacity, and provide that seating capacity using an appropriate number and/or type(s) of vehicles predicted to be required for the associated route(s).

[0068] Accordingly, some approaches can attempt to reach an optimal state that corresponds to a“zero” state for a service area, where the density of capacity is equal to the density of demand for a specified period of time, the demand including both actual and predicted demand. Other approaches can attempt to reach an optimal state where vehicles are moved proactively to attempt to match capacity and demand density to the extent that such vehicle movement satisfies criteria such as those discussed elsewhere herein with respect to the objective function and other such approaches. When a vehicle is not actively serving a trip or route, for example, that vehicle can be parked at a nearby location, moved to a location of anticipated future demand, or moved to a determined intermediate location, among other such options, where in at least some embodiments the selected option corresponds to the overall selected routing solution. In some embodiments routing options for vehicles currently serving routes can also take into account the predicted demand when assigning future routes or modifying existing routes, etc.

[0069] When predicting demand, the demand can be expressed as a set of records, where each record can include any of a number of different fields. These fields can include, for example, day of the week, pick up time window, an origin location or identifier, a destination location or identifier, a number of riders, a probability of occurrence, and an average booking lead time, among other such options. In at least some embodiments it can be assumed that the demand records are independent, and predicted demand that fails to materialize will not be carried forward. Further, in at least some embodiments the actual demand in excess of the predicted demand does not reduce the future predicted demand. The predicted demand injection can be performed at the initiation of a service window, for the entire length of the window. A constrained time horizon may be considered for longer service windows in some embodiments. Retraction can be performed immediately before the lead time of the demand record preceding the time interval for which the record has been declared, among other such options. The predictive demand can also be determined stop to stop, as opposed to point to point, where the points can be any identified geographic location. In some embodiments, movement such as walking or other third party transportation may not be considered for predictive placement.

[0070] In some embodiments the filter can be modified or developed to include various factors relating to predictive demand. These can involve new metrics, or factors that make up the various existing metrics of an objective function. For example, with respect to various rider convenience factors, the sensitivity to a time match can be reduced for proactive placement, as well as the penalty for an inability to provide specific trip options relating to proactive placement. A constant walking time can be assumed for the relative trip delay cancelation, as well as a constant length. With respect to the QoS factors, none of these may apply for a proactive placement trip corresponding to a speculative route, except that a penalty for trip calculation may be retained but reduced. The service delivery efficiency factors may still all apply for a proactive placement route. Thus, proactive placements are determined and optimized based much more on operational efficiency metrics than quality of service, since there would be no active riders impacted by the service of the proactive route, unless an occurrence impacts the start of an actual planned route, etc. Many of the other modules in FIG. 5B include functionality previously discussed with respect to FIG. 5A. A person of ordinary skill, upon reading the present disclosure, would understand how modules of FIG. 5A fit within FIG. 5B.

[0071] FIG. 6 illustrates an example process 600 of filtering for efficient routing data in accordance with various embodiments. The example process 600 includes sub-process 602 for receiving a request for a trip. In sub-process 604, a determination is made for route offerings for the trip based at least in part on a time to complete the trip. In sub-process 606, a device of the service provider environment may seek access to profile information associated with the request. When the request is granted, the profile information is accessed to inform or update a filter. In an example, the access is automatic via cookies or pre-authentication protocols, but the access is logged to ensure that a filter that may exist outside the profile information is most up-to-date. Sub-process 610 performs a determination of whether the profile information includes user preference for trips. When no such preferences are found, available route offerings from sub- process 604 is provided to the user. When preferences are found, a check may be performed for existing filters for the profiled information. In an example, the existing filters may be individual to the user (requesting rider) or may be formed from a combination of multiple riders for a previous shared route. A timestamp may be verified by a log that includes information for the previous filter was generated. Alternatively, a new filter is prepared for the individual user or for a grouping of requests. Sub-process 612 filters, using the profile information and at a filter remote from an origin of the request, the route offerings based at least in part on restrictions from the profile information to provide filtered route offerings. Sub-process 614 provides portions from the filtered route offerings as computer-readable instructions in response to the request.

[0072] Various embodiments can further improve or optimize such filtering processes, at least in certain circumstances, by accounting for anticipated demand in various routing

determinations. As mentioned, determining routes and matching vehicles can provide optimal solutions for a specific set of rides or trips. It will often be the case, however, that the placement of vehicles after these rides will be less than optimal for the next set of rides to be provided. As an example, FIG. 7A shows a set of origin locations 702 for future ride requests, and the current locations 704 of vehicles having capacity to serve those ride requests. The future ride requests could all relate to a future time period, or a current demand, among other such options. The locations 704 of the various vehicles could be proximate a last destination location, or could be a location where the vehicle was parked after a last trip or destination, among other such options.

[0073] FIG. 7B illustrates the same distribution 720 of the ride requests, or future demand, and the vehicle locations, or available capacity, but without the map data for purposes of illustration. As illustrated, the locations 704 of the vehicles are somewhat randomly distributed with respect to the origin locations 702. This can result in some of the vehicles having to travel long distances to get to their assigned origin locations, which can result in extra cost and lower utilization as discussed in more detail elsewhere herein. There is thus some inefficiency in the fact that the distribution of demand does not match the distribution of capacity for this point in time. As illustrated, there can be regions 722 of high demand where there is little to no capacity located, such that all vehicles will have to come from outside this location. This can occur in locations such as town centers at afternoon rush hour, for example, where many people are traveling from a small region to destinations scattered about a large region.

[0074] For such situations, however, the efficiency can be improved by anticipating the demand and including the anticipated demand in the routing of the vehicles. This can be improved using at least two different approaches. A first approach involves proactively locating vehicles to locations of anticipated demand. For example, as illustrated in the example distribution 740 of FIG. 7C, the vehicles can be proactively positioned such that the density or distribution of the vehicles over various regions is matched, or similar, to the distribution of the anticipated demand. In this way, the average distance to be traveled, and time to reach the origin location, can be significantly decreased. Further, labor costs can be reduced by, for example, moving the vehicle during a driver shift. If the driver is near the end of his or her shift and the vehicle is to be moved to a specific location, the driver can move the vehicle towards that location towards the end of the shift such that additional cost will not be incurred at the start of the next shift to move the vehicle to the origin. Other factors can be considered as well, however, such as the available parking locations, costs for parking at any of those locations, additional distance or time incurred for driving to those locations, and the like. In this example, the density of demand to capacity in the examined region 722 is much more balanced. Thus, even if the actual demand ends up being slightly off from the anticipated demand, the location of capacity to fill those requests will still be much more conveniently placed. [0075] In order to provide for further optimization, approaches in accordance with various embodiments will consider where vehicles will be located at the end of assigned or planned routes before assigning or proactively positioning those vehicles for upcoming routes. This information can also be considered when analyzing various routing options over a period of time. As an example, FIG. 8A illustrates location data 800 for an example situation wherein ride requests require routes to be taken between two origin locations 802 and two destination locations 804. Using just a proactive positioning approach as discussed previously might result in two available vehicles 806 being positioned proximate the two origin locations 802, such that the vehicles will be able to quickly serve those requests at the appropriate time, and with minimal additional cost and effort. One example solution 820 is illustrated in FIG. 8B, wherein a first vehicle 822 moves proximate a first origin location and follows a route to the relevant destination. A second vehicle 824 performs a similar route for the second destination. In this example, however the locations 826 of origins for two future ride requests is displayed. The routes illustrated in FIG. 8B cause both vehicles to end up a significant distance away from the subsequent origin destinations. When both of those vehicles are then positioned to serve routes for the future requests, each vehicle will end up driving a significant amount of additional time and distance to serve the additional requests. Depending upon the relative timing, this may also end up delaying the start time for the subsequent requests.

[0076] Approaches in accordance with various embodiments attempt to consider and/or predict this future demand when assigning current or planned routes, based at least in part upon where vehicles will be positioned at the end of specific routes. As an example, consider the alternate route solution 840 illustrated in FIG. 8C. In this example, a first vehicle 822 is assigned to the two origin locations 826 for future demand that are at a significant distance, so that only that vehicle has to travel the full distance. This vehicle 822 also avoids the additional distance needed to travel to the location of one of the currently planned routes. The second vehicle 824 can then serve both the current requests, time permitting, where the respective destination locations 804 are relatively close together. This also significantly decreases the distance that the second vehicle will have to travel, as it will not have to travel the long distance to the subsequent origin locations 826. Thus, there can be advantages in not only proactively positioning vehicles based on anticipated demand, but also considering the future locations of vehicles completing specific routes when optimizing and selecting various routing solutions. A goal of such an approach can be to optimize costs, efficiency, and other factors over a lengthy period of time, instead of for a specific point in time, or relatively short period of time. The above information may be taken in to consideration during the system criteria application to generate the available route offerings prior to application of the filter described with respect to other figures in this disclosure.

[0077] FIG. 8D illustrates one example approach for incorporating future capacity and vehicle locations in density matching that can be utilized in accordance with various embodiments. The distribution 860 corresponds to a service area that is broken up into an array of quantized regions. Any appropriate quantization or region selection approach may be utilized, as may be based upon distance, population, average demand, and the like. In this example, open circles represent origin locations for future rides, closed circles represent destinations ending in that region in a prior period of time, and the x markers correspond to vehicles (or seating capacity) in that region at a time of the future demand. In this example, it can be desirable to anticipate the demand in each region, and attempt to get the available capacity as close as possible to the anticipated demand. Excluding costs and other concerns, an ideal optimization might have the available capacity in each region exactly match the anticipated demand. The available capacity for a region can take into account the number of vehicles anticipated to be in that region anyway due to the prior destinations of those vehicles, for example, and can determine the amount of capacity that can be proactively moved into that region. Such an approach can be used with an optimization algorithm to determine a target capacity for each region, as well as a predicted capacity, and within the optimization process attempt to move vehicles proactively to have the availability for the various regions match the capacity. The optimization can also balance various factors, such as whether to prioritize balance across the regions, or deviations from targets within a region, among other such factors. In some embodiments the probability of demand can also be taken into account. For example, if there is a 50% chance that a person will submit a ride request for a specific location at a point in time, then the demand for that location can be set as 0.5 instead of 1.0. The predicted demand across the region can then be an aggregation or statistical combination of these fractional demands.

[0078] In order to determine the anticipated demand for a point in time, approaches in accordance with various embodiments can analyze historical data for requests received, routes served, and other aspects over at least a determined period of time in the past. These values can be decayed, weighted, or otherwise accounted for in such a way that more recent data has more of an impact than data from the distant past, etc. The data can also be analyzed for specific time periods or occurrences, such as days of the week, weekends, seasons, events, rush hours, and the like. For a future period of time, such as 10:00 on a Wednesday in the summer for a specific geographical region with no major events listed, the historical data can be analyzed to predict the demand across that region, as well as other values such as the available capacity, routes in progress, and the like. The historical information in at least some embodiments can also be used to train one or more machine learning models, which can then provide predicted demand for a given time period with a given set of conditions, such as may relate to events occurring at that time and the like. The above implementations may be applied to generate the general router offerings for trips, prior to applying the system criteria, or may be applied to generate the available router offerings prior to applying a filter of the user preferences.

[0079] As an example, the historical data for a service area (i.e., a defined geographical region) can include information about the rides requested, including origin and destination locations, for a specific time period. The historical data may also include information associated with those requests, such as maximum numbers of stopped requested, arrival time windows, and types of vehicles or service requested, among other such request options discussed and suggested herein. The historical data may also include information about the type of rider (human, animal, offering, etc.) and the type or amount of capacity needed to accommodate that rider. The historical data can also include data for the actual demand, including which routes were actually assigned and delivered, including the individual trips or segments, as well as timing and other such information. The historical data can also include performance data, such as the timeliness, number of miles incurred, amount of time incurred, types of vehicles utilized, stop deviations, etc. The historical information can also identify any special conditions to be considered, such as accidents, construction, or event traffic, which may have impacted the potential values in order to determine whether to consider those specific values in the prediction. Historical data can be obtained from any of a number of different sources, such as past data for the particular provider, third party data, user data obtained from cell phones or other mechanisms, etc. [0080] The data can be processed to determine, for example, a predicted amount of demand for each of a set of regions within a service area in some embodiments, or a demand distribution or other such predicted demand mapping in others. This can include information about the predicted location and number of requests, such that an attempt can be made to provide sufficient capacity for each predicted trip. As mentioned, the number of riders can be modified by a likelihood factor, such that if there is a 50% chance of two people submitting requests for a particular area then a demand value of 1.0 (or another statistically determined number) may be used for the capacity demand for that location at that time. In some embodiments this can be based upon an average demand for that location and that period as well, where fractional demand is permissible. For example, an average demand could be calculated at 2.3 people, which could case capacity for 2-3 persons to be proactively moved to (or proximate) that location in at least some

embodiments. For offerings, an overall capacity size as well as an anticipated individual offering size can be utilized, with fractional demand further based in part upon probability of demand. As mentioned, a similar approach can be taken to anticipate the destinations for the predicted demand, which can be used to select routes, assign vehicles, and take other such actions as discussed and suggested herein.

[0081] FIG. 9 illustrates an example computing device 900 that can be used in accordance with various embodiments. Although a portable computing device ( e.g ., a smart phone or tablet computer) is shown, it should be understood that any device capable of receiving, processing, and/or conveying electronic data can be used in accordance with various embodiments discussed herein. The devices can include, for example, desktop computers, notebook computers, smart devices, Internet of things (IoT) devices, video gaming consoles or controllers, wearable computers (e.g., smart watches, glasses, or contacts), television set top boxes, and portable media players, among others. In this example, the computing device 900 has an outer casing 902 covering the various internal components, and a display screen 904 such as a touch screen capable of receiving user input during operation of the device. These can be additional display or output components as well, and not all computing devices will include display screens as known in the art. The device can include one or more networking or communication components 906, such as may include at least one communications subsystem for supporting technologies such as cellular communications, Wi-Fi communications, BLUETOOTH^® communications, and so on. There may also be wired ports or connections for connecting via a land line or other physical networking or communications component.

[0082] FIG. 10 illustrates an example set of components that can comprise a computing device 1000 such as the device described with respect to FIG. 9, as well as computing devices for other purposes such as application servers and data servers. The illustrated example device includes at least one main processor 1002 for executing instructions stored in physical memory 1004 on the device, such as dynamic random-access memory (DRAM) or flash memory, among other such options. As would be apparent to one of ordinary skill in the art, the device can include many types of memory, data storage, or computer-readable media as well, such as a hard drive or solid state memory functioning as data storage 1012 for the device. Application instructions for execution by the at least one processor 1002 can be stored by the data storage 1006 then loaded into memory 1004 as needed for operation of the device 1000. The processor can also have internal memory in some embodiments for temporarily storing data and instructions for processing. The device can also support removable memory useful for sharing information with other devices. The device will also include one or more power components 1010 for powering the device. The power components can include, for example, a battery compartment for powering the device using a rechargeable battery, an internal power supply, or a port for receiving external power, among other such options.

[0083] The computing device may include, or be in communication with, at least one type of display element 1008, such as a touch screen, organic light emitting diode (OLED), or liquid crystal display (LCD). Some devices may include multiple display elements, as may also include LEDs, projectors, and the like. The device can include at least one communication or networking component 1006, as may enable transmission and receipt of various types of data or other electronic communications. The communications may occur over any appropriate type of network, such as the Internet, an intranet, a local area network (LAN), a 5G or other cellular network, or a Wi-Fi network, or can utilize transmission protocols such as BLUETOOTH^® or NFC, among others. The device can include at least one additional input device 1014 capable of receiving input from a user or other source. This input device can include, for example, a button, dial, slider, touch pad, wheel, joystick, keyboard, mouse, trackball, camera, microphone, keypad, or other such device or component. Various devices can also be connected by wireless or other such links as well in some embodiments. In some embodiments, a device might be controlled through a combination of visual and audio commands, or gestures, such that a user can control the device without having to be in contact with the device or a physical input mechanism.

[0084] Much of the functionality utilized with various embodiments will be operated in a computing environment that may be operated by, or on behalf of, a service provider or entity, such as a rideshare provider or other such enterprise. As noted in prior aspect, as used herein rideshare may apply to bicycles, motorbikes, and other vehicles with one rider or more than one rider. There may be dedicated computing resources, or resources allocated as part of a multi- tenant or cloud environment. The resources can utilize any of a number of operating systems and applications, and can include a number of workstations or servers Various embodiments utilize at least one conventional network for supporting communications using any of a variety of commercially-available protocols, such as TCP/IP or FTP, among others. As mentioned, example networks include for example, a local area network, a wide-area network, a virtual private network, the Internet, an intranet, and various combinations thereof. The servers used to host an offering such as a ridesharing service can be configured to execute programs or scripts in response requests from user devices, such as by executing one or more applications that may be implemented as one or more scripts or programs written in any appropriate programming language. The server(s) may also include one or more database servers for serving data requests and performing other such operations. The environment can also include any of a variety of data stores and other memory and storage media as discussed above. Where a system includes computerized devices, each such device can include hardware elements that may be electrically coupled via a bus or other such mechanism. Example elements include, as discussed previously, at least one central processing unit (CPU), and one or more storage devices, such as disk drives, optical storage devices and solid-state storage devices such as random access memory (RAM) or read-only memory (ROM), as well as removable media devices, memory cards, flash cards, etc. Such devices can also include or utilize one or more computer-readable storage media for storing instructions executable by at least one processor of the devices. An example device may also include a number of software applications, modules, services, or other elements located in memory, including an operating system and various application programs. It should be appreciated that alternate embodiments may have numerous variations from that described above.

[0085] Various types of non-transitory computer-readable storage media can be used for various purposes as discussed and suggested herein. This includes, for example, storing instructions or code that can be executed by at least one processor for causing the system to perform various operations. The media can correspond to any of various types of media, including volatile and non-volatile memory that may be removable in some implementations.

The media can store various computer readable instructions, data structures, program modules, and other data or content. Types of media include, for example, RAM, DRAM, ROM,

EEPROM, flash memory, solid state memory, and other memory technology. Other types of storage media can be used as well, as may include optical (e.g., Blu-ray or digital versatile disk (DVD)) storage or magnetic storage (e.g., hard drives or magnetic tape), among other such options. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the various embodiments.

The specification and drawings are to be regarded in an illustrative sense, rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the various embodiments as set forth in the claims.

Claims

WHAT IS CLAIMED IS:

1. A computer-implemented method, comprising:

receiving a request for a trip;

determining a number of route offerings for the trip based at least in part on criteria associated with a time to complete the trip, the route offerings comprising combinations of route information and of vehicle information;

providing at least first data comprising the route offerings;

accessing a data store for restrictions associated with the request; providing at least second data comprising fewer than the number of route offerings based at least in part on the restrictions, the second data thereby reducing storage and transmission data units from the first data; and

transmitting the second data as computer-readable instructions in response to the request.

2. The computer-implemented method of claim 1, further comprising:

discarding select route offerings from the second data to remove redundant data units based at least part on user preferences.

3. The computer-implemented method of claim 1, further comprising:

receiving an input associated with the second data; and

providing a responsive route offering from the route offerings available for the request from the second data.

4. The computer-implemented method of claim 1, further comprising:

generating the second data from a modification to the first data to remove at least one redundant data unit from the first data.

5. The computer-implemented method of claim 1, further comprising:

generating the criteria to comprise one or more threshold values associated with the time to complete the trip; and

generating the first data to comprise, as part of the route offerings, one or more of a starting time, an ending time, a wait time, a detour time, a number of stops, a vehicle type, vehicle occupancy information, and time units associated with traffic for the trip.

6. The computer-implemented method of claim 5, further comprising:

generating the criteria based at least in part on analysis of the trip using first information from prior trips sharing a common portions with the trip and using second information from current conditions based at least in part on one of the common portions of the trip; and

generating the one or more threshold values based at least in part on the first information and the second information.

7. The computer-implemented method of claim 6, further comprising:

modifying, based at least in part on the one or more threshold values, the generated one or more of the starting time, the ending time, the wait time, the detour time, the number of stops, the vehicle type, the vehicle occupancy information, and the time units associated with traffic for the trip.

8. The computer-implemented method of claim 1, further comprising:

providing access to a profile of an electronic account associated with the request; obtaining, as the restrictions, values associated with one or more of a walking limit in distance or time, a space, a capacity, and a vehicle type; and

providing a filter located remote from a device requested the request, the filter applying the limitations for the selection of the fewer than the route offerings.

9. A system, comprising:

at least one processor; and

a memory device including instructions that, when executed by the at least one processor, cause the system to: receive a request for a trip;

determine route offerings for the trip based at least in part on a time to complete the trip;

access profile information associated with the request;

filter using the profile information, at a filter remote from an origin of the request, the route offerings based at least in part on restrictions from the profile information to provide filtered route offerings; and

provide portions from the filtered route offerings in computer-readable instructions in response to the request.

10. The system of claim 9, wherein the instructions, when executed by the at least one processor, further cause the system to:

discard unfiltered route offerings to remove redundant data units.

11. The system of claim 9, wherein the instructions, when executed by the at least one processor, further cause the system to:

receive an input associated with the portions from the filtered route offerings; and provide a responsive route offering from the filtered route offerings.

12. The system of claim 9, wherein the instructions, when executed by the at least one processor, further cause the system to:

generate second data from a modification of first data, the first data comprising the route offerings, the second data requiring reduced data storage units than the first data by removal of at least one redundant data unit from the first data.

13. The system of claim 12, wherein the instructions, when executed by the at least one processor, further cause the system to:

generate a criteria comprising one or more threshold values associated with the time to complete the trip; and

generate the second data to comprise, as part of the route offerings, one or more of a starting time, an ending time, a wait time, a detour time, a number of stops, a vehicle type, vehicle occupancy information, and time units associated with traffic for the trip.

14. The system of claim 13, wherein the instructions, when executed by the at least one processor, further cause the system to:

generate the criteria based at least in part on analysis of the trip using first information from prior trips sharing a common portions with the trip and using second information from current conditions based at least in part on one of the common portions of the trip; and

generate the one or more threshold values based at least in part on the first information and the second information.

15. The system of claim 14, wherein instructions, when executed by the at least one processor, further cause the system to:

modify, based at least in part on the one or more threshold values, the generated one or more of the starting time, the ending time, the wait time, the detour time, the number of stops, the vehicle type, the vehicle occupancy information, and the time units associated with traffic for the trip.

16. The system of claim 9, wherein instructions, when executed by the at least one processor, further cause the system to:

obtain, from the profile information, values associated with one or more of a walking limit in distance or time, a space, a capacity, and a vehicle type; and

provide the filter to apply the values for the filtering to provide the filtered route offerings.

17. A non-transitory computer-readable storage medium including instructions that, when executed by at least one processor of a computing system, cause the computing system to:

receive a request for a trip; determine route offerings for the trip based at least in part on a time to complete the trip;

access profile information associated with the request;

filter using the profile information, at a filter remote from an origin of the request, the route offerings based at least in part on the profile information to provide filtered route offerings; and

provide portions from the filtered route offerings as computer-readable instructions in response to the request.

18. The non-transitory computer readable storage medium of claim 17, wherein the instructions, when executed by the at least one processor, further cause the computing system to:

discard unfiltered route offerings to remove redundant data units.

19. The non-transitory computer readable storage medium of claim 17, wherein the instructions, when executed by the at least one processor, further cause the computing system to:

20. The non-transitory computer readable storage medium of claim 17, wherein the instructions, when executed by the at least one processor, further cause the computing system to: