WO2019203804A1

WO2019203804A1 - Intelligent itinerary option sorting

Info

Publication number: WO2019203804A1
Application number: PCT/US2018/027925
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

A transportation service can sort itineraries that it proposes to service a passenger trip request. To enable sorting, the transportation service can evaluate itineraries based on itinerary characteristics, a passenger profile, and contextual information of the trip request. Itinerary characteristics can be manually supplied or automatically determined. Passengers can rate itineraries, provide reviews for itineraries, reject undesirable itineraries, and accept desirable itineraries. The service can then build a passenger profile based on the actions of a passenger. The service can determine itinerary characteristics based on weather conditions and exposure to the weather conditions.

Description

INTELLIGENT ITINERARY OPTION SORTING

BACKGROUND

[0001] With the advent and proliferation of navigation applications and services, people are increasingly turning to these applications and services to guide them to their destinations. While traditional street and transit maps can provide anyone the lay of the land, navigation applications help people find the fastest route to their destination. These navigation applications and services are effective at minimizing trip durations and cost, but they fail to incorporate other factors into their algorithms, especially if those factors have little influence on the total travel time or cost. Furthermore, traditional applications and services fail to consider unique travel preferences and priorities of specific users. These applications and services are less useful as a passenger becomes more familiar with the roads and public transit of an area.

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] FIG. 1 illustrates an example trip request screen in accordance with various embodiments. [0004] FIG. 2 illustrates an example origination and destination locations and itineraries for serving those locations in accordance with various embodiments.

[0005] FIG. 3 illustrates an example itinerary evaluation breakdown screen in according with various embodiments.

[0006] FIG. 4 illustrates an example process for sorting itineraries in accordance with various embodiments. [0007] FIG. 5 illustrates an example ride request environment in which various embodiments can be implemented.

[0008] FIGS. 6 A and 6B illustrate example origination 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 embodiments.

[0009] FIG. 7 illustrates example service metrics that can be balanced via an objective function in accordance with various embodiments.

[0010] FIG. 8 illustrates an example system that can be utilized to implement aspects of the various embodiments. [0011] FIG. 9 illustrates an example process for determining a routing solution for a set of trip requests that can be utilized in accordance with various embodiments.

[0012] FIG. 10 illustrates an example computing device that can be utilized to submit trip requests and receive itineraries in accordance with various embodiments.

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

DETAILED DESCRIPTION

[0014] 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.

[0015] Approaches described and suggested herein relate to the providing an order list of available itineraries in response to a trip request. In particular, various embodiments provide approaches for receiving a trip request to provide future transport for a passenger. The request can relate to transportation of people, animals, packages, or other objects or passengers, from an origination location to a destination location. The requests may also include at least one time component. A transportation service can determine a plurality of itineraries that can satisfy the trip request. The itineraries can include travel via a variety of modes of transportation and transportation services. The itineraries can include walking and waiting portions. The itineraries can have itinerary characteristics describing waiting portions, walking portions, and riding portions of the itineraries. The itinerary characteristics can include more than just travel times and costs; for example the itinerary characteristics can include environmental conditions such as a weather forecast for a portion of the itinerary, seating availability for a waiting period of the itinerary, and whether the itinerary includes a walk up stairs. Using the itinerary characteristics, the itineraries can be evaluated to determine a sort order. The evaluation can also use a profile for the passenger, the profile detailing preferences of the passenger towards various itinerary characteristics. Some itinerary characteristics are preferred while others are not preferred and are evaluated accordingly. Based on the sort order, the itineraries can be sorted and displayed. A user can then select an itinerary.

[0016] FIG. 1 illustrates an example client device 100 for with a display 110 for displaying various itineraries 1 l2_a-l l2_d that could service a trip request. A user can request transport from an origin to a destination using a transportation service. The transportation service can suggest various itineraries 112 for getting from the origin to the destination. The transportation service can sort the itineraries 112 based on a variety of itinerary characteristics. The transportation service can determine how much the user will value the itineraries 112 and can order them accordingly. [0017] In some embodiments, the transportation service can provide transport on a for-hire basis such as a taxi. The transportation service can provide scheduled routes. It should be understood that, in some embodiments, the transportation service can determine itineraries while relying on third parties to provide the actual transport.

[0018] The itineraries 112 that the transportation service identifies might have various itinerary characteristics. The transit service can compare the itinerary characteristics and generate a sorted list of the itineraries. Previous approaches to ordering itineraries solely focused on minimizing ticket cost or travel time. The itineraries can be sorted based on a profile for an individual user, a group of users, or the entire population and how the user, group of users, or population would likely value the respective itineraries. [0019] Comparing example itinerary 1 l2_a with itineraries 112_¾ and 1 l2_c illustrates how an itinerary can be ordered higher than others even if it is not the fastest or cheapest. For example the“Embarcadero” itinerary is fastest (32 minutes instead of 41) but is more expensive, has a walk up stairs, does not have wireless connectivity during the ride, costs more, etc. Similarly, the “California” itinerary is cheapest, but takes longer and has higher total trip time variability. A user can have various preferences for or against characteristics such as stairs, bad weather, transfers, walking, quiet cabins, wireless connectivity, etc.

[0020] The transportation service can develop a profile for a user based on the characteristics of itineraries that the user chooses. The user can also provide feedback to itineraries, marking characteristics that the user enjoyed or disliked. The user can rate itineraries or order itineraries so that the transportation service can further develop a profile for a user.

[0021] FIG. 2 illustrates an example map 200 demonstrating how multiple itineraries 212, 214, and 216 can satisfy a trip request from origin 202 to destination 220. Different characteristics may increase or decrease the relative ordering of an itinerary. For example, itinerary 212 does not have a walking portion, itinerary 216 has the shortest riding distance, and itinerary 214 has two transfers (illustrated by the circles in FIG. 2). Even if itinerary 212 is the longest of the example itineraries; it may be preferred because it does not have walking segments 204 or 206.

In some embodiments, itinerary 214 is preferred because it has a shorter walking portion 206 and shorter travel distance. [0022] FIG. 3 illustrates an example client device displaying an example breakdown of how an itinerary was evaluated 310. For example, the transportation service can determine a total cost or benefit of an itinerary for a user. In the example evaluation breakdown 310, the ticket cost might be $3.50 and the transportation service can determine a monetary equivalent of other costs and benefits for the itinerary. For example, the transportation service can determine a time cost for the itinerary. For example, if the user values his or her time at $10 per hour and the trip takes 30 minutes, the time cost can be $5. The time cost can be calculated based on how much time the user will be unable to do a certain activity such as working. For example, if the user likes working during a commute, the transportation service can determine how much of the time will not be amenable to working (e.g., standing, walking, or transferring) and can calculate a cost of those times.

[0023] The transportation service can determine weather conditions for the itinerary. For example, if the user will be exposed to bad weather during the itinerary. The transportation service can evaluate the cost of the weather condition based on the probability that the condition will occur (e.g., if the service determines that rain for 10 minutes is a cost of $10, then a 10% chance of rain for 10 minutes can have a cost of $1). The cost of the weather condition can be based on how long the user would be subjected to the weather condition.

