Electronic contract management and control method, device and equipment and storage medium

Abstract

The invention relates to the technical field of electronic contract management, in particular to an electronic contract management and control method and device, equipment and a storage medium. Generating a unique key according to a preset system root key, the signature sample, the voiceprint sample and the face recognition sample; according to a preset adaptation rule and preset contract parameters, carrying out binding processing on preset contract terms to obtain a binding relationship; generating an electronic contract according to a preset love label template library, the user input service type, a preset contract version and the binding relationship; encrypting the electronic contract according to the unique key and a preset judicial chain to obtain an electronic signature contract; storing the electronic signature contract to a preset block chain; an electronic signature contract is generated by means of judicial chain authoritative endorsement encryption, and is stored in a block chain, so that distributed tamper-proof storage and a complete traceability chain are realized, and sufficient judicial efficacy and reliable evidence support are given to the electronic contract.

Description

Technical Field

[0001] This invention relates to the field of electronic contract management technology, specifically to an electronic contract control method, apparatus, equipment, and storage medium. Background Technology

[0002] The current electronic contract generation process lacks unified industry standards, resulting in fragmented templates with insufficient adaptability. Significant differences in contract formats and core clauses among different entities easily lead to disputes due to ambiguity, reducing generation efficiency and compliance. Regarding encrypted signatures, some technologies fail to meet the "reliable electronic signature" standard of the Electronic Signature Law, exhibiting issues such as insufficient algorithm security, inadequate certification authority qualifications, and simplified identity verification processes. This makes it difficult to ascertain the authenticity and uniqueness of signatures, casting doubt on their judicial validity. Evidence preservation and traceability rely on centralized storage models, making data susceptible to tampering or loss. Furthermore, inconsistent cross-platform evidence preservation standards, incomplete traceability chains, and a lack of authoritative third-party endorsement result in insufficient evidence reliability, making it difficult to effectively prove evidence in the event of a dispute. Summary of the Invention

[0003] In order to overcome the shortcomings of the prior art, the present invention aims to provide an electronic contract management method, apparatus, device and storage medium.

[0004] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: This invention provides an electronic contract management method, comprising: collecting voiceprint samples, signature samples, and facial recognition samples according to a preset number of collections; generating a unique key based on a preset system root key, signature samples, voiceprint samples, and facial recognition samples; binding preset contract terms according to preset adaptation rules and preset contract parameters to obtain a binding relationship; obtaining user input business type and generating an electronic contract based on a preset signature template library, user input business type, preset contract version, and binding relationship; encrypting the electronic contract according to the unique key and a preset judicial chain to obtain an electronically signed contract; and storing the electronically signed contract in a preset blockchain.

[0005] Furthermore, the step of generating a unique key based on the preset system root key, signature sample, voiceprint sample, and face recognition sample includes: performing hash operations on the contract version, signature sample, voiceprint sample, and face recognition sample to obtain a signing hash, a voiceprint feature hash, and a face feature hash; binding the signing hash, voiceprint feature hash, and face feature hash to obtain a signing process hash; and generating a unique key based on the system root key and the signing process hash.

[0006] Furthermore, the step of generating a unique key based on the system root key and the signing process hash includes: verifying the system root key according to a preset chi-square verification method to obtain hit frequency data, R-value parameters, and mapping results; determining whether the hit frequency data is greater than a preset frequency threshold; if the hit frequency data is greater than the frequency threshold, verifying the mapping results based on a preset adjacent value association rule to obtain a verification result; if the verification result is satisfactory, generating a unique key based on the signing process hash and the R-value parameters.

[0007] Further, the step of verifying the system root key according to the preset chi-square verification method to obtain hit frequency data, R-value parameters, and mapping results includes: performing an XOR operation on preset effective entropy data according to the system root key, a preset temporary random number, a preset first index range, and a preset second index range to obtain R-value parameters; dividing a preset value range into multiple equidistant sub-intervals according to a preset division ratio; verifying the R-value parameters according to the chi-square verification method to obtain multiple verification statistics; and mapping the multiple verification statistics to multiple equidistant sub-intervals to obtain hit frequency data and mapping results.

[0008] Furthermore, the step of encrypting the electronic contract using a unique key and a preset judicial chain to obtain an electronically signed contract includes: generating the signatory's identity and permissions based on the signing process hash; reviewing the signatory's identity and permissions using the judicial chain to obtain a review result; if the review result is approved, generating a judicial evidence number based on the signatory's identity and permissions; generating a contract seal based on preset filing information and the judicial evidence number; generating a handwritten signature based on the signatory's identity and permissions and the contract seal; and encrypting the electronic contract using the unique key, the handwritten signature, and the contract seal to obtain an electronically signed contract.

[0009] Furthermore, storing the electronically signed contract in a preset blockchain includes: converting the electronically signed contract according to a preset evidence format and a preset XSLT conversion method to obtain electronic evidence data; determining whether the electronic evidence data meets preset smart contract rules; when the electronic evidence data meets the smart contract rules, selecting multiple authorized nodes from the blockchain according to a preset selection number; and storing the electronic evidence data in the multiple authorized nodes.

