Electronic contract signing method and system based on PDF form

Abstract

The invention relates to the technical field of electronic contracts and information security, and particularly discloses a PDF form-based electronic contract signing method and system, and the method comprises the steps: obtaining form field information in a to-be-signed PDF contract document, and carrying out the extraction and analysis of the form field information, and obtaining field metadata; performing semantic matching and coordinate matching on the field metadata to determine a binding relationship between the fields and contract terms, and generating a field topological graph; a field rule base is constructed according to the field topological graph, and real-time verification is conducted on the logic relation between the fields through a dynamic verification engine; calling a digital certificate or a handwritten signature to sign a contract; and after signing is completed, an independent hash value is generated for each field through a field-level hash chain technology, and a hash tree is constructed to realize difference verification. According to the method, the problem of intelligent binding between PDF form fields and contract terms is solved, field-level real-time verification is realized, and format errors and business logic errors are effectively intercepted.

Description

Technical Field

[0001] This invention relates to the field of electronic contracts and information security technology. More specifically, this invention relates to a method and system for signing electronic contracts based on PDF forms. Background Technology

[0002] With the rapid development of information technology, the application of electronic contracts has gradually become an important part of enterprise digital transformation. Currently, 90% of electronic contract platforms on the market mainly rely on dedicated templates (such as DOCX format) for contract generation and signing, while enterprise historical contracts are mostly stored in PDF format. When converting these PDF contracts to dedicated templates, the loss rate of form fields (such as signature fields and fill boxes) is as high as 37%, resulting in high implementation costs and operational complexity for enterprises during the migration process. In addition, traditional PDF signing methods usually require manually dragging the signature image to the target location, taking an average of 2.3 minutes per contract, and due to positioning errors, about 15% of contracts need to be re-signed, affecting overall efficiency.

[0003] In terms of security, existing technologies typically only perform hash verification on the entire file, failing to achieve field-level tamper detection, such as modifying the amount without simultaneously updating the capitalized amount field. Furthermore, the lack of automatic verification mechanisms for critical contract fields like amount and date may lead to contract disputes. The financial industry has imposed higher compliance requirements on electronic contracts; for example, Article 13 of the Electronic Signature Law explicitly stipulates that "the content must not be altered at the time of signing," creating a clear demand for field-level anti-tampering technology. In addition, supporting PDF / A-3 format to meet the long-term archiving requirements of the EU eIDAS regulation is also a significant challenge in cross-border trade scenarios.

[0004] In summary, existing technologies have certain limitations in terms of format compatibility, signing efficiency, and security, and there is an urgent need for an innovative solution that can address these issues. Summary of the Invention

[0005] The purpose of this invention is to provide an electronic contract signing method and system based on PDF form fields, suitable for electronic contract scenarios that require rapid signing, high security, and compatibility with existing PDF files.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] In a first aspect, the present invention provides an electronic contract signing method based on PDF form fields, the method comprising the following steps:

[0008] Obtain form field information from the PDF contract document to be signed, and extract and analyze the form field information to obtain field metadata; the field metadata includes field name, type, coordinate position, validation rules, and parent-child relationship;

[0009] By performing semantic and coordinate matching on the field metadata, the binding relationship between the fields and contract terms is determined, and a field topology diagram is generated.

[0010] A field rule base is constructed based on the field topology diagram, and the logical relationships between fields are validated in real time through a dynamic validation engine;

[0011] Use digital certificates or handwritten signatures to sign contracts;

[0012] After signing, each field is assigned an independent hash value using field-level hash chaining technology, and a hash tree is constructed to enable difference verification.

[0013] When a contract is revised, incremental notarization technology is used to store only the hash value and version number of the changed fields, and the notarization is distributed through a blockchain network.

[0014] Preferably, form field information from the PDF contract document to be signed is obtained, and the form field information is extracted and analyzed to obtain field metadata, including:

[0015] The PDF contract document to be signed is scanned using a PDF parsing engine, and the field metadata of the form fields is extracted.

