Method and computer system for providing a route or route duration for travel from a source location to a target location

Abstract

To provide a method for calculating a route of a transportation system passenger, a computer system implementing and executing the method and a computer service product.SOLUTION: A method for producing a plan of a route in a transportation system receives route requirements, including a starting location and an ending location. The method builds a model of the transportation system from data about vehicles. The model abstracts a "prospect travel" between two locations using any of a range of choices of vehicles and walks that can travel between the two locations. Given anticipated wait durations for the vehicles and their ride durations, the method determines an expected minimum travel duration using any of these choices. The method combines the expectations for various locations in a scalable manner. As a result, a route plan that achieves an expected shortest travel duration, and meets other requirements, is computed for one of the largest metropolitan areas in existence today.SELECTED DRAWING: Figure 5

Description

[Technical field]

[0001] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application is based on and claims the priority date of the following application: US, Application No. 62 / 608586, filed December 21, 2017 US, Application No. 62 / 613779, filed January 5, 2018 US, Application No. 62 / 659157, filed April 18, 2018 Korea, Application No. 10-2018-0045558, Filing date April 19, 2018 US, Application No. 16 / 180050, filed November 5, 2018 These are incorporated herein by reference. [Background technology]

[0002] The present invention relates to route planning in metropolitan areas. The objective of route planning is to determine how to travel from one location to another using available vehicles from various transportation service providers. Often, among other requirements, it is required that the trip take as little time as possible or depart at a specific time. A route specifies instructions for a rider, usually including walking routes, riding routes, etc. Summary of the Invention

[0003] Embodiments include a method for calculating routes, a computer system that implements and executes the method, and a computer service product that enables a user to issue a routing query and receive a route in response.

[0004] According to one embodiment of the present invention, there is provided a method for generating a route plan. The method receives a query in the form of a source location and a target location for a route, and other requirements including a departure time or arrival deadline. The method creates a graph that models the statistical characteristics of vehicles. One of its features is a "probability edge" that models travel from one location to another using any of a variety of vehicle and walking options. In one embodiment, the edge models the expected minimum travel duration between two locations. Using the graph, or an extension thereof depending on the details of the query, the method generates a route plan in response to the query.

[0005] According to one embodiment of the present invention, a computer system for generating a route plan is provided. The system is a combination of hardware and software. It obtains information about transportation systems and walking between locations from multiple data providers. The system creates multiple graphs that model the transportation systems and calculates the shortest paths in the graphs to generate a route plan.

[0006] According to one embodiment of the present invention, a computer service product is provided for generating a route plan that allows a user to specify a query through a user interface of a device, such as a smart phone, and display a generated route plan on the device.

[0007] The embodiments of the invention presented herein are for illustrative purposes and are not exhaustive. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the embodiments.

[0008] The data retrieval, processing operations, and the like disclosed in the present invention may be implemented as computer systems or services, and not as mental steps or unembodied abstract ideas.

[0009] In the presentation, the terms "first", "second", "said" and similar terms are not used in a limiting sense but are used for distinguishing purposes unless the context clearly indicates otherwise. Unless the context clearly indicates otherwise, singular expressions include the plural. [Brief description of the drawings]

[0010] The drawings included herein illustrate various features and advantages of embodiments of the present invention. [Figure 1] FIG. 1 shows a graph G0 according to an embodiment of the present invention. [Diagram 2] FIG. 2 shows a process flow for constructing a graph G0 according to one embodiment of the present invention. [Diagram 3] FIG. 3 illustrates a trip from c to c′ that includes walking, waiting, taking a bus, and walking, according to one embodiment of the present invention. [Figure 4] FIG. 4 illustrates a trip from c to c′ involving one bus route but two travel modes according to one embodiment of the present invention. [Diagram 5] FIG. 5 illustrates two bus routes, each providing a separate mode of travel from c to c′, according to an embodiment of the present invention. [Figure 6] FIG. 6 illustrates a trip from c to c′ that includes walking, waiting, taking a subway, and walking, according to one embodiment of the present invention. [Figure 7] FIG. 7 illustrates the probabilistic edges of three options for moving from c to c' according to one embodiment of the present invention. [Figure 8] FIG. 8 illustrates the likelihood edges of two options for travel from c to c′ given a travel time random variable conditional on the passenger's arrival time at c, according to one embodiment of the present invention. [Figure 9] FIG. 9 shows pseudocode for computing the likelihood edge under the interval model of waiting times and fixed travel times according to one embodiment of the present invention. [Figure 10]FIG. 10 illustrates how graph G1 extends graph G0 with edges from sources in a query when the sources are known, according to one embodiment of the present invention. [Figure 11] FIG. 11 illustrates how graph G2 extends graph G0 with possible edges to targets in a query when the targets are known, according to one embodiment of the present invention. [Figure 12] FIG. 12 illustrates an example of calculating potential trip options continuing from the penultimate stop / station when a target is revealed at query time, according to an embodiment of the present invention. [Figure 13] FIG. 13 illustrates a process flow for a computer system for responding to a routing query according to one embodiment of the present invention. [Figure 14] FIG. 14 illustrates an example of a display of a route in response to a service product query on a user's smartphone according to one embodiment of the present invention. Detailed Description of the Invention

[0011] (4 Detailed Description) A metropolitan transportation system consists of vehicles such as subways and buses. A typical objective of passengers is to determine the fastest route from a particular location to another location in the metropolitan area. Routes can be calculated using vehicle timetables and desired departure or arrival deadlines, as found in major providers of online mapping services. However, in practice, some vehicles do not follow the timetable exactly, e.g., due to traffic conditions. In contrast to the prior art, the present invention shows how to calculate routes using a mix of vehicles that follow the timetable and those that do not. The present invention uses route similarity and waiting times to improve route determination results.

[0012] A simple example will illustrate the improvement. Consider two consecutive bus stops b1,b2 along a bus route. The ride time is 20 minutes on average. Furthermore, assume that a bus arrives at b1 every 24 minutes on average. For a passenger arriving at b1 at a random time, the average journey time to b2 is 32 minutes (waiting + boarding). Now assume that there is another bus operating between these two bus stops. Under the same timing assumptions, but assuming bus independence, the average journey time is reduced by 4 minutes. Typically, for n buses, the average is 20+24 / (n+1) minutes. This is simply because passengers can board the first bus that arrives at b1.

[0013] However, natural large cities are more complex than simple diagrams, with sophisticated overlapping patterns of routes, with vehicles having different arrival and speed patterns. Overlapping routes is not strictly necessary to achieve improvements, since passengers may walk between stops. Transportation systems may evolve over time, e.g., subway timetables may change or bus routes may be added. Furthermore, even in large metropolitan areas, efficient methods of calculating routes are needed so that computers can respond quickly to many routing queries.

[0014] (4.1 Model Overview) A model of a transportation system is introduced to calculate routes or route durations.

