Shared vehicle returning method, system, medium and device

Abstract

The embodiment of the invention provides a shared vehicle returning method and system, a medium and a device. The method comprises the steps of obtaining motion data of a shared vehicle after an order is initiated; in response to the motion data meeting a first preset condition, obtaining vehicle use information of an order user; determining whether the order user forgets to lock based on the vehicle use information; and in response to the fact that the order user forgets to lock, generating and sending a locking instruction.

Description

Technical Field

[0001] The present invention relates to the field of shared vehicles, and in particular to a method, system, medium and device for returning a shared vehicle. Background Art

[0002] After using a shared vehicle, users often forget to lock the vehicle and return it, causing the vehicle to remain in the continuous billing stage. This causes users to pay more fees for no reason. The vehicle may even be used by others before the order is completed, increasing the user's losses.

[0003] Therefore, it is hoped that a method, system, medium and device for returning a shared vehicle can be provided, which can determine whether the user forgets to lock the vehicle, and then automatically lock and close the vehicle, thereby recovering the user's losses as much as possible and improving the user's vehicle return experience. Summary of the invention

[0004] One or more embodiments of the present specification provide a method for returning a shared vehicle. The method for returning a shared vehicle includes: obtaining motion data of the shared vehicle after an order is initiated; in response to the motion data satisfying a first preset condition, obtaining vehicle usage information of the order user; based on the vehicle usage information, determining whether the order user forgets to lock the vehicle; and in response to the order user forgetting to lock the vehicle, generating and sending a lock instruction.

[0005] One of the embodiments of the present specification provides a shared vehicle return system, comprising: a motion data acquisition module, configured to acquire the motion data of the shared vehicle after an order is initiated; a usage information acquisition module, configured to acquire the vehicle usage information of the order user in response to the motion data satisfying a first preset condition; a determination module, configured to determine whether the order user forgets to lock the vehicle based on the vehicle usage information; and an instruction generation module, configured to generate and send a lock instruction in response to the order user forgetting to lock the vehicle.

[0006] One or more embodiments of the present specification provide a shared vehicle return device, comprising at least one processor and at least one storage device, wherein the processor is configured to execute the shared vehicle return method, and the at least one storage device is configured to store computer instructions.

[0007] One or more embodiments of the present specification provide a computer-readable storage medium, wherein the storage medium stores computer instructions. When a computer reads the computer instructions in the storage medium, the computer executes the method for returning a shared vehicle. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] This specification will be further described in the form of exemplary embodiments, which will be described in detail by the accompanying drawings. These embodiments are not restrictive, and in these embodiments, the same number represents the same structure, wherein:

[0009] Figure 1 is a schematic diagram of an application scenario of a shared vehicle return system according to some embodiments of this specification;

[0010] Figure 2 is a module schematic diagram of a shared vehicle return system according to some embodiments of this specification;

[0011] Figure 3 is an exemplary flow chart of a method for returning a shared vehicle according to some embodiments of this specification;

[0012] Figure 4 is a schematic diagram of a first preset condition according to some embodiments of this specification;

[0013] Figure 5 is an exemplary schematic diagram of a prediction model according to some embodiments of this specification;

[0014] Figure 6 is an exemplary flow chart of a re-unlocking process according to some embodiments of the present specification. DETAILED DESCRIPTION

[0015] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following is a brief introduction to the drawings required for the description of the embodiments. Obviously, the drawings described below are only some examples or embodiments of this specification. For ordinary technicians in this field, this specification can also be applied to other similar scenarios based on these drawings without creative work. Unless it is obvious from the language environment or otherwise explained, the same reference numerals in the figures represent the same structure or operation.

[0016] It should be understood that the "system", "device", "unit" and / or "module" used herein are a method for distinguishing different components, elements, parts, portions or assemblies at different levels. However, if other words can achieve the same purpose, the words can be replaced by other expressions.

[0017] As shown in this specification and claims, unless the context clearly indicates an exception, the words "a", "an", "an" and / or "the" do not refer to the singular and may also include the plural. Generally speaking, the terms "comprise" and "include" only indicate the inclusion of the steps and elements that have been clearly identified, and these steps and elements do not constitute an exclusive list. The method or device may also include other steps or elements.

[0018] Flowcharts are used in this specification to illustrate the operations performed by the system according to the embodiments of this specification. It should be understood that the preceding or following operations are not necessarily performed precisely in order. Instead, the steps may be processed in reverse order or simultaneously. At the same time, other operations may also be added to these processes, or one or more operations may be removed from these processes.

[0019] Since existing shared vehicles require manual operation by the user to end the billing, it is impossible to protect the user's property when the user forgets to lock the vehicle after use. Based on this problem, in some embodiments of this specification, by comprehensively considering the parking spot location, parking time period, user's historical lock forgetting data, etc., it is comprehensively determined whether the parking is a scene of forgetting to lock, so as to achieve automatic lock and close the ticket, save the user's loss as much as possible, and improve the user's car return experience.

[0020] Figure 1 1 is a schematic diagram of an application scenario of a shared vehicle return system according to some embodiments of this specification. Figure 1 As shown, the application scenario 100 of the shared vehicle return system may include a shared vehicle 110, an ordering user 120, a user terminal 130, a server 140, a storage device 150 and a network 160.

