Method and device for querying suspected vehicle and related equipment

Abstract

The invention provides a method and device for querying a suspected vehicle and related equipment. Wherein the OBD detection equipment receives a vehicle identification code VI N input by a user through the query module, obtains a domain name of the server through the configuration management module, and queries whether a vehicle corresponding to the VI N belongs to a suspected vehicle from the corresponding server. And the server verifies the legality of the user and the OBD detection equipment, and returns a query result after successful verification. And the OBD detection equipment receives a response returned by the server, displays a query result to the user, and displays whether the vehicle is in a suspected vehicle list. Wherein the configuration management module can obtain domain names configured by a user, so that the query module is allowed to access different data sources. Therefore, the development efficiency and the cost effectiveness of OBD detection equipment can be improved, the flexibility and the expandability of a suspected vehicle query scheme can be enhanced, and meanwhile, the independence and the safety of data can be ensured.

Description

Technical Field

[0001] This application relates to the field of vehicle query, and particularly to a method, device and related equipment for querying suspected vehicles. Background Art

[0002] In the modern automotive industry, in order to improve the efficiency and safety of vehicle management, many enterprises and institutions need to frequently query and verify vehicle identity information, especially to identify whether there are suspected vehicles. Among them, different vehicle management offices and vehicle management institutions will establish databases of suspected vehicles, and judge the identity of a vehicle by comparing the vehicle's identity information with the database of suspected vehicles.

[0003] Therefore, how to provide a flexible and efficient method for querying suspected vehicles has become an urgent problem to be solved. Summary of the Invention

[0004] An embodiment of this application provides a method for querying suspected vehicles. Among them, on-board diagnostic system (OBD) detection devices are configured with relevant modules for unified query of suspected vehicles, which improves the development efficiency and cost-effectiveness of OBD detection devices. The OBD detection device sends a query request to the server through the relevant modules for querying suspected vehicles, ensuring the independence and security of data during the query of suspected vehicles.

[0005] In a first aspect, a method for querying suspected vehicles is provided, which is applied to an on-board diagnostic system (OBD) detection device. The OBD detection device includes a configuration management module and a query module. The method includes: the OBD detection device logs in to a first user, and based on the identity identification number (ID) of the first user, obtains domain name information through the configuration management module. The domain name information includes user ID, OBD detection device ID, and domain name; the OBD detection device receives a vehicle identification number (VIN), constructs a uniform resource locator (URL) through the query module, and sends a query request to the server indicated by the URL. The query request includes the user ID, the OBD detection device, and the VIN; the OBD detection device receives and displays the query result returned by the server, and the query result is used to indicate whether the vehicle corresponding to the VIN is a suspected vehicle.

[0006] In an embodiment of this application, the OBD detection device receives the VIN input by the user, sends a query request to the server, and receives the query result returned by the server. The OBD detection device and the server can jointly form a service platform for querying suspected vehicles to realize the user's query of suspected vehicles.

[0007] Combined with the first aspect, after the OBD detection device logs in to the first user, the method further includes: the configuration management module reads a configuration file, and the configuration file is used to store the domain name information.

[0008] In the embodiments of the present application, different users correspond to their respective server domain names, and the OBD detection device can obtain the domain name information of the corresponding server according to the ID of the logged-in user.

[0009] Combined with the first aspect, in some implementation manners provided by the first aspect, the server stores a suspected vehicle database. After sending a query request to the server indicated by the URL, the method further includes: the server receives the query request, and verifies the legitimacy of the request based on the user ID and the OBD detection device ID; after determining that the query request is legal, the server queries the vehicle corresponding to the VIN based on the suspected vehicle database, and returns the query result to the OBD detection device.

[0010] In the embodiments of the present application, the server performs identity verification on the received suspected vehicle query request. After passing the identity verification and considering the suspected vehicle query request legal, the server queries for suspected vehicles in the server. If the server considers the query request for the suspected vehicle illegal through the identity verification, it will not provide the service of querying for suspected vehicles. In this way, the server provides query operation services to devices that are confirmed to be safe, improving the data security in the server.

[0011] Combined with the first aspect, in some implementation manners provided by the first aspect, the OBD detection device stores an application programming interface API and a URL template. The API uses the GET request method and requires request parameters including the user ID, the OBD detection device ID, and the VIN.

[0012] In the embodiments of the present application, setting a unified API and URL template for the OBD detection device can improve the development efficiency of related modules of the OBD detection device.

[0013] Combined with the first aspect, in some implementation manners provided by the first aspect, the query module includes a matching module. The matching module is used to obtain the API and the URL template, construct a uniform resource locator URL through the query module, and send a query request to the server indicated by the URL. The method includes: the matching module obtains the VIN and the domain name information, constructs the URL, and adds the user ID, the OBD detection device ID, and the VIN to the API; the OBD detection device sends a query request for the API to the server indicated by the URL.

[0014] In the embodiments of the present application, the query module may include a matching module specifically for obtaining the API and the URL model, which can improve the efficiency of the query module in constructing API requests and URLs.

[0015] In combination with the first aspect, in some embodiments provided in the first aspect, the OBD detection device receives and displays the query result returned by the server. The method includes: the matching module receives the response information returned by the server, extracts and displays the query result in the response information. The response information includes the query result and a status code, and the status code is used to indicate to the OBD detection device whether the vehicle corresponding to the VIN is a suspected vehicle. The query result is used to display to the user the result of querying whether the vehicle corresponding to the VIN is a suspected vehicle.

[0016] In an embodiment of the present application, the OBD detection device receives the query result returned by the server. The OBD detection device can obtain whether the vehicle corresponding to the VIN is a suspected vehicle through the status code and display the query result to the user. In this way, the user can be prompted to perform the next operation.

[0017] In combination with the first aspect, in some embodiments provided in the first aspect, the server is developed based on the API and deployed under the domain name based on the user ID.

[0018] In an embodiment of the present application, the server develops a server program based on the API interface, which can match the query request of the OBD detection device, improving the development efficiency of the function of querying suspected vehicles in the server.

[0019] In a second aspect, an electronic device is provided. The electronic device includes one or more memories and one or more processors; the memory is coupled to the one or more processors, and the memory is used to store computer program code. The computer program code includes computer instructions, and the one or more processors call the computer instructions so that the electronic device executes the method according to any one of the embodiments of the first aspect or the server in the first aspect.

[0020] In a third aspect, a computer-readable storage medium is provided, on which computer instructions are stored. When the computer instructions are executed by a processor, the method according to any one of the embodiments of the first aspect or the server in the first aspect is implemented.

[0021] In a fourth aspect, a computer device is provided, including a memory, a processor, and a computer program stored on the memory. The processor executes the computer program to implement the method according to any one of the embodiments of the first aspect or the server in the first aspect.

[0022] In a fifth aspect, a communication system is provided. The communication system includes: an OBD detection device and a server. The OBD detection device is used to execute the method according to any one of the embodiments of the first aspect or the OBD detection device in the first aspect, and the server is used to execute the method according to any one of the embodiments of the first aspect or the server in the first aspect.

