Multi-thread local signing method, system, device and medium based on wasm

Abstract

The application discloses a multi-file local signing method based on WASM, which comprises the following steps: starting a thread for each to-be-signed file, checking all signing positions of the to-be-signed file, adding corresponding signing position pictures to form a to-be-processed task list, triggering the execution of a signing task according to the to-be-processed task list, and returning an interaction layer according to the task and the signing position information obtained by a backend server; the interaction layer determines a signing picture according to the signing position information, obtains a corresponding file according to the to-be-processed task list, calculates a file hash, and sequentially transmits the file hash and corresponding signing position data into a WASM service layer; the WASM service layer creates a file signature field, a backend server returns signature data of the signing position, calculates a signature value according to the signature data of the signing position, transmits the signature value to a WASM synthesis module, writes the signature value into a corresponding file signing position, and completes signature synthesis.

Description

Technical Field

[0001] This application relates to the fields of electronic information processing technology and information security technology, specifically a method for local signing of multiple documents based on WASM technology. Background Technology

[0002] Online electronic signing services for electronic documents are increasingly being used in e-government, e-finance, and electronic archives due to the growing demand for e-commerce applications. This involves complex signing requirements such as document security, large file sizes, multiple copies, and multiple signing locations.

[0003] Because JavaScript has many limitations in file operations within browsers, it cannot meet the requirement of directly completing the signing of SDK files on the front end. The conventional solution to this problem is to access a service provided on the server and let the server perform the file signing function. However, this is problematic due to network communication issues and the potential information security risks associated with transmitting the content of the file to be signed over the network.

[0004] Publication No.: CN110943844A, entitled "A Secure Signing Method and System for Electronic Documents Based on Local Web Client Services," discloses a secure signing method and system for electronic documents based on local web client services. This method relates to the field of electronic document signature services, specifically addressing the elimination of the need for a U-key. It utilizes a private key based on the Public Key Infrastructure (PKI) standard and deploys specific web script commands on the server side. This allows a web browser to obtain a secure electronic document signing module when accessing specific content, replacing traditional signing methods that require a U-key or mobile terminal. Users can securely sign electronic documents using only a web browser.

[0005] Publication number CN113806815A, titled "A Document Signing Method and System," describes a method where the client transmits the received target file identifier and signer's account information to a cloud server. The cloud server retrieves authentication information based on the signer's account information and generates a signing instruction based on the target file identifier and authentication information, transmitting the instruction to the signing server. The signing server parses the signing instruction to obtain the target file identifier and signing information. Based on the target file identifier, the signing server retrieves the corresponding target transposed storage file from multiple transposed storage files stored in the storage service. The signing server composites a seal image onto the corresponding seal position in the target transposed storage file to obtain an initial signed document. The signing server calculates the signature value based on the initial signed document and certificate information and adds the calculated signature value to the initial signed document to obtain the target signed document.

[0006] All of the aforementioned document signing tasks occur on the server side, placing high demands on the server's capacity under concurrent scenarios. Furthermore, they cannot handle situations where clients might not want to transmit private files to the network environment. For scenarios involving large files or multiple locations requiring signing, signing via a signing server over the network can lead to delays due to network latency and limitations in large file transmission. Additionally, signing on the server side and transmitting files over the network compromises the security of the signed documents. Summary of the Invention

[0007] The problems addressed in this application are: excessively long network communication times due to file uploads and other related operations when signing large documents; potential information security issues during network transmission of signed documents; closed networks that prohibit file transmission; and insufficient server resources to support large-volume and high-concurrency signing of documents. This application proposes a local multi-file signing method based on WASM. The method involves displaying the documents to be signed on the front end, verifying the legality of the signed documents, creating a local multi-threaded channel to decompose and merge the files, and generating a relevant evidence report which is then uploaded to the server to complete the signing task.

[0008] According to one aspect of this application, a multi-file local signing method based on WASM is proposed, comprising: a local signing terminal initiating a signing task to establish a list of files to be signed, editing the signing bits, starting a thread for each file to be signed, adding the corresponding signing bit images to all signing bits under the file to be signed to form a list of tasks to be processed, triggering the execution of signing tasks according to the order of the list of tasks to be processed, and simultaneously, the interaction layer determining the signing image based on the signing bit information, obtaining the corresponding file according to the list of tasks to be processed, calculating the file hash, and sequentially passing the file hash and the corresponding signing bit data to the WASM service layer, the WASM service layer creating a file signature field and setting the signing image as the appearance of this signature; the backend server obtaining the signing bit signature data and returning it to the interaction layer, the interaction layer calculating the signature value based on the signing bit signature data, the WASM synthesis module writing the signature value into the corresponding file signing bit, synthesizing the signing bits, and completing the file signing.

