WO2021247679A1 - Communications network for managing vehicles - Google Patents

Abstract

A method for managing vehicles using a communications network, the method comprising: designating a plurality of routes, each route including a plurality of stops; determining that a rider is at one of the plurality of stops associated with one of the plurality of routes; receiving a ride request along the one of the plurality of routes from the rider; selecting at least one driver to fulfil the ride request; messaging the at least one driver to fulfil of the ride request; receiving agreement from the at least one driver to fulfil of the ride request.

Description

COMMUNICATIONS NETWORK FOR MANAGING VEHICFES

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims the benefit of US provisional patent application number 63/034674, filed June 4, 2020, the entire contents of which are incorporated herein by reference, and claims the benefit of US provisional patent application number 63/069222, filed August 24, 2020, tire entire contents of which are incorporated herein by reference.

BACKGROUND

[0002] The present disclosure relates generally to communication networks, and more particularly to systems, methods and computer program products for managing vehicles along predesignated routes.

[0003] Traffic congestion in almost all large and growing metropolitan regions around the world is increasing and is expected to worsen. Increasing public transit and road capacity has not significantly reduced road congestion, if at all. While there have been many proposals to address increased traffic congestion, none have significantly improved traffic congestion, particularly during peak commuting hours.

BRIEF DESCRIPTION OF DRAWINGS

[0004] Referring now to the drawings wherein like elements are numbered alike in the several FIGURES:

[0005] FIG. 1 depicts a vehicle management system in an example embodiment;

[0006] FIG. 2 depicts a flowchart of a process for operating the vehicle management system in an example embodiment;

[0007] FIG. 3 depicts a flowchart of a process for obtaining a ride in an example embodiment;

[0008] FIG. 4 depicts a notification on a rider device in an example embodiment; [0009] FIG. 5 depicts a notification on a driver device in an example embodiment;

[0010] FIGs. 6-9 illustrate providing a ride in an example embodiment;

[0011] FIG. 10 depicts costs for traditional ride sharing and institutionally subsidized ride sharing in an example embodiment;

[0012] FIG. 11 depicts costs for institutionally subsidized ride sharing in an example embodiment;

[0013] FIG. 12 depicts ride costs for traditional ride sharing and institutionally subsidized ride sharing in an example embodiment;

[0014] FIGs. 13-15 depict user interfaces for an application providing institutionally subsidized ride sharing in an example embodiment;

[0015] FIG. 16 depicts costs for mobility as a service and municipal public transit in an example embodiment;

[0016] FIGs. 17-23 depict user interfaces for an application providing mobility as a service in an example embodiment.

DETAILED DESCRIPTION

[0017] FIG. 1 depicts a vehicle management system 10 for providing ride services in an example embodiment. The system 10 includes a ride services server 12. The ride services server 12 may be embodied as any type of processor-based computation or computer device capable of performing the functions described herein, including, without limitation, a computer, a server, a workstation, a desktop computer, a laptop computer, a notebook computer, a tablet computer, a mobile computing device, a mobile phone, a wearable computing device, a network appliance, a web appliance, a distributed computing system (e.g., cloud computing), a processor-based system, and/or a consumer electronic device. A database 14 is associated with the ride services server 12 and may be implemented using known storage devices for storing electronic data, either locally or remotely from the ride services server 12. [0018] Access to the ride services server 12 may be made over a network 16. The network 16 may be implemented via one or more wired and/or wireless networks, such as, but are not limited to, one or more of WiMax, a Local Area Network (LAN), Wireless Local Area Network (WLAN), a Personal area network (PAN), a Campus area network (CAN), a Metropolitan area network (MAN), a Wide area network (WAN), a Wireless wide area network (WWAN), or any broadband network, and further enabled with technologies such as, by way of example, Global System for Mobile Communications (GSM), Personal Communications Service (PCS), Bluetooth, WiFi, Fixed Wireless Data, 2G, 2.5G, 3G (e.g., WCDMA/UMTS based 3G networks), 4G, IMT-Advanced, pre-4G, LTE Advanced, mobile WiMax, WiMax 2, WirelessMAN-Advanced networks, enhanced data rates for GSM evolution (EDGE), General packet radio service (GPRS), enhanced GPRS, iBurst, UMTS, HSPDA, HSUPA, HSPA, HSPA+, UMTS-TDD, lxRTT, EV-DO, messaging protocols such as, TCP/IP, SMS, MMS, extensible messaging and presence protocol (XMPP), real time messaging protocol (RTMP), instant messaging and presence protocol (IMPP), instant messaging, USSD, IRC, or any other wireless data networks, broadband networks, or messaging protocols.

[0019] In operation, drivers and riders communicate with the ride services server 12 so that riders are provided ride services. FIG. 1 depicts riders 20 operating rider devices 22. The rider devices 22 may be embodied as any type of processor-based computation or computer device capable of performing the functions described herein, including, without limitation, a computer, a server, a workstation, a desktop computer, a laptop computer, a notebook computer, a tablet computer, a mobile computing device, a mobile phone, a wearable computing device, a network appliance, a web appliance, a distributed computing system (e.g., cloud computing), a processor-based system, and/or a consumer electronic device. The rider devices 22 communicate with the ride services server 12 over network 16. The rider devices 22 execute a software application, referred to herein as a rider application. Rider access to the ride services server 12 may be limited to individuals who are members of a ride service. Requiring membership may be used to limit the number of participants and control activity.

[0020] FIG. 1 depicts drivers 30 (and an associated vehicle) operating driver devices 32. Vehicles providing ride services may include any type of vehicle, such as a car, minivan, bus, etc. The driver devices 32 may be embodied as any type of processor-based computation or computer device capable of performing the functions described herein, including, without limitation, a computer, a server, a workstation, a desktop computer, a laptop computer, a notebook computer, a tablet computer, a mobile computing device, a mobile phone, a wearable computing device, a network appliance, a web appliance, a distributed computing system (e.g., cloud computing), a processor-based system, and/or a consumer electronic device. The driver devices 32 communicate with the ride services server 12 over network 16. The driver devices 22 execute a software application, referred to herein as a driver application. Driver access to the ride services server 12 may be limited to individuals who are members of a ride service. Requiring membership may be used to limit the number of participants and control activity.

[0021] FIG. 2 depicts a high-level flowchart of a process for operating the system 10. The process begins at 110 with the creation of routes and stops. The routes and stops are assigned by administrators of the system 10 and stored in database 14. The routes identify travel paths that drivers will follow and the stops identify locations along a route at which riders can be picked up or dropped off. In this manner, the system 10 is different from existing ride services (such as Uber or Lyft) in which the rider designates the beginning and ending points of a ride. In embodiments of the invention, the routes and stops are assigned by administrators of the system 10. As described herein, the routes and stops are not static, but rather are constantly updated. The routes and stops initially created at 110 may be based on existing population data and existing traffic data for a geographical area.

[0022] The stops may be public places, including government and commercial locations, such as schools, libraries, universities, medical facilitates, corporate offices/campuses, coffee shops, restaurants, gas stations, retail locations, etc. Retail locations, such as restaurants or retailers, may pay a fee to be assigned as a stop. Existing transportation depots, such as bus stops, taxi stands, etc., may be used as stops.

