Task order and contract automatic signing linkage method based on finite state machine

Abstract

The present application relates to the technical field of data processing, and more particularly to a task order receiving and contract automatic signing linkage method based on a finite state machine; comprising the following steps: collecting order receiving success event data responded by a task publishing system; obtaining order receiving success event data types for state recognition of the order receiving success event data by the finite state machine and contract party information extracted from a user database by the finite state machine; matching the order receiving success event data types with a preset contract template library to obtain a contract electronic template; inputting the contract party information into the contract electronic template to form an event electronic contract; pushing the event electronic contract to contract parties to obtain a signed contract and synchronizing a completion state of the signed contract to the finite state machine. The present application not only reduces errors in manually drafting contracts, improves the efficiency of contract generation, but also reduces manual intervention, shortens the contract signing period, and realizes more efficient contract signing.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method for linking task order acceptance and automatic contract signing based on a finite state machine. Background Technology

[0002] Currently, digital service platforms, including crowdsourcing platforms, gig economy platforms, enterprise service procurement platforms, and logistics scheduling platforms, require the creation and acceptance of tasks or orders, as well as the signing of contracts. The existing task acceptance process includes the client posting the task, the service provider browsing and accepting the order, the platform or client confirming the acceptance, and the task entering the execution phase.

[0003] Before and after order acceptance, both parties draft, negotiate, and sign the contract offline or through a separate electronic contract system. The signed contract is then manually linked to the task on the platform. However, order acceptance and contract signing rely on manual synchronization of status and data transfer between different systems. Each step—order acceptance, approval, signing, and archiving—is independent and requires manual synchronization, resulting in a complex process prone to information gaps and workflow fragmentation. Furthermore, the disconnect between contract signing and task status necessitates manual intervention to trigger signing, leading to a lack of transparency and ultimately, inefficiency in contract signing. Summary of the Invention

[0004] The purpose of this invention is to provide a method for automatic linkage between task order acceptance and contract signing based on finite state machine, which solves the problem of low signing efficiency caused by the complexity of existing task order acceptance and contract signing processes.

[0005] To achieve the above objectives, this invention provides a method for linking task acceptance and automatic contract signing based on a finite state machine, comprising the following steps: Collect order acceptance success event data from the task publishing system, wherein the order acceptance success event data includes task number information, order acceptor number information, publisher number information, and node time information; After the order acceptance success event data is pushed to the finite state machine, the order acceptance success event data type that the finite state machine uses to identify the state of the order acceptance success event data is obtained, and the contract party information is extracted from the user database by the finite state machine. The data type of the successful order acceptance event is matched with the preset contract template library stored in the electronic contract system to obtain the electronic contract template; The information of the contracting parties is entered into the electronic contract template to form an electronic contract for the event; The electronic contract for the event is pushed to the contracting parties. Upon confirmation from the contracting parties, a signed contract is obtained, and the completion status of the signed contract is synchronized to the finite state machine.

[0006] The steps of pushing the order acceptance success event data to the finite state machine, obtaining the order acceptance success event data type for state identification by the finite state machine, and extracting contract party information from the user database by the finite state machine include: The order acceptance success event data is pushed to the finite state machine. In response to the finite state machine's data recognition of the order acceptance success event data, the timestamp of the data recognition information is obtained. The timestamp of the data identification information is time-corrected to obtain the corrected timestamp; Based on the calibrated timestamp, the finite state machine is used to obtain the order acceptance success event data type for state identification and to extract contract party information from the user database.

[0007] The steps of obtaining the order acceptance success event data type for state identification using the finite state machine based on the calibrated timestamp and extracting contract party information from the user database using the finite state machine include: Using the corrected timestamp, the data extraction time point of the finite state machine is determined; Based on the data extraction time points of the finite state machine, a preset state identification library and a preset user database are determined. Using the preset state recognition library, obtain the order acceptance success event data type for state recognition of the finite state machine; Using the preset user database, a finite state machine is used to extract contract party information from the user database.

[0008] The steps of pushing the order acceptance success event data to the finite state machine and obtaining the timestamp of the data identification information after the finite state machine identifies the order acceptance success event data include: The order acceptance success event data is pushed to the finite state machine to determine the receiving state of the finite state machine; If the finite state machine indicates an abnormal reception status, the order acceptance success event data will be pushed to the finite state machine again and an alarm will be triggered. If the finite state machine indicates that the reception is normal, then in response to the finite state machine's data identification of the successful order acceptance event data, a timestamp of the data identification information is obtained.

[0009] The step of matching the data type of the successful order acceptance event with the preset contract template library stored in the electronic contract system to obtain the electronic contract template includes: Identify all contract data types in the preset contract template library stored in the electronic contract system; Using all the contract data types, perform type matching on the order acceptance success event data types to obtain a matching index for each contract type; Using a preset matching index and a preset contract template library, contracts are filtered based on the matching index of each contract type to obtain electronic contract templates.