[0016] The extracted field metadata is categorized and organized to generate a field list; the field list includes the field identifier, the clause number to which the field belongs, and the logical dependencies of the field.

[0017] Preferably, the step of determining the binding relationship between fields and contract terms by performing semantic and coordinate matching on the field metadata and generating a field topology diagram includes:

[0018] Calculate the weighted Jaccard similarity between field descriptions and clause keywords to determine the semantic matching relationship between fields and clauses, and obtain the semantic matching results;

[0019] The coordinate matching relationship between the field and the clause text is calculated using the Euclidean distance algorithm to obtain the coordinate matching result;

[0020] The semantic matching results and coordinate matching results are fused to generate a field topology graph; the field topology graph uses nodes to represent fields and edges to represent the logical dependencies between fields.

[0021] Preferably, the step of constructing a field rule base based on the field topology graph and performing real-time validation of the logical relationships between fields using a dynamic validation engine includes:

[0022] Configure basic rules through a field rule base, which include validation of amount format, date format, and ID number format.

[0023] Configure Groovy scripts to customize business rules;

[0024] Establish logical relationships between fields using a field topology diagram;

[0025] When a user fills in a field, the dynamic validation engine triggers rule validation in real time based on the logical relationships described above.

[0026] Preferably, contract signing is performed by calling a digital certificate or handwritten signature, including:

[0027] Obtain digital certificate signature data and write the digital signature data into the signature dictionary of the PDF;

[0028] Obtain a handwritten signature image, convert the handwritten signature image into an SVG vector graphic, and overlay it onto the signature field layer;

[0029] During the signing process, the timestamp of the signing is automatically recorded, and the signing process is distributed and stored through a blockchain network.

[0030] Preferably, after signing, the step of generating an independent hash value for each field using field-level hash chaining technology and constructing a hash tree to achieve difference verification includes:

[0031] Perform SHA-3 hash calculation on the field ID, field value, and timestamp of each field to generate a field-level hash value;

[0032] Construct a hash tree using field-level hash values ​​as leaf nodes;

[0033] The integrity of the entire contract is verified by using the root hash value of the hash tree.

[0034] Preferably, when the contract is revised, incremental notarization technology is used to store only the hash value and version number of the changed fields, and distributed notarization is performed through a blockchain network, including:

[0035] Set initial evidence storage parameters; the evidence storage parameters include the initial block size and block interval time;

[0036] Historical version difference data is stored in IPFS, and the hash value of the difference data is written to the blockchain network.

[0037] When revising the contract, only the hash value and version number of the changed fields are stored, and the differences are verified using a hash tree;

[0038] When there is a delay in blockchain evidence storage, the evidence storage data is written to the local SQLite database and asynchronously synchronized to the blockchain network in the background service.

[0039] Secondly, the present invention provides an electronic contract signing system based on PDF forms, the system comprising:

[0040] The field parsing module is used to obtain form field information from the PDF contract document to be signed, and to extract and analyze the form field information to obtain field metadata; the field metadata includes field name, type, coordinate position, validation rules, and parent-child relationship;

[0041] The field binding module is used to determine the binding relationship between fields and contract terms by performing semantic and coordinate matching on the field metadata, and to generate a field topology diagram.

[0042] The dynamic validation module is used to construct a field rule base based on the field topology diagram and to validate the logical relationships between fields in real time through the dynamic validation engine.

[0043] The multimodal signing module is used to sign contracts by calling digital certificates or handwritten signatures;

[0044] The evidence storage module is used to generate an independent hash value for each field after signing, and to build a hash tree to achieve difference verification.

[0045] The audit module is used to store only the hash value and version number of the changed fields when the contract is revised, using incremental evidence storage technology, and performs distributed evidence storage through a blockchain network.

[0046] Preferably, the field parsing module includes:

[0047] The field extraction module is used to scan the PDF contract document to be signed using a PDF parsing engine and extract the field metadata of the form fields.

