TRIP PLANNING AND IMPLEMENTATION
A network computer system can receive location information indicating a current location of a user, upon detecting a user having arrived at an airport. based at least on the current location of the user, the network computer system can determine a time-to-reach pickup interval. Additionally, the network computer system can receive location information indicating a current location of each of a set of service providers. Based on at least on the current location of at least one service provider of the set of service providers, the network computer system can determine a request time interval. Moreover, based on the request time interval and the time-to-reach pickup interval, the network computer system can determine a computed request time indicating a time to trigger a service request.
This application is a continuation of U.S. patent application Ser. No. 14/746,766 filed Jun. 22, 2015, which claims benefit of priority to U.S. Provisional Patent Application No. 62/015,284, filed Jun. 20, 2014; the aforementioned applications being incorporated by reference in their entireties.
BACKGROUNDA conventional way for a user to plan for travel is for that user to first book a flight by visiting a website for an airline or a website for a travel booking company. The user can then book a hotel from either the same website for the travel booking company or by visiting a separate website for a hotel. In some instances, the user can also reserve a rental vehicle from the same website for the travel booking company or by visiting a website for a vehicle rental company.
A system and method are provided which obtain a travel itinerary for a user, the itinerary identifying a trip, including a scheduled flight to a destination. A scheduled flight is monitored to detect when the scheduled flight arrives at the destination. Upon the scheduled flight arriving at an airport of the destination, one or more notifications are sent to a mobile computing device of the user. Information can be provided with the notifications for an on-demand ground transportation service. The information may include a location at the airport where the user can be picked up in connection with receiving the on-demand transportation service, and a timing indicator to indicate when the user should make a request to receive the on-demand transportation service based on a real-time determination of a number of available service providers in a vicinity of the airport.
Still further, some examples described herein provide for a system and a method for providing recommended itineraries for a trip of a user based on the user's specified travel information. A recommended itinerary can provide a comprehensive or end-to-end itinerary for the user from the beginning of the trip (e.g., from a user-specific start location at a start date and/or time) to the end of the trip (e.g., to a user-specific return location at a return date and/or time), as opposed to a typical itinerary that simply provides information about a selected flight and information about a selected hotel.
According to some examples, a reservation system can determine a set of initial travel information of a trip for a user based on received user input. As used herein, a set of initial travel information refers to information that is specific to a particular user and that defines the parameters of the user's trip. For example, a set of initial travel information can include one or more of (i) a start location indicating where the trip is to begin, (ii) a start date and/or time indicating when the trip is to begin, (iii) a destination location (e.g., a location that the user wishes to travel to), (iv) a return location indicating where the trip is to end, and (v) a return date and/or time indicating when the trip is to end. Still further, as used herein, a trip refers to an event or a journey that begins from the user-specified start location and ends at the user-specified end location. The duration of the trip lasts from the start date and/or time to the return date and/or time. A trip can include one or more other locations that the user travels to during the duration of the trip.
The reservation system can communicate, over one or more networks, with a plurality of airline systems, a plurality of lodging systems, and/or a plurality of intermediary systems (e.g., systems that communicate with the airline systems and/or lodging systems, such as third-party travel booking systems) to receive a set of data from the individual systems based on one or more initial travel information from the set of initial travel information provided by the user. The reservation system can use the received set of data to determine one or more recommended itineraries for the trip for the user. The one or more recommended itineraries can be provided on a user interface to enable the user to view the details about the one or more recommended itineraries and/or make changes to one or more recommendations within a recommended itinerary. In one example, each recommended itinerary can include one or more transport service recommendations, one or more flight recommendations, and/or one or more lodging recommendations that cover the user's travel and transport needs for the entirety of the trip. In this manner, a single travel itinerary can be booked or reserved by the user through a single interface based on recommendations provided by the reservation system.
In some examples, the reservation system can communicate with at least one traditional hotel system as well as at least one shared-economy (or consumer-sharing) lodging system to access a variety of different types of lodging options for the user's trip when determining a lodging recommendation. By communicating with a combination of both traditional hotel systems and shared-economy systems, the reservation system can have a larger selection of lodging options to choose from in order to make a lodging recommendation for the user's specified trip.
Still further, the reservation system can communicate with an on-demand transport arrangement system to request one or more transport services to be arranged on behalf of the user in advance of the trip. The reservation system and the on-demand transport arrangement system can exchange data to enable pre-payment for the one or more transport services to be made. For example, typically, the on-demand transport arrangement system operates in real-time (or close to real-time) by receiving a real-time request for a transport service from a user at or around a time the user wants the transport service. By being in communication with the on-demand transport arrangement system, the reservation system can (i) automatically make a request for a transport service(s) for the user when the user books a recommended itinerary, or (ii) automatically make a request for a transport service(s) at around the time the user needs the transport service for the trip.
One or more examples described herein provide that methods, techniques, and actions performed by a computing device are performed programmatically, or as a computer-implemented method. Programmatically, as used herein, means through the use of code or computer-executable instructions. These instructions can be stored in one or more memory resources of the computing device. A programmatically performed step may or may not be automatic.
One or more examples described herein can be implemented using programmatic modules, engines, or components. A programmatic module, engine, or component can include a program, a sub-routine, a portion of a program, or a software component or a hardware component capable of performing one or more stated tasks or functions. As used herein, a module or component can exist on a hardware component independently of other modules or components. Alternatively, a module or component can be a shared element or process of other modules, programs or machines.
Some examples described herein can generally require the use of computing devices, including processing and memory resources. Examples described herein may be implemented, in whole or in part, on computing devices or systems such as servers, datacenters, desktop computers, cellular or smartphones, personal digital assistants (e.g., PDAs), laptop computers, printers, digital picture frames, network equipment (e.g., routers) and tablet devices. Memory, processing, and network resources may all be used in connection with the establishment, use, or performance of any example described herein (including with the performance of any method or with the implementation of any system).
Furthermore, one or more examples described herein may be implemented through the use of instructions that are executable by one or more processors. These instructions may be carried on a computer-readable medium. Machines shown or described with figures below provide examples of processing resources and computer-readable mediums on which instructions for implementing examples can be carried and/or executed. In particular, the numerous machines shown with examples include processor(s) and various forms of memory for holding data and instructions. Examples of computer-readable mediums include permanent memory storage devices, such as hard drives on personal computers or servers. Other examples of computer storage mediums include portable storage units, such as CD or DVD units, flash memory (such as carried on smartphones, multifunctional devices or tablets), and magnetic memory. Computers, terminals, network-enabled devices (e.g., mobile devices, such as cell phones) are all examples of machines and devices that utilize processors, memory, and instructions stored on computer-readable mediums. Additionally, examples may be implemented in the form of computer-programs, or a computer usable carrier medium capable of carrying such a program.
System Description
According to one example, the reservation system 110 can include a system interface 115, a recommendation engine 120, a user interface (UI) component 125, and a data store 135. The components of the reservation system 110 can combine to (i) receive a set of initial travel information of a trip for a user based on received user input, (ii) communicate with the airline systems 150, lodging systems 160, and/or the intermediary systems to receive a set of data based on the set of initial travel information, and (iii) determine one or more recommended itineraries for the trip based on the received set of data. Depending on implementation, one or more components of the reservation system 110 can be implemented on a computing system, such as a server, laptop, PC, etc., or on multiple computing systems that can communicate with other systems over one or more networks. In some examples, a computing system can operate or execute an application to perform one or more of the processes described by the various components of the transport arrangement system. The reservation system 110 can also be implemented through other computer systems in alternative architectures (e.g., peer-to-peer networks, etc.).
The reservation system 110 can communicate, over one or more networks via a network interface (e.g., wirelessly), with airline systems 150, lodging systems 160, and the on-demand transport arrangement system 170 using the system interface 115. The system interface 115 can enable and manage communications between the reservation system 110 and the other systems. For example, the reservation system 110 and the other systems can exchange data with each other using application programming interfaces (APIs).
The UI component 125 can generate and provide one or more user interfaces (UI) 126 to be displayed on a display of a computing device. For example, the UI 126 can be accessible (over one or more networks) by a user's computing device via a portal, such as through a website or an application operable on the computing device. The user can interact with the UI 126 in order to provide input 127 for specifying the user's set of initial travel information 128 (see
The user can provide input 127 to specify a set of initial travel information for a trip, including for example, (i) a start location indicating where the trip is to begin, (ii) a start date and/or time indicating when the trip is to begin, (iii) a destination location (e.g., a location that the user wishes to travel to), (iv) a return location indicating where the trip is to end, and/or (v) a return date and/or time indicating when the trip is to end. The recommendation engine 120 can receive the set of initial travel information 128 based on the received user input 127. In some examples, the UI component 125 can also provide the set of initial travel information 128 to the data store 135 so that the set of initial travel information 128 can be associated with the user's profile (of a plurality profiles 136) and stored in the data store 135.
In some examples, the recommendation engine 120 can also be in communication with the data store 135 to access user-specific data from the user's profile 136 when the user signs up with or logs in to the reservation system 110 via the portal. A user profile 136 can be associated with a particular user via a user name or other user identification, such as an e-mail address and/or phone number. Each user profile 136 can include user-specific information provided by a user, such as, for example, (i) information about one or more locations (e.g., an address for the user's home, an address for the user's office(s), an address for other locations frequently visited by the user, such as the gym, a relative's home, etc.), (ii) transport service preferences (e.g., vehicle type to be picked up in and dropped off in; vehicle color; specific requests for content within a vehicle, such as newspaper, water, gum, etc.), (iii) flight preferences (e.g., airline company; airplane type; size of airplane; aisle or window seat; time of flight, such as morning, afternoon, evening, etc.), (iv) lodging preferences (e.g., lodging company; lodging type, such as traditional hotels or bed-and-breakfast type or consumer-sharing lodging), (v) payment and billing information (e.g., bank account information; credit card information, etc.), and/or (vi) other user-specific information. Such information can be provided by the user in response to the user providing inputs 127 on UI 126.
The data store 135 can store historical data 137 for trips that were previously taken by users of the reservation system 110. Historical data 137 can be associated with user profiles 136. The data store 135 also store feedback information 138 about individual transport services, flights, and/or lodgings of trips that the user and other users of the reservation system 110 have taken or used. Such feedback information 138 can be provided by individual users after their individual experience with the transport services, flights, and/or lodgings. The recommendation engine 120 can access the historical data 137 and/or the feedback information 138 from the data store 135 for purposes of making recommendations for a trip of a user. For example, for a particular user, the recommendation engine 120 can use that user's historical data 137 and/or feedback information 138 as well as other users' historical data 137 and/or feedback information 138 to determine one or more recommended itineraries.
Referring back to the example above, a user who is planning a trip can sign in to the reservation system 110 and provide a set of initial travel information 128 for the trip. Once the user fills out the fields of the UI 126, the user can select a feature (e.g., “Search” or “Magic!”) on the UI 126 to cause the reservation system 110 to process the data for purposes of providing recommended itineraries. When the recommendation engine 120 receives the set of initial travel information 128 for the trip, the recommendation engine 120 can communicate at least a portion of the set of initial travel information 128 to the airline systems 150 and/or the lodging systems 160 (if necessary), e.g., referred in
For example, based on the specified a start location and a start date/time, a destination location, and a return location and a return date/time, only one or more flight options from one or more airlines may be pertinent to the user's trip (e.g., flights that are departing and arriving in areas close to or within predefined distances of the specified locations and at times close to the dates/times). Similarly, only one or more lodging options from one or more lodging systems may be pertinent to the user's trip (e.g., lodging options that are in an area close to or within a predefined distance of the destination location and have available rooms during a dates/duration that the user is at or within the predefined distance of the destination location).
As described herein, a set of airline data 153 from an airline system 150 can include flight information of one or more flights (e.g., flight number, airplane type, starting airport, ending airport, etc.), flight times for the one or more flights (e.g., take off time, landing time, duration of the flight, etc.), and costs for the one or more flights (e.g., total cost, or broken down costs between airfare, taxes, etc.). Also as described herein, a set of lodging data 163 from a lodging system 160 can include lodging information of one or more rooms (e.g., single room, double room, king size bed, etc.), the check-in date/time and/or the check-out date/time, the duration of the stay, and costs for the one or more rooms (e.g., total cost, or broken down costs between rooms, taxes, etc.).
According to some examples, the data collect component of the recommendation engine 120 can receive or collect the initial set of travel information 128, the airline data 153, and/or the lodging data 163, as well as other information, such as information from the user's profile 136, historical information 137, and/or feedback information 138. The recommendation engine 120 can also include or communicate with a database of rules or parameters, where the rules or parameters can specify how the recommendation engine 120 is to determine one or more recommended itineraries. As an example, a rule can specify which data or information to use or to not use to determine a recommended itinerary (e.g., do not use historical information 137 or feedback information 138), and/or specify what weights are applied to which data or information (e.g., larger weights are applied to travel or lodging options that the user has previously taken or used and ranked highly as compared to other travel or lodging options). One or more rules in the database can be configurable by a user of the reservation system 110.
Based on one or more rules, the recommendation engine 120 can use the set of travel information 128 and the received data to generate one or more recommended itineraries for the trip for the user. In one example, the recommendation engine 120 can use a plurality of rules or parameters to determine multiple recommended itineraries, such as one set of rules for determining a recommended itinerary that is weighted heavily for lower prices for individual travel or lodging recommendations (e.g., travel or lodging options are given higher scores or rankings based on prices being lower than other options), another set of rules for determining a recommended itinerary that is weighted heavily for convenience of travel for the trip (e.g., travel or lodging options are given higher scores or rankings based on proximity to locations, shorter travel times, etc.), or still further, a third set of rules for determining a recommended itinerary that is weighted heavily for luxury or high ratings by users.
For each recommended itinerary, the recommendation engine 120 can determine one or more transport service recommendations to transport the user between locations (e.g., ground transport provided by a vehicle transport service), one or more flight recommendations to fly the user to and from airports, and one or more lodging recommendations (if necessary) to house the user when the user is at a destination. For example, although the user may need to fly from a start location to a destination location (e.g., San Francisco to Los Angeles), the user's start date and the return date can be on the same day, in which the recommendation engine 120 can automatically determine that no lodging is necessary. As an example of a recommended itinerary, based on the set of initial travel information 128, the recommendation engine 120 can determine that the user needs (i) a first transport service from the user's home to a first airport twenty miles away, (ii) a first flight from the first airport to a second airport in an area close to the destination, (iii) a second transport service from the second airport to a hotel, (iv) three nights in the hotel, (v) a third transport service from the hotel to the second airport, (vi) a second flight from the second airport to a third airport, and (vii) a fourth transport service from the third airport to the user's office. Each of the individual travel recommendations and lodging recommendation for a recommended itinerary can be selected based on each other, as the times and availabilities of one can influence the other.
In addition, for each recommended itinerary, the recommendation engine 120 can also provide a cost (or an estimated cost) for each of the travel and/or lodging recommendations and provide a total cost (or total estimated cost) for that itinerary. For example, the recommendation engine 120 can include the cost as provided by the airline system(s) 150 and/or the lodging system(s) 160 in the airline data 153 and/or the lodging data 163, respectively. Additionally, the recommendation engine 120 can provide, to the transport arrangement system 170, location information from the set of initial travel information 128 in order to receive a cost (or an estimated cost) for each of the transport service recommendation(s) (e.g., the cost can vary based on the distance between locations from a start to an end of a transport service). This cost can also be based on a recommended vehicle type specified by the recommendation engine 120. In this manner, the recommendation engine 120 can determine one or more recommended itineraries for a user, with each recommended itinerary corresponding to an end-to-end and comprehensive itinerary that substantially plans out or outlines the entirety of the travel and lodging facets of the trip.
Still further, the recommendation engine 120 can determine a plurality of recommended itineraries, and in some implementations, can rank the recommended itineraries. For example, ten different recommended itineraries can be determined and ranked (e.g., relative to each other from one to ten) so that the user can view the recommended itineraries in raking order one after the other. In other examples, recommended itineraries in a first set of recommended itineraries (e.g., that are weighted to favor lower/lowest prices) can be ranked relative to each other in the first set, recommended itineraries in a second set of recommended itineraries (e.g., that are weighted to favor convenience or lower/lowest travel times) can be ranked relative to each other in the second set, and so forth.
The recommendation engine 120 can provide the determined one or more recommended itineraries 121 to the UI component 125. The UI component 125 can provide the recommended itineraries 121 on or as part of an itinerary UI 129, in order to enable to view a recommended itinerary 121, to select between viewing different recommended itineraries 121, to adjust one or more travel and/or lodging recommendations, and/or to place an order (have the reservation system 110 make reservations on behalf of the user) using a recommended itinerary 121 (see
In another example, for a recommended itinerary, the recommendation engine 120 may have selected a first flight option as the first flight recommendation to be displayed on or shown with the recommended itinerary. The recommendation engine 120 can also provide, in response to a user input to modify or view other options, other flight options if the user wishes to select another flight. For example, the user can select a feature that causes another interface (e.g., a menu, a drop down menu, etc.) to be displayed, in which the other interface displays other flight options and/or their associated information. The user can select another flight option from that interface and in response, the recommendation engine 120 may, if necessary, dynamically change the times, the costs, the transport service recommendation(s), and other travel and/or lodging recommendations for that recommended itinerary (e.g., as a result of the change in flight times or locations, the lodging recommendation may have to be changed). In some variations, the recommendation engine 120 can retrieve airline data 153 and the lodging data 163 in response to receiving the user's input to change a recommendation in order to receive updated data 153, 163 based on the new user-specified information. In this manner, if the user determines that one of the recommended itineraries 121 is best suited for his or her trip, but not is not perfect to his or her liking, the user can modify one or more of the travel and/or lodging recommendations.
When the user is satisfied with a recommended itinerary 121, the user can select a feature on the itinerary UI 129 to order or checkout the selected recommended itinerary 121. In one example, the UI component 125 can receive user input 127 and notify the recommendation engine 120 that the user wishes to order or reserve the specified recommendations in the selected recommended itinerary 121. In response to the reservation system 1120 receiving the user input to order the selected recommended itinerary 121, the recommendation engine 120 can communicate with the respective airline system(s) 150 and/or the lodging system(s) 160 that provide the travel and/or the lodging recommendations specified in the selected recommended itinerary 121 in order to provide reservation requests on behalf of the user. The recommendation engine 120 can provide, via the system interface 115, a reservation request 154 to the airline system(s) 150 for reserving the one or more flight recommendations and a reservation request 164 to the lodging system(s) 160 for reserving the one or more lodging recommendations.
The recommendation engine 120 can provide the reservation requests 154, 164 to the respective systems along with user-specific information of the user (by previously accessing the user profile 136). Such user-specific information can include the user's name, address, billing information, payment information, contact information, government document information (e.g., passport number, citizenship information), etc., for reserving the different travel and/or lodging recommendations. In some examples, the user may have a pre-existing account or a profile with the airline system 150 and/or the lodging system 160. The recommendation engine 120 can provide the user's user name or rewards number to the associated systems if found in the user profile 136. In another variation, the reservation system 110 can, via the UI component 125, provide a UI to enable the user to provide such information for reservation purposes. The user can be charged at the time of reservation and/or when the user checks in or checks out of the lodging venue using the user's provided payment method and information.
The recommendation engine 120 can also communicate with the on-demand transport arrangement system 170 to provide one or more scheduled requests 171 to order or reserve the one or more transport service recommendations in the selected recommended itinerary 121. The scheduled request(s) 171 can also include information about the user (e.g., the user's name, email address, phone number, billing information, payment information) as well as the vehicle type and/or the time(s) the vehicle is needed for the one or more transport service recommendations. According to some examples, the user may already have a pre-existing account with the transport arrangement system 170. If the user has an account with the transport arrangement system 170, the account can store the user's specified payment method and information. By providing the scheduled request(s) 171 with the user's email address (and/or password), for example, the transport arrangement system 170 can make a reservation for the user for the one or more transport service recommendations using the user's payment method in the account (e.g., as opposed to the payment method in the profile 136 of the reservation system 110).
As an addition or an alternative, as discussed, the on-demand transport arrangement system 170 can arrange transport services between users and service providers (e.g., drivers) in real-time or close to real-time, as users make requests on-demand (as opposed to a scheduled reservation made days or weeks in advance). In such an example, the recommendation engine 120 may not transmit the scheduled request(s) 171 to the transport arrangement system 170 at the time the user order the selected recommended itinerary 121. The recommendation 120 can store information about the time(s) and/or the vehicle type(s) for the one or more transport service recommendations (e.g., as part of reservations information 139 in the data store 135). When it is time or close to time to make an on-demand request for the transport service (e.g., to transport the user from the start location to a first airport at the recommended time in the recommended itinerary 121), the recommendation engine 120 can transmit a request on behalf of the user to the transport arrangement system 170. Similarly, at a later time for another transport service (e.g., from the return pickup location to the return location), the recommendation engine 120 can transmit another request to the transport arrangement system 170 for another transport service.
After the reservations have been requested, the recommendation engine 120 can receive confirmation messages or emails from the airline system(s) 150, the lodging system(s) 160, and/or the transport arrangement system 170 that the reservations have been made for the user. The recommendation engine 120 can store the confirmation messages as reservations information 139 in the data store 135. In other examples, as an addition or an alternative, the user can receive notifications (e.g., emails) from these individual systems confirming that the reservations have been made. In this manner, the reservation system 110 can provide a variety of comprehensive recommended itineraries for a user based on the user's specific trip information to substantially cover the user's travel and transport needs for the entirety of the trip.
As an addition or an alternative, the reservation system 110 can be used or implemented (at least in part) by an enterprise, business, corporation, etc., where each employee of the enterprise (e.g., each user) can have an associated profile 136. Such a reservation system 110 can be used by employees when planning a business trip. The profiles 136 can be associated with back-office systems or human resource (employee personnel) information systems. In this manner, user specific-information, which can be used for some initial travel information 128, can be auto-populated for a user or included in a drop down menu for selection when inputting the set of initial travel information 128 on the UI 126. For example, the user's home address can be pre-associated with the user's profile 136. The user can input or select “Home” in a field for the start location and the user's home address can be automatically populated in the UI 126. Still further, the reservation system 110 can be in communication with the enterprise's financial system and/or expense system so that when reservations for a recommended itinerary are made through use of the reservation system 110, the user does not have to additional provide expense reports. The reservation system 110 can automatically bill the enterprise's financial system or use the financial system to make the reservations, or if the user's payment methods are used, automatically provide the expense and billing to the enterprise's expense system on behalf of the user.
User Interface Examples
The input interface 200 can include a plurality of features and fields to enable the user to provide input via one or more input mechanisms of his or her computing device to specify a set of initial travel information for a trip. For example, a profile feature 210 showing the user's name or account user name, “Username,” is displayed on the input interface 200 so that the user can select the feature 210 to view and/or edit various information in his or her profile with the reservation system (e.g., specify travel preferences, such as window seat versus aisle seat, or lodging preferences, etc.). The input interface 200 can also include set of additional features 215 to enable the user to search, view previous travels or upcoming travels, or change settings for the reservation system.
The input interface 200 can also include a variety of different features or fields that direct the user to provide information about the user's trip, including for example, (i) a start location field 220, (ii) a start date field 230, (iii) a start time field 240, (iv) a destination field 250, (v) a return pickup location field 260, (vi) a return drop off location field 270, (vii) a return date field 280, and/or (viii) a return time field 290. The user can manually type in information in the fields, or in some examples, selection of a field can provide drop down menus or additional user interfaces for selection. Although not illustrated in
In addition, although not illustrated in
When the user has finished inputting the set of initial trip information, the user can select a “search,” “recommend,” or “order” feature, or in the example of
A recommended itinerary can include departure information 320, returning information 330, cost information 350, and a reserve feature 370 to reserve or order the recommended itinerary. As discussed, the reservation system can provide a comprehensive itinerary that provides transport services, travel services, and/or lodging services for a substantial entirety of the trip. A trip for the user does not just begin from the beginning of the user's first flight, but instead, begins when the user is ready to leave his home, office, or other location. In this manner, the departure information 320 and the returning information 330 together can provide an end-to-end itinerary for the user.
In the example of
The cost information 350 can also be displayed on the itinerary user interface 300. The cost information 350 can display the cost or estimated cost for each of the different recommendations for the recommended itinerary. In addition, the total cost 360 for the recommended itinerary can also be displayed. If the user wants to reserve the recommended itinerary, the user can then select the reserve feature 370 to cause the reservation system to book or reserve the various recommendations on behalf of the user.
Methodology
Referring to
Based on the set of initial travel information, the reservation system 110 can receive a set of data from a plurality of travel systems, including one or more airline systems, one or more lodging systems, and/or an on-demand transport arrangement system (420). In some examples, the one or more lodging systems can also include a consumer-sharing lodging system (e.g., a lodging system in which private owners or rentals of homes, condominiums, apartments, etc., can allow other users to rent lodging) in addition to traditional hotel systems.
Using the received data form the travel systems, the reservation system 110 can determine one or more recommended itineraries for the trip (430). Each of the recommended itineraries can include a plurality of recommendations, including, for example, one or more transport service recommendations, one or more flight recommendations, and/or one or more lodging recommendations for the trip. The recommended itinerary can provide the user with travel recommendations from the start of the user's trip to the end of the user's trip. The one or more recommended itineraries can be provided on a user interface to enable the user to view, modify, and/or reserve a recommended itinerary (440).
The reservation system 110 can also communicate with an on-demand transport service to receive vehicle type information, estimated cost data (e.g., based on locations and/or time information provided by the reservation system), availability information, etc.
The reservation system 110 can determine one or more recommended itineraries for the trip for the user based on the received data, as well as based on other information (e.g., user preferences, historical data, feedback information, etc.) (460). The reservation system 110 can determine one or more recommended itineraries based on one or more rules or parameters and the received airline data and lodging data. For example, the reservation system 110 can use the airline data (e.g., including availability of good seats, such as bulk head seats, emergency exit seats, etc.) as well as the user's preference (aisle seat or window seat, or closer to the front or the back of the plane, etc.) in order to determine one or more flight recommendations. In examples, recommendations for flights can also be based one or more of flight occupancy, on-time departure scores, predicted weather during specific days or times, travel time, capacity/crowding, seat optimization, location, weather, ground traffic, past feedback from the traveler, past feedback from other travelers, etc. Flights and/or lodging recommendations can be ranked to determine options that are optimized for price, convenience, and/or best suggestion that is optimized for a combination of factors (e.g., a balanced recommended itinerary).
As discussed, a recommended itinerary can include a plurality of recommendations from a start location and/or a start date/time to an end or return location and/or a return date/time. For example, with reference to
The reservation system 110 can format the results and provide the one or more recommended itineraries on a user interface to be viewable by the user (465). The user can interact with the user interface via user input to modify a recommendation on a recommended itinerary. The reservation system 110 can determine whether user input has been received to change one or more recommendations for a recommended itinerary (470). If yes, the reservation system 110 can adjust the one or more recommendations of that recommended itinerary, and if necessary, can dynamically adjust one or more other recommendations of that recommended itinerary (475). On the other hand, if no, the reservation system 110 can determine whether it has received user input to select and reserve (or order) one of the recommended itineraries (480).
If the user has not provided input to select and reserve a recommended itinerary, the reservation process ends (490). If the user provides input to select and request reservation of a recommended itinerary, the reservation system 110 can make a reservation of the recommendations (e.g., flight and/or lodging recommendation(s)) for the selected recommended itinerary on behalf of the user (485). For example, for the checkout process, the reservation system communicates with the respective airline system(s) 150, the lodging system(s) 160, and/or the on-demand transport arrangement system 170 to make individual reservations for the recommendations. A booking or confirmation number can be returned to the reservation system and/or displayed to the user. The selected recommended itinerary and a pre-paid booking code for any recommendation of the trip, including any shared-economy lodging recommendation(s) or on-demand transport service recommendation(s) of the trip, may be provided to the user. In some cases, a booking code can be used to pay at the time of service of shared-economy services by entering the booking code into the shared economies online booking application or providing the booking code directly to the operator of the shared-economy system or on-demand transport arrangement system.
As an addition or an alternative, after reserving the recommended itinerary, the reservation system 110 can also perform monitoring operations of any of the reserved transport service(s), flight(s), and/or lodging(s) to notify any of the transport service system, the airline system(s), the lodging system(s), and/or the user about changes that are occurring or are to occur (e.g., changes to times, flight changes, delays, etc.). The reservation system 110 can include a tracking component in order to alert a driver of a transport service vehicle, a lodging operator, and/or the user via email, text message, SMS message, phone call, etc., for example, when there is a change due a flight delay. Similarly, during a transport service from the start location to the first airport, for example, if the vehicle is delayed, the vehicle's location information and/or the estimated time of arrival can be provided to the reservation system 110, which can then alert other systems, such as airline systems air and/or lodging systems. In some examples, a link for real-time tracking and/or communication via text, SMS, email, or phone, can be provided to providers operating the systems.
One technical achievement and improvement which can be achieved is that, through implementation of ODTM 500 (or method thereof), the power level of a user's mobile computing device can be conserved at a point in travel where the mobile computing device is needed most. For example, when a business traveler lands at a destination, the mobile device is often put into instant use to check voicemail, email, messages, call home, and confirm reservations. At the same time, the duration of the flight may have drained the phone, so the mobile computing device may be operating a low power level. Examples recognize that on-demand ground transportation is often a necessary aspect of travel, but the service application requires more energy than native application such as SMS, for purpose of rendering a real-time map and/or acquiring position information and communicating the position information to the service. To alleviate the energy demand on mobile devices, some examples of
Another technical achievement and improvement that is achieved with examples as described is that the user is able to efficiently receive transport service when arriving at a destination, using a communication medium that does not distract the user. An unfamiliar airport, for example, can delay the user if the user loses attention and misses the sign. Examples recognize that any additional requirement on a user, in which the user is to use another service application to arrange a necessary service at the critical time of arrival, poses a distraction that can impede the user and lessen the user's efficiency.
In more detail, the ODTM 500 includes a trigger component 510, a monitoring component 520, timing logic 530, and a communication interface 540. Additionally, the ODTM 500 includes a plurality of application programming interfaces (APIs) 502, 504, 506, for enabling corresponding components to receive or extend communications to other resources (e.g., user device, hotel lodging, airline/airport services 570 etc.). The ODTM 500 can communicate with a reservation interface 505 in order to receive a trip itinerary 515. The reservation interface 505 can be implemented as part of the reservation system 110 (see
From the reservation interface 505, the ODTM 500 receives the trip itinerary 515, which can be in the form of a structured (e.g., form with fields) or unstructured document. The ODTM 500 can include an intake workflow which parses the trip itinerary 515 to determine elements of the planned trip (e.g., see
The monitoring component 520 can implement processes to monitor various resources for conditions 521, 523 which activate triggers 511 of a given trip when the trip is in progress. In an example of
The monitoring component 520 can also check user resources 544 for information that is indicative of other types of conditions 523. The user resources 544 can include a mobile computing device of the user, which can be selectively monitored (with user permission) for information such as (i) user's location, (ii) user's service application activity (e.g., for the on-demand service), and/or (iii) time period when mobile computing device is off and on.
When the trip itinerary 515 is received, the monitoring component 520 can be scheduled to perform monitoring for the trip. In one implementation, the monitoring component 520 can verify the user is going on the trip. For example, the user may have a reservation, and the monitoring component 520 can monitor the user location before the flight departure to ensure the user is keeping the reservation. Other indicators from user activity/inactivity can also be used as confirmation.
On arrival to the destination, the triggering component 510 and the monitoring component 520 can combine to (i) detect the user's arrival, e.g., at an airport, (ii) implement a process or series of communications by which the user is able to obtain on-demand ground transportation in a most efficient manner, and (iii) provide automation with respect to notifications of interested or relevant parties with respect to the current trip. To detect the user's arrival, the monitoring component 520 can interface with the flight tracker 572 to determine when the flight of the user is complete. Once the user's flight is complete, triggers 511 can be activated for implementing a process or series of notifications for efficiently delivering the user to an on-demand ground transportation service. The triggers 511 can result in the communication interface 540 sending the user one or more notifications 541. The notifications 541 can be through a messaging protocol such as SMS, email, or other service (including through the service application).
In one example, the notifications 541 issued through the communication interface 540 can include or provide a guide, such as a map or walking direction, for guiding the user from the arrival gate to a pickup location for the on-demand transport. The guide can optionally direct the user through baggage claim. The itinerary 515 can, for example, include information about whether the user has baggage, or the user can make a selection from the guide as to whether they have baggage or not. If the user has baggage, the monitoring component 520 may determine from the baggage component 576 when and which baggage terminal the user should go to, and further directions on walking to the baggage terminal. The guide provided to the user can be specific as to (i) what floor of the airport the user should be on to receive the on-demand transport; (ii) what door nearest the baggage claim the user should walk through to receive or request on-demand transport; (iii) permissible locations where the user may stand to request or receive on-demand transport; and/or (iv) the location of a stand or designated area where the ground transport can be received. In guiding the user to through the arrival, the monitoring component 520 can also communicate with the mobile computing device of the user, which can provide location information using the device's geo-aware resources. In one implementation, the guide can be provided through a series of text messages, as a mechanism to conserve power.
As an addition or alternative, the notifications 541 can serve to enable the user to time the request for transport. On-demand services typically have a wait time, which can range from less than one minute to several minutes, depending on a variety of factors. For the most efficient delivery of the user through the airport and to the next place of the trip (e.g., lodging), embodiments recognize that the user's wait time for receiving on-demand transport should be minimized. However, it is also a waste of resources for the on-demand provider to wait for the user, as the provider can be servicing individuals who are ready to receive transport. Thus, it is not beneficial for the service if the user makes the request too early, causing the provider to wait (or causing the provider to circle around). An embodiment of
In order to request transport service, the ODTM 500 can enable text message requests. Optionally, the text message requests can be prompted from the user as a reply message 543 to a notification 541. By using SMS, for example, battery life of the user's mobile computing device can be preserved. In variations, the ODTM 500 can simply request the transport service on behalf of the user.
In one implementation, the timing component 530 uses a combination of airport information (static), user information, service demand information (dynamic) and airport traffic congestion (dynamic) to determine a request time interval for the user. In determining the dynamic information such as available drivers and demand for the service, the ODTM 500 can include or access a sub-system 548 which tracks the geo-aware resources of the mobile devices of drivers and users in order to provide real-time information 549 affecting the status of the transport service. The supply for a user at a given airport can be based on available drivers within a defined vicinity of the airport.
In variations, the supply can be based on available drivers and drivers who are on assignment with a passenger, who will arrive at the airport (or within the vicinity) within a designated duration of time. The demand for the transport service can be based on a variety of sources, including the number of users who have requested transport services from ODTM 500, the number of users who have itineraries or reservations for receiving the on-demand transport, the number of users who have turned on a service application from which a transport request has been made, historical data as to time or day, and/or statistical approximation based on number of arriving passengers in a relevant time period.
The request time interval 531 can be communicated to the device of the user, and can identify a length of time which will likely be needed for a service provider to arrive at a pickup location nearest to the user's location at the airport, once the user makes the request. With the request time interval 531, the user can estimate an appropriate time to make the request for transport.
An example of
Furthermore, an example of
In variations, the request for on-demand transport can be made automatically, from the ODTM 500, when the corresponding trigger is activated. When the request is made automatically, the user information can be communicated to the driver, and a confirmation of the request being made and/or being accepted can be communicated to the user. When the provider is on route, the user can be given an estimated time to arrival for the provider.
The timing of the notification (or automated transport request) can vary based on dynamic real-time information 549, such as the demand for service providers and the corresponding supply, as well as traffic or congestion near the airport. As the timing of the optimal instance for requesting the on-demand transport is based on information that is not available to the user (e.g., the dynamic information of available service providers and demand thereof, as well as traffic or congestion) an embodiment as described provides another instance of an achievement in efficiency of operation that is technical, and outside the realm of manual involvement.
In some variations, the notifications 541 can be structured or communicated through a transport that enables the user to reply, either with information or with questions. For example, if the user stops to use the bathroom, he can send a reply notification 543, which the communication interface 540 can parse to determine that the user progress through the airport may be delayed.
The communication interface 540 can also structure links 545 in notifications 541 which can be selected by the user to (i) launch the user's service application, and (ii) receive updated application data specific to the user's current state (e.g., current location, whether transport has been requested, time of arrival, etc.) of the user. In one implementation, the communication interface 540 initiates an instance of the user's service application at a determined moment after when the user's flight arrives at the destination. For example, the trigger component 510 can trigger the communication interface 540 to initiate an instance of the user's service application at a particular moment in time after the user's flight arrives. The moment in time can be a constant (e.g., 5 minutes after landing), conditional (e.g., upon user replying to a text message), or even variable (e.g., based on time of user to arrive to pickup location). When communicated through a medium such as SMS, the notifications can embed the link 545 which links to updated application state information for the instance of the application which is running on the communication component 540. With selection of the link 545, the service application may launch on the user device, and the service application may identify the application state information from the communication interface 540 so that the service application running on the user device is quickly up to date.
Throughout the timeline of when the user arrives at the destination, receives the on-demand transport, and travels to the place of interest, the trigger component 510 and monitoring component 520 continue to monitor for pre-defined conditions in order to anticipate next actions. For example, if the user's flight was on time, but the user's arrival to the transport provider was late, the monitor 520 can detect a delay as an expected schedule, and the triggering component 510 can trigger the communication component 540 to generate (and optionally send) a communication (e.g., email, SMS) to a relevant part of the place of interest. The relevant party can be, for example, a lodging host, a hotel front desk, or a person whom needs the user has previously indicated as being a contact for the place of interest (e.g., business associate whom a meeting is with). These other parties can be accessed as TIPR 550. For example, a notification to the lodging can include (i) the communication component 540, selecting a transport (e.g., SMS, email) for a particular lodging service 560 in order to convey information. The lodging transport 560 can, in some instances include a service interface 562 (e.g., network interface, website, email address) where notifications can be received. In other instances, the lodging can, for example, be hosted by a private individual (e.g., AIRBNB) and the communication can be configured for a communication end point 564, such as an email address or cellular phone number.
While examples as described serve to conserve the power level (e.g., battery life, battery power level, etc.) of a user's mobile computing device in a situation where the power level can be low, a variation also provides for a contingency of the user being without use of the mobile computing device (e.g., the mobile computing device becomes fully drained). Under conventional approaches when such scenarios occur, the user is not able to request on-demand service. However, in examples provided, the itinerary 515 is known, which sets a schedule that is predictive of the user's progress through the airport. Moreover, the monitoring component 520 can confirm when the user's flight arrives at the destination. The use of schedule information enables the ODTM 500 to provide a contingency plan for the user, in order to enable the user to receive on-demand transportation when the user's mobile computing device is not operative. The contingency plan can be activated by the triggering component 510 when conditions such as the user failing to respond to text messages, or the user failing to turn his or her device on, are detected. As part of the contingency plan, one implementation provides that the user is provided, in advance (e.g., with the travel itinerary) (i) a code, such as a 4 sequence numeral or word, and/or (ii) directions to where the user is to wait for pickup or stand for on-demand travel, and/or (iii) the duration of time the user is to wait. While the user name or other identifier can suffice, the code enables the user to preserve his privacy and personal information.
When the contingency plan is triggered, the ODTM 500 can perform one or more of the following operations: (i) request transport for the user at an appropriate time (e.g., ten minutes after flight arrives), (ii) identify the code to an operator or driver who is assigned to pick up the passenger, (iii) identify the passenger by picture or otherwise (e.g., by biometric data such as fingerprint), and/or (iv) communicate to the driver the place of interest (as determined from the itinerary 515). In this way, the user who arrives without use or availability of the mobile computing device can progress through the airport with the expectation that he or she will receive on-demand transport.
With reference to an example of
Once the flight is determined to arrive, the ODTM 500 can implement triggers which include sending the user one or more notifications or messages (630) containing information for facilitating the user in requesting and/or receiving transport services. The information can include (i) a location at the airport where the user can be picked up in connection with receiving the on-demand transportation service (632), and (ii) a timing indicator to indicate when a request to receive the on-demand transportation service should be made (634). The timing indicator can be based on a variety of factors that take into account both the time needed for a transport request to be fulfilled with the arrival of a transport provider to the pickup location (e.g., request time interval 531), and a time duration needed for the passenger to arrive at a pickup location (e.g., time-to-reach pickup interval 533). Determinations such as the request time interval 531 and the time-to-reach pickup interval 533 can utilize variable or dynamic information, including information that is outside of the knowledge of the user.
For example, the determination of the request time interval 531 may based on real-time and/or predictive information in regards to a determination of a number of available service providers in a vicinity of the airport (642), as well as a real-time determination of a number of requesters for the transport service (644). The available service providers can be determined based on an expectation of when the user will request the transport service. Thus, for example, the determination can include an estimation of available vehicles that takes into account the number of currently available vehicles which will become unavailable when the transport request is made, and the number of currently unavailable vehicles which will become available in the vicinity of the airport when the transport request is made. Likewise, the real-time determination of requesters can include an expectation of demand at the moment when the user makes the transport request. This information can be based on historical information, statistical data (e.g., number of travelers in the airport versus percentage of travelers who use on-demand ground transportation), reserved or planned on-demand transportation requests (which can be compiled from itineraries of other travelers) and/or mobile computing device/application activity of users.
The timing indicator of the passenger may also be a dynamic and real-time determination, subject to events specific to the user (e.g., bathroom stop). Information such as (i) a determination (e.g., from the itinerary 515) of whether the user has baggage, and (ii) a gate of arrival can be used to plot and predict when the user has traversed through the airport.
With these determinations in mind, the request for transport can be optimally timed to reduce the user's wait time, while avoiding the service provider from having to wait for the user.
Hardware Diagram
In one implementation, computer system 700 includes processing resources 710, a main memory 720, a ROM 730, a storage device 740, and a communication interface 750. Computer system 700 includes at least one processor 710 for processing information and a main memory 720, such as a random access memory (RAM) or other dynamic storage device, for storing information and instructions to be executed by the processor 710. Main memory 720 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor. Computer system 700 may also include a read only memory (ROM) 730 or other static storage device for storing static information and instructions for processor. A storage device 740, such as a magnetic disk, a solid-state storage, or an optical disk, is provided for storing information and instructions. For example, the storage device 740 can correspond to a computer-readable medium that stores recommendation engine instructions 742 for performing operations discussed with respect to
The communication interface 750 can enable computer system 700 to communicate with one or more networks 780 (e.g., cellular network) through use of the network link (wireless or via a wire). Using the network link, computer system 700 can communicate with a plurality of travel systems and can provide a portal to be accessible by users operating their respective computing devices. According to some examples, computer system 700 can receive a set of initial travel information 772 for a trip of a user from a user's computing device via the network link. The recommendation engine instructions 742 can be executed by the processor 710 to implement the recommendation engine in order to (i) receive a set of data 774 from airline and/or lodging system(s) based on the set of initial travel information 772, (ii) determine one or more recommended itineraries for the trip, and (iii) in response to a user request to reserve a selected recommended itinerary, transmit reservation requests 776 to the respective airline and/or lodging system(s) that provide the travel recommendations in the selected recommended itinerary.
Computer system 700 can also include a display device 760, such as a cathode ray tube (CRT), an LCD monitor, or a television set, for example, for displaying graphics and information to a user. An input mechanism 770, such as a keyboard that includes alphanumeric keys and other keys, can be coupled to computer system 700 for communicating information and command selections to the processor 710. Other non-limiting, illustrative examples of input mechanisms 770 include a mouse, a trackball, touch-sensitive screen, or cursor direction keys for communicating direction information and command selections to the processor 710 and for controlling cursor movement on display.
Examples described herein are related to the use of computer system 700 for implementing the techniques described herein. According to one example, those techniques are performed by computer system 700 in response to the processor 710 executing one or more sequences of one or more instructions contained in main memory 720, such as the recommendation engine instructions 742. Such instructions may be read into main memory 720 from another machine-readable medium, such as the storage device 740. Execution of the sequences of instructions contained in main memory 720 causes the processor 710 to perform the process steps described herein. In alternative implementations, hard-wired circuitry may be used in place of or in combination with software instructions to implement examples described herein. Thus, the examples described are not limited to any specific combination of hardware circuitry and software.
It is contemplated for examples described herein to extend to individual elements and concepts described herein, independently of other concepts, ideas or system, as well as for examples to include combinations of elements recited anywhere in this application. Although examples are described in detail herein with reference to the accompanying drawings, it is to be understood that the concepts are not limited to those precise examples. Accordingly, it is intended that the scope of the concepts be defined by the following claims and their equivalents. Furthermore, it is contemplated that a particular feature described either individually or as part of an example can be combined with other individually described features, or parts of other examples, even if the other features and examples make no mentioned of the particular feature. Thus, the absence of describing combinations should not preclude having rights to such combinations.
Claims
1. A network computer system comprising:
- a network communication interface;
- one or more processors; and
- a memory that stores a set of instructions, that when executed by the one or more processors, cause the network computer system to: upon detecting a user having arrived at an airport: receive, via the network communication interface and from a mobile computing device of the user, location information indicating a current location of the user; based at least on the current location of the user, determine a time-to-reach pickup interval indicating an estimated amount of time for the user to travel from the current location of the user to a pickup location at the airport where the user can receive a transport service; receive, via the network communication interface and from each of a set of mobile computing devices of a set of service providers, location information indicating a current location of each of the set of service providers; based on the current location of at least one service provider of the set of service providers, determine a request time interval indicating an estimated amount of time for a service provider to travel to the pickup location; based on the request time interval and the time-to-reach pickup interval, determine a computed request time indicating a time to trigger a service request such that the user arrives at the pickup location approximately when a service provider arrives at the pickup location; and automatically trigger the service request by transmitting, via the network communication interface and to a mobile computing device of a selected service provider from the set of service providers, a set of data at the computed request time, the set of data indicating at least the pickup location.
2. The network computer system of claim 1, wherein the at least one service provider is within a vicinity of the airport.
3. The network computer system of claim 2, wherein the at least one service provider is available.
4. The network computer system of claim 1, wherein execution of the set of instructions by the one or more processors further cause the network computer system to:
- transmit, via the network communication interface and to the mobile computing device of the user, a notification including information associated with the pickup location at the airport.
5. The network computer system of claim 4, wherein the notification includes a text notification with a link to an application.
6. The network computer system of claim 5, wherein execution of the set of instructions by the one or more processors further cause the network computer system to:
- structure the link to provide updated application information that is specific to the user.
7. The network computer system of claim 4, wherein the information provided in the notification includes a map indicating the pickup location for receiving the transport service.
8. The network computer system of claim 7, wherein execution of the set of instructions by the one or more processors further cause the network computer system to:
- determine an arrival terminal at which the user is located; and
- wherein the map identifies the pickup location that is specific to the arrival terminal.
9. The network computer system of claim 1, wherein the computed request time is further based on an estimation of a demand for the transport service.
10. The network computer system of claim 9, wherein the estimation for the demand is based on an estimation of a number of open service requests and a number of predicted service requests for the transport service in a given duration corresponding to the computed request time.
11. The network computer system of claim 10, wherein the computed request time is further based at least in part on a predicted time for the user to locate baggage.
12. The network computer system of claim 10, wherein the computed request time is further based at least in part on a predicted time for the user to pass through customs.
13. A computer implemented method comprising:
- upon detecting a user having arrived at an airport: receiving, via a network communication interface and from a mobile computing device of the user, location information indicating a current location of the user; based at least on the current location of the user, determining a time-to-reach pickup interval indicating an estimated amount of time for the user to travel from the current location of the user to a pickup location at the airport where the user can receive a transport service; receiving, via the network communication interface and from each of a set of mobile computing devices of a set of service providers, location information indicating a current location of each of the set of service providers; based on the current location of at least one service provider of the set of service providers, determining a request time interval indicating an estimated amount of time for a service provider to travel to the pickup location; based on the request time interval and the time-to-reach pickup interval, determining a computed request time indicating a time to trigger a service request such that the user arrives at the pickup location approximately when a service provider arrives at the pickup location; and automatically triggering the service request by transmitting, via the network communication interface and to a mobile computing device of a selected service provider from the set of service providers, a set of data at the computed request time, the set of data indicating at least the pickup location.
14. The computer implemented method of claim 13, wherein the at least one service provider is within a vicinity of the airport.
15. The computer implemented method of claim 14, wherein the at least one service provider is available.
16. The computer implemented method of claim 13, further comprising:
- transmitting, via the network communication interface and to the mobile computing device of the user, a notification including information associated with the pickup location at the airport.
17. The computer implemented method of claim 16, wherein the information provided in the notification includes a map indicating the pickup location for receiving the transport service.
18. The computer implemented method of claim 17, further comprising:
- determining an arrival terminal at which the user is located; and
- wherein the map identifies the pickup location that is specific to the arrival terminal.
19. The computer implemented method of claim 13, wherein the computed request time is further based on an estimation of a demand for the transport service, and wherein the estimation for the demand is based on an estimation of a number of open service requests and a number of predicted service requests for the transport service in a given duration corresponding to the computed request time.
20. A non-transitory computer readable medium storing instructions that, when executed by one or more processors of a network computer system, cause the network computer system to:
- upon detecting a user having arrived at an airport: receive, via a network communication interface and from a mobile computing device of the user, location information indicating a current location of the user; based at least on the current location of the user, determine a time-to-reach pickup interval indicating an estimated amount of time for the user to travel from the current location of the user to a pickup location at the airport where the user can receive a transport service; receive, via the network communication interface and from each of a set of mobile computing devices of a set of service providers, location information indicating a current location of each of the set of service providers; based on the current location of at least one service provider of the set of service providers, determine a request time interval indicating an estimated amount of time for a service provider to travel to the pickup location; based on the request time interval and the time-to-reach pickup interval, determine a computed request time indicating a time to trigger a service request such that the user arrives at the pickup location approximately when a service provider arrives at the pickup location; and automatically trigger the service request by transmitting, via the network communication interface and to a mobile computing device of a selected service provider from the set of service providers, a set of data at the computed request time, the set of data indicating at least the pickup location.
Type: Application
Filed: Jul 19, 2019
Publication Date: Nov 7, 2019
Inventor: Howard David Jaffe (Pacifica, CA)
Application Number: 16/517,468
