OPTIMIZING CHARGING, FUELING, AND PARKING OVERHEADS OF FLEET VEHICLES IN MaaS ARCHITECTURE

Abstract

To provide a system for optimizing charging, fueling, and parking overheads of fleet vehicles in a Mobility-as-a-Service (MaaS) architecture for preventing a congestion in a charging / gas station, which may cause an increase of traffic and a long waiting time in a high density city, a computing device and a program.SOLUTION: A system includes a scheduling subsystem MLSS. The scheduling subsystem generates a scheduling instruction by using machine learning on the basis of a retrieved vehicle parameter, infrastructure resource availability information, and historical usage information, and transmits the scheduling instruction to a fleet of vehicles. The scheduling instruction is provided in order to schedule usage of at least one infrastructure resource by one or more of the vehicles in the fleet.SELECTED DRAWING: Figure 3A

Description

Technical Field

[0001] The embodiments described herein generally relate to the optimization of fleet vehicle resources, including the overhead of charging, fueling, and parking fleet vehicles in a vehicle management system, particularly in a network architecture (e.g., Mobility-as-a-Service (MaaS) network architecture).

Background Art

[0002] In a MaaS network architecture, it may not be an efficient process to charge or refuel fleet vehicles by driving them to a charging / gasoline station, especially during peak traffic times. Similarly, for parking, having fleet vehicles drive around to find parking spots on their own can also be a cause of inefficient fleet management.

Brief Description of the Drawings

[0003] The figures in the accompanying drawings show some embodiments by way of example and not limitation.

[0004] [Figure 1] A MaaS network using a fleet management system with a charging / fueling / parking control system (CFPCS) according to an exemplary embodiment is shown.

[0005] [Figure 2] An exemplary use case associated with the CFPCS according to an exemplary embodiment is shown.

[0006] [Figure 3A] The machine learning (ML)-based scheduling subsystem (MLSS) of the CFPCS of FIG. 1 according to an exemplary embodiment is shown.

[0007] [Figure 3B]This is a block diagram showing the training of a deep learning (DL) model used by MLSS in one exemplary embodiment, as shown in Figure 3A.

[0008] [Figure 3C] Figure 3A shows the structure of a neural network that can be used by MLSS according to one embodiment.

[0009] [Figure 4] The following is a system overview of another example of a fleet management system with predictive recharging / refueling to optimize quality of service (QoS), according to one exemplary embodiment.

[0010] [Figure 5] This map shows a map representation of the Portland metropolitan area in Oregon, including a service area represented as a hexagonal grid and existing demand / fleet resources represented by icons, according to one exemplary embodiment.

[0011] [Figure 6] This example illustrates the calculation of dynamic service area boundaries based on demand and utility forecasts for a given planning period.

[0012] [Figure 7] This example illustrates a dynamic MaaS service area map that combines user demand forecasting with fleet range forecasting.

[0013] [Figure 8] An exemplary embodiment shows the initial deployment of a fleet of vehicles to an expected source hotspot.

[0014] [Figure 9] An example of a cluster that groups several vehicles receiving services from a mobile charging station is shown, according to one exemplary embodiment.

[0015] [Figure 10] A flowchart showing a method for managing a fleet of vehicles according to an exemplary embodiment.

[0016] [Figure 11] A block diagram showing an exemplary machine in which any one or more of the techniques (e.g., methods) described herein may function according to an exemplary embodiment. **DETAILED DESCRIPTION**

[0017] The following description sets forth numerous specific details in order to provide a thorough understanding of several exemplary embodiments for the purpose of explanation. It will be apparent to those of ordinary skill in the art that the present disclosure may be practiced without these specific details.

[0018] In a MaaS network, a fleet of vehicles may include autonomous vehicles (AVs), non-autonomous vehicles, or semi-autonomous vehicles associated with a ride-sharing service, a delivery service, or another type of service. The vehicles in the fleet may have to move to a charging / gasoline station or search for a parking spot, which can increase fuel and time consumption, increase road traffic in already congested urban areas, and cause congestion at charging / gasoline stations that can lead to longer waiting times.

[0019] One approach to address these problems is to add in the city a centralized facility for charging / fueling / parking the fleet vehicles at the targeted locations. However, this can significantly increase the capital expenditure (CAPEX) and operating expenses (OPEX) related to the deployment of MaaS and fleet management. Furthermore, to solve the problem of parking fleet vehicles that are temporarily out of service, the centralized facility may be insufficient if there is only a very small number of them.

[0020] In some aspects, an online marketplace sharing platform can be used for shared parking and charging of electric vehicles (EVs). In such a platform, property owners can rent out their parking spaces and EV charging units (if available) by listing them via an online platform. This solution is designed for scenarios where the consumers are general public vehicles and the service providers (mobile charging / fueling, online marketplace parking sharing) are separate entities that have no access to real-time information (e.g., fuel level, route planning, etc.) regarding civilian vehicles. However, charging, fueling, and parking in a MaaS network are handled differently. In a MaaS network, the consumers (fleet vehicles) and the service providers belong to the same entity. The service provider has full control over the fleet vehicles and has detailed real-time information from the vehicles such as route planning, charge / fuel level, real-time traffic information, etc. Therefore, previous solutions are not suitable for a MaaS network as they do not utilize the real-time information from fleet vehicles and the control power over those vehicles to optimize charging / fueling / parking overhead operations.

[0021] The disclosed techniques may be used for fleet management in a MaaS network to efficiently and automatically process charging / fueling / parking operations. More specifically, the disclosed fleet management system utilizes the fact that it can fully control the operation of fleet vehicles and obtain detailed real-time information from these vehicles. The proposed fleet management system may be composed of the following exemplary functions.

[0022] (a) A mobile energy distribution system that deploys energy distribution vehicles (EDVs), which are special service vehicles for transporting and distributing charge / fuel, to distribute charge / fuel to a cluster of fleet vehicles (in accordance with local regulations regarding fuel supply).

[0023] (b) Mobile recharging in operation using induction coils, in which a vehicle having excess charge capacity, fuel cell, or hybrid fuel may be able to transfer current to a forward-facing bumper or adjacent fender via a rear-mounted induction coil, and an autonomous vehicle (AV) and automated driving system (SDS) automation system may position the induction coil in close proximity, and a V2V network (such as Bluetooth® and Wi-Fi Direct®) or induction coil connection may transmit a micropayment protocol to perform a “stop” of recharging without stopping. This technology makes available new service opportunities for mobile recharging infrastructure that do not require on / off ramps and capital investment in fixed recharging “stations”.

[0024] (c) A machine learning (ML)-based scheduling subsystem (MLSS) is used as the intelligent scheduling engine in the proposed fleet management system. The MLSS is configured to minimize congestion and improve the overall fuel / charge economy of the system by performing these overhead operations using one or more machine learning techniques to make optimized decisions and commands for fleet vehicles and EDVs.

[0025] (d) The proposed framework can be configured as an online marketplace sharing platform and, when combined with MLSS, integrates with an Information Sharing Subsystem (ISS) that can benefit fleet administrators. The ISS would enable property owners (such as residential properties and businesses) to lease their facilities (such as parking spaces and / or charging units) to fleet vehicles and earn monetary rewards through a micropayment system.

[0026] (e) A distributed ledger technology (DLT) subsystem (DLTS) may be configured to perform functions associated with a micropayment framework for exchanging value for electricity, where value can take the form of digital currency, information assets, or electronic contracts.

[0027] Some of the advantages of the disclosed fleet management system include improving the service throughput of the MaaS network by efficiently handling the frequent overheads in MaaS fleet management, namely refueling, charging, and parking, to enable efficient route planning. The proposed ISS online marketplace platform opens up further resources (residential, commercial, etc.) for efficiently managing the overheads of EV charging and fleet parking.

[0028] The integration of payments (e.g., via DLTS) can directly reward multiple points of efficiency improvement before mature value shifts may occur. For example, if fleet-managed recharging vehicles can draw power from a nearby solar array, there is little extra effort required to introduce a solar array provider into the value shift. This is because electronic contracts can authorize fleet vehicles to connect to the solar array and process payments immediately, regardless of the form of electronic currency determined by the electronic contract. This could include contracts relating to commodities, stocks, information assets, electronic currencies such as stablecoins and Bitcoin, and traditional currencies such as dollars and euros. [Overview of the Fleet Management System]

[0029] To optimize the charging / fueling / parking overhead of fleet vehicles and to automate these operations, the disclosed method may use a fleet management system as shown in Figure 1.

[0030] Figure 1 shows a MaaS network 100 using a fleet management system 102 equipped with a charging / fueling / parking control system (CFPCS) according to one exemplary embodiment. The MaaS network 100 includes a fleet management system 102 which can be communicatively coupled to vehicle fleets 124, 126, ..., 128 associated with corresponding transport operators 118, 120, ..., 122. The fleet management system 102 is further communicatively coupled to EDVs and other service vehicles 130, MaaS users 115, and property owners 117 registered in the information sharing subsystem (ISS) 116 of the CFPCS 110.

[0031] The fleet management system 102 may include a dispatch subsystem 104, a vehicle gateway 106, a fleet service system 108, a CFPCS 110, and a fleet technician application 111. The CFPCS 110 may include an MLSS 112, a DLTS 114, and an ISS 116.

[0032] Figure 1 shows a schematic model of a MaaS system comprising a fleet 124, ..., 128 of vehicles providing transportation for people or goods. The fleet vehicles may be provided and managed by several different transport operators (TOs) 118, ..., 122, provided that a MaaS provider (e.g., a service provider managing a fleet management system 102) is given control over the operation of the fleet vehicles.

[0033] A fleet of vehicles 124, ..., 128 may consist of one or more MaaS nodes. A MaaS node is a component computing platform that integrates various essential computing elements common to MaaS calculations. By building a fleet management method centered on fleet vehicles based on a MaaS node architecture, a low-cost yet high-quality / reliable MaaS system can be easily realized through manufacturing economies of scale. A MaaS node typically consists of a sensor hub, context sensors (position, velocity, direction of travel, temperature, accelerometer, ALS, decibel, air quality), a context manager, a task request / response handler, a message bus, a RAN connection / communication manager, a compute / computation accelerator (xPU), an autonomous controller module, a micropayment manager, a MaaS orchestration scheduler / task manager, etc.