[0048] The field analysis module is used to classify and organize the extracted field metadata and generate a field list; the field list includes the field identifier, the clause number to which it belongs, and the logical dependencies of the field.

[0049] Preferably, the field binding module includes:

[0050] The semantic matching module is used to calculate the weighted Jaccard similarity between field descriptions and clause keywords, determine the semantic matching relationship between fields and clauses, and obtain semantic matching results.

[0051] The coordinate matching module is used to calculate the coordinate matching relationship between fields and clause text using the Euclidean distance algorithm, and obtain the coordinate matching results.

[0052] This invention provides an electronic contract signing method and system based on PDF form fields. By introducing field-level parsing and intelligent binding technology, it solves the problem of intelligent binding between PDF form fields and contract terms. Through a dynamic rule engine and cross-field association verification technology, real-time field-level verification is achieved, effectively intercepting formatting errors and business logic errors. Field-level hash chain technology and incremental evidence storage technology significantly improve the accuracy of contract tampering detection and reduce the storage space required for evidence storage. This method not only allows direct reuse of existing enterprise PDF templates but also retains the dynamic attributes of the original form, avoiding secondary modifications. Furthermore, by optimizing the structure through blockchain evidence storage, audit location time is shortened and blockchain storage costs are reduced. Attached Figure Description

[0053] Figure 1 This is a flowchart of an electronic contract signing method based on PDF form fields provided by the present invention.

[0054] Figure 2 yes Figure 1 A flowchart of a preferred embodiment of step S1.

[0055] Figure 3 yes Figure 1 A flowchart of a preferred embodiment of step S2.

[0056] Figure 4 yes Figure 1 A flowchart of a preferred embodiment of step S5.

[0057] Figure 5 This is a schematic diagram of an electronic contract signing system based on PDF form fields provided by the present invention.

[0058] Figure 6 yes Figure 5 A schematic diagram of a preferred embodiment of the field parsing module.

[0059] Figure 7 yes Figure 5 A schematic diagram of a preferred embodiment of the field binding module. Detailed Implementation

[0060] 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 some embodiments of the present invention, but not all embodiments.

[0061] Reference Figure 1 This invention provides an electronic contract signing method based on PDF form fields, the method comprising the following steps:

[0062] S1. Obtain the form field information in the PDF contract document to be signed, and extract and analyze the form field information to obtain field metadata.

[0063] In step S1, the PDF contract document to be signed can be an existing PDF contract module of the enterprise or a dedicated module uploaded by the user. For the PDF contract document to be signed, this embodiment obtains the form field information and extracts the relevant field metadata. Specifically, such as... Figure 2 As shown, the steps include:

[0064] S11. Scan the PDF contract document to be signed using a PDF parsing engine and extract the field metadata of the form fields; the field metadata includes the field name, type, coordinate position, validation rules, and parent-child relationship;

[0065] S12. Classify and organize the extracted field metadata to generate a field list; the field list includes the field identifier, the clause number to which it belongs, and the logical dependencies of the field.

[0066] For example, in a PDF form containing a monetary amount field, this embodiment identifies the field as numeric, located 50px from the top left corner of the page, and its validation rules may require the input value to be positive. It is then categorized as a monetary amount field, and its logical dependency with the uppercase monetary amount field is recorded. This process ensures accurate extraction and organization of form field information, laying the foundation for subsequent processing.

[0067] S2. By performing semantic and coordinate matching on the field metadata, the binding relationship between the field and the contract terms is determined, and a field topology diagram is generated.

[0068] In step S2, this embodiment performs semantic matching and coordinate matching on the field metadata to determine the binding relationship between the field and the contract terms, such as... Figure 3 As shown, specifically, it includes the following steps:

[0069] S21. Calculate the weighted Jaccard similarity between field descriptions and clause keywords to determine the semantic matching relationship between fields and clauses, and obtain the semantic matching results;

[0070] S22. Calculate the coordinate matching relationship between the field and the clause text using the Euclidean distance algorithm to obtain the coordinate matching result;