[0021] The shared vehicle 110 refers to a shared vehicle with a time-sharing rental model. For example, the shared vehicle may be a shared bicycle, a shared motorcycle, a shared car, etc. In some embodiments, the shared vehicle 110 may be configured with one or more sensors, such as a position sensor, a motion sensor, etc. Based on the one or more sensors, the position data, motion state data (such as stop state, moving state, moving speed), etc. of the shared vehicle may be obtained. The shared vehicle 110 may send the sensor data to the server 140 through the network 160 for subsequent analysis.

[0022] The order user 120 refers to the user who initiates the car order. The order user 120 can initiate an order, end an order, and other operations through the user terminal 130. The user terminal 130 refers to one or more terminal devices or software used by the order user 120. For example, the user terminal 130 can be a device with input and / or output functions such as a mobile phone.

[0023] In some embodiments, the user terminal 130 may send the vehicle usage information to the storage device 150 and / or the server 140 for storage and / or subsequent processing. The vehicle usage information may include the user's own information, data related to the user's current order or data related to the user's historical orders, etc. In some embodiments, the user terminal 130 may also obtain order-related data issued by the server 140, for example, the user terminal 130 may obtain lock prompt information issued by the server 140, etc.

[0024] The server 140 may be used to manage data resources and process data and / or information from at least one component involved in the application scenario 100 or an external data source (e.g., a cloud data center). The server 140 may execute program instructions based on the data, information, and / or processing results, thereby performing one or more functions described in this specification. For example, the server 140 may determine the probability that the order user 120 currently forgets to lock the vehicle based on the vehicle usage information, and then determine whether the user forgets to lock the vehicle.

[0025] In some embodiments, the server 140 may include one or more sub-processing devices (e.g., a single-core processing device or a multi-core multi-core processing device). As an example only, the server 140 may include a central processing unit (CPU), a graphics processing unit (GPU), etc., or any combination thereof.

[0026] The storage device 150 may be used to store data and / or instructions. For example, the storage device 150 may be used to store vehicle usage information transmitted by the user terminal 130 via the network 160. For another example, the storage device 150 may also be used to store one or more instruction data sent by the server 140 to the user terminal 130 or the shared vehicle 110. In some embodiments, the storage device 150 and the server 140 may communicate data via the network 160, and the storage device 150 may also be a part of the server 140.

[0027] In some embodiments, the storage device 150 may include random access memory (RAM), read only memory (ROM), mass storage, etc., or any combination thereof.

[0028] In some embodiments, one or more components of the application scenario 100 may transmit data to other components of the application scenario 100 via the network 160. For example, the server 140 may obtain information and / or data from the user terminal 130, the shared vehicle 110, and the storage device 150 via the network 160, or may send information and / or data to the user terminal 130 and the storage device 150 via the network 160.

[0029] Figure 2is an exemplary module diagram of a shared vehicle return system according to some embodiments of this specification. Figure 2 As shown, the shared vehicle return system 200 (hereinafter referred to as the return system 200 ) may include a motion data acquisition module 210 , a usage information acquisition module 220 , a determination module 230 and an instruction generation module 240 .

[0030] In some embodiments, the vehicle return system 200 may be integrated into one or more of a server, a shared vehicle, and a user terminal.

[0031] The motion data acquisition module 210 can be configured to acquire the motion data of the shared vehicle after the order is initiated.

[0032] In some embodiments, the motion data acquisition module 210 may monitor the sensor status of the shared vehicle to obtain one or more of the status duration, vehicle status, and vehicle location of the shared vehicle.

[0033] The usage information acquisition module 220 may be configured to acquire the vehicle usage information of the ordering user in response to the motion data satisfying a first preset condition.

[0034] In some embodiments, the usage information acquisition module 220 can obtain data such as the user's current parking time period, current parking location, and user's historical forgetting to lock data by monitoring the sensor status of the shared vehicle and retrieving user historical data from a storage device.

[0035] The determination module 230 may be configured to determine whether the ordering user forgets to lock the vehicle based on the vehicle usage information.

[0036] In some embodiments, the determination module can determine whether the ordering user forgets to lock the vehicle based on the vehicle usage information in a variety of ways, such as through mathematical statistics, machine learning, etc.

[0037] The instruction generation module 240 may be configured to generate and send a lock instruction in response to the ordering user forgetting to lock the door.

[0038] In some embodiments, the locking instruction generated by the instruction generation module 240 can be transmitted to the shared vehicle through the network to trigger the shared vehicle to automatically lock. In some embodiments, the locking instruction can also be pushed to the user terminal at the same time to remind the user.

[0039] The instruction generation module 240 may also be configured to obtain user feedback after sending the lock instruction, and send an unlock instruction in response to the user feedback including re-unlocking and the user position meeting the second preset condition.

[0040] For more information about the functions of the motion data acquisition module 210, the usage information acquisition module 220, the determination module 230, and the instruction generation module 240, please refer to the description content in other parts of this specification.