[0023] At 112, the system 10 manages drivers. Drivers interface with the ride services server 12 through the driver application executing on a driver device 32. Drivers may be added and removed from the system 10. Drivers may create profiles identifying vehicle type and vehicle capacity. Drivers may also be associated with certain routes, times of day per route, day of week per route or other preferences. Data associated with drivers may be stored in database 14.

[0024] At 114, the system 10 manages riders. Riders interface with the ride services server 12 through the rider application executing on a rider device 22. Riders may be added and removed from the system 10. Riders may create profiles identifying preferred routes and preferred stops, times of day per route, day of week per route or other preferences. Data associated with riders may be stored in database 14.

[0025] A person can be a driver, a rider, or both. The ride services system 10 may require that drivers and riders be members of the system. Drivers are typically compensated via on funds received from riders, derived from per ride payments, membership fees and/or other financial means.

[0026] At 116, the system 10 monitors traffic. By using the location (e.g., GPS) of both the driver devices 32 and the rider devices 22, the system 10 can monitor traffic along the routes all day, every day. The traffic data is continually collected by the ride services server 12 and stored in database 14.

[0027] At 118, the system 10 is updated based on data collected by the ride services server 12. The ride services server 12 executes intelligent processes to update drivers, routes and/or stops. The intelligent processes may be supported by forms of machine learning. For example, the ride services server 12 may implement a decision tree, associational rule set, logic programming, regression model, cluster analysis mechanisms, Bayseian network, propositional formulae, generative models, or other models or forms of decision-making. The ride services server 12 may employ deep learning processes.

[0028] At 118, drivers may be assigned to new routes in order to move resources from underused routes (too few riders) to overused routes (too many riders). Drivers may also be recruited to serve overused routes. A potential source of drivers for an overused route are riders who frequently ride that route.

[0029] At 118, new routes and/or stops may be added. For example, if a route is frequently overused, then an additional route may be added. Riders may also request the addition of routes and/or stops by sending a route request and/or a stop request to the ride services server 12.

[0030] FIG. 3 depicts a process of a rider obtaining a ride along a route in an example embodiment. FIG. 3 refers to a single stop, but a similar process would occur for all stops. At 210, the system 10 detects that a rider is located at a stop. This may be performed by tracking the location of a rider device 22 and determining that the rider is proximate to a stop. If a rider has not approached as stop, the process continues to wait at step 210.

[0031] If a rider has approached a stop at 210, flow proceeds to 212, where the rider is queried whether they need a ride. Step 212 may be performed by sending a message to the rider device 22 associated with the rider at the stop. FIG. 4 depicts an example message presented on a rider device 22. If the rider does not need a ride at 212, then flow returns to 210. If the rider confirms that they need a ride, flow proceeds to 214 where the rider can then provide ride parameters such as the destination stop, number of passengers, cargo requirements, accessibility needs, etc. The ride parameters are used to create a ride request.

[0032] At 216, the ride services server 12 locates one or more drivers to fulfill the ride request. The ride services server 12 may consider several factors in determining which drivers should be contacted regarding the outstanding ride request. The ride parameters are compared to available drivers to determine how well available drivers match the ride parameters. An initial inquiry may limit the pool of available drivers to drivers associated with the route in question and having capacity for passengers. Other ride parameters such as accessibility needs, cargo space, etc. may be used to determine the top N drivers best matching the ride parameters (e.g., top three drivers). Once identified, the potential drivers are sent a message regarding the ride request via the driver application on the driver device 32.

[0033] FIG. 5 depicts an example message presented on a driver device 32. If the driver is willing to fulfill the ride request, the driver selects yes and proceeds to the stop. If no driver replies, the system will timeout. The first driver to reply YES is assigned to fulfill the ride request. Referring back to FIG. 3, once a driver has accepted to fulfill the ride request, flow proceeds to 218 where the ride is confirmed. Both the rider device 22 and the driver device 32 may receive confirmation messages along with estimate time of arrival, the vehicle description, driver phone number, etc.

[0034] FIGS. 6-9 present an example of fulfilling a ride request in an example embodiment. In FIG. 6, there are four drivers (D-l to D-4), and there are 16 riders (R1 to R16) located at five stops (STOP-1 to STOP-5). The drivers D-l to D-4 travel along designated routes, shown as Al-Bl, A2-B2, A3-B3 and A4-B4. Once a rider arrives at a stop, they will send request which stop they are going to go. For example, riders 4 and 5 at STOP-2 want to go the STOP-5.

[0035] In FIG. 7, the ride services server 12 has processed the ride parameters (e.g., two riders from STOP-2 to STOP-5) to determine drivers best matching the ride request. Based on the best match algorithm, the ride services server 12 determines that drivers D2 and D4 are best suited to serve the ride request from R4 and R5 at STOP-2.

[0036] In FIG. 8, the ride services server 12 sends messages to the driver devices 32 associated with drivers D-2 and D-4 querying if the drivers will fulfill the ride request. The message is depicted as “2 from S2 to S5. Y/N?”. The first driver to reply Y will be assigned to fulfill the ride request. If no answer is received within a pre-defined time period, this indicates an answer of “No”.

[0037] In FIG. 9, driver D-4 has responded YES and is assigned to fulfill the ride request. Driver D-2 receives a message that the ride request has been filled by another driver. Driver D-4 will stop at STOP-2, pickup riders R4 and R5, travel to STOP-5 along the designated route and drop riders R4 and R5 at STOP-5. Then driver D-4 will continue to the original destination B4 along the designated route. Meanwhile, driver D-2 may be assigned another ride request or may drive to his destination B2 without any riders.

[0038] Embodiments of the vehicle management system 10 allow for institutional sponsorship of ride sharing services. All of, or a portion of, a route may be sponsored by institutions which are paid for by those institutions. Institutions may include entities such as workplaces (campuses, offices, franchises, mobile/care-based, Stores), educational (campuses, school districts/municipal, universities, government), MUD/FIOA (apartments and condominiums, property developers, employing corporations), TNCs (transportation network companies; ride-sharing & ride-hailing services, bus & train operators, taxi companies, municipal/government transportation providers, airline & travel operators, automotive OEMs, etc.).

[0039] Transportation routes which service institutional locations or locations otherwise of interest to institutions are sponsored to varying degrees by those institutions, thus creating a pool of funds contributing towards the overall costs of rides within those routes. Institutions may or may not validate the subsidy on a per-rider basis; meaning riders of this transportation system may be eligible for subsidies based only upon their membership to these institutions, or subsidy may be granted to all riders using a particular sponsored route, or a combination therein. Furthermore, riders who are granted subsidies based upon institutional membership may have those subsidies made available to them across all routes by their sponsoring institution. Subsidies by institutions contributing to overall costs of rides are generally broken into three parts, each relating to a pertinent stakeholder within the transportation system; 1. Program Pay: the portion of the Program Subsidy paid to the transportation driver. 2. Program Margin: a flexible share of the Program Subsidy first covering any incidentals related to the respective ride or route, then paid to an operator of the vehicle management system 10. 3. Program Fee: the portion of the Program Subsidy paid to the operator of the vehicle management system 10 directly. These three parts are generally of equal value to each other, but not necessarily.

