Vehicle identity binding method based on internet of vehicles device, electronic device, and storage medium

Abstract

This application provides a vehicle identity binding method, electronic device, and storage medium based on a vehicle-to-everything (V2X) device. The method includes: obtaining a user identification code of a communication card on a vehicle via an in-vehicle communication terminal, and sending a login request containing the vehicle identification code and the user identification code to a connected platform, wherein the connected platform verifies whether the vehicle identification code belongs to a registered vehicle; receiving a verification result from the connected platform based on the login request, and if the verification result indicates that the vehicle identification code has passed the verification by the connected platform, determining whether to establish a binding relationship between the user identification code and the current vehicle identification code based on the historical binding records of the vehicle identification code on the connected platform. This method aims to significantly improve the efficiency and accuracy of communication card data management on the V2X platform, providing a reliable data foundation for subsequent business functions.

Description

Technical Field

[0001] This application relates to the field of vehicle networking technology, and in particular to a vehicle identity binding method, electronic device, and storage medium based on vehicle networking equipment. Background Technology

[0002] With the widespread application of unmanned vehicles (such as unmanned logistics vehicles, unmanned cleaning vehicles, and unmanned patrol vehicles) in smart cities, industrial park logistics, and public safety scenarios, in-vehicle communication terminals (such as TBOX) have become key components for unmanned vehicles to access cloud dispatch platforms and realize core functions such as remote monitoring, firmware upgrades (OTA), and operational data feedback. To ensure service security and accurate data attribution, the connected vehicle platform needs to authenticate each vehicle. Among these, the binding relationship between the Vehicle Identification Number (VIN) and the Interconnect Card User Identification Number (IMSI) is the foundation for realizing device identity management.

[0003] In existing technologies, the binding of vehicles and communication cards is typically completed when a vehicle rolls off the production line or is first activated, and is stored statically in the platform database. For example, when a TBOX is first deployed, the platform records the correspondence between the VIN and the current IMSI, and subsequent logins rely on this fixed mapping for authentication. However, in actual operation and maintenance, due to reasons such as TBOX replacement during maintenance, reusing communication cards in test vehicles, or after-sales upgrades, the same communication card is often installed in different vehicles, or a new communication card is replaced in the same vehicle. Because existing solutions lack a dynamic verification mechanism for the binding relationship, the platform still uses the old mapping, causing problems such as vehicle identity confusion, mis-sent remote commands, incorrect billing attribution, and even service security risks.

[0004] Therefore, there is an urgent need for a technical solution that can automatically verify and dynamically maintain the binding relationship between the vehicle and the communication card each time the vehicle logs in, in order to solve the problem of identity binding failure caused by the replacement or reuse of the communication card, and ensure the accuracy, security and manageability of the vehicle network service. Summary of the Invention

[0005] This application provides a vehicle identity binding method, electronic device, and storage medium based on vehicle networking equipment, in order to significantly improve the efficiency and accuracy of communication card data management in the vehicle networking platform, and provide a reliable data foundation for subsequent business functions.

[0006] In a first aspect, embodiments of this application provide a vehicle identity binding method based on a vehicle networking device, comprising: obtaining a user identification code of a communication card on a vehicle through an in-vehicle communication terminal, and sending a login request containing a vehicle identification code and the user identification code to a network platform, wherein the network platform is used to verify whether the vehicle identification code is a registered vehicle; receiving a verification result fed back by the network platform based on the login request, and if the verification result indicates that the vehicle identification code has passed the verification of the network platform, determining whether to establish a binding relationship between the user identification code and the current vehicle identification code according to the historical binding record of the vehicle identification code on the network platform.

[0007] In one possible implementation, the network platform queries its database to see if there is a bound vehicle identification code corresponding to the user identification code; if it exists and the bound vehicle identification code is different from the current vehicle identification code, the binding relationship between the user identification code and the bound vehicle identification code is released, and a new binding relationship between the user identification code and the current vehicle identification code is established; if it does not exist, the binding relationship between the user identification code and the current vehicle identification code is established directly.

[0008] In one possible implementation, the network-connected platform calls an interface provided by a telecommunications operator, inputs the user identification code, and obtains the corresponding basic data of the communication card. The basic data of the communication card includes at least one of the following: integrated circuit card identification code, card activation time, activation status, and expiration date. The basic data of the communication card is then stored in the database of the network-connected platform.

