Insurance contract unified generation method based on multi-dimensional routing

Abstract

The invention discloses an insurance contract unified generation method based on multi-dimensional routing, and relates to the technical field of data processing, and the method comprises the steps: obtaining a standardized data message containing an insurance policy number and an insurance type code, and distributing a unique identifier for the data message; calling a preset dynamic data routing rule based on the insurance policy number and the insurance type code, and determining a contract template matched with a target insurance product; executing data conversion processing and integrating the anti-counterfeiting watermark into the contract template to generate a PDF document with anti-counterfeiting features; and carrying out formatting processing on the PDF document through a label rendering technology, and outputting an insurance contract file conforming to a unified standard. According to the multi-dimensional routing-based insurance contract unified generation method provided by the embodiment of the invention, efficient and unified generation and output of the insurance contract can be realized, the processing efficiency and the format standardization degree are remarkably improved, and the security and legality of the contract are enhanced by integrating an anti-counterfeiting technology.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a unified method for generating insurance contracts based on multi-dimensional routing. Background Technology

[0002] As a core support module in the field of insurance information technology, insurance contract generation systems are widely used in key business processes such as policy management, risk control, and customer service. With the accelerated digital transformation of the insurance industry, traditional contract generation methods are no longer sufficient to meet the demands of processing massive amounts of policies. Among related technologies, a complete technical system from data input to physical output has been constructed through the collaborative operation of data processing, template management, and anti-counterfeiting integration. Specifically, this technology covers key aspects such as data verification, risk assessment, template matching, formatting, and anti-counterfeiting generation. The core technical architecture consists of standardized XML / JSON interfaces, a rule engine decision-making system, and multi-printer adaptation interfaces. Based on this, the industry has formed a composite technology ecosystem based on electronic contract generation, combined with digital signatures and encryption technologies.

[0003] However, existing technical solutions employ a hybrid approach of manual operation and simple automation tools, lacking systematic data routing rules and template matching mechanisms. Specifically, traditional methods lack standardized mapping rules for XML data extraction, leading to 12 types of inconsistencies in field parsing; template selection relies on manual judgment, resulting in a matching accuracy of less than 75%; and anti-counterfeiting measures rely solely on basic watermarking technology, achieving a counterfeit detection accuracy of less than 85%. Furthermore, the non-idempotent design of the data processing stage introduces the risk of redundant processing, with approximately 450 out of 3,000 policies requiring manual intervention daily due to formatting issues. The lack of unified version control and state machine management means the system requires an average of 72 hours to update templates in response to regulatory changes, with a 15% policy rework rate. These technical deficiencies not only result in contract generation efficiency of less than 3 minutes per contract but also cause annual management cost losses exceeding 20 million yuan, severely hindering the large-scale development of the insurance business. Summary of the Invention

[0004] The main objective of this invention is to provide a unified method for generating insurance contracts based on multi-dimensional routing.

[0005] Another objective of this invention is to propose a unified insurance contract generation device based on multi-dimensional routing.

[0006] The third objective of this invention is to provide a computer device.

[0007] A fourth objective of this invention is to provide a non-transitory computer-readable storage medium.

[0008] To achieve the above objectives, a first aspect of the present invention proposes a unified method for generating insurance contracts based on multi-dimensional routing, comprising: S1, Obtain a standardized data message containing the policy number and insurance type code, and assign a unique identifier to the data message; S2, based on the policy number and insurance type code, invoke the preset dynamic data routing rules to determine the contract template that matches the target insurance product; S3, perform data conversion processing and integrate the anti-counterfeiting watermark into the contract template to generate a PDF document with anti-counterfeiting features; S4. The PDF document is formatted using tag rendering technology, and an insurance contract file conforming to a unified standard is output.

[0009] In this embodiment of the invention, the step of determining a contract template matching the target insurance product by invoking a preset dynamic data routing rule based on the policy number and insurance type code includes: S21, the dynamic data routing rule is composed of a combination of policy number prefix features and insurance type code features, and the policy number format is matched by the regular expression ^[AZ]\d{12}$. S22, Export an offline rule file based on the routing rule matching results. The offline rule file contains a mapping relationship between template selection conditions and corresponding PDF template paths.

[0010] In this embodiment of the invention, the step of performing data conversion processing and integrating the anti-counterfeiting watermark into the contract template to generate a PDF document with anti-counterfeiting features includes: S31, An optical watermarking algorithm is used to embed an invisible watermark in a non-sensitive area of ​​the PDF document. The watermark is obtained through a formula. Perform anti-counterfeiting feature verification; S32, the gray barcode and message data are hashed and then integrated into the metadata of the PDF document. The gray barcode contains a 17-bit digital feature value.

[0011] In this embodiment of the invention, the step of formatting the PDF document using tag rendering technology includes: S41, for PDF documents <highlight>The text within the tag is bolded and italicized; the bolding is achieved using... Marking, tilting mark; S42, for <color>The text within the label is rendered with color, and the color value is defined in hexadecimal format #RRGGBB.

[0012] In this embodiment of the invention, it further includes: S5, perform special processing on the PDF document according to preset visual impairment adaptation rules, the special processing includes...<key_info> The text font inside the label is enlarged to 144pt, and embossed markings are added to the designated area; S6. Store the visually impaired version of the PDF document and the standard version of the PDF document in different directories of the object storage system, with the directory paths distinguished by / accessibility / and / standard / .

[0013] To achieve the above objectives, a second aspect of the present invention provides an insurance contract unified generation apparatus based on multi-dimensional routing, comprising: The standardized data message acquisition module is used to acquire standardized data messages containing policy numbers and insurance type codes, and to assign a unique identifier to the data message; The dynamic data routing and matching module is used to call preset dynamic data routing rules based on the policy number and insurance type code to determine the contract template that matches the target insurance product; The anti-counterfeiting feature integration module is used to perform data conversion processing and integrate the anti-counterfeiting watermark into the contract template to generate a PDF document with anti-counterfeiting features; The tag rendering and formatting module is used to format the PDF document using tag rendering technology and output an insurance contract file that conforms to a unified standard.

[0014] To achieve the above objectives, a third aspect of this application provides a computer device, including a processor and a memory; wherein the processor reads executable program code stored in the memory to run a program corresponding to the executable program code, for implementing a unified insurance contract generation method based on multi-dimensional routing as described in the first aspect embodiment.

[0015] To achieve the above objectives, a fourth aspect of this application provides a non-transitory computer-readable storage medium storing a computer program that, when executed by a processor, implements a unified insurance contract generation method based on multi-dimensional routing as described in the first aspect embodiment.

