Multi-expert online co-sign method and multi-expert co-sign system based on local service

Abstract

This application relates to the field of electronic signature technology, specifically to a multi-expert online countersigning method and a multi-expert countersigning system based on local services. The multi-expert online countersigning method includes: obtaining the expert's identity information, a reference document, and a confirmed signature information block; parsing the confirmed signature information block, rendering the confirmed signature on the reference document, and generating corresponding display content for the reference document and the confirmed signature; obtaining the current expert's signature position and signature image data, and calculating the current expert's hash value on the reference document; in response to the current expert's confirmation of the signature, generating the current expert's signature information block and storing it in the corresponding countersigning task on the server; and in response to the completion of all signature information blocks, verifying the hash values ​​and expert identity information in all signature information blocks. This multi-expert online countersigning method can improve countersigning efficiency, ensure countersigning compliance, and support real-time countersigning across multiple terminals.

Description

Technical Field

[0001] This application relates to the field of electronic signature technology, specifically to a multi-expert online countersigning method and a multi-expert countersigning system based on local services. Background Technology

[0002] During the bidding and evaluation process, multiple experts need to electronically sign and confirm the same PDF document, such as the evaluation report, which is known as a countersigning operation. Experts often use different browsers and terminal devices, and the goal is to achieve parallel signing to shorten the evaluation cycle. At the same time, they can view the completed stamp positions of other experts in real time during the operation to avoid position conflicts and improve collaboration efficiency.

[0003] However, most current countersigning operations are carried out using the traditional serial full-package return solution. This solution requires experts to download the complete PDF document, rely on a local plugin to perform the signing, and then upload the entire package file. Not only is the upload and download process cumbersome, but to avoid signing conflicts, subsequent experts must wait for the previous expert to complete their operation before they can sign. The traditional serial full-package return solution significantly increases the time consumption for large files or multi-expert scenarios and has weak system fault tolerance, making it prone to interruption due to network fluctuations or plugin failures.

[0004] While invention patent application CN113704796A supports parallel downloading and signing by multiple expert clients, uploading and merging data by extracting differences, it still relies on browser plugins or OCX controls to directly write the signature into the PDF structure, potentially leading to inconsistencies in behavior across multiple browsers. Furthermore, previewing others' signatures requires the server to include preceding data in the download request, resulting in a fragmented preview experience. Additionally, the signature information block lacks a hash value that can be compared with the server's baseline document, failing to effectively anchor the document's integrity and posing a potential risk of tampering. Invention patent application CN112994900A employs a method of parallel uploading of the impression, position, and signature structure by the client, with incremental merging by the server; however, experts cannot visually confirm the confirmed signature layout before signing. Summary of the Invention

[0005] In view of this, this application provides a multi-expert online countersigning method and a multi-expert countersigning system based on local services, which have the advantages of improving the efficiency of multi-expert countersigning, enhancing the security of signed documents, and supporting real-time collaboration across multiple terminals.

[0006] To address the aforementioned technical problems, this application adopts the following technical solution: A method for multi-expert online countersigning is provided, comprising: obtaining the expert identity information of the current expert, a reference document, and a confirmed signature information block; the confirmed signature information block includes at least the signature position of the confirmed signature, the signature image data of the confirmed signature, and the hash value of the confirmed signature; parsing the confirmed signature information block; rendering the confirmed signature on the reference document according to the signature position and the signature image data of the confirmed signature; and generating display content corresponding to the reference document and the confirmed signature; obtaining the signature position of the current expert in the reference document, the... The system collects the signature image data of the current expert and calculates the hash value of the current expert on the benchmark document. In response to the current expert's confirmation of signature, it generates a signature information block for the current expert, including the expert's identity information, signature location, signature image data, and hash value, and stores it in the corresponding countersigning task on the server. In response to the completion of all signature information blocks, the server verifies the hash values ​​and expert identity information in all signature information blocks. The server is used to batch apply for digital certificates for all experts after all signature information blocks have passed verification and to merge all signature information blocks into the benchmark document to generate a countersigned document.

[0007] In one specific implementation, after obtaining the signature position and signature image data of the current expert in the benchmark document, the process includes: rendering the signature of the current expert on the benchmark document based on the signature position and signature image data of the current expert, and generating display content corresponding to the benchmark document, the confirmed signature, and the signature of the current expert.

[0008] In one specific implementation, the response before all signature information blocks are generated includes: obtaining the countersigning rules from the countersigning task on the server; and determining whether all signature information blocks have been generated based on the countersigning rules.

[0009] In one specific implementation, obtaining the expert's identity information, the reference document, and the confirmed signature information block includes: obtaining the confirmed signature information block from the confirmed list of the countersigning task, and obtaining the reference document from the countersigning task.

[0010] To address the aforementioned technical problems, this application adopts the following technical solution: A method for multi-expert online countersigning, comprising receiving and storing an original document as a reference document, the reference document being associated with the countersigning task; receiving a signature information block sent by a client, the signature information block containing expert identity information, signature position, signature image data, and hash value; in response to receiving all the signature information blocks, verifying the hash value and expert identity information in all the signature information blocks; in response to the verification passing, batch applying for digital certificates for all experts; and merging the signature image data of all the signature information blocks into the reference document to generate a countersigned document.

[0011] In one specific implementation, merging the signature image data of all the signature information blocks into the reference document includes: obtaining the signature position of all the signature information blocks; constructing a one-to-one corresponding placeholder rectangle in the reference document according to the signature position, wherein the signature position includes page number, anchor point coordinates, and signature image data size; determining whether there is a conflict between the placeholder rectangles; in response to at least two placeholder rectangles conflicting with each other, adjusting the position of at least one of the placeholder rectangles according to a preset rule, and generating at least one new signature position; sending the new signature position to the client of the corresponding expert; and in response to receiving a confirmation message sent by the client, merging the signature image data of all the signature information blocks one-to-one into the placeholder rectangle in the reference document.

[0012] In one specific implementation, determining whether there is a conflict between the placeholder rectangles includes calculating the overlapping area between any two placeholder rectangles; responding to at least two placeholder rectangles conflicting with each other includes responding to the fact that the ratio of the overlapping area of ​​at least two placeholder rectangles to the area of ​​the smallest placeholder rectangle is greater than or equal to a preset ratio.

[0013] In one specific implementation, the verification of the hash value and expert identity information in all the signature information blocks includes: obtaining the associated benchmark document from the countersigning task corresponding to the signature information block; calculating the benchmark hash value from the benchmark document; and determining whether the hash value in all the signature information blocks is consistent with the benchmark hash value.

[0014] In one specific implementation, the expert identity information includes the expert's name, identity number, and document image. The verification of the hash value and expert identity information in all the signature information blocks includes: obtaining the expert identity information from the signature information block; sending the document image to the OCR ID card recognition interface; receiving the OCR recognition result and confidence level sent by the OCR ID card recognition interface, wherein the OCR recognition result includes the document name and document number in the document image; determining whether the expert name from the same signature information block matches the document name, determining whether the identity number from the same signature information block matches the document number, and determining whether the confidence level is higher than a preset confidence level.

