An insurance application information automatic filling and checking method, system, product and medium

Abstract

The application discloses a kind of automated filling and checking method, system, product and medium of insurance information, and it is related to artificial intelligence field.The method comprises the following steps: in response to batch insurance instruction, the insured identity information is received and managed, and the independent data object is constructed to form the insured information set;Age is calculated by traversing the set and analyzing birth date;Age is used as a matching factor, matched with an insurance product rule base, to determine the applicable product plan range and premium calculation factor;Generate and bind a differentiated rule set for each data object;Based on context and differentiated rule set, generate an aggregated interactive interface;Receive input information in the exclusive problem area, and check according to the differentiated rule set;All input information that passes the check is summarized to generate an aggregated insurance order.Implementation of the technical solution provided in the application improves the efficiency of automated processing in the batch insurance scenario.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence, and in particular to a method, system, product, and medium for automatically filling and verifying insurance information. Background Technology

[0002] Currently, individuals and families are significantly more aware of risk protection, and insurance, as a risk management tool, is experiencing a continuous increase in market penetration. With the booming development of the digital economy, online insurance purchase has become the mainstream channel for users to access insurance services. To optimize user experience and improve business efficiency, building automated and intelligent online insurance purchase processes is particularly important for the digital transformation of the insurance industry.

[0003] In related technologies, the automated insurance application information filling and verification method first uses Optical Character Recognition (OCR) technology to extract key information such as name and ID number from the user's uploaded ID document image and automatically fills it into the corresponding fields. Then, a dynamic question-answering engine is activated, presenting relevant questions to the user in a progressive manner based on the filled-in information such as age and gender, and performing real-time format verification on each user input to guide the user through the insurance application process.

[0004] However, when dealing with insurance scenarios involving one-to-many relationships, such as a single policyholder insuring multiple family members, the single-session architecture, designed around independent, stateless single transactions, tends to break down the task of insuring multiple insured individuals into multiple independent processes. In this process, the policyholder's public information needs to be repeatedly submitted and verified in each session, and the differences in data and rules between insured individuals force the system to initiate entirely new question-and-answer and verification sequences for each individual. This approach leads to data redundancy and fragmented contextual information, thereby increasing the overall operational complexity and time cost, and reducing the overall efficiency of automated data entry and verification. Summary of the Invention

[0005] This application provides a method, system, product, and medium for automated filling and verification of insurance information, which can improve the efficiency of automated processing in batch insurance application scenarios.

[0006] The first aspect of this application provides a method for automatically filling in and validating insurance information, the method comprising:

[0007] In response to a batch insurance application instruction, the system initiates a batch insurance application session and establishes an insurer data context for storing common information about the insured. It receives and manages the identity information of the insured, constructing each insured's identity information as an independent data object, thus obtaining an insured information set. It iterates through all data objects in the insured information set, extracts the ID card number, and parses the insured's date of birth based on the ID card number to calculate the insured's age. Using age as a matching factor, it matches the data with a pre-defined insurance product rule base to determine the applicable product plan scope and premium calculation factor for each data object. It generates and binds a differentiated rule set for each data object. Based on the insurer data context and the differentiated rule set bound to each data object, it generates an aggregated interactive interface. It receives input information for a dedicated question area and validates the input information according to the differentiated rule set. It summarizes all validated input information and, combined with the insurer data context and the insured information set, generates an aggregated insurance application order.

[0008] In the above embodiments, by establishing the policyholder context, constructing the insured data object, and generating a differentiated rule set based on age and rule base matching, personalization for each insured is achieved. Furthermore, by generating an aggregated interactive interface, verification is performed in a dedicated question area based on the differentiated rule set, ultimately summarizing and generating an aggregated insurance order, improving the efficiency, accuracy, and user experience of batch insurance information processing.

[0009] In conjunction with some embodiments of the first aspect, in some embodiments, the identity information of the insured is received and managed, and the identity information of each insured is constructed into an independent data object to obtain a set of insured information, specifically including:

[0010] The system receives the insured's identity information and constructs it into a data object. For each data object, it receives the relationship type between the insured and the policyholder. It matches the relationship type with a pre-defined insurance benefit rule base to determine whether the insured meets the insurance benefit requirements. If so, the relationship type is stored in the data object. If not, the data object is marked as unqualified and prevented from entering the subsequent process. All data objects that are not marked as unqualified are collected to obtain the insured's information set.

[0011] In the above embodiments, by receiving the insured's identity information and obtaining the relationship type with the policyholder, and then matching it with a preset insurance benefit rule base, automated judgment of insurance eligibility is achieved. This enables the early identification and prevention of ineligible data objects from entering subsequent processes, reducing invalid processing and resource waste, and improving the overall efficiency, accuracy, and compliance of batch insurance applications.

[0012] In conjunction with some embodiments of the first aspect, in some embodiments, after aggregating all data objects not marked as unqualified to obtain the insured information set, the method further includes:

[0013] For all data objects, group them according to relation type; for each relation type group, identify the public information collection items associated with the relation type from the insurance product rule base; if the relation type group contains multiple data objects, generate an aggregated input interface for the public information collection items; receive the public information input from the user in the aggregated input interface for the public information collection items, and populate the public information input into the fields corresponding to all data objects in the corresponding group; update the collected data objects that have completed public information collection to the insured information set.

[0014] In the above embodiments, the insured groups that may share information during batch insurance applications and the shared content are located. Furthermore, users are allowed to input public information once, which is then automatically populated into all relevant data objects. This reduces the workload of repetitive data entry, improves the efficiency and accuracy of data entry, reduces the user's operational burden and error rate, thereby optimizing the user experience and overall processing efficiency of batch insurance applications.

[0015] In conjunction with some embodiments of the first aspect, in some embodiments, an aggregated interactive interface is generated based on the policyholder data context and the differentiated rule set bound to each data object, specifically including:

[0016] Based on the policyholder's data context and the differentiated rule set bound to each data object, an aggregated interactive interface is generated. In the question area containing multiple alternative plan data objects, an interactive element that triggers the alternative plan comparison function is embedded. In response to the trigger command of the interactive element, the detailed coverage and key differences of the multiple alternative plan data objects are extracted from the insurance product rule base. A comparison view is generated that displays the detailed coverage and key differences in parallel. The comparison selection results in the comparison view are updated to the corresponding data objects.

[0017] In the above embodiments, by embedding comparison trigger elements for insured individuals with multiple alternative plans in the aggregated interface, users can actively initiate comparisons. Detailed coverage and key differences are extracted and displayed side-by-side, transforming complex information into an intuitive view. This reduces the difficulty for users to understand and choose, improving the efficiency, accuracy, and user satisfaction of complex decision-making in batch insurance scenarios.

[0018] In conjunction with some embodiments of the first aspect, in some embodiments, after updating the comparison selection result in the comparison view to the corresponding data object, the method further includes:

[0019] Based on a pre-defined combination insurance rule base, identify groups of combined data objects in the insured information set that have interdependent or combined preferential conditions; generate combination insurance schemes for the combined data object groups, with each combination insurance scheme containing a selected product plan for each data object within the combination data object group; calculate the overall premium, overall protection benefits, and any combined preferential conditions for each combination insurance scheme; generate a combination scheme comparison view that displays the combination insurance schemes side by side; and update the selection results from the received combination scheme comparison view to the product plan selection field corresponding to each data object in the data object group.

[0020] In the above embodiments, potential combined insurance opportunities are identified. By generating and calculating multiple insurance plans for these combinations, the system quantifies complex combination decisions and then displays a comparative view of these plans side-by-side. Policyholders can intuitively and comprehensively evaluate the advantages and disadvantages of different combinations, reducing the difficulty of manual calculation and comparison. This not only helps policyholders efficiently select the most cost-effective or suitable combination plan, avoiding missing out on benefits, but also improves the intelligence level and overall value of bulk insurance.

[0021] In conjunction with some embodiments of the first aspect, in some embodiments, input information for a specific problem region is received, and the input information is validated according to a differentiated rule set, specifically including:

[0022] The system receives input information for each dedicated question area within the aggregated interactive interface; identifies complex validation fields in the input information and distinguishes them from real-time validation fields; performs real-time validation on real-time validation fields based on a differentiated rule set and provides real-time feedback; for complex validation fields, it submits the input information and the corresponding differentiated rule set to the asynchronous validation service and provides real-time status feedback during the validation process; in the asynchronous validation service, it executes complex validation tasks in parallel; when a complex validation task is completed, it asynchronously pushes the validation result to the aggregated interactive interface and updates the display status of the dedicated question area based on the result.

[0023] In the above embodiments, real-time validation and feedback are provided based on a differentiated rule set, ensuring the user's ability to correct errors instantly during the input process and improving the accuracy and fluency of data entry. For complex validation fields that take a long time to process, the user interface is prevented from being blocked for extended periods, improving the system's response speed and the continuity of user operations, ensuring that users can obtain the final validation results promptly. This balances the rigor of validation with the smoothness of the user experience, improving the efficiency, accuracy, and user satisfaction of data input in batch insurance application scenarios.

[0024] In conjunction with some embodiments of the first aspect, in some embodiments, the identity information of the insured is received and managed, and the identity information of each insured is constructed into an independent data object to obtain a set of insured information, specifically including:

[0025] The system receives the insured's identity information and constructs it into an independent data object. Based on the identity information in the data object, a unique insured identification code is generated. The insured identification code is used to check for duplicates within the insured information set. If duplicate data objects are found, they are merged into a single data object. The insured identification code is used to query the existing customer database. If a matching existing customer record is found, the data object is associated with the existing customer record, and the historical association information related to this insurance application is extracted from the existing customer record. The historical association information and the data object are then combined to form the insured information set.

[0026] In the above embodiments, the mechanism of deduplication and historical data association is integrated to ensure that the final collection of insured information is accurate and free of redundancy, thereby providing a high-quality data foundation for subsequent underwriting, risk assessment and product matching, and improving the intelligence level and decision support capabilities of batch insurance.

[0027] Secondly, embodiments of this application provide an automated insurance information filling and verification system, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, which includes computer instructions, and the one or more processors call the computer instructions to cause the automated insurance information filling and verification system to perform the method described in the first aspect and any possible implementation thereof.

[0028] Thirdly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on an automated insurance information filling and verification system, causes the automated insurance information filling and verification system to execute the method described in the first aspect and any possible implementation thereof.

[0029] Fourthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on an automated insurance information filling and verification system, cause the automated insurance information filling and verification system to perform the method described in the first aspect and any possible implementation thereof.

[0030] Understandably, the automated insurance information filling and verification system provided in the second aspect, the computer program product provided in the third aspect, and the computer storage medium provided in the fourth aspect are all used to execute the automated insurance information filling and verification method provided in the embodiments of this application. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods, and will not be repeated here.

[0031] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages:

[0032] 1. This application achieves personalization for each insured by establishing a policyholder context, constructing insured data objects, and generating differentiated rule sets based on age and a rule base. Furthermore, by generating an aggregated interactive interface, verification is performed in a dedicated question area according to the differentiated rule sets, ultimately summarizing and generating aggregated insurance orders, thus improving the efficiency, accuracy, and user experience of batch insurance information processing.

[0033] 2. This application achieves automated assessment of eligibility for insurance by receiving the insured's identity information and obtaining the relationship type with the policyholder, and then matching it with a pre-defined insurance benefit rule base. This enables the early identification and prevention of ineligible data objects from entering subsequent processes, reducing invalid processing and resource waste, and improving the overall efficiency, accuracy, and compliance of batch insurance applications.

[0034] 3. This application identifies the insured groups who may share information during batch insurance applications and the information they share. This allows users to input public information once, which is then automatically populated into all relevant data objects. This reduces repetitive data entry, improves data entry efficiency and accuracy, lowers user workload and error rates, and thus optimizes the user experience and overall processing efficiency for batch insurance applications. Attached Figure Description

[0035] Figure 1 This is a flowchart illustrating an automated insurance information filling and verification method in an embodiment of this application.

[0036] Figure 2 This is another flowchart illustrating the automated filling and verification method for insurance information in this application embodiment;

[0037] Figure 3 This is an exemplary hardware structure diagram of an automated insurance information filling and verification system in the embodiments of this application. Detailed Implementation

[0038] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to and includes any or all possible combinations of one or more of the listed items.

[0039] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0040] In related technologies, automated insurance information filling and verification methods are typically designed around a single insured individual. Identification information is extracted using technologies such as Optical Character Recognition (OCR), and a series of question-and-answer processes are initiated to perform real-time format verification of user input. However, in "one-to-many" batch insurance scenarios where the same policyholder insures multiple insured individuals, each insured individual is often treated as an independent application process. This results in the need for the policyholder's common information (such as contact information and payment methods) to be repeatedly entered and verified for each insured individual. Furthermore, each insured individual, due to differences in age, health status, etc., triggers independent rule matching and question sequences. This model leads to a large number of repetitive operations, data redundancy, and fragmented contextual information, increasing the operational burden and time cost for policyholders, and reducing overall application efficiency and user experience.

[0041] In this embodiment, by responding to batch insurance application instructions, a "policyholder data context" is first established to store common information, avoiding duplicate data entry. Simultaneously, each insured person is constructed as an "independent data object," forming an "insured person information set," laying the foundation for batch processing. Crucially, these data objects are traversed, age is calculated based on identity information, and this age is used as a matching factor to "generate and bind a differentiated rule set" for each data object, determining the applicable product plan and premium factor. Finally, by "generating an aggregated interactive interface," the exclusive question areas for all insured persons are integrated and presented, and verification is performed according to their respective differentiated rule sets. This achieves efficient and personalized processing of multiple insured persons within a single interface, improving the efficiency of batch insurance applications and the user experience.

[0042] Figure 1 This is a flowchart illustrating the automated filling and verification method for insurance information in this application, including the following steps:

[0043] S101. Respond to the batch insurance application instruction, start the batch insurance application session, and establish an insurance application data context for storing common information of the insurance policyholders.