[0071] S23. The semantic matching result and the coordinate matching result are fused to generate a field topology graph.

[0072] The semantic matching and coordinate matching are described in detail below.

[0073] In the semantic matching phase, the field description text and contract terms first need to be standardized and preprocessed. The preprocessing process includes:

[0074] Text cleaning: Remove special characters, punctuation marks, etc.

[0075] Word segmentation: A word segmenter enhanced with a professional legal dictionary;

[0076] Stop word filtering: Preserves key terms in legal documents;

[0077] Word form reduction: restoring words in different forms to their basic form;

[0078] Regarding the content of contract terms, this embodiment also needs to extract representative term keywords, which are usually terms, phrases or named entities that can reflect the core content of the terms.

[0079] Keyword extraction employs a hybrid approach combining the TF-IDF (Term Frequency-Inverse Document Frequency) algorithm and the TextRank algorithm. The TF-IDF algorithm identifies words that appear frequently in specific clauses but less frequently in the entire document, highlighting the unique content of each clause. The TextRank algorithm, based on a graph model, calculates word importance and captures semantically key nodes. The extracted keywords and their weights constitute the semantic feature vector of each clause, preparing for subsequent similarity calculations.

[0080] In step S21, the Jaccard similarity between the field description and the clause keywords is calculated using the following formula:

[0081]

[0082] Here, A represents the set of field descriptions, and B represents the set of clause keywords.

[0083] To account for word weights, a weighted Jaccard similarity algorithm is used, with the following formula:

[0084]

[0085] in and These represent the weights of word i in sets A and B, respectively.

[0086] The specific calculation steps include:

[0087] The field descriptions and term keyword sets are converted into a weighted term set, and each term is assigned a TF-IDF weight.

[0088] All words in the two word sets are weighted and aligned, with the weight of words that do not appear being set to 0.

[0089] Calculate the sum (numerator) of the minimum weights of all words in the two word sets;

[0090] Calculate the sum of the maximum weights of all words in the two word sets (denominator);

[0091] Divide the numerator by the denominator to obtain the weighted Jaccard similarity value.

[0092] Based on the calculated weighted Jaccard similarity values, a multi-level threshold strategy is used to determine the semantic matching relationship between fields and terms:

[0093] High match: Similarity value ≥ 0.7, fields and terms clearly match;

[0094] Possible match: 0.4 ≤ similarity value < 0.7, further confirmation via coordinate matching is needed;

[0095] Low match: Similarity value <0.4, the fields and terms are likely not a match.

[0096] For field groups with parent-child relationships, a holistic matching strategy is employed. The similarity between the parent field and the clause is calculated and applied as a holistic consideration to all child fields. This strategy ensures semantic consistency among related fields and prevents field groups from being incorrectly split into different clauses.

[0097] Preferably, this embodiment can further establish a specialized legal terminology dictionary, assigning higher weight coefficients to specific legal terms appearing in the contract, such as force majeure and breach of contract, to ensure that these key terms play a more important role in similarity calculation. Simultaneously, it can support synonym mapping, associating words with different expressions but the same meaning (such as "Party A" and "Client") to improve the accuracy of semantic matching.

[0098] In step S22, this embodiment calculates the coordinate matching relationship between the field and the clause text using the Euclidean distance algorithm, as follows:

[0099] Each form field in a PDF document has its own coordinate position information, typically with the bottom left corner as the origin (0, 0), and the field's bounding box position is represented in points or points. To perform effective spatial relationship calculations, a unified coordinate space system needs to be established first. Since different PDF pages may have different sizes and resolutions, this embodiment standardizes the coordinate system of all pages into a relative coordinate system, where the page width and height are normalized to 1.0, and all field coordinates are converted to proportional values ​​relative to the page size.

[0100] The coordinate standardization process includes:

[0101] Get the actual width W and height H of the PDF page (in points);

[0102] Convert the actual coordinates (x1, y1, x2, y2) of the field to relative coordinates:

[0103]