[0016] The embodiments of the present invention have the following beneficial effects: The embodiments of the present invention can achieve efficient and unified generation and output of insurance contracts, significantly improve processing efficiency and standardization of format, and enhance the security and legality of contracts by integrating anti-counterfeiting technology. Attached Figure Description

[0017] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 A flowchart illustrating a unified method for generating insurance contracts based on multi-dimensional routing, provided in an embodiment of the present invention; Figure 2 This is a structural diagram of an insurance contract unified generation device based on multi-dimensional routing, provided in an embodiment of the present invention. Detailed Implementation

[0018] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0019] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0020] The following description, with reference to the accompanying drawings, describes a method and apparatus for unified generation of insurance contracts based on multi-dimensional routing, according to an embodiment of the present invention.

[0021] Example 1 This embodiment provides a unified method for generating insurance contracts based on multi-dimensional routing. For example... Figure 1 As shown, the method includes the following steps: S1, Obtain a standardized data message containing the policy number and insurance type code, and assign a unique identifier to the data message.

[0022] Specifically, in some implementations, the step of acquiring a standardized data message containing the policy number and insurance type code, and assigning a unique identifier to the data message, is a crucial starting point for the data processing flow in the entire unified insurance contract generation and output system. This step is mainly completed through the system's data receiving and initialization module. Its technical implementation is based on standardized data exchange formats (such as XML or JSON), combined with idempotency processing mechanisms and unique identifier generation strategies to ensure data integrity and traceability.

[0023] In this embodiment of the invention, the system first receives structured data messages from the unified buffer layer through the policy synchronization process receiving data call module. These data messages must conform to predefined insurance data exchange standards and typically include fields such as policyholder information, insured amount, insurance period, policy number, and insurance type code. The XML extraction module performs structured parsing of the data according to a preset XML Schema, extracts key fields, and cleans the data, removing invalid or duplicate data to ensure the data quality for subsequent processing. Subsequently, the idempotent database entry module writes the data to the database, marking the status as "pending processing" to prevent duplicate processing.

[0024] Furthermore, the initialization message module assigns a globally unique UUID to each data packet. This UUID conforms to the RFC 4122 standard and typically uses version 1 or version 4 of the UUID generation algorithm. The UUID can be generated optionally based on a timestamp and MAC address or completely randomly to ensure no conflicts occur in a distributed system. This unique identifier will serve as the core tracking identifier throughout the entire contract generation process, spanning subsequent steps such as data routing, template selection, PDF generation, and anti-counterfeiting integration.

[0025] In this embodiment of the invention, the UUID field is 128 bits long, typically represented as a 36-bit hexadecimal string, such as 550e8400-e29b-41d4-a716-446655440000. The standardized format of the data message must meet ISO 20022 or industry-defined XML / JSON Schema specifications to ensure consistency in field naming, data types, and structure. Furthermore, the system supports configuring routing rules, which are typically composed of a policy number prefix and an insurance type code, used to match the corresponding contract template.

[0026] This step is widely used in insurance business systems, especially in scenarios such as batch policy processing and multi-channel data access (e.g., online application, offline agent submission). By assigning a unique identifier to each data message, the system can achieve full-process tracking of each policy, facilitating anomaly handling, log auditing, and system monitoring. Simultaneously, the acquisition of standardized data messages provides structured input for subsequent template matching and content filling, forming the foundation for unified contract generation and anti-counterfeiting integration.

[0027] In this embodiment of the invention, this step effectively improves the system's data processing efficiency and accuracy, avoiding contract generation errors caused by data duplication or inconsistent formats. By introducing a unique identifier, the system achieves independent processing and status management for each policy, enhancing the system's scalability and stability. Furthermore, the acquisition of standardized data provides a unified data interface for subsequent modules, reducing the complexity of system integration and improving the automation level of the overall business process.

[0028] S2, based on the policy number and insurance type code, invoke the preset dynamic data routing rules to determine the contract template that matches the target insurance product.

[0029] Specifically, in some implementations, invoking preset dynamic data routing rules based on the policy number and insurance type code to determine the contract template matching the target insurance product is one of the core processing steps of the unified contract generation and output system in this invention. This step, through the collaborative mechanism of the rule engine and template library, achieves accurate classification and template matching of policy data, thereby ensuring the consistency and compliance of the generated contract documents in terms of format, content, and legal validity.

[0030] This step first receives policy data from the unified buffer layer, typically in XML or JSON format. The system uses the XML extraction module to extract key fields such as the policy number (PolicyNo) and product code (ProductCode) based on a preset XPath path. Subsequently, the system invokes dynamic data routing rules, stored in the rule engine as key-value pairs or decision trees. The core logic is to match the corresponding insurance product category (such as life insurance, health insurance, auto insurance, etc.) based on the prefix of the policy number or the encoding rules of the product code, and further locate the corresponding contract template path. For example, if the product code is HL001, the system will match the template set for the health insurance category and select the best-matching template version.

[0031] In this embodiment of the invention, dynamic data routing rules typically include multiple dimensions of matching conditions, such as PolicyNo.startsWith("LX"), ProductCode == "HL001", etc., and support multi-level nested conditions and priority sorting. The system records the matching path and results during the matching process for subsequent auditing and log tracking. Furthermore, the system supports template version control, using the TemplateVersion field to ensure that the latest compliant version is used, avoiding legal risks caused by outdated templates.

[0032] This step is widely used in the automated contract generation process of insurance business, especially in high-concurrency, multi-product-line business scenarios, such as batch policy processing for auto insurance, health insurance, and life insurance. Through this mechanism, the system can quickly respond to the contract generation needs of different types of insurance, reduce manual intervention, and improve processing efficiency.

[0033] The technical advantage of this step lies in its ability to automatically match and invoke contract templates, ensuring consistency in structure, content, and legal compliance of the generated contract documents. Simultaneously, through the flexible configuration of the rules engine, the system possesses excellent scalability and adaptability, enabling rapid response to template update needs arising from new insurance types or regulatory changes, thereby significantly improving the efficiency and accuracy of contract generation.

[0034] Furthermore, S2 includes: S21, the dynamic data routing rule is composed of a combination of policy number prefix features and insurance type code features, and the policy number format is matched by the regular expression ^[AZ]\d{12}$.

