US20150142518A1 - System for making available for hire vehicles from a fleet aggregated from a plurality of vehicle fleets - Google Patents

System for making available for hire vehicles from a fleet aggregated from a plurality of vehicle fleets Download PDF

Info

Publication number
US20150142518A1
US20150142518A1 US14/403,123 US201314403123A US2015142518A1 US 20150142518 A1 US20150142518 A1 US 20150142518A1 US 201314403123 A US201314403123 A US 201314403123A US 2015142518 A1 US2015142518 A1 US 2015142518A1
Authority
US
United States
Prior art keywords
vehicle
journeys
module
fleet
zones
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US14/403,123
Other languages
English (en)
Inventor
João Tiago Farinha Gomes Félix
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
MOBIAG Lda
Original Assignee
MOBIAG Lda
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by MOBIAG Lda filed Critical MOBIAG Lda
Assigned to MOBIAG, LDA. reassignment MOBIAG, LDA. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: FARINHA GOMES FÉLIX, João Tiago
Publication of US20150142518A1 publication Critical patent/US20150142518A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0645—Rental transactions; Leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0201—Market modelling; Market analysis; Collecting market data
    • G06Q30/0202—Market predictions or forecasting for commercial activities
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/20—Monitoring the location of vehicles belonging to a group, e.g. fleet of vehicles, countable or determined number of vehicles