[0104] Calculate the center point coordinates (x) of the field c y c As its representative point:

[0105]

[0106] For contract clauses, it is necessary to determine the bounding box of their text area. The text location information of each clause is obtained through a PDF parsing engine, the bounding rectangle of the clause text is calculated, converted to a relative coordinate system, and the coordinates of its center point are calculated. The calculation of the clause area needs to consider the overall paragraph structure, merging text lines belonging to the same paragraph into a single area to avoid misjudging the text of the same paragraph as multiple independent areas.

[0107] The Euclidean distance algorithm is used to calculate the straight-line distance between two points in multidimensional space. In two-dimensional coordinate space, the formula for calculating the Euclidean distance between two points P1(x1, y1) and P2(x2, y2) is as follows:

[0108]

[0109] In this embodiment, the Euclidean distance between the center point of the field and the center point of the clause area, as well as the shortest distance from the center point of the field to the boundary of the clause area, are calculated. Considering that clause text usually occupies a large area, while fields are usually located near the clauses, multiple spatial relationship measures are used:

[0110] Center point distance: The Euclidean distance from the center point of a field to the center point of a clause area;

[0111] Nearest boundary distance: The shortest distance from the center point of the field to the boundary box of the clause area;

[0112] Containment relationship detection: Determines whether a field is completely inside the clause area.

[0113] For each field-term pair, the calculated Euclidean distance value needs to be normalized and converted into a similarity score. A Gaussian function is then used to map the distance to a similarity value between 0 and 1.

[0114]

[0115] Where d is the Euclidean distance and σ is a parameter that controls the decay rate, which can be set to 0.1-0.2.

[0116] The coordinate matching rules in this embodiment include:

[0117] Nearest neighbor rule: Fields are matched based on the clause with the closest spatial distance;

[0118] Regional consistency rule: Fields located in the same visual region tend to match the same clause;

[0119] Alignment rules: Field groups with alignment relationships tend to match the same clause.

[0120] The coordinate matching result is ultimately converted into a matching probability value, which, together with the semantic matching result, constitutes bimodal matching evidence. Semantic matching and coordinate matching provide evidence of field-clause matching from different modalities, and these two types of evidence need to be effectively fused to obtain the final matching result. This embodiment adopts a weighted evidence fusion strategy, assigning dynamic weights to each matching method and calculating the final matching score.

[0121] S final =α·S semantic +β·S spatial

[0122] Where S semantic It is the semantic matching score (weighted Jaccard similarity), S spatial It is the coordinate matching score (similarity based on Euclidean distance), and α and β are weight coefficients (α+β=1).

[0123] The field topology graph in this embodiment is a directed graph structure, where nodes represent fields or clauses, and edges represent the membership relationships between fields and clauses, as well as the logical dependencies between fields. The construction process of the topology graph includes:

[0124] Node creation: Create a field node for each form field and a clause node for each contract clause;

[0125] Membership edge addition: Based on the final match score, add membership edges between field nodes and clause nodes (when S...). final≥θ, where θ is the matching threshold, preferably set to 0.5)

[0126] Adding dependency edges: Add dependency edges between field nodes based on the logical dependencies in the field metadata.

[0127] The topology graph employs a hierarchical layout algorithm, treating clause nodes as upper-level nodes and field nodes as lower-level nodes. Membership edges connect nodes at different levels, while dependency edges connect field nodes at the same or different levels. Different colors and line styles are used to distinguish different types of edges: solid lines represent membership relationships, dashed lines represent dependency relationships, and arrows indicate the direction of dependency.

[0128] S3. Construct a field rule base based on the field topology diagram, and perform real-time verification of the logical relationships between fields through a dynamic verification engine.

[0129] In step S3, a field rule base is built based on the field topology graph to support real-time validation of logical relationships between fields. The dynamic validation engine traverses the dependency edges in the topology graph and checks whether the values ​​of relevant fields satisfy logical constraints. Specifically:

[0130] Configure basic rules through a field rule base, including checks on amount format, date format, and ID number format.