[0023] In the embodiment of the present application, the OBD detection device receives the VIN input by the user through the query module, obtains the user ID, the OBD detection device ID, and the domain name through the configuration management module, determines the URL and API for requesting the query instruction from the server, and queries whether the vehicle corresponding to the VIN belongs to a suspected vehicle from the corresponding server. The server verifies the legality of the user ID and the OBD detection device ID. After successful verification, it queries the suspected vehicle database according to the VIN and returns the query result. The OBD detection device receives the response returned by the server and displays the query result to the user to show whether the vehicle is in the list of suspected vehicles. Among them, the configuration management module can obtain the domain name configured by the user, thereby allowing the query module to access different data sources. This can not only improve the development efficiency and cost-effectiveness of the OBD detection device, but also enhance the flexibility and scalability of the suspected vehicle query solution, and at the same time ensure the independence and security of the data. Description of the Drawings

[0024] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0025] Figure 1 It is a flowchart of a method for an OBD detection device to query suspected vehicles provided by an embodiment of the present application;

[0026] Figure 2 It is a schematic diagram of a suspected vehicle query interface provided by an embodiment of the present application;

[0027] Figure 3 It is a schematic diagram of the query result of a suspected vehicle provided by an embodiment of the present application;

[0028] Figure 4 It is a schematic diagram of an OBD detection device setting the server domain name provided by an embodiment of the present application;

[0029] Figure 5 It is a schematic diagram of the module structure of an OBD detection device provided by an embodiment of the present application;

[0030] Figure 6 It is a flowchart of a method for a server to query suspected vehicles provided by an embodiment of the present application;

[0031] Figure 7 It is a flowchart of a method for a communication system to query suspected vehicles provided by an embodiment of the present application;

[0032] Figure 8Schematic diagram of a communication system architecture provided by an embodiment of the present application;

[0033] Figure 9 Schematic diagram of an OBD detection device unit provided by an embodiment of the present application;

[0034] Figure 10 Schematic diagram of a server unit provided by an embodiment of the present application;

[0035] Figure 11 Schematic diagram of the hardware structure of the OBD detection device provided by an embodiment of the present application;

[0036] Figure 12 Schematic diagram of the hardware structure of the server provided by an embodiment of the present application. Detailed implementation manners

[0037] The terms used in the following embodiments of the present application are only for the purpose of describing specific embodiments and are not intended to limit the present application. The technical solutions in the embodiments of the present application will be clearly and elaborately described below with reference to the drawings. Among them, in the description of the embodiments of the present application, unless otherwise specified, " / " means "or", for example, A / B may mean A or B; "and / or" in the text is only a description of the association relationship of the associated objects, indicating that there can be three relationships, for example, A and / or B may mean: A exists alone, A and B exist simultaneously, and B exists alone these three situations.

[0038] Hereinafter, the terms "first" and "second" are only used for descriptive purposes and cannot be understood as implying or suggesting relative importance or implicitly indicating the quantity of the indicated technical features. Thus, the features defined with "first" and "second" may explicitly or implicitly include one or more of such features. In the description of the embodiments of the present application, unless otherwise specified, the meaning of "a plurality" is two or more.

[0039] Referring to "embodiment" in the present application means that the specific features, structures or characteristics described in connection with the embodiment may be included in at least one embodiment of the present application. The appearance of this phrase in various positions in the specification does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will explicitly and implicitly understand that the embodiments described in the present application may be combined with other embodiments.

[0040] First, several terms related to the embodiments of the present application are introduced:

[0041] Vehicle Identification Number (VIN). The VIN, also known as the frame number or 17-digit code, is the vehicle's identification card and consists of 17 digits (letters and numbers). By reading the VIN, a lot of relevant information about the vehicle can be obtained, including the country of production, vehicle manufacturer, vehicle type, model year, production serial number, etc.

[0042] On-Board Diagnostics (OBD). Through the vehicle data and fault codes provided by OBD, vehicle problems can be quickly found and the faults can be resolved. In the embodiments of the present application, the OBD detection device can be connected to a standardized OBD interface to obtain vehicle data.

[0043] A suspected vehicle generally refers to a vehicle that has been stolen, forged, violated regulations or is involved in other legal issues. In the embodiments of the present application, a suspected vehicle can also be other vehicles set by the user and determined by the suspected vehicle database configured by the user in the server.

[0044] The above are the terms involved in the embodiments of the present application.

[0045] In the modern automotive industry, in order to improve the efficiency and safety of vehicle management, many enterprises and institutions need to frequently query and verify vehicle identity information, especially to identify whether there are suspected vehicles. Many different vehicle management offices and vehicle management institutions will establish suspected vehicle databases and often use OBD detection devices to improve vehicle management efficiency and inspection accuracy. Therefore, how to provide a convenient and fast suspected vehicle query solution has become an urgent problem to be solved.

[0046] An embodiment of the present application provides a method for querying suspected vehicles. A query module and a configuration management module are added to the OBD detection device. The query module receives the VIN input by the user. The suspected vehicle database is stored in the server configured by the user. The OBD detection device can obtain the user identity document (ID), the OBD detection device ID, and the domain name through the configuration management module, determine the uniform resource locator (URL) and the application programming interface (API) for requesting a query instruction from the server, and query the server corresponding to whether the vehicle corresponding to the VIN belongs to a suspected vehicle. The server verifies the legality of the user ID and the OBD detection device ID. After successful verification, it queries the suspected vehicle database according to the VIN and returns the query result. The OBD detection device receives the response returned by the server and displays the query result to the user, showing whether the vehicle is on the list of suspected vehicles. Among them, the configuration management module can obtain the domain name configured by the user, thereby allowing the query module to access different data sources. This can not only improve the development efficiency and cost-effectiveness of the OBD detection device, but also enhance the flexibility and scalability of the suspected vehicle query solution, and at the same time ensure the independence, security of the data and meet the personalized service needs of customers.

[0047] The method for querying suspected vehicles is described below through three embodiments. Among them, Embodiment 1 describes the method flow for the OBD detection device to query suspected vehicles, Embodiment 2 describes the method flow for the server to query suspected vehicles, and Embodiment 3 describes the method flow for querying suspected vehicles in a communication system composed of the OBD detection device and the server.

[0048] Embodiment 1

[0049] As Figure 1 shown, Figure 1 shows the method flow for the OBD detection device to query suspected vehicles.

[0050] S101. The configuration management module initializes, obtains the domain name information from the configuration file based on the user ID, and passes the obtained domain name information to the query module.

[0051] In the embodiment of the present application, an application (APP) for querying suspected vehicles is designed in the OBD detection device. The APP includes a query module and a configuration management module. Among them, the relevant functions for querying suspected vehicles are encapsulated in the query module, such as receiving the VIN input by the user. The configuration management module is used to set, store, and read the server domain name configuration under the current user ID, and is used to support the construction of the URL for the API request.