[0035] Specifically, in some implementations, the construction of dynamic data routing rules is based on the combination of policy number prefix features and insurance type codes. Its core purpose is to achieve accurate matching and efficient invocation of contract templates. This rule uses the regular expression ^[AZ]\d{12}$ to validate the policy number format, ensuring that the structure of the input data meets the system's processing requirements. This regular expression indicates that the policy number must begin with an uppercase letter, followed by 12 digits, forming a standardized 13-digit policy number format. This format design meets the insurance industry's requirements for the uniqueness and identifiability of policy numbers, while also facilitating subsequent routing decisions and data processing.

[0036] In this embodiment of the invention, the system performs pattern matching on the policy number using a rule engine, and combines this with the insurance type code (e.g., "LIFE" for life insurance and "HEALTH" for health insurance) for multi-dimensional feature analysis. When receiving XML or JSON format data from the unified buffer layer, the system first extracts the policy number field and performs format validation using the aforementioned regular expression. If the validation passes, the system further parses the insurance type code and combines the two into a routing key for matching preset template routing rules. This rule can be configured as a key-value pair, for example, { "A1234567890123:LIFE" : "template_v1"}, thereby achieving mapping between different product types and different templates.

[0037] It should be noted that the policy number prefix is ​​typically used to identify the insurance company, product line, or region code. It is one character long and limited to uppercase English letters (AZ) to ensure the simplicity and scalability of routing rules. The numeric portion is 12 digits long, conforming to the compatibility requirements of checksum standards such as ISO / IEC 7064, facilitating subsequent verification and data processing. The insurance type code is usually a combination of letters of four characters or less, such as "LIFE" or "HEALTH," used to distinguish different insurance product types.

[0038] This dynamic data routing mechanism is widely used in scenarios involving the batch generation and personalized customization of insurance contracts. For example, in a business system that handles both life and health insurance, this rule can automatically load contract templates for different types of insurance, thereby improving system processing efficiency and reducing manual intervention. Furthermore, this mechanism supports the export and deployment of offline rule files, facilitating rule synchronization and version management in a distributed environment.

[0039] The technical advantage of this step lies in the fact that, through the combination of standardized policy number formats and insurance type codes, the system can achieve efficient and accurate template matching and data routing, thereby improving the automation and consistency of contract generation. Furthermore, this mechanism provides a reliable data input foundation for subsequent modules such as anti-counterfeiting watermark integration, clause insertion, and visually impaired version creation, enhancing the stability and scalability of the entire system.

[0040] S22, Export an offline rule file based on the routing rule matching results. The offline rule file contains a mapping relationship between template selection conditions and corresponding PDF template paths.

[0041] Specifically, in some implementations, the step of exporting offline rule files based on routing rule matching results is a key step in achieving intelligent template selection and efficient processing in a unified insurance contract generation and output system. This step maps policy data to corresponding PDF template paths through preset routing rules, thereby achieving automated template matching and retrieval during the contract generation process.

[0042] This step relies on the system's built-in rule engine, whose core logic is to determine routes based on the combination of policy number and insurance type code. The rule engine constructs a mapping table by reading routing rules from the configuration file, binding specific policy types to corresponding PDF template paths. During data processing, the system extracts key fields from the policy data, such as `policy_type` and `product_code`, and matches them against conditions in the rule table. Upon successful matching, the system writes all template selection conditions and PDF template paths corresponding to that policy into an offline rule file for subsequent processing modules to use.

[0043] In this embodiment of the invention, routing rules are typically stored in key-value pairs, such as {"policy_type": "life_insurance", "product_code": "L001", "template_path": " / templates / life / L001_template.pdf"}. The offline rule file can be in JSON or XML format for easy system parsing and loading. In actual deployment, the rule file update frequency can be set to daily, hourly, or real-time synchronization according to business needs to ensure the timeliness and accuracy of the template path. Furthermore, the system supports rule version control, ensuring that a stable version matching the current policy data can still be used when the template is updated or the rule is changed.

[0044] This step is widely used in scenarios involving the batch generation of insurance contracts, especially when handling multiple types of policies such as life insurance and health insurance. It can significantly improve the system's ability to identify and respond to different product types. For example, when processing millions of policy data, the system can quickly locate the template path through offline rule files, avoiding the performance bottleneck caused by real-time database queries, thereby achieving high-concurrency, low-latency contract generation services.

[0045] Furthermore, this step effectively improves the intelligence and processing efficiency of the contract generation system. By exporting the mapping relationship between routing rules and template paths as offline files in advance, the system does not need to frequently access the database or configuration center during runtime, reducing system response time and increasing throughput. At the same time, this mechanism ensures the consistency and compliance of contract formats, providing a stable data foundation for subsequent anti-counterfeiting processing, tag rendering, and the creation of visually impaired versions, thus enhancing the overall robustness and maintainability of the system.

[0046] S3, perform data conversion processing and integrate the anti-counterfeiting watermark into the contract template to generate a PDF document with anti-counterfeiting features.

[0047] Specifically, in some implementations, performing data conversion processing and integrating anti-counterfeiting watermarks into the contract template to generate a PDF document with anti-counterfeiting features is one of the key steps in the unified generation and output system of insurance contracts. Its technical implementation is based on the integration of structured data parsing, template engine rendering, and digital anti-counterfeiting technology. This step first uses a data conversion component to perform structured processing on the XML and JSON format data received from the unified buffer layer, mapping the raw data to the field structure required by the contract template. During the conversion process, the system precisely matches and fills in the data with placeholders in the template according to preset style sheets and template rules (such as field loops and conditional judgments), ensuring the accuracy of the contract content and the consistency of the format.

[0048] Furthermore, during the template invocation decision phase, the system selects the corresponding PDF template based on the Type field in the message and integrates the anti-counterfeiting watermark into that template. The anti-counterfeiting watermark is generated using optical watermarking technology, embedding an invisible or semi-visible watermark image in a specific area of ​​the PDF document. Its content typically includes information such as the policy number, generation timestamp, and unique identifier (e.g., UUID). The watermark integration method can be based on the PDF's layer overlay mechanism, using standard PDF APIs (such as iText and Apache PDFBox). The watermark transparency is generally set to 15%–30% to balance visibility and anti-counterfeiting effectiveness.

[0049] In this embodiment of the invention, the embedding position of the anti-counterfeiting watermark is typically controlled by coordinate parameters (x, y) and a scaling factor to ensure that its fixed position in the document is not easily tampered with. The resolution of the watermark image is recommended to be no less than 300 DPI to prevent information loss during printing or scanning. Furthermore, the watermark content can be encoded using Base64 or a cryptographic hash (such as SHA-256) to enhance its anti-counterfeiting strength.