[0131] Configure Groovy scripts to customize business rules; for example, in a loan contract, when the contract amount exceeds 1 million, the system will forcibly add specific terms and trigger the validation of relevant fields.

[0132] Establish logical relationships between fields through field topology diagrams; for example, the amount field and the capital amount field need to maintain numerical consistency. If a user enters "10000" in the amount field but enters something other than "Ten Thousand Yuan" in the capital amount field, the system will immediately prompt an error.

[0133] As users fill in fields, the dynamic validation engine triggers rule validation in real time based on the logical relationships described above. This ensures that the field content conforms to format requirements and business logic. This process significantly improves the accuracy and compliance of contract completion.

[0134] For example, if field A depends on field B, then when the value of field B changes, the value of field A will be automatically checked to see if it is still valid.

[0135] When contract documents are revised, the system traverses the field topology graph to identify affected field-clause relationships, updates the matching strength of corresponding edges in the topology graph, and marks field dependencies that need to be re-validated. A version management mechanism maintains different versions of the topology graph, enabling the tracing and auditing of contract revision history.

[0136] Ultimately, the field topology graph and its corresponding rule base are distributed and stored through a blockchain network to ensure the immutability and verifiability of field-clause matching relationships. Each storage record contains the hash value, version number, and timestamp of the topology graph, forming a complete field-clause matching storage chain, providing technical protection for the legal validity of electronic contracts.

[0137] S4. Use digital certificates or handwritten signatures to sign contracts.

[0138] In step S4, digital certificate signature data is obtained and written into the signature dictionary of the PDF; a handwritten signature image is obtained, converted into an SVG vector graphic, and overlaid onto the signature field layer; during the signing process, the timestamp of the signing is automatically recorded, and the signing process is distributedly stored through a blockchain network.

[0139] S5. After signing, generate an independent hash value for each field using field-level hash chaining technology, and build a hash tree to achieve difference verification.

[0140] In step S5, such as Figure 4 As shown, the field-level hashing process in this embodiment is as follows:

[0141] S51. Perform SHA-3 hash calculation on the field ID, field value, and timestamp of each field to generate a field-level hash value;

[0142] S52. Construct a hash tree using field-level hash values ​​as leaf nodes; Merkle Tree is preferred.

[0143] S53. Verify the integrity of the entire contract using the root hash value of the hash tree.

[0144] S6. When a contract is revised, incremental evidence storage technology is used to store only the hash value and version number of the changed fields, and distributed evidence storage is performed through a blockchain network.

[0145] Specifically, initialization parameters for evidence storage are set, including the initial block size and block interval. Historical version difference data is stored via IPFS, and the hash values ​​of the difference data are written to the blockchain network. During contract revision, only the hash values ​​and version numbers of the changed fields are stored, and difference verification is performed using a hash tree. When blockchain evidence storage is delayed, the evidence storage data is written to a local SQLite database and asynchronously synchronized to the blockchain network in the background service. For example, in a procurement contract, if a user modifies the content of the "delivery date" field, the hash value of this field is recalculated and compared with the original hash value to quickly detect differences.

[0146] The electronic contract signing method provided in this invention is applicable to various application scenarios. For example, in the financial industry, it can meet strong compliance requirements through field-level anti-tampering technology and dynamic verification mechanisms; in cross-border trade scenarios, the system supports PDF / A-3 format to meet the long-term archiving requirements of the EU eIDAS regulation. Furthermore, existing PDF templates can be directly reused, retaining the dynamic attributes of the original form and avoiding secondary modifications. The optimized structure through blockchain-based evidence storage significantly shortens audit location time and reduces the amount of storage space required for evidence storage.

[0147] Based on the above-described electronic contract signing method, this embodiment of the invention also provides an electronic contract signing system based on PDF forms, such as... Figure 5 As shown, the system includes:

[0148] Field parsing module 1 is used to obtain form field information in the PDF contract document to be signed, and to extract and analyze the form field information to obtain field metadata; the field metadata includes field name, type, coordinate position, validation rules, and parent-child relationship;