[0010] Furthermore, storing electronic evidence data to multiple authorized nodes includes: generating traceability keywords based on the electronically signed contract; analyzing the traceability keywords based on preset association relationships to obtain matching evidence index parameters; and storing the electronic evidence data to multiple authorized nodes based on the matching evidence index parameters.

[0011] Furthermore, an electronic contract management device includes: a sample acquisition module for acquiring voiceprint samples, signature samples, and facial recognition samples according to a preset number of acquisitions; a key generation module for generating a unique key based on a preset system root key, signature samples, voiceprint samples, and facial recognition samples; a binding processing module for binding preset contract terms according to preset adaptation rules and preset contract parameters to obtain a binding relationship; an electronic contract generation module for acquiring user-input business types and generating electronic contracts based on a preset signature template library, user-input business types, preset contract versions, and binding relationships; an encryption processing module for encrypting the electronic contracts according to the unique key and a preset judicial blockchain to obtain electronically signed contracts; and a storage module for storing the electronically signed contracts on a preset blockchain.

[0012] Furthermore, an electronic contract management device includes: a memory and at least one processor, wherein the memory stores instructions; at least one processor invokes the instructions in the memory to cause the electronic contract management device to perform the steps of an electronic contract management method as described in any one of the above descriptions.

[0013] Furthermore, a computer-readable storage medium stores instructions that, when executed by a processor, implement the steps of an electronic contract management method as described in any one of the above descriptions.

[0014] In the technical solution of this invention, by pre-setting industry-specific adaptation rules and a dedicated signature template library, scenario templates are accurately matched based on business type. Combined with an automated binding mechanism for contract parameters and clauses, this replaces manual matching of each clause, avoiding disputes caused by missing, mismatched, or ambiguous clauses. It also forms a standardized generation process, improving contract generation efficiency, adaptability, and compliance, ensuring that the content aligns with actual business needs. By collecting biometric samples from multiple dimensions and combining them with the system root key through hash operations to generate a unique key, it fully meets the requirements for reliable electronic signatures, ensuring the authenticity and uniqueness of the signature and solving problems such as simplified identity verification and insufficient algorithm security. Relying on the authoritative endorsement of the judicial blockchain, the electronic signature contract is encrypted and generated and stored on the blockchain, realizing distributed tamper-proof storage and a complete traceability chain. This gives the electronic contract full judicial validity and reliable evidence support, making it easily accepted in disputes and effectively solving the problem of difficulty in providing evidence. The overall process achieves standardization, automation, and security upgrades, comprehensively ensuring the legality, compliance, security, and trustworthiness of electronic contracts, and adapting to the needs of various business scenarios. Attached Figure Description

[0015] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1A first flowchart of an electronic contract management method provided in an embodiment of the present invention; Figure 2 A second flowchart of an electronic contract management method provided in an embodiment of the present invention; Figure 3 A third flowchart of an electronic contract management method provided in an embodiment of the present invention; Figure 4 A fourth flowchart of an electronic contract management method provided in an embodiment of the present invention; Figure 5 A fifth flowchart of an electronic contract management method provided in an embodiment of the present invention; Figure 6 A sixth flowchart of an electronic contract management method provided in an embodiment of the present invention; Figure 7 A seventh flowchart of an electronic contract management method provided in an embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of an electronic contract management device provided in an embodiment of the present invention; Figure 9 This is a schematic diagram of the structure of an electronic contract management device provided in an embodiment of the present invention. Detailed Implementation