[0041] It should be noted that the above description of the shared vehicle return system and its modules is only for the convenience of description and does not limit this specification to the scope of the embodiments. It is understandable that for those skilled in the art, after understanding the principle of the system, it is possible to arbitrarily combine the modules or form a subsystem to connect with other modules without deviating from this principle. In some embodiments, Figure 2 The motion data acquisition module, usage information acquisition module, determination module and instruction generation module disclosed in the specification can be different modules in a system, or one module can realize the functions of two or more modules. For example, each module can share a storage module, or each module can have its own storage module. Such variations are all within the scope of protection of this specification.

[0042] Figure 3 FIG. 3 is a flow chart of a method for returning a shared vehicle according to some embodiments of the present specification. In some embodiments, process 300 may be executed by the vehicle return system 200. Figure 3 As shown, the process 300 includes the following steps 310 to 340.

[0043] Step 310, obtaining the movement data of the shared vehicle after the order is initiated.

[0044] Movement data refers to data related to the use of shared vehicles, such as the movement trajectory and speed of shared vehicles.

[0045] In some embodiments, the vehicle return system 200 can obtain motion data in a variety of ways. For example, the vehicle return system 200 can obtain motion data through a motion sensor on the shared vehicle.

[0046] In some embodiments, the motion data may include at least one of a vehicle state, a state duration, and a vehicle position.

[0047] The vehicle state may reflect the operating state of the shared vehicle at some time. For example, the vehicle state may include a stopped state, a moving state, etc.

[0048] In some embodiments, the vehicle return system 200 can obtain the vehicle status of the shared vehicle in a variety of ways, such as determining whether the vehicle is in motion based on detection data collected by a motion sensor of the shared vehicle.

[0049] The state duration refers to the duration of a shared vehicle in certain vehicle states. The vehicle return system 200 can obtain the state duration of a shared vehicle in a variety of ways. For example, the vehicle return system 200 can monitor the vehicle state of the shared vehicle in real time, and when the vehicle state changes, determine the state duration of the previous vehicle state.

[0050] In some embodiments, the vehicle return system 200 can obtain the vehicle location based on a variety of methods. For example, the shared vehicle can report its current location to the vehicle return system 200 in real time or according to a preset period or in a preset state. The preset state may include a state where the shared vehicle is in a preset vehicle state or receives a positioning instruction issued by the vehicle return system 200. For example, the shared vehicle can report its real-time location information to the vehicle return system 200 when the vehicle state is a stopped state.

[0051] Step 320, in response to the motion data satisfying the first preset condition, obtaining the vehicle usage information of the ordering user.

[0052] The first preset condition refers to a condition related to the motion data of the shared vehicle. For example, the first preset condition may be that the shared vehicle is in a stopped state. For another example, the first preset condition may be that the vehicle is located at a preset parking spot.

[0053] In some embodiments, the first preset condition can be preset by a technician based on actual needs and experience.

[0054] In some embodiments, the first preset condition may be that the shared vehicle is in a stopped state and the state duration meets the preset time requirement. For more information about the first preset condition, please refer to Figure 4 and related instructions.

[0055] The order user refers to the user who initiated the current order.

[0056] Vehicle usage information refers to data related to the order user's use of the shared vehicle. For example, the vehicle usage information may include the number of times the order user has used the shared vehicle in the past, the start time of the current order, etc.

[0057] In some embodiments, the vehicle return system 200 can obtain the vehicle usage information of the order user in a variety of ways. For example, the vehicle usage information of the order user can be associated with its user identification (such as user ID, etc.) and stored in a storage device, and the vehicle return system 200 can retrieve the vehicle usage information of the order user from the storage device based on the user identification of the order user. For another example, the vehicle return system 200 can determine the vehicle usage information by obtaining the input data of the order user in the user terminal.

[0058] In some embodiments, the vehicle usage information also includes at least one of the current parking location, the current time period, and historical forget-lock data.

[0059] The current parking position refers to the parking position of the shared vehicle at the current time. For example, the current parking position may be the current vehicle position of the shared vehicle. For more information about the vehicle position, see the corresponding content of step 310.

[0060] The current time period refers to the time period to which the current time belongs. In some embodiments, the vehicle return system 200 can divide the time into multiple time periods based on multiple methods. For example, a day can be divided into multiple time periods such as morning (such as 7:00-10:00) and noon (such as 11:00-14:00) based on natural time. For another example, the time can be divided into peak time periods, non-peak time periods, etc. based on the number of orders for shared vehicles at different times.

[0061] In some embodiments, the vehicle return system 200 may determine the current time period based on the division of time periods and the current time point.

[0062] Historical forgetting to lock data refers to data related to forgetting to lock events when order users use shared vehicles in the past, such as the number of times they forget to lock, the time distribution of forgetting to lock, etc.

[0063] In some embodiments, the historical lock forgetting data may include the lock forgetting data of the order user at the current parking location, and the lock forgetting data at other locations. Other locations refer to locations other than the current parking location.