[0044] Among them, a batch insurance application instruction refers to an instruction issued by a user through a front-end interface or API interface, requesting to apply for insurance for multiple insured persons simultaneously; a batch insurance application session refers to an independent business process instance created in response to a batch insurance application instruction, used to manage all relevant data and operations for this batch insurance application; policyholder public information refers to information shared by all insured persons in a batch insurance application that is related to the policyholder, such as the policyholder's name, contact information, payment account, etc.; policyholder data context refers to a data storage area used to persist and transmit policyholder public information throughout the entire batch insurance application session. The default method is designed based on insurance business needs and data models, and is derived and configured by those skilled in the art.

[0045] Specifically, when a user clicks "Start Batch Insurance Purchase" at the batch insurance purchase portal on the insurance platform or triggers the batch insurance purchase process through other means, this instruction will be the first thing to respond to.

[0046] Upon response, a new, independent batch insurance application session is initiated to ensure that this batch insurance application operation is isolated from other business processes and can be independently managed in terms of lifecycle and status. Simultaneously with the initiation of this session, a dedicated policyholder data context is established. This context collects and stores the policyholder's (i.e., the user initiating this batch insurance application) common information, typically including basic identification information, contact details, payment preferences, etc. This information is common to all insured persons in this batch insurance application. By establishing this context, duplicate policyholder information can be avoided when processing information for each insured person later, thereby improving data entry efficiency and consistency. This context serves as a shared data source throughout the entire batch insurance application process, ensuring that all subsequent operations can access consistent common policyholder information.

[0047] S102. Receive and manage the identity information of the insured, and construct each insured's identity information into an independent data object to obtain a set of insured information.

[0048] Among them, the insured's identity information refers to the basic information required to identify the individual insured and to process subsequent insurance business, such as name, ID number, gender, date of birth, etc.; an independent data object refers to a data structure instance created for each insured that encapsulates all relevant information and can be operated and managed independently, usually existing in the form of a class instance in object-oriented programming; the insured information set refers to the list of insureds used for this batch of insurance applications, which consists of all these independent data objects. The default method is designed according to the insurance business requirements and data model, and is derived and configured by those skilled in the art.

[0049] Specifically, the system receives the identity information of all insured persons provided by the policyholder. This information can be submitted in various forms, such as manual entry, batch import via Excel templates, or batch transmission via API. The received insured person identity information is parsed and constructed into independent, standardized data objects. Each data object encapsulates all the basic identity attributes of the insured person, such as name, ID number, gender, and contact information. By constructing each insured person's information as an independent data object, each insured person's information is processed, validated, and matched against rules using a unified format and method, while maintaining data integrity and manageability.

[0050] All the individual data objects will eventually be aggregated to form a set of insured information, which will serve as the core processing data source for this batch insurance application session.

[0051] In some embodiments, in batch insurance scenarios, when there is a specific relationship between the insured and the policyholder and some information can be shared, pre-processing relationship type verification, intelligent grouping, and public information aggregation can be used to reduce duplicate data entry and improve the accuracy and efficiency of information collection.

[0052] Specifically, the process begins immediately upon receiving the insured's identity information submitted by the policyholder. First, the insured's identity information is received and constructed into a data object, ensuring that each insured's information is standardized and encapsulated for easy subsequent processing.

[0053] Next, for each data object, the relationship type between the insured and the policyholder is received. For example, when entering insured information, the user will specify whether the insured is the policyholder's "spouse," "child," "parent," or "themselves." This relationship type is the basis for subsequent validation and intelligent population.

[0054] Subsequently, the relationship type is matched against a pre-defined insured benefit rule base to determine whether the insured meets the insured benefit requirements. This pre-defined insured benefit rule base refers to a set of business rules that include restrictions on the relationship between the policyholder and the insured, as well as insured benefits available under specific relationships (such as family single-insurance discounts, specific coverage scopes). These rules are pre-defined by underwriting experts and product managers based on the insurance company's underwriting policies, product design specifications, and relevant laws and regulations, and then transformed into an executable rule set by those skilled in the art. For example, the rule base might stipulate that "the policyholder can only insure immediate family members" or "children as insured persons can enjoy family supplementary insurance." This matching determines whether the insured meets the insured benefit requirements. If yes, the relationship type is stored in a data object for use in subsequent processes. If not, the data object is marked as ineligible and prevented from proceeding to the next step. For example, if an applicant attempts to insure a non-relative, the insured is marked as ineligible and removed from the list of valid applications for this batch. This avoids further invalidation of insureds who do not meet the eligibility criteria, improving processing efficiency and reducing compliance risks. All data objects not marked as ineligible are aggregated to obtain an insured information set, which is a list of valid insureds determined through preliminary screening and relationship type criteria.

[0055] Next, to further optimize information collection efficiency, all data objects are grouped according to relationship type. For example, all "children" will be grouped into one group, and all "parents" will be grouped into another. The purpose of this grouping is to identify insured persons with common attributes or who may share information. Then, for each relationship type group, public information collection items associated with the relationship type are identified from the insurance product rule base. Public information collection items refer to information fields that multiple insured persons may share under a specific relationship type and that need to be collected uniformly during the insurance application process. For example, if multiple insured children are of similar age, they may need to fill in the same "school attended" information; if multiple family members live together, they may need to fill in the same "residential address" information. The insurance product rule base here includes not only product applicability rules but also definitions of public information collection items related to different relationship types. The default method is similar to the rule base in S104, determined by product design and business needs.

[0056] If a relational group contains multiple data objects, a aggregated input interface is generated for the common information collection items. This aggregated input interface is specifically designed for this group, centrally displaying common information collection items shared by all insured persons within the group, avoiding the need to repeatedly display and fill in the same information for each insured person. For example, if an insured person wants to insure three children who all attend the same school, an interface will be generated, displaying the "School Attended" input box only once. The system receives the common information input from the user in the aggregated input interface and populates the corresponding fields of all data objects within the group. This means that the user only needs to enter the common information once, and it will be automatically and synchronously populated into the data objects of all relevant insured persons within the group, reducing the workload of repetitive entry and improving the efficiency and consistency of data entry. Finally, the collected data objects with completed common information collection are updated to the insured person information set to ensure the integrity and accuracy of all insured person data objects, preparing for subsequent age calculations and product matching.

[0057] This step, through pre-emptive relationship type verification, enables early filtering of insured individuals who do not meet the requirements for insurance benefits, avoiding invalid processing. Simultaneously, by intelligently identifying relationship types, grouping and aggregating common information, it transforms the previously repetitive entry of shared information from multiple insured individuals into a one-time input, reducing user operations and data entry time, thereby improving the efficiency of automated processing and user experience in batch insurance scenarios.

[0058] S103. Traverse all data objects in the insured's information set, extract the ID card number, and parse the insured's date of birth based on the ID card number to calculate the insured's age.

[0059] Specifically, the process automatically iterates through each individual data object in the insured's information set. For each data object, the ID card number is extracted. Once the ID card number is successfully extracted, the insured's date of birth is parsed using the encoding rules in the ID card number (e.g., the 7th to 14th digits of a Chinese resident ID card represent the date of birth). This parsing process involves string truncation and date format conversion.