[0024] The transportation service can determine a physical exertion cost based on the expected physical exertion for the itinerary. Physical exertion can include walking, running, biking, standing, going up or down a hill, going up or down stairs, or getting into a vehicle. The transportation service can determine a personal safety cost if there are security risks for the itinerary. Some itineraries might include passing through areas that have higher incidents of pick pockets for example. The transportation service can calculate a benefit of whether the travel experience is pleasant such as including a nice view. It should be understood that providing value assessments of an itinerary need not be expressed as money. For example, a valuation of an itinerary can be a score such as 1-5 stars. In some embodiments, a sort order for an itinerary is a relative measurement of how it compares to other available itineraries.

[0025] FIG. 4 illustrates an example process 400 for ordering itineraries. A transportation service can receive a trip request to provide future transport for a user (step 402). A trip request can include a trip origin and a trip destination which can be a specific address, coordinates, business, region, or city. The trip request can include a reference to a prior location that was visited. The trip request can include a trip arrival time (i.e.,“arrive by..”) a trip departure time (i.e.,“leave at or after..”), a user or users, and filters. The trip request can be for a single person or a group of people (regardless of whether they have a profile with the transportation service). Filters for a trip request can specify a maximum ticket price, a preferred mode of transportation, a preference to avoid itinerary characteristics such as bad weather, transfers, or walking. It should be understood that the principles herein disclosed can apply to conveying people, animals, and inanimate objects such as a packages and letters. [0026] Various approaches for receiving trip requests can be used within the scope of various embodiments. For example a trip request can be received from an application running on a client device, an internet application, by messaging, or telephonic mechanisms. In some embodiments, a trip request can be received generated and received by the same system, such as for a simulation. Other communications can be used in place of requests, as may relate to instructions, calls, commands, and other data transmissions. 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 might be used to submit an initial request for an object, package, or other deliverable, and then subsequent requests might be received from the object, for example, or a device or mechanism associated with the device.

[0027] A user can enter an origination location and a destination location, either manually or from a set of suggested locations, among other such options, such as by selecting from a map or other interface element. In some embodiments, a source such as a machine learning algorithm or artificial intelligence system can select the appropriate locations based on relevant information, such as historical user activity, current location, and the like. Such a system can be trained using historical ride data, and can learn and improve over time using more recent ride and rider data, among other such options. A backend system, or other provider service, can take this information and attempt to match the request with vehicles having capacity at the appropriate time.

[0028] 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.

[0029] A transportation service can determine a plurality of itineraries that can satisfy the request (step 404). An itinerary can include waiting periods such as transfers, stops, or layovers. An itinerary can include segments undertaken by foot (e.g., walkingjogging, or running) and segments in a vehicle. An itinerary can include various types of transportation arrangements such as using a passenger-owned vehicle, a vehicle for-hire, a private transit company, a ridesharing service, or a public transit company. An itinerary can include any combination of the foregoing; for example, an itinerary can include a bicycling segment, a waiting segment, a walking segment, a taxi segment, and a segment on a ridesharing service. [0030] A vehicle can include a personal conveyance (e.g., wheelchair, skateboard, bicycle, or motorcycle), car, truck, boat, ferry, plane, light-rail, trolley, train, cable-car, or aerial tram. A vehicle can transport one or more passengers, animals, and inanimate objects such as parcels for delivery. A vehicle can be reconfigurable to increase capacity (e.g., to have more space for passengers, animals, or inanimate objects) or decrease capacity (e.g., to increase fuel economy). A vehicle can have a driver or be driverless. A driverless vehicle can be is self-driving. A vehicle can follow a specific route or be on a track or guide.

[0031] The trip request can include filters and the plurality of itineraries can be the itineraries that satisfy the filters. Filters can include a maximum total time, a maximum distance, a maximum ticket price, a maximum walking distance (or time), a maximum waiting time, a maximum number of stairs (including excluding any itineraries that have any stairs), a requirement that food is along the itinerary, etc. It should be understood that any itinerary characteristics discussed herein can be used as filters.

[0032] A transportation service can provide transportation for at least a segment of an itinerary. When determining a plurality of itineraries that satisfy the trip request, the

transportation service can create or modify routes to provide at least one itinerary that could service the trip request. In some embodiments, the transportation service can propose to create or modify routes. Approaches in accordance with various embodiments can utilize at least one objective function to determine route options for a set of vehicles, or other transportation mechanisms, for one or more regions of service or coverage. At least one optimization algorithm can be applied to adjust various factors considered in order to improve a result of the objective function, such as to minimize or maximize the score for a set of route options. The factors in the objective function can include itinerary characteristics that the transportation service can control directly or indirectly. The optimization can apply not only to particular routes and vehicles, for example, but also to future planned routes, individual riders or packages, and other such factors. An objective function can serve as an overall measure of quality of a routing solution, set of proposed routing options, or past routing selections. An objective function serves as a codification of a desire to balance various factors of importance, as may include the rider’s convenience or experience, as well as the service delivery efficiency for a given area and the quality of service (QoS) compliance for specific trips, among other such options. For a number of given origination and destination locations over a given period of time, the objective function can be applied and each proposed routing solution given a score, such as an optimized route score, which can be used to select the optimal routing solution. In some embodiments the routing option with the highest route score will be selected, while in other embodiments there can be approaches to maximize or minimize the resulting score, or generate a ranking, among various other scoring, ranking, or selection criteria. Routing options with the lowest score may be selected as well in some embodiments, such as where the optimization function may be optimized based on 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 desirable to be as high as possible, among other such options. In other embodiments the option selected may not have the optimal objective score, but has an acceptable objective score while satisfying one or more other ride selection criteria, such as may relate to operational efficiency or minimum rider experience, among others. In one embodiment, an objective function accepts as inputs the rider’s convenience, the ability to deliver confirmed trips, the fleet operational efficiency, and the current demand. In some embodiments, there will be weightings of each of these terms that may be learned over time, 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.

[0033] The objective function can incorporate itinerary characteristics into the objective function analysis. The objective function can attempt to maximize a benefit or minimize a cost to the passenger according to a profile for the passenger. Additionally or alternatively, the objective function can maximize a benefit or minimize a cost to the transportation service.

[0034] A transportation service can determine respective itinerary characteristics for each of the plurality of itineraries (step 406). Itinerary characteristics can include a total trip time, a total trip cost, fees, environmental impacts, weather conditions, security considerations, passenger risk, available food options, physical exertion, accessibility considerations, wireless connectivity, itinerary adjustment availability, etc. In some embodiments, the itinerary characteristics can be manually provided (e.g., a person can identify stops that have covered waiting areas, walking portions that are uphill, etc.). Additionally or alternative, the itinerary characteristics can be automatically determined. [0035] The itinerary characteristics can include a total trip time. The total trip time can include waiting time(s). In some embodiments, the total trip time for an itinerary might be uncertain. Potential missed transfers, mechanical failures, medical emergencies, and other delays can cause the total trip time to be uncertain. The transportation service can simulate various scenarios (e.g., if a certain transfer is missed or bus breaks down) and assign a probability to the scenario and its respective total trip time. The itinerary characteristics can include a total trip time variability (e.g., +/- 10 minutes). The transportation service can determine the passenger’s preference to various trip times and, by combining the passenger’s preferences with the probabilities that respective trip times will come to pass, the transportation service can give a score to the expected total trip time, incorporating variances.

