Vehicle information query method and device and storage medium

Abstract

The invention discloses a vehicle information query method and device and a storage medium, relates to the technical field of vehicle information sharing and access control, and discloses a vehicle information query method, which comprises the following steps: in response to a vehicle insurance quotation request for a target vehicle, generating a dynamic encryption token associated with a current session and a corresponding vehicle insurance quotation list; in response to the vehicle information access request, obtaining vehicle historical data related to the target vehicle; according to the identity information of the current visitor and the data label attached to each data item in the historical data of the vehicle, determining the range of data authorized to be accessed; and based on the data range and the historical data of the vehicle, returning a vehicle information view matched with the authority of the current visitor. According to the method, the access security is guaranteed through dynamically encrypting the token, accurate authority control is realized in combination with the identity information and the data label, dispersed vehicle historical data can be integrated and presented as required, the problem of information asymmetry in vehicle insurance quotation is effectively solved, and the pricing accuracy and the information transparency are improved.

Description

Technical Field

[0001] This application relates to the field of vehicle information sharing and access control technology, and in particular to a vehicle information query method, device and storage medium. Background Technology

[0002] In vehicle information sharing scenarios, such as used car transactions, insurance underwriting, or financial risk control, it is often necessary to temporarily provide third parties with historical data of specific vehicles, including insurance claims records, maintenance information, and traffic violation records. However, this data is scattered across multiple independent systems of insurance companies and traffic management departments, lacking an effective integration mechanism. Insurance companies and consumers struggle to fully grasp the complete history of a vehicle since its registration, leading to insufficient risk identification and severe information asymmetry. Consumers cannot verify the reasonableness of car insurance premiums, insurance companies struggle to achieve accurate underwriting, and used car buyers face valuation discrepancies and transaction risks due to the lack of crucial information.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main purpose of this application is to provide a vehicle information query method, device and storage medium, which aims to solve the technical problem that insurance companies and consumers cannot accurately control vehicle risks and pricing due to the dispersion of vehicle historical data and information asymmetry.

[0005] To achieve the above objectives, this application provides a vehicle information query method, which includes: In response to a car insurance quote request for a target vehicle, a dynamic encryption token and a corresponding car insurance quote are generated and associated with the current session; wherein, the dynamic encryption token is embedded in a QR code, which is a component of the car insurance quote, so that visitors can initiate a vehicle information access request carrying the dynamic encryption token by scanning the QR code. In response to the vehicle information access request, historical vehicle data related to the target vehicle is obtained. The historical vehicle data includes vehicle insurance underwriting records, insurance claim records, traffic violation information, maintenance records, driving behavior assessments, vehicle registration changes and pledge / seizure status. Each data item in the historical vehicle data is attached with a data tag. Based on the current visitor's identity information and the data tags attached to each data item in the vehicle's historical data, the scope of data that the current visitor is authorized to access is determined; Based on the data range and the vehicle history data, a vehicle information view that matches the current visitor's permissions is generated and returned.

[0006] In one embodiment, the step of determining the data range that the current visitor is authorized to access based on the current visitor's identity information and the data tags attached to each data item in the vehicle history data includes: Based on the current visitor's identity information, obtain the current visitor's role type; Based on the role type, query the preset identity tag mapping table to obtain the target data tag set corresponding to the current visitor; Match the data tags of each data item in the vehicle history data with the target data tag set; The data items that are successfully matched will be included in the data range that the current visitor is authorized to access.

[0007] In one embodiment, the step of obtaining historical vehicle data related to the target vehicle in response to the vehicle information access request includes: Upon receiving the vehicle information access request, the session identifier, timestamp, and target vehicle identification information are obtained from the dynamic encryption token. If the difference between the current time and the timestamp exceeds a preset valid duration, or if the dynamic encryption token is marked as used, then the vehicle historical data will not be returned. Otherwise, based on the identification information of the target vehicle contained in the dynamic encryption token, the corresponding historical data of the vehicle is queried and returned.

[0008] In one embodiment, the step of refusing to return the vehicle history data if the difference between the current time and the timestamp exceeds a preset valid duration, or if the dynamic encryption token is marked as used, includes: When the difference between the current time and the timestamp exceeds the preset valid duration, a first rejection response message is generated; When it is detected that the dynamic encryption token has been marked as used, a second rejection response message is generated; The generated rejection response information is returned to the client of the current visitor.

[0009] In one embodiment, before the step of determining the data range authorized for access by the current visitor based on the current visitor's identity information and the data tags attached to each data item in the vehicle historical data, the vehicle information query method further includes: In response to the vehicle information access request, the current visitor is guided to complete real-name authentication through a third-party identity authentication platform in order to obtain the current visitor's identity information; Based on the vehicle registration information in the vehicle's historical data, the identity information of the vehicle owner of the target vehicle is determined; The identity information of the current visitor is compared with the identity information of the vehicle owner; If the comparison results are consistent, then the step of determining the data range that the current visitor is authorized to access based on the current visitor's identity information and the data tags attached to each data item in the vehicle's historical data is directly executed; If the comparison results are inconsistent, the current visitor is determined to be a third-party visitor, and the authorization verification process is triggered.

[0010] In one embodiment, the step of determining that the current visitor is a third-party visitor and triggering the authorization verification process if the comparison results are inconsistent includes: Send an authorization request notification to the vehicle owner, the authorization request notification including the user identifier of the third-party visitor and the business scenario type of the current session; In response to the authorization confirmation operation initiated by the vehicle owner through the authentication terminal, a temporary authorization credential is generated and returned to the current session of the third-party visitor; After obtaining the temporary authorization credential, the step of determining the data range that the current visitor is authorized to access is executed based on the current visitor's identity information and the data tags attached to each data item in the vehicle's historical data.

[0011] In one embodiment, the step of generating a dynamic encrypted token and a corresponding car insurance quote associated with the current session in response to a car insurance quote request for the target vehicle includes: Obtain the identification information of the target vehicle and the session identifier of the current session; Based on a preset encryption algorithm, the identification information, the session identifier, and the current timestamp are encrypted to generate a basic token value; Based on the business scenario type of the current session, an initial access policy is determined. The initial access policy includes the default allowed role types, the valid access duration, and whether multiple uses are allowed. The basic token value and the initial access policy are encapsulated into a token payload, and the token payload is digitally signed using the server's private key to generate the dynamic encrypted token. The dynamic encrypted token is stored in association with the session identifier. The dynamic encryption token is embedded into the QR code, and the QR code is embedded into the car insurance quote to generate the car insurance quote.

[0012] In one embodiment, the step of generating and returning a vehicle information view that matches the current visitor's permissions based on the data range and the vehicle history data includes: Based on the data range, target data items are extracted from the vehicle historical data; The target data items are desensitized, and the desensitization process includes partially hiding or replacing sensitive information according to preset rules; The de-identified target data items are organized and arranged according to a preset view template, which is pre-set according to different business scenario types and role types; The organized target data items are encapsulated into the vehicle information view, and the vehicle information view is returned to the current visitor's client for display.

[0013] This application embodiment also provides a vehicle information query device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. The computer program is configured to implement the steps of the vehicle information query method described above.

[0014] This application embodiment also provides a storage medium, which is a computer-readable storage medium, and stores a computer program thereon. When the computer program is executed by a processor, it implements the steps of the vehicle information query method described above.