[0149] Field binding module 2 is used to determine the binding relationship between fields and contract terms by performing semantic matching and coordinate matching on the field metadata, and to generate a field topology diagram;

[0150] Dynamic validation module 3 is used to construct a field rule base based on the field topology diagram and to perform real-time validation of the logical relationships between fields through a dynamic validation engine;

[0151] Multimodal signing module 4 is used to call digital certificates or handwritten signatures to sign contracts;

[0152] The evidence storage module 5 is used to generate an independent hash value for each field after signing, and to build a hash tree to achieve difference verification.

[0153] Audit module 6 is used to store only the hash value and version number of the changed fields when the contract is revised, using incremental evidence storage technology, and to perform distributed evidence storage through a blockchain network.

[0154] In one specific embodiment, such as Figure 6 As shown, field parsing module 1 includes:

[0155] Field extraction module 11 is used to scan the PDF contract document to be signed using a PDF parsing engine and extract the field metadata of the form fields;

[0156] The field analysis module 12 is used to classify and organize the extracted field metadata and generate a field list; the field list includes the field identifier, the clause number to which it belongs, and the logical dependencies of the field.

[0157] In one specific embodiment, such as Figure 7 As shown, field binding module 2 includes:

[0158] Semantic matching module 21 is used to calculate the weighted Jaccard similarity between field descriptions and clause keywords, determine the semantic matching relationship between fields and clauses, and obtain semantic matching results;

[0159] The coordinate matching module 22 is used to calculate the coordinate matching relationship between the field and the clause text using the Euclidean distance algorithm, and obtain the coordinate matching result.

[0160] In this embodiment of the invention, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0161] It should be noted that the system provided in the above embodiments is only illustrated by the division of the above functional modules when implementing its functions. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept, and the specific implementation process can be found in the method embodiments, which will not be repeated here.

[0162] This invention also provides a computer device including a processor and a memory, wherein the memory stores at least one instruction or at least one program, which is loaded and executed by the processor to implement the electronic contract signing method based on PDF forms as provided in the above method embodiments.

[0163] It should be noted that the order of the above embodiments of the present invention is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, specific embodiments of the present invention have been described above. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0164] The various embodiments in this invention are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device, equipment, and storage medium embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0165] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0166] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for signing electronic contracts based on PDF forms, characterized in that, The method includes the following steps: Obtain form field information from the PDF contract document to be signed, and extract and analyze the form field information to obtain field metadata; The field metadata includes the field name, type, coordinate location, validation rules, and parent-child relationship; By performing semantic and coordinate matching on the field metadata, the binding relationship between the fields and contract terms is determined, and a field topology diagram is generated. A field rule base is constructed based on the field topology diagram, and the logical relationships between fields are validated in real time through a dynamic validation engine; Use digital certificates or handwritten signatures to sign contracts; After signing, each field is assigned an independent hash value using field-level hash chaining technology, and a hash tree is constructed to enable difference verification. When a contract is revised, incremental notarization technology is used to store only the hash value and version number of the changed fields, and the notarization is distributed through a blockchain network.

2. The electronic contract signing method based on PDF forms according to claim 1, characterized in that, Obtain form field information from the PDF contract document to be signed, and extract and analyze the form field information to obtain field metadata, including: The PDF contract document to be signed is scanned using a PDF parsing engine, and the field metadata of the form fields is extracted. The extracted field metadata is categorized and organized to generate a field list; the field list includes the field identifier, the clause number to which the field belongs, and the logical dependencies of the field.

3. The electronic contract signing method based on PDF forms according to claim 1, characterized in that, The process of determining the binding relationship between fields and contract terms by performing semantic and coordinate matching on the field metadata and generating a field topology diagram includes: Calculate the weighted Jaccard similarity between field descriptions and clause keywords to determine the semantic matching relationship between fields and clauses, and obtain the semantic matching results; The coordinate matching relationship between the field and the clause text is calculated using the Euclidean distance algorithm to obtain the coordinate matching result; The semantic matching results and coordinate matching results are fused to generate a field topology graph; the field topology graph uses nodes to represent fields and edges to represent the logical dependencies between fields.

