WO2019203806A1

WO2019203806A1 - Ridesharing utilizing excess capacity

Info

Publication number: WO2019203806A1
Application number: PCT/US2018/027932
Authority: WO
Inventors: Alexander Balva
Original assignee: Ford Global Technologies, Llc
Priority date: 2018-04-17
Filing date: 2018-04-17
Publication date: 2019-10-24

Abstract

A third-party provider, such as a transportation management service, can offer ridesharing-type transportation in response to requests. An employer, governmental agency, or other party might sponsor vehicles or routes for a first entity. Embodiments provide approaches for determining and selecting from various routes to serve transportation requests for the first entity, as well as a second entity and other entities interesting in obtaining rides or delivery of inanimate objects through excess capacity, including "standby" service. Incentives may be offered to the provider or the first entity in exchange for use of the excess capacity. The provider can utilize an objective function to balance metrics when selecting proposed routing solutions to serve a set of ride requests. Optimization network processes can be applied to improve each routing solution and capacity utilization. Approaches can also perform proactive placement of vehicles in order to more closely match vehicle capacity with anticipated demand.

Description

RIDESHARING UTILIZING EXCESS CAPACITY

BACKGROUND

[0001] People are increasingly turning to transportation offerings such as ridesharing to accomplish everyday tasks. Ridesharing can involve riders being allocated vehicles that are dedicated to those riders for a period of time, or being allocated seats on vehicles that will have other passengers riding at the same time. While individually-allocated cars can have some benefits, sharing vehicles reduces cost and provides some certainty as to scheduling. In order to ensure profitability of such a service, it is often desirable to attempt to minimize cost, as well as to increase utilization of the vehicles. An entity such as an employer or governmental agency, or another third-party, might sponsor a particular ridesharing vehicle or set of ridesharing routes, but such vehicle or routes may often not be filled or otherwise utilized to capacity. It is in the interest of the riders as well as the third-party ride provider to maximize use of vehicular capacity.

BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Various embodiments in accordance with the present disclosure will be described with reference to the drawings, in which: [0003] FIG. 1 A illustrates an example ride request environment in which various embodiments can be implemented;

[0004] FIG. 1B illustrates an example ride request environment in which excess third-party ridesharing capacity has been utilized in accordance with various embodiments various embodiments can be implemented; [0005] FIGS. 2A and 2B illustrate example origination and destination locations, and routes for serving those locations, for a service area over a period of time, in accordance with various embodiments; [0006] FIG. 3 A is a block diagram illustrating an example process for utilizing excess third- party ridesharing capacity, in accordance with various embodiments;

[0007] FIG. 3B is a block diagram illustrating an example process employed in connection with utilization of excess third-party ridesharing capacity, in accordance with various embodiments;

[0008] FIG. 4 illustrates an example system for utilizing excess third-party ridesharing capacity, in accordance with various embodiments;

[0009] FIG. 5 illustrates an example computing device that can be utilized to submit trip requests and receive route options, in accordance with various embodiments; and [0010] FIG. 6 illustrates example components of a computing device that can be utilized to implement aspects of the various embodiments.

DETAILED DESCRIPTION

[0011] In the following description, various embodiments will be described. For purposes of explanation, specific configurations and details are set forth in order to provide a thorough understanding of the embodiments. However, it will also be apparent to one skilled in the art that the embodiments may be practiced without the specific details. Furthermore, well-known features may be omitted or simplified in order not to obscure the embodiment being described.

[0012] Approaches described and suggested herein relate to the providing of ridesharing-type transportation in response to various requests. An employer, governmental agency, or other third-party might sponsor a particular vehicle or set of routes for a first entity. In particular, various embodiments provide approaches for determining and selecting from various third-party routes to serve a set of transportation requests for a first entity, a second entity, and even third and other entities interested in obtaining rides through excess capacity. To be clear, while the term“entity” is used herein for convenience, it is intended to be quite broad and can refer to an individual as well as a business, collective, group, or any other non-human organization.

Likewise, unused package capacity can be sold hereunder.

[0013] The shared-ride requests can relate to the transportation not only of people, but also animals, packages, or other objects, from an origination location to a destination location. The requests may also include at least one time component. A provider, such as a transportation service, can utilize an objective function to balance various metrics when selecting between proposed routing solutions to serve a set of customer trip requests. An objective function can provide a compromise between, for example, rider experience and provider economics, taking into account metrics such as rider convenience, operational efficiency, and the ability to deliver on confirmed trips. The analysis can consider not only planned trips, or trips currently being planned, but also trips currently in progress. One or more optimization processes can be applied, which can vary the component values or weightings of the objective function in order to attempt to improve each routing solution. In addition to optimizing the routing and first and second entity use of the routing, approaches in accordance with various embodiments can also perform proactive placement of vehicles in order to more closely match the vehicle capacity with the anticipated demand. The probability of various ride requests can be determined, and used to generate proactive ride requests. These requests can be submitted along with actual ride requests to attempt to proactively position vehicles closer to where the actual demand will occur. Actual requests can take priority over proactive requests, such that actual demand is served

appropriately. The proactive placement can also attempt to look forward over time, such that vehicles are assigned to routes based not only on where the vehicles are currently, or will be near the start of a tip, but also where the vehicles will end up after one or more trips, in order to attempt to reduce the overall cost and time needed to serve future rides.

[0014] Various other such functions can be used as well within the scope of the various embodiments as would be apparent to one of ordinary skill in the art in light of the teachings and suggestions contained herein.