[0034] Fleet vehicles 124, ..., 128 require repetitive charging / refueling / parking, which is overhead that requires efficient handling. In densely populated urban areas, it may be necessary to deploy a large fleet to meet demand, which increases these overheads. If charging / refueling / parking operations are not handled efficiently, it can cause traffic congestion, become a bottleneck, and consequently saturate the service throughput of the MaaS system.

[0035] CFPCS110 hosts MLSS112, which periodically collects information from fleet vehicles and other sources regarding current traffic conditions, route planning, service demand, vehicle location, fuel levels, and range estimations. Based on this information, MLSS112 makes optimal decisions about where and when each fleet vehicle should refuel, recharge, or park (for example, by applying one or more machine learning (ML) techniques as shown in Figures 3B and 3C). During peak traffic, when existing charging / refueling stations are congested, or when traffic conditions prevent fleet vehicles from reaching stations quickly, the scheduling engine can decide to deploy EDVs at optimal locations and times to avoid congested areas. Because this is a complex problem in a high-dimensional optimization space, ML techniques (e.g., ML-based algorithms) may be used to compute a near-optimal solution.

[0036] Residential, private, and commercial buildings in urban areas may have resources such as underutilized parking spaces and EV charging stations during certain times of the day. Making these resources available for fleet management would be beneficial for MaaS operations. ISS116 opens up opportunities to utilize these additional resources that are advantageous for fleet management. Using ISS116, homeowners / private owners will be able to advertise their resources based on their availability and, as a result, earn compensation from MaaS providers.

[0037] DLTS114 may be used as a micropayment framework for exchanging value for electricity, where value can take the form of digital currency, information assets, or electronic contracts. This approach allows for more direct exchange interactions, avoiding complex value chains in which a central entity determines the value of various entities in value changes based on political influence, marketing influence, or other factors that may not be directly related to the value supplied at the time of asset exchange.

[0038] Figure 2 shows several exemplary use cases of the proposed framework using CFPCS110.

[0039] Figure 2 shows an exemplary use case 200 associated with CFPCS according to an exemplary embodiment. Referring to Figure 2, the exemplary use case may include EDV 204 providing charge to EVs 206, 208, 210, ..., 212 in parking lot 202; a vehicle on road 214 detecting an empty parking space P5 and transmitting a parking space availability message 216 to fleet management system 102 via base station 203; the owner of house 222 transmitting a message 224 to base station 203 indicating the availability of a parking space and EV charging unit; and base station 203 transmitting a command 228 to a low-battery vehicle 226, the command instructing the vehicle to charge in parking lot 202.

[0040] It is assumed that fleet vehicles are connected to the fleet management system 102 via a wireless network (such as 4G, 5G, or DSRC). Fleet vehicles cooperate with the fleet manager by providing information such as range estimation, route planning, and road traffic conditions. Vehicles may follow refueling / charging / parking commands from the fleet manager, and depending on the situation, vehicles can proactively send requests to the system to secure a nearby parking spot or charging station. [MLSS (or Intelligent Scheduling Engine) for efficiently handling fleet overhead operations]

[0041] Figure 3A shows a diagram 300A of the machine learning (ML)-based scheduling subsystem (MLSS) 112 of the CFPCS in Figure 1, according to an exemplary embodiment. Figure 3A provides an overview of the MLSS 112, with an emphasis on input parameters and output command messages. The MLSS 112 is configured to process various input parameters, as shown in Figure 3A, and generate a set of commands at the output to optimize a defined set of objectives. [Input parameters]

[0042] As shown in Figure 3A, MLSS112 is configured to receive several input parameters from multiple different subsystems.

[0043] Fleet vehicle information (or vehicle parameters) 308. Since fleet vehicles are MaaS entities that require scheduling for charging / fueling / parking, MLSS 112 needs to know basic and current information about each vehicle. Input parameters for fleet vehicle information 308 are periodically obtained from individual fleet vehicles via the vehicle gateway 106. In some embodiments, fleet vehicles are configured to transmit vehicle parameters periodically or on demand via a wireless connection to the MaaS provider and fleet management system 102. Exemplary vehicle parameters are listed in Table 1 below. [Table 1] [Table 1]

[0044] Infrastructure Resource Availability 310. MLSS112 is configured to enable MaaS providers to make parking and EV charging resources available in residential, airport, hotel, commercial and corporate buildings, etc. MLSS112 can obtain infrastructure resource availability information via an interface with ISS116. Availability information may be provided to MLSS112 on demand in the form of a list of requested geographic locations. Each element in the list may contain resource information, for example, as shown in Table 2 below. [Table 2] [Table 2]

[0045] Demand forecast 312. It is sometimes preferable to avoid scheduling overhead operations of fleet vehicles during peak demand because it is important to maximize fleet capacity during these times. In some embodiments, MLSS 112 may obtain information about future demand forecasts 312 in the geographic area in which the relevant fleet vehicles are operating from the demand forecast module 302 (e.g., on demand). The forecast shall include information about expected demand in the requested geographic area for the requested time period / s. In some embodiments, the demand forecast module 302 may be ML-based and may be part of MLSS 112.

[0046] Points of Interest (POIs) and route planning information 314. In the context under consideration, POIs are relevant resources available for fleet use, such as parking lots and other parking spots, EV charging stations, and / or gas stations. In some embodiments, route planning information is used by MLSS 112 to determine the best route and timing for fleet vehicles to complete overhead operations.

[0047] In some embodiments, MLSS112 can obtain POI and route planning information from the map cloud service 304. In some embodiments, MLSS112 may query the map cloud service 304 (e.g., the map cloud, which may be a map generation or map management network) by sending a set of vehicle source locations, a set of resource destinations, and a set of timings. The map cloud may respond to the query timing by providing N best routes between each vehicle and N best resource destinations (where N can be arbitrarily defined on a case-by-case basis). While calculating the best routes, the map cloud may consider traffic forecasts for a given timing. The route planning information responded by the map cloud is used by MLSS112 as input parameters.

[0048] Government rules and regulations 316 may be obtained from local ordinance services 306 (e.g., a network providing access to government rules and regulations 316). Sharing residential parking spaces for fleet management may result in additional traffic in residential areas. Furthermore, local authorities may have certain restrictions, such as traffic restrictions in residential areas to avoid congestion, or designated areas for vehicle refueling. MLSS 112 may consist of mechanisms for implementing regulations in cooperation with city authorities.

[0049] Furthermore, government rules and regulations may include tax rules such as energy use taxes, highway use and maintenance taxes, vehicle property taxes, sales taxes (on the sale of energy), or electronic services provided through MaaS infrastructure. MLSS112 may provide a mechanism for tax collection that leverages the micropayment functions described herein. [Optimization algorithm]

[0050] MLSS112 can be configured to solve optimization problems related to the various input parameters described above using one or more ML methods (including optimization algorithms). As the number of active fleet vehicles increases, the optimization problems become more complex and difficult to handle with deterministic algorithms. Therefore, the algorithm may use ML methods to compute the best / near-best solution. This disclosure broadly describes the optimization problems using informal definitions of optimization criteria and associated constraints.

[0051] [the purpose] The objective or goal of the optimization problem may be to maximize the overall efficiency and economics of the MaaS system. In some aspects, a multi-objective optimization problem may be considered, which may differ slightly among the overheads of charging, refueling, and parking. Below, we describe some of the main objectives (or optimization criteria) that may be considered during the design of MLSS112.

[0052] Exemplary objectives may include minimizing the expected travel time to a resource (parking spot or charging / gas station) and the travel time to the next service destination (if known). Minimizing travel time ensures that the traffic footprint left by fleet vehicles due to overhead operations is as small as possible.

[0053] In the case of charging / refueling, the exemplary objective is to minimize expected waiting time, including waiting time and execution time (at charging / gas stations). In the case of charging, execution time can vary significantly depending on the wattage of the charger.

[0054] An exemplary objective is to minimize the total cost of overhead operations. Total costs include direct costs such as charging, refueling, or parking, and indirect costs such as the cost of traveling to the resource destination.

[0055] Exemplary objectives include maximizing fleet availability and distributing it across the service area in proportion to the distribution of demand forecasts.

[0056] In some aspects, MLSS112 may also consider distributing fleet vehicle routes across multiple different areas to avoid congestion. For example, if more fleet vehicles are scheduled to visit the same refueling station at the same time, congestion will almost certainly occur along the route and at the station. This can therefore be avoided.

[0057] Since some contradictions exist between these objectives, the final objective function may be obtained by a weighted average of the individual objectives. In some aspects, the weights are dynamic and depend on several different factors. Some examples are as follows: If higher demand is predicted in the near future, higher weights may be used to maximize fleet availability and minimize expected travel and waiting times, while smaller weights may be used to minimize total costs. In another example of overnight vehicle parking, larger weights may be assigned to minimize the total cost of overhead operations, while smaller weights may be assigned for other purposes.

[0058] Optimization Parameters and Constraints. Optimization parameters are choices that MLSS112 must intelligently select to achieve the objectives described above. Each optimization parameter may affect one or more objectives. The following are the main parameters that MLSS112 may be configured to optimize (for example, during ML model training as described in relation to Figures 3A and 3B).

[0059] (a) Timing of overhead operations: This parameter affects all of the purposes listed above. When selecting this parameter for each fleet vehicle, certain constraints may exist. For example, the latest time limit may be affected by factors such as the remaining charge / fuel in the vehicle and the distance to the nearest available resource.

[0060] (b) Charging / Fueling / Parking Resources: This parameter belongs to the set of resources available in the service area, including dedicated MaaS facilities, public resources such as parking / refueling stations, and residential / corporate resources available via online sharing platforms (e.g., ISS). The desired value will vary for each resource depending on its attributes, such as location, price / cost, and time required. Due to government regulations or reservation limitations, there may be some constraints on the selection of resources for fleet vehicles.

[0061] (c) Number of EDVs to deploy: During certain times when readily available resources are insufficient, such as during peak traffic hours, achieving the desired objective may be difficult. In such cases, deploying EDVs to charge / refuel fleet vehicles may significantly improve the objective. The impact of this parameter on the objective may be determined by considering other relevant parameters such as the target location and timing of the EDVs.

[0062] Output control commands (for MLSS112). MLSS112 periodically solves the optimization problems described above and generates outputs 318, 320, 322, and 324 as described herein. With each iteration, based on the resulting solution, MLSS112 generates control commands at specific timings. These control commands are sent to several different subsystems of the MaaS provider to perform overhead operations. The main commands generated by the scheduling engine are listed below.