[0010] The step of using a preset matching index and a preset contract template library to filter contracts based on the matching index for each contract type to obtain an electronic contract template includes: Using a preset matching index, contracts are filtered for each contract type matching index to obtain each filtered matching index; Based on each filtering matching index and the preset contract template library, determine the filtering contract template corresponding to each filtering matching index and the weight of each contract template. Based on each screening matching index and each contract template weight, each of the screened contract templates is prioritized to obtain an electronic contract template.

[0011] The step of using a preset matching index to filter contracts for each contract type and obtaining each filtered matching index includes: Using a preset matching index, initial contract screening is performed on each contract type matching index to obtain each initial screening matching index; If the initial matching index of each filter is less than the preset matching index, then the preset contract template library is updated, and then all contract data types in the updated preset contract template library are determined and an early warning is issued. If there exists an initial matching index that is greater than or equal to the preset matching index, then extract all initial matching indices that are greater than or equal to the preset matching index as each initial matching index.

[0012] The steps involved in inputting the information of the contracting parties into the electronic contract template to form an electronic contract for the event include: Input the information of the contracting parties into the electronic contract template to obtain the initial electronic contract; The electronic initial contract is subjected to integrity verification to obtain the verified electronic initial contract; The verified electronic initial contract is then subjected to text validation to obtain the event electronic contract.

[0013] The steps for performing integrity verification on the electronic initial contract to obtain the verified electronic initial contract include: The integrity of the electronic initial contract is verified, and the integrity verification result is obtained. If the integrity verification result indicates that there is missing information in the electronic initial contract, the information of the contracting parties is re-entered into the electronic contract template, and the electronic initial contract is obtained again. After that, the integrity verification is performed and an error is detected. If the integrity verification result indicates that it is qualified, the verified electronic initial contract is obtained.

[0014] The steps for collecting the order acceptance success event data from the task publishing system include: Collect raw data of the order acceptance success event from the task publishing system; The raw data of the successful order acceptance event is preprocessed to obtain the preprocessed raw data; The preprocessed raw data is validated to obtain successful order acceptance event data.

[0015] The present invention provides a method for linking task order acceptance and automatic contract signing based on a finite state machine, which has the following advantages: This invention improves the efficiency of subsequent contract signing by collecting order acceptance success event data from the task publishing system. After pushing the order acceptance success event data to a finite state machine, the finite state machine obtains the order acceptance success event data type for state identification and extracts contract party information from the user database, thereby improving the maintainability of automatic task acceptance and contract signing, and accommodating complex signing scenarios. The order acceptance success event data type is matched with a preset contract template library stored in the electronic contract system to obtain an electronic contract template, ensuring contract content compliance and structural uniformity, reducing errors in manual contract drafting, and improving contract generation efficiency. The contract party information is then input into the electronic contract template to form an event-based electronic contract, achieving paperless contract signing. Finally, the event-based electronic contract is pushed to the contract parties. Upon confirmation from the contract parties, a signed contract is obtained, and the completion status of the signed contract is synchronized to the finite state machine. This achieves automatic generation of task acceptance and contract signing, with signing and status synchronized, reducing manual intervention and shortening the contract signing cycle. Meanwhile, finite state machines ensure compliant state transitions, and electronic signature technology safeguards the legal validity of contracts, making contract signing more efficient, faster, and more convenient. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below.

[0017] Figure 1 This is a flowchart of the first embodiment of the present invention.

[0018] Figure 2This is a flowchart of step S200 in the second embodiment of the present invention.

[0019] Figure 3 This is a flowchart of step S300 in the fifth embodiment of the present invention.

[0020] Figure 4 This is a flowchart of step S400 in the eighth embodiment of the present invention.

[0021] Figure 5 This is a flowchart of step S100 in the tenth embodiment of the present invention. Detailed Implementation

[0022] The embodiments of the present invention are described in detail below. Examples of the embodiments are shown in the accompanying drawings. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain the present invention, but should not be construed as limiting the present invention.

[0023] The first embodiment of this application is as follows: Please see Figure 1 A method for linking task order acceptance and automatic contract signing based on finite state machines includes the following steps: S100: Collect order acceptance success event data from the task publishing system. This data includes task number information, order acceptor number information, publisher number information, and node time information. Specifically, the task number (uniquely identifying the task), order acceptor number (identifying the service provider), publisher number (identifying the requester), and node time information (including acceptance time and confirmation time) are included to ensure traceability of subsequent operations. Specifically, order acceptance success event data is captured through the task publishing system API or message queue. The data format is JSON or XML, and the data includes a timestamp to record the operation sequence. This step improves data collection efficiency by reducing manual intervention; it also utilizes time information to verify the timeliness of contract signing, such as automatic reminders for timeouts.