[0015] Assume that the transportation system consists of two types of vehicles: (1) vehicles that follow fixed timetables, departing and arriving at given times throughout the day, e.g., according to a weekday schedule. We call these vehicles subways and their stations subway stations; and (2) vehicles that do not have fixed departure and arrival times. We call these vehicles buses and their stops bus stops. Both subway stations and bus stops have fixed geographic locations, so that the walking distance between them can be determined. Buses are grouped into bus routes. Buses on a bus route operate following a fixed sequence of bus stops, usually to the terminal bus stop of the bus route.

[0016] In reality, some buses may arrive very precisely, which may not seem to comply with the model. For example, consider a bus leaving the first bus stop of a bus route according to a fixed timetable. The bus may arrive on time at the first few stops until it reaches a metropolitan area with unpredictable traffic. If a passenger arrives at one of these first bus stops after boarding a subway, the bus waiting time is predictable, and the total subway-walk-bus trip time is also predictable. This case can be modeled by adding a subway conceptually to represent this multi-vehicle subway-walk-bus trip. Similarly, bus-walk-subway, bus-walk-bus, and subway-walk-subway, and other combinations, can be conceptualized if the operations are synchronized or very punctual. In the following description of the invention, the assumption of fixed timetable subway and non-fixed timetable buses is maintained to simplify the presentation of the disclosure.

[0017] The method is not limited to routing people by bus or subway. In contrast, the method is more general. It accounts for many types of vehicles that occur in reality. For example, they include subways, buses, trams, trains, taxis, shared vans, cars, autonomous vehicles, ferry boats, airplanes, delivery bikes, lorries, or container trucks. The routes created by the method can be used to route any object. For example, they include people, cargo, parcels, letters, or groceries. The object is also called a rider.

[0018] The transportation system is modeled by a collection of directed graphs, each of which is made up of vertices and edges. Each vertex represents a bus stop, a subway station, or an auxiliary element. Other examples of vertices include train stations, taxi stands, shared van pick-up or drop-off points, parking lots, autonomous vehicle pick-up or drop-off points, platforms, levels, ports, ferry or air terminals, airports, or loading docks. Edges represent waits, trips from one location to another, or auxiliary elements. In one embodiment, edges have weights that indicate the duration of the wait or trip. In other embodiments, the weights are random variables. In other embodiments, some random variables are conditioned, for example, on the time of day, holiday / non-holiday type, among others. In other embodiments, some random variables may be correlated with other random variables.

[0019] In one embodiment, the probability distribution of a random variable is determined from historical data. For example, the time it takes for a bus of a particular bus line to travel from a particular bus stop b1 to a particular bus stop b2 is measured over a one-month period, and the empirical distribution of travel times is determined from this one-month sample. In another example, the arrival or departure times of buses of a particular bus line at a particular bus stop are measured over a period of time, and the empirical distribution of waiting times for buses of that bus line is determined by minute on weekdays. In another example, the transit interval reported by the bus operator is used to determine the average waiting time. In another example, the current location of the bus is used to calculate a more accurate distribution of waiting times for the buses.

[0020] Some of the random variables used in this method are non-trivial. Trivial random variables have exactly one value with probability 1. Other random variables are non-trivial.

[0021] The purpose of the graph is to assist in finding a route or route duration between two geographic locations in response to a query. The starting point of the route is called the source and the end point is called the target. The locations are determined by the application of the routing system. For example, locations could be commercial businesses, bus and subway stations themselves, any point in a park, or a person's current location as determined by the Global Positioning System. In one embodiment, the graph is based on Dijkstra's shortest path algorithm or A * A route is found by applying (A-star) search algorithms to the graph, or by some adaptations of these algorithms described below.

[0022] In some embodiments, constraints are added to the route, including, for example, vehicle type, vehicle stop type, threshold number of vehicle transfers, wait time threshold, walking time threshold, object type that is routed to only specific vehicles, monetary cost threshold of the trip, departure time from a source, arrival time at a target, or desired probability of arriving before a deadline.

[0023] In one embodiment, the method calculates a route or route duration that has the smallest expected duration, although the method is more general and may also calculate a route or route duration that is approximately the fastest, or may not be the fastest, but which limits the risk of arriving after a certain deadline.

[0024] The present invention constructs several graphs to answer routing queries, and some embodiments extend the graphs with additional vertices and edges based on the query.

[0025] (4.2 Graph G0) A graph called G0 represents the routing between bus stops and subway stations. A detailed description of its structure follows. The description of graph G0 is given in Figure 1, and the process flow of its structure is given in Figure 2.

[0026] (4.2.1 Fixed timetable) The first group of vertices and edges represents routing by vehicles following a fixed timetable. Since the timetable is fixed, known algorithms can be used to calculate the fastest route between two locations, which may involve a multi-vehicle sequence with footpaths in between. Therefore, we use a single edge to abstract this multi-vehicle movement from a source to a target.