[0052] In the embodiment of the present application, a configuration file is set and stored in the OBD detection device for storing domain name information. The domain name information can be associated with the user ID and stored together in the configuration file. For example, the configuration file stores the domain name information of the current user, and the domain name information includes the current user ID, the OBD detection device ID, and the domain name. Among them, the current user can be the first user, and the ID of the current user can be the user ID logged in when the OBD detection device is started, or the user ID logged in when the OBD detection device enters the APP for querying suspected vehicles. The embodiment of the present application does not limit this.

[0053] In the embodiment of the present application, before the configuration management module is initialized, the OBD detection device starts the APP for querying suspected vehicles to obtain the user's login ID. The OBD detection device can log in to multiple different users, each user has a different user ID, corresponding to different domain name information. When the configuration management module is initialized, it is necessary to determine the domain name information set by the current user from the multiple different domain name information.

[0054] In the embodiment of the present application, after the OBD detection device starts the APP for querying suspected vehicles, it can display a suspected vehicle query interface, as Figure 2 shown.

[0055] Figure 2 shows the suspected vehicle query interface, Figure 2 which includes an item bar 10, an input prompt message 11, an input field 12, an input field prompt message 13, and a query button 14 of the suspected vehicle query interface. Among them, the item bar 10 is displayed as "Matching stolen vehicles", the input prompt message 11 is displayed as "Please enter the 17-digit Vehicle Identification Number (VIN)", and the input field prompt message 13 is displayed as "Please enter the VIN". The user can enter the VIN in the input field 12 and click the query button 14 to query whether the vehicle corresponding to the VIN is a suspected vehicle. The OBD detection device receives the above user operation and executes the subsequent steps S102 - S103.

[0056] In some embodiments, the user can directly type the VIN in the input field 12 as Figure 2 shown, or automatically recognize the VIN input in the pictures stored in the OBD detection device, or input the VIN by photographing the vehicle by the OBD detection device. The embodiment of the present application does not limit the specific manner of the user inputting the VIN.

[0057] S102. The query module receives the VIN input by the user, constructs a URL, adds the request parameters to the request message, and sends the request message to the server corresponding to the URL.

[0058] In the embodiment of the present application, the APP for querying suspected vehicles may be provided with a unified API interface and a unified URL structure template for access by the matching module. Among them, the matching module belongs to the above-mentioned query module and is used to obtain the URL indicating the server and the API for sending requests to the server. Different users can develop the server according to the unified API interface and deploy the corresponding server program under the specified domain name.

[0059] In the embodiment of the present application, the API interface supports querying whether a vehicle is a suspected vehicle through the VIN. The API interface specifies the required request method and request parameters for each API. For example, the API interface stipulates that the API uses the query request (GET request) in the Hypertext Transfer Protocol (HTTP), and the request parameters include the VIN, user ID, and OBD detection device ID. The query result uses a unified response format, such as using the programming language Java data format (Java Script Object Notation, JSON) as the unified response format.

[0060] In the embodiment of the present application, the user can input the VIN in the input field as shown in Figure 2 After clicking the query button, the OBD detection device receives the VIN input by the user through the query module. Based on the API interface and URL structure template obtained by the matching module, it constructs an API request and the corresponding URL by matching the VIN and the domain name of the current user ID, and adds the request parameters to the API request and sends it to the corresponding server.

[0061] Among them, after the OBD detection device sends the request message to the server, it waits to receive the response from the server. After the OBD detection device receives the response from the server, it executes the subsequent S103 step.

[0062] S103. The query module receives the response returned by the server, extracts the query result of the vehicle corresponding to the VIN and displays it to the user, and displays whether the vehicle is in the list of suspected vehicles.

[0063] In the embodiment of the present application, the response received by the OBD detection device from the server may include the query result and the status code. Among them, the status code is used to indicate the result of querying the VIN to the OBD detection device, and the query result is used to be displayed to the user through the OBD detection device, as shown in Figure 3 shown.

[0064] Figure 3 The query result of the suspected vehicle is shown. In Figure 2 On the suspected vehicle query interface shown, a new message pop-up window 15 is added. In the message pop-up window 15, it is prompted that the query result of the VIN is "Suspect Vehicle Database Reminds you: Please Check the Vehicle’s Documents and Uniqueness!", indicating that the vehicle corresponding to this VIN is on the suspected vehicle list and belongs to a suspected vehicle, prompting the user to conduct further inspection on this vehicle.

[0065] In the embodiment of the present application, the query module in the OBD detection device is used to process the response returned by the server, parse the data format of the response, extract the query result and the status code, and display the query result to the user to show whether the vehicle is on the suspected vehicle list.

[0066] Based on the above steps S101 - S103, the embodiment of the present application provides a method for the OBD detection device to perform a suspected vehicle query. By setting a unified API interface design, the adaptability of the APP function module for querying suspected vehicles is enhanced, facilitating the OBD detection device developer to quickly develop a service platform for querying suspected vehicles.

[0067] In the embodiment of the present application, through the configuration management module, the OBD detection device can set different domain names for different user IDs, instructing the query module to send suspected vehicle query requests to different servers. For the same user ID, the configured domain name can also be modified to indicate the location of the new server resource. The specific method for the OBD detection device to set the domain name is as Figure 4 shown.

[0068] Figure 4 Shows the OBD detection device setting the server domain name. Figure 4The item bar 10 shown in [Figure] is displayed as "Settings". Under the item bar 10, there are four sub-item bars, which are displayed in sequence as: sub-item bar 10-1 "Units", sub-item bar 10-2 "Shop information", sub-item bar 10-3 "Printer Set", and sub-item bar 10-4 "Stolen vehicle database setting". In the interface of the sub-item bar 10-4, a prompt label 16 and a corresponding input box 17 are displayed. The prompt label 16 is displayed as "Domain name". The user can enter the specific domain name to be set in the input box 17 and click the connection button 18 to test whether the input domain name can be normally connected.

[0069] In the embodiment of the present application, the OBD detection device displays different prompt messages for different connection results: If the prompt message 19 such as Figure 4 "Connection Success!" is displayed, it means that the domain name connection is successful, and at the same time, the domain name is also successfully configured in the domain name information corresponding to the ID of the logged-in user; If the connection fails, a connection failure prompt message can be displayed in the OBD detection device, such as "Connection Default!", and this connection failure prompt message is used to instruct the user to change the input domain name and click the connection button 18 again for testing until the input domain name can be successfully connected.

[0070] Based on the above Figure 4 shown domain name configuration scheme, the dynamic domain name configuration enhances the scalability of the APP function module for querying suspected vehicles, can cope with the needs of different customers and market changes, and improves the competitiveness of the OBD detection device and the APP.

[0071] Based on the foregoing Figures 1 - 4 shown query process of the OBD detection device, Figure 5 the module structure of the OBD detection device is shown.

