US20220215499A1 - Hierarchical selection process - Google Patents
Hierarchical selection process Download PDFInfo
- Publication number
- US20220215499A1 US20220215499A1 US17/587,226 US202217587226A US2022215499A1 US 20220215499 A1 US20220215499 A1 US 20220215499A1 US 202217587226 A US202217587226 A US 202217587226A US 2022215499 A1 US2022215499 A1 US 2022215499A1
- Authority
- US
- United States
- Prior art keywords
- transport
- scheduled
- provider
- request
- fulfill
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 38
- 230000008569 process Effects 0.000 title abstract description 20
- 238000012790 confirmation Methods 0.000 claims description 19
- 230000032258 transport Effects 0.000 description 324
- 230000007423 decrease Effects 0.000 description 11
- 238000004364 calculation method Methods 0.000 description 9
- 230000000875 corresponding effect Effects 0.000 description 9
- 238000010586 diagram Methods 0.000 description 9
- 238000004891 communication Methods 0.000 description 8
- 238000013459 approach Methods 0.000 description 6
- 238000013507 mapping Methods 0.000 description 6
- 238000012545 processing Methods 0.000 description 6
- 230000004044 response Effects 0.000 description 6
- 238000010276 construction Methods 0.000 description 5
- 230000000977 initiatory effect Effects 0.000 description 4
- 230000001413 cellular effect Effects 0.000 description 3
- 230000002596 correlated effect Effects 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 230000008901 benefit Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 230000003190 augmentative effect Effects 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 230000001934 delay Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000000446 fuel Substances 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 230000002452 interceptive effect Effects 0.000 description 1
- 238000010801 machine learning Methods 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000005055 memory storage Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 229920006395 saturated elastomer Polymers 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 239000002699 waste material Substances 0.000 description 1
Images
Classifications
-
- G06Q50/40—
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
- G06Q50/30—Transportation; Communications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/10—Office automation; Time management
- G06Q10/109—Time management, e.g. calendars, reminders, meetings or time accounting
- G06Q10/1093—Calendar-based scheduling for persons or groups
- G06Q10/1097—Task assignment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0201—Market modelling; Market analysis; Collecting market data
- G06Q30/0206—Price or cost determination based on market factors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/02—Marketing; Price estimation or determination; Fundraising
- G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
- G06Q30/0208—Trade or exchange of goods or services in exchange for incentives or rewards
Definitions
- the network system can also manage the on-demand transport service by connecting requesting users with available transport providers and/or autonomous vehicles (AVs) operating throughout the given region.
- the network system can receive user requests for transportation from requesting users via a designated application executing on the users' mobile computing devices.
- the network system can identify a number of proximate available transport providers and transmit a transport invitation (e.g., an interactive notification) to one or more transport provider devices of the proximate available transport providers to service the transport request.
- the transport providers s can either accept or decline the invitation based on a variety of reasons, for example, the route being too long or having a destination that is impractical for the transport provider.
- one or more of the proximate available transport providers can comprises an AV, and thus the network system can transmit a transport directive instructing a most optimal SDV to service the transport request.
- the user can request a particular ride type. Accordingly, when the scheduled ride time approaches, the network system can begin transmitting transport invitations to drivers of the requested ride type. In many examples, the request will be accepted, in which case the scheduled ride will be services successfully. However, in the event that the invitation is not accepted by any proximate available vehicles of the particular ride type (e.g., based on an ETA threshold), the network system can fail over to an alternative ride type option. Thus, in this case, the network system can look up ETA information from drivers and/or SDVs of an alternative ride type and begin transmitting transport directives to proximate available drivers or vehicles until the scheduled ride is accepted.
- the network system can look up ETA information from drivers and/or SDVs of an alternative ride type and begin transmitting transport directives to proximate available drivers or vehicles until the scheduled ride is accepted.
- the network system can provide compensation schemas for both requesting users and drivers based on lateness and/or cancelations by both driver and requesting user.
- the network system can monitor the selected vehicle via, for example, location-based resources (e.g., global positioning system (GPS) resources) of the driver's mobile computing device to identify when the optimal vehicle arrives at the start location. If the scheduled start time has passed and the vehicle has arrived at the start location, this may indicate that the requesting user is late.
- the network system can initiate a fare meter for the scheduled ride as the driver awaits the requesting user at the start location.
- location-based resources e.g., global positioning system (GPS) resources
- the scheduling engine 140 can generate and transmit a sequence of reminders 146 to the user device 190 .
- the scheduling engine 140 can generate a first reminder 146 exactly one day prior to the scheduled transport time, a second reminder two hours prior, and a final reminder thirty minutes prior to the transport time.
- the reminders 146 can be generated as push notifications that can wake up the user device 190 if it is in a low power mode, or overlay displayed content.
- the user can utilize the reminder 146 to either confirm the scheduled transport 142 or cancel the scheduled transport 142 , in which case the scheduling engine 140 can flush the scheduled transport 142 entry from the ride scheduling logs 132 .
- the pricing engine 165 can initiate a standard fare meter for the transport service type once the driver accepts the transport invitation 182 . If the requesting user cancels the scheduled transport 142 , the pricing engine 165 can incur a charge to the requesting user based on the standard rate between transport provider acceptance 183 and the cancelation time. In variations, the pricing engine 165 can calculate the cancelation fee at a separate cancelation rate, or can charge a flat fee.
- the network system 100 can implement a number of backup measures to ensure fulfillment of each scheduled transport 142 .
- backup measures can include features described herein such as moving supply and failing over to alternative ride service types.
- rapid data collection can enable the pricing engine 165 to accurately predict upfront prices 167 for not only on-demand rides based on current information (e.g., weather, traffic, supply, demand, etc.), but also for future scheduled transport requests 198 to provide users with added certainty in utilizing the transport arrangement services managed by the network system 100 .
- the network system 100 in checking the transport supply for the scheduled transport request 198 , can determine that driver and/or SDV supply is insufficient ( 570 ). For example, the system 100 can identify a certain risk factor that no transport providers will be available within a certain proximate of the start location. In such scenarios, the network system 100 can fall back on a number of options or combination of options. In one example, the network system 100 can generate and transmit an incentive offer 184 to one or more transport providers close to the start location ( 575 ), to which the transport providers may accept or decline ( 575 ).
Abstract
A network computer system can implement a hierarchical selection process to fulfill a scheduled transport request. The hierarchical selection process can include a first selection process and a second selection process. The first selection process can include assigning a first transport provider to fulfill the scheduled transport request. The second selection process can be implemented at a specified time prior to the scheduled time and can include selecting a backup transport provider to service the scheduled transport request.
Description
- This application is a continuation of U.S. patent application Ser. No. 16/423,623, filed on May 28, 2019; which is a continuation of U.S. patent application Ser. No. 15/615,754 filed Jun. 6, 2017 (now U.S. Pat. No. 10,395,333), which claims benefit of priority to U.S. Provisional Application No. 62/347,043, filed on Jun. 7, 2016; the aforementioned priority applications being hereby fully incorporated by reference in their entireties.
- On-demand transport services can provide a platform connecting available transport providers with requesting users using designated applications executing on mobile devices. Typically, users make requests at the time a transport service is needed, and a network system arranges the transport service to be provided by an available transport provider.
- The disclosure herein is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements, and in which:
-
FIG. 1 is a block diagram illustrating an example transport network system in communication with user devices and a fleet of transport providers, as described herein; -
FIG. 2 is a block diagram illustrating a user device executing a designated application for a transport arrangement service, as described herein; -
FIG. 3 is a block diagram illustrating a driver device executing a designated driver application for a transport arrangement service, as described herein; -
FIGS. 4A through 4E are example screenshots illustrating the scheduled rides feature on a user device executing a designated application, according to examples described herein; -
FIG. 5 is a flow chart describing an example method of implementing a scheduled transport service, according to examples described herein; -
FIG. 6 is a flow chart describing example methods of coordinating scheduled transport, according to examples described herein; and -
FIG. 7 is a block diagram illustrating a computer system upon which examples described herein may be implemented. - A network system is disclosed herein that can provide a ride scheduling feature for a designated application of an on-demand transportation service. According to examples described herein, the ride scheduling feature can enable users to schedule future rides with the on-demand transportation service—which can be managed by the network system. The network system can receive user requests for scheduled transport requests, where the user can input a future time for service (e.g., a scheduled future date and/or time, as compared to the current time), a start location, and a destination. In certain implementations, the network system can manage a ride or transport service scheduling log (referred to herein as scheduling log) including all scheduled transport services for a given region.
- In many examples, the network system can also manage the on-demand transport service by connecting requesting users with available transport providers and/or autonomous vehicles (AVs) operating throughout the given region. In doing so, the network system can receive user requests for transportation from requesting users via a designated application executing on the users' mobile computing devices. Based on an inputted start location, the network system can identify a number of proximate available transport providers and transmit a transport invitation (e.g., an interactive notification) to one or more transport provider devices of the proximate available transport providers to service the transport request. In many examples, the transport providers s can either accept or decline the invitation based on a variety of reasons, for example, the route being too long or having a destination that is impractical for the transport provider. In certain variations, one or more of the proximate available transport providers can comprises an AV, and thus the network system can transmit a transport directive instructing a most optimal SDV to service the transport request.
- When nearing the scheduled time for transport, the network system can select and/or transmit a transport invitation to an optimal transport provider to service the scheduled transport request and transmit a confirmation to the user device via the designated application that the optimal vehicle is selected and/or traveling to the start location. As used herein, the term “optimal” transport provider can include a closest proximate transport provider or vehicle in relation to the start location that accepts the transport invitation. As such, an actual closest proximate available transport provider may decline the invitation, which can cause the network system to perform a number of backup options, such as selecting a next best option, or failing over to an alternative service type (e.g., a black car service if normal peer-to-peer options are unavailable). Thus, the “optimal” transport provider can comprise a best available option given the transport providers' ability to decline a transport invitation or directive. The network system can perform a hierarchical selection process when a series of rejections are received in order to converge on an optimal transport provider to ultimately service the scheduled transport request. Examples described herein recognize that non-fulfillment of a scheduled transport service can cause consumer distrust and significant inconvenience, and therefore extending backup options (described in detail herein) can provide assurances that each scheduled transport request is serviced within tolerable time constraints, despite having to resort to backup options.
- In many examples, the network system can compile historical pricing data for individual trips executed throughout the given region. Such pricing data can be compiled for every trip utilizing the core on-demand transport services as well as the scheduled transport services described herein. In some examples, the network system can utilize the historical pricing data to determine an upfront price for a scheduled transport request for a requesting user. The upfront price can further be based on the scheduled date, the scheduled time, the start location, and the destination indicated in the scheduled transport request. In some examples, the historical pricing data can include surge pricing data for time windows in specified areas of the given region based on driver supply versus user demand.
- Furthermore, various additional factors may be considered by the network system in determining the upfront price, such as accessing a weather resource to determine likely weather conditions for the future date and time, accessing event schedules for the given region to determine whether a particular event (e.g., a sporting event, a concert, road construction, etc.) will coincide with the scheduled ride. Accordingly, given all such factors as historical pricing data for similar rides, timing data indicating historical supply/demand price surging, weather forecast data for the scheduled ride, scheduled road construction or maintenance, and/or event data corresponding to the scheduled transport request, the network system can filter the compiled pricing data to determine the upfront price for the scheduled transport request. In many examples described herein, the upfront price can comprise a guaranteed cost for the scheduled ride to the user based on the historical pricing data, whereas the network system can provide payment to a transport provider of the optimal vehicle for the scheduled ride based on time and distance traveled in servicing the scheduled ride.
- In certain implementations, the network system may require a certain confidence level with regard to offering the upfront price to requesting users. For example, for each scheduled ride, the network system can perform a price optimization based on the foregoing inputs to determine the upfront price and calculate a probability that the actual cost (e.g., including payment to the driver) will be within a predetermined error range of the upfront price (e.g., >95% probability that the actual cost will be within $0.50 of the upfront price offered). Accordingly, if the probability calculation is not within the acceptable tolerances, the network system can schedule the transport request to include normal trip pricing for the on-demand transportation service (e.g., based on time and distance traveled).
- According to some examples, when variances in factors for predicting upfront prices (e.g., based on uncertain weather conditions, historical pricing data, scheduled events, etc.) cause probability calculations for upfront prices to exceed certainty thresholds for a particular area or sub-region, the network system can input blackout periods for such areas or sub-regions in which scheduled rides and/or upfront pricing is unavailable. For example, certain rare events in a given sub-area may cause uncertainty in driver supply and/or SDV supply, such that the network system may be unable to provide a guarantee (or near-guarantee) of transport facilitation. Given that non-fulfillment of scheduled rides can result in significant consumer inconvenience or disappointment, the network system may black out the scheduling service for such uncertain time periods in those sub-regions.
- In certain variations, the network system can provide an incentive to “move supply” when proximate available transport providers are lacking for a particular upcoming scheduled ride. For example, prior to the scheduled time for start (e.g., 30 minutes prior), the network system can perform a lookup of estimated time of arrival (ETA) information based on driver device locations and/or SDV locations to identify that the scheduled start location is relatively remote from the driver and/or SDV supply. According to some examples, the network system can generate and transmit an offer incentive to transport provider devices to travel to the start location or closer to the start location in order to ensure that the scheduled ride is serviced. The offer incentive can comprise set monetary offer, an initiation of a fare meter to compensate the driver for traveling to the start location, a service bonus or credit, and the like.
- As described herein, the network system can provide a plurality ride service options, such as a peer-to-peer ride service option, a ride pool service option, a luxury ride service option, a large vehicle ride service option, a professional ride service option, and the like. Each service option can comprise a different fare calculation and can include drivers and/or vehicles that meet certain requirement. For example, a luxury ride service option can guarantee a luxury type vehicle of a particular quality, brand, year, etc., but may be driven by an ordinary peer-to-peer driver. As another example, the professional ride service option can guarantee a credentialed driver and a certain vehicle type (e.g., a professional driver and/or a black car, such as a limousine). In inputting the user request for a scheduled ride, the user can request a particular ride type. Accordingly, when the scheduled ride time approaches, the network system can begin transmitting transport invitations to drivers of the requested ride type. In many examples, the request will be accepted, in which case the scheduled ride will be services successfully. However, in the event that the invitation is not accepted by any proximate available vehicles of the particular ride type (e.g., based on an ETA threshold), the network system can fail over to an alternative ride type option. Thus, in this case, the network system can look up ETA information from drivers and/or SDVs of an alternative ride type and begin transmitting transport directives to proximate available drivers or vehicles until the scheduled ride is accepted.
- Furthermore, given the schedule intensive nature of the scheduled ride service, the network system can provide compensation schemas for both requesting users and drivers based on lateness and/or cancelations by both driver and requesting user. In one example, the network system can monitor the selected vehicle via, for example, location-based resources (e.g., global positioning system (GPS) resources) of the driver's mobile computing device to identify when the optimal vehicle arrives at the start location. If the scheduled start time has passed and the vehicle has arrived at the start location, this may indicate that the requesting user is late. In order to compensate the transport provider for the loss of time, the network system can initiate a fare meter for the scheduled ride as the driver awaits the requesting user at the start location.
- Additionally or alternatively, the driver and/or requesting user may cancel the scheduled ride without charge up until a certain time prior to the scheduled start time (e.g., until a driver accepts the scheduled ride). Thereafter, the network system can initiate a cancelation fee rate calculation that progresses as the scheduled time for start approaches. Such a feature can essentially transfer funds between the connected driver and requesting user based on inconvenience, fuel or energy costs, and/or wasted time.
- Among other benefits, the examples described herein achieve a technical effect of combining ride scheduling services with an on-demand transport service platform. The disclosed transport coordination system can leverage an existing on-demand transportation arrangement platform, in which ETA data may be utilized to invite drivers or proximate SDVs to service a scheduled ride as the start time approaches. Furthermore, since historical pricing data is available for rides throughout a given region based on the on-demand service, the network system may provide upfront pricing for a scheduled ride to give the requesting user a guaranteed price for the scheduled ride. Still further, because the on-demand ride service can provide multiple different ride service options, the network system can implement a failover process, or utilize alternative ride service types as backup options, if a requested ride service type is unavailable or impracticable.
- As used herein, a computing device refers to devices corresponding to desktop computers, cellular devices or smartphones, personal digital assistants (PDAs), laptop computers, tablet devices, virtual reality (VR) and/or augmented reality (AR) devices, wearable computing devices, television (IP Television), etc., that can provide network connectivity and processing resources for communicating with the system over a network. A computing device can also correspond to custom hardware, in-vehicle devices, or on-board computers, etc. The computing device can also operate a designated application configured to communicate with the network service.
- 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. For example, one or more examples described herein may be implemented, in whole or in part, on computing devices such as servers, 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 disclosed herein can be carried and/or executed. In particular, the numerous machines shown with examples of the invention include processors 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 those 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.
- Numerous examples are referenced herein in context of an autonomous vehicle (AV) or self-driving vehicle (SDV). An AV or SDV refers to any vehicle which is operated in a state of automation with respect to steering and propulsion. Different levels of autonomy may exist with respect to AVs and SDVs. For example, some vehicles may enable automation in limited scenarios, such as on highways, provided that drivers are present in the vehicle. More advanced AVs and SDVs can drive without any human assistance from within or external to the vehicle.
- System Description
-
FIG. 1 is a block diagram illustrating an example network system in communication with user devices and a fleet of transport providers, as described herein. Thenetwork system 100 can include arequester interface 105 in communication with user devices 190 executing a designatedapplication 195 over one ormore networks 180. Thenetwork system 100 can further include avehicle interface 115 to communication with any number ofvehicles 185 operating throughout a given region (e.g., a metropolitan area such as New York City or the San Francisco Bay Area). In some aspects, thenetwork system 100 can communicate with human drivers of such vehicles over the network(s) 180 via the drivers' devices 188 (e.g., mobile computing devices executing a designated provider application 187). Additionally or alternatively, thenetwork system 100 can communicate with any number of self-driving vehicles (SDVs) 189 operating throughout the given region to service start requests. - According to examples described herein, a user of a particular user device 190 can input sets of data indicating user requests 196 in connection with the transportation services managed by the
network system 100.Such user requests 196 can be in the form of an on-demand transport request 197, indicating that the user wishes to request immediate or near-immediate pick-up. Thetransport request 197 can include a start location, which thenetwork system 100 can utilize to service thetransport request 197. - Specifically, the
network system 100 can include aselection engine 135 which can process thetransport request 197 to determine a set of proximate available transport providers utilizing the start location and the locations oftransport providers 181 operating throughout the given region. Thescheduling engine 135 can receive theprovider locations 181 utilizing the location based resources (e.g., GPS resources) of thedriver devices 188. Thus, for on-demand ride services, thenetwork system 100 can determine a set of proximate available transport providers in relation to the start location included in thetransport request 197, and generate and transmit transport invitations ordirectives 182 to optimal transport providers or SDVs (e.g., a closest driver or SDV in relation to the start location). As described herein, the transport provider can input anacceptance 183 of thetransport invitation 182 via the designatedprovider application 187 and thus drive to the start location to rendezvous with the requesting user. For SDV implementations, thetransport invitation 182 may be in the form of a directive instructing theSDV 189 to autonomously drive to the start location to rendezvous with the requesting user. - As provided herein, the
network system 100 can manage several different ride service types, such as a peer-to-peer ride service option, a ride pool service option, a luxury ride service option, a large vehicle ride service option, a professional ride service option, and the like. In submitting the on-demand start request 197, the user can further specify a ride service type, which theselection engine 135 can utilize as a filter for the receivedprovider locations 181. In some examples, the user can scroll through the different transport service types on the designatedapplication 195. Thenetwork system 100 can providedynamic ETA data 148 to the user device 190 indicating an estimated time of arrival for one or more available transport providers of that particular type. For example, theprovider locations 181 can be filterable by theselection engine 135 based on the vehicle type and/or service type for which the vehicle is qualified. Along these lines, theselection engine 135 can utilizemap data 179 and/ortraffic data 177 from amapping engine 175, and theprovider locations 181 of thevarious vehicles 185 operating throughout the given region, to provide the user with theETA data 148 for each scrolled service type. Thus, if astart request 197 indicates a service type, theselection engine 135 can filter through thevehicles 185 proximate to the start location in order to transmit one or more transport invitations ordirectives 182 to only those vehicles that satisfy the characteristics of the specified service type. - The
network system 100 can correlate each ride service type to a different fare calculation. For example, a ride pool service option can be correlated with a lowest fare calculation, whereas a professional ride service option can be correlated with a highest fare calculation. Accordingly, thenetwork system 100 can include apricing engine 165 that can provide an estimatedcost range 168 for a requested ride based onhistorical pricing data 162 in adatabase 160, the specified ride service type in thestart request 197, current or estimated traffic conditions indicated in thetraffic data 177, and a proposed route between the start location and an inputted destination indicated in thetransport request 197. In some examples, the user can accept the ride service based on the estimatedcost range 168 determined by thepricing engine 165. - In additional to providing the on-demand transport arrangement services, the
network system 100 can further provide a scheduled transport service option through the designatedapplication 195. As provided herein, the scheduled transport feature can be selected by a user to input a set of data corresponding to auser request 196 in the form of a scheduledtransport request 198. Thenetwork system 100 can include ascheduling engine 140 that can manage a set of ride scheduling logs 132 inmemory 130 in order to facilitate administration of the scheduled transport service. - In various implementations, the
network system 100 can further include anetwork interface 125 that enables access to a number ofthird party resources 155, such as websites, event calendars for the given region, weather forecasting resources, public works resources indicating road construction, calendar resources (e.g., indicating holidays), airport or airline calendars indicating saturated flight periods, and other third-party sources that can indicate localized traffic and future demand for transport services for certain sub-regions throughout the given region. In some examples, thescheduling engine 140 can utilize the third-party data 157 from theresources 155 to inputblackout times 134 in the scheduling logs 132, in which thenetwork system 100 does not offer the scheduled transport service. For example, the third-party data 157 can indicate high potential variance in transport service demands due to a sporting event, a concert, a holiday, a time of day, a time of week, a holiday, etc., and any combination of factors that may increase the potential variance. Thus, in determining theblackout times 134, thescheduling engine 140 can calculate a certainty probability of transport service demand for sub-regions within the given region based, at least in part, on the third-party data 157, and if uncertainty exceeds a certain threshold (e.g., 15% uncertainty), thescheduling engine 140 can blackout a time period for that sub-region. Alternatively, the third-party data 157 indicating potential variance in transport service demand can be ultimately utilized by thepricing engine 165 in providing anupfront price 167 for a particular scheduledride request 198, as described in further detail below. - Upon receiving a scheduled
transport request 198, thescheduling engine 140 can input data indicating a scheduledtransport 142 into the scheduling logs 132 for the requesting user. In certain implementations, the scheduledtransport 142 can include a start location, a destination, and a start time and start date. In further implementations, the scheduledtransport 142 can also indicate a transport service type offered by thenetwork system 100. According to examples described herein, the scheduled transport service can be offered up to a predetermined amount of time in advance of the scheduled transport request 198 (e.g., two weeks or a month). Thus, in one example, the scheduling logs 132 need only be managed by thescheduling engine 140 up to the predetermined amount of time. Furthermore, in certain implementations, the requesting user can edit the scheduledtransport 142 up until a certain amount of time prior to the scheduled start time. Thescheduling engine 140 can process such edits accordingly in the scheduling logs 132. - In certain implementations, the
scheduling engine 140 andselection engine 135 can coordinate to generate aclaim offer 186 for the scheduledride 142, and transmit theclaim offer 186 to one or more select drivers based on any number of factors. In various aspects, the characteristics of the scheduledride 142 can enable theselection engine 135 to identify a set of optimal drivers that may be interested in claiming the scheduledride 142. For example, the start time and start location can be correlated to a home location of a driver that is within a certain proximity of the start location. If the start time is within a certain time range of a typical on-duty start time of the driver (e.g., within thirty minutes), then theselection engine 135 can provide theclaim offer 186 to the driver at any time prior to the start time (or a predetermined time prior to the start time, as described herein). - The
database 160 can store driver profiles 166 that can indicate the home locations of the drivers (e.g., the driver's address), preferred operating areas (e.g., either inputted by the driver or inferred by thenetwork system 100 over time), the driver's service rating and/or safety rating, the driver's history of claiming and delivering on claimed rides (e.g., a failed claim rate), the driver's cancelation rate, and the like. Based on such profile information, theselection engine 135 can determine one or more drivers that would be optimally suited to claim the scheduledtransport 142. In some aspects, theselection engine 135 can further include an incentive or bonus payment with theclaim offer 186 to further incentivize the driver to claim the scheduledtransport 142. In one example, theselection engine 135 can provide aninitial claim offer 186, and gradually provide increased incentives until the scheduledtransport 142 is claimed. - According to various examples, the
selection engine 135 can provide theclaim offer 186 immediately after receiving a scheduled transport request 198 (e.g., upon performing a selection optimization to identify one or more optimal candidate drivers to service the scheduled ride), or can perform a subsequent analysis to determine whether another driver may be more optimally suited to service the scheduledtransport 142. For example, theselection engine 140 can attribute weightings to certain factors, such as the driver's home location, typical operation times or on-duty times, common operational areas, the driver's safety and/or service rating, the driver's cancelation rate, and/or the driver's claimant failure rate (e.g., a rate at which the driver claims a scheduledtransport 142 but fails to deliver. - Based on such weightings and the characteristics of the scheduled transport 142 (e.g., start location, destination, start time, service type, etc.), the
selection engine 135 can converge on one or more most optimal drivers to which theclaim offer 186 is to be provided. The driver(s) can either accept or decline theclaim offer 186 accordingly. Upon accepting theclaim offer 186, thenetwork system 100 can conditionally bind or associated the claimant or accepting driver to the scheduledtransport 142. When the start time approaches, thenetwork system 100 can monitor theprovider device 188 of the driver (e.g., via the provider app 187) to determine whether the driver is on-duty and/or available to service the scheduledtransport 142. In order to ensure that the scheduledtransport 142 is serviced, thenetwork system 100 can decouple or disassociate the claimant transport provider from the scheduledride 142 if the driver is not online or on-duty (or otherwise unavailable) within a predetermined, specified time prior to the scheduled transport 142 (e.g., fifteen minutes prior). In certain examples, the specified time can vary based on a sparsity factor of the scheduledtransport 142. - For example, if the start location is in a sparse network of servicing drivers (e.g., a rural town), the
network system 100 can increase the specified decouple time to ensure enough time for an on-demand transport provider to arrive by the scheduled start time. Conversely, if the start location is within a dense driver network (e.g., in a downtown city location), then thenetwork system 100 can decrease the specified decouple time accordingly. In various examples, the decouple time can be provided to the claimant transport provider via push notifications to the provider device 188 (e.g., agnostic of whether theprovider app 187 is executing or not). Accordingly, the decouple time can be dynamically determined based on the sparsity of the driver network surrounding the start location prior to the start time. - If the claimant transport provider is available and online, then the
transport coordination system 100 can transmit a confirmation request to theprovider device 188 of the claimant transport provider to confirm that the claimant transport provider will service the scheduledtransport request 198. Thenetwork system 100 can then monitor the progress of the claimant transport provider to ensure that the scheduledtransport request 198 is fulfilled. However, at the predetermined decouple time, if the claimant transport provider is not available, then thenetwork system 100 can decouple or otherwise disassociate the claimant transport provider from the scheduledtransport request 198 and perform a standard on-demand matching and selection process (e.g., a default selection process based on location and/or estimated time of arrival of a candidate set of drivers from the start location). Accordingly, initially providing theclaim offer 186 for the scheduledtransport request 198 and including a set of fall back options (e.g., failing over to the default selection process, and/or a different transport service option) can comprise a hierarchical selection process implemented by thenetwork system 100, as described herein. - As the scheduled time for the scheduled
transport 142 approaches, thescheduling engine 140 can generate and transmit a sequence ofreminders 146 to the user device 190. For example, thescheduling engine 140 can generate afirst reminder 146 exactly one day prior to the scheduled transport time, a second reminder two hours prior, and a final reminder thirty minutes prior to the transport time. In some examples, thereminders 146 can be generated as push notifications that can wake up the user device 190 if it is in a low power mode, or overlay displayed content. In one aspect, the user can utilize thereminder 146 to either confirm the scheduledtransport 142 or cancel the scheduledtransport 142, in which case thescheduling engine 140 can flush the scheduledtransport 142 entry from the ride scheduling logs 132. - Furthermore, the
scheduling engine 140 can generatetriggers 144 for theselection engine 135 to initiate a search of proximate available transport providers (e.g., of the transport service type indicated in the scheduled transport request 198) in relation to the scheduled start location. For example, thirty minutes prior to the scheduled start time, theselection engine 135 can be triggered to filter theavailable transport providers 185 based on the requested service type, utilize theprovider locations 181 of matching service type vehicles to identify a number of candidate transport providers proximate to the start location, and utilizemap data 179 and/ortraffic data 177 from themapping engine 175 to estimate a time of arrival for each of the candidate transport providers. In one aspect, theselection engine 135 can continue to monitor the ETA information for all available transport providers entering a geo-fenced area—generated by theselection engine 135 to surround the start location—up until the ETA information for a current candidate set of available transport providers substantially correlates to the time delta to the scheduled start time. In variations, theselection engine 135 can identify that sufficient supply exists (e.g., more than five available vehicles within a ten minute ETA of the start location), and can place the search on standby for thenext time trigger 144 from thescheduling engine 140.Such triggers 144 may be initiated by thescheduling engine 140 in accordance with a trigger schedule, such as every five minutes. - In response to a given
trigger 144, theselection engine 135 can set a geo-fence around the start location in the scheduledtransport request 198 and identify available transport providers based onprovider locations 181 within the geo-fence. As provided herein, the geo-fence may be based on a set area surrounding the start location, and/or estimated arrival times of available transport providers usingmap data 179 and/ortraffic data 177 in proximity to the start location. Additionally, theselection engine 135 can filter the available transport providers based on the requested transport service type (e.g., a peer-to-peer ride, a professional transport service, etc.). According to examples described herein, once the ETA information of the available transport providers (e.g., two or three transport providers within a ten minute ETA) substantially coincides with the countdown time to the scheduled start time (e.g., start time minus eight minutes), theselection engine 135 can generate atransport invitation 182, and transmit thetransport invitation 182 to aprovider device 188 of one or more of the proximate available transport providers. If one of the transport providers transmits anacceptance 183, theselection engine 135 can generate and transmit aconfirmation 199 comprising information corresponding to the selectedtransport provider 193 to the user device 190 of the requesting user. - In certain implementations, the
pricing engine 165 can initiate a logical fare meter for each servicedtransport request 197 throughout the given region. The fare meter can be based on individualtransport service rates 164 for transport types, and can calculate the overall fare for a given ride or service transport based distance and/or time traveled from the start location to the destination. In many implementations, thepricing engine 165 initiates the fare meter once the transport provider arrives at the start location and the requesting user enters the provider's vehicle, and terminates the fare meter upon arrival at the destination. According to such implementations, the overall fare is unknown to the requesting user until drop-off, at which point thepricing engine 165 can submit a receipt or bill to the requesting user's device 190 via the designatedapplication 195. Thus, thepricing engine 165 can monitor theprovider location 181 of the transport provider - Over time, the
pricing engine 165 can collectprice data 117 for variousindividual transport requests 197 serviced throughout the given region, and catalog thehistorical price data 117 in pricing data logs 162 in adatabase 160 of thenetwork system 100. In accordance with examples described herein, the pricing data logs 162 can be chronicled based on any of the following: the transport route, time of day, day of the week, day of the month (e.g., whether thetransport request 197 was on a holiday), transport service type, whether surge conditions applied (i.e., limited supply in relation to transport demand), the surge pricing factor (e.g., 1.0 for normal conditions), traffic conditions, transport time, weather conditions, coinciding events (e.g., a concert or sporting event ending proximate to the transport route), and the like. Thus, thepricing engine 165 can utilize the pricing data logs 162 in thedatabase 160 in order to, for example, implement machine learning techniques and/or filter the pricing data logs 162 in order to accurately predict anupfront price 167 of requested transport services prior to the requesting user accepting the transport service. - In some examples, the
selection engine 135 can provideinformation 149 corresponding to the scheduledtransport 142 to thepricing engine 165 prior to the scheduled transport time. In certain aspects, theinformation 149 can further comprisetraffic data 177 or predicted traffic information for a route to be traveled by the selectedtransport provider 193 after making the scheduled pick-up. Additionally or alternatively, theinformation 149 can include third-party data 157 provided by third-party resources 155, such as event data, road construction information, predicted weather information for the scheduledtransport 142. In many examples, thisinformation 149 can be provided to thepricing engine 165 prior to the requesting user scheduling thetransport request 198 in order to generate anupfront price 167 based onsuch information 149 as well as the pricing data logs 162. - As an example, when the requesting user utilizes the scheduled transport feature on the designated
application 195, and inputs a start time, a start location, a destination, and, in some examples, a transport service type, thepricing engine 165 can filter the pricing data logs 162 based on the inputted information and perform a lookup foractual transport requests 197 serviced with the same or similar characteristics. Additionally, thepricing engine 165 may be provided withadditional information 149 such as predicted weather conditions, event calendar information, road construction information, and the like, in order to further filter the pricing data logs 162 to identify a number of matchingtransport requests 197—and hence their charged costs—in order to determine anupfront price 167 for the scheduledtransport 142. In early implementations, theupfront price 167 may be offered only when thepricing engine 165 calculates a certainty probability of theupfront price 167 above a certain threshold (e.g., 95%) in relation to a traditional fare meter price for the scheduledtransport 142 based on distance, time, and/or ride service type. However, in further implementations, as collectedhistorical pricing data 117 and the pricing data logs 162 become more robust, thepricing engine 165 can accurately predictupfront prices 167 for every on-demand transport request 197 and scheduledtransport 142. - According to examples described herein, the designated
application 195 can automatically submit a query via to thepricing engine 165 when a transport service type, a start location, a start time, and a destination are inputted. Thepricing engine 165 can return anupfront price 167 based on the above factors, which can comprise a guaranteed offer to the requesting user for the on-demand transport or scheduledtransport 142. For scheduledtransport 142 implementations, thepricing engine 165 can predicted theupfront price 167 based on future conditions (e.g., event conditions, traffic conditions, weather conditions, etc.), which can be extrapolated from both the pricing data logs 162 and the third-party resources 155. Thepricing engine 165 may then submit theupfront price 167 to the user device 190 prior to the user scheduling thetransport request 142. In these examples, when the requesting user submits the scheduledtransport request 198 to thescheduling engine 140, theschedule transport request 198 may already include an acceptance of theupfront price 167, which can bind thenetwork system 100 to theupfront price 167 for the scheduledtransport 142 despite future contingencies during the actual scheduled transport. - Additionally, the
information 149 for thepricing engine 165 can further comprise thedynamic provider location 181 of the selectedtransport provider 193 and the scheduled start time and location of the scheduledtransport 142. Examples described herein recognize that in order to facilitate efficiency and optimize timing and cost both the requesting user and the transport provider for the scheduledtransport 142, these entities may be held to at least minimal scheduling duties in order to disincentivize unnecessary delays that, on the one hand, could make the requesting user late for a flight or an important meeting, and on the other hand, could waste valuable time for the transport provider in servicingadditional transport requests 197 throughout the day. Thus, thepricing engine 165 can execute optimized pricing calculations that discourage cancelations as well as belatedness. - In one example, the
pricing engine 165 can implement a “pay to wait” calculation. In this example, thepricing engine 165 can monitor theprovider location 181 of the selectedtransport provider 189 as theprovider 193 is traveling to the start location. If the selectedtransport provider 193 arrives at the start location early, then no additional charges may be incurred. However, if thetransport provider 193 arrives on time, and the requesting user is late, thepricing engine 165 can initiate a logical fare meter once the scheduled start time has lapsed based on atransport service rate 164 corresponding to the requested transport service type. Inupfront price 167 implementations, the incurred charge for the wait time (i.e., between the schedule start time when the selectedtransport provider 193 has arrived and the time in which the requesting user enters the vehicle) can be tagged onto theupfront price 167 at the end of the ride. In such examples, a notification can be provided to the requesting user beforehand (e.g., when accepting theupfront price 167 and scheduling the transport 142). - Furthermore, in certain implementations the requesting user can cancel the scheduled
transport 142 at any time up until a predetermined time prior to the scheduled start time. This predetermined time may be a set time (e.g., thirty minutes), or may be triggered based on atransport provider 189 being selected to service the scheduledtransport 142. In the latter example, acceptance to service the scheduledtransport 142 can comprise an expectation on the transport provider's 193 part in which some compensation is warranted. Thus, the requesting user may be notified that once thetransport provider 193 has accepted or claimed atransport invitation 182 or claimoffer 186 corresponding to the scheduledtransport 142, charges may incur for cancelation. In one example, thepricing engine 165 can initiate a standard fare meter for the transport service type once the driver accepts thetransport invitation 182. If the requesting user cancels the scheduledtransport 142, thepricing engine 165 can incur a charge to the requesting user based on the standard rate betweentransport provider acceptance 183 and the cancelation time. In variations, thepricing engine 165 can calculate the cancelation fee at a separate cancelation rate, or can charge a flat fee. - The
pricing engine 165 can also charge the transport provider for canceling an accepted scheduledtransport 142. Given the nature of transport scheduling and the inherent importance of fulfilling expected scheduledtransports 142, driver cancelation after acceptance may be heavily discouraged. Furthermore, it is envisioned that thenetwork system 100 will compensate the requesting user in the unlikely event of failure to fulfill a scheduledtransport 142. Such compensation may be in the form of a fully credited future ride, which can create the potential for fraud by conspiring drivers and users. In order to prevent such fraud, thenetwork system 100 can provide a discounted future ride, notify and charge the driver for canceling the accepted ride, and/or revoke the driver's credentials for utilizing the platform to service transport requests in the future. - According to certain implementations, a
trigger 144 for an upcoming scheduledride 142 can cause theselection engine 135 to perform a search for available transport providers. In certain scenarios, theselection engine 135 may realize that available driver supply is lacking significantly in the area surrounding the scheduled start location. In other scenarios, thescheduling engine 140 can identify the start location as being in a remote area, and thus notify theselection engine 135 to “move supply” in order to ensure adequate transport provider supply for the scheduledtransport 142. In either scenario, theselection engine 135 can generate and transmit one or more incentive offers 184 tovehicles 185 within a certain area of the start location. The incentive offers 184 can include, for example, a bonus payment, an early fare meter initiation (e.g., in which thepricing engine 165 initiates the fare meter for thetransport provider 193 from a current location to the start location), a higher service rate, and the like. In certain examples, theselection engine 135 can issue theincentive offer 184 to multiple transport providers at the same time, and award theincentive offer 184 to a first accepting driver, which can bind or associate the accepting driver to the scheduledtransport 142. In variations, theselection engine 135 can transmit theincentive offer 184 to oneprovider device 188 at a time, which the transport provider can accept, decline, or ignore (e.g., automatically after fifteen seconds). - In certain examples, the
network system 100 can synch the scheduledtransport 142 with other applications on the user device 190, such as a calendar application. In variations, thenetwork system 100 can provide the transport scheduling feature on third-party applications or websites to enable the user to scheduletransport 142 in conjunction with scheduling a flight or a meeting. In scheduling transport through a calendar application on the user device 190 or via a third-party application or website, thenetwork system 100 can provide a “zero-click” function in which the scheduledtransport 142 is automatically arranged and shows up at the start location (e.g., inputted or preset as a default, such as the user's home screen) without any additional input by the requesting user. - As provided herein, the
network system 100 can implement a number of backup measures to ensure fulfillment of each scheduledtransport 142. Such backup measures can include features described herein such as moving supply and failing over to alternative ride service types. Furthermore, rapid data collection can enable thepricing engine 165 to accurately predictupfront prices 167 for not only on-demand rides based on current information (e.g., weather, traffic, supply, demand, etc.), but also for future scheduledtransport requests 198 to provide users with added certainty in utilizing the transport arrangement services managed by thenetwork system 100. -
FIG. 2 is a block diagram illustrating a user device executing a designated application for a transport arrangement service, as described herein. The mobile computing device 200 can store a designated application (e.g., a designated transport app 232) in alocal memory 230. In response to a user input 218, the designatedapp 232 can be executed by aprocessor 240, which can cause anapp interface 242 to be generated on adisplay screen 220 of themobile computing device 230. Theapp interface 242 can enable the user to, for example, check current price levels and availability for the transportation arrangement service. In various implementations, theapp interface 242 can further enable the user to select from multiple ride services, such as a carpooling service, a regular rider service, a professional ride service, a van transport service, a luxurious ride service, and the like. - The user can generate a user request 267 via user inputs 218 provided on the
app interface 242. For example, the user can select a start location, view the various service types and estimated pricing, and select a particular service for transportation to an inputted destination. As provided herein, the user requests 267 can comprise an on-demand transport request 276 for immediate or near-immediate pick-up, or can comprise a scheduledtransport request 277 described herein. In certain implementations,current location data 262 from aGPS module 260 of the mobile computing device 200 can be transmitted to the network system 290 (e.g., thenetwork system 100 ofFIG. 1 ) to set the start location. In many examples, the user can also input the destination prior to start. Theprocessor 240 can transmit the start request 267 via acommunications interface 210 to thebackend network system 290 over anetwork 280. In response, the mobile computing device 200 can receive a confirmation 269 from thenetwork system 290 indicating the selected SDV that will service the start request 267 and rendezvous with the user at the start location. - In certain implementations, the mobile computing device 200 can further include a
microphone 270 to enable the user to provide voice inputs 272 to further interact with the designatedapplication 232. For example, instead of providing user inputs 218 on thedisplay screen 220, certain commands can be provided via voice input 272 (e.g., user requests 267, confirmations, cancelations, postponements, etc.). Additionally, the mobile computing device 200 can include one ormore output devices 275 that can provideoutputs 271 and/or feedback based on user interactions and responses through the designatedapplication 232.Such outputs 271 can include haptic and/or audio feedback (e.g., voice feedback) generated by the designatedapplication 232, such as ride update information, tonal responses, alerts, and the like. - According to examples, the mobile computing device 200 can receive
ETA data 292 from thenetwork system 290. Current ETA information for mapping, routing, and traffic resources may utilize GPS information (e.g.,location data 262 from the GPS resources of users' mobile devices). Examples described herein can significantly improve theETA data 292 utilizing real-time location data from transport providers, which can further be utilized by thenetwork system 290 in mid-level routing of the transport providers, as described herein. This can further bolster ETA predictability and provide users of the service with highly accurate ETA information relating to arrival times for pick-up and overall trip time to a destination. - In one example, the
ETA data 292 can include estimated arrival times for a plurality of transport providers that are proximate to the user's current location. For example, theapp interface 242 can include a mapping feature with real-time virtual representations of transport providers traveling on the mapping feature. TheETA data 292 can include an estimated arrival time for each of the transport providers on the map (e.g., on a miniature window next to the SDV's displayed virtual representation). Additionally or alternatively, theETA data 292 can include an estimated arrival time of a transport provider selected to service an on-demand request 276 submitted by the user. In further examples, theETA data 292 can include an estimated arrival time to a destination once the user has been start by the selected transport provider. - In accordance with many aspects, upon submitting a scheduled
transport request 277, the user device 200 can be provided withconfirmations 293 that thetransport request 277 has been scheduled and that the transport provider is traveling to once a driver has accepted or an SDV has been instructed to rendezvous with the requesting user. Furthermore, after a scheduledtransport request 277 has been submitted, the user device 200 can periodically receivereminders 291 of the upcoming ride. -
FIG. 3 is a block diagram illustrating a driver device executing a designated driver application for a transport arrangement service, as described herein. Thedriver device 330 can store a designateddriver application 332 inmemory 300, which the driver can execute via user inputs 318 to notify the network system 390 (e.g., thetransport coordination system 100 ofFIG. 1 ) that the driver is available to service start requests and scheduled ride requests. In many examples, the user device 200 ofFIG. 2 and thedriver device 300 ofFIG. 3 can comprise mobile computing device (e.g., smart phone devices) that can execute any number of applications stored thereon. Upon initiating thedriver application 332, thedriver device 300 can initiate aGPS module 360 to transmitlocation data 362 to thenetwork system 390 over anetwork 380. Based on thelocation data 362, thenetwork system 390 can transmittransport invitations 392 to thedriver device 300 over thenetwork 380 for transport requests at proximate locations in relation to the driver's current location. - The
transport invitations 392 may be invitations for on-demand rides, or invitations to service a scheduled transport request. Thetransport invitations 392 can be received by acommunications interface 310 of thedriver device 300 and processed by aprocessor 340. In executing thedriver application 332, theprocessor 340 can generate adriver application interface 342 on a display screen of thedriver device 300 to enable the driver to accept or decline thetransport invitation 392, or to cancel a currently acceptedinvitation 392. In some implementations, since the driver may be driving, thedriver device 300 can include amicrophone 370 to enable the driver to inputvoice inputs 372 in order to accept or declinetransport invitations 392. Thedriver device 300 may further include one ormore output devices 375, which can provide haptic or audio responses, feedback, ornotification outputs 371 to the driver in conjunction with notification(s) 344 being displayed on thedisplay screen 320. In accepting an on-demand or scheduled transport request, the driver can input aconfirmation 322 to service the transport request and rendezvous with the requesting user at a start location specified in thetransport invitation 392. - User Interface Examples
-
FIGS. 4A through 4E are example screenshots illustrating the scheduled rides feature on a user device executing a designated application, according to examples described herein.FIG. 4A shows an example home screen for the rider application. The home screen can enable the user to set a pick-up location using a pick-uplocation pin 402 in order to request an on-demand ride, or to schedule a future ride by selecting the scheduled ride feature 410. In various examples, the home screen can include a mapping feature and a selection portion that enables the user to scroll through multiple differentride service types 404 using a rideservice selection feature 406. According to some examples, the locations of available vehicles can be represented by small virtual objects (as shown), and can be filtered based on the ride service selection. Thus, as the user scrolls the rideservice selection feature 406 across multipleride service types 404, the rider application can automatically update the displayed interface to include only those vehicles that match theride service type 404 on which the rideservice selection feature 406 is located. -
FIG. 4B shows an example screen shot of aconfirmation screen 412 in which the user has inputted a time, date, and destination for the scheduled ride based on the pick-up location of the previous screen shown inFIG. 4A . As shown inFIG. 4B , the user can be enabled to edit the scheduled ride, or schedule another ride. - In certain implementations, as shown in
FIG. 4C , selection of the scheduled ride feature 410 can cause a scheduledride input screen 414 to be generated that enables the user to input the various details of the scheduled ride, such as a pick-up data and time, a pick-up location, and a destination. As shown inFIG. 4D , selection of the various input features of the scheduledride input screen 414 can cause acorresponding input window 416 to be generated, which enables the user to quickly set an inputted value, such as a date and time. In certain implementations described herein, upon entering the information for the scheduled ride, thenetwork system 100 ofFIG. 1 can determine that sufficient pricing data has been compiled to provide an upfront price for the scheduled ride, which may be scheduled by the user well prior to the pick-up time (e.g., two weeks or a month prior). Thus, as shown inFIG. 4E , anoffer window 420 can be generated including a calculated upfront price (as shown) for the scheduled ride. The user can be enabled to cancel, decline, or accept the upfront price on theoffer window 420. Furthermore, upon accepting the upfront price, the scheduled ride request can be transmitted to thenetwork system 100 and the ride can be scheduled accordingly. - Methodology
-
FIG. 5 is a flow chart describing an example method of implementing a scheduled transport service, according to examples described herein. In the below description ofFIG. 5 , reference may be made to reference characters representing like features shown and described with respect toFIG. 1 . Furthermore, the various processes discussed below in connection withFIG. 5 may be performed by anexample network system 100 as described with respect toFIG. 1 . Referring toFIG. 5 , thenetwork system 100 can provide a transport scheduling feature on the designatedapplication 195, which can enable users to schedule transport in connection with an on-demand transportation arrangement service managed by the network system 100 (500). - In various implementations, the
network system 100 can detect inputs on via scheduling feature, which can include a start location, a destination, a date, and a start time (535). In some examples, thenetwork system 100 can further compile historical pricing data for a given region, as described herein (540). Based at least in part on the historical pricing data and the inputted scheduled ride information, thenetwork system 100 can calculate anupfront price 167 for the scheduled transport request 198 (545). In variations, theupfront price 167 can further be based on third-party data 157, such as event information, weather conditions, time of day and day of the week (e.g., rush hour on a weekday), and the like. - The
network system 100 can then calculate a certainty probability for theupfront price 167 based on the foregoing data (550). For example, the certainty probability can comprise a probability that the calculatedupfront price 167 will be within a predetermine range (e.g., 3-5%) of an actual price of fulfilling the scheduledtransport request 198 utilizing a logical fare meter and a fare rate base on the transport service type. Thus, thenetwork system 100 can determine whether the certainty probability is above a certain threshold (e.g., 95%) (555). If not, (559), then thenetwork system 100 can apply a standard fare rate for the scheduledtransport request 198 at the time thetransport request 198 is serviced (560). However, if so (557), then thenetwork system 100 can offer theupfront price 167 as a guaranteed price for the scheduled transport request 198 (565). - In many examples, the
network system 100 can receiveuser requests 196 for future, scheduled transport via the scheduling feature on the designated application 195 (505). The scheduledtransport request 198 can include a start location and destination (507), and a scheduled date and scheduled start time (509). Thenetwork system 100 can input eachuser request 196 as a scheduledride 142 in the scheduling logs 132 managed inmemory 130 of the system 100 (510). In certain aspects, thenetwork system 100 can transmit periodic reminders to the user devices 190 corresponding to the scheduledtransport requests 198, either by push notification or via the designated application 195 (e.g., if executing on the device 190) (515). - As each scheduled
transport request 198 approaches, thenetwork system 100 can periodically check ETA data of proximate transport providers in relation to the start location to gauge transport supply (520). The ETA data can comprise estimated arrival time information of proximate available drivers (521) and/or SDVs (523) of the specified transport service type indicated in the scheduledtransport request 198. Accordingly, thenetwork system 100 may determine whether the ETA data of the drivers and/or SDVs correlate with the time delta to the start time (525). If not (527) (e.g., if there is a surplus of transport supply within a time-based or location-based geo-fence around the start location), then thenetwork system 100 can place the scheduledtransport request 198 on standby and check again in the near future (e.g., every two minutes) (520). However, if so (529) (e.g., if the ETA time for one or more transport providers is within a certain range of the time delta to the start time), then thenetwork system 100 can generate and transmit one ormore transport invitations 182 to the one or more proximate drivers or SDVs (530), which can accept or decline thetransport invitations 182 accordingly. As provided herein, a first accepting transport provider (whether driver or SDV) can comprise an optimal transport providers to service the scheduledtransport request 198. - In some examples, in checking the transport supply for the scheduled
transport request 198, thenetwork system 100 can determine that driver and/or SDV supply is insufficient (570). For example, thesystem 100 can identify a certain risk factor that no transport providers will be available within a certain proximate of the start location. In such scenarios, thenetwork system 100 can fall back on a number of options or combination of options. In one example, thenetwork system 100 can generate and transmit anincentive offer 184 to one or more transport providers close to the start location (575), to which the transport providers may accept or decline (575). As provided herein, theincentive offer 184 can comprise a bonus payment or other incentive (e.g., initiating the fare meter early) to incentivize an available transport provider to at least travel towards the start location. Thus, thenetwork system 100 can receive an incentive offer acceptance from a particular driver (580), and thereafter transmit atransport invitation 182 to that transport provider to rendezvous with the requesting user to service the scheduled transport request 198 (530). - Additionally or alternatively, in situations of insufficient supply for the requested transport service type, the
network system 100 can fail over to alternative transport service types (585). In other words, if thenetwork system 100 determines that supply for the requested transport service type (e.g., a professional transport service) is lacking significantly, in order to ensure fulfilling the scheduled transport obligation, thenetwork system 100 can begin to transmit transport invitations ordirectives 182 to drivers and vehicles of alternative service types (e.g., peer-to-peer or ride pool service types) (530). Thus, once a transport directive orinvitation 182 is accepted, then thenetwork system 100 can monitor the rendezvous and trip to ensure success accordingly. In certain examples, if the driver arrives at the start location and the requesting user has not rendezvoused with the driver by the start time, thenetwork system 100 can initiate a fare meter for the scheduled ride regardless of whether the user has or has not rendezvoused with the accepting driver. If any issues arise, such as cancelations, then thenetwork system 100 can implement backup procedures and attribute charges, as described herein. -
FIG. 6 is a flow chart describing example methods of coordinating scheduled transport, according to examples described herein. In the below discussion ofFIG. 6 , reference may be made to references characters representing like features as described above with respect toFIGS. 1 through 4E . Furthermore, one or more steps described in connection withFIG. 6 may be performed in conjunction with or in addition to one or more steps discussed above with respect toFIG. 5 . Referring toFIG. 6 , thenetwork system 100 can provide a ride scheduling feature on the designatedapp 195 of a requesting user's computing device 190 (600). In some aspects, the ride scheduling feature can be provided based on a sparse network trigger (602). For example, if the user's home location or start location is outside a typical service area for on-demand transportation services, then the designatedapplication 195 can include ride scheduling feature specifically to enable drivers to claim rides. In other examples, the ride scheduling feature can be a global feature for the designatedapplication 195 that users can utilize (604). - The
network system 100 can receive user requests for future, scheduled transport via the scheduling feature (605). In various aspects, each scheduledtransport request 198 can comprise a start location and destination (607) as well as a date and a time for the scheduled transport request 198 (609). As described herein, thenetwork system 100 may then input the request as a scheduledtransport request 198 into a ride scheduling log 132 (610). Thenetwork system 100 may then identify a candidate set of transport providers to claim the scheduled transport request 198 (615). - According to various implementations, the
network system 100 determine the candidate drivers based on the driver's claimed rides history in the driver's profile data (625). For example, if the driver is otherwise an ideal candidate, but has a propensity towards forsaking claimed rides, thenetwork system 100 can exclude the driver from the candidate set. The network system can also determine the candidate set based on the driver's common operational area(s) (630). Thenetwork system 100 can also perform lookups in the driver's safety and/or service ratings (635). For example, certain schedules transport requests may be relatively lucrative for drivers, and thenetwork system 100 can incentivize good ratings and good service in general by providing those drivers with claim offers 186 for the most lucrative scheduled transport requests 198. In still further implementations, thenetwork system 100 can determine the candidate set based on the home locations of the drivers (640). For example, thenetwork system 100 can correlate the start location of the scheduledtransport request 198 to the home locations of drivers within a certain proximity of the start location. Thenetwork system 100 may then provide theclaim offer 186 for the scheduledtransport request 198 to a driver with a nearest or close to nearest home location to the start location. - In various examples, the
network system 100 can then transmit theclaim offer 186 to one or more most optimal drivers for the scheduled transport request (645). Thenetwork system 100 may then determine whether the scheduledtransport request 198 has been claimed by the driver (650). For example, thenetwork system 100 can give the driver a certain amount of time to accept theclaim offer 186. If the driver does not accept theclaim offer 186 within the allowable timeframe (652), then thenetwork system 100 can either determine an incentive to attached to theclaim offer 186 to further facilitate transport claiming (655), and/or identify a next best driver or a new candidate set of drivers, as described above (615). - If the driver accepts the claim offer 186 (654), then the network system can conditionally bind or associate the claimed driver or accepting driver to the scheduled ride (660). The conditions for the binding or associating can comprise factors such as the claimed driver must be online or on-duty and available at a specified decouple time prior to the start time for the scheduled
transport request 198. Additionally, the conditions can include that the driver must be within a certain distance from the start location at the specified decouple time. As provided herein, the decouple time may be determined dynamically based on a current driver network density surrounding the start location (e.g., a number of available driver within a two or three kilometer radius of the start location). - Upon approaching the scheduled transport time, the
network system 100 can determine whether the claimed driver is online and available (665). If so, thenetwork system 100 can transmit a confirmation request to the claimed driver to ensure that the scheduledtransport request 198 will be serviced, and aconfirmation 199 to the requesting user to coordinate the ride (670). However, if the claimed driver is not online and/or is unavailable at the specified decouple time, thenetwork system 100 can decouple or otherwise disassociate the driver from the scheduledtransport request 198 and execute a normal, default on-demand selection and matching process to service the scheduledtransport request 198 as a more typical on-demand ride, as described herein (675). - Hardware Diagram
-
FIG. 7 is a block diagram that illustrates a computer system upon which examples described herein may be implemented. Acomputer system 700 can be implemented on, for example, a server or combination of servers. For example, thecomputer system 700 may be implemented as part of a network service for providing transportation services. In the context ofFIG. 1 , thenetwork system 100 may be implemented using acomputer system 700 such as described byFIG. 7 . Thenetwork system 100 may also be implemented using a combination of multiple computer systems as described in connection withFIG. 7 . - In one implementation, the
computer system 700 includes processingresources 710, amain memory 720, a read-only memory (ROM) 730, astorage device 740, and acommunication interface 750. Thecomputer system 700 includes at least oneprocessor 710 for processing information stored in themain memory 720, such as provided by a random access memory (RAM) or other dynamic storage device, for storing information and instructions which are executable by theprocessor 710. Themain memory 720 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by theprocessor 710. Thecomputer system 700 may also include theROM 730 or other static storage device for storing static information and instructions for theprocessor 710. Astorage device 740, such as a magnetic disk or optical disk, is provided for storing information and instructions. - The
communication interface 750 enables thecomputer system 700 to communicate with one or more networks 780 (e.g., cellular network) through use of the network link (wireless or wired). Using the network link, thecomputer system 700 can communicate with one or more computing devices, one or more servers, driver devices, and/or SDVs. In accordance with examples, thecomputer system 700 receives user requests 782 (e.g., on-demand requests or scheduled transport requests) from mobile computing devices of individual users. The executable instructions stored in thememory 730 can include ridescheduling instructions 724, which theprocessor 710 can execute to schedule the ride, provide reminders, generate and transmit transport invitations ordirective 754 to drivers and/or SDVs, and implement one or more backup options when transport supply is insufficient (e.g., fail over to a different ride type or generate incentive offers) in order to ensure fulfillment of the scheduled ride. - The
main memory 720 can also store upfront pricing instructions 722, which theprocessor 710 executes to compile and chronicle or otherwise classify pricing data for serviced rides throughout the given region. In executing the upfront pricing instructions 722, the processor can further utilizethird party data 784, such as event data (e.g., sporting events, concerts), weather information (e.g., rainy weather can indicate an increase in transport demand), traffic information, and the like. The pricing instructions 722 can cause theprocessor 710 to utilize the foregoing data as well as route information for a scheduled ride, time of day, day of week, and other calendar information, to determine anupfront price 752 for the scheduled ride, as described herein. - The
main memory 720 can also storeride coordination instructions 726, which theprocessor 710 can execute to identify candidate drivers to claim a scheduled ride. In doing so, thecomputer system 700 can perform lookups indriver profiles 166 and optimize between driver history, common operational areas, home locations, and safety ratings of the drivers to converge on, or otherwise determine an optimal driver to which the scheduled ride can be offered and claimed. Execution of theride coordination instructions 726 can further cause thecomputer system 700 monitor the claimant transport provider upon approaching the scheduled ride time, provide notifications to the driver, and ultimately determine whether the driver will fulfill the claimed ride. If so, then thecomputer system 700 can provide the driver with atransport invitation 754 to facilitate the start. However, if the driver forsakes the claimed ride (e.g., is not on-duty at a predetermined time prior to the scheduled time), then thecomputer system 700 can execute a default or standard on-demand selection and matching process to fulfill the scheduled ride as an on-demand ride request. - The
processor 710 is configured with software and/or other logic to perform one or more processes, steps and other functions described with implementations, such as described byFIGS. 1 through 6 , and elsewhere in the present application. - It is contemplated for examples described herein to extend to individual elements and concepts described herein, independently of other concepts, ideas or systems, 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. As such, many modifications and variations will be apparent to practitioners skilled in this art. 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 claiming rights to such combinations.
Claims (20)
1. A computer system, comprising:
one or more processors; and
one or more memory resources storing instructions that are executed by the one or more processors to cause the computer system to:
a scheduled transport request from a computing device of a user, the scheduled transport request indicating (i) a pick-up location and (ii) a scheduled time for a scheduled transportation service;
determine a transport provider to fulfill the scheduled transport request;
transmit, to a computing device of the transport provider, a transport invitation to fulfill an on-demand transport request for one or more other users prior to the scheduled time;
receive data indicative of an acceptance of the transport invitation by the transport provider to fulfill the on-demand transport request;
determine an ability of the transport provider to fulfill the scheduled transport request at the scheduled time based on location data from received from the computing device of the transport provider and the pick-up location; and
based on the ability of transport provider to fulfill the scheduled transport request at the scheduled time, transmit data indicative of a confirmation associated with the scheduled transport request if the transport provider is able to fulfill the scheduled transport request, or determine a backup transport provider to fulfill the scheduled transport request at the scheduled time if the transport provider is unable to fulfill the scheduled transport request.
2. The computer system of claim 1 , wherein the executed instructions cause the computer system to transmit the data indicative of the confirmation to the computing device of the transport provider.
3. The computer system of claim 1 , wherein the executed instructions cause the computer system to transmit the data indicative of the confirmation to the computing device of the user.
4. The computer system of claim 1 , wherein the executed instructions cause the computer system to select the transport provider from a plurality of transport providers based, at least in part, on a preselected location for each of the plurality of transport providers.
5. The computer system of claim 1 , wherein the executed instructions cause the computer system to determine that the transport provider is unable to fulfill the scheduled transport request at the scheduled time based on the transport provider being unavailable at a predetermined decouple time prior to the scheduled time.
6. The computer system of claim 1 , wherein the executed instructions further cause the computer system to:
transmit one or more reminder notifications to the computing device of the transport provider prior to the scheduled time.
7. The computer system of claim 1 , wherein the executed instructions cause the computer system to determine the backup transport provider to fulfill the scheduled transport request by identifying, at a predetermined time prior to the scheduled time, a plurality of available transport providers within an estimated arrival time to the pick-up location, and selecting the backup transport provider to service the scheduled transport request based at least in part on an estimated time of arrival of the backup transport provider to the pick-up location.
8. A non-transitory computer readable medium storing instructions that, when executed by one or more processors of a computer system, cause the computer system to:
receive a scheduled transport request from a computing device of a user, the scheduled transport request indicating (i) a pick-up location and (ii) a scheduled time for a scheduled transportation service;
determine a transport provider to fulfill the scheduled transport request;
transmit, to a computing device of the transport provider, a transport invitation to fulfill an on-demand transport request for one or more other users prior to the scheduled time;
receive data indicative of an acceptance of the transport invitation by the transport provider to fulfill the on-demand transport request;
determine an ability of the transport provider to fulfill the scheduled transport request at the scheduled time based on location data from received from the computing device of the transport provider and the pick-up location; and
based on the ability of transport provider to fulfill the scheduled transport request at the scheduled time, transmit data indicative of a confirmation associated with the scheduled transport request if the transport provider is able to fulfill the scheduled transport request, or determine a backup transport provider to fulfill the scheduled transport request at the scheduled time if the transport provider is unable to fulfill the scheduled transport request.
9. The non-transitory computer readable medium of claim 8 , wherein the executed instructions cause the computer system to transmit the data indicative of the confirmation to the computing device of the transport provider.
10. The non-transitory computer readable medium of claim 8 , wherein the executed instructions cause the computer system to transmit the data indicative of the confirmation to the computing device of the user.
11. The non-transitory computer readable medium of claim 8 , wherein the executed instructions cause the computer system to select the transport provider from a plurality of transport providers based, at least in part, on a preselected location for each of the plurality of transport providers.
12. The non-transitory computer readable medium of claim 8 , wherein the executed instructions cause the computer system to determine that the transport provider is unable to fulfill the scheduled transport request at the scheduled time based on the transport provider being unavailable at a predetermined decouple time prior to the scheduled time.
13. The non-transitory computer readable medium of claim 8 , wherein the executed instructions further cause the computer system to:
transmit one or more reminder notifications to the computing device of the transport provider prior to the scheduled time.
14. The non-transitory computer readable medium of claim 8 , wherein the executed instructions cause the computer system to determine the backup transport provider to fulfill the scheduled transport request by identifying, at a predetermined time prior to the scheduled time, a plurality of available transport providers within an estimated arrival time to the pick-up location, and selecting the backup transport provider to service the scheduled transport request based at least in part on an estimated time of arrival of the backup transport provider to the pick-up location.
15. A computer-implemented method for managing a transport service, the method being performed by one or more processors and comprising:
receiving a scheduled transport request from a computing device of a user, the scheduled transport request indicating (i) a pick-up location and (ii) a scheduled time for a scheduled transportation service;
determining a transport provider to fulfill the scheduled transport request;
transmitting, to a computing device of the transport provider, a transport invitation to fulfill an on-demand transport request for one or more other users prior to the scheduled time;
receiving data indicative of an acceptance of the transport invitation by the transport provider to fulfill the on-demand transport request;
determining an ability of the transport provider to fulfill the scheduled transport request at the scheduled time based on location data from received from the computing device of the transport provider and the pick-up location; and
based on the ability of transport provider to fulfill the scheduled transport request at the scheduled time, transmitting data indicative of a confirmation associated with the scheduled transport request if the transport provider is able to fulfill the scheduled transport request, or determine a backup transport provider to fulfill the scheduled transport request at the scheduled time if the transport provider is unable to fulfill the scheduled transport request.
16. The method of claim 15 , wherein the one or more processors transmit the data indicative of the confirmation to the computing device of the transport provider.
17. The method of claim 15 , wherein the one or more processors transmit the data indicative of the confirmation to the computing device of the user.
18. The method of claim 15 , wherein the one or more processors select the transport provider from a plurality of transport providers based, at least in part, on a preselected location for each of the plurality of transport providers.
19. The method of claim 15 , wherein the one or more processors determine that the transport provider is unable to fulfill the scheduled transport request at the scheduled time based on the transport provider being unavailable at a predetermined decouple time prior to the scheduled time.
20. The method of claim 15 , further comprising:
transmitting one or more reminder notifications to the computing device of the transport provider prior to the scheduled time.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US17/587,226 US20220215499A1 (en) | 2016-06-07 | 2022-01-28 | Hierarchical selection process |
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201662347043P | 2016-06-07 | 2016-06-07 | |
US15/615,754 US10395333B2 (en) | 2016-06-07 | 2017-06-06 | Hierarchical selection process |
US16/423,623 US11250531B2 (en) | 2016-06-07 | 2019-05-28 | Hierarchical selection process |
US17/587,226 US20220215499A1 (en) | 2016-06-07 | 2022-01-28 | Hierarchical selection process |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US16/423,623 Continuation US11250531B2 (en) | 2016-06-07 | 2019-05-28 | Hierarchical selection process |
Publications (1)
Publication Number | Publication Date |
---|---|
US20220215499A1 true US20220215499A1 (en) | 2022-07-07 |
Family
ID=60483430
Family Applications (3)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/615,754 Active 2037-08-10 US10395333B2 (en) | 2016-06-07 | 2017-06-06 | Hierarchical selection process |
US16/423,623 Active 2037-10-26 US11250531B2 (en) | 2016-06-07 | 2019-05-28 | Hierarchical selection process |
US17/587,226 Pending US20220215499A1 (en) | 2016-06-07 | 2022-01-28 | Hierarchical selection process |
Family Applications Before (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US15/615,754 Active 2037-08-10 US10395333B2 (en) | 2016-06-07 | 2017-06-06 | Hierarchical selection process |
US16/423,623 Active 2037-10-26 US11250531B2 (en) | 2016-06-07 | 2019-05-28 | Hierarchical selection process |
Country Status (5)
Country | Link |
---|---|
US (3) | US10395333B2 (en) |
AU (1) | AU2017277637A1 (en) |
BR (1) | BR112018075358A8 (en) |
CA (1) | CA3026772A1 (en) |
WO (1) | WO2017214324A1 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20210269010A1 (en) * | 2019-05-17 | 2021-09-02 | Honda Motor Co., Ltd. | System and method for actuating a vehicle operation power mode |
US11599964B2 (en) | 2017-02-14 | 2023-03-07 | Uber Technologies, Inc. | Network system to filter requests by destination and deadline |
US11747154B2 (en) | 2016-09-26 | 2023-09-05 | Uber Technologies, Inc. | Network system for preselecting a service provider based on predictive information |
Families Citing this family (47)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10467554B2 (en) | 2013-03-14 | 2019-11-05 | Lyft, Inc. | System for connecting a driver and a rider |
US9888087B2 (en) | 2014-03-31 | 2018-02-06 | Uber Technologies, Inc. | Adjusting attributes for an on-demand service system based on real-time information |
WO2016029168A1 (en) | 2014-08-21 | 2016-02-25 | Uber Technologies, Inc. | Arranging a transport service for a user based on the estimated time of arrival of the user |
GB2535718A (en) | 2015-02-24 | 2016-08-31 | Addison Lee Ltd | Resource management |
GB201503083D0 (en) | 2015-02-24 | 2015-04-08 | Addison Lee Ltd | Allocating vehicles to private hire bookings |
US9939279B2 (en) | 2015-11-16 | 2018-04-10 | Uber Technologies, Inc. | Method and system for shared transport |
US20180005144A1 (en) * | 2016-06-29 | 2018-01-04 | RideSage Inc. | Delaying rides pre-arranged with ridesharing services |
US11087252B2 (en) | 2016-08-16 | 2021-08-10 | Teleport Mobility, Inc. | Interactive real time system and real time method of use thereof in conveyance industry segments |
US11176500B2 (en) | 2016-08-16 | 2021-11-16 | Teleport Mobility, Inc. | Interactive real time system and real time method of use thereof in conveyance industry segments |
US11182709B2 (en) | 2016-08-16 | 2021-11-23 | Teleport Mobility, Inc. | Interactive real time system and real time method of use thereof in conveyance industry segments |
US10607192B2 (en) * | 2016-08-25 | 2020-03-31 | Ford Global Technologies, Llc | Methods and apparatus for autonomous vehicle scheduling |
US10192448B2 (en) * | 2016-09-30 | 2019-01-29 | Nec Corporation | Method to control vehicle fleets to deliver on-demand transportation services |
US11132626B2 (en) * | 2016-11-30 | 2021-09-28 | Addison Lee Limited | Systems and methods for vehicle resource management |
SG11201805482PA (en) * | 2016-12-21 | 2018-07-30 | Meru Cab Company Private Ltd | System, method, and computer-readable medium for providing optimal dynamic content of a service to a user |
USD848463S1 (en) * | 2016-12-30 | 2019-05-14 | Lyft, Inc. | Display screen or portion thereof with graphical user interface |
USD862506S1 (en) | 2016-12-30 | 2019-10-08 | Lyft, Inc. | Display screen or portion thereof with graphical user interface |
USD848462S1 (en) * | 2016-12-30 | 2019-05-14 | Lyft, Inc. | Display screen or portion thereof with graphical user interface |
US9769616B1 (en) | 2017-04-04 | 2017-09-19 | Lyft, Inc. | Geohash-related location predictions |
US10142222B1 (en) * | 2017-06-13 | 2018-11-27 | Uber Technologies, Inc. | Customized communications for network systems |
AU2018284492A1 (en) * | 2017-06-14 | 2020-02-27 | Beijing Didi Infinity Technology And Development Co., Ltd. | Systems and methods for transport capacity scheduling |
US10872134B2 (en) * | 2017-08-07 | 2020-12-22 | Ridemites Group, Inc. | Method and system for identifying pre-identified or pre-selected groups of individuals for transportation |
US10721327B2 (en) | 2017-08-11 | 2020-07-21 | Uber Technologies, Inc. | Dynamic scheduling system for planned service requests |
WO2019103695A1 (en) * | 2017-11-24 | 2019-05-31 | Ctrlworks Pte. Ltd. | Dual mode personal mobility device (pmd), a method for managing a fleet of such pmds |
US10559211B2 (en) * | 2017-11-27 | 2020-02-11 | Uber Technologies, Inc. | Real-time service provider progress monitoring |
US10349223B1 (en) * | 2017-12-14 | 2019-07-09 | Lyft, Inc. | Initiating transportation requests |
US11474519B2 (en) * | 2018-02-26 | 2022-10-18 | Nvidia Corporation | Systems and methods for computer-assisted shuttles, buses, robo-taxis, ride-sharing and on-demand vehicles with situational awareness |
CA3036182C (en) * | 2018-03-12 | 2023-01-24 | Letstow Transport Inc. | System and method for managing a request for roadside assistance |
US11501643B2 (en) * | 2018-05-02 | 2022-11-15 | Uber Technologies, Inc. | Reducing autonomous vehicle downtime and idle data usage |
US11244685B2 (en) * | 2018-09-04 | 2022-02-08 | Uber Technologies, Inc. | Network computer system to generate voice response communications |
USD948543S1 (en) | 2018-10-26 | 2022-04-12 | Hvr Mso Llc | Display screen or portion thereof with a graphical user interface |
US10940870B1 (en) | 2018-11-28 | 2021-03-09 | BlueOwl, LLC | Systems and methods for visualizing predicted driving risk |
US11175151B1 (en) | 2018-11-28 | 2021-11-16 | BlueOwl, LLC | Systems and methods of efficient carpooling based on driver risk groups |
US20200294172A1 (en) * | 2019-03-14 | 2020-09-17 | Walmart Apollo, Llc | Adaptive resource allocation |
JP7262075B2 (en) * | 2019-03-20 | 2023-04-21 | パナソニックIpマネジメント株式会社 | Information processing method and information processing system |
US11915225B2 (en) * | 2019-05-03 | 2024-02-27 | Visa International Service Association | Mobile merchant payment system |
US10832294B1 (en) | 2019-06-26 | 2020-11-10 | Lyft, Inc. | Dynamically adjusting transportation provider pool size |
US11829904B2 (en) * | 2019-09-27 | 2023-11-28 | Uber Technologies, Inc. | On-demand transport selection process based on pick-up/drop-off zone utilization |
CN111028053B (en) * | 2019-12-03 | 2020-12-01 | 北京嘀嘀无限科技发展有限公司 | Order processing method and device, electronic equipment and storage medium |
US11669786B2 (en) | 2020-02-14 | 2023-06-06 | Uber Technologies, Inc. | On-demand transport services |
US20210374650A1 (en) * | 2020-06-01 | 2021-12-02 | HopSkipDrive, Inc. | Ride assignment system |
US11691643B2 (en) | 2020-08-27 | 2023-07-04 | Here Global B.V. | Method and apparatus to improve interaction models and user experience for autonomous driving in transition regions |
US11713979B2 (en) | 2020-08-27 | 2023-08-01 | Here Global B.V. | Method, apparatus, and computer program product for generating a transition variability index related to autonomous driving |
US20220063639A1 (en) * | 2020-08-27 | 2022-03-03 | Here Global B.V. | Method, apparatus, and computer program product for predicting autonomous transition regions using historical information |
US11687094B2 (en) | 2020-08-27 | 2023-06-27 | Here Global B.V. | Method, apparatus, and computer program product for organizing autonomous vehicles in an autonomous transition region |
US20220067813A1 (en) * | 2020-08-27 | 2022-03-03 | Here Global B.V. | Automated autonomous vehicle recommendations based on personalized transition tolerance |
SG10202009755UA (en) * | 2020-10-01 | 2021-07-29 | Grabtaxi Holdings Pte Ltd | Communications server apparatus and method for allocating resources to service requests related to a shared economy on-demand service or asset provision |
JP7380508B2 (en) * | 2020-10-08 | 2023-11-15 | トヨタ自動車株式会社 | Information processing device, information processing method, and terminal device |
Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080195428A1 (en) * | 2007-02-12 | 2008-08-14 | O'sullivan Sean | Shared transport system and service network |
US20120041675A1 (en) * | 2010-08-10 | 2012-02-16 | Steven Juliver | Method and System for Coordinating Transportation Service |
US20140038640A1 (en) * | 2011-04-19 | 2014-02-06 | Kees Wesselius | System and method for associating devices moving along the same travel path |
US20140172727A1 (en) * | 2005-12-23 | 2014-06-19 | Raj V. Abhyanker | Short-term automobile rentals in a geo-spatial environment |
US20150254581A1 (en) * | 2014-03-04 | 2015-09-10 | iCarpool, Inc. | Rideshare system and method to facilitate instant carpooling |
US20150339923A1 (en) * | 2013-01-01 | 2015-11-26 | Tomtom Development Germany Gmbh | Vehicle management system |
US20160335568A1 (en) * | 2015-05-15 | 2016-11-17 | Cox Automotive, Inc. | Parallel Processing for Solution Space Partitions |
US20190392368A1 (en) * | 2018-06-23 | 2019-12-26 | Mitsubishi Electric Research Laboratories, Inc. | System and Method for Scheduling Multiple Modes of Transport |
US20200272954A1 (en) * | 2019-02-25 | 2020-08-27 | Mitsubishi Electric Research Laboratories, Inc. | System and Method for Scheduling Multiple Modes of Transport with Incomplete Information |
US11605246B2 (en) * | 2015-02-05 | 2023-03-14 | Uber Technologies, Inc. | Programmatically determining location information in connection with a transport service |
US11754407B2 (en) * | 2015-11-16 | 2023-09-12 | Uber Technologies, Inc. | Method and system for shared transport |
Family Cites Families (28)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4023753A (en) * | 1974-11-22 | 1977-05-17 | International Standard Electric Corporation | Vehicle control system |
CA2282294C (en) * | 1996-10-21 | 2009-12-08 | Orissa, Inc. | Transportation network system |
US6697730B2 (en) * | 2000-04-04 | 2004-02-24 | Georgia Tech Research Corp. | Communications and computing based urban transit system |
AU2002339943A1 (en) | 2001-10-01 | 2003-04-14 | The Boeing Company | System for management of itineraries |
EP1450321A1 (en) | 2003-02-21 | 2004-08-25 | Swisscom Mobile AG | Method and system for detecting possible fraud in paying transactions |
JP2004334527A (en) | 2003-05-07 | 2004-11-25 | Intelligent Wave Inc | Calculation program and method for illegal determination score value, and calculation system for illegal determination score value of credit card |
US20060155591A1 (en) | 2005-01-10 | 2006-07-13 | Faheem Altaf | Systems, methods, and media for managing a travel itinerary |
US20060293937A1 (en) * | 2005-06-24 | 2006-12-28 | Mark Sohm | System and method of wireless carpool scheduling |
US20090030885A1 (en) * | 2007-07-26 | 2009-01-29 | Ridecharge | Method and system for on-demand and scheduled services relating to travel and transportation |
US8977567B2 (en) | 2008-09-22 | 2015-03-10 | Visa International Service Association | Recordation of electronic payment transaction information |
US20100153279A1 (en) * | 2008-09-30 | 2010-06-17 | Walter Zahn | Systems and methods for global transportation,vetting, and payment |
US9280605B2 (en) | 2010-03-11 | 2016-03-08 | Flightstats, Inc. | Systems and methods for itinerary messaging service |
US20110251951A1 (en) | 2010-04-13 | 2011-10-13 | Dan Kolkowitz | Anti-fraud event correlation |
US20120072249A1 (en) | 2010-09-22 | 2012-03-22 | Mobiata LLC | System and method for sending travel information to a wireless mobile device |
US8738529B2 (en) | 2011-07-15 | 2014-05-27 | Wal-Mart Stores, Inc. | Multi-channel data driven, real-time fraud determination system for electronic payment cards |
US20140149157A1 (en) | 2012-11-27 | 2014-05-29 | GoEuro Corp. | Travel planning |
US20160148167A1 (en) * | 2013-06-28 | 2016-05-26 | Nokia Technologies Oy | Method and apparatus for facilitating meeting |
US20150032485A1 (en) * | 2013-07-25 | 2015-01-29 | Mark Nelson | Digital method For Providing Transportation Services |
EP3080774A4 (en) * | 2013-12-11 | 2017-06-07 | Uber Technologies Inc. | Optimizing selection of drivers for transport requests |
US20150176997A1 (en) * | 2013-12-22 | 2015-06-25 | Andreas Kurt PURSCHE | Adaptive transportation framework |
US20150206267A1 (en) * | 2014-01-22 | 2015-07-23 | Jahan Khanna | Systems and methods for providing a transportation marketplace |
US10197410B2 (en) * | 2014-11-18 | 2019-02-05 | International Business Machines Corporation | Dynamic real-time carpool matching |
US9904900B2 (en) * | 2015-06-11 | 2018-02-27 | Bao Tran | Systems and methods for on-demand transportation |
US20170169366A1 (en) * | 2015-12-14 | 2017-06-15 | Google Inc. | Systems and Methods for Adjusting Ride-Sharing Schedules and Routes |
US10459440B2 (en) * | 2016-01-04 | 2019-10-29 | GM Global Technology Operations LLC | System and method for remotely assisting autonomous vehicle operation |
US10282681B2 (en) * | 2016-02-03 | 2019-05-07 | Operr Technologies, Inc. | System and method for customizable prescheduled dispatching for transportation services |
US11537953B2 (en) * | 2018-11-29 | 2022-12-27 | Here Global B.V. | Method and apparatus for proactive booking of a shared vehicle |
US11829904B2 (en) * | 2019-09-27 | 2023-11-28 | Uber Technologies, Inc. | On-demand transport selection process based on pick-up/drop-off zone utilization |
-
2017
- 2017-06-06 US US15/615,754 patent/US10395333B2/en active Active
- 2017-06-07 BR BR112018075358A patent/BR112018075358A8/en unknown
- 2017-06-07 AU AU2017277637A patent/AU2017277637A1/en not_active Abandoned
- 2017-06-07 WO PCT/US2017/036430 patent/WO2017214324A1/en active Application Filing
- 2017-06-07 CA CA3026772A patent/CA3026772A1/en active Pending
-
2019
- 2019-05-28 US US16/423,623 patent/US11250531B2/en active Active
-
2022
- 2022-01-28 US US17/587,226 patent/US20220215499A1/en active Pending
Patent Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20140172727A1 (en) * | 2005-12-23 | 2014-06-19 | Raj V. Abhyanker | Short-term automobile rentals in a geo-spatial environment |
US20080195428A1 (en) * | 2007-02-12 | 2008-08-14 | O'sullivan Sean | Shared transport system and service network |
US20120041675A1 (en) * | 2010-08-10 | 2012-02-16 | Steven Juliver | Method and System for Coordinating Transportation Service |
US20140038640A1 (en) * | 2011-04-19 | 2014-02-06 | Kees Wesselius | System and method for associating devices moving along the same travel path |
US20150339923A1 (en) * | 2013-01-01 | 2015-11-26 | Tomtom Development Germany Gmbh | Vehicle management system |
US20150254581A1 (en) * | 2014-03-04 | 2015-09-10 | iCarpool, Inc. | Rideshare system and method to facilitate instant carpooling |
US11605246B2 (en) * | 2015-02-05 | 2023-03-14 | Uber Technologies, Inc. | Programmatically determining location information in connection with a transport service |
US20160335568A1 (en) * | 2015-05-15 | 2016-11-17 | Cox Automotive, Inc. | Parallel Processing for Solution Space Partitions |
US11754407B2 (en) * | 2015-11-16 | 2023-09-12 | Uber Technologies, Inc. | Method and system for shared transport |
US20190392368A1 (en) * | 2018-06-23 | 2019-12-26 | Mitsubishi Electric Research Laboratories, Inc. | System and Method for Scheduling Multiple Modes of Transport |
US20200272954A1 (en) * | 2019-02-25 | 2020-08-27 | Mitsubishi Electric Research Laboratories, Inc. | System and Method for Scheduling Multiple Modes of Transport with Incomplete Information |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US11747154B2 (en) | 2016-09-26 | 2023-09-05 | Uber Technologies, Inc. | Network system for preselecting a service provider based on predictive information |
US11599964B2 (en) | 2017-02-14 | 2023-03-07 | Uber Technologies, Inc. | Network system to filter requests by destination and deadline |
US20210269010A1 (en) * | 2019-05-17 | 2021-09-02 | Honda Motor Co., Ltd. | System and method for actuating a vehicle operation power mode |
US11787388B2 (en) * | 2019-05-17 | 2023-10-17 | Honda Motor Co., Ltd. | System and method for actuating a vehicle operation power mode |
Also Published As
Publication number | Publication date |
---|---|
US20170352125A1 (en) | 2017-12-07 |
BR112018075358A2 (en) | 2019-03-19 |
US20190347754A1 (en) | 2019-11-14 |
WO2017214324A1 (en) | 2017-12-14 |
US10395333B2 (en) | 2019-08-27 |
US11250531B2 (en) | 2022-02-15 |
AU2017277637A1 (en) | 2019-01-03 |
CA3026772A1 (en) | 2017-12-14 |
BR112018075358A8 (en) | 2023-04-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20220215499A1 (en) | Hierarchical selection process | |
US11747154B2 (en) | Network system for preselecting a service provider based on predictive information | |
US11842302B2 (en) | Method, device, cloud service, system, and computer program for smart parking a connected vehicle | |
US20230044760A1 (en) | Systems and methods for recommending transportation services | |
US11599964B2 (en) | Network system to filter requests by destination and deadline | |
US10417727B2 (en) | Network system to determine accelerators for selection of a service | |
US20230120345A1 (en) | Forecasting requests based on context data for a network-based service | |
US20170169366A1 (en) | Systems and Methods for Adjusting Ride-Sharing Schedules and Routes | |
US20190392357A1 (en) | Request optimization for a network-based service | |
US20150254581A1 (en) | Rideshare system and method to facilitate instant carpooling | |
US20150206267A1 (en) | Systems and methods for providing a transportation marketplace | |
US20150032485A1 (en) | Digital method For Providing Transportation Services | |
US20180314998A1 (en) | Resource Allocation in a Network System | |
JP6956810B2 (en) | How to manage the shuttle service | |
GB2535718A (en) | Resource management | |
CN110612523B (en) | Associating identifiers based on paired data sets | |
WO2009058117A1 (en) | Method and system for providing transportation service | |
US11508026B2 (en) | System for navigating transportation service providers to fulfill transportation requests authorized by an organization | |
US20220292414A1 (en) | Dynamic invitation transmission and presentation mode determination for a network-based service | |
CN114881692A (en) | Network appointment scheduling method and device, electronic equipment and storage medium | |
US20230039994A1 (en) | Multi-staged event processing based on client device data | |
US20200293953A1 (en) | Ride request evaluation systems and methods | |
Brinn-Rodriguez et al. | GEARS: Group Employee Automatic Rideshare System | |
CN112106089A (en) | Digital wallet |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: RESPONSE TO NON-FINAL OFFICE ACTION ENTERED AND FORWARDED TO EXAMINER |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: FINAL REJECTION MAILED |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: DOCKETED NEW CASE - READY FOR EXAMINATION |
|
STPP | Information on status: patent application and granting procedure in general |
Free format text: NON FINAL ACTION MAILED |