[0064] In some embodiments, the historical data of forgetting to lock a shared vehicle can be obtained based on the historical usage of the shared vehicle by the ordering user, and stored in the vehicle usage information of the corresponding ordering user in the storage device. The vehicle return system 200 can obtain the historical data of forgetting to lock a shared vehicle by the ordering user based on the vehicle usage information stored in the storage device. For a detailed description of the storage device, see Figure 1 The corresponding content.

[0065] In some embodiments, historical lock forgetting data may also be obtained by other means, including but not limited to obtaining manual input confirmation, etc.

[0066] In some embodiments of this specification, the probability of a user forgetting to lock the car at the current parking location can be preliminarily determined by comparing the current parking location, the current time period, and the historical forgetting to lock data. For example, if the number of times the user forgets to lock the car at the current parking location is high in the historical forgetting to lock data, the probability of the user forgetting to lock the car at the current parking location is high. For another example, if the time period of forgetting to lock the car overlaps with the current time period in the historical forgetting to lock data, the probability of the user forgetting to lock the car at the current time period is high. By comprehensively considering the aforementioned factors, the accuracy of the subsequent determination of the probability of forgetting to lock the car can be improved, thereby avoiding the misjudgment of whether the car is forgotten to lock the car.

[0067] In some embodiments, the vehicle usage information also includes the number of historical temporary stops and / or the average temporary stop duration.

[0068] The historical number of temporary stops refers to the number of times an order user temporarily stops when using a shared vehicle within a historical time period.

[0069] In some embodiments, the number of historical temporary stops can be obtained based on the statistics of the historical vehicle usage data of the ordering user. For example, if the vehicle return system 200 determines that a temporary stop has occurred, the statistical value of the number of historical temporary stops of the ordering user is increased by 1, and the vehicle return system 200 can obtain the statistical value as the number of historical temporary stops of the ordering user.

[0070] In some embodiments, the vehicle return system 200 may determine whether temporary parking occurs based on a variety of methods. For example, the vehicle return system 200 may determine whether temporary parking occurs based on the acquired motion data of the shared vehicle.

[0071] In some embodiments, the vehicle return system 200 can determine whether a temporary parking occurs in a variety of ways based on the vehicle state and state duration in the motion data. For example, if in an order, the vehicle state includes a stop state and a moving state that appear successively, wherein the duration of the stop state does not exceed a preset time threshold, and the vehicle state changes to a moving state, then the parking state can be considered to be a corresponding temporary parking.

[0072] For example, if the duration of the stopped state exceeds a preset time threshold, based on the acquired vehicle movement data and the vehicle usage information of the ordering user, the vehicle return system 200 determines that the user did not forget to lock the vehicle during parking, and the subsequent vehicle state becomes a moving state again, and the parking state can be considered to be a corresponding temporary parking.

[0073] For another example, if the vehicle return system 200 determines that the user forgot to lock the vehicle during parking, and after the shared vehicle executes the locking instruction, the user issues a user feedback of re-unlocking the vehicle in response to the locking instruction, then the parking state can be considered to be a corresponding temporary parking. For more information about user feedback and re-unlocking, see Figure 6 The corresponding content.

[0074] The vehicle return system 200 may also use other methods such as obtaining manual input to determine whether temporary parking occurs.

[0075] The average temporary stop duration refers to the average duration of multiple temporary stops corresponding to multiple temporary stops. A temporary stop duration may correspond to the parking duration that occurs during a temporary stop. In some embodiments, the average temporary stop duration may be obtained by calculation based on historical data. For example, the average temporary stop duration may be determined based on the ratio of the total temporary stop duration to the total number of temporary stops.

[0076] Some embodiments in this specification, by adding the number of historical temporary stops and / or the average temporary stop duration to the vehicle usage information, can facilitate the judgment of whether the user has the habit of temporary parking, thereby improving the accuracy of the probability of forgetting to lock the car determined based on the vehicle usage information, and reducing the error rate of misjudging the user's temporary parking as forgetting to lock the car.

[0077] The above description of vehicle usage information is only an example. Vehicle usage information may also include other data related to shared vehicles, such as vehicle type preference, etc.

[0078] Step 330, based on the vehicle usage information, determine whether the ordering user forgets to lock the vehicle.

[0079] In some embodiments, the vehicle return system 200 can determine whether the ordering user forgets to lock the vehicle based on the vehicle usage information in a variety of ways. For example, the vehicle return system 200 can determine whether the ordering user forgets to lock the vehicle based on the vehicle usage information by matching vectors in a vector database.

[0080] As an example only, the vector database may include multiple reference vectors and the user locking status of the historical orders corresponding to each reference vector. The user locking status may include the user forgetting to lock or the user not forgetting to lock. The multiple reference vectors are constructed based on the vehicle usage information corresponding to the historical orders of multiple historical users.

[0081] The vehicle return system 200 can determine the target feature vector based on the currently acquired vehicle usage information; based on the target feature vector, through the vector database, determine the reference vector that meets the preset search conditions with the target feature vector as the target vector. The elements of the target feature vector may include the parking location of the historical order, the parking time period, the user's historical forgetting to lock data, etc. The vehicle return system 200 can determine the user locking state corresponding to the target vector as the current locking state of the order user to determine whether the order user forgets to lock. The preset search condition may be the minimum vector distance, etc.