[0015] One or more technical solutions proposed in this application have at least the following technical effects: This application generates a dynamic encrypted token associated with the current session when responding to a car insurance quote request, and embeds this dynamic encrypted token into a QR code to generate a car insurance quote containing the QR code. Because this dynamic encrypted token is bound to the current business session and integrated with the car insurance quote via the QR code, rather than relying solely on user identity or fixed authorization information, even if the token is intercepted or forwarded, it cannot be used by unauthorized entities to access data from other sessions or vehicles, thus effectively preventing unauthorized access, ensuring the security of vehicle historical information, and avoiding the leakage of sensitive data. By responding to a vehicle information access request triggered by a visitor scanning the QR code in the car insurance quote, carrying this dynamic encrypted token, vehicle historical data is obtained. Each data item is labeled with a data tag, providing a clear data attribute basis for subsequent refined access control, making the classification and management of vehicle historical data feasible, and solving the problem of vehicle historical information being scattered across different institutions such as insurance companies and traffic management departments, making efficient aggregation difficult. Furthermore, by... The system matches the user's identity information with data tags in the vehicle's historical data to dynamically determine the scope of data that the user is authorized to access. This achieves dual access control based on identity and data attributes, ensuring that users with different identities can only access vehicle data within their authorized scope. This avoids data abuse or information loss caused by excessive permissions or insufficient control. In addition, the system generates and returns a vehicle information view that matches the user's permissions based on the authorized data scope. This presents the scattered and permission-filtered historical vehicle data in an intuitive view, allowing users (such as insurance companies and consumers) to clearly obtain the vehicle's historical information under their corresponding permissions. This effectively solves the information asymmetry problem in car insurance quotations and used car transactions. It provides complete data support for insurance companies to accurately price car insurance and allows consumers to intuitively understand the pricing basis, while ensuring the compliance and security of data access. Attached Figure Description

[0016] Figure 1 This is a flowchart illustrating the vehicle information query method of this application in Embodiment 1. Figure 2 This is a flowchart illustrating Embodiment 2 of the vehicle information query method of this application; Figure 3 This is a flowchart illustrating Embodiment 3 of the vehicle information query method of this application; Figure 4 This is a flowchart illustrating Embodiment 4 of the vehicle information query method of this application; Figure 5 This is a flowchart illustrating Embodiment 5 of the vehicle information query method of this application; Figure 6 This is a schematic diagram of the structure of the vehicle information query device in the hardware operating environment involved in the vehicle information query method in this application embodiment.

[0017] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0018] It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit this application.

[0019] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0020] In vehicle information sharing scenarios, such as used car transactions, insurance underwriting, or financial risk control, it is often necessary to temporarily provide third parties with historical data of specific vehicles, including insurance claims records, maintenance information, and traffic violation records. However, this data is scattered across multiple independent systems of insurance companies and traffic management departments, lacking an effective integration mechanism. Insurance companies and consumers struggle to fully grasp the complete history of a vehicle since its registration, leading to insufficient risk identification and severe information asymmetry. Consumers cannot verify the reasonableness of car insurance premiums, insurance companies struggle to achieve accurate underwriting, and used car buyers face valuation discrepancies and transaction risks due to the lack of crucial information.

[0021] In view of the above problems, this application proposes a vehicle information query method. In response to a car insurance quote request for a target vehicle, a dynamic encrypted token and a corresponding car insurance quote associated with the current session are generated. The dynamic encrypted token is embedded in a QR code, which is a component of the car insurance quote, allowing a visitor to initiate a vehicle information access request carrying the dynamic encrypted token by scanning the QR code. In response to the vehicle information access request, historical vehicle data related to the target vehicle is obtained. This historical data includes car insurance underwriting records, insurance claim records, traffic violation information, maintenance records, driving behavior assessments, vehicle registration changes, and pledge / seizure status. Each data item in the historical data is attached with a data tag. Based on the current visitor's identity information and the data tags attached to each data item in the historical vehicle data, the data scope authorized for access by the current visitor is determined. Based on the data scope and the historical vehicle data, a vehicle information view matching the current visitor's permissions is generated and returned.

[0022] This application provides a solution that generates a dynamic encrypted token associated with the current session when responding to a car insurance quote request, and embeds this dynamic encrypted token into a QR code to generate a car insurance quote containing the QR code. Because this dynamic encrypted token is bound to the current business session and integrated with the car insurance quote via the QR code, rather than relying solely on user identity or fixed authorization information, even if the token is intercepted or forwarded, it cannot be used by unauthorized entities to access data from other sessions or vehicles, thus effectively preventing unauthorized access, ensuring the security of vehicle historical information, and avoiding the leakage of sensitive data. By responding to a vehicle information access request triggered by a visitor scanning the QR code in the car insurance quote, carrying this dynamic encrypted token, vehicle historical data is obtained. Each data item is labeled with a data tag, providing a clear data attribute basis for subsequent refined access control, making the classification and management of vehicle historical data feasible, and solving the problem of vehicle historical information being scattered across different institutions such as insurance companies and traffic management departments, making efficient aggregation difficult. Furthermore, by... The system matches the user's identity information with data tags in the vehicle's historical data to dynamically determine the scope of data that the user is authorized to access. This achieves dual access control based on identity and data attributes, ensuring that users with different identities can only access vehicle data within their authorized scope. This avoids data abuse or information loss caused by excessive permissions or insufficient control. In addition, the system generates and returns a vehicle information view that matches the user's permissions based on the authorized data scope. This presents the scattered and permission-filtered historical vehicle data in an intuitive view, allowing users (such as insurance companies and consumers) to clearly obtain the vehicle's historical information under their corresponding permissions. This effectively solves the information asymmetry problem in car insurance quotations and used car transactions. It provides complete data support for insurance companies to accurately price car insurance and allows consumers to intuitively understand the pricing basis, while ensuring the compliance and security of data access.

[0023] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a computer, mobile phone, cloud service platform, etc., or an electronic device, vehicle data service platform, vehicle information query system, etc., capable of realizing the above functions. The following description uses a vehicle information query system as an example to illustrate this embodiment and the subsequent embodiments.

[0024] Please refer to the vehicle information query method of the first embodiment proposed in this application. Figure 1 The method includes steps S10 to S40: Step S10: In response to a car insurance quote request for the target vehicle, generate a dynamic encryption token and a corresponding car insurance quote associated with the current session; wherein, the dynamic encryption token is embedded in a QR code, which is a component of the car insurance quote, so that visitors can initiate a vehicle information access request carrying the dynamic encryption token by scanning the QR code.