[0016] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" or "having" and any variations thereof are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0017] For ease of understanding, the specific process of the embodiments of the present invention is described below. Please refer to [link / reference]. Figure 1 One embodiment of an electronic contract management method according to the present invention includes: 101. Collect voiceprint samples, signature samples, and face recognition samples according to the preset number of collection attempts; In this embodiment, voiceprint samples are collected using a high-fidelity microphone (or a microphone built into the mobile device). The user is required to read a designated text (such as a contract signing confirmation statement), and the voice signal is recorded simultaneously. The sampling rate is no less than 44.1kHz to ensure that the signal-to-noise ratio meets the standard and adapts to different noise environments. Signature samples are collected using electronic writing devices such as electronic pens and touch screens. The dynamic characteristics of the user's handwritten signature, such as trajectory, pressure, and writing speed, are recorded, rather than just static images, to ensure the uniqueness of the signature behavior. Face recognition samples are collected using a high-definition camera (resolution no less than 1080P), integrating infrared liveness detection technology (to prevent attacks from photos, videos, and 3D models). The user is required to complete a designated liveness action (blinking, turning the head), and multiple collections are made to filter out effective samples with clear and unobstructed facial features. 102. Generate a unique key based on the preset system root key, signature sample, voiceprint sample, and face recognition sample; In this embodiment, a unique key is generated by combining three types of samples: signature, voiceprint, and face recognition, based on the system root key for security. The sample features are first extracted and processed by hashing and other operations, and then fused with the system root key. This makes the key both associated with the signer's identity information and has high-strength security, effectively preventing forgery and tampering. 103. Bind the preset contract terms according to the preset adaptation rules and preset contract parameters to obtain the binding relationship; In this embodiment, the adaptation rules can be preset according to industry and business type (such as financial business must include interest rate clauses), replacing manual matching of each clause. This process ensures the accuracy of the matching between contract parameters and clauses, avoiding problems such as missing clauses and mismatched parameters caused by human error. At the same time, it forms a standardized binding relationship, providing a unified data foundation for subsequent contract generation. Contract parameters typically cover basic information of the parties (such as name, title, identity, and contact information), core elements of the contract (amount, performance period, and details of the subject matter), business-specific content (such as interest rates for financial business and housing information for rental business), and compliance parameters associated with the adaptation rules, providing accurate data support for clause binding. 104. Obtain the user-inputted business type and generate an electronic contract based on the preset AiSign template library, the user-inputted business type, the preset contract version, and the binding relationship; In this embodiment, the generation of electronic contracts is guided by the business type input by the user. The corresponding scenario template is accurately matched from the AiSign template library (such as matching a rental contract template for a rental business). The content is then filled in by combining the preset contract version and binding relationship. This generation logic of business type-template-version-binding relationship eliminates the need for manual template selection and version adjustment, thus improving the efficiency of contract generation. At the same time, it avoids the problem of poor business adaptability caused by using general templates, ensuring that the contract content fits the actual needs. 105. Encrypt the electronic contract using a unique key and a pre-defined legal chain to obtain an electronically signed contract; In this embodiment, a unique key is used as the security core, combined with the authoritative endorsement of the judicial chain to encrypt electronic contracts. The generated electronic signature contracts have both high security and judicial validity. The unique key ensures that the contract is not forged or tampered with, and the judicial chain provides it with compliant evidence storage support, making it easily accepted in disputes and providing reliable technical protection for the legality and validity of electronic contracts. 106. Store electronically signed contracts in a pre-defined blockchain; In this embodiment, by pre-setting industry-specific adaptation rules and a dedicated signature template library, scenario templates are accurately matched based on business type. Combined with an automated binding mechanism for contract parameters and clauses, this replaces manual matching, avoiding disputes caused by missing, mismatched, or ambiguous clauses. It also establishes a standardized generation process, improving contract generation efficiency, adaptability, and compliance, ensuring content aligns with actual business needs. By collecting biometric samples from multiple dimensions and combining them with the system root key through hash calculations to generate a unique key, it fully meets the requirements for reliable electronic signatures, guaranteeing the authenticity and uniqueness of the signature and addressing issues such as simplified identity verification and insufficient algorithm security. Relying on the authoritative endorsement of the judicial blockchain, the electronically signed contract is encrypted and stored on the blockchain, achieving distributed, tamper-proof storage and a complete traceability chain. This gives the electronic contract full judicial validity and reliable evidentiary support, making it easily accepted in disputes and effectively solving the problem of difficulty in providing evidence. The overall process achieves standardization, automation, and security upgrades, comprehensively ensuring the legality, compliance, security, and trustworthiness of electronic contracts, adapting to various business scenario needs.

[0018] Please see Figure 2 In a second embodiment of an electronic contract management method according to the present invention, step 102 specifically includes: 201. Perform hash operations on the contract version, signature sample, voiceprint sample, and face recognition sample to obtain the signature hash, voiceprint feature hash, and face feature hash; In this embodiment, targeted hashing operations are performed on four types of core data: contract version, signature sample, voiceprint sample, and facial recognition sample. The signature sample and contract version are generated by SHA-256 and other algorithms to generate a signature hash. This hash value can uniquely identify the contract version. Even if there are minor changes to the version content (such as changes in the wording of the clauses), the hash value will change, preventing the risk of using an expired version. The voiceprint and facial recognition samples are not directly hashed. Instead, biometric features (such as the Mel-frequency cepstral coefficients of the voiceprint and 106 feature points of the face) are extracted first, and then the feature data is hashed using national cryptographic algorithms such as SM3 to generate voice feature hash and facial feature hash. This process not only preserves the uniqueness of biometric features, but also avoids the risk of privacy leakage caused by direct transmission and storage of the original samples, which complies with data security regulations. 202. Bind the signature hash, voiceprint feature hash, and facial feature hash to obtain the signature process hash; In this embodiment, the original data is first concatenated into 384 bits in the order of signature hash, voiceprint feature hash, and facial feature hash. Then, the SM3 hash operation is performed on the data to finally generate a 256-bit signature process hash. The fixed order ensures the consistency of the binding logic. The secondary hash transforms the multi-dimensional data into an indivisible credential, so that the signature process hash is associated with the contract version and the biometric features of the signer, forming a complete association chain of who owns the contract, who signed it, and which version was used when signing. 203. Generate a unique key based on the system root key and the hash of the signing process; In this embodiment, the uniqueness of the key can prevent forgery and tampering, it is deeply bound to the signing scenario, facilitates traceability, and provides reliable support for the encryption of electronic contracts; In this embodiment, a precise hashing and binding mechanism is used to ensure the security of electronic contracts. The SHA-256 algorithm is used to generate a signature hash for the contract version and signature sample, realizing a unique identifier for the contract version and effectively preventing the risk of using expired versions. The biometric sample first extracts core features and then hashes them using the SM3 national cryptographic algorithm, which not only preserves the uniqueness of the identity but also avoids the leakage of the original data, complying with data security regulations. The signature process hash generated by binding multiple hashes in a fixed order and performing secondary hashing builds a complete association chain between the contract and the identity, clearly tracing the ownership and signing information. Combined with the unique key generated by the system root key, it has both anti-forgery and tamper-proof characteristics and scenario binding attributes, providing highly reliable support for electronic contract encryption and improving the security of encrypted data.