[0009] In one possible implementation, the network service permissions of the current vehicle are dynamically controlled based on the activation status or expiration time in the basic data of the communication card, including: restricting at least one of remote control, OTA upgrade or data reporting services when the communication card is not activated or has expired.

[0010] In one possible implementation, the vehicle authentication service of the connected platform receives the login request and calls its vehicle data management service to verify whether the vehicle identification code conforms to the preset format rules and exists in the vehicle registration database of the connected platform; if the vehicle identification code meets the format rules and exists in the vehicle registration database, it is determined that the vehicle identification code is a registered vehicle and a verification pass result is generated; otherwise, it is determined to be an unregistered vehicle and subsequent binding processing is rejected.

[0011] In one possible implementation, after the network platform unbinds the user identification code from the original vehicle identification code, it sends a binding failure notification to the vehicle communication terminal corresponding to the original bound vehicle to trigger the original vehicle to re-execute the login authentication process.

[0012] In one possible implementation, after establishing a new binding relationship between the user identification code and the current vehicle identification code, the method further includes:

[0013] The online platform generates a binding change log containing new binding relationship information and a timestamp, and synchronizes the binding change log to the blockchain evidence storage node or audit database;

[0014] Send a binding change notification message to the user terminal associated with the user identification code, wherein the notification message includes the previously bound vehicle identification code, the current vehicle identification code, and the binding change time;

[0015] If the number of binding changes for the same user identification code exceeds the threshold within a preset time window, the abnormal risk control mechanism will be triggered, temporarily freezing the binding permissions of the user identification code and generating a security alarm.

[0016] Secondly, embodiments of this application provide a vehicle identity binding device based on a vehicle networking device, comprising: an acquisition module, configured to acquire a user identification code of a communication card on a vehicle via an in-vehicle communication terminal, and send a login request containing a vehicle identification code and the user identification code to a network platform, wherein the network platform is configured to verify whether the vehicle identification code is a registered vehicle; and a determination module, configured to receive a verification result fed back by the network platform based on the login request, and, if the verification result indicates that the vehicle identification code has passed the verification of the network platform, determine whether to establish a binding relationship between the user identification code and the current vehicle identification code based on the historical binding record of the vehicle identification code on the network platform.

[0017] Thirdly, embodiments of this application provide a vehicle identity binding device based on a vehicle networking device, including: a memory and a processor;

[0018] The memory stores computer-executed instructions;

[0019] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0020] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0021] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0022] The vehicle identity binding method, electronic device, and storage medium based on vehicle-to-everything (V2X) devices provided in this application embodiment involve the onboard communication terminal sending a login request containing a vehicle identification code and a communication card user identification code to the network platform each time a vehicle comes online. The network platform first verifies whether the vehicle is a registered vehicle, and then dynamically determines whether the correspondence between the vehicle and the communication card needs to be updated by combining the historical binding records of the user identification code in its database. This method avoids the "vehicle-card mismatch" problem caused by communication card replacement, reuse, or repair, ensuring that the platform always provides remote control, data services, and billing management based on the correct vehicle identity, thereby significantly improving the efficiency and accuracy of communication card data management on the V2X platform. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0024] Figure 1 A flowchart illustrating the vehicle identity binding method based on vehicle networking devices provided in this application. Figure 1 ;

[0025] Figure 2 A flowchart illustrating the vehicle identity binding method based on vehicle networking devices provided in this application. Figure 2 ;

[0026] Figure 3 A schematic diagram of the vehicle identity binding device based on the Internet of Vehicles (IoV) equipment provided in this application;

[0027] Figure 4 A schematic diagram of the vehicle identity binding device based on the Internet of Vehicles (IoV) provided in this application.

[0028] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

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

[0030] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0031] Figure 1 A flowchart illustrating the vehicle identity binding method based on vehicle networking devices provided in this application. Figure 1 ,like Figure 1 As shown, the method includes:

[0032] S201. Obtain the user identification code of the communication card on the vehicle through the vehicle-mounted communication terminal, and send a login request containing the vehicle identification code and the user identification code to the network platform.