[0027] We add vertices to model subways where passengers board without waiting, as if they were timed to arrive at the station according to the subway train's departure. For each subway station s, we introduce two vertices: SUBWAY_FROM_s, SUBWAY_STATION_s. Any two distinct stations s, s' have the following edges: SUBWAY_FROM_s→SUBWAY_STATION_s' This represents the ride time from s to s', which may include subway transfers and walking (e.g., from station s, take subway A to station B, walk to station C, then take subway D to station s'), and this edge is labeled RideManyGetOff. In one embodiment, the weight of the edge is the minimum ride time during the weekday morning rush hour. In another embodiment, a random variable is used for each of many time windows. In another embodiment, the random variable is conditioned on the passenger's arrival time at or departure time from location s.

[0028] Model the event when a passenger arrives at a subway station during a trip and needs to wait for the subway. For any two distinct stations s' and s”, add the following vertex that represents a ride from s' to s”, SUBWAY_FROM_TO_s'_s”. There is a next edge, labeled WaitGetOn, which represents the waiting time to get on the subway to travel from s' to s”. SUBWAY_STATION_s' →SUBWAY_FROM_TO_s'_s”. In one embodiment, the weight of an edge is set to the average wait time of the subway that will get a passenger to s" fastest for a passenger arriving at s' at a random time during the weekday morning rush hour. In another embodiment, the weight is set to half the average arrival time of the subway from s' to s". In another embodiment, a random variable is used for each of many time windows. In another embodiment, the random variable is conditional on the distribution of passenger arrival or departure times at the location of s'.

[0029] The next edge is added, SUBWAY_FROM_TO_s'_s” →SUBWAY_STATION_s”, It is labeled RideManyGetOff and represents the ride time from s' to s", which may include subway transfers and walking. In one embodiment, the edge weight is set to the average minimum ride time during the weekday morning rush hour. In another embodiment, a random variable is used. In another embodiment, the random variable is conditioned on the passenger's arrival time at or departure time from the location of s'.

[0030] (4.2.2 Non-fixed timetable) The second group of vertices and edges represents vehicle routing that does not follow a fixed schedule.

[0031] For every bus route, we add vertices that model the bus stops and the buses at the stops. The former abstracts passengers outside the bus, and the latter abstracts passengers inside the bus. n Let be n consecutive bus stops (including on-demand stops) along bus route e. Add the following vertices for each k, 1≦k≦n: BUS_STOP_b k and BUS_AT_BUS_STOP_b k _k_e. Two bus routes can share a bus stop. There is an edge labeled GetOff indicating that the bus gets off at this bus stop, and the weight of this edge is zero. BUS_AT_BUS_STOP_b k _k_e→BUS_STOP_b k . There is a reverse edge, and before boarding the bus stop b k It is labeled WaitGetOn, which represents the time it takes to wait for a bus on bus route e. BUS_STOP_b k →BUS_AT_BUS_STOP_b k _k_e. In one embodiment, the edge weights are set to half the average arrival time of buses on bus route e during the weekday morning rush hour, which is the same for all bus stops on that bus route. In another embodiment, a random variable is used for each of many time windows and bus stops. In another embodiment, the random variable is b k Conditional on the arrival time, or distribution of arrival times, of passengers at a location.

[0032] To model same-bus trips, the following edge is added, labeled RideSame, and connects bus stop b k From the next bus stop b k+1 It shows the time required to get there. BUS_AT_BUS_STOP_b k _k_e →BUS_AT_BUS_STOP_b k+1 _k+l_e. In one embodiment, the edge weights are set to the average ride time between these bus stops during the weekday morning rush hour. In another embodiment, a random variable is used for each of the many time windows and bus stops. In another embodiment, the random variable is k the arrival time of the bus to the location of b k The departure time is from the location.

[0033] (4.2.3 On foot) Use walking to connect the bus stop and subway station vertices.

[0034] In this and other sections of this disclosure, various requirements for walking are allowed. In one embodiment, the shortest walking time at a specific speed of 4km / h is used. In another embodiment, the weights are random variables for each of several walking path requirements, including a speed of 6km / h, avoiding stairs, avoiding dark streets, etc. In another embodiment, only walking times of at most a fixed amount of time, e.g., 1 hour, are allowed. In another embodiment, the walking is in a straight line ignoring obstacles. In another embodiment, the walking can include travel by lift, moving walkway, elevator, or escalator.

[0035] For any b, b', s, and s', if the requirement is allowed, the following edges are added: BUS_STOP_b →BUS_STOP_b', BUS_STOP_b →SUBWAY_STATION_s, SUBWAY_STATION_s → BUS_STOP_b, and SUBWAY_STATION_s →SUBWAY_STATION_s'. Each edge is labeled Walk and its weight represents the walking time.

[0036] (4.2.4 Constraints) We then add an auxiliary vertex that allows modeling constraints on the initial wait along the route. In one embodiment, the wait is zero, which models passengers who are early enough to catch a departing bus / subway, but not too early, and walk to the stop / station. In another embodiment, the wait depends on the start time of the trip, which models passengers who leave home and start their trip at a particular time, for example 8am.

[0037] Bus stops and subway stations are clustered based on their geographical proximity. In one embodiment, the cluster radius is fixed at 2 meters. In another embodiment, the number of clusters is chosen depending on the resource / quality tradeoff required by the user of the routing system. In another embodiment, the cluster radius is 0 meters, in which case the clusters are simple replications of bus stops and subway stations.

[0038] For each cluster c, the following vertices are added: STOPSTATION_CLUSTER_SOURCE_c And b k Or if s is in cluster c, then the following edges are added connecting the cluster to bus and subway: STOPSTATION_CLUSTER_SOURCE_c →BUS_AT_BUS_STOP_b k _k_e, and STOPSTATION_CLUSTER_SOURCE_c →SUBWAY_FR0M_s. The edge is labeled FirstWaitGetOn. In one embodiment, the weight of the edge is 0. In another embodiment, the weight of the edge depends on the location of the vertex (bus stop b k , or metro station s). In other embodiments, for example when the cluster radius is large, c and b k or the weight is increased by the walking time between s.

[0039] The next vertex in the graph STOPSTATION_CLUSTER_SOURCE_c Any nontrivial path from traverses the FirstWaitGetOn edge exactly once.

[0040] Other auxiliary vertices STOPSTATION_CLUSTER_TARGET_c Then, for each b and s in cluster c, the following edges are added: BUS_STOP_b → STOPSTATION_CLUSTER_TARGET_c, and SUBWAY_STATION_s →STOPSTATION_CLUSTER_TARGET_c. Edges are labeled as Zero and have weight 0. In other embodiments, the weight increases with walking time, for example when the cluster radius is large.

[0041] The next vertex, STOPSTATION_CLUSTER_TARGET_c The introduction of helps reduce the size of the graph when there are many routing target locations. In other embodiments, these vertices can be optionally BUS_STOP_b, and SUBWAY_STATION_s can be replaced with a direct edge from to the target.

[0042] The graph constructed so far is that for any c and c', STOPSTATION_CLUSTER_SOURCE_c STOPSTATION_CLUSTER_TARGET_c', , which models the duration of a trip, where the first bus or subway is boarded without waiting or with a given waiting time, and after the passenger disembarks from the bus or subway sequence, subsequent vehicle boardings require waiting to board.

[0043] (4.2.5 Prospect Edge) We then add auxiliary vertices and edges that indicate improvements in journey time by using any of several vehicles. The improvements can come from reducing vehicle waiting times or reducing vehicle ride times.

[0044] The time spent waiting to board a ride can be modeled by assuming that passengers arrive at stops / stations at random times, due to the stochastic nature of vehicles with non-fixed timetables. If there are two consecutive RideManyGetOff board edges on a graph path, the edges can be replaced with a single RideManyGetOff edge.

[0045] We introduce a prospect edge, which abstracts travel between two locations using one of several vehicle choices. In one embodiment, the weight of the edge is the value of the expected minimum travel time among these choices.

[0046] In this section, the two locations connected by a potential edge are near a vehicle stop. However, this is not a limitation of the method. In fact, in later sections, we discuss potential edges that terminate at any location that may be far from a vehicle stop. In general, a potential edge can connect any two vertices in the graph. However, for purposes of illustration, this section focuses on potential edges near a vehicle stop.

[0047] Similar to above, we cluster bus stops and subway stations based on their geographical proximity. Given two distinct clusters c and c', we consider a trip from c to c' by walking, taking a bus, and then walking, and we allow both trips to have length 0. For example, Figure 3 shows the distance from c to the next vertex BUS_STOP_b, From there, the next vertex includes bus route e with edges WaitGetOn, RideSame, and GetOff. BUS_STOP_b', Through a graph path that ends with BUS_STOP_b' Here, T is a random variable representing the travel time from c to c', walking from c to b, b' to c', and taking a bus from b to b' modeled by a graph path. This variable is the sum of the random variables of the graph edges along the path plus two walking random variables, one for the front leg and one for the back leg. Its distribution can be constructed from the distributions of its components. In one embodiment, the random variable is conditioned on the departure time from c.

[0048] In one embodiment, the random variable T is uniformly distributed in the interval [x,y], with the ends of the interval being x = (minimum walking time from c to b) + (sum of expected RideSame trip times along the route edges) + (minimum walking time from b' to c'), and y = x + 2 (estimated WaitGetOn time). In other embodiments, both ends are scaled by multiple standard deviations of the random variable. In other embodiments, consider c, b, b', c' only if the walking time from c to b and from b' to c' is at most a fixed time, e.g. 1 hour. In other embodiments, any of the walks may be zero length (optional walks). In other embodiments, request the shortest walking time from c to b or from b' to c'. In other embodiments, the walks may have an implementation as in section 4.2.3. In other embodiments, the random variable T is non-uniform. In other embodiments, the random variable T is conditioned on the passenger's arrival time at the location of c.

[0049] For a fixed bus route e, there are many options for traveling from c to c', since passengers can board and alight at various stops on the route and walk for the rest of the trip. For example, Figure 4 extends Figure 3, adding one additional stop, BUS_STOP_b” Another trip at increases the total ride time but decreases the total walking time. In one embodiment, among these options, we use the random variable T with the smallest expected value. We denote this by the variable Tcc'e. This is a fixed random variable for bus route e and start and end clusters c, c'. This variable indicates the fastest travel time to reach c from c' stochastically by bus route e. In one embodiment, if the candidates for Tcc'e are uniformly distributed in the interval, the smallest expected candidate is simply the one with the smallest median value for that interval. In another embodiment, we use one variable for each of many time windows, for example to ensure higher frequency of buses and higher road traffic during peak hours. In another embodiment, the random variable is conditional on the arrival time of the passenger at the location of c.

[0050] All bus routes e1,..,e that serve passengers from c to c' n Note that the configuration of walking and bus stops may be different. For example, Figure 5 shows two bus routes e1 and e2, each with distinct bus stops and different walking times. As previously defined, Tcc'e1,..,Tcc'e n Let be the random variables for each fastest travel time.

[0051] The expected minimum value of a variable E[min(1≦i≦n)Tcc'e i ] can be calculated. This estimate models the travel time by "which bus will get me there faster". In one embodiment, the random variables for different bus routes are independent. That is, the probability of any two different bus routes e i and e j About Tcc'e i Tcc'e jIn another embodiment, the random variables are independent and uniform in a common interval [x,y], so the expected minimum is (y+nx) / (n+1). In another embodiment, the expected value is calculated through a mathematical formula for the expected minimum, an approximate integral, random sampling, or other approximation algorithm or heuristic. With an approximation algorithm, the method does not generate the shortest route, but instead generates a near-shortest route.

[0052] Next, we explain how to include subways in the calculation of expected minimum travel time. Similar to buses, let Tcc'ss' be a random variable for the fastest travel time from c to c' by walking and taking the subway. As shown in Figure 6, walking from c to s, a route in the graph SUBWAY_STATION_s →SUBWAY_FROM_TO_s_s' →SUBWAY_STATION_s', and there is a walk from s' to c'. The distribution of this variable can be constructed from the distributions of its components. In one embodiment, the random variable is conditioned on the departure time from c.

[0053] In one embodiment, Tcc'ss' is uniformly distributed in the interval [x,y], with the two ends of the interval being x = (minimum walking time from c to s) + (Estimated RideManyGetOff (multiple rides and get-offs) time required for the route in the graph) + (minimum walking time from s' to c'), and y = x + 2 (estimated WaitGetOn time for the route in the graph). In other embodiments, both ends are scaled by multiple standard deviations of the random variables. In other embodiments, we limit the walking time from c to s and from s' to c' to at most some fixed time, e.g., 1 hour. In other embodiments, any of the walks may be of zero length (optional walk). In other embodiments, we require a minimum walking time from c to s or from s' to c'. In other embodiments, the walks may have an implementation as in section 4.2.3. In other embodiments, Tcc'ss' is non-uniform. In other embodiments, Tcc'ss' is conditional on the passenger's arrival time at c's location. In other embodiments, we use one variable for each of many time windows.

[0054] Complications arise in that the subway random variables are derived from a fixed subway schedule, resulting in pairwise dependencies of random variables, which can complicate the calculation of the expected minimum travel time from c to c'.

[0055] Consider all subway trips that serve to transport a passenger from c to c', s1, s'1, .., s m , s' m are the random variables Tcc's1s'1,..,Tcc's m s' m Let there be m subway stations with boarding and alighting passengers, each with

[0056] In one embodiment, any one subway random variable is independent along with all bus line random variables, so we calculate the expected minimum travel times for buses and subways as the minimum of the expected minima, and add one subway trip at a time to the bus trip pool, denoted as P(c,c'), as follows: P(c,c') = min E[min(Tcc's j s' j ,Tcc'e1,..,Tcc'e n ], (1) 1≦j≦m P(c,c') is called the prospect travel and represents a trip from c to c' with multiple favorable transportation options. Here, we consider (m+n) constituent random variables Tcc's j s' j ,Tcc'e i are called choices.

[0057] In one embodiment, Tcc'e i is uniform throughout the interval, and Tcc's j s' j In that case, for some number of T i The expected minimum value E[min T i ], each interval [x i ,y i ] is uniform throughout.

[0058] For example, Figure 7 shows a move from c to c', with three choices: · Bus route e' with uniform waiting time and walking & boarding time of 1700 in the section [0,900], "Bus route e" with uniform waiting and walking & boarding 1000 in the section [0,3600], Subway with uniform waiting and walking & boarding 2200 in section [0,300]. In this case, the minimum expected travel time is 2150 = min{2150, 2800, 2350}, which does not reflect any improvement in travel due to "whichever is faster", although the expected minimum is lower: P(c, d) = 1933.

[0059] In another example, Figure 8 shows a probability distribution conditional on the time a passenger arrives at c (the source of the prospective edge). There are two options to get from c to c', one by bus and one by subway. Each option has a conditional probability distribution for waiting, and for walking and riding.

[0060] If the value of P(c,c') is less than the minimum expected value min(min(1≦j≦m) E[Tcc's j s' j ],min (1≦i≦m) E[Tcc'e i ]), there is a gain in the time required for a potential move. In that case, the graph has the following vertex and PROSPECT_CLUSTER_SOURCE_c, and PROSPECT_CLUSTER_TARGET_c', Then add the next edge, labeled AvgMinWalkWaitRideWalk, with weight P(c,c'). PROSPECT_CLUSTER_SOURCE_c →PROSPECT_CLUSTER_TARGET_c'. We also add edges from bus and subway stations in cluster c to the following vertices: PROSPECT_CLUSTER_SOURCE_c, Add to the next vertex, PROSPECT_CLUSTER_TARGET_c' From cluster c', we add edges to bus and subway stations, which are labeled as Zero and have weight zero. In one embodiment, we add a prospective edge only if its weight P(c,c') results in a gain above a threshold, for example at least 10 seconds.

[0061] The method does not require passengers to board the first arriving transportation option simply because later options requiring longer wait times may arrive at the destination sooner (think express vs. regular buses). The method does not require passengers to board the bus at the same stop / station because passengers can walk to another stop / station, for example, in anticipation of an express train departing from there.

[0062] (Definition 1) In one embodiment, the potential movement is defined by: Any two locations c, c', Random variables T1,..,T k , The k variables are independent, dependent, or optionally correlated. Any of the k variables may be conditional on the time A at which the passenger arrives at location c, which may be a random variable. The expected travel time is the minimum value min(T1,..,T k ), which is itself a random variable. The weight of a prospective edge is the expectation of this minimum, P(c,c') = E[min(T1,..,T k )].