[0015] FIG. 1A illustrates an example environment 100 in which aspects of the various embodiments can be implemented. In this example, a first entity or second entity user can request transportation from an origination to a destination location using, for example, an application executing on a client computing device 110. Various other approaches for submitting requests, such as by messaging or telephonic mechanisms, can be used as well within the scope of the various embodiments. Further, at least some of the requests can be received from, or on behalf of, an object being transported or scheduled to be transported. For example, a client device might be used to submit an initial request for an object, package, or other deliverable, and then subsequent requests might be received from the object, for example, or a device or mechanism associated with the device. Other communications can be used in place of requests, as may relate to instructions, calls, commands, and other data transmissions. For various embodiments discussed herein, a“client device” should not narrowly be construed as a conventional computing device unless otherwise stated, and any device or component capable of receiving, transmitting, or processing data and communications can function as a client device in accordance with various embodiments.

[0016] The transportation can be provided using a vehicle 102 (or other object) capable of concurrently transporting one or more riders, affiliated with a first entity, a second entity, and potentially additional entities. Again, while riders as used herein will often refer to human passengers, it should be understood that a“rider” in various embodiments can also refer to a non human rider or passenger, as may include an animal or an inanimate object, such as a package for delivery. Thus, any reference to“capacity,”“seats,”“seat instances,”“occupancy,” or the like herein can mean not only capacity for human passengers, but animal capacity and inanimate object storage capacity. In this example, a rideshare service offers routes using at least one type of vehicle that includes space for a driver 104 and seats or other capacity for up to a maximum number of riders. It should be understood that various types of vehicles can be used with different numbers or configurations of capacity, and that autonomous vehicles without dedicated drivers can be utilized as well within the scope of the various embodiments herein. Vehicles such as smart bicycles or personal transport vehicles may be used as well, which may include seating capacity for only a single rider or limited number of passengers. For a given vehicle 102 on a given route, a number of seat instances 106 (or other rider locations) may be occupied by first entity riders, while another number of seat instances 108 may be unused or unoccupied by riders associated with a first entity, to be filled by riders associated with a second entity in accordance with systems and methods herein. In some embodiments objects such as packages or deliveries may also occupy available space for a ride as well. In order to improve the economics of the rides offered, it can be desirable in at least some embodiments to have the occupancy as close to full as possible during the entire length of the trip. Such a situation results in very few unsold seats, which improves operational efficiency. One way to achieve high occupancy might be to offer only fixed routes where all passengers board at a fixed origination location and off- board at a fixed destination location, with no passengers onboarding or off-boarding at intermediate locations. [0017] In the present example, a given first entity or second entity rider or user can enter an origination location 112 and a destination location 114, either manually or from a set of suggested locations 116, among other such options, such as by selecting from a map 118 or other interface element. In other embodiments, a source such as a machine learning algorithm or artificial intelligence system, including those employing a neural network trained on a data set, can optimize ride recommendations, route determinations, and capacity calculations, and can select the appropriate locations based on relevant information, such as historical user activity, current location, collected metadata, and the like. Such collected data and metadata will allow the systems and methods herein to“learn” meanings from systems’ and particular riders’ transportation patterns, histories, trends, tendencies, etc. As is known in the machine learning and artificial intelligence arts, a variety of techniques could be applied, including, but by no means limited to, feedforward, recurrent, radial basis function, modular, and self-organizing neural networks, among others. Prior to production environment use, a non-production data set may be employed for training a neural network model for deep learning, in some embodiments, and generating the recommendations and notifications. The systems and methods can use a beam search or other algorithm to efficiently rank suggestions, and optimizations in some embodiments are made to a predictive system so that the optimized recommendations can be made in real time. Although graphics processing units (GPUs) are effective for many deep learning applications, the present systems and methods can be used with GPU-based or central processing unit (CPU)-based systems. Such systems can be trained using historical ride data, and can learn and improve over time using more recent ride and rider data, among other such options.

[0018] A backend system, or other service, can take a ride request, route data, and other optimized information and attempt to match the request with a specific vehicle having capacity at the appropriate time. As known for such purposes, it can be desirable to select a vehicle that will be near the first entity origination location at that time in order to minimize overhead such as fuel and driver costs. As mentioned, the capacity can include a seat for a human rider or sufficient available volume for a package or object to be transported, among other such measures of capacity.

[0019] Such an approach may not be optimal for all situations, however, as it may be difficult to get enough users or object providers to agree to be at a specific origination location at a specific time, or within a particular time window, which can lead to relatively low occupancy or capacity utilization, and thus low operational efficiency. Further, that approach may result in fewer rides being provided, which may reduce overall revenue. Requiring multiple users to travel to a specific, fixed origination location may also cause users to utilize other means of transportation, as may involve taxis or dedicated rideshare vehicles which do not require the additional effort. Accordingly, it can be desirable in at least some embodiments to factor rider convenience into the determination and selection of routes to be provided. What may be convenient for one rider, however, may not be convenient for other riders. For example, picking up one rider in front of his or her house might add an additional stop, and additional route distance, to an existing route that might not be acceptable to the riders already on, or assigned to, that route. In addition, different riders may prefer to leave at different times from different locations, as well as to get to their destinations within a maximum allowable amount of time, such that the interests of the various riders are at least somewhat competing, against each other and those of the ride provider. It therefore can be desirable in at least some embodiments to balance the relative experience of the various first entity, as well as potential second entity, and other riders, with the economics of the rideshare service for specific rides, routes, or other transportation options. While such an approach will likely prevent a ride provider from maximizing profit per ride, there can be some middle ground that enables the service to be profitable while providing (at a minimum) satisfactory service to the various riders or users of the service. Such an approach can improve the rider experience and result in higher ridership levels, which can increase revenue and profit if managed appropriately.

[0020] Depicted in FIG. 1B is the illustrative ridesharing environment 100 of FIG. 1 A in which aspects of the various embodiments have been implemented to provide riders, associated with a second entity, seat instances 109 which were previously unused or unoccupied by riders associated with a first entity. As may be seen, applying the systems and methods herein results in greater vehicle 102 occupancy (i.e., fewer seat instances 108 unoccupied by the first entity), and thereby can increase revenue to the ridesharing service provider.