[0015] To solve the above-mentioned technical problems, one technical solution adopted in this application is: providing a multi-expert countersigning system based on local services, used to implement the multi-expert online countersigning method as described in any of the above specific embodiments. The multi-expert countersigning system based on local services includes a client and a server. The client includes a local storage module and a local service module connected to each other. The local service module is connected to the server. The local storage module is used to store the identity information of the current expert. The local service module is used to obtain the expert identity information of the current expert, the reference document, and the confirmed signature information block. The confirmed signature information block includes at least the signature position and the signature image data of the confirmed signature. The local service module is also used to parse the confirmed signature information block, render the confirmed signature on the reference document according to the signature position and the signature image data of the confirmed signature, and generate display content corresponding to the reference document and the confirmed signature. The local service module is also used to obtain the reference document. The local service module is used to: determine the signature position and image data of the current expert in the reference document; calculate the hash value of the current expert in the reference document; in response to the current expert's confirmation of signature, generate a signature information block of the current expert including the expert's identity information, signature position, image data, and hash value, and store the signature information block of the current expert in the corresponding countersigning task in the server; receive and store the original document as the reference document, which is associated with the countersigning task; receive the signature information block of the current expert sent by the local service module; in response to receiving signature information blocks from all experts, verify the hash value and expert identity information in all signature information blocks; in response to successful verification, apply for digital certificates for all experts in batches, merge the signature image data of all signature information blocks into the reference document, and generate a countersigning document.

[0016] The beneficial effects of this application include: real-time acquisition and rendering of confirmed signatures by the local service module for current experts' reference, greatly reducing the probability of expert signature conflicts and enabling efficient parallel signing by multiple experts. After all signature information blocks are collected, batch verification of hash values ​​and expert identity information followed by merging improves verification efficiency while alleviating problems such as high network traffic load, long waiting times, browser compatibility issues, and susceptibility to document tampering. It offers advantages such as improved signing efficiency, enhanced security of signed documents, ensured compliance of the signing process, and support for real-time collaboration across multiple terminals. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the implementation will be briefly introduced below. Obviously, the drawings described below are some implementations of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0018] Figure 1 This is a first flowchart illustrating an embodiment of the multi-expert online review method of this application;

[0019] Figure 2 This is a second flowchart illustrating an embodiment of the multi-expert online review method of this application;

[0020] Figure 3 This is a third flowchart illustrating an embodiment of the multi-expert online review method of this application;

[0021] Figure 4 This is a schematic flowchart of the fourth embodiment of the multi-expert online review method of this application;

[0022] Figure 5 This is the fifth flowchart illustrating an embodiment of the multi-expert online review method of this application;

[0023] Figure 6 This is a schematic diagram of the structure of the multi-expert countersigning system based on local services in this application.

[0024] Figure label:

[0025] 100. Multi-expert countersigning system based on local services; 110. Client; 111. Local storage module; 112. Local service module; 120. Server; 121. Countersigning task. Detailed Implementation

[0026] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of the invention. However, those skilled in the art will understand that the invention can be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods are omitted so as not to obscure the description of this application with unnecessary detail.

[0027] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0028] It should also be understood that the terminology used in this application specification is for the purpose of describing particular embodiments only and is not intended to limit the application. As used in this application specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise. The terms “first” and “second” are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as “first” or “second” may explicitly or implicitly include at least one of that feature. In the description of this application, “a plurality” means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0029] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0030] Many specific details are set forth in the following description in order to provide a full understanding of this application. However, this application may also be implemented in other ways different from those described herein. Those skilled in the art can make similar extensions without departing from the spirit of this application. Therefore, this application is not limited to the specific embodiments disclosed below.

[0031] During the bidding and evaluation process, multiple experts need to electronically sign and confirm the same PDF document, such as the evaluation report, which is known as a countersigning operation. Experts often use different browsers and terminal devices, and the goal is to achieve parallel signing to shorten the evaluation cycle. At the same time, they can view the completed stamp positions of other experts in real time during the operation to avoid position conflicts and improve collaboration efficiency.

[0032] However, most current countersigning operations are carried out using the traditional serial full-package return solution. This solution requires experts to download the complete PDF document, rely on a local plugin to perform the signing, and then upload the entire package file. Not only is the upload and download process cumbersome, but to avoid signing conflicts, subsequent experts must wait for the previous expert to complete their operation before they can sign. The traditional serial full-package return solution significantly increases the time consumption for large files or multi-expert scenarios and has weak system fault tolerance, making it prone to interruption due to network fluctuations or plugin failures.

[0033] While invention patent application CN113704796A supports parallel downloading and signing by multiple expert clients, uploading and merging data by extracting differences, it still relies on browser plugins or OCX controls to directly write the signature into the PDF structure, potentially leading to inconsistencies in behavior across multiple browsers. Furthermore, previewing others' signatures requires the server to include preceding data in the download request, resulting in a fragmented preview experience. Additionally, the signature information block lacks a hash value that can be compared with the server's baseline document, failing to effectively anchor the document's integrity and posing a potential risk of tampering. Invention patent application CN112994900A employs a method of parallel uploading of the impression, position, and signature structure by the client, with incremental merging by the server; however, experts cannot visually confirm the confirmed signature layout before signing.

[0034] In order to improve the above technical problems, the inventors of this application, after long-term research, have proposed at least the following embodiments.

[0035] Please see Figure 1 , Figure 1 This is a schematic flowchart of the first embodiment of the multi-expert online review method of this application. It should be noted that if substantially the same result is achieved, this embodiment does not necessarily require further explanation. Figure 1 The illustrated process sequence is limited. This application provides a multi-expert online review method, including:

[0036] S100: Obtain the expert's identity information, benchmark documents, and the confirmed signature information block of the current expert.

[0037] The confirmed signature information block may include at least the signature location, the signature image data, and the hash value of the confirmed signature.

[0038] The implementing entity in this specific implementation can be a client machine operated by an expert. Expert identity information refers to unique information used to identify the co-signing expert, such as the expert's name, employee number, ID number, ID photo, portrait photo, affiliated organization, etc. Expert identity information can identify and record the executor of the signing operation during the co-signing process. The current expert's identity information can be manually entered by the expert using the client's human-computer interaction interface, or uploaded from a configuration file stored locally on the client.

[0039] A benchmark document refers to a document awaiting signature by multiple experts, such as a bid evaluation report or contract document. As the common basis for all expert signatures, the benchmark document's content remains unchanged throughout the signing process, ensuring all experts read the same information. Benchmark documents can be loaded from the local file system by the client or downloaded from a specified storage location over a network.

[0040] A signature information block refers to a data unit obtained by structurally encapsulating the signature behavior of an expert. It usually includes the expert's identity information, the position of the signature on the base document, the image data of the signature, and the hash value of the confirmed signature calculated from the base document on which the expert's signature was based.

[0041] A confirmed signature block can be sent directly to the current expert client by other expert clients that have already completed the signing. Alternatively, it can be sent directly to a public, unstructured storage area by other expert clients that have already completed the signing, from which the current expert client can then retrieve it.

[0042] The signature position refers to the specific coordinate information of the signature in the base document, such as page number, line number within the page, X / Y coordinates within the page, length and width of the signature, etc.

[0043] Signature image data refers to the graphical representation of a signature, usually in image format. Signature image data is used for visual rendering on documents.

[0044] A hash value is a fixed-length numerical value calculated from the content of a reference document using a hash algorithm. Hash values ​​are unique and are used to verify the integrity and tamper-proof nature of the reference document's content.

[0045] In a specific embodiment of this application, step S100, "obtaining the expert identity information, benchmark document, and confirmed signature information block of the current expert," may specifically include: obtaining the confirmed signature information block of the countersigning task from the confirmed list of the countersigning task, and obtaining the benchmark document from the countersigning task.

[0046] In this context, a countersigning task can be a task workflow created and managed by the server for a specific multi-expert countersigning task. Each countersigning task is interconnected with corresponding baseline documents, participating experts, generated signature information blocks, and other information and data. A countersigning task can be understood as a logical entity containing all countersigning-related information. For example, a countersigning task might be a record in a database, containing data such as document ID, list of participating experts, countersigning status, list of completed signature transfers, and generated signature information blocks.