[0025] It should be noted that the target vehicle refers to the vehicle to be insured specified by the user when initiating a car insurance quote, usually identified by entering the vehicle identification number (VIN) or license plate number; the car insurance quote request is a business instruction initiated by the user terminal (such as an insurance company's APP, web page, or third-party platform) to the server to obtain the estimated insurance cost of the target vehicle; the current session refers to the logical interaction process from the time the user submits the car insurance quote request to the generation of the car insurance quote containing a QR code, and the completion of viewing the vehicle's historical information or abandoning the operation, which is usually uniquely identified by a session identifier (SessionID).

[0026] A dynamic encryption token is a security credential with time-limited validity. Its content is strongly bound to the target vehicle's identification information, the current session context, and a time factor, and is used for controlled access to the vehicle's historical data. This dynamic encryption token is valid only for a limited time after generation and cannot be reused after use, thus preventing replay attacks or unauthorized access if the token is intercepted.

[0027] In this embodiment, the car insurance quote can be generated and delivered in the form of an electronic document or a paper document. Besides QR codes, dynamic encryption tokens can also be embedded in the quote via embedded NFC tags or encrypted access links to adapt to different access scenarios and terminal capabilities. For example, in an electronic quote scenario, a car insurance quote page containing an encrypted link can be directly generated; visitors can click the link to initiate a request carrying the dynamic encryption token. In a paper quote scenario, an NFC adhesive label pre-written with the dynamic encryption token can be affixed to the surface of the quote; visitors can use an NFC-enabled mobile terminal to seamlessly read the dynamic encryption token and trigger access by simply tapping it against the NFC tag.

[0028] In scenarios such as auto insurance and used car transactions, vehicle-related information is often managed separately by different institutions. Insurance company underwriting and claims records, traffic management platform violation data, and repair shop maintenance and accident repair information are isolated and lack effective integration. Users typically only have access to the vehicle's current insurance status or some publicly available violation records, making it difficult to fully understand its complete history since registration, including key risk factors such as the number of accidents, liability determinations, repair costs, ownership transfers, and pledge status. This fragmented information makes it difficult for insurance companies to fully assess the true risk of individual vehicles when pricing, and consumers, lacking transparent criteria, struggle to judge the reasonableness of premiums or the actual value of used cars, easily leading to a lack of trust and biased decision-making.

[0029] As a feasible implementation method, a dynamic encryption token can be generated by combining the target vehicle's identification information, the current session identifier, and a timestamp, and then performing a one-way encryption operation with a key. This combination can be further enhanced with a random perturbation factor to improve uniqueness. The generated dynamic encryption token is signed by the server, associated with the session identifier, and stored with a limited validity period. Once a dynamic encryption token is used for data access, it is marked as used, and subsequent requests for vehicle information access using the same dynamic encryption token will be rejected.

[0030] Understandably, in temporary interaction scenarios such as car insurance quotes, relying on long-term identity credentials or open static data interfaces can easily lead to the unauthorized dissemination of sensitive vehicle information. However, by generating a dynamic encrypted token that is instantly bound to the vehicle, session, and time at the moment the quote is triggered, each data access request for vehicle information has context awareness and a one-time characteristic. This not only effectively prevents the risks of token reuse and man-in-the-middle attacks but also provides a trusted entry point for subsequent identity-based fine-grained access control, significantly improving the security and privacy compliance of vehicle historical data in cross-entity collaboration.

[0031] Step S20: In response to the vehicle information access request, obtain the vehicle historical data related to the target vehicle. The vehicle historical data includes vehicle insurance underwriting records, insurance claim records, traffic violation information, maintenance records, driving behavior assessments, vehicle registration changes and pledge / seizure status. Each data item in the vehicle historical data is attached with a data tag.

[0032] It should be noted that vehicle history data refers to structured or semi-structured records related to vehicle status, usage behavior, and risk events generated in multiple business systems since the target vehicle was first registered and licensed. These records include, but are not limited to, vehicle insurance underwriting records, insurance claim records (such as accident time, accident type, compensation amount, and liability determination), traffic violation information (such as violation code, penalty result, and location of occurrence), maintenance records (such as repair items, replaced parts, and labor costs), driving behavior assessments, vehicle registration changes (such as number of transfers and time of change of owner), and pledge / seizure status.

[0033] Data tags are metadata identifiers assigned to each data item in vehicle history data, used to describe the sensitivity level, business category, applicable role type, or disclosure conditions of that data item. For example, "accident amount" can be tagged as "highly sensitive - visible only to vehicle owner / insurance company underwriter," and "number of traffic violations" can be tagged as "low sensitive - visible to all certified users." Data tags can be automatically assigned by the system according to preset rules when the data is entered into the database, or they can be manually reviewed and added later.

[0034] As a feasible implementation method, upon receiving a vehicle information access request carrying a dynamic encryption token, the system first parses the dynamic encryption token to verify its validity (including timeliness, whether it has been used, signature legality, etc.). If the verification is successful, the system aggregates the corresponding vehicle historical data from multiple source databases (such as insurance company claims systems, traffic management platforms, and third-party data platforms) based on the identification information of the target vehicle contained in the dynamic encryption token, and attaches a predefined data tag to each data item.

[0035] As an example, the system can call a unified data service middleware, which connects to multiple data sources and has a built-in tag mapping engine. When the middleware returns the original vehicle history data, the tag engine automatically matches the tag template based on the data field name, data source organization, and content characteristics, and finally outputs a vehicle history dataset in JSON format with data tags.

[0036] As another feasible implementation method, after step S20, the following steps are included: extracting characteristic indicators related to vehicle risk based on historical vehicle data. These characteristic indicators include the number of accidents, accident liability type, cumulative compensation amount, repair item category, frequency of traffic violations, vehicle age, and transfer frequency. The characteristic indicators are then input into a preset risk assessment model, which outputs the risk level of the target vehicle. The risk level includes low risk, medium risk, or high risk. Based on the risk level of the target vehicle, the identity information of the current visitor (e.g., role type), and the business scenario type of the current session, a set of restricted data tags corresponding to the current visitor is determined, and this set of restricted data tags is used as the final authorized data range.

[0037] Step S30: Determine the data range that the current visitor is authorized to access based on the current visitor's identity information and the data tags attached to each data item in the vehicle history data.

[0038] It should be noted that the current visitor's identity information refers to the set of user attributes obtained after real-name authentication during this visit, including user ID, real name, ID number, authentication method (such as facial recognition, bank card verification, etc.), and the type of role (such as car owner, insurance company employee, used car buyer, financial risk control personnel, etc.).

[0039] It should be noted that, in order to protect user privacy and data security, all collection, storage, processing and access to sensitive personal information (including but not limited to real names, ID numbers, biometric features, bank cards, vehicle usage records) shall be conducted in strict accordance with relevant laws and regulations and privacy protection standards, and only with the explicit, voluntary and informed authorization of the user.

[0040] As one possible implementation, step S30 includes steps S310 to S340: Step S310: Obtain the role type of the current visitor based on the current visitor's identity information.

[0041] Step S320: Based on the role type, query the preset identity tag mapping table to obtain the target data tag set corresponding to the current visitor.

[0042] Step S330: Match the data tags of each data item in the vehicle history data with the target data tag set.

[0043] Step S340: Include the successfully matched data item in the data range that the current visitor is authorized to access.

[0044] The system can pre-configure an identity tag mapping table, which defines the set of data tags that different role types are allowed to access. When determining the data range that the current visitor is authorized to access (hereinafter referred to as the authorized access range), the system first parses the current visitor's identity information to determine their role type, and then queries the identity tag mapping table to obtain the corresponding target set of data tags; subsequently, it matches the tags of each data item in the vehicle's historical data with this set, and only retains the data items that match successfully as the authorized access range.

[0045] As an example, if the current visitor is a used car buyer (not the car owner), their role type is "third-party buyer." According to the identity tag mapping table, the data tags they can access include "number of traffic violations," "number of accidents," "whether it is a major accident," and "annual inspection status," but they cannot access highly sensitive tags such as "description of major accidents" and "compensation details." The system filters the raw data accordingly, forming a restricted data subset.

[0046] Step S40: Based on the data range and the vehicle history data, generate and return a vehicle information view that matches the permissions of the current visitor.

[0047] After obtaining authorized access, the system first performs anonymization processing on sensitive fields (e.g., replacing mobile phone numbers with "123****5678" and blurring precise addresses to "a certain city and a certain district"). Then, it selects the corresponding front-end view template based on the current visitor's role type and business scenario (e.g., car insurance quotes, used car viewing, loan risk control). The front-end view template defines the display order of data items, visualization format (e.g., timeline, charts, cards), interactive controls (e.g., "View Details" and "Export Report"), and explanatory text (e.g., "This accident has resulted in an increase in insurance premiums of approximately 12%").

[0048] As an example, when the visitor is an insurance company underwriter, the system returns a structured report containing complete claims details, repair content ratings, and historical risk scores, along with an explanation of the pricing basis; while when the visitor is an ordinary car owner, key events are displayed in a concise timeline format, with positive prompts such as "Your vehicle has had no major accidents in the past 3 years" highlighted.

[0049] As a feasible implementation method, when generating the vehicle information view, the system extracts risk feature data from the vehicle's historical data according to the authorized access scope. This risk feature data includes the number of accidents, accident liability type, cumulative compensation amount, repair item category, frequency of traffic violations, vehicle age, and transfer frequency. Based on the current visitor's role type and the current session's business scenario type, the system determines the corresponding risk interpretation rule set from a preset rule base. This risk interpretation rule set is stored in the form of a structured rule table or decision tree, used to define the natural language prompt templates and risk level mapping relationships corresponding to different risk feature combinations. The risk feature data is input into the rule engine, which performs matching calculations based on the risk interpretation rule set to generate corresponding risk interpretation content. This risk interpretation content includes an explanation of the risk's causes, the direction of its impact on premiums or valuations, the range of its impact, and suggested operational guidelines. The risk interpretation content is embedded as metadata into the preset display area of ​​the vehicle information view and returned to the client for rendering along with the anonymized target data items.

[0050] The rule engine is a configurable logical processing unit deployed on the server side, supporting hot updates of rule tables without restarting the service. Based on the current visitor's role type, business scenario type, and extracted risk feature data, the rule engine performs condition matching on a preset risk interpretation rule set. Each rule defines the triggering conditions (such as "accident count ≥ 2 and visitor role is a used car buyer") and the corresponding actions, including selecting a natural language prompt template, calculating derived indicators (such as premium impact or risk level), and filling the calculation results and original risk feature data into placeholders in the corresponding prompt template (such as {accident count}, {impact magnitude}), thereby forming a complete natural language text, which is used as the risk interpretation content.

[0051] In this implementation, by dynamically generating encrypted tokens during the auto insurance pricing process and combining data tagging, identity-driven access control, and view customization mechanisms, on-demand, permission-based, and scenario-based secure disclosure of vehicle historical information is achieved. This solution effectively addresses the issues of pricing distortion, trust deficiency, and decision-making bias caused by fragmented and opaque information in auto insurance and used car transactions. It not only protects the privacy rights of car owners but also provides reliable data support for insurance companies' accurate underwriting and consumers' rational assessment, significantly improving industry service efficiency and user experience.

[0052] Based on the above embodiments of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 In the vehicle information query method, step S10 includes steps S110 to S150: Step S110: Obtain the identification information of the target vehicle and the session identifier of the current session.

[0053] Upon receiving a car insurance quote request, the system first parses the VIN or license plate number from the request parameters and verifies its validity using the vehicle registration database. Simultaneously, it extracts the established session identifier from the request header or authentication context. If no session has been established, the session management module creates and returns a new session ID immediately. This session identifier is used throughout the entire quote and information query process, serving as a crucial basis for subsequent token binding and permission verification.

[0054] Step S120: Based on a preset encryption algorithm, perform encryption operations on the identification information, the session identifier, and the current timestamp to generate a basic token value.

[0055] It should be noted that the current timestamp refers to the system time recorded by the server when performing this step, used to limit the valid window of the token. The preset encryption algorithm refers to the cryptographic functions pre-configured by the server, which may include message authentication code algorithms with keys (such as HMAC-SHA256), digital signature algorithms, or token generation mechanisms based on key derivation.

[0056] The system concatenates the target vehicle's VIN digest (such as a fixed-length value hashed using SHA-256), session identifier, and current timestamp in a predetermined order into the original input string. It then performs an HMAC operation on this string using the symmetric key held by the server, outputting fixed-length binary data. This binary data is subsequently encoded into a Base64 or hexadecimal string as the base token value. This base token value itself does not contain any plaintext sensitive information, but it is strongly bound; even a slight change in any parameter will result in a significantly different output.

[0057] As an example, if the VIN is CL123456, the session identifier is sess_a123, and the current timestamp is 2025 / xx / xx 14:00, which is converted to the Unix timestamp format 1703935200, the system first calculates the SHA-256 digest of the VIN, then concatenates it with sess_a123 and 1703935200, and after HMAC-SHA256 operation, obtains the basic token value T0. This T0 is only valid within this session and cannot be used to deduce the original VIN or session ID.

[0058] Step S130: Determine the initial access policy based on the business scenario type of the current session. The initial access policy includes the default allowed role type, the valid access duration, and whether multiple uses are allowed.

[0059] It should be noted that the business scenario type refers to the specific application context in which a user initiates a car insurance quote request, such as "individual car owner self-service quote," "insurance agent requesting quotes on behalf of customers," "vehicle appraisal on a used car platform," or "pre-loan risk control by financial institutions." Different scenarios have different requirements for the scope, timeliness, and reusability of data disclosure; therefore, the initial access policy needs to be dynamically configured to adapt to compliance and business needs.

[0060] As a feasible implementation method, the system records the business scenario type when a session is created and associates it with a preset access policy template library. For example, in the "individual car owner self-service quotation" scenario, the initial access policy can be set as follows: only the car owner is allowed to access, the validity period is 600 seconds, and multiple uses are prohibited; while in the "insurance agent inquiring about prices on behalf of customers" scenario, the initial access policy can be set as follows: authorized agents authorized by the car owner are allowed to access, the validity period is 1800 seconds, and multiple views are allowed, but re-authentication is required each time. This initial access policy is stored in the form of structured data (such as JSON objects).

[0061] Step S140: Encapsulate the basic token value and the initial access policy into a token payload, and digitally sign the token payload using the server's private key to generate the dynamic encrypted token. The dynamic encrypted token is stored in association with the session identifier.

[0062] It should be noted that the token payload refers to the data structure containing the core attributes of the token. In addition to the basic token value and initial access policy, it may also include metadata such as version number, issuance time, and target vehicle digest, which are used to support subsequent parsing and verification. The server private key refers to the asymmetric encryption private key securely stored by the server, used to digitally sign the token payload to ensure that the token content has not been tampered with and that its source is trustworthy.

[0063] Step S150: Embed the dynamic encryption token into the QR code, and embed the QR code into the car insurance quote to generate the car insurance quote.

[0064] In this embodiment, the car insurance quote can be generated and delivered in the form of an electronic document or a paper document. Besides QR codes, dynamic encryption tokens can also be embedded in the quote via embedded NFC tags or encrypted access links to adapt to different access scenarios and terminal capabilities. For example, in an electronic quote scenario, a car insurance quote page containing an encrypted link can be directly generated; visitors can click the link to initiate a request carrying the dynamic encryption token. In a paper quote scenario, an NFC adhesive label pre-written with the dynamic encryption token can be affixed to the surface of the quote; visitors can use an NFC-enabled mobile terminal to seamlessly read the dynamic encryption token and trigger access by simply tapping it against the NFC tag.

[0065] As an example, the generated dynamic encrypted token is embedded in the QR code on the car insurance quote page. After the user scans the QR code, the client submits the dynamic encrypted token as a request parameter to the vehicle history data interface. The server determines whether to grant data access by verifying the signature with the public key, parsing the strategy, and checking the validity period and usage status.

[0066] In this embodiment, after the dynamic encryption token is generated, the system binds it to the session identifier of the current session and stores it in the server's secure cache or database, for example, recording it with the session identifier as the key and the dynamic encryption token and its associated vehicle identifier information as the value. Therefore, when a subsequent vehicle information access request carrying the dynamic encryption token is received, although the dynamic encryption token does not disclose the plaintext content of the original VIN or session ID externally, and cannot be reverse-analyzed in the absence of the server key or storage context, the system can still accurately and efficiently locate the corresponding target vehicle and session context based on the dynamic encryption token, providing a reliable data anchor for subsequent vehicle historical data queries, permission verification, and view generation.

[0067] Based on the above embodiments of this application, in the third embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 In the vehicle information query method, step S20 includes steps S210 to S230: Step S210: After receiving the vehicle information access request, obtain the session identifier, timestamp, and target vehicle identifier information from the dynamic encryption token.

[0068] It should be noted that a vehicle information access request refers to an API call submitted by a user terminal (such as a request initiated after scanning a QR code with a mobile phone) to the server for obtaining historical vehicle data. This request carries a dynamically encrypted token generated during the car insurance quotation stage. In this embodiment, after receiving the vehicle information access request, the server can restore the context information it is bound to by parsing or querying the dynamically encrypted token.

[0069] As a feasible implementation method, if the dynamic encryption token adopts the JWT (JSON Web Token) format, the server first uses the public key to verify the legality of its digital signature, and then decodes the token payload to extract the target vehicle's digest identifier, session identifier, and issuance timestamp. If the dynamic encryption token is a randomly generated meaningless string (such as a state token), the server uses the dynamic encryption token as the key to query the corresponding metadata record in the cache (such as Redis). This record has been pre-associated with and stored complete information such as the session identifier, vehicle VIN, token generation time, and usage status.

[0070] As an example, when a user scans the QR code in the quotation, the client sends a dynamically encrypted token as a URL parameter or request header to the vehicle history data interface; after receiving the vehicle information access request, the server selects the parsing path according to the token type, and finally obtains the session identifier sess_a123, the timestamp 1703935200, and the target vehicle VIN CL123456 (or its hash digest).

[0071] Step S220: If the difference between the current time and the timestamp exceeds a preset valid duration, or if the dynamic encryption token is marked as used, then refuse to return the vehicle historical data.

[0072] It should be noted that the preset validity period refers to the maximum lifespan defined by the initial access policy during the dynamic encryption token generation phase, such as 300 seconds or 600 seconds. The specific value can be dynamically configured according to the security level of the business scenario. Marking a dynamic encryption token as "used" means that after the token is successfully used for data access for the first time, the system updates its status to non-reusable to prevent replay attacks.

[0073] After parsing the dynamic encrypted token, the server immediately reads the current system time and calculates the difference between it and the issuance timestamp in the token. If this difference is greater than the preset validity period, the token is deemed expired. Simultaneously, the server checks the token's usage status flag in the cache or database. If the usage status flag is "used," it is considered a duplicate request. If either condition is met, the rejection logic is triggered.

[0074] As an example, suppose the preset validity period is 600 seconds, the current system time is 1703936000 (i.e., 14:13:20 on December 30, 2025), and the token timestamp is 1703935200 (14:00:00), the time difference is 800 seconds, exceeding the 600-second threshold, the system will immediately generate a rejection response; or, if the time is still within the validity period, but the status field of the token in the cache is used=true, access will also be rejected, and security audit logs can be recorded for abnormal behavior analysis.

[0075] Step S230: Otherwise, based on the identification information of the target vehicle contained in the dynamic encryption token, query and return the corresponding historical data of the vehicle.

[0076] After confirming that the dynamic encryption token is valid and unused, the server immediately uses the target vehicle's identification information (such as VIN) as the primary key to invoke the unified data service layer. This service layer interfaces with multiple heterogeneous data sources, including insurance company claims systems (to obtain claims and underwriting records), traffic management platforms (to obtain traffic violations and accident reports), and third-party data platforms (such as obtaining maintenance and repair work orders through repair platforms, and obtaining transfer and pledge records through used car registration platforms). The raw vehicle historical data returned by each data source is standardized, then merged according to a preset data model, and each data item is given a corresponding data label (such as "highly sensitive," "only visible to the owner," "publicly available," etc.), ultimately forming a structured vehicle historical dataset.

[0077] As another feasible implementation, step S220 further includes steps S2210 to S2230: Step S2210: When it is detected that the difference between the current time and the timestamp exceeds the preset valid duration, a first rejection response message is generated.

[0078] The first rejection response message is used to clearly inform the client of the specific reason for the access failure and the subsequent action instructions, in order to improve the user experience and reduce invalid retries. The first rejection response message includes the rejection reason "token expired" and the suggested action "regenerate a token and resend the request".

[0079] After determining that the token has expired, the system uses a preset error template to generate a structured response, including an error code, error type, descriptive text, and operational suggestions. For example, the error code could be set to 01, the error type to TOKEN_EXPIRED, and the description could be that the dynamic encrypted token has expired, suggesting that the user return to the car insurance quote page to obtain the latest quote and scan the code again.

[0080] Step S2220: When it is detected that the dynamic encryption token is marked as used, a second rejection response message is generated.

[0081] The second rejection response message indicates that the token has been successfully used and is in a normal invalidation state. Its purpose is not only to prevent unauthorized replay attacks but also to avoid the repeated abuse of the same authorization, which is particularly important for risk control in scenarios involving third parties viewing vehicle information. This response message includes the rejection reason "token already used" and the suggested action "re-obtain a valid token".

[0082] Optionally, the system supports dynamically configuring the maximum allowed number of token accesses based on the initial access policy, rather than setting it to a fixed single use. Therefore, after receiving each vehicle information access request with a valid token, the server increments the actual access count and compares it to the upper limit; only if the access count does not exceed the upper limit is the vehicle history data allowed to be returned. If the upper limit has been reached, this step is triggered, generating a second rejection response.

[0083] The system maintains a usage status flag for each dynamic encrypted token in the cache or database, initially set to false; after the first successful access, this flag is set to true. When a request carrying the same token is received again and the flag is true, the system triggers this step, generating a rejection response containing semantics that the token has been used, and may attach a security prompt, such as that each quotation can only be viewed once to protect the car owner's privacy.

[0084] As an example, if a used car buyer has already viewed a vehicle's historical report by scanning a QR code, and their agent tries to access it again using the same QR code, the system will return a second rejection response message. This message may include error code 02, a message that the dynamic token is only allowed for one-time access and cannot be reused, and a suggestion to contact the vehicle owner to re-authorize and generate a new token.

[0085] Step S2230: Return the generated rejection response information to the client of the current visitor.

[0086] After generating the first or second rejection response, the server returns it to the client via the standard HTTP response channel. Upon receiving the rejection response, the client can automatically guide the user to perform appropriate actions based on the error code and suggestion fields, such as redirecting to a pricing page, prompting the user to contact the vehicle owner, or displaying a message indicating that the authorization has expired.

[0087] As an example, in a mobile app, when a user receives a token expiration response after scanning the code, the interface can automatically pop up a message saying "The link has expired. Please return to the previous page to refresh the quote" and provide a button to return to the quote. If a response indicating that the token has been used is received, it will display "This vehicle information has been viewed. To view it again, please request the vehicle owner to share it again."

[0088] This embodiment ensures that only legitimate, unused requests can trigger the vehicle history data query process by employing dual verification of the validity of dynamic encrypted tokens (timeliness + single use) and a secure data backtracking mechanism. This design not only effectively defends against common security threats such as token hijacking and replay attacks, but also achieves efficient aggregation and structured output of vehicle lifecycle information through standardized integration with multi-source data systems. This provides a data foundation for subsequent identity-based fine-grained access control and personalized view generation, thereby supporting the core business needs of accurate car insurance pricing and transparent used car transactions while ensuring privacy and security.

[0089] Based on the above embodiments of this application, in the fourth embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 Before step S30, the vehicle information query method further includes steps S301 to S305: Step S301: In response to the vehicle information access request, guide the current visitor to complete real-name authentication through a third-party identity authentication platform to obtain the current visitor's identity information.

[0090] It should be noted that third-party identity authentication platforms refer to trusted identity service providers recognized by the industry. The real-name authentication process typically involves verifying one or more of the following elements: name, ID number, facial recognition, and mobile phone number, to ensure the authenticity and traceability of the current visitor's identity.

[0091] When the server receives a vehicle information access request carrying a dynamic encrypted token but has not yet completed identity authentication, it returns a redirection instruction or an embedded authentication component, guiding the user to the selected third-party authentication platform to complete login and real-name verification. After successful authentication, the third-party platform sends the encrypted identity credentials back to the server. The server verifies the signature using a public key, decrypts the credentials, and extracts the structured identity information for subsequent comparison.

[0092] Step S302: Based on the vehicle registration information in the vehicle historical data, determine the identity information of the vehicle owner of the target vehicle.

[0093] It should be noted that vehicle registration information refers to the legal owner information recorded by the traffic management platform in vehicle registration, transfer, and change of ownership, and usually includes fields such as the owner's name and registration date.

[0094] When acquiring historical vehicle data, the system simultaneously extracts the latest vehicle registration records (such as owner information after the most recent transfer). If multiple records exist, the latest valid record prevails. For company vehicles, the owner's identity information includes the company name and unified social credit code, along with the legal representative's information for subsequent company authorization verification.

[0095] Step S303: Compare the identity information of the current visitor with the identity information of the vehicle owner.

[0096] The system first standardizes the names and ID numbers of both parties (e.g., removing spaces and unifying capitalization), and then performs a precise match; if company vehicles are involved, the system compares the company name with the unified social credit code.

[0097] Step S304: If the comparison results are consistent, then directly execute the step of determining the data range that the current visitor is authorized to access based on the current visitor's identity information and the data tags attached to each data item in the vehicle's historical data.

[0098] Understandably, if the current visitor is the registered owner of the target vehicle, they can access all data items matching their role (such as complete claim details, repair lists, etc.) according to a preset policy without additional authorization. In this case, the system can skip the third-party authorization process and directly enter the permission filtering stage based on data tags, improving user experience and system efficiency.

[0099] Step S305: If the comparison results are inconsistent, the current visitor is determined to be a third-party visitor, and the authorization verification process is triggered.

[0100] It should be noted that third-party visitors refer to entities that are not the registered owners of the vehicle but have a legitimate business need to view the vehicle's historical information, such as used car buyers, insurance agents, financial institution risk control personnel, or maintenance consultants. For such users, authorization from the vehicle owner is required to obtain limited data access permissions.

[0101] The authorization verification process includes: pushing an authorization request notification to the vehicle owner's linked mobile phone number or authenticated app. The notification includes the third-party visitor's user identifier (such as a de-identified nickname or organization name), the business scenario type of the current session (such as "used car viewing" or "insurance quote"), a summary of the requested data scope, and the validity period. After the vehicle owner confirms the authorization by clicking the "Agree" button, the system generates a temporary authorization credential and binds it to the current session and a dynamic encryption token, allowing the third party to access specified data under limited conditions.

[0102] This embodiment introduces an authorization verification mechanism based on vehicle owner confirmation into the data access process, ensuring that the disclosure of vehicle historical data is contingent upon the owner's explicit consent. Upon receiving a third-party request to access vehicle information, the system proactively sends an authorization notification to the vehicle owner, including the access party's identity and the business scenario. Only after confirmation is received is a temporary authorization credential generated, which is then used to control the actual accessible content based on role type and data tags. This mechanism supports time limits and status management for authorization operations, and authorization records are traceable. Thus, while meeting the legality requirements of personal information processing, it provides a controllable technical implementation path for necessary cross-entity data sharing in scenarios such as insurance, used car transactions, and financial services.

[0103] As one possible implementation, step S305 includes steps S3051 to S3053: Step S3051: Send an authorization request notification to the vehicle owner. The authorization request notification includes the user identifier of the third-party visitor and the business scenario type of the current session.

[0104] It should be noted that the authorization request notification is a system-pushed message to the vehicle owner to obtain their explicit consent. Its content must ensure transparency while avoiding the disclosure of excessive sensitive information. Specifically, the user identifier of the third-party visitor is usually anonymized, for example, displayed as "Zhang* (123****5678)" or "consultant of a used car platform," rather than the full name and mobile phone number. The business scenario type clearly states the purpose of the visit, such as "car insurance renewal quote," "used car transaction assessment," or "financial loan risk control," so that the car owner can make a reasonable judgment based on the context.

[0105] As a feasible implementation method, authorization request notifications can be pushed through various channels, including but not limited to the WeChat service account linked to the vehicle owner, SMS, the official app message center of the insurance company, or the associated account of the traffic management platform. The notification is presented in the form of a structured card, containing "Agree" and "Decline" operation buttons, and a default timeout period (e.g., 30 seconds). If no response is received within the timeout period, it is automatically considered a denial.

[0106] Step S3052: In response to the authorization confirmation operation initiated by the vehicle owner through the authentication terminal, generate the temporary authorization credential and return the temporary authorization credential to the current session of the third-party visitor.

[0107] It should be noted that a temporary authorization credential is a short-term valid proof of authorization. Its lifecycle is independent of the dynamic encryption token, but it is bound to the current session. This credential contains metadata such as the authorizing person's (vehicle owner's) identity digest, the authorized person's (third party's) identifier, the scope of authorized data, the business scenario, and the expiration time.