[0072] As Figure 5As shown in the figure, the OBD detection device includes a configuration management module, a query module, and a storage module. Among them, the configuration management module is used to set, store, and read the domain name configuration under the user ID, and this domain name is used to construct the URL of the API request server. The query module encapsulates functions related to querying suspected vehicles, allowing users to input the VIN and displaying the query results. The query module includes a matching module, which is used to access the unified API interface and URL structure template. The storage module is used to store configuration files, and the domain name information of the current user is stored in the configuration file, including the current user ID, the OBD detection device ID, and the corresponding domain name.

[0073] In the embodiment of the present application, the configuration management module obtains the domain name information from the configuration file in the storage module and sends this domain name information to the query module. The query module obtains the API interface and URL structure template through the matching module. After receiving the VIN input by the user, it constructs the URL of the server corresponding to the domain name in the API request, adds the request parameters including the VIN, user ID, and OBD detection device ID to the API request, and sends it to the corresponding server.

[0074] In the embodiment of the present application, the query module can also receive the response returned by the server, extract the query result and status code of the vehicle corresponding to the VIN from this response, and display the query result to the user to show whether the suspected vehicle is in the list of suspected vehicles. Among them, the response returned by the server can be unified in JSON format, and the query module parses the JSON data to obtain the query result and status code after receiving this response.

[0075] In some embodiments, the matching module can be an independent module, which is used to send the obtained API structure and URL template to the query module.

[0076] In other embodiments, the matching module and the query module can belong to the same module, and the query module executes the functions of the matching module, including sending the obtained API structure and URL template. The embodiment of the present application does not limit the inclusion relationship of each module in the OBD detection device.

[0077] In some embodiments, the OBD detection device can also include more modules, such as a display module, which is used to display the query result returned by the server to the user; a communication module, which is used to receive the query information and URL of the query module, send this query information to the server corresponding to the URL, and receive the response returned by the server. The embodiment of the present application does not limit the specific modules of the OBD detection device.

[0078] Embodiment 2

[0079] As Figure 6 shown, Figure 6 shows the method flow of the server querying suspected vehicles.

[0080] S201. The server receives a query request from the OBD detection device and obtains the user ID and the OBD detection device ID.

[0081] In the embodiment of the present application, the server deploys a suspected vehicle database, which can be set by the user himself to construct a database of suspected vehicles that need attention.

[0082] In the embodiment of the present application, the server develops a program based on the API interface specified in the OBD detection device and deploys the server program under the domain name of the OBD detection device. The server can receive the API request sent by the OBD detection device through the deployed program. For example, if the API request is a GET request in HTTP, the server can receive the user ID logged in the OBD detection device and the ID of the OBD detection device. Before the server executes the API request, in order to prevent malicious users from performing malicious operations on the database through the API request, it is necessary to verify the legality of the user ID and the OBD detection device ID, and perform the following S202 step.

[0083] In some embodiments, the server also deploys a database of legal user IDs and a database of legal OBD detection device IDs to provide a list for verifying the legality of the user ID and the OBD detection device ID in step S202.

[0084] S202. The server verifies the legality of the user ID and the OBD detection device ID.

[0085] In some embodiments, the server can preset a list of legal user IDs and legal OBD detection device IDs, and by querying the received user ID with the legal user IDs in the list and the received OBD detection device ID with the legal OBD detection device IDs in the list, determine whether the received user ID and OBD detection device ID are legal IDs.

[0086] In the embodiment of the present application, the server has different execution methods for different verification results: if both the user ID and the OBD detection device ID belong to the legal IDs in the list, it is considered that the received IDs are legal, and the operation of querying suspected vehicles in the API request is performed, as shown in step S203; if the user ID or the OBD detection device ID does not belong to the legal IDs in the list, it is considered that the received IDs are illegal, and the operation in the API request will not be performed. Among them, the legal user ID can be obtained from the database of legal user IDs, and the list of legal OBD detection device IDs can be obtained from the database of legal OBD detection device IDs.

[0087] In some embodiments, the server may verify the legitimacy of the user ID and the OBD detection device ID through a check code, or may also verify the legitimacy of the user ID and the OBD detection device ID through a verification algorithm. The embodiments of the present application do not limit this.

[0088] S203. After the server confirms the legitimacy of the user ID and the OBD detection device ID, it queries the suspected vehicle database based on the VIN.

[0089] In the embodiments of the present application, the server parses the received request parameters to obtain the VIN input by the user in the OBD detection device. In the suspected vehicle database stored in the server, different suspected vehicles correspond to different VINs. The server uses the VIN as the query keyword to retrieve whether the VIN input by the user is the same as the VIN stored in the database in the suspected vehicle database. If it exists, it means that the vehicle corresponding to the VIN is a suspected vehicle. The server generates a query result indicating that the detected vehicle is a suspected vehicle and obtains the status code corresponding to the query result. If it does not exist, it means that the vehicle corresponding to the VIN does not belong to the suspected vehicle. The server generates a query result indicating that the detected vehicle is a normal vehicle and obtains the feature code corresponding to the query result.

[0090] In the embodiments of the present application, after the server obtains the query result and the feature code, it returns the query result and the feature code to the OBD detection device and executes the subsequent step S204.

[0091] S204. The server returns the query result to the OBD detection device.

[0092] In the embodiments of the present application, the server returns the query result to the OBD detection device, and the query result is used to display to the user whether the vehicle corresponding to the VIN belongs to the suspected vehicle. Among them, the server can provide different prompt messages for different query results. If the query result of the server shows that the vehicle corresponding to the VIN belongs to the suspected vehicle, the server can add a prompt message of the suspected vehicle to the query result to prompt the user to further detect the vehicle. If the query result of the server shows that the vehicle corresponding to the VIN is a normal vehicle, the server can add a prompt message of the normal vehicle to the query result to prompt the user that the vehicle is normal. The embodiments of the present application do not limit this.

[0093] In the embodiments of the present application, the server also returns the feature code corresponding to the query result to the OBD detection device. The feature code is used to represent different query results and is used to indicate the obtained query result to the OBD detection device. Among them, the server can configure the query result and the feature code in a unified JSON format.

[0094] Based on the above steps S201 - S204, the embodiments of the present application provide the same interface and data format for developing server programs, which can improve the development speed of the server side in the query suspected vehicle solution. At the same time, the suspected vehicle database stored in the server can be set by the user himself to meet the needs of diverse customer groups; the user information is verified for the received API requests, and different users can set different databases and servers, thus ensuring the independence and security of data during the VIN query process.

[0095] Embodiment 3

[0096] As Figure 7 shown Figure 7 shows the method flow of querying suspected vehicles in a communication system. Among them, the communication system is composed of an OBD detection device and a server.

[0097] S301. The OBD detection device starts, the user logs in, and domain name information is obtained.

[0098] In the embodiments of the present application, an APP for querying suspected vehicles is designed in the OBD detection device, and at the same time, a configuration file is set and stored in the OBD detection device, and the domain name information is stored in the configuration file. The domain name information can be associated with the user ID and stored in the configuration file together.

[0099] In the embodiments of the present application, the OBD detection device starts the APP for querying suspected vehicles to obtain the user's login ID. The OBD detection device can log in to multiple different users, each user has a different user ID, corresponding to different domain name information, and the OBD detection device needs to determine the domain name information set by the current user from the multiple different domain name information.