[0060] For each data object, the goal is to accurately obtain the date of birth in order to calculate the age. The methods for obtaining the date of birth may include, but are not limited to, one or more of the following:

[0061] Extracting the ID card number: The insured's date of birth is extracted using the coding rules within the ID card number. This parsing process involves string truncation and date format conversion.

[0062] Direct Entry: Receives the insured's date of birth directly entered by the user.

[0063] Other identity documents: Extract and parse the insured's date of birth from other identity documents (such as passport, household registration book, birth certificate, etc.).

[0064] Linking existing customer data: Retrieve the stored birth dates of insured individuals by linking with the existing customer database.

[0065] Subsequently, based on the current system date (i.e. the date the insurance application was submitted) and the parsed date of birth, the insured's age in full is calculated, as the underwriting conditions and premium calculations for many insurance products are closely related to the insured's age.

[0066] S104. Use age as a matching factor and match it with the preset insurance product rule base to determine the applicable product plan scope and premium calculation factor for each data object.

[0067] Among them, the matching factor refers to the key data points used to find and filter applicable rules in the rule base, specifically the insured's age; the preset insurance product rule base refers to a database or rule engine that structurally stores all business rules such as the underwriting conditions, coverage, and premium calculation logic of insurance products. The preset method is to be jointly formulated and configured by actuaries and business experts according to the insurance company's product design and underwriting requirements, and then transformed into an executable rule set by those skilled in the art; the product plan scope refers to the list of all product plans that the insured can apply for, filtered according to the insured's age and other conditions; the premium calculation factor refers to various parameters that affect the premium calculation, such as age rate, occupational surcharge, and health condition adjustment factor.

[0068] Specifically, for each data object in the insured's information set, the age calculated in step S103 will be used as the core matching factor. This age factor will then be used for matching within a pre-defined insurance product rule base.

[0069] The rule base contains detailed rules for all insurance company products, such as "a certain product plan only accepts applicants aged 0-60," "what is the premium rate for a certain age group," and "specific occupational categories require additional fees." The matching process typically involves querying and evaluating the rule base to identify all product plans that match the current insured's age. Simultaneously, based on the definitions of these product plans, premium calculation factors related to the insured's age are extracted, such as basic rate tables and age adjustment factors.

[0070] S105. Generate and bind a differentiated rule set for each data object.

[0071] The differentiated rule set refers to a set of exclusive business rules customized for each individual insured person based on specific attributes (such as age) and the matching results of step S104. It includes the scope of product plans and premium calculation factors. The scope of product plans refers to the list of all product plans that the insured person can purchase, as determined in step S104. The premium calculation factors refer to the various parameters that affect the premium calculation for the insured person, as determined in step S104.

[0072] Specifically, a unique set of differentiated rules is generated and bound to each data object in the insured's information set. This set of differentiated rules is highly personalized, encapsulating the product plan scope and premium calculation factors matched for that specific insured in step S104. This means that each insured has their own unique set of rules to guide subsequent interface display, information collection, and verification.

[0073] For example, a differentiated rule set for a child insured may include product plans for "student accident insurance" and "children's critical illness insurance," as well as the corresponding children's rate factors; while a rule set for an adult insured may include "adult accident insurance" and "term life insurance," as well as the corresponding adult rate factors.

[0074] By generating differentiated rule sets, it is ensured that subsequent processes can be tailored to the specific circumstances of each insured, avoiding the rigidity and inapplicability of general rules, thereby improving the flexibility and accuracy of automated processing.

[0075] S106. Generate an aggregated interactive interface based on the policyholder's data context and the differentiated rule set bound to each data object.

[0076] Among them, the policyholder data context refers to the structured data area that stores the policyholder's public information; the aggregated interactive interface refers to a unified interface that integrates all insured information entry and selection functions, and can display multiple insured's exclusive information areas in one view at the same time. The default method is to design by UI / UX designers and implement by front-end developers according to UI / UX design principles and business needs, including exclusive question areas corresponding to the differentiated rule sets for each data object; the exclusive question area refers to the interface module in the aggregated interactive interface that is independently divided for each insured, used to display applicable product plans and receive personalized insurance information (such as selected products, coverage amount, health declaration, etc.).

[0077] Specifically, by comprehensively utilizing the policyholder data context (including common policyholder information) established in step S101 and the differentiated rule set generated and bound for each insured in step S105, a unified interactive interface is dynamically generated. This interface is the primary location for user operations throughout the entire batch insurance application process. Its core feature is its aggregation, meaning that it can simultaneously present all relevant information and operation areas for all insured persons in a unified view.

[0078] The interface contains one or more dedicated question areas, each corresponding to a unique insured person's data object. Each dedicated question area intelligently displays applicable product plan options (e.g., dropdown menus or checkboxes), required personalized questions (e.g., health declaration, occupation details, coverage amount input box), and other relevant information based on the differentiated rule set bound to that insured person. This dynamic generation ensures the accuracy and personalization of the interface content, avoids the tedious process of users repeatedly switching between interfaces for different insured persons, and improves the efficiency of batch operations and the user experience.

[0079] S107. Receive input information for the specific problem area and verify the input information according to the differentiated rule set.

[0080] The dedicated question area refers to a separate interface module for each insured person within the aggregated interactive interface; the input information refers to the data filled in by the user in the dedicated question area regarding the insured person's insurance intentions and related details, such as the selected product plan, coverage amount, occupation, and health declaration answers; the differentiated rule set refers to a set of exclusive business rules tailored to each insured person, including the product plan scope and premium calculation factors, as well as verification rules. The default method is defined by product managers and compliance personnel based on insurance product design and underwriting requirements, and implemented by technical personnel as executable verification logic.

[0081] Specifically, the system receives input information submitted by users in each insured's designated question area. This input information may include the specific product plan selected by the user for that insured, the desired coverage amount, detailed occupational information, and answers to health declarations. Upon receiving this information, the system performs real-time or batch verification based on the differentiated rule set bound to the insured's data object. Verification may include: whether the selected product plan is within the allowed range (e.g., whether it is within the product plan range defined in S104), whether the coverage amount meets the minimum / maximum limits stipulated by the product, whether the occupation falls within the scope of rejection or requires additional premiums, and whether the answers to health declarations trigger underwriting rules (e.g., certain medical histories may lead to rejection or require manual underwriting). In this way, it ensures that every piece of information entered by the user complies with the specific underwriting conditions and product rules for that insured, promptly identifies and alerts non-compliant or unreasonable data, thereby ensuring the accuracy and validity of subsequent underwriting and order generation, and preventing invalid data from entering subsequent processes.