[0021] FIGS. 2 A and 2B illustrate one example approach that can be utilized to provide a ridesharing service in accordance with various embodiments. In the example mapping 200 of FIG. 2A, a set of origination points 202 and destination points 204 indicate locations, over a determined period of time, between which one or more users would like to travel. As illustrated, there are clusters of locations where users may want to be delivered, or objects are to be delivered, as may correspond to town centers, urban locations, or other regions where a number of different businesses or other destinations are located. The origin locations, however, may be less clustered, such as may relate to suburbs or rural areas where rider homes may be located.

The clustering can also vary throughout the day, such as where people travel from their homes to their places of employment in the mornings, and generally travel in the reverse directions in the evening. There may be little clustering between these periods, or the clustering may be primarily to locations within an urban area. Economically, it may not be practical for a multi-rider, shared vehicle service to provide each person a dedicated vehicle for the determined route, as the overall occupancy per vehicle would be very low, even if allowing for second entity riders to participate in the service. Ensuring full occupancy for each vehicle, however, can negatively impact the experience of the individual riders who may then have to have longer routes and travel times in order to accommodate the additional riders, which may cause them to select other means of transportation. Similarly, requiring a large number of passengers to meet at the same origination location may be inconvenient for at least some of those passengers, who may then choose alternate travel options.

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

transportation options that balance, or at least take into consideration, these and other such factors. As an example, the mapping 250 of FIG. 2B illustrates a selection of routes 252 that can be provided over a period of time in order to satisfy various first entity, second entity, and other rider requests. The routes may not include or correspond to each precise origination and destination location, but can come within an acceptable distance of those locations in most instances. There may be situations where origination or destination locations are not served, or served at particular times, where route options may not be available, although in some embodiments a dedicated, limited capacity vehicle may be offered at a determined price, among other such options. While the routes may not enable every vehicle to have full first entity rider occupancy, the number of passengers per vehicle can be sufficient to provide at least adequate profitability or efficiency to the ridesharing service, particularly when allowing second entity riders participate in the service under the systems and methods herein. The routes 252 defined and provided by such a service may change over time, or even at different times of day, but can be sufficiently set such that riders can have at least some level of certainty over their commute or travel. While this may not offer the flexibility of other travel options, it can provide certainty of travel at a potentially lower cost point, particularly to second entity riders, which can be desirable to many potential users of the service. As mentioned, however, such a service can also provide added flexibility with other ride options, which may come with a higher price to the potential rider.

[0023] In order to determine the routes to provide, as well as the vehicles (or types of vehicles) to use to provide those routes, various factors can be considered. A function of these factors can then be optimized in order to provide for an improved customer experience, or transport experience for transported objects, while also providing for improved profitability, or at least operational efficiency, with respect to other available routing options. The optimization approaches and route offerings can be updated over time based on other available data, as may relate to more recent ride data, ridership requests, traffic patterns, construction updates, and the like. In some embodiments an artificial intelligence-based approach, as may include machine learning or a trained neural network, for example, can be used to further optimize the function based upon various trends and relationships determined from the data as discussed elsewhere herein.

[0024] An example route determination system can consider trips that are already planned or being planned, as well as trips that are currently in progress. The system can also rely on routes and trips that occurred in the past, for purposes of determining the impact of various options.

For trips that are in progress, information such as the remaining duration and distance can be utilized. Using information for planned routes enables the routing system to focus on a part of the service window that can still be impacted, typically going forward in time. For prorated and planned but not yet driven routes, the optimal distance may be difficult to assess directly since the route is not actually being driven. To approximate the optimal distance not yet driven, the routing system can prorate the total optimal distance in some embodiments to represent a portion of the planned distance not yet driven.

[0025] In accordance with various embodiments, FIG. 3 A illustrates a process 300 by which second entity (and potentially third or later entity) riders can utilize excess capacity of a third- party ridesharing service, when the first entity riders do not fill a given ride to capacity. It should be understood that, for this and all other processes discussed herein, there can be additional, fewer, or alternative steps, performed in similar or alternative steps, or in parallel, within the scope of the various embodiments unless otherwise stated. [0026] In an illustrative embodiment of this process 300, as an initial matter, the ridesharing service receives various trip requests from, or on behalf of, various potential first entity customers of a transportation service. The requests in this example relate to a future period of time, for at least one specified service area or region, in which the transport is to occur for one or more persons, animals, packages, or other objects or passengers. The requests can be submitted through an application executed on a computing device in many embodiments, although other request mechanisms can be used as well. In order to determine how to best serve the requests, this example process determines available vehicle capacity for serving the requests. This can include, for example, determining which vehicles or transport mechanisms are available to that service area over the specified future period of time, as well as the available seating or other capacity of those vehicles for that period of time. As mentioned, in some embodiments at least some of the seats of the various vehicles may already be committed or allocated to specific routes, riders, packages, or other such options

[0027] At step 302, data is obtained, detailing and otherwise relating to a ride on one of the predefined transportation service routes, with the ride having a plurality of seat instances for a first entity. In illustrative embodiments, seat instances are allocated 304 by the ridesharing service, based on the obtained data, and the seat instances are made available for reservation by another party, such as the first entity. The ridesharing service, or another party, can determine 306, after accounting for all first entity riders, that at least one seat instance will be unused or not occupied by a first entity rider, with pricing for the unused seat instance determined 308. A request to reserve at least one seat instance on that ride is received 310 from a second computing device of a second entity. The second entity may provide a set of reservation criteria or constraints in connection with its ride request, including factors such as a bid price for the ride reservation for the second entity, a total maximum price which the second entity is willing to pay for the ride reservation, and a timeframe desired for the ride. If there is at least one unused seat instance on the ride which meets the criteria specified by the second entity, a ride reservation for the second entity is generated 312, reserving the unused seat instance for the second entity. The process 300 is iterative and may be repeated in any number of ways, in the interest of maximizing the occupancy of a shared-ride vehicle.