[0009] Further optimization involves each thread processing a document with several signature bits to be signed. Each thread independently calls the WASM module to perform the signing task. Multiple documents to be signed are processed in parallel by multiple threads. When merging each signature bit, the content of the document is updated and the merging information is written. This process continues until all signature bits are merged, completing the signature merging of all documents in the thread list. The thread then ends and the merging information is uploaded to the backend server.

[0010] Further optimization reveals that the signature data format is a combination of filename and multiple signature data points, forming a dataset with multiple signature points. Each data entry consists of a filename and multiple signature data points. The signature data format for multiple files is: [SignData, SignData... Multiple files with signature points]. Here, SignData is the complete signature data format for a single file: SignData = {file, signInfo: [SignOverlay, SealOverlay, ... multiple signature points or seal points]}. The signature data format is SignOverlay = {data, rectangle, 2, page}, and the seal data format is SealOverlay = {data, rectangle, 1, page}. Here, rectangle represents the position and size information of the signature point, file represents a PDF file, data represents the signature value, signInfo represents the signature information, and page represents the signature page number.

[0011] Further optimization involves transmitting all signature bit data for a single file to the WASM service layer when processing the signing task. The WASM service layer then creates a file signature field based on the file and the corresponding signed signature bit data, setting each signature bit as the appearance of the current signature. This allows the signed signature bits generated by the front-end layer to be pasted onto the file and updated to a signed file, thus completing the signing of a single file.

[0012] Further optimization involves the Wasm compositing module in the WASM service layer processing multiple files to be composited. During multi-threaded execution, it checks all signature bits in the file to be composited, uploads the data for each signature bit to the backend service, and saves the image for each signature bit. The signature bit information and images returned by the backend service are added to the task queue to be processed. During the execution of each signing task, the signature bit data in that task is uploaded to the backend service, and the returned signature bit information, along with the signature bit images, is saved to the processing task to be composited, resulting in a task queue to be processed. Based on the number of signature bits in the task queue, the queue is set into multiple corresponding tasks, and these tasks are executed concurrently. After all signing tasks in the task queue are processed, all data is retrieved from the processing task to be composited, and the file's hash value and corresponding data are passed to the Wasm compositing module line by line.

[0013] According to another aspect of this application, a multi-document local signing system based on WASM is proposed, comprising: a local signing client, a front-end and WASM interaction layer, a WASM service layer, and a back-end server. The local signing client initiates a signing task, establishes a list of documents to be signed, edits the signing bits, and starts a thread for each document to be signed. It adds the corresponding signing bit image to all signing bits of the document to be signed to form a list of tasks to be processed. The signing task is executed according to the order of the task list. At the same time, the interaction layer determines the signing image based on the signing bit information, obtains the corresponding file according to the task list, calculates the file hash, and sequentially passes the file hash and the corresponding signing bit data to the WASM service layer. The WASM service layer creates a file signature field and sets the signing image as the appearance of this signature. The back-end server obtains the signing bit signature data and returns it to the interaction layer. The interaction layer calculates the signature value based on the signing bit signature data. The WASM synthesis module writes the signature value into the corresponding file signing bit, synthesizes the signing bit, and completes the document signing.

[0014] According to another aspect of this application, an electronic device is proposed, comprising: a processor; and a memory storing a program, wherein the program includes instructions that, when executed by the processor, cause the processor to perform the WASM-based multi-document local signing method described above.

[0015] According to another aspect of this application, a non-transitory computer-readable storage medium storing computer instructions, wherein the computer instructions are used to cause the computer to perform the WASM-based multi-document local signing method described above.