[0033] The online platform is used to verify whether the vehicle identification number belongs to a registered vehicle.

[0034] Among them, vehicle-mounted communication terminals refer to networked devices (such as TBOX) installed in vehicles, which have mobile communication capabilities and are used to realize data interaction between vehicles and cloud platforms. They are usually equipped with IoT communication cards.

[0035] A communication card refers to an Internet of Things (IoT) SIM card or eSIM used for cellular network access, which provides data connectivity services. Each card has a globally unique identifier.

[0036] User identification code: also known as International Mobile Subscriber Identity (IMSI), is a unique identifier for a communication card within an operator's network. It is used to identify the user and their network affiliation, and in this scheme, it serves as the representative identifier for the communication card.

[0037] The Vehicle Identification Number (VIN) is a 17-character alphanumeric code that is a unique identifier for each vehicle worldwide.

[0038] The connected platform refers to the vehicle network service platform deployed in the cloud, which is responsible for vehicle access management, identity authentication, data processing and service delivery, including modules such as vehicle authentication service, database, and message middleware.

[0039] Registered vehicles refer to vehicles whose vehicle identification numbers have been verified by the car manufacturer or platform and stored in the vehicle registration database of the online platform, thus possessing legal qualifications for online services.

[0040] When the vehicle is powered on and started, the onboard communication terminal automatically initializes and reads the information of the locally inserted communication card, obtaining the user identification code (IMSI) of the communication card through AT commands or other standard interfaces. Simultaneously, the terminal reads the vehicle identification code (VIN) from the vehicle controller (such as the BCM or ECU). Subsequently, the terminal constructs a login request message, encapsulating the VIN and IMSI within it, and sends it to the connected platform via a cellular network (such as 4G / 5G).

[0041] Upon receiving the request, the online platform first enters the identity pre-verification stage: determining whether the VIN has been registered on the platform (i.e., whether it belongs to a legally authorized vehicle). This step aims to prevent unauthorized devices or vehicles from accessing the system and is a prerequisite for subsequent binding operations.

[0042] S202. Receive the verification result from the network connectivity platform based on the login request. If the verification result indicates that the vehicle identification code has passed the verification of the network connectivity platform, determine whether to establish a binding relationship between the user identification code and the current vehicle identification code based on the historical binding record of the vehicle identification code on the network connectivity platform.

[0043] The verification result refers to the output of the online platform's judgment on the legality of the vehicle identification code, which is usually either "passed" or "rejected".

[0044] Historical binding records refer to the historical mapping relationship between communication card user identification codes and vehicle identification codes stored in the database of the online platform, which is used to track the vehicles that each communication card has been bound to.

[0045] Establishing a binding relationship refers to creating or updating a record in the platform database that associates the current user identification code with the current vehicle identification code, serving as the identity basis for subsequent service calls.

[0046] In other words, after the online platform completes the verification of the vehicle identification number's legality, if the verification result is "passed," the dynamic binding decision process is triggered. The platform's communication card management service will query its database to retrieve whether there are any historical binding records associated with the current user identification number (IMSI).

[0047] This mechanism ensures that no matter how the communication card is replaced or reused, the network platform always uses the vehicle currently equipped with the card as the service target, fundamentally solving the service anomaly problem caused by "one card for multiple vehicles" or "vehicle-card mismatch".

[0048] The vehicle identity binding method based on vehicle-to-everything (V2X) devices provided in this application involves the onboard communication terminal sending a login request containing the vehicle identification code and the communication card user identification code to the network platform each time the vehicle comes online. The network platform first verifies whether the vehicle is a registered vehicle, and then dynamically determines whether the correspondence between the vehicle and the communication card needs to be updated by combining the historical binding records of the user identification code in its database. This method avoids the "vehicle-card mismatch" problem caused by communication card replacement, reuse, or repair, ensuring that the platform always provides remote control, data services, and billing management based on the correct vehicle identity, thereby significantly improving the efficiency and accuracy of communication card data management on the V2X platform.

[0049] Figure 2 A flowchart illustrating the vehicle identity binding method based on vehicle networking devices provided in this application. Figure 2 ,like Figure 2 As shown, in this embodiment... Figure 1 Based on the embodiments, a detailed description of the vehicle identity binding method based on vehicle networking devices is provided. The method includes:

[0050] S301. The vehicle authentication service of the connected platform receives the login request and calls its vehicle data management service to verify whether the vehicle identification code conforms to the preset format rules and exists in the vehicle registration database of the connected platform.

[0051] Optionally, if the vehicle identification number (VIN) meets the format rules and exists in the vehicle registration database, then the VIN is determined to be a registered vehicle, and a verification result is generated.

[0052] Alternatively, otherwise, the vehicle will be deemed an unregistered vehicle, and subsequent binding processing will be rejected.

[0053] Preset format rules: These refer to the rules for verifying the structural validity of the Vehicle Identification Number (VIN), such as: 17-digit length, no letters I / O / Q, the 10th digit representing the year, and having a valid check digit, which conforms to industry standards.

[0054] The vehicle registration database is a list of legal vehicles stored in the database of the connected vehicle platform. It only includes vehicle identification numbers that have been authorized by the car manufacturer or platform and have completed the network access registration.

[0055] If the verification passes, it means the vehicle is qualified to access the platform and can continue with the subsequent binding and service process; otherwise, the process will be terminated.

[0056] When the login request sent by the vehicle communication terminal reaches the connected platform, the vehicle authentication service first receives the request and extracts the Vehicle Identification Number (VIN). Subsequently, this service synchronously calls the vehicle data management service to initiate dual verification:

[0057] Format validation: Determines whether the VIN conforms to the preset 17-bit encoding rules and the validity of the characters;

[0058] Existence verification: Query the vehicle registration database of the online platform to confirm whether the VIN has been officially registered.

[0059] Only when both of the above verifications pass simultaneously will the vehicle authentication service determine that the vehicle is a registered vehicle, generate a verification pass result, and allow the process to proceed to the next stage (i.e., communication card binding processing).

[0060] If any verification fails (such as an incorrect VIN format, or a correct format but not registered in the registry), the vehicle is determined to be an unregistered vehicle. The vehicle authentication service immediately terminates the login process, refuses to perform subsequent binding relationship establishment or update operations, and can return an authentication failure response to the terminal to prevent unauthorized devices from accessing the platform.

[0061] This step ensures that only legitimate and authorized vehicles can participate in the dynamic binding mechanism, thus guaranteeing the security and data reliability of the vehicle-to-everything (V2X) system from the source.

[0062] S302. The online platform queries its database to see if there is a bound vehicle identification code corresponding to the user identification code.

[0063] Optionally, if a bound vehicle identification code exists and is different from the current vehicle identification code, the binding relationship between the user identification code and the bound vehicle identification code is released, and a new binding relationship between the user identification code and the current vehicle identification code is established.

[0064] Optionally, if it does not exist, a binding relationship between the user identification code and the current vehicle identification code is directly established.

[0065] "Bound Vehicle Identification Number" refers to a Vehicle Identification Number (VIN) that is associated with the user's identification number in the database of the online platform, indicating that the communication card has been previously assigned to a vehicle.

[0066] Unbinding refers to deleting or marking invalid "user identification code - vehicle identification code" mapping records in the platform database, so that the original vehicle is no longer regarded as a legitimate user of the communication card.

[0067] Establishing a new binding relationship means adding a new record in the database that associates the current user identification code with the current vehicle identification code, which will serve as the identity basis for subsequent service calls.

[0068] Specifically, after the vehicle identification number (VIN) passes the validity verification, the communication card management service of the connected vehicle platform performs a query operation in its database based on the user identification number carried in the login request to check whether there is a bound VIN associated with that user identification number. Based on the query results, the system processes the data according to the following logic:

[0069] If a vehicle identification number is already bound:

[0070] The system further compares whether the bound vehicle identification number matches the vehicle identification number in the current login request:

[0071] If there is a discrepancy, it means that the communication card has been removed from the original vehicle and installed in the new vehicle (e.g., due to maintenance, testing, reuse, or replacement of the TBOX). At this time, the platform will automatically unbind the user identification code from the original vehicle identification code and establish a new binding relationship between the user identification code and the current vehicle identification code in the database.

[0072] If they match, it means the communication card has not been changed, and the existing binding remains unchanged without any additional operation.