[0063] In another embodiment, the random variable T i is uniformly distributed in the interval. i conditional on the arrival time at c, or the probability distribution of arrival times at c, falling within a particular time window.

[0064] In one embodiment, the random variables T1, .., T k To determine c, determine a list of vehicle stops near c and the walking times from c to these stops, and a list of vehicle stops near c' and the walking times from these stops to c', and for each pair of vehicle stops in the two lists, determine a travel time random variable.

[0065] In one embodiment, the random variables min(T1, .., T k ) one is the expectation already mentioned, and another is the probability mass which can be used to determine which arrival times can be reached with a particular probability. Several methods are used to calculate these statistics, including sampling, closed form formulas, approximate integration, and other approximation algorithms or heuristics.

[0066] In one embodiment, components of a potential trip can be pre-computed and stored to avoid retrieving the components from storage and computing the components from scratch when a potential trip needs to be determined. Examples of such components include a random variable for the trip duration between pairs of vehicle stops, an expected minimum of two or more trip duration random variables, a probability distribution of the minimum of at least two trip duration random variables, or a route or trip duration between pairs of vehicle stops.

[0067] So far we have defined how to compute the probabilistic edges for a given c and c'. We apply this definition to every distinct pair of c and c', which determines which probabilistic clusters are connected and which are not, by which probabilistic edges of what weight.