[0019] Please see Figure 3 In a third embodiment of an electronic contract management method of the present invention, step 203 specifically includes: 301. Verify the system root key according to the preset chi-square verification method to obtain the hit frequency data, R value parameter and mapping result; In this embodiment, chi-square verification determines whether the root key meets the preset security characteristics by calculating the deviation between the actual observed value and the theoretical expected value. The R-value parameter is the product of the fusion operation of the root key, temporary random number, and effective entropy data. The fusion of multi-dimensional factors ensures its uniqueness. The hit frequency data reflects the reasonableness of the distribution of the verification statistics. The mapping result establishes the correlation between the statistics and the preset interval, providing a basis for subsequent verification. 302. Determine whether the hit frequency data is greater than the preset frequency threshold; 303. When the hit frequency data is greater than the frequency threshold, the mapping result is verified based on the preset adjacent value association rule to obtain the verification result; In this embodiment, the frequency threshold is a security benchmark set based on a large number of security tests. If the hit frequency is lower than the frequency threshold, it indicates that the distribution of the root key verification statistics is abnormal, and the root key may be at risk of leakage or tampering, so the process is terminated directly. Only when the hit frequency is higher than the frequency threshold can the basic validity of the root key be proven, and the process can proceed to the next step, filtering out invalid root keys and improving process efficiency. After the hit frequency data is greater than the frequency threshold and passes the verification, the adjacent value association rule analyzes the correlation of the statistical values ​​of adjacent intervals in the mapping result (such as correlation coefficient and distribution trend) to determine whether there is human intervention or random error in the data. A single frequency meeting may have accidental factors, while the adjacent value association verification verifies the rationality from the internal logic level of the data and ensures the authenticity of the mapping result. 304. If the verification result is satisfactory, a unique key is generated based on the signing process hash and the R value parameter. In this embodiment, the signing process hash ensures that the generated unique key is associated with a specific signing entity and contract, while the R value parameter continues the security attributes of the root key, avoiding the problem of the key becoming disconnected from the signing scenario; In this embodiment, the chi-square verification accurately judges the security characteristics of the root key from a statistical perspective, and the generated R-value parameter lays a solid foundation for key security. The frequency threshold screening and adjacent value association rules can quickly filter out invalid root keys to improve process efficiency, while eliminating the risk of accidental compliance, ensuring that the verification results are true and valid, and improving the key security compliance rate. The unique key generated in the end continues the security attributes of the system's root key. At the same time, the unique key generation logic is verifiable and traceable, providing strong technical support for electronic contract encryption and improving the acceptance of encrypted data in judicial scenarios.