[0040] FIG. 10 depicts an overview of a ride cost comparison between a traditional ride-sharing (ride-hailing) route, and an institutionally subsidized ride-sharing route. The routes for which these cost amounts are shown are equal in all parameters. Data for this sample route are taken from a standard high-congestion ride-hailing trip within downtown San Francisco, CA of 2.93 miles, lasting 13.05 min. An operator of the vehicle management system 10 may be referred to as a transportation network company (TNC).

[0041] FIG. 10 includes the following components, which are described in further detail herein. Component 1.1 describes the total cost of the example route for a traditional TNC ride ($12.64), with the portion of that cost paid for by the rider shown below ($12.64, All). Component 1.2 describes the total cost of the example route for an institutionally subsidized TNC route ($8.44), with the portion of that cost paid for by the rider shown below ($6.41). Component 1.3 (Subsidy) describes the total amount of this route paid for by the subsidizing institution. In this example, that subsidy is set at a standard (minimal) contribution level of 24%, coming out to an amount of $2. Component 1.4 (TNC Fees) describes the total amount of this route collected directly, via fees, by the TNC ($2.36, 28% of the total route cost) in this example. Component 1.5 (Driver $) describes the total quantitative share of this route earned by the driver (vehicle owner and operator handling this route on behalf of the TNC) ($5.40, 64% of the total route cost). Component 1.6 (Driver $) describes the total quantitative share of this route earned by the driver, in this example the driver of a traditional TNC ride/route ($5, 59% of the total route cost). Component 1.7 (TNC Fees) describes the total amount of this route collected directly, via fees, by the traditional TNC ($5, 40% of the total route cost) in this example.

[0042] Total Route Costs ( component 1.1) and Rider shares of those Costs are stated at top (component 1.1 states the total cost and rider portion of cost for a Traditional TNC ride, while 1.2 states the total cost and rider portion of cost for an Institutionally Subsidized TNC route). Comprising the total cost of an Institutionally Subsidized ride-sharing route are components 1.3, 1.4, and 1.5, representative of costs/payments to three stakeholders within the route environment; component 1.3 represents the subsidy portion of the route paid for by the Institutional Program Host, component 1.4 represents the TNC fee portion of the route paid for by the rider/user and paid to the TNC, and component 1.5 represents the driver $ portion of the route paid for by the rider/user and paid to the driver servicing this particular Route/Ride. The component 1.3, or the Subsidy portion of the route cost paid for by the institutional program host, pays out to both rider/user and driver stakeholders, as well as providing a margin (component 2.2, Figure 11) for liabilities implicit within the subject ride. Ah of these constituent line item costs are detailed further in FIG. 12.

[0043] Comprising the total cost of a traditional TNC ride-sharing route/ride are components 1.6 and 1.7, representative of costs/payments to two stakeholders within the route environment (given that traditional TNC ride-sharing routes only include the two stakeholders of rider/user and driver); component 1.6 represents the driver $ portion of the route paid for by the rider/user and paid to the driver servicing this particular route/ride, while component 1.7 represents the program fee (component 2.3, Figure 11) portion of the route paid for by the rider/user and paid to the TNC. All of these constituent line item costs are detailed further in FIG. 12.

[0044] FIG. 11 includes the following components. Component 2.1 (program pay) describes the share of the subsidy collected by the driver of this route, and thus in turn the share of the total route cost collected by the driver. Component 2.2 (program margin) describes the share of the subsidy used to cover route incidental costs, and then collected by the TNC - in turn this describes the share of the total route cost used to cover incidental costs and afterward be collected by the TNC. Component 2.3 (program fee) describes the share of the subsidy collected by the TNC, and thus in turn the share of the total route cost collected by the TNC. Component 2.4 (distance rate) describes the total cost of all miles driven within the ride (ride is defined by the route from the perspective of the rider; the interval between a rider boarding the route vehicle and arriving at their respective destination), collected by the driver. Component 2.5 (time rate) describes the total cost of the time interval passing during the Ride, collected by the Driver. Component 2.6 (booking fee) describes the share of the time interval costs (time rate) and the miles driven cost (distance rate), collected by the TNC.

[0045] FIG. 11 includes a list of cost components used in embodiments including institutional sponsorship of ride sharing services. Only the program subsidy (component 1.3) components are particular to this invention (“system”) - these components include program pay (component 2.1), program margin (component 2.2)” and program fee (component 2.3). As stated previously, components 2.1, 2.2, and 2.3 are constituents of the program subsidy (component 1.3), or the portion of this route paid for by the subsidizing institution. Each accounts for different stakeholders; program pay (component 2.1) is collected by drivers, program margin (component 2.2) covers incidentals and is then collected by the TNC, and program fee (component 2.3) is collected by the TNC. Components 2.4, 2.5 and 2.6 are standard ride-sharing definitions, accounting for cost line items transacting between rider/users and drivers, and ride costs attributed to TNCs.

[0046] FIG. 12 depicts a detailed theoretical ride cost comparison between a traditional TNC ride-sharing (ride-hailing) route (at left), and an institutionally subsidized ride-sharing route (at right)- including total cost shares and percentages of total to drivers, riders, programs and TNCs, and cost components as defined in FIG. 11. For the traditional TNC ride-sharing route, on the left-hand side, the total cost share collected by the driver servicing this route is shown as being $7.47, representing 59% of the total route cost. The total cost share collected by the TNC for this route is shown as being $5.17, representing 41% of the total route cost of $12.64. FIG. 12 includes component 3.1 (base fare) describes the minimum payment collected from the rider for the ride, collected by the driver. Component 3.2 (service fee) describes the share of total ride costs attributed to a fee for usage of TNC software services, collected by the TNC.

[0047] Components of the costs collected by the driver and paid for in full by the rider/user include distance rate (component 2.4), time rate (component 2.5) and base fare (component 3.1). Components of the costs collected by the TNC and paid for in full by the rider/user include booking fee (component 2.6) and service fee (component 3.2). The distance (2.93 mi) and distance rate ($0.6825/mi) for this example route can be seen at the bottom left, as well as the time (13.05 min) and time rate ($0.2925/min) for this example route to the right of that.

[0048] For the institutionally subsidized TNC ride-sharing route:, on the right-hand side, the total cost share collected by the driver servicing this route is shown as being $5.40, representing 64% of the total route cost. The total cost share collected by the TNC for this route is shown as being $2.37-$3.05, a range indicating the degree by which the program margin (component 2.2) is used to cover incidentals prior to being collected by the TNC. This range represents, at maximum, 36% of the total route cost.

[0049] Components of the cost collected by the driver include distance rate (component 2.4) and time rate (component 2.5), which are paid for in full by the rider/user, and program pay (component 2.1) which is paid for in full by the institutional program host. Components of the costs collected by the TNC include the booking fee (component 2.6), which is paid for in full by the rider/user, and the program fee (component 2.3), which is paid for in full by the institutional program host.