[0108] When the vehicle owner clicks "Agree" on their authentication terminal, the front end calls the authorization confirmation interface, carrying the session ID and operation signature. After verifying that the operation comes from the legitimate vehicle owner, the server generates a corresponding temporary authorization credential based on the default authorization policy for this business scenario (e.g., "used car buyers can view accidents and violations from the past five years") and writes it into the context state of the current session. Simultaneously, the system records authorization logs, including authorization time, operation IP, and device fingerprint, for auditing and traceability.

[0109] Step S3053: After obtaining the temporary authorization credential, execute the step of determining the data range authorized for access by the current visitor based on the current visitor's identity information and the data tags attached to each data item in the vehicle's historical data.

[0110] After the temporary authorization credential takes effect, the system updates the current visitor's role type to "Authorized Third Party" and, in conjunction with the authorization scope specified in the credential and the preset identity tag mapping table, determines the final set of accessible data tags. For example, even if the tag mapping table allows "third-party buyers" to view "repair amount," if the car owner did not select this field during authorization (or the business scenario strategy does not include it), it will still be filtered.

[0111] Optionally, car owners can simply confirm their agreement to the authorization request without manually selecting fields during authorization. In this mode, the system determines the role type of the third-party visitor (such as "used car buyer," "insurance agent," or "financial institution risk controller") based on the business scenario of the current session, and automatically matches the set of data tags allowed for that role type as the default scope of this authorization, using a pre-set identity tag mapping table. This identity tag mapping table is pre-configured and made public by the platform. For example, in the "used car viewing" scenario, the data tags corresponding to the role "third-party buyer" include "number of accidents," "traffic violation records," and "whether it was a major accident," but do not include highly sensitive fields such as "specific compensation amount" or "reporter's contact information." This method is suitable for ordinary users who prioritize ease of operation, significantly reducing the cognitive burden of authorization while ensuring that data disclosure strictly adheres to the principle of minimum necessity and industry compliance requirements.