[0073] If no vehicle identification number is already bound:

[0074] This indicates that the user identification code is being used on the platform for the first time, or has not been used for any registered vehicle before. In this case, the platform directly creates a binding relationship between the user identification code and the current vehicle identification code, completing the initial binding.

[0075] Through the above mechanism, the network platform achieves dynamic alignment between communication cards and vehicle identities, ensuring that no matter how the communication card is transferred or reused, the platform will always accurately associate the service with the vehicle currently equipped with the card, effectively avoiding maintenance problems such as remote command mis-sending, data attribution errors, and billing confusion caused by "one card for multiple vehicles" or "vehicle-card mismatch".

[0076] For example, the Netcom platform calls the interface provided by the telecommunications operator, inputs the user identification code, and obtains the corresponding basic data of the communication card. The basic data of the communication card includes at least one of the following: integrated circuit card identification code, card activation time, activation status, and expiration date. The basic data of the communication card is then stored in the database of the Netcom platform.

[0077] Basic data of a communication card refers to a set of key information describing the basic attributes and status of an IoT communication card. For example, it includes: Integrated Circuit Card Identifier (ICCID): a unique physical number printed on the surface of the SIM card to identify the card itself; Activation time: the timestamp of the card's activation process in the operator's system; Activation status: indicating whether the card has completed its first activation (e.g., "activated" or "not activated"); Expiry date: the end date of the communication card's service validity period, after which it will be unable to access the network or generate data traffic.

[0078] When the connected platform discovers that the current user identification code (IMSI) has not been registered in the local database during the vehicle login process (e.g., for first-time access or for a new card), in order to avoid subsequent services failing due to lack of card information, the platform will proactively initiate a data synchronization operation with the telecommunications operator's system.

[0079] Specifically, the platform's communication card management service constructs a standard query request, using the user identification code as a parameter, and calls the open interface provided by the communication operator after security authentication. Upon receiving the request, the operator's system returns the basic communication card data associated with that IMSI.

[0080] After receiving the response, the platform parses and extracts the valid fields (such as ICCID, activation status, validity period, etc.), and stores this information in a structured manner in the database of the network platform to form a complete communication card file.

[0081] This not only allows for the construction of a proprietary communication card asset database, eliminating the need for manual data entry and enabling automatic collection and archiving of SIM card information, but also supports subsequent intelligent management: the acquired activation status and validity period can be directly used to determine whether a vehicle is eligible for network connectivity. For example, if the card is not activated or has expired, services such as remote control, OTA upgrades, or high-bandwidth data reporting can be automatically restricted, enhancing the platform's ability to manage communication resources with greater precision.

[0082] For example, based on the activation status or expiration date in the basic data of the communication card, the network service permissions of the current vehicle can be dynamically controlled, including: when the communication card is not activated or has expired, restricting at least one of the following services: remote control, OTA upgrade or data reporting.

[0083] Optionally, network service permissions refer to the set of cloud functions that the vehicle can use through the vehicle communication terminal, including: remote control: such as issuing commands for remote start, air conditioning control, door unlocking, etc.

[0084] OTA (Over-The-Air) update: Over-the-air technology used to remotely update vehicle ECU firmware or application software;

[0085] Data reporting: Vehicle operating status, fault codes, location, energy consumption and other data are uploaded to the platform periodically or triggered by events.

[0086] Dynamic control: This refers to the network platform evaluating the communication card status in real time each time a vehicle logs in or during periodic heartbeat checks, and adjusting the vehicle's service access permissions accordingly, rather than relying on static configuration.

[0087] After establishing the binding relationship between the user identification code and the current vehicle identification code, the network platform will read the basic data of the communication card associated with the user identification code from its database, focusing on checking the activation status and expiration date.

[0088] The platform dynamically determines and executes service access control based on the following rules:

[0089] If the activation status is "not activated", it means that the communication card has not been activated and does not have legal communication qualifications;

[0090] If the current system time has exceeded the expiration date, it indicates that the card service has expired.

[0091] The connected platform will then automatically restrict some or all of the vehicle's network services. Specific restriction policies may include: prohibiting the receipt of remote control commands from users (to prevent invalid operations);