[0028] As may be seen in the illustrative process 301 depicted in FIG. 3B, should a first entity provide a request 314 to use the at least one unused seat instance, the ride reservation for the second entity can be revoked or suspended in some embodiments. An updated ride reservation state may then be saved. If at least one second unused seat instance becomes available, the acceptance of requests to reserve a seat instance on the ride may be resumed 316. An option, particularly for popular routes, is to provide 318 the second entity with at least one“standby”- type opportunity for the ride when riders associated with the first entity fail to timely appear for the ride. In this vein, there can potentially also be standby options whereby a second entity can join an earlier ride if not all reserved first entity riders are present for that ride. It is entirely possible that some embodiments may be configured such that a second entity ride reservation is not revocable, although the applicable price to the second entity can be adjusted to reflect such reservation status. As with the process shown in FIG. 3A, the process 301 in FIG. 3B is iterative and may be repeated in the interest of maximizing vehicle occupancy.

[0029] In some embodiments, determinations of unused or available capacity can be made for different portions or legs of a ride as well. For example, there might be twelve seats reserved for a first entity on a vehicle, and eleven of those will be occupied at some point during the ride. There may be times, however, where seats or other capacity will be unused, such as before riders get on the vehicle or after riders exit the vehicle, such that there may be fewer than eleven riders on the vehicle during a significant portion of the ride. In at least some embodiments, this excess capacity (predicted or actual) can be provided for use by at least a second entity as well. For example, instead of only making available a seat that will be unoccupied for the entire ride or trip, a seat that is unused between two stops can be provided to a second or third entity for any duration that lasts no longer than a segment between those two stops. In some embodiments the capacity may be sold at a lower rate, since the rider will only be able to obtain the seating (or other) capacity up to the point where another rider will board the vehicle who has reserved that seat for a subsequent segment. As mentioned, the capacity can be offered based on projected capacity in addition to actual capacity in some embodiments, although such an approach may require the second entity to be in a“standby” or similar status, wherein that seat will only be available for the reduced price if an actual rider of the first entity does not occupy that seat during that segment of the ride. Once on the vehicle, the passenger may then be guaranteed in at least some embodiments to be able to complete the requested or agreed-upon journey.

[0030] As mentioned, the ability to sell this capacity in at least some embodiments may require permission from the entity reserving the capacity. As mentioned, the pricing of the reservation may vary based at least in part upon an ability to utilize excess capacity for other purposes. In some embodiments, an entity may be able to specify whether to allow for any reselling of unused but reserved capacity, or whether to not allow any such reselling or repurposing. In some embodiments, the reserving entity may be able to specify conditions or limits on the repurposing, such as to only allow repurposing for capacity determined to go unused for an entire ride or route, to be able to repurpose as long as a minimum amount of the capacity remains available for other riders associated with the first entity, or whether to allow for any capacity for any portion of a ride or journey where capacity is not utilized, among other such options.

[0031] Further, as noted herein, machine learning can be used to learn user and entity behavior, as well as to better predict and price excess capacity. As an example, a neural network can be trained on a data set and applied to optimize any number of steps and elements, such as defining routes, allocating seat instances, generating ride suggestions for the first entity, generating ride suggestions for the second entity, and predicting, or at least promptly determining, unused seat instances. Various other machine learning and artificial intelligence-based approaches to optimization can be utilized as well within the scope of the various embodiments as discussed and suggested elsewhere herein.

[0032] With regard to the defining of ride routes, based at least in part upon the various available vehicles and capacity, a set of potential routing solutions can be determined, which include not only providing for the actual demand, but also providing for the anticipated demand and proactively positioning vehicles based at least in part upon that anticipated demand. This can include, for example, using one or more route determination algorithms that are configured to analyze the various origination and destination locations, as well as the number of passengers and corresponding time windows for each, and generate a set of routing solutions for serving the various requests. The potential solutions can allocate vehicles to first entity, second entity, and other customers based on, for example, common or proximate origination and destination locations, or locations that can be served by a single route of a specific vehicle. In some embodiments a routing algorithm can potentially analyze all possible combinations for serving the requests with the available vehicles and capacity, and can provide any or all options that meet specific criteria, such as at least a minimum utilization or profitability, or at most a maximum allowable deviation (on average or otherwise) from the parameters of the various customer requests. This can include, for example, values such as a distance between the requested origination location and a suggested pick up point, deviations from a requested time, and the like. In some embodiments all potential solutions can be provided for subsequent analysis.

[0033] At least a subset of the proposed routing solutions can be analyzed using an objective function, or other such mechanism, to determine a quality score or other such value or measure. The objective function can include values for the various customer and operational efficiency metrics that are based at least in part upon the predicted demand and proactive positioning capability. A routing solution can then be selected based at least in part upon the respective route quality score as discussed elsewhere herein. The relevant routing data can then be transmitted to the impacted vehicles in order to cause those vehicles to move to the determined locations at the determined time, which in some cases may correspond to proactive placement.

In some embodiments or situations the transmission may occur to a computing device associated with the vehicle or a driver of the vehicle, among other such options. Information about the planned or predicted routes can also be transmitted to devices of potential first entity, second entity, and other customers in some embodiments, in order to enable those customers to request specific routes, times, stops, or other such options

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