[0100] In the embodiments of the present application, the OBD detection device can obtain the logged-in user ID when starting the APP for querying suspected vehicles, or the OBD detection device can also obtain the logged-in user ID when starting the OBD detection device, and obtain the domain name information based on the user ID. For the specific description of the OBD detection device obtaining the domain name information, reference can be made to the aforementioned step S101, which will not be elaborated here.

[0101] In the embodiments of the present application, before receiving the API request sent by the OBD detection device, the server pre-stores a suspected vehicle database, develops and runs a server program based on a specified API interface for receiving the API request sent by the OBD server.

[0102] In some embodiments, after obtaining the domain name information, the OBD detection device communicates with the server corresponding to the domain name based on the domain name information to test whether it can communicate with the server normally, and establishes a communication system between the OBD detection device and the server corresponding to the domain name.

[0103] S302. The OBD detection device receives the VIN input by the user, constructs a URL, and sends a request message to the server corresponding to the URL.

[0104] In the embodiment of the present application, the APP for querying suspected vehicles in the OBD detection device has a unified API interface and URL template. An API request and a URL connection are established based on the obtained VIN, and an API query request is sent to the server resource corresponding to the URL connection. The specific process for the OBD detection device to execute the sending of the API query request can refer to the aforementioned step S102 and will not be elaborated here.

[0105] In the embodiment of the present application, the API interface supports querying whether a vehicle is a suspected vehicle through the VIN. The user can enter the VIN in the input field as shown in Figure 2 The specific description of the user entering the VIN in the input field can refer to the specific description of the aforementioned Figure 2 and will not be elaborated here.

[0106] S303. The server receives the request message and verifies the legality of the user ID and the OBD detection device ID.

[0107] In the embodiment of the present application, the server deploys a suspected vehicle database, which can be set by the user himself to construct a database of suspected vehicles that need attention. The server develops a program based on the API interface specified in the OBD detection device and deploys the server program under the domain name of the OBD detection device.

[0108] In some embodiments, the server can preset a list of legal user IDs and legal OBD detection device IDs. By querying the received user ID with the legal user IDs in the list and querying the received OBD detection device ID with the legal OBD detection device IDs in the list, it is determined whether the received user ID and OBD detection device ID are legal IDs.

[0109] In the embodiment of the present application, the server receives the API request message and verifies the legality of the user ID and the OBD detection device ID in the request message. Specifically, it can refer to the aforementioned steps S201 - S202 and will not be elaborated here.

[0110] In some embodiments, the server can also communicate with the OBD detection device again to obtain other information of the OBD detection device to verify whether the OBD detection device and the user meet the legality requirements. The embodiment of the present application does not limit this.

[0111] S304. After the server verifies and confirms legality, it queries the suspected vehicle database according to the VIN and returns the query result to the OBD detection device.

[0112] In an embodiment of the present application, the server parses the received request parameters to obtain the VIN input by the user in the OBD detection device. In the suspected vehicle database stored in the server, different suspected vehicles correspond to different VINs. The server uses the VIN as the query keyword to retrieve in the suspected vehicle database whether the VIN input by the user is the same as the VINs stored in the database.

[0113] In an embodiment of the present application, the server returns a query result to the OBD detection device, and the query result is used to display to the user whether the vehicle corresponding to the VIN is a suspected vehicle.

[0114] In an embodiment of the present application, the server queries the suspected vehicle data in the suspected vehicle database based on the VIN and returns the query result to the OBD detection device. For details, reference can be made to the foregoing steps S203 - S204, which will not be elaborated here.

[0115] S305. The OBD detection device receives the query result returned by the server and displays whether the vehicle corresponding to the VIN is a suspected vehicle.

[0116] In an embodiment of the present application, the response received by the OBD detection device from the server may include a query result and a status code. Among them, the status code is used to indicate to the OBD detection device the result of querying the VIN, and the query result is used to be displayed to the user through the OBD detection device. The query result of the suspected vehicle can refer to the foregoing description of Figure 3 and will not be elaborated here.

[0117] In an embodiment of the present application, the OBD detection device receives the query result returned by the server and displays to the user whether the vehicle corresponding to the VIN is a suspected vehicle. For details, reference can be made to the foregoing step S103, which will not be elaborated here.

[0118] In an embodiment of the present application, through the configuration management module, the OBD detection device can set different domain names for different user IDs, instruct the query module to send suspected vehicle query requests to different servers, and can also modify the configured domain name for the same user ID to indicate the new server resource location. The setting of the server domain name for the OBD detection device can refer to the foregoing description of Figure 4 and will not be elaborated here.

[0119] Based on the above steps S301 - S305, a communication system composed of an OBD detection device and a server constructs a flexible, efficient, and secure query service platform for suspected vehicles based on the unified API interface design and highly flexible domain name configuration mechanism, realizing the function of sharing the query of suspected vehicles by different customers. In this way, not only the adaptability and scalability of the relevant functional modules for querying suspected vehicles in the OBD detection device are enhanced, but also the OBD detection device can meet the needs of different customers. Different servers can store different databases, and this communication system can ensure the independence and security of data, maintaining sufficient competitiveness and vitality.

[0120] Figure 8 The communication system architecture is shown. This communication system is an exemplary architecture diagram of the communication system applicable to the embodiments of this application. The communication system includes an OBD detection device 100 and a server 200, and the OBD detection device 100 and the server 200 can communicate with each other.

[0121] The OBD detection device 100 can be distributed throughout the communication system and can be stationary or mobile. In some embodiments of this application, the OBD detection device 100 can include user equipment (UE), mobile devices, mobile stations, mobile units, machine - to - machine (M2M) terminals, wireless units, terminal devices, remote units, terminal agents, mobile clients, etc.

[0122] The OBD detection device 100 can include a storage module, in which a configuration file is stored. The configuration file includes the current user ID, the ID of the OBD detection device 100, and the domain name of the server 200. In the embodiments of this application, the above information can be referred to as domain name information.

[0123] The OBD detection device 100 can store multiple pieces of domain name information. Different users can set different configuration files in the OBD detection device 100 to indicate different servers 200 for storing the suspected vehicle database. When a user logs in to the OBD detection device 100, the OBD detection device 100 can determine the domain name information of the current user based on the ID of the logged - in user and construct a URL for communicating with the server 200 based on this domain name information.

[0124] The OBD detection device 100 can obtain the VIN input by the user and generate an API request for accessing the server 200. The API request includes request parameters such as the user ID, the OBD detection device ID, and the VIN.

[0125] The OBD detection device 100 sends the obtained user ID, the ID of the OBD detection device 100, and the input VIN to the server 200, and the server 200 receives and verifies whether the user ID and the ID of the OBD detection device 100 are legal IDs.