[0047] The server refers to the centralized computing entity responsible for coordinating, storing, and processing signing tasks in a multi-expert online signing system. It can receive signature information blocks from clients and perform subsequent verification, merging, and other operations.

[0048] The confirmed list is a data structure within a countersigning task. It stores references or the actual content of the signed information blocks submitted by experts who have completed the signing process. For example, the confirmed list can be a JSON array stored in a server-side database or a collection of key-value pairs in a distributed cache.

[0049] One way to retrieve confirmed signature blocks is through a client API (Application Programming Interface) call. The client sends a request to the server, which then queries persistent storage (such as a relational or non-relational database) based on the signing task ID and returns all confirmed signature blocks in the confirmed list. Another way is to utilize a message queue mechanism. When an expert completes a signing, the server publishes the new signature block to a specific message queue. Clients subscribe to this queue to receive real-time updates of confirmed signature blocks.

[0050] Clients can obtain the base document through document service download. This involves the client calling the document download interface provided by the server, passing in the countersigning task ID, and the server retrieving and transferring the base document from a file storage system such as a distributed file system or object storage service. Alternatively, the base document can be accessed via a preset URL (Uniform Resource Locator). The server generates a unique, accessible URL for the base document when the countersigning task is created, and the client can directly download the base document through this URL.

[0051] In the method provided in this specific embodiment, by retrieving the confirmed signature information block from the confirmed list of the countersigning task, it is ensured that the current expert can accurately obtain and synchronize the signature status of other experts before performing the signing operation, realizing real-time rendering and visualization of signature position and image data, thereby assisting the current expert in signing. Simultaneously, by retrieving the reference document from the countersigning task, it is ensured that the document reviewed by the current expert during countersigning is consistent with the reference document, avoiding signature misalignment or verification failure caused by document changes.

[0052] This specific implementation method ensures that the multi-expert online countersigning method of this application has a standardized data input interface by clearly defining the source path of the confirmed signature information block and the reference document. It overcomes the problem of unclear data source or inconsistent acquisition method during the countersigning process, and provides a reliable data foundation for subsequent hash value calculation, signature rendering and final batch verification. It enhances the automation level and standardization of the entire countersigning system, thereby improving the efficiency and accuracy of multi-expert online countersigning.

[0053] S200: Parse the confirmed signature information block, render the confirmed signature on the base document according to the signature position and signature image data, and generate the corresponding display content of the base document and the confirmed signature.

[0054] After receiving a confirmed signature information block, the client can parse its data structure to extract the signature location and image data. Then, based on the parsed signature location information, the client can overlay and render the corresponding signature image data onto the appropriate page of the base document, generating the corresponding display content.

[0055] The displayed content can be shown using the display module connected to the client. The benchmark document can be integrated with all confirmed signatures to form a document preview view showing all confirmed signatures, presented to the current expert for preview and as a signature reference.

[0056] S300: Obtain the signature position and signature image data of the current expert in the benchmark document, and calculate the hash value of the current expert in the benchmark document.

[0057] The signature image data of the current expert can be the signature image data input by the current expert through the human-machine interface of the client, or it can be the signature image data uploaded by the current expert from the local computer of the client, or it can be obtained in real time through a scanning device connected to the client. For example, if the human-machine interface is a handwriting screen, the current expert can use the handwriting screen to sign to form signature image data.

[0058] The current expert's signature position can be specified by the expert using the client's human-computer interface through clicking, dragging, or other operations on the displayed content of the benchmark document. The coordinates and dimensions of this area are recorded as the signature position. For example, if the human-computer interface is a mouse, the current expert can use the mouse to drag the signature image data to the specified area on the displayed content of the benchmark document, and the coordinates and dimensions of this area are recorded as the signature position.

[0059] The client performs a hash algorithm on the entire contents of the benchmark document used for the current expert's signature, generating a unique hash value for the current expert corresponding to that benchmark document.

[0060] In a specific embodiment of this application, after step S300 "obtaining the current expert's signature position and the current expert's signature image data in the benchmark document", it may further include: rendering the current expert's signature on the benchmark document according to the current expert's signature position and the current expert's signature image data, and generating the corresponding benchmark document, confirmed signature and current expert's signature display content.

[0061] After obtaining the selected signature location and image data of the current expert's signature, the signature can be rendered on the benchmark document. This rendering process aims to present the current expert's signature in a visual form at the designated location on the benchmark document, allowing the expert to intuitively see the actual effect and layout of the signature. Furthermore, since other confirmed signatures are also displayed in the benchmark document, the expert can compare their pending signature with those already confirmed.

[0062] For example, after receiving the signature location and signature image data selected by the current expert, the client's local service module can use document rendering engines such as PDF.js and Poppler (library) to overlay the signature image data onto the specified location of the base document, forming a temporary, unfixed visual layer. Alternatively, the client can call a graphics interface or the browser's built-in rendering capabilities such as Canvas and SVG (Scalable Vector Graphics) to draw the signature image data onto the display interface of the base document according to the signature location information, enabling real-time preview.

[0063] Based on this, the client integrates the original content of the benchmark document, the signatures confirmed by other experts, and the signatures to be confirmed by the current expert to form a complete countersigning view for the current expert to preview.

[0064] For example, the client-side local service module can overlay or merge the rendering results of the baseline document, the rendering results of the confirmed signature, and the temporary rendering results of the current expert signature to generate a unified image or interactive document view for the user to view.

[0065] For example, the client-side display interface can maintain a display context, which includes the underlying rendering of the base document, the intermediate rendering of the confirmed signatures, and the top layer rendering of the current expert's signature. When the current expert adjusts the signature position or selects a different signature, only the top layer rendering is updated, thereby generating and updating the complete display content in real time.

[0066] Furthermore, when the current expert's signature has not yet been confirmed, the current expert's signature can be rendered using the same Canvas drawing method, but distinguished by a different color or semi-transparent border than the confirmed signature, to indicate to the current expert that their signature has not yet been finalized.

[0067] The method provided in this specific embodiment can render the current expert's signature on the reference document after obtaining the current expert's signature position and signature image data. It then integrates the current expert's signature with the reference document and the display content of confirmed signatures to generate a display content that includes the reference document, the current expert's signature, and confirmed signatures. This allows the current expert to intuitively see the relative positional relationship between the signature they are about to add or have already added and the confirmed signature, as well as the overlay effect with the reference document content. This effectively solves the problem that experts have difficulty perceiving the layout of their signatures in real time during a signing scenario, and can provide an instant and comprehensive visual preview.

[0068] Furthermore, the step of "rendering the current expert's signature on the benchmark document" can be performed before the current expert confirms the signature. This allows the current expert to adjust the signature position and signature image data according to the displayed content before confirming the signature, thereby reducing the probability of signature overlap, obscuring key information, and poor signature effect. This greatly improves the accuracy of expert operation and the efficiency of the signing process, and ensures the standardization of the final signed document's layout and visual neatness.

[0069] S400: In response to the current expert's confirmation and signature, generate a signature information block for the current expert, including the expert's identity information, the location of the current expert's signature, the image data of the current expert's signature, and the hash value of the current expert, and store it in the corresponding countersigning task on the server.

[0070] Specifically, the current expert confirms the signature when they complete the selection of the signature location and image data, and input the confirmation instruction through the client. For example, the current expert can trigger the generation of the confirmation instruction by clicking the "Confirm Signature" button with the mouse connected to the client.