[0082] In some embodiments, step S107 can be implemented in several ways: Optionally, it can be achieved through a combination of real-time front-end validation and secondary back-end validation: When a user enters information in a form field within a specific question area, the front-end JavaScript code performs real-time validation based on simple validation rules (such as data format, required fields, and numerical range) defined in the differentiated rule set, and immediately displays error messages on the interface to prevent the user from submitting non-compliant data. When a user completes the completion of a specific question area and clicks "Confirm" or "Next," the front-end sends the input information for that area along with the corresponding differentiated rule set to the back-end service. Upon receiving the information, the back-end service uses a rule engine or business logic layer to perform secondary validation based on complex validation rules (such as multi-field cross-validation, comparison with external data sources, and business logic judgment) defined in the differentiated rule set, ensuring that the data also conforms to all business rules on the server side. The validation result (pass or fail and detailed error information) is returned to the front-end, and the front-end updates the interface state based on the result, such as highlighting error fields and displaying error information.

[0083] Optionally, batch verification can be performed through a unified verification service: After users complete the dedicated question areas for all insured individuals in the aggregated interactive interface, clicking the "Submit All Insured Information" button causes the front-end to package all insured individuals' input information and their corresponding differentiated rule sets and send them to a unified verification service on the back-end. The unified verification service processes the verification task for each insured individual in parallel. Each task undergoes comprehensive verification based on its independent differentiated rule set, including product selection, coverage amount, health declaration, etc. The verification service aggregates all verification results and returns them to the front-end. Based on the returned results, the front-end displays the verification status (e.g., "Verification passed," "Verification failed, please change occupation") in the corresponding dedicated question area and displays a list of all insured individuals who failed the verification, guiding users to make corrections.

[0084] It is understandable that this step can be achieved in other ways, and no specific method is specified here.

[0085] In some embodiments, when there are complex validation fields in the user input information that are time-consuming or have external dependencies, the smoothness of user interaction and the overall efficiency of batch insurance can be improved by distinguishing the validation type and adopting an asynchronous validation mechanism.

[0086] Specifically, the process is triggered after a user completes information in one or more dedicated question areas within the aggregated interactive interface. It then receives the input information submitted by the user in each insured person's dedicated question area. This input information may include the specific product plan selected by the user for that insured person, the expected coverage amount, detailed occupational information, and answers to health declarations. Upon receiving this information, the system identifies which fields in this input information require complex validation that is time-consuming or relies on external dependencies, and clearly distinguishes them from fields that require immediate validation. This distinction is based on preset validation rule attributes, which are jointly defined by business experts and technical personnel based on the complexity of the validation, the resources required (such as whether external interfaces need to be called, whether a large amount of data calculation is involved), and response time requirements. For example, determining whether a field is empty or whether the format is correct falls under immediate validation; while querying an external occupational risk database and performing cross-validation of multi-condition health declarations falls under complex validation.

[0087] For fields requiring immediate validation, validation is performed based on the rules defined in the differentiated rule set bound to the insured's data object. For example, it checks whether the sum insured is within the minimum / maximum allowed by the product, or whether a required field has been filled in. Validation results are immediately displayed on the user interface as visual feedback (such as a red border or error message text). This immediate feedback mechanism helps users quickly identify and correct simple input errors, improving user experience and data entry accuracy, and preventing invalid data from entering subsequent processes.

[0088] For complex validation fields, validation is not performed synchronously in the current user's thread. Instead, the input information for that field, along with the corresponding differentiated rule set (containing all the rules and context required for complex validation), is submitted to an asynchronous validation service. Simultaneously, the user is immediately provided with real-time status feedback during validation processing (e.g., displaying a "Validating" loading icon or text), allowing them to continue working on other dedicated question areas or switch to filling in information for other insured individuals. This asynchronous submission and non-blocking feedback is key to improving the efficiency of batch insurance applications, avoiding the lag and interruptions experienced by users waiting for time-consuming validations, and enabling users to perform multitasking smoothly.

[0089] In the asynchronous verification service, these submitted complex verification tasks are executed in parallel, meaning that multiple insured individuals' complex verification tasks can be processed simultaneously in the background, making full use of system resources and shortening the overall verification time. When a complex verification task is completed, regardless of whether the result is success or failure, the asynchronous verification service will asynchronously push the verification result to the aggregated interactive interface. This asynchronous push mechanism ensures that the user interface can reflect the latest verification status in a timely manner without requiring the user to manually refresh. The interface will update the display status of the dedicated problem area according to the pushed verification result, for example, updating the "Verification in progress" status to "Verification passed" or "Verification failed," and displaying specific error information when it fails, guiding the user to make corrections.

[0090] By employing this meticulous verification type differentiation and asynchronous processing mechanism, the system balances the rigor of verification with the smoothness of user interaction, thereby improving the efficiency of automated processing and the user experience in batch insurance application scenarios.

[0091] The above technical steps, by distinguishing between real-time and complex verification, and employing asynchronous parallel processing and asynchronous result push for complex verification, avoid operation interruptions and long waiting times for users during batch filling. This improves the smoothness of user interaction and the overall efficiency of batch insurance applications, reduces user cognitive load and abandonment rate, thereby accelerating the order generation process.

[0092] S108. Summarize all verified input information and combine it with the policyholder data context and the insured information set to generate an aggregated insurance order.

[0093] Among them, the verified input information refers to all insured's personalized insurance application data that meets the rules and is error-free after strict verification in step S107, including their selected product plan, coverage amount, premium, health declaration, etc.; the policyholder data context refers to the structured data area that stores the policyholder's public information; the aggregated insurance order refers to a complete order data structure that contains all the necessary information for this batch of insurance applications (policyholder information, all insured information and their selected product plan, coverage amount, premium, etc.), which can be directly submitted to the insurance company's core system for underwriting and insurance. Its default method is designed by system architects and business analysts according to the insurance core system interface specifications and industry standards.