[0035] After the optimization, at least some of the various proposed solutions may have updated quality scores. Some of the proposed solutions may also have been removed from consideration based on, for example, unacceptable quality scores or an inability to adequately serve a sufficient number of the pending requests, among other such factors. A specific routing solution can then be selected from the remaining solutions, where the solution can be selected based at least in part upon the optimized quality scores. For example, if optimizing for factors such as profitability or customer satisfaction rating, it can be desirable to select the option with the highest score. If optimizing for factors such as cost, it might be desirable to select the option with the lowest score. Other options can be utilized as well, such as to select the score closest to a target number ( e.g ., zero). As mentioned, other factors may be considered as well. For example, a solution might be selected that has close to the best quality score, but has a much better profitability or customer satisfaction value, or satisfies one or more other such goals or criteria. Once the solution is determined, the appropriate capacity can be allocated based upon vehicles and seating, among other potential options, determined to be available for the determined region at, or near, the future period of time. This can include, for example, predetermining routes and stops, and assigning vehicles with appropriate capacity to specific routes. The assignment of specific types of vehicles for certain routes may also be specified in the routing options, as there may be certain types of vehicles that get better gas mileage in town and some that get better gas mileage on the highway, for example, such that operational costs can be broken down by types of vehicles as well. In some embodiments specific vehicles might also be due to service for a specific mileage target, which can be factored in as well as other factors, such as cost per mile, type of gasoline, fuel, or power utilized, and the like. Information about the selected routing option can then be provided to particular first entity and participating second entity customers, such as those associated with the received requests. The information can indicate to the users various aspects such as the time and location of pickup, the route being taken, the location and approximate time of arrival at the destination, and potentially information about the specific vehicle and driver, among other such options.

[0036] An illustrative process for determining proactive placement of vehicles can be utilized in various embodiments. The predicted demand for a service area could be determined based at least in part upon historical data. The relevant data may relate to a corresponding time period, including time of day, day of the week, or event occurrence, among other such options. And the predicted demand relates at least in part to ride or transport requests anticipated to be received from first entity customers. This can be based upon machine learning (i.e., trained neural networks) or prediction models, among other such options. For the various anticipated requests, information can be determined as may relate to a probability of that request being received, as well as a likely number of riders to be submitted for the request. This information can be used to determine a seat instance demand for each of a set of quantized region of the service area, where that seating demand can be fractional based at least in part upon the probability being applied to the seating requests as discussed herein. In addition, an anticipated number of routes needed to satisfy the anticipated seating demand can be determined, as the likely variations in destinations will often be unable to be served using a single vehicle while still satisfying the various criteria for route determination.

[0037] FIG. 4 illustrates an example system 400 that can be utilized to determine and manage vehicle routing in accordance with various embodiments. In this system, various first entity riders 401, second entity riders 403, and other users can use applications executing on various types of computing devices 402 to submit route and ride requests over at least one network 404 to be received by an interface layer 406 of a service provider environment 408. The first entity 401 and second entity 403 user computing devices can be any appropriate devices known or used for submitting electronic requests, as may include desktop computers, notebook computers, smartphones, tablet computers, and wearable computers, among other such options. The network(s) 404 can include any appropriate network for transmitting the request, as may include any selection or combination of public and private networks using wired or wireless connections, such as the Internet, a cellular data connection, a WiFi connection, a local area network connection (LAN), and the like. The service provider environment 408 can include any resources known or used for receiving and processing electronic requests, as may include various computer servers, data servers, and network infrastructure as discussed elsewhere herein. The interface layer 406 can include interfaces (such as application programming interfaces), routers, load balancers, and other components useful for receiving and routing requests or other communications received to the service provider environment. The interfaces, and content to be displayed through those interfaces, can be provided using one or more content servers capable of serving content (such as web pages or map tiles) stored in a content repository 412 or other such location.

[0038] Information for a ride request can be directed to a route manager 414, such as may include code executing on one or more computing resources, configured to manage aspects of routes to be provided using various vehicles of a vehicle pool or fleet associated with the transport service. The route manager can analyze information for the request, determine available predetermined routes from a route data store 416 that have capacity can match the criteria of the request, and can provide one or more options back to the corresponding device 402 for selection by the potential rider. The appropriate routes to suggest to either first entity 401 or second entity 403 users can be based upon various factors, such as proximity to the origination and destination locations of the request, availability within a determined time window, and the like. An application on a client device 402 may instead present the available options from which a user can select, and the request can involve obtaining a seat for a specific planned route at a particular planned time.

[0039] In some embodiments users can either suggest route information or provide information that corresponds to a route that would be desired by the user. This can include, for example, an origination location, a destination location, a desired pickup time, and a desired drop-off time. Other values can be provided as well, as may relate to a maximum duration or trip length, maximum number of stops, allowable deviations, and the like. In some embodiments at least some of these values may have maximum or minimum values, or allowable ranges, specified by one or more route criteria. There can also be various rules or policies in place that dictate how these values are allowed to change with various circumstances or situations, such as for specific types of users or locations. The route manager 414 can receive several such requests, and can attempt to determine the best selection of routes to satisfy the various requests. In this example, the route manager can work with a route generation module 418 that can take the inputs from the various requests and provide a set of route options that can satisfy those requests. This can include options with different numbers of vehicles, different vehicle selections or placements, and different options for getting the various customers to their approximate destinations at or near the desired times. It should be understood that in some embodiments customers may also request for specific locations and times where deviation is not permissible, and the route manager may need to either determine an acceptable routing option or deny that request if minimum criteria are not met. In some embodiments, an option can be provided for each request, and a pricing manager 422 can determine the cost for a specific request using pricing data and guidelines from a price repository 424, which the user can then accept or reject.

[0040] In this example, the route generation module 418 can generate a set of routing options based on the received requests for a specified area over a specified period of time. A route optimization module 420 can perform an optimization process using the provided routing options to determine an appropriate set of routes to provide in response to the various requests. Such an optimization can be performed for each received request, in a dynamic routing system, or for a batch of requests, where users submit requests and then receive routing options at a later time. This may be useful for situations where the vehicle service attempts to have at least a minimum occupancy of vehicles or wants to provide the user with certainty regarding the route, which may require a quorum of riders for each specific planned route in some embodiments. In various embodiments an objective function is applied to each potential route in order to generate a route “quality” score, or other such value. The values of the various options can then be analyzed to determine the routing options to select. In one embodiment, the route optimization module 420 applies the objective function to determine the route quality scores and then can select the set of options that provides the highest overall, or highest average, total quality score. Various other approaches can be used as well as would be understood to one of ordinary skill in the art, in light of the teachings and suggestions contained herein.

