Shared vehicle reservation method and device, vehicle and computer readable storage medium

Abstract

The invention discloses a shared vehicle reservation method and device, a vehicle and a computer readable storage medium. The method comprises the steps that vehicle reservation information of a target user is acquired; matching the vehicles meeting a preset condition, and generating a matching result; wherein the preset conditions include elimination of vehicles with faults, insufficient residual endurance, reservation conflicts and exceeding the vehicle use range; pushing a matching result and cost estimation, and obtaining a user confirmation instruction to generate a vehicle reservation order; wherein the reservation order comprises use permission information of the target vehicle corresponding to the matching result; and obtaining the use state of the target user on the target vehicle, and generating a fee bill after the vehicle use is finished. By applying the technical scheme of the invention, the technical problem that the user cannot find the vehicle to use after arriving at the vehicle taking point due to the fact that the problems of vehicle fault, insufficient endurance, reservation conflict, geographical range limitation and the like are not comprehensively considered in the vehicle matching process of the existing shared vehicle platform can be solved.

Description

Methods, devices, vehicles, and computer-readable storage media for booking shared vehicles Technical Field

[0001] This application relates to the field of vehicle technology, and specifically to a method, apparatus, vehicle, and computer-readable storage medium for booking shared vehicles. Background Technology

[0002] With the deepening of urbanization and the increasingly diversified travel needs of residents, car sharing has rapidly become a popular innovative transportation service model worldwide. This model effectively alleviates urban traffic congestion and reduces the number of private cars by optimizing vehicle resource allocation, while also reducing energy consumption and environmental pollution, providing users with more flexible and economical travel options. Currently, mainstream car sharing services rely primarily on mobile application platforms. Users input basic information such as usage time, departure location, and destination through these platforms. The system automatically matches nearby available vehicles based on the user's location and sends vehicle information and cost estimates to the user. After confirming the order, the user can pick up the car at the designated location. The system uses keyless unlocking technology to start the vehicle, and after the ride, the fee is settled based on the actual mileage and duration, forming a complete one-stop service process for vehicle booking, unlocking, use, and payment. However, in existing technologies, the vehicle matching process only filters based on the geographical distance between the user and the vehicle, the cost calculation mechanism only uses a single mileage or time-based billing standard, there is a time delay in updating vehicle status data, and the allocation of vehicle usage rights lacks a dynamic verification mechanism, leading to uncertainty regarding vehicle availability and service continuity for users during actual use. Summary of the Invention

[0003] In view of the above problems, this application provides a method, device, vehicle and computer-readable storage medium for reserving shared vehicles, which can solve the technical problem that existing shared vehicle platforms do not comprehensively consider problems such as vehicle failure, insufficient battery life, reservation conflicts and geographical range limitations during the vehicle matching process, resulting in users finding that the vehicle cannot be used after arriving at the pick-up point.

[0004] According to one aspect of the embodiments of this application, a method for reserving shared vehicles is provided. The method includes: obtaining vehicle reservation information of a target user; matching vehicles that meet preset conditions and generating a matching result; wherein the preset conditions include excluding vehicles that are faulty, have insufficient remaining range, have reservation conflicts, or are outside the usage range; pushing the matching result and a cost estimate, and obtaining a user confirmation instruction to generate a vehicle reservation order; wherein the reservation order includes usage permission information of the target vehicle corresponding to the matching result; obtaining the target user's usage status of the target vehicle, and generating a bill of charges after the vehicle is used.

[0005] In one optional exemplary embodiment, a vehicle status dataset of shared vehicles is obtained; wherein the vehicle status dataset includes vehicles The system obtains information such as the current location coordinates of the shared vehicle, its fault status, remaining range, and the reservation waiting time range; it acquires a data set of vehicle reservation information; wherein the vehicle reservation information includes the usage time, departure coordinates, destination coordinates, and estimated usage duration; it matches shared vehicles that meet preset conditions based on the vehicle reservation information and generates matching results.

[0006] In an optional exemplary embodiment, the method further includes: filtering the vehicle status dataset of the shared vehicles; obtaining vehicles in a faulty state from the vehicle status dataset and excluding them to generate a first candidate set; obtaining vehicles with insufficient remaining range from the vehicle status dataset and excluding them to generate a second candidate set; obtaining vehicles in the vehicle status dataset whose reservation waiting time interval overlaps with the usage time, then excluding vehicles in a reservation conflict state and generating a third candidate set; obtaining vehicles in the vehicle status dataset that exceed the preset radius range of the departure coordinates and excluding them to generate a fourth candidate set; and generating the matching result based on the first candidate set, the second candidate set, the third candidate set, and the fourth candidate set.

[0007] In one optional exemplary embodiment, the step of obtaining and excluding vehicles with insufficient remaining range in the vehicle status dataset to generate a second candidate set includes: filtering the power type of vehicles in the shared vehicle status dataset; if the power type of the vehicle is a new energy vehicle, obtaining and excluding new energy vehicles with insufficient remaining battery power based on the user's itinerary determined in the car reservation information to generate a second candidate set; if the power type of the vehicle is a gasoline vehicle, obtaining and excluding new energy vehicles with insufficient remaining fuel based on the user's itinerary determined in the car reservation information to generate a second candidate set.

[0008] In an optional exemplary embodiment, the method further includes: sorting the matching results in ascending order according to a distance threshold to prioritize recommending vehicles closest to the target user; and sorting the matching results by remaining range; wherein new energy vehicles and fuel vehicles are both sorted in descending order.

[0009] In an optional exemplary embodiment, the method further includes: generating a recommendation list based on the matching results; wherein the recommendation list is divided into new energy vehicle groups and fuel vehicle groups according to vehicle power type; generating a recommendation card for each vehicle in the recommendation list; obtaining the selection status of the recommendation card and displaying the corresponding cost estimation information of the recommendation card.

[0010] In an optional exemplary embodiment, the method further includes: if the matching result indicates that there are no available vehicles, then pushing a preset condition adjustment suggestion.

[0011] According to another aspect of the embodiments of this application, a shared vehicle reservation device is provided. The device includes: an acquisition module for acquiring vehicle reservation information of a target user; a matching module for matching vehicles that meet preset conditions and generating a matching result; wherein the preset conditions include excluding vehicles that are faulty, have insufficient remaining range, have reservation conflicts, or are outside the usage range; a push module for pushing the matching result and a cost estimate, and acquiring a user confirmation instruction to generate a vehicle reservation order; wherein the reservation order includes usage permission information of the target vehicle corresponding to the matching result; and a generation module for acquiring the target user's usage status of the target vehicle and generating a cost invoice after the vehicle is used.

[0012] According to another aspect of the embodiments of this application, a vehicle is provided, including: a controller; and a memory for storing one or more programs, which, when executed by the controller, cause the controller to implement the shared vehicle reservation method described above.

[0013] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, wherein a computer program is stored in the computer program, the computer program including at least one executable instruction, which, when executed on a shared vehicle reservation device / vehicle, causes the shared vehicle reservation device / vehicle to perform the operation of the shared vehicle reservation method as described above.

[0014] The shared vehicle reservation method in this application accurately captures user needs by obtaining the target user's vehicle reservation information. It ensures the reliability of the matching results by excluding vehicles with malfunctions, insufficient remaining range, reservation conflicts, or those outside the designated usage area based on preset conditions, thus preventing situations where users arrive at the pick-up point to find the vehicle unusable. By pushing matching results and cost estimates and obtaining user confirmation instructions to generate a vehicle reservation order containing usage permission information, a complete permission allocation mechanism is established, ensuring the security of vehicle use. By obtaining the target user's usage status of the target vehicle and generating a bill after the usage period, closed-loop management of the service process is achieved, improving the system's automation level. This technical solution improves the problem of information opacity in the vehicle matching process. The comprehensive application of multi-dimensional screening conditions significantly improves the accuracy of vehicle availability verification. Simultaneously, the dynamic bill generation mechanism effectively solves the fairness problem caused by a single billing standard, ultimately optimizing platform operational efficiency while ensuring a good user travel experience.

[0015] The above description is merely an overview of the technical solutions of the embodiments of this application. In order to better understand the technical means of the embodiments of this application and to implement them in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the embodiments of this application more obvious and understandable, specific implementation methods of this application are described below. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0017] Figure 1 shows a flowchart of an embodiment of the shared vehicle reservation method applied to remote terminal devices according to this application.

[0018] Figure 2 shows a schematic diagram of an embodiment of the reservation device for shared vehicles applied in this application.

[0019] Figure 3 shows a structural schematic diagram of an embodiment of the vehicle provided in this application. Detailed Implementation

[0020] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0021] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0022] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0023] In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0024] Existing shared vehicle platforms rely solely on geographical distance for a crude selection process during vehicle matching, failing to incorporate crucial operational constraints such as vehicle malfunction status, remaining battery range, scheduling conflicts, and service geofencing. This results in users frequently encountering problems upon arriving at the pick-up point, including vehicles failing to start, low battery / fuel levels, vehicles already booked by others, or vehicles located outside the service area. Such ineffective matching not only wastes user time and disrupts the user experience but also leads to systemic technical flaws such as increased complaint rates, decreased operational trust, and higher vehicle vacancy rates. The root of the problem lies in the multi-dimensional decoupling between vehicle dispatching logic and actual physical conditions and spatiotemporal usage rules, lacking a unified, executable, and verifiable closed-loop matching mechanism.

[0025] In view of this, to address the aforementioned problems, this application proposes a method for reserving shared vehicles. This method aims to resolve the technical issue that existing shared vehicle platforms fail to comprehensively consider vehicle malfunctions, insufficient battery life, reservation conflicts, and geographical limitations during the vehicle matching process, leading to users finding the vehicle unusable upon arrival at the pick-up point. The entity executing this shared vehicle reservation method can be a terminal device, server, vehicle domain controller, cockpit domain controller, or other processing device. The terminal device can be a user equipment (UE), computer, mobile device, user terminal, terminal, cellular phone, personal digital assistant (PDA), handheld device, computing device, in-vehicle device, wearable device, etc. In some possible implementations, this shared vehicle reservation method can be implemented by a processor calling computer-readable instructions stored in memory.

[0026] Specifically, please refer to Figure 1 for the shared vehicle reservation method of this embodiment, which includes the following steps: Step S100, obtaining the vehicle reservation information of the target user.

[0027] The target users refer to those who initiate car-hailing requests through mobile terminals (such as mobile apps, mini-programs, etc.), and their identities are verified through platform real-name authentication and assessment. The car-hailing reservation information is a structured dataset that includes at least the car-hailing start time t. req Geographic coordinates of departure point (X req Y req ), destination geographic coordinates (X dest Ydest The reservation information includes the estimated usage duration Δt; this reservation information is uploaded to the sharing platform service module via HTTPS protocol in encrypted form. In some embodiments, the reservation information may also include user preference tags, such as prioritizing new energy vehicles, prohibiting modified vehicle types, and requiring support for child seats, for weighting in subsequent matching strategies.

[0028] Step S200: Match vehicles that meet the preset conditions and generate matching results.

[0029] The preset conditions include excluding vehicles that are faulty, have insufficient remaining range, have reservation conflicts, or are outside the designated usage area. Vehicles that meet the preset conditions refer to a set of shared vehicles that simultaneously pass four exclusivity checks. The four checks are performed in logical order—that is, if any check fails, the subsequent evaluation of that vehicle is terminated, improving computational efficiency.

[0030] A vehicle with a fault refers to a vehicle whose fault status is indicated by the fault status flag F reported by the vehicle terminal. i =1, this flag is actively triggered by the vehicle's ECU (Electronic Control Unit) or BMS (Battery Management System), including dynamic threshold determinations such as powertrain failure, braking abnormality, high-voltage insulation fault, and communication interruption. For new energy vehicles, it is based on the user's travel distance, combined with the full-charge range M (unit: km) and the current remaining battery percentage E. i Calculate the remaining driving range R i =M×E i When R i <D req For gasoline vehicles, the remaining range is determined to be insufficient; for gasoline vehicles, it is determined based on the fuel tank capacity C. max (Unit: L), Real-time Remaining Oil Volume O i (Unit: L) and fuel consumption η per 100 km (unit: L / 100km), converted to R i =O i / η×100, similarly compare R i With D req .

[0031] Vehicles with reservation conflicts refer to vehicles currently scheduled for the waiting time interval T. i =[T start ,i, T end [i] and user's reserved time slot [t] req , t req +Δt] have an intersection, and the judgment logic is: (t req ∈T i )∨(t req +Δt∈T i )∨(Ti [t req , t req +Δt]).

[0032] Vehicles outside the designated usage area refer to the vehicle's current location (X). i Y i ) and origin coordinates (X req Y req The distance value d i The radius exceeds a preset threshold R, which can range from 3km to 8km, with a default value of 5km. This threshold can be dynamically adjusted based on the city heat map—3km for high-density urban areas and 8km for suburban areas. All verification data sources are from the status dataset uploaded periodically (≤15s interval) by the vehicle terminal module, including vehicle ID information and the current location coordinates (X...). i Y i Fault status F i Remaining battery power E i / Remaining fuel level O i Current appointment waiting time interval T i .

[0033] Step S300: Push the matching result and cost estimate, and obtain user confirmation to generate a vehicle reservation order; wherein, the reservation order includes the usage permission information of the target vehicle corresponding to the matching result; wherein, the matching result is a set C of non-empty vehicles filtered by the above embodiments, and each element includes a unique vehicle identifier, real-time location coordinates, power type, remaining range Ri, and distance d from the user. i and estimated arrival time E TA Cost estimation uses a differentiated billing model: Total Cost = F base +F distance ×D req +F time ×Δt, where F base Basic service fee (e.g., 8 yuan), F distance The price is per kilometer (e.g., 1.5 yuan / km for new energy vehicles and 2.0 yuan / km for gasoline vehicles), F timeThe unit price is based on duration (e.g., 0 yuan / min for Δt≤10min, 0.3 yuan / min for Δt>10min); this estimate is calculated based on vehicle power type before being pushed to avoid miscalculation; the user confirmation instruction is a single click, swipe confirmation, or biometric authentication (e.g., fingerprint, face, palm print, iris, etc.) performed by the user on any matching vehicle card on the terminal interface; the vehicle reservation order is an unalterable electronic certificate issued by the platform, including order ID information, user ID information, vehicle ID information, reservation time period, fee details, time constraints (e.g., automatically invalidated if not unlocked within 15 minutes), and a list of usage permissions; the usage permission information is a fine-grained access control policy, which may specifically include keyless near-field unlocking permission (UWB or NFC band), engine remote start permission (CAN bus command whitelist), and in-vehicle navigation destination writing permission (X dest ,Y dest The permissions for vehicle data access (such as coordinates, driving data reading permissions, speed limit information, SOC information, fault codes, etc.) are all bound to the vehicle usage order cycle and are dynamically issued to the vehicle terminal by the permission allocation and control module.

[0034] Step S400: Obtain the usage status of the target vehicle by the target user, and generate a bill after the vehicle use ends.

[0035] The usage status of the target vehicle can include GPS trajectory point sequences reported by the vehicle terminal (sequences include timestamps, speed, direction angle, etc.), SOC (State of Charge) or fuel level change curves uploaded by BMS / ECU, door / engine opening / closing events, and rapid acceleration / braking events. This status data is encrypted and pushed to the real-time monitoring and anomaly handling module, triggering a two-level response: the first level is a front-end prompt (e.g., an APP pop-up window "Battery remaining 20%, it is recommended to return the car early"), and the second level is a back-end intervention (e.g., automatically shortening the order validity period or recommending the nearest charging station). The end of vehicle use refers to the occurrence of any of the following events: the vehicle is stationary for more than 10 minutes and the SOC / O i <10%, user-initiated "End Trip" button in the app, or order timeout forcibly terminated (e.g., reserved time slot + Δt + 15 minutes), etc.; the bill is the final settlement voucher, generated within a certain period after the trip ends, based on the actual mileage D. actual Actual vehicle usage time Δt actual Additional service fees incurred during the trip (e.g., highway tolls, parking fees, and OCR recognition results) will be recalculated.

[0036] Through the above steps, this application achieves the following: using vehicle reservation information as a trigger point to drive real-time verification of vehicle status data across all dimensions; embedding multiple constraints such as geographical accessibility, vehicle reliability, energy sustainability, and spatiotemporal exclusivity into the matching logic, fundamentally eliminating the problem of "reservation successful but vehicle pickup failed"; preventing disorderly unlocking and unauthorized operations through the coupling of cost estimation and order generation; and constructing a complete closed loop for vehicle reservations by using timely status awareness and dynamic bill recalculation, making every vehicle usage activity traceable and verifiable. This application's solution does not rely on external third-party data sources; all logic is executed autonomously by the platform service module, adapting to various power types such as pure electric vehicles, plug-in hybrid vehicles, gasoline vehicles, and hydrogen fuel cell vehicles.

[0037] In an optional embodiment, the present application further includes: obtaining a vehicle status dataset of the shared vehicles.

[0038] The vehicle status dataset includes vehicle information, current location coordinates of the shared vehicle, fault status, remaining range, and reservation waiting time interval. This dataset is a real-time dynamic data set periodically collected and structured from multiple vehicle terminal modules by the sharing platform service module, used to support vehicle scheduling and matching decisions. Each record in this dataset corresponds to a single shared vehicle, uniquely identified by its vehicle ID. Vehicle information includes the Vehicle Identification Number (VIN), license plate number, vehicle model, power type (new energy vehicle or fuel vehicle), and operating area code. The current location coordinates of the shared vehicle are latitude and longitude pairs in a geographic coordinate system (X...). i Y i Data is acquired periodically uploaded by the vehicle-mounted GNSS (Global Navigation Satellite System); the fault status is indicated by the vehicle's fault flag F. i The value is 0 for a normal state or 1 for a fault state. Fault states include, but are not limited to, battery management system (BMS) communication interruption, braking system malfunction, high-voltage circuit disconnection, and door locking mechanism failure; the remaining range is the driving range R. i (Unit: km), for new energy vehicles, R i = M × E i Where M represents the vehicle's nominal range on a full charge, and E... i The current SOC percentage (0%–100%); for gasoline vehicles, R i = O i / η, where O iThe remaining fuel volume is (L), η is the average measured fuel consumption per 100 km for this model (L / 100 km), converted to fuel consumption per kilometer (L / km); the reservation waiting time interval T. i Let [Tstart, Tend] be a closed interval representing the time period during which the vehicle has been reserved by other users, where T is the starting point. start With T end All timestamps are UTC, written by the platform's order system when a reservation is generated, and automatically cleared after the ride ends or the order is canceled. This interval supports overlap detection logic and is the core basis for judging reservation conflicts.

[0039] Obtain the car booking information dataset; this dataset includes booking time, departure coordinates, destination coordinates, and estimated booking duration. The car booking information dataset is collected by the user terminal module through a mobile application (APP) and submitted to the sharing platform service module as request data. Booking time t req The user-specified start and end time of the planned vehicle rental; the departure coordinates are the geographic coordinates (X, Y, F, G) obtained from the user's location. req Y req ), obtained through mobile phone GPS or Wi-Fi assisted positioning; destination coordinates (X dest ,Y dest The destination location set by the user is also in latitude and longitude coordinates; the estimated usage time Δt is the user's estimated total usage time (in minutes).

[0040] Based on the car-hailing reservation information, vehicles that meet preset conditions in the shared vehicle pool are matched, and a matching result is generated. Here, matching refers to a deterministic filtering and sorting algorithm executed by the shared platform service module. Its input is the vehicle status dataset and the car-hailing reservation information dataset obtained in the above embodiments, and its output is a non-empty ordered list of vehicles C (candidate set).

[0041] First, perform a distance screening: for each shared vehicle i, calculate its current location (X). i ,Y i ) and departure point (X) req ,Y req The distance of ) only if d i The vehicle is retained in the initial candidate set when the distance is ≤ R (R is a preset distance threshold, preferably 5 km). The preset distance threshold is set according to the actual application situation. For example, the preset distance threshold can be 1km, 3km, 5km, etc., and is not specifically limited here.

[0042] Then, multidimensional exclusion is performed: based on the initial candidate set, multiple exclusion rules—fault state F—are applied sequentially. i =1 means excluded; remaining range R i <D reqThen exclude; t req ∈ T i or (t) req + Δt) ∈ T i Vehicles with overlapping time periods are excluded; vehicles whose origin coordinates exceed the geofence of their operating area are excluded; the final matching result is an ordered set of vehicles remaining after the above filtering, and its default sorting strategy is: first sort by d i Ascending order, d i Press R if they are the same i Descending order, R i If the vehicle IDs are the same, they are sorted in ascending order; this result directly drives the subsequent recommendation list generation and cost estimation modules without manual intervention or fuzzy weighting.

[0043] In the above embodiments, the vehicle status dataset provides objective, real-time, and structured vehicle-side input, while the car reservation information dataset provides explicit, quantifiable, and spatiotemporally anchored user-side input; together, they constitute the complete input space of the matching algorithm; and the matching itself is based on verifiable strategies (such as d i Calculation, R i Judgment, T i The deterministic process of overlapping judgment ensures that the same input produces consistent output at different times and on different server nodes; thus solving the problem that existing solutions only match based on distance and do not take into account factors such as faults, battery life, and reservation conflicts, which leads to users being unable to use the car after arrival, and significantly improving the matching success rate.

[0044] In an optional embodiment, the present application further includes: filtering the vehicle status dataset of shared vehicles. Filtering the vehicle status dataset of shared vehicles refers to retrieving the status data information corresponding to all online and validly registered shared vehicles from the real-time vehicle database of the sharing platform service module. This status data information is uniquely identified by the vehicle ID, and each record contains at least the following information: the vehicle's current location latitude and longitude coordinates (X, Y, X). i ,Y i Fault status F i Remaining battery power E i Or remaining oil volume O i Appointment waiting time interval T i This filtering action is triggered immediately upon receiving the user's car booking information by the platform service module, ensuring that the data processed is the latest uploaded status data from the current moment.

[0045] After identifying and excluding vehicles in a faulty state from the vehicle status dataset, a first candidate set is generated. Identifying vehicles in a faulty state involves iterating through all records in the vehicle status dataset and reading the fault state F for each vehicle i. i When F iWhen =1, it is determined that the vehicle has a hardware or software anomaly affecting safe operation, such as a battery management system (BMS) error, a braking system fault code, or a door locking mechanism failure; exclusion is a logical exclusion operation, that is, after constructing an initial candidate set C in memory, F i All vehicle IDs with a value of 1 are removed from C, and the resulting set of remaining vehicles is denoted as the first candidate set C1. This step has the highest priority, ensuring that high-risk vehicles are blocked before subsequent screening.

[0046] After identifying and excluding vehicles with insufficient remaining range from the vehicle status dataset, a second candidate set is generated; where insufficient remaining range refers to the maximum driving distance R supported by the vehicle's current remaining energy. i Less than the user's booked trip distance ;D req Using the departure coordinates (X) in the car booking information req , Y req ) and destination coordinates (X dest ,Y dest ) Calculated to obtain; R i Based on the vehicle's power type, the exclusion refers to all vehicles that meet the R... i <D req Vehicles that are removed from the first candidate set C1 are denoted as the second candidate set C2.

[0047] If the vehicle reservation waiting time interval overlaps with the vehicle usage time in the vehicle status dataset, then vehicles with conflicting reservation statuses are excluded, and a third candidate set is generated. Here, overlap between the reservation waiting time interval and the usage time refers to the T-time interval of vehicle i. i =[T start ,T end [Reserve a car rental time with the user t] req The time interval [t] is composed of the expected vehicle usage time Δt. req ,t req +Δt] have an intersection; that is, t req ∈T i or (t) req +Δt)∈T i or T i [t req ,t req +Δt] or [t] req , t req +Δt] T i Vehicles in a conflicting reservation state are those that meet any of the above overlapping conditions. Exclusion means removing such vehicles from the second candidate set C2, and the resulting set is denoted as the third candidate set C3.

[0048] After retrieving and excluding vehicles from the vehicle status dataset that are outside the preset radius of the origin coordinates, a fourth candidate set is generated; where "outside the preset radius of the origin coordinates" refers to the current position (X...) of vehicle i. i Y i ) and the user's departure location (X) req ,Y req The distance d between them i Exceeding the preset threshold R. Exclusion refers to removing all d values. i Vehicles with value >R are removed from the third candidate set C3, and the resulting set is denoted as the fourth candidate set C4.

[0049] Matching results are generated based on the first, second, third, and fourth candidate sets. These matching results are the final output after multi-level filtering, i.e., C4 is the final matching result. This result is encapsulated as a list of vehicle IDs, with each item accompanied by a corresponding d. i R i T i and T ypei Metadata is used by subsequent cost estimation and sorting modules.

[0050] Through the above scheme, this application achieves modular, traceable and highly deterministic execution of the vehicle screening process. By adopting a phased independent exclusion mechanism, it directly eliminates matching failures caused by omissions in a single dimension through multi-layer constraints such as fault identification, range verification, time conflict detection and geofencing, thus ensuring the consistency and reliability between user reservation behavior and actual vehicle usage results.

[0051] In an optional embodiment, the present application further includes: filtering the power type of vehicles in the vehicle status data of shared vehicles; wherein, the power type filtering is achieved by parsing the vehicle data associated with the vehicle ID, which is entered by the operation and maintenance personnel when the vehicle is connected to the platform and is fixed in the vehicle digital file, supporting the branch judgment of subsequent matching logic, specifically including new energy vehicles and fuel vehicles.

[0052] When the vehicle's power type is a new energy vehicle, a second candidate set is generated by identifying and excluding new energy vehicles with insufficient remaining battery power based on the user's itinerary determined in the vehicle reservation information; where new energy vehicles specifically refer to vehicles that use power batteries as their sole or primary driving energy source, including pure electric vehicles (BEVs) and range-extended electric vehicles (EREVs); the user's itinerary is determined by the departure coordinates (X...) in the vehicle reservation information. req ,Y req ) and destination coordinates (X dest ,Y dest ) It was calculated that the criterion for insufficient remaining power is: E i Converted to equivalent drivable mileage R i Ri =M×E i / 100, where M is the vehicle model's rated full-charge range (unit: km), when R i <D req If the vehicle is deemed to have insufficient remaining battery power, it will be removed from the current candidate set.

[0053] When the vehicle's power type is a gasoline-powered vehicle, a second candidate set is generated by identifying and excluding gasoline-powered vehicles with insufficient remaining fuel based on the user's itinerary determined in the car reservation information; where gasoline-powered vehicles refer to internal combustion engine vehicles that use gasoline or diesel as fuel, and the criterion for determining insufficient remaining fuel is: [The remaining fuel level is missing from the original text]. i Converted to equivalent drivable mileage R i R i =O i / η, where η is the fuel consumption rate per 100 kilometers specified for this vehicle model (unit: L / 100km), when R i <D req If the vehicle is deemed to have insufficient fuel, it will be removed from the current candidate set.

[0054] Through the above solution, this application realizes a differentiated range evaluation model for different power types in the vehicle matching process. By accurately identifying the power type and calculating the range by type, it ensures that all vehicles in the second candidate set are feasible to complete the user's trip, and significantly improves the reliability of the matching results.

[0055] In an optional embodiment, the present application further includes: sorting the matching results in ascending order according to a distance threshold, so as to prioritize recommending vehicles closest to the target user; wherein, the matching results refer to the set of available vehicles formed after passing through the multi-layer screening mechanism defined in this application (i.e., excluding faulty vehicles, vehicles with insufficient remaining range, vehicles with reservation conflicts, and vehicles outside the usage range), and each element of the set includes at least a unique vehicle identifier and the current location coordinates (X). i ,Y i ), the target user's reservation departure coordinates (X) req ,Y req ) and the calculated distance In one optional embodiment, the distance threshold is set to R = 5km. This threshold is used to constrain the spatial accessibility boundary of candidate vehicles, ensuring that all sorted objects are valid candidates that meet the basic spatial accessibility conditions. Ascending sorting refers to sorting based on d... i Arrange the values ​​in ascending order so that d i The smallest vehicle is placed at the top of the recommendation list, thus prioritizing the option with the shortest walking distance and highest arrival efficiency in scenarios with multiple vehicles.

[0056] The matching results are sorted by remaining range; both new energy vehicles and gasoline vehicles are sorted in descending order; remaining range is an operating parameter characterizing a vehicle's ability to continue driving after a single charge / refueling, and its value is strongly correlated with the vehicle's power type: for new energy vehicles, the remaining range R... i =M×E i For gasoline vehicles, the remaining range R i =O i / η; Descending order refers to sorting according to R i The values ​​are arranged from largest to smallest to ensure that vehicles with the longest remaining range are listed first, thereby enhancing the ability to complete the journey under the same distance conditions; both new energy vehicles and fuel vehicles are arranged in descending order, meaning that they are not grouped and sorted independently by power type, but rather under a unified numerical dimension R. i Then perform a global comparison and sorting.

[0057] This application solution enables the application of structured presentation logic to the matching results after the basic vehicle availability screening has been completed, making the recommendation list more user-friendly. By using ascending distance sorting, the walking time from confirming the reservation to actually contacting the vehicle is significantly shortened, improving response speed and service immediacy. Because the descending sorting across power types is used, the deviation in range assessment caused by differences in power type is effectively avoided, enhancing the robustness of the trip in long-distance or high-load scenarios.

[0058] In an optional embodiment, the present application further includes: generating a recommendation list based on the matching results; wherein the recommendation list is divided into new energy vehicle groups and fuel vehicle groups according to vehicle power type; the matching results refer to the set of available vehicles retained after multi-layer screening (including distance threshold judgment, fault status elimination, reservation conflict identification, remaining battery / remaining fuel, etc.) in the above embodiments; the recommendation list is determined by dividing the above matching results into new energy vehicle groups and fuel vehicle groups according to vehicle power type, and based on the PowerType field explicitly marked in the vehicle status dataset uploaded by the vehicle terminal module; for each vehicle in the recommendation list, a recommendation card is generated; wherein the recommendation card is a standardized UI component for user terminals (such as smartphone APP, in-vehicle HMI or mini-program interface), each card is uniquely bound by the vehicle ID, and displays the corresponding recommended new energy vehicle and / or recommended fuel vehicle respectively. The selection status of the recommendation card is obtained, and the corresponding cost estimation information of the recommendation card is displayed. The selection status of a recommended card refers to the effective interactive behavior performed by the user on a specific recommended card on the terminal interface, including but not limited to single clicks, double clicks, long presses, or voice command triggers (such as "select the first new energy vehicle"). This status is captured by the event listener of the user terminal module and reported to the sharing platform service module in real time. The corresponding cost estimation information may include, but is not limited to, the basic service fee F. base Mileage Fee Fdistance ×D req Duration Fee F time ×Δt, etc., then: Total cost = ; ; .

[0059] The cost estimate is embedded as highlighted text at the top of the selected recommended card, with bold font and a color distinct from other fields. If the user switches to a different target card, the original card's cost information is automatically hidden, while the new card's cost information is refreshed simultaneously, ensuring strict consistency between the interface and the backend calculations. Through this solution, this application achieves the following: by structurally dividing the matching results into new energy vehicle groups and fuel vehicle groups, users can browse based on subjective factors such as environmental preferences, cost sensitivity, or range anxiety. Furthermore, without increasing server computing load, through front-end display logic restructuring and a front-end / back-end collaborative response mechanism, the conversion path from matching results to order confirmation is significantly optimized, improving the usability of the shared vehicle service system.

[0060] In an optional embodiment, the present application further includes: if the matching result indicates that no vehicles are available, then a preset condition adjustment suggestion is pushed. Here, "no vehicles are available" means that after completing multiple screenings in the above embodiments (i.e., excluding faulty vehicles, vehicles with insufficient remaining range, vehicles with scheduling conflicts, and vehicles outside the designated usage area), the final generated candidate vehicle set is an empty set; this determination is achieved through real-time logical judgment executed by the shared platform service module. The preset condition adjustment suggestion is a set of built-in prompts in the system, such as "It is recommended to advance / delay the usage time by 5-15 minutes," "The search radius can be expanded to 8km," or "Switch to a nearby area (such as around XX subway station)," "No distinction is made between power types; both fuel vehicles and new energy vehicles are recommended," etc. Through this application, when the vehicle matching module outputs an empty candidate vehicle set, the preset condition adjustment suggestion generation and push mechanism is actively activated, significantly reducing the difficulty of users finding vehicles, thereby improving the platform's service initiative and user experience.

[0061] Figure 2 shows a schematic diagram of an embodiment of the vehicle-sharing reservation device applied to vehicles according to this application. Referring to Figure 2, the vehicle-sharing reservation device 500 includes an acquisition module 510, a matching module 520, a push module 530, and a generation module 540. The acquisition module 510 is used to acquire the vehicle reservation information of the target user. The matching module 520 is used to match vehicles that meet preset conditions and generate a matching result; wherein, the preset conditions include excluding vehicles with malfunctions, insufficient remaining range, reservation conflicts, and vehicles outside the designated usage area. The push module 530 is used to push the matching result and a cost estimate, and acquire a user confirmation instruction to generate a vehicle reservation order; wherein, the reservation order includes the usage permission information of the target vehicle corresponding to the matching result. The generation module 540 is used to acquire the target user's usage status of the target vehicle and generate a cost invoice after the vehicle is used.

[0062] It should be noted that the shared vehicle reservation device 500 provided in the above embodiments and the shared vehicle reservation method provided in the aforementioned embodiments belong to the same concept. The specific way in which each module and unit performs operations has been described in detail in the method embodiments, and will not be repeated here.

[0063] Figure 3 shows a structural schematic diagram of an embodiment of the vehicle of this application, which illustrates a structural schematic diagram of a computer system suitable for implementing the vehicle of this application. The specific embodiments of this application do not limit the specific implementation of the vehicle.

[0064] Please refer to Figure 3. The vehicle includes: a controller; and a memory for storing one or more programs, which, when executed by the controller, perform the aforementioned method for reserving shared vehicles.

[0065] Referring to Figure 3, the vehicle's computer system 600 includes a Central Processing Unit (CPU) 601, which can perform various appropriate actions and processes, such as executing the methods described in the above embodiments, based on programs stored in Read-Only Memory (ROM) 602 or programs loaded from storage section 608 into Random Access Memory (RAM) 603. The RAM 603 also stores various programs and data required for system operation. The CPU 601, ROM 602, and RAM 603 are interconnected via a bus 604. An Input / Output (I / O) interface 605 is also connected to the bus 604.

[0066] The following components are connected to I / O interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to I / O interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 610 as needed so that computer programs read from it can be installed into storage section 608 as needed.

[0067] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by central processing unit (CPU) 601, it performs various functions defined in the system of this application.

[0068] Another aspect of this application provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the shared vehicle reservation method described above. This computer-readable storage medium may be included in the vehicle described in the above embodiments, or it may exist independently and not be installed in the vehicle.

[0069] Another aspect of this application provides a computer program product or computer program, which includes at least one executable instruction. When the executable instruction runs on a shared vehicle reservation device / vehicle, it causes the shared vehicle reservation device / vehicle to perform the shared vehicle reservation method as described below: obtaining the vehicle reservation information of the target user; matching vehicles that meet preset conditions and generating a matching result; wherein the preset conditions include excluding vehicles that are faulty, have insufficient remaining range, have reservation conflicts, or are outside the usage range; pushing the matching result and a cost estimate, and obtaining a user confirmation instruction to generate a vehicle reservation order; wherein the reservation order includes the usage permission information of the target vehicle corresponding to the matching result; obtaining the target user's usage status of the target vehicle, and generating a bill of charges after the vehicle is used.

[0070] In one alternative approach, the executable instructions may further be used to cause the shared vehicle reservation device / vehicle to perform the following operations: acquire a vehicle status dataset of the shared vehicle; wherein the vehicle status dataset includes vehicles The system obtains information such as the current location coordinates of the shared vehicle, its fault status, remaining range, and the reservation waiting time range; it acquires a data set of vehicle reservation information; wherein the vehicle reservation information includes the usage time, departure coordinates, destination coordinates, and estimated usage duration; it matches shared vehicles that meet preset conditions based on the vehicle reservation information and generates matching results.

[0071] In one alternative approach, the executable instructions may further be used to cause the shared vehicle reservation device / vehicle to perform the following operations: filtering the vehicle status dataset of the shared vehicles; obtaining vehicles in a faulty state from the vehicle status dataset and excluding them to generate a first candidate set; obtaining vehicles with insufficient remaining range from the vehicle status dataset and excluding them to generate a second candidate set; obtaining vehicles from the vehicle status dataset whose reservation waiting time intervals overlap with the usage time, excluding vehicles in a reservation conflict state, and generating a third candidate set; obtaining vehicles from the vehicle status dataset that exceed the preset radius range of the departure location coordinates and excluding them to generate a fourth candidate set; and generating the matching result based on the first candidate set, the second candidate set, the third candidate set, and the fourth candidate set.

[0072] In one alternative approach, the executable instructions may further be used to cause the shared vehicle reservation device / vehicle to perform the following operations: filter the power type of vehicles in the shared vehicle status dataset; if the power type of the vehicle is a new energy vehicle, obtain new energy vehicles with insufficient remaining battery power based on the user's itinerary determined in the vehicle reservation information and exclude them to generate a second candidate set; if the power type of the vehicle is a fuel vehicle, obtain new energy vehicles with insufficient remaining fuel based on the user's itinerary determined in the vehicle reservation information and exclude them to generate a second candidate set.

[0073] In an alternative approach, the executable instructions may further be used to cause the shared vehicle reservation device / vehicle to perform the following operations: sort the matching results in ascending order by a distance threshold to prioritize recommending vehicles closest to the target user; sort the matching results by remaining range; wherein new energy vehicles and fuel vehicles are both sorted in descending order.

[0074] In an alternative approach, the executable instructions may further be used to cause the shared vehicle reservation device / vehicle to perform the following operations: generate a recommendation list based on the matching results; wherein the recommendation list is divided into new energy vehicle groups and fuel vehicle groups according to vehicle power type; generate a recommendation card for each vehicle in the recommendation list; obtain the selection status of the recommendation card, and display the corresponding cost estimation information of the recommendation card.

[0075] In one alternative approach, the executable instructions can also be used to cause the shared vehicle reservation device / vehicle to perform the following operations: if the matching result indicates that no vehicle is available, then push a preset condition adjustment suggestion.

[0076] The shared vehicle reservation method in this application accurately captures user needs by obtaining the target user's vehicle reservation information. It ensures the reliability of the matching results by excluding vehicles with malfunctions, insufficient remaining range, reservation conflicts, or those outside the designated usage area based on preset conditions, thus preventing situations where users arrive at the pick-up point to find the vehicle unusable. By pushing matching results and cost estimates and obtaining user confirmation instructions to generate a vehicle reservation order containing usage permission information, a complete permission allocation mechanism is established, ensuring the security of vehicle use. By obtaining the target user's usage status of the target vehicle and generating a bill after the usage period, closed-loop management of the service process is achieved, improving the system's automation level. This technical solution improves the problem of information opacity in the vehicle matching process. The comprehensive application of multi-dimensional screening conditions significantly improves the accuracy of vehicle availability verification. Simultaneously, the dynamic bill generation mechanism effectively solves the fairness problem caused by a single billing standard, ultimately optimizing platform operational efficiency while ensuring a good user travel experience.

[0077] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. The transmitted data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0078] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0079] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0080] According to one aspect of the embodiments of this application, a computer system is also provided, including a Central Processing Unit (CPU), which can perform various appropriate actions and processes based on a program stored in read-only memory (ROM) or a program loaded from storage into random access memory (RAM), such as performing the methods described above. Various programs and data required for system operation are also stored in the RAM. The CPU, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0081] The following components are connected to the I / O interface: input components including keyboards, mice, etc.; output components including cathode ray tubes (CRTs), liquid crystal displays (LCDs), and speakers; storage components including hard drives; and communication components including network interface cards such as LAN (Local Area Network) cards and modems. The communication components perform communication processing via networks such as the Internet. Drives are also connected to the I / O interface as needed. Removable media, such as disks, optical discs, magneto-optical discs, semiconductor memories, etc., are installed on the drive as needed so that computer programs read from them can be installed into the storage components as required.

[0082] The above description is merely a preferred exemplary embodiment of this application and is not intended to limit the implementation of this application. Those skilled in the art can easily make corresponding modifications or alterations based on the main concept and spirit of this application. Therefore, the scope of protection of this application should be determined by the scope of protection claimed in the claims.

[0083] In practice, the collection and processing of data in this application should strictly comply with the requirements of relevant national laws and regulations, obtain the informed consent or separate consent of the data subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the data subject.

Claims

1. A method for booking shared vehicles, characterized in that, The method includes: obtaining the vehicle reservation information of the target user; matching vehicles that meet preset conditions and generating a matching result; wherein, the preset conditions include excluding vehicles that are faulty, have insufficient remaining range, have reservation conflicts, or are outside the usage range; pushing the matching result and a cost estimate, and obtaining a user confirmation instruction to generate a vehicle reservation order; wherein, the reservation order includes the usage permission information of the target vehicle corresponding to the matching result; obtaining the target user's usage status of the target vehicle, and generating a bill after the vehicle usage ends.

2. The method for reserving shared vehicles according to claim 1, characterized in that, The method further includes: obtaining a vehicle status dataset of shared vehicles; wherein, the vehicle status dataset includes vehicles The system obtains information such as the current location coordinates of the shared vehicle, its fault status, remaining range, and the reservation waiting time range; it acquires a data set of vehicle reservation information; wherein the vehicle reservation information includes the usage time, departure coordinates, destination coordinates, and estimated usage duration; it matches shared vehicles that meet preset conditions based on the vehicle reservation information and generates matching results.

3. The method for reserving shared vehicles according to claim 2, characterized in that, The method further includes: filtering the vehicle status dataset of the shared vehicles; obtaining vehicles in a faulty state from the vehicle status dataset and excluding them to generate a first candidate set; obtaining vehicles with insufficient remaining range from the vehicle status dataset and excluding them to generate a second candidate set; obtaining vehicles in the vehicle status dataset whose reservation waiting time interval overlaps with the usage time, then excluding vehicles in a reservation conflict state and generating a third candidate set; obtaining vehicles in the vehicle status dataset that exceed the preset radius range of the departure coordinates and excluding them to generate a fourth candidate set; and generating the matching result based on the first candidate set, the second candidate set, the third candidate set, and the fourth candidate set.

4. The method for reserving shared vehicles according to claim 2, characterized in that, The step of obtaining vehicles with insufficient remaining range from the vehicle status dataset and excluding them to generate a second candidate set includes: filtering the power type of vehicles in the shared vehicle status dataset; if the power type of the vehicle is a new energy vehicle, obtaining new energy vehicles with insufficient remaining battery power based on the user's itinerary determined in the car reservation information and excluding them to generate a second candidate set; if the power type of the vehicle is a gasoline vehicle, obtaining new energy vehicles with insufficient remaining fuel based on the user's itinerary determined in the car reservation information and excluding them to generate a second candidate set.

5. The method for reserving shared vehicles according to claim 3, characterized in that, The method further includes: sorting the matching results in ascending order according to a distance threshold to prioritize recommending vehicles closest to the target user; sorting the matching results by remaining range; wherein new energy vehicles and fuel vehicles are both sorted in descending order.

6. The method for reserving shared vehicles according to claim 1, characterized in that, The method further includes: generating a recommendation list based on the matching results; wherein the recommendation list is divided into new energy vehicle group and fuel vehicle group according to vehicle power type; generating a recommendation card for each vehicle in the recommendation list; obtaining the selection status of the recommendation card and displaying the corresponding cost estimation information of the recommendation card.

7. The method for reserving shared vehicles according to claim 6, characterized in that, The method further includes: if the matching result indicates that there are no available vehicles, then pushing a preset condition adjustment suggestion.

8. A reservation device for shared vehicles, characterized in that, The device includes: an acquisition module for acquiring vehicle reservation information of a target user; a matching module for matching vehicles that meet preset conditions and generating a matching result; wherein the preset conditions include excluding vehicles with malfunctions, insufficient remaining range, reservation conflicts, and vehicles outside the designated usage area; a push module for pushing the matching result and a cost estimate, and acquiring a user confirmation instruction to generate a vehicle reservation order; wherein the reservation order includes usage permission information of the target vehicle corresponding to the matching result; and a generation module for acquiring the target user's usage status of the target vehicle and generating a cost invoice after the vehicle usage ends.

9. A vehicle, characterized in that, include: Controller; A memory for storing one or more programs that, when executed by a controller, cause the controller to implement the shared vehicle reservation method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including at least one executable instruction that, when executed on the shared vehicle reservation device / vehicle, causes the shared vehicle reservation device / vehicle to perform the operation of the shared vehicle reservation method as described in any one of claims 1 to 7.

Images