[0094] Specifically, all personalized insurance application information for each insured person that has passed the verification in step S107 is aggregated. This information is the core business data for this batch of insurance applications, including each insured person's final selected product plan, determined coverage amount, calculated premium, and all health declarations that meet underwriting requirements. While aggregating this personalized information, the data context of the policyholder established in step S101 (containing the policyholder's public information, such as name, contact information, payment account, etc.) and the set of insured person information constructed in step S102 (containing each insured person's basic identity information) are also combined. Finally, all this data is integrated to generate a complete and structured aggregated insurance application order. This order contains all the details of this batch of insurance applications, such as an order header (containing policyholder information, total premium, and order creation time) and multiple order detail items (each detail item corresponds to an insured person, including their identity information, selected product plan, coverage amount, premium details, health declaration, etc.). This aggregated insurance order can be directly submitted to the insurance company's core business system for subsequent underwriting, payment and insurance processing, thus completing the entire batch insurance process and realizing an automated closed loop from information entry to order generation.

[0095] In the above embodiments, by establishing the policyholder context, constructing the insured data object, and generating a differentiated rule set based on age and rule base matching, personalization for each insured is achieved. Furthermore, by generating an aggregated interactive interface, verification is performed in a dedicated question area based on the differentiated rule set, ultimately summarizing and generating an aggregated insurance order, improving the efficiency, accuracy, and user experience of batch insurance information processing.

[0096] In other embodiments of this application, in batch insurance scenarios, when a single insured person faces multiple optional product plans with complex coverage and terms, the insured person may encounter a decision-making dilemma due to difficulty in quickly understanding and comparing the advantages and disadvantages of each plan, which may even affect the efficiency of the insurance application. The automated insurance information filling and verification method provided in this application can intelligently generate a parallel comparison view, intuitively presenting the detailed coverage and key differences of each plan, thereby assisting the insured person in making an efficient and accurate insurance choice.

[0097] like Figure 2 The diagram shown is another flowchart illustrating the automated insurance information filling and verification method provided in this application embodiment, including the following steps:

[0098] S201. Respond to the batch insurance application instruction, start the batch insurance application session, and establish an insurance application data context for storing common information of the insurance policyholders.

[0099] S202. Receive and manage the identity information of the insured, and construct each insured's identity information into an independent data object to obtain a set of insured information.

[0100] In some embodiments, in batch insurance scenarios, when the insured information may be duplicated or associated with existing customers, the accuracy, efficiency and comprehensiveness of data processing can be improved by generating intelligent identification codes, deduplication within batches, and associating with existing customer data.

[0101] First, the system receives the insured's identity information and constructs it into an independent data object. This ensures that each piece of original insured information is standardized and encapsulated, facilitating subsequent unified processing.

[0102] Next, a unique insured identification code is generated based on the identity information in the data object. This code is generated according to preset algorithms and rules, typically combining the insured's core identity elements (such as ID number, name, date of birth, etc.) through a hash function or other deterministic algorithm. The aim is to provide each insured with a stable and unique identifier within the system. This generation method is derived and configured by those skilled in the art based on data uniqueness requirements and information security standards.

[0103] Subsequently, the insured's identification code is used to perform deduplication within the insured's information set. This means that among all the insured data submitted in this batch of applications, the system proactively checks for duplicate entries of the same insured. If duplicate data objects are found, they are merged into a single data object. For example, if an applicant accidentally submits the same insured twice, the system intelligently identifies and merges them into one valid record, thus avoiding duplicate subsequent processing for the same insured, saving computational resources, and ensuring data accuracy.

[0104] Following this, the insured's identification code is further utilized to query the existing customer database. This database represents a long-term accumulation of customer information assets by the insurance company, including historical insurance application records, health declarations, claims history, and risk ratings. This query aims to identify whether the insured individuals applying for this batch of insurance are already existing customers of the insurance company. If a matching existing customer record is found, the data object is associated with the existing customer record, and relevant historical information related to this application is extracted. This relevant historical information may include the customer's historical health declarations, total sum insured of existing policies, past claims history, occupational change history, or risk rating. Through this association and extraction, more comprehensive and in-depth background information can be provided for this application, enabling subsequent underwriting and product matching to be based on more complete data. This improves the accuracy of underwriting and the comprehensiveness of risk assessment, and provides users with more personalized services, such as pre-filling some historical information to reduce the user's data entry burden.

[0105] Ultimately, historical information and data objects are linked together to form an insured information set. This set contains deduplicated insured data objects that may have been linked to historical information, providing a high-quality and complete data foundation for subsequent steps such as age calculation and product rule matching.

[0106] This step generates a unique insured identification code, enabling the intelligent merging of duplicate data within a batch and avoiding invalid processing. Simultaneously, by linking with the existing customer database and extracting historical information, it improves the completeness and accuracy of insured information, providing more comprehensive data support for subsequent underwriting and product matching. This, in turn, enhances the efficiency, accuracy, and compliance of automated batch insurance processing.

[0107] S203. Traverse all data objects in the insured's information set, extract the ID card number, and parse the insured's date of birth based on the ID card number to calculate the insured's age.

[0108] S204. Use age as a matching factor and match it with the preset insurance product rule base to determine the applicable product plan scope and premium calculation factor for each data object.

[0109] S205. Generate and bind a differentiated rule set for each data object.

[0110] Steps S201-S205 and Figure 1 Steps S101-S105 in the illustrated embodiment are similar and can be found in the descriptions of steps S101-S105, which will not be repeated here.

[0111] S206. Based on the policyholder's data context and the differentiated rule set bound to each data object, generate an aggregated interactive interface, and embed interactive elements that trigger the alternative plan comparison function in the question area containing multiple alternative plan data objects.

[0112] Among them, the policyholder data context refers to the structured data area that stores the policyholder's public information during the batch insurance application session; the multiple alternative plan data object refers to the insured data object whose product plan scope, determined by the corresponding differentiated rule set, includes two or more alternative product plans in this batch insurance application; the product plan scope refers to the list of all product plans that the insured can apply for, filtered according to the insured's conditions; the interactive element that triggers the alternative plan comparison function refers to the visual component (such as a button, link, or icon) embedded in the question area of ​​the multiple alternative plan data object in the aggregated interactive interface, which is used to start the detailed comparison function of the alternative product plans when the user clicks it.

[0113] Specifically, by comprehensively utilizing the policyholder data context (including common policyholder information) established in step S201 and the differentiated rule sets generated and bound for each insured in step S205, a dynamic aggregated interactive interface is generated. This interface is the core platform for users to perform batch insurance purchase operations. The design concept is "aggregation," that is, presenting all relevant information and operation areas of all insured persons in a unified view. Based on this, this step introduces: traversing all insured person data objects and checking the bound differentiated rule sets. If the product plan scope determined by the differentiated rule set of a certain insured person data object includes multiple alternative product plans (i.e., the insured person has multiple insurance products to choose from), an interactive element that triggers the alternative plan comparison function is embedded in the exclusive question area corresponding to that insured person.

[0114] For example, display a "Compare" button or a "View Details" link next to the product selection dropdown. This interactive element aims to address the difficulty users face when confronted with multiple similar but subtly different product options, making it hard to make a quick decision. By embedding this functionality in advance during the interface generation phase, users are provided with a convenient entry point to deeply understand and compare the advantages and disadvantages of different product plans when needed, thereby assisting them in making more informed insurance decisions and improving user experience and decision-making efficiency.

[0115] S207. Respond to the trigger command of the interactive element and extract the detailed coverage and key differences of the multiple alternative plan data objects from the insurance product rule base.

[0116] Among them, the trigger command for interactive elements refers to the operation command issued by the user by clicking the interactive element embedded in step S206 (such as the "Compare" button); the insurance product rule base refers to a database or rule engine that structurally stores all business rules such as the underwriting conditions, coverage, and premium calculation logic of insurance products. The default method is to formulate and configure them jointly by actuaries and business experts according to the product design and underwriting requirements of insurance companies, and then transform them into an executable rule set by those skilled in the art; the multiple alternative plan data object refers to the specific insured data object that the user currently wants to compare products with; detailed coverage refers to the comprehensive coverage terms provided by each alternative product plan, including but not limited to the sum insured, scope of coverage, deductible, waiting period, and exclusions; key differences refer to the differences that users care about most among multiple alternative product plans and that can help them quickly distinguish and choose, such as premium level, coverage of specific diseases, additional services, and renewal conditions.

[0117] Specifically, in response to trigger commands, the system identifies which specific multi-alternative plan data object (i.e., which insured) requires product comparison. Then, based on the identifiers of the multiple alternative product plans associated with that insured data object, it proactively extracts detailed information about these plans from the insurance product rule base. This extraction process goes beyond simply obtaining product names; it delves into the detailed coverage of each plan, including specific coverage categories (such as disease types and accident types), sum assured, deductible settings, waiting periods, and other supplementary services. Simultaneously, it analyzes these alternative plans to identify key differences between them. For example, one plan might have a lower premium but narrower coverage, while another plan might have a higher premium but include coverage for specific high-incidence diseases. By automatically extracting this detailed information and key differences, the system provides users with a comprehensive and focused basis for comparison, avoiding the tedious process of manually searching and comparing complex product terms, saving users time and effort, and ensuring the accuracy and effectiveness of subsequent comparison views.

[0118] S208. Generate a comparative view that displays detailed coverage details and key differences side-by-side.

[0119] The detailed coverage refers to the comprehensive coverage terms of each alternative product plan extracted in step S207; the key differences refer to the significant differences between multiple alternative product plans identified in step S207; and the comparison view is a specially designed user interface that displays the detailed coverage and key differences of multiple alternative product plans in a side-by-side (usually in a table or card) format to facilitate horizontal comparison by users.

[0120] Specifically, this structured data is used to generate a side-by-side comparative view. This view is typically presented in the form of a table or multi-column cards, where each column represents an alternative product plan and each row represents a coverage item or a key difference. For example, the first row of the table might be "Product Name," the second "Annual Premium," the third "Main Insurance Sum Insured," the fourth "Critical Illness Coverage," the fifth "Deductible," and so on. The corresponding information for each product plan is then populated into the corresponding columns and rows. Key differences can be specially marked or highlighted during the presentation to guide the user's attention and help quickly identify the core differences between different products. This visual and structured presentation reduces the difficulty for users to understand complex insurance product terms, transforming the tedious process of manually reading multiple product brochures and making comparisons into an intuitive and efficient interactive experience. By providing clear comparative information, users can more quickly and accurately assess the advantages and disadvantages of different product plans, thus making the best choice that meets their needs, improving decision-making efficiency and user satisfaction in the bulk insurance process.

[0121] S209. Update the comparison selection results in the comparison view to the corresponding data object.

[0122] The comparison selection result refers to the user's final selection of a specific product plan in the comparison view; the corresponding data object refers to the specific insured data object identified as a "multiple alternative plan data object" in step S206.

[0123] Specifically, when a user explicitly specifies an alternative product plan as their final choice by clicking the "Select this plan" button or similar interactive element in the comparison view, this comparison selection result is captured. Subsequently, the selected product plan information is updated to the corresponding data object. Specifically, the specific insured person's data object that initiated this comparison is located, and the internally stored "Selected Product Plan" field is updated to the product plan determined by the user in the comparison view. This update operation ensures that the user's final choice in the complex decision-making process is accurately reflected in the system's internal data model. By updating the comparison selection result to the corresponding data object in a timely and accurate manner, data consistency and integrity are guaranteed, providing correct input for subsequent verification (S210) and final order generation (S211), avoiding potential errors caused by information asynchrony or human error, thereby ensuring the smoothness and accuracy of the entire batch insurance application process.

[0124] In some embodiments, in batch insurance scenarios, when multiple insured persons have a specific relationship or common insurance needs, the system can also intelligently identify and combine insurance opportunities, generate and compare combination plans, thereby providing policyholders with more cost-effective and comprehensive insurance options, further improving the level of automation and user satisfaction.

[0125] First, based on a pre-defined combination insurance rule base, groups of combined data objects with interdependent or combined preferential conditions are identified from the insured information set. This pre-defined combination insurance rule base refers to a set of business rules containing preferential policies, underwriting conditions, and product combination logic for family policies, group policies, main and supplementary insurance combinations, and combined insurance for specific groups (such as spousal mutual insurance or parent-child joint insurance). These rules are pre-defined by the product design and actuarial teams based on the insurance company's market strategy, actuarial models, and underwriting regulations, and then transformed into an executable rule set by those skilled in the art. For example, the rule base might define "spouses can enjoy premium discounts when insuring simultaneously" or "family members can obtain additional coverage when insuring specific products." Based on these rules, the insured information set is intelligently analyzed to identify subsets of insured individuals that meet the combination conditions, forming one or more combined data object groups. For example, if an insured person insures both themselves and their spouse, a "spousal combination group" is identified.

[0126] After identifying the combined data object groups, a combined insurance plan for each group is generated. Each combined insurance plan contains a selected product plan for each data object within the group. This means that based on the insured individuals within each group and the range of product plans applicable to them, multiple possible insurance plans are intelligently arranged and combined. Each plan represents the set of specific product plans selected by all insured individuals within that group. For example, a couple's group might have multiple plans such as "husband chooses A + wife chooses X" or "husband chooses B + wife chooses Y".

[0127] Next, the overall premium, overall protection benefits, and any bundled benefits for each combined insurance plan are calculated. For each generated combined plan, the total premium of all product plans selected by all insured persons within the group is considered, and the overall premium is calculated based on the preferential conditions defined in the combined insurance rule base (such as family discounts and bundled sales offers). Simultaneously, the overall protection benefits provided by the combined plan are evaluated, such as the total sum insured, the types of risks covered, and additional services. Any bundled benefits arising from the combined insurance (such as premium reductions and additional coverage) are also explicitly calculated. This calculation process is complex, requiring the application of multiple rules, but through automated processing, the accuracy and efficiency of the calculation are ensured, providing users with a clear value assessment.

[0128] Subsequently, a comparison view of the combined insurance plans is generated, displaying them side-by-side. This view includes the overall premium, overall coverage benefits, and combined discounts. Similar to the single-product comparison view in S208, this view compares the entire combined plan. Each combined plan is presented side-by-side in an intuitive table or card format, showing a summary of the overall premium, overall coverage benefits, and clear information on combined discounts. This visual presentation allows policyholders to easily compare the advantages and disadvantages of different combined plans, such as "Plan 1 has a lower total premium but slightly less coverage" or "Plan 2 has a slightly higher total premium but offers a family discount of XX% and more comprehensive coverage." This simplifies the decision-making process for policyholders in complex combination selections, helping them quickly find the insurance strategy that best suits their family or group needs.

[0129] Finally, the selection results from the received combination plan comparison view are updated in the product plan selection field corresponding to each data object in the data object group. When the policyholder selects an optimal combination plan in the combination plan comparison view, this selection is captured, and the product plans determined for each insured in that combination plan are automatically updated in the product plan selection field corresponding to that insured's data object. This operation ensures that the policyholder's combination decision is reflected in each insured's individual data, providing accurate input for subsequent final order generation. Through this series of steps, not only is the automation efficiency of batch insurance applications improved, but also additional value is created for policyholders through intelligent combination recommendations and comparisons, achieving an intelligent upgrade from "selecting products for each individual" to "selecting the best combination for the entire group."

[0130] This step automates the previously complex manual decision-making process by intelligently identifying combined insurance opportunities among insured parties and generating, comparing, and selecting combined insurance plans. This not only reduces the workload of policyholders who repeatedly select and calculate, but also helps them make better insurance decisions by clearly displaying the overall premium, coverage benefits, and combined discounts, thereby improving the intelligence, efficiency, and user satisfaction of bulk insurance applications.

[0131] S210. Receive input information for the specific problem area and verify the input information according to the differentiated rule set.

[0132] S211. Summarize all verified input information and combine it with the policyholder data context and the insured information set to generate an aggregated insurance order.

[0133] Steps S210-S211 and Figure 1 Steps S107-S108 in the illustrated embodiment are similar and can be found in the descriptions of steps S107-S108, which will not be repeated here.

[0134] In the above embodiments, by embedding interactive elements that trigger the comparison of alternative insurance plans within the aggregated interactive interface for insured individuals with multiple available insurance plans, a convenient and proactive decision-making support entry point is provided. When the user responds to this trigger command, the detailed coverage and key differences of each alternative plan are extracted from the insurance product rule base. This avoids the hassle of users having to spend time manually reviewing, understanding, and organizing complex product terms, ensuring the comprehensiveness and accuracy of the comparison information. Subsequently, a comparison view displaying this information and differences is generated, transforming the originally scattered and obscure terms into an intuitive, structured, and easy-to-understand comparative presentation. This visual and difference-focused display method allows policyholders to easily evaluate the advantages and disadvantages of different product plans, thereby reducing the difficulty and time cost of decision-making when faced with multiple choices, and improving the accuracy, efficiency, and user satisfaction of insurance decisions.

[0135] The following describes an exemplary automated insurance information filling and verification system 300 provided in an embodiment of this application. Figure 3 This is an exemplary hardware structure diagram of the insurance information automatic filling and verification system 300 provided in this application embodiment.

[0136] In some embodiments, the automated insurance information filling and verification system 300 is a computer device or includes a computer device. The computer device includes a processor, memory, and a network interface connected via a system bus. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the computer device stores data. The network interface of the computer device is used to communicate with other external terminals or servers via a network connection. In some embodiments, the network interface can be a wired network interface; in some embodiments, the network interface can also be a wireless network interface. When the computer program is executed by the processor, it implements the methods in the embodiments of this application.

[0137] Those skilled in the art will understand that Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0138] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