[0024] S200: After pushing the order acceptance success event data to the finite state machine, obtain the order acceptance success event data type for state identification by the finite state machine and extract contract party information from the user database. The finite state machine in this step manages the object lifecycle using state transition rules. In the order acceptance scenario, states include pending confirmation, accepted, pending signing, and completed. State identification triggers state transitions based on events (such as order acceptance success) and extracts contract party information, such as the order acceptor and publisher IDs. The finite state machine is driven by four elements: current state, condition, action, and next state. For example, the order acceptance success event serves as a condition, triggering the state transition from pending confirmation to accepted, and extracting party information. This improves the maintainability of state management, supports complex business scenarios such as multi-state concurrent processing, and enables operation auditing through state logs.

[0025] S300: Match the successful order acceptance event data type with the preset contract template library stored in the electronic contract system to obtain an electronic contract template. The preset contract template library stores standardized contract templates, categorized by task type (e.g., service and procurement), and includes dynamic fields such as task number and party information. This step matches the corresponding template based on the order acceptance data type (e.g., service tasks), extracts the dynamic fields from the template using a rule engine or NLP technology, and binds them to fields in the event data (e.g., task number). The preset contract template library ensures contract content compliance and structural consistency, reducing errors from manual drafting and improving contract generation efficiency.

[0026] S400: Input the contract party information into the electronic contract template to form an event-based electronic contract. The event-based electronic contract is an electronic document with legal effect, created by injecting party information (such as the order recipient's and issuer's numbers) into the contract template and supporting electronic signatures. This step is completed through an electronic contract platform (such as the SafeSign platform), and then through real-name authentication, template filling, electronic signature (compliant with the Electronic Signature Law), and timestamp affixing, the event-based electronic contract is signed. Simultaneously, a hash algorithm can be used to generate a digest of the contract content, and a digital certificate issued by a CA institution ensures the signature is tamper-proof. This achieves paperless signing, reducing costs, and ensures contract security through encrypted storage.

[0027] S500: The electronic contract for the event is pushed to the contracting parties. Upon confirmation from the parties, a signed contract is obtained, and its completion status is synchronized to the finite state machine. This completion status synchronization occurs after the contract is signed, by sending the status (e.g., "signed") back to the finite state machine via API, triggering subsequent processes such as task execution. Specifically, after the electronic contract is pushed to the parties, real-time signing monitoring is achieved through an electronic signature system. Monitoring includes automatic notifications via email or SMS, synchronization across multiple devices, and signing log records, such as signing time and IP address. Status synchronization is achieved through a data synchronization mechanism, ensuring consistency between the finite state machine and the contract system state, thereby improving signing efficiency.

[0028] This invention improves the efficiency of subsequent contract signing by collecting order acceptance success event data from the task publishing system. Next, after pushing the order acceptance success event data to a finite state machine, the finite state machine obtains the order acceptance success event data type for state identification and extracts contract party information from the user database, thereby improving the maintainability of task acceptance and automatic contract signing, and accommodating complex signing scenarios. The order acceptance success event data type is matched with a preset contract template library stored in the electronic contract system to obtain an electronic contract template, ensuring contract content compliance and structural uniformity, reducing errors from manual drafting, and improving contract generation efficiency. The contract party information is then input into the electronic contract template to form an event-based electronic contract, achieving paperless contract signing. Finally, the event-based electronic contract is pushed to the contract parties. Upon confirmation from the contract parties, a signed contract is obtained, and the completion status of the signed contract is synchronized to the finite state machine. This achieves automatic generation of task acceptance and contract signing, with signing and status synchronized, reducing manual intervention and shortening the contract signing cycle. Meanwhile, finite state machines ensure compliant state transitions, and electronic signature technology safeguards the legal validity of contracts, making contract signing faster and more convenient.

[0029] The second embodiment of this application is as follows: Please see Figure 2 Based on the first embodiment, step S200 of this embodiment, after pushing the order acceptance success event data to the finite state machine, and obtaining the order acceptance success event data type for the finite state machine to perform state identification on the order acceptance success event data, and the step of the finite state machine extracting contract party information from the user database, includes: S210: The order acceptance success event data is pushed to the finite state machine. In response to the finite state machine's data recognition of the order acceptance success event data, a timestamp of the data recognition information is obtained. The timestamp of the data recognition information is a unique time stamp generated by the finite state machine through the system clock or blockchain timestamp service when parsing the order acceptance success event data, used to pinpoint the precise moment the order acceptance success event data was recognized. Specifically, the order acceptance success event data is pushed to the finite state machine via a message queue (such as Kafka). The finite state machine triggers state transition rules, such as from order acceptance to pending signing, and simultaneously calls the timestamp generation module to record the event processing time. Timestamp generation uses the NTP protocol to synchronize server time, ensuring global time consistency. This enables timeliness monitoring of contract signing, such as automatic reminders for timeouts; and utilizes the timestamp chain to prevent tampering of operations.