[0092] Pause OTA upgrade push tasks (to avoid flashing failure due to network interruption);

[0093] Reduce or stop the frequency of vehicle data reporting (reduce invalid traffic consumption);

[0094] The vehicle is marked as "communication abnormal" in the management backend for maintenance personnel to follow up.

[0095] The aforementioned restrictions can be implemented at the request entry point through the platform's service gateway. For example, when a remote control command is received, the communication card status of the corresponding vehicle is first checked. If the status does not meet the requirements, the command is rejected directly and an error code is returned.

[0096] This mechanism enables refined service governance based on the lifecycle of communication cards. On the one hand, it avoids service failures and resource waste caused by the use of inactive or expired cards. On the other hand, it also encourages users to renew or activate communication services in a timely manner, thereby ensuring the stability, security and commercial sustainability of vehicle networking services.

[0097] For example, after the network platform unbinds the user identification code from the original vehicle identification code, it sends a binding failure notification to the vehicle communication terminal corresponding to the original bound vehicle to trigger the original vehicle to re-execute the login authentication process.

[0098] Specifically, when the network platform detects that the same communication card has been installed in a new vehicle and performs an unbinding operation (i.e., unbinding the user identification code from the original vehicle identification code), in order to prevent the original vehicle from continuing to operate with an "invalid identity" without its knowledge, which could lead to service abnormalities or lost instructions, the platform will immediately (for example, within milliseconds after the unbinding transaction is submitted) push a binding failure notification to the vehicle communication terminal corresponding to the original bound vehicle.

[0099] Optionally, the notification can be sent in real time through a long-established connection channel between the platform and the vehicle (such as downlink messages based on the MQTT protocol). Upon receiving the notification, the vehicle's onboard communication terminal recognizes its abnormal identity status and triggers a local re-authentication mechanism.

[0100] Clear cached session credentials;

[0101] Reread the communication card information currently installed in this vehicle (including the new or still retained IMSI);

[0102] Construct a new login request and re-initiate authentication with the online platform.

[0103] If the original vehicle is still using the same communication card (i.e., it has not been replaced), the platform will refuse its login because the card has been bound to the new vehicle, and will display the message "The communication card has been used by another vehicle"; if the original vehicle has been replaced with a new card, the new binding can be completed normally.

[0104] This mechanism enables two-way identity synchronization, ensuring that at any given time, one communication card corresponds to only one valid vehicle, while also ensuring that the original vehicle can promptly detect identity changes and respond accordingly, significantly improving the consistency, reliability, and user experience of the vehicle networking system.

[0105] Optionally, the online platform generates a binding change log containing new binding relationship information and timestamps, and synchronizes the binding change log to the blockchain evidence storage node or audit database;

[0106] Send a binding change notification message to the user terminal associated with the user identification code. The notification message includes the previously bound vehicle identification code, the current vehicle identification code, and the binding change time.

[0107] In other words, whenever a "vehicle change" or "card change" binding change occurs, the system not only needs to record it in the regular database, but also generate a detailed log (who, when, and from which vehicle to which vehicle). This log will be sent to the blockchain or a dedicated audit database.

[0108] In this way, ordinary database administrators might have the right to modify data to cover up illegal operations (such as secretly binding the card of car A to car B). However, once the data is on the blockchain, it becomes immutable and has a timestamp. If a vehicle is stolen, there is an insurance dispute, or an asset ownership dispute occurs in the future, this record will be legally recognized "ironclad evidence" that can reconstruct the true history of vehicle transfer.

[0109] If the number of binding changes for the same user identification code exceeds the threshold within a preset time window, the abnormal risk control mechanism will be triggered, temporarily freezing the binding permissions of the user identification code and generating a security alarm.

[0110] The system monitors each communication card (user identification code) to see if it frequently switches between different vehicles within a short period (e.g., within 1 hour or 24 hours). If the number of switching exceeds a set threshold, the system determines it as abnormal. It then freezes the card's binding function (preventing further binding) and sends an alert to the safety officer.