[0050] Components of the costs paid for by the institutional program host include the program pay (component 2.1), which is paid to the driver, the program margin (component 2.2), which is used to cover incidental costs first and then subsequently paid to the TNC, and the program fee (component 2.3), which is paid to the TNC. In this example, the rider/user pays $6.41, or 76% of the total ride cost. The institutional program host pays $2.04, or 24% of the total ride cost.

[0051] FIG. 13 depicts an example mobile software application for a TNC service showing a user perspective on institutional program subsidies they are a part of, and their options for altering and receiving said subsidies. Also shown are other institutional route subsidy programs offered, and assorted other user interface elements to be described further below. FIG. 13 includes the following components. Components 4.1, 4.5 (route reduction) describes the share of the total ride costs for rides on this route paid for by the institutional program host. For this example, which is different from the previous cost comparison example provided, that reduction on rides within this route is 62%. Components 4.2, 4.6 (billable?) describes the willingness of this institutional program host to apply route reduction (subsidy) to rides outside of sponsored routes (rides not involving Institutional locations within origins, stops, or destinations). In this example, this “billable” trait is expressed as a toggle switch, toggleable by a user/rider of this TNC application, with the function of enabling or disabling institutional subsidies on non-institutional routes. This toggle switch will not be movable by the user if the institutional program host does not allow for this schema. Components 4.3, 4.7 (billable reduction) describes the share of the total ride costs for rides outside of sponsored routes, if applicable given the state of “billable” switch (component 4.2). Components 4.4, 4.8 (X program description) provides a link for users/riders to a more detailed screen providing data and trends relating to their usage of institutional program host routes - this more detailed screen can be seen as FIG. 14. Component 4.9 (other program offers) describes offers put forth by other institutions participating in this TNC services’ program subsidy system, presented based on rider destinations, stops, origins, or general user trends. Nominally, these offers present the route reduction (subsidy share) made available by the participating institutions for rides within their respective routes (involving these offering institutions’ facilities or locations of interest), as well as the billability of these program subsidies, and perhaps but not necessarily, the method by which this program offer was selected for any given user/rider.

[0052] The first pane from the top, within the section “Your Programs” displaying institutional programs to which the viewing rider/user³ is part of. The example of FIG. 13 includes an institutional program “Workplace” - located at the address given with the example identification icon at left. The subsidy offered by this institutional program host, perceived by the rider/user as a discount, is given as the route reduction (component 4.1) - standing at 62% of all ride costs for rides within program routes taken by this rider/user. The user may toggle the “billable?” (component 4.2) option to receive a subsidy amount equal to that amount of 5% shown as billable reduction (component 4.3) from this program host on non-institutional routes, if made available by the subject institution. The user may view an expanded data set relating to this institutional program by selecting Workplace, program description (component 4.4).

[0053] The second pane from the top describes an institutional program, for example, “University Campus” - located at the address given with the example identification icon at left. The subsidy offered by this institutional program host, perceived by the rider/user as a discount, is given as the route reduction (component 4.5) - standing at 40% of all ride costs for rides within program routes taken by this user. The user may not, in this case, toggle the “billable?” (component 4.6) option, as no subsidy amount (“not billable” as shown for “billable reduction” (component 4.7)) is made available on routes besides institutional routes by this subject institution. The user may view an expanded data set relating to this institutional program by selecting University Campus, program description (component 4.8).

[0054] The button “Your Past Memberships”, within the section “Your Programs”, allows the user to see all institutional host programs to which they were members in the past.

[0055] The third pane from the top is a section called “Join Other Programs”, which presents users with offers (component 4.9) put forth by other institutions participating in this TNC services’ program subsidy system, presented based on rider destinations, stops, origins, or general user trends. Nominally, these offers present the route reduction (component 4.1, subsidy share) made available by the participating institutions for rides within their respective routes (involving these offering institutions’ facilities or locations of interest), as well as the billability (component 4.2, component 4.3) of these program subsidies (component 1.3), and perhaps but not necessarily, the method by which this program offer (component 4.9) was selected for any given user/rider. The search tool “Manually Join Program”, within the section “Join Other Programs”, allows users to manually locate institutional programs to which they may apply for membership. [0056] FIG. 14 shows an expanded menu listing of the example mobile software application showing a user/rider perspective on institutional program subsidies (component 1.3) that user is a member of, and their options for altering and receiving said subsidies. In addition, this expanded menu shows user statistics and economics over a period of time of past rides within this institution subsidized routes.

[0057] FIG. 14 includes the following components. Component 5.1 (ride congestion) describes the average traffic/congestion on rides taken by the respective user/rider within this institutionally subsidized route. This average congestion, as shown in the example of FIG. 14, is generally expressed graphically in terms of relative time intervals over a given period of usage (a month, in this example). Generally, this ride congestion indicator will be used to describe the time intensiveness of a commute route or set of routes, based upon timing and traffic conditions. Component 5.2 (total spend on program routes) describes the total amount spent by the rider/user of this TNC institutionally subsidized service on routes sponsored by this institutional program host. In this example, that amount spent within the last Month on institutional routes is $180.82, representing a +4% increase over the previous month. Component 5.3 (savings compared to standard TNC on program routes) describes the total amount saved by the rider/user taking rides on institutionally subsidized routes versus using a traditional TNC for those equivalent rides. In this example, the total amount displayed is aggregated over a month of rides on these institutionally subsidized routes, totaling $350 which is representative of a 52% discount for the rider choosing institutionally subsidized routes versus traditional TNC routes. Component 5.4 (utilization of program routes) describes the utilization of this programs’ institutionally subsidized routes by the rider/user versus that riders’ total ride utilization on the TNC platform. In this example, the rider has used these institutionally subsidized routes for 74% of their total rides on the TNC platform over the course of a month, representing a -2% decrease over the previous month. Component 5.5 (optimal times for [transit via] program routes) describes the optimal times, in terms of route congestion/duration, for the rider/user to take rides on institutionally subsidized routes. These optimal times are generally presented based on historic congestion data and trends, just as the ride congestion data visualization (component 5.1). [0058] The first pane from the top, within the section “Your Programs”, describes an institutional program “Workplace”, detailing route reduction and billability (component 4.1, component 4.2, component 4.3), just as the first pane does in FIG. 13.

[0059] The expanded “Monthly Stats” section, selected via the “[Workplace] Program Description” (component 4.4) link described in FIG. 13, displays an expanded data set relating to this institutional program over a past monthly period. Average ride congestion (component 5.1) over the previous monthly period is shown at top, along with optimal times (component 5.5) for the viewing user to transit over these institutional routes given those historical traffic trends. Average times for rides within the institutional subsidized routes are given within the optimal times (component 5.5). Total spend (component 5.2) on subsidized routes under this institutional program, along with savings compared to standard TNC routes (component 5.3) are displayed in terms of dollars and percentages. Utilization (component 5.4) trends are displayed, representing the share of total rides taken by the viewing user which fall under routes applicable by this institutional program.

[0060] The third pane from the top describes an example institutional program “University Campus” - detailing route reduction and billability (component 4.1, component 4.2, component 4.3), just as the first pane does in FIG. 13. The button “Your Past Memberships”, within the section “Your Programs”, allows the user to see all institutional host programs to which they were members of in the past. The section “Join Other Programs” can be seen at screen bottom, though it is blank at this view.