[0063] Vehicle commands 322 are transmitted to the vehicle gateway 106. These control commands are specific to individual fleet vehicles and are transmitted via the vehicle gateway 106 and subsequently via the wireless network. These commands may include instructions to vehicles to charge / refuel / park by visiting specific locations.

[0064] EDV direction commands 324 are transmitted to the dispatch subsystem 104. These control commands are sent to the dispatch subsystem 104 to direct the EDV to the target location. They also include further instructions such as the fuel / charge capacity to be carried and the ID of the fleet vehicle to be charged / refueled.

[0065] Reservation instructions 320 (sent to ISS116) and reservation payments 318 (sent to DLTS114). These instructions are used to reserve the necessary resources on an online sharing platform (e.g., ISS116). Payments required for resource reservations are sent via the payment system of DLTS114. [Online Marketplace Sharing Platform (ISS116)]

[0066] ISS116 enables the MaaS fleet management system 102 to leverage resources available in residential and commercial infrastructure. In some embodiments, ISS116 may include an online marketplace sharing platform that can be used in the fleet management system 102, which property owners can use to list their private parking spaces and EV chargers (if available). In some embodiments, the online sharing platform of ISS116 may be integrated with MLSS112 as part of CFPCS110 (as shown in Figure 1) and then become part of an optimization process (e.g., ML-based training and model generation on MLSS112, as described in relation to Figures 3A and 3B). This integrated setup can significantly optimize overhead processes in fleet management that cannot be achieved with the online sharing platform alone.

[0067] Here, exemplary requirements for ISS116 for optimization and its interface with the MaaS fleet management system 102 are described. In some embodiments, ISS116 may be hosted within the MaaS provider system as part of CFPCS110, or it may be hosted by an external cloud service (for example, as part of an external network separate from the fleet management system 102). The following are some features of ISS116 that can be integrated with the scheduling engine.

[0068] (a) ISS116 is configured to provide a reliable and secure service that allows legal homeowners and business owners to register and list their resources (parking spaces and EV chargers) on the platform. ISS116 may also include appropriate mechanisms for accurately collecting and verifying necessary resource details (location, size, type, etc.) from users.

[0069] (b) In some embodiments, the ISS116 may be configured to allow the owner to set (e.g., dynamically) resource prices and to provide a service for registered users to reserve resources.

[0070] (c) In some embodiments, ISS116 is configured to allow the user to make payments for reservations via DLTS114.

[0071] (d) In some embodiments, ISS116 is configured to provide a service for querying on-demand the availability of resources within a requested geographic area. ISS116 should also provide a service that can be used by scheduling algorithms to obtain detailed information about the resources in question. [Micropayment systems (e.g., DLTS114)]

[0072] DLTS114 is configured to extend to multiple service points or information exchange interfaces in the MaaS network 100. Each resource available for scheduling, exchange, or bartering is equipped with access to a micropayment exchange interface, an electronic wallet, and a transaction clearing node. In the context of refueling / recharging, in some embodiments, an energy provider may supply m watts of energy in exchange for n micropayment tokens. Resources requiring recharging / refueling receive payment for the services or value they generate in micropayment tokens stored in an electronic wallet (which can later be used to purchase the energy to be recharged / refueled).

[0073] In some embodiments, micropayments in DLTS114 process transaction settlement using a decentralized clearinghouse approach such as distributed ledger technology (DLT). DLTS nodes may be virtually hosted at any location within the MaaS network 100, including integration with radio access network (RAN) infrastructure such as cell towers, base stations, and low Earth orbit (LEO) satellites, or they may be integrated with MaaS edge nodes (such as lighting poles, traffic signals, cameras, mobile devices, IoT sensors, or other vehicle-to-vehicle / vehicle-to-infrastructure (V2X) devices).

[0074] Discounts and subsidies for clean energy can be more easily tracked by DLTS114, which allows clean solar charging stations to prove the type of energy generation in electronic contracts for supplying energy. Transactions may offer clean energy subsidies so that there are fewer micropayment tokens that need to be exchanged in return as a result of a lower per-watt valuation. For example, EVs may receive Uber-like compensation for ride-sharing in electronic currencies such as Ethereum. Charging facilities could accept payments only in dollars, rather than converting Ether to euros. Unnecessary conversion losses can be avoided by exchanging various currencies, including information assets, in the form of electronic contracts.

[0075] In some embodiments, DLTS114 may include a Micropayment Module (MPM) which may consist of MaaS nodes used for efficient processing of micropayments in exchange for processing. The MPM may be equipped with various internal sensors / meters for determining the amount of computing resources used to perform Units of Work (UoW). UoW consumed to perform MaaS operations / workloads are aggregated and used to charge tenants' e-wallets as needed / approved. The MPM may pay for resources on a “pay-per-use” model, taking into account the power, cooling, tamper resistance, and other costs associated with hosting MaaS services on the MaaS nodes. Electronic contracts may be created to guarantee payment for any MaaS node microtransactions and to guarantee ACID (Indivisibility, Consistency, Independence, Permanence) properties and non-double-use, etc.

[0076] Figure 3B is a block diagram 300B showing the training of a deep learning (DL) model 310B used by the MLSS in Figure 3A, according to one exemplary embodiment. In some exemplary embodiments, a machine learning program (MLP), which includes a deep learning program, also collectively referred to as a machine learning algorithm, tool, or technique, is used to perform operations associated with correlating data or other artificial intelligence (AI)-based capabilities in relation to the capabilities described herein performed by the MLSS 112.

[0077] As shown in Figure 3B, deep learning model training 308B is performed within a deep learning architecture (DLA) 306B based on training data 302B (which may include features). During deep learning model training 308B, features from training data 302B may be assessed for the purpose of further training the DL model. The result of DL model training 308B is a trained DL model 310B. The trained DL model 310B may include one or more classifiers 312B that can be used to provide DL assessment 316B (e.g., assessment performed in relation to MLSS 112 functions) based on new data 314B (which may be obtained by MLSS 112 from one or more other subsystems in the fleet management system 102).

[0078] In one exemplary embodiment, DLA306B and deep learning model training 308B are performed within MLSS112. The trained model 310B is also included as part of MLSS112. In other embodiments, training and model storage may be provided on a remote network that MLSS112 can access on demand.

[0079] In some embodiments, the training data 302B may include input data 303B and output data 305B, which may be configured based on the optimization function of MLSS112 described above. The input data 303B and output data 305B are used during DL model training 308B to train the DL model 310B. In this context, the trained DL model 310B receives new data 314B, extracts features based on the data, and performs event decisions using the new data 314B.

[0080] Deep learning is a subfield of machine learning that gives computers the ability to learn without being explicitly programmed. Machine learning involves the study and construction of algorithms, also referred to herein as tools, which may learn from existing data, correlate data, and make predictions about new data. Such machine learning tools operate by building a model from exemplary training data (e.g., training data 302B) and making data-driven predictions or decisions, which are represented as outputs or assessments 316B. While exemplary embodiments are presented for a limited number of machine learning tools (e.g., deep learning architectures), the principles presented herein may be applicable to other machine learning tools.

[0081] In some exemplary embodiments, multiple different machine learning tools may be used. For example, logistic regression, naive Bayes, random forest, neural networks, matrix factorization, and support vector machine tools may be used during deep learning model training 308B (for example, to correlate training data 302B).

[0082] Two common types of problems in machine learning are classification problems and regression problems. Classification problems, also known as categorization problems, aim to classify items into one of several categorical values ​​(e.g., is this object an apple or an orange?). Regression algorithms aim to quantify several items (e.g., by providing real values). In some embodiments, DLA306B may be configured to use a machine learning algorithm that utilizes training data 302B to find correlations between identified features that affect the outcome.

[0083] The machine learning algorithm uses features from the training data 302B to analyze new data 314B and generate assessments 316B. These features include individual measurable properties of phenomena observed and used to train the machine learning model. The concept of features is related to the concept of explanatory variables used in statistical methods such as linear regression. For the effective operation of MLPs in pattern recognition, classification, and regression, it is important to select useful, detailed, and independent features. Features may be of multiple different types, such as numerical features, strings, and graphs. In some embodiments, the training data may be of multiple different types, with these features being numerical values ​​used by the computing device.

[0084] In some embodiments, the features used during DL model training 308B may include not only input data 303B and output data 305B, but also sensor data from multiple sensors (e.g., audio sensors, motion sensors, GPS sensors, image sensors), actuator event data from multiple actuators (e.g., wireless switches or other actuators), external information from multiple external sources, sensor state data (e.g., time sensor data is acquired), actuator event data, or timer data associated with external information source data, user communication information, user data, user behavior data, etc.

[0085] The machine learning algorithm uses the training data 302B to find correlations between identified features that influence the outcome of assessment 316B. Using the training data 302B (which may contain identified features), the DL model is trained using DL model training 308B within DLA306B. The result of the training is the trained DL model 310B (e.g., neural network 320C in Figure 3C). When DL model 310B is used to perform an assessment, new data 314B is provided as input to the trained DL model 310B, and DL model 310B generates assessment 316B as output. For example, DLA306B can be deployed within MLSS112 to perform ML methods as described herein.

[0086] Figure 3C shows a diagram 300C of the structure of a neural network that may be used by MLSS in Figure 3A using DLA 306B in Figure 3B, according to one embodiment. The neural network 320C takes source domain data 310C (for example, data provided by MLSS 112 to perform one or more ML-based techniques) as input and processes the source domain data 310C using an input layer 330C, intermediate hidden layers 340C, 342C, 344C, 346C, and 348C, and an output layer 350C to produce the result 360C.

[0087] Each of layers 330C–350C contains one or more nodes (or "neurons"). In Figure 3C, the nodes of the neural network 320C are shown as circles or ellipses. Each node receives one or more input values, processes these input values ​​using zero or more internal variables, and produces one or more output values. The input to the input layer 330C is the values ​​from the source domain data 310C. The output of the output layer 350C is the result 360C. The hidden layers 340C–348C are called "hidden" because they do not directly interact with either the inputs or outputs and are entirely within the neural network 320C. Five hidden layers are shown in Figure 3C, but more or fewer hidden layers may be used.

[0088] The model may be run on a training dataset over several epochs (e.g., iterations) to refine the results by repeatedly supplying the training dataset to the model. For example, in a supervised learning phase, the model is unfolded to predict an output for a given set of inputs, while simultaneously evaluating the model over several epochs to more reliably provide a specified output corresponding to a given input for the maximum number of inputs on the training dataset. In another example, in an unsupervised learning phase, the model is unfolded to cluster the dataset into n groups, while simultaneously evaluating the model over several epochs to see how consistently it places a given input within a given group, and how reliably it generates these n desired clusters throughout each epoch.

