System, method and computer program product providing Intelligent Transportation Services

REFERENCE TO CO-PENDING APPLICATIONS

Priority is claimed from United States Provisional Patent Application No. 62/745,345 entitled SYSTEM AND METHODS FOR ADAPTIVE USER LOCATIONS POSITIONING AT INTELLIGENT TRANSPORTATION SERVICES

filed in the U.S., on October 13, 2018, the disclosure of which application is hereby incorporated by reference.

FIELD OF THE INVENTION

This invention relates to computerized control of transportation services.

BACKGROUND OF THE INVENTIO

Current transportation services include public transportation (such as buses and taxis) and also private transportation services such as those presented by Uber, Lyft, Gett, Via and similar. Those services include ride-hading, ride sharing and similar types of mobility services. In those systems the riser typically enters a request for a service which includes his/her pickup (PU) and drop-off (DO) locations. As a response, those systems propose one or more alternatives for the needed mobility sendee (a proposal alternative may include for example private ride and/or ride -sharing). The proposals include, typically, the estimated time of pickup, and sometimes the estimated time of drop-off, assuming the given PU/DO locations. Those locations may be inserted by entering an address, or by clicking on a map. The given locations may display more available options for a service proposal that may be more suitable for the user/customers. For example, the user may be willing to walk a litle if he/she will get cheaper price, shorter ETP/ETA, better vehicle class, or any social preference regarding the allocated vehicle additional passengers (e.g. if the additional passenger occupying the same vehicle are fans of the same sport team/are in the same age group/like the same music type, etc.).

Quality-of-Service (QoS) is a well-known term in the telecommunication sen-ices arena, and there are many management methods for QoS parameters in communications services.

Computation of probabilities for posterior and prior models, is known, e.g. any of those described or referenced in the following http links: http://www. math. n;g.nl/siat/modeis/files/meen. pdf and

htps://academic.oup.com/bioxnet/article- nbstraei/89/3/491 /251692?redirectedFrom = ^: P¾F

The disclosure of which is hereby incorporated by reference.

SUMMARY

Abbreviations:

MaaS - Mobility as a Service

QoS - Quality of Service

• QMS --- QoS-driven MaaS System

• ETA - Estimated Time of Arrival (to a destination, .e.g. drop-off of passenger) ETP - Estimated Time of Pick-up

AV - Autonomous vehicle

• SLA - Service Level Agreement

Certain embodiments seek to provide improved planning and operation of adaptive and dynamic allocation and routing of vehicles in Intelligent Transportation systems.

Certain embodiments seek to provide adaptive user location positioning.

Certain embodiments seek to provide a system and methods used to prepare more adaptive, diverse and personal mobility sendee proposals in which some of the request parameters may be altered (with regard to those entered initially by die user/passenger).

Although some Quality of Service (QoS) parameters are presented to the customer, in known systems, no real management of those QoS parameters for the ride requests is done. Typically, these existing service plans are fixed during the service period, meaning that when a service plan proposed by the Transportation Service Operator (TSO) is accepted by the user/customer/passenger (typically without QoS management as mentioned above), then it is fixed - no other alternative (update of the SLA) is presented to the passenger during the ride, and no request to change the ride parameters is available to the passenger (except sometimes changing the destination location). Moreover, the existing route planning systems are single -vehicle oriented and have no ability to perform planning of a group/fleet of vehicles servicing a group of passengers. This sub-optimal planning procedure may result in sub-optimal resource utilization and therefore higher cost and low user experience than what is achievable.

In communication systems QoS parameters include for example the bit-rate (maximal/average/minimal), the time delay (maximal/average), the delay jitter, the error rate (bit-error-rate/packet-error-rate), etc. Each sendee type has its own parameters that are important to the service user, and in mobility/transportation use- cases there is no comprehensive and standard QoS definitions and no real QoS management in the art so far.

Certain embodiments seek to provide a MaaS system that may define and manage the QoS of each ride request, may allow dynamic ride request service parameters also during the service period, and be able to perform this capability in a fleet-level scale, considering concurrently all fleet assets and all ride requests while learning and considering the environment traffic state/model (current and predicted).

BRIEF DESCRI PTION

In order to understand the invention and to see how it may be carried out in practice, embodiments will now be described, by way of non -limi ting exam ple only, with reference to the accompanying drawings, in which:

Fig, la illustrates schematically the block diagram of the QoS-Driven MaaS System (QMS) architecture for a Human dri ver case:

Fig. lb illustrates schematically the block diagram of the QoS-Driven MaaS System architecture for an Autonomous driver case;

Fig. 2a illustrates schematically example of the QMS Core (QMSC) functional block diagram of Adaptive Smart Transportation for a Human driver case:

Fig. 2b illustrates schematically example of the QMSC functional block diagram of Adaptive Smart Transportation for an Autonomous driver case; Fig. 2c illustrates schematically an additional example of the QMSC functional block diagram of the Adaptive Smart Transportation;

Fig. 3 illustrates schematically example of the QMSC Sendee Manager Functional Block Diagram;

Fig. 4 illustrates schematically example of the Proposals Generator (part of the QMSC Service Manager) Functional Block Diagram;

Fig. 5a presents an example of a method of operation, aka main process of the QoS-driven MaaS System;

Fig. 5b presents example of a method of operation, aka the main process of the internal bidding system;

Fig. 6 presents an example of a flow diagram for an intra-vehicle (level- 1) user- triggered bidding process;

Fig. 7 presents an example of a flow diagram for an intra-vehicle (level- 1) operator-triggered bidding process;

Fig. 8 presents an example of a flow diagram for a multi-vehicle fleet level (level-2) user-triggered bidding process;

Fig. 9 presents an example of a flow diagram for a multi-vehicle fleet level (level-2) operator-triggered bidding process;

Fig. 19a presents an example of an on-board passenger proposals page during an internal bidding session (for level 1+2 bidding);

Fig. 10b presents an example of an on-board passenger proposals page during an internal bidding session (for level 1 bidding only);

Fig. 10c presents an example of a committed passenger proposals page during an internal bidding session (for level 1+2 bidding);

Fig. 1 Od presents an example of a potential passenger proposals page during an internal bidding session;

Fig. lOe presents an example of a flow diagram of a potential passenger proposals page during an internal bidding session (when a passenger does not choose a proposal);

Fig. lla-llc presents examples of a potential passenger preference questionnaire page;

Fig. 12 presents an example of a committed passenger monitoring page before and during his/her pickup;

Fig. 13 presents an example of a driver page before and during a pickup; Fig. 14 presents an example of a proposals preparation process;

Fig. 15 presents an additional example of a proposals preparation process;

Fig. 16 presents an example of a modified proposals computation process;

Fig. 17-18 presents additional examples of a passenger preference questionnaire page;

Fig. 19 presents an example of computations and functions executed by the

Fig. 20a, 20b, 20c, 20d present examples of a passenger page during pickup location selection by map pressing and followed by an optional street view selection process;

Fig. 21a, 21b present examples of a passenger page during pickup location address insertion:

Fig. 22a, 22b present examples of passenger page during dropoff location selection by map pressing;

Fig. 23a, 23b present examples of passenger page during dropoff location address insertion;

Fig. 24 presents an example of passenger page presenting nominal proposal (route and QoS parameters configuration (QPC)) for original given locations;

the QoS parameters configuration may for example be as descriebd herein with reference to all or any subset of figs 1 la, 1 lb, 1 lc , 17,18,19 QoS parameters configuration may be a specific setting of the QoS parameters set in Fig 19 e as define in 1920.

Fig. 25 presents an example of a passenger page presenting modified locations proposal (route and QoS parameters configuration (QPC)) for Minimum ETA goal/criteria;

Fig. 26 presents an example of passenger page presenting modified locations proposal (route and QoS parameters configuration (QPC)) for Minimum Price goal/criteria;

Fig. 27a,27b27c,27d present examples of a passenger page presenting several modified locations proposals (locations and QoS parameters configuration (QPC)) and followed by an optional street view selection process;

Fig. 28a, 28b present examples of a passenger page during selection of optional pickup location e.g. by pressing on the map and presentation of a derived proposal; Fig. 29a,29bl,29el,29c2 present examples of a passenger page during selection of optional QoS parameter (Min. ETA) e.g. by pressing, presentation of derived results, and further selecting the desired alternative; and

Fig. 30a,30bl,30cl,30c2 present additional examples of a passenger page during selection of optional QoS parameter (Min. Price) e.g. by pressing, presentation of derived results and further selecting the desired alternative.

Methods and systems included in the scope of the present invention may include some (e.g. any suitable subset) or ail of the functional blocks shown in the specifically illustrated implementations by way of example, in any suitable order e.g. as shown.

Any hardware component mentioned herein may in fact include either one or more hardware devices e.g. chips, which may be co-located or remote from one another.

It is appreciated that terminology such as "mandatory", "required", "need" and "must" refer to implementation choices made within the context of a particular implementation or application described herewithin for clarity and are not intended to be limiting since in an alternative implantation, the same elements might be defined as not mandatory' and not required or might even be eliminated altogether.

Features of the present invention, including operations, which are described in the context of separate embodiments may also be provided in combination in a single embodiment. For example, a system embodiment is intended to include a corresponding process embodiment and vice versa. Features may also he combined with features known in the art and particularly although not limited to those described in the Background section or in publications mentioned therein.

Conversely, features of the invention, including operations, which are described for brevity in the context of a single embodiment or in a certain order may be provided separately or in any suitable subcombination, including with features known in the art (particularly although not limited to those described in the Background section or in publications mentioned therein) or in a different order "e.g." is used herein in the sense of a specific example which is not intended to be limiting. Each method may comprise some or ail of the operations illustrated or described, suitably ordered e.g. as illustrated or described herein.

It is appreciated that in the description and drawings shown and described herein, functionalities described or illustrated as systems and sub-units thereof can also be provided as methods and operations therewithm, and functionalities described or illustrated as methods and operations therewithin can also be provided as systems and sub-units thereof. The scale used to illustrate various elements in the drawings is merely exemplary' and/or appropriate for clarity of presentation and is not intended to be limiting.

DETAILED DESCRIPTION OF EMBODIMENTS

In the drawings and descriptions set forth, identical reference numerals indicate those components that are common to different embodiments or configurations.

It is appreciated that any features, properties , logic, modules, blocks, operations or functionalities described herein which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment except where the specification or the general knowledge specifically indicates that certain teachings are mutually contradictory _' and cannot be combined.

Conversely, any modules, blocks, operations or functionalities described herein, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub -combination.

Note that the description below refers to devices. Typical, yet not exclusive, examples of devices are mentioned above and may also include laptop, router, switch, smartphone, mobile telephone, laptop dongle facilitating access of laptop to cellular network, laptop connectible to cellular networks and/ or any device that may form part of a cellular or terrestrial network (such as the Internet or other private network).

The description below is provided with reference to a passengers ride service, for simplicity however the invention is by no means bound to this use-case and any other transportation and/or mobility sendee use case may also apply to this invention, such as parcels delivery, last-mile delivery', delivery- by air-bome platforms (such as drones), ride-sharing, ride-hailing, food and/or goods delivery, technicians dispatch, schools pupils/students transportation, work -place transportation, public transportation, etc. The following embodiments may apply mutatis mutandis to any transportation/mobility sendees and not only passengers rides, as many of them share many common features. For example, items delivery' use case also may also have all or any subset of those common features such as pick-up and drop-off locations, time constraints/windows for ETP/ETA, vehicle capacity management, or any other QoS parameter. Therefore the proposed QoS-driven MaaS may apply to any mobility/transportation sendee use-case. Figure 1 is an illustration of an example of the QoS-driven MaaS System (QMS) high level block diagram and interfaces. The entities in the scenario may include all or any subset of the following;

Passengers [22], [23], [24] that may carry' a mobile device [20] . The passengers may be divided into all or any subset of the following three types:

o On-board [22] - passengers that already have been picked up and are therefore on-board the vehicles.

o Committed [23] - passengers that will be served by the QMS but have not been picked up yet. The QMS provided proposals and those passengers have accepted the proposals during the validity period of the proposal. They are planned to be picked up by a vehicle of the operator fleet.

o Potential [24] - Passengers that ask for a mobility (e.g. transportation) service but have not been yet got approval/assignment for a service of the QMS.

Each passenger may carry a mobile device. Mobile device examples may be a smartphone, tablet, laptop, phablet, or any electrical mobile device. The QMS may have a module as a part of the passenger mobile device [20] - the Passengers MaaS Module (PMM) [200] which rs typically installed or part of the software and/or hardware of the passengers’ mobile device. The PMM [200] may be for example an application in the mobile device [20] or a web page presented at the mobile device [20] or any other software in the mobile device [20] Several examples for a PMM [200] pages/screens will be given hereunder. The PMM [200] typically comprises an interface between the passengers and other parts of the QMS (e.g. the QMS Core [100]), and may include several functionalities such as presentation of proposals, preparing and sending requests for a mobility sen/ice, definition of service parameters (e.g. QoS parameters) and their importance/prioritization/preference to the passengers, presenting information regarding the vehicle and/or drivers that will serve him/her, requests for a change in the committed service (e.g. changing all or any subset of the QoS parameters of the agreed Service-Level Agreement (SLA), etc). QoS parameters may include all or any subset of the following parameters:

o Minimal/A verage/Maximal ETP

o Minimal/A verage/Maximal ETA

o Minimal/ Average/Maximal duration of the ride o Service (ride) price

o Smoothness/softness of the ride (if the ride is comfortable, there is no major acceleration, or if the road has many pothole, bumps or is a rough road)

o Number of additional passengers in the same car

o Smoking or non-smoking vehicle/ride

An additional QoS parameter (that may be part of the QoS parameters configuration) may be the possibility to direct tire user to arrive to a close-by (near) location with regard to the pickup and/or drop-off locations (this additional QoS parameters is also tenned“Short walking distance” herein ). If this additional QoS parameter (“Short walking distance”) is used and enabled at a certain sendee plan, optionally walking directions to the pickup/drop-off station are also pro vided to the user when necessary'. Several examples for a page/screen of the PMM will he presented hereunder.