[0061] FIG. 15 depicts an example mobile software application showing a driver perspective on institutional subsidy programs they are a part of, and their options for earning program pay (program subsidies (component 1.3)) both via these member institutional programs shown and additional programs offered (as in shown FIGs. 13 and 14). FIG. 15 includes the following components. Component 6.1 (Program Members) describes the total number of riders/users who are both eligible and registered under this program host (institutionally subsidized routes), as seen from the perspective of a TNC ride-sharing service driver. Component 6.2 (Members on your [Driver’s] Routes) describes the total number of program members (riders/users who are both eligible and registered under this program host) who are regularly using institutionally subsidized routes on which the viewing driver is also commuting. Component 6.3 (Active Driver?) describes the ability for a driver using the application of a TNC service to toggle on/off their visibility on the TNC service platform for all rider/users who are part of the respective institutionally subsidized routes program. In this example, the using driver has toggled the setting to the on position, allowing for all rider/users who are part of the “Workplace” institutional subsidy program to openly view them. Component 6.4 (Fare Subsidy) describes the cost share of applicable institutionally subsidized routes collectable by the driver for servicing of rides along those routes. This cost share is previously described as “Program Pay”, and is a subsidy payment of 10% of the total fare amount received by the driver for servicing a ride, on top of the already existing fare payment as described in FIG. 11.

[0062] Referring to FIG. 15, the first pane from top, within the section “Your Programs” displaying institutional programs to which the viewing driver is part of, describes an institutional program “Workplace” - located at the address given with the example identification icon at left. The quantity of riders/users who are participating members of this institutional program is shown at top (program members, component 6.1), with the quantity of those members overlapping routes taken by the viewing driver shown below as members on your routes (component 6.2). The active driver (component 6.3) toggle allows the viewing driver to be visible to all program members (as displayed in component 6.1), if toggled ON, or only visible to overlapping program members (as displayed in component 6.2), if toggled OFF. Fare subsidy (component 6.4) describes the cost share of applicable institutionally subsidized routes collectable by the driver for servicing of rides along those routes. This cost share is previously described as “Program Pay”, and is a subsidy (component 1.3) payment of 10% of the total fare amount received by the driver for servicing a ride, on top of the already existing fare payment as described in FIG. 11. The driver may view an expanded data set relating to this institutional program by selecting [Workplace] Program Description (component 4.4).

[0063] The second pane from the top is identical to the first in terms of definition.

[0064] The third pane from the top is a section called “Join Other Programs”, which presents drivers with offers (component 4.9) put forth by other institutions participating in this TNC services’ program subsidy system, presented based on driver destinations, stops, origins, or general user/driver trends. Nominally, these offers present the fare subsidy (component 6.4) made available by the participating institutions for driven routes within their respective routes (involving these offering institutions’ facilities or locations of interest), as well as the member discount (a promotional term applying to driver/user transactional engagement with that institution), and perhaps but not necessarily, the method by which this program offer (component 4.9) was selected for any given user/rider.

[0065] The section “Join Other Programs” can be seen at screen bottom, though it is blank at this view.

[0066] Embodiments of the vehicle management system 10 allow for multimodal trips. A system, service and application allowing users of a ride-sharing service to put together routes or travel plans between origins and destinations spanning multiple mass transit mediums available to them, leveraging varied transit networks and transit modes to bring ride-sharing users cost savings and improved flexibility in terms of area coverage, time efficiency, and cargo/logistics capability.

[0067] Embodiments of the vehicle management system 10 address systemic deficits for several transit system stakeholders within ride-sharing systems; ride-sharing users (riders), public transportation operators, and ride-sharing network operators (TNCs). Existing ride-sharing services (refer also to “ride hailing services³”) offer no in-built mobility as a service methods, thus leaving riders without cohesive access to all available public and private transportation networks (or any networks outside on the TNC network), TNCs without customer service, network coverage, and marketing/perception benefits inherent in multi-modal transportation service offerings, and public transportation operators without the improvements in customer service, operation and coverage brought by servicing of routes and riders via a TNC application.

[0068] FIG. 16 depicts a pricing comparison between a mobility as a service (MaaS) ride-sharing application (11.1) and standard municipal owned & operated public transportation, with estimated costs shown in monthly allotments, attributed towards two stakeholders - operators (the municipality, in this case), and users (riders). This pricing schema comparison exists to show the increased efficiency, in economic terms, of MaaS ride sharing services (11.1) over standard public transportation. The budgetary numbers representing estimated municipal monthly costs and pricing are taken from the BART (Bay Area Rapid Transit) 2018 year-end Budget.

[0069] FIG. 16 includes the following components. Component 11.1, MaaS ride sharing describes the estimated monthly costs for a commuter/application user of a ride sharing application offering any and all available transportation modes to for any user- requested route. These costs, or expenses, are divided by those due to the user and those due to the operator, with further subdivision provided for costs collected by the route driver, TNC, and margin (11.6). Component 11.2, user expense describes the portion of the total monthly MaaS ride sharing (11.1) cost which is paid for by the user/rider. Component 11.3, operating expense describes the portion of the total monthly MaaS ride sharing (11.1) cost which is paid for by the operator. Component 104, driver pay describes the total quantitative share of this monthly MaaS ride sharing routes total earned by the driver (vehicle owner and operator handling this route on behalf of the TNC). Component 11.5, fee revenue describes the total quantitative share of this monthly MaaS ride sharing collected by the TNC via fees. Component 11.6, margin describes the total share of the route cost used to cover route incidental costs, and then collected by the TNC. Component 11.7, municipal public transit describes the estimated monthly costs for a commuter/user/rider of a system of transport, in contrast to private transport, available for use by the general public, typically managed on a schedule, operated on established routes (public transit routes), and charging a predetermined fee for each trip. Component 11.8, operating revenue describes the total share of the monthly municipal public transit cost considered to be incoming revenue to the operator, from transit network operations (e.g. ticket fares, user fees). Component 11.9, fares describes the total share of the monthly municipal public transit cost collected by the operator via fares (e.g. ticket sales). Component 11.10, employees describes the total share of the monthly municipal public transit cost spent by the operator on employment (e.g. drivers, conductors, office staff). Component 11.11, user cost describes the total share of the monthly municipal public transit cost paid for by the user/rider. Component 11.12, debt interest describes the total share of the monthly municipal public transit cost spent by the operator on interest for loans (e.g. infrastructure cost loans, bond loans, expansion loans). Component 11.13, purchased transportation describes the total share of the monthly municipal public transit cost spent by the operator on transportation outside of their network (e.g. paratransit - contracted temporary route busses). Component 11.14, expansion budget describes the total share of the monthly municipal public transit cost spent by the operator on transportation network expansion (e.g. expansion of routes, expansion of coverage).