[0112] In this embodiment, the temporary authorization credential not only serves as a switch to enable permissions, but also as a supplementary constraint for data tag filtering, allowing vehicle owners to further refine permissions when authorizing (such as supporting the selection of specific fields), while the system can achieve refined disclosure at the current stage through scenario-based default strategies.

[0113] Based on the above embodiments of this application, in the fifth embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 5 In the vehicle information query method, step S40 includes steps S410 to S430: Step S410: Extract the target data item from the vehicle historical data according to the data range.

[0114] It should be noted that the data range refers to the set of data tags that the current visitor is authorized to access. Based on this data range, the system filters the complete historical vehicle data that has been acquired, retaining only data items that match the tags as target data items.

[0115] Step S420: Desensitize the target data item, the desensitization process includes partially hiding or replacing sensitive information according to preset rules.

[0116] It should be noted that de-identification refers to the process of modifying content that may reveal personal privacy or commercially sensitive information without changing the meaning of the data in order to meet the requirements of data minimization and privacy protection.

[0117] Preset rules can be dynamically configured based on data type, role permissions, and regulatory requirements. Common de-identification methods include masking (e.g., mobile phone number 138****5678), generalization (e.g., replacing the exact address with the administrative division), hash perturbation (e.g., truncating the prefix after irreversibly hashing the license plate number), and numerical range (e.g., displaying the compensation amount as "10,000 to 30,000 yuan").