[0030] S220: Time verification is performed on the timestamp of the data identification information to obtain a verified timestamp. This time verification involves comparing multiple time sources (such as system clock, GPS time, and blockchain timestamps) to verify the accuracy of the timestamp and correct clock deviations. This step employs a multi-source time comparison algorithm, such as obtaining time from the system clock, GPS module, and blockchain oracle, and determining the verified timestamp using a weighted average or minimum value method. For example, if the deviation between the system clock and GPS time exceeds a preset time tolerance range, a clock synchronization service is triggered to adjust the system time, thereby avoiding system time errors caused by a single time source failure, improving time reliability, and reducing contract disputes caused by time deviations. The verification formula is expressed as: ; in, Indicates the timestamp after proofreading. Indicates the system clock. Indicates GPS time. Represents a blockchain timestamp. This indicates the preset time tolerance range (e.g., -500ms to +500ms). express The minimum value in.

[0031] S230: Based on the verified timestamp, obtain the order acceptance success event data type for status identification using the finite state machine and the contract party information extracted from the user database by the finite state machine. The order acceptance success event data type is an event type categorized by the finite state machine based on event characteristics (such as task number prefix and order acceptor type), such as service and IT maintenance, procurement and equipment procurement, etc., used to match the corresponding contract template. The contract party information is the real-name authentication information, contact information, and bank account of the order acceptor and publisher extracted from the user database (such as a CRM system), used to populate the electronic contract. This step triggers a status query based on the verified timestamp using the finite state machine, and matches the event type with the contract template library through a rule engine. Simultaneously, it calls the user database API (such as a RESTful interface) to extract the party information and injects it into the contract template to generate the final contract. Using timestamps reduces manual verification time, shortens contract signing time, enhances a transparent and efficient contract signing experience, and strengthens user trust and compliance security.

[0032] The third embodiment of this application is as follows: Based on the second embodiment, this embodiment, based on the calibrated timestamp, includes the following steps for obtaining the order acceptance success event data type for state identification using the finite state machine and extracting contract party information from the user database using the finite state machine: Using the calibrated timestamp, the data extraction time point of the finite state machine is determined. This data extraction time point is a precise moment determined based on the calibrated timestamp, used to define the effective time range of the state machine operation. This time point meets business timeliness requirements, such as contract signing needing to be triggered within one hour of order acceptance. The data extraction time point of the finite state machine can be determined using existing time window algorithms.

[0033] Based on the data extraction time point of the finite state machine, a preset state identification library and a preset user database are determined. The preset state identification library stores state transition rules, is versioned by time dimension, and includes the mapping relationship between event types and states (e.g., successful order acceptance maps to pending signing). The preset user database stores user real-name authentication information, contact information, and bank account details, indexed by timestamp to the latest valid data; historical versions are retained even after user information is updated. Specifically, the corresponding version of the preset state identification library and preset user database can be selected using the timestamp index. This avoids using expired rules or user information, ensuring that contract signing complies with current business rules and the latest user status. It also improves process compliance and reduces legal risks arising from expired rules or information.

[0034] Using the preset state recognition library, the finite state machine obtains the order acceptance success event data type for state recognition. The order acceptance success event data type is determined by matching the event categories in the state recognition library, such as service category versus IT maintenance; procurement category versus equipment procurement, used for subsequent contract template matching. This step can use a rule engine for pattern matching, such as inputting event data features (e.g., task number prefix IT-2026-001) and rule templates in the state recognition library, such as IT-* corresponding to service category versus IT maintenance. Then, state transition rules are triggered, such as order acceptance success versus pending signing, and the matched event type is output. This ensures accurate matching between event types and contract templates, improving contract template matching efficiency.

[0035] Using the pre-defined user database, a finite state machine is used to extract contract party information from the user database. This contract party information includes the real-name authentication information (such as ID card number and unified social credit code), contact information, and bank account details of the order recipient and publisher, extracted from the user database, used to populate the electronic contract. This step queries the database using the user ID or number, calls the user database API (e.g., GET / users / {user_id}), inputs the order recipient or publisher number, and returns the latest valid user information. Sensitive information (such as bank account details) is anonymized. This ensures the authenticity of the contract signing entities, and simultaneously protects user data security through anonymization and access control.

[0036] The fourth embodiment of this application is as follows: Based on the second embodiment, this embodiment pushes the order acceptance success event data to a finite state machine. The step of obtaining the timestamp of the data identification information after the finite state machine identifies the order acceptance success event data includes: The successful order acceptance event data is pushed to a finite state machine to determine the receiving state of the finite state machine. The receiving state of the finite state machine is a binary state (normal or abnormal) determined by the state machine after receiving an input event, based on the current state and transition rules, to decide whether the event is allowed to trigger a state transition. For example, if the state machine is currently in the pending order state and receives a successful order acceptance event, the receiving state is normal; if it is currently in the completed state, the receiving state is abnormal. Simultaneously, data push is implemented asynchronously through a message queue (such as RabbitMQ) or API gateway to ensure data reliability in high-concurrency scenarios. State machine rule verification ensures the consistency between event data and the current business state, avoiding invalid events triggering processes or state conflicts. This improves system fault tolerance and reduces process errors caused by inconsistent states.