[0020] Please see Figure 4 In the fourth embodiment of an electronic contract management method of the present invention, step 301 specifically includes: 401. Perform an XOR operation on the preset effective entropy data based on the system root key, the preset temporary random number, the preset first index range, and the preset second index range to obtain the R value parameter; In this embodiment, an XOR operation is performed using the system root key, a temporary random number, a first index range, a second index range (each index range is used to accurately define the operation boundary and avoid data overflow and invalid calculations), and effective entropy data (a high-purity random source to ensure the basic randomness threshold) to generate an R-value parameter. The XOR operation has the characteristics of high efficiency and strong anti-collision. The participation of multiple parameters can maximize the unpredictability of the R-value: the temporary random number prevents the operation logic from being reverse-engineered, the index range enables precise control of the operation process, and the effective entropy data provides a high-security random foundation, avoiding the problem of insufficient randomness caused by a single parameter, and solving the pain point that the basic parameters of traditional keys are easily cracked by brute force or mathematical derivation. 402. Divide the preset value range into equal intervals according to the preset division ratio to obtain multiple equal-interval sub-intervals; In this embodiment, the minimum possible value of R (usually 0, since the result of the XOR operation is a non-negative integer) and the maximum possible value (e.g., 2) are determined. 128 -1), forming a complete value range "min~max", ensuring that all R values ​​are within this range. The number of sub-ranges is preset according to the business security level (3-20, the higher the security level, the more the number), and the corresponding division ratio is "equal weight distribution" (1:1:…:1). The total length of the value range (max-min) is divided by the number of sub-ranges to obtain the length of each sub-range. Then, the boundary of each sub-range is derived in turn. Example: Value range "0~1000", number of sub-ranges 5, division ratio 1:1:1:1:1, then the interval length = 1000 / 5 = 200, the 5 equidistant sub-ranges are "0-200", "200-400", "400-600", "600-800", "800-1000"; 403. Verify the R-value parameter using the chi-square verification method to obtain multiple verification statistics; In this embodiment, the verification logic of the chi-square verification R value parameter is as follows: First, the R value is set to conform to the theoretical random distribution. A sufficient number of R value samples are extracted from the R value parameter to obtain the actual observation frequency. The theoretical expected frequency is calculated in combination with the total sample size. Then, by analyzing the deviation between the actual observation frequency and the theoretical expected frequency, multiple verification statistics are generated. All multiple verification statistics are chi-square statistics, which provide a quantitative security basis for key generation. 404. Map multiple validation statistics to multiple equidistant sub-intervals to obtain hit frequency data and mapping results; In this embodiment, a standardized statistical benchmark is constructed by using equidistant sub-intervals, so that the validation statistics of R value (such as chi-square statistic) can be uniformly mapped to each sub-interval. If R value is a highly random parameter, its validation statistics will be evenly distributed in each sub-interval (with similar hit frequencies); if it is a pseudo-random parameter, it will hit a few sub-intervals in a concentrated manner (with large differences in hit frequencies), thereby accurately screening out low-security R values. In this embodiment, multi-parameter XOR operations, combined with factors such as the system root key and temporary random numbers, enhance the unpredictability of the R value, avoiding the risks of reverse engineering and brute-force attacks, and addressing the pain point of insufficient randomness in traditional key basic parameters. The equally weighted sub-intervals provide a standardized statistical benchmark for verification, ensuring objective and fair statistical results. Chi-square verification quantifies the deviation between actual and theoretical frequencies to generate accurate verification statistics, thus determining randomness. In the statistical value mapping stage, pseudo-random parameters are accurately filtered out by identifying differences in frequency distribution. The entire process is automated and standardized, ensuring computational efficiency while controlling the quality of core key generation parameters. This provides reliable security support for key aspects such as electronic contract encryption and electronic signatures, adapting to high-security business scenarios and enhancing the overall encryption system's resilience and compliance.

[0021] Please see Figure 5 In the fifth embodiment of an electronic contract management method of the present invention, step 105 specifically includes: 501. Generate the signatory's identity and permissions based on the hash of the signing process; In this embodiment, the signing process hash is an irreversible and unique identifier previously generated by binding the contract version, voiceprint features, and facial features with triple hashes. Its essence is a digital fingerprint of the signatory's identity and contract information. The signatory's identity and permissions are generated with this hash as the core, which not only ensures that identity and permissions are bound to the signing process to avoid identity impersonation (the uniqueness of the hash determines that permissions cannot be forged), but also realizes the association between identity, signing behavior, and contract content, solving the pain point of the disconnect between identity and permissions and signing behavior in traditional electronic signatures. 502. Verify the identity and permissions of the signatory based on the legal chain to obtain the verification result; In this embodiment, the judicial chain, as a consortium chain connecting notary offices, authoritative CA institutions, and judicial appraisal centers, possesses inherent judicial credibility. The judicial chain verifies the identity and permissions of the generated signatories. The core verification dimensions include the authenticity of the signator's identity information (cross-verification with the public security identity system and enterprise business registration system), the validity of biometric authentication (verification of voiceprint and facial feature liveness detection records), and the voluntariness of the signing behavior (verification of operation logs showing no abnormal interference traces). The verification process is confirmed by the consensus of the judicial chain nodes, and the results are transparent and traceable, ensuring that the identity and permissions of those who pass the verification fully comply with the requirements of the Electronic Signature Law for the qualifications of subjects who can make reliable electronic signatures, and preventing illegal subjects or false identities from participating in the signing. 503. If the review result is "approved", a judicial evidence number will be generated based on the signatory's identity and authority. In this embodiment, the judicial evidence number generated after the review is approved is a unique legal identifier assigned by the judicial chain, which includes core information such as the signatory's identity code, signing timestamp, and judicial chain node verification identifier. This number is not only a filing certificate for the electronic contract in the judicial system, but also a key index for quickly retrieving judicial evidence records in subsequent dispute resolution, so that the electronic contract has judicial traceability from the beginning of its generation, solving the problem that traditional electronic contracts lack authoritative legal identifiers and are difficult to link to judicial resources when presenting evidence. 504. Generate contract seals based on preset filing information and judicial evidence numbers; In this embodiment, a contract seal is generated based on the filing information of the signatory (such as business license filing or personal identity filing) and the judicial evidence number, ensuring that the name, style, and usage rights of the seal are consistent with the legal qualifications of the signatory, avoiding the risk of forging electronic seals, and complying with relevant regulations on corporate seal management. 505. Generate a handwritten signature based on the signatory's identity and authority, and the contract seal; In this embodiment, a unique handwritten signature is generated by combining the signer's identity and permissions (including handwriting feature association data). This not only retains the personalized characteristics of offline handwritten signatures, but also achieves a unique correspondence between the signature and the subject through identity and permission binding, avoiding behaviors such as proxy signing and forged signatures, and meeting the exclusivity requirements of electronic signatures. 506. Encrypt the electronic contract using a unique key, handwritten signature, and contract seal to obtain an electronically signed contract; In this embodiment, a unique key provides underlying data encryption protection (a high-security key based on card verification), while handwritten signatures and contract seals serve as additional encryption layers. This not only achieves the intuitive effect of making the signatures visible, but also forms a protection system of encryption protection, identity association, and signature verification through their binding relationship with identity permissions. The encrypted data is irreversible, and any tampering will result in a mismatch between the hash values ​​of the signature, seal, and contract content, thus technically preventing the possibility of contract tampering. In this embodiment, identity permissions are generated using the hash of the signing process, thus linking identity with signing behavior and preventing the impersonation of the signatory. Judicial chain verification ensures that identity permissions comply with the requirements of the Electronic Signature Law, preventing the participation of illegal entities. Judicial evidence storage numbers construct judicial filing certificates and retrieval indexes, improving the convenience of evidence presentation. Compliant contract seals and personalized handwritten signatures prevent forgery and proxy signing, meeting the exclusivity requirements of electronic signatures. Relying on a highly secure unique key and seal encryption, it ensures that the contract is tamper-proof and the signatory cannot deny its rights. The entire process is compliant and transparent, and the legal effect of the seal is equivalent to that of a physical seal, increasing judicial acceptance and adapting to electronic signing scenarios with high compliance requirements in multiple fields.