[0089] When an epoch is executed, the model is evaluated, and the values ​​of its variables are adjusted in an attempt to iteratively refine the model more effectively. In various embodiments, the evaluation may be biased towards missed detections, false positives, or evenly biased towards the overall accuracy of the model. These values ​​may be adjusted in several ways depending on the machine learning technique used. For example, in a genetic or evolutionary algorithm, the values ​​for the model that most successfully predicted the desired output are used to expand the values ​​for the model used in subsequent epochs, which may include random changes / transformations to provide additional data points. Those skilled in the art will be familiar with several other machine learning algorithms that may be applied in this disclosure, including linear regression, random forests, decision tree learning, neural networks, and deep neural networks.

[0090] Each model develops a rule or algorithm over several epochs by changing the values ​​of one or more variables that affect the input to map more closely to the desired outcome. However, since the training dataset may change and is preferably very large, perfect accuracy and precision may not be achievable. Therefore, the number of epochs constituting the learning phase may be set as a given number of trials or a fixed time / computation budget, or it may be terminated before reaching that number / budget if the accuracy of a given model is sufficiently high, sufficiently low, or the accuracy plateaus. For example, if the training phase is designed to run n epochs to produce a model with at least 95% accuracy, and such a model is produced before the nth epoch, the learning phase may be terminated early, and the produced model that meets the final target accuracy threshold may be used. Similarly, if a given model is sufficiently inaccurate to satisfy the random chance threshold (for example, only 55% accurate in determining true / false outputs for a given input), the training phase for that model may be terminated early, while other models in the training phase may continue training. Likewise, if a given model continues to provide similar accuracy over multiple epochs, or if the results continue to fluctuate, i.e., if the performance plateaus, the training phase for that model may be terminated before reaching the number of epochs / computational budget.

[0091] Once the training phase is complete, the model is committed. In several exemplary embodiments, the committed model is evaluated against test criteria. In the first example, a test dataset containing known outputs for inputs is fed into the committed model to determine the model's accuracy when processing data it has not been trained on. In the second example, the false positive rate or false negative rate may be used to evaluate the committed model. In the third example, a depiction between data clusters is used to select the model that produces the clearest boundaries between data clusters.

[0092] Neural network 320C may be a deep learning neural network, a deep convolutional neural network, a recurrent neural network, or another type of neural network. A neuron is an architectural element used in data processing and artificial intelligence, particularly machine learning, that contains memory capable of determining when to "remember" and when to "forget" values ​​held in that memory based on the weights of the inputs provided to a given neuron. An exemplary type of neuron in neural network 320C is a long-short-term memory (LSTM) node. Each neuron used herein is configured to accept a predefined number of inputs from other neurons in the network and to provide relational and subrelational outputs about the content of the frame being analyzed. Individual neurons may be organized and / or chained in a tree structure in various configurations of the neural network to provide interaction and relational learning models about how each frame in an utterance relates to the others.

[0093] For example, an LSTM functioning as a neuron includes an input vector (e.g., time-series data), memory cells, and several gates for processing the output vector. The input and output gates control the information flowing into and out of the memory cells, respectively, while a forget gate is optional and removes information from the memory cells based on inputs from early linked cells in the neural network. During the training phase, weights and bias vectors for the various gates are adjusted, and once the training phase is complete, those weights and biases are determined for normal operation. Those skilled in the art will understand that neurons and neural networks can be constructed according to a program (e.g., via software instructions) or via specialized hardware that links each neuron to form a neural network.

[0094] Neural networks, sometimes called artificial neural networks, are computational systems based on considerations of the biological neural networks of animal brains. Such systems perform tasks, usually without task-specific programming, by progressively improving their performance through a process called learning. For example, in image recognition, a neural network may be taught to identify images containing an object by analyzing example images tagged with the object's name, and after learning the object and its name, it may use the analysis results to identify that object in untagged images. A neural network is based on a collection of connected units called neurons, and each connection between neurons, called a synapse, can transmit a one-way signal with an activation intensity that varies depending on the strength of the connection. A receiving neuron can activate a signal and propagate it to downstream neurons connected to it, usually based on whether the combined input signal from potentially many transmitting neurons is strong enough (where intensity is a parameter).

[0095] A deep neural network (DNN) is a stacked neural network composed of multiple layers. These layers consist of nodes, where computations are performed, roughly patterned on neurons in the human brain, which fire when sufficiently stimulated. Nodes combine input from data with a set of coefficients or weights that amplify or attenuate that input. This assigns importance to the input related to the task the algorithm is trying to learn. These input-weight products are summed up and passed through a so-called node activation function to determine whether, and to what extent, the signal progresses further through the network and influences the outcome. DNNs use a cascade of many layers of nonlinear processing units for feature extraction and transformation. Each successive layer uses the output from the previous layer as input. Higher-level features are derived from lower-level features to form a hierarchical representation. Layers following the input layers may be convolutional layers that filter the input results and generate feature maps that are used by the next convolutional layer.

[0096] In training a DNN architecture, regression, structured as a set of statistical processes for estimating relationships between variables, can include minimizing a cost function. The cost function may be implemented as a function that returns a number representing how well the neural network performed in mapping training examples and correcting the output. If the cost function value is outside a given range during training, backpropagation is used based on known training images. Backpropagation is a common method for training artificial neural networks used in optimization methods such as stochastic gradient descent (SGD).

[0097] The use of backpropagation can include propagation and weight updating. Once an input is presented to a neural network, it is propagated forward through the network layer by layer until it reaches the output layer. The output of the neural network is then compared to the desired output using a cost function, and an error value is calculated for each node in the output layer. The error values ​​are propagated backward, starting from the output, until the associated error values ​​of each node roughly represent their contribution to the original output. Backpropagation can then use these error values ​​to calculate the gradient of the cost function across the weights in the neural network. The weights are updated by feeding the calculated gradient into a chosen optimization method, attempting to minimize the cost function.

[0098] In some exemplary embodiments, the structure of each layer is predefined. For example, a convolutional layer may include a small convolutional kernel and its corresponding convolutional parameter, and a summation layer may calculate the sum or weighted sum of two or more values. Training helps in defining the weight coefficients of the summation.

[0099] One way to improve the performance of a DNN is to identify newer structures for the feature extraction layer, and another is to improve how these different layers identify parameters to achieve the desired task. A given neural network may have millions of parameters to optimize. Optimizing all of these parameters from scratch can take hours, days, or even weeks, depending on the available computing resources and the amount of data in the training set. [Fleet management method for optimizing QoS through predictive recharging / refueling]

[0100] In some scenarios, a fleet of autonomous vehicles (AVs) for taxi dispatch services may navigate smart cities and converge at hotspots. The locations of these hotspots may continuously change depending on the time of day, day of the week, and season. At some point in the routine operations, some vehicles in the fleet will need to be recharged. Because hotspots change over time, fixing the locations where charging may occur is not cost-effective for fleet managers. In addition to avoiding this inefficiency, future cities should avoid increased visual pollution by using real-state data for fixed charging stations. Fixed charging stations result in suboptimal movement and increased downtime for on-demand fleets. Mobile charging stations alone do not solve the problem and may even worsen it.

[0101] Currently, the majority of existing charging solutions are based on fixed infrastructure, which presents several challenges as described herein. Fleet vehicles, whether manually or automated, must be driven to public infrastructure charging / refueling points, and the time these vehicles are driving (and recharging / refueling) represents downtime that impacts the fleet owner's revenue.

[0102] The mobile charging infrastructure is still in its early stages. In some forms, vehicles can be deployed to charge other vehicles. For example, Nation-E's Angel Car is a mobile charging station intended to support stranded EVs. However, there is currently no perfect solution for efficiently managing the logic regarding the deployment of mobile charging infrastructure to minimize fleet downtime.

[0103] In some embodiments, cell type notation may be used to describe coverage areas in the map for vehicles, define corridors between cells, and determine potential service times when requests need to move from one cell to another. However, the cells are fixed and do not take into account the dynamic changes in hotspots in cities or the current charge / fuel state of the fleet.

[0104] If charging infrastructure is fixed, vehicles within a fleet may have to travel long distances to recharge, potentially increasing downtime. Furthermore, mobile charging stations alone do not solve the problem of minimizing AV downtime. The disclosed method can be used as a perfect solution using mobile charging stations, but ML-based methods can also be used to efficiently support AV fleets. More specifically, the proposed method may be used to maximize the performance of electric (or fuel) fleets. This method creates a real-time map of “dynamic service” based on predicted usage demand and existing fleet resource ranges, and anticipates the need for recharging in AV fleets, determining how many times each vehicle needs to be recharged to support demand in a determined area by deploying mobile charging stations (also known as EDVs) to maintain / maximize quality of service (QoS). The disclosed method can be used (e.g., by MLSS112) to manage fleets more efficiently and reduce downtime for individual vehicles. The disclosed method presents the following further advantages: The disclosed method anticipates the need for vehicles to recharge / refuel and deploys this mobile solution in a convenient location near them. The disclosed method may be used by MLSS112 (or other subsystems within the fleet management system 102) to return vehicles to partial or full charge capacity near the last ride, thereby reducing downtime. The disclosed method can be used to reduce the visual pollution of fixed charging stations in future cities. The disclosed method can be used to eliminate fleet dependence on public charging stations at fixed locations and to reduce the movement of multiple AVs to fixed charging stations that may be far from the AVs.

[0105] The disclosed method can be used to optimize fleet management, linked to defined quality of service, through predictive demand and service monitoring and the deployment of mobile charging units to strategic locations within supported MaaS areas. Figure 4 shows the components of a MaaS fleet management system using the disclosed method.

[0106] Figure 4 shows a system overview of another example of a fleet management system 400 with predictive recharging / refueling for quality of service (QoS) optimization, according to one exemplary embodiment. The fleet management system 400 may be the same as the fleet management system 102 in Figure 1, and Figure 4 provides a different network view of the fleet management system.

[0107] The fleet management system 400 includes a real-time fleet dashboard 402, a predictive MaaS service dashboard 404, a fleet maintenance subsystem 406, an operations subsystem 408, a ride planning subsystem 410, a charging planning subsystem 412, a service forecast subsystem 414, a demand forecast subsystem 416, map information 418, a fleet telematics subsystem 420, a ride dispatch subsystem 422, a subsystem for mobile charging stations 424, real-time traffic information (RTTI) 426, and a MaaS user application programming interface (API) 428.