[0050] In practical applications, this step is primarily used for the electronic generation and distribution of insurance contracts. Especially when processing policies in batches, it effectively prevents contracts from being illegally copied or altered, ensuring their legal validity. Its technical benefits are twofold: firstly, intelligent matching of structured data with templates improves the efficiency and consistency of contract generation; secondly, integrating anti-counterfeiting watermarks enhances the contract's anti-counterfeiting capabilities, providing reliable technical support for subsequent contract verification, auditing, and legal tracing.

[0051] Furthermore, S3 includes: S31, An optical watermarking algorithm is used to embed an invisible watermark in a non-sensitive area of ​​the PDF document. The watermark is obtained through a formula. Perform anti-counterfeiting feature verification.

[0052] Specifically, in some implementations, this invention embeds an invisible optical watermark in non-sensitive areas of a PDF document to achieve anti-counterfeiting and anti-tampering functions for the contract. This optical watermark is embedded using an algorithm based on minimizing errors; its core lies in using a formula... The feature deviations in the watermark embedding process are verified and optimized to ensure the invisibility and robustness of the watermark.

[0053] In this embodiment of the invention, the optical watermark is typically embedded in the blank areas, headers, footers, or image backgrounds of a PDF document to avoid interfering with the main text of the contract. The watermark information can be text, graphics, or binary-coded anti-counterfeiting features, and its embedding process is based on image processing techniques, such as frequency domain transformation (e.g., DCT, DWT) or pixel-level perturbation. In this system, when the watermark information is fused with the original PDF content, the embedding strength is controlled by minimizing the loss function, making the watermark visually invisible while maintaining a high recognition accuracy during extraction.

[0054] It should be noted that in the formula Indicates the first (in the original PDF image) The grayscale value of each pixel This represents the grayscale value of the pixel after the watermark is embedded. This represents the total number of pixels involved in the calculation. By minimizing... The system can dynamically adjust the watermark embedding strength coefficient. This ensures that the visual distortion after watermark embedding is controlled within a range imperceptible to the human eye, typically... In addition, the system supports multi-layer embedding of watermarks to enhance their resistance to attacks, such as resistance to cropping, rotation, and scaling.

[0055] In application scenarios, this step is primarily used in insurance contract generation systems to ensure the uniqueness and verifiability of each output PDF document. After generating the PDF, the system automatically invokes the optical watermarking module to embed watermark information in non-sensitive areas and binds the watermark features to the original message data, facilitating subsequent verification using specialized tools. This technology is widely applicable to scenarios such as anti-counterfeiting, copyright protection, and identity authentication in electronic contracts.

[0056] This step effectively enhances the security and credibility of contract documents. Through the formula... With its optimized mechanism, the system can achieve high-precision watermark embedding and extraction without affecting document readability, thereby preventing contracts from being illegally altered or forged and ensuring the legal validity and business compliance of contracts.

[0057] S32, the gray barcode and message data are hashed and then integrated into the metadata of the PDF document. The gray barcode contains a 17-bit digital feature value.

[0058] Specifically, in some implementations, integrating the gray barcode and message data into the metadata of the PDF document after hashing is one of the key steps in this invention to enhance the anti-counterfeiting capabilities of insurance contracts. This step generates a unique digest by hashing the 17-bit digital feature value (i.e., the gray barcode) with the contract message data, and embeds it into the metadata of the PDF document, thereby achieving integrity verification and anti-tampering functions for the contract content.

[0059] This step first acquires the raw message data from the contract generation process, including key fields such as policyholder information, insurance terms, sum insured, and insurance period. Simultaneously, the system generates a 17-bit gray barcode. This gray barcode is typically generated by the system using an encryption algorithm based on the policy number, generation timestamp, and random number, ensuring its uniqueness and irreversibility. Subsequently, the system concatenates the gray barcode with the message data into a string, performs a hash operation using a secure hash algorithm (such as SHA-256), and generates a fixed-length digest value. This digest value is then written to the metadata field of the PDF document, such as the / Metadata or / Custom tag, ensuring that it is invisible in the document structure but can be read and verified by the program.

[0060] In this embodiment of the invention, the gray barcode is 17 digits long, conforming to common unique identifier design specifications and effectively avoiding duplication and collisions. The preferred hash algorithm is SHA-256, which has an output length of 256 bits, providing high collision resistance and security. Furthermore, the system can optionally standardize the data before hashing, such as removing spaces and unifying the encoding format, to ensure the stability and consistency of the hash value.

[0061] This step is widely used in the electronic generation and distribution of insurance contracts. Once the contract PDF document is generated, the system sends it to the insurance contract production center for printing or sends it to the customer via email, SMS, or other means. In the subsequent contract verification stage, the system can extract the hash value from the PDF metadata and compare it with the hash value recalculated from the current message data and the gray barcode. If they do not match, it can be determined that the document has been tampered with, thus achieving the anti-counterfeiting and anti-tampering functions of the contract.

[0062] Furthermore, the technical effect of this step is to significantly enhance the credibility and security of insurance contracts. By binding gray barcodes to message data and embedding them with PDF metadata, the system implements a digital fingerprint function for the contract content, ensuring data integrity during transmission and storage. Simultaneously, this mechanism provides reliable technical support for contract auditing, traceability, and compliance checks, enhancing the system's overall anti-counterfeiting capabilities.

[0063] S4. The PDF document is formatted using tag rendering technology, and an insurance contract file conforming to a unified standard is output.

[0064] Specifically, in some implementations, formatting the PDF document using tag-based rendering technology and outputting an insurance contract file conforming to a unified standard is a key step in achieving structured and visually standardized contract content in this invention. This step is based on the deep integration of PDF templates and XML / JSON data, utilizing a tag-driven rendering mechanism to achieve dynamic filling and style control of contract content.

[0065] In this embodiment of the invention, the tag rendering technology uses preset identifiable tags (such as...) in the PDF template. <bold> , <italic> , <color>In the rendering process, the system parses these tags and applies the corresponding style rules. For example, the system receives a PDF document generated by the merge component in the tag component, and through the parsing of the tag structure therein, the text in the specified area is bolded, italicized, color-adjusted, etc. This process usually uses PDF content stream parsing technology combined with DOM tree structure or XPath expression to achieve accurate positioning and style injection of document content.