[0139] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0140] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0141] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for automatically filling and validating insurance information, characterized in that, include: In response to a bulk insurance application instruction, initiate a bulk insurance application session and establish an insurance application data context for storing common information about the insurance applicants; Receive and manage the identity information of the insured, and construct each insured's identity information into an independent data object to obtain a set of insured information; Iterate through all the data objects in the insured's information set, extract the ID card number, and parse the insured's date of birth based on the ID card number to calculate the insured's age; The age is used as a matching factor and matched with a preset insurance product rule base to determine the applicable product plan scope and premium calculation factor for each data object; A differentiated rule set is generated and bound to each of the data objects; the differentiated rule set includes the product plan scope and the premium calculation factor; Based on the policyholder data context and the differentiated rule set bound to each data object, an aggregated interactive interface is generated, and an interactive element that triggers the alternative plan comparison function is embedded in the question area containing multiple alternative plan data objects; The multiple alternative plan data objects are the corresponding differentiated rule sets, and the product plan scope includes multiple alternative plans; the interactive interface includes a dedicated question area corresponding to the differentiated rule set for each data object; In response to the trigger command of the interactive element, the detailed coverage and key differences of the multiple alternative plan data objects are extracted from the insurance product rule base; Generate a comparative view that displays the detailed coverage and key differences side-by-side; Update the comparison selection results in the comparison view to the corresponding data object; Receive input information for each of the dedicated question areas within the aggregated interactive interface; Identify complex validation fields in the input information and distinguish them from real-time validation fields; The real-time validation field is validated in real-time based on the differentiated rule set, and real-time feedback is provided. For the complex validation field, the input information and the corresponding differentiated rule set are submitted to the asynchronous validation service, and real-time status feedback is provided during the validation process. In the asynchronous verification service, complex verification tasks are executed in parallel; When the complex verification task is completed, the verification result is asynchronously pushed to the aggregated interactive interface, and the display status of the dedicated question area is updated according to the result; All verified input information is aggregated and combined with the policyholder data context and the insured information set to generate an aggregated insurance order.