[0082] In some embodiments, the vehicle return system 200 can also determine whether the ordering user forgets to lock the vehicle based on the vehicle usage information through a prediction model. For more information about the prediction model, please see Figure 5 and related instructions.

[0083] Step 340, in response to the order user forgetting to lock the device, a lock instruction is generated and sent.

[0084] The locking command refers to the command used to control the shared vehicle to lock and end the current order.

[0085] In some embodiments, the vehicle return system 200 may generate a locking instruction and send it to the shared vehicle if it is determined that the ordering user forgets to lock the vehicle.

[0086] After receiving the locking command, the shared vehicle can automatically lock the vehicle and report the locking completion feedback command to the server. The server will end the order and generate the current order fee and send it to the user.

[0087] In some embodiments of this specification, the vehicle return system 200 analyzes the parking habits of the order user based on the vehicle usage information of the order user, thereby determining whether the order user has forgotten to lock the car. In the event that the order user forgets to lock the car, the system automatically locks the car and ends the order, thereby reducing the user's loss and improving the user's vehicle return experience.

[0088] Figure 4 This is a schematic diagram of a first preset condition shown in some embodiments of this specification.

[0089] In some embodiments, the first preset condition 400 may include multiple sub-conditions. For example, the first preset condition 400 may include a first sub-condition 410. The first sub-condition 410 is that the vehicle state of the shared vehicle is a stopped state and the state duration meets the preset time requirement. For more information about the vehicle state, see Figure 3 The corresponding content.

[0090] The preset time requirement refers to the time requirement that the shared vehicle must meet in the stopped state before obtaining the vehicle usage information. For example, the preset time requirement includes that the time the shared vehicle must be stopped must meet a preset time range.

[0091] The preset time range can be preset by technical personnel based on actual needs and experience.

[0092] In some embodiments, the preset time requirement may include a state duration exceeding a time threshold.

[0093] In some embodiments, the time threshold may be determined based on the current order fee.

[0094] The current order fee refers to the fee that the order user needs to pay when completing the order at the current moment. The current moment may refer to the moment when the first preset condition is met or the current real time moment.

[0095] In some embodiments, the vehicle return system 200 can determine the time threshold based on the current order fee in a variety of ways. For example, the vehicle return system 200 can obtain the current vehicle usage time T0 of the shared vehicle, where the current vehicle usage time T0 refers to the time between the time when the order is successfully initiated and the current time; the vehicle return system 200 can obtain the corresponding order fee C0 when the order user locks the vehicle at the current time; and based on the pre-designated fee rules of the shared vehicle, calculate the maximum riding time T1 of the order user under the same order fee C0; and use the difference between the maximum riding time T1 and the current vehicle usage time T0 as the time threshold.

[0096] Some embodiments in this specification, by determining the time threshold based on the order fee, can maximize the user's use time of the shared bicycle without increasing the order fee, thereby maximizing the user's benefits and improving user satisfaction.

[0097] In some embodiments, the time threshold may also be positively correlated with the average stop time of the ordering users.

[0098] The average temporary parking duration refers to the average temporary parking duration corresponding to the historical temporary parking of the order user. For more information about the average temporary parking duration, please refer to Figure 3 and related instructions.

[0099] In some embodiments, the vehicle return system 200 may determine the time threshold value through a first preset comparison table based on the average temporary stop duration. The first preset comparison table may include a correspondence between different average temporary stop durations and time threshold values. The first preset comparison table may be constructed based on prior knowledge or historical data, for example, the longer the average temporary stop duration, the greater the time threshold value.

[0100] Some embodiments in this specification make the determination of the time threshold more in line with the actual needs of each user by fully considering the parking habits of different users when determining the time threshold.

[0101] In some embodiments, the time threshold may be determined based on location characteristics of the vehicle's location.

[0102] The location feature refers to a feature related to the location of the shared vehicle. For example, the location feature may include the administrative region to which the shared vehicle currently resides.

[0103] In some embodiments, the location characteristics may include the vehicle location type, the level of pedestrian traffic at the current vehicle location in the current time period, and the like.

[0104] The vehicle location type refers to the type of environment where the shared vehicle is located. For example, the vehicle location type may include an office building, a business district, a factory, etc. The vehicle return system 200 may classify each operating area into types in advance, and based on the acquired vehicle location information, the vehicle return system 200 may determine the current vehicle location type of the shared vehicle.

[0105] The level of pedestrian flow at the current vehicle location in the current time period can represent the pedestrian flow situation at the current shared vehicle location in the current time period.

[0106] The level of pedestrian flow at the current vehicle position in the current time period can be determined in a variety of ways. For example, the vehicle return system 200 can determine the corresponding level of pedestrian flow based on the current time period and the current vehicle position through a second preset comparison table. The second preset comparison table can include the level of pedestrian flow at each vehicle position in each time period. The second preset comparison table can be constructed based on historical data. For example, the greater the pedestrian flow at the corresponding vehicle position in a certain time period, the higher the corresponding level of pedestrian flow.