[0126] The server 200 can develop a corresponding receiving end based on the API interface specified by the OBD detection device 100, and extract the request parameters therein when receiving the API request of the OBD detection device 100, including the user ID, the OBD detection device ID, and the VIN. The server 200 is deployed in the domain name specified by the user, and this domain name is the same as the domain name corresponding to the same user ID in the OBD detection device 100. The OBD detection device 100 can communicate with the server 200 through this domain name. Different servers 200 have different domain names, which are set by different users. The OBD detection device 100 only needs to configure the domain names corresponding to different user IDs, and there is no need to separately set a server differentiation module for each user ID.

[0127] The server 200 can be provided with a data management system, and this database management system includes a database for storing suspected vehicles. In some embodiments, the data management system of the server can also store a database of legal user IDs and legal OBD detection device IDs. The server 200 can set, store, and modify the databases in the data management system, and can add or delete records in the original database. Different databases can be set in different servers 200 to meet the needs of different users for setting the server 200.

[0128] The server 200 can compare the received user ID with the list of legal user IDs in the database, and compare the OBD detection device ID with the list of legal OBD detection device IDs in the database, so as to determine whether the received API request is legal. Similarly, the server 200 can also determine whether the vehicle corresponding to the VIN is a suspected vehicle by comparing the VIN with the list of suspected vehicles.

[0129] After receiving the API request sent by the OBD detection device 100, the server 200 verifies whether the user ID and the OBD detection device ID are legal through the data management system. If the user ID is on the list of legal user IDs and the OBD detection device ID is on the list of legal IBD detection device IDs, the server 200 verifies that the user ID and the OBD detection device ID are legal and executes the received API request. If the user ID is not on the list of legal user IDs or the OBD detection device ID is not on the list of legal IBD detection device IDs, the server 200 verifies that the user ID and the OBD detection device ID are illegal and does not execute the received API request. Among them, the API request sent by the OBD detection device 100 includes querying whether the vehicle corresponding to the VIN is a legal vehicle.

[0130] After determining that the user ID and the OBD detection device ID are legal, the server 200 compares the VIN with the list of VINs of suspected vehicle data in the suspected vehicle database to determine whether the vehicle corresponding to the VIN is a suspected vehicle. If the VIN received by the server 200 is on the list of VINs of suspected vehicle data, the server 200 determines that the vehicle corresponding to the VIN belongs to a suspected vehicle. If the VIN received by the server 200 is not on the list of VINs of suspected vehicle data, the server 200 determines that the vehicle corresponding to the VIN does not belong to a suspected vehicle.

[0131] The server 200 can return the verification result of the VIN comparison with the suspected vehicle database to the OBD detection device 100. Among them, different verification results can correspond to different status codes. For example, if the verification result of the server 200 is that the vehicle corresponding to the VIN belongs to a suspected vehicle, the status code can be the first status code, which is used to indicate to the OBD detection device 100 that the vehicle corresponding to the current VIN belongs to a suspected vehicle. If the verification result of the server 200 is that the vehicle corresponding to the VIN does not belong to a suspected vehicle, the status code can be the second status code, which is used to indicate to the OBD detection device 100 that the vehicle corresponding to the current VIN does not belong to a suspected vehicle. The verification result is the information used to prompt the user, and the verification code is the verification result returned to the OBD detection device 100.

[0132] In some embodiments, the server 200 encapsulates the verification result and the verification code in a unified data format and sends them to the OBD detection device 100, such as the JSON data format, which is not limited in this embodiment of the present application.

[0133] Upon receiving the response returned by the server 200, the OBD detection device 100 parses the data format of the response and extracts the inspection result therein for display to the user. Among them, the OBD detection device 100 can parse the JSON data format returned by the server 200, extract the encapsulated inspection result and status code, and display the inspection result in the OBD inspection device in the form of a message pop-up window, as described above Figure 3 as shown, which will not be elaborated here

[0134] During the above introduction process, the communication method provided by the embodiment of the present application is applied to Figure 8 the communication system shown. In addition, this method can be executed by two communication devices, which are, for example, the first communication device and the second communication device. Among them, the first communication device can be the OBD detection device 100, or a communication device that can support the OBD detection device 100 to implement the functions required by this method. Of course, it can also be other communication devices, such as a chip system. For the second communication device, it can be the server 200 or a communication device that can support the server 200 to implement the functions required by this method. Of course, it can also be other communication devices, such as a chip system

[0135] If the embodiment of the present application is applied to Figure 8 the communication system shown, then the OBD detection device described above Figures 1 - 5 can be the OBD detection device 100 in the communication system shown Figure 8 above, and the server device described above Figure 6 can be the server 200 in the communication system shown Figure 8 below. It should be noted that the embodiment of the present application only takes one OBD detection device 100 and one server 200 as an example for execution, and does not limit the number of the OBD detection device 100 and the server 200. For one OBD detection device, multiple different user IDs can be logged in, and each user can correspond to a different server 200. That is, multiple different servers 200 can be included in this communication system, and different servers 200 are set separately by different users, avoiding data leakage between different users

[0136] Based on Figure 8 the communication system shown Figure 9 the OBD detection device unit provided by the embodiment of the present application is shown, including the following units

[0137] The configuration management unit 901 is used to set, store, and read the server domain name configuration under the current user ID in the OBD detection device, and send the domain name information to the suspected vehicle query unit 903

[0138] The first storage unit 902 is used to store configuration files and other cached data during the operation of the OBD detection device, such as the unified API interface and URL template set in the OBD detection device.

[0139] Among them, the configuration file is obtained by the configuration management unit 901, and the API interface and URL template are read by the suspected vehicle query unit 903.

[0140] The suspected vehicle query unit 903 is used to encapsulate all functions related to the query of suspected vehicles, receive the VIN input by the user, generate an API request and URL for querying the server. It is also used to receive the response returned by the server, extract the query results therein, and display the query results to the user.

[0141] In some embodiments, the API request generated by the suspected vehicle query unit 903 is a GET request in HTTP, and the server response received is in JSON format, including the query results and status codes.

[0142] The data processing and display unit 904 is used to receive the response returned by the server received by the suspected vehicle query unit 903, process the data format of the response, and obtain the specific content therein. It is also used to display the query results obtained from the response in the OBD detection device.

[0143] In some embodiments, the data processing and display unit 904 may belong to the suspected vehicle query unit 903, and the suspected vehicle query unit 903 may include other modules and units for implementing the VIN query function. In the embodiments of the present application, the specific content of the suspected vehicle query unit 903 is not limited.

[0144] The first communication unit 905 is used to obtain the URL generated in the suspected vehicle query unit 903, determine the server communicating with the OBD detection device. It is also used to send the API request generated in the suspected vehicle query unit 903 to the server, receive the response returned by the server, and transmit the obtained response to the suspected vehicle query unit 903.

[0145] Based on the OBD detection device unit as Figure 9 shown, corresponding to the method for querying suspected vehicles by the Figure 1 shown OBD detection device, the specific corresponding relationship is as follows:

[0146] The configuration management unit 901 is used to execute the initialization of the configuration management module in step S101, obtain the domain name information from the configuration file based on the user ID, and transfer the obtained domain name information to the suspected vehicle query module.