[0036] The transportation service can determine how much a passenger values their time. For example, one passenger might value shorter itineraries (even if they cost more) while another might value cheaper itineraries (even if they take longer). The transportation service can calculate the total monetary cost of the trip and a time-cost of the trip (e.g., by multiplying the total time by a time valuation for the passenger), by adding the total monetary cost and the time- cost (as well as any other“costs”), the transportation service can determine a“total cost” of the trip for the passenger.

[0037] The itinerary characteristics can include a total trip cost. The total trip cost can include ticket costs. The transportation service can determine any tickets would need to be purchased for the itinerary. For example, a bus and train ticket. If the passenger has a pass for a transit network, the passenger can provide information for the pass to the transportation service so that prices can be adjusted accordingly. As some modes of transportation can be outside of a network operated by the transportation service, the transportation service can retrieve expected ticket costs via an external computing system or can make a prediction of those costs. [0038] The total trip cost can include for-hire fees. For example, if the itinerary includes a segment on a taxi, the transportation service can determine the expected taxi fare for that segment. Similarly,“ridesharing” fees can be calculated.

[0039] The total trip cost can include costs related to a private vehicle for the user. Costs related to the private vehicle can include fuel costs, wear and tear, parking costs, toll costs, and insurance costs. Fuel costs can be calculated based on distance(s) of roads the passenger will need to drive, congestion on those roads, fuel economy for the vehicle (e.g., the passenger can provide his car details and the service can determine the expected fuel economy for the car), and local fuel prices. Fuel can include electric power. Wear and tear can be calculated based on the distance the vehicle will have to go, the time the vehicle will be in use, details of the passenger’s vehicle such as its make, model, and year. Wear and tear can also include characteristics of the parking location (e.g., is it a covered garage, under a tree, or in a high-crime area). Parking costs can include any parking fees that will likely be accrued. The system can determine a likely parking location, an expected duration at that location, and a cost. In some embodiments, the system can account for certain parking areas being at capacity based on the expected arrival time. Toll costs can include any tolls fees that will likely be incurred while driving. Toll costs can be based on the type of vehicle (e.g., car, motorcycle, semi-truck, or electric), a passenger capacity (e.g., to qualify for a high occupancy vehicle discount), and the time that certain toll stations are expected to be crossed. Some vehicles are insured based on the number of miles driven, thus expected insurance costs can be accounted for.

[0040] The itinerary characteristics can include an environmental impact of the itinerary. The environmental impact can be based on fuel expended for the trip (including fuel used to produce electricity for an electric vehicle), wear and tear on the transportation means, or the

environmental impact to create the transportation means (e.g., materials used in making a vehicle might have a negative environmental impact), etc.

[0041] The itinerary characteristics can include itinerary adjustment availability. Itinerary adjustment availability can be based on the cancellation policy of a segment of the itinerary or if the segment has a rescheduling option. Itinerary adjustment availability can include whether a price for a segment is likely to increase so a purchase should be made in advance. Itinerary adjustment availability can be useful for those who have uncertain plans and may need to cancel or adjust their plans. Itinerary adjustment availability can also include whether an itinerary has adequate“backups” in case a problem arises with that itinerary. For example, if a passenger has an important event to get to and takes an underground train, there is a chance that the passenger might be stuck underground whereas if the passenger takes a bus, the passenger can always get out and walk or hail a taxi should a problem arise.

[0042] The itinerary characteristics can include a passenger risk metric. The transportation service can determine the expected danger of each segment of an itinerary and calculate how likely there will be an accident along that segment that would cause bodily injury or death. For example, a plane flight might have less passenger risk than driving the same distance.

[0043] The itinerary characteristics can include how pleasant a trip is. For example, a certain train segment might have a nice view (weather dependent) while a taxi segment might be stressful. Certain segments may develop reputations of having more pleasant drivers, conductors, or station attendants. Certain vehicles or locations can also be more pleasing based on the ambiance. For example, one walk might be along a beach while another walking segment might be through traffic.

[0044] The itinerary characteristics can include environmental characteristics. Environmental characteristics can include physical conditions that a passenger would encounter during the itinerary such as weather conditions, weather exposure, seating conditions, stairs, pollution, noise, etc.

[0045] The environmental characteristics can include weather conditions. The weather conditions can be for the location(s) that the passenger will be and the respective times. For example, the transportation service can use historical data to predict what the weather conditions will be for the future time at a certain location of the itinerary. Weather conditions can include temperature, sun exposure (such as cloudy or sunny), precipitation (e.g., rain, snow, sleet, or hail), wind, air quality (e.g., pollution), pollen count, etc.

[0046] The transportation service can determine a weather exposure based on the weather conditions. Weather exposure can mean how much the weather will have an effect on the passenger (or the passenger’s itinerary). For example, if the transportation service predicts snowfall at a transfer point and time for the itinerary, the transportation service can then evaluate whether that stop has exposure to snow (e.g., is it covered). The transportation service can determine that an underground metro has little weather exposure, that walks on stairs have a high degree of weather exposure to snow and ice, that walking has exposure to rain, wind, or extreme temperatures, that driving has weather exposure to ice and snow, etc. In some embodiments, a passenger might want to get to a destination at a specific time and arriving early might require the passenger to wait outside; in such situations, the transportation service can penalize itineraries that arrive too early, especially if arriving early subjects the passenger to weather exposure. In some embodiments, the transportation service can use satellite imagery to determine the exposure for a certain area (e.g., to identify whether a stop is covered or uncovered or how quickly snow removal occurs).

[0047] The environmental characteristics can include security considerations. Security considerations can include issues relating to privacy, personal safety, or safety for the passenger’s property. Certain vehicles can provide better privacy having private cabins, tinted windows, individual seats, etc. The transportation service can give better scores to itineraries with discrete vehicles (e.g., those that are not branded a certain way to attract attention). Security considerations can be evaluated based on the presence or lack of security personnel, security cameras, locks, other passengers, loiterers, etc. Security considerations can include the presence of a phone to call for help. Security considerations can be evaluated based on the lighting (e.g., expected sunlight, expected moonlight, or artificial light) as well as general cleanliness of the location. The transportation service can evaluate security considerations based on crime reports for respective locations. For example, a certain train station might be more prone to pick- pockets, a parking lot might have more break-ins, and a bus stop might have harassment issues from local loiterers.

[0048] The environmental characteristics can include available food options. Available food options can include food provided by a mode of transportation (e.g., on a train, plane, or boat), at a station, along a route (e.g., a fast food restaurant along a driving portion), etc. The available food options can include a cost for the food, a type of food (e.g., Italian, Korean, American, BBQ), dietary considerations of the food (e.g., whether food options are Kosher, Halal, vegan, vegetarian, organic, locally sourced, or allergy considerations). Certain food options can have times associated with them, for example, how long it takes to go to the food vender, order, receive the food, and eat the food. The transportation service can determine the expected times based on how busy the food vender is expected to be when the passenger would be there. The transportation service can determine if the passenger has enough time to get food based on how much of a detour getting the food would be and how much time is available (e.g., how long a layover is). In some embodiments, the ride request can include a desire for food along the itinerary.