[0022] Please see Figure 6In the sixth embodiment of an electronic contract management method of the present invention, step 106 specifically includes: 601. Convert the electronically signed contract according to the preset evidence format and the preset XSLT conversion method to obtain electronic evidence data; In this embodiment, the electronic signature contract is restructured using XSLT (Extensible Stylesheet Language Transformation) technology. As a mature structured data transformation tool, XSLT can uniformly map electronic signature contracts in different formats (such as PDF, Word, and XML) into a standardized electronic evidence data format recognized by judicial authorities. This ensures that the data structure is standardized and key information is not omitted, solving the pain points of inconsistent electronic contract formats and the need for additional adaptation when presenting evidence in court. The entire conversion process is automated, avoiding data distortion caused by manual intervention and ensuring the originality and consistency of electronic evidence data. 602. Determine whether the electronic evidence data meets the preset smart contract rules; In this embodiment, the converted electronic evidence data needs to be automatically verified by the smart contract's preset rules. The core of this process is to achieve dual screening: first, verifying the integrity of the data (such as whether key fields such as contract number, signatory identity information, and signature timestamp are complete); second, verifying the compliance of the data (such as whether the electronic signature meets the reliable electronic signature standard, and whether the evidence data contains tamper detection marks). The decentralized nature of the smart contract ensures that the verification rules are immutable, the verification process is transparent and traceable, and the validity review can be completed without the intervention of a third party. If the data does not meet the rules, it is directly blocked to prevent invalid data from entering the evidence storage process, thus ensuring the quality and legal validity of the evidence data from the source. 603. When the electronic evidence data meets the smart contract rules, multiple authorized nodes are selected from the blockchain according to the preset selection quantity. In this embodiment, after the electronic evidence data passes verification, the system selects authorized nodes with credibility (such as notary offices, judicial appraisal centers, authoritative CA institutions, core business partners, etc.) from the blockchain network according to a preset selection number (to meet the redundancy requirements of distributed storage). The node selection follows the principles of decentralization and credibility endorsement, and the judicial recognition of the evidence data is guaranteed by the compliance qualifications of the authorized nodes. The selection process is automatically executed by smart contracts, and the nodes are selected based on preset indicators such as node reputation and storage capacity to ensure reasonable node distribution and high reliability. 604. Store electronic evidence data to multiple authorized nodes; In this embodiment, electronically signed contracts are converted into standardized, judicially recognized evidence data using the XSLT transformation method. This addresses the pain point of cumbersome evidence presentation, ensures data standardization and integrity, and verifies the electronic evidence data (integrity and compliance) through smart contracts, blocking invalid data. The rules are immutable and the verification is transparent and traceable. Authorized nodes with credibility (such as notary offices and CA institutions) are selected according to a preset number, ensuring reasonable node distribution and high reliability. Combined with distributed redundant storage, it prevents the risk of data loss and tampering from centralized storage. The overall process is compliant and efficient, improving both judicial evidence presentation efficiency and the judicial acceptance rate of evidence data, adapting to the needs of large-scale electronic contract evidence management in multiple fields.

