Diagnostic device-based account management method and related apparatus

Abstract

Embodiments of the present application disclose a diagnosis device-based account management method and related apparatus, the method comprising: obtaining an account allocation request of a user; allocating a target account associated with a diagnosis device of the user to the user according to the account allocation request; obtaining a function request initiated by the user based on the target account; and performing an operation corresponding to the function request according to a permission check result after performing permission check on the function request. The embodiments of the present application can improve the task processing efficiency of the function request.

Description

Technical Field

[0001] This invention relates to the field of account management technology, and in particular to an account management method and related apparatus based on diagnostic equipment. Background Technology

[0002] Currently, the serial numbers, account passwords, and other related information for all series of diagnostic equipment are centrally managed by the operations management system. Due to the increasing number of end-users of diagnostic equipment, the number of after-sales issues requiring timely responses, such as password resets and retrievals, is also increasing.

[0003] For individual end users, the professional after-sales customer service center provides unified access and handles relevant after-sales tasks in the background. However, for enterprise end users of car manufacturers, the after-sales service personnel of the car manufacturer usually connect with the terminal sales and service stores of the car manufacturer or their third-party customers, and then the after-sales service personnel of the car manufacturer connect with the key customer after-sales service manager. The key customer after-sales service manager queries and processes the background information based on the after-sales issues.

[0004] However, for car manufacturers' after-sales service personnel, the above procedures are cumbersome, increasing communication costs and resulting in long processing cycles and low efficiency for after-sales tasks. Summary of the Invention

[0005] To address the aforementioned issues, embodiments of the present invention provide an account management method and related apparatus based on diagnostic equipment, which can improve the task processing efficiency of function requests when responding to user function requests.

[0006] In a first aspect, embodiments of the present invention provide an account management method based on diagnostic devices, applied to a server, the method comprising: Obtain the user's account allocation request; Based on the account allocation request, assign a target account associated with the user's diagnostic device to the user; Obtain the function request initiated by the user based on the target account; After verifying the permissions of the function request, the operation corresponding to the function request is executed according to the permission verification result.

[0007] Secondly, embodiments of the present invention provide an account management device based on diagnostic equipment, the device comprising an acquisition unit and a processing unit; The acquisition unit is used to acquire the user's account allocation request; The processing unit is configured to assign a target account associated with the user's diagnostic device to the user according to the account allocation request; Obtain the function request initiated by the user based on the target account; After verifying the permissions of the function request, the operation corresponding to the function request is executed according to the permission verification result.

[0008] Thirdly, embodiments of the present invention provide an electronic device, the electronic device including a processor and a memory, the processor being connected to the memory, the memory being used to store a computer program, and the processor being used to execute the computer program stored in the memory, so that the electronic device performs the method as described in the first aspect.

[0009] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program that is executed by a processor to implement the method described in the first aspect.

[0010] Fifthly, embodiments of this application provide a computer program product, the computer program product including a non-transitory computer-readable storage medium storing a computer program, the computer being operable to perform the method as described in the first aspect.

[0011] Implementing the embodiments of this application has the following beneficial effects: In this embodiment, the server first obtains the user's account allocation request. Then, based on the account allocation request, it allocates a target account associated with the user's diagnostic device to the user. Next, it obtains the function request initiated by the user based on the target account. After verifying the permissions of the function request, it executes the operation corresponding to the function request based on the permission verification result. Thus, by directly allocating a target account associated with the user's diagnostic device to the user, the user can initiate function requests through the target account and obtain the corresponding execution results, reducing the intermediate communication links with key customer after-sales service managers and improving the task processing efficiency of function requests. Attached Figure Description

[0012] To more clearly illustrate the technical solutions in the embodiments of the present invention or the background art, the drawings used in the embodiments of the present invention or the background art will be described below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0013] Figure 1 This is a schematic diagram of the architecture of an account management system based on diagnostic equipment provided in an embodiment of this application; Figure 2 This is a flowchart illustrating an account management method based on diagnostic equipment provided in an embodiment of this application; Figure 3This is a logical architecture diagram of a target account executable functional module provided in an embodiment of this application; Figure 4 This is a schematic diagram of a security audit process for operation log recording provided in an embodiment of this application; Figure 5 This is a logical block diagram of an access control center associated with account allocation and access verification provided in an embodiment of this application; Figure 6 This application provides a flowchart of an account management and permission verification process based on policy rules and product configuration. Figure 7 This is a schematic diagram of the structure of an account management device based on diagnostic equipment provided in an embodiment of this application; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0014] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0015] The terms "first," "second," "third," and "fourth," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or modules is not limited to the listed steps or modules, but may optionally include steps or modules not listed, or may optionally include other steps or modules inherent to these processes, methods, products, or devices.

[0016] In this document, the term "embodiment" means that a particular feature, result, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0017] The following describes the relevant content, concepts, technical issues, technical solutions, and beneficial effects involved in the embodiments of this application.

[0018] First, let me explain some of the technical terms used in this application: B2B (Business to Business) customers refer to businesses or organizations that purchase products or services to meet their operational, production, or other business needs. Unlike C-end customers (Consumers), B2B customer purchasing decisions typically involve multiple roles and complex decision-making processes.

[0019] Currently, due to security risks and the principle of integrated management, the serial numbers and corresponding account passwords of various diagnostic equipment are centrally managed by the operations management system. With the increasing number of end users and frequent staff turnover, coupled with the mandatory password reset policies implemented by major automakers in accordance with information security regulations, the number of after-sales issues requiring timely responses, such as password retrieval, is gradually increasing 24 / 7, creating significant after-sales pressure and escalating customer complaint risks. Given existing stable key clients, investing in building a new user management backend is clearly impractical. Therefore, how to reasonably open up some functions of the existing user management backend to clients while ensuring data security and preventing information leakage has become a major problem that urgently needs to be solved.

[0020] When dealing with after-sales issues reported by individual users of diagnostic instruments, the relevant matters are generally handled by a professional after-sales customer service center in the background. However, when dealing with some B-end customers of car manufacturers, the more common scenario is that the car manufacturer's after-sales service personnel directly connect with their terminal sales and service stores or third-party customers, and then connect with the key customer's after-sales service manager to query and process the background information.

[0021] The methods mentioned above involve cumbersome processes. After-sales service personnel of B-end customers do not have direct authority to handle issues such as account management of their subordinate sales and service stores or third parties. They must go through key customer service managers, which increases communication costs, may lead to longer problem-solving cycles, affect the normal operation of terminal stores and user experience, and also puts enormous pressure on the operation and maintenance costs and service response of the after-sales service side.

[0022] This solution addresses the above issues by leveraging the user management backend functionality to ensure that authorized access to certain end-user management functions is reasonably granted to car manufacturer B-end clients within a secure and controllable scope. The core of this solution involves assigning dedicated administrator accounts, allowing them to query relevant information and modify passwords / activation codes a limited number of times; and implementing data isolation between different clients through product configuration binding to prevent unauthorized access. To ensure security, the system will record all operation logs for auditing and employ measures such as communication encryption and operation limit restrictions.

[0023] See Figure 1 , Figure 1This is a schematic diagram of the architecture of an account management system based on a diagnostic device, provided in an embodiment of this application. The account management system based on a diagnostic device includes a server and a diagnostic device, which exchange information through data interaction. The server is used for account allocation, permission verification, and function request processing; the diagnostic device is used by after-sales service personnel of B-end customers, and it interacts with the server to complete operations such as account association and function execution.

[0024] See Figure 2 , Figure 2 This is a flowchart illustrating an account management method based on diagnostic equipment provided in this application embodiment. The account management method based on diagnostic equipment provided in this application embodiment, applied to a server, includes, but is not limited to, the following steps: Step S101: Obtain the user's account allocation request; Step S102: Based on the account allocation request, assign a target account associated with the user's diagnostic device to the user; Step S103: Obtain the function request initiated by the user based on the target account; Step S104: After verifying the permissions of the function request, execute the operation corresponding to the function request based on the permission verification result.

[0025] In one possible embodiment, an account allocation request from a user is obtained. The user is a B-end customer of the vehicle manufacturer, specifically including the vehicle manufacturer's after-sales service management department and related authorized after-sales agencies. The account allocation request may include basic customer information, information related to the diagnostic equipment to be managed, specific functional requirements, and user scale. The information related to the diagnostic equipment to be managed may include equipment series, product configuration range, associated serial number range, etc.; specific functional requirements may include permission requests such as information query and password modification; user scale may include the number of sales and service stores, the number of enterprise end users, etc.

[0026] Specifically, customers can submit electronic requests through the dedicated administrator platform web page or client of the diagnostic equipment. The platform will transmit the request data to the server in real time through a preset interface. Alternatively, they can send request files via encrypted email. The server is equipped with a dedicated email receiving module to decrypt the email and extract the request information. For car manufacturers that have already implemented an Application Programming Interface (API) with the system, they can also initiate requests directly through their own business systems to achieve automatic data synchronization.

[0027] After receiving a request, the server first verifies the integrity of the request data, checking whether it contains necessary fields such as basic customer information, device information, and functional requirements. If any information is missing, the server will send a supplementary notification to the customer via platform messages, encrypted emails, or other means. The server also verifies the legitimacy of the request source by checking whether the Internet Protocol Address (IP) address that initiated the request is in the customer's pre-set trusted IP list and whether the request file has a compliant digital signature, thus eliminating malicious or illegal requests. Finally, the server verifies the validity of the customer's qualifications to ensure that account allocation requests are only responded to by compliant customers.

[0028] In one possible embodiment, a target account associated with the user's diagnostic device is assigned to the user based on an account allocation request. The target account is a dedicated administrator account generated by the server for the B-end customer, which is associated with the diagnostic device used by the B-end customer for after-sales service. The B-end after-sales personnel can log in to the diagnostic device used for after-sales service using the target account and initiate function requests to the server. The association is achieved by binding the product configuration information of the diagnostic device with the account parameters.

[0029] Specifically, firstly, the account allocation request is parsed to extract information such as customer type, scope of managed devices, functional requirement level, and user scale. Customer types are categorized based on cooperation scale and level into core OEM customers, regular OEM customers, and special cooperation customers, with different account permission configurations for each type. Secondly, based on the parsing results, core parameters for the target account are configured. These parameters include functional permission scope, operation limit, and login control rules. The functional permission scope is matched to the correlation between the customer request and the diagnostic device. For example, core OEM customers can be configured with full management functions such as information query, password modification, and activation code reset; regular OEM customers can be configured with basic query and password modification functions; and special cooperation customers can only be configured with information query functions within a specific scope. Operation limit settings are set for sensitive operations, such as password modification. The number of login attempts is limited to no more than 50 per day, and the number of activation code resets is limited to no more than 10 per day. This limit is positively correlated with the scale of end users managed by the customer to prevent account abuse. Login control rules include limits on the number of devices that can log in simultaneously and timeout logout times to ensure account security. Then, a target account entity is generated. The account name can adopt a standardized naming rule of customer abbreviation-product configuration identifier-serial number. The server sends the target account's account name, initial password, and login instructions to the customer's designated contact person via encrypted email or a platform-specific message channel. The customer contact person logs into the administrator platform to complete the initial login verification. After the system forces them to change the initial password, the target account is officially activated and takes effect. At the same time, the server stores data such as account information, associated device range, and permission parameters in the account management database and records logs such as account creation time, creator, and activation status.

[0030] During account allocation, the server also establishes an account association verification mechanism to ensure that the target account can only manage the diagnostic devices specified in the request. By matching the product configuration identifier in the account parameters with the product configuration information in the diagnostic device database, an access control boundary is formed. For example, a target account allocated to vehicle manufacturer A has its product configuration identifier bound to A-series diagnostic devices, and can only manage diagnostic devices under that configuration, achieving precise isolation from devices from other vehicle manufacturers.

[0031] In one possible embodiment, a function request initiated by a user based on a target account is obtained. This function request is a specific operation application initiated by the B-end customer administrator after logging into the administrator platform with the target account, targeting the diagnostic device account of a subordinate end user. Based on the actual business scenario of diagnostic device account management, function requests include information query requests and operation modification requests. Information query requests include querying basic information such as the configuration name corresponding to the diagnostic device's serial number, user account, configuration software version, download history, download restriction history, and software download expiration date. Operation modification requests include changing the login password of the end user account and resetting the registration activation code of the diagnostic device. This type of request is used to resolve after-sales issues such as forgotten passwords or expired activation codes.

[0032] Specifically, for users, after logging into the target account, the administrator selects the corresponding function module in the platform's operation interface, and enters the necessary request parameters as prompted. For information query requests, the diagnostic device serial number is required; for operation modification requests, in addition to the serial number, a new password / activation code, verification code, or other verification information can be entered as required. After confirming that everything is correct, the request is submitted. The platform encapsulates the request data into standardized data packets and transmits them to the server via an encrypted communication protocol, ensuring the security of data transmission.

[0033] Specifically, for the server, the request receiving module listens to data packets in the transmission channel in real time, decrypts and decapsulates the data packets, and extracts core information such as the target account identifier, function request type, request parameters, initiation time, and initiating terminal IP address from the request. Request preprocessing is then performed, including verifying the standardization of the request format and the matching of request parameters with the target account's associated device range. For example, it checks whether the product configuration corresponding to the serial number is within the account management scope. If preprocessing fails, the server will return a response indicating a format error or invalid parameters, and record a request failure log. If preprocessing passes, the request data is temporarily stored in the request processing queue, awaiting subsequent permission verification and execution.

[0034] In one possible implementation, after verifying the permissions of a function request, the operation corresponding to the function request is executed based on the permission verification result. Permission verification is a crucial step in ensuring account management security and preventing unauthorized operations. The server executes differentiated verification logic for different types of function requests to ensure clear permission boundaries.

[0035] For information query requests, permission verification is a product configuration matching verification. The server first queries the diagnostic device database based on the serial number in the request to obtain the first product configuration information corresponding to the device; it then queries the bound configuration information of the target account; and compares the two types of configuration information through the permission verification API interface. If the first product configuration information falls within the scope of the initial product configuration information, the verification passes; otherwise, the verification fails, and only publicly available basic information such as device serial number and device model is allowed to be queried, while access to sensitive information is restricted. After successful verification, the server extracts the information corresponding to the request from related data sources such as the device information database and download record database, organizes it into a standardized response format, and returns it to the administrator platform through an encrypted channel. At the same time, an operation log is recorded, including information such as the operator, operation time, operation object, operation type, and operation result.

[0036] For operation modification requests, permission verification includes dual verification. First, product configuration matching verification, with the same logic as information query requests, only proceeding to subsequent verification if the device product configuration is within the account management scope. Second, operation count threshold verification. The server queries the target account for the number of times this type of operation has been executed that day and compares it with a preset threshold. If the number of executions has not exceeded the threshold, the verification passes; otherwise, it fails, returning a response message that the operation count has reached its limit and requesting assistance from the after-sales manager, and logging the count exceeding the limit. After dual verification passes, the server executes the corresponding modification operation. When executing a password modification operation, the new password is irreversibly encrypted, and the password field for the corresponding serial number in the device account database is updated, overwriting the original encrypted password. When executing an activation code reset operation, a unique activation code is generated using a random algorithm, the corresponding field in the database is updated, and the old activation code and reset time are recorded. After the operation is completed, a success message is returned to the administrator platform.

[0037] If the permission verification fails, such as due to product configuration mismatch, exceeding the operation limit, or incorrect parameters, the server returns a verification failure message, including the reason for the failure and a solution. At the same time, a verification failure log is recorded, which includes request details, the reason for failure, and the information of the initiating terminal.

[0038] In this embodiment, precise account allocation, function request processing, and permission verification enable B-end customers to manage their diagnostic device accounts autonomously, reducing intermediate communication links, shortening after-sales problem handling cycles, and lowering after-sales maintenance pressure. At the same time, through product configuration binding, operation limit, encrypted transmission, and log auditing, data security and permission isolation are ensured, effectively preventing information leakage and unauthorized operation risks. A balance is achieved between centralized control and distributed autonomous management, taking into account both management efficiency and security stability.

[0039] Optionally, step S102, assigning a target account associated with the user's diagnostic device to the user based on the account allocation request, may include the following steps: Step S201: Determine the user type based on the account allocation request; Step S202: Determine the account parameters of the target account based on the user type; the account parameters are used to limit the function name, number of functions, maximum login time per session, and permission parameters for each function of the target account; Step S203: Assign the target account to the user based on the account parameters.

[0040] In one possible implementation, the user type is determined based on the account allocation request. The user type is a classification identifier based on the B-end customer's business scale, cooperation level, and functional complexity requirements. Specifically, it can be divided into three categories: Tier 1 automaker customers, Tier 2 automaker customers, and specialized cooperation customers. Tier 1 automaker customers can be large automakers with an annual diagnostic equipment purchase volume exceeding 5,000 units, more than 300 affiliated 4S stores and third-party customers, and a requirement to fully open query and modification functions. Tier 2 automaker customers can be medium-sized automakers with an annual diagnostic equipment purchase volume between 1,000 and 5,000 units, 100 to 300 affiliated service outlets, and a requirement to open basic query and some modification functions. Specialized cooperation customers can be small automakers or specialized cooperation enterprises that cooperate on specific diagnostic equipment series and have simple functional requirements.

[0041] First, the data in the account allocation request is extracted, including the customer's annual purchase volume, the number of subordinate service outlets, and the required function types and quantities. Then, the server's built-in user type determination rule base is invoked. This rule base is generated through machine learning algorithms trained on historical cooperative customer data and includes quantitative determination thresholds and standards for each user type, such as the complexity level of functional requirements. Finally, the extracted request data is compared and matched with the standards in the determination rule base to output the corresponding user type. For example, if a car manufacturer's request shows an annual diagnostic equipment purchase volume of 6,000 units, 450 subordinate 4S stores and third-party customers, and requests all functions such as query, password modification, and activation code reset, the server determines it to be a Tier 1 car manufacturer customer. If a customer's annual purchase volume is 2,000 units, with 150 subordinate service outlets, and only requests information query and password modification functions, it is determined to be a Tier 2 car manufacturer customer.

[0042] In one possible embodiment, account parameters for the target account are determined based on the user type. These parameters define the target account's function names, number of functions, maximum single login time, and permission parameters for each function. Account parameters are pre-configured information set by the server for the target account, enabling refined account management. The appropriateness of this configuration directly impacts the security and convenience of account use. Function names refer to the specific operation names that the target account can perform. Considering the actual business scenarios of diagnostic device account management, these include functions such as serial number lookup, configuration name lookup, user account lookup, configuration software lookup, download history lookup, download restriction history lookup, software download expiration lookup, password modification, and activation code / registration password reset. Additional functions, such as account cancellation requests and permission change requests, can be added through the server's function extension module based on industry development and customer needs. The number of functions refers to the total number of function names available to the target account. The number of functions varies depending on the user type to match their actual needs. The maximum single login time refers to the longest valid time the target account can remain inactive after logging into the administrator platform. Exceeding this time will automatically log the account out, preventing account theft or accidental operation. The permission parameters for each function are specific restrictions on the conditions under which each function can be used, including the scope of use of the function, such as only being able to operate diagnostic device accounts configured for specific products, and the maximum number of times it can be used within a preset time period.

[0043] Specifically, the permission parameters for each function include the maximum number of times each function can be used within a preset time period. The preset time period is set to a calendar day (24 hours) by default. B-end customers can apply to the super administrator to adjust it to a week (168 hours) or a month (720 hours) according to their own business needs. The maximum number of uses is a threshold determined based on a combination of user type, user scale, and function sensitivity, used to prevent data security risks caused by account abuse.

[0044] In one possible implementation, a target account is assigned to the user based on account parameters. The target account is a dedicated administrator account generated by the server for the B-end customer, consisting of a username and an initial password. The username can follow a naming convention of customer abbreviation + product configuration identifier + administrator serial number, which facilitates the server's quick identification of the customer and management scope of the account. The initial password is generated by the server using a random algorithm and contains uppercase letters, lowercase letters, numbers, and special symbols to ensure the security of the initial password.

[0045] First, the account generation module is invoked to generate an account name according to the aforementioned naming rules, and an initial password is generated using a random algorithm. The account name and initial password are then associated and bound with predetermined account parameters such as function name, number of functions, maximum single login time, and maximum number of uses for each function. Second, the associated account information is stored in the server's account management database, recording information such as account creation time, creator, client, and status (activated or inactive). Then, the target account's account name and initial password are sent to the designated contact person of the B-end client via encrypted email or the administrator platform's message notification module. Finally, the B-end client contact person logs into the administrator platform, enters the account name and initial password, completes the initial login verification, and the system forces them to change the initial password. The target account is then officially activated, and the account status is updated to activated.

[0046] To ensure the security of account allocation, the server also implements the following control measures during the allocation process: First, the generated initial password is irreversibly encrypted before storage to prevent password leakage; Second, the entire account allocation process is logged, including account generation time, sending time, recipient information, activation time, etc., for auditing by the super administrator; Third, if the B-end customer fails to activate the account within a preset time after receiving the account information, the server automatically freezes the account and notifies the super administrator to verify it. After verification, the activation information can be resent or a new target account can be generated.

[0047] For example, see Figure 3 , Figure 3 This is a logical architecture diagram of an executable functional module for a target account provided in an embodiment of this application. The target account may include the following specific functional modules: product serial number information query, password reset, activation code reset, and other functions.

[0048] Optionally, the permission parameters for each function include the maximum number of times each function can be used within a preset time period; step S202, determining the account parameters of the target account based on the user type, may include the following steps: Step S301: Determine the user's functional requirements and user scale based on the user type; Step S302: Determine the function name and number of functions based on the functional requirements; Step S303: Based on the user base, determine the maximum single login time and the maximum number of times each function can be used within a preset time period.

[0049] In one possible implementation, the functional requirements and user scale of a user are determined based on the user type. A mapping relationship exists between user type and functional requirements, stored in the server's functional configuration database. For example, a Tier 1 automaker customer might require 9 functional requirements; a Tier 2 automaker customer might require 7 information query functions and a password modification function, totaling 8; and a special cooperation customer might only require a portion of the information query functions. The user scale is determined by cross-validating the number of subordinate 4S stores and third-party customers in the account allocation request with the total number of diagnostic devices associated with that customer registered in the system, ensuring the accuracy of the user scale data. For example, if a Tier 2 automaker customer requests 150 subordinate service outlets, and the system registers 2200 associated diagnostic devices for that customer, then the final user scale is determined to be 150 service outlets and 2200 associated devices.

[0050] In one possible implementation, the function names and number of functions are determined based on functional requirements. The server queries the function configuration database to extract all function names corresponding to the user type; the number of functions is the total number of extracted function names. For example, a Tier 1 car manufacturer customer has 9 function names and 9 functions; a Tier 2 car manufacturer customer has 8 function names and 8 functions; a special cooperation customer applying only for serial number query and download history query functions has 2 function names and 2 functions. Simultaneously, the server supports personalized function configuration. If a Tier 2 car manufacturer customer needs to add an activation code reset function due to special business requirements, they can submit a special application. After approval by the super administrator, the function name is added to their account parameters, and the number of functions is adjusted accordingly.

[0051] In one possible implementation, the maximum login time per session and the maximum number of times each function can be used within a preset time period are determined based on the user base. Specifically, the larger the user base, the shorter the maximum login time per session, to reduce the security risks associated with prolonged account logins. For example, for Tier 1 car manufacturers with more than 300 service outlets or more than 5,000 associated devices, the maximum login time per session is set to 30 minutes; for Tier 2 car manufacturers with 100-300 service outlets or 1,000-5,000 associated devices, and some Tier 1 car manufacturers, the maximum login time per session is set to 60 minutes; for specialized cooperation clients and small Tier 2 car manufacturers with fewer than 100 service outlets or fewer than 1,000 associated devices, the maximum login time per session is set to 90 minutes. This correspondence can be adjusted by the super administrator in the policy rule base according to actual security management needs.

[0052] The maximum number of times each function can be used within a preset time period is determined based on the function's sensitivity and the user base. Information query functions are considered non-sensitive and can have a higher maximum usage limit; for example, 500 times per day for Tier 1 car manufacturers, 300 times per day for Tier 2 car manufacturers, and 100 times per day for special cooperation clients. Password modification functions are considered moderately sensitive and have a uniform maximum usage limit of 50 times per day, consistent with the system's security control standards. Activation code reset functions are considered highly sensitive and have a uniform maximum usage limit of 10 times per day to prevent malicious reset operations. If the user base exceeds the above-mentioned limits, such as a Tier 1 car manufacturer client having 10,000 associated devices, an application can be made to increase the maximum usage limit for the corresponding function. The server will review the application based on historical operation data, security rating, and other factors. Once approved, a personalized threshold will be configured individually in the policy rule base.

[0053] Optionally, step S104, after verifying the permissions of the function request, executing the operation corresponding to the function request based on the permission verification result, may include the following steps: Step S401: Parse the function request to obtain the sequence number and target operation type; Step S402: If the target operation type is the first operation type, execute the operation corresponding to the function request based on the sequence number; Step S403: If the target operation type is the second operation type, verify the number of requests made within a preset time period; Step S404: If the number of requests is less than the maximum number of uses, perform the operation corresponding to the function request based on the sequence number.

[0054] In one possible embodiment, after receiving a function request, the server first calls the request parsing module to parse the request data packet. The type identifier of the function request is identified; this identifier is a preset field in the request data packet, such as QUERY representing an information query request and MODIFY representing an operation modification request. Based on the type identifier, the target operation type is further subdivided. The first operation type corresponds to an information query request, including specific operations such as serial number query and configuration name query; the second operation type corresponds to an operation modification request, including specific operations such as password modification and activation code reset. Core identifier information is extracted from the request parameters. For information query requests, the core identifier information is the serial number, configuration name, or user account, with the serial number being the primary query identifier by default; for operation modification requests, the core identifier information is the serial number. The parsed serial number, target operation type, and other request parameters are organized into a standardized parsing result and stored in a temporary data cache for subsequent permission verification and operation execution.

[0055] For example, if a B-end customer administrator initiates a function request to query the user account and download history corresponding to the diagnostic device with serial number SN12345678, the server will parse the request and obtain the serial number SN12345678. The target operation type is the first operation type, which is serial number query and download history query. If the initiated function request is to change the password of the user account corresponding to the diagnostic device with serial number SN87654321, the server will parse the request and obtain the serial number SN87654321. The target operation type is the second operation type, which is password change.

[0056] During the parsing process, if the requested parameters are missing or the parameter format is incorrect, such as no serial number being entered or the serial number length not meeting the preset standard, the server generates a parameter error response to inform the user of the missing parameters or incorrect format requirements, and records the parsing failure log so that the user can correct it and re-initiate the request.

[0057] In one possible embodiment, the operation corresponding to the function request is performed based on the serial number. The server uses the serial number as an index to query the relevant associated information of the diagnostic device account and returns the query results to the user.

[0058] Specifically, for sensitive operations such as password modification and activation code reset, the server performs additional permission checks on the number of requests in addition to the aforementioned product configuration information comparison, in order to prevent malicious modification operations.

[0059] The first step is to determine the function type and preset time period corresponding to the request. For example, if the function request is to change a password, the corresponding function type is password change, and the preset time period is 24 hours by default; if it is to reset an activation code, the function type is activation code reset, and the preset time period is also 24 hours by default.

[0060] The second step is to query the historical request count for this function type of the target account within a preset time period. The server's operation log database records the operation logs of all target accounts, including information such as function type, operation time, and operation result. The server uses the target account identifier, function type, and preset time period as query conditions to filter operation log entries that meet the conditions in the operation log database and counts the number of entries, which is the historical request count. For example, to query the number of password change operations performed by the target account of car manufacturer A within a preset time period, the server filters out all operation logs of the password change function type for this account within that time period, and counts 35 times.

[0061] The third step is to obtain the maximum number of uses for this function type. The server queries the account parameters corresponding to the target account from the account management database and extracts the maximum number of uses threshold for this function type. For example, the maximum number of uses for the password change function is 50 times per day, and the maximum number of uses for the activation code reset function is 10 times per day.

[0062] The fourth step is to compare the historical request count with the maximum usage count. If the historical request count is less than the maximum usage count, the request count verification is passed, and subsequent operations are allowed. If the historical request count is greater than or equal to the maximum usage count, the request count verification is failed, and the server returns a response message stating that the usage limit for this function within the preset time period has been reached. The user is advised to try again in the next time period or contact the after-sales service manager for assistance. The server also records the limit exceedance log and notifies the super administrator to monitor for any abnormal operations by this account.

[0063] For example, if a target account of a second-tier car manufacturer initiates an activation code reset request, the server will find that the account has initiated 9 activation code reset operations on that day, while the maximum number of uses is 10. If the number of requests is less than the maximum number of uses, the verification will pass; if it has been initiated 10 times, the verification will fail and an "exceeded limit" message will be returned.

[0064] In one possible implementation, if the number of requests is less than the maximum usage limit, the operation corresponding to the function request is executed based on the sequence number. This also requires steps such as obtaining the first product configuration information, obtaining the initial product configuration information, and comparing the configuration information; the only difference lies in the content of the final operation. If the configuration information matches and the request count verification passes, the server executes the corresponding modification operation.

[0065] If the function request is for password modification, the server first verifies whether the new password entered by the user meets the password complexity requirements. If it does not meet the requirements, it returns a password format error message. If it meets the requirements, it performs irreversible encryption on the new password, updates the user account password field corresponding to the serial number in the device information database, and overwrites the original encrypted password. After the modification is completed, it returns a password modification success message, notifies the end user to log in with the new password, and records the password modification operation log, including the operator, operation time, operation object such as serial number, execution action, operation result, and digest information of the encrypted new password.

[0066] If the function request is for resetting the activation code, the server calls the activation code generation module to generate a new activation code using a random algorithm and updates the activation code field corresponding to the serial number in the device information database. At the same time, it records the old activation code before the reset and the reset time for easy traceability later. After the reset is completed, it returns a message indicating that the activation code has been successfully reset and records the activation code reset operation log, including the operator, operation time, operation object, executed action, operation result, and the encrypted digest information of the new activation code.

[0067] If the configuration information does not match, the server will not perform the modification operation even if the number of requests has not reached the limit, and will return a prompt that the permission verification failed and log the unauthorized modification request.

[0068] For example, if a target account of a Tier 1 car manufacturer customer initiates a password change request, and the first product configuration information corresponding to the serial number is consistent with the initial product configuration information, and the number of password changes per day is 45, which is less than the maximum of 50, and the new password entered by the user meets the complexity requirements, then the server will perform the password update operation and return a success message; if the product configuration information corresponding to the serial number is not within the management scope of the account, then an insufficient permissions message will be returned.

[0069] Optionally, in step S402, if the target operation type is the first operation type, executing the operation corresponding to the function request based on the sequence number may include the following steps: Step S501: Based on the serial number, determine the first product configuration information corresponding to the function request; Step S502: Obtain the initial product configuration information for the target account; Step S503: Compare the first product configuration information with the initial product configuration information; Step S504: If the first product configuration information matches the initial product configuration information, execute the operation corresponding to the function request; Step S505: If the first product configuration information and the initial product configuration information are inconsistent, execute the operation corresponding to the query operation type in the function request and return the first operation result. For the operation corresponding to the modification operation type in the function request, return an insufficient permission prompt.

[0070] In one possible implementation, the first product configuration information corresponding to the function request is determined based on the serial number. First, the target resource is determined based on the serial number, and then the first product configuration information corresponding to the target resource is obtained.

[0071] In one possible embodiment, the target resource is determined based on the serial number. The target resource refers to all data information related to the diagnostic device account corresponding to the serial number, stored in the server's device information database. This includes basic information, software configuration information, and usage record information. Basic information may include device model, manufacturer, production date, serial number, configuration name, user account, initial password encrypted storage value, activation code, etc. Software configuration information may include configuration software name, version number, update time, installation package storage path, etc. Usage record information may include download history, download restriction history, software download period, login history, etc. The server performs a precise matching query in the device information database using the serial number. Since the serial number is a unique identifier for the diagnostic device, each serial number corresponds to a unique device information record, thus quickly locating all target resource data corresponding to that serial number. If the corresponding target resource is not found, the server will return a response result indicating that no device information corresponding to the serial number was found and record a query failure log.

[0072] In one possible embodiment, the first product configuration information corresponding to the target resource is obtained. The first product configuration information refers to the product configuration category to which the target resource belongs. This information is entered during the production and warehousing of the diagnostic equipment and stored in the product configuration field of the equipment information database. The naming convention for the product configuration information can be customer abbreviation-product model / version-configuration identifier, ensuring clear differentiation of the configuration affiliation of different vehicle manufacturers and different models of diagnostic equipment. The server can obtain the first product configuration information by querying the product configuration field corresponding to the target resource.

[0073] In one possible implementation, the initial product configuration information of the target account is obtained. Initial product configuration information refers to the range of product configurations bound to the target account when it is assigned. This information is stored in the product configuration binding field of the server's account management database and serves as the basis for data isolation. For example, the initial product configuration information of a target account assigned to car manufacturer A includes all product configurations for the A series. The server can obtain the initial product configuration information by querying the product configuration binding field corresponding to the target account in the account management database using the target account identifier.

[0074] In one possible embodiment, the first product configuration information and the initial product configuration information are compared. The server calls the permission verification API module to perform the comparison operation. It is determined whether the first product configuration information falls within the scope covered by the initial product configuration information. Specifically, if the initial product configuration information is the full range of configurations from car manufacturer A, then as long as the customer abbreviation of the first product configuration information is A, it is determined that the comparison is consistent; if the initial product configuration information is a specific product configuration model, then the first product configuration information must be completely consistent with that model to be determined that the comparison is consistent; if the initial product configuration information is a combination of multiple product configurations, then as long as the first product configuration information belongs to any one of the configurations, it is determined that the comparison is consistent.

[0075] In one possible embodiment, the corresponding operation is performed based on the comparison result. If the first product configuration information is consistent with the initial product configuration information, the server extracts the target resource data corresponding to the function request from the device information database. For example, if the function request is to query the user account and download history, the user account field and download history field data in the target resource are extracted, and the data is organized into a standardized response format, including table format, list format, etc. The user can choose the display method on the administrator platform, and the data is returned to the administrator platform through an encrypted channel. The platform displays the results to the user. At the same time, the server records the query operation log, including the operator (target account identifier), operation time, operation object (serial number), execution action, operation result, and other information.

[0076] If the first product configuration information is inconsistent with the initial product configuration information, the server will only perform the basic information query operation corresponding to the query operation type in the function request, specifically including publicly available basic information such as serial number, device model, and production date. It will then return the first operation result, i.e., the aforementioned basic information, and indicate in the result that the device is outside your management scope, displaying only basic publicly available information. For modification operation types that may be implicit in the function request, if a user mistakenly initiates a modification request that exceeds their permissions, the server will directly return an insufficient permissions prompt, stating: "Your account does not have permission to operate the device configured for this product. Please contact the super administrator for consultation." Simultaneously, it will record the unauthorized request log, including the operator, operation time, operation object, executed action, operation result (i.e., insufficient permissions), request IP address, etc., for the super administrator to audit.

[0077] For example, if the initial product configuration information for the target account of car manufacturer A is the configuration of all products in the A series, when the administrator enters the serial number SN12345678, corresponding to the first product configuration information A-2023 diagnostic instrument configuration, and initiates a request to query the user account and download history, the server returns the complete user account and download history data because the comparison is consistent. However, if the administrator enters the serial number SN87654321, corresponding to the first product configuration information B new energy diagnostic equipment configuration, and initiates the same query request, the server only returns basic information such as the serial number, device model, and production date of the device because the comparison is inconsistent, and prompts insufficient permissions.

[0078] Optionally, the following steps may also be included: Step S601: Obtain the operation log of the target account within the target time period; the operation log includes the user's login behavior and device operation behavior using the target account within the target time period; Step S602: Perform anomaly monitoring on the operation log; Step S603: If an abnormality is detected in the operation log, implement permission management for the target account.

[0079] In one possible implementation, the target time period can be flexibly set by the super administrator according to management needs, and defaults include real-time monitoring, daily monitoring, weekly monitoring, and monthly monitoring, while also supporting custom time period queries. The operation log is a full log of data recorded in real time by the server when the target account executes various function requests. It is stored in an operation log database using a distributed storage architecture to ensure the security and scalability of the log data.

[0080] For servers, the super administrator can initiate a log query request by selecting the target account identifier and target time period through the log management module of the access control center. The server filters the corresponding log data in the operation log database according to the query conditions, including login behavior logs and device operation behavior logs. The login behavior logs can include login time, IP address, login terminal information, login success / failure status, logout time, etc. The device operation behavior logs can include operation time, operator, operation object, function type, request parameters, operation result, exception prompts, etc. The filtered log data is then summarized and organized to generate standardized log reports.

[0081] The server calls the log analysis module to perform in-depth analysis of the acquired operation logs. For login behavior, it extracts features such as login time distribution (e.g., whether frequent logins occur outside of working hours), login IP address distribution (e.g., whether multiple logins from different IP addresses occur), login terminal information (e.g., whether logins are made using unfamiliar terminals), and login success rate (e.g., whether there are cases of successful logins after multiple failed login attempts). For device operation behavior, it extracts features such as operation function type distribution (e.g., whether query operations or modification operations are the main types), operation object distribution (e.g., whether operations are concentrated on a certain range of serial numbers), operation frequency (e.g., whether the number of operations per unit time is abnormal), and operation result distribution (e.g., whether there are a large number of operation failures or insufficient permissions records).

[0082] By analyzing these characteristics, the server can determine the user's usage behavior patterns. For example, if a target account's login behavior is characterized by daily logins from 9:00 AM to 6:00 PM, login IP addresses concentrated at the headquarters and affiliated 4S stores of car manufacturer A, login terminals being three fixed office computers, a 100% login success rate, and device operation behavior primarily consisting of query operations (approximately 50 queries per day), and modification operations mainly involving password changes (approximately 10 changes per day), with all operations targeting A-series diagnostic device serial numbers and all resulting in success, then the account's usage behavior is determined to conform to a regular business pattern.

[0083] In one possible embodiment, the server has a built-in anomaly monitoring rule base, which includes two main categories: login behavior anomaly rules and device operation behavior anomaly rules.

[0084] For example, abnormal login behavior rules could include: logging in more than 3 times outside of working hours; successfully logging in after more than 5 failed login attempts in a single session; logging in from 3 or more different IP addresses within the same time period; logging in using an unfamiliar terminal; or failing to automatically log out after the login duration exceeds the maximum single login time and no further action is taken.

[0085] For abnormal device operation behavior rules, the number of operations within a unit of time exceeds the preset threshold; the proportion of modification operations exceeds 50% of the total number of operations; multiple consecutive operations on the same serial number; the proportion of records with insufficient permissions or incorrect parameters in the operation results exceeds 30%; and the number of operation requests that exceed the product's configuration range exceeds 10 times per day.

[0086] In one possible embodiment, the server's anomaly monitoring module performs real-time matching and verification of operation logs. If the behavioral characteristics in the operation logs trigger any of the aforementioned anomaly rules, the operation log is determined to be abnormal, and the anomaly type is marked, such as abnormal login from a different location, abnormal operation frequency, etc. For example, if a target account logs in from three different IP addresses (address 1, address 2, and address 3) between 2:00 AM and 3:00 AM, and initiates 150 activation code reset operations within one hour, then the three anomaly rules of abnormal login from a different IP address during non-working hours and abnormal operation frequency are triggered, and the log is determined to be abnormal.

[0087] In one possible implementation, the server takes different access control measures for the target account based on the severity of the anomaly, specifically divided into three levels of control: Level 1 control targets minor anomalies and applies to situations that trigger a single minor anomaly rule, such as a single login outside of working hours or a single login from an unfamiliar terminal. The server automatically sends an anomaly alert to the super administrator and sends a risk warning SMS / email to the target account's associated contacts, informing them of the abnormal login or operation behavior and prompting them to verify. At the same time, the target account's normal permissions are retained, but an additional operation verification step is added, such as requiring a dynamic verification code to be entered each time a modification operation is performed. The dynamic verification code is sent to the associated mobile phone number via SMS.

[0088] Level 2 control targets moderate anomalies, applicable to situations triggering two or more anomaly rules or a single severe anomaly rule, such as multiple logins from different IP addresses, abnormal operation frequency, or continuous unauthorized requests. The server automatically freezes the target account's edit permissions, retaining only query permissions; sends an emergency alert notification to the super administrator, along with a detailed anomaly log report; the super administrator contacts the target account's associated contact to verify the anomaly. If verified as a legitimate operation (e.g., staff working remotely), the edit permissions are unfrozen, and the account's bound IP address or terminal information is updated. If verified as an abnormal operation (e.g., account theft), the target account password is reset, and the contact is required to reactivate the account.

[0089] Level 3 control is for severe anomalies and applies to situations that trigger multiple serious anomaly rules or show clear signs of malicious operation, such as batch modification of passwords / activation codes for unrelated devices, repeated attempts to crack other people's accounts, or a large number of malicious request parameters in the operation log. The server immediately freezes all functional permissions of the target account, prohibiting login and operation; sends the highest level alert to the super administrator and security audit center; the security audit center conducts source tracing analysis of the abnormal operation to investigate data leakage risks; and through the super administrator, urgently communicates with the target customer to verify the situation and decide whether to unfreeze the account, cancel the account, or reassign a new account based on the actual situation, and investigates and holds relevant personnel accountable.

[0090] For example, if a target account is accessed by an employee who is traveling to another location and logs in using an unfamiliar terminal outside of working hours, triggering a minor anomaly rule, the server will take level one control measures, send a risk warning and add operation verification. If the account is stolen by someone else and initiates a batch of unauthorized activation code reset operations, triggering a major anomaly rule, the server will immediately freeze the account, initiate source tracing analysis, and notify the relevant personnel for handling.

[0091] See Figure 4 , Figure 4 This is a schematic diagram of a security audit process for operation log recording provided in an embodiment of this application. Specifically, operation log records are obtained from the target account, and then the operation log records are audited by a security audit center to monitor for anomalies in the target account.

[0092] Optionally, the following steps may also be included: Step S701: Encrypt each transmitted data between the server and the diagnostic device using a preset communication encryption protocol.

[0093] To ensure data security during transmission and prevent eavesdropping, tampering, or forgery, this method also includes a data encryption step.

[0094] Specifically, all data transmitted between the server and the administrator platform, which is the client operation entry point corresponding to the diagnostic device, is encrypted using a preset communication encryption protocol. The default encryption protocol is TLS 1.2 or above, which has strong security and compatibility and can effectively resist network security risks such as man-in-the-middle attacks and data eavesdropping.

[0095] After the administrator platform initiates a connection request, the server sends a digital certificate to the platform. The platform verifies the validity of the digital certificate. Once the verification is successful, it generates a random session key, encrypts the session key using the server's public key, and sends it to the server. The server decrypts the session key using its own private key, obtains the session key, and completes the handshake process.

[0096] After a successful handshake, all data transmitted between the server and the platform, including account allocation requests, function requests, response results, and operation logs, is encrypted using the AES-256 encryption algorithm with a session key for symmetric encryption. A message authentication code is added to the encrypted data to verify its integrity. Upon receiving the data, the receiver first verifies the message authentication code value to confirm that the data has not been tampered with, and then uses the session key to decrypt the data and obtain the original information.

[0097] In addition, the server regularly updates digital certificates and session key generation algorithms to ensure the security of the encryption mechanism; it also monitors and records abnormal data transmission behaviors during the transmission process, such as data transmission interruption, repeated transmission, and data verification failure, to promptly detect potential security risks.

[0098] See Figure 5 , Figure 5 This is a logical block diagram illustrating the association of account allocation and permission verification within a permission control center, as provided in an embodiment of this application. The permission control center is used to allocate target accounts to users and to verify the permissions of function requests issued by users based on those target accounts.

[0099] Further, see Figure 6 , Figure 6 This application provides a flowchart of account management and permission verification based on policy rules and product configuration. If a login authentication request is received, the permission control center is triggered to allocate a target account, bind the product configuration library, and set the policy rule library, which includes login timeout and access limits. If an information query request or an information reset modification request is received, the permission control center performs permission verification, access limit verification through the policy rule library, and product configuration verification through the product configuration library.

[0100] In one possible implementation, a backend system defines management functions accessible to B-end clients, such as allowing them to query configuration names, user accounts, configuration software, download history, download restriction history, and software download expiration dates by inputting a serial number. These clients also have permissions to modify passwords and registration passwords or activation codes. Information querying is a routine function, while password / activation code modification is a relatively sensitive function requiring frequency limits. For a given client, password modifications are allowed no more than 50 times per day, and activation code modifications no more than 10 times per day. Exceeding these limits requires reporting to the after-sales service manager for assistance. The backend assigns fixed accounts and passwords to each B-end client administrator with super administrator privileges, limiting the number of client devices they can simultaneously log into and implementing a timeout logout mechanism. The server records detailed operation logs for all B-end client administrators, including login behavior (login time, IP address, login success / failure) and device operations (password / activation code modification time and result). Each log entry includes the operator, operation time, target device, executed action, and result. The backend super administrator has the ability to globally view and analyze all B-end client administrator operation logs to promptly identify and intervene in abnormal patterns.

[0101] For multiple B-end clients from car manufacturers, data isolation measures are implemented to prevent unauthorized access. When creating administrator accounts, they are categorized by product configuration bindings, and this field strictly distinguishes and isolates data from different clients. For example, a B-end client administrator account belonging to client A has its corresponding A-series product configuration set in the backend. When an administrator account retrieves a configuration that belongs to the A-series through a serial number, it has the relevant modification permissions; otherwise, it only has basic query permissions and no modification permissions. During this process, product configuration permission checks are performed on every request in all backend API interfaces to confirm whether the currently logged-in B-end client administrator has the authority to operate on the requested target resource.

[0102] In addition, all communication between the administrator platform and the server should use strong encryption protocols, such as TLS 1.2+, to prevent data from being eavesdropped or tampered with during transmission. The rights and responsibilities of B-end customer administrators should be clearly defined through user agreements or other means to prohibit them from engaging in unauthorized account sharing, selling, or other operations, in order to ensure account security.

[0103] In this embodiment, a dedicated administrator account is assigned, allowing the administrator to query relevant information and modify passwords / activation codes a limited number of times. Data isolation between different customers is achieved through product configuration binding, preventing unauthorized access. To ensure security, the system records all operation logs for auditing and employs measures such as communication encryption and operation limit limits, achieving a perfect balance between authorization and control. This ensures that B-end customers have account operation permissions within a secure scope, enabling them to directly manage basic functions such as product and account management for end users. This not only reduces after-sales service pressure but also helps improve the management efficiency of B-end customers. Facing a massive user base and multiple access points, this system ensures both security and a convenient unified management experience, striking a balance between centralized control and distributed autonomous management. It guarantees overall security while empowering customers and improving overall efficiency.

[0104] In a specific embodiment, for user A, user A submits an account allocation request to the server. After receiving the account allocation request, the server obtains user information such as the number of third-party clients and the number of functional requirements of user A. Based on the user information, the server determines the user type of user A, for example, determining that it is a first-tier car manufacturer client. Based on the user type, the server determines the function name and number of functions, for example, the function name is 9 items and the number of functions is 9. Based on the user scale, the server determines the maximum single login time and the maximum number of times each function can be used, for example, the maximum single login time is 30 minutes, the maximum number of times information query functions can be used is 500 times per day, the password modification function is 50 times per day, and the activation code reset function is 10 times per day. The server generates a target account and initial password and sends them to user A via encrypted email. After user A logs in and changes the initial password, the account is activated.

[0105] After User A logs into the target account, they enter the serial number of the diagnostic device and initiate a password change request. The server parses the request, obtains the serial number, and determines the target operation type to be the second type, i.e., password change. The server checks the account's daily password change count, finding it to be 15, which is less than 50, thus passing the request count verification. After verifying that the new password entered by the user meets the complexity requirements, the server encrypts and updates the password field in the database, returns a success message, and records the operation in the log.

[0106] For User B, only three functions are needed: device serial number query, download history query, and software download expiration date query. User B submits an account allocation request, confirming the functional requirements as these three query functions. The server determines User B's user type; determines the function names as serial number query, download history query, and software download expiration date query, with a function quantity of 3; based on user scale, determines the maximum single login time as 90 minutes, and the maximum number of times query functions can be used per day as 100; generates the target account and initial password, and sends them to User B; after User B activates the account, the account is officially enabled.

[0107] User B logs in to their account, enters the serial number, and initiates a download history query request. The server parses the request, identifying the target operation type as the first operation type; it retrieves the initial product configuration information (general diagnostic instrument configuration) and compares it with the first product configuration information; the server queries the device information database, extracts the download history data for that serial number, including download time, software name, download IP, etc., organizes it into a table format, returns it to user B, and records the query log.

[0108] If user B enters an incorrect serial number and initiates a download history query request, the server compares the product configuration information and finds no discrepancy. It then returns only basic information such as the device's serial number, model, and production date, and indicates that the device is outside the management scope, displaying only basic information and logging unauthorized queries.

[0109] In this embodiment, account allocation, account parameter configuration, permission verification, and security control effectively solve the problems of insufficient operation permissions for B-end customers and cumbersome after-sales processes in existing technologies. This allows B-end customers to directly manage the diagnostic equipment accounts of their subordinate service outlets, reducing communication costs with after-sales, shortening problem-solving cycles, improving operational efficiency and user experience at terminal stores, and significantly reducing after-sales service pressure and maintenance costs. Product configuration binding achieves data isolation between different customers. Combined with multiple security measures such as operation frequency limits, operation log auditing, data encryption, and abnormal behavior monitoring, data security for all parties is ensured, effectively preventing information leakage and unauthorized access, achieving a balance between authorization and control. It possesses high flexibility and scalability, allowing flexible configuration of account parameters based on user type, user scale, and business needs. It supports the addition and adjustment of functions, adapting to B-end customers of different sizes and needs, while being compatible with multiple transmission protocols and access methods, adapting to industry technology development and changes in business scenarios. Through full-process operation log recording and anomaly monitoring, account usage is traceable and controllable, facilitating timely detection and handling of security risks, and ensuring the stable operation of the account management system.

[0110] In summary, in this embodiment, the server first obtains the user's account allocation request. Then, based on the account allocation request, it allocates a target account associated with the user's diagnostic device to the user. Next, it obtains the function request initiated by the user based on the target account. After verifying the permissions of the function request, it executes the operation corresponding to the function request based on the permission verification result. Thus, by directly allocating a target account associated with the user's diagnostic device to the user, the user can initiate function requests through the target account and obtain the corresponding execution results, reducing the intermediate communication links with key customer after-sales service managers and improving the task processing efficiency of function requests.

[0111] The methods of the embodiments of the present invention have been described in detail above, and the apparatus of the embodiments of the present invention is provided below.

[0112] See Figure 7 , Figure 7 This is a schematic diagram of the structure of an account management device based on diagnostic equipment provided in an embodiment of this application. Figure 7 As shown, the account management device 800 based on diagnostic equipment includes an acquisition unit 801 and a processing unit 802; the acquisition unit 801 is used to acquire a user's account allocation request; the processing unit 802 is used to allocate a target account associated with the user's diagnostic equipment to the user according to the account allocation request; acquire the function request initiated by the user based on the target account; and after verifying the permission of the function request, execute the operation corresponding to the function request according to the permission verification result.

[0113] In specific implementations, the acquisition unit 801 and the processing unit 802 in this application embodiment can also execute other implementations described in the account management method based on diagnostic equipment in the above application embodiment, which will not be repeated here.

[0114] See Figure 8 , Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 8 As shown, the electronic device 900 includes a transceiver 901, a processor 902, and a memory 903, which are connected via a bus 904. The memory 903 stores computer programs and data, and can transmit the data stored in the memory 903 to the processor 902. The electronic device 900 can be the aforementioned account management device 800 based on a diagnostic device, and the processor 902 can be the aforementioned acquisition unit 801 and processing unit 802. In this embodiment, the processor 902 is used to read the computer program in the memory 903 and execute some or all of the steps of the aforementioned account management method based on a diagnostic device.

[0115] This application also provides a computer-readable storage medium storing a computer program that is executed by a processor to implement some or all of the steps of any of the diagnostic device-based account management methods described in the above method embodiments.

[0116] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the diagnostic device-based account management methods described in the above method embodiments.

[0117] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0118] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0119] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or modules may be electrical or other forms.

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

[0121] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software program modules.

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

[0123] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. An account management method based on diagnostic equipment, characterized in that, Applied to a server, the method includes: Obtain the user's account allocation request; Based on the account allocation request, assign a target account associated with the user's diagnostic device to the user; Obtain the function request initiated by the user based on the target account; After verifying the permissions of the function request, the operation corresponding to the function request is executed according to the permission verification result.

2. The method as described in claim 1, characterized in that, The step of allocating a target account associated with the user's diagnostic device to the user according to the account allocation request includes: Based on the account allocation request, determine the user type of the user; Based on the user type, the account parameters of the target account are determined; the account parameters are used to limit the function name, number of functions, maximum login time per session, and permission parameters for each function of the target account. The target account is assigned to the user based on the account parameters.

3. The method as described in claim 2, characterized in that, The permission parameters for each function include the maximum number of times each function can be used within a preset time period; determining the account parameters of the target account based on the user type includes: Based on the user type, determine the user's functional requirements and user scale; Based on the functional requirements, determine the function name and the number of functions; Based on the user base, determine the maximum single login time and the maximum number of times each function can be used within a preset time period.

4. The method as described in claim 3, characterized in that, The step of performing permission verification on the function request and then executing the operation corresponding to the function request based on the permission verification result includes: Parse the function request to obtain the serial number and target operation type; If the target operation type is the first operation type, the operation corresponding to the function request is executed based on the sequence number; If the target operation type is the second operation type, verify the number of times the function request is requested within the preset time period; If the number of requests is less than the maximum number of uses, the operation corresponding to the function request is executed based on the sequence number.

5. The method as described in claim 4, characterized in that, If the target operation type is the first operation type, the step of executing the operation corresponding to the function request based on the sequence number includes: Based on the serial number, determine the first product configuration information corresponding to the function request; Obtain the initial product configuration information of the target account; Compare the first product configuration information with the initial product configuration information; If the first product configuration information and the initial product configuration information match, execute the operation corresponding to the function request; If the first product configuration information and the initial product configuration information are inconsistent, the operation corresponding to the query operation type in the function request is executed and the first operation result is returned. For the operation corresponding to the modification operation type in the function request, an insufficient permission prompt is returned.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: Obtain the operation logs of the target account within a target time period; the operation logs include the user's login behavior and device operation behavior using the target account within the target time period. Perform anomaly monitoring on the operation log; If an anomaly is detected in the operation log, access control will be implemented for the target account.

7. The method according to any one of claims 1-5, characterized in that, The method further includes: Each transmitted data between the server and the diagnostic device is encrypted using a preset communication encryption protocol.

8. An account management device based on diagnostic equipment, characterized in that, The device includes an acquisition unit and a processing unit; The acquisition unit is used to acquire the user's account allocation request; The processing unit is configured to assign a target account associated with the user's diagnostic device to the user according to the account allocation request; Obtain the function request initiated by the user based on the target account; After verifying the permissions of the function request, the operation corresponding to the function request is executed according to the permission verification result.

9. An electronic device, characterized in that, include: A processor and a memory, the processor being connected to the memory, the memory being used to store a computer program, the processor being used to execute the computer program stored in the memory to cause the electronic device to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1-7.

Images