[0071] In response to the confirmation of signature, the client encapsulates the current expert's identity information, signature location, signature image data, and the calculated hash value of the current expert to form a structured signature information block of the current expert. The client then sends this signature information block to the server, which stores it in the storage area associated with the current countersigning task.

[0072] S500: In response to the completion of all signature information blocks, the server is triggered to verify the hash value and expert identity information in all signature information blocks.

[0073] The server is used to apply for digital certificates for all experts in batches after all signature information blocks have been verified, and to merge all signature information blocks into the base document to generate a countersigned document.

[0074] A digital certificate is an electronic credential issued by an authoritative certification authority to prove a user's identity and the validity of their signature.

[0075] A countersigned document is the final document formed after all expert signature blocks have been verified and merged into a base document. A countersigned document contains the signatures of all experts and has corresponding legal effect. After the countersigned document is generated, a digital certificate can be used to confirm the legal validity of the signatures.

[0076] In step S500, the client continuously monitors the signed information blocks received by the countersigning task. When the number of received signed information blocks is greater than or equal to the preset total number of participating experts, the client can determine that all signed information blocks have been generated.

[0077] Once all signature information blocks have been generated, the client can trigger the server to iterate through all received signature information blocks, extract the hash value from each block, and compare it with the hash value of the baseline document stored on the server to verify the document's integrity. Simultaneously, the client also triggers the server to extract and compare the expert identity information from each block to verify the legitimacy of the signing expert's identity.

[0078] After all the hash values ​​and expert identity information of the signed information blocks have been verified, the server can submit digital certificate applications for all participating experts to the digital certificate authority in batches, thus achieving one-time batch application for digital certificates.

[0079] Finally, the server can overlay the signature locations and image data recorded in all signature information blocks onto the corresponding positions of the base document to generate a complete countersigned document containing the signatures of all experts.

[0080] For example, after determining that all signature information blocks have been generated, the client can send a signature completion notification message to the server. This notification message contains a unique identifier for the countersigning task. The server can then initiate verification in response to receiving the signature completion notification message.

[0081] In the multi-expert online countersigning method provided in this specific implementation, by deconstructing the signing process into structured signing information blocks, consistent rendering and management of signed content are achieved across different terminal environments in a multi-expert online countersigning scenario. This effectively avoids signing position conflicts and improves signing efficiency. Simultaneously, a hash anchoring mechanism is introduced to ensure the integrity verification of the base document during the signing process, preventing tampering with the signed document. Furthermore, through centralized server-side verification and merging, compliant issuance of countersigned documents is achieved after all personnel have signed, significantly improving the efficiency and security of countersigning.

[0082] In one specific embodiment of this application, before step S500 "in response to all signature information blocks being generated", it may further include: obtaining the countersigning rules from the countersigning task on the server. Then, it is determined whether all signature information blocks have been generated based on the countersigning rules.

[0083] During the joint signing process, the client can obtain the joint signing rules from the server's joint signing task. This allows the client to flexibly determine whether the joint signing process is complete based on the specific business scenario and requirements of the current joint signing process. It can adapt to the differentiated requirements of joint signing processes for different types of documents, different projects, or different industries, thereby ensuring the compliance and flexibility of the joint signing process.

[0084] The countersigning rules can be structured data in JSON or XML format, defining the number of experts participating in the countersigning, the list of experts who must sign, the signing order, and the mandatory nature of certain signatures.

[0085] For example, the client's judgment process based on the countersigning rules may include, but is not limited to: checking whether the number of generated signature information blocks is greater than or equal to the minimum number of expert signatures defined in the countersigning rules; verifying whether the identity information of the signed experts covers the mandatory signature expert list specified in the countersigning rules; and verifying whether the generation order of the signature information blocks conforms to the signature process defined in the rules.

[0086] The co-signing rules can also include complex judgment rules such as "at least 3 experts must sign, and among them must be the chief expert and the deputy chief expert". In this case, the client can perform multi-dimensional matching based on the expert identity information in the collected signature information blocks. Only when all conditions are met will the client determine that "all signature information blocks have been generated" and trigger the subsequent verification and merging process.

[0087] In the method provided in this specific implementation, the client dynamically obtains the co-signing rules associated with the current co-signing task from the server. Based on the specific business logic of the co-signing task, it can accurately judge the generated signature information blocks to determine whether the condition that all signature information blocks have been generated has been met. This rule-based judgment mechanism ensures that subsequent verification and merging processes are triggered only when the preset business logic is fully met. This not only improves the automation and rigor of the entire co-signing process and avoids compliance issues caused by lax process control, but also makes the co-signing process more flexible in adapting to various complex business needs, thereby significantly improving co-signing efficiency and accuracy.

[0088] Further, see Figure 2 , Figure 2 This is a schematic flowchart of the second process of an embodiment of the multi-expert online review method of this application. It should be noted that if substantially the same result is achieved, this embodiment does not necessarily require further consideration. Figure 2 The illustrated process sequence is limited. This specific implementation provides a method for multi-expert online countersigning, including:

[0089] S101: Receive and store the original document as a reference document.

[0090] The multi-expert online countersigning method provided in this specific embodiment can be implemented by a server. First, the server receives and stores the original document as a reference document. This reference document is associated with a specific countersigning task and is centrally managed on the server, ensuring the consistency of document versions operated by all experts. This provides a unified basis for signatures for all participating experts and avoids signature conflicts caused by differences in document content.

[0091] S600: Receives a block of signature information sent by the client.

[0092] The signature information block contains expert identity information, signature location, signature image data, and hash value.

[0093] The server can receive signature information blocks from each client. Each signature information block contains expert identity information, signature location, signature image data, and hash value calculated from the base document. This achieves hash anchoring between the signature information block and the base document, enabling subsequent verification of whether the document has been tampered with during the signing process by checking the hash value.

[0094] S700: In response to receiving all signed information blocks, verify the hash value and expert identity information in all signed information blocks.

[0095] Based on this, once the server receives all the signed information blocks, it verifies the hash values ​​in each block. This involves comparing the hash value of each signed information block with the base hash value of the baseline document stored on the server to ensure that the document was not tampered with during the expert signing process. Simultaneously, the server also verifies the expert's identity information to ensure the legitimacy of the signing entity.

[0096] S800: In response to successful verification, the server is also used to apply for digital certificates for all experts in batches.

[0097] Upon successful verification, the server can apply for digital certificates for all experts in batches, avoiding the waste of resources that might result from applying for digital certificates in advance during the signing process and improving the efficiency of digital certificate application.

[0098] S900: Merge the signature image data of all signature information blocks into the base document to generate a countersigned document.

[0099] Finally, the server can merge the signature image data of all signature information blocks into the base document, corresponding to the signature positions, to generate the final countersigned document.

[0100] In the method provided in this specific implementation, the signature information blocks are collected on the server for centralized verification and batch application for digital certificates. This simplifies the expert countersigning process into a structured data transmission process between the client and the server, eliminating the need for complex PDF writing on the client side and avoiding compatibility issues with client browsers. This significantly reduces the reliance of the countersigning task on expert client plugins. Furthermore, the centralized verification and merging process of signature information blocks meets the requirements for compliant drafting in bidding evaluation, enabling centralized compliant drafting after all experts have signed, and significantly improving the efficiency and security of multi-expert countersigning.

[0101] In a specific embodiment of this application, see [reference]. Figure 3 , Figure 3 This is a schematic flowchart of the third embodiment of the multi-expert online review method of this application. It should be noted that if substantially the same result is achieved, this embodiment does not necessarily require further clarification. Figure 3 The illustrated process sequence is limited. Step S900, "merging the signature image data of all signature information blocks into the base document," may further include:

[0102] S910: Obtain the signature position of all signature information blocks, and construct a one-to-one placeholder rectangle in the base document based on the signature position.

[0103] The signature location includes the page number, anchor point coordinates, and signature image data size. The signature location is crucial information used to precisely indicate the specific area within the document where the signature is placed.

[0104] Page numbers clearly indicate the document page where the signature is located. They can be obtained through interactive selection by the user on the client's human-computer interface, or automatically identified by the client based on the baseline document structure. Anchor point coordinates define the starting point of the signature on the specified page number; for example, it could be the pixel coordinates of the top-left corner of the page, or logical coordinates relative to page content elements. The signature image data size specifies the width and height of the signature image data; it can be the inherent size of the signature image data file itself, or a size scaled according to the baseline document layout or expert requirements.

[0105] Specifically, a placeholder rectangle can be a rectangular geometric data structure built in memory based on the signature position, used to simulate the actual area occupied by each signature in the base document before merging signatures on the server side. Placeholder rectangles can be used only for conflict detection calculations and not directly rendered into the base document. Each placeholder rectangle is uniquely determined by its page number, anchor point coordinates (x, y), and signature image data size.

[0106] Using this detailed signature location information, the server can construct an abstract placeholder rectangle in memory for each signature, with a specific page number, position, and size, as the basis for subsequent signature layout management and merging signatures into the base document.

[0107] S920: Determine if there is a conflict between the placeholder rectangles.

[0108] When determining whether there are conflicts between placeholder rectangles, the server can check whether there is overlap between all constructed placeholder rectangles. For example, the server can iterate through all pairs of placeholder rectangles on the same page, calculate the area of ​​their overlapping region, and if the overlapping area is greater than zero, it is determined to be a conflict.

[0109] For example, the server can use spatial indexing techniques such as R-trees and quadtrees to efficiently retrieve and identify rectangular regions that may overlap, thereby reducing unnecessary computation and improving the efficiency of detecting conflicts between placeholder rectangles.

[0110] S930: In response to at least two placeholder rectangles conflicting with each other, adjust the position of at least one of the placeholder rectangles according to a preset rule and generate at least one new signature position.

[0111] When a conflict of placeholder rectangles is detected, the server can adjust the position of the conflicting rectangles according to preset rules, and generate a new signature position corresponding to the adjusted placeholder rectangle based on the adjustment. The new signature position corresponds one-to-one with the signature information block and the signing expert.

[0112] The default rule prioritizes different experts or signature types. The server can automatically shift lower-priority placeholder rectangles outwards or downwards, and wrap them to the next line if they exceed the page width, thus avoiding higher-priority placeholder rectangles. This priority is determined by the order in which signatures are confirmed, with earlier confirmed signatures having higher priority.

[0113] Without affecting the readability of the signature, the default rule can also be to appropriately scale low-priority placeholder rectangles to reduce the space they occupy. For example, the area can be scaled proportionally to 80% of its original size.

[0114] For example, when two signatures overlap, if the lower priority signature is located to the left of the higher priority signature, the placeholder rectangle of the lower priority signature can be moved further to the left until the placeholder rectangles of the two signatures no longer overlap.

[0115] Furthermore, the grid snapping function can be used in conjunction with the adjustment of the placeholder rectangle to maintain the neatness of the layout.

[0116] In a specific embodiment of this application, step S920, "determining whether there is a conflict between the placeholder rectangles," may specifically include: calculating the overlapping area between any two of the placeholder rectangles. Step S930, "in response to at least two placeholder rectangles conflicting with each other," may specifically include: in response to the fact that the ratio of the overlapping area of ​​at least two placeholder rectangles to the area of ​​the smallest placeholder rectangle is greater than or equal to a preset ratio.

[0117] Specifically, the calculation of the overlapping area between any two placeholder rectangles can be achieved in various ways. For example, a geometric algorithm can be used to determine the intersection region by comparing the coordinate ranges of the two placeholder rectangles and then calculating the area of ​​that intersection region.

[0118] For example, functions provided by the graphics processing library can be used to directly call the interface to calculate the overlapping area of ​​two placeholder rectangles, thereby accurately quantifying the degree of physical overlap between any two placeholder rectangles in the reference document space, providing an objective data basis for conflict judgment.

[0119] Furthermore, to more accurately determine whether a substantial conflict exists, this specific implementation introduces the concept of the ratio of the overlapping area to the area of ​​the smallest occupying rectangle. The server can calculate the ratio of the obtained overlapping area to the smaller of the two occupying rectangles. For example, if the two occupying rectangles are A and B, with areas Area(A) and Area(B) respectively, and the overlapping area is Area(Overlap), then the ratio is Area(Overlap) / min(Area(A),Area(B)).

[0120] The visual impact of a large placeholder rectangle slightly covering the edge of a small placeholder rectangle is drastically different from that of a small placeholder rectangle being almost completely covered by another large placeholder rectangle. This method of proportional calculation can effectively distinguish the overlapping effects between placeholder rectangles of different sizes, reducing the probability of misjudgment caused by differences in the size of the placeholder rectangles.

[0121] The server will compare the calculated ratio with a preset ratio. When the overlapping area is greater than or equal to the area of ​​the smallest placeholder rectangle, the server will determine that the two placeholder rectangles are in conflict.

[0122] This preset percentage is a configurable parameter whose value can be adjusted according to the needs of the actual application scenario. For example, it can be set to 0.1 (i.e., 10%), 0.05 (i.e., 5%), etc. This preset percentage can be stored in the server's system configuration file or directly associated with the co-signing task.

[0123] The method provided in this specific embodiment introduces a quantitative and intelligent placeholder rectangle conflict detection mechanism. By accurately calculating the overlapping area between any two placeholder rectangles and comparing it proportionally with the area of ​​the smallest placeholder rectangle, combined with a preset ratio, it can effectively distinguish between minor edge overlaps and severe occlusion conflicts. This intelligently identifies conflicts that truly affect visual effects and the integrity of signatures, avoiding over-adjustments due to minor deviations. Therefore, when merging signature image data, it maintains document neatness while ensuring that each expert's signature information is clearly presented. This refined management method effectively solves the problem of chaotic document layout caused by positional conflicts when multiple experts sign in parallel, significantly improving the clarity and compliance of the signed documents.

[0124] S940: Send the new signature location to the corresponding expert's client.

[0125] Since there is a one-to-one correspondence between the new signature position, the signature information block, and the expert, the new signature position needs to be sent to the client of the corresponding expert. The client then uses the new signature position, the signature information block originally stored in the client, and the expert's signature image to re-render the new display content. The expert can then learn about the adjustment of their signature from the new display content.

[0126] S950: In response to receiving at least one confirmation message from the client, merge the signature image data of all signature information blocks into the placeholder rectangle in the base document.

[0127] Once the expert confirms that their signature adjustment is correct based on the new display content, they can send a confirmation message to the server via the client. This confirmation message notifies the server that the signature position has been confirmed. Each confirmation message corresponds one-to-one with the adjusted signature position. When the server receives all confirmation messages, it means that all signature position modifications have been confirmed by the corresponding expert. At this point, the signature image data of all signature information blocks can be merged one-to-one into the placeholder rectangle in the base document.

[0128] For example, this step can be achieved by calling the API of a document processing library such as a PDF rendering engine. By adding the signature image data as a layer or content stream to a specified page number of the base document, and precisely scaling and positioning it according to the size and coordinates defined by the placeholder rectangle, each signature image data is accurately placed in a position that corresponds to it and does not conflict with other signature image data.