[0016] This application utilizes WASM technology, where the signing process occurs locally. User signing relies primarily on terminal device performance, minimizing server load. Furthermore, the file does not need to be transmitted to the server; signing is completed locally, and the signed file is returned to the user, significantly improving signing efficiency and security, especially in scenarios with high security requirements. Using Wasm technology for interaction with the signing end replaces backend service functions, eliminating the need for network calls and completing file signing directly locally with virtually no additional network communication overhead. Since file signing is not transmitted over the network, the security of the file content is guaranteed. Compared to traditional server-side aggregation of all signing requests, this effectively alleviates server pressure for signing large files, freeing up server resources and reducing server costs. Local synthesis effectively ensures the confidentiality of related documents, enhancing security. It solves the problem of isolated network file signing, and local synthesis eliminates the need to transmit files to the server, greatly improving transmission speed and providing a better user experience. A local multi-threaded channel is created to decompose and merge files, verify the legality of signed documents, and generate relevant evidence reports for easy verification in case of disputes. Attached Figure Description

[0017] like Figure 1 A schematic diagram of a Wasm-based local signing system in an exemplary embodiment of this application; like Figure 2 The diagram shown is a schematic representation of a multi-threaded signing process in an exemplary embodiment of this application. like Figure 3 The diagram shown is a structural block diagram of an exemplary electronic device that can be used to implement embodiments of this application. Detailed Implementation

[0018] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. While some embodiments of this application are shown in the drawings, it should be understood that this application can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this application. It should be understood that the drawings and embodiments of this application are for illustrative purposes only and are not intended to limit the scope of protection of this application.

[0019] It should be understood that the steps described in the method embodiments of this application may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this application is not limited in this respect.

[0020] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the following description. It should be noted that the concepts of "first", "second", etc., mentioned in this application are used only to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0021] It should be noted that the terms "a" and "a plurality of" used in this application are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0022] The names of the messages or information exchanged between multiple devices in the embodiments of this application are for illustrative purposes only and are not intended to limit the scope of these messages or information.

[0023] Because JavaScript has many limitations in file operations within browsers, it cannot meet the requirement of directly signing SDK files on the front end. The conventional solution to this problem is to access a service provided on the server side to perform the file signing function. However, considering network communication issues and potential information security problems arising from transmitting the content of the file to be signed over the network, this embodiment uses Wasm to complete the backend service function, eliminating the need to access the file to be signed over the network and completing the file signing function directly locally.

[0024] Wasm, short for WebAssembly, is a technology that translates code written in a programming language into machine code that a browser can understand. It allows code in other languages ​​(such as C++) to run in a browser and is designed as a compilation target for other languages. WASM uses binary encoding, resulting in superior performance during program execution. Compared to text formats, binary-encoded text occupies less storage space. It also supports multiple languages, allowing smart contracts to be written in C / C++ / Rust / Go and compiled into WASM bytecode.

[0025] like Figure 1 The diagram shown is a schematic diagram of a local signing system based on Wasm in an exemplary embodiment of this application, including: a local signing terminal, a front-end and Wasm interaction layer, a Wasm synthesis processing layer, and a back-end service layer.

[0026] The local signing interface, acting as the front-end, handles the display and visual operation of adding signed signatures to documents, serving as the source of content production. It is essentially the system's input, allowing users to submit and sign documents, and is the most crucial component of the entire system.

[0027] The local signing client uploads files and initiates signing, starts the SDK to render files, edits the signing field, formats the file list and signing field data, and sends the formatted file list and signing field data to the front-end and WASM interaction layer.

[0028] The front-end interacts with the WASM layer, iterating through and inspecting all files to be signed. For each file, a separate thread is started, processing each file and all signature bits within it. All signature bits are processed in parallel, significantly improving response efficiency and reducing processing time. After starting any thread, the interaction layer checks all signature bits in the file to be signed. During this process, each signature bit's data is uploaded to the backend server for processing, and its image is added to form a list of pending tasks. Once all signature bits are processed, the pending task list is triggered, and within each task, the signature bit data for that task is uploaded to the backend server.

[0029] The backend server obtains the base64 information of the signature bit based on the uploaded task and returns it to the interaction layer.

[0030] The interaction layer determines the signed image based on the base64 information of the signature bit and saves it to the storage unit to be synthesized. Synthesis is performed according to the task list order. All data is extracted from the storage unit to be synthesized and processed. Based on the data in the storage unit to be synthesized, the corresponding file is obtained, the file hash is calculated, and the file hash and corresponding data are sequentially passed to the WASM service layer according to the task list.