Definitions

  • the invention belongs to the technical field of fleet forecasting processes in the area of mobility, namely for optimization, operation and control of complex fleet networks.
  • Car-sharing can be defined as a system of renting cars for short periods (typically less than 1 day and usually a few hours) without human intervention and the need for additional paperwork. Usually all costs are included in the rental fee (petrol, insurance, parking, etc) and billing is based on duration of usage. Having technology to intermediate these transactions lowers the transaction costs to a level where it makes sense for users and operators to allow for these short periods of usage (and corresponding low revenue per transaction) and makes it possible to introduce a new transport system to complement the existing heavy modes. Cars are traditionally parked on the street or in public access car parks and are accessed by members who identify themselves to the system namely by means of an RFID card or a mobile phone.
  • the “bases” will typically be geographical points where multiple parking spaces will be available and where the operator can, potentially, provide an additional number of services to the users and the fleet.
  • the state of the art example at moment is the recently activateated, electric car-only Auto'Lib operation in central Paris.
  • This model despite being much more functional than previous iterations, still misses two critical points in user experience—point-to-point trips where the end point is the clients' actual destination and availability of free spaces when a user arrives at the station, which in turn prompts the need for the user to book a free space, bringing back the need for anticipated planning and restriction of freedom.
  • These problems can be mitigated but only at high infrastructural costs (increasing the number of bases and/or increasing the capacity of such bases).
  • this system will be based on a multi-platform service (Web and Mobile), where the user will have real-time access to the available cars' location and can pick the one that better fulfils her needs for that trip.
  • the on-board system will allow access to the vehicle (via an instruction from the central management system) and the user can then initiate her journey which will last for as long as needed, and finish at the users' intended destination as long as it is inside the allowed zone (which, is worth emphasising, is a major, positive distinction to the more traditional models).
  • all existing operators irrespective of the implemented model, present the same problem, namely they all work as closed systems (or “islands”). This means clients are limited to using only the vehicles made available by the operator to which it has contractualized the service.
  • a system for making available for hire and for reserving vehicles from an aggregated vehicle fleet from a plurality of vehicle fleets over a predetermined area comprising:
  • the multivariate forecasting module comprises—as inputs—time, number of vehicle journeys, number of vehicle relocations, wherein the number of vehicle journeys comprises accepted and denied vehicle journeys, and comprises—as output—the difference between forecasted supply and forecasted demand for each geographical unit of the predetermined area.
  • the number of journeys input is split into two inputs, one input for accepted vehicle journeys and one input for denied vehicle journeys.
  • the forecasting module further comprises an input for the total number of aggregated fleet vehicles.
  • the forecasting module further comprises an input for the number of third-party backup vehicle journeys.
  • the inputs of number of vehicle journeys are inputs of the accumulated number of vehicle journeys.
  • the multivariate forecasting module is an artificial neuronal network, ANN, comprising input layer neurons for each forecasting module input and output layer neurons for each geographical unit of the predetermined area, in particular a RBF ANN.
  • a preferred embodiment further comprises a travel simulation model for providing input training data to the multivariate forecasting model, wherein said travel simulation model is configured to simulate travel journeys that are not capacity capped, from an input origin/destination matrix which comprises the number of journeys for each combination of origin, destination and time period.
  • the origin/destination matrix is a smoothed origin/destination matrix, which is smoothed in the three dimensions of origin, destination and time period.
  • a preferred embodiment further comprises a zone management module for defining preferential, neutral or disfavoured vehicle drop-off dynamical zones, within said predetermined area, for each vehicle of the aggregated vehicle fleet;
  • a preferred embodiment further comprises a billing module for billing reserved car hire journeys, configured to account for the preferential, neutral or disfavoured vehicle drop-off zones for each vehicle journey.
  • the multivariate vehicle supply and demand forecasting module is configured to indicate what preferential, neutral or disfavoured vehicle drop-off dynamical zones are to be created, modified or deleted, such that vehicle availability in preferential zones, or preferential zones and neutral zones, is maximized.
  • a preferred embodiment further comprises a database of vehicle location and status managed by the fleet tracking module configured such that for each vehicle aggregated from said vehicle fleet operators, a shadow vehicle is created, tracked and its location and status updated, so as to reflect the location and status of said vehicle in the vehicle fleet operator system.
  • the preferential, neutral or disfavoured vehicle drop-off dynamical zones for each vehicle are the same for more than one of the vehicle fleet operators.
  • a preferred embodiment further comprises a heat map analysis module configured to generate tasks such that to maximize vehicle availability in preferential zones, or preferential zones and neutral zones, such tasks comprising: indicating vehicle relocation, indicating high-demand zones, indicating incentive zones, and/or indicating zones for priority intervention.
  • each vehicle record of the aggregated vehicle fleet is marked according to its availability indicated by its corresponding vehicle fleet operator.
  • a preferred embodiment further comprises a central user registry database module interfaced with said vehicle fleet operator systems, comprising all user data.
  • the preferential, neutral or disfavoured vehicle drop-off dynamical zones for each vehicle are polygons.
  • a preferred embodiment further comprises a billing module configured to split journey bills between vehicle fleet operator and the reservation module operator, according to predetermined criteria and parameters.
  • a method for operating a system comprising multivariate forecasting, by the multivariate forecasting module—from the inputs—time, number of vehicle journeys, number of vehicle relocations, wherein the number of vehicle journeys comprises accepted and denied vehicle journeys,—to the outputs—the difference between forecasted supply and forecasted demand for each geographical unit of the predetermined area.
  • the multivariate forecasting comprises training and evaluating an artificial neuronal network, ANN, in particular a RBF ANN.
  • a preferred embodiment further comprises simulating travel journeys for providing input training data to the multivariate forecasting, wherein said simulated travel journeys are not capacity capped and are simulated from an input origin/destination matrix which comprises the number of journeys for each combination of origin, destination and time period.
  • a preferred embodiment further comprises previously smoothing the origin/destination matrix by the three dimensions of origin, destination and time period.
  • It is also disclosed a computer readable medium comprising the computer program with computer program code adapted to perform any of the previously described methods when said program is run on a data processing system.
  • the system developed intends to provide car-sharing operators with a management system for their operations comprising Operations, Fleet and Customer Relations Management that is at the same time highly functional but very flexible and easy to use, with zero initial investment and low running costs.
  • a management system for their operations comprising Operations, Fleet and Customer Relations Management that is at the same time highly functional but very flexible and easy to use, with zero initial investment and low running costs.
  • such software is used by the requesting company for the management, control and optimization of the resulting network of providers.
  • Such network arises from the possibility of using this software to have multiple operators allowing roaming of their clients and assets thus creating a seamless network of vehicles to be used by all clients irrespective of which operator they have contracted the service.
  • MobiAG's proposed solution addresses these three issues in particular with aggregation.
  • aggregation as a mechanism by which the entire fleet of shared vehicles available in a given area can be used by any client of the system, irrespective of which operator they have a commercial relationship with.
  • one single entity has the capacity to access, process and analyze data relative to user demand in the past, the present and the future (through central reservations), as well as supply patterns resulting from users' journeys and using this information to manage resulting imbalances between both.
  • This allows the manager of the aggregated system, to influence it, via its users, to maximise service and resource utilization and to manage, through complex, computer-implemented processes, the entire system in a unified, optimized way, something which is currently impossible in the “island” fleet structure, as no single entity has access to the full picture in terms of demand or the ability to direct resources to where they are most effective.
  • the system operationalizes the previously discussed solution using its internally developed processes which are implemented as a software to manage all aspects of this aggregation. This materialises as:
  • the system may include data-mining and statistical forecasting algorithms able to process the vast amounts of data generated and extract the relevant insights.
  • These algorithms are any of a class of self-learning and in continuous auto-improvement process as more data is processed and absorbed.
  • Relevant external factors such as events, metrological conditions, market geography and topography and advanced reservations (see below) are also fed into the algorithms along side system data.
  • the expected outcome will automatically feed into other processes that monitor current system conditions to generate automated workflows designed to influence and modify user's behaviour with minimal human (administrator and operator) intervention.
  • the invention includes a number of solutions which address the challenges and opportunities that arise from this innovative market structure.
  • Major identified challenges are detailed below:
  • the client will have to be well informed of the factors affecting the price of each journey beforehand, or during the journey if anything changes. This means real-time display of operational zones from vehicles inside and outside the platform at the moment of reservation, available and applicable promotions and managing the bewildering array of possible pricing combinations, taking into account commercial policies applicable to every different vehicle, to every different client and, if applicable any external entities.
  • the disclosure defines zones as a geographical area, for example delimited by a polygon, overlaid on a map of the relevant market where the user can terminate his reservation at no additional cost.
  • zones can travel to any point, except to forbidden zones (which typically will be foreign countries and occasionally high-crime/dangerous areas). If the user wishes to terminate his journey at any point outside an operational zone he will be charged a variable fee designed to limit this behaviour and to make the operator whole for costs incurred with ferrying the vehicle back to an operational zone.
  • Operational Zones are defined by the operator on a vehicle by vehicle basis, using a Zone Management Interface on a CSO Management System.
  • the process is as follows—when an operator first loads the vehicle into the central database it must define the operational zones for it, either from a pre-defined standard list (general city centre for a given market), from its own personalized list based on zones he is already using in for other vehicles, or by drawing a new zone, e.g. a polygon, in the Zones Management Editor.
  • This flexibility is one of the most important features that allow a single system to support 4 distinct car-sharing models as previously presented.
  • a vehicle can have multiple operational zones (for operators with operations in multiple markets for instance) and that zones can be edited at any point in time in the CSO Management System.
  • External Partners defined as partners of the system operating under external systems, who may not have zoning capabilities
  • the system will store zones for each vehicle to be applied to the “shadow vehicle” whenever it is logged on to the platform.
  • the process of designing zones will happen when an External Partner initiates its relationship with the present disclosure system but the Partner's will have remote access to the Zone Management Editor should they wish to modify this at any point in the future.
  • the Zoning tool is one of the most instrumental in supply and demand management, particularly on the supply side. It accomplishes this by allowing the managing company to dynamically create “high demand zones” (where users have a benefit if they finish their journey inside that area) and “bonus areas”, typically next to a “high-demand” area, where users will have a bonus for starting their journeys (to incentivize a spreading of demand).
  • An easily updatable Zoning tool also allows for longer-term supply management by allowing operators to swap vehicles between themselves and for an operator to change markets quickly and temporarily (like the transferring from the capital to the coast in Summer), thus allowing the system to adapt much faster to demand shifts.
  • the power of the Zoning tool is extended as it is via this module that Operators and External Entities can define “promotion zones”, zones where the conditions of the pricing plan or promotion apply. It is also with recourse to this tool that the system can create “High Demand Zones” that are posted to all operators, based on the supply/demand analysis and forecasting software discussed later.
  • the present disclosure developed a process to display this information to the users in a simple and readily understandable way.
  • the user when choosing a car that fits his needs at any given time will, before concluding the reservation, be shown a map of the Operational Zone(s) for that particular vehicle. If his destination lies outside the Operational Zone she could or should choose another vehicle, or alternatively, supply the destination and be shown an estimate of the penalty cost so she can make a fully informed decision. In any case, it is preferred that if the user tries to close a reservation outside an Operational Zone she will always be shown the Penalty Fee value for that action and will have to accept it before closing his reservation.
  • This may be based on a client-server architecture to optimize performance and resource usage on the client side and to preserve system security and data integrity as much as possible. It is believed that the devised process is unique in that it allows the present system to be fully utilized irrespective of technological capabilities of the clients' system, as it is possible to complement several shortcomings of current systems (lack of a zoning tool, or poor marketing campaign implementation options, for example).
  • One-way car-sharing users are not obliged to return the car to the original pick-up location. This creates potential in-balances between areas, as travel demand is usually in-balanced (e.g. pendular movements from home to work in the morning peak time). This may be compensated by relocating cars from areas of forecasted low demand to areas of forecasted high demand (e.g. directly by employees or by providing user incentives like free rentals in order to increase drop-offs in the desired areas). As it necessitates time and resources to move the required cars, it is usually necessary to forecast demand such that high demand is met by previously initiating the relocation of cars such that these will be available when required.
  • pick-ups and/or returns maybe carried in specific base stations, though the more general and difficult problem does not have base stations.
  • Car demand involves 4 main factors—number of clients, number of vehicles, time and location.
  • Car demand clients requiring a car
  • car supply vehicles available
  • Car demand clients requiring a car
  • car supply vehicles available
  • the definitive availability of the vehicle is only known when the drop off is completed.
  • a forecasting module is thus described for the above purposes.
  • a density map is used that links supply and demand, such map having space and time dimensions.
  • the content of the map is the imbalance, whether actual or forecasted, between supply and demand.
  • Such a map can be two-dimensional grid representation of space (see FIG. 10 ).
  • Such a map can also represent base-stations—if used—by mapping a specific cell to each base-station. As the grid map will usually cover a large area, with multiple sub-areas of interest, the number of cells (columns by lines) is normally fairly large.
  • a multivariate vehicle supply and demand forecasting model is suitable for this task.
  • the forecasting may be split according to vehicle class by using multiple models, one for each class.
  • One of the suitable multivariate models is a model comprising artificial neuronal networks (ANN), in particular of the type Radial Basis Function (RBF) as these are well suited for models with a large number of outputs.
  • ANN artificial neuronal networks
  • RBF Radial Basis Function
  • One of the suitable RBF ANN models involves three neuron layers one layer for inputs, one layer for outputs and a middle layer of so-called ‘hidden’ neurons.
  • the input data in most embodiments comprises vehicle journeys: actual client journeys (demand that was met), staff vehicle relocations, denied client journeys for lack of supply (unmet demand), maximum available supply (number of fleet vehicles), demand met by use of third-party backup fleets (e.g. taxy journeys) whereas the output data comprises the quantity of the difference between forecasted supply and forecasted demand for each geographical map unit (or cell).
  • one of the inputs is time (or time-period), such that the remaining inputs and outputs are then correlated by the training data set to a specific time.
  • FIG. 11 A typical embodiment is shown in FIG. 11 , but the disclosure is pertinent to other embodiments in this case, 3 input layer neurons (time, accumulated total journeys, accumulated total relocations), 4 hidden (intermediate) layer neurons and as many output layer neurons as map units.
  • the number of hidden layer neurons is defined according to methods known in the art, usually the number of hidden layer neurons that produces the best quality forecasts and does not over fit the training data set (in particular, the minimum of hidden layer neurons that attains these two goals).
  • Inputs and/or outputs are preferably normalized to a standard scale, in some embodiments between 0 and 1. Obviously, when obtaining normalized forecasted results the output must then be converted to actual real-life scale.
  • the time input when the time input is normalized, it will range from 0 to 1. In particular, 0 will correspond to the first time instant being forecast (e.g. 6 am) and 1 will correspond to the last time being forecast (e.g. 10 pm). In particular, it may also range in discrete steps according to each time period (e.g. if there are ten time periods to be forecast, the input will be 0.0, 0.1, 0.2, . . . 0.9, 1.0).
  • the output neurons are preferably each related to a specific grid cell.
  • the number of cells (or inversely, the size of the cells) is a compromise between better detail (more cells, smaller cells) and lighter computational workload (less cells, larger cells).
  • time is preferably not an output of the output neurons of the model.
  • outputs when operating the forecasting module, can have negative values, in particular when the inputs and training set comprise all possible demand—negative values simply show unmet demand (demand outstripping capacity).
  • three inputs can be used—time (or time-period); total demand (number of journeys, whether accepted or rejected); number of relocations.
  • time or time-period
  • total demand number of journeys, whether accepted or rejected
  • number of relocations are the accumulated total from the first forecasting time.
  • the total demand (number of journeys) input can be split into two separate inputs—accepted journeys (met demand) and rejected journeys (unmet demand). In particular, these are the accumulated total from the first forecasting time.
  • a further input can be added—maximum available supply (number of fleet vehicles). This number is usually constant; not varying along the forecasting period, but it may indeed vary because of vehicle malfunction or planned maintenance, where vehicles are removed from the available car pool. Furthermore, in the case of aggregation of various car pools, the number of vehicles may vary substantially along the forecasting period—because the number of vehicles available for aggregation is beyond the control of the aggregating car pool.
  • a further input can be added for demand met by the use of third-party backup fleets (e.g. taxy journeys).
  • the demand that was met by the use of third-party backup fleets may be not included in another demand input (e.g. accepted journeys—met demand).
  • the outputs reflect car availability vs demand.
  • the vehicles may be scattered randomly at the beginning of the forecasting period—this enables that the full map is used for training and avoids any potential bias.
  • relocations may be carried out using simple heuristics or more complex rules or systems—it is preferred that relocations are carried out using the same rules/criteria during both training and forecasting phases.
  • the size of the fleet may be artificially very high such that only rarely, or never, do capacity constrains occur.
  • This has the advantage that the training is phase is not biased by a limited capacity and will better predict in the operation phase all potential demand.
  • the various input/output formats described have the advantage of being particularly compact forms that provide the required output detail, while at the same time using straightforward input variables.
  • the forecasting module incorporates the required output maps.
  • the forecasting module is fed using overall operation parameters (e.g. number of journeys), not requiring in-depth knowledge (e.g. specific origins, destinations, durations or lengths of specific journeys). This way the model, while providing robust forecasts, is very straightforward to use, easy to implement, reliable and predictable.
  • neuronal network topology does not require that an actual grid is used, other 2-D cell layouts are thus possible, for example making each cell correspond to a specific urban or city area (which usually are not part of a grid, e.g. London boroughs).
  • separate forecasting models are used according to the timescale involved. Though the same model can be used to forecast all time periods along the desired forecasting timescale, say a week, preferably different cascading models are used. For example, some embodiments comprise combining a day model using periods in minutes or hours, with a week model using periods in hours or days, and, optionally, with a seasonal model using periods in weeks or months.
  • the forecasting model comprises relocation data and is able to accommodate different relocation policies of each sub-pool, by simply including such relocations in the forecast.
  • ‘shadow-cars’ may be used. As these do not have to comply with the same rules of the system's own car pool, managing this supply and demand is more difficult.
  • the forecasting model comprises own car pool travel data and third-party car travel data as it is then able to accommodate these different car pools, by simply including such travel data in a global forecast.
  • a travel simulation model is described below for the purpose of providing input training data to the forecasting model described above.
  • a second model that simulates travel based on actual available travel data is preferably used in some embodiments for training the first model, having the advantage of providing travel data that is not capacity capped to the forecasting model.
  • the origin/destination matrix is smoothed by using an appropriate smoothing algorithm of those known in the art (least squares, another neuronal network, among others). For example, taking origin from line 1 of FIG. 12 , one obtains the probability of destinations as in FIG. 13 . This can be smoothed and normalized as in FIG. 14 . This is an example, as smoothing is preferably carried out in three dimensions (origin, destination, time) of the matrix.
  • a journey can then be simulated—by inverting the accumulated probability curve and a lookup based on a random number generation.
  • the time period is first determined and then the origin/destination is determined (two-step approach).
  • the travel simulation model also has the advantage of providing input data to the forecasting model, even when no actual data is available (for example, bootstrapping the forecast model when no existing car-sharing system data is available).
  • FIG. 1 Schematic Representation of the Central Reservation Engine
  • the Central Reservation Engine is the implementation of a key process in the successful management of an aggregated car-sharing system.
  • the Engine receives an input from an end user, who is previously authenticated and authorized to perform reservations in the system.
  • the user In the first step, the user must define intended start location, intended start time, intended vehicle class (optional) and how many notifications he wishes to receive, as well as via which channel.
  • the reservation process begins with the user selecting whether he is looking for an immediate reservation, i.e. a car to start using right now or an anticipated reservation, where usage will not happen immediately. If he picks immediate reservation he will be shown a list (or map, depending on the chosen view) of available vehicles, real-time location of said vehicles and respective details, including price plan, operational zones, etc. Users can then choose their preferred vehicle and initiate a reservation (see FIG. 1.1 ).
  • the user chooses to perform an anticipated reservation, he must first choose if this is a “Deterministic” reservation, where he will be guaranteed a specific vehicle on his reservation date (except in rare cases where the previous user might have not arrived on time or the vehicle had to be taken out of operation). These vehicles must be picked from a small pool of operators who will work under the “round-trip” model previously discussed, and, hence, can determine at any point in time whether the vehicle will be available or not. To this end, the user must state in the reservation process not just his pick-up time, but also the drop-off time, and must, naturally, perform a return trip.
  • the client will not be performing a true “reservation” in the strict sense of the word, but he will be flagging an intention of using a vehicle at that specific point in time.
  • the request After the user submits his request, the request will be logged and a time stamp of [Reservation Start Time ⁇ X hours], where X varies with vehicle class and is such that a statistical certainty, say 99%, exists that a vehicle meeting the reservations' criteria will be available, will be logged with that entry.
  • this request will be tested to check whether the time stamped time is in the past or the future relative to current time. If in the future, user will be notified that his request has been accepted and the request will marked “Accepted” and logged in the database for later processing. If the current time stamp is in the past, the system will calculate the expected minimum time interval to obtain at least one positive match to the request criteria with over statistical certainty, say 90%.
  • This expected time is obtained from the Dynamic Heat Map, generated by the Supply/Demand Management System, for the specific class of vehicle, in the intended start location and for the intended reservation start time.
  • the request enters the second test where the time difference between current time and reservation start time will be tested against the calculated minimum time interval. If the minimum time interval is longer than the difference between current time and reservation time the user will be notified that the reservation is not accepted and the request becomes an active search process where the user receives notifications whenever a vehicle that matches the request is available. If the minimum time interval is shorter than the difference between current time and reservation time the system tests whether this request has been previously accepted or not. The test looks for the “Accepted” stamp that was added to the request after the first test.
  • the request has not been stamped “Accepted”, it gets stamped with the actual calculated minimum time, stamped as “Accepted” which generates a notification to the user and it gets logged on the database for later processing. If it been previously accepted, then the request becomes an active search process where the user receives notifications whenever a vehicle that matches the request is available. Requests that were logged on the database are sorted from shortest to longest difference between current time and time stamp time and will be continuously fed, in a linear fashion, through the first decision step to test whether the condition that current time is still before time stamp time, thus re-entering the loop.
  • FIG. 2 Schematic Representation of Dynamic Multivariate Supply/Demand Forecasting and Management System
  • the Dynamic Multivariate Supply/Demand Forecasting and Management System comprises the core processes used to actively manage the system to attain the stated goals of service level and occupancy rate maximization.
  • the System is built around three distinct sub-systems, that not only interact within this system, but also publish information to be used by other modules and systems.
  • the three main sub-systems are: Modelling and Forecasting Algorithmics, Imbalance Analysis and Tasking, Active System Management.
  • the first of these sub-systems is the most innovative in its conception and application to the problem of managing an aggregated mobility system. It comprises 3 main modules: the Algorithmic Learning Module (ALM), the Supply/Demand Analysis Module (SDAM) and the Heat Map Generator Module (HMGM).
  • ALM Algorithmic Learning Module
  • SDAM Supply/Demand Analysis Module
  • HMGM Heat Map Generator Module
  • the first module is dedicated to continuous improvement and analysis of the algorithms used to predict supply/demand.
  • This module will pull historical data from the central database of the Inputs to be used in forecasting, namely, Time of day, year, month, calendar day, week day, used to discretize and compare seasonality, scheduled events that impact demand, such as school holiday periods or public holidays, and unscheduled events like public transport industrial action or a music festival.
  • the weather is a large influencer of demand for these types of services and it may be an input as well as geo-topographical and demographical data for the market being analysed (this will be obtained from the central database as well since it is not expected to be dynamic).
  • Both historical series and current values are organized in some embodiments in a star-based architecture running on top of a data-mart solution.
  • Historic series of these inputs feed into the Algorithmic Learning Module and present and forecasted values of the same variables will be inputs for the Supply/Demand Analysis Module.
  • the ALM pulls historical demand and supply from the central database as historical reservations, trips with start point in the segment and density maps for each segment divided by car class. This division is of paramount importance as car classes will be skewed and for clients it's very important to be able to choose the type of car that is convenient to them.
  • the ALM uses, in some embodiments, algorithms based on Multiple Linear Regression and Artificial Neural Networks for situations with solid historical data and relies on a third algorithm, based on a Hidden Markov Model (or other Bayesian network models) to improve performance in transient periods.
  • These algorithms are Learning Algorithms and by continuous analysis of actual system behavior and comparison with forecasted system behavior (continuous feedback loop) are self-improving, increasing performance over time. It is important to state that is some embodiments it is expected to use similar algorithms across markets but that each segment may then have specific parameters that will be continuously tuned for better forecasting performance.
  • Ensemble Forecast a forecast that combines all forecasts produced by the different algorithms to obtain a single forecast with variance smaller than the variance of any of its components.
  • the following module takes the forecasting algorithms produced by ALM and feed into them all the above mentioned information (Inputs 1 through 4), optionally plus any requests registered on the database for the analysis period, returning the expected number of vehicles and the expected demand for vehicles in each discreet segment of the grid (e.g. segments will start at 1 km-side squares, and resolution may be improved over time).
  • These forecasts can be made for each segment, for each vehicle class and in, e.g. 15 minutes, intervals which means approximately 59,000 segment calculations per day just for an embodiment for Central London, by any means a daunting task and one that needs optimization of the algorithms so that the hardware necessary to accomplish this will be within reach of a small scale organization.
  • the expected result of this Analysis is a segment-by-segment forecast of the difference between available vehicles and demanded vehicles, which may be referred to as the Supply/Demand Imbalance. Furthermore, treating the same set of results using a different statistical model it is intended to be able to accurately forecast (say, to within 95% confidence) the average time between vehicles of each class, a result that is very important in most embodiments for the functioning of the previously described Reservation Engine.
  • the third model of the Modelling and Forecasting Algorithmics sub-system will generate a “heat map” for the close future time, say the next 12 h, defined as a geographical map on top of which will be overlaid the segment grid, for example with each segment coloured a specific shade based on the size (and positive or negative sign) of the imbalance. It is this map that is shown to operators in the notification part and, coupled with the tasks generated by the Active System Management sub-system, allows operators and the central system to dynamically influence both supply and demand using pricing (namely through the mechanism of micro-promotions and reward points). It also feeds through to the Imbalance Analysis and Tasking sub-system for processing and analysis.
  • the Map Once the map enters the Imbalance Analysis and Tasking sub-system it is processed by the “Heat Map Analysis” module.
  • This module uses tracking and Fleet management inputs to calculate if any current trips can be finished in the areas of greater need and, for imbalances detected early, prepare the tasks for owners to send out to the Task Market or to specific service providers, such as relocating a specific class of vehicle or redistribute a higher concentration than needed.
  • the output is a list of actionable tasks (a task includes vehicle ID, start point, finish point and compensation, for example) aimed at operators which actively contribute to a more efficient running of the aggregate system.
  • the previous output finally enters into the final stage of analysis, Active System Management.
  • the system now has a list of tasks for the next few hours (depending of what is determined by the analysis module) but not all have the same value to the system and, hence, are worth the same compensation.
  • the operator of the system of the present disclosure as aggregator, is in a position to attribute a value to each task based on its relevance to the system and revenue potential.
  • This ranking and valuation is performed by the Task Processor Module (TPM) which receives inputs from the Heat Map Analysis module and a “helper” module called “Dynamic Task Pricing Matrix” (DTPM).
  • TPM Task Processor Module
  • DTPM Dynamic Task Pricing Matrix
  • DTPM will receive the same hyperspace-defining inputs as Algorithmic Learning Module (ALM) and the Supply/Demand Analysis Module (SDAM) so as to be able to characterize segments correctly and more return more accurate forecasts that actually take into account the full set of variables in use throughout the system
  • ALM Algorithmic Learning Module
  • SDAM Supply/Demand Analysis Module
  • FIG. 3 Schematic Representation of External Partners Interface System
  • the system of the present disclosure is able to offer to its clients a Car-sharing Operations Management System. Because some operators may be reluctant to give up their legacy systems and because of the system's nature as an aggregator it may need to be ready to interface with said systems.
  • Integration starts with a operator-side client that will read the clients equivalent of the Central Database whenever queried by the its system-side server pair.
  • the client software will also be responsible for “translating” any information it posts to the server to the system's data structure to ensure onward compatibility.
  • This client-server architecture limits hardware load and improves data security for both sides.
  • the Interface system will create “shadow” cars in the system's Fleet Management Module and any interaction from the system's clients with an external vehicle will be handled as if it were a system vehicle, with all information pertaining to the vehicle and the trip being recorded on the system's platform.
  • the system's server will either ping the vehicle's On Board Systems directly or will regularly ping the External Partner's system for the minimum required information (depending on technological solutions employed and commercial agreements).
  • the system will suggest to the Partner, during the initial stages, to define a operator-level zone that will be stored in the system and will be activated whenever the “shadow” cars are logged on to the system.
  • “Shadow” cars are in some embodiments implemented by communicating car availability asynchronously. This has the benefit of requiring lower computational resources and allowing a less strict use of the available car pools thus taking advantage of the forecasting model.
  • Aggregated car-pools periodically publish to a central server only general information—car ID (e.g. license plate), car availability status (free/busy), current location. Thus, no full data is published or communicated, e.g. future reservation data or maintenance periods.
  • the forecasting model takes these cars into account together with all other supply data.
  • the system “pings” the car (confirms with the on-board system) that the vehicle is still available, because availability is not strictly managed (there is no future booking) and the car may have been taken by someone else in the meantime.
  • FIG. 4 Schematic Representation of the Journey Rating & Billing Engine and Invoicing System
  • the implemented process that enables operations in roaming, aggregation of multiple operators and service providers by processing of all transactions performed inside the present disclosure's system is based around the Journey, as previously described.
  • the Journey object is created by the Reservations Module after a user gives the command to reserve a vehicle and this command is validated by the CRM Module, and exists in two states, a transient one that exists only for the duration of the transaction and a persistent one that records processed information.
  • the first state registers all relevant information generated by system in a raw state. Recorded information includes start and finish time, start and finish time of motor running, all location points sent by the vehicle OBS and any incidents that generate automated reporting, initial fuel and final fuel, identification of the vehicle used, etc.
  • the system will automatically process this information (or a copy thereof in case the journey is still running) in the Journey Processing Module.
  • This module is responsible for calculating the relevant data from the raw data, including journey time, distance travelled, fuel consumption, itinerary plus logging any incidents or events (positive and negative) that might have been generated on this journey.
  • This data is stored in the persistent state of the Journey object and is used to rate the journey in the next step, the Billing & Rating Module.
  • the system proposed has been described mainly based on the free-float model, but its flexibility allows it to enable any of the 4 operational models to ensure easier acceptance from incumbents and individuals.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Tourism & Hospitality (AREA)
  • Data Mining & Analysis (AREA)
  • Game Theory and Decision Science (AREA)
  • Quality & Reliability (AREA)
  • Operations Research (AREA)
  • Human Resources & Organizations (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
US14/403,123 2012-05-22 2013-05-22 System for making available for hire vehicles from a fleet aggregated from a plurality of vehicle fleets Abandoned US20150142518A1 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
PT106323 2012-05-22
PT10632312 2012-05-22
PCT/IB2013/054241 WO2013175418A1 (fr) 2012-05-22 2013-05-22 Système pour rendre disponible la location de véhicules d'un parc agrégé à partir d'une pluralité de parcs de véhicules

Publications (1)

Publication Number Publication Date
US20150142518A1 true US20150142518A1 (en) 2015-05-21

Family

ID=48747640

Family Applications (1)

Application Number Title Priority Date Filing Date
US14/403,123 Abandoned US20150142518A1 (en) 2012-05-22 2013-05-22 System for making available for hire vehicles from a fleet aggregated from a plurality of vehicle fleets

Country Status (4)

Country Link
US (1) US20150142518A1 (fr)
EP (1) EP2852924A1 (fr)
CA (1) CA2874200A1 (fr)
WO (1) WO2013175418A1 (fr)

Cited By (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160364669A1 (en) * 2015-06-12 2016-12-15 Sap Se Dynamic location recommendation for public service vehicles
US20160364824A1 (en) * 2015-06-15 2016-12-15 International Business Machines Corporation Managing transportation deployment using customer activity
US20170301054A1 (en) * 2014-09-03 2017-10-19 Meru Cab Company Private Limited Dynamic forecasting for forward reservation of cab
US20190078901A1 (en) * 2017-09-12 2019-03-14 Uber Technologies, Inc. Promoting user compliance with adaptive checkpoints
US10417585B2 (en) * 2014-01-31 2019-09-17 Bluecarsharing Method and system for rebalancing a facility for shared use of vehicles, and facility implementing such a method and/or system
CN110264023A (zh) * 2018-03-12 2019-09-20 丰田自动车株式会社 共享车辆管理服务器和存储共享车辆管理程序的非暂时性存储介质
US10559209B2 (en) * 2016-11-10 2020-02-11 Sap Se Vehicle position planning
CN110945451A (zh) * 2017-07-28 2020-03-31 纽诺有限公司 用于特殊产品和服务递送的机器人载具的机队
CN112602110A (zh) * 2018-08-24 2021-04-02 株式会社东芝 合乘车辆用需求预测装置、合乘车辆用需求预测方法及程序
US20210110416A1 (en) * 2019-10-11 2021-04-15 cg42 LLC Analytics system and method for building an autonomous vehicle deployment readiness model for a geographic area
US11055932B2 (en) * 2019-05-08 2021-07-06 Honeywell International Inc. Usage-based maintenance service system
CN113269427A (zh) * 2021-05-19 2021-08-17 安徽中科美络信息技术有限公司 一种公务出行任务调度管理方法及系统
US11107304B1 (en) 2020-04-20 2021-08-31 Geotab Inc. Method for sharing and monitoring vehicles
US11107009B2 (en) 2015-06-15 2021-08-31 International Business Machines Corporation Managing user transportation needs without user intervention
EP3901867A1 (fr) * 2020-04-20 2021-10-27 GEOTAB Inc. Dispositif de gestion de stockage de véhicule partagé
EP3901866A1 (fr) * 2020-04-20 2021-10-27 GEOTAB Inc. Système de gestion du stockage d'un véhicule partagé
EP3901868A3 (fr) * 2020-04-20 2021-11-10 GEOTAB Inc. Procédé de gestion du stockage de véhicule partagé
US11210612B2 (en) 2020-04-20 2021-12-28 Geotab Inc. Method for shared vehicle maintenance and recovery
US20220198352A1 (en) * 2019-06-13 2022-06-23 Bayerische Motoren Werke Aktiengesellschaft System and Method for Vehicle Relocation
US11429910B1 (en) 2021-08-05 2022-08-30 Transit Labs Inc. Dynamic scheduling of driver breaks in a ride-sharing service
US11427140B2 (en) 2020-04-20 2022-08-30 Geotab Inc. Shared vehicle I/O expander
US11537955B2 (en) 2020-04-20 2022-12-27 Geotab Inc. Device for shared vehicle utilization management
US11605031B2 (en) 2020-04-20 2023-03-14 Geotab Inc. System for shared vehicle utilization management
US11605032B2 (en) 2020-04-20 2023-03-14 Geotab Inc. System for shared vehicle maintenance and recovery
US11613265B2 (en) 2020-04-20 2023-03-28 Geotab Inc. Device for shared vehicle maintenance and recovery
CN116188052A (zh) * 2023-04-24 2023-05-30 北京阿帕科蓝科技有限公司 共享车辆的投放方法、装置、计算机设备和存储介质
WO2023136011A1 (fr) * 2022-01-14 2023-07-20 住友電気工業株式会社 Dispositif de gestion de réservation de véhicule, procédé de gestion de réservation de véhicule et programme de gestion de réservation de véhicule
CN117217243A (zh) * 2023-09-13 2023-12-12 广州莲雾科技有限公司 一种工器具自动借还管理系统

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10915978B2 (en) 2014-05-14 2021-02-09 Ilan VAN DER BERG Integrated ride sharing system and method for fleet management systems
WO2016122292A1 (fr) * 2015-01-27 2016-08-04 Velez Villa Mario Manuel Procédé pour pronostiquer la demande de produits non saisonniers et non périssables
CN107437129B (zh) * 2016-05-25 2022-04-26 北京嘀嘀无限科技发展有限公司 预约单处理方法及服务器
CN107045673B (zh) * 2017-03-31 2020-09-29 杭州电子科技大学 基于堆模型融合的公共自行车流量变化量预测方法

Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030014286A1 (en) * 2001-07-16 2003-01-16 Cappellini Pablo Dario Search and retrieval system of transportation-related flexibly defined paths
US20040024621A1 (en) * 2001-10-12 2004-02-05 Read Lewis C. Viable alternative to private vehicles in urban areas
US20060074707A1 (en) * 2004-10-06 2006-04-06 Schuette Thomas A Method and system for user management of a fleet of vehicles including long term fleet planning
US20060224400A1 (en) * 2005-04-01 2006-10-05 Microsoft Corporation Business event notifications on aggregated thresholds
US20090030862A1 (en) * 2007-03-20 2009-01-29 Gary King System for estimating a distribution of message content categories in source data
US20090066641A1 (en) * 2005-03-10 2009-03-12 Motus Corporation Methods and Systems for Interpretation and Processing of Data Streams
US20090182565A1 (en) * 2008-01-10 2009-07-16 At&T Services, Inc. Aiding Creation of Service Offers Associated with a Service Delivery Framework
US20110130857A1 (en) * 2009-11-30 2011-06-02 Exxonmobil Research And Engineering Company Method and apparatus for optimizing a performance index of a bulk product blending and packaging plant
US20110320256A1 (en) * 2009-12-11 2011-12-29 Jean-Louis Florucci City parking services with area based loyalty programs
US20120116825A1 (en) * 2007-04-30 2012-05-10 Georges Bernard Marie Paul Antoine Gallais Methods and system making it possible to place an individual public vehicle at the disposal of a user
US20120265580A1 (en) * 2009-11-24 2012-10-18 Ntt Docomo, Inc. Demand prediction device and demand prediction method

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4657728B2 (ja) * 2002-08-29 2011-03-23 アイティス・ホールディングス・ピーエルシー トラフィック情報を提供するための装置および方法
JP2004110462A (ja) * 2002-09-19 2004-04-08 Nec Corp 車両共同利用の予約方法及びそのシステム
US8912883B2 (en) * 2010-10-27 2014-12-16 Ncr Corporation Techniques for automating rental car transactions

Patent Citations (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030014286A1 (en) * 2001-07-16 2003-01-16 Cappellini Pablo Dario Search and retrieval system of transportation-related flexibly defined paths
US20040024621A1 (en) * 2001-10-12 2004-02-05 Read Lewis C. Viable alternative to private vehicles in urban areas
US20060074707A1 (en) * 2004-10-06 2006-04-06 Schuette Thomas A Method and system for user management of a fleet of vehicles including long term fleet planning
US20090066641A1 (en) * 2005-03-10 2009-03-12 Motus Corporation Methods and Systems for Interpretation and Processing of Data Streams
US20060224400A1 (en) * 2005-04-01 2006-10-05 Microsoft Corporation Business event notifications on aggregated thresholds
US20090030862A1 (en) * 2007-03-20 2009-01-29 Gary King System for estimating a distribution of message content categories in source data
US20120116825A1 (en) * 2007-04-30 2012-05-10 Georges Bernard Marie Paul Antoine Gallais Methods and system making it possible to place an individual public vehicle at the disposal of a user
US20090182565A1 (en) * 2008-01-10 2009-07-16 At&T Services, Inc. Aiding Creation of Service Offers Associated with a Service Delivery Framework
US20120265580A1 (en) * 2009-11-24 2012-10-18 Ntt Docomo, Inc. Demand prediction device and demand prediction method
US20110130857A1 (en) * 2009-11-30 2011-06-02 Exxonmobil Research And Engineering Company Method and apparatus for optimizing a performance index of a bulk product blending and packaging plant
US20110320256A1 (en) * 2009-12-11 2011-12-29 Jean-Louis Florucci City parking services with area based loyalty programs

Cited By (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10417585B2 (en) * 2014-01-31 2019-09-17 Bluecarsharing Method and system for rebalancing a facility for shared use of vehicles, and facility implementing such a method and/or system
US10593005B2 (en) * 2014-09-03 2020-03-17 Meru Cab Company Private Limited Dynamic forecasting for forward reservation of cab
US20170301054A1 (en) * 2014-09-03 2017-10-19 Meru Cab Company Private Limited Dynamic forecasting for forward reservation of cab
US10360521B2 (en) * 2015-06-12 2019-07-23 Sap Se Dynamic location recommendation for public service vehicles
US20160364669A1 (en) * 2015-06-12 2016-12-15 Sap Se Dynamic location recommendation for public service vehicles
US20160364824A1 (en) * 2015-06-15 2016-12-15 International Business Machines Corporation Managing transportation deployment using customer activity
US10984498B2 (en) * 2015-06-15 2021-04-20 International Business Machines Corporation Managing transportation deployment using customer activity
US11107009B2 (en) 2015-06-15 2021-08-31 International Business Machines Corporation Managing user transportation needs without user intervention
US10559209B2 (en) * 2016-11-10 2020-02-11 Sap Se Vehicle position planning
CN110945451A (zh) * 2017-07-28 2020-03-31 纽诺有限公司 用于特殊产品和服务递送的机器人载具的机队
US10732000B2 (en) * 2017-09-12 2020-08-04 Uber Technologies, Inc. Promoting user compliance with adaptive checkpoints
US20190078901A1 (en) * 2017-09-12 2019-03-14 Uber Technologies, Inc. Promoting user compliance with adaptive checkpoints
CN110264023A (zh) * 2018-03-12 2019-09-20 丰田自动车株式会社 共享车辆管理服务器和存储共享车辆管理程序的非暂时性存储介质
CN112602110A (zh) * 2018-08-24 2021-04-02 株式会社东芝 合乘车辆用需求预测装置、合乘车辆用需求预测方法及程序
US20210174270A1 (en) * 2018-08-24 2021-06-10 Kabushiki Kaisha Toshiba Rideshare vehicle demand forecasting device, method for forecasting rideshare vehicle demand, and storage medium
US11704943B2 (en) 2019-05-08 2023-07-18 Honeywell International Inc. Usage-based maintenance service system
US11055932B2 (en) * 2019-05-08 2021-07-06 Honeywell International Inc. Usage-based maintenance service system
US20220198352A1 (en) * 2019-06-13 2022-06-23 Bayerische Motoren Werke Aktiengesellschaft System and Method for Vehicle Relocation
US20210110416A1 (en) * 2019-10-11 2021-04-15 cg42 LLC Analytics system and method for building an autonomous vehicle deployment readiness model for a geographic area
US11427140B2 (en) 2020-04-20 2022-08-30 Geotab Inc. Shared vehicle I/O expander
US11605032B2 (en) 2020-04-20 2023-03-14 Geotab Inc. System for shared vehicle maintenance and recovery
EP3901868A3 (fr) * 2020-04-20 2021-11-10 GEOTAB Inc. Procédé de gestion du stockage de véhicule partagé
US11210612B2 (en) 2020-04-20 2021-12-28 Geotab Inc. Method for shared vehicle maintenance and recovery
US11537955B2 (en) 2020-04-20 2022-12-27 Geotab Inc. Device for shared vehicle utilization management
EP3901867A1 (fr) * 2020-04-20 2021-10-27 GEOTAB Inc. Dispositif de gestion de stockage de véhicule partagé
EP3901866A1 (fr) * 2020-04-20 2021-10-27 GEOTAB Inc. Système de gestion du stockage d'un véhicule partagé
US11613265B2 (en) 2020-04-20 2023-03-28 Geotab Inc. Device for shared vehicle maintenance and recovery
US11361596B2 (en) 2020-04-20 2022-06-14 Geotab Inc. Method for shared vehicle storage management
US11605031B2 (en) 2020-04-20 2023-03-14 Geotab Inc. System for shared vehicle utilization management
US11107304B1 (en) 2020-04-20 2021-08-31 Geotab Inc. Method for sharing and monitoring vehicles
CN113269427A (zh) * 2021-05-19 2021-08-17 安徽中科美络信息技术有限公司 一种公务出行任务调度管理方法及系统
US11429910B1 (en) 2021-08-05 2022-08-30 Transit Labs Inc. Dynamic scheduling of driver breaks in a ride-sharing service
WO2023136011A1 (fr) * 2022-01-14 2023-07-20 住友電気工業株式会社 Dispositif de gestion de réservation de véhicule, procédé de gestion de réservation de véhicule et programme de gestion de réservation de véhicule
CN116188052A (zh) * 2023-04-24 2023-05-30 北京阿帕科蓝科技有限公司 共享车辆的投放方法、装置、计算机设备和存储介质
CN117217243A (zh) * 2023-09-13 2023-12-12 广州莲雾科技有限公司 一种工器具自动借还管理系统

Also Published As

Publication number Publication date
WO2013175418A1 (fr) 2013-11-28
EP2852924A1 (fr) 2015-04-01
CA2874200A1 (fr) 2013-11-28

Similar Documents

Publication Publication Date Title
US20150142518A1 (en) System for making available for hire vehicles from a fleet aggregated from a plurality of vehicle fleets
Boyacı et al. An integrated optimization-simulation framework for vehicle and personnel relocations of electric carsharing systems with reservations
Perboli et al. Business models and tariff simulation in car-sharing services
Dandl et al. Comparing future autonomous electric taxis with an existing free-floating carsharing system
Pevec et al. A data‐driven statistical approach for extending electric vehicle charging infrastructure
Dlugosch et al. Combining analytics and simulation methods to assess the impact of shared, autonomous electric vehicles on sustainable urban mobility
Martínez et al. Insights into carsharing demand dynamics: Outputs of an agent-based model application to Lisbon, Portugal
Molnar et al. Long-term vehicle reservations in one-way free-floating carsharing systems: A variable quality of service model
Luè et al. Green move: An innovative electric vehicle-sharing system
Alfian et al. A simulation tool for prioritizing product-service system (PSS) models in a carsharing service
Mo et al. Competition between shared autonomous vehicles and public transit: A case study in Singapore
Santos et al. Finding the relevance of staff-based vehicle relocations in one-way carsharing systems through the use of a simulation-based optimization tool
CN112488400B (zh) 基于区块链技术与出行计划共享的交通出行行为调控方法
Lopes et al. Simulating carsharing operations through agent-based modelling: An application to the city of Lisbon, Portugal
Mak Enabling smarter cities with operations management
Fernández et al. Bike3S: A tool for bike sharing systems simulation
Pantuso Exact solutions to a carsharing pricing and relocation problem under uncertainty
Guillen et al. Europcar integrates forecasting, simulation, and optimization techniques in a capacity and revenue management system
Yu et al. Demand prediction and optimal allocation of shared bikes around urban rail transit stations
Azadeh et al. Choice-driven service network design for an integrated fixed line and demand responsive mobility system
González et al. Utilization rate of the fleet: a novel performance metric for a novel shared mobility
Jacquillat et al. Deployment and utilization of plug-in electric vehicles in round-trip carsharing systems
Wang et al. Adaptability analysis methods of demand responsive transit: a review and future directions
Mo et al. Dynamic interaction between shared autonomous vehicles and public transit: A competitive perspective
Richter et al. Exploring the financial implications of operating a shared autonomous electric vehicle fleet in Zurich

Legal Events

Date Code Title Description
AS Assignment

Owner name: MOBIAG, LDA., PORTUGAL

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:FARINHA GOMES FELIX, JOAO TIAGO;REEL/FRAME:034811/0726

Effective date: 20150108

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION