SaaS multi-tenant-oriented online car-hailing data verification method and system

Abstract

The invention discloses an online car-hailing data verification method and system oriented to SaaS (Software as a Service) multiple tenants. The invention relates to the technical field of online car-hailing aggregation platform systems. User (driver or vehicle administrator) data information is input into an interface of the online car-hailing aggregation platform; the user data information comprises key fields such as an identity card number, a name, a license plate number, an engine number, a vehicle owner and a VIN code. And loading the corresponding customized verification rule according to the tenant to which the current user belongs. Performing preliminary verification on the input data, and checking whether the input data meet the specific format, length and necessary item requirements of the tenant or not; by implementing the multi-tenant customized verification rule, the unnecessary data verification process is reduced, so that the verification is more accurate and efficient. According to the automatic error correction mechanism, common data entry errors can be recognized and corrected in real time, the tedious process of manual repeated checking and modification is avoided, and the passing rate of data verification is remarkably increased.

Description

Technical Field

[0001] The present invention relates to the technical field of online car-hailing aggregation platform systems, and specifically to multi-tenant online car-hailing data verification, and in particular to an online car-hailing data verification method and system for SaaS multi-tenants. Background Art

[0002] In the traditional technical framework of the current online ride-hailing aggregation platform system, information entry and verification plays a vital role. This link covers the collection and verification of multi-dimensional data such as driver information, vehicle information, personal and vehicle certificates, etc., aiming to ensure the accuracy and compliance of all input information. For example, the system will strictly verify key fields such as ID number and vehicle VIN code as a prerequisite for subsequent double-certificate verification and manual review processes. For the specific verification process, please refer to the attached figure of the manual. Figure 2 , I will not go into details here.

[0003] However, an in-depth analysis of current technical practices reveals several limitations in data verification, which significantly affect the platform's operational efficiency and the occupancy rate of drivers and vehicles. Specifically, the problems are mainly reflected in the following aspects:

[0004] (1) Lack of customized verification rules for multiple tenants: The current system uses a globally unified verification rule, which fails to fully consider the differentiated needs of different tenants. For example, some tenants may require compulsory traffic insurance information, while other tenants may not have such a mandatory requirement. This lack of flexibility in the verification mechanism undoubtedly limits the platform's ability to adapt to different business scenarios.

[0005] (2) Insufficient error recognition and automatic repair mechanisms: When faced with obvious errors in input information, such as the OCR technology mistakenly identifying the "0" in the license plate number as "O", or the driver's name containing spaces that should not appear, the system lacks effective automatic correction and repair capabilities. The accumulation of such errors directly leads to frequent obstructions in the verification process, reducing overall processing efficiency.

[0006] (3) Rigidity of the verification logic adjustment mechanism: When faced with unreasonable verification of specific fields, the system lacks the ability to respond quickly and automatically adjust the verification logic. For example, when a large number of driver's license owner fields fail to be verified under a certain tenant (often due to insufficient coverage of the verification regular expression), the system cannot intelligently skip this step, resulting in unnecessary delays and waste of resources.

[0007] To sum up, the above-mentioned problems existing in the data verification link of the existing online ride-hailing aggregation platform system not only directly reduce the efficiency of the platform's subsequent double-certificate verification and manual review, but also indirectly affect the occupancy rate of drivers and vehicles, thereby posing a challenge to the overall operational efficiency of the platform.

[0008] To this end, the present invention proposes a method and system for verifying online car-hailing data for SaaS multi-tenants. Summary of the invention

[0009] In view of this, the present invention hopes to provide a SaaS multi-tenant-oriented online car-hailing data verification method and system to solve or alleviate the technical problems existing in the prior art, that is, how to implement multi-tenant customization, automatic error correction, feedback adjustment verification mechanism for the current implementation defects of data verification of most online car-hailing aggregation platform systems, improve the efficiency of data verification, and ultimately increase the occupancy rate of drivers and vehicles on the platform, and at least provide a beneficial option for this; the technical solution of the present invention is implemented as follows:

[0010] First, a data verification method for online car-hailing services for SaaS multi-tenants:

[0011] 1. Overview:

[0012] The present invention aims to provide an efficient, flexible and intelligent data verification solution for online ride-hailing aggregation platforms. The solution proposes targeted optimization strategies for the challenges currently faced by the platform in the data verification process, such as multi-tenant customization requirements, frequent input errors, and rigid verification logic. By implementing multi-tenant customized verification rules, it is ensured that the data verification standards of different tenants can be met; at the same time, an automatic error correction mechanism is introduced to intelligently identify and repair common input errors, thereby improving the pass rate of data verification; in addition, a feedback adjustment verification mechanism is established to monitor the data verification status in real time and automatically adjust the verification logic to meet the verification needs in different scenarios.

[0013] (II) Technical solution:

[0014] To achieve the above technical objectives, the present invention selects to execute the following steps.

[0015] 2.1 Step S1, data entry:

[0016] The interface of the online ride-hailing aggregation platform enters user (driver or vehicle manager) data information.

[0017] 2.1.1 Step S100, input data:

[0018] The data information includes ID number, name, license plate number, engine number, vehicle owner and VIN code information. The application performs preliminary data format verification.

[0019] For example, check whether the ID number is 18 digits, whether the license plate number conforms to the local format, whether the VIN code is 17 digits, and other basic requirements.

[0020] If the data format does not meet the requirements, the system will immediately prompt the user to re-enter the data.

[0021] 2.1.2 Step S101, data encryption and transmission:

[0022] The data entered by the user is encrypted on the application side to ensure the security of the data during transmission. The encrypted data is sent to the SaaS server of the online car-hailing aggregation platform via the HTTPS protocol.

[0023] 2.2 Step S2, application of multi-tenant customized verification rules:

[0024] Load the corresponding customized validation rules according to the tenant to which the current user belongs. Perform a preliminary validation on the entered data to check whether it meets the tenant's specific format, length, and required field requirements.

[0025] 2.2.1 Step S200, identify the tenant to which the user belongs:

[0026] After the user data is entered and transmitted to the SaaS server, the tenant to which the user belongs is identified through the tenant ID or tenant context information used when the user logs in.

[0027] 2.2.2 Step S201, load customized verification rules:

[0028] According to the tenant to which the user belongs, the SaaS server loads the corresponding customized validation rules from the configuration file on the database side. These rules define the specific requirements for data validation under the tenant, including format, length, and required items.

[0029] 2.2.3 Step S202, execute customized verification rules:

[0030] The verification rules cover the format, length and mandatory requirements for key fields such as ID number, license plate number, engine number, vehicle owner and VIN code.

[0031] Load and apply the corresponding customized verification rules for the tenant to which the current user belongs; compare the data entered by the user one by one to ensure that each data meets the tenant-specific verification standards;

[0032] For example, for a specific tenant of an online ride-hailing aggregation platform, its customized verification rules include: the ID number must be 18 digits and start with a specific number, the license plate number must comply with the format requirements of the region (such as "Su A12345"), the engine number cannot be empty and the length must be within a certain range (such as 6-10 digits), the vehicle owner field must be filled in and cannot contain special characters, and the VIN code must be 17 digits and comply with the international standard format.

[0033] Another tenant identifies different rules based on the regional characteristics of the data information it provides, such as: the ID number is allowed to be 15 or 18 digits, the license plate number format requirements are different, the engine number is optional, the vehicle owner field is allowed to contain a specific prefix or suffix, and the VIN code is not required but must comply with the format when filled in.

[0034] 2.2.4 Step S203, verification result processing:

[0035] If the data does not meet the customized validation rules of S202, an error message will be generated, indicating the specific fields and reasons that do not meet the rules. The error message will be returned to the application end so that the user can make necessary modifications and resubmit.

[0036] If the data meets the customized verification rules of S202, then enter S3.

[0037] 2.3 Step S3, activating automatic error correction processing:

[0038] Use natural language processing (NLP) technology to automatically correct the entered data and identify and correct common errors according to the preset strategy. Before executing this step, load the preset automatic error correction strategy library, which contains the identification and correction rules for various common errors. Prepare the models and algorithms required by natural language processing (NLP) technology to perform intelligent analysis on the entered data.

[0039] 2.3.1 Step S300, correct the ID card number:

[0040] Check if there are lowercase letters in the ID number, and if so, automatically convert them to uppercase letters. Check if there are spaces in the ID number, and if so, automatically remove the spaces.

[0041] 2.3.2 Step S301, correct the name field:

[0042] Checks for intervening spaces in the name field and automatically removes them if present.

[0043] Check the symbols in the name field. If they are ".", ".", "·" or "·", they will be automatically converted to full-width separators "·".

[0044] 2.3.3 Step S302, correct the engine number:

[0045] Check whether there is "-", "—" or "_" in the engine number. If so, convert them to a minus sign "-".

[0046] 2.3.4 Step S303, correct the vehicle owner field:

[0047] Check whether there are half-width brackets "(" or ")" in the vehicle owner field. If so, automatically convert them to full-width brackets "()".

[0048] 2.3.5 Step S304, correct the OCR recognition result:

[0049] Check whether the license plate number or VIN code has "0" mistakenly identified as "O". If so, repair it to "0".

[0050] 2.3.6 Step S305, error correction result processing:

[0051] S300 to S304 are executed again on the corrected data; at the same time, the corrected data is updated to the database end each time; when S300 to S304 are executed again and no error occurs, enter S4.

[0052] 2.4 Step S4, execute feedback adjustment verification mechanism:

[0053] The data verification results are recorded in the data verification history information library. The verification history data is monitored and analyzed, and the frequency of failed certificate data verification under each tenant is counted.

[0054] If the frequency of data verification failure of a certain type of certificate under a certain tenant exceeds the threshold, the fuse mechanism will be automatically triggered, the verification of this type of certificate will be skipped, and an alarm notification will be sent to the system administrator or relevant tenant.

[0055] 2.4.1 Step S400, record the verification results:

[0056] The results of each data verification are recorded in the data verification history information library, including verification time, tenant information, certificate type, verification result (pass / fail) and specific reasons for failure.

[0057] 2.4.2 Step S401, monitor and analyze verification history data:

[0058] Regularly monitor and analyze the data verification history information database, and count the frequency of failed verifications for different types of certificates under each tenant. Use data visualization tools or reports to display the pass rate and failure frequency of each tenant's certificate verification, so as to identify potential problems in a timely manner.

[0059] 2.4.3 Step S402, setting threshold and detecting:

[0060] According to business needs and historical data, set reasonable verification failure frequency thresholds for different types of certificates. Detect the verification failure frequency of certificate data under each tenant in real time and compare it with the set threshold.

[0061] 2.4.4 Step S403, triggering the fuse mechanism:

[0062] If the frequency of verification failure of a certain type of certificate data under a certain tenant exceeds the set threshold, the fuse mechanism will be automatically triggered. The fuse mechanism will skip the subsequent verification steps of this type of certificate, directly regard it as verification failure, and record relevant logs.

[0063] 2.4.5 Step S404, sending an alarm notification:

[0064] When the circuit breaker mechanism is triggered, both the SaaS server and the application send an alarm notification to the system administrator and related tenants. The alarm notification contains detailed tenant information, certificate type, and verification failure frequency.

[0065] After receiving the alarm notification, the system administrator or relevant tenant will investigate and handle the problem. After the processing is completed, the processing results will be fed back to the system so that subsequent operations such as resetting the fuse mechanism or adjusting the threshold can be performed.

[0066] 2.5 Step S5, subsequent processing flow:

[0067] If steps S2 to S4 are all passed, the subsequent double-certificate verification and / or manual review process will be entered. Otherwise, the user will be prompted to re-enter or upload the correct information.

[0068] (III) Mechanism for solving technical problems:

[0069] 3.1 Multi-tenant customized verification mechanism:

[0070] Provide an independent verification rule configuration interface for different tenants, allowing tenants to customize verification rules according to their own business needs, including field mandatory, format requirements, length restrictions, etc.

[0071] The system dynamically loads and applies the corresponding verification rules based on the tenant information associated with the user when logging in, ensuring that the data verification process meets the specific requirements of the tenant.

[0072] Supports version management of verification rules, allowing tenants to update and roll back rule versions at any time to ensure the continuity and stability of the verification logic.

[0073] 3.2 Automatic error correction mechanism:

[0074] Using natural language processing (NLP) technology, intelligent analysis of input data is performed to identify common input errors, such as OCR recognition errors and irregular formats. According to the preset error correction strategy library, the identified errors are automatically corrected. For example, the lowercase letters in the ID card number are automatically converted to uppercase, and extra spaces in the name are removed. For errors that cannot be automatically corrected or suspected complex situations, the system provides a manual review interface to allow manual intervention for final judgment and processing.

[0075] 3.3 Feedback adjustment and verification mechanism:

[0076] When the frequency of data verification failures for a certain type of certificate under a certain tenant increases abnormally, the system automatically triggers the fuse mechanism, temporarily skips the verification process for this type of certificate, and sends an alarm notification to the system administrator or relevant tenant. At the same time, the system dynamically adjusts the verification logic and strategy based on historical data and real-time conditions to reduce misjudgments and missed judgments. Based on the results of feedback adjustment and actual user feedback, the verification strategy library and error correction strategy library are continuously optimized and iterated to improve the system's intelligence level and user satisfaction.

[0077] In the second aspect, a data verification system for online car-hailing services for SaaS multi-tenants includes:

[0078] (1) An application end used for data entry, display of verification results, and provision of user feedback channels;

[0079] (2) It is used to receive data from the application end, execute multi-tenant customized verification rules, automatic error correction processing and feedback adjustment verification mechanism, and return the processing results to the SaaS server end of the application end;

[0080] (3) The database side is responsible for storing and managing all system data: including user information, verification rules, verification history, etc.

[0081] The application end includes a user interface module for providing an input interface, a verification result display module for instantly displaying the result of data verification, and a user feedback channel for setting a user feedback entry;

[0082] The SaaS server includes a multi-tenant customized verification module that loads and applies corresponding verification rules, an automatic error correction module that identifies and corrects common errors, and a feedback adjustment verification module that dynamically adjusts the verification logic and strategy according to feedback results;

[0083] The database end includes a relational database for storing structured data and a non-relational database for storing unstructured or semi-structured data.

[0084] Compared with the prior art, the present invention has the following beneficial effects:

[0085] 1. Improve data verification efficiency: The present invention reduces unnecessary data verification processes by implementing multi-tenant customized verification rules, making verification more accurate and efficient. The automatic error correction mechanism of the present invention can instantly identify and correct common data entry errors, avoiding the tedious process of manual repeated verification and modification, and significantly improving the pass rate of data verification.

[0086] 2. Improve user experience: The customized verification rules of the present invention meet the unique needs of different tenants, making the data entry and verification process more in line with the user's actual business scenario and improving user satisfaction. The automatic error correction and feedback adjustment mechanism of the present invention reduces errors and obstructions in the data verification process, allowing drivers and vehicle managers to complete the settlement process more smoothly.

[0087] 3. Improve the intelligence level of the system: By introducing natural language processing technology, the present invention can intelligently identify and correct data entry errors, demonstrating a high level of intelligence. The feedback adjustment mechanism enables the system to dynamically adjust the verification logic and strategy according to the actual application situation, and continuously optimize and improve the data verification function.

[0088] 4. Reduce operating costs: The improved automation of the present invention reduces the workload of manual data verification and reduces the operating costs of the online car-hailing aggregation platform. The improved data verification efficiency also enables the platform to process driver and vehicle entry applications more quickly, improving overall operating efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0089] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or technical descriptions will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0090] Figure 1 This is a logic diagram of a method according to Embodiment 1 of the present invention;

[0091] Figure 2 It is a logic diagram of the traditional verification method;

[0092] Figure 3 This is a schematic diagram of the verification logic of the first embodiment of the present invention;

[0093] Figure 4 This is a schematic diagram of the system composition of the second embodiment of the present invention. DETAILED DESCRIPTION

[0094] In order to make the above-mentioned purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are described in detail below in conjunction with the accompanying drawings. In the following description, many specific details are set forth to facilitate a full understanding of the present invention. However, the present invention can be implemented in many other ways different from those described herein, and those skilled in the art can make similar improvements without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below;

[0095] It should be noted that the various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments, and the same or similar parts between the various embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description.

[0096] Terminology explanation:

[0097] (1) Multi-tenancy: A ride-hailing service provider can be considered as a tenant in the system.

[0098] (2) Personal identification: the driver’s ID card, driver’s license and online car-hailing driver’s license.

[0099] (3) Vehicle certificates: vehicle driving license, online car-hailing transport license, compulsory traffic insurance and commercial insurance.

[0100] (4) VIN code: The full name is Vehicle Identification Number, which is a unique code consisting of 17 English letters and numbers. It is used to identify the specific information of a vehicle. The VIN code is equivalent to the "identity card" of the car. It is unique and can be used to identify vehicles worldwide.

[0101] (5) Verification of two certificates: The online ride-hailing aggregation platform will review and verify the authenticity of the online ride-hailing driver’s license and the online ride-hailing transport license to ensure the validity and compliance of the certificates.

[0102] (6) OCR: Optical Character Recognition, a technology that uses recognition software to convert text in an image into text format for further editing and processing by word processing software. When drivers and vehicles join the online ride-hailing platform, the uploaded ID and vehicle certificates are analyzed by OCR software, and the values ​​of the fields in each certificate are extracted to form structured data, which is convenient for the platform's subsequent processing and storage.

[0103] (7) Verification rules: The platform can configure policies to determine whether verification is enabled for each input field of each type of information (driver, vehicle, ID card, and vehicle ID card).

[0104] (7) SaaS server: SaaS platform is a software delivery model based on cloud computing, also known as "software as a service". In the SaaS model, software vendors deploy software applications on cloud servers and provide services to users through the Internet.

[0105] Embodiment 1: Figure 1 and 3 As shown, this embodiment will provide a method for verifying online car-hailing data for SaaS multi-tenants, including the following execution steps.

[0106] In this embodiment, regarding step S1, data entry and preliminary verification:

[0107] Specifically, step S100, data entry and format verification: In the user interface of the online car-hailing aggregation platform, the driver or vehicle manager needs to enter key information including ID number, name, license plate number, engine number, vehicle owner and VIN code. The application end will perform preliminary data format verification.

[0108] For example, check whether the ID number is composed of 18 digits, whether the license plate number conforms to the local format, whether the VIN code is a combination of 17 letters and numbers, etc. If the data format does not meet the requirements, the system will immediately display an error prompt to the user and require re-enter the correct information.

[0109] Specifically, step S101, data encryption and secure transmission: the input data is encrypted on the application side to ensure the security of the data during transmission. The encrypted data is securely sent to the SaaS server of the online car-hailing aggregation platform via the HTTPS protocol.

[0110] In this embodiment, regarding step S2, the multi-tenant customized verification rules are applied:

[0111] Specifically, step S200, identifying the tenant to which the user belongs: after the user data is transmitted to the SaaS server, the system accurately identifies the tenant to which the user belongs through the tenant identifier or tenant context information used when the user logs in.

[0112] Specifically, step S201, loading and applying customized validation rules: according to the tenant to which the user belongs, the SaaS server loads the corresponding customized validation rules from the configuration file on the database side. These rules define in detail the specific requirements for data validation under the tenant, such as format, length, and required items.

[0113] Specifically, in step S202, customized verification is performed: the data entered by the user is compared one by one to ensure that each data meets the verification standard specific to the tenant.

[0114] For example, for a specific online ride-hailing aggregation platform tenant, its customized verification rules may include: the ID number must be 18 digits and start with a specific number, the license plate number must comply with the format requirements of the region, the engine number cannot be empty and must be between 6 and 10 digits long, the vehicle owner field must be filled in and cannot contain special characters, and the VIN code must be 17 digits and comply with international standard formats. For another tenant, depending on the regional characteristics of the data information it provides, the verification rules may be different, such as the ID number allows 15 or 18 digits, and the license plate number format requirements are different.

[0115] Specifically, step S203, verification result processing and feedback: if the data does not meet the customized verification rules, an error prompt is generated, and the specific fields and reasons that do not meet the rules are indicated. The error prompt will be returned to the application end so that the user can make necessary modifications and resubmit. If the data meets the customized verification rules, it will enter step S3 for further processing.

[0116] In this embodiment, regarding step S3, the automatic error correction processing mechanism is activated:

[0117] Specifically, steps S300-S304 automatically correct the input data: using natural language processing (NLP) technology, the system performs intelligent analysis on the input data, and identifies and corrects common errors according to preset error correction strategies.

[0118] Furthermore, S300-S304 include:

[0119] Step S300, correcting the ID card number: checking whether there are lowercase letters in the ID card number, if so, automatically converting them to uppercase letters. Checking whether there are spaces in the ID card number, if so, automatically clearing the spaces.

[0120] Step S301, correct the name field: check whether there is a space in the name field, if so, automatically clear the space. Check the symbol in the name field, if it is ".", ".", "·" or "·", automatically convert it to a full-width spacer "·".

[0121] Step S302, correct the engine number: check whether there is "-", "—" or "_" in the engine number, if so, convert it to a minus sign "-".

[0122] Step S303, correct the vehicle owner field: check whether there are half-width brackets "(" or ")" in the vehicle owner field. If so, automatically convert them to full-width brackets "()".

[0123] For example, the system checks whether there are lowercase letters or spaces in the ID number, and automatically converts or clears them; checks the symbols in the name field, and uniformly converts them into full-width separators; checks the separators in the engine number, and uniformly converts them into minus signs; checks the brackets in the vehicle owner field, and converts them into full-width brackets; at the same time, the system also checks whether there are any cases in which "0" is incorrectly identified as "O" in the license plate number and VIN code, and repairs them.

[0124] Specifically, step S305, error correction result processing and database update: recheck the corrected data and update the corrected data to the database. When all error correction steps are completed and no error occurs, proceed to step S4 for subsequent processing.

[0125] In this embodiment, regarding step S4, a feedback adjustment verification mechanism is executed:

[0126] Specifically, step S400, recording the verification results: recording the results of each data verification in detail in the data verification history information library, including the verification time, tenant information, certificate type, verification results and specific reasons for failure, etc.

[0127] Specifically, steps S401-S402, monitor and analyze historical verification data and set thresholds: regularly monitor and analyze the data verification history information library, and count the verification failure frequencies of different types of certificates under each tenant. At the same time, according to business needs and historical data, set reasonable verification failure frequency thresholds for different certificate types, and perform real-time detection.

[0128] Specifically, steps S403-S404 trigger the fuse mechanism and alarm notification: if it is found that the frequency of verification failure of a certain type of certificate data under a certain tenant exceeds the set threshold, the system will automatically trigger the fuse mechanism, skip the subsequent verification steps of this type of certificate, and record relevant logs. At the same time, both the SaaS server and the application will send alarm notifications to the system administrator and related tenants to handle potential problems in a timely manner.

[0129] In this embodiment, regarding step S5, the subsequent processing flow: if steps S2 to S4 are all passed successfully, the data will enter the subsequent double-certificate verification or manual review process. Otherwise, the system will prompt the user to re-enter or upload the correct information.

[0130] In this embodiment, the execution procedure of the application front end is as follows:

[0131]

[0132]

[0133]

[0134] The above procedures include:

[0135] (1) Flask application: The code uses the Flask framework to create a web application that includes a homepage (index) and an endpoint for submitting data (submit).

[0136] (2) Data encryption: Before sending data to the SaaS server, the Fernet class of the cryptography library is used to encrypt the data. The encryption key is pre-defined and obtained from environment variables or configuration files.

[0137] (3) HTTPS communication: Use the requests library to send encrypted data to the SaaS server via the HTTPS protocol.

[0138] (4) Data decryption and processing: After receiving the response from the SaaS server, the data is decrypted using the same encryption key and processed accordingly based on the response content from the server.

[0139] (5) Web interface: index.html is an HTML form where users can enter data. When the form is submitted, the data is sent to the / submit endpoint.

[0140] (6) Error handling: If the SaaS server returns verification errors, these errors will be decrypted and displayed to the user.

[0141] (7) SSL context: During development, to test HTTPS, app.run used ssl_context = 'adhoc' to generate a self-signed SSL certificate. A valid SSL certificate should be used in a production environment.

[0142] In this embodiment, the execution procedure of the SaaS server is as follows:

[0143]

[0144]

[0145]

[0146] The above procedures include:

[0147] (1) Flask application: The code uses the Flask framework to create an API endpoint / api / validate to receive POST requests.

[0148] (2) Data decryption: After receiving the encrypted data, the data is decrypted using the same encryption key as the front end.

[0149] (3) Data validation: Validate data according to predefined customized validation rules. If the data does not meet the rules, error information will be collected.

[0150] (4) Build response: Build a response based on the verification result. If the data verification passes, a successful response and data are returned; if the data verification fails, an error list is returned.

[0151] (5) SSL context: During development, to test HTTPS, app.run used ssl_context = 'adhoc' to generate a self-signed SSL certificate. A valid SSL certificate should be used in a production environment.

[0152] (6) Regular expression: Regular expressions are used in validation rules to define the format of a field. If a field value does not conform to the format defined by the regular expression, it will be considered an error.

[0153] (7) Required fields check: Validation rules also define which fields are required. If a required field is missing or empty, it will be considered an error.

[0154] Embodiment 2: Figure 4 As shown, based on the first embodiment, this embodiment further discloses a SaaS multi-tenant-oriented online car-hailing data verification system, including:

[0155] (1) An application end used for data entry, display of verification results, and provision of user feedback channels;

[0156] Its components include:

[0157] (1.1) A user interface module that provides an input interface: allowing the driver or vehicle manager to enter key information such as ID number, name, license plate number, engine number, etc.

[0158] (1.2) A verification result display module that instantly displays the results of data verification: including the specific reasons for passing or failing and the operations required by the user (such as re-entering or uploading correct information).

[0159] (1.3) Set up a user feedback channel: collect users’ opinions and suggestions on the data verification process in order to continuously optimize and improve it.

[0160] (2) SaaS server that receives data from the application, executes multi-tenant customized verification rules, automatic error correction processing and feedback adjustment verification mechanism, and returns the processing results to the application;

[0161] Its components include:

[0162] (2.1) Multi-tenant customized verification module that loads and applies corresponding verification rules: Dynamically loads and applies corresponding verification rules according to the tenant to which the user belongs, ensuring that the data verification process meets the specific requirements of the tenant.

[0163] (2.2) Automatic error correction module that identifies and corrects common errors: It uses a preset error correction strategy library to intelligently analyze input data, identify and correct common errors, and stores the models and algorithms required for natural language processing (NLP) technology.

[0164] (2.3) Feedback adjustment verification module that dynamically adjusts verification logic and strategy based on feedback results: real-time monitoring and analysis of verification history records, dynamically adjusting verification logic and strategy based on feedback results to reduce misjudgments and missed judgments.

[0165] (3) The database side responsible for storing and managing all data of the system: including user information, verification rules, verification history records, etc.;

[0166] Its components include:

[0167] (3.1) Relational database used to store structured data: such as user information, vehicle information, etc. Supports high-concurrency access and read-write operations to ensure the real-time and accuracy of data.

[0168] (3.2) Non-relational databases used to store unstructured or semi-structured data: such as verification rules, error correction strategies, etc. Provide flexible data models and scalability to meet complex data storage requirements.

[0169] All the above embodiments only express the implementation methods of the relevant practical applications of the present invention, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the invention patent. It should be pointed out that, for ordinary technicians in this field, several variations and improvements can be made without departing from the concept of the present invention, which all belong to the protection scope of the present invention. Therefore, the protection scope of the patent of the present invention shall be based on the attached claims.