[0147] The first storage unit 902 is used to execute the method of setting and storing a configuration file in the OBD detection device in step S101, and is also used to execute the method of setting a unified API interface and a unified URL structure template in step S102.

[0148] The suspected vehicle query unit 903 is used to execute the method of receiving domain name information sent by the configuration management module in step S101; in step S102, the query module receives the VIN input by the user, constructs a URL, adds the request parameters to the request information, and sends an API request; in S103, the query module receives the response returned by the server, extracts the query result of the vehicle corresponding to the VIN, and obtains whether the vehicle is in the list of suspected vehicles.

[0149] The data processing and display unit 904 is used to execute the method of extracting the query result of the vehicle corresponding to the VIN in S103 and displaying it to the user, and displaying whether the vehicle is in the list of suspected vehicles.

[0150] The first communication unit 905 is used to execute the method of sending the API request information to the server corresponding to the URL in step S102, and is also used to execute the method of receiving the response returned by the server in step S103.

[0151] The specific implementation manners of the above corresponding steps in the embodiments of the present application will not be elaborated herein.

[0152] It can be understood that the functional division of the units shown in the embodiments of the present application is only illustrative and does not constitute a limitation on the functions of the OBD detection device. In other embodiments of the present application, the OBD detection device may also adopt different units or a combination of multiple units from those in the above embodiments to implement the functions of the OBD detection device.

[0153] Such as Figure 10 The server unit provided by the embodiments of the present application is shown, including the following units:

[0154] The verification unit 1001 is used for the server to verify the user ID and the OBD detection device ID sent by the OBD detection device, and determine whether the user ID and the OBD detection device ID are legal IDs. If the user ID and the OBD detection device ID are legal IDs, the server executes the verification request sent by the OBD detection device.

[0155] Among them, the verification request sent by the OBD detection device includes querying whether there is a matching record in the suspected vehicle database in the server based on the VIN input by the user.

[0156] The second storage unit 1002 is used to store databases, including a legal user ID database and a legal OBD detection device ID database for comparing the user ID and the OBD detection device ID in the verification unit 1001, and also includes a suspected vehicle database set by the user himself. The suspected vehicle database includes suspected vehicles and VIN records corresponding to the suspected vehicles.

[0157] The database query unit 1003 is used to implement the verification operation of the user ID and the OBD detection device ID in the verification unit 1001, and is also used to implement the query operation of the server for the received VIN in the suspected vehicle database.

[0158] The second communication unit 1004 is used to receive the API request sent by the OBD detection device, including the request parameters in the API request. And after the server queries the VIN in the suspected vehicle database, the query result and the verification code are sent back to the OBD detection device as the response returned by the OBD detection device sending the API request.

[0159] Based on the server unit as Figure 10 shown, corresponding to the method of the server querying suspected vehicles as Figure 6 shown, the specific corresponding relationship is as follows:

[0160] The verification unit 1001 is used to execute the method of the server verifying the legality of the user ID and the OBD detection device ID as shown in step S202.

[0161] The second storage unit 1002 is used to execute the server deployment of the suspected vehicle database, the legal user ID database, and the legal OBD detection device ID database as shown in step S201.

[0162] The database query unit 1003 is used to execute the method of obtaining the list of legal user IDs and the list of legal OBD detection device IDs from the corresponding databases in verifying the legality of the user ID and the OBD detection device ID as shown in step S202, and is also used to execute the method of querying the suspected vehicle database based on the VIN in step S203.

[0163] The second communication unit 1004 is used to execute the method of the server returning the query result to the OBD detection device as shown in step S204.

[0164] The specific implementation manners of the above corresponding steps in the embodiments of the present application will not be elaborated herein.

[0165] It should be understood that the functional division among the units illustrated in the embodiments of the present application is only illustrative and does not constitute a limitation on the functions of the server. In other embodiments of the present application, the server may also adopt different units from those in the above embodiments, or a combination of multiple units to implement the functions of the server.

[0166] As Figure 11 shown in the hardware structure of the OBD detection device provided by the embodiments of the present application. The OBD detection device 100 includes: a processor 101, a memory 102, a communication module 104, and a computer program 103 stored in the memory 102 and executable on the processor 101. Among them, when the processor 101 executes the computer program 103, the steps in the embodiments of the above vehicle ECU flashing method are implemented.

[0167] Exemplarily, the above computer program 103 may be divided into one or more units / modules, and the above one or more units / modules are stored in the memory 102 and executed by the processor 101 to complete the present application.

[0168] The above one or more units / modules may be a series of computer program instruction segments capable of performing specific functions, and the instruction segments are used to describe the execution process of the above computer program 103 in the OBD detection device 100. For example, the above computer program 103 may be used to execute obtaining domain name information, obtaining user input VIN, constructing an API request and the corresponding ULR, sending the API request, receiving the response of the service to the API request, displaying the query result of the VIN, etc. The specific functions or mechanisms have been described in the above embodiments and will not be elaborated here.

[0169] Those skilled in the art can understand that Figure 11 merely examples of the OBD detection device 100 do not constitute a limitation on the OBD detection device 100, and may include more or fewer components than shown in the figure, or combine certain components, or different components. For example, the above OBD detection device 100 may further include input / output devices, network access devices, buses, etc.

[0170] The above-mentioned processor 101 may be a Central Processing Unit (CPU), or may also be other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc.

[0171] In some embodiments, the processor 101 may include one or more interfaces. The interfaces may include an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general-purpose input / output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0172] It can be understood that the interface connection relationships between the modules illustrated in the embodiments of the present application are only illustrative and do not constitute a structural limitation on the OBD detection device 100. In other embodiments of the present application, the OBD detection device 100 may also adopt different interface connection methods in the above embodiments, or a combination of multiple interface connection methods.

[0173] The above-mentioned memory 102 may be an internal storage unit of the OBD detection device 100, such as the hard disk or memory of the OBD detection device 100. The above-mentioned memory 102 may also include both the internal storage unit of the OBD detection device 100 and an external storage device.

[0174] The above-mentioned memory 102 is used to store the above-mentioned computer program and other programs and data required by the above-mentioned OBD detection device 100. The above-mentioned memory 102 can also be used to temporarily store the data that has been output or will be output. For example, the above-mentioned memory 102 can include a configuration file for storing the domain name information of the user, including information such as user ID, OBD detection device ID for verification, and domain name.

[0175] The communication module 104 can provide wireless communication solutions applied to the OBD detection device 100, including wireless local area networks (WLAN) (such as wireless fidelity (Wi-Fi) networks), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near field communication (NFC), infrared technology (IR), etc.

[0176] The communication module 104 can be one or more device communication modules integrating at least one communication processing module. The communication module 104 receives electromagnetic waves via the antenna, demodulates and filters the electromagnetic wave signals, and sends the processed signals to the processor 101.