[0049] In some embodiments, the transportation service can provide coupons, discounts, or advertisements for available food options or a store nearby. This can be especially useful if a delay inconveniences a passenger (e.g.,“the bus is running 10 minutes late, here’s a coupon for a free hot chocolate at the coffee shop”). [0050] The environmental characteristics can include accessibility characteristics for the itinerary. The accessibility characteristics can include a number of stairs of the itinerary and whether the passenger must ascend or descend the stairs (e.g.,“three flights of stairs up and two down”), a slope of a path (which can be especially useful for wheelchair users and those carting wheeled goods), an elevation of a vehicle (e.g., to get into a bus), and a distance of walking. The amount of physical exertion can include an elevation gain or loss for a segment, which can be measured in feet, with an angle or steepness value, etc. In some embodiments the transportation service can count the amount of“steps” recorded by a portable electronic device on a passenger during travel to estimate the physical conditions for segments of itineraries. Similarly, the transportation service can, through an application on a passenger’s phone and with the passenger’s consent, determine how much standing and sitting a passenger does at a waiting location based on the phone’s inertial measurement unit.

[0051] Accessibility characteristics can also include factors relevant to passengers with disabilities. For example, some itineraries may be better suited for the blind (e.g., if they have audible announcements or truncated dome tiles indicating safe areas), the deaf (e.g., if they have visual signage), those with mobility constraints (e.g., if elevators or escalators are available, or expected to be available at the respective time), those with size requirements, those with companion animals, or those with anxiety (e.g., if the itinerary excludes driving over bridges, driving on highways, riding in crowded areas, or having confusing transfers). Accessibility considerations can include languages (e.g., what languages are spoken by employees, drivers, etc. and what language the signage is in). Accessibility considerations can include whether an itinerary is wheelchair or stroller friendly.

[0052] The itinerary characteristics can include an amount of physical exertion which can be based on a total amount of exertion (e.g., how many calories the passenger would“burn” during the itinerary) or the amount of exertion at any time (e.g., how difficult an individual portion is). The amount of physical exertion can be based on the physical conditions of the itinerary and characteristics of the passenger. The amount of physical exertion can be based on the passenger’s age, fitness level, desire to get a workout, and cargo (e.g., if the passenger is carting luggage or a heavy backpack). The amount of physical exertion can be based on an amount of standing time required of the passenger, such as standing on a bus, a train, or while waiting at a stop. The transportation service can determine the likelihood that the passenger will not be able to find a seat on a vehicle based on ridership data for where the passenger gets on the vehicle. Some itineraries may include a jog or fast walking segment which can influence the amount of physical exertion for the itinerary. [0053] Some passengers may wish to get exercise and so might prefer a 15 minute walk to 15 minutes of standing, especially if the itinerary with the walking portion gets them to their destination quicker. The transportation service can determine, using the passenger’s phone (or other portable electronic device) that the passenger is active or desires to be active (e.g., that the passenger has a goal for a certain number of daily“steps”) and weight itineraries accordingly. [0054] The environmental characteristics can include comfort characteristics. For example, the transportation service can determine a quality of heating or air conditioning on a vehicle (e.g., some vehicles might get cold and some underground metro segments may get hot). Comfort characteristics can include an amount of legroom, headroom (e.g., how high the ceiling is), width of a seat, availability of handrails, odor or noise characteristics, etc. Comfort characteristics can include how clean a vehicle or location is. Comfort characteristics can include how gentle or bumpy a segment is, this can be determined by recording accelerometer readings of a vehicle for that segment.

[0055] Comfort characteristics can include ridership profiles. While travelling, it is common for people to desire to travel with people that are looking for a similar travel experience. A ridership profile can indicate that passengers keep to themselves for a segment (e.g., for work or study), that passenger are talkative for a segment (e.g., for groups of friends), or that a segment is family-friendly (e.g., no alcohol or adult media are present and energetic kids are not a disturbance). The transportation service can determine ridership profiles for each segment of the trip based on the time of day (e.g., a trip on a subway during commute hours will likely be more business-like while the same trip at night will be more lively).

[0056] Comfort characteristics can include whether a vehicle is likely noisy. Some vehicles are designed with acoustic dampening and thus might be more comfortable for passengers that wish to have a quiet trip. Comfort characteristics can indicate that locations where a train is underground or turning are more prone to be noisy. The transportation service can determine that some segments are more likely to have noisy people on them (e.g., children leaving school).

[0057] Comfort characteristics can include seat characteristics for vehicles or waiting locations. For example, a seat can recline, have more headroom or legroom, and have a soft cushion. Seat characteristics can include the likelihood that a passenger will be able to get a seat. [0058] The environmental characteristics can include wireless connectivity. While a passenger travels, the passenger might want network connectivity for a portable electronic device using, for example, 802.11 (WiFi) protocols or cellular networks. Wireless connectivity can indicate a signal strength, available bandwidth, carrier (such as cell phone provider or WiFi network), wireless protocol (e.g., HSPA+, LTE, or 802.1 lac), and reliability. In some embodiments, a vehicle might provide wireless connectivity (e.g., a bus, train, or airplane) but have dead zones while, for example entering a tunnel or ascent/descent (for an airplane), which the transportation service can incorporate into the environmental characteristics. In some embodiments, the wireless connectivity comes at a cost (or has a free tier and paid tiers of service), the

transportation service can incorporate the cost of the wireless connectivity while evaluating an itinerary.

[0059] These and other characteristics may be used to generate a value, such as an“agony” factor, that can be used to compare route options against each other, as well as options from other providers or options outside provider services, such as walking. This may also be considered as a quality factor for the rides that is separate from price and relates more to the convenience and experience of the ride. The agony factor can consider various environmental values discussed herein, and may weight those by determined or learned importance. This may include, for example, expected wait or connection time, total overall time, walking distance or time, and the like. These values can be calculated for various ride options, and then used to select or rank the various options. This can also be used to compare the options against each other or an agony baseline, among other such options. An agony factor can also be determined for two specific route options. For example, the combined wait, walk, and ride times can be compared for the routes with relative weightings to generate an agony value for taking one route versus the other. This can be used to select or recommend the option with the lower agony value, or can be used to price the routes accordingly, such that the route with the higher agony factor may have a lower price or other incentive offered relative to the route option with the lower agony factor or score. As mentioned, such a score or factor can include other parameters as well, such as elevation gain, perceived security, environmental exposure, and the like.