[0129] This specific implementation introduces a placeholder rectangle mechanism to transform signature image data into geometric objects within the document space, providing a unified mathematical model for conflict detection between signatures. After the server receives and verifies all expert signature information blocks, it can automatically identify and handle signature layout conflicts. Even if signature positions overlap, the final signed document will still maintain clear visibility of each signature without interference. Furthermore, the modified signature positions can be sent to the experts for reconfirmation, and the experts will be aware of the signature modifications. This ensures the compliance and professionalism of the signed document, improves the automation of the signed document generation process, significantly enhances signing efficiency and document quality, and effectively alleviates the document standardization and readability problems caused by overlapping or obscuring signature positions when multiple experts sign in parallel.

[0130] In a specific embodiment of this application, see [reference]. Figure 4 , Figure 4 This is a schematic flowchart of the fourth step in an embodiment of the multi-expert online review method of this application. It should be noted that if substantially the same result is achieved, this embodiment does not necessarily require further consideration. Figure 4 The illustrated process sequence is limited. Step S700, "verifying the hash values ​​and expert identity information in all signature information blocks," may also include:

[0131] S701: Obtain the associated base document from the countersigning task corresponding to the signature information block.

[0132] After receiving all the signed information blocks submitted by the experts, the server can perform a series of verification steps to ensure the rigor of the signing process and the integrity of the documents.

[0133] Step S701 ensures that the hash value used for verification comes from the original base document stored on the server by obtaining the base document associated with the countersigning task, thereby effectively determining whether the document used by the expert for signing has been tampered with.

[0134] For example, the server can find the corresponding countersigning task based on the location where the signature information block is stored, and then directly retrieve the original base document associated with the countersigning task.

[0135] S702: Calculate the baseline hash value from the baseline document.

[0136] By performing real-time hashing on the baseline document, a baseline hash value reflecting the original document can be obtained, thus providing an objective and unique baseline reference for subsequent hash value verification.

[0137] Preferably, the SHA-256 algorithm (Secure Hash Algorithm 256) can be used to hash the entire binary data of the base document to generate a fixed-length hash value. The SHA-256 algorithm has advantages such as high security and collision resistance, and is widely used for data integrity verification.

[0138] S703: Determine whether the hash values ​​in all signed information blocks are consistent with the base hash value.

[0139] By comparing the hash values ​​recorded in the signature information blocks submitted by each expert with the baseline hash value one by one, it can be effectively identified whether the document has been illegally altered or replaced during the signing process if the document is illegally tampered with or replaced.

[0140] For example, the server can iterate through all received signature information blocks. For each signature information block, it extracts the hash value contained therein and compares it with the previously calculated baseline hash value using precise string or binary data. If all comparison results are consistent, the verification passes.

[0141] For example, the server can also collect the hash values ​​of all signed information blocks into a set, and then determine whether all elements in the set are equal to the base hash value.

[0142] This specific implementation introduces a real-time hash comparison mechanism for benchmark documents. By obtaining authoritative benchmark documents from the server from the signing task and recalculating their hash values ​​as verification benchmarks, it can ensure that the document versions used by all experts when signing are completely consistent with the final merged document version on the server. This overcomes the problem that the documents used for signing may be tampered with or replaced, thereby avoiding a certain degree of disconnect between the signed documents and the actual benchmark document content. It significantly improves the compliance and traceability of the entire signing process, providing more reliable technical support for highly sensitive business scenarios such as bidding and tendering.

[0143] In a specific embodiment of this application, see [reference]. Figure 5 , Figure 5 This is the fifth flowchart illustrating an embodiment of the multi-expert online review method of this application. It should be noted that if substantially the same result is achieved, this embodiment does not necessarily replace it with the original method. Figure 5 The illustrated process sequence is limited. Step S700, "verifying the hash values ​​and expert identity information in all signature information blocks," may also include:

[0144] S711: Obtain expert identity information from the signature information block.

[0145] The expert's identity information includes their name, identification number, and identification document image. This information is crucial data used to uniquely identify and verify the expert's identity. The expert's name and identification number are their basic legal identifiers, while the identification document image serves as visual proof of their identity. Specifically, the identification document image can be the front and back of the expert's ID card.

[0146] When experts participate in the signing process, they can fill out and upload scanned copies or photos of their identification documents through the client's human-computer interaction interface. The client can then initially store this expert identification information. The human-computer interaction interface can include at least one of a keyboard, mouse, touchscreen, camera, or scanning device. For example, if the human-computer interaction interface includes a keyboard, experts can input their name and identification number into the client via the keyboard.

[0147] The client can also interface with authoritative identity authentication platforms, such as the unified identity authentication system of government agencies. After expert authorization, the client can directly obtain the expert's name, identity number, and corresponding identification document image from the authoritative identity authentication platform.

[0148] When the server receives a signature information block sent by the client, it can parse the data structure of the signature information block. For example, the signature information block can directly contain fields such as the expert's name, identification number, and identification document image. The server can obtain the expert's identity information by reading these fields.

[0149] For example, the signature information block may contain only a unique identifier pointing to the storage location of the expert's identity information. The server can use this identifier to obtain complete expert identity information, such as the expert's name, ID number, and ID image, from the expert identity database connected to the server.

[0150] S712: Sends the document image to the OCR ID card recognition interface.

[0151] Step S712 utilizes OCR (Optical Character Recognition) technology to automatically extract structured text information from the document image for subsequent identity verification. After obtaining the document image from the signature information block, the server can send it as input to the OCR ID card recognition interface.

[0152] The OCR ID card recognition interface can be an external third-party cloud service API. For example, it can call OCR recognition services provided by Tencent Cloud, Alibaba Cloud, etc. via HTTP / HTTPS protocol. Alternatively, the OCR ID card recognition interface can also be a self-developed OCR recognition module deployed on a local server or private cloud environment, which can receive and process ID card images through internal calls or message queue mechanisms.

[0153] S713: Receives the OCR recognition results and confidence level sent by the OCR ID card recognition interface.

[0154] The OCR recognition results include the name and ID number on the ID card image.

[0155] After completing image processing, the OCR ID card recognition interface can return the recognition results to the server. For example, the OCR ID card recognition interface can return a structured data packet such as a JSON object, which contains explicit fields such as "ID Name," "ID Number," and a confidence score. The confidence score can be a floating-point number or percentage between 0 and 1.

[0156] For example, the OCR ID card recognition interface can also return an XML document, in which the recognized ID card name, ID card number, and confidence level are defined by tags.

[0157] S714: Determine whether the expert's name from the same signature information block matches the name on the identification document, determine whether the identity number from the same signature information block matches the identification document number, and determine whether the confidence level is higher than the preset confidence level.

[0158] For example, the preset confidence level can be set to 90%, and the recognition result is considered valid only when the confidence level of OCR recognition is higher than 90%.

[0159] When characters in document images may be difficult to recognize, in order to improve robustness, in addition to exact matching, fuzzy matching algorithms can also be used to allow for a certain range of character differences, such as for rare characters or slight recognition errors.

[0160] This specific implementation introduces a multi-dimensional identity verification mechanism. It uses the OCR ID card recognition interface to identify and extract the name and number of the ID card in the ID card image and generate a confidence score. It compares the name of the expert declared in the signature information block with the name of the ID card recognized by OCR, compares the declared identity number with the ID card number recognized by OCR, and further determines whether the confidence score is higher than the preset confidence score, so as to ensure that the declared information and the authoritative ID card image information corroborate each other.