[0111] The vehicle identity binding method based on vehicle-to-everything (V2X) devices provided in this application involves the onboard communication terminal sending a login request containing the vehicle identification code and the communication card user identification code to the network platform each time the vehicle comes online. The network platform first verifies whether the vehicle is a registered vehicle, and then dynamically determines whether the correspondence between the vehicle and the communication card needs to be updated by combining the historical binding records of the user identification code in its database. This method avoids the "vehicle-card mismatch" problem caused by communication card replacement, reuse, or repair, ensuring that the platform always provides remote control, data services, and billing management based on the correct vehicle identity, thereby significantly improving the efficiency and accuracy of communication card data management on the V2X platform.

[0112] Figure 3 This is a schematic diagram of the vehicle identity binding device based on the Internet of Vehicles (IoV) provided in this application, such as... Figure 3 As shown, the vehicle identity binding device 40 based on the Internet of Vehicles (IoV) device provided in this embodiment includes:

[0113] The acquisition module 401 is used to acquire the user identification code of the communication card on the vehicle through the vehicle communication terminal, and send a login request containing the vehicle identification code and the user identification code to the network platform. The network platform is used to verify whether the vehicle identification code belongs to a registered vehicle.

[0114] The determination module 402 is used to receive the verification result fed back by the network platform based on the login request. If the verification result indicates that the vehicle identification code has passed the verification of the network platform, it determines whether to establish a binding relationship between the user identification code and the current vehicle identification code based on the historical binding record of the vehicle identification code on the network platform.

[0115] In one possible implementation, the determining module 402 is used to query the database of the network platform to see if there is a bound vehicle identification code corresponding to the user identification code; if there is, and the bound vehicle identification code is different from the current vehicle identification code, then the binding relationship between the user identification code and the bound vehicle identification code is released, and a new binding relationship between the user identification code and the current vehicle identification code is established; if there is no binding relationship, then the binding relationship between the user identification code and the current vehicle identification code is established directly.

[0116] In one possible implementation, the determining module 402 is used to call the interface provided by the communication operator through the network platform, pass in the user identification code, and obtain the corresponding communication card basic data, wherein the communication card basic data includes at least one of the following: integrated circuit card identification code, card opening time, activation status, and expiration time; and store the communication card basic data in the database of the network platform.

[0117] In one possible implementation, the determining module 402 is used to dynamically control the network service permissions of the current vehicle based on the activation status or expiration time in the basic data of the communication card, including: restricting at least one of remote control, OTA upgrade or data reporting services when the communication card is not activated or has expired.

[0118] In one possible implementation, the acquisition module 401 is used to receive the login request from the vehicle authentication service of the connected platform and call its vehicle data management service to verify whether the vehicle identification code conforms to the preset format rules and exists in the vehicle registration database of the connected platform; if the vehicle identification code meets the format rules and exists in the vehicle registration database, it is determined that the vehicle identification code is a registered vehicle and a verification pass result is generated; otherwise, it is determined to be an unregistered vehicle and subsequent binding processing is rejected.

[0119] In one possible implementation, the determining module 402 is used to send a binding failure notification to the vehicle communication terminal corresponding to the original bound vehicle after the network platform unbinds the user identification code from the original vehicle identification code, so as to trigger the original vehicle to re-execute the login authentication process.

[0120] In one possible implementation, the determining module 402 is used to generate a binding change log containing new binding relationship information and a timestamp from the network platform, and synchronize the binding change log to the blockchain evidence storage node or audit database; send a binding change notification message to the user terminal associated with the user identification code, wherein the notification message contains the previously bound vehicle identification code, the current vehicle identification code, and the binding change time; if it is detected that the same user identification code has undergone more than a threshold number of binding changes within a preset time window, an abnormal risk control mechanism is triggered, temporarily freezing the binding permission of the user identification code and generating a security alarm.

[0121] The vehicle identity binding device based on the Internet of Vehicles (IoV) device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0122] Figure 4 This is a schematic diagram of the vehicle identity binding device based on the Internet of Vehicles (IoV) provided in this application. Figure 4As shown, the electronic device 50 provided in this embodiment includes at least one processor 501 and a memory 502. Optionally, the device 50 further includes a communication component 503. The processor 501, memory 502, and communication component 503 are connected via a bus 504.

[0123] In a specific implementation, at least one processor 501 executes computer execution instructions stored in memory 502, causing at least one processor 501 to perform the above-described method.