[0031] After receiving the file hash and the signature bit data to be synthesized, the WASM synthesis module in the WASM service layer creates a file signature field, sets the signature bit image as the appearance of this signature, and returns the document information to the interaction layer when synthesizing. The interaction layer receives the document information and uploads the document information, signing data, and the file's hash value to the backend server. The backend server obtains the base64 signature data of the signature bit and returns it to the WASM interaction layer. The interaction layer calculates the signature value based on the base64 signature data of the signature bit using the cryptographic hash algorithm SM3, and sends the signature value to the WASM synthesis module. The WASM synthesis module writes the signature value into the corresponding file signature bit, completing the signature synthesis.

[0032] Each time a signature bit is synthesized, the file content is updated, and synthesis information is written, until all signature bits are synthesized, at which point the thread terminates. After completing the signature synthesis for all files in the thread list, the synthesis information is uploaded to the backend server, which saves the synthesis information as signing evidence via the signing evidence interface. The interaction layer returns a list of signed files to the local signing client.

[0033] The specific technical solution of this embodiment is as follows: The front end receives data to be signed. This data can come from personal computers, laptops, mobile phones, and other terminals, and the data format may include: For example, use the SignOverlay variable name to replace the signature data format. SignOverlay = {data, rectangle, type, page} Wherein, data: the signature information to be signed, rectangle: {width: width of the signature area, height: height of the signature area, x: horizontal position relative to the PDF coordinate system, y: vertical position relative to the PDF coordinate system}, type: 2, page: the signature page number.

[0034] Use the SealOverlay variable name instead of the format for the stamp position. SealOverlay = { data: information about the seal to be signed, rectangle, type, page} Wherein, data: the seal information to be signed, rectangle: {width: width of the signature area, height: height of the signature area, x: horizontal position relative to the PDF coordinate system, y: vertical position relative to the PDF coordinate system,}, type: 1, page: the page number of the document to be signed.

[0035] Here, 'type' indicates the type of signature field; 'type' = 1 indicates a seal, and 'type' = 2 indicates a signature. `page` specifies the page number to be added to the PDF file. For example, if it's to be added to page 3 of the file, then `page` is set to page 3. `Data` contains the data that needs to be signed. `rectangle` is the position and size information of the signature area, determining the size and location of the signature on the PDF page. The PDF page coordinate system follows the standard, with the lower left corner as the origin.

[0036] The complete signature data format for a single document is represented by the variable name SignData. SignData = {file,signInfo: [SignOverlay, SealOverlay, ... multiple signed signature or seal positions]}, where file: PDF file, which must be an instance of the browser's File object, and this object must conform to Web standards.

[0037] This application enables the signing of multiple files and multiple signing positions. The data format is a data format with multiple signing positions formed by aggregating the file name and multiple signing position data. The content of each data item consists of a file and multiple signing position data, which are aggregated together to form a data format of multiple files with multiple signing positions.

[0038] The complete signing data format for multiple documents is: [SignData, SignData... multiple documents with multiple signed signature bits].

[0039] Figure 2 This is a schematic diagram of a multi-threaded signing process, which includes receiving data of documents to be signed, iterating through the data of documents to be signed, executing the process of creating a thread for each document to be signed, monitoring the signing progress, closing the corresponding thread after the signing task of a single document is completed, and submitting the data to the server to complete data storage and on-chain after all thread signing tasks are completed, and returning the signed document.

[0040] The system processes a list of files, creating a new thread for each file to complete the signing task for that single file.

[0041] The process iterates through the acquired data to be signed, checks all documents, and executes a thread creation process for each document. Each thread corresponds to a document with several signature positions. Each thread independently calls the WASM module to execute the signing task. Multiple documents to be signed are processed in parallel using multiple threads. A new thread is created for each document, and the signing progress is monitored to achieve parallel processing of multiple documents, thereby shortening the completion time. After the signing task of a single document is completed, the corresponding thread is closed until the signing tasks of all documents are completed. For example, if there are 10 documents to be signed, 10 threads need to be created to process the signing tasks concurrently. Only after all 10 signing tasks are completed will the process proceed to the next stage.

[0042] The WASM module provides the ability to perform signing tasks in a web environment. It takes the document to be signed and the signature or seal information to be signed as input, and returns the signed document. It can be implemented in various languages, such as C++, Go, and Rust.