[0037] If the finite state machine's receiving status indicates an abnormality, the order acceptance success event data will be pushed to the finite state machine again, and an alarm will be triggered. Receiving abnormalities include data format errors (such as missing task numbers), state conflicts (such as duplicate order acceptance), and insufficient permissions (such as unauthorized party accepting the order). Alarms will be issued in real time through multiple channels, including system logs, SMS or email notifications, and monitoring dashboards, triggering manual intervention or automatic repair processes. This reduces business interruptions caused by abnormalities and ensures the continuity of the contract signing process.

[0038] If the finite state machine's receiving status indicates normal reception, then in response to the finite state machine's data identification of the successful order acceptance event data, a timestamp of the data identification information is obtained. This timestamp chain enables full traceability of the operation process, providing an accurate time reference for subsequent contract signing procedures.

[0039] The fifth embodiment of this application is as follows: Please see Figure 3 Based on the first embodiment, step S300 of this embodiment, which involves matching the data type of the successful order acceptance event with the preset contract template library stored in the electronic contract system to obtain an electronic contract template, includes: S310: Determine all contract data types in the pre-set contract template library stored in the electronic contract system. The pre-set contract template library is a database storing standardized contract templates, categorized by business type (e.g., services, procurement, and leasing). Each template contains dynamic fields (e.g., task number and party information) and legal clauses. Contract data types are template categories based on business scenarios, such as IT services versus software development, equipment procurement versus machinery, etc. Each type corresponds to a specific contract structure and clause combination. Specifically, the template library is constructed through a combination of manual classification and machine learning: a basic classification framework is manually defined (e.g., the FIDIC contract classification standard), and machine learning models (e.g., the BERT text classifier) ​​automatically classify new templates based on historical contract data. Classification criteria include core elements such as contract subject matter, monetary range, and performance period. For example, service contracts emphasize deliverables and acceptance standards, while procurement contracts focus on price adjustment mechanisms. Standardized templates reduce legal compliance risks, thereby improving efficiency.

[0040] S320: Using all the contract data types, perform type matching on the order acceptance success event data types to obtain a matching index for each contract type. Type matching is the process of calculating the similarity between the order acceptance event data type (e.g., IT service order acceptance) and the contract data types in the template library. The matching index is a numerical value that quantifies type similarity and can be used with the existing cosine similarity formula. This step uses the TF-IDF algorithm to convert text features into vectors; for example, the feature vector for IT service categories includes keyword weights such as software development and acceptance standards. This improves matching accuracy.

[0041] S330: Using a preset matching index and a preset contract template library, contracts are filtered based on the matching index for each contract type to obtain electronic contract templates. The preset matching index threshold is the minimum similarity value required to determine a valid contract template, for example, 0.8. Templates exceeding this threshold are added to the candidate list. The contract filtering rules are based on matching index sorting and business rules (e.g., prioritizing high-priced contracts against procurement templates) to select the optimal template. Candidate templates can be sorted in descending order of matching index, and a secondary filtering can be performed using business rules (e.g., automatically matching major procurement templates for contracts exceeding 1 million). Then, a contract template engine (e.g., DocuSign) injects order event data (e.g., task number and party information) into the template's dynamic fields to generate the final electronic contract template. This reduces manual intervention, provides a more transparent and efficient contract signing experience, and enhances compliance and security.

[0042] The sixth embodiment of this application is as follows: Based on the fifth embodiment, this embodiment utilizes a preset matching index and a preset contract template library to filter contracts based on the matching index of each contract type, and the steps to obtain electronic contract templates include: Using a preset matching index, contracts are filtered based on the matching index of each contract type, resulting in a filtered matching index. The preset matching index is a system-defined threshold (e.g., 0.8) used to define the validity of the match between the contract type and the order acceptance event. This threshold is derived based on industry experience (e.g., legal compliance requirements) and machine learning model training. The filtered matching index is the set of matching indices after threshold filtering, retaining only contract types with a matching index not lower than the preset threshold. For example, if the matching index for IT services is 0.9, it enters the filtering list; if it's 0.7 for equipment procurement, it is excluded. Threshold control ensures that only high-matching templates enter the candidate pool, improving the accuracy of contract generation.

[0043] Based on each screening matching index and the preset contract template library, the corresponding screening contract template and the weight of each contract template are determined. The screening contract template is a set of candidate templates filtered by a threshold, with each template corresponding to a contract data type, such as IT services versus software development. The contract template weight is a priority coefficient calculated based on business rules (such as contract amount and customer level) or machine learning models (such as random forests), used to quantify the applicability of the template. For example, the weight of a major project template is set to 1.2, and the weight of a regular project template is 1.0. In this step, the weight of each contract template is determined by combining the basic weight of each contract template, business rules, and a hybrid model of machine learning; for example, in the business rule dimension, the correction coefficient increases by 10% when the contract amount is not less than 1 million, and by 5% when the customer is a VIP. The machine learning dimension uses an XGBoost model trained based on historical contract signing data to predict the applicability probability of the template, and the output is used as the weight correction coefficient. This allows for dynamic adjustment of weights to support special scenarios, such as prioritizing matching large contracts. The formula for calculating the weight of each contract template is as follows: ; in, The weight of the i-th contract template. The base weight of the i-th contract template. The correction factor for the business rules of the i-th contract template. Refers to the machine learning correction coefficient for the i-th contract template.