[0107] In some embodiments, the vehicle return system 200 can determine the time threshold through a third preset comparison table based on the location feature. The third preset comparison table includes the correspondence between different location features and different time thresholds. The third preset comparison table can be constructed based on prior knowledge or historical data. For example, the higher the level of traffic flow, the smaller the time threshold. For another example, the time threshold when the vehicle location type is a business district is less than the time threshold when the vehicle location type is a factory. The specific correspondence between the vehicle location type and the time threshold can be determined based on the statistics of historical vehicle usage data.

[0108] Some embodiments in this specification reduce the occupation of shared bicycle resources by a single order user by considering the vehicle location type and the level of passenger flow at the vehicle location in the current time period when determining the time threshold, thereby improving the utilization rate of shared bicycles while taking into account the needs of a single user.

[0109] In some embodiments, the first preset condition 400 may further include a second sub-condition 420. The second sub-condition 420 is that the vehicle position meets the parking position requirement.

[0110] In some embodiments, the parking position requirement may be that the vehicle is located within a parking area. The parking area refers to a pre-set standard parking range where the vehicle can be returned.

[0111] In some embodiments of this specification, if the ordering user parks the shared vehicle in the parking area, the possibility that the user parks the vehicle for the purpose of returning the vehicle is increased to a certain extent. In this case, the first preset condition takes the parking location requirements into consideration, and when the first preset condition is met, the vehicle usage information is obtained to determine whether the vehicle is forgotten to be locked, which can improve the accuracy of subsequent judgments.

[0112] Some embodiments in this specification make the first preset condition more comprehensive and reliable by setting corresponding requirements for the vehicle status, status duration and parking position of the shared vehicle. Only when the motion data meets the first preset condition is the vehicle usage information of the ordering user obtained to determine whether the user has forgotten to lock the vehicle, thereby reducing the waste of computing resources.

[0113] In some embodiments, the first preset condition may be any combination of the first sub-condition 410, the second sub-condition 420, and other sub-conditions. The more sub-conditions the first preset condition contains, the more likely it is that the user forgets to lock the vehicle when the motion data of the shared vehicle meets the first preset condition. The judgment of whether the user forgets to lock the vehicle is made only when the first preset condition is met, which can further improve the accuracy of the judgment and save computing resources.

[0114] Figure 5 is an exemplary schematic diagram of a prediction model according to some embodiments of the present specification.

[0115] In some embodiments, the vehicle return system 200 can determine whether the ordering user forgets to lock the vehicle based on the vehicle usage information through a predictive model.

[0116] like Figure 5 As shown, the prediction model 540 can determine the probability of forgetting to lock 550. In some embodiments, the prediction model 540 can be any feasible machine learning model, for example, a deep neural network (DNN) model, a convolutional neural network (CNN) model, etc. or any combination thereof.

[0117] In some embodiments, the input of the prediction model 540 may include the current parking position 510, the current time period 520, and the historical unlocking data 530, and the output may include the unlocking probability 550. In some embodiments, the input of the prediction model 540 may also include other data related to the riding conditions of the shared vehicle, such as the motion data of the shared vehicle.

[0118] The probability of forgetting to lock 550 refers to the probability that the order user forgets to lock the car during the current parking. The probability of forgetting to lock 550 can be expressed in any feasible way such as percentage, degree, etc.

[0119] In some embodiments, if the probability of forgetting to lock 550 satisfies a preset probability condition, it can be considered that the order user forgot to lock. The preset probability condition can be that the probability of forgetting to lock 550 exceeds a preset probability threshold. The preset probability threshold can be set based on historical experience, such as the preset probability threshold can be 60%.

[0120] In some embodiments, the prediction model 540 can be obtained by training the initial prediction model based on a large number of labeled first training samples through training methods such as gradient descent method. Among them, a first training sample corresponds to a historical vehicle use data of a sample user, wherein the historical vehicle use data can be a vehicle use event determined by the vehicle return system 200 as forgotten to lock. A historical vehicle use data may include the parking location and parking time period of a historical parking of the sample user and the historical forgetting to lock data corresponding to the sample user. The label corresponding to the first training sample can be whether the sample user forgot to lock the car during the historical parking. For example, if the user forgets to lock the car, the label value is 1, otherwise it is 0. The label can be obtained by manual annotation.

[0121] The first training sample and label can be obtained based on historical data. The label can be determined based on the feedback result sent by the user through the mobile terminal. For example, if the historical parking event corresponding to the training sample obtains feedback that the user requires re-unlocking, it means that the lock has not been forgotten, and the label value is 0.

[0122] In some embodiments, when the vehicle usage information may include the number of historical temporary stops and / or the average temporary stop duration, the input of the prediction model 540 may also include the number of historical temporary stops and / or the average temporary stop duration of the ordering user. Correspondingly, the first training sample may also include the number of historical temporary stops and / or the average temporary stop duration of the sample user.

[0123] Some embodiments in this specification can significantly reduce the amount of data required for manual calculations, reduce prediction errors, and improve the efficiency and accuracy of determining the probability of forgetting to lock by determining the probability of forgetting to lock based on a prediction model.