[0108] The fleet telematics subsystem 420 and the dispatch subsystem 422 may communicate with the fleet of vehicles 430. RTTI 426 may be obtained from the fleet of vehicles 430 or from the real-time traffic information provider 432. Map information 418 is obtained from the map source 434. The MaaS user API 428 is configured to process MaaS user requests 436 associated with services provided by the fleet management system 400. The demand forecasting subsystem 416 may be configured to access service requests and historical service request data. The service forecasting subsystem 414 is configured to forecast where services will be needed, including several vehicles, vehicle capacity, etc.

[0109] In one exemplary embodiment, the disclosed method may be associated with the functionality provided by the predictive MaaS service dashboard 404, the charging planning subsystem 412, the service forecasting subsystem 414, the demand forecasting subsystem 416, and the subsystem for mobile charging stations 424. In one exemplary embodiment, the disclosed method can perform forecasting or planning functions that can be performed using the disclosed ML-based method. In this context, the disclosed forecasting or planning functions of the fleet management system 400 may be performed by MLSS 112 and its ML-based functions.

[0110] The following disclosure relates to the transition from static demand maps to real-time dynamic fleet monitoring maps with charging and demand forecasts.

[0111] Figure 5 shows a map representation of the Portland metropolitan area in Oregon, including a service area represented as a hexagonal grid and existing demand / fleet resources represented by icons, according to one exemplary embodiment. Figure 5 shows that the presence of fleet vehicles may be monitored within a coverage area, e.g., the Portland metropolitan area. In some embodiments, the coverage area may be segmented based on service needs and time to service, and the presence of fleet vehicles and customer demand may be monitored. For example, icon 502 represents an incoming service request, and icon 504 represents vehicle availability in the area. In some embodiments, random time-variable and time-dependent minimum-cost routing models may be used for routing fleet vehicles.

[0112] However, the approach described above does not include a function to represent the fleet's ability to handle these demands. Furthermore, considering the need for vehicle charging / refueling, the real-time location of these vehicles may not reflect the fleet's ability to support current or projected demand.

[0113] Today, vehicle telematics allows for remote monitoring of fuel / battery status, and this information, combined with predicted user demand, can be used to determine future on-demand service needs. Such information may be used in a demand forecasting module combined with a vehicle fleet resource utilization forecasting model to create dynamic boundary estimates of service cells over a defined planning period, as shown in Figure 6.

[0114] Figure 6 shows a diagram 600 of dynamic service area boundary calculation based on demand and utility forecasts for a planned period, according to an exemplary embodiment. Referring to Figure 6, user demand information 602 can be combined with fleet status information 604 to generate boundaries 606 associated with user demand and fleet status. After some time (e.g., time_horizon), user demand changes to user demand 608 and fleet status changes to fleet status 610. The updated user demand 608 and fleet status 610 are used to update the boundaries to boundaries 612 representing the new demand and fleet status.

[0115] The user demand forecasting model is trained using historical data from user demand collected through calls from MaaS applications / APIs. This model includes the location at the time the MaaS transportation request is initiated and the intended destination. Contextual data during the request and user profile data are also collected.

[0116] In some embodiments, fleet utility prediction models are trained from historical data to estimate fuel / battery consumption and also receive vehicle characteristics, average consumption, and traffic information as input, as well as the use of in-vehicle services that may affect range (e.g., AC / heating use).

[0117] The resulting model outputs can be combined to calculate a MaaS coverage area, represented as a set of service reachability, which can help identify service need hotspots by considering the deployment of adjacent cell vehicles to cover service needs within the planned period. The resulting map is a dynamic MaaS service area prediction using variable-size cells, as shown in Figure 7.

[0118] Figure 7 shows a dynamic MaaS service area map 700 in which user demand forecasting is combined with fleet range forecasting, according to one exemplary embodiment. In Figure 7, the dynamic MaaS service area map 700 at time T is updated (after elapsed time TimeHorizon) using user demand forecasting (in the case of time T + TimeHorizon) to obtain dynamic fleet demand forecasting for each area 702 and fleet utilization forecasting to obtain dynamic fleet deployment forecasting for each area 704. The dynamic MaaS service area 706 associated with time T + TimeHorizon is obtained by combining the dynamic fleet demand forecasting and the dynamic fleet range forecasting.

[0119] As a result of the functions described above, fleet operators using the fleet management system can monitor demand and available resources, and at the same time, predict cases where low availability of fleet resources causes user demand hotspots to converge, leading to a decrease in coverage and, consequently, a decline in the quality of MaaS services in the target area.

[0120] This task may be solved by deploying more fleet vehicles than demand. However, such a solution may be ineffective and waste resources. On the other hand, resource downtime due to refueling / recharging is not optimal. In this regard, mobile charging stations may be used, while properly monitoring which stations can maintain the target quality of service.

[0121] The following disclosures relate to fleet management of mobile charging stations for MaaS QoS assurance.

[0122] Figure 8 shows the initial deployment of a fleet of vehicles 800 to an expected source hotspot in one exemplary embodiment. Referring to Figure 8, the illustrated map may be updated with the locations of the autonomous vehicles 802 and the expected source hotspot 804.

[0123] In some embodiments, taxi dispatch (or other similar services), AVs may be deployed in a smart city. Initial deployment may be from headquarters to random locations, or to expected source hotspots within the smart city (as shown in Figure 8). The latter deployment is a sign of an efficient fleet, which is accomplished by this solution. That is, it distributes the fleet within the smart city using the user demand forecasting model described above.

[0124] In some embodiments, when it is expected that several AVs in the fleet are on the verge of exceeding a threshold at the current charge level,

number

[0125] In a further embodiment, the estimation of the maximum time required to deploy a mobile charging station may be performed as follows: For reference in the worst case, the disclosed function is that (if there are more than one) the charge of one set of AVs from any mobile charging station headquarters

number

number

number

number

number

number

number

number

number

number

[0126] In some aspects, the disclosed method is such that the charge within the planned period

number

number

number

[0127] In one exemplary embodiment, the disclosed method is

number

number

[0128] To form clusters, the disclosed method can avoid using the Euclidean distance between the expected position of the AV as it approaches the need for recharging and the current center of mass in iteration i of the clustering algorithm. The distance between the two points does not reflect the time the AV may have to cross a congested street to reach the expected position of the mobile charger, and such cumbersome issues. Instead, the disclosed method uses the expected time the AV will need to cross the sum of waypoints (as shown in Figure 9),

number

number

number

number

number

number

number

number

number

[0129] Once the above analysis is complete, the mobile stations are deployed to their assigned clusters. The disclosed method can be used to determine the optimal location for deploying the mobile charging infrastructure for each cluster. In some embodiments, the optimal location may be closer to the center of mass of such a cluster. This location determination is influenced not only by the center of mass but also by the availability of space convenient for deploying the mobile infrastructure. The mobile infrastructure is deployed in anticipation, while analyzing the time required to reach the best location for each cluster and the estimated time it takes for the AVs to complete their movement and move to the determined movement location. As a result, AV downtime is minimized (as shown in Figure 9). The disclosed method may use a clustering algorithm, e.g., K-means, to ensure that all AVs in the set of AVs that need to be charged are assigned to a cluster, and so that the mobile charging infrastructure covers them.

[0130] Figure 9 shows a diagram 900 of an example cluster of several vehicles being serviced by a mobile charging station, according to one exemplary embodiment. Referring to Figure 9, the mapped area shown indicates the deployment of the autonomous vehicle 902, the expected position of the AV when its charge falls below a threshold 904, and the mobile charging station 906.

[0131] In some embodiments, according to a fleet utility prediction model, vehicle recharging while at a mobile hotspot may be full or partial, depending on the capacity of mobile charge allocated to the sector and the number of AVs being recharged (the goal is to minimize AV downtime). The recharging station returns to HQ to prepare for the next charging round. Using the disclosed technique, when it is detected that an additional N AVs are approaching the recharge level, the process of planning the next EDV deployment can be resumed. In some embodiments, if AVs in a fleet have similar charge capacities and are patrolling the city from similar start times, there is a high probability that a group of vehicles in a cluster will run out of charge at similar times.

[0132] The disclosed methods could be used to minimize the presence of fixed charging stations in future smart cities, but if this type of infrastructure is available, it could be incorporated into innovations for service vehicles if it is the most efficient option available. The disclosed methods may include recovery features for AVs that become stranded due to unforeseen circumstances.

[0133] Figure 10 is a flowchart illustrating a method 1000 for managing a fleet of vehicles according to an exemplary embodiment. Referring to Figure 10, the method 1000 includes operations 1002, 1004, 1006, 1008, and 1010 that can be performed by MLSS 112 in the fleet management system 102. Operation 1002 retrieves vehicle parameters associated with the fleet of vehicles (e.g., fleet vehicle information 308). Vehicle parameters include, for example, a movement estimate range for each vehicle in the fleet. Operation 1004 retrieves infrastructure resource availability information (e.g., resource availability information 310) associated with at least one infrastructure resource used by the fleet of vehicles. Operation 1006 retrieves historical usage information (which may be part of resource availability information 310) associated with at least one infrastructure resource. In operation 1008, scheduling instructions are generated using machine learning based on vehicle parameters, infrastructure resource availability information, and historical usage information (e.g., instructions 320, 322, and 324). In operation 1010, the scheduling instructions may be transmitted to the vehicle fleet (e.g., via the vehicle gateway 106). The scheduling instructions may be used to schedule the use of at least one infrastructure resource by one or more vehicles in the fleet.

[0134] Figure 11 is a block diagram showing an exemplary machine of a computer system 1100 according to one embodiment. In this machine, a set or sequence of instructions may be executed to cause the machine to perform any one of the methods described herein. In alternative embodiments, the machine may operate as a standalone device or be connected to other machines (e.g., networked). In a networked deployment, the machine may operate as a server or client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a vehicle subsystem, a personal computer (PC), a tablet PC, a hybrid tablet, a personal digital assistant (PDA), a mobile phone, or any machine capable of executing instructions (sequentially or otherwise) that specify the actions to be performed by that machine. Furthermore, although only a single machine is illustrated, the term “machine” shall also be interpreted to include any set of machines individually or collectively executing one (or more) sets of instructions to perform any one or more of the methods described herein. Similarly, the term “processor-based system” shall be interpreted as including any set of one or more machines controlled or operated by a processor (e.g., a computer) to individually or collectively execute instructions for performing one or more of the methods described herein.