[0043] When the Wasm compositing module processes multiple files to be composited, it executes a multi-threaded process to check all signature bits in each file and uploads the data for each signature bit to the backend service, while also saving the image for each signature bit. It then retrieves the signature bit information returned by the backend service and adds it, along with the signature bit images, to the task queue.

[0044] During the execution of each signing task, the signature bit data for that task is uploaded to the backend service. After the upload is complete, the signature bit information is returned and saved along with the signature bit image to the processing task to be synthesized. A queue of processing tasks to be uploaded is created and uploaded to the backend server to obtain the queue of tasks to be processed.

[0045] Based on the number of signature bits obtained from the backend service in the pending task queue, the queue is configured into multiple corresponding tasks. When signing is triggered, multiple signing tasks in the pending queue are executed concurrently. After all tasks are completed, the data generated by them is retrieved. After processing all pending task queues, all data is retrieved from the processing tasks to be synthesized. All data is traversed, and the file hash value and corresponding data are passed to the wasm synthesis module one by one.

[0046] Return to the signed document to complete the local signing process.

[0047] Once all threads have completed their signing tasks, the data is submitted to the server to complete data storage and on-chain verification.

[0048] For future traceability, the relevant data of the signed documents also need to be stored and uploaded to the blockchain. Only the data related to the documents will be uploaded, not the document content.

[0049] During the processing of a single file signing task, all signature bit data for that file is transmitted to the Wasm service layer. The Wasm service layer creates a file signature field based on the file and its corresponding signed signature bit data, setting each signature bit to the appearance of this signature. This ensures that the previously generated signed signature bits from the front-end layer are appended to the file, updating it to a signed file and completing the single file signing task. It then returns the signed file and the combined signature bit information, and saves it. The processing flow for each signing task is the same. The Wasm service layer's work ends once all signing tasks have been processed.

[0050] After processing all signing tasks, the previously saved signed files and the synthesized signature information are submitted to the server through the front-end layer. The server determines whether the data originates from the Wasm service layer based on the hash value generated from the file and the synthesized signature information. If so, the signing evidence is saved; otherwise, the signing evidence is rejected.

[0051] The wasm synthesis module triggers a synthesis task, returns the signed document information to the front end, and then uploads the document information, data and file hash value to the back end service. The front end then obtains the signature data of the signature bit, calculates the signature value, writes it to the file and updates the file content, thus completing the synthesis of a single signature bit.

[0052] Each time a single signature bit is synthesized, the signed data is written to the synthesis information. This process continues until all signature bits are synthesized, marking the file as signed. Once all threads have finished processing, the signature bit information for all files has been synthesized, and the data is written to the synthesis information. The synthesis information is then uploaded to the backend service and saved as legally valid proof of signing. After processing, the server returns a list of signed files to the frontend.

[0053] The signed data is converted into a format that is compatible with Wasm; all signed data bits are saved and written into the composite information as proof of signing. Wasm plays a central role in the entire system, significantly reducing the pressure on backend services.

[0054] An exemplary embodiment of this application also provides an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor. The memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the electronic device to perform a method according to an embodiment of this application.

[0055] An exemplary embodiment of this application also provides a non-transitory computer-readable storage medium storing a computer program, wherein the computer program, when executed by a computer's processor, is used to cause the computer to perform a method according to an embodiment of this application.

[0056] An exemplary embodiment of this application also provides a computer program product, including a computer program, wherein, when executed by a computer's processor, the computer program is used to cause the computer to perform a method according to an embodiment of this application.

[0057] refer to Figure 3The present invention describes a structural block diagram of an electronic device 300 that can serve as a server or client of this application, which is an example of a hardware device that can be applied to various aspects of this application. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the application described and / or claimed herein.

[0058] like Figure 3 As shown, the electronic device 300 includes a computing unit 301, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 302 or a computer program loaded from a storage unit 308 into a random access memory (RAM) 303. The RAM 303 may also store various programs and data required for the operation of the device 300. The computing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0059] Multiple components in electronic device 300 are connected to I / O interface 305, including: input unit 306, output unit 307, storage unit 308, and communication unit 309. Input unit 306 can be any type of device capable of inputting information to electronic device 300. Input unit 306 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device. Output unit 307 can be any type of device capable of presenting information and may include, but is not limited to, a display, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 308 may include, but is not limited to, disk and optical disk. Communication unit 309 allows electronic device 300 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and may include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0060] The computing unit 301 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 301 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 301 performs the various methods and processes described above. For example, in some embodiments, the reconstruction and decomposition of the muscle movement trajectory of the signature stroke based on the original trajectory, and the decomposition of its logarithmic velocity curve, can be implemented as a computer software program, which is tangibly contained in a machine-readable medium, such as storage unit 308. In some embodiments, part or all of the computer program can be loaded and / or installed on the electronic device 300 via ROM 302 and / or communication unit 309. In some embodiments, the computing unit 301 can be configured by any other suitable means (e.g., by means of firmware) to perform a signature handwriting dynamic acquisition implementation method.