[0044] Based on each screening matching index and each contract template weight, each screened contract template is prioritized to obtain an electronic contract template. The priority ranking is a process of sorting candidate templates in descending order based on a comprehensive score of the screening matching index and contract template weight. The final selected electronic contract template is used to populate order acceptance event data and generate electronic contracts. This weighted ranking ensures that both matching accuracy and business priority are considered, improving both contract generation efficiency and customer satisfaction.

[0045] The seventh embodiment of this application is as follows: Based on the sixth embodiment, this embodiment utilizes a preset matching index to filter contracts for each contract type matching index, and the steps to obtain each filtered matching index include: Using a preset matching index, initial contract screening is performed on each contract type, resulting in an initial matching index for each screening. This initial matching index represents the actual match degree between each contract type and the order acceptance event, calculated using the cosine similarity formula. By traversing all contract types, their matching indices with the order acceptance events are determined. A vector space model is used to quantify similarity, combined with business rules (such as service contracts must match acceptance standard keywords) for secondary verification. This avoids errors caused by subjective judgment.

[0046] If the initial matching index for each filter is less than the preset matching index, the preset contract template library is updated before all contract data types in the updated library are determined and an alert is issued. The template library update is triggered when all initial matching indices are less than the preset matching index, leading to a version upgrade. Contract templates are added or modified through manual review or machine learning models (such as BERT text classifier). The alert is sent in real-time through multiple channels, including system logs, SMS or email notifications, and monitoring dashboards, prompting business personnel to check the integrity of the template library or abnormal order data. Template library versions can be managed using Git-like tools, recording the reason for each update, such as adding a new business type. Furthermore, if the total matching index falls below the threshold three times consecutively, a deep learning model is triggered to analyze order event characteristics and automatically generate template update suggestions. Version control supports business rule retrospectives, reducing compliance risks.

[0047] If an initial matching index is greater than or equal to a preset matching index, then all initial matching indices greater than or equal to the preset matching index are extracted as each initial matching index. This ensures that only high-match templates proceed to subsequent processes, improving customer satisfaction and trust, and supporting contract signing across regions and time zones.

[0048] The eighth embodiment of this application is as follows: Please see Figure 4 Based on the first embodiment, step S400 of this embodiment, which involves inputting the information of the contracting parties into the electronic contract template to form an electronic event contract, includes: S410: Input the contract party information into the electronic contract template to obtain the initial electronic contract. The initial electronic contract is a preliminary electronic document generated by injecting party information into dynamic fields of the contract template using a template engine (such as Docx-Mailmerge), in DOCX or PDF format. The initial electronic contract can be generated in batches by using a template field mapping table (e.g., {receiving party name} to user_name) and either Python's docx library or Java's Apache POI library. This improves the efficiency of contract generation.

[0049] S420: Perform integrity verification on the initial electronic contract to obtain a verified initial electronic contract. Integrity verification verifies whether the contract document contains all required fields and has not been tampered with, using a rule engine or hash algorithm. Required fields include party information, task number, amount, and performance period. Dual verification can be performed using rule verification and hash comparison. Rule verification checks field format using regular expressions and checks the integrity of required fields using a predefined rule table. Hash comparison calculates the hash value of the initial contract file and compares it with a baseline hash value in the template library to ensure the file has not been tampered with, thereby reducing the contract error rate.

[0050] S430: Perform text verification on the verified initial electronic contract to obtain the event electronic contract. Text verification uses NLP tools or a rule engine to check the grammatical correctness of the contract text and the compliance of legal clauses. The event electronic contract is the final electronic contract after integrity verification and text verification, possessing legal effect and supporting electronic signatures and blockchain notarization. This step can employ NLP analysis and a rule engine for verification. NLP analysis uses the BERT model for grammatical error correction and clause compliance checks, such as detecting abnormal clauses where the liquidated damages exceed the legal limit. The rule engine performs logical consistency verification based on a business rule base to ensure there are no contradictions between clauses. Through text verification, the legality and logical rigor of the contract content are ensured.