[0135] An exemplary computer system 1100 includes at least one processor 1102 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both, a processor core, a compute node, etc.), main memory 1104, and static memory 1106, which communicate with each other via a link 1108 (e.g., a bus). The computer system 1100 may further include a video display unit 1110, an alphanumeric input device 1112 (e.g., a keyboard), and a user interface (UI) navigation device 1114 (e.g., a mouse). In one embodiment, the video display unit 1110, the input device 1112, and the UI navigation device 1114 are integrated into a touchscreen display. The computer system 1100 may further include a memory device 1116 (e.g., a drive unit), a signal generation device 1118 (e.g., a speaker), a network interface device 1120, and one or more sensors (not shown), such as a Global Positioning System (GPS) sensor, a compass, an accelerometer, a gyrometer, a magnetometer, or other sensors. In some embodiments, the processor 1102 may include a main processor and a deep learning processor (e.g., used to perform deep learning functions including the neural network processing described above).

[0136] The storage device 1116 includes a machine-readable medium 1122 in which one or more sets of data structures and instructions 1124 (e.g., software) are stored, which embody or utilize one or more of the methods or functions described herein. The instructions 1124 may reside entirely or at least partially in the main memory 1104, the static memory 1106, and / or in the processor 1102 being executed by the computer system 1100, the main memory 1104, the static memory 1106, and the processor 1102 also constitute the machine-readable medium.

[0137] In one exemplary embodiment, the machine-readable medium 1122 is shown as a single medium, but the term “machine-readable medium” may include a single or multiple mediums (e.g., a centralized or distributed database, and / or associated caches and servers) that store one or more instructions 1124. The term “machine-readable medium” shall also be interpreted as including any tangible medium capable of storing, encoding, or carrying instructions for execution by a machine, and capable of causing a machine to execute one or more of the methods of the Disclosure, or storing, encoding, or carrying data structures utilized by or associated with such instructions. Accordingly, the term “machine-readable medium” shall be interpreted as including, but is not limited to, solid-state memory, optical media, and magnetic media. Specific examples of machine-readable media include, but are not limited to, non-volatile memory, including semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)) and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

[0138] Instruction 1124 may further be transmitted or received over a communication network 1126 using a transmission medium via a network interface device 1120 that utilizes one of several well-known transmission protocols (e.g., HTTP). Examples of communication networks include local area networks (LANs), wide area networks (WANs), the Internet, cellular networks, basic telephone (POTS) networks, and wireless data networks (e.g., Bluetooth®, Wi-Fi®, 3G, and 4G LTE / LTE-A, 5G, DSRC, or WiMAX networks). The term “transmission medium” shall be interpreted as including any intangible medium that can store, encode, or carry instructions for execution by a machine and that includes digital or analog communication signals or other intangible media for facilitating communication of such software.

[0139] In consideration of the above disclosures, various examples are described below. One or more features of the examples given separately or in combination should be considered within the scope of the disclosures of this application.

[0140] Example 1 is a system comprising a scheduling subsystem, the scheduling subsystem is configured to acquire vehicle parameters associated with a fleet of vehicles, the vehicle parameters including a movement estimation range for each of the vehicles in the fleet; acquire infrastructure resource availability information associated with at least one infrastructure resource used by the fleet of vehicles; acquire historical usage information associated with the at least one infrastructure resource; generate scheduling orders using machine learning based on the vehicle parameters, the infrastructure resource availability information, and the historical usage information; and transmit the scheduling orders to the fleet of vehicles, the scheduling orders being for scheduling the use of the at least one infrastructure resource by one or more of the vehicles in the fleet.

[0141] In Example 2, the subject described in Example 1 includes an information sharing subsystem configured to register the infrastructure resource availability information in a database shared with the scheduling subsystem based on a registration request from the resource owner of the at least one infrastructure resource.

[0142] In Example 3, the subject described in Example 2 includes a subject in which the registration request further includes usage fees and available hours for at least one of the infrastructure resources.

[0143] In Example 4, the subject described in either Example 2 or 3 includes a subject wherein the scheduling instruction includes a reservation instruction for reserving the use of the at least one infrastructure resource for a future time, and the information sharing subsystem is further configured to communicate the reservation instruction to the resource owner of the at least one infrastructure resource.

[0144] In Example 5, the subject described in any of Examples 2 to 4 includes a subject in which at least one of the infrastructure resources includes one or more of the following: public parking resources, private parking resources, fuel refueling station resources, and electric vehicle charging station resources.

[0145] In Example 6, the subject described in any of Examples 1 to 5 further includes the subject, wherein the vehicle parameters also include the current geographical location and route information for each vehicle within the fleet of vehicles.

[0146] In Example 7, the subject described in Example 6 further includes a subject in which the above vehicle parameters also include parking availability information regarding public or private parking resources located near the current geographical location.

[0147] In Example 8, the subject described in any of Examples 1 to 7 includes a subject in which the estimated movement range includes a first estimated movement range based on the remaining charge for each of the first set of electric vehicles in the fleet and a second estimated movement range based on the fuel level for each of the second set of non-electric vehicles in the fleet.

[0148] In Example 9, the subject described in Example 8 is configured to generate a second scheduling command using machine learning based at least on the first movement estimate range for each of the first set of electric vehicles, wherein the second scheduling command includes a command to schedule at least one energy distribution vehicle (EDV) to the current geographical location of at least one of the first set of electric vehicles, and the first movement estimate range for the electric vehicles is below a threshold range.

[0149] In Example 10, the subject described in Example 9 further includes a subject in which the second scheduling command further includes a command for scheduling the recharging of the at least one electric vehicle by the at least one EDV at a stationary position within a predetermined distance from the current geographical location of the electric vehicle.

[0150] In Example 11, the subject described in either Example 9 or 10 includes a subject wherein the second scheduling instruction further includes an instruction for scheduling the recharging of the electric vehicle by the at least one EDV or another electric vehicle while both the at least one EDV or the other electric vehicle and the electric vehicle are in motion.

[0151] In Example 12, the subject described in any of Examples 8 to 11 includes a subject, wherein the scheduling subsystem is further configured to use machine learning to estimate future demand for the first set of vehicles or the second set of vehicles over a future period within the geographical locations forming the service area, and to use machine learning to determine the future usefulness of the first set of vehicles or the second set of vehicles over a future period within the geographical locations by applying the machine learning method.

[0152] In Example 13, the subject matter described in Example 12 includes a subject matter in which the future utility includes the estimated charge for each of the first set of electric vehicles during the future period and the estimated fuel level for each of the second set of non-electric vehicles during the future period.

[0153] In Example 14, the subject described in Example 13 is configured to further update the service area map based on the estimated future demand and fleet range forecast, the fleet range forecast being based on the estimated charge and the estimated fuel level, and to schedule energy distribution vehicles (EDVs) to be deployed to geographic locations within the service area, such that the geographic locations associated with the estimated future demand are above a first threshold and the fleet range forecast is below a second threshold.

[0154] In Example 15, the subject described in any of Examples 1 to 14 includes a subject comprising a distributed ledger technology subsystem (DLT subsystem) configured to detect the use of the at least one infrastructure resource by vehicles in the fleet and to record ledger entries in the distributed ledger of the DLT subsystem, wherein the ledger entries are associated with payments for the use of the at least one infrastructure resource by the vehicles.

[0155] Example 16 is a computing device comprising a network interface card (NIC) and a processing circuit coupled to the NIC, wherein the processing circuit is configured to perform operations including: acquiring vehicle parameters associated with a fleet of vehicles, wherein the vehicle parameters include a movement estimation range for each of the vehicles in the fleet; acquiring infrastructure resource availability information associated with at least one infrastructure resource used by the fleet of vehicles; acquiring historical usage information associated with the at least one infrastructure resource; generating a scheduling instruction using machine learning based on the vehicle parameters, the infrastructure resource availability information, and the historical usage information; and transmitting the scheduling instruction to the fleet of vehicles via the NIC, wherein the scheduling instruction is for scheduling the use of the at least one infrastructure resource by one or more of the vehicles in the fleet.

[0156] In Example 17, the subject described in Example 16 includes a subject in which the movement estimation range includes a first movement estimation range based on the remaining charge for each of a first set of electric vehicles in the fleet and a second movement estimation range based on the fuel level for each of a second set of non-electric vehicles in the fleet, and the processing circuit is configured to perform an operation that generates a second scheduling instruction using machine learning, based at least on the first movement estimation range for each of the first set of electric vehicles, wherein the second scheduling instruction includes an instruction to schedule an energy distribution vehicle (EDV) to the current geographical location of the first set of electric vehicles, and the first movement estimation range for the electric vehicles is below a threshold range.

[0157] In Example 18, the subject described in Example 17 is configured to perform operations including using machine learning to estimate future demand for the first set of vehicles or the second set of vehicles in a future period within the geographical locations forming a service area, and using machine learning to determine the future utility of the first set of vehicles or the second set of vehicles in a future period within the geographical locations, wherein the future utility includes the estimated charge for each of the first set of electric vehicles in the future period and the estimated fuel level for each of the second set of non-electric vehicles in the future period.

[0158] In Example 19, the subject described in Example 18 includes a subject configured to perform operations including updating the service area map based on estimated future demand and fleet range forecast, wherein the fleet range forecast is based on estimated charge and estimated fuel level, and scheduling energy distribution vehicles (EDVs) to be deployed to geographic locations within the service area, wherein the geographic locations associated with the estimated future demand are above a first threshold and the fleet range forecast is below a second threshold.

[0159] Example 20 is a machine-readable storage medium having an instruction, the instruction, when executed by a processing circuit of a computing device in a Mobility-as-a-Service (MaaS) network, causes the processing circuit to perform an operation including: an operation to acquire vehicle parameters associated with a fleet of vehicles, wherein the vehicle parameters include a range of movement estimates for each of the vehicles in the fleet; an operation to acquire infrastructure resource availability information associated with at least one infrastructure resource used by the fleet of vehicles; an operation to acquire historical usage information associated with the at least one infrastructure resource; an operation to generate a scheduling instruction using machine learning based on the vehicle parameters, the infrastructure resource availability information, and the historical usage information; and an operation to transmit the scheduling instruction to the fleet of vehicles, wherein the scheduling instruction is for scheduling the use of the at least one infrastructure resource by one or more of the vehicles in the fleet.