[0170] For those skilled in the art, it can be further appreciated that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0171] At the same time, those skilled in the art can understand that all or part of the processes in all the above-mentioned embodiments can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, storage, database or other media provided in this application and used in the embodiments may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM) or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (SSRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

Claims

1. A method for verifying online car-hailing data for SaaS multi-tenants, characterized in that: The following steps are included: S1, input user data information on the interface of the online car-hailing aggregation platform; S2, according to the tenant to which the current user belongs, load the corresponding customized verification rules; perform preliminary verification of the format, length and required items of the entered data; S3, uses NLP technology to automatically correct the input data, identifying and correcting common errors according to preset strategies; S4, recording the result of data verification into the data verification history information library; S5: If steps S2 to S4 are all passed, the double certificate verification and / or manual review process will be entered; otherwise, the user will be prompted to re-enter or upload the correct information.

2. The online car-hailing data verification method according to claim 1, characterized in that: In S1, the data information includes identity card number, name, license plate number, engine number, vehicle owner and VIN code information; the application end performs preliminary data format verification.

3. The online car-hailing data verification method according to claim 2, characterized in that: In S1, the data entered by the user is encrypted on the application side and sent to the SaaS server of the online car-hailing aggregation platform via the HTTPS protocol.

4. The online car-hailing data verification method according to claim 1, characterized in that: The implementation method of S2 includes: S200, after the user data is entered and transmitted to the SaaS server, the tenant to which the user belongs is identified; S201, the SaaS server loads the corresponding customized verification rules from the configuration file on the database side; S202, verification rules cover the format, length and mandatory requirements of key fields such as ID number, license plate number, engine number, vehicle owner and VIN code; S203, if the data does not conform to the customized verification rules of S202, an error prompt is generated, and the specific fields and reasons that do not conform to the rules are pointed out; the error prompt will be returned to the application end.

5. The online car-hailing data verification method according to claim 4, characterized in that: In the S203, the customized verification rules include the number of digits in the ID number and its specific digits at the beginning, the regional format requirements of the license plate number, the engine number cannot be empty and the length must be between 6 and 10 digits or optional, the vehicle owner field is allowed or not allowed to contain a specific prefix or suffix, and the VIN code must be 17 digits or is not a required item but must comply with the format when filled in.

6. The online car-hailing data verification method according to claim 1, characterized in that: The implementation method of S3 includes: S300, checking whether there are lowercase letters in the ID number; if so, automatically converting them to uppercase letters; checking whether there are spaces in the ID number; if so, automatically clearing the spaces; S301, checking whether there is a space in the name field; if so, automatically clearing the space; S302, check whether there is "-", "—" or "_" in the engine number, if so, convert it to a minus sign "-"; S303, check whether there is a half-width bracket "(" or ")" in the vehicle owner field. If so, automatically convert it to a full-width bracket "()"; S304, check whether there is a situation where "0" is mistakenly recognized as "O" in the license plate number and VIN code. If so, repair it to "0".

7. The online car-hailing data verification method according to claim 6, characterized in that: The implementation method of S3 further includes re-executing S300 to S304 on the corrected data; at the same time, updating the corrected data to the database end; when S300 to S304 are executed again and no error occurs, entering S4.

8. The online car-hailing data verification method according to claim 1, characterized in that: In the S4, it also includes triggering a fuse mechanism: if it is found that the verification failure frequency of a certain type of certificate data under a certain tenant exceeds the set threshold, the fuse mechanism is automatically triggered to skip the subsequent verification steps of this type of certificate, directly regard it as verification failure, and record relevant logs.

9. A SaaS multi-tenant oriented online car-hailing data verification method for executing the online car-hailing data verification method according to any one of claims 1 to 8, characterized in that: include: The application end is used for data entry, display of verification results, and provision of channels for user feedback; It is used to receive data from the application side, execute multi-tenant customized verification rules, automatic error correction processing and feedback adjustment verification mechanism, and return the processing results to the SaaS server side of the application side; The database side is responsible for storing and managing all data of the system.

10. The online car-hailing data verification system according to claim 9, characterized in that: The application end includes a user interface module that provides an input interface, a verification result display module that instantly displays the result of data verification, and a user feedback channel that sets a user feedback entry; The SaaS server includes a multi-tenant customized verification module that loads and applies corresponding verification rules, an automatic error correction module that identifies and corrects common errors, and a feedback adjustment verification module that dynamically adjusts the verification logic and strategy according to feedback results; The database end includes a relational database for storing structured data and a non-relational database for storing unstructured or semi-structured data.

Images