[0070] Components 11.1 (MaaS ride sharing) and 11.7 (municipal public transit) are titles for the underlying pricing/budgetary comparisons. Components 11.2 (user expense), 11.3 (operating expense) are sectional titles within the MaaS ride sharing section, sectioning expenses due to the user (of the MaaS ride-sharing system) from expenses due to the operator (of the MaaS ride-sharing system; a TNC and any relevant transportation network operators). Component 11.8 (operating revenue) and the adjacent operating expense are sectional titles within the municipal public transit section, sectioning expenses due to the user (rider of the public transportation system) from expenses due to the operator (of the public transportation system; a municipality, in this example). The following components represent MaaS ride sharing expenses: Component 11.4 (driver pay) shows the amount paid to the driver directly by the rider/user, over the course of one month. Component 11.5 (fee revenue) shows the amount paid directly to the TNC by the rider/user, over the course of one month. The two values by these same names on the municipal public transit side of the circle are simply paid by the operator instead of by the user. Component 11.6 (margin) shows the amount paid to cover incidentals and liability, by the operator. The following components represent municipal public transit expenses. Component 11.9 (fares) shows the amount paid to the operator in fares by the rider/user. Components 11.10, 11.12, 11.13 and 11.14 show amounts paid by the operator for operational costs (required to run the transportation system).

[0071] FIG. 17 depicts an example mobile software application for a MaaS ride sharing service showing the initial configuration screen for a trip planner, allowing the rider/user of the service to request service for a trip over a larger distance (larger than a typical commute route, often but not necessarily a trans-city trip, servicing non-typical destinations). FIG. 17 includes the following components. Component 12.1, origin describes the user input field enabling the user/rider to search for and define the starting point of a route, as well as the starting time for that route. Component 12.2, final destination describes the user input field enabling the user/rider to search for and define the destination point for a route. Component 12.3, recent searches describes the destinations most recently searched for by the user/rider, in configuring a route to request from the TNC. Component 12.4, favorites describes the destinations and/or routes most often used, searched for, configured, or manually added by the user/rider, in order to be requested from the TNC service. Component 12.5, suggested trips describes the relevant routes (trips) suggested to the user/rider by the MaaS Application (11.1), sorted and displayed based upon those routes’ efficiency in transit time and cost at any given time (system time - the time in which this element is viewed).

[0072] Referring to FIG. 17, the first section from the top allows users/riders to set an origin (component 12.1) and leaving time, or starting point, and a final destination (component 12.2), or ending point, for their trip. The second pane from the top, recent searches (component 12.3), displays any destinations recently searched for by the rider/user as their final destination (12.2). The third pane from the top, favorites (component 12.4), displays destinations frequently searched for, travelled to, or otherwise interacted with by the rider/user. The last pane, suggested trips, displays optimal trips the rider/user may want to take based on timing and economic efficiency. All of these sections combined give varied optionality to riders/users requesting a trip via a MaaS ride-sharing application.

[0073] FIG. 18 depicts an example mobile software application for a MaaS ride sharing service (11.1) showing the confirmation screen for a trip configured by a rider/user of the application/service. FIG. 18 includes the following components. Component 13.1, leave at time describes the time set by the user/rider for embarking on the configured route/trip. This is set via the user input field “origin (12.1)”. Component 13.2, route (e.g., San Jose Downtown) describes a route available within this trip. This displayed route is via the ride sharing transit mode, in this case using the application provider ride-sharing TNC service, with the destination stop for this user/rider listed, along with the route cost and route time duration. The user/rider may choose to select this Route, and thus request the service of this ride-sharing transportation. Component 13.3, describes the choice available to the application user/rider for selection of routes with different transportation modes comprising that user/riders’ configured trip. Component 13.4, route (e.g., Stanford - San Jose Line) describes a route available within this trip. This displayed route is via public transportation systems, in this case using the #40 city bus line, with the destination stop for this user/rider listed, along with the route cost and route time duration. The user/rider may choose to select this route, and thus be redirected to (or do so within the platform) purchase tickets for this public transit route. Component 13.5, route (e.g., San Jose - Los Angeles) describes a route available within this trip. This displayed route is via the ride-sharing transit mode, in this case using the application provider ride-sharing TNC service, with the destination stop for this user/rider listed, along with the route cost and route time duration. The user/rider may choose to select this route, and thus request the service of this ride-sharing transportation. Component 13.6, totals describes the total parameters for the trip configured by the user/rider of the MaaS ride sharing application, depending on the current state of selected routes and those routes’ respective live timings. These parameters may include, but are not limited to, trip time duration, trip cost, rider quantity on this ride-sharing ride, and trip distance.

[0074] In the example of FIG. 18, the rider/user has already configured and requested a trip via the previous screen, trip planner launch screen (FIG. 17), and is now presented with the routes via all possible transit modes available to them. The rider/user may select from those routes which have multiple transit modes available, such as the first trip segment, which has a ride-sharing and a public bus route available.

[0075] The first section from the top allows users/riders to set an origin (e.g., Los Altos, CA here) and leaving time (e.g., 11:00 AM, here), or starting point, and a final destination (e.g., Los Angeles, CA here), or ending point, for their trip.

[0076] The second section from the top, with a defined leaving time of 11:02 AM and starting point marker shown (Component 13.1), displays all trip segments with all available route options shown. To begin their trip, the rider/user is directed to walk for 10 minutes. The first trip segment, leaving from the rider/user configured origin point and arriving at a transit hub is named by its destination, San Jose Downtown (component 13.2). This trip segment is via the ride sharing transit mode, which is the implicit service offered by the TNC operating this MaaS ride- sharing application (11.1).

[0077] The first trip segment is also serviced by a different transit mode (city bus), as denoted by the “or” option (13.3). This route is named after the city bus line title, Stanford to San Jose Line, with the destination stop for this rider/user given below. The rider/user may choose either of these routes/transit modes to serve as constituents for their trip, based on the given leave time and cost parameters, and the general logistics of these modes. [0078] The user is then directed to walk for 8 minutes, after which they are presented with a singular option for completion of their configured trip. This route is via the ride sharing transit mode, and is named after the route origin and destination. The rider/user does not have any choice in the routes/transit modes serving as their trip for this trip segment.

[0079] The bottommost section shows the totals (13.6) for this trip, as they are based on whichever routes the user selects.