[0160] In Example 21, the subject described in Example 20 further includes a subject that causes the instruction to perform an operation which includes an operation to detect the use of the at least one infrastructure resource by a vehicle in the fleet, and an operation to record ledger entries in a distributed ledger, wherein the ledger entries are associated with a payment for the use of the at least one infrastructure resource by the vehicle.

[0161] Example 22 is a machine-readable medium having an instruction, the instruction, when executed by a processing circuit, causes the processing circuit to perform an operation that performs any of Examples 1 to 21.

[0162] Example 23 is an apparatus that includes means for carrying out any of Examples 1 to 21.

[0163] Example 24 is a system that implements any of Examples 1 through 21.

[0164] Example 25 is a method of implementing any of Examples 1 through 21.

[0165] The detailed description above includes references to the accompanying drawings, which form part of the detailed description. The drawings illustrate specific embodiments that may be practiced. These embodiments are also referred to herein as “examples.” Such examples may include more than one element in addition to those illustrated or described. However, examples that include only the illustrated or described elements are also contemplated. Furthermore, with respect to a particular example (or one or more embodiments thereof) or another example (or one or more embodiments thereof) illustrated or described herein, examples (or one or more embodiments thereof) that use any combination or substitution of those illustrated or described elements are also contemplated.

[0166] Publications, patents, and patent documents referenced herein are incorporated herein by reference in their entirety, as if they were incorporated individually by reference. In the event of any inconsistent use between this specification and those references incorporated by reference, the use in the incorporated references is supplementary to that herein, and the use herein governs any irreconcilable inconsistencies.

[0167] In this specification, the term “one (a or an)” is used to include one or more, independently of any other instances or uses of “at least one” or “one or more” as found in the patent documents. In this specification, the term “or” is used to refer to a non-exclusive OR, such that “A or B” includes “A but not B,” “B but not A,” and “A and B.” In the appended claims, the terms “including” and “in which” are used as plain English equivalents of their corresponding terms “equipped with” and “here.” Furthermore, in the following claims, the terms “including” and “equipped with” are not restricted; that is, a system, device, article, or process that includes more than one element in addition to the elements listed after such terms in a claim is still considered to be included within the scope of that claim. Moreover, in the following claims, terms such as “first,” “second,” and “third” are used merely as labels and are not intended to suggest a numerical order of their subjects.

[0168] The above description is intended to be illustrative and not limiting. For example, the above example (or one or more of its embodiments) may be used in combination with others. Other embodiments may be used by those skilled in the art when considering the above description. The abstract is intended to allow the reader to quickly confirm the nature of the technical disclosure. The abstract is submitted with the understanding that it will not be used to interpret or limit the claims or their meaning. Furthermore, in embodiments for carrying out the above invention, various features may be grouped together to streamline the disclosure. However, since embodiments may feature a subset of such features, the claims may not describe all of the features disclosed herein. Moreover, embodiments may include fewer features than those disclosed in a particular example. Accordingly, the following claims are incorporated into embodiments for carrying out the invention together with claims that stand independently as separate embodiments. The scope of embodiments disclosed herein should be determined by referring to the appended claims, together with the entire scope of equivalents to which such claims are granted. [Other adjacent items] (Item 1) A system comprising a scheduling subsystem, wherein the scheduling subsystem is Obtaining vehicle parameters associated with a fleet of vehicles, wherein the vehicle parameters include a movement estimation range for each of the vehicles in the fleet. To obtain infrastructure resource availability information associated with at least one infrastructure resource used by the above vehicle fleet, Obtaining historical usage information associated with at least one of the above infrastructure resources, Based on the above vehicle parameters, the above infrastructure resource availability information, and the above historical usage information, a scheduling command is generated using machine learning. The transmission of the scheduling command to the fleet of the above vehicles, wherein the scheduling command is for scheduling the use of at least one infrastructure resource by one or more of the above vehicles in the fleet. Configured to perform, system. (Item 2) An information sharing subsystem is configured to register the availability information of the infrastructure resource in a database shared with the scheduling subsystem, based on a registration request from the resource owner of at least one of the above infrastructure resources. The system described in item 1 further includes the following: (Item 3) The above registration request further includes the usage fees and available hours for at least one of the above infrastructure resources, as described in item 2. (Item 4) The above scheduling instruction includes a reservation instruction to reserve the above use of at least one of the above infrastructure resources for future use. The above information sharing subsystem is further configured to communicate the above reservation order to the resource owner of the above at least one infrastructure resource. The system described in item 2. (Item 5) At least one of the above infrastructure resources is required. Public parking resources, Dedicated parking resources, Fuel injection station resources, and Electric vehicle charging station resources A system described in item 2, which includes one or more of the following. (Item 6) The above vehicle parameters further include the current geographical location and route information for each vehicle within the fleet, as described in item 1. (Item 7) The above vehicle parameters further include parking availability information regarding public or private parking resources located near the current geographical location, as described in item 6. (Item 8) The system according to item 1, wherein the above-mentioned movement estimation range includes a first movement estimation range based on the remaining charge for each of the first set of electric vehicles in the fleet, and a second movement estimation range based on the fuel level for each of the second set of non-electric vehicles in the fleet. (Item 9) The above scheduling subsystem further: The method involves generating a second scheduling command using machine learning, based at least on the first estimated movement range for each of the first set of electric vehicles, wherein the second scheduling command includes an instruction to schedule at least one energy distribution vehicle (EDV) to the current geographical location of at least one of the first set of electric vehicles, and the first estimated movement range for the electric vehicles is below a threshold range. The system described in item 8, configured to perform the following actions. (Item 10) The system according to item 9, wherein the second scheduling command further includes a command for scheduling the recharging of the at least one electric vehicle by the at least one EDV at a stationary position within a predetermined distance from the current geographical location of the electric vehicle. (Item 11) The system according to item 9, wherein the second scheduling instruction further includes an instruction for scheduling the recharging of the electric vehicle by the at least one EDV or another electric vehicle while both the at least one EDV or the other electric vehicle and the electric vehicle are in operation. (Item 12) The above scheduling subsystem further: Using machine learning, we estimate the future demand for the first set of vehicles or the second set of vehicles over a future period within the geographical locations that make up the service area. By applying the above machine learning method, we will use machine learning to determine the future usefulness of the first set of vehicles or the second set of vehicles in the above geographical location during the above future period. The system described in item 8 is configured as follows. (Item 13) The above future usefulness is The estimated charge for each of the above-mentioned first set of electric vehicles during the above-mentioned future period, The estimated fuel levels for each of the two sets of non-electric vehicles in the above future period and The system described in item 12, including the system described in item 12. (Item 14) The above scheduling subsystem further: Updating the service area map based on the estimated future demand and fleet range forecast, wherein the fleet range forecast is based on the estimated charge and estimated fuel levels. Scheduling energy distribution vehicles (EDVs) to be deployed to geographical locations within the service area, such that the geographical locations associated with the estimated future demand are above a first threshold and the fleet range forecast is below a second threshold. The system described in item 13, configured to perform the following actions. (Item 15) The above system is Distributed Ledger Technology Subsystem (DLT Subsystem) The DLT subsystem is equipped with, To detect the use of at least one infrastructure resource by vehicles within the aforementioned fleet, Recording ledger entries in the distributed ledger of the DLT subsystem, wherein the ledger entries are associated with payments for the use of the vehicle for the at least one infrastructure resource. Configured to perform, The system described in item 1. (Item 16) Network interface card (NIC), Processing circuit coupled to the above NIC and A computing device comprising, The above processing circuit is, An operation to acquire vehicle parameters associated with a fleet of vehicles, wherein the vehicle parameters include a movement estimation range for each of the vehicles in the fleet. An operation to obtain infrastructure resource availability information associated with at least one infrastructure resource used by the above vehicle fleet, The operation of obtaining historical usage information associated with at least one of the above infrastructure resources, Based on the above vehicle parameters, the above infrastructure resource availability information, and the above historical usage information, the operation generates scheduling instructions using machine learning, An operation to transmit the scheduling command to the fleet of vehicles via the above NIC, wherein the scheduling command is for scheduling the use of at least one infrastructure resource by one or more of the vehicles in the fleet; and an operation to transmit the scheduling command. Configured to perform actions including, Computing device. (Item 17) The above-mentioned movement estimation range includes a first movement estimation range based on the remaining charge for each of the first set of electric vehicles in the fleet, and a second movement estimation range based on the fuel level for each of the second set of non-electric vehicles in the fleet, and the processing circuit is An operation to generate a second scheduling command using machine learning, based at least on the first estimated movement range for each of the first set of electric vehicles, wherein the second scheduling command includes a command to schedule an energy distribution vehicle (EDV) to the current geographical location of the first set of electric vehicles, and the first estimated movement range for the electric vehicles is below a threshold range. A device as described in item 16, configured to perform operations including those described above. (Item 18) The above processing circuit is, The operation involves using machine learning to estimate future demand for the first set of vehicles or the second set of vehicles over a future period within the geographical locations that make up the service area, An operation to determine the future usefulness of the first set of vehicles or the second set of vehicles in the above geographical location during the above future period using machine learning. It is configured to perform actions including, The above future utility includes the estimated charge for each of the first set of electric vehicles during the above future period and the estimated fuel level for each of the second set of non-electric vehicles during the above future period. The device described in item 17. (Item 19) The above processing circuit is, An operation to update the service area map based on the estimated future demand and fleet range forecast, wherein the fleet range forecast is based on the estimated charge and estimated fuel levels, An operation to schedule energy distribution vehicles (EDVs) to be deployed to geographical locations within the service area, wherein the geographical locations associated with the estimated future demand are above a first threshold, and the fleet range forecast is below a second threshold. A device as described in item 18, configured to perform operations including those described above. (Item 20) A non-temporary machine-readable storage medium comprising instructions, When the above instruction is executed by the processing circuit of a computing device within a Mobility-as-a-Service (MaaS) network, the processing circuit will: An operation to acquire vehicle parameters associated with a fleet of vehicles, wherein the vehicle parameters include a movement estimation range for each of the vehicles in the fleet. An operation to obtain infrastructure resource availability information associated with at least one infrastructure resource used by the above vehicle fleet, The operation of obtaining historical usage information associated with at least one of the above infrastructure resources, Based on the above vehicle parameters, the above infrastructure resource availability information, and the above historical usage information, the operation generates scheduling instructions using machine learning, An operation to transmit the scheduling command to the fleet of vehicles, wherein the scheduling command is for scheduling the use of at least one infrastructure resource by one or more of the vehicles in the fleet; and an operation to transmit the scheduling command. A machine-readable storage medium that enables the execution of operations including [specific actions]. (Item 21) The above instruction further instructs the above processing circuit: An operation to detect the use of the above-mentioned at least one infrastructure resource by a vehicle within the above-mentioned fleet, An action of recording ledger entries in a distributed ledger, wherein the ledger entries are associated with a payment for the use of the vehicle for the at least one infrastructure resource, and an action of recording A machine-readable storage medium as described in item 20, which enables the execution of operations including the above.

Claims

1. 1. A system comprising a scheduling subsystem, the scheduling subsystem comprising: obtaining vehicle parameters associated with a fleet of vehicles, the vehicle parameters including a travel range estimate for each of the vehicles in the fleet; obtaining infrastructure resource availability information associated with at least one infrastructure resource used by the fleet of vehicles; obtaining historical usage information associated with the at least one infrastructure resource; generating the scheduling instructions based on the vehicle parameters, the infrastructure resource availability information, and the historical usage information using a machine learning model that receives the vehicle parameters, the infrastructure resource availability information, and the historical usage information and outputs scheduling instructions; communicating the scheduling instructions to the fleet of vehicles, the scheduling instructions being for scheduling use of the at least one infrastructure resource by one or more of the vehicles in the fleet; configured to: The scheduling subsystem further comprises: estimating future demand for a first set of vehicles for future time periods within the geographic locations forming a service area using a machine learning model trained with historical data of user demand and outputting future demand for vehicles for the future time periods within the geographic locations forming the service area; determining the future utility of the first set of vehicles within the geographic locations for the future time periods using a machine learning model trained from historical data to estimate fuel / battery consumption, the machine learning model outputting the future utility of vehicles within the geographic locations for the future time periods; determining how much each vehicle must be recharged or refueled to support the demand for the first set of vehicles in the future time period within the geographic location; The system is configured as follows:

2. an information sharing subsystem configured to register the infrastructure resource availability information in a database shared with the scheduling subsystem based on a registration request from a resource owner of the at least one infrastructure resource; The system of claim 1 further comprising:

3. The system of claim 2 , wherein the registration request further includes a usage fee and an available time for the at least one infrastructure resource.

4. the scheduling instructions include a reservation instruction for reserving the use of the at least one infrastructure resource for a future time; the information sharing subsystem is further configured to communicate the reservation command to the resource owner of the at least one infrastructure resource. The system of claim 2 .

5. The at least one infrastructure resource is: public parking resources, dedicated parking resources, Fuel injection station resources, and Electric Vehicle Charging Station Resources The system of claim 2 , comprising one or more of:

6. The system of claim 1 , wherein the vehicle parameters further include current geographic location and route information for each vehicle in the fleet of vehicles.

7. The system of claim 6 , wherein the infrastructure resource availability information further comprises availability timings of public or private parking resources in the vicinity of the current geographic location.

8. 6. The system of claim 1, wherein the travel range estimates include a first travel range estimate based on a remaining charge for each of a first set of electric vehicles in the fleet and a second travel range estimate based on a fuel level for each of a second set of non-electric vehicles in the fleet.

9. The scheduling subsystem further comprises: generating the second scheduling instructions based at least on the first travel range estimate for each of the first set of electric vehicles using a machine learning model that receives the first travel range estimate for each of the vehicles and outputs second scheduling instructions, the second scheduling instructions including instructions for scheduling at least one energy distribution vehicle (EDV) to a current geographic location of at least one electric vehicle in the first set, wherein the first travel range estimate for the electric vehicle is below a threshold range; The system of claim 8 configured to:

10. 10. The system of claim 9, wherein the second scheduling instructions further comprise instructions for scheduling a recharge of the at least one electric vehicle by the at least one EDV at a stationary location within a predetermined distance from the current geographic location of the electric vehicle.

11. 10. The system of claim 9, wherein the second scheduling instructions further include instructions for scheduling a recharging of the electric vehicle by the at least one EDV or another electric vehicle while both the at least one EDV or the other electric vehicle and the electric vehicle are moving.

12. The scheduling subsystem further comprises: estimating future demand for the second set of vehicles for the future time periods within the geographic locations forming the service area using the machine learning model trained with the historical data of user demand and outputting the future demand for the vehicles for the future time periods within the geographic locations forming the service area; determining the future utility of the second set of vehicles within the geographic location for the future time period using the machine learning model trained from the historical data to estimate the fuel / battery consumption and outputting the future utility of the vehicles within the geographic location for the future time period; determining how much each vehicle must be recharged or refueled to support the demand for the second set of vehicles in the future time period within the geographic location; The system of claim 8 , configured to:

13. The future utility is an estimated charge for each of the first set of electric vehicles for the future time period; and an estimated fuel level for each of the second set of non-electric vehicles in the future time period; and The system of claim 12 , comprising:

14. The scheduling subsystem further comprises: updating the map of the service area based on the estimated future demand and a fleet range forecast, the fleet range forecast being based on the estimated charge and the estimated fuel level; scheduling energy distribution vehicles (EDVs) to be deployed at geographic locations within the service area, the geographic locations associated with the estimated future demand above a first threshold and the fleet range forecast below a second threshold; The system of claim 13 configured to:

15. The system comprises: Distributed Ledger Technology Subsystem (DLT Subsystem) The DLT subsystem comprises: Detecting the use of the at least one infrastructure resource by vehicles in the fleet; recording a ledger entry in the distributed ledger of the DLT subsystem, the ledger entry being associated with payment for the use of the at least one infrastructure resource by the vehicle; configured to:

15. The system of any one of claims 1 to 5, 13 and 14.

16. a network interface card (NIC); a processing circuit coupled to the NIC; A computing device comprising: The processing circuitry an operation of obtaining vehicle parameters associated with a fleet of vehicles, the vehicle parameters including a travel range estimate for each of the vehicles in the fleet; obtaining infrastructure resource availability information associated with at least one infrastructure resource used by the fleet of vehicles; obtaining historical usage information associated with the at least one infrastructure resource; generating the scheduling instructions based on the vehicle parameters, the infrastructure resource availability information, and the historical usage information using a machine learning model that receives the vehicle parameters, the infrastructure resource availability information, and the historical usage information and outputs scheduling instructions; an act of communicating the scheduling instructions to the fleet of vehicles via the NIC, the scheduling instructions being for scheduling use of the at least one infrastructure resource by one or more of the vehicles in the fleet; and configured to perform operations including The processing circuitry further comprises: estimating future demand for a first set of vehicles for future time periods within geographic locations forming a service area using a machine learning model trained with historical data of user demand and outputting future demand for vehicles for future time periods within the geographic locations forming the service area; determining future utility of the first set of vehicles within the geographic location for the future time period using a machine learning model trained from historical data to estimate fuel / battery consumption, the machine learning model outputting future utility of vehicles within the geographic location for the future time period; determining how much each vehicle must be recharged or refueled to support the demand for the first set of vehicles in the future time period within the geographic location; 10. A computing device configured to perform operations including:

17. the travel range estimates include a first travel range estimate based on a remaining charge for each of a first set of electric vehicles in the fleet, and a second travel range estimate based on a fuel level for each of a second set of non-electric vehicles in the fleet; The processing circuitry further comprises: generating second scheduling instructions based at least on the first travel range estimate for each of the first set of electric vehicles using a machine learning model that receives the first travel range estimate for each of the vehicles and outputs second scheduling instructions, the second scheduling instructions including instructions for scheduling an energy distribution vehicle (EDV) to a current geographic location of the first set of electric vehicles, and the first travel range estimate for the electric vehicles is below a threshold range; 17. The computing device of claim 16 configured to perform operations including:

18. The processing circuitry further comprises: estimating future demand for the second set of vehicles for the future time periods within the geographic locations forming the service area using the machine learning model trained with the historical data of user demand, the machine learning model outputting the future demand for the vehicles for the future time periods within the geographic locations forming the service area; determining the future utility of the second set of vehicles within the geographic location for the future time period using the machine learning model trained from the historical data to estimate the fuel / battery consumption and outputting the future utility of the vehicles within the geographic location for the future time period; determining how much each vehicle must be recharged or refueled to support the demand for the second set of vehicles in the future time period within the geographic location; configured to perform operations including the future utility includes an estimated charge for each of the first set of electric vehicles in the future time period and an estimated fuel level for each of the second set of non-electric vehicles in the future time period; 20. The computing device of claim 17.

19. The processing circuitry further comprises: updating the map of service areas based on the estimated future demand and a fleet range forecast, the fleet range forecast being based on the estimated charge and the estimated fuel level; scheduling energy distribution vehicles (EDVs) to be deployed at geographic locations within the service area, the geographic locations associated with the estimated future demand above a first threshold and the fleet range forecast below a second threshold; 20. The computing device of claim 18 configured to perform operations including:

20. A program, A processing circuit of a computing device in a Mobility-as-a-Service (MaaS) network includes: obtaining vehicle parameters associated with a fleet of vehicles, the vehicle parameters including a travel range estimate for each of the vehicles in the fleet; obtaining infrastructure resource availability information associated with at least one infrastructure resource used by the fleet of vehicles; obtaining historical usage information associated with the at least one infrastructure resource; generating the scheduling instructions based on the vehicle parameters, the infrastructure resource availability information, and the historical usage information using a machine learning model that receives the vehicle parameters, the infrastructure resource availability information, and the historical usage information and outputs scheduling instructions; communicating the scheduling instructions to the fleet of vehicles, the scheduling instructions being for scheduling use of the at least one infrastructure resource by one or more of the vehicles in the fleet; Execute The program causes the processing circuit to: estimating future demand for a first set of vehicles for future time periods within the geographic locations forming a service area using a machine learning model trained with historical data of user demand, the machine learning model outputting future demand for vehicles for future time periods within the geographic locations forming the service area; determining the future utility of the first set of vehicles within the geographic location for the future time period using a machine learning model trained from historical data to estimate fuel / battery consumption, the machine learning model outputting the future utility of vehicles within the geographic location for the future time period; determining how much each vehicle must be recharged or refueled to support the demand for the first set of vehicles in the future time period within the geographic location; A program that further executes the above.

21. The processing circuitry detecting the use of the at least one infrastructure resource by vehicles in the fleet; recording a ledger entry in a distributed ledger, the ledger entry being associated with a payment for the use of the at least one infrastructure resource by the vehicle; The program according to claim 20, further comprising:

22. A machine-readable storage medium storing the program according to claim 20 or 21.

Images