[0061] The program code used to implement the methods of this application may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the functions / operations specified in the flowcharts and / or block diagrams are implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0062] In the context of this application, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0063] As used in this application, the terms "machine-readable medium" and "computer-readable medium" refer to any computer program product, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) for providing machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term "machine-readable signal" refers to any signal for providing machine instructions and / or data to a programmable processor.

[0064] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0065] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0066] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other.

Claims

1. A multi-document local signing method based on WASM, characterized in that, include: The local signing client initiates a signing task, creates a list of documents to be signed, edits the signing positions, and starts a thread for each document to be signed. It adds the corresponding signing position image to all signing positions under the document to be signed, forming a task list to be processed. The signing task is executed according to the order of the task list. Simultaneously, the local signing client sends the signing position data to the front-end and WASM interaction layer. The front-end and WASM interaction layer upload each signing position data to the back-end server for processing. The back-end server retrieves the signing position information based on the uploaded task and returns it to the interaction layer. The interaction layer determines the signing image based on the signing position information, retrieves the corresponding file from the task list, calculates the file hash, and sequentially passes the file hash and corresponding signing position data to the WASM service layer. The WASM synthesis module in the WASM service layer receives the file hash and the signing position data to be synthesized, creates a file signature field, and sets the signing image as the appearance of this signature. During synthesis, it returns document information to the interaction layer. The interaction layer receives the document information, uploads the document information, signing data, and the file hash value together to the back-end server. The back-end server retrieves the signature data encoded in the signing position encoding method and returns the signature data to WASM. The interaction layer calculates the signature value based on the signature data in the signature bits. The WASM synthesis module writes the signature value into the corresponding file signature bits, synthesizes the signature bits, and completes the file signing.

2. The method according to claim 1, characterized in that, Each thread processes a document with several signature bits to be signed. Each thread independently calls the WASM module to perform the signing task. Multiple documents to be signed are processed in parallel by multiple threads. When merging each signature bit, the content of the document is updated and the merging information is written. This continues until all signature bits are merged, completing the signature merging of all documents in the thread list. The thread then ends and the merging information is uploaded to the backend server.

3. The method according to claim 1, characterized in that, The signing data format is a collection of files and multiple signature position data, forming a multi-signature position data. Each data entry consists of a file (file) and multiple signature position data (data). The signing data format for multiple files is: [SignData, SignData... multiple files with signature positions]. Here, SignData is the complete signing data format for a single file: SignData = {file, signInfo: [SignOverlay, SealOverlay, ... multiple signature positions or seal positions]}. The signature position data format is SignOverlay = {data, rectangle, 2, page}, and the seal position data format is SealOverlay = {data, rectangle, 1, page}. Here, rectangle: the position and size information of the signature position, file is a PDF file, data: the signature value, signInfo: signature information, and page: the signature page number.

4. The method according to any one of claims 1-3, characterized in that, When processing a single file signing task, all signature bit data under the file is transmitted to the WASM service layer. The WASM service layer creates a file signature field based on the file and the corresponding signed signature bit data, sets each signature bit as the appearance of this signature, so that the signed signature bit generated by the front-end layer is pasted on the file and updated to a signed file, thus completing the signing of a single file.

5. The method according to any one of claims 1-3, characterized in that, In the WASM service layer, when the Wasm composition module processes multiple files to be composed, it executes a multi-threaded process to check all signature bits in the file to be composed, uploads the data of each signature bit to the backend service, and saves the image of each signature bit. The signature bit information and images returned by the backend service are added to the task queue to be processed. During the execution of each signing task, the signature bit data in that task is uploaded to the backend service, and the returned signature bit information, along with the signature bit images, is saved to the processing task to be composed, resulting in the task queue to be processed. Based on the number of signature bits in the task queue to be processed, the queue is set into multiple corresponding tasks, and these tasks are executed concurrently. After all the signing tasks in the task queue are processed, all data is retrieved from the processing task to be composed, and the file hash value and corresponding data are passed to the Wasm composition module one by one.