[0023] Please see Figure 7 In the seventh embodiment of an electronic contract management method of the present invention, step 604 specifically includes: 701. Generate traceability keywords based on electronically signed contracts; In this embodiment, the traceability keywords include subject identification keywords (unique identity credentials such as signatory identity ID and judicial evidence number), contract attribute keywords (contract number, contract type (such as labor, business, medical), contract version number, and signing timestamp), and security feature keywords (technical features such as signing process hash value, unique key association identifier, and electronic seal anti-counterfeiting code). 702. Analyze the source keywords based on the preset association relationship to obtain the matching evidence storage index parameters; In this embodiment, based on the pre-set association relationship of the smart contract (such as the binding rule of judicial evidence number-signer identity ID-contract number), the consistency and integrity of keywords are verified, invalid or tampered keyword data is excluded, and the verified keywords are mapped to standardized evidence index parameters. These parameters include core fields such as node matching code, data storage path identifier, and cross-node retrieval association code. Essentially, they are used to construct a unique mapping relationship between keywords, storage nodes, and data fragments, ensuring that the index parameters have the universality and accuracy of cross-node retrieval. 703. Store electronic evidence data to multiple authorized nodes according to the matching evidence index parameters; In this embodiment, based on the data storage path identifier matching the evidence storage index parameters, the electronic evidence storage data (including the original contract text, signature information, and operation logs) is distributed to multiple authorized nodes to achieve redundant data storage. In this embodiment, keywords cover three dimensions: subject identifier, contract attributes, and security features. Combined with smart contract preset relationship verification of keyword consistency and integrity, invalid or tampered data is effectively avoided. Standardized evidence storage index parameters with cross-node retrieval universality and accuracy are generated, improving traceability retrieval efficiency. Based on matching evidence storage index parameters, targeted redundant storage of electronic evidence data (including original contract text, signature information, and operation logs) is achieved. A multi-authorized node distributed architecture avoids the risk of data tampering and loss in centralized storage, ensuring data security and controllability. Simultaneously, the complete keyword, index, and storage evidence chain, along with the credibility of authorized nodes, enhances the judicial acceptance rate of evidence data. Furthermore, the entire process complies with relevant laws and regulations, ensuring compliant and standardized operation, and comprehensively meeting the core needs of electronic contract evidence storage and traceability in multiple fields such as finance, healthcare, and government.

[0024] The above describes an electronic contract management method according to an embodiment of the present invention. The following describes an electronic contract management device according to an embodiment of the present invention. Please refer to [link / reference]. Figure 8 One embodiment of the electronic contract management device of the present invention includes: Sample acquisition module 1 is used to acquire voiceprint samples, signature samples and face recognition samples according to a preset number of acquisitions; Key generation module 2 is used to generate a unique key based on the preset system root key, signature sample, voiceprint sample and face recognition sample; Binding processing module 3 is used to bind preset contract terms according to preset adaptation rules and preset contract parameters to obtain binding relationships; The electronic contract generation module 4 is used to obtain the business type input by the user and generate an electronic contract based on the preset AiSign template library, the business type input by the user, the preset contract version and binding relationship; Encryption module 5 is used to encrypt electronic contracts based on a unique key and a preset judicial chain to obtain electronically signed contracts. Storage module 6 is used to store electronically signed contracts to a pre-defined blockchain; In this embodiment, by pre-setting industry-specific adaptation rules and a dedicated signature template library, scenario templates are accurately matched based on business type. Combined with an automated binding mechanism for contract parameters and clauses, this replaces manual matching, avoiding disputes caused by missing, mismatched, or ambiguous clauses. It also establishes a standardized generation process, improving contract generation efficiency, adaptability, and compliance, ensuring content aligns with actual business needs. By collecting biometric samples from multiple dimensions and combining them with the system root key through hash calculations to generate a unique key, it fully meets the requirements for reliable electronic signatures, guaranteeing the authenticity and uniqueness of the signature and addressing issues such as simplified identity verification and insufficient algorithm security. Relying on the authoritative endorsement of the judicial blockchain, the electronically signed contract is encrypted and stored on the blockchain, achieving distributed, tamper-proof storage and a complete traceability chain. This gives the electronic contract full judicial validity and reliable evidentiary support, making it easily accepted in disputes and effectively solving the problem of difficulty in providing evidence. The overall process achieves standardization, automation, and security upgrades, comprehensively ensuring the legality, compliance, security, and trustworthiness of electronic contracts, adapting to various business scenario needs.

[0025] Figure 9 This is a schematic diagram of the structure of an electronic contract management device 900 provided in an embodiment of the present invention. The electronic contract management device 900 can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 910 (e.g., one or more processors) and a memory 920, and one or more storage media 930 (e.g., one or more mass storage devices) for storing application programs 933 or data 932. The memory 920 and storage media 930 can be temporary or persistent storage. The program stored in the storage media 930 may include one or more modules (not shown in the diagram), each module may include a series of instruction operations on the electronic contract management device 900. Furthermore, the processor 910 may be configured to communicate with the storage media 930 and execute a series of instruction operations in the storage media 930 on the electronic contract management device 900 to implement the steps of the electronic contract management method provided in the above-described method embodiments.

[0026] An electronic contract management device 900 may further include one or more power supplies 940, one or more wired or wireless network interfaces 950, one or more input / output interfaces 960, and / or one or more operating devices 931, such as Windows Server, MacOSX, Unix, Linux, FreeBSD, etc. Those skilled in the art will understand that... Figure 9The structure of an electronic contract management device 900 shown does not constitute a limitation on an electronic contract management device 900. It may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0027] The present invention also provides a computer-readable storage medium, which can be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium, wherein the computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the steps of an electronic contract management method.