[0124] In some embodiments of the present specification, whether the user forgets to lock the car is determined based on a comprehensive analysis of multiple factors related to the user's parking, such as the current parking location, the current time period, historical forgetting to lock data, the historical number of temporary stops and / or the average temporary stop duration, so that the determination result of whether the user forgets to lock the car is more in line with the corresponding user's car usage habits, avoiding misjudgment.

[0125] Figure 6 is an exemplary flow chart of a re-unlocking process according to some embodiments of the present specification.

[0126] Process 600 may be performed by the vehicle return system 200, such as Figure 6 As shown, process 600 may include the following steps.

[0127] Step 610, obtaining user feedback after sending the lock instruction.

[0128] User feedback refers to user feedback on the locking instruction. User feedback may include confirmation of locking, re-unlocking, etc. In some embodiments, user feedback may also include other feedback related to the locking instruction, for example, suggestions for locking operations, etc.

[0129] In some embodiments, the vehicle return system 200 can obtain user feedback in a variety of ways. For example, the vehicle return system 200 can obtain user feedback by sending a lock pop-up window to the user terminal asking whether to re-lock the vehicle, and based on the selection result of the ordering user on the lock pop-up window. If the user chooses to re-lock the vehicle, the user feedback is considered to include re-locking. For another example, if the ordering user chooses to confirm the lock, or does not respond to the lock pop-up window after a time threshold, the user feedback is considered to include confirmation of lock closing.

[0130] In some embodiments, the vehicle return system 200 may also obtain user feedback through other means such as confirming user feedback with the ordering user by phone.

[0131] Step 620: In response to the user feedback including re-unlocking and the user location meeting the second preset condition, sending an unlocking instruction.

[0132] User location refers to the location of the user when he or she sends feedback.

[0133] In some embodiments, the vehicle return system 200 may obtain the user's location based on a variety of methods. For example, the vehicle return system 200 may request the GPS positioning data of the user terminal to obtain the user's location.

[0134] The vehicle return system 200 may also obtain the user's location based on any other feasible method. For example, the vehicle return system 200 may use the location information input by the user in the user terminal as the user's location.

[0135] The second preset condition refers to a condition that the user position must meet. For example, the second preset condition may be that the distance between the user position and the current parking position of the shared vehicle does not exceed a distance threshold. The distance threshold may be determined based on a variety of methods, for example, it may be determined by default.

[0136] In some embodiments, the second preset condition may also be other conditions related to the user's location, such as the user's location does not belong to a preset area.

[0137] The unlocking instruction refers to an instruction for instructing the shared vehicle to perform an unlocking operation. When the user feedback includes re-unlocking and the user's location meets the second preset condition, the vehicle return system 200 sends an unlocking instruction to the shared vehicle, and the shared vehicle can be re-unlocked after receiving the unlocking instruction, thereby avoiding the ordering user from performing the corresponding unlocking operation again.

[0138] In some embodiments, the vehicle return system 200 may send a reminder to the user terminal while sending an unlocking instruction to the shared vehicle, for example, reminding the user that the vehicle has been unlocked again and the user should go to the vehicle as soon as possible.

[0139] In some embodiments, the vehicle return system 200 may also combine the user's location and the current parking location of the shared vehicle to generate route guidance to the shared vehicle to guide the user to the parking location of the shared vehicle.

[0140] In some embodiments, when a shared vehicle receives an unlocking command but fails to unlock successfully, or when the vehicle return system 200 receives a user's feedback on a failed re-unlock based on a user terminal, the vehicle return system 200 can collect the reason for the shared vehicle's failed unlocking or upload the result of the failed unlocking to the server to facilitate the server to determine the existing problem.

[0141] In some embodiments of the present specification, when a user reports that the vehicle needs to be unlocked again, the shared vehicle is controlled to be unlocked directly, which can save the user from having to perform the unlocking operation at the terminal, making it more convenient for the user to use the vehicle. At the same time, requiring the user's location to meet a second preset condition can avoid the situation where the ordering user is too far away from the vehicle when unlocking the vehicle again, and the vehicle is ridden away by others after being unlocked again, making the unlocking process more reasonable.

[0142] An embodiment of the present specification also provides a shared vehicle return device, the device comprising at least one storage device and at least one processor, the at least one storage device being used to store computer instructions; and the at least one processor being used to execute computer instructions to implement any of the shared vehicle return methods described in any of the embodiments of the present specification.

[0143] The embodiments of this specification also provide a computer-readable storage medium, which stores computer instructions. When the computer instructions are executed by a computer, the method for returning a shared vehicle described in any one of the embodiments of this specification is implemented.

[0144] The basic concepts have been described above. Obviously, for those skilled in the art, the above detailed disclosure is only for example and does not constitute a limitation of this specification. Although not explicitly stated here, those skilled in the art may make various modifications, improvements and corrections to this specification. Such modifications, improvements and corrections are suggested in this specification, so such modifications, improvements and corrections still belong to the spirit and scope of the exemplary embodiments of this specification.

[0145] At the same time, this specification uses specific words to describe the embodiments of this specification. For example, "one embodiment", "an embodiment", and / or "some embodiments" refer to a certain feature, structure or characteristic related to at least one embodiment of this specification. Therefore, it should be emphasized and noted that "one embodiment" or "an embodiment" or "an alternative embodiment" mentioned twice or more in different positions in this specification does not necessarily refer to the same embodiment. In addition, certain features, structures or characteristics in one or more embodiments of this specification can be appropriately combined.