Vehicles [30], [32] of the MaaS operator and their Drivers [31 j. The QMS may have one or more allocated vehicles concurrently. The drivers [31] may also have a mobile device [33] (similar to the above description regarding the passengers’ mobile device, their types, etc.). As part of the driver mobile device [33] there may be also a Driver Management Module (DMM) [300] that is typically the interface of the QMS to the drivers [31] Examples for Driver management actions that are done using the DMM [300] may be all or any subset of the following:

(1) Tire Driver [31] may notify the QMSC [100] that a passenger has been picked up

(2) The Driver [31 ] may notify the QMSC [ 100] that the vehicle has arrived to a destination/location

(3) The QMSC [100] may send to the Driver [31] the near-term route and/or navigation guidance commands

(4) The QMSC [100] may send to the Driver [31] information regarding the next (one or many) pick-up destination/s. The information may include for example all or any subset of the following: identity or any relevant information of the next passenger that needs to be picked-up (e.g. how to identify him/her), his/her contact details such as phone number, the ETP for next destination, the ETA for next destination, etc. The vehicles [32] may optionally have also a module of the QMS --- the Vehicle Management Module (VMM) [310] . The VMM [310] typically comprises the interface between the vehicles [32] and the QMS Core (QMSC) [100] Using this interface, for example, vehicle measurements, such as vehicle location, speed, fuel status, maintenance issues, and any vehicle data or measurement available from the vehicle sub-systems may he sent to the QMSC [100]

QMS Core [100] - is the processing block of the QMS. It is typically configured for collection, processing and analysis of the data from the passengers (such as ride requests), generation of MaaS ride proposals that are sent to the relevant passengers, drivers [31] management, management of QoS of the served passengers, etc (e.g as per any of the embodiments described and illustrated herein). The QMSC [100] may be deployed at computing facilities on premise or more typically at cloud computing infrastructure [11] such as cloud based servers.

Operation manager block [70] - is the operation and management interface to the QMS system. It typically interfaces the QMSC [100] because most of the data is stored and accessed by this block. The Operation manager block may be used to configure system parameters and to monitor system status and performance.

External data sources [60] - The QMSC may also be connected to various external data sources to get access to data that may improve the system performance. Example of such external data sources may be weather status and forecasting systems (that may provide weather conditions that may help to provide better traffic condition estimation). An additional example may be any road traffic congestion data source, such as road speed sensors, road cameras, etc. The external data sources may be used optionally for gathering external observations that may be optionally used by the QMSC to improve the models (e.g. the posterior models) and accuracy of future predictions. A wide variety of sources such as cellular network data, open public transportation data, weather measurements and forecast, traffic lights data, location of mobile devices (e.g. based on GNSS/GPS/Galileo/Glonass), mobile applications data and etc., may ^¬ be used. Fig. lb illustrates another system architecture alternative for the QMS whereas the vehicles are autonomous (autonomous driver). Many high-level system blocks are similar to those presented for the human driver case (e.g. Fig. la), however the drivers and sometimes vehicle management modules typically differ relative to the human driver case. Because there is no human driver, there is a block that replaces the drivers functionalities - the Autonomous Driver Module (ADM) [400] it may comprise software and/or hardware parts. The ADM [400] may replace functionalities such as navigation of the vehicle along its route, passengers’ management functionality, etc. Examples for passengers’ management actions may be all or any subset of the following:

(5) the ADM may notify the QMSC [100] that a passenger has been picked up

(6) the ADM may notify the QMSC [100] that the vehicle has arrived to a destination/location

(7) the QMSC [100] may send to the ADM [400] the near-term route and/or navigation guidance commands

(8) the QMSC [100] may send to the ADM [400] information regarding the next (one or many) pick-up destinations. The information may include for example all or any subset of the following: identity or any relevant information of the next passenger that needs to be picked-up (e.g. how to identify him/her), his/her contact details such as phone number, the ETP for next destination, the ETA for next destination, etc.

Fig. 2a illustrates some additional embodiments of the present invention. In Fig. 2a example of functional block diagram of the QMSC [100] is given accompanied by some relevant typical interfaces. The QMSC [ 100] may include all or any subset of the following components:

• Service Manager [110] which is typically configured to perform QoS management of the QMS . Some of its typical roles may include all or any subset of the following:

o Service proposals preparation/generation

o Proposals responses analysis and assignment (of SLAs)

o Assignments/commitments

o QoS monitoring and management World Modeler [120] which is typically configured for modeling the real world. It [120] has several sub-blocks e.g. as described below with reference to Fig. 2c. The world modeler [120] is typically configured to do all or any subset of the following:

o Learning the model, functionality and behavior of the real-world components

o Importing from the external interface e.g. by tire operation manager [70] part of, or all of, the world model

o Implementing the model/s

o Operating the model to do analysis of some past or real-time input data o Operating the model to do predictions used for planning

• Routing Engine [130] which is a QMS component configured for routing computations. For example, as part of its computations, it computes shortest or fastest route between two locations (e.g. in the roads network), and, using the derived route, it may compute and present the navigation guidance command in each junction or intersection (e.g. which turn to take, which exit in the road circle to take, etc.). Alternatively, the routing engine may take any given metric/parameter or weighted combination of metrics/parameters of the road network elements such as nodes or edges/segments (e.g. road network edges) and compute the total utility function of each route alternative. Those route alternatives are important and are used in order to present the user several ride proposals (e.g. each with its own QoS/SLA) or to find a route that achieves a desired goal (e.g. in multi-parameter optimization, a desired goal may he for example one or combination of the QoS parameters such as minimum ETA, minimum ETP, minimum ride duration, minimum additional passengers in the vehicle. The optimization, for example minimum or maximum, is typically relative to the set of all possible proposals the system can give [e.g. over all dispatching and routing alternatives using all fleet vehicles] typically (e.g. as a constraint) while keeping the service level / QoS of all already served passengers). For example, a price computation function may be displayed that considers the predicted operational expenses (OPEX), the desired profit and the QoS parameters for each ride proposal (the user experience). The OPEX may be multi-parameter function, and the parameters may include for example (for a segment/route) all or any subset of: the (estimated) driving time (T), its length (L), its smoothness (if it has bumps or is not a flat road), its inclination (the road inclination angle may affect the fuel consumption), any maintenance affecting parameters, etc.

· Passengers’ F ront-End (PFE) [ 140] which typically provides the interface to the passengers its functional blocks may include all or any subset of the following: o Passengers Proposals Distributor [141] which gets proposals from the Service Manager [110] and sends the proposals to each of the rele vant passengers. Optionally it needs to assure the proposals have reached their destinations - the PMMs [200], by getting an acknowledge message from the PMM [200] or any other known method for messages transmission assurance. It may also have a scheme for timing (or synchronization) of the transmissions of the proposals to the passengers. An example of transmission timing scheme may be to send proposals only on synchronized time samples (e.g. collecting proposals during a time window and sending all the collected time proposals concurrently at the time samples. Those synchronized time samples may be predetermined or dynamically determined as a function of on-line system parameters values. Alternatively, those synchronized time samples may be periodic or non-periodic. Optionally, only som e of the proposals may be transmitted at a synchronized time sample, whereas the rest are not. Any combination of the latter options also may be valid for the system.

o Passengers Data Collector [142] which collects the data that is transmitted from the passengers (by using the PMM [200]) to the QMS.

There are typically several types of data that may sent from the PMM [200] (all or any subset of the below):

* Proposal responses. Example of such responses may be, for example:

· approval of a proposal or list of proposals

rejection of a proposal or list of proposals remark regarding a proposal (for example, if a passenger is very pleased/dissatisfied with a proposal he/she may send a remark regarding that)

^■ Passengers’ requests for a ride. Typically, such requests include pickup location and drop-off location it may also include other parameters, e.g. any other QoS parameter as described above.

* Passenger feedback regarding the service or any other issue.

^■ Passenger information. An example of such information may be any data that the passenger allows to send (e.g. personal data/information) from the passenger mobile device, e.g. all or any subset of the following.:

• Geo-location

• Surrounding temperature

• Acceleration

Passenger health data such as heart rate, blood pressure, body temperature, etc.

o Assignment Distributor [143] which is typically configured for distribution of assignments. Assignment is the message that acknowledges to the user/passenger that a service proposal (generated by either the QMSC or the passenger) that has been accepted by the user/passenger and the response was sent back to the QMSC, and has been approved by the QMSC and all system resources (such as vehicles/drivers) have been assigned to it, and therefore it is valid. The assignment phase will be presented in some of the following figures. · Drivers Front-End (DFE) [150] which typically provides the interface to the

Drivers by us g the DMM [300] . Typical messages that are transmitted from DFE 1 150] to the DMM [300] may include ail or any subset of:

o Navigation commands, for example: what action to do in the next j unction/road intersection .

o Information regarding the served passengers. For example, what is the personal or any other relevant information regarding the passengers (name, phone number, identity signs, etc.), his/her/their pick-up location and/or time, his/her/their drop-off location and/or time. Typical messages that are transmitted from the DMM [300] to the DFE [150] may include all or any subset of:

o Pick-up of passenger/s acknowledgement

o Drop-off of passenger/s acknowledgement

o Passenger/s not found

o Any remark that the driver needs to update the QMSC (such as in -ability to continue the ride, problematic passenger, etc.).

Vehicles Front-End (VFE) [160] which typically provides the functionality of the interface to the vehicles by using the VMM [310] . Typical messages that are transmitted from VFE [160] to the VMM [310] may include for example requests for data (e.g. request for vehicle measurements/sensory data). Typical messages that are transmitted from the VMM [310] to the VFE [160] may include one or m ore of vehicle measurements or any vehicle sensors data. They may be sent periodically, statistically or as a result of an event (event triggered). Fig. 2b illustrates some additional embodiments of the present invention. In Fig.

2b an example of a functional block diagram of the QMSC [100] for Autonomous Driving is given accompanied by some relevant typical interfaces. Many high-level system blocks are similar to those presented for the human driver case (e.g. Fig. 2a), however the drivers and sometimes vehicles managements modules, differ typically, relative to the human driver case. Because there is no human driver, there is a block that replaces the drivers’ functionalities - the Autonomous Driver Module (ADM) [400] The ADM [400] functionality may be similar (may have some or all functionality) to the DMM [300] of Fig. 2a. It may comprise software and/or hardware parts. The ADM [400] may replace functionalities such as navigation of the vehicle along its route, passengers’ management functionality, etc.

Fig. 2c describes some additional embodiments of present invention. In Fig. 2c an additional example of functional block diagram of the QMSC [100] for Human driver is given accompanied by some relevant typical interfaces. In Fig. 2c the World Modeler [ 120] shown in Figures-2a typically comprises optional building blocks e.g. ail or any subset of the following:

Passengers (or users) Modeler [121 ] which includes the functionality of passengers modeling such as model learning, model simulation/emulation and model analysis. The Passenger model may include for example: o The passengers’ QoS parameters configuration preference generally (in average) and specific per ride configuration. An example for QoS parameters configuration preference may include the preferred price for each configuration of QoS proposal parameters, learned from past responses to proposals: and/or

o Passengers’ rides statistical data. This may include statistical parameters regarding frequency of pick-up and drop-off locations, dependence of pick-up and drop-off locations, dependence on other parameters such as day-of-week and time-of-day (what time it is during the day).

· Drivers Modeler which models the driver entity. It may include for example: o Drivers’ driving behavior, such as typical acceleration per road segment, state/configuration or driving behavior for various weather conditions, accuracy of following the driving commands, passengers’ feedback regarding driver hospitality, etc.; and/or

o It may analyze vehicle measurements from the VFE (e.g. [160] of Fig.

2a) and deduce the driver’s driving model.

Vehicle Modeler [123] which models the vehicle with regard to the traffic model. The Vehicle Model parameters may include for example the vehicle fuel consumption as a function of other parameters such as vehicle speed, road condition, weather conditions (e.g. temperature, wind speed, precipitation), the vehicle’s age, number of passengers on-board, etc.

• World Traffic Modeler [124] which is typically configured for modeling which includes the modeling of the traffic infrastructure (such as traffic lights cycles, dynamic traffic signs status, traffic speeds of each road segment (of the road network), rides requests demand model (ride requests frequency/fiux as a function of location). In addition it integrates all other modelers and implements cross-modelers’ influence, for example modeling the overall driving model of a combination of a specific driver and specific vehicle (or vehicle type). This World traffic modeler [124] has all the features described above regarding the World Modeler [120] in Fig. 2a and Fig. 2b.

All new embodiments of Fig. 2c (such as the world modeler building blocks) may be applied to the Autonomous Driver architecture accordingly and also form part of the invention’s embodiments. Prior models (referenced also as just“models” in this document) are compact representation of prior knowledge obtained from historical data and expert knowledge. These models contain various types of information which may be relevant for route planning such as average travel/vehicle speed in different road segments, demand distribution (ride request demands distribution over time or geography), correlation between travel speeds in different time intervals of a day and/or different road segments, correlation between weather and travel speed, traffic congestion model, traffic lights operations model, personal human driving behavior and preferences and so on.

Internal observations database may be part of the Databases (e.g. block [118] in Fig. 3) which hold measurements collected from the fleet vehicles e.g. GPS position, timestamp (time of measurement), acceleration, speed, fuel tank status, other car subsystems measurements (such as wheels gas pressure, breaks status, oil status, etc.) while data obtained from external sources is stored in an external observations database.

Posterior models estimation module, which is part of the World Modeler (block [120] in Fig. 2a/2b), is typically configured for update of posterior models used by all route planning elements (e.g. the routing engine block [130] in Fig. 2a/2b). This update may be periodical or on-demand. Posterior models represent system“belief’ for the parameters value for a certain future time window, e.g. the entire day (next 24 hours) based on (e.g. by computing probabilities conditional on, or by using a neural net or machine learning to generate predictions from) observations collected so far. For example, if significant vehicles speed slowdown is observed at some road segment at a certain time due to an accident or faulty traffic light, and it is known that travel speed has strong temporal correlation at this road segment, then there is a good chance (high probability) that at the near-term time-window travel speed at this road segment will be lower than usual (e.g. lower than the prior model estimation). At each start of day, posterior models may be reset to prior models. In addition, various learning methods may be implemented using the data acquired along history, and prior models may be updated accordingly. Learning methods may include for example machine learning methods such as neural networks (NN), deep learning (DL), probabilistic/Bayesian learning (BL), logical learning and similar.

Posterior computation may be regarded for some use cases as inference from a model . A model is an estimated function for a feature/parameter/variable in the scenario. For example the traffic speed of each road segment may be a continuous variable and may be modelled e.g. using Gaussian Mixture modelling or Gaussian Process modelling, service demand at each location (when and what we estimate will he the rides demand) can he modelled using Poisson modelling. There are many types of models that may be used for the mentioned models in this documents. For example, various variable types may be modelled according to their estimated features, e.g. classification problem may be implemented using neural network or by discrete random variables as part of probabilistic model (such as probabilistic graphical model - PGM, for example Bayesian Network or Random Markov Field). Use case with continuous variables may be implemented for example by using Bayesian network incorporating continuous Gaussian variables and/or by Random processes (e.g. Gaussian processes) or by using NN with continuous outputs (e.g. using softmax output function . Optionally alternatively, there are heterogenous use cases that incorporate both discrete and continuous variables (either random or other) that may be modelled using a heterogenous model with these two types of variables.

Fig 3 is an example of functional block diagram of the Service Manager [110] block of the QSMC [100] the Service Manager [110] may have all or any subset of the following functional blocks:

• Proposals Generator [111]

Responses Analyzer [112]

Assignment Handler [1 13]

• QoS Calculator [114]

• Pricing Calculator [115]

Timing Handler [116]

Real-time QoS Analyzer [117]

• Databases [118]

Fig. 4 is example of functional block diagram of the Proposals Generator [111] block of the Service Manager (e.g. [1 10] of Fig 3). Tire Proposals Generator [111] may have all or any subset of the following functional blocks:

Proposals Pool Generator [11 la]

• Proposals Filtering [T 1 lb]

• Proposals QoS vs. Pricing Calculator [11 lc]

Proposals validity time-window calculator [ 11 Id] Fig. 5a presents an example of a method of operation aka main process of the QMS. The first optional operation (dashed block) is the registration of the user/passenger to the QMS [501] The registration may he made by the user or by any other system that tire user has already registered to it in the past. During registration, the user identity is typically defined (e.g. name, phone number, age, home address, work address, etc.) and any other optional personal information may also be stored. The next optional operation is the users QoS parameters preferences definition or update [502 ] . The user preferences definition may be inserted manually (by using a dedicated web-page or application screen) or automatically from any external system. The user preferences may be inserted by the user himself, or by any other person that knows this information. The values of the user-preferred QoS parameters are used typically for QoS computations and user/passenger model update/leaming (user/passenger model is part of the World Modeler [120] in Figures-2a/2b or Passengers Modeler [121] in Fig. 2c). Examples of pages for passengers’ preferences definition are described herein with reference to the embodiments of Figs. 11a - 11c, 17 - 18. The next optional operation is the user request for a mobility service [503] (the status of tire user is then turn to “potential” from“not serviced”). The request for a mobility sendee includes data regarding the requested ride/delivery, such as the pickup and drop-off locations and any other QoS parameter which is mandatory or optional for the requested ride/delivery. The next operation is the preparation of proposal (or proposals) by the QMS for the user and then sending it/them back to the (potential) user [504] There are cases in which previous operation [503] is absent, and the QMS prepares the proposal based on the QMS internal detection of a situation/state that the user may prefer a different QoS parameters configuration compared to his current SLA.

For example the system may try to propose a rider to decrease its ETA if it learned that the typical arrival time of this rider to this destination is usually earlier than the current accepted ETA value. Optionally another example: if the system learned that the user is now riding to work in the morning at a certain time, it may send proactively a proposal to the user at the relevant time (e.g. enough time in advance, such that the user will see the proposal and accept it during its validity time-window and with the preferred QoS parameters configuration that were learned in the past, for example, if the system knows that the user should get to work at a specific time/hour and it detects a traffic congestion on the way to work, then it may alert tire user and prepare adequate mobility sen/ice proposal to meet the user QoS parameters configuration). Tire result of die proposal/s presentation may typically be divided into two outcomes: the first [504b] is the case that the user rejects part of or all proposal/s [509] In this case this information e.g. documentation or metadata characterizing the user’s rejection such as, say, current time and the current QoS parameters configuration used to make the proposal, may be sent [509a] to the user preferences update block [502] in order to update the user model and make better proposals in the future. The second case [504a] is the case that one or more proposals have been chosen by the user as acceptable [505] . In this case [505] there may optionally be also a procedure of final acknowledgement by the QMSC that the proposal is still valid. Thereafter, SLA is made (between the mobility sendee operator and the user) and a service plan is executed (a sendee plan includes all the actions that the QMS needs to do in order to complete the SLA, for example updating the drivers’ commands (either human or autonomous) and the vehicle/s route/s). In this operation, the status of the user/passenger (or delivery') is changed from“potential” to“committed”. Tire information regarding the acceptance of a proposal may also be delivered [505a] to the user preferences update block [502], its in the case of a rejection. The SLA and/or the service plan are transferred [505b] to the monitoring and control block [507] When a user/passenger/delivery is collected by a vehicle [506] his/its status is changed to“on-board” and the relevant information is also sent to the monitoring and control block [507] This block [507] monitors and controls all vehicles and risers, with respect to the SLAs that were agreed between the QMS and the risers and the resulting service plan/s. This monitoring and control process is performed for the committed and on-board users/passengers/deliveries. While the users are in those two statuses (committed and on-board), the next operation of bidding [508] may apply and may be trigged [507a] upon QoS request update in several cases, for example in all or any subset of the following situations:

when a served passenger sends an additional request (for example if he wants to change the SLA/QoS during the ride),

• when the operation manager commands to send a new proposal to a user,

• when the QMSC detects a situation in which it recommends to send a new proposal to a user. For example, if the system learned that the user is now riding to work in the morning and his last available and accepted SLA will get him to work late (compared to a typical morning), and the system (the QMSC part of the QMS) detects a possibility during the ride that the ETA may be reduced, the zl

QMSC may proactively prepare a proposal for an updated QoS parameters configuration (in which the ETA will be shorter) and send/preset it to the user.

• when a given e.g. predetermined or configured period of time had passed from the last proposal. Tins time period may be predefined in advance, or computed on-line. This period of time may also be constant or dynamic for a specific user, or for all users.

The bidding process [508] is one of the embodiments of the presented invention. It will be presented in more detail in the next figures. During this operation/process the QMSC prepares a set of proposals with better QoS configuration for several users (potential/committed/on-board). If a bid is accepted by some user(s) then the SLAs and service-plans are updated and sent back [508a] to die monitoring and control block [507 ] . Typically all responses to bids are sent [508b] to the user preferences model update block/process [502] The loop of operations [507] and [508] is performed for each served user. When a user service has been completed [507b] (for example it was dropped off at the destination), then the user is turned into not-service status and the ride information is sent to the user model update block [502] .

Fig 5b describes an example for the QMS bidding process (for example a process that may be done by block [508] or [507] of Fig. 5a). The first operation [510] is the case of nominal execution of the current service plan and the allocation of resources to accepted proposals (agreed SLAs); this operation is part of operation [507] of Fig. 5a. Upon a trigger (as described in Fig. 5a) the process of bidding is activated. The first operation of the bidding process is the computation of the bid proposals set [520] This operation typically includes certain operations described herein, including with reference to all or any subset of Figs. 6 - 9 The bid proposals set may comprise one or several proposals for several users. The bid proposals set may be valid for a bounded/limited time window* computed during the proposals ^’ preparation process (e.g. by block [11 id] in Fig. 4). Fiach proposal has its own time limit/bound, and sometimes there are dependencies between time windows of different proposals. For example, if there are two passengers, Alice and Bob that are on-board a vehicle, and Alice is planned to be dropped first, and Bob makes a request to make his ETA earlier, then a proposal with a change of the order of drop-off of the two on-board passengers will he valid typically until the vehicle will drop off Alice, or, alternatively, until the vehicle reaches its next junction, or a specific point in Alice’s route. Bid proposals may be divided into two types: * bids between single vehicle passengers only (are referenced in tins text as“level-1” bidding). Typically, the actions that are considered for the sen-ice-plan update are changing the order of the users pickup and/or drop-off, and other changes between the QoS parameters of the specific vehicle users only.

biddings that take into consideration users of more than one vehicle (which are referenced in this disclosure as “level-2” bidding). For example proposals that include a change in the serving vehicle for a user during his/her current service session (ride). The computation of level-2 biddings are much more complex as they need to consider more parameters and dependencies.

The next operation is the presentation of proposals to the relevant passengers [521] and to wait for a response from them. Then responses are received [522]; the responses may be active (for example if a user accepted a proposal or several proposals presented to him/her) or passive (for example if validity of a certain proposal has expired). If a proposal has been actively accepted, then its status is changed from “proposed” to“pending”. Typically, in order to succeed in a bid, two or more proposals from two or more users need to be recei ved by the QMSC (although in some cases only one proposal from one user may he needed if the traffic model is updated and new QoS parameter configuration may be applied to a user without any change in the overall service plan) so the system needs to wait to receive rninimal/partial response to the bid. In the next operation [523] there are typically several different cases:

• If no match is found (either rejections from users are received or time-out of bid is reached) then a rejection is sent to the relevant users/passengers (e.g. if users A and B got bid proposals that are dependent, and user A has rejected it, then user B will get rejection as well). Typically, a match is a situation in which all users affected by a bid (e.g. the set of users that are needed to accept the bid such that at least one alternative proposal can be made), agree to the bid during the bid’s time window (thus none of the users affected by the bid reject the bid). The rejection information is sent also to the computation process for user learning and better optimization for the next bids. If a match is found during the proposal time-window, then the system assigns the bid results in the sen' ice plan of the QSMC [540], updates the planned routes and drivers [541], and sends confirmation to the relevant users [542]

Fig 6 presents an additional example of a flow diagram for an intra-vehicle (level-1) user-triggered bidding process. In this example, there is a fleet vehicle VI [600] that already carries three passengers (PI, P2, P3) on-board. Each passenger has SLA with the QMS and operation [610] show's initial nominal prices and SLQ/QoS per ride of the three passengers. Some of the SLA parameters of these three passengers appear in [611] where Td(Pi) is the estimated drop-off time (ETA) for passenger i and M(Pi) is the price (money) that was part of the SLA with passenger i. Passenger P i ETA is 8 (for example 08:00AM) and the price for his ride is 5 (e.g US dollars), passenger P2 ETA is 9 and the price for his ride is 5 and passenger P3 ETA is 10 and the price for his ride is also 5. The following operations, all or any subset of which may be provided, present examples of the bidding process for the user-triggered level-1 case:

1. In the next operation is [620] passenger P3 sends request to the QMS to advance his ETA to 8 or earlier (the given request metric). This request is the trigger for the bidding process (user-triggered bidding).

2. The next operations, [630] and [640], are executed in order to prepare bid proposals forthe intra-vehicle bidding. In operation [630] the QMSC bid proposal generator (e.g. block [H I] in Fig. 3) computes the proposals pool. The proposal pool (made/prepared optionally by Proposals pool Generator block [11 la] in Fig. 4) is the set of ail available and valid sendee plans alternatives in which the request metric is met (e.g. passenger P3 arrives to his destination/drop-off at time less or equal to 8). It should be noted that the proposals pool may be the full list of alternative service plans made for example by an exhaustive search over all possible routes that keep the requested metric and also serve the other on-board passengers (PI and P2) to arrive to their destinations in different QoS parameter configurations than currently accepted by their

SLAs (for example by changing PI and P2 ETA/drop-off time parameter). A method to make the full list for intra-vehicle bidding is to make the foil list of combinations of drop-off order of the current on board passengers, and to check which of them meets the requested metric. Alternatively, for example if the full/exhaustive search is very- complex and the computation is time-consuming, then approximation methods may be used to generate bid proposals pool and a partial (relative to the full) list may be made. Such approximation methods may include for example grid-search, simulated annealing, heuristic search methods, gradient decent, Monte-Carlo tree search and similar methods for efficient search. The next operation [640] is optional and its role is to narrow down the list of optional bid proposals (if it is too long for practical use). In this operation, filtering of the pool proposals is made (e.g. by proposals filtering block [1 1 lb] of Fig. 4) and validity time- window for each filtered bid proposal is updated or made/computed (if not already made/computed in previous operation [630]). The bid proposal filtering of operation [640] may also consider the user preferences and current and/or predicted world model . In the example of this figure (Fig. 6) in addition to the initial order of drop-off, there are 5 additional combinations of drop-off orders of the three passengers (3 ! combinations in total). These additional alternative orders of drop-offs are computed in operation [630] and a sub-set of these alternative orders is chosen (so that each chosen alternative meets the required metric, each order alternative being an optional service plan) in order to make the proposal pool . It can be assumed for the current example that three out of the five service plan alternatives meet the requested criteria and are part of the proposals pool. In operation [640] this proposal pool is further filtered, for example by using the user/passenger model (e.g. which is part of the Passengers Modeler block [121] of Fig. 2c) which learns the user preferences with regard his/her rides, and by using the user/passenger model, the proposals that are part of the proposals pool may be ranked/prioritized for filtering. In a further embodiment of present invention, there is a weighted function used for the filtering process of operation [640] in which se v eral parameters are weighted and the result is used for final proposals ranking during the filtering. The weighted function may include all or any subset of the following data:

* User/passenger/delivery data, such as user preferences model with regard to the QoS parameters configurations (alternatively average for a user or optionally dependent on ride parameters such as ride request time of day, day of week, pickup location, drop-off location, etc.). For example the QMSC may use the user/passenger model (that learned the user using his rides history) whether the user prefers to save money (lo price) or prefers to save time (minimal ETA) in a current ride. In general, all QoS parameters, or any subset thereof, may be used in the weighted function.

External sources data (e.g. from external data sources block [60] of Fig. la/lb/2a/2b/2c). For example, weather conditions in the ride request pickup or drop-off location may be considered so that the user experience for each request is tuned.

The computed price for each bid proposal. The proposed price for each bid proposal (having its own QoS parameters configuration) itself may also be learned according to past experience of the user rides.

Other world model data.

In the current (Fig. 6) example the result of operation [640] is presented [641] Two out of the three proposals pool alternatives were filtered/selected - option ! and option 2. In option 1 passenger PI is placed last in the queue of drop-offs however his price is lowered:

Td(Pl)=10 & M(P1)=3, passenger P2 stays second in the order and his price does not change: Td(P2)=9 & M(P2)=5 and passenger P3 arrives to its destination earlier (according to his request), however the price is increased: Td(P3)=8 & M(P3)=8. In option 2 passenger P2 is placed last in the queue of drop-offs however ins price is lowered: Td(P2)=l l &

M(P2)=2, passenger PI is second in the order and his price reduced a little: Td(Pl) ^: =9 & M(P1)=4 and passenger P3 arrives to its destination earlier (according to his request) however the price is increased: Td(P3)=8 & M(P3)=9.

3 The next operation [650] is to send and present the proposals to the users/passengers. Table [651] summarizes the bids proposals that each passenger sees: passenger PI gets two bid proposals (Td=10&M=3, Td=9&M=4), passenger P2 gets only one bid proposal (Td=l 1&M=2) and passenger P3 gets as a proposal the requested change followed by the other QoS parameters values and the accompanied price (Td=8&M=9) In some following figures (e.g. figures lOa/lOb/lOc/lOd/lOe) examples of bidding proposals page/screens that are presented to the users are given.

Next operation [660] is the collection of the responses to the bid proposals (e.g. by the Passengers Data Collector block [142] in Fig. 2a/2b) during the validity time window. In tire current example, table [661] presents the accepted proposals of each passenger: passenger PI accepts the proposal Td=l0&M=3, passenger P2 accepts the proposal Td=l ! &M=2 and passenger P3 accepts the proposal Td=8&M=9. Next operation [670] is the analysis of the accepted responses and selection of the best bid proposals with respect to the user (e.g. P3) request and other system optimization goals (such as reduced cost, profit, user experience, etc.). In some cases, for a bid proposal to be activated/fully accepted, there is a need that several users accept the same proposal alternatives (each proposal option, such as e.g. options 1 and 2 [641] make a list of dependent users proposals), only proposal options that all dependent users proposals were accepted may be valid for selection. Table [671] presents the result of the selected alternative for execution. Option-1 of [641] was chosen: for PI Td=l0&M=3, for P2 there is no change and for P3 Td=8&M=9. Option-2 (of [641]) may not be valid because user PI have not accepted option-2 proposal alternative (Pi did not accept: Td=9&M=4, he accepted only Td=l 0&M=3), and although passenger P2 accepts option-2 proposal (for P2: Td=T 1 &M=2) it cannot be executed.

Next operation [680] is to send the results to the users and update service plan and vehicle routes and commands (by updating the DMM/ADM). In this operation passenger P3 got a message that his request was accepted and passenger PI was updated that his acceptance of the bid proposal was assigned and is valid. Passenger P2 was also notified that although he accepted the bid proposal, the final assignment could not be carried out, and this proposal is no longer valid. Fig. 7 presents an example of flow diagram for an intra-vehicle (level- 1 ) operator-triggered bidding process. Many operations are similar to the level-1 user triggered bidding presented in Fig. 6 and the relevant description may apply here as well. There may be a change in all or any subset of the following operations:

1. At tire beginning of the bidding process - operation [720] - the trigger may be activated in all or any subset of the following alternatives (other than by the user):

if the operation manager commands to send a proposal to a user,

• if the QMSC detects a situation in which it recommends to send a proposal to a user. For example, if the system learned that the user is now nding to work in the morning, and his last available and accepted SLA will get him to work late (compared to a typical morning), and the system (the QMSC part of the QMS) detects a possibility during the ride that the ETA may be reduced, the QMSC may proactively prepare a proposal for an updated QoS parameters configuration (in which the ETA will be shorter) and send/preset it to the user.

* If a period of time had passed from the last proposal. ^" Lins time period may be predefined in advance, or computed on-line. This period of time may also be constant or dynamic for a specific user, or for all users.

2. The next operation [730] may also be changed relative to Fig. 6 as the requested metric is made by the system, and not by the user.

Fig. 8 presents an example of a flow' diagram for a multi-vehicle fleet level (level-2) user-triggered bidding process hi this case, more than one vehicle is considered during the bidding process in this example there are two vehicles, VI and V2. On-board VI there are three passengers: Pi, P2 and P3. On-board V2 there are two passengers: P4 and P5. There are two additional passengers: P6 that is committed by the QMS and will be currently served by vehicle V2, and passenger P7 that is not yet served by the QMS (potential user/passenger) and asks for a ride/mobility service. The following operations may be similar to those presented at Fig. 6 and all relevant embodiments may apply accordingly in tins example. There may be some additional changes in case of level-2 bidding: e.g. all or any subset of the following: 1. [811] shows the list of SLAs for each served user (for terms and explanation see Fig. 6 description).

2. The example bidding process begins at [820] when passenger P7 asks for a service by sending a ride request and/or on-board passenger P3 asks to arrive at 9 or earlier (Td< 9).

3. In the bid proposals pool generation operation [830] there may be a different computation method because many more combinations may be considered in the level-2 case compared to level- 1 case as the currently served and potential users may be allocated to each of the available vehicles (all or part of the fleet operational vehicles) and also for each vehicle there may be all options of users pickup or/and drop-off orders that need to be evaluated. As in level- 1 bidding, also here approximation methods may apply to make efficient preparati on of the proposals pool (as listed in Fig 6).

4. In the proposal filtering operation [840] as well, additional schemes for filtering may apply (see Fig. 6). For example, if a certain user is not in favor of changing the car during the ride, then the bidding proposals that include this change/switch of car for this user, may be omitted. If the QMSC may use other social information/preferences in order to decide which users to transfer to a vehicle (for example, users that like the same music or that are fans of the same basketball group, or that smoke).

Fig. 9 presents an example of a flow' diagram for a multi-vehicle fleet level (level-2) operator-triggered bidding process. It may be seen that it is very similar to Fig. 8, except for the first operations . All or part of the changes of Fig. 7 with respect to Fig. 6 may also apply here

Figiires-lOa/lOb/lOc/lOd/lOe/1 la/1 lb/12/13 present a screen/page of a smartphone as an example of a user device. Any user device type may be used for presenting the pages in those figures (as described at the beginning of this disclosure).

Fig 10a presents an example of an on-board passenger proposals page during bidding session for level 1+2 bidding the current time is presented [1018] for example as a reference to the proposals timeouts the bid timeout may also be presented [1019] In this example several bid proposals are presented ([1011], [1012], 1013], [1015], [1016], [ 1017]) in addition to the current accepted SLA [1014] Each proposal presents all QoS parameters of the proposal or any subset thereof, typically in addition to the price. In the example the ETA time and die vehicle switching event and switching time (here presented under the“Notes” column) are illustrated. A variety of proposals may be presented, for example proposals with later ETAs (proposals [1011], [ 1012] and [1013]) and with earlier ETA (proposals [1015], [1016] and [1017]). The Minimal ETA proposal may also be presented and highlighted (here presented at the bottom of the proposals list -“Minimal”). Proposal notes may also indicate that the ride will be private (only the user occupy the vehicle) from a certain time point (such as presented for the Minimal proposal [ 1017]). In this example both level- 1 and level-2 bid proposals are presented. For level-2 proposals with later ETAs (proposals [101 1] and [1012]) the vehicle switching event and time of switching is presented).

Fig. 10b presents an example of an on-board passenger proposals page during a bidding session for level 1 bidding. The page is very similar to the one presented in Fig. 10a (and all relevant embodiments from this figure may apply also for this figure (Fig. 10b) but typically fewer bid proposals alternatives are presented and notes specific to level-2 bidding are not relevant (such as switching event and time).

Fig. 10c presents an example of a committed passenger proposals page during internal bidding session for level 1 +2 bidding. The page is very similar to the one presented in Fig. 10a and all relevant embodiments from this figure may apply also for this figure (Fig. 10c). In the committed passenger page the QoS presented parameters for each proposal may include also the FTP in addition to the ETA.

Fig. lOd presents an example of a potential passenger proposals page during an internal bidding session. The page is very similar to the one presented in Fig. 10c and all relevant embodiments from this figure may apply also for this figure (Fig. lOd). For the potential user there is no current SLA. Current SLA is presented for committed passengers (such as [1034] in Fig. 10c) and for on-board passengers (such as [1023 ] in Fig. 10b and [1014] in Fig. 10a).

Fig. 1 Oe presents an additional example of a flow diagram of potential passenger proposals page during an internal bidding session when a passenger does not choose a proposal. In the presented potential passengers page, each proposal has its own timeout value (the rightmost column) which is the validity time-window of each bid proposal. This example sho 's that the time-window of each bid proposal will affect its validity over time. In the beginning [1051 ] at 09:02 (when first presented to the user) the bid proposals page presents all proposals as valid. Each proposal has its own time-out. In the next operation [1052] the time elapsed to 09:06. The two bottom proposals that their timeouts have been reached (09:05 and 09:04) became non-valid and were colored in a strong grey color and may not be selected from this timepoint and further. In the next operation [1053] the time elapsed to 09: 10 and additional proposals (whose timeout have been reached) were disabled --- see additional three bottom valid proposals of [1052] In the page, an additional optional buton may be added [1055] for updating the proposals page. If this button is pressed then the QMSC computes the current available proposals and presents only the valid proposals to the user.

Figures 11a- 11c present examples of a potential passenger preference questionnaire page.

In Fig l la a question regarding the importance of each QoS parameter to the user (in general) is presented [1112] and a list of several QoS parameters are presented, each one with a corresponding selection bar in which the user selects the importance rank for him/her (from the most/very important to the least/not important (alternatively and other methods for selecting the value of the importance of the parameter may apply, for example by writing a numerical value, etc.). Several QoS parameters, all or any subset of which may be provided, are shown in this example, each with its corresponding selection bar:

Minimum ETP [1113]

Minimum ETA [1 114]

• Minimum Ride Duration [1115]

• Minimum Price [1 1 16]

Minimum Additional Passengers [11 17]

Smooth (aka“soft”) Ride [1118] (any suitable operationalization or implementation to ensure the ride is comfortable, e.g. there is no major acceleration, or avoidance of any road has many pothole, bumps or is a rough road. Typically it can be measured or implemented by limiting the acceleration in each one of the spatial axes to a certain value)

The user in the example prefers in his typical/general configuration minimum ETP, ETA and price. In addition, this user is less sensitive (the following parameters are less important for him) to the quantity of additional passengers, ride duration and ride smoothness. The importance factor may be regarded as the user average (prior) preferences for the QoS proposals computation, preparation and filtering. In Fig. 1 lb a question regarding the importance of each QoS parameter to the user for a specific ride is presented [1122] and a list of several QoS parameters are presented, each one with a corresponding selection bar in which the user selects the importance rank for him/her (from the most/very important to tire less/not important (alternatively and other method for selecting the value of tire importance of the parameter may apply, for example by writing a numerical value, etc.). Several QoS parameters are shown in this example, all of any subset of which may be provided, each with its corresponding selection bar:

Minimum ETP [1 123]

· Minimum ETA [ 1124]

Minimum Ride Duration [1125]

• Minimum Price [1126]

• Minimum Additional Passengers [1127]

• Smooth (aka '‘soft”) Ride [1 128]

The user in the example prefers minimum ETA only. All other parameters are less important for tins specific ride. The importance factor may be regarded as the user current preferences for the QoS proposals computation, preparation and filtering.

In Fig. 1 1c an additional alternative of a page for getting user preference is presented. It may be seen that it includes optionally a question regarding the general preferences of the user [1 132] and an additional optional question regarding the next ride [1134], if relevant. There is a buton for each one of the QoS parameters for each question ([ 1134] for general preferences and [1135] for the current ride preferences) and e.g. by pressing buttons, a user selects (and optionally highlights) the most important parameters. The importance factor may be regarded as the user general/current preferences for the QoS proposals computation, preparation and filtering.

Fig. 12 presents an example of a committed passenger monitoring page flow before and during his/her pickup. The monitoring page is a part of the Passenger MaaS Module (e.g. PMM block 200 in Fig. la/lb/2a/2h/2c) and it is used by the user/passenger in order to monitor his current ongoing service (e.g. to observe the current values of the QoS parameters). This page, for example, shows graphically or numerically the distance and/or pickup time of the potential serving vehicle (or vehicles) or a function of them (the distances/pickup times). In all operations, the current time and any additional messages are presented in the upper side of the screen. The location of the user is presented by a pin-point or upside-down triangle. In the first operation [1210] the ETP is also presented on the upper side of the screen (ETP: 09: 12) and because the ETP is relatively far from the current time, there may be several vehicles that may pick up the user (and also meet his SLA), therefore a circle is drawn around the user location which shows a function of the current distance of those potential serving vehicles. In an additional embodiment this function may be a circle around the user with a radius which is equal to the most distant potential serving vehicle. In the next operation [ 1220] the time elapsed and the current time is 09:07. in this operation the circle which represents the distance or pickup time of the user is smaller because the potential serving vehicle(s) are closer to the user. In the third operation [1230] the time is further elapsed and is 09: 10. As a result of the short distance and pickup time relative to current time, the confidence level regarding the serving vehicle is high, and the final serving vehicle for the user is chosen. It may be seen in [1230] that additional information regarding the serving vehicle (Black BMW #1923456) and its driver (John Nash, mobile: 012-234-543) may also be shown to the user. In addition in [1230] the exact location of the vehicle may be shown on the map, and the planned route from the vehicle’s current location to the user’s pickup location may also be shown. The last operation [ 1240] is an example of the user page/screen layout when the serving vehicle arrives to the user pickup location . An optional message that the vehicle had arrived to the pickup location may be shown (“Driver is waiting”) and the ETP may be removed as it is no longer valid. In the map the car is then located at the user pickup location.

Fig. 13 presents an example of a driver page flow, before and during a pickup. The page includes the current time 09:02 (optionally in the upper part of the screen). The next guidance commands may also be shown on the screen (e.g. in operation [ 1310] -“Turn left at next junction”). Visual guidance may be accompanied also by voice commands. The page includes a map that shows the current location of the vehicle and a planned route. The planned route may be either full planned route (for example until the final serving location which is the last drop-off of the last served passenger), or any partial route of the current full planned route. In [1310] only partial route is presented to the driver (although the full planned route may be longer) Tire partial view of the planned route may be shown in order not to confuse the driver as in the fleet level optimized routing algorithm the planned route may change drastically over time (for example if level-2 bid involving one or more of the vehicle passengers is made and accepted ). In the next operation [1320] the time advances and the current time is 09:05, and near-term navigation commands are shown by text and as a route in the screen. In this operation still the next destination (either pickup or drop-off or both) cannot not be determined with high confidence, and is therefore not shown. However, in the third operation [1330] the next destination is finally chosen and information regarding it may be shown on the screen (‘Next passenger is Michael Rich, mobile: 023-234-34333”). In addition, the next destination location may also be shown on the map (in the example as an upside-down triangle) and the following navigation commands to this location may also be shown and/or voiced (“Turn right at next junction, next passenger is 100 meters ahead”). In addition, the estimated arrival time to the next destination and information about this destination (either pickup or drop-off of passenger or delivery, number of passengers to pick up or drop-off, etc.) may also be shown to the driver. The final presented operation [1340] shows an example of the driver page when the driver arrives to the next destination location. A message regarding the arrival to the destination location may be shown to the driver (‘"Arri ved at next passenger location”) and the car icon is then located at the next destination location on the map. Upon arrival to the destination, an optional button may appear on the screen for getting feedback from the driver that the user was picked up or dropped-off (in [1340] it is represented by a black rectangle in the bottom of the screen with the text“Press this button when next passenger is on-board”. Alternatively, this acknowledge message may be automatically sent by the vehicle if the vehicle senses and identifies the user that was picked-up or dropped off (for example using a wireless connection such as Bluetooth or WiFi or NFC or sim ilar or any combination of such).

There is other optional infonnation that the user may also provide to the QMS, e.g. pick up time (or time window), drop-off time (or time window'), personal preferences such as type of seat, favored music, ride characteristics (maximal acceleration, turning speed, etc.), etc. Additional information sent from vehicles to QMSC are notifications of user on-boarding and off-boarding the vehicle (for example by using a detection or short-range technology such as Near-Field-Communication, Bluetooth, WiFi, RFID, etc.). This information helps QMS to update status of service requests (acknowledging that a certain user has been picked-up or dropped-off). V ehicle - QMSC interface is implemented using communication technology such as cellular, WIFI, satellite, etc. Fig. 14 and Fig. 15 present two examples of a proposals preparation process. The proposals preparation process may be activated for a potential passenger that requests a mobility service (e.g. at block [504] in Fig. 5a) or for a passenger that is served by the QMS, either committed or onboard (e.g. at block [520] in Fig. 5b or operations [630], [640] in Fig. 6 or operations [730], [740] in Fig. 7 or operations [830], [840] in Fig. 8 or operations [930], [940] in Fig. 9) the presented examples of the proposals’ preparation process (e.g. as described herein with reference to Figs. 14 and/or 15) may be done by the Proposals Generator block [1 11] of Fig. 3. Any of the operations presented in the diagram flow may be optional e.g. as highlighted herein. Fig. 14 describes a proposal preparation process that includes preparation/computation of modified proposals and/or baseline proposals substantially in parallel. Tire first operation [1410] presented in Fig. 14 is the triggering of the proposals preparation process. As described above in Fig. 5a and Fig. 5b, the trigger may be activated either by the passenger or by the QMS (see details in Fig. 5a/5b or in the text at the right to block [1410] in Fig. 14). After a trigger had occurred, two types of computation may ^¬ be done (each one of them separately, or two of them together/in parallel):

Computation of baseline proposals pool [1420] The baseline proposals pool are proposals that consider the PU and/or DO location/s given/inserted previously by tire passenger. Those locations may be inserted as part of the passenger sendee request process (an example of location insertion in a passenger page will be presented in Figures 20a&20b,2Ia&21b,22a&22b,23a&23b). The computation may be done using algorithm of block [504] in Fig. 5a or block [520] in Fig. 5b or operation [630] in Fig. 6 or operation [730] in Fig. 7 or operation [830] in Fig. 8 or operation [930] in Fig. 9; and/or

• Computation of modified proposals pool [1430] - during this operation other alternative proposals are made, in which the PU and/or DO locations are modified (moved from the original user-given locations to other alternative locations), in order to explore other optional proposals for the user that cover different user-preferable QoS/Price configurations. Fig. 16 and Figure 19 present examples of the computations and processing flow for this block. The mode of operation (whether baseline only or modified only, or both proposals pools are computed/generated) may be chosen by the system operator in advance (preset), or in real time. Alternatively, it may be chosen by the QMS as a result of a system state (for example if the QPC of the baseline is not sufficient or if there are no results/proposals in the baseline), or it may be chosen by the user in advance or in real-time.

The output of the baseline and/or modified proposals pool block is then transferred to the next block [ 1440] for proposals pools filtering. This filtering block [1440] may be optional for the overall process. The filtering block is typically configured for all or any subset of the following:

* first optionally to aggregate the two proposal pools results, in case that the two proposals pool blocks ([1430] and [1420]) are activated (otherwise there is no need for aggregation because only one proposals pool block is activated.

this block is typically configured to filter all proposals pool/s results generated by previous block/s. The filtering may be needed if the proposals pool has a large amount of alternative proposals and this amount needs to be reduced to be presented to the user. Filtering may be done similarly to the methods used in block [504] in Fig. 5a or in block [520] in Fig 5b or operation [640] in Fig. 6 or operation [740] in Fig. 7 or operation [840] in Fig. 8 or operation [940] in Fig. 9. Fig. 16 and Figure 19 presents examples of the computations and processing flow for this block.

* There may be an interface [1440a] between this block [1440] and the Passenger Model [ 1470] The Passenger Model [ 1470] is managed by the Passenger Modeler (e.g. as [121] in Fig. 2c or as a part of the World Modeler block [120] in Fig. 2b). This interface may be used in order to get passenger information, e.g. user preferred QoS Parameters Configuration (QPC) or any other user information (e.g. how many proposals the user wants to see, what is his/her wage level, etc.) that may be considered during the proposals pool filtering process.

The last two operations are similar to those presented in previous figures. Block [1450] is similar to block [521] in Fig. 5b or operation [650] in Fig. 6 or operation [750] in Fig. 7 or operation [850] in Fig. 8 or operation [950] in Fig. 9. Block [ 1460] is similar to block [522] in Fig. 5b or operation [660] in Fig. 6 or operation [760] in Fig. 7 or operation [860] in Fig. 8 or operation [960] in Fig 9 An additional update [1460a] of the Passenger Model [ 1470] may be carried out following reception of proposal responses [1460] from the user, similar to interface [505a] in Fig. 5a.

Fig 15 presents an alternative example of a proposals preparation process in addition to that presented in Fig. 14 Many blocks in Fig. 15 are similar to those presented in Fig. 14 and may have similar functionality. Typically, unlike Fig. 14, in Fig. 15 the modified proposals pool computation and generation [1550] is done sequentially (after/in tandem to) the computation of the baseline proposals pool [1540] and only if the baseline proposal pool results are not satisfactory' (the output of block [1545] is No/Negative). An additional difference is the separation of the optional proposals pool filtering block (block [1440] in Fig. 14) into two separate optional blocks: Baseline proposals pool filtering [1540] that follows the Baseline proposals pool computation/generation [ 1520] and Modified proposals pool filtering [1560] that follows the Modified proposals pool computation/generation [1550] Block [ 1545] cheeks whether the baseline proposal pool is satisfactory. An example of a satisfactory case may be if the filtered baseline proposals pool results have QPC that is close enough (having smaller distance than a given threshold) to the desired QPC of the user. An additional example for a satisfactory' ease may be if the filtered baseline proposals pool has enough results (for example has at least three or more valid results).

Fig. 16 presents an example of the modified proposals computation process presented in Fig. 14 and Fig. 15 as a part of the overall proposals preparation process. The blocks in Fig. 16 include Modified proposals pool computation block ([1430] in Fig. 14 or [1550] in Fig. 15) and the Modified proposals pool filtering block ([1440] in Fig. 14 or [1560] in Fig. 15). Computation/generation of the proposals pool may be divided into two sub-operations:

Operation [1610] in which a list of modified PU and/or DO locations is computed. These modified PU and/or DO locations may be chosen nearby to the original user-given locations, for example at a given radius from the original given location, or at a given walking distance from the original given location. There may be an interface [1610a] between this block [1610] and between the World Model [1615] ([1615] may be part of the World Modeler block [120] of Fig. 2a/2b) Typical data that may be passed by [1610a] from the World Model [1615 ] to [1610] may be weather conditions at the surrounding of the PU/DQ locations, traffic conditions, and any other relevant data that may be used in order to determine die modified locations. Then these modified locations may be optionally filtered according to the ability of a vehicle to stop at these locations (e.g. bus-stops, etc.) or according to the safety conditions of each close-by location. The modified locations may have any geometrical shape, for example points on map (e.g. as presented in Fig. 27a) or line/road segments (e.g. as presented in Fig. 29bl/30bl) or any combination of shapes (e.g. as presented in Fig. 27b)

* Next operation [1620] is die computation of the proposal pool for these modified PU and/or DO locations. Typically, in this operation, an optimal route for each (but sometimes for some of) the modified locations from previous operation [1610] is computed, given the fleet vehicles. All valid proposals (e.g. that their QoS parameters values are close enough to the user-desired values, or that their cost/price is acceptable e.g. delta with respect to a typical ride for the original locations is below a threshold) are stored in the modified proposals pool. In addition to the route, the price for each proposal may be computed in this operation. The price may depend on the additional cost (OPEX = operational expenses) of the proposal execution and/or the wanted profit for that proposal (that may depend on the user information/time/system state, or any other relevant data). The computation of the proposals pool may use the Proposals QoS Vs. Pricing calculator [11 icj (presented also in Fig. 4) and/or Proposals validity time-window' calculator [11 Id]

(presented also in Fig. 4).

The next two operations that may be included in the proposals pool filtering ([1630] and [1640]) are optional (each of them may be optionally omitted):

Operation [1630] in which the proposals pool proposals are arranged according to a given rank/metric of the proposal (that may be one dimensional or multi-dimensional). An example of such a rank/metric may be the expected user experience of the proposal, e.g. weighted vector of the distance between proposal QPC and tire user-desired QPC: Proposal Rank = SU TiW^distiQP ropsai- Q -i^d)).

in which the summation index“i” is done over all QPC parameters, W' is the weight of parameter i (e.g importance with respect to other QPC parameters), dist(a,b) is a distance function between value a and value b, QP is QoS Parameter abbreviation, QP propsai is the value of parameter i in the proposal and QP _sired is the value of parameter i in the desired QPC. A distance function dist(a,b) may be for example a subtraction (“· “) or absolute value of subtraction or a ratio or any other algebraic distance function. Another example of a proposal rank is its price. The rank may be any combination/function of the expected user experience and the price of the proposal and any other relevant system parameter (such as expected future demand of the route, exploration factor of the route that will create more information regarding the knowledge of the World Model, etc ). See Fig. 19 for further explanation. The arrangement of the proposals may be used also at the presentation operation ([1450] in Fig. 12 or [1570] in Fig. 15) for suitable positioning and ordering of the proposals in the page/screen of the user device.

* In the next operation [ 1640], the best proposals from the ordered list are presented to the user. The number and types of selected proposals may be chosen according to several considerations such as (all or any subset of the following):

o Number of proposals the user prefers to see (whether defined by the user or learned by the QMS).

o Number of proposals that may be presented on the user device screen.

o Desired QPC.

o Distribution of QoS parameters values of the various proposals o Di stributi on of proposal s ranks .

o Number of valid proposals.

It may be seen in Fig. 16 that the Passenger Model [1650] may be used by one or more blocks (e.g. [1620] and/or [1630] and/or [1640]) for utilizing passenger data for the internal computations.

Fig. 17 and Fig. 18 present additional examples of a passenger preference questionnaire page (in addition to those presented in Figures-! !a/1 !b/l lc). Fig. 17 presents additional page layout similar to that presented in Fig. 1 la/1 lb (and therefore all relevant description and embodiments may apply here as well), however QoS parameters are added to the list of parameters. Parameters [1713], [1714], [1715], [1 716], [1717] and [1718] are similar to [1113], [1114], [1 1 15], [1116], [ 1117] and [1118] accordingly. There are two additional parameters m this example that may be used for the computation ofthe modified locations proposals: [1719] which reflects the user importance/preference about walking to a modified PIJ/DO location, and [1720] which reflects tire user importance/preference with regard to riding in a vehicle which allows smoking. Fig. 18 presents an additional page layout similar to that presented in Fig. l i e (and therefore all relevant description and embodiments may apply here as well), however QoS parameters are added to the list of parameters. There are two additional parameters in this example that may be used for the computation of the modified locations proposals: a “Short Walking” button which reflects the user importance/preference about walking distances to modified PU/DO location, and‘"Non- smokers” which reflects the user importance/preference to ride in a vehicle in which smoking is not allowed.

Fig. 19 presents an example of computations and functions executed by the QMSC In [1910] an example of a list of QoS parameters (QoS parameters set - QPS) is presented. Equation [ 1930] describes an example of function type, fl, for the computation of Proposal Price. It may be seen the Proposal Price function arguments may include all or any subset of:

* OPEX (operational expenses such as estimated fuel consumption, maintenance fees, driver payment, road tolls, etc.) of the proposed route User Experience rank (as described above) ofthe proposed route Estimated ride requests demand along the proposed route Exploration factor of the proposed route. Exploration factor reflects the system (world) model information gain as a result of data acquired along the proposed route).

Equation [1940] describes an example of the type of the User Experience rank function £2. £2 arguments may include all or any subset of:

QPC of the proposed route

Desired QPC (user-desired values of the QoS parameters) Proposed (e.g. modified) Pick-Up Location (PPUL). * Proposed (e.g. modified) Drop-Off Location (PDOL).

Equation [1950] further describes a more detailed example for the User Experience rank function £2. In this example £2 is a distance metric between the desired QoS and the proposal QoS and the optimization process may aim to minimize this m tric. £2 in [1950] is the summation over all (or part of the) parameters of the QPS of the factor of all or any subset of the following:

QPS parameter weighting factor Wp that reflects the significance/importance of each parameter relative to others. Typically the range of this weighting factor is between zero (0) and one (1).

* QPS parameter normalizing factor Np that normalizes the parameter value with respect to the range of the parameter values.

• Difference between the desired value of the QPS parameter and the proposed route value of the QPS parameter (subtraction of the values). It shall be noted that for some parameters a ratio between the desired value and the proposed route value may be more appropriate than subtraction. Any mathematical distance function may be used here as well (e.g. algebraic, geometric or statistical distance function).

• Additional function, £3, of other data regarding the proposed route such as the weather at the PPUL and the PDOL.

The last equation [ 1960] gives an example of function f4 used for selection of the proposals to be presented. The arguments of f4 may include the proposal price and/or proposal user experience rank (and set of the QPS parameters may be taken).

Fig. 20a, Fig. 20b, Fig. 20c and Fig. 2Gd present examples of pickup location selection in the passenger application by map clicking/pressing: Fig 20a, and thereafter Fig. 20b, and further optionally Fig. 20c and Fig 20d. In Fig. 20a the request to enter the pick-up location e.g. by pressing on the map is presented [2010] Then the passenger clicks on the screen (e.g. by pressing his finger [2020]) on the desired location. In response, an icon of pickup (e.g. as an upside-down triangle) may be drawn on the map at the selected location [2030], and optionally the address of this location may be also displayed on the screen - [2040] or [2050] Additional optional operation in the process of pick-up location insertion is presented in Fig. 20c and Fig. 20d. This operation helps to improve the accuracy of the pickup location in the street, for example on what side of the sidewalk the passenger is planning to wait, and/or what is the planned spot along the sidewalk where the passenger is going to be located during pickup. In Fig. 20c the QMS is requesting from the user to identify the exact location in the street view . For this purpose, a street view image or illustration (of the surroundings of the selected location in Fig. 20b) is optionally presented on the passenger screen [2060], and a guidance sentence is displayed [2011] The street-view of the pickup location may be accompanied by a text describing the viewpoint of the street view image/illustration (in [2060] of Fig. 20c there is an example of such text - “13 Sutter Street East Direction"’). The next operation is presented in Fig. 2Qd, where the passenger clicks on the screen [2020] at the exact location in the street view image/illustration to pin-point the desired pickup location point, and then optionally an image or an icon (in [2060] it is a man’s black icon [2070]) is presented in this point to show' graphically the received/identified location.

Fig. 2 la and Fig. 21b present an example pickup location selection in the passenger application by entering an address: Fig. 21a and thereafter Fig. 2 lb. In Fig. 2 la the request to enter the pick-up location by entering an address is presented [21 10] Then the passenger enters the address in the empty text line [2150] . In response, an icon of pickup may be drawn on the map [2130] at the selected location, and optionally the address of this location is also displayed on the screen/map [2140] or [2150] . A street- view' accurate location selection (as presented at Fig. 20c and Fig. 2Qd) applicable in this use-case as well

Fig. 22a and Fig. 22b present additional example of drop-off location selection in the passenger application by map pressing/clicking: Fig. 22a and thereafter Fig. 22b. In Fig. 22a the request to enter the drop-off location e.g. by pressing on the map is presented [2210] Then the passenger clicks on the screen (e.g. by pressing his finger [2220]) at the desired location. In response an icon of pickup (e.g. as an upside-down triangle) may be drawn on the map at the selected location [2230] and optionally the address of this location may be also displayed on the screen - [2240] or [2250] . A street- view accurate location selection (as presented at Fig. 20c and Fig 20d) is applicable in this use-case as well.

Fig. 23a and Fig. 23b present an example of passenger drop-off location selection in the passenger application by entering an address: Fig. 23a and thereafter Fig. 23b. In Fig. 23a the request to enter the drop-off location by entering an address is presented [2310] Then the passenger enters the address in the empty text line [2350] In response an icon of drop-off may be drawn on the map at the selected location [2330] and optionally the address of this location may be also displayed on the screen/map [2340] or [2350] A street-view accurate location selection (as presented at Fig. 20c and Fig. 20d) is applicable in this use-case as well.

Fig. 24 presents an example of presenting nominal (also tenned“baseline” in this document) proposal result (e.g route and QoS parameters configuration (QPC)) for original given locations in the passenger application. This page/screen includes a statement that the nominal route for the original locations is presented [2410] In addition, the following items may be also presented on the screen:

* Proposed route [2450] from the original pickup location [2420] to the original drop-off location [2430].

all QoS parameters values, or any subset thereof, for the current proposal [2440] For example in Fig. 24 it is:“FTP: 09: 15, ETA: 09:35, Car class: B, Price: 8$”. Presented QoS parameters values may be computed during the proposals preparation and/or filtering processes. In case there are no enough proposals for the original PU/DO locations, or any other trigger for computation, and presentation of modified location/s proposals is received (e.g. the user asks for a modified PU/DO locations proposals in order to optimize all or any subset of the QoS parameters), additional proposals may be prepared and presented to the passenger. Fig. 29a and Fig. 30a present examples of a QoS parameter selection in the passenger application; the parameters may be used for further optimization of proposals preparation. It Fig. 29a there is a statement [2910] that asks the passenger to press/select the relevant parameter for additional proposals preparation. In addition, the original Pli location [2921 ] and DO location [2922] may be also presented on the screen. All or any subset of the QoS parameters are presented to the passenger ([2931], [2932], [2933] and [2934]) and the passenger may press/select all or any subset of these parameters [2940] for preparation of additional alternative proposals with modified PIJ and/or DO locations. In Fig. 29a the passenger has pressed the“Min. ETA” button, meaning that he/she wants the QMS system to present additional proposals with modified PU and/or DO locations that optimize this parameter (for Fig. 30a the optimized parameter is minimal price). After the modified proposal preparation process is triggered (e.g. after Fiure-29a or Fig. 30a) there are several optional pages to be presented to the passenger, for example Fig. 25/ 26/ 27a / 27b/ 29b 1/ 29cl/ 30bl/ 30cl . Fig. 25 presents an example of a modified locations proposal page for the case of Minimum ETA parameter optimization. The optimization parameter that was used for preparation of the current proposal [2510] may be optionally displayed. Modified pickup location icon [2540], the modified pickup location address [2541 ] and the walking distance from the original passenger-given address to the modified pickup address [2542] may he also presented (each one, or a set of them) on the screen. Optionally, (if the proposal requires modified drop-off location), the modified drop-off icon [2550], modified DO location address [2551] and walking distance [2552] may be also presented. The proposed route [2570] may be also presented on the road map/network. Moreover, as an alternative, all or any subset of QoS parameters values for the current proposal may be presented [2560] For example in Fig. 25 it is:“ΈTR: 09: 13, ETA: 09: 30, Car class: A, Price: 10$”. This proposal has earlier ETA than the one given for the nominaJ/baseline proposal in Fig. 24 (09:30 instead of 09:35). The presented QoS parameters values may be computed during the proposals' preparation and/or filtering processes.

Fig. 26 presents an additional example of a modified locations proposal page for the case of Minimum Price parameter optimization. The optimization parameter that was used for preparation of the current proposal [2610] may be optionally displayed. Modified pickup location icon [2640], the modified pickup location address [2641 ] and the walking distance from the original passenger-given address to the modified pickup address [2642] may be also presented (each one, or a set of them) on the screen. The proposed route [2670] may be also presented on the road map/network. Moreover, as an alternative, all or any subset of QoS parameters values for the current proposal may ^¬ be presented [2660] In Fig. 26 example it is:“FTP: 09: 16, ETA: 09:40, Car class: C, Price: 5$”. This proposal has a lower price than the one given for the nominal/baseline proposal in Fig. 24 (5$ instead of 8$). The presented QoS parameters values may be computed during the proposals’ preparation and/or filtering processes.

In some cases, several alternative proposals may be relevant and available for presentation to the passenger (for choosing among them). Fig. 27a and Fig. 27b present page layout for these cases.

Fig. 27a shows an example of a multi-proposal display for the passenger, and aggregates the single proposals presented in Fig 24, Fig. 25 and Fig. 26 into a Single page layout. The page header [2710] states that several proposals are presented in this page (“Showing available proposals locations”). For every presented proposal, the PU and/or DO location are presented (the ability to show both is dependent on the screen zoom for example). Every proposal is marked differently, so the various proposals may be distinguishable. In Fig. 27a the proposals are differentiated by colors of the icons and relevant text. The nominal proposal PU location icon [2741], DO location icon [2742] and corresponding addresses are (or may be) colored in red. Some (or all) QoS parameters and/or price of the nominal proposal [2720]:“Nominal: ETA 09:35, Price 8$” also use red font. The minimum ETA proposal PU location icon [2781], DO location icon [2783] and accompanied addresses are (or may be) colored in blue. Some (or all) QoS parameters and/or price of tire minimum ETA proposal [2731] :“Min. ETA: 09:30 also use blue font. The minimum price proposal PU location icon [2771 ], DO location icon [2773] and accompanied addresses are (or may be) colored in green. Some (or all) QoS parameters and/or price of the minimum price proposal [2732] :“Min. Price: 5$” may also use green font.

Fig 27b illustrates an additional example of multi -proposal display for the passenger, and aggregates the single proposals presented in Fig 24, Fig. 25 and Fig. 26 into a single page layout as in Fig. 27a, but the difference is that several PU and/or DO locations are presented as road segments instead of location icons. The page header [2710] states that several proposals are presented in this page (“Showing available proposals locations”). For every presented proposal the PU and/or DO location are presented (the ability to show both is dependent on the screen zoom for example) Every proposal is marked differently, so the various proposals may be distinguishable. In Fig. 27b the proposals are differentiated by colors of the icons and relevant text. The nominal proposal PU location icon [2741], DO location icon [2742] and corresponding addresses are colored in red. Some (or all) QoS parameters and/or price of the nominal proposal [2720] :“Nominal: ETA 09:35, Price 8$” also use red font. Tire minimum ETA proposal PU location (represented by a colored road segment where the pickup may be made [2761]), DO location road segment [2763] and associated address ranges (for the PU [2762]“23-30 Polk street” and for the DO [2763]“102-107 Geary street”) all have blue color. Some (or all) QoS parameters and/or price of the minimum ETA proposal [2731]:“Min ETA: 09:30” may also use blue font. ^" Fire minimum Price proposal PU location road segment [2751], DO location icon [2753] and associated addresses or address ranges are colored in green: [2752] for PU and [2754] for DO. QoS parameters and/or price of the minimum price proposal [2732] :“Min. Price: 5$” also use green font. Fig. 27c and Fig. 27d may be optional operations following Fig. 27a (or Fig. 27b), in which more exact/accurate position of modified pickup location and/or modified drop-off location may he presented to the passenger. The first operation, illustrated at Fig. 27c is to ask the user to select a proposal among those presented to him/her (any method for location selection may apply, for example by clicking on the proposed location icon in the map, by selecting the proposal from a list, etc.). In Fig. 27c a request to press a proposal location icon is presented on the screen [2715] and states“Press a proposal location icon to present street view location”. In the next operation illustrated in Fig. 27d, the passenger selects one of the presented proposals by clicking [2790] on the associated location icon [2771 ] e.g. which is the minimum price proposal of Fig. 27a. Thereafter, an image or illustration of the exact location (either pickup location or drop-off location) of the passenger is presented (e.g. as a black icon [2792]) overlaying the street view surrounding of the selected modified location [2791] Additional information regarding the direction and/or orientation of the street view image/illustration may he displayed on the screen as well (in the presented example the address and viewing direction are presented:“17 Polk street North Direction” inside the street view box [2791]).

Fig. 28a and Fig. 28b describe additional flow of proposals preparation and presentation. In these figures, the user may choose to explore additional PU and/or DO locations, in addition to the original given locations. This use case may apply for example if the nominal (baseline) proposal/s do not satisfy the user. In Fig. 28a a text that asks the passenger to select additional optional location for pickup [2810] (the same may apply to drop-off location) is displayed on the page. The selection is done in the example by clicking on the map presented on the screen [2890] (but any selection method for address/location may apply). The original PU location [2820] and DO location [2830] rnay be also presented on the map for reference. After choosing the additional optional location on the map, this new location may be displayed as a new pickup icon [2840] on the map, and the corresponding new address may be presented as a text as well [2841] In the next operation, shown in Fig. 28b, the system prepares an additional proposal for the new selected pickup location, and presents the results on the screen. The computed route of the new proposal [2870] and some (or all) QoS parameters values (partial or full QPC) [2860] (as in the current example:“ETP: 09: 14, ETA: 09:33, Car class: A, Price: 8$”) may be presented on the screen. Additional optional information that may be presented to the passenger, is the w'aikmg distance from the original pickup location to the new selected location [2841] : “Walking distance: 45m”.

Fig. 29a, wh h was mentioned above, presents an example of a QoS parameter selection in the passenger application; the parameters may be used for further optimization of proposals preparation. There are several alternatives for a process following Fig. 29a (in addition to all or any subset of those described above), all or any subset of which may be provided:

* Fig. 29b 1 presents an alternative in which, as a result of parameter/s selection, several alternative proposals with modified pickup locations (represented as road segments) [2960] are suggested to the user. In this use case (as described in Fig. 29a) the user selected the minimum ETA parameter for further proposals filtering/presentation. Therefore ETA or ETA range for each proposed road segment for pickup is presented and colored using the same color as the road segment [2951 ], [2952], [2953], [2954] The same may apply to the drop-off modified locations proposals [2970] The original locations [2921], [2922] may also be presented for better passenger map orientation. Thereafter, the user needs to select the desired PU and DO proposals if they are preferred.

• However, if marking of the proposals is associated with the QoS parameter value, it may be visually difficult to identify PU and DO locations of each proposal. Therefore, sometimes, it is better to present only one of the location types (PU or DO), and after selection of the first modified location (of PU or DO), to present the second type of modified locations for selection. This sequential process is illustrated in Fig 29c 1 and Fig. 29c2 (as an additional optional alternative). In Fig. 29c 1 only the modified pickup location proposals (as road segments [2960]) are displayed to the user in the first operation, accompanied optionally by a legend ([2951 ], [2952], [2953], [2954]). In the next operation shown in Fig. 29d, the passenger may choose one (or sometimes more) of the proposals e.g. by pressing [2981] the associated proposal location (e.g. road segment [2961]). Then only the relevant (filtered) drop-off proposals alternatives are presented ([2971] and [2972]). In the second selection operation, the passenger clicks [2982] on one of the presented DO alternatives [2971] (or sometimes more) in order to complete tire proposal selection process.

The set of the following figures: Fig. 30a, Fig. 30bl, Fig. 30c 1 and Fig. 30c2 present similar types of screens of proposals presentation and selection for different QoS parameter selection (minimum price) similarly to Fig. 29a, Fig. 29b 1, Fig. 29c 1, Fig. 29c2 and all their embodiments and description, may be applied in these cases, accordingly.

Each sentence or request or result, instead of being presented as a text on the screen, may be given/conveyed to the passenger or driver as a voice command/prompt (e.g. by using text-to-voice application).

Any of the blocks/modules/processes/actions described in the text may be performed/processed on a local computer processor and/or memory and/or on a cloud processor and/or memory .

it is appreciated that any reference herein to, or recitation of, an operation being performed is, e.g. if the operation is performed at least partly in software, intended to include both an embodiment where the operation is performed in its entirety by a server A, and also to include any type of“outsourcing” or“cloud” embodiments in which the operation, or portions thereof, is or are performed by a remote processor P (or several such), which may be deployed off-shore or“on a cloud”, and an output of the operation is then communicated to, e.g. over a suitable computer network, and used by, server A. Analogously, the remote processor P may not, itself, perform all of the operations, and, instead, foe remote processor P itself may receive output/s of portion/s of the operation from yet another processor/s P', may be deployed off-shore relative to P, or“on a cloud”, and so forth.

Also provided, excluding signals, is a computer program comprising computer program code means for performing any of the methods shown and described herein when the program is ran on at least one computer; and a computer program product, comprising a typically non-transrtory computer-usable or -readable medium e.g. non- transitory computer -usable or -readable storage medium, typically tangible, having a computer readable program code embodied therein, the computer readable program code adapted to be executed to implement any or all of the methods shown and described herein. The operations in accordance with foe teachings herein may be performed by at least one computer specially constructed for the desired purposes, or general purpose computer specially configured for the desired purpose by at least one computer program stored in a typically non-transitory computer readable storage medium. The term "non-transitory" is used herein to exclude transitory, propagating signals or waves, but to otherwise include any volatile or non-volatile computer memory technology suitable to the application.

Any suitable processor/s, display and input means may be used to process, display e.g. on a computer screen or other computer output device, store, and accept information such as information used by or generated by any of the methods and apparatus shown and described herein: the above processor/s, display and input means including computer programs, in accordance with all or any subset of the embodiments of the present invention. Any or all functionalities of the invention shown and described herein, such as but not limited to operations within flowcharts, may be performed by any all or any subset of: at least one conventional personal computer processor, workstation or other programmable device or computer or electronic computing device or processor, either general-purpose or specifically constructed, used for processing; a computer display screen and/or printer and/or speaker for displaying; machine -readable m em ory such as optical disks, CDROMs, D VDs, B!uRays, magnetic -optical discs or other discs; RAMs, ROMs, EPROMs, EEPROMs, magnetic or optical or other cards, for storing, and keyboard or mouse for accepting. Modules shown and described herein may include any one or combination or plurality of: a server, a data processor, a memory/computer storage, a communication interface, a computer program stored in memory /computer storage.

Idle term "process" as used above is intended to include any type of computation or manipulation or transformation of data represented as physical, e.g. electronic, phenomena which may occur or reside e.g. within registers and /or memories of at least one computer or processor. Use of nouns in singular form is not intended to be limiting; thus the term processor is intended to include a plurality of processing units which may be distributed or remote. The term server is intended to include plural, typically interconnected, modules running on plural respective servers, and so forth.

All operations, blocks and modules described and illustrated herein may be provided or alternatively, any subset thereof may be provided. All operations illustrated or described herein may be performed, e.g. by one or more processors, in any suitable order e.g. as shown. Each element e.g. operation, block and module described herein may have all attributes described or illustrated herein or according to other embodiments, may have any subset of the attributes described herein. The terms processor or controller or module or logic as used herein are intended to include computer microprocessors which typically have digital memory' and processing capacity, such as those available from, say Intel and Advanced Micro Devices (AMD), and any operation or functionality or computation or logic described herein may be implemented entirely or in any part on any suitable circuitry _' including any such computer microprocessor/s as well as in firmware or in hardware or any combination thereof.

It is appreciated that elements illustrated in more than one drawings, and/or elements in the written description may still be combined into a single embodiment, except if otherwise specifically clarified herewithm.

The apparatus of the present invention may include, according to certain embodiments of the invention, machine readable memory containing or otherwise storing a program of instructions which, when executed by the machine, implements all or any subset of the apparatus, methods, features and functionalities of the invention shown and described herein. Alternatively or in addition, the apparatus of the present invention may include, according to certain embodiments of the inventi on, a program as above which may be written in any conventional programming language, and optionally a machine for executing the program such as but not limited to a general purpose computer which may optionally be configured or activated in accordance with the teachings of the present invention. Any' of the teachings incorporated herein may, wherever suitable, operate on signals representative of physical objects or substances.

Any trademark occurring m the text or drawings is the property of its owner and occurs herein merely' to explain or illustrate one example of how an embodiment of the invention may be implemented.

Unless stated otherwise, terms such as, "processing", "computing".

"estimating”, "selecting", "ranking", "grading", "calculating", "determining”, "generating", "reassessing", "classifying", "generating", "producing", "stereo- matching", "registering", "detecting", "associating", " superimposing", "obtaining",

'providing", "accessing”, "setting" or the like, refer to the action and/or processes of at least one computer/s or computing system/s, or processor/s or similar electronic computing device/s or circuitry _' , that manipulate and/or transform data which may be represented as physical, such as electronic, quantities e.g. within the computing system's registers and/or memories, and/or may be pro vided on-the-fly, into other data which may be similarly represented as physical quantities within the computing system's memories, registers or other such information storage, transmission or display devices or may be provided to external factors e.g. via a suitable data network. The term “computer” should be broadly construed to cover any kind of electronic device with data processing capabilities, including, by way of non-limiting example, personal computers, servers, embedded cores, computing system, communication devices, processors (e.g digital signal processor (DSP), microcontrollers, field programmable gate array (FPGA), application specific integrated circuit (ASIC), etc.) and other electronic computing de vices. Any reference to a computer, controller or processor is intended to include one or more hardware devices e.g. chips, which may be co-located or remote from one another. Any controller or processor may for example comprise at least one CPU, DSP, FPGA or ASIC, suitably configured in accordance with the logic and functionalities described herein.

The present invention may be described, merely for clarity, in tenns of terminology specific to, or references to, particular programming languages, operating systems, browsers, system versions, individual products, protocols and the like. It will he appreciated that this terminology or such reference/s is intended to convey general principles of operation clearly and briefly, by way of example, and is not intended to limit the scope of the invention solely to a particular programming language, operating system, browser, system version, or individual product or protocol. Nonetheless, the disclosure of the standard or other professional literature defining the programming language, operating system, browser, system version, or individual product or protocol in question, is incorporated by reference herein in its entirety.

Elements separately listed herein need not be distinct components and alternatively may be the same structure. A statement that an element or feature may exist is intended to include (a) embodiments in which the element or feature exists; (b) embodiments in which the element or feature does not exist: and (c) embodiments in which the element or feature exist selectably e.g. a user may configure or select whether the element or feature does or does not exist.

Many modifications of the system herein are of course possible. For example, a given system may have all or any subset of the following characteristics:

a. QoS driven MaaS b. system configured for learning passengers preferences c. system configured for generation of Personal proposals (and, typically presentation), typically taking into account at least passenger preferences e.g. as per the embodiment/s of all or an subset of Figs 11, 14-30.

d. system provides Internal bidding

e. system generates and manages proposals for end-users during their respective periods of service/trips e.g as per the embodiment/s of all or an subset of Figs. 5-11. f. QoS-driven MaaS System (QMS) used to provide mobility services to users by managing and operating a fleet of vehicles including more than one vehicle, the QMS comprises Driver management module. Passengers MaaS module and QMS Core (QMSC)

g. passenger inserts pickup and drop-off original locations, and QMSC computes service proposals which include modified pickup or drop-off locations, and presents them to the user.

h. QMS provides proposals to at least one user that includes QoS parameters configuration and price.

i. QoS parameters configuration include one parameter.

j . QoS parameters configuration include all or any subset of these parameters:

Minimum ETP, Minimum ETA, Minimum Ride Duration, Minimum Price, Minimum Additional Passengers, Smooth Ride, Minimum walking distance. Car class, Non-smokers vehicle.

Any suitable input device, such as but not limited to a sensor, may be used to generate or otherwise provide information received by the apparatus and methods shown and described herein. Any suitable output device or display may be used to display or output information generated by the apparatus and methods shown and described herein. Any suitable processor/s may be employed to compute or generate or route, or otherwise manipulate or process information as described herein and/or to perform functionalities described herein and/or to implement any engine, interface or other system described herein. Any suitable computerized data storage e.g. computer memory' may be used to store information received by or generated by the systems shown and described herein. Functionalities shown and described herein may be divided between a server computer and a plurality of client computers. These or any oilier computerized components shown and described herein may communicate between themselves via a suitable computer network.