2. The method according to claim 1, characterized in that, The process of receiving and managing the insured's identity information, and constructing each insured's identity information into an independent data object to obtain an insured information set, specifically includes: Receive the insured's identity information and construct it into a data object; For each of the data objects, the relationship type between the insured and the policyholder is received; The relationship type is matched with a preset insured benefit rule base to determine whether the insured meets the insured benefit requirements; If so, the relationship type is stored in the data object; If not, the data object will be marked as unqualified and prevented from proceeding to the next step. All data objects that were not marked as unqualified were aggregated to obtain the insured information set.

3. The method according to claim 2, characterized in that, After aggregating all data objects not marked as unqualified to obtain the insured information set, the process further includes: For all the data objects, group them according to the relation type; For each of the relationship types, identify the public information collection items associated with the relationship type from the insurance product rule base; If the relationship type group contains multiple data objects, then an aggregated input interface for the public information collection item is generated; Receive public information input from the user in the aggregated input interface for the public information collection item, and fill the public information input into the fields corresponding to all the data objects in the corresponding group; The collected data objects that have completed the collection of the public information will be updated to the insured information set.

4. The method according to claim 1, characterized in that, After updating the comparison selection result in the comparison view to the corresponding data object, the method further includes: Based on the preset combined insurance rule base, identify the combined data object group with interdependent or combined preferential conditions in the insured information set; Generate a combined insurance plan for the combined data object group, wherein each combined insurance plan contains a selected product plan for each data object within the combined data object group; Calculate the overall premium, overall protection benefits, and any combination discounts for each of the aforementioned combined insurance plans; Generate a comparison view of the combined insurance plans, displaying them side-by-side; the comparison view includes the total premium, the total protection benefits, and the combined discounts. The selection results received from the combined scheme comparison view are updated to the product plan selection field corresponding to each data object in the data object group.

5. The method according to claim 1, characterized in that, The process of receiving and managing the insured's identity information, and constructing each insured's identity information into an independent data object to obtain an insured information set, specifically includes: Receive the insured's identity information and construct it into an independent data object; Based on the identity information in the data object, a unique insured identification code is generated; Using the insured identification code, duplicate data objects are checked within the insured information set. If duplicate data objects are found, they are merged into a single data object. Using the insured's identification code, the existing customer database is queried. If a matching existing customer record is found, the data object is associated with the existing customer record, and the historical information related to this insurance application is extracted from the existing customer record. The associated historical information and the data objects are combined to form an insured information set.

6. An automated insurance information filling and verification system, characterized in that, The automated insurance information filling and verification system includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to cause the automated insurance information filling and verification system to perform the method as described in any one of claims 1-5.

7. A computer program product containing instructions, characterized in that, When the computer program product is run on the insurance information automatic filling and verification system, the insurance information automatic filling and verification system performs the method as described in any one of claims 1-5.

8. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is executed on the insurance information automatic filling and verification system, the insurance information automatic filling and verification system performs the method as described in any one of claims 1-5.

Images