6. A multi-document local signing system based on WASM, characterized in that, include: The process involves a local signing client, a frontend-WASM interaction layer, a WASM service layer, and a backend server. The local signing client initiates a signing task, creating a list of documents to be signed, editing the signing positions, and starting a thread for each document to be signed. It adds the corresponding signing position image to all signing positions in the document to form a task list. Signing tasks are executed according to the order of the task list. Simultaneously, the local signing client sends the signing position data to the frontend-WASM interaction layer. The frontend-WASM interaction layer uploads each signing position data to the backend server for processing. The backend server retrieves the signing position information based on the uploaded task and returns it to the interaction layer. The interaction layer determines the signing image based on the signing position information, retrieves the corresponding file from the task list, calculates the file hash, and sequentially passes the file hash and corresponding signing position data to the WASM service layer. In the WASM service layer, the WASM compositing module receives the file hash and the signing position data to be composited, creates a file signature field, and sets the signing image as the appearance of the signature. During compositing, it returns document information to the interaction layer. The interaction layer receives the document information, the signing data, and the file hash. The file is uploaded to the backend server along with the signature bit. The backend server obtains the signature data in the encoding method of the signature bit and returns the signature data to the WASM interaction layer. The interaction layer calculates the signature value based on the signature data. The WASM synthesis module writes the signature value into the corresponding file signature bit, synthesizes the signature bit, and completes the file signing.

7. The system according to claim 6, characterized in that, Each thread processes a document with several signature bits to be signed. Each thread independently calls the WASM module to perform the signing task. Multiple documents to be signed are processed in parallel by multiple threads. When merging each signature bit, the content of the document is updated and the merging information is written. This continues until all signature bits are merged, completing the signature merging of all documents in the thread list. The thread then ends and the merging information is uploaded to the backend server.

8. The system according to claim 6, characterized in that, The signing data format is a collection of files and multiple signature position data, forming a multi-signature position data. Each data entry consists of a file (file) and multiple signature position data (data). The signing data format for multiple files is: [SignData, SignData... multiple files with signature positions]. Here, SignData is the complete signing data format for a single file: SignData = {file, signInfo: [SignOverlay, SealOverlay, ... multiple signature positions or seal positions]}. The signature position data format is SignOverlay = {data, rectangle, 2, page}, and the seal position data format is SealOverlay = {data, rectangle, 1, page}. Here, rectangle: the position and size information of the signature position, file is a PDF file, data: the signature value, signInfo: signature information, and page: the signature page number.

9. The system according to any one of claims 6-8, characterized in that, When processing a single file signing task, all signature bit data under the file is transmitted to the WASM service layer. The WASM service layer creates a file signature field based on the file and the corresponding signed signature bit data, sets each signature bit as the appearance of this signature, so that the signed signature bit generated by the front-end layer is pasted on the file and updated to a signed file, thus completing the signing of a single file.

10. The system according to any one of claims 6-8, characterized in that, In the WASM service layer, when the Wasm composition module processes multiple files to be composed, it executes a multi-threaded process to check all signature bits in the file to be composed, uploads the data of each signature bit to the backend service, and saves the image of each signature bit. The signature bit information and images returned by the backend service are added to the task queue to be processed. During the execution of each signing task, the signature bit data in that task is uploaded to the backend service, and the returned signature bit information, along with the signature bit images, is saved to the processing task to be composed, resulting in the task queue to be processed. Based on the number of signature bits in the task queue to be processed, the queue is set into multiple corresponding tasks, and these tasks are executed concurrently. After all the signing tasks in the task queue are processed, all data is retrieved from the processing task to be composed, and the file hash value and corresponding data are passed to the Wasm composition module one by one.

11. An electronic device, comprising: processor; And a memory for storing programs, characterized in that the programs include instructions that, when executed by the processor, cause the processor to perform the WASM-based multi-document local signing method according to claims 1-5.

12. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, in, The computer instructions are used to cause the computer to execute the WASM-based local signing method for multiple documents as described in claims 1-5.

Images