Patent Grant
11551325
A travel coordination system receives requests from clients (e.g., “riders”) for transportation to a destination. The travel coordination system identifies a provider for the trip and directs the provider to pick up the rider. Typically, the rider designates the rider's location as the location for the provider to pick up the rider and begin the trip. This manual determination of pickup location can often yield pickup locations that are not optimized for actual road conditions, or may delay pick up time or total trip time due to poorly-chosen pickup locations by users. Users may also need to contact the provider to adjust a pick up location, for example to cross the street, or because the initially-proposed pickup location is not suitable for the pickup. In addition, the manual selection of a pickup location can add an additional step in the user's request for trip services.
A travel coordination system automatically selects pickup locations for a trip to efficiently facilitate transport or delivery services for requesting users. For example, when an individual user or client of a network service makes a request for a transport service, the system can determine a pickup location for the transport service to reduce the amount of distance traveled by a provider, reduce the amount of time spent traveling by a provider, reduce the amount of time the client has to wait, and/or improve the overall efficiency of the network service. The system can instruct both a selected provider and the client to travel to the selected pickup location.
In some embodiments, the travel coordination system associates eligible pickup locations with individual regions, which may represent city blocks, buildings, individual portions of buildings, or other geographic areas. In these embodiments, the travel coordination system determines a region in which the user is located and selects a pickup location from the region associated with the user. In addition, the regions may be hierarchically organized, such as a portion of a building within a building, and the travel coordination system may consider one or more regions in the hierarchy that include the user's location for considering eligible pickup locations. For example, the travel coordination system may initially evaluate pickup locations associated with the smallest-size region, and evaluate additional regions in the hierarchy when those pickup regions do not provide a favorable trip time or when other conditions occur.
In addition, while a provider is en route (e.g., traveling) to an initially-selected pick up location, the travel coordination system may evaluate alternative eligible pickup locations and suggest an alternate pickup location before the pickup occurs. Information about the alternate pickup location and associated information can be provided to the rider's device, so as to inform the rider about the option to change pickup locations and to educate the rider about the potential results of changing pickup locations.
The travel coordination system 130 identifies a provider to provide the on-demand trip for the client. Typically, to provide a trip, a selected provider operates a car or other vehicle (e.g., bus, boat, etc.) and picks the client up from the pickup location of the client and takes the client to the destination. There may be many providers available to provide the trip, each operating a provider device 110, and each of whom may be located at different distances from the client or a specified location provided by the client. As described herein, an amount of time associated with a trip can include an amount of time for a provider to reach the pickup location of the client, and an amount of time for the provider to reach the destination location of the client. The time for a provider to reach the pickup location of the client is termed the estimated time of arrival, or ETA, and the time to reach the destination location from the pickup location is termed the estimated destination time, or ETD. The total time for a trip can be represented by the sum of the ETA and ETD. In some examples, the total time for a trip is the sum of the ETA, the ETD, and a predefined amount of time to represent the time it takes for the client to actually find and enter the vehicle and/or a predefined amount of time to represent the time it takes for the client to exit the vehicle. To reduce the total time for a trip and improve pickup of the client by the provider, the travel coordination system 130 may suggest a pickup location for the client, rather than using the client's current location or specified pickup location (e.g., a location corresponding to an address or a location indicated by a graphic pin on a map specified by the client).
The client device 100 and provider device 110 are electronic (e.g., computing) devices that can communicate with the travel coordination system 130. These devices may be portable or handheld devices that communicate with the travel coordination system 130 via a network 120. Typical devices include smart phones, portable data devices (PDAs), laptops, and other such devices. Each client device 100 and provider device 110 can store and run a respective client application that can communicate with the travel coordination system 130. For example, the client device 100 may execute an application that provides a user interface to enable the client to request a trip. In other examples, the client device 100 may be a fixed station for coordinating travel for clients.
The client device 100 can also include a location detection or positioning system, such as a global positioning satellite (GPS) sensor or receiver, or other method for determining the location of the client device 100. In some examples, when the client device 100 requests a trip from the travel coordination system 130, it provides a location of the client device 100 by communicating with the GPS sensor. As further described with respect to
According to some examples, the client may indicate to the travel coordination system 130 that the client is willing to travel (e.g., walk) to a location suggested by the travel coordination system 130. The client may indicate the client's willingness to walk a maximum distance by opting in or agreeing to an option via a user interface of the client application (e.g., before, after, or during trip request). As an addition or an alternative, the client may specify the pickup location, before or after a suggested location is provided by the travel coordination system 130. Still further, in another example, after a trip is requested, the client may also move to another location, such that the actual pickup location for a trip differs from the suggested location or the pickup location selected by the client. When the trip begins (i.e., the client enters the provider's vehicle and/or the provider begins the trip by providing input in the provider's application), the client device 100 or provider device 110 may report the actual pickup location of the beginning of the trip to the travel coordination system 130.
In addition, the client of the client device 100 may indicate to the travel coordination system 130 that the client is willing to “pool” with another client. In some examples, the client may select a “pool” vehicle type or service type on the client application when making the trip request. When pooling with another client, the provider may pick up more than one client from one area who are both headed to different destinations. As further described below, the travel coordination system 130 may coordinate the pickup location for a second client in a trip (i.e., to join a first client) based on the trip already in progress for the first client.
To determine a pickup location for the client, the travel coordination system 130 identifies eligible pickup locations for the trip based on a region specified by the client (and/or based on a location specified by the client), and scores the eligible pickup locations to suggest a location to the client.
According to various examples, the travel coordination system 130 includes various modules and data stores for providing trip coordination between clients and providers. In this example, the travel coordination system 130 includes a selection module 140, a pickup location module 145, a trip monitor 150, region pickup module 155, a routing module 160, a region datastore 165, a trip datastore 170, a mapping datastore 175, and a pickup location datastore 180. In various embodiments, more or fewer modules and datastores may be used by the travel coordination system, and certain elements may be provided by other external systems in communication with the travel coordination system 130. For example, the mapping datastore 175 and routing module 160 in some embodiments are provided by an external mapping service, rather than as a part of the travel coordination system 130.
The trip datastore 170 maintains a record of each completed and in-progress trip coordinated by the travel coordination system 130. The record of each trip may indicate the client, provider, the pickup location, the destination location, the vehicle type, the route traveled, the duration of time, the fare, etc., for the trip. As applicable, the trip datastore 170 may include any suggested pickup location, pickup locations designated by the client, and the actual pickup location of the trip.
The mapping datastore 175 maintains data describing data relating to navigation and mapping. For example, the mapping datastore 175 may include locations, points of interest, roads and other mapping detail. In some embodiments, the mapping datastore 175 may also include short-term data reflecting short-term effects on routing and navigation, such as construction, traffic, weather, or events. This data may also be maintained by a separate system or datastore.
In some examples, the pickup location datastore 180 stores predetermined location data points corresponding to locations that may be selected for suggested pickup locations. The determination of these predetermined location data points is described below, and may reflect where previous trip pickup locations and trip destination locations have (and have not) occurred in a given region. For example, one predetermined location data point for a city (which may have many predetermined location data points) can be a location where a large number of pickups have occurred on a street or street corner that is frequented by people and/or vehicles. The predetermined location data points may be used to determine eligible pickup locations for a trip, and may be determined, as described below, by the pickup location module 145.
In some examples, the travel coordination system 130 includes a region datastore 165. The region datastore 165 maintains a set of regions and a set of predetermined location data points for each region. Each region defines a geographical area, such that a given location can be determined as within one or more regions. Each predetermined location data point may also be associated with more than one region. The regions may overlap, and may be hierarchically-arranged (i.e., one region may be a geographical subset of another region). As examples, one region may be the city of New York. Several further regions may be included within the City of New York region, such as a region corresponding to the “upper east side” or “Rockefeller Center.” Regions may also include smaller geographic areas, such as a city block, a building, or a portion of or lot of a building. Similar, a park may be designated as a region, and different portions of the park may also be designated as regions hierarchically belonging to the park. The regions and associated predetermined data points may be determined by the region pickup module 155 as described below. Each region may also be associated with one or more addresses (though typically defines only one contiguous geographic area), and may be associated with structured data about the region that may include additional details of the region, such as a name of the region (“central park”). In some instances, an associated region is identified for a trip request, and the pickup location is selected from among the predetermined location data points for that region.
When a request is received by the travel coordination system 130 from a client device 100, the travel coordination system 130 can determine the client identifier, the vehicle or service type, the user-specified pickup location or current location of the client device 100 or pickup region (referred to herein as “specified pickup location”), and/or the destination location. The selection module 140 coordinates the selection of providers for trip requests by evaluating and selecting a provider for the trip.
According to an example, when the travel coordination system 130 receives a request for a trip, the selection module 140 identifies the specified pickup location, and determines a set or pool of providers that are within a predetermined distance or predetermined ETA away from the specified pickup location and are capable of being able to provide the trip for the client (e.g., has an availability state). The travel coordination system 130 can periodically receive locations and state information of providers from the providers' applications running on the provider devices 120 and store/update the information in a provider database (not illustrated in
Still further, in one example, a pickup location module 145 determines eligible pickup locations from the mapping datastore 175 or the pickup location datastore 180 based on the location of the client or the specified pickup location. The eligible pickup locations can correspond to predetermined location data points near the specified pickup location that are eligible to be selected as the suggested pickup location for the trip. For example, the pickup location module 145 can determine eligible pickup locations from predetermined location data points that are within a predetermined distance or predetermined estimated travel time by walking (e.g., at a standard rate) from the specified pickup location. In another example, the travel coordination system 130 can transmit data of the eligible pickup locations to the client device 100 so that graphic indicators corresponding to the eligible pickup locations may be displayed in a user interface.
The pickup location module 145 can determine and suggest a pickup location for the client for a trip. To determine the pickup location, the pickup location module 145 determines predetermined location data points, and identifies eligible pickup locations from the predetermined location data points. The predetermined location data points may be stored in the pickup location datastore 180. The pickup location module 145 can use historical trip information from the trip datastore 160 to determine the location data points. The historical trip information reflects the locations that users actually used for trips, and therefore may reflect favorable places for trip pickup, without requiring clients to specifically designate areas as good or bad pickup areas. In some examples, rather than predetermining the location data points, the location data points may be determined when a trip is requested by a client. In addition, a pickup location may be determined after a provider is en route to the client, and may suggest a modification to an initial pickup location.
The pickup location module 145 determines eligible pickup locations from the predetermined location data points, and then scores the eligible pickup locations to determine which, if any, to suggest to the user. The scoring may be based on a cost for a provider to reach the eligible pickup location and the cost for the provider to reach the destination from the eligible pickup location, so that the total travel time for a provider (and thus the trip) may be reduced or minimized. Various processes used by the pickup location module 145 for suggesting a pickup location is more fully discussed with respect to
The trip monitor 150 monitors trips that are assigned to providers and/or are in-progress (e.g., not yet complete). For example, the trip monitor 150 may receive information (e.g., periodically receive status and/or location information) from provider devices 110 while the provider travels to the destination for a trip. In particular, the trip monitor 150 may maintain a list of in-progress trips that are eligible for pooling with new client trip requests. The trip monitor 150 thus provides information to the selection module 140 or the pickup location module 145 for selecting an in-progress trip as a provider for a new trip. When a trip concludes, the trip monitor 150 notifies the selection module 140 to determine the price of the trip and bill the client, and the trip monitor 150 stores the resulting trip details in the trip datastore 160.
The region pickup module 155 identifies a set of regions and identifies associations of location data points with each region. For example, the region pickup module 155 can determine, based on the specified pickup location information (e.g., a lat/long coordinate of the pin, an address, or a structured object), one or more regions applicable to that pickup location. Each location data point associated with a region designates a location data point from which a pickup may occur from that region. As noted above, regions define a geographical area, such as city block, building, or portion of a building. Each region may be provided by mapping data from the mapping datastore 175 or may be retrieved from external data sources. A region may also be determined based on maps or other information provided by mapping services or building owners, who may provide layout and other configuration information for a building itself.
The region pickup module 155 may also automatically determine regions based on the location and orientation of roads and buildings. For example, the region pickup module 155 may automatically identify a region for each city block or area enclosed by roads. In addition, the region pickup module 155 may automatically identify a region for each building, and optionally associate that building with the city block in which the building is located. Each city block may also automatically be associated with a region for each sidewalk between roads on the city block. Regions may also be automatically determined based on the location of clients that request rides. For example, the trip datastore 170 may retain the location of a client when the client requested a trip from the travel coordination system, as well as the location that a client was picked up to begin the trip. The locations of clients when requesting trips may be clustered to identify regions associated with each cluster of users. Such clusters may represent distinct geographic areas of a building, such as a front or back lobby, or different stores within a mall. The locations of clients may be clustered at varying levels of granularity (e.g., an increasing number of clusters) to generate a hierarchy of regions. For example, locations in a city block may be initially clustered to identify regions that may correspond to sidewalks and buildings within the city block, and locations within the buildings may be clustered to identify portions of the building from which users request trips.
For example,
While the building region 200 may be associated with each of the location data points 220A-H, each store region 210 may be associated with a different set of location data points to serve as pickup locations from that store region 210. For example, store region 210A may be associated with location data points 220D and 220E. To determine associations between regions and location data points, the region pickup module 155 identifies trips that originate in each region and identifies which location data points are actually used by clients when beginning trips from that region. Outlier location data points may be excluded, or those that are not used at least a threshold quantity or percentage of trips. Accordingly, while the building region 200 may be associated with many location data points 220A-H at the exits of the building, the store region 210A may only be associated with regions 220D and 220E when users from this region only use these location data points from this region. As discussed further below, these regions may be used to more accurately suggest pickup locations from each region, while also permitting consideration of additional pickup locations from a larger region (i.e., of which the current region is a subset) under certain conditions. For example, a user located at location 230 (or alternatively, a pickup location specified by the user at location 230) may be identified as both within store region 210A and in building region 200. The pickup location module 145 may consider the location data points associated with store region 210A initially, and secondarily consider the location data points associated with the building region 200 when the location data points associated with store region 210A do not score well for the trip.
Returning to
In this example method, the travel coordination system 130 determines 300 location data points prior to receiving a client trip request (i.e., the travel coordination system 130 determines possible locations for suggesting a pickup prior to receiving individual client trip requests). These predetermined location data points may be stored in the pickup location datastore 180. To determine the location data points, in one example the location data points include any intersection between roads, and may include corners of each intersection as a location data point (i.e., as a possible pickup location to select for a trip). In another example, the location data points may be selected based on the pickup locations of previous trips. To determine these pickup locations for prior trips, prior trip information is retrieved from the trip datastore 170. These pickup locations may include any actual pickup location (i.e., the location at which a client was actually picked up), or pickup locations specified by a client, which may differ from the actual pickup location for a trip. In one embodiment, the location data points do not consider trips from the trip datastore 160 that had a pickup location suggested by the travel coordination system 130, to permit actual user pickups to continue to affect the suggested pickups. From the pickup locations in the trip datastore 160, the pickup location module 145 may group the pickup locations into clusters based on distance from one another, and from within one cluster select one location as a location data point. To select this location data point from within a cluster of locations, the pickup location module 145 identifies a most frequently used pickup location or identifies a “center of mass” within the cluster. The “center of mass” may be determined by averaging the locations of the pickups within the cluster. Additional or alternative methods of selecting a location data point from within a region may also be used. In another example, the eligible pickup locations may include any location along a street that is not excluded as indicated below. These methods may also be used in combination with one another, for example to include each intersection as well as eligible pickup locations from a center-of-mass for past pickups for a region. After determining these location data points, they may be stored in the pickup location datastore 180 for association with various regions in the region datastore 165. The determination of location data points 300 may also be performed asynchronously from any individual trip request, and updated at various times, such as each day, week, or month.
From each of these methods, the pickup location module 145 may also exclude as a location data point those locations from which no pickup has occurred. These locations may indicate undesirable or impossible locations for a pickup, though those locations may be at an intersection or otherwise appear accessible from the mapping data at mapping datastore 165. Since no trips actually originate from that location, these locations may represent poor locations for a pickup and be excluded as pickup locations.
Next, the travel coordination system 130 receives 305 a client trip request for a client and identifies 210 the specified location of the client requesting the trip. The client trip request 305 may provide a specified pickup location from the client. In some examples, the client trip request also includes the destination, the user identifier, a device identifier, and/or other settings for the trip, such as whether the client is willing to pool with other clients for a trip, or a vehicle type, etc. The travel coordination system 130 identifies 310 the specified location of the trip from the client device 100. The specified location may be the location of the client device, or may be another location specified by the client. Next, the travel coordination system 130 then identifies 315 eligible pickup locations for the trip. The eligible pickup locations 315 are those locations among the location data points that may be a pickup location for this particular trip. The eligible pickup locations may be limited by a threshold distance or walking time from the specified client location. For example, the eligible pickup locations may only be selected from within 150 meters of the specified client current location. This threshold may be set by an operator of the travel coordination system 130, or may be configurable by a client. Within this threshold distance, the eligible pickup locations may be selected from the location data points, for example by selecting all location data points within the threshold distance.
After identifying 315 eligible pickup locations, the eligible locations may also be reduced to a maximum number of eligible locations, for example five or ten. In some examples, such as when the user does not select the pickup location (e.g., a specific pickup location is selected by the travel coordination system 130), the eligible locations are not reduced and all eligible locations may be subsequently scored 335. To select which eligible locations to include after reducing to the maximum number, heuristics or other criteria may be applied to eliminate eligible pickup locations that are within a specified distance of one another, for example to remove pickup locations within ten meters of another pickup location, though other threshold distances may be used.
In this example, the received 305 client trip request did not provide the destination for the trip, such that the eligible pickup locations are sent 320 to the client device 100 for display to the user as the user enters a destination for the trip.
The eligible pickup locations may be sent 320 even if the client trip request specified the destination, so that the eligible pickup locations can be displayed as the travel coordination system 130 determines a provider and suggested pickup location for the trip. The eligible pickup locations may be displayed on a map user interface within a radius reflecting the maximum distance of an eligible pickup location, as further shown in
When the user enters the trip destination, the trip destination is sent to the travel coordination system 130, which identifies 325 the destination. After identifying the destination, the travel coordination system 130 identifies 330 a set of providers eligible to provide the trip for the user. The set of providers may be identified from the providers within a threshold distance of the user, and can include providers that indicate to the travel coordination system 130 that they are eligible for accepting trips. When the client indicates that the client is willing to pool with other clients, the set of providers may also include those providers that are already on a trip with a client that is willing to pool, or may include free providers that are willing to provide pooled trips. To select the set of providers, in one embodiment the providers nearest the client location, up to a maximum number, may be selected. Alternatively, all providers within a threshold distance may be included in the set of eligible providers. In other embodiments, when the client indicates a request to pool with another client for a trip, the selection module 140 requests eligible providers from the trip monitor 150 to identify providers on existing trips that pass within a threshold distance and within a threshold time of the client location. These providers may also be excluded if the client's destination is over a threshold distance from a destination of the existing trip for the provider.
In various configurations, the pickup location or provider may be selected first, and in other cases the pickup locations and providers are jointly evaluated to determine the pickup location-provider combination that provides the lowest cost from among the set of possible providers. In alternate embodiments, rather than selecting and evaluating a set of eligible providers, a single provider may be selected, and a pickup location selected for that provider as indicated below. To compare multiple providers, the optimal pickup location for each provider may be identified, and each provider-optimal pickup location scored to select the best score (e.g., with the shortest trip time).
To identify a suggested pickup location for the trip, the eligible pickup locations for are scored 335 for each provider. To score 335 the eligible pickup locations, the pickup location module 145 determines the total cost of travel for each pickup location. The cost of travel for a pickup location is evaluated based on the estimated time to reach the pickup location from the provider's current location (ETA), and the estimated time to reach the destination from the pickup location (ETD). The cost of travel may be determined by the routing module 155. These travel costs may account for the direction of travel of the provider at the time of the request, traffic conditions, and other routing conditions.
To score a provider with an existing client (e.g., a pooled trip), in addition to determining the ETA and the ETD for the eligible pickup location, the cost to reach the destination for the existing client is considered and the expected increase in cost from the additional pickup at the requesting client's location is determined and added to the cost for the eligible pickup location.
In examples in which the pickup location is selected first, the eligible pickup locations may be scored based on the ETD from each eligible pickup location to the destination. After selection of a pickup location, the providers may subsequently be scored based on the ETA to the selected pickup location. This may be used, for example, to permit a client to view pickup location scores and select a pickup location prior to selection of a provider.
In addition to the constraints on selecting an eligible pickup location as indicated above, an eligible pickup location may also be excluded if the estimated time for the client to walk to the pickup location exceeds the time for the provider's ETA, to prevent the provider from waiting at the pickup location. In addition, if the cost improvement relative to the current location of the client is very low (e.g., 1-2 minutes) or relative to the specified pickup location, the eligible pickup location may also be excluded in some embodiments, such that the client's current location or specified pickup location may be used.
In some circumstances, evaluating the cost of the eligible pickup locations may be inefficient and costly. To improve the evaluation of eligible pickup locations, an optimization may be performed to evaluate the pickup locations. In this optimization, the pickup locations may be sampled, for example to select eligible pickup locations at least a threshold distance from one another, and perform the scoring for those pickup locations. In another example, the expected route of a provider may be calculated and the scoring function may be performed based on the pickup locations along the provider's route.
After scoring the eligible pickup locations for each provider, the lowest-cost pickup location may be determined for each provider, and the provider with the lowest cost is selected 340. After selection, in some embodiments the provider and/or client confirm 345 whether to accept the trip and/or pickup location. When the provider and pickup location are confirmed 350, a route to the selected pickup location is calculated for the client's location and the route is sent 355 to the client. Similarly, a route to the selected pickup location from the provider's location is sent 355 to the provider. After receiving the selected pickup locations, the client and provider may proceed to the selected pickup location to begin the trip. When the provider does not confirm the trip, another provider may be selected 340.
As an addition or an alternative, in some examples, the travel coordination system 130 can suggest a pickup location for the user after selecting an eligible provider to provide the service for the user. For example, the travel coordination system 130 can receive the trip request, identify the specified location provided by the user, and select a provider from a pool of eligible providers based on the proximity or estimated travel time of the individual providers to the specified location. After selecting the provider having the shortest estimated travel time or shortest distance from the specified location, for example, the travel coordination system 130 can determine the estimated speed and route of travel of the selected provider (e.g., direction and/or speed of travel, what road the selected provider is on, etc.). Based on the estimated speed and/or route of travel of the selected provider to the general region of the user, the travel coordination system 130 can determine which eligible pickup location, within a predetermined distance of the specified location of the user, is best suitable for the trip to minimize the amount of time and/or distance the provider would have to travel. The travel coordination system 130 can then provide the suggested pickup location to both the provider device 110 and the client device 100, such as described with an example of
Next, eligible pickup locations are identified 430 associated with the individual identified region(s). The eligible pickup locations are identified as the location data points associated with each identified region. In some examples, rather than identifying the all location data points associated with the one or more regions, the eligible pickup locations are initially identified from one selected region. One region from the one or more regions may be selected, for example, based on its location in a region hierarchy. For example, the selected region may be the region that is hierarchically the lowest (i.e., a subset of another region) or associated with the least geographical area. In addition, a geographical center may be determined for each region, and the selected region may be the region to which the client location is closest to the geographical center. The location data points associated with the selected regions (or one or more regions) may be identified as eligible pickup locations for the trip. As described with respect to
Prior to selecting the pickup location, the method may include selecting additional regions from the one or more regions for consideration of location data points as an eligible pickup location for the trip. In some embodiments, one or more conditions affecting the selected region cause additional regions to be considered and its associated location data points added to the identified eligible pickup locations for the trip (which then may be scored 440). These conditions may include, for example, significant changes in short-term conditions to user's location or to the identified pickup locations. Such short-term conditions may include, for example, traffic or construction in or near the region or its associated pickup locations. When the changes are above a threshold, the pickup location module 145 may consider another region identified 420 with the client's location, such as a region hierarchically broader (e.g., a larger geographical area) than the previously selected region for the eligible pickup locations. For example, for the user located at user location 230, store region 210A and building region 200 may both be identified as regions in which the client is located. The store region 210A may initially be selected for consideration of its associated location data points 220D and 220E for an eligible trip. After scoring 440 the eligible pickup locations, the scoring 440 may indicate a high ETA for the provider due to short term conditions in arriving at location data points 220D and 220E. The building region 200 may then be selected for possible pickup locations to determine whether the scoring for additional eligible pickup locations improve the score, such as for location data points 220A-C and 220F-H. The scores for these additional eligible pickup locations may be discounted to adjust for the different region, and if the scores are better than the other location data points, may be selected for the pickup.
When the user makes the request for the service, an interface, as shown in
By providing the various pickup locations and permitting adjustments to the pickup locations after trips are initiated, the travel coordination system 130 can account for locations where clients actually initiate trips, and account for the ease of accessing different pickup locations for different regions, while maintaining flexibility to adjust for modified conditions. The use of the location data points based on prior trip pickups permits pickup locations to be automatically selected and minimizing additional coordination by clients and providers. In embodiments where the location data points are associated with regions, the identification of relevant location data points and the related scoring of eligible pickups may be reduced by automatically looking up eligible pickup locations from the region in which a user is located.
As an addition or an alternative, the travel coordination system 130 may also select a suggested destination for the trip using the location data points stored in the pickup location datastore 170. In this example, the suggested destination for a trip may be used to improve efficiency of a pooled trip, and to reduce extra time that a rider must travel when it is inconvenient for a provider to reach the exact destination of the trip. To determine the suggested destinations for a trip, the travel coordination system 130 may access the predetermined location data points near the specified destination of a trip to identify eligible destinations and similarly score and suggest one of these eligible destinations as a destination for the trip. To score the eligible destinations, the travel coordination system 130 may first determine the estimated time for the provider to reach the destination entered by the user. Next, for each eligible destination, the travel coordination system 130 may combine the estimated time for the provider to reach the eligible destination and the estimated time for the client to walk from the eligible destination to the client-selected destination. This estimated time for an eligible destination may be compared with the estimated time to reach the destination, and the eligible destination suggested to the user when it has a reduced time relative to the provider traveling to the client-selected destination itself. In additional examples, the estimated time to reach another destination for another client on the trip (i.e., for a pooled trip) for the destination and the eligible destination may also be included in the estimated time.
The foregoing description of the embodiments of the invention has been presented for the purpose of illustration; it is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Persons skilled in the relevant art can appreciate that many modifications and variations are possible in light of the above disclosure.
Some portions of this description describe the embodiments of the invention in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations are commonly used by those skilled in the data processing arts to convey the substance of their work effectively to others skilled in the art. These operations, while described functionally, computationally, or logically, are understood to be implemented by computer programs or equivalent electrical circuits, microcode, or the like. Furthermore, it has also proven convenient at times, to refer to these arrangements of operations as modules, without loss of generality. The described operations and their associated modules may be embodied in software, firmware, hardware, or any combinations thereof.
Any of the steps, operations, or processes described herein may be performed or implemented with one or more hardware or software modules, alone or in combination with other devices. In one embodiment, a software module is implemented with a computer program product comprising a computer-readable medium containing computer program code, which can be executed by a computer processor for performing any or all of the steps, operations, or processes described.
Embodiments of the invention may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, and/or it may comprise a general-purpose computing device selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a non-transitory, tangible computer readable storage medium, or any type of media suitable for storing electronic instructions, which may be coupled to a computer system bus. Furthermore, any computing systems referred to in the specification may include a single processor or may be architectures employing multiple processor designs for increased computing capability.
Embodiments of the invention may also relate to a product that is produced by a computing process described herein. Such a product may comprise information resulting from a computing process, where the information is stored on a non-transitory, tangible computer readable storage medium and may include any embodiment of a computer program product or other data combination described herein.
Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based hereon. Accordingly, the disclosure of the embodiments of the invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.
This application is a continuation of U.S. patent application Ser. No. 15/228,732, filed on Aug. 4, 2016; which claims the benefit of priority to U.S. Provisional Application No. 62/265,747, filed Dec. 10, 2015; the aforementioned applications being hereby incorporated by reference in their respective entireties.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5557522 | Nakayama | Sep 1996 | A |
| 5948040 | DeLorme | Sep 1999 | A |
| 6058339 | Takiguchi | May 2000 | A |
| 6233517 | Froeberg | May 2001 | B1 |
| 6321158 | DeLorme | Nov 2001 | B1 |
| 6608566 | Davis | Aug 2003 | B1 |
| 6756913 | Ayed | Jun 2004 | B1 |
| 6832092 | Suarez | Dec 2004 | B1 |
| 7062376 | Oesterling | Jun 2006 | B2 |
| 7263437 | Hirose | Aug 2007 | B2 |
| 7822426 | Wuersch | Oct 2010 | B1 |
| 7957871 | Echeruo | Jun 2011 | B1 |
| 7970749 | Uhlir | Jun 2011 | B2 |
| 8005488 | Staffaroni | Aug 2011 | B2 |
| 8412667 | Zhang | Apr 2013 | B2 |
| 8565789 | Staffaroni | Oct 2013 | B2 |
| 8630987 | Dhuse | Jan 2014 | B2 |
| 9070101 | Abhayanker | Jun 2015 | B2 |
| 9075136 | Joao | Jul 2015 | B1 |
| 9158414 | Gluzberg | Oct 2015 | B1 |
| 9172738 | daCosta | Oct 2015 | B1 |
| 9244147 | Soundararajan | Jan 2016 | B1 |
| 9452785 | Tsuneyama et al. | Sep 2016 | B2 |
| 9547307 | Cullinane | Jan 2017 | B1 |
| 9562785 | Racah | Feb 2017 | B1 |
| 9599477 | Aula | Mar 2017 | B1 |
| 9613386 | Arden | Apr 2017 | B1 |
| 9631933 | Aula | Apr 2017 | B1 |
| 9715233 | Mandeville-Clark | Jun 2017 | B1 |
| 9702714 | Botea | Jul 2017 | B2 |
| 9733096 | Colijn | Aug 2017 | B2 |
| 9886667 | Lord | Feb 2018 | B2 |
| 9911170 | Kim | Mar 2018 | B2 |
| 10002333 | Lord | Jun 2018 | B2 |
| 10074065 | Jones | Sep 2018 | B2 |
| 10152053 | Smith | Dec 2018 | B1 |
| 10178890 | Andon | Jan 2019 | B1 |
| 10545023 | Herbach | Jan 2020 | B1 |
| 10572964 | Kim | Feb 2020 | B2 |
| 10721327 | Cheng | Jul 2020 | B2 |
| 10731998 | Rahematpura | Aug 2020 | B2 |
| 11196838 | Cheng | Dec 2021 | B2 |
| 20020044186 | Tochihara et al. | Apr 2002 | A1 |
| 20030040944 | Hileman | Feb 2003 | A1 |
| 20030058082 | Mallick | Mar 2003 | A1 |
| 20040158483 | Lecouturier | Aug 2004 | A1 |
| 20040249818 | Isaac | Dec 2004 | A1 |
| 20050004757 | Neeman | Jan 2005 | A1 |
| 20050021227 | Matsumoto | Jan 2005 | A1 |
| 20050227704 | Ferra | Oct 2005 | A1 |
| 20050278063 | Hersh | Dec 2005 | A1 |
| 20060023569 | Agullo | Feb 2006 | A1 |
| 20060034201 | Umeda | Feb 2006 | A1 |
| 20060059023 | Mashinsky | Mar 2006 | A1 |
| 20060155460 | Raney | Jul 2006 | A1 |
| 20060173841 | Bill | Aug 2006 | A1 |
| 20060184341 | Couckuyt | Aug 2006 | A1 |
| 20060235739 | Levis | Oct 2006 | A1 |
| 20070150375 | Yang | Jun 2007 | A1 |
| 20070233373 | Choi | Oct 2007 | A1 |
| 20080033633 | Akiyoshi | Feb 2008 | A1 |
| 20080195428 | O'Sullivan | Aug 2008 | A1 |
| 20080270019 | Anderson | Oct 2008 | A1 |
| 20080275645 | Hoshino | Nov 2008 | A1 |
| 20080277183 | Huang | Nov 2008 | A1 |
| 20090156241 | Staffaroni | Jun 2009 | A1 |
| 20090176508 | Lubeck | Jul 2009 | A1 |
| 20090192851 | Bishop | Jul 2009 | A1 |
| 20090216600 | Hill | Aug 2009 | A1 |
| 20090235176 | Jayanthi | Sep 2009 | A1 |
| 20090248587 | Van Buskirk | Oct 2009 | A1 |
| 20090296990 | Holland | Dec 2009 | A1 |
| 20090326991 | Wei | Dec 2009 | A1 |
| 20100070168 | Sumcad | Mar 2010 | A1 |
| 20100074383 | Lee | Mar 2010 | A1 |
| 20100207812 | Demirdjian | Aug 2010 | A1 |
| 20100280853 | Petralia | Nov 2010 | A1 |
| 20110099040 | Felt | Apr 2011 | A1 |
| 20110145089 | Khunger | Jun 2011 | A1 |
| 20110153629 | Lehmann et al. | Jun 2011 | A1 |
| 20110238755 | Khan | Sep 2011 | A1 |
| 20110301997 | Gale et al. | Dec 2011 | A1 |
| 20110320232 | Staffaroni | Dec 2011 | A1 |
| 20120004840 | Lee | Jan 2012 | A1 |
| 20120023294 | Resnick | Jan 2012 | A1 |
| 20120041675 | Juliver | Feb 2012 | A1 |
| 20120130627 | Islam | May 2012 | A1 |
| 20120239289 | Gontmakher | Sep 2012 | A1 |
| 20120253548 | Davidson | Oct 2012 | A1 |
| 20120265580 | Kobayashi | Oct 2012 | A1 |
| 20120253654 | Sun | Nov 2012 | A1 |
| 20120290950 | Rapaport | Nov 2012 | A1 |
| 20130024249 | Zohar | Jan 2013 | A1 |
| 20130046456 | Scofield | Feb 2013 | A1 |
| 20130054281 | Thakkar | Feb 2013 | A1 |
| 20130073327 | Edelberg | Mar 2013 | A1 |
| 20130110392 | Kosseifi | May 2013 | A1 |
| 20130132140 | Amin | May 2013 | A1 |
| 20130132246 | Amin | May 2013 | A1 |
| 20130144831 | Atlas | Jun 2013 | A1 |
| 20130159028 | Lerenc | Jun 2013 | A1 |
| 20130215843 | Diachina | Aug 2013 | A1 |
| 20140011522 | Lin | Jan 2014 | A1 |
| 20140074536 | Meushar | Mar 2014 | A1 |
| 20140082069 | Varoglu et al. | Mar 2014 | A1 |
| 20140129135 | Holden | May 2014 | A1 |
| 20140149441 | Wang | May 2014 | A1 |
| 20140172727 | Abhayanker | Jun 2014 | A1 |
| 20140365250 | Ikeda | Dec 2014 | A1 |
| 20140378159 | Dolbakian | Dec 2014 | A1 |
| 20150006072 | Goldberg | Jan 2015 | A1 |
| 20150045068 | Soffer | Feb 2015 | A1 |
| 20150055178 | Ishibashi | Feb 2015 | A1 |
| 20150067878 | Steelberg | Mar 2015 | A1 |
| 20150073645 | Davidsson | Mar 2015 | A1 |
| 20150081362 | Chadwick | Mar 2015 | A1 |
| 20150143275 | Lee | May 2015 | A1 |
| 20150161564 | Sweeney | Jun 2015 | A1 |
| 20150161698 | Jones | Jun 2015 | A1 |
| 20150204684 | Rostamian | Jul 2015 | A1 |
| 20150219464 | Beaurepaire | Aug 2015 | A1 |
| 20150228192 | Kawamoto | Aug 2015 | A1 |
| 20150248689 | Paul | Sep 2015 | A1 |
| 20150254581 | Brahme | Sep 2015 | A1 |
| 20150262430 | Farrelly | Sep 2015 | A1 |
| 20150278618 | Nuscheler | Oct 2015 | A1 |
| 20150302342 | Yeh | Oct 2015 | A1 |
| 20150317568 | Grasso | Nov 2015 | A1 |
| 20150323330 | Lord | Nov 2015 | A1 |
| 20150324718 | Lord | Nov 2015 | A1 |
| 20150325128 | Lord | Nov 2015 | A1 |
| 20150339923 | Konig et al. | Nov 2015 | A1 |
| 20150339928 | Ramanujam | Nov 2015 | A1 |
| 20160019496 | Gorlin | Jan 2016 | A1 |
| 20160026936 | Richardson | Jan 2016 | A1 |
| 20160027306 | Lambert | Jan 2016 | A1 |
| 20160027307 | Abhyanker | Jan 2016 | A1 |
| 20160034828 | Sarawgi | Feb 2016 | A1 |
| 20160034845 | Hiyama | Feb 2016 | A1 |
| 20160042303 | Medina | Feb 2016 | A1 |
| 20160048804 | Paul | Feb 2016 | A1 |
| 20160055769 | Angelescu | Feb 2016 | A1 |
| 20160071411 | Stenneth | Mar 2016 | A1 |
| 20160132792 | Rosnow | May 2016 | A1 |
| 20160187150 | Sherman | Jun 2016 | A1 |
| 20160301698 | Katara | Oct 2016 | A1 |
| 20160320195 | Liu | Nov 2016 | A1 |
| 20160320198 | Liu | Nov 2016 | A1 |
| 20160321771 | Liu | Nov 2016 | A1 |
| 20160364678 | Cao | Dec 2016 | A1 |
| 20160364679 | Cao | Dec 2016 | A1 |
| 20160364812 | Cao | Dec 2016 | A1 |
| 20160364823 | Cao | Dec 2016 | A1 |
| 20160370194 | Colijn | Dec 2016 | A1 |
| 20170052034 | Magazinik | Feb 2017 | A1 |
| 20170059347 | Flier | Mar 2017 | A1 |
| 20170083832 | Williams | Mar 2017 | A1 |
| 20170103490 | Haparnas | Apr 2017 | A1 |
| 20170115125 | Outwater | Apr 2017 | A1 |
| 20170126837 | Wang | May 2017 | A1 |
| 20170147959 | Sweeney | May 2017 | A1 |
| 20170153714 | Gao | Jun 2017 | A1 |
| 20170160092 | Botea | Jun 2017 | A1 |
| 20170169366 | Klein | Jun 2017 | A1 |
| 20170169535 | Tolkin | Jun 2017 | A1 |
| 20170193404 | Yoo | Jul 2017 | A1 |
| 20170213308 | Wellborn | Jul 2017 | A1 |
| 20170240098 | Sweeney | Aug 2017 | A1 |
| 20170255881 | Ritch | Sep 2017 | A1 |
| 20170263120 | Durie, Jr. | Sep 2017 | A1 |
| 20170270794 | Sweeney | Sep 2017 | A1 |
| 20170277191 | Fairfield | Sep 2017 | A1 |
| 20170286884 | Shoval | Oct 2017 | A1 |
| 20170293950 | Rathod | Oct 2017 | A1 |
| 20170300848 | Shoval | Oct 2017 | A1 |
| 20170308824 | Lord | Oct 2017 | A1 |
| 20170309171 | Zhao | Oct 2017 | A1 |
| 20170314948 | Tsuneyama et al. | Nov 2017 | A1 |
| 20170337810 | Abe | Nov 2017 | A1 |
| 20170365030 | Shoham | Dec 2017 | A1 |
| 20180005145 | Lo | Jan 2018 | A1 |
| 20180060838 | Agrawal | Mar 2018 | A1 |
| 20180091604 | Yamashita | Mar 2018 | A1 |
| 20180101925 | Brinig | Apr 2018 | A1 |
| 20180156623 | West | Jun 2018 | A1 |
| 20180158325 | Bernhardt | Jun 2018 | A1 |
| 20180189918 | Lu | Jul 2018 | A1 |
| 20180202820 | Yu | Jul 2018 | A1 |
| 20180202821 | Yu | Jul 2018 | A1 |
| 20180211351 | Kim | Jul 2018 | A1 |
| 20180339714 | Smid | Nov 2018 | A1 |
| 20180342035 | Sweeney | Nov 2018 | A1 |
| 20180356239 | Marco | Dec 2018 | A1 |
| 20180374032 | Pan | Dec 2018 | A1 |
| 20180374350 | Sweeney | Dec 2018 | A1 |
| 20190137288 | Rahematpura | May 2019 | A1 |
| 20190244318 | Rajcok | Aug 2019 | A1 |
| 20190265703 | Hicok | Aug 2019 | A1 |
| 20190272486 | Lord | Sep 2019 | A1 |
| 20190306258 | Yamashita | Oct 2019 | A1 |
| 20200160709 | Ramot | May 2020 | A1 |
| 20200211070 | Singh | Jul 2020 | A1 |
| 20200249042 | Warr | Aug 2020 | A1 |
| 20200258344 | Brinig | Aug 2020 | A1 |
| 20200272957 | Lord | Aug 2020 | A1 |
| 20200273337 | Sweeney | Aug 2020 | A1 |
| 20200292335 | Rahematpura | Sep 2020 | A1 |
| 20200322451 | Cheng | Oct 2020 | A1 |
| 20210209520 | Sarawgi | Jul 2021 | A1 |
| 20210285783 | Warr | Sep 2021 | A1 |
| 20210337047 | Cheng | Oct 2021 | A1 |
| 20210364300 | Rahematpura | Nov 2021 | A1 |
| 20210365848 | Lord | Nov 2021 | A1 |
| 20210407032 | Kim | Dec 2021 | A1 |
| Number | Date | Country |
|---|---|---|
| 104575072 | Apr 2015 | CN |
| 104931063 | Sep 2015 | CN |
| 10201607712 | Nov 2016 | DE |
| 2 501 075 | Oct 2013 | GB |
| 2010-208195 | Aug 1998 | JP |
| 2004-302941 | Oct 2004 | JP |
| 2004-362271 | Dec 2004 | JP |
| 3934985 | Jun 2007 | JP |
| 2012-73995 | Apr 2012 | JP |
| 2004-073639 | May 2015 | JP |
| 10-2006-0081193 | Jul 2006 | KR |
| 10-2011-0132765 | Dec 2011 | KR |
| 10-2013-0130978 | Dec 2013 | KR |
| 10-2014-0023541 | Feb 2014 | KR |
| WO 2002000694 | Jan 2002 | WO |
| WO 2002006994 | Jan 2002 | WO |
| WO 2011-120161 | Oct 2011 | WO |
| WO 2014074407 | May 2014 | WO |
| WO-2014106617 | Jul 2014 | WO |
| WO 2018132715 | Jul 2018 | WO |
| Entry |
|---|
| Pelzer et al., Oct. 2015, A Partition-Based Match Making Algorithm for Dynamic Ridesharing, IEEE Transactions on Intelligent Transportation Systems, vol. 16., No. 5, pp. 2587-2596 (Year: 2015). |
| Pelzer, et al., “A Partition-Based Match Making Algorithm for Dynamic Ridesharing”, IEEE Transactions on Intelligent Transportation Systems, vol. 16, Issue: 5, pp. 2587-2596 (2015). |
| Office Action in EP 15830335.4 dated Nov. 21, 2019. |
| First Office Action in CN 201580043970 dated Apr. 22, 2020. |
| Pre-Examination Office Action in BR 112017002174-9 dated May 6, 2020. |
| Examination Report No. 1 for AU 2015301178 dated Jun. 11, 2020. |
| Office Action in EP 16874019.9 dated Jun. 9, 2020. |
| Pre-Exam Office Action in BR 112018011694-7 dated Jul. 13, 2020. |
| Exam Report No. 1 in AU 2018207620 dated Apr. 6, 2021. |
| EESR in EP 18873921.3 dated Jul. 14, 2021. |
| Fay et al, Decentralizing routing control for guided transportation systems, 2008 IEEE. |
| Vaqar et al, Smart Protocol for Communication in Mobile Ad Hoc Networks of Vehicles, 2007, IEEE, p. 1-6. |
| Fay et al, Decentralized control strategies for transpotation systems, 2005, IEEE p. 898-903. |
| Dessouky, et al, Real-time scheduling rules for demand responsive transit systems, 1998 IEEE pp. 2956-2961. |
| Andrew J. Hawkins, Lyft is now suggesting more convenient pickup locations, because a little walking won't kill you. Jun. 26, 2017 The Verge (www.theverge.com). |
| Arney, Utilizing Mobile Phone Technology to Improve Rideshare Services, 2011 Transportation Research Board Annual Meeting. |
| Fougeres, A push service for carpooling, 2012 IEEE International Conference on Green Computing and Communications, Conference on Internet of Things, and on Cubler, Physical and Social Computing, 2012. |
| Megalingam, Automated Wireless Carpooing System for an Eco-Friendly Travel, 2011 IEEE. |
| Dillenburg, The Intelligent Travel Assistant, IEEE 5th International Conference on Intelligent Transportation Systems, Sep. 3-6, 2002, Singapore. |
| Guc, Real-time, Scalable Route Planning using a Stream-Processing Infrastructure, 2010 13th International IEEE, Annual Conference on Intelligent Transport Systems, Madeira Island, Portugal ,Sep. 19-22, 2010. |
| Lalos, A Framework for dynamic car and taxi pools with the use of Positioning Systems, 2009 Computation World: Future Computing, Service Computation, Congitive, Adaptive, Content, Patterns 2009. |
| Shahzada, Dynamic Vehicle Navigation: An A* Algorithm Based Approach Using Traffic and Road Information, 2011 International Conference on Computer Applications and Industrial Electronics, (ICCAIE 2011). |
| Boufaied, A Diagnostic Approach for Advanced Tracking of Commercial Vehicles with Time Window Constraints, IEEE Transactions on Intelligent Systems, vol. 14, No. 3, Sep. 2013. |
| Vaughan-Nichols, Will Mobile Computing's Future be Location, Location, Location? Industry Trends, IEEE Computer Society, 2009 IEEE. |
| International Search Report in PCT/US2015/043654 dated Nov. 26, 2015. |
| IPRP in PCT/US2015/043654 dated Feb. 16, 2017. |
| International Search Report in PCT/US2016/066030 dated Feb. 28, 2017. |
| Written Opinion in SG 11201700671P dated Oct. 13, 2017. |
| EESR in EP 15830335.4 dated Nov. 29, 2017. |
| IPRP in PCT/US2016/066030 dated Jun. 21, 2018. |
| 2nd Written Opinion in SG 11201700671P dated Aug. 29, 2018. |
| ESER in EP 16874019.9 dated Aug. 2, 2018. |
| ISR and Written Opinion in PCT/US2018/013583 dated Apr. 20, 2018. |
| ISR and Written Opinion in PCT/US2018/059230 dated Jan. 2, 2019. |
| Office Action in EP 15830335.4 dated Mar. 21, 2019. |
| Office Action in JP 2017-505856 dated Feb. 6, 2019. |
| Mark H. Walker, “Microsoft Office Visio 2003 Official Manual”, Initial Pressing, Nikkei BP Soft Press, Apr. 4, 2005, First Edition, pp. 423-425. |
| ISR dated Oct. 3, 2018 in PCT/US2018/039830. |
| Borison, Rebecca, “Uber Brings its SUV Fleet to NYC”, Jul. 30, 2014, Business Insider, p. 1. |
| Hilen, Brittany, Uber and Google bring WIFI to cars in Philadelphia, Slashgear, dated Jul. 24, 2014, p. 1, https://web.archive.org/web/20140724201314/http://www.slashgear.com/uber-and-google-bring-wifi-to-car-in-philadelphia-22338326. |
| Jain, “Contextual Adaptive User Interface for Android Devices”, Annual IEEE India Conference (INDICON), IEEE, pp. 1-4 (2013). |
| IPRP in PCT/U52019/039830 dated Jun. 29, 2019. |
| Exam Report No. 1 in AU 2016366687 dated Oct. 6, 2021. |
| Office Action in EP 17771000.1 dated Aug. 23, 2021. |
| Exam Report No. 2 in AU 2017328067 dated Jan. 22, 2022. |
| Office Action in KR 10-2016-7034177 dated Mar. 30, 2022. |
| Number | Date | Country | |
|---|---|---|---|
| 20200034943 A1 | Jan 2020 | US |
| Number | Date | Country | |
|---|---|---|---|
| 62265747 | Dec 2015 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15228732 | Aug 2016 | US |
| Child | 16531847 | US |