[0161] Meanwhile, the method provided in this specific implementation combines confidence level judgment, which can prevent problems such as tampering, impersonation, and forgery of document images to a certain extent, and provide a guarantee for the authenticity and legality of the identity of each expert participating in the signing. It provides a solid trust foundation for subsequent digital certificate applications and the generation of signing documents, and can meet the strict identity verification requirements of high-security scenarios such as electronic bidding.

[0162] This specific implementation method reduces the cost and subjective error of manual review through automated identification, which can significantly improve the reliability and security of expert identity verification during multi-expert online signing, and effectively ensure the compliance and security of the entire signing process.

[0163] This application also provides a local service-based multi-expert countersigning system for implementing the multi-expert online countersigning method as described in any of the above embodiments. (See also...) Figure 6 , Figure 6 This is a schematic block diagram of the multi-expert countersigning system based on local services in this application. The multi-expert countersigning system 100 based on local services may specifically include a client 110 and a server 120. The client 110 may include a local storage module 111 and a local service module 112 connected to each other, wherein the local service module 112 is connected to the server 120.

[0164] For example, the local service module and the local storage module can be connected through an in-process communication interface, and the local service module and the server can communicate and connect through the HTTPS protocol.

[0165] The local storage module 111 is used to store the current expert's identity information. The local service module 112 is used to obtain the current expert's identity information, the benchmark document, and the confirmed signature information block. The confirmed signature information block includes at least the confirmed signature location and the confirmed signature image data.

[0166] For example, the local storage module can be a browser-based IndexedDB or LocalStorage. The local service module can perform read and write operations on the local storage module through a standardized Web API.

[0167] The local service module 112 is also used to parse the confirmed signature information block, render the confirmed signature on the base document according to the signature position and image data of the confirmed signature, and generate the corresponding display content of the base document and the confirmed signature. The local service module 112 is also used to obtain the signature position and image data of the current expert in the base document, and calculate the hash value of the current expert in the base document. In response to the current expert's confirmation of signature, the local service module 112 is also used to generate the current expert's signature information block including the current expert's expert identity information, the current expert's signature position, the current expert's signature image data, and the current expert's hash value, and store the current expert's signature information block in the corresponding countersigning task 121 in the server 120.

[0168] For example, the local service module can be a JavaScript library compiled based on WebAssembly, capable of being loaded and run in a client environment via a browser. The local service module can perform signature rendering and hash value calculation operations in a separate thread using Service Worker or Web Worker to avoid blocking UI rendering on the main thread.

[0169] The local service module and the server can communicate via a RESTful API under the HTTPS protocol. Signature information blocks can be encapsulated in JSON format and submitted to the server via an HTTP POST request. For confirmed signature information blocks, the local service module can receive proactive pushes from the server through Long Polling or Server-Sent Events (SSE) mechanisms.

[0170] Server 120 receives and stores the original document as a base document, which is associated with the countersigning task 121. Server 120 also receives the signature information blocks of the current experts sent by the local service module 112. Upon receiving signature information blocks from all experts, server 120 verifies the hash values ​​and expert identity information in all signature information blocks. Upon successful verification, server 120 batch-applies for digital certificates for all experts, merges the signature image data of all signature information blocks into the base document, and generates the countersigned document.

[0171] This specific implementation standardizes and ensures compliance in the electronic countersigning process. The client 110, through the cooperation of the local storage module 111 and the local service module 112, ensures independent management of expert identity information and localized execution of signing operations, effectively avoiding compatibility issues caused by different browser environments. The local service module 112 obtains and parses the confirmed signature information blocks and renders them on the base document, allowing experts to intuitively perceive the signature positions of other experts when signing, thus enhancing the collaboration of the countersigning process.

[0172] By calculating the hash value of the benchmark document and encapsulating it into a signature information block, a strong association between the signature and the content of the benchmark document is established, ensuring the integrity and tamper-proof capability of the countersigning process. Server 120, as the core control node, receives and stores the benchmark document, achieving unified management of countersigning task 121. Server 120 performs unified verification, certificate application, and merging only after collecting all signature information blocks, ensuring the authenticity and validity of each signature data. This meets the compliance requirements of full attendance and centralized drafting in the bidding process, avoiding document format errors caused by plugin differences on client 110, and achieving efficient, consistent, and traceable electronic countersigning.

[0173] The following is a more detailed explanation through a more specific embodiment.

[0174] In an online bid evaluation process, multiple experts need to electronically sign and confirm a bid evaluation report. This report is stored as a benchmark document under the server-side bid evaluation task. Assume that experts A, B, and C need to bid on this benchmark document. This embodiment uses expert A's participation in the bid evaluation process as an example. In reality, the clients used by experts B and C are not substantially different from those used by expert A.

[0175] When expert A logs into the co-signing system, the local service module of the client used by expert A will obtain expert A's expert identity information. At the same time, the local service module will obtain the base document from the corresponding co-signing task on the server, and retrieve the confirmed signature information blocks from experts B and C from the confirmed list of the co-signing task.

[0176] The local service module parses the signature information blocks of experts B and C. Based on the signature positions and image data contained in these signature information blocks, the local service module can render the confirmed signatures of experts B and C on the base document and generate the corresponding base document and confirmed signature display content. Expert A can clearly see the completed signature positions of other experts before signing.

[0177] Expert A selects the location for their signature on the benchmark document, referencing the displayed content, and provides their signature image data. After obtaining Expert A's signature location and image data, the local service module renders Expert A's signature on the benchmark document's display content based on these elements, generating the corresponding benchmark document, confirmed signatures, and Expert A's signature display content, providing Expert A with immediate visual feedback.

[0178] The local service module can simultaneously calculate the hash value of the benchmark document currently viewed by expert A. This hash value serves as an anchor for the document content, proving in subsequent verification processes that the document content used by expert A for signing has not been tampered with.

[0179] Once expert A confirms the signature, the local service module generates a signature information block containing expert A's identity information, signature location, signature image data, and calculated hash value. This signature information block is then sent and stored in the corresponding countersigning task on the server. This method allows multiple experts to submit their respective signature information blocks in parallel, without waiting for the previous expert to complete the signing of the entire document and send it back, greatly reducing the countersigning time.

[0180] The client obtains the countersigning rules from the server's countersigning task and determines whether all signature information blocks have been generated based on the countersigning rules. When the client determines that the server has received the signature information blocks from experts A, B, and C, meaning that all experts have confirmed and submitted their signature information blocks, the server will be triggered to verify the hash values ​​and expert identity information in all signature information blocks.

[0181] The server retrieves the associated baseline document from the countersigning task and recalculates the baseline hash value for that document. Then, the server checks if the hash values ​​in all signature information blocks match the baseline hash value to verify the integrity of the document content. Simultaneously, the server retrieves the expert's name, ID number, and ID image from the signature information blocks, sends the ID image to the OCR ID card recognition interface, receives the OCR recognition result and confidence level, and determines whether the expert's name matches the name on the ID card, whether the ID number matches the ID card number, and whether the confidence level is higher than a preset confidence level.

[0182] In response to the successful verification of all signature information blocks, the server batch-applies for digital certificates for Expert A, Expert B, and Expert C. Subsequently, the server retrieves the signature positions of all signature information blocks, including page numbers, anchor point coordinates, and signature image data dimensions, and constructs corresponding placeholder rectangles on the base document based on these signature positions.