[0041] In at least some embodiments, the objective function can be implemented independent of a particular implementation of an optimization algorithm. Such an approach can enable the function to be used as a comparative metric of different approaches based on specific inputs. Further, such an approach enables various optimization algorithms to be utilized that can apply different optimization approaches to the various routing options to attempt to develop additional routing options and potential solutions, which can help to not only improve efficiency but can also potentially provide additional insight into the various options and their impact or

interrelations. In some embodiments, there can be different objective functions used for different entities as well. For example, a first objective function might be used to determine ride convenience, as well as the ability to deliver this level of quality or convenience in some embodiments, can be used for a first entity, while a separate objective function can be used to determine ride convenience, and other such factors or metrics, for at least a second entity. In some embodiments different objective functions can be used initially for different entities, while in other embodiments the same objective function might be used for different entities, but different versions of the objective function can emerge over time for the various entities, based upon data analysis or machine learning, among other such options.

[0042] In some embodiments, an optimization console can be utilized that displays the results of various optimization algorithms and enables a user to compare the various results and factors in an attempt to determine the solution to implement, which may not necessarily provide the best overall score. For example, there might be minimum values or maximum values of various factors that are acceptable, or a provider might set specific values or targets on various factors, and look at the impact on the overall value and select options based on the outcome. In some embodiments the user can view the results of the objective function as well, before any optimization is applied, in order to view the impact of various factor changes on the overall score. Such an approach also enables a user or provider to test new optimization algorithms before selecting or implementing them, in order to determine the predicted performance and flexibility with respect to existing algorithms.

[0043] Further, such an approach enables algorithms to evolve automatically over time, as may be done using random experimentation or based on various heuristics. As these algorithms evolve, the value of the objective function can serve as a measure of fitness or value of a new generation of algorithms. Algorithms can change over time as the service areas and ridership demands change, as well as to improve given the same or similar conditions. Such an approach may also be used to anticipate future changes and their impact on the service, as well as how the various factors will change. This can help to determine the need to add more vehicles, reposition parking locations, etc.

[0044] In some embodiments artificial intelligence-inclusive approaches, such as those that utilize machine learning, can be used with the optimization algorithms to further improve the performance over time. For example, the raising and lowering of various factors may result in a change in ridership levels, customer reviews, and the like, as well as actual costs and timing, for example, which can be fed back into a machine learning algorithm to learn the appropriate weightings, values, ranges, or factors to be used with an optimization function. The optimization function itself may be produced by a machine learning process that takes into account the various factors and historical information to generate an appropriate function and evolve that function over time based upon more recent result and feedback data, as the machine learning model is further trained and able to develop and recognize new relationships.

[0045] In addition to determining anticipated demand, a corresponding analysis can be performed for determining first entity rider 401 capacity, thereby ascertaining additional room (if any) for second entity riders 403. In this example, the target capacity for each region can be determined based at least in part upon the anticipated seating demand, where the target capacity can include a number of seats and/or vehicles, and in at least some embodiments can be desired to correspond as closely as possible to the seating and vehicle demand anticipated. In order to determine capacity to move to a specific region, the capacity already allocated to that region for a specific time period can be determined. This can include, for example, vehicles already allocated to provide a ride for that region, vehicles with destinations in that region, vehicles expected to be parked in that region, and so on. Based at least in part upon the difference between the target capacity and the allocated available capacity, additional capacity to be allocated for the various regions can be determined. Various routing solutions can be proposed, optimized, and/or evaluated with an objective function in order to select an appropriate routing option, which can involve the proactive placement of vehicles in various regions of the service area, in order to cause the available capacity to more closely match, or correspond to, the anticipated first entity demand. Information for the selected solution can then be sent to the impacted vehicles, or devices associated with the vehicles or drivers, in order to cause those vehicles to move to the indicated locations at the appropriate times. It can be desired to smooth and limit the movement over time, as well as to ensure that various operational efficiency standards are still met by the process.

[0046] Various pricing methods can be used in accordance with the various embodiments, and in at least some embodiments the pricing, including discounts thereto or other incentives, can be used as a metric for route optimization. The cost factors in some embodiments can be evaluated in combination with one or more capacity, seat instance desirability, seat instance revocability status, or revenue factors. For example, a first entity or a second entity, or both, may be offered an incentive in the hope of filling a given ride to capacity. Such incentive is not limited and could include discounted pricing, compensation or a refund, or points in a customer reward program. In the case of an employer or government sponsored vehicles or routes, the first or second entity may offer the sponsor compensation or other incentive to allow the first entity and potentially the second entity to use excess capacities in those vehicles or routes. For example, if an employer shuttle bus or other vehicle has an empty seat instance that could fill a route request, a second entity, or a provider offering ridesharing services to second entities, might offer a monetary or other sort of incentive to the sponsor to allow the second entity to fill that seat.

[0047] Additionally, one ride option might have a higher cost than a second option, but might also be able to recognize higher revenue and generate higher satisfaction. Certain routes for dedicated users with few to no intermediate stops might have a relatively high cost per rider, but those riders might be willing to pay a premium for the service. Similarly, the rider experience values generated may be higher as a result. Thus, the fact that this ride option has a higher cost should not necessarily have it determined to be a lower value option than others with lower cost but also lower revenue. In some embodiments there can be pricing parameters and options that are factored into the objective function and optimization algorithms as well. Various pricing algorithms may exist that determine how much a route option would need to have charged to the individual riders. The pricing can be balanced with consumer satisfaction and willingness to pay those rates, among other such factors. The pricing can also take into various other factors as well, such as tokens, credits, discounts, monthly ride passes, and the like. In some embodiments there might also be different types of riders, such as customer who pay a base rate and customers who pay a premium for a higher level of service. These various factors can be considered in the evaluation and optimization of the various route options. Additionally, in calculating a cost for a ride reservation for the second (or later) entity, the cost can be based upon an available capacity on the ride or the cost of the ride may be the subject of an auction, online or otherwise.