[0118] As an example, for fields marked as "highly sensitive - personal identifier" (such as vehicle owner's name), the name desensitization rule "Zhang*" is used; for fields marked as "medium sensitive - contact information" (such as phone number), the middle four-digit asterisk mask is used; and for fields marked as "lowly sensitive - statistical" (such as annual inspection number), no desensitization is required and the data is output directly.

[0119] Step S430: Organize and arrange the de-identified target data items according to a preset view template, which is preset according to different business scenario types and role types.

[0120] It should be noted that a view template is a structured definition of front-end display logic, used to control the presentation order of data items, grouping methods, visualization formats (such as timelines, tables, cards, charts), and auxiliary explanatory text.

[0121] Different roles have different focuses when it comes to information. Car owners focus on complete vehicle history data and pricing basis, used car buyers focus on accident and repair risks, and insurance company underwriters need a detailed claims process. Therefore, the system pre-sets corresponding templates for each combination of "business scenario + role type".

[0122] In this embodiment, the view template is stored in the template management service as a configuration file, containing field mapping rules, layout instructions, interactive controls (such as "Expand Details" and "Export PDF"), and explanatory text (such as "No major accidents in the past 3 years, expected premium reduction of 5%)". After determining the current visitor's role type and business scenario type, the system loads the corresponding template and fills the anonymized data items into the corresponding positions according to the template instructions, generating a renderable intermediate representation.

[0123] As an example, in the scenario of renewing car insurance and the current visitor being the car owner, the view template is displayed from top to bottom in the form of a timeline: latest policy → claims records for the past three years → traffic violation summary → maintenance log, with "Your vehicle risk rating: low" highlighted at the top; while in the scenario of used car appraisal and the current visitor being a third-party buyer, it starts with a risk summary card, listing "Major accident: No", "Total number of claims: 1", "Last repair: 2023", and hiding the specific amount and institution name.

[0124] Step S440: Encapsulate the organized target data items into the vehicle information view, and return the vehicle information view to the current visitor's client for display.

[0125] In this embodiment, the vehicle information view is encapsulated in a standard data format (such as JSON or HTML fragments), containing metadata (such as view version and generation time), various data items, and front-end rendering instructions. The server returns the vehicle information view to the client via a RESTful API or WebSocket channel. The client parses the view and calls its local UI component library for rendering, ensuring cross-platform consistency.

[0126] This embodiment achieves accurate, compliant, and user-friendly presentation of vehicle historical information through data extraction based on authorized access scope, hierarchical de-identification processing, and scenario-based view assembly. This mechanism ensures that visitors with different identities only see the content they are entitled to and necessary to know. Simultaneously, by using de-identification and templated display, it balances privacy protection with information usability, effectively supporting core business needs such as transparent pricing for auto insurance and rational decision-making in the used car market, while adhering to the principles of minimum necessity and purpose limitation in personal information processing.

[0127] This application provides a vehicle information query device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the vehicle information query method in the above embodiment 1.

[0128] The following is for reference. Figure 6The diagram illustrates a structural schematic of a vehicle information query device suitable for implementing embodiments of this application. The vehicle information query device in this application may include various hardware and software components for implementing vehicle information query methods. Figure 6 The vehicle information query device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0129] like Figure 6 As shown, the vehicle information query device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the vehicle information query device. The processing unit 1001, the ROM 1002, and the RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. The communication device 1009 allows the vehicle information query device to communicate wirelessly or wiredly with other devices to exchange data. Although the figures show vehicle information query devices with various systems, it should be understood that implementing or having all of the systems shown is not required. More or fewer systems may be implemented alternatively.

[0130] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0131] The vehicle information query device provided in this application, employing the vehicle information query method described in the above embodiments, can solve the technical problem that insurance companies and consumers cannot accurately control vehicle risks and pricing due to the fragmentation of historical vehicle data and information asymmetry. Compared with the prior art, the beneficial effects of the vehicle information query device provided in this application are the same as those of the vehicle information query method provided in the above embodiments, and other technical features of this vehicle information query device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0132] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0133] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0134] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the vehicle information query method in the above embodiments.