4. The electronic contract signing method based on PDF forms according to claim 3, characterized in that, The step of constructing a field rule base based on the field topology graph and performing real-time validation of the logical relationships between fields using a dynamic validation engine includes: Configure basic rules through a field rule base, which include validation of amount format, date format, and ID number format. Configure Groovy scripts to customize business rules; Establish logical relationships between fields using a field topology diagram; When a user fills in a field, the dynamic validation engine triggers rule validation in real time based on the logical relationships described above.

5. The electronic contract signing method based on a PDF form according to claim 4, characterized in that, Using digital certificates or handwritten signatures to sign contracts includes: Obtain digital certificate signature data and write the digital signature data into the signature dictionary of the PDF; Obtain a handwritten signature image, convert the handwritten signature image into an SVG vector graphic, and overlay it onto the signature field layer; During the signing process, the timestamp of the signing is automatically recorded, and the signing process is distributed and stored through a blockchain network.

6. The electronic contract signing method based on a PDF form according to claim 5, characterized in that, After signing is completed, an independent hash value is generated for each field using field-level hash chaining technology, and a hash tree is constructed to achieve difference verification, including: Perform SHA-3 hash calculation on the field ID, field value, and timestamp of each field to generate a field-level hash value; Construct a hash tree using field-level hash values ​​as leaf nodes; The integrity of the entire contract is verified by using the root hash value of the hash tree.

7. The electronic contract signing method based on PDF forms according to claim 6, characterized in that, When a contract is revised, incremental notarization technology is used to store only the hash value and version number of the changed fields, and distributed notarization is performed through a blockchain network, including: Set initial evidence storage parameters; the evidence storage parameters include the initial block size and block interval time; Historical version difference data is stored in IPFS, and the hash value of the difference data is written to the blockchain network. When revising the contract, only the hash value and version number of the changed fields are stored, and the differences are verified using a hash tree; When there is a delay in blockchain evidence storage, the evidence storage data is written to the local SQLite database and asynchronously synchronized to the blockchain network in the background service.

8. An electronic contract signing system based on PDF forms, characterized in that, The system includes: The field parsing module is used to obtain form field information from the PDF contract document to be signed, and to extract and analyze the form field information to obtain field metadata; the field metadata includes field name, type, coordinate position, validation rules, and parent-child relationship; The field binding module is used to determine the binding relationship between fields and contract terms by performing semantic and coordinate matching on the field metadata, and to generate a field topology diagram. The dynamic validation module is used to construct a field rule base based on the field topology diagram and to validate the logical relationships between fields in real time through the dynamic validation engine. The multimodal signing module is used to sign contracts by calling digital certificates or handwritten signatures; The evidence storage module is used to generate an independent hash value for each field after signing, and to build a hash tree to achieve difference verification. The audit module is used to store only the hash value and version number of the changed fields when the contract is revised, using incremental evidence storage technology, and performs distributed evidence storage through a blockchain network.

9. The electronic contract signing system based on PDF forms according to claim 8, characterized in that, The field parsing module includes: The field extraction module is used to scan the PDF contract document to be signed using a PDF parsing engine and extract the field metadata of the form fields. The field analysis module is used to classify and organize the extracted field metadata and generate a field list; the field list includes the field identifier, the clause number to which it belongs, and the logical dependencies of the field.

10. The electronic contract signing system based on PDF forms according to claim 8, characterized in that, The field binding module includes: The semantic matching module is used to calculate the weighted Jaccard similarity between field descriptions and clause keywords, determine the semantic matching relationship between fields and clauses, and obtain semantic matching results. The coordinate matching module is used to calculate the coordinate matching relationship between fields and clause text using the Euclidean distance algorithm, and obtain the coordinate matching results.

Images