[0080] FIG. 19 depicts an example mobile software application for a MaaS ride sharing service (11.1) showing the initial configuration screen for a commute route, in which a user/rider can plan a commonly taken and often repeated trip, either via configuration of origin and destination information, or selection of a commonly or historically taken route. FIG. 19 includes the following components. Component 14.1, transit types shown provides a link for users/riders to a more detailed screen providing choices for transportation modes shown (“Transit Types Shown” (15.6, 16.1) in FIGs. 20 and 21 (Commuter Transit Type Selection Screens)). Component 14.2, your stop describes the user input field enabling the user/rider to search for and define the starting point of a route, as well as the starting time for that route. Component 14.3, Where To? describes the user input field enabling the user/rider to search for and define the destination point for a route. Component 14.4, $ (dollar sign) describes the least expensive route cost for the user/rider preferred destination - in this context, that destination is “Workplace”. Component 14.5, route (Workplace, Ride Sharing) describes a route of interest available to the user/rider. This displayed route is via the ride sharing transit mode, in this case using the application provider ride-sharing TNC service, with the destination stop for this user/rider listed, along with the route cost and route time duration. The user/rider may choose to select this route, and thus request the service of this ride-sharing transportation. Component 14.6, favorite (star symbol) describes an often taken, configured, or requested route by this user/rider. The user/rider in question may simply often interact with this route, or may manually add this to a listing of favorite routes. Component 14.7, route (Workplace, Bus + Bike Share) describes a route of interest available to the user/rider. This displayed route is via public transportation systems, in this case using the city bus and bike share, with the destination stop for this user/rider listed, along with the route cost and route time duration. The user/rider may choose to select this route, and thus be redirected to (or do so within the platform) purchase tickets for the various operators within this public transit route. Component 14.8, route (Workplace, Bus + Subway) describes a route of interest available to the user/rider. This displayed route is via public transportation systems, in this case using the city bus and city subway, with the destination stop for this user/rider listed, along with the route cost and route time duration. The user/rider may choose to select this route, and thus be redirected to (or do so within the platform) purchase tickets for the various operators within this public transit route. Component 14.9, quickest (time symbol) describes the most direct (least time duration) route for the user/rider preferred destination, in this context, that destination is “Workplace”. Component 14.10, route (university campus, private taxi) describes a route of interest available to the user/rider. This displayed route is via a private taxi, meaning a traditional car-for-hire taxi service. The destination for this user/rider is listed, along with the route cost and route time duration. The user/rider may choose to select this route, and thus be redirected to (or do so within the platform) book a taxi ride.

[0081] The first section, with the screen title “Available Routes”, 14.1, from the top includes an option for the rider/user to be served routes with different transit modes, besides the default ride sharing mode (the service offered by the TNC application/service operator). The next section allows the rider/user to configure their origin and leave time (14.2), as well as destination (14.3). Following are four tiles representing the commute routes, with differing transit modes, served to this rider/user. The routes 14.5, 14.7 and 14.8 service the typical destination of “Workplace”, but each with differing transit modes; Component 14.5 is via the implicit ride sharing mode, component 14.7 is via a combination of two routes with two different transit modes - city bus and bike share, and component 14.8 is also via a similar combination - but via transit modes city bus line and a city subway line. These four route tiles are served to the rider/user for reasons of economic efficiency (pricing) (14.4), common use (favorite) (14.6), and time efficiency (14.9).

[0082] FIG. 20 depicts an example mobile software application for a MaaS ride sharing service (11.1) showing the options for a rider/user to be served routes with different transit modes besides the default ride sharing mode. This option is referenced previously in Component 14.1, within FIG. 19. FIG. 20 includes the following components. Component 15.1, transit types shown describes a mobile application menu providing choices for transportation modes shown for routes comprising trips configured by and/or requested by the user/rider. In this case, none of those transportation modes available via this MaaS ride sharing application (11.1) are selected, thus, the only transportation mode available for routes shown is ride-sharing (the TNC ride-sharing service implicit via the application). Component 15.2, route (Workplace) describes a route of interest available to the user/rider. This displayed route is via the default transit mode, in this case using the application provider ride sharing TNC service, with the destination address for this user/rider listed. The user/rider may choose to select this route, and thus request the service of this ride-sharing transportation. Component 15.3, transit type (ride-share) describes the transportation mode for this route provided by the MaaS ride-sharing application (11.1) to the user/rider.

[0083] The first section, showing option buttons for transit types to be shown (15.1), will provide options based on this user’s location, linked transit memberships, and/or preferences. The rider/user may select whichever transit modes they would like to see when requesting routes via the MaaS ride-sharing service (al.l), and those modes will show as available routes when able. Given, in this example, there are no transit modes selected, all routes served by the system/application are using the default implicit ride-sharing mode. Commute routes such as “Workplace” (15.2) can be seen as being of the implicit type ride share (15.3).

[0084] FIG. 21 depicts an example mobile software application for a MaaS ride sharing service (11.1) showing the options for a sider/user to be served routes with different transit modes besides the default ride sharing mode. In this case, all transit modes are selected. FIG. 21 includes the following components. Component 16.1, transit types shown describes a mobile application menu providing choices for transportation modes shown for routes comprising trips configured by and/or requested by the user/rider. In this case, all transportation modes available via this MaaS ride-sharing application (11.1) are selected, thus, the transportation modes available in this example are (respectively); city bus, subway, taxi, corporate transit, and ride-sharing (the TNC ride-sharing service implicit via this Application). Component 16.2, route (e.g., Workplace) describes a route of interest available to the user/rider. This displayed route is via the ride-sharing transit mode, in this case using the application provider ride-sharing TNC service, with the destination stop for this user/rider listed, along with the route cost and route time duration. The user/rider may choose to select this route, and thus request the service of this ride-sharing transportation. Component 16.3, route (e.g., Partner Office, City Bus + Corporate Bus) describes a route of interest available to the user/rider. This displayed route is a hybrid of two routes, one via public transportation systems and one via private transportation systems, in this case using the #40 city bus and corporate shuttle (bus), with the destination stop for this user/rider listed, along with the route cost and route time duration. The user/rider may choose to select this route, and thus be redirected to (or do so within the platform) purchase tickets for the various operators within this public transit route, and any application or web address used for scheduling or confirming corporate trips. Component 16.4, route (e.g., Partner Office, City Bus + Subway) describes a route of interest available to the user/rider. This displayed route is a hybrid of two routes, both via public transportation systems, in this case using the #40 city bus and subway, with the destination stop for this user/rider listed, along with the route cost and route time duration. The user/rider may choose to select this route, and thus be redirected to (or do so within the platform) purchase tickets for the various operators within this public transit route. Component 16.5, route (e.g., Workplace, Private Taxi) describes a route of interest available to the user/rider. This displayed route is via a private taxi, meaning a traditional car-for-hire taxi service. The destination for this user/rider is listed, along with the route cost and route time duration. The user/rider may choose to select this route, and thus be redirected to (or do so within the platform) book a taxi ride.

[0085] The first section, showing option buttons for transit types to be shown (16.1), is now entirely selected, meaning ah transit types available to the rider/user will be served. Those different transit modes selected to be served can be seen in the following routes available to the user. The first route, going to “Workplace” (16.2), is via the ride sharing mode. The second route, going to ’’Partner Office” (16.3), is via two Transit Modes of two different types; city bus route #40 of type public transit, and corporate shuttle of type corporate transit (private transit). The third route, also going to “Partner Office” (16.4), is via two transit modes within the same type; city bus route #40 and city subway line E, both of type public transit. The fourth route, going to “Workplace” (16.5), is via a private taxi (private transit).