[0066] Further, the tag rendering process needs to follow the preset style specifications, such as font size (usually 10pt or 12pt), font type (such as Song, Bold, Times New Roman), color value (such as #000000 for black, #FF0000 for red), etc. In addition, the system supports nested processing of tags, for example <bold><color red> Important Terms< / bold> < / color> < / italic> < / bold> This allows for the overlay of multiple styles. Rendering engines are typically based on open-source PDF processing libraries such as Apache PDFBox or iText, supporting the PDF / A standard to ensure the long-term readability and compliance of documents.

[0067] This step is widely used in scenarios involving the batch generation and personalization of insurance contracts. For example, when generating life insurance contracts, the system can bold key fields such as "beneficiary information" and "insured amount" to highlight them; in health insurance contracts, the "health declaration" section can be highlighted in red to remind policyholders to pay close attention. For visually impaired individuals, the system can also control font size through labels (such as setting...).<size 16pt> Markings in special embossed areas are used to meet the needs of accessible reading.

[0068] In this embodiment of the invention, this step achieves structural and visual consistency of contract content, significantly improving the readability and professionalism of the contract. Through a tag-driven rendering mechanism, the system can flexibly respond to the format requirements of different products and customer groups, while ensuring that all output documents conform to internal company or industry standards (such as the ISO 32000 document management standard), providing a solid foundation for subsequent quality inspection, archiving, and distribution.

[0069] The unified insurance contract generation method based on multi-dimensional routing in this invention can achieve efficient and unified generation and output of insurance contracts. It improves processing efficiency and format consistency through data routing and intelligent template matching, and enhances contract security by integrating anti-counterfeiting watermark and encrypted signature technologies.

[0070] Furthermore, S4 includes: S41, for PDF documents <highlight>The text within the tag is bolded and italicized; the bolding is achieved using... Marking, tilting mark.

[0071] Specifically, in some implementations, the unified contract generation and output system of the present invention performs the following steps during the PDF document generation process: <highlight>The text within the tags is bolded and italicized to enhance the readability and visual prominence of key information. This step is achieved by embedding a tag recognition and style mapping mechanism into the PDF rendering engine. Specifically, the system parses the structure of the synthesized PDF document in the tag component module and identifies the tags it contains. <highlight>The system identifies the tag and uses it as a trigger point for style modification. Upon recognizing the tag, the system invokes a preset stylesheet and applies it to the text content within the tag. Markup is used to make the font bold and apply it. The markup achieves font slant, resulting in a visually striking highlight effect in the final output PDF document.

[0072] In this embodiment of the invention, the font bold and italic style attributes can be configured through the API of the PDF generation engine, for example, by setting the Font.BOLD and Font.ITALIC flags respectively in commonly used PDF libraries such as iText or Apache PDFBox. Furthermore, the system supports... <highlight>The font size, color, and other attributes of the text within the label can be customized to meet the individual needs of different products or user groups (such as visually impaired individuals). In practical applications, this step is often used for key clauses, premium amounts, and insurance liabilities in insurance policies to ensure that users can quickly identify important content when reading the contract.

[0073] This step not only enhances the readability and professionalism of the PDF document but also strengthens the traceability and compliance of the contract content. Through a structured tagging and style separation design, the system decouples content from presentation, facilitating subsequent automated quality inspection, content extraction, and multilingual version generation. Furthermore, this mechanism works in conjunction with modules such as anti-counterfeiting watermarks and electronic signatures to ensure that highlighted content in the contract is tamper-proof, thereby enhancing the contract's legal validity and security.

[0074] S42, for <color>The text within the label is rendered with color, and the color value is defined in hexadecimal format #RRGGBB.

[0075] Specifically, in some implementations, for <color>The step of color rendering of text within tags is a key function of the tag component module in the unified insurance contract generation and output system. This step, based on input data in XML or JSON format and combined with pre-reserved tags in the PDF template, enables color control of specific areas within the contract text, thereby enhancing the readability and visual distinctiveness of the contract. Specifically, when the system receives input data containing tags... <color>After the text content of the tag, the system first parses the tag's attributes. Color values ​​are defined in hexadecimal format #RRGGBB, for example, #FF0000 represents red, and #0000FF represents blue. During parsing, the system verifies the validity of the color values, ensuring they conform to the standard hexadecimal color coding specification, which consists of a hash symbol followed by 6 hexadecimal digits, and each color channel (red, green, blue) has a value range of 00 to FF.

[0076] Furthermore, the system maps color rendering operations to specific locations in the contract document through a reserved tag mechanism within the PDF template. During the template design phase, developers insert specific tag identifiers (such as...) into the PDF. <color id="12345">This establishes a mapping relationship with the backend rendering engine. When the label component receives a label with color information, it calls the PDF rendering engine to set the color value of the corresponding text area to the color defined in the #RRGGBB format. This process is usually implemented based on PDF libraries (such as iText, Apache PDFBox, etc.) and sets the text color attribute through API calls, such as setColor(Color.decode("#FF0000")).

[0077] In this embodiment of the invention, the system supports a 24-bit true color depth, meaning each color channel is 8 bits with a value range of 0 to 255. The color rendering precision is determined by the resolution of the PDF template, typically 300 DPI or higher, to ensure that colors are not distorted during printing. Furthermore, the system supports configuring color rendering priority rules in the label component, for example, forcing the use of high-contrast colors (such as #FF0000, #0000FF) in critical areas such as terms and conditions and risk warnings to improve visual recognition.

[0078] This step is widely used to highlight key information in insurance contracts, such as terms and conditions, risk warnings, and monetary amounts. For example, in health insurance contracts, content related to "exclusions" or "waiting periods" can be highlighted using color rendering for easy identification by customers. For contracts for visually impaired individuals, the system can further enhance the perceptibility of information through combinations of color, bold font, and italics.

[0079] The technical benefits of this step lie in its ability to improve the readability and information delivery efficiency of contract documents through precise color control, while also enhancing the visual consistency and professionalism of the documents. Furthermore, color rendering, as part of anti-counterfeiting measures, can be combined with technologies such as optical watermarking and gray bars to improve the contract's tamper-proof capabilities, thereby ensuring the authenticity and legality of the contract.

[0080] The unified insurance contract generation method based on multi-dimensional routing in this invention can achieve efficient and unified generation and output of insurance contracts. It improves processing efficiency and format consistency through data routing and intelligent template matching, and enhances contract security by integrating anti-counterfeiting watermark and encrypted signature technologies.

[0081] S5, perform special processing on the PDF document according to preset visual impairment adaptation rules, the special processing includes...<key_info> The text font within the label is enlarged to 144pt, and embossed markings are added to the designated area.

[0082] Specifically, in some implementations, the visual impairment insurance contract creation step of this invention is a special PDF document processing flow tailored for visually impaired users. Its technical implementation is based on preset visual impairment adaptation rules, which enhance the readability and tactile recognition capabilities of visually impaired users by enlarging the font of specific tags and adding embossed markings to the PDF document. This step, located after the assembly and generation of the PDF document in the system flow, is an extended functional module of the output unit.

[0083] At the technical implementation level, the system first identifies the contents contained in the PDF document.<key_info> The text content of the tags, which are typically used to mark key information in the contract, such as policy number, policyholder's name, sum insured, and insurance period. After recognition, the system uses a PDF rendering engine to...<key_info> The font size of the text within the label is increased from the default value (e.g., 12pt) to 144pt to ensure that visually impaired users can clearly read it when using magnifying devices or tactile readers. The font magnification operation must follow the standard PDF document structure and ensure that the text content maintains consistent character spacing, line spacing, and paragraph alignment after magnification to avoid formatting errors caused by magnification.

[0084] Furthermore, the system adds embossed markings to designated areas. These markings are typically Braille characters or raised graphic symbols, used to assist visually impaired users in quickly locating key information through touch. The addition of embossed markings is achieved through PDF annotation layers or transparent layers, and their positions are determined by preset coordinate parameters (e.g., x=100pt, y=500pt). The size and shape of the markings must conform to the requirements for Braille printing in the ISO 27628 standard to ensure clear tactile feedback and resistance to wear.

[0085] In this embodiment of the invention, the font enlargement operation must meet the following conditions: the font size is 144pt, and the font type is a sans-serif font (such as Arial or Helvetica) to enhance readability; the raised height of the embossed markings should be controlled between 0.5mm and 1.2mm, and the width should be between 3mm and 5mm to meet the requirements of tactile comfort and recognizability.

[0086] This step applies to the creation of visually impaired versions of insurance contracts, especially when the customer is visually impaired or the contract requires a Braille reader for assistance. While generating the standard PDF contract, the system automatically triggers a visually impaired adaptation process, generating a version adapted for visually impaired users. This version is then packaged together with the standard version and stored in an object storage system for later printing or distribution.

[0087] The technical effect of this step is that, by combining enlarged fonts and embossed markings, it significantly improves the accessibility and readability of key information in insurance contracts for visually impaired users, while ensuring the integrity and consistency of the contract content. This feature not only reflects the system's inclusive design but also conforms to accessibility design principles, enhancing the accessibility of insurance services and the user experience.

[0088] S6. Store the visually impaired version of the PDF document and the standard version of the PDF document in different directories of the object storage system, with the directory paths distinguished by / accessibility / and / standard / .

[0089] Specifically, in some implementations, storing visually impaired PDF documents and standard PDF documents in different directories of an object storage system is one of the key steps in this invention to achieve differentiated document management and accessibility service support in a unified insurance contract generation and output system. This step achieves document classification management and targeted distribution by setting up a logically isolated directory structure in the object storage system, using / accessibility / and / standard / as path prefixes to store accessible documents for visually impaired users and standard format documents for ordinary users, respectively.

[0090] In this embodiment of the invention, this step relies on the directory structure design and metadata management mechanism of the object storage system. After the document is generated, the system dynamically constructs the storage path based on the document type (visually impaired or standard). For example, for a visually impaired version of the PDF, its storage path can be represented as / accessibility / <policy_id> / <version>For .pdf, the filename is .pdf, while for the standard version of PDF it is / standard / .<policy_id> / <version>.pdf. Among them,<policy_id> As a unique identifier for the policy, <version>This serves as the document version number, ensuring document traceability and version control capabilities. The path construction logic is controlled by the system's file distribution module, based on the user requirement identification results from the policy generation unit.

[0091] Furthermore, this step involves the object storage system's path naming conventions, file naming strategies, and storage performance metrics. Path naming must follow a unified naming rule, such as using UUIDs or policy numbers as unique identifiers to avoid path conflicts. File naming typically uses...<policy_id> _ <timestamp>.pdf format, in which <timestamp>To generate timestamps for version ordering and time tracing. In addition, the object storage system should support high-concurrency writing and low-latency access, usually requiring write latency below 100 ms and read latency below 50 ms to meet the real-time requirements of large-scale policy generation and distribution.

[0092] In the embodiments of the present application, this step is widely used in the multi-version distribution scenario of insurance contracts, especially in the accessibility services for visually impaired users. The visually impaired version PDF usually contains font enlargement of key information, high-contrast layout, readability optimization labels, and markers for part of the embossed content, facilitating subsequent physical printing processing. The standard version PDF follows the conventional layout and format specifications, suitable for ordinary users to download, print or archive. Through path isolation, the system can realize targeted push to different user groups, such as sending audio links or special format documents of the visually impaired version PDF to specific users through the mail system or the SMS system.

[0093] The technical effect of this step is that through the design of structured storage paths, efficient classification and management of documents are achieved, improving the maintainability and scalability of the system. At the same time, providing special version PDF documents for visually impaired users meets the accessibility design principles (WCAG 2.1 standard), enhancing the inclusiveness and compliance of the system. Further, this mechanism provides a solid data foundation for subsequent audit, version traceability and personalized services, which is an important support for the invention to realize differentiated output and user adaptation in the insurance contract generation system.

[0094] Embodiment 2 The present application relates to a kind of unified generation system of insurance contract based on multi-dimensional routing, which will be described in detail below.

[0095] One kind of unified generation system of insurance contract based on multi-dimensional routing.

[0096] (1) Contract unified generation output system: the system of generating paper insurance contract pdf to be printed file. Responsible for the typesetting of contract data to generate with format. Including the following process modules: Policy synchronization process receives data call: receive the xml and json data transmitted by unified buffer layer.

[0097] XML extraction: extract data according to XML configuration.

[0098] Idempotent storage: data enters the state of waiting for processing.

[0099] Initialization message module: increase uuid, a message with a uuid.

[0100] Data routing: Configure data routing rules in the system, routing rules are usually composed of policy number and insurance code, after configuring routing rules, you can export offline rules file, determine which template (process variable template) to use according to policy number and insurance code, determine which product the data belongs to.

[0101] Process variable setting: Set variables, determine which products to copy all product variables.

[0102] Conversion component: Data conversion (after completing the template, style sheet is matched, template has some rules, loop judgment, etc., after the message reaches this component, the component will determine which template style sheet to use according to the Type field in the message, such as picture decoration content position layout) and template calling decision (converted data determines which PDF template to call).

[0103] Generate anti-counterfeiting optical watermark: watermark, gray bar.

[0104] Anti-counterfeiting integrated data message: integration of gray bar and message data.

[0105] Merge component: after routing and data conversion, XML and PDF template synthesis.

[0106] Label component: get the merged component and get the synthesized PDF, PDF reserved label, the role is to extract these labels and perform some text bold rendering, etc., tilt, color, etc. within the specified range of label.

[0107] Assembly and generation of PDF document: clause insertion, entire policy page number generation, directory generation.

[0108] Successful data scanning: queue table query generates successful data.

[0109] Loop call distribution process: data sending state changes to distribution success data.

[0110] Rule engine: state changes to pending inspection. Prepare for inspection.

[0111] Inspection service: determine whether inspection is needed (determination: manual, automatic, no inspection needed) Insurance description: generate policy description service.

[0112] Policy file packaging and copying: policy result file is stored to outsourcing extraction directory.

[0113] Business update: distribution success.

[0114] Consumable statistics: statistics of consumables needed for file generation, business update to pending print.

[0115] Pending print policy: pending print policy is suspended and waits for print center to return print data.

[0116] Visual Impairment Insurance Contract Production: Visually impaired individuals need an additional version of the contract, with enlarged font for key information and special embossed printing for certain parts.

[0117] Key module interactions in the system process: During the data receiving phase, the policy synchronization process's data receiving module is responsible for receiving XML and JSON data from the unified buffer layer. The XML extraction module extracts data according to the XML configuration, and after processing by the idempotent database module, the data is placed in a pending state. The initialization message module adds a UUID to each message to ensure data uniqueness. The data routing module determines which template to use for contract generation based on the configured data routing rules (usually including the policy number and insurance type code).

[0118] The process variable setting module is responsible for setting variables and copying all product variables based on the judgment results. The conversion component module performs data conversion and selects the appropriate template style sheet based on the Type field in the message. The merging component module combines XML data and PDF templates to generate a preliminary PDF document. The tag component module performs special processing on tags in the PDF document, such as bolding, italics, and coloring. The PDF document assembly and generation module is responsible for inserting clauses, generating page numbers and a table of contents, and finally generating a complete PDF document.

[0119] (2) Other peripheral support systems: Signature system: digital signature, electronic seal, encryption, anti-counterfeiting.

[0120] The unified contract buffer layer system is responsible for queuing insurance contracts according to priority, smoothing out peak periods and filling in valleys.

[0121] Email system: Send emails containing an audio link to the insurance contract.

[0122] SMS system: Sends SMS messages containing an audio link to the insurance contract.

[0123] Message queue: Sends file archiving information, including various events, to the queue to notify archiving.

[0124] Object storage: A place to save other files such as PDFs and audio files.

[0125] Insurance Contract Production Center: Prints out physical insurance contract documents from PDFs.

[0126] II. System Basic Architecture and General Workflow

[0127] The data input unit includes: Enter information: Enter your personal information and policy information.

[0128] Data validation mechanism: The input data is formatted correctly and is valid through regular expressions, data range checks, and other methods.

[0129] Data cleaning: Remove duplicate, invalid, or erroneous data to ensure data quality.

[0130] The data processing unit includes: Risk assessment models: Multiple built-in risk assessment models are used to assess the risk level of a customer's life and health insurance based on their health data and personal information.

[0131] Premium calculation engine: Based on risk level, insurance product terms and conditions, and rate table, it automatically calculates key data such as premiums and coverage amount. (Based on transmitted messages) Data caching and backup: Intermediate and result data during processing will be cached and backed up regularly to prevent data loss.

[0132] The policy generation unit includes: Template library management: The system has built-in policy templates for various life insurance and health insurance, and supports template customization and expansion.

[0133] Data population and formatting: Automatically populates policy content based on policy data and the selected template, and performs formatting processing such as layout, font, and color.

[0134] Electronic signature and anti-counterfeiting: The generated paper insurance policy can support electronic signature and add anti-counterfeiting codes or watermarks to ensure the authenticity and legality of the policy.

[0135] Output unit, including: Print Management: Supports various printer models and paper sizes to ensure clear and aesthetically pleasing print results.

[0136] Quality inspection and reprint: Automatic or manual quality inspection is performed on the printed paper insurance policies. Policies that fail the quality inspection can be reprinted.

[0137] Mailing and Delivery: We offer policy mailing services or connect with third-party logistics systems to achieve rapid policy delivery.

[0138] III. Functional details and operation steps explained.

[0139] System backend processing: The data input unit receives data submitted by customers, verifies and cleans it, and then transmits it to the data processing unit. The data processing unit generates policy data based on the risk assessment model and premium calculation engine (this step can be performed within the core business system). The policy generation unit selects a suitable policy template, fills in and formats the policy data, and generates a paper policy electronic document. The output unit sends the paper policy electronic document to the printer for printing and performs quality checks simultaneously.

[0140] Exception Handling and Logging: The system has exception handling mechanisms at each processing stage. If an exception occurs (such as data format errors or calculation failures), the system will promptly notify the user and record the exception in a log. The logging function records the system's operation process, data changes, and operation history in detail, facilitating subsequent tracking and auditing.

[0141] Data Security and Protection: The system employs encryption technologies (such as SSL / TLS) to protect data during transmission. Sensitive data stored in the database (such as personal health data) is encrypted and subject to strict access control. The system is regularly scanned for and patched to ensure security.

[0142] Policy Generation Unit: The policy generation unit is the core component of the paper policy generation system, responsible for converting processed policy data into formatted paper policies. Its main functions include template selection, data filling, formatting, and anti-counterfeiting measures.

[0143] Template Selection: The policy generation unit includes a variety of life and health insurance policy templates designed for different insurance products and customer needs. When a policy needs to be generated, the system will automatically select a suitable template as the basis based on the insurance product selected by the customer and related configurations.

[0144] Data population: Once a template is selected, the policy generation unit will automatically populate the corresponding positions in the template with the policy data (such as policyholder information, insured information, sum insured, and insurance period) calculated by the data processing unit. This process ensures the accuracy and consistency of the policy information.

[0145] Formatting: After the data is populated, the policy generation unit will format the policy, including adjusting the font, optimizing the layout, and configuring the colors, to ensure that the generated paper policy is visually neat, easy to read, and meets professional standards.

[0146] Anti-counterfeiting measures: To enhance the security and anti-counterfeiting capabilities of paper insurance policies, the policy generation unit also incorporates anti-counterfeiting elements such as anti-counterfeiting codes, watermarks, or special printing processes. These anti-counterfeiting measures help verify the authenticity and legality of the policy and prevent forgery or alteration.

[0147] Output Unit: Outputs PDF files to the insurance contract production center.

[0148] IV. The main steps and considerations when selecting a template for the policy generation unit include: Product type identification: First, the policy generation unit will identify the type of life insurance or health insurance product selected by the customer.

[0149] Template Library Search: Based on the identified product type, the policy generation unit will search its built-in template library. The template library contains standardized policy templates designed for different product types, each customized according to the characteristics and regulatory requirements of the corresponding insurance product.

[0150] Matching Assessment: After retrieving candidate templates, the policy generation unit evaluates the matching degree between each template and the customer's needs. This includes comparing whether the fields, format, and layout in the template match the insurance product selected by the customer, and whether they meet the customer's personalized needs (if any).

[0151] Rule Engine Application: The policy generation unit may use a rule engine to assist in the template selection process. The rule engine contains a series of preset business rules and logic to guide template selection decisions. For example, based on the customer's geographical location, the amount of coverage purchased, or specific insurance terms, the rule engine may recommend a specific policy template.

[0152] Version control: After a template is selected, the policy generation unit also checks the template's version information to ensure that the latest and most valid template version is used. This is crucial for complying with constantly changing regulations and industry standards.

[0153] Anomaly Handling: If any issues are encountered during the template selection process (such as no matching template in the template library, rule engine conflicts, etc.), the policy generation unit will trigger an anomaly handling mechanism. This may include prompting operator intervention, providing alternative template options, or automatically recording the problem for subsequent analysis.

[0154] Recording and Auditing: Finally, the policy generation unit records the details of the selected template and the reason for selecting the template, so as to facilitate subsequent auditing and traceability.

[0155] Example 3 This invention also provides a unified insurance contract generation device based on multi-dimensional routing, such as... Figure 2 As shown, the device 10 includes: The standardized data message acquisition module 100 is used to acquire standardized data messages containing policy numbers and insurance type codes, and to assign a unique identifier to the data message; The dynamic data routing and matching module 200 is used to call preset dynamic data routing rules based on the policy number and insurance type code to determine the contract template that matches the target insurance product; The anti-counterfeiting feature integration module 300 is used to perform data conversion processing and integrate the anti-counterfeiting watermark into the contract template to generate a PDF document with anti-counterfeiting features; Tag rendering and formatting module 400 is used to format the PDF document using tag rendering technology and output an insurance contract file that conforms to a unified standard.

[0156] Example 4 To implement the methods of the above embodiments, the present invention also provides a computer device, which includes a memory and a processor; wherein the processor runs a program corresponding to the executable program code by reading executable program code stored in the memory, so as to implement the various steps of the methods described above.

[0157] Example 5 To implement the above embodiments, this application also proposes a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the method described in the foregoing embodiments.

[0158] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0159] In the description of this specification, the references to "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0160] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.< / timestamp> < / timestamp> < / version> < / version> < / version> < / color> < / color> < / color> < / color> < / highlight> < / highlight> < / highlight> < / highlight> < / color> < / highlight>

Claims

1. A unified method for generating insurance contracts based on multi-dimensional routing, characterized in that, Includes the following steps: S1, Obtain a standardized data message containing the policy number and insurance type code, and assign a unique identifier to the data message; S2, based on the policy number and insurance type code, invoke the preset dynamic data routing rules to determine the contract template that matches the target insurance product; S3, perform data conversion processing and integrate the anti-counterfeiting watermark into the contract template to generate a PDF document with anti-counterfeiting features; S4. The PDF document is formatted using tag rendering technology, and an insurance contract file conforming to a unified standard is output.

2. The method according to claim 1, characterized in that, The step of determining the contract template matching the target insurance product by invoking preset dynamic data routing rules based on the policy number and insurance type code includes: S21, the dynamic data routing rule is composed of a combination of policy number prefix features and insurance type code features, and the policy number format is matched by the regular expression ^[AZ]\d{12}$. S22, Export an offline rule file based on the routing rule matching results. The offline rule file contains a mapping relationship between template selection conditions and corresponding PDF template paths.

3. The method according to claim 1, characterized in that, The process of performing data conversion and integrating anti-counterfeiting watermarks into the contract template to generate a PDF document with anti-counterfeiting features includes: S31, An optical watermarking algorithm is used to embed an invisible watermark in a non-sensitive area of ​​the PDF document. The watermark is obtained through a formula. Perform anti-counterfeiting feature verification; S32, the gray barcode and message data are hashed and then integrated into the metadata of the PDF document. The gray barcode contains a 17-bit digital feature value.

4. The method according to claim 1, characterized in that, The formatting process of the PDF document using tag rendering technology includes: S41, for PDF documents <highlight>The text within the tag is bolded and italicized; the bolding is achieved using... Marking, tilting mark; < / highlight> S42, for <color> The text within the label is rendered with color, and the color value is defined in hexadecimal format #RRGGBB.< / color> 5. The method according to claim 1, characterized in that, Also includes: S5, perform special processing on the PDF document according to preset visual impairment adaptation rules, the special processing includes...<key_info> The text font inside the label is enlarged to 144pt, and embossed markings are added to the designated area; S6. Store the visually impaired version of the PDF document and the standard version of the PDF document in different directories of the object storage system, with the directory paths distinguished by / accessibility / and / standard / .

6. A unified insurance contract generation device based on multi-dimensional routing, characterized in that, include: The standardized data message acquisition module is used to acquire standardized data messages containing policy numbers and insurance type codes, and to assign a unique identifier to the data message; The dynamic data routing and matching module is used to call preset dynamic data routing rules based on the policy number and insurance type code to determine the contract template that matches the target insurance product; The anti-counterfeiting feature integration module is used to perform data conversion processing and integrate the anti-counterfeiting watermark into the contract template to generate a PDF document with anti-counterfeiting features; The tag rendering and formatting module is used to format the PDF document using tag rendering technology and output an insurance contract file that conforms to a unified standard.

7. A computer device, characterized in that, Including processor and memory; The processor reads executable program code stored in the memory to run a program corresponding to the executable program code, so as to implement a unified insurance contract generation method based on multi-dimensional routing as described in any one of claims 1-5.

8. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements a unified method for generating insurance contracts based on multi-dimensional routing as described in any one of claims 1-5.

Images