[0146] In addition, unless explicitly stated in the claims, the order of the processing elements and sequences described in this specification, the use of alphanumeric characters, or the use of other names are not intended to limit the order of the processes and methods of this specification. Although the above disclosure discusses some invention embodiments that are currently considered useful through various examples, it should be understood that such details are only for illustrative purposes, and the attached claims are not limited to the disclosed embodiments. On the contrary, the claims are intended to cover all modifications and equivalent combinations that are consistent with the essence and scope of the embodiments of this specification. For example, although the system components described above can be implemented by hardware devices, they can also be implemented only by software solutions, such as installing the described system on an existing processor or mobile device.

[0147] Similarly, it should be noted that in order to simplify the description disclosed in this specification and thus help understand one or more embodiments of the invention, in the above description of the embodiments of this specification, multiple features are sometimes combined into one embodiment, figure or description thereof. However, this disclosure method does not mean that the features required by the subject matter of this specification are more than the features mentioned in the claims. In fact, the features of the embodiments are less than all the features of the single embodiment disclosed above.

[0148] In some embodiments, numbers describing the number of components and attributes are used. It should be understood that such numbers used in the description of the embodiments are modified by the modifiers "about", "approximately" or "substantially" in some examples. Unless otherwise specified, "about", "approximately" or "substantially" indicate that the numbers are allowed to vary by ±20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximate values, which may change according to the required features of individual embodiments. In some embodiments, the numerical parameters should take into account the specified significant digits and adopt the general method of retaining digits. Although the numerical domains and parameters used to confirm the breadth of their range in some embodiments of this specification are approximate values, in specific embodiments, the setting of such numerical values ​​is as accurate as possible within the feasible range.

[0149] Each patent, patent application, patent application publication, and other materials, such as articles, books, specifications, publications, documents, etc., cited in this specification are hereby incorporated by reference in their entirety. Except for application history documents that are inconsistent with or conflicting with the contents of this specification, documents that limit the broadest scope of the claims of this specification (currently or later attached to this specification) are also excluded. It should be noted that if the descriptions, definitions, and / or use of terms in the materials attached to this specification are inconsistent or conflicting with the contents described in this specification, the descriptions, definitions, and / or use of terms in this specification shall prevail.

[0150] Finally, it should be understood that the embodiments described in this specification are only used to illustrate the principles of the embodiments of this specification. Other variations may also fall within the scope of this specification. Therefore, as an example and not a limitation, alternative configurations of the embodiments of this specification may be considered consistent with the teachings of this specification. Accordingly, the embodiments of this specification are not limited to the embodiments explicitly introduced and described in this specification.

Claims

1. A method for returning a shared vehicle, characterized in that: include: Obtain the movement data of the shared vehicle after the order is initiated; In response to the movement data satisfying a first preset condition, obtaining vehicle usage information of the ordering user; Based on the vehicle usage information, determining whether the ordering user forgets to lock the vehicle; In response to the order user forgetting to lock the door, a lock instruction is generated and sent.

2. The method according to claim 1, characterized in that The motion data includes at least one of a vehicle state, a state duration, and a vehicle position.

3. The method according to claim 2, characterized in that The first preset condition includes: the shared vehicle is in a stopped state, and the duration of the state meets a preset time requirement.

4. The method according to claim 1, characterized in that The vehicle usage information includes at least one of a current parking location, a current time period, and historical forget-to-lock data.

5. The method according to claim 4, characterized in that The determining, based on the vehicle usage information, whether the ordering user forgets to lock the vehicle comprises: Based on the vehicle usage information, a prediction model is used to determine whether the ordering user forgets to lock the vehicle, and the prediction model is a machine learning model.

6. The method according to claim 4, characterized in that The method further comprises: Obtaining user feedback after sending the lock instruction; In response to the user feedback including re-unlocking, and the user position meeting the second preset condition, sending an unlocking instruction.

7. A shared vehicle return system, characterized in that: include: A motion data acquisition module, configured to acquire motion data of the shared vehicle after the order is initiated; A usage information acquisition module, configured to acquire vehicle usage information of the ordering user in response to the motion data satisfying a first preset condition; A determination module, configured to determine whether the ordering user forgets to lock the vehicle based on the vehicle usage information; The instruction generation module is configured to generate and send a lock instruction in response to the order user forgetting to lock the door.

8. The system according to claim 7, characterized in that The instruction generation module is further configured to: Obtaining user feedback after sending the lock instruction; In response to the user feedback including re-unlocking, and the user position meeting the second preset condition, sending an unlocking instruction.

9. A computer-readable storage medium storing computer instructions, characterized in that: When the computer instructions are executed by a computer, the method according to any one of claims 1 to 6 is implemented.

10. A shared vehicle return device, characterized in that: The apparatus comprises at least one processor and at least one storage device, The at least one storage device is used to store computer instructions; The at least one processor is configured to execute at least part of the computer instructions to implement the method according to any one of claims 1 to 6.

Images