[0086] FIG. 22 depicts an example mobile software application for a MaaS ride sharing service (11.1) showing the initial configuration screen for a driver of the ride-sharing service, in which a driver/commuter can plan to service a commonly taken and often repeated trip (a commute route), either via the “Favorite Routes” displayed on the bottom portion of the screen, or the routes shown on the interactive map on the top portion of the screen. The driver may also choose to scroll down, in which case they will be able to configure a customized route, as shown in FIG. 23. FIG. 22 includes the following components. Component 17.1, ride-sharing driver interactive map is a scrolling, typically but not necessarily location dependent, (GPS) map showing the driver using the application available routes, stops, transit centers, and user/riders in the vicinity. Component 17.2, start route, is a button available to the driver using the application, by which they may choose to begin a route which has either been configured or selected. Component 17.3, route (e.g., Your Stop to Workplace) describes a route of interest available for the driver to service. This is using the application provider ride-sharing TNC service, with the destination stop for this driver and the user/rider listed, along with the route earn and route time duration. The driver may choose to select this route, and thus begin the routing and servicing of this route within the MaaS ride-sharing application (11.1).

[0087] The top portion of the screen of FIG. 22 shows an interactive map (17.1), overlaid with all routes available in the displayed area which the driver/user can service. The driver may also see from the interactive map representations of pending passengers (in this example; small people, color-coded to their respective routes), representations of stops on these routes (in this example; two map pins and a building), and transit hubs (in this example; a subway train).

[0088] The bottom portion of the screen shows the most commonly serviced commute routes which this driver selects, each of these routes (17.3) presents to the driver some key information for making a decision on which route to take, if any of these immediately served are taken (route origin and destination, earnings from this route, and passengers on this route).

[0089] In the center of the screen is a large button allowing the driver to begin their selected route (17.2), be that route selected from the interactive map or from the favorites list.

[0090] FIG. 23 depicts an example mobile software application for a MaaS ride sharing service (11.1) showing the custom configuration screen for a driver of the ride sharing service, in which a driver can configure a route to service according to their own origin and destination, and receive detailed information on rider/user activity at local transit hubs and nearby points of interest. The driver may also choose from served commuter routes (“favorite routes”), as shown in FIG. 23. FIG. 23 includes the following components. Component 18.1, transit view provides a toggle option for drivers/users to have visibility and configuration capability into public transportation routes, for the purpose of servicing routes for users/riders which interact with public transportation routes. Component 18.2, route (e.g., Your Stop to Workplace) describes a route of interest available for the driver to service. This is using the application provider ride-sharing TNC service, with the destination stop for this driver and the user/rider listed, along with the route earn and route time duration. The driver may choose to select this route, and thus begin the routing and servicing of this route within the MaaS ride-sharing application (11.1). Component 18.3, origin + final destination (route configuration) describes the route configuration options for the driver/user of the application, specifically, options for the starting point and final destination point of the route. Component 18.4, stops on route is a list presented to the driver/user of all stops on the route which is being (has been) created. Component 18.5, next arrivals, is a list presented to the driver/user of upcoming public transportation route arrivals at the transit center stops, and the quantity of users/riders due to arrive. Component 18.6, POI’s (points of interest) describes additionally suggested stops of interests to the driver/user.

[0091] In FIG. 23, the top portion of the screen shows “Favorite Routes” (18.2), just as in FIG. 22, but with the addition of a transit mode visibility button (18.1) allowing the driver to service public transit networks or not. At the screen center is a section titled “Custom Route”, allowing the driver to configure an origin and first stop (or destination) (18.3). On the bottom portion of screen, data is displayed pertaining to possible stops on the route being configured by the driver (18.4). In the first box, data about local (geographically in proximity, or parts of routes shown on interactive map) transit hubs (18.5) - including when passengers (riders/users) are due to be requesting ride-sharing service from these hubs. In the second box, local points of interest are displayed, for purposes of the driver servicing passengers (riders/users).

[0092] Embodiments provide several advantages. Groups can easily organize ride services. For example, a community or neighborhood could easily set up routes and stops relevant to their location and to support transportation between areas, such as a community center and a public transit station (subway, etc.). Corporations would also benefit from providing ride services for employees to share rides, with a stop assigned to a company’s park space. The ride services system may be used to provide transportation solutions to crowded concerts, sports, festivals, shows, etc. The ride services system may be used to provide alternatives to school buses, which may provide limited services from public budget. Several other applications exist, such as airport, tourist, senior citizen and patients, etc.

[0093] As described above, the exemplary embodiments can be in the form of processor-implemented processes and devices for practicing those processes. The ride services server 12 executes computer programs to implement the functions described herein. Also, the rider devices 22 and driver devices 32 execute computer programs to implement the functions described herein. Exemplary embodiments may be in the form of computer program code containing instructions embodied in tangible media, such as floppy diskettes, CD ROMs, hard drives, or any other computer-readable storage medium, wherein, when the computer program code is loaded into and executed by a computer, the computer becomes a device for practicing the exemplary embodiments. The exemplary embodiments can also be in the form of computer program code, for example, whether stored in a storage medium, loaded into and/or executed by a computer, or transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, or via electromagnetic radiation, wherein, when the computer program code is loaded into an executed by a computer, the computer becomes an device for practicing the exemplary embodiments. When implemented on a general-purpose microprocessor, the computer program code segments configure the microprocessor to create specific logic circuits.

[0094] While the invention has been described with reference to example embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted for elements thereof without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular situation or material to the teachings of the invention without departing from the essential scope thereof. Therefore, it is intended that the invention not be limited to the particular embodiments disclosed for carrying out this invention, but that the invention will include all embodiments falling within the scope of the claims. Moreover, the use of the terms first, second, etc., do not denote any order or importance, but rather the terms first, second, etc., are used to distinguish one element from another. Furthermore, the use of the terms a, an, etc., do not denote a limitation of quantity, but rather denote the presence of at least one of the referenced item.

Claims

WHAT IS CLAIMED IS:

1. A method for managing vehicles using a communications network, the method comprising: designating a plurality of routes, each route including a plurality of stops; determining that a rider is at one of the plurality of stops associated with one of the plurality of routes; receiving a ride request along the one of the plurality of routes from the rider; selecting at least one driver to fulfil the ride request; messaging the at least one driver to fulfil of the ride request; receiving agreement from the at least one driver to fulfil of the ride request.

2. The method of claim 1 further comprising: monitoring traffic along the routes; updating at least one of the plurality of routes and the plurality of stops in response to the traffic.

3. The method of claim 1 wherein determining that the rider is at one of the plurality of stops comprises detecting a location of a rider device proximate to the one of the plurality of stops.

4. The method of claim 1 wherein receiving the ride request includes receiving a message from the rider.

5. The method of claim 4 wherein the ride request includes at least one ride parameter.

6. The method of claim 5 wherein the ride parameter includes a number of passengers and a destination stop.

7. The method of claim 5 wherein selecting the at least one driver to fulfil the ride request includes determining a match between the at least one driver and the at least one ride parameter.

8. The method of claim 1 wherein selecting the at least one driver to fulfil the ride request includes selecting N drivers.

9. The method of claim 1 further comprising providing for an institution to subsidize a portion of costs associated with the ride request.

10. The method of claim 1 wherein the ride request is part of a travel plan including at least municipal transit.

11. A computer program product, the computer program product including a storage medium readable by a processing circuit and storing instructions for execution by the processing circuit for facilitating operations of any one of claims 1-10.

12. A system comprising: memory comprising computer-executable instructions; and a processor executing the computer-executable instructions, the computer-executable instructions, when executed by the processor, cause the processor to perform operations of any one of claims 1-10.