[0135] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0136] The aforementioned computer-readable storage medium may be included in the vehicle information query device; or it may exist independently and not be installed in the vehicle information query device.

[0137] The aforementioned computer-readable storage medium carries one or more programs that, when executed by a vehicle information query device, cause the vehicle information query device to: in response to a vehicle insurance quote request for a target vehicle, generate a dynamic encryption token associated with the current session and a corresponding vehicle insurance quote; wherein the dynamic encryption token is embedded in a QR code, which is a component of the vehicle insurance quote, allowing a visitor to initiate a vehicle information access request carrying the dynamic encryption token by scanning the QR code; in response to the vehicle information access request, obtain vehicle historical data related to the target vehicle, the vehicle historical data including vehicle insurance underwriting records, insurance claim records, traffic violation information, maintenance records, driving behavior assessments, vehicle registration changes, and pledge / seizure status, each data item in the vehicle historical data being attached with a data tag; determine the data range authorized for access by the current visitor based on the current visitor's identity information and the data tags attached to each data item in the vehicle historical data; and generate and return a vehicle information view matching the current visitor's permissions based on the data range and the vehicle historical data.

[0138] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

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

[0140] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0141] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described vehicle information query method. This solves the technical problem that insurance companies and consumers cannot accurately control vehicle risk and pricing due to the dispersion of historical vehicle data and information asymmetry. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the vehicle information query method provided in the above embodiments, and will not be elaborated upon here.

[0142] This application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the vehicle information query method described above.

[0143] The computer program product provided in this application can solve the technical problem that insurance companies and consumers cannot accurately control vehicle risks and pricing due to the fragmentation of vehicle historical data and information asymmetry. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the vehicle information query method provided in the above embodiments, and will not be repeated here.

[0144] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

[0145] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0146] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method.

[0147] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for querying vehicle information, characterized in that, The vehicle information query method includes: In response to a car insurance quote request for a target vehicle, a dynamic encryption token and a corresponding car insurance quote are generated and associated with the current session; wherein, the dynamic encryption token is embedded in a QR code, which is a component of the car insurance quote, so that visitors can initiate a vehicle information access request carrying the dynamic encryption token by scanning the QR code. In response to the vehicle information access request, historical vehicle data related to the target vehicle is obtained. The historical vehicle data includes vehicle insurance underwriting records, insurance claim records, traffic violation information, maintenance records, driving behavior assessments, vehicle registration changes and pledge / seizure status. Each data item in the historical vehicle data is attached with a data tag. Based on the current visitor's identity information and the data tags attached to each data item in the vehicle's historical data, the scope of data that the current visitor is authorized to access is determined; Based on the data range and the vehicle history data, a vehicle information view that matches the current visitor's permissions is generated and returned.

2. The vehicle information query method as described in claim 1, characterized in that, The step of determining the data range that the current visitor is authorized to access based on the current visitor's identity information and the data tags attached to each data item in the vehicle's historical data includes: Based on the current visitor's identity information, obtain the current visitor's role type; Based on the role type, query the preset identity tag mapping table to obtain the target data tag set corresponding to the current visitor; Match the data tags of each data item in the vehicle history data with the target data tag set; The data items that are successfully matched will be included in the data range that the current visitor is authorized to access.

3. The vehicle information query method as described in claim 1, characterized in that, The step of obtaining historical vehicle data related to the target vehicle in response to the vehicle information access request includes: Upon receiving the vehicle information access request, the session identifier, timestamp, and target vehicle identification information are obtained from the dynamic encryption token. If the difference between the current time and the timestamp exceeds a preset valid duration, or if the dynamic encryption token is marked as used, then the vehicle historical data will not be returned. Otherwise, based on the identification information of the target vehicle contained in the dynamic encryption token, the corresponding historical data of the vehicle is queried and returned.

4. The vehicle information query method as described in claim 3, characterized in that, The step of refusing to return the vehicle history data if the difference between the current time and the timestamp exceeds a preset valid duration, or if the dynamic encryption token is marked as used, includes: When the difference between the current time and the timestamp exceeds the preset valid duration, a first rejection response message is generated; When it is detected that the dynamic encryption token has been marked as used, a second rejection response message is generated; The generated rejection response information is returned to the client of the current visitor.

5. The vehicle information query method as described in claim 1, characterized in that, Before the step of determining the data range that the current visitor is authorized to access based on the current visitor's identity information and the data tags attached to each data item in the vehicle's historical data, the vehicle information query method further includes: In response to the vehicle information access request, the current visitor is guided to complete real-name authentication through a third-party identity authentication platform in order to obtain the current visitor's identity information; Based on the vehicle registration information in the vehicle historical data, the identity information of the vehicle owner of the target vehicle is determined; The identity information of the current visitor is compared with the identity information of the vehicle owner; If the comparison results are consistent, then the step of determining the data range that the current visitor is authorized to access based on the current visitor's identity information and the data tags attached to each data item in the vehicle's historical data is directly executed; If the comparison results are inconsistent, the current visitor is determined to be a third-party visitor, and the authorization verification process is triggered.

6. The vehicle information query method as described in claim 5, characterized in that, The steps to determine that the current visitor is a third-party visitor and trigger the authorization verification process if the comparison results are inconsistent include: Send an authorization request notification to the vehicle owner, the authorization request notification including the user identifier of the third-party visitor and the business scenario type of the current session; In response to the authorization confirmation operation initiated by the vehicle owner through the authentication terminal, a temporary authorization credential is generated and returned to the current session of the third-party visitor; After obtaining the temporary authorization credential, the step of determining the data range that the current visitor is authorized to access is executed based on the current visitor's identity information and the data tags attached to each data item in the vehicle's historical data.

7. The vehicle information query method as described in claim 1, characterized in that, The step of generating a dynamic encrypted token and a corresponding car insurance quote associated with the current session in response to a car insurance quote request for the target vehicle includes: Obtain the identification information of the target vehicle and the session identifier of the current session; Based on a preset encryption algorithm, the identification information, the session identifier, and the current timestamp are encrypted to generate a basic token value; Based on the business scenario type of the current session, an initial access policy is determined. The initial access policy includes the default allowed role types, the valid access duration, and whether multiple uses are allowed. The basic token value and the initial access policy are encapsulated into a token payload, and the token payload is digitally signed using the server's private key to generate the dynamic encrypted token. The dynamic encrypted token is stored in association with the session identifier. The dynamic encryption token is embedded into the QR code, and the QR code is embedded into the car insurance quote to generate the car insurance quote.

8. The vehicle information query method as described in claim 1, characterized in that, The step of generating and returning a vehicle information view that matches the current visitor's permissions based on the data range and the vehicle history data includes: Based on the data range, target data items are extracted from the vehicle historical data; The target data items are desensitized, and the desensitization process includes partially hiding or replacing sensitive information according to preset rules; The de-identified target data items are organized and arranged according to a preset view template, which is pre-set according to different business scenario types and role types; The organized target data items are encapsulated into the vehicle information view, and the vehicle information view is returned to the current visitor's client for display.

9. A vehicle information query device, characterized in that, The vehicle information query device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the vehicle information query method as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the vehicle information query method as described in any one of claims 1 to 8.

Images