[0028] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the device or unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

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

[0030] Finally, it should be noted that the above descriptions are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. 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 managing electronic contracts, characterized in that, include: Voiceprint samples, signature samples, and face recognition samples are collected based on a preset number of collection attempts. A unique key is generated based on the preset system root key, signature sample, voiceprint sample, and face recognition sample; The pre-defined contract terms are bound according to the pre-defined adaptation rules and pre-defined contract parameters to obtain the binding relationship; Obtain the business type input by the user, and generate an electronic contract based on the preset AiSign template library, the business type input by the user, the preset contract version, and the binding relationship; The electronic contract is encrypted using a unique key and a pre-defined legal chain to obtain an electronically signed contract. Electronically signed contracts are stored in a pre-defined blockchain.

2. The electronic contract management method as described in claim 1, characterized in that, The process of generating a unique key based on a preset system root key, signature sample, voiceprint sample, and face recognition sample includes: Hash operations are performed on the contract version, signature sample, voiceprint sample, and face recognition sample to obtain the signature hash, voiceprint feature hash, and face feature hash. The signature hash, voiceprint feature hash, and facial feature hash are bound together to obtain the signature process hash; A unique key is generated based on the system root key and the hash of the signing process.

3. The electronic contract management method as described in claim 2, characterized in that, The process of generating a unique key based on the system root key and the hash of the signing process includes: The system root key is verified according to the preset chi-square verification method to obtain the hit frequency data, R value parameter and mapping result; Determine whether the hit frequency data is greater than the preset frequency threshold; When the hit frequency data is greater than the frequency threshold, the mapping result is verified based on the preset adjacent value association rule to obtain the verification result; If the verification result is satisfactory, a unique key is generated based on the signing process hash and the R value parameter.

4. The electronic contract management method as described in claim 3, characterized in that, The step of verifying the system root key according to the preset chi-square verification method to obtain hit frequency data, R-value parameters, and mapping results includes: The preset effective entropy data is XORed with the system root key, a preset temporary random number, a preset first index range, and a preset second index range to obtain the R value parameter. The preset value range is divided into equal intervals according to the preset division ratio to obtain multiple equal intervals. The R-value parameter was validated using the chi-square validation method to obtain multiple validation statistics. Multiple validation statistics are mapped to multiple equidistant sub-intervals to obtain hit frequency data and mapping results.

5. The electronic contract management method as described in claim 2, characterized in that, The process of encrypting the electronic contract using a unique key and a pre-defined legal chain to obtain an electronically signed contract includes: Generate the signatory's identity and permissions based on the hash of the signing process; The identity and permissions of the signatory are verified according to the judicial chain to obtain the verification result; If the review result is "approved", a judicial evidence number will be generated based on the signatory's identity and authority. Generate contract seals based on preset filing information and judicial evidence numbers; A handwritten signature is generated based on the signatory's identity and authority, and the contract seal. Electronic contracts are encrypted using a unique key, handwritten signature, and contract seal to obtain an electronically signed contract.

6. The electronic contract management method as described in claim 1, characterized in that, The process of storing electronically signed contracts into a pre-defined blockchain includes: The electronically signed contract is converted according to the preset evidence format and the preset XSLT conversion method to obtain electronic evidence data. Determine whether the electronic evidence data meets the preset smart contract rules; When the electronic evidence data meets the smart contract rules, multiple authorized nodes are selected from the blockchain according to the preset selection quantity. Electronic evidence data is stored on multiple authorized nodes.

7. The electronic contract management method as described in claim 6, characterized in that, The process of storing electronic evidence data to multiple authorized nodes includes: Generate traceability keywords based on electronically signed contracts; The source keywords are analyzed based on the preset association relationships to obtain matching evidence storage index parameters; The electronic evidence data is stored to multiple authorized nodes based on the matching evidence index parameters.

8. An electronic contract management device, characterized in that, include: The sample acquisition module is used to acquire voiceprint samples, signature samples, and face recognition samples according to a preset number of acquisitions. The key generation module is used to generate a unique key based on the preset system root key, signature sample, voiceprint sample and face recognition sample; The binding processing module is used to bind preset contract terms according to preset adaptation rules and preset contract parameters to obtain binding relationships; The electronic contract generation module is used to obtain the business type input by the user and generate an electronic contract based on the preset AiSign template library, the business type input by the user, the preset contract version, and the binding relationship. The encryption module is used to encrypt electronic contracts based on a unique key and a preset legal chain to obtain electronically signed contracts. The storage module is used to store electronically signed contracts to a pre-defined blockchain.

9. An electronic contract management device, characterized in that, include: A memory and at least one processor, wherein the memory stores instructions; At least one of the processors invokes the instructions in the memory to cause the electronic contract management device to perform the steps of the electronic contract management method as claimed in any one of claims 1-7.

10. A computer-readable storage medium storing instructions thereon, characterized in that, When the instructions are executed by the processor, they implement the various steps of the electronic contract management method as described in any one of claims 1-7.

Images