[0051] The ninth embodiment of this application is as follows: Based on the eighth embodiment, this embodiment performs integrity verification on the electronic initial contract to obtain the verified electronic initial contract. The steps include: The electronic initial contract undergoes integrity verification to obtain the integrity verification result. Specifically, the integrity verification result is a diagnostic conclusion generated after scanning the electronic initial contract using multi-dimensional verification rules, including three dimensions: field integrity status (e.g., whether required fields are missing), format compliance (e.g., whether the date format is correct), and hash value consistency (e.g., whether the SHA-256 value matches the template library's baseline value). Dual verification can be performed using a rule engine and a hash algorithm. The rule engine traverses all fields of the contract, judging field compliance through regular expressions, range checks (e.g., amount ≥ 0), and logical checks (e.g., start date ≤ end date). The hash algorithm uses the national cryptographic standard SM3 or SHA-256 to calculate the file's hash value, comparing it with the baseline value stored in the template library to ensure the file has not been tampered with. This improves verification accuracy, achieves tamper-proof verification through the hash algorithm, and supports audit trails.

[0052] If the integrity check result indicates that there is missing information in the electronic initial contract, the contract party information is re-entered into the contract electronic template, and after obtaining the electronic initial contract, integrity check is performed and a check exception is prompted. Among them, when missing information is detected, the system automatically re-calls the template engine to inject the party information and triggers a new round of integrity check. The check exception prompt is a real-time alarm through multiple channels such as system logs, text messages or email notifications, and monitoring dashboards, prompting the specific missing fields (such as the receiving party's bank account not filled in) and their positions. By re-entering the contract party information into the contract electronic template, and then performing integrity check after obtaining the electronic initial contract, the data filling success rate is improved, and with the exception prompt and the quick response of multi-channel alarms, problems are ensured to be exposed and processed in a timely manner, thereby reducing the business interruption time.

[0053] If the integrity check result indicates qualified, the inspected electronic initial contract is obtained. Specifically, indicating qualified adopts the methods of qualified marking and version locking, adding a digital watermark (such as verification passed - 20260129) and a timestamp to the qualified contract to prevent subsequent tampering. The contract version is locked to the currently verified version to ensure that subsequent processes (such as text verification and signing) are operated based on the same version. Thereby, the contract generation efficiency is improved; business rule backtracking is supported through version control, reducing compliance risks. Furthermore, the compliance sense of security and operation convenience are enhanced, and business disputes caused by contract errors are reduced.

[0054] The tenth embodiment of this application is as follows: Please refer to Figure 5 , based on the first embodiment, the steps of step S100 in this embodiment for collecting the data of the order receiving success event responded by the task publishing system include: S110: Collect the original data of the order receiving success event responded by the task publishing system. Among them, the original data of the order receiving success event is the initial data stream generated when the task publishing system responds to the order receiving operation, including structured fields (such as JSON / XML) and unstructured logs. The core fields include the task number (unique identifier), the receiving party number (service provider ID), the publishing party number (demander ID), the node timestamp (order receiving moment), the geographical location (optional), and the device information (such as the order receiving terminal IP), etc. Specifically, the order receiving event can be asynchronously captured through the API gateway (such as RESTful interface) or message queue (such as Kafka) of the task publishing system. The timestamp synchronizes the server time using the NTP protocol to ensure global consistency. Thereby, not only the data collection efficiency is improved, but also cross-system integration is supported through the API standardized interface, reducing the coupling degree.

[0055] S120: Perform data preprocessing on the raw data of the successful order acceptance event to obtain preprocessed raw data. Data preprocessing involves cleaning, transforming, deduplicating, and filling in missing values ​​in the raw data. For example, timestamps are converted to the ISO8601 standard format, encoding anomalies (such as UTF-8 garbled characters) are handled, and missing fields (such as the order acceptor's contact information) are filled in using the user database. This standardized format supports seamless integration with subsequent contract template matching and signing processes.

[0056] S130: Perform data verification on the preprocessed raw data to obtain order acceptance success event data. Specifically, data verification verifies the validity, integrity, and compliance of the data through a rule engine or machine learning model. For example, verifying the format of ID numbers, the range of contract amounts, and time logic. A hybrid model of rule verification and machine learning can be used. Rule verification performs hard verification based on a predefined rule base (e.g., the order acceptor's number must exist in the user database), and violations of the rules are marked as abnormal. Machine learning verification uses the XGBoost model to predict the probability of data anomalies, such as detecting abnormally high-frequency order acceptance behavior (e.g., a single account accepting more than 100 orders in one hour). Hash verification improves the calculation of the SHA-256 hash value of the preprocessed data and compares it with the hash value of the original data, thereby ensuring that it has not been tampered with during transmission. This reduces data processing time and reduces the cost of manual intervention.

[0057] The above-disclosed embodiments are merely one or more preferred embodiments of this application and should not be construed as limiting the scope of this application. Those skilled in the art can understand that all or part of the processes for implementing the above embodiments and equivalent changes made in accordance with the claims of this application still fall within the scope of this application.

Claims

1. A method for automatic linkage between task order acceptance and contract signing based on a finite state machine, characterized in that, Includes the following steps: Collect order acceptance success event data from the task publishing system, wherein the order acceptance success event data includes task number information, order acceptor number information, publisher number information, and node time information; After the order acceptance success event data is pushed to the finite state machine, the order acceptance success event data type that the finite state machine uses to identify the state of the order acceptance success event data is obtained, and the contract party information is extracted from the user database by the finite state machine. The data type of the successful order acceptance event is matched with the preset contract template library stored in the electronic contract system to obtain the electronic contract template; The information of the contracting parties is entered into the electronic contract template to form an electronic contract for the event; The electronic contract for the event is pushed to the contracting parties. Upon confirmation from the contracting parties, a signed contract is obtained, and the completion status of the signed contract is synchronized to the finite state machine.

2. The task order acceptance and automatic contract signing linkage method based on finite state machine as described in claim 1, characterized in that, After pushing the order acceptance success event data to the finite state machine, the steps of obtaining the order acceptance success event data type for state identification by the finite state machine and extracting contract party information from the user database by the finite state machine include: The order acceptance success event data is pushed to the finite state machine. In response to the finite state machine's data recognition of the order acceptance success event data, the timestamp of the data recognition information is obtained. The timestamp of the data identification information is time-corrected to obtain the corrected timestamp; Based on the calibrated timestamp, the finite state machine is used to obtain the order acceptance success event data type for state identification and to extract contract party information from the user database.

3. The task order acceptance and automatic contract signing linkage method based on finite state machine as described in claim 2, characterized in that, Based on the calibrated timestamp, the steps for obtaining the order acceptance success event data type for state identification using the finite state machine and extracting contract party information from the user database using the finite state machine include: Using the corrected timestamp, the data extraction time point of the finite state machine is determined; Based on the data extraction time points of the finite state machine, a preset state identification library and a preset user database are determined. Using the preset state recognition library, obtain the order acceptance success event data type for state recognition of the finite state machine; Using the preset user database, a finite state machine is used to extract contract party information from the user database.

4. The task order acceptance and automatic contract signing linkage method based on finite state machine as described in claim 2, characterized in that, The steps of pushing the order acceptance success event data to the finite state machine and obtaining the timestamp of the data identification information after the finite state machine identifies the order acceptance success event data include: The order acceptance success event data is pushed to the finite state machine to determine the receiving state of the finite state machine; If the finite state machine indicates an abnormal reception status, the order acceptance success event data will be pushed to the finite state machine again and an alarm will be triggered. If the finite state machine indicates that the reception is normal, then in response to the finite state machine's data identification of the successful order acceptance event data, a timestamp of the data identification information is obtained.

5. The task order acceptance and automatic contract signing linkage method based on finite state machine as described in claim 1, characterized in that, The steps of matching the data type of the successful order acceptance event with the preset contract template library stored in the electronic contract system to obtain the electronic contract template include: Identify all contract data types in the preset contract template library stored in the electronic contract system; Using all the contract data types, perform type matching on the order acceptance success event data types to obtain a matching index for each contract type; Using a preset matching index and a preset contract template library, contracts are filtered based on the matching index of each contract type to obtain electronic contract templates.

6. The task order acceptance and automatic contract signing linkage method based on finite state machine as described in claim 5, characterized in that, The steps of filtering contracts based on the matching index of each contract type using a preset matching index and a preset contract template library to obtain electronic contract templates include: Using a preset matching index, contracts are filtered for each contract type matching index to obtain each filtered matching index; Based on each filtering matching index and the preset contract template library, determine the filtering contract template corresponding to each filtering matching index and the weight of each contract template. Based on each screening matching index and each contract template weight, each of the screened contract templates is prioritized to obtain an electronic contract template.

7. The task order acceptance and automatic contract signing linkage method based on finite state machine as described in claim 6, characterized in that, The steps for filtering contracts based on the matching index of each contract type using a preset matching index, to obtain each filtered matching index, include: Using a preset matching index, initial contract screening is performed on each contract type matching index to obtain each initial screening matching index; If the initial matching index of each filter is less than the preset matching index, then the preset contract template library is updated, and then all contract data types in the updated preset contract template library are determined and an early warning is issued. If there exists an initial matching index that is greater than or equal to the preset matching index, then extract all initial matching indices that are greater than or equal to the preset matching index as each initial matching index.

8. The task order acceptance and automatic contract signing linkage method based on finite state machine as described in claim 1, characterized in that, The steps for inputting the information of the contracting parties into the electronic contract template to form an electronic contract for the event include: Input the information of the contracting parties into the electronic contract template to obtain the initial electronic contract; The electronic initial contract is subjected to integrity verification to obtain the verified electronic initial contract; The verified electronic initial contract is then subjected to text validation to obtain the event electronic contract.

9. The task order acceptance and automatic contract signing linkage method based on finite state machine as described in claim 8, characterized in that, The steps for performing integrity verification on the electronic initial contract to obtain the verified electronic initial contract include: The integrity of the electronic initial contract is verified, and the integrity verification result is obtained. If the integrity verification result indicates that there is missing information in the electronic initial contract, the information of the contracting parties is re-entered into the electronic contract template, and the electronic initial contract is obtained again. After that, the integrity verification is performed and an error is detected. If the integrity verification result indicates that it is qualified, the verified electronic initial contract is obtained.

10. The task order acceptance and automatic contract signing linkage method based on finite state machine as described in claim 1, characterized in that, The steps for collecting order acceptance success event data from the task publishing system include: Collect raw data of the order acceptance success event from the task publishing system; The raw data of the successful order acceptance event is preprocessed to obtain the preprocessed raw data; The preprocessed raw data is validated to obtain successful order acceptance event data.

Images