[0183] The server calculates the overlapping area between any two placeholder rectangles to determine if a conflict exists. A conflict occurs if the overlapping area of ​​at least two placeholder rectangles is greater than or equal to a preset percentage of the area of ​​the smallest placeholder rectangle. In response to the conflict, the server moves at least two placeholder rectangles away from each other until the overlapping area of ​​at least two placeholder rectangles is less than the preset percentage of the area of ​​the smallest placeholder rectangle, thus mitigating the problem of signatures obscuring each other.

[0184] The server merges the signature image data of all signature information blocks one by one into the placeholder rectangle in the base document, generating a clear and standardized countersigned document. This avoids the inconsistency in behavior that may occur when the client actually writes the signature structure into the PDF in a multi-browser environment, thus ensuring the quality of the final countersigned document.

[0185] In this application, the terms "embodiment" and "implementation" mean that a specific feature or characteristic described in connection with an embodiment can be included in at least one embodiment of this application. The appearance of these phrases in various places in the specification does not necessarily refer to the same embodiment, nor are they independent or alternative embodiments mutually exclusive with other embodiments. Those skilled in the art will understand, explicitly and implicitly, that the embodiments described in this application can be combined with other embodiments. Furthermore, it should be understood that the features, elements, or characteristics described in the various embodiments of this application can be arbitrarily combined to form another embodiment that does not depart from the spirit and scope of the technical solution of this application, provided there is no contradiction between them.

[0186] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application and are not intended to limit it. Although this application has been described in detail with reference to the above preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions to the technical solutions of this application should not depart from the spirit and scope of the technical solutions of this application.

Claims

1. A method for multi-expert online countersigning, characterized in that, include: Obtain the expert's identity information, benchmark documents, and a confirmed signature information block. The confirmed signature information block includes at least the signature position, signature image data, and hash value of the confirmed signature. The confirmed signature information block is parsed, and the confirmed signature is rendered on the base document according to the signature position and signature image data of the confirmed signature, and the corresponding display content of the base document and the confirmed signature is generated. Obtain the signature position and signature image data of the current expert in the benchmark document, and calculate the hash value of the current expert in the benchmark document; In response to the current expert's confirmation and signature, a signature information block of the current expert is generated, including the expert's identity information, the signature position, the signature image data, and the hash value of the current expert, and stored in the corresponding countersigning task on the server. In response to the completion of the generation of all signature information blocks, the server is triggered to verify the hash value and expert identity information in all the signature information blocks. The server is used to apply for digital certificates for all experts in batches after all the signature information blocks have been verified and to merge all the signature information blocks into the base document to generate a countersigned document.

2. The multi-expert online countersigning method according to claim 1, characterized in that, After obtaining the signature position of the current expert and the signature image data of the current expert in the benchmark document, the process includes: Based on the current expert's signature position and signature image data, render the current expert's signature on the benchmark document to generate display content corresponding to the benchmark document, the confirmed signature, and the current expert's signature.

3. The multi-expert online countersigning method according to claim 1, characterized in that, The response, which occurs before all signature information blocks have been generated, includes: Obtain the joint signature rules from the joint signature task on the server. Determine whether all signature information blocks have been generated based on the aforementioned countersigning rules.

4. The multi-expert online countersigning method according to claim 1, characterized in that, The process of obtaining the current expert's identity information, benchmark documents, and the confirmed signature information block includes: Obtain the confirmed signature information block from the confirmed list of the countersigning task, and obtain the base document from the countersigning task.

5. A method for multi-expert online countersigning, characterized in that, include: Receive and store the original document as a reference document, which is associated with the countersigning task; Receive a signature information block sent by the client, wherein the signature information block includes expert identity information, signature location, signature image data and hash value; Upon receiving all the signed information blocks, the hash values ​​and expert identity information in all the signed information blocks are verified. In response to the successful verification, apply for digital certificates for all experts in batches; The signature image data of all the signature information blocks are merged into the base document to generate a countersigned document.

6. The multi-expert online countersigning method according to claim 5, characterized in that, The step of merging the signature image data of all the signature information blocks into the base document includes: Obtain the signature position of all the signature information blocks, and construct a one-to-one placeholder rectangle in the base document according to the signature position. The signature position includes page number, anchor point coordinates, and signature image data size. Determine whether there is a conflict between the placeholder rectangles; In response to at least two of the placeholder rectangles conflicting with each other, the position of at least one of the placeholder rectangles is adjusted according to a preset rule, and at least one new signature position is generated; The new signature location is sent to the client of the corresponding expert; In response to receiving at least one confirmation message from the client, the signature image data of all the signature information blocks are merged one-to-one into the placeholder rectangle in the base document, and the confirmation message corresponds one-to-one with the new signature position.

7. The multi-expert online countersigning method according to claim 6, characterized in that, Determining whether there is a conflict between the placeholder rectangles includes calculating the overlapping area between any two placeholder rectangles; The response to at least two of the placeholder rectangles conflicting with each other includes: the response to the overlapping area of ​​at least two of the placeholder rectangles being a proportion of the area of ​​the smallest of the placeholder rectangles being greater than or equal to a preset proportion.

8. The multi-expert online countersigning method according to claim 5, characterized in that, The verification of the hash values ​​and expert identity information in all the signature information blocks includes: Obtain the associated benchmark document from the countersigning task corresponding to the signature information block; The benchmark hash value is calculated from the benchmark document; Determine whether the hash value in all the signed information blocks is consistent with the base hash value.

9. The multi-expert online countersigning method according to claim 5, characterized in that, The expert identity information includes the expert's name, ID number, and ID image. The verification of the hash value and expert identity information in all the signature information blocks includes: The expert's identity information is obtained from the signature information block; The document image is sent to the OCR ID card recognition interface; Receive the OCR recognition result and confidence level sent by the OCR ID card recognition interface, wherein the OCR recognition result includes the ID card name and ID card number in the ID card image; Determine whether the expert's name from the same signature information block matches the name on the certificate, determine whether the identity number from the same signature information block matches the certificate number, and determine whether the confidence level is higher than a preset confidence level.

10. A multi-expert countersigning system based on local services, characterized in that, For implementing the multi-expert online countersigning method as described in any one of claims 1 to 9, the multi-expert countersigning system (100) based on local services includes a client (110) and a server (120), the client (110) includes a local storage module (111) and a local service module (112) connected to each other, and the local service module (112) is connected to the server (120). The local storage module (111) is used to store the current expert's identity information; The local service module (112) is used to obtain the expert identity information, the benchmark document, and the confirmed signature information block. The confirmed signature information block includes at least the signature position and the signature image data of the confirmed signature. The local service module (112) is also used to parse the confirmed signature information block, render the confirmed signature on the benchmark document according to the signature position and the signature image data of the confirmed signature, and generate display content corresponding to the benchmark document and the confirmed signature. The local service module (112) is also used to obtain the signature position of the current expert and the signature image data of the current expert in the benchmark document, and calculate the hash value of the current expert in the benchmark document; in response to the current expert confirming the signature, the local service module (112) is also used to generate the signature information block of the current expert including the expert identity information of the current expert, the signature position of the current expert, the signature image data of the current expert and the hash value of the current expert, and store the signature information block of the current expert in the corresponding countersigning task in the server (120); The server (120) is used to receive and store the original document as the base document, and the base document is associated with the countersigning task (121); The server (120) is used to receive the signature information block of the current expert sent by the local service module (112); in response to receiving the signature information blocks of all experts, the server (120) is also used to verify the hash value and expert identity information in all the signature information blocks; in response to the verification passing, the server (120) is also used to apply for digital certificates for all experts in batches, merge the signature image data of all the signature information blocks into the base document, and generate a countersigned document.

Images