[0124] The specific implementation process of processor 501 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0125] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0126] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0127] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0128] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0129] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0130] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0131] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0132] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0133] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0134] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0135] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0136] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0137] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for binding vehicle identity based on vehicle networking devices, characterized in that, include: The user identification code of the communication card on the vehicle is obtained through the vehicle-mounted communication terminal, and a login request containing the vehicle identification code and the user identification code is sent to the network platform. The network platform is used to verify whether the vehicle identification code belongs to a registered vehicle. The system receives the verification result from the connected platform based on the login request. If the verification result indicates that the vehicle identification code has passed the verification of the connected platform, the system determines whether to establish a binding relationship between the user identification code and the current vehicle identification code based on the historical binding record of the vehicle identification code on the connected platform.

2. The method according to claim 1, characterized in that, Determining whether to establish a binding relationship between the user identification code and the current vehicle identification code based on the historical binding records of the vehicle identification code on the connected vehicle platform includes: The online platform queries its database to see if there is a bound vehicle identification code corresponding to the user identification code; If a bound vehicle identification code exists and is different from the current vehicle identification code, then the binding relationship between the user identification code and the bound vehicle identification code is released, and a new binding relationship between the user identification code and the current vehicle identification code is established. If it does not exist, then directly establish the binding relationship between the user identification code and the current vehicle identification code.

3. The method according to claim 2, characterized in that, Before establishing the binding relationship between the user identification code and the current vehicle identification code, the method further includes: The network platform calls the interface provided by the telecommunications operator, inputs the user identification code, and obtains the corresponding basic data of the communication card. The basic data of the communication card includes at least one of the following: integrated circuit card identification code, card activation time, activation status, and expiration date. The basic data of the communication card is stored in the database of the network platform.

4. The method according to claim 3, characterized in that, After storing the basic data of the communication card in the database of the network platform, the method further includes: Based on the activation status or expiration time in the basic data of the communication card, the network service permissions of the current vehicle are dynamically controlled, including: when the communication card is not activated or has expired, restricting at least one of the following services: remote control, OTA upgrade or data reporting.

5. The method according to claim 1, characterized in that, After sending a login request containing the vehicle identification code and the user identification code to the online platform, the method further includes: The vehicle authentication service of the connected platform receives the login request and calls its vehicle data management service to verify whether the vehicle identification code conforms to the preset format rules and exists in the vehicle registration database of the connected platform. If the vehicle identification number meets the format rules and exists in the vehicle registration database, then the vehicle identification number is determined to be a registered vehicle, and a verification result is generated. Otherwise, it will be judged as an unregistered vehicle, and subsequent binding processing will be refused.

6. The method according to claim 2, characterized in that, After the network platform unbinds the user identification code from the original vehicle identification code, it sends a binding failure notification to the vehicle communication terminal corresponding to the original bound vehicle to trigger the original vehicle to re-execute the login authentication process.

7. The method according to claim 2, characterized in that, After establishing the new binding relationship between the user identification code and the current vehicle identification code, the method further includes: The online platform generates a binding change log containing new binding relationship information and a timestamp, and synchronizes the binding change log to the blockchain evidence storage node or audit database; Send a binding change notification message to the user terminal associated with the user identification code, wherein the notification message includes the previously bound vehicle identification code, the current vehicle identification code, and the binding change time; If the number of binding changes for the same user identification code exceeds the threshold within a preset time window, the abnormal risk control mechanism will be triggered, temporarily freezing the binding permissions of the user identification code and generating a security alarm.

8. A vehicle identity binding device based on a vehicle networking device, characterized in that, include: The acquisition module is used to acquire the user identification code of the communication card on the vehicle through the vehicle-mounted communication terminal, and send a login request containing the vehicle identification code and the user identification code to the network platform, wherein the network platform is used to verify whether the vehicle identification code belongs to a registered vehicle; The determination module is used to receive the verification result fed back by the network platform based on the login request, and if the verification result indicates that the vehicle identification code has passed the verification of the network platform, determine whether to establish a binding relationship between the user identification code and the current vehicle identification code according to the historical binding record of the vehicle identification code on the network platform.

9. A vehicle identity binding device based on a vehicle networking device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

Images