[0177] The communication module 104 can also receive the signal to be sent from the processor 101, frequency-modulate and amplify it, and convert it into electromagnetic waves through the antenna for radiation. For example, the OBD detection device sends an API request to the server through the communication module 104 and receives the response returned by the server to obtain the query result of the vehicle corresponding to the VIN.

[0178] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the above-mentioned division of each functional unit and module is used as an example. In actual applications, the above-mentioned functions can be allocated to different functional units and modules according to needs, that is, the internal structure of the above-mentioned device is divided into different functional units or modules to complete all or part of the functions described above.

[0179] Each functional unit and module in the embodiment can be integrated into a processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of a software functional unit.

[0180] In the embodiments of the present application, the specific names of the functional units and modules are only for the convenience of distinguishing from each other, and are not used to limit the protection scope of the present application.

[0181] Reference Figure 12 , Figure 12 FIG. 7 is a hardware structure of a server provided by an embodiment of the present application. The server 200 includes a processor 201, a memory 202, and a wireless communication module 204. The processor 201, the memory 202, and the wireless communication module 204 can be interconnected through a communication bus 203. The communication bus 203 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc.

[0182] The communication bus 203 can be divided into an address bus, a data bus, a control bus, etc. For the sake of convenience of representation, Figure 12 only a thick line is used in FIG. 7 to represent it, but it does not mean that there is only one bus or one type of bus. The memory 202 is used to store a computer program, and the computer program includes program instructions. The processor 201 is configured to call the program instructions. The above program includes the parts or all of the steps executed by the server shown in FIGS. 7 and 8. Figure 6 and Figure 7 FIG. 8.

[0183] The memory 202 can be a Read Only Memory (ROM) or other types of static storage devices that can store static information and instructions, a Random Access Memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an Electrically Erasable Programmable Read Only Memory (EEPROM), a Compact Disc Read Only Memory (CD ROM) or other optical disc storage, optical disc storage (including compact discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store the desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto.

[0184] The memory can exist independently and be connected to the processor via a bus. The memory can also be integrated with the processor. Exemplarily, the memory 202 can store databases set by users, including a database of legitimate user IDs, a database of legitimate OBD detection devices, a database of suspected vehicles, etc.

[0185] The server 200 can also include a communication interface, which includes a USB interface and can be used to connect to an external storage medium. The wireless communication module 204 can include at least one filter, switch, power amplifier, low noise amplifier (LNA), etc.

[0186] In addition, the server 200 can also include general components such as an antenna, which will not be elaborated here for the time being.

[0187] It should be understood that each step in the above method embodiments provided in the present application can be completed by the integrated logic circuit of the hardware in the processor or the instructions in the form of software. The method steps disclosed in combination with the embodiments of the present application can be directly embodied as being executed and completed by the hardware processor, or executed and completed by the combination of the hardware and software modules in the processor.

[0188] The present application also provides a computer program product, which includes: a computer program (which can also be referred to as code or instructions). When the computer program is run, it causes the computer to execute the method executed by the vehicle inspection device in the above embodiments.

[0189] The present application also provides a computer-readable storage medium, which stores a computer program (which can also be referred to as code or instructions). When the computer program is run, it causes the computer to execute the method executed by the electronic device in any of the foregoing embodiments.

[0190] The various embodiments of the present application can be combined arbitrarily to achieve different technical effects.

[0191] In the foregoing embodiments, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product.

[0192] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on the computer, the processes or functions described in the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.

[0193] The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (such as coaxial cable, optical fiber, digital subscriber line) or wireless (such as infrared, wireless, microwave, etc.) means.

[0194] The computer-readable storage medium can be any available medium accessible by a computer or a data storage device such as a server or a data center that includes one or more integrated available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid state disk).

[0195] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the foregoing embodiments can be completed by relevant hardware instructed by a computer program. The program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the foregoing method embodiments. The foregoing storage medium includes various media that can store program codes, such as ROM or random access memory (RAM), magnetic disks, or optical discs.

[0196] In summary, the above description is only an embodiment of the technical solution of the present invention and is not intended to limit the protection scope of the present invention. Any modifications, equivalent replacements, improvements, etc. made based on the disclosure of the present invention shall be included within the protection scope of the present invention.

Claims

1. A method for querying a suspected vehicle, characterized in that: Applied to an on-board self-diagnosis system OBD detection device, the OBD detection device includes a configuration management module and a query module, and the method includes: The OBD detection device logs in a first user, and based on the identity identification number ID of the first user, obtains domain name information through the configuration management module, wherein the domain name information includes a user ID, an OBD detection device ID and a domain name; The OBD detection device receives a vehicle identification code VIN, constructs a uniform resource locator URL through the query module, and sends a query request to a server indicated by the URL, wherein the query request includes the user ID, the OBD detection device and the VIN; The OBD detection device receives and displays the query result returned by the server, where the query result is used to indicate whether the vehicle corresponding to the VIN is a suspected vehicle.

2. The method according to claim 1, characterized in that: After the OBD detection device logs in the first user, the method further includes: The configuration management module reads a configuration file, and the configuration file is used to store the domain name information.

3. The method according to claim 1, characterized in that: The server stores a suspect vehicle database. After sending a query request to the server indicated by the URL, the method further includes: The server receives the query request and verifies the legitimacy of the request based on the user ID and the OBD detection device ID; After determining that the query request is legitimate, the server queries the vehicle corresponding to the VIN based on the suspected vehicle database and returns the query result to the OBD detection device.

4. The method according to claim 1, characterized in that: The OBD detection device stores an application program interface API and a URL template. The API adopts a GET request method and needs to include request parameters of the user ID, the OBD detection device ID and the VIN.

5. The method according to claim 4, characterized in that: The query module includes a matching module, the matching module is used to obtain the API and the URL template, the uniform resource locator URL is constructed by the query module, and a query request is sent to the server indicated by the URL. The method includes: The matching module obtains the VIN and the domain name information, constructs the URL, and adds the user ID, the OBD detection device ID, and the VIN to the API; The OBD detection device sends a query request of the API to the server indicated by the URL.

6. The method according to claim 5, characterized in that: The OBD detection device receives and displays the query result returned by the server, and the method includes: The matching module receives the response information returned by the server, extracts and displays the query result in the response information, the response information includes the query result and a status code, the status code is used to indicate to the OBD detection device whether the vehicle corresponding to the VIN is a suspected vehicle, and the query result is used to display to the user the result of querying whether the vehicle corresponding to the VIN is a suspected vehicle.

7. The method according to any one of claims 4 to 6, characterized in that: The server is developed based on the API and deployed under the domain name based on the user ID.

8. An electronic device, comprising one or more memories and one or more processors; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions so that the electronic device executes any one of the methods performed by the OBD detection device as described in claims 1 to 7.

9. A computer-readable storage medium having computer instructions stored thereon, characterized in that: When the computer instructions are executed by a processor, any one of the methods described in claims 1 to 7 is implemented by the OBD detection device.

10. A computer device comprising a memory, a processor and a computer program stored in the memory, characterized in that: The processor executes the computer program to implement any one of the methods performed by the OBD detection device in claims 1 to 7.

Images