[0060] In many instances the agony factors can be used to compare specific route options from a common provider or for a certain situation. It may be desirable, however, to normalize the agony factors such that all routes can be compared against each other, regardless of provider or location. This can help not only with pricing, but to determine where and how to adjust routes or improve route quality. Individual weightings may vary between users as well. For example, some users may not care about the connection times as long as they make their connections. Other users might want some amount of time buffer, and may not enjoy a route if they barely make their connection. Accordingly, at least some of the weightings and factors can vary by user, and can be learned over time based upon user feedback, machine learning, or other such approaches. Further, a maximum agony value may be learned for some users, such that no trip options above the maximum agony value will be suggested. In other embodiments, the agony factor may be used to reduce the number of options provided to only those that fall below an agony threshold, except where there may only be a few options available. In some embodiments the filtering or decisions can be made using a combination of the agony factor and price, as some users may be willing to take a route with a high agony factor if the price is right. The balancing point for various users can also be learned or determined over time. [0061] A transportation service can evaluate each of the plurality of itineraries based on the respective itinerary characteristics, yielding itinerary scores (step 408). In some embodiments, the transportation service can evaluate itineraries based on a user profile for the passenger. The transportation service can also evaluate itineraries based on the total population of passengers. In some embodiments, the transportation service can assign a metric to each characteristic and score an itinerary based on the sum of the metrics.

[0062] This evaluation can include determining how much value the passenger would assign to each itinerary. Each characteristic can increase or decrease the total value of the respective itineraries (as illustrated in FIG. 3). Some factors such as weather conditions and total trip time, deal with probabilities, the transit service can determine an expected value to the passenger of the itinerary based on how much the passenger values each possible outcome, weighted by its respective probability. The transportation service, when evaluating itineraries, can determine a confidence level that the evaluation accurately matches how the passenger would value the itinerary. Itineraries with less than a determined confidence level can be discarded. [0063] In some embodiments, the transportation service can evaluate itineraries based on a benefit or cost to the transportation service. For example, multiple itineraries might be of similar value to the passenger based on the itinerary characteristics but one itinerary might be more costly to the transportation service. The transportation service can then increase an itinerary score for those that are better for the transportation service can decrease the itinerary score for itineraries that are more costly to the transportation service. The transportation service can value the recited itinerary characteristics differently than the passenger. Other characteristics that can be considered are the total distance travelled, capacity of a vehicle, likelihood that the itinerary will facilitate picking up other passengers, and the likelihood that an itinerary will encourage the passenger to return to the transportation service. For example, if one itinerary includes a segment on the transportation service that is fast and not crowded while another itinerary includes a segment that is slow and crowded, the transportation service might want to showcase the fast and not crowded segment even if the passenger would be indifferent between the itineraries taken as a whole. [0064] In some embodiments, the transportation service can modify or create a route to satisfy at least a portion of the trip request. For example, the transportation can use the objective function described herein to modify or create a route that goes from the origin to the destination of the trip request. The transportation service can use the objective function and generate or modify a route using applicable“itinerary characteristics.” The transportation service base the objective function on one or more passenger profiles.

[0065] It should be understood that itinerary characteristics can interrelate. For example, a passenger might prefer a quiet environment if the total trip time is long but might not care about noise if the total trip time is short. Similarly, the weather conditions at a stop might only matter if the passenger is planning on eating food.

[0066] The transportation service can determine the passenger’s preferences. The passenger preferences can be included in a passenger profile. In some embodiments, certain preferences can serve as binary filters (e.g.,“avoid stairs,”“I forgot my umbrella, no uncovered waiting if there’s bad weather,”“less than 400 feet of walking,”“no more than 5 minutes of standing,”“no less than five minutes to make a connection,” etc.), where itineraries that do not match the filter are excluded. This approach might be overly exclusive; for example, if tolls are typically around $5, the passenger might choose to exclude tolls missing out on an itinerary having a $0.20 toll that could save 30 minutes. Thus, the transportation service can evaluate how strong or weak the passenger’s preferences are towards certain characteristics. [0067] In some embodiments, the trip request can include contextual information or passenger preferences for the trip. For example, the trip request can include an indication that the passenger would like to work, eat, talk on the phone, sleep, play video games, or engage in any other activity during the trip. The transportation service can automatically determine contextual information or passenger preferences. For example, if the trip request is to go to a day care, the transportation service might assume that the passenger is going with a stroller and thus itineraries that have better accessibility can be preferred. Similarly, if the trip request is to go to a school, the transportation service can deduce that the passenger would prefer an itinerary that is quieter. If the trip request is from or to a pet groomer (or similar pet-related store), the transportation service can give pet-friendly itineraries a higher rating. The transportation service can determine preferences for any of the itinerary characteristics listed herein. In some embodiments, contextual information can include a trip sponsor. For example, the passenger may have an employee-sponsored plan with the transportation service; the transportation service can then determine that the trip is for business and can increase the weighting of itineraries that are better suited for business (e.g., fast, quiet, and reliable). Contextual information can include the time of day (e.g., a passenger might want a morning trip to be quiet and fast while wanting an evening trip to be fun and entertaining).

[0068] The transportation service can provide the passenger with a survey, inquiring how much the passenger prefers various factors (e.g.,“would you pay $1 to save 10 minutes?” or “how much extra would you pay for a seat on the train?”). The transportation service can prompt the passenger to score or rate itineraries in order to“train” a model of the passenger’s preferences. For example, the passenger can give a star rating (e.g., 4/5 stars) or a value assessment (e.g.,“I’d pay $7 for this itinerary”). In some embodiments, an application presents various itineraries and a passenger can reject itineraries (e.g., by“swiping” them away) to indicate that the itinerary provides less value to the passenger. The transportation service can use a passenger selecting a certain itinerary as an indication that the selected itinerary is superior to the other options. The transportation service can determine that a passenger is a repeat customer for a certain itinerary (e.g., that the passenger takes similar itineraries routinely) and determine that the passenger has a strong preference to that itinerary (and the characteristics that make up the itinerary).

[0069] The transportation service can use machine learning to evaluate itineraries and to determine passenger preferences. Training data can include historical data for what itineraries the passenger has chosen in the past. Training data can include how the passenger reviews or rates a past itinerary or whether the passenger took a similar itinerary in the future. The transportation service can use regression analysis, neural networks, and other statistical tools for determining relationships between factors and evaluations. In some embodiments, the transportation service can do a statistical analysis on each passenger individually. Alternatively or additionally, the transportation service can attempt to profile passengers and determine preferences of the profile population as a whole (e.g., that elderly passengers value accessibility while college-aged passengers are more price sensitive). Profiles can correspond to age, gender, occupation, location, cell phone make or model, or usage riding characteristics.

[0070] A transportation service can sort, in a sorted list, the plurality of itineraries based on the respective itinerary scores (step 410). In some embodiments, instead of evaluating the available itineraries independently, the transportation service can determine differences between the itineraries (e.g., they may all cost the same amount and have the same total time, but one might have good cell reception). Doing a difference analysis can economize processing power as itineraries might have a large number of similarities.

[0071] A transportation service can display the sorted list of the plurality of itineraries (step 412). In some embodiments, the transportation service automatically selects the top-evaluated itinerary and provides the itinerary to fulfill the trip request. In some embodiments, a user can select an itinerary.

[0072] FIG. 5 illustrates an example environment 500 in which aspects of the various embodiments can be implemented. In this example, a user can request transportation from an origination to a destination location using, for example, an application executing on a client computing device 510. 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 might be used to submit an initial request for an object, package, 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.