[0048] FIG. 5 illustrates an example computing device 500 that can be used in accordance with various embodiments. Although a portable computing device ( e.g ., a smart phone or tablet computer) is shown, it should be understood that any device capable of receiving, processing, and/or conveying electronic data can be used in accordance with various embodiments discussed herein. The devices can include, for example, desktop computers, notebook computers, smart devices, Internet of Things (IoT) devices, video gaming consoles or controllers, wearable computers (e.g., smart watches, glasses, or contacts), television set top boxes, and portable media players, among others. In this example, the computing device 500 has an outer casing 502 covering the various internal components, and a display screen 504 such as a touch screen capable of receiving user input during operation of the device. These can be additional display or output components as well, and not all computing devices will include display screens as known in the art. The device can include one or more networking or communication

components 506, such as may include at least one communications subsystem for supporting technologies such as cellular communications, Wi-Fi communications, BLUETOOTH^® communications, and so on. There may also be wired ports or connections for connecting via a land line or other physical networking or communications component.

[0049] FIG. 6 illustrates an example set of components that can comprise a computing device 600 such as the device described with respect to FIG. 5, as well as computing devices for other purposes such as application servers and data servers. The illustrated example device includes at least one main processor 602 for executing instructions stored in physical memory 604 on the device, such as dynamic random-access memory (DRAM) or flash memory, among other such options. As would be apparent to one of ordinary skill in the art, the device can include many types of memory, data storage, or computer-readable media as well, such as a hard drive or solid state memory functioning as data storage 606 for the device. Application instructions for execution by the at least one processor 602 can be stored by the data storage 606 then loaded into memory 604 as needed for operation of the device 600. The processor can also have internal memory in some embodiments for temporarily storing data and instructions for processing. The device can also support removable memory useful for sharing information with other devices. The device will also include one or more power components 610 for powering the device. The power components can include, for example, a battery compartment for powering the device using a rechargeable battery, an internal power supply, or a port for receiving external power, among other such options.

[0050] The computing device may include, or be in communication with, at least one type of display element 608, such as a touch screen, organic light emitting diode (OLED), or liquid crystal display (LCD). Some devices may include multiple display elements, as may also include LEDs, projectors, and the like. The device can include at least one communication or networking component 612, as may enable transmission and receipt of various types of data or other electronic communications. The communications may occur over any appropriate type of network, such as the Internet, an intranet, a local area network (LAN), a 5G or other cellular network, or a Wi-Fi network, or can utilize transmission protocols such as BLUETOOTH^® or NFC, among others. The device can include at least one additional input device 614 capable of receiving input from a user or other source. This input device can include, for example, a button, dial, slider, touch pad, wheel, joystick, keyboard, mouse, trackball, camera, microphone, keypad, or other such device or component. Various devices can also be connected by wireless or other such links as well in some embodiments. In some embodiments, a device might be controlled through a combination of visual and audio commands, or gestures, such that a user can control the device without having to be in contact with the device or a physical input mechanism.

[0051] Much of the functionality utilized with various embodiments will be operated in a computing environment that may be operated by, or on behalf of, a service provider or entity, such as a rideshare provider or other such enterprise. There may be dedicated computing resources, or resources allocated as part of a multi-tenant or cloud environment. The resources can utilize any of a number of operating systems and applications, and can include a number of workstations or servers Various embodiments utilize at least one conventional network for supporting communications using any of a variety of commercially-available protocols, such as TCP/IP or FTP, among others. As mentioned, example networks include for example, a local area network, a wide-area network, a virtual private network, the internet, an intranet, and various combinations thereof. The servers used to host an offering such as a ridesharing service can be configured to execute programs or scripts in response requests from user devices, such as by executing one or more applications that may be implemented as one or more scripts or programs written in any appropriate programming language. The server(s) may also include one or more database servers for serving data requests and performing other such operations. The environment can also include any of a variety of data stores and other memory and storage media as discussed above. Where a system includes computerized devices, each such device can include hardware elements that may be electrically coupled via a bus or other such mechanism. Example elements include, as discussed previously, at least one central processing unit (CPU), and one or more storage devices, such as disk drives, optical storage devices and solid-state storage devices such as random access memory (RAM) or read-only memory (ROM), as well as removable media devices, memory cards, flash cards, etc. Such devices can also include or utilize one or more computer-readable storage media for storing instructions executable by at least one processor of the devices. An example device may also include a number of software applications, modules, services, or other elements located in memory, including an operating system and various application programs. It should be appreciated that alternate embodiments may have numerous variations from that described above. [0052] Various types of non-transitory computer-readable storage media can be used for various purposes as discussed and suggested herein. This includes, for example, storing instructions or code that can be executed by at least one processor for causing the system to perform various operations. The media can correspond to any of various types of media, including volatile and non-volatile memory that may be removable in some implementations. The media can store various computer readable instructions, data structures, program modules, and other data or content. Types of media include, for example, RAM, DRAM, ROM, EEPROM, flash memory, solid state memory, and other memory technology. Other types of storage media can be used as well, as may include optical ( e.g ., Blu-ray or digital versatile disk (DVD)) storage or magnetic storage (e.g., hard drives or magnetic tape), among other such options. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the various embodiments.

[0053] The specification and drawings are to be regarded in an illustrative sense, rather than a restrictive sense. It will, however, be evident that various modifications and changes may be made thereunto without departing from the broader spirit and scope of the various embodiments as set forth in the claims.