[0068] In one embodiment, instead of considering the quadratics of the c,c' pairs, we perform a graph traversal. In one embodiment, for each c, we consider the vertices, PROSPECT_CLUSTER_SOURCE_c, , all vertices reachable by walk-bus / subway-walk, PROSPECT_CLUSTER_TARGET_c' Use a "forward" traversal in a forward direction until, for each c', PROSPECT_CLUSTER_TARGET_c', Once we have identified all such paths for a particular c', PROSPECT_CLUSTER_SOURCE_c, and PROSPECT_CLUSTER_TARGET_c' We can then compute all alternatives between,c,and,c,and compute the expected minimum of these alternatives (see,Figure 9 for further examples). Since we restrict the search to only the reachable parts of the graph, we can often compute the possible edges more efficiently. In one embodiment, for each,c,, we PROSPECT_CLUSTER_TARGET_c', all vertices reachable by the "reversed" path walk-bus / subway-walk, PROSPECT_CLUSTER_SOURCE_c We use a symmetric method called "backwards" traversal backwards until

[0069] FIG. 9 illustrates an embodiment of a process for adding a potential edge to graph G0 when all waiting times are uniformly distributed in the interval [0, 2WaitGetOn] of each edge and the ride time is deterministic.

[0070] (4.3 Extending graph G0) We describe extensions of graph G0, where each extension is useful for a particular type of routing query.

[0071] (4.3.1 Source Known) In some embodiments, the source location of a routing query is known in advance. For example, suppose we are interested in finding the shortest route from all restaurants in a metropolitan area, and the locations of the restaurants are known. This can be achieved using the augmented graph G0.

[0072] In one embodiment, for each such source s, add the following vertices: SOURCE_s. See Figure 1. In one embodiment, SOURCE_s From any bus stop or metro station cluster STOPSTATION_CLUSTER_SOURCE_c Add an edge going to G0. The edge is labeled Walk and its weight represents the duration of the walk. In other embodiments, the shortest walk with duration at most a threshold is used, or other embodiments as in Section 4.2.3.

[0073] The resulting graph is denoted as G1 (including G0). G1 can be any SOURCE_s From any STOPSTATION_CLUSTER_TARGET_c In one embodiment, when a query is presented, several paths are pre-computed, saved, and retrieved from storage.

[0074] In another embodiment, when the targets are known in advance, a symmetric method is used: for each target t, add the following vertices: TARGET_t, Any STOPSTATION_CLUSTER_TARGET_c Any TARGET_t We add an edge,labeled Walk,to,G1,. The resulting graph is denoted as,G1'.

[0075] (4.3.2 Target Known) In some embodiments, the target location of a routing query is known in advance, and we extend G0 with potential edges to the target.

[0076] For each target t, add the following vertices: TARGET_t. See Figure 1. In one embodiment, bus stop and subway station clusters in graph G0 STOPSTATION_CLUSTER_TARGET_c from, TARGET_t, , where x is the number of edges between the first and second nodes. The edge is labeled Walk and its weight represents the duration of the walk. In other embodiments, we use the shortest walk with duration at most a threshold, or other embodiments as in Section 4.2.3.

[0077] Add potential edges by following the same process as in Section 4.2.5. Specifically, for any PROSPECT_CLUSTER_SOURCE_c and TARGET_t, For,c,, determine all paths from,c,to,t,for the following two types. (1) Graph route for walking to catch a bus: Walk from c to b, BUS_STOP_b →BUS_AT_BUS_STOP_b_i_e →BUS_AT_BUS_STOP_b'_j_e →BUS_STOP_b' →STOPSTATION_CLUSTER_TARGET_c” →TARGET_t, (2) Graph route for taking the subway by foot: Walk from c to s' SUBWAY_STATION_s' →SUBWAY_FROM_TO_s'_s” →SUBWAY_STATION_s” →STOPSTATION_CLUSTER_TARGET_c' →TARGET_t. In other embodiments, we use the shortest walk with travel time at most up to a threshold, or other embodiments as in Section 4.2.3. Define random variables for travel time along each route as in Section 4.2.5.