[0073] The transportation can be provided using a vehicle 500 (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 a package for delivery. In this example, a rideshare service offers routes using at least one type of vehicle that includes space for a driver 502 and seats or other capacity 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 506 (or other rider locations) may be occupied by riders, while another number of seats 508 may be unoccupied. In some embodiments objects such as packages or deliveries may also occupy available space for a ride as well. In order to improve the economics of the rides offered, it can be desirable in at least some embodiments to have the 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 origination location and off-board at a fixed destination location, with no passengers onboarding or off- boarding at intermediate locations.

[0074] In the present example, a given user can enter an origination location 512 and a destination location 514, either manually or from a set of suggested locations 516, among other such options, such as by selecting from a map 518 or other interface element. In other embodiments, source such as a machine learning algorithm or artificial intelligence system can select the appropriate locations based on relevant information, such as historical user activity, current location, and the like. Such a system can be trained using historical ride data, and can learn and improve over time using more recent ride and rider data, among other such options. 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, it can be desirable to select a vehicle that will be near the origination location at that time in order to minimize overhead such as fuel and driver costs. As mentioned, the capacity can include a seat for a human rider or sufficient available volume for a package or object to be transported, among other such measures of capacity. [0075] Such an approach may not be optimal for all situations, however, as it may be difficult to get enough users or object providers to agree to be at a specific origination 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. Further, such an approach may result in fewer rides being provided, which may reduce overall revenue. Further, requiring multiple users to travel to a specific, fixed origination 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, it can be desirable in at least some embodiments to factor rider convenience into the selection of routes to be provided. 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. Further, 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, such that the interests of the various riders are at least somewhat competing, against each other and those of the ride provider. It therefore can be desirable in at least some embodiments to balance the relative experience of the various riders with the economics of the rideshare service for specific rides, routes, or other transportation options. While such an approach will likely prevent a ride provider from maximizing profit per ride, there can be some middle ground that enables the service to be profitable while providing (at a minimum) satisfactory service to the various riders or users of the service. Such an approach can improve the rider experience and result in higher ridership levels, which can increase revenue and profit if managed appropriately.

[0076] FIGS. 6A and 6B illustrate one example approach that can be utilized to provide such service in accordance with various embodiments. In the example mapping 600 of FIG. 6A, a set of origination points 602 and destination points 604 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 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, 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 origination location may be inconvenient for at least some of those passengers, who may then choose alternate travel options.

[0077] It thus can be desirable, in at least some embodiments, to provide routes and

transportation options that balance, or at least take into consideration, these and other such factors. As an example, the mapping 650 of FIG. 6B illustrates a selection of routes 652 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 origination and destination location, but can come within an acceptable distance of those locations in most instances. There may be situations where origination 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 652 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. 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. [0078] 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. A function of these factors can then be optimized in order to provide for an improved customer experience, or transport experience for transported objects, while also providing for improved profitability, or at least operational efficiency, with respect to other available routing options. The optimization approaches and route offerings can be updated over time based on other available data, as may relate to more 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 function based upon various trends and relationships determined from the data as discussed elsewhere herein.

[0079] Approaches in accordance with various embodiments can utilize at least one objective function to determine route options for a set of vehicles, or other transportation mechanisms, for one or more regions of service or coverage. At least one optimization algorithm can be applied to adjust the various factors considered in order to improve a result of the objective function, such as to minimize or maximize the score for a set of route options. The optimization can apply not only to particular routes and vehicles, for example, but also to future planned routes, individual riders or packages, and other such factors. An objective function can serve as an overall measure of quality of a routing solution, set of proposed routing options, or past routing selections. An objective function serves as a codification of a desire to balance various factors of importance, as may include the rider’s convenience or experience, as well as the service delivery efficiency for a given area and the quality of service (QoS) compliance for specific trips, among other such options. For a number of given origination and destination locations over a given period of time, the objective function can be applied and each proposed routing solution given a score, such as an optimized route score, which can be used to select the optimal routing solution. In some embodiments the routing option with the highest route score will be selected, while in other embodiments there can be approaches to maximize or minimize the resulting score, or generate a ranking, among various other scoring, ranking, or selection criteria. Routing options with the lowest score may be selected as well in some embodiments, such as where the optimization function may be optimized based on 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 desirable to be as high as possible, among other such options. In other embodiments the option selected may not have the optimal objective score, but has an acceptable objective score while satisfying one or more other ride selection criteria, such as may relate to operational efficiency or minimum rider experience, among others. In one embodiment, an objective function accepts as inputs the rider’s convenience, the ability to deliver confirmed trips, the fleet operational efficiency, and the current demand. In some embodiments, there will be weightings of each of these terms that may be learned over time, 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. [0080] 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.

[0081] As an example, a rider’s convenience score can take into account various factors. One factor can be the distance from the rider’s requested origination point to the origination point of the selected route. The scoring may be performed using any 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 that a user is willing to walk or travel to an origination location, or the average maximum distance of all users, among other such options. For packages, this may include the distance that a provider is willing to travel to have those packages 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 origination location halfway between the requested and proposed origination 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. Various other factors may be taken into account as well, as may include 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.

[0082] Optimizing, or at least taking into consideration, a rider’s convenience metric can help to ensure that trips offered to the riders 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. Any appropriate factors can be considered that can be objectively determined or calculated using available data. 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 some embodiments a rider can provide a target time, while in others the riders can provide time windows or acceptable ranges, among other such options. Another factor 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 for a potential route through that area or those locations. For high demand areas there may also be an amount of time needed to find parking, or there may be additional cost for that parking that should be considered. Another factor may relate to the walking (or non-route travel) required of the user for a given route. This can include, as mentioned, the 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 may also be considered if appropriate. [0083] 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. For example, the currently planned seating or object capacity utilization can be considered.

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. 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 and other such factors. The deviation of a path can also be factored in, as sometimes there may be benefits to taking a specific path around a location for traffic, toll, or other purposes, but this may also be somewhat frustrating to a user in certain circumstances.

[0084] Another factor that may be considered with the rider convenience metric, but that may be more difficult to measure, is the desirability of a particular location. In some embodiments the score may be determined by an employee of the provider, while in other 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. 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 for a proposed route option. [0085] Another component metric 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. 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. 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 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. Further, factors can relate to whether origination 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 selecting proposed routes as discussed herein.

[0086] With respect to service delivery efficiency, 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. [0087] 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 origination 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 origination location and waiting for the passengers to board. 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 the convenience or QoS metrics.

[0088] 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. Accordingly, approaches in accordance with various embodiments can utilize a metric invariant of the behavior of the routing system. 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.

[0089] 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.

[0090] FIG. 7 illustrates an example set of service delivery efficiency metrics 700 that can be utilized in accordance with various embodiments. This example shows an approach that can balance planned vehicle miles with planned vehicle hours, and use these to determine“optimal” rider miles 702 for use in determining service efficiency. The optimal miles can be prorated to planned miles that have not yet been driven. The vehicle miles metric 704 can differ from the vehicle hours metric 706 along a number of different dimensions. For example, the vehicle to service area assignment for vehicle miles can be static, while the assignment for vehicle hours can be dynamic. Further, the optimization goal for a vehicle miles-based approach can be routing efficiency, while the optimization goal for a vehicle hours-based approach can be the overall service efficiency. Another type of optimization metric is referred to herein as a“made good” metric. For vehicle miles, this can be an occupancy made good (OMG) metric, and for vehicle hours this can be a velocity made good (VMG) or similar value. These“made good” metrics can provide an indication of whether specific optimization goals are met, and a balance can be made to make sure that both metrics are balanced while satisfying that goal, in order to provide for adequate occupancy (and thus operational efficiency) with sufficient average velocity (to provide operational efficiency as well as customer service satisfaction). Different objective functions can prioritize either parameter (or a combination of the parameters) based on service goals, but can attempt to ensure that the metrics both satisfy specified service criteria.

[0091] As mentioned, a route optimization system in some embodiments can attempt to utilize such an objective function in order to determine and compare various routing options. FIG. 8 illustrates an example system 800 that can be utilized to determine and manage vehicle routing in accordance with various embodiments. In this system, various users can use applications executing on various types of computing devices 802 to submit route requests over at least one network 804 to be received by an interface layer 806 of a service provider environment 808. The computing devices 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 812 or other such location. [0092] Information for the request can be directed to a route manager 814, 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 can analyze information for the request, determine available planned routes from a route data store 816 that have capacity can match the criteria of the request, and can provide one or more options back to the corresponding device 802 for selection by the potential rider. The appropriate routes to suggest can be based upon various factors, such as proximity to the origination and destination locations of the request, availability within a determined time window, and the like. In some embodiments, an application on a client device 802 may instead present the available options from which a user can select, and the request can instead involve obtaining a seat for a specific planned route at a particular planned time.

[0093] As mentioned, however, in some embodiments users can either suggest route information or provide information that corresponds to a route that would be desired by the user. This can include, for example, an origination 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 814 can receive several such requests, and can attempt to determine the best selection of routes to satisfy the various requests. In this example the route manager can work with a route generation module 818 that can take the inputs from the various requests and provide a set of route options that can satisfy those requests. 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. It should be understood that in some embodiments customers may also request for specific locations and times where deviation is not permissible, and the route manager may need to either determine an acceptable routing option or deny that request if minimum criteria are not met. In some embodiments an option can be provided for each request, and a pricing manager 822 can determine the cost for a specific request using pricing data and guidelines from a price repository 824, which the user can then accept or rej ect.

[0094] In this example, the route generation module 818 can generate a set of routing options based on the received requests for a specified area over a specified period of time. A route optimization module 820 can perform an optimization process using the provided routing options to determine an appropriate set of routes to provide in response to the various requests. Such an optimization can be performed for each received request, in a dynamic routing system, or for a batch of requests, where users submit requests and then receive routing options at a later time. 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. In various embodiments an objective function is applied to each potential route in order to generate a route “quality” score, or other such value. The values of the various options can then be analyzed to determine the routing options to select. In one embodiment, the route optimization module 820 applies the objective function to determine the route quality scores and then can select the set of options that provides the highest overall, or highest average, total quality score. 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.

[0095] In at least some embodiments, the objective function can be implemented independent of a particular implementation of an optimization algorithm. Such an approach can enable the function to be used as a comparative metric of different approaches based on specific inputs. Further, such an approach enables various optimization algorithms to be utilized that can apply different optimization approaches to the various routing options to attempt to develop additional routing options and potential solutions, which can help to not only improve efficiency but can also potentially provide additional insight into the various options and their impact or interrelations. In some embodiments an optimization console can be utilized that displays the results of various optimization algorithms, and enables a user to compare the various results and factors in an attempt to determine the solution to implement, which may not necessarily provide the best overall score. For example, there might be minimum values or maximum values of various factors that are acceptable, or a provider might set specific values or targets on various factors, and look at the impact on the overall value and select options based on the outcome. In some embodiments the user can view the results of the objective function as well, before any optimization is applied, in order to view the impact of various factor changes on the overall score. Such an approach also enables a user or provider to test new optimization algorithms before selecting or implementing them, in order to determine the predicted performance and flexibility with respect to existing algorithms.

[0096] Further, such an approach enables algorithms to evolve automatically over time, as may be done using random experimentation or based on various heuristics. 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.

[0097] 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.

[0098] 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. 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.

[0099] FIG. 9 illustrates an example process 900 for determining routing for a set of user requests that can be utilized in accordance with various embodiments. It should be understood that, for this and other processes discussed herein, there can be additional, fewer, or alternative steps, performed in similar or alternative steps, or in parallel, within the scope of the various embodiments unless otherwise stated. In this example, various trip requests are received 902 from, or on behalf of, various potential customers of a transportation service. The requests in this example relate to a future period of time, for at least one specified service area or region, in which the transport is to occur for one or more persons, animals, packages, or other objects or passengers. The requests can be submitted through an application executed on a computing device in many embodiments, although other request mechanisms can be used as well. In order to determine how to best serve the requests, this example process first determines 904 available vehicle capacity for serving the requests. This can include, for example, determining which vehicles or transport mechanisms are available to that service area over the specified future period of time, as well as the available seating or other capacity of those vehicles for that period of time. As mentioned, in some embodiments at least some of the seats of the various vehicles may already be committed or allocated to specific routes, riders, packages, or other such options.

[0100] Based at least in part upon the various available vehicles and capacity, a set of potential routing solutions can be determined 906. This can include, for example, using one or more route determination algorithms that are configured to analyze the various origination and destination locations, as well as the number of passengers and corresponding time windows for each, and generate a set of routing solutions for serving the various requests. The potential solutions can attempt to allocate vehicles to customers based on, for example, common or proximate origination and destination locations, or locations that can be served by a single route of a specific vehicle. In some embodiments a routing algorithm can potentially analyze all possible combinations for serving the requests with the available vehicles and capacity, and can provide any or all options that meet specific criteria, such as at least a minimum utilization or

profitability, or at most a maximum allowable deviation (on average or otherwise) from the parameters of the various customer requests. This can include, for example, values such as a distance between the requested origination location and a suggested pick up point, deviations from a requested time, and the like. In some embodiments all potential solutions can be provided for subsequent analysis.

[0101] In this example process, the various potential routing solutions can be analyzed 908 using an objective function that balances various factors, such as provider efficiency and customer satisfaction, or at least takes those factors into consideration as discussed elsewhere herein. Each potential routing solution that is analyzed using the function, or at least that meets specific minimum criteria, can be provided with a routing quality score generated inserting the relevant values for the solution into the objective function. This can include, for example determining a weighted combination of various quality factors as discussed herein. In some embodiments, the solution with the best (e.g., highest or lowest) quality score can be selected for implementation. In this example, however, at least one optimization procedure is performed 910 with respect to at least some of the potential solutions. In some embodiments the process might be performed for all potential solutions, while in others only a subset of the solutions will go through an optimization procedure, where solutions with a quality score outside an acceptable range may not be considered for optimization in order to conserve time and resources. The optimization process can attempt to improve the quality scores of the various solutions. As discussed herein, an optimization process can attempt to adjust various parameters of the solution, such as to adjust pickup times, stops per route, capacity distribution, and the like. As mentioned, multiple optimization procedures may be applied in some embodiments, where the algorithms may look at different factors or adjustable ranges, etc. Different optimization algorithms may also optimize for, or prioritize, different factors, such as different QoS or efficiency components, profitability, rider comfort, and the like.

[0102] After the optimization, at least some of the various proposed solutions may have updated quality scores. Some of the proposed solutions may also have been removed from consideration based on, for example, unacceptable quality scores or an inability to adequately serve a sufficient number of the pending requests, among other such factors. A specific routing solution can then be selected 912 from the remaining solutions, where the solution can be selected based at least in part upon the optimized quality scores. For example, if optimizing for factors such as profitability or customer satisfaction rating, it can be desirable to select the option with the highest score. If optimizing for factors such as cost, it might be desirable to select the option with the lowest score. Other options can be utilized as well, such as to select the score closest to a target number (e.g., zero). As mentioned, other factors may be considered as well.

For example, a solution might be selected that has close to the best quality score, but has a much better profitability or customer satisfaction value, or satisfies one or more other such goals or criteria. Once the solution is determined, the appropriate capacity can be allocated 914 based upon vehicles and seating, among other potential options, determined to be available for the determined region at, or near, the future period of time. This can include, for example, determining routes and stops, and assigning vehicles with appropriate capacity to specific routes. The assignment of specific types of vehicles for certain routes may also be specified in the routing options, as there may be certain types of vehicles that get better gas mileage in town and some that get better gas mileage on the highway, for example, such that operational costs can be broken down by types of vehicles as well. In some embodiments specific vehicles might also be due to service for a specific mileage target, which can be factored in as well as other factors, such as cost per mile, type of gasoline, fuel, or power utilized, and the like. Information about the selected routing option can then be provided 914 to particular customers, such as those associated with the received requests. The information can indicate to the users various aspects such as the time and location of pickup, the route being taken, the location and approximate time of arrival at the destination, and potentially information about the specific vehicle and driver, among other such options.

[0103] FIG. 10 illustrates an example computing device 1000 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 1000 has an outer casing 1002 covering the various internal components, and a display screen 1004 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 1006, 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.

[0104] FIG. 11 illustrates an example set of components that can comprise a computing device 1100 such as the device described with respect to FIG. 10, 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 1102 for executing instructions stored in physical memory 1104 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 1106 for the device. Application instructions for execution by the at least one processor 1102 can be stored by the data storage 1106 then loaded into memory 1104 as needed for operation of the device 1100. 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 1110 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.

[0105] The computing device may include, or be in communication with, at least one type of display element 1108, 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 1112, 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 1114 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.

[0106] 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. 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.

[0107] 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.

[0108] 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

CLAIMS WHAT IS CLAIMED IS:

1. A computer-implemented method, comprising:

receiving a trip request;

determining a plurality of itineraries can satisfy the trip request;

determining respective itinerary characteristics for each of the plurality of itineraries by:

determining an environmental characteristic for at least one of the plurality of itineraries;

evaluating each of the plurality of itineraries based on the respective itinerary characteristics, yielding itinerary scores;

sorting, into a sorted list, the plurality of itineraries based on the respective itinerary scores; and

displaying the sorted list of the plurality of itineraries.

2. The computer-implemented method of claim 1, wherein determining an environmental characteristic comprises:

determining that the at least one of the plurality of itineraries includes a waiting segment with a waiting time of day and waiting location; and

determining an amount of climate exposure based on a predicted weather for the waiting time of day and waiting location.

3. The computer-implemented method of claim 1, wherein the environmental characteristic includes an accessibility characteristic.

4. The computer-implemented method of claim 2, wherein determining an environmental characteristic includes determining that a walking segment of the at least one of the plurality of itineraries has at least one of stairs, a steep slope, or a specified elevation change.

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

determining a profile for the passenger, the profile including a passenger environmental characteristic preference, wherein the evaluating the plurality of itineraries is further based on the passenger environmental characteristic preference and the respective environmental characteristics.

6. The computer-implemented method of claim 5, wherein determining the profile for the passenger comprises:

receiving a rating of a prior itinerary that the passenger took; and

determining how prior itinerary characteristics influenced the rating.

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

receiving a selection of a rejected itinerary of the plurality of displayed itineraries; and

updating the profile for the passenger based on the rejected itinerary.

8. The computer-implemented method of claim 1, wherein displaying the sorted list of the plurality of itineraries includes displaying a plurality of characteristics that influenced the respective itinerary score for each of the plurality of itineraries.

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

removing itineraries from the plurality of itineraries that have below a predetermined itinerary score.

10. The computer-implemented method of claim 1, wherein determining the plurality of itineraries that can satisfy the trip request includes:

modifying a route of a vehicle of the transportation service to be able to satisfy at least a portion of the trip request.

11. A computer-implemented method, comprising:

receiving a trip request;

determining a plurality of itineraries can satisfy the trip request;

determining that an itinerary has an itinerary score less than a

predetermined amount; and

removing the itinerary from the plurality of itineraries.

12. The computer-implemented method of claim 11, wherein determining an environmental characteristic for at least one of the plurality of itineraries includes:

determining a location and a time of day for the at least one of the plurality of itineraries; and

determining a predicted weather for the location and the time of day.

13. The computer-implemented method of claim 11, wherein the environmental characteristic includes at least one of an elevation gain for a walking segment or an accessibility characteristic.

14. The computer-implemented method of claim 11, further comprising: determining a profile for the passenger, the profile including passenger preferences relating to the itinerary characteristics, wherein the evaluating the plurality of itineraries is further based on the profile for the passenger.

15. The computer-implemented method of claim 13, wherein determining the profile for the passenger comprises: receiving a rating of a prior itinerary for the passenger; and

determining how prior itinerary characteristics influenced the rating.

16. The computer-implemented method of claim 11, further comprising:

updating the profile for the passenger based on the rejected itinerary.

17. The computer-implemented method of claim 11, wherein displaying the sorted list of the plurality of itineraries includes displaying a plurality of characteristics that influenced the respective itinerary score for each of the plurality of itineraries.

18. A system, comprising:

at least one processor; and

memory including instructions that, when executed by the at least one processor, cause the system to:

receive a trip request to provide future transport for a passenger;

determine a plurality of itineraries can satisfy the trip request;

determine respective environmental characteristics for each of the plurality of itineraries;

evaluate each of the plurality of itineraries based on the respective environmental characteristics;

sort, into a sorted list, the plurality of itineraries based on the respective itinerary scores; and

display the sorted list of the plurality of itineraries.

19. The system of claim 18, wherein the instructions, when executed, further cause the system to determine a profile for the passenger, the profile including a passenger environmental characteristic preference and wherein the evaluating of the plurality of itineraries is further based on the profile.

20. The system of claim 18, wherein the instructions, when executed, further cause the system to:

receive a review for a prior itinerary; and

modify the passenger environmental characteristic preference based on the review.