[0054] The use of the terms“a” and“an” and“the” and similar referents in the context of describing the disclosed embodiments (especially in the context of the following claims) are to be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms“comprising,”“having,”“including,” and “containing” are to be construed as open-ended terms (i.e., meaning“including, but not limited to,”) unless otherwise noted. The term“connected” is to be construed as partly or wholly contained within, attached to, or joined together, even if there is something intervening.

Recitation of ranges of values herein are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein and each separate value is incorporated into the specification as if it were individually recited herein. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples, or exemplary language (e.g,“such as”) provided herein, is intended merely to better illuminate embodiments of the disclosure and does not pose a limitation on the scope of the disclosure unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure. Disjunctive language such as the phrase“at least one of X, Y, or Z,” unless specifically stated otherwise, is intended to be understood within the context as used in general to present that an item, term, etc., may be either X, Y, or Z, or any combination thereof ( e.g ., X, Y, and/or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, or at least one of Z to each be present.

Claims

CLAIMS WHAT IS CLAIMED IS:

1. A computer-implemented method, comprising:

obtaining data relating to a predefined ridesharing route and a scheduled ride for the predefined ridesharing route, the scheduled ride having a plurality of seat instances;

allocating the plurality of seat instances to a first entity, based on the obtained data; receiving a request to reserve at least one seat instance on the scheduled ride;

determining, using a computer system, an initially-unused seat instance of the plurality of seat instances allocated to the first entity;

receiving, from a second entity, one or more reservation criteria for reserving a ride on the route, the reservation criteria including at least one of: a bid price for a ride reservation for the second entity, a total maximum price for the ride reservation for the second entity, and a desired timeframe for a ride on the predefined ridesharing route;

offering the first entity an incentive to allow the second entity to reserve at least one seat instance on the scheduled ride;

determining, using a computer system, that the initially-unused seat matches the reservation criteria; and

generating a ride reservation, relating to the at least one initially-unused seat instance, for the second entity.

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

providing the second entity with at least one standby opportunity for at least one of the ride or an earlier ride on the route, when riders associated with the first entity fail to timely appear for the ride or the earlier ride.

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

calculating a cost for the ride reservation for the second entity, the cost based upon at least one of: an available capacity on the scheduled ride; a desirability of a seat instance, and seat instance revocability status.

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

training a recurrent neural network on a data set; and applying the recurrent neural network to optimize at least one of: defining the predefined ridesharing route, ride suggestions for the first entity, ride suggestions for the second entity, and the determination of the one unused seat instance on the ride with respect to the first entity.

5. A computer-implemented method, comprising:

obtaining data relating to a predefined route and a scheduled ride for the route, the scheduled ride having a plurality of seat instances allocated to a first entity;

receiving a request to reserve at least one seat instance on the scheduled ride;

receiving, from a second entity, one or more reservation criteria for reserving a ride on the route;

generating a ride reservation, relating to the at least one unused seat instance, for the second entity.

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

offering the first entity an incentive to allow the second entity to reserve at least one seat instance on the scheduled ride.

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

calculating a cost for the ride reservation for the second entity, the cost based upon at least one of: an available capacity on the scheduled ride; a desirability of the initially-unused seat instance, and seat instance revocability status.

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

providing the second entity with at least one standby opportunity for the scheduled ride when riders associated with the first entity fail to timely appear for the scheduled ride.

9. The computer-implemented method of claim 5, wherein the one or more reservation criteria include at least one of: a bid price for the ride reservation for the second entity, a total maximum price for the ride reservation for the second entity, and a timeframe for a ride on the predetermined route.

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

receiving, from the first computing device, a request for the first entity to use the at least one unused seat instance;

suspending the ride reservation for the second entity; and

saving a state associated with the ride reservation relating to the predefined route.

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

resuming receiving requests to reserve a seat instance on the scheduled ride when at least one second unused seat instance becomes available.

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

training a machine learning model on a data set; and

applying the trained machine learning model to optimize at least one of: defining the predefined route, ride suggestions for the first entity, ride suggestions for the second entity, and the determination of the one unused seat instance on the scheduled ride with respect to the first entity.

13. A system, comprising:

at least one processor; and

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

obtain data relating to a predefined route and a scheduled ride for the route, the scheduled ride having a plurality of seat instances allocated to a first entity;

receive a request to reserve at least one seat instance on the scheduled ride;

determine, using a computer system, an initially-unused seat instance of the plurality of seat instances allocated to the first entity;

receive, from a second entity, one or more reservation criteria for reserving a ride on the route;

determine, using a computer system, that the initially-unused seat matches the reservation criteria; and generate a ride reservation, relating to the at least one unused seat instance, for the second entity.

14. The system of claim 13, wherein the instructions when executed further cause the system to:

offer the first entity an incentive to allow the second entity to reserve at least one seat instance on the scheduled ride.

15. The system of claim 13, wherein the instructions when executed further cause the system to:

calculate a cost for the ride reservation for the second entity, the cost based upon at least one of: an available capacity on the scheduled ride; a desirability of the initially-unused seat instance, and seat instance revocability status.

16. The system of claim 13, wherein the instructions when executed further cause the system to:

provide the second entity with at least one standby opportunity for the scheduled ride when riders associated with the first entity fail to timely appear for the scheduled ride.

17. The system of claim 13, wherein the one or more reservation criteria include at least one of: a bid price for the ride reservation for the second entity, a total maximum price for the ride reservation for the second entity, and a timeframe for a ride on the predetermined route.

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

receive, from the first computing device, a request for the first entity to use the at least one unused seat instance;

suspend the ride reservation for the second entity; and

save a state associated with the ride reservation relating to the predefined route.

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

resume receiving requests to reserve a seat instance on the scheduled ride when at least one second unused seat instance becomes available.

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

train a machine learning network on a data set; and

apply the machine learning network to optimize at least one of: defining the predefined route, ride suggestions for the first entity, ride suggestions for the second entity, and the determination of the one unused seat instance on the scheduled ride with respect to the first entity.