[0078] In one embodiment, we assume that type (1) are independent random variables and type (2) are non-independent. We then consider the pool of all type (1) random variables (suitably removing overlaps for repeated bus routes) and calculate the expected minimum trip time by adding to the pool of type (2) random variables, one at a time, as in Equation 1 for P(c,c'). In another embodiment, we use Definition 1 of Expected Trips, which defines P(c,t), called the expected trip from c to t.

[0079] If there is a gain in travel time beyond the minimum expected PROSPECT_CLUSTER_SOURCE_c from, TARGET_t An edge is added up to c,t, which has weight P(c,t) and is labeled AvgMinWalkWaitRideWalk. From PROSPECT_CLUSTER_SOURCE_c, PROSPECT_CLUSTER_TARGET_c' Similar embodiments are used for these as for the previously defined edges up to .

[0080] In one embodiment, for all c and t, using "forward" or "backward" graph traversal as described in Section 4.2.5, PROSPECT_CLUSTER_SOURCE_c, and TARGET_t, in order to speed up the computation of potential edges between G0 and G1. In other embodiments, this traversal can be merged into the traversal when computing potential edges in G0.

[0081] The resulting graph is denoted as G2 (including G0). G2 is any STOPSTATION_CLUSTER_SOURCE_c From any TARGET_t In one embodiment, when a query is presented, several paths are pre-computed, saved, and retrieved from storage.

[0082] In another embodiment, when the sources are known a priori, a symmetric method is used: for each source s, add the following vertices: SOURCE_s, Any, SOURCE_s Any PROSPECT_CLUSTER_TARGET_c Calculate the possible edges to,. The resulting graph is denoted as G2'.

[0083] (4.3.3 Source and target are known when a query is presented) In some embodiments, the target location of a routing query is known in advance, but the source is only revealed when the query is presented.

[0084] In one embodiment, graph G2 from Section 4.3.2 is used to compute the shortest ride.

[0085] Given a query (s,t), determine the walking distance from s's location to each of the following: STOPSTATION_CLUSTER_SOURCE_c. In one embodiment, a shortest walk with a duration at most a threshold is used to generate a list of vehicle stops near the source location, or other embodiments as in section 4.2.3. Also, in graph G2, STOPSTATION_CLUSTER_SOURCE_c from, TARGET_t In one embodiment, the shortest travel continuation is determined to STOPSTATION_CLUSTER_SOURCE_c From each of TARGET_t, Pre-compute the shortest path time to and store the results. When a query is posed, retrieve these results from storage. In another embodiment, use a shortest path algorithm graph in G2 to compute the time when a query is posed.

[0086] Find a cluster c that minimizes the sum of the time it takes to walk from s to c and the time it takes to travel from c to t. This minimum is the shortest travel time from s to t.

[0087] In another embodiment, a symmetric method is used when the target is only revealed when the query is presented: Then, instead of generating a list of vehicle stops near the source location, a list of vehicle stops near the target location is generated.

[0088] In another embodiment, instead of using graph G2, graph G1' is used.

[0089] (4.3.4 Target and source are known when query is presented) In some embodiments, the source location of a routing query is known in advance, but the target is only revealed when the query is presented.

[0090] In one embodiment, we use graph G1 from Section 4.3.1 to compute the shortest ride, except that we need to compute the likely edges to the target, which is more complicated than Section 4.3.2 because the target is not known a priori.

[0091] Recall how the choice is computed for each possible edge in G0. For each cluster c and c', define the choice (c,c') as PROSPECT_CLUSTER_SOURCE_c from, PROSPECT_CLUSTER_TARGET_c' Let P(c,c') be the choice used to compute P(c,c') for an edge to G0. Choice (c,c') can have only one choice (e.g., one bus, one subway, etc.). Choice (c,c') is defined even if a potential edge was not added to G0 because it did not have enough payoff.

[0092] In graph G1, the following source: SOURCE_s And let (s,t) be a query posed for an arbitrary target location,t,that may not be represented in the graph.

[0093] The shortest path from s to t may involve only one bus or only subway. In that case, we do not need to consider the prospective edges. Take a graph G1 and extend it further. Vertices, TARGET_t, And for any c, STOPSTATION_CLUSTER_TARGET_c, from, TARGET_t. Each of these edges is labeled Walk and its weight is the walking time. In one embodiment, any edge represents the shortest walking time with duration at most up to a threshold, or other embodiments as in section 4.2.3. In the resulting graph, SOURCE_s from TARGET_t Calculate the shortest path from s to t, and denote the path length by A(s,t). This length is a candidate for the shortest travel time from s to t.

[0094] There are other candidates: the shortest path may contain more vehicles, in which case there is a stop / station that is the penultimate along the path. To cover this case, we compute the possible edges to t. This process is illustrated in Figure 12. To simplify the diagram, the drawing shows singleton possible clusters (each with only one bus stop or one subway station).

[0095] To compute the possible edges to t, start with a graph G1. Enumerate each part of the trip from s to t that ends at the penultimate stop / station. Specifically, SOURCE_s Then, for each c, PROSPECT_CLUSTER_SOURCE_c, The shortest travel time to c is determined. This travel time is expressed as shortest (s → c). For example, in FIG. SOURCE_s from SUBWAY_STATION_s l The value 900 attached to the edge to SOURCE_s from, PROSPECT_CLUSTER_SOURCE_s1 Graph G1. Note that this move may traverse along any possible edge in graph G1. In one embodiment, this travel time may be precomputed and stored before the query is posed, and retrieved from storage at query time.

[0096] Determine how the trip continues from the penultimate stop / station to the target t using the prospective edges and walks. PROSPECT_CLUSTER_SOURCE_c, First, choose an intermediate called option (c,c'), PROSPECT_CLUSTER_TARGET_c' Determine the option to travel from c to t by moving to and continuing the walk from c' to t. In one embodiment, only the shortest walk from c' to t with a duration at most a threshold is considered, or other embodiments as in Section 4.2.3. For example, in FIG. 12, option (b1,b0) is BUS_STOP_b1 from BUS_STOP_b0 There are two options: bus line e" with uniform waiting time at [0,900] and travel time of 1600; and bus line e'" with uniform waiting time at [0,3600] and travel time of 1000. Then, BUS_STOP_b0 from TARGET_t It takes 240 meters on foot to get there.

[0097] Since passengers at c may choose c' as their continuation, we combine all c' options at t. This combination forms the travel options from c to t. For example, in Figure 12, BUS_STOP_b1 There is another edge from, BUS_STOP_b2 The choice (b1, b2) attached to that edge has only one choice, which is bus route e', with uniform waiting time and travel time of 900 in [0, 300]. Next, BUS_STOP_b2 from TARGET_t It takes 500 meters on foot to get there. By combining options (b1,b0) and options (b1,b2), three options (bus routes e', e", e'") are generated. These are: BUS_STOP_b1 from TARGET_t The expected minimum travel time using these options is 2636.

[0098] As in Section 4.2.5, it is necessary to eliminate duplicate bus rides on the same bus route. For example, in Figure 12, a passenger uses the same bus route e" SUBWAY_STATION_s1 You can start from two different locations, BUS_STOP_b2 and, SUBWAY_STATION_s0 For a bus route at c, we keep only the option for this bus route that has the shortest expected travel time from c to t (eliminating other options for this bus route at c). For example, in Figure 12, SUBWAY_STATION_s0 Choice t has a higher expectation, so it is eliminated. Calculate the expected minimum travel time P(c,t) from the remaining choices in the same way that we calculated P(c,c') in Section 4.2.5.

[0099] Since the shortest path can pass through any of the c's, we calculate the minimum over all the c's and denote it as B(s,t) below. B(s,t)=min c {shortest(s→c)+P(c,t)}. For example, in FIG. 12, the minimum value B(SOURCE_s, TARGET_t)=2445, i.e., min{2636, 2445}, which is the second-to-last passenger. SUBWAY_STATION_s1 Moving to the penultimate BUS_STOP_b1 This is more advantageous than moving to.

[0100] This quantity gives the shortest travel time from s to t, including the penultimate vehicle. B(s,t) is another candidate for the shortest travel time from s to t.

[0101] Finally, the response to the query is the minimum of the two candidates: min{A(s,t),B(s,t)}.

[0102] For example, in FIG. 12, the response to the query is still 2445, which means SOURCE_s from, BUS_STOP_b0 Through TARGET_t The travel time cannot be shortened by using only one vehicle that travels to the destination, and the travel time is A(SOURCE_s, TARGET_t)=3000+240.

[0103] In another embodiment, instead of using graph G1, graph G2' is used.

[0104] In another embodiment, where the source is only revealed when the query is presented, we use a symmetric method to calculate the likely edges from the source, so instead of considering the penultimate and last stops before reaching the target, we consider the first and second stops after leaving the source.

[0105] (4.3.5 Sources and Targets Revealed at Query Time) When both the source and target of a query are unknown in advance, we select and combine the methods from the previous section. In one embodiment, from the location of the source s, for each c, STOPSTATION_CLUSTER_SOURCE_c, Determine the distance to STOPSTATION_CLUSTER_SOURCE_c Move from to target t (with or without the penultimate choice). Respond with the minimum sum selected in c. In one embodiment, use the shortest walk with time taken at most to the threshold, or other embodiments as in section 4.2.3.

[0106] (4.4 Modifications) Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the embodiments. For illustrative purposes, some variations are presented.

[0107] In one embodiment, we use a more general notion of a prospective edge. If a trip involves multiple vehicles and waits, then the shortest path search in the graph may traverse multiple prospective edges, and these prospective edges along the path together abstract multiple wait-ride chains. To capture this multiplicity, in one embodiment, we use a more general notion of a prospective edge of depth d, which abstracts up to d wait-ride chains. For example, the path c-walk1-wait1-bus1-walk2-wait2-bus2-walk3-c' can be abstracted as a prospective edge of depth 2 from c to c'. In one embodiment, for d greater than 1, we add a prospective edge of depth d to the graph.

[0108] In one embodiment, the method builds a route given a departure time. For example, consider a passenger starting a trip at 8 a.m. on Tuesday. Here, the routing query specifies a source location and a target location as well as a departure time. In one embodiment, the source: STOPSTATION_CLUSTER_SOURCE_s, and the target is STOPSTATION_CLUSTER_TARGET_t We modify the graph G0 (see Figure 1) by adding the FirstWaitGetOn edge, and the SUBWAY_FROM_s Remove vertices and , and for any b and s in cluster c, STOPSTATION_CLUSTER_SOURCE_c from, BUS_STOP_b and SUBWAY_STATION_s, In one embodiment, we employ Dijkstra's shortest path algorithm to use the potential edges. PROSPECT_CLUSTER_SOURCE_c For each, we maintain the lowest known expected arrival time of a passenger at the vertex and use this time to adjust the waiting, walking, and ride time random variables. PROSPECT_CLUSTER_TARGET_c' Using the edge weights calculated in this way, PROSPECT_CLUSTER_SOURCE_c' In another embodiment, each known minimum expected arrival time is updated by PROSPECT_CLUSTER_SOURCE_c or PROSPECT_CLUSTER_TARGET_c In other embodiments, other shortest path algorithms, such as A in a similar manner, may be used. * (A-star) search algorithm is employed. In other embodiments, for example when the departure time is "now / soon", conditional random variables are calculated using the state of the transportation system at the time of the query, providing a more accurate distribution of wait times and ride durations.

[0109] In one embodiment, the method constructs routes given arrival deadlines. For example, consider a passenger who wants to arrive at a destination before 9am on Tuesday. This is equivalent to departing from the target at 9am, but going backwards in time and space. This can be easily abstracted by constructing the graph in the appropriate reverse (buses and subways move in reverse time and space).

[0110] In one embodiment, we determine a potential trip that satisfies a desired probability of arrival p before the final deadline. When considering a potential edge from c to d, we use a random variable A that indicates the passenger's arrival time at c. We then use a selection to find k random variables T1, . . . , T k Given A+T1,..,A+T k) to determine the distribution of arrival times at c'. Then, determine up to what time t this distribution has mass with the desired probability p.

[0111] In one embodiment, we report the vehicles along the shortest path, or the arrival / departure times for each point along the path. This information can be easily read from the path in the graph and the possible edge choices along the path.

[0112] In one embodiment, we answer routing queries on computing devices that have limited storage and limited communication with backend servers. For example, this may occur on a mobile phone of a user who is concerned about privacy. In that case, we use an appropriately small number of clusters in graph G0. Similar techniques can be used for other graphs.

[0113] In one embodiment, requirements are imposed on the routing response, including maximum walking time, maximum number of transfers, maximum waiting time, and restrictions to certain types of vehicles (e.g., only use rapid buses and subways). The invention achieves these requirements through appropriate modifications of the graph and a shortest path algorithm on the graph.

[0114] In one embodiment, the method is applied to an incomplete graph. For example, the weight of edge WaitGetOn may not accurately reflect the expected waiting time for the subway, perhaps because it misestimated the time or used bus vertices and edges that do not exist in the metropolitan area, perhaps the bus route was canceled by the city government and the method did not notice the cancellation, or perhaps it sampled the expected minimum of the options with a large error or used an approximation formula / algorithm. These are just a few examples of incompleteness. In any case, the method is still applicable; it just generates routes with some errors.

[0115] In one embodiment, we remove unnecessary vertices and edges from the graph. For example, the "pass" vertices in G0, SUBWAY_AVG_FROM_TO_s'_s” is removed by blending the incoming and outgoing edges.

[0116] In one embodiment, the method steps are applied in another order, for example, when constructing graph G0, the order described in sections 4.2.1 and 4.2.2 can be reversed, first adding the vertices and edges of non-fixed timetable vehicles, and then adding the vertices and edges of fixed timetable vehicles.

[0117] In one embodiment, the method is parallelized. For example, PROSPECT_CLUSTER_SOURCE_c Instead of computing the potential edge from each of c1 and c2, consider any two c1 and c2. PROSPECT_CLUSTER_SOURCE_c1 When calculating the expected edge from PROSPECT_CLUSTER_SOURCE_c2 This is done in parallel with the calculation of the expected edge from

[0118] (5 Computer Systems) One embodiment of the present invention is a computer system that responds to routing queries.

[0119] In one embodiment, the system responds to queries for the shortest route between locations given a departure time: where any query has a predefined format (source, target, minuteOfDay). Responses are in the format of duration, route with alternatives. An illustration of the embodiment is in FIG. 13.

[0120] The term "module" is used herein. This term is known in the art to mean a computer (sub)system providing a particular function. This choice to divide the computer system into specific modules is exemplary and not required. Those skilled in the art will recognize that the system can be organized into modules in other ways without departing from the scope of the present invention.

[0121] A module (1202) of the system reads information about the metropolitan transportation system from multiple data sources (1201). This module determines which vehicles, routes, or parts thereof are considered to be fixed-timetable and which are non-fixed-timetable. This module calculates routes for fixed-timetable vehicles. This module also calculates distributions of waiting and boarding times based on the times of non-fixed-timetable vehicles.

[0122] The output is passed to a module (1204) that computes probabilistic edges. The module queries information about walking from multiple data sources (1203). For selected probabilistic clusters c and c', and the passenger's arrival time at c, the module computes the weights P(c, c') of the probabilistic edges and preferences using a random variable conditional on the passenger's arrival time at c. The results are saved in storage (1205).

[0123] Modules 1202 and 1204 operate continuously, so that the system maintains a new model of the transportation system.

[0124] Meanwhile, another module (1206) pre-computes the shortest paths. The module builds a graph connecting the locations by reading potential edges from (1205) and non-potential edges from (1202) from time to time. For selected queries of a given type (stop / station cluster source, stop / station cluster target, minuteOfDay), a shortest path algorithm is applied to the graph to compute a path. The results are stored so that they can be retrieved later from storage (1207) when needed.

[0125] At the same time, the query response module (1208) responds to the query. When a query (source, target, minuteOfDay) (1209) arrives, the module calculates the shortest path according to section 4. The module contacts (1203) to determine the walk between the source and target, and the stop / station cluster. The module retrieves the relevant pre-calculated shortest path from (1207). If needed but not yet available, the module requests the shortest path from module (1206) and saves the resulting shortest path in storage (1207) for future use. The module (1208) also retrieves alternatives and times from (1205). These walks, shortest paths, and alternatives are combined to generate a response to the query (1210).

[0126] Aspects of the invention may take the form of hardware embodiments, software embodiments, or a combination of the two. Steps of the invention, including any flow chart block, may be performed out of order, partially in parallel, or provided from a repository, depending on functionality and optimization. Aspects may take the form of sequential or parallel / distributed systems, with each component implementing some aspects that may overlap with other components, and the components may communicate, for example, using any type of network. Computer programs performing operations for aspects of the invention may be written in any programming language, including C++, Java, or JavaScript. Any program may execute on any hardware platform, including a central processing unit (CPU), a graphics processing unit (GPU), and associated memory and storage devices. Programs may execute aspects of the invention on one or more software platforms, including, but not limited to, smartphones running operating systems such as Android or iOS, or web browsers including Firefox, Chrome, Internet Explorer, or Safari.

[0127] (6 Computer Service Products) One embodiment of the present invention is a service product, such as a smartphone application or a web page, available to a user through a user-facing device. It will be apparent to those skilled in the art that the present invention is not limited to these devices. It will also be apparent that the representation of the service in the drawings can be modified (including rearrangement, resizing, color, shape change, adding or removing components) without departing from the scope of the present invention.

[0128] In one embodiment, the service is accessed from a smartphone application. The user interacts with the application's user interface on the smartphone to specify the departure time, source, and destination. The service then generates a route and displays the route on the smartphone. Figure 14 shows an example result of a query departing from A to L at 8am.

[0129] In one embodiment, the service reports which option currently results in the shortest travel time. In one embodiment, the system highlights this faster option (shown at 1401 on the route), indicates the travel time of that option, or indicates the current waiting time (shown at 1402 near D). In one embodiment, this faster option is calculated given the vehicle's current location. In one embodiment, this report is shown when the user is currently near the location of the option, e.g., if the user is starting from A, the service indicates that in the current situation it may be faster to reach F via D and E instead of via B and C.

[0130] In one embodiment, the service shows the current wait time for each option among a selection of locations (shown at 1403 near F) or the expected ride time for each option (shown at 1404), which can help the user make their own choices, even if they are not optimal.

[0131] In one embodiment, the service reports one expected wait time for all options at a location, which is the expected wait time assuming the user takes the option that achieves the minimum expected travel time (shown at 1405 near the H). In one embodiment, this report is shown when the vehicle location is uncertain, for example for parts of the route that are far down the road compared to the user's current location. This informs the user how long they will be idle at the stop / station waiting for a vehicle.

[0132] In one embodiment, the service reports the expected travel time between two locations (indicated by 1406 on the route), a value denoted as P(c,c') in Section 4.

[0133] In one embodiment, the service responds to the user with at least one of the following: 1. Source location shown on map. 2. Target location shown on the map. 3. The locations of any stops shown on the map along the route. 4. A series of stop locations shown on a map along a route. 5. The name, address, or identifier of either the source location, the target location, or a stop along the route. 6. Departure time. 7. Departure Time Range. 8. Arrival time. 9. Arrival time range. 10. Probability of arriving before the deadline. 11. A series of locations along multiple choices between two locations shown on a map. 12. Instructions for the walking component in any selection. 13. Location or duration of waiting components in any selection. 14. Instructions for ride components in any selection. 15. The expected minimum waiting time for at least two options. 16. Current minimum waiting time for at least two options. 17. The expected travel time for any component or option of the choice, or the minimum expected travel time among at least two options. 18. The current travel time for any component or option of the choice, or the minimum travel time among at least two options. 19. The expected departure time or expected arrival time for any component, option, or the minimum of at least two options within the option. 20. The current departure time or the current arrival time for any component, choice, or the minimum of at least two choices in the choice. 21. The name or identifier of any vehicle in any of the options. 22. Any vehicle name, address, or stop identifier in any selection. 23. The current location of any vehicle in any selection. 24. Suggestion of which option among two or more options would be presented most quickly given the vehicle's current location.

[0134] (7 Claims) Those skilled in the art will recognize that various modifications can be made and essentially equivalents can be substituted without departing from the scope of the invention. Moreover, particular situations can be adapted to the teachings of the invention without departing from its scope. Therefore, although the invention has been described with reference to disclosed embodiments, it is not intended to be limited to those embodiments. Rather, the invention includes all embodiments falling within the scope of the appended claims.

Claims

[Claim 1] A method for providing information indicating a route for travel from a source location to a target location; The method includes: (a) receiving a query including the source location and the target location; (b) generating said information; and (c) responding to the query with the information; The method is characterized by: (d) determining a graph path, where the graph path is a path between a graph vertex within a first distance threshold from the source location and a graph vertex within a second distance threshold from the target location; wherein the graph paths are included in a graph, the graph including: (i) a plurality of graph vertices, where at least two graph vertices representing locations are included in the plurality of graph vertices; and (ii) a plurality of graph edges, wherein at least two graph edges representing travel times are included in the plurality of graph edges; wherein the graph path includes at least two prospect edges; Here: (iii) each prospective edge is included in the plurality of graph edges; (iv) each potential edge leads from a source vertex of the potential edge to a destination vertex of the potential edge, both the source vertex and the destination vertex being included in the plurality of graph vertices; and (v) each prospect edge is calculated by determining two or more prospect routes; Here: (A) each potential route represents the movement from the location of the starting vertex to the location of the destination vertex; and (B) each possible route is a travel option included in the route of the travel; and (e) using said two or more probable routes when generating said information;

Images