OFD-based multi-person collaborative endorsement method, device and equipment and storage medium
By using OFD technology and the WebSocket protocol, the system can acquire and display the handwriting coordinates and user information of the signatory users in real time, which solves the problems of location conflicts and handwriting attribution in multi-person collaborative signing, realizes efficient multi-person collaborative signing, and improves user experience and signing efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING ZHONGHONG LIDA TECH DEV CO LTD
- Filing Date
- 2026-01-26
- Publication Date
- 2026-05-05
AI Technical Summary
Existing multi-person collaborative signature solutions suffer from issues such as signature location conflicts, unclear handwriting attribution, pseudo-collaboration, and poor signature synchronization performance, resulting in low efficiency and a poor user experience.
By using an OFD-based multi-user collaborative signing method, the system can acquire and display the handwriting coordinates and user information of signing users in real time. It can realize real-time collaborative signing by multiple users using a shared canvas, use the WebSocket protocol for data synchronization, and combine spatial Boolean operations and permission management to avoid handwriting conflicts and recommend signing areas.
It enables real-time collaborative signing by multiple users, reduces handwriting conflicts, clarifies handwriting attribution, and improves the synchronization efficiency of signed content and formatted documents, as well as the user experience.
Smart Images
Figure CN121981684A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of data processing technology, and in particular to a method, apparatus, device and storage medium for multi-person collaborative signing based on OFD. Background Technology
[0002] In government offices, corporate management, and other scenarios, to prevent abuse of power, arbitrary decisions, or flawed decision-making, the approval of major contracts typically involves multiple stages, including confirmation of needs by the business department, risk assessment by the legal department, fund review by the finance department, and comprehensive decision-making by the responsible leader. With the widespread adoption of online office systems, collaborative signing of electronic documents by multiple parties has become a common requirement. This involves not only moving traditional offline signing processes online but also reconstructing collaborative workflows through digitalization and intelligentization to improve the efficiency of the signing process.
[0003] However, existing multi-person collaborative approval schemes have the following problems: (1) Signature position conflict: When multiple users sign at the same time, the handwriting often overlaps because the signature position of the other party cannot be perceived in real time. This requires repeated adjustments, which reduces efficiency and seriously affects the seriousness of the document. (2) Unclear handwriting ownership: The handwriting of the signature lacks a clear owner identification, which can easily lead to accidental erasure or revocation of other users' signatures, affecting the integrity of the signature; (3) “Pseudo-collaboration”: Some systems adopt “file lock” or “serial signature” mechanisms, that is, the next user can only sign after the previous user has completely saved and exited, which cannot achieve true synchronous collaboration and is inefficient. (4) Poor performance of “signature synchronization”: When any user saves, all users’ handwriting will be written to the OFD document and synchronized to all other users, resulting in a large amount of network transmission and data reading and writing. When the signature file is large, the system delay will cause the user experience to be sluggish.
[0004] Therefore, there is an urgent need for a multi-person collaborative signing solution that can reduce location conflicts, clarify handwriting attribution, and achieve efficient synchronization between the signed content and the format document. Summary of the Invention
[0005] To address the aforementioned problems in the prior art, this invention provides a method, apparatus, device, and storage medium for multi-user collaborative signature approval based on OFD. The technical problem to be solved by this invention is achieved through the following technical solution: The first aspect of this invention provides a multi-person collaborative signature method based on OFD, comprising: In response to the current approving user's co-signing task trigger operation on the target OFD document, the system acquires the first approval data generated by the approving user's approval operation on the shared canvas in real time; wherein, the first approval data includes the user ID of the approving user and the first handwriting coordinate array; the shared canvas is generated by the server for the target OFD document when creating the co-signing task; Based on the first handwriting coordinate array, the signed content generated by the signed user's signing operation is displayed in real time on the shared canvas of the current page; Obtain the user display information corresponding to the user ID of the approved user; The user's information is displayed in the approved area generated by the approved user's approval operation.
[0006] The method provided by this invention supports real-time or near-real-time collaborative signing and approval by multiple users, and can effectively reduce handwriting conflicts caused by multiple signing operations, clarify handwriting attribution, and achieve efficient synchronization of signing content and format documents. It is suitable for parallel signing and approval processing of electronic documents by multiple users in government, enterprise and other scenarios.
[0007] In one possible implementation, the method further includes: In response to the current approving user's approval operation on the target OFD document, the second approval data generated by the current approving user's approval operation is uploaded to the server in real time, so that the server can broadcast the second approval data to other approving users in real time. The second approval data includes the user ID of the current approving user and a second handwriting coordinate array.
[0008] In one possible implementation, the method further includes: In response to the current approving user's approval and modification operation on the target OFD document, obtain the user ID to which the approved content belongs corresponding to the approval and modification operation; If the user ID of the current approving user is inconsistent with the user ID of the approved content corresponding to the approval modification operation, the approval modification operation will not be allowed to be executed, and a permission-unauthorized prompt message will be displayed to indicate that the current approving user does not have permission to modify.
[0009] In one possible implementation, the method further includes: In response to the current approving user's reopening operation of the target OFD document, the stored historical handwriting of the current approving user is obtained and displayed; In response to the current approving user performing an approval operation on the target OFD document that has been reopened, the current approving user's historical handwriting is first cleared, and then the new handwriting generated by the current approving user's approval operation on the target OFD document that has been reopened is written.
[0010] In one possible implementation, the method further includes: In response to the current approving user's new approval operation on the target OFD document, determine whether there is an overlapping area between the newly added approval area corresponding to the new approval operation and the already approved area; If present, the signatures in the overlapping areas will not be displayed.
[0011] In one possible implementation, the method further includes: In response to the current approving user's countersigning task triggering operation on the target OFD document, the pending approving content of the current approving user and the unapproved content of the unapproved users are obtained in real time. Based on the content to be approved, the unapproved content, the approved area, and the total approval area of the current page, a recommended approval area is determined. The recommended approval area is displayed to prompt the current approval user to perform the approval operation within the recommended approval area.
[0012] In one possible implementation, the method further includes: Before the current approving user triggers the co-signing task for the target OFD document, the server broadcasts and pushes the co-signing task; wherein, the co-signing task includes task data, canvas association data and co-signing user data, and the co-signing user data includes the user IDs and user display information of all approving users.
[0013] A second aspect of the present invention provides an OFD-based multi-user collaborative signature device, applied to the current signature user terminal, the device comprising: The first acquisition module is used to respond to the current approving user's countersigning task trigger operation on the target OFD document, and to acquire the first approval data generated by the approving user's approval operation on the shared canvas in real time; wherein, the first approval data includes the user ID of the approving user and the first handwriting coordinate array; the shared canvas is generated by the server for the target OFD document when creating the countersigning task; The first display module is used to display the signed content generated by the signed user's signing operation on the shared canvas of the current page in real time, based on the first handwriting coordinate array. The second acquisition module is used to acquire user display information corresponding to the user ID of the approved user; The second display module is used to display the user's information in the approved area generated by the approved user's approval operation.
[0014] A third aspect of the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a multi-person collaborative signature method based on OFD provided in the first aspect of the present invention.
[0015] A fourth aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements a multi-person collaborative signature method based on OFD provided in the first aspect of the present invention.
[0016] For a detailed description of the second to fourth aspects of the present invention and their various implementations, please refer to the detailed description in the first aspect and its various implementations; and for a detailed description of the beneficial effects of the second to fourth aspects and their various implementations, please refer to the beneficial effect analysis in the first aspect and its various implementations, which will not be repeated here.
[0017] The technical solution of the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description
[0018] Figure 1 This is a flowchart illustrating a multi-person collaborative signing method based on OFD according to an embodiment of the present invention. Figure 2 This is a structural block diagram of a multi-person collaborative signing device based on OFD according to an embodiment of the present invention; Figure 3 This is a block diagram of the internal structure of an electronic device according to an embodiment of the present invention. Detailed Implementation
[0019] The present invention will be further described in detail below with reference to specific embodiments, but the implementation of the present invention is not limited thereto.
[0020] This invention provides a multi-user collaborative signature method based on OFD. This method is applied to the current signature user, which can be a server or a terminal device. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. The terminal device can be a smartphone, tablet, desktop computer, wearable device, etc., but is not limited to these.
[0021] Figure 1 This is a flowchart illustrating a multi-user collaborative signature method based on OFD provided in this embodiment. Figure 1 As shown, the main process of this method is described below (steps S101 to S104): Step S101: In response to the current approving user's countersigning task trigger operation on the target OFD document, the first approval data generated by the approving user's approval operation on the shared canvas is obtained in real time; wherein, the first approval data includes the user ID of the approving user and the first handwriting coordinate array. Step S102: Based on the first handwriting coordinate array, display the signed content generated by the signed user in real time on the shared canvas of the current page. Step S103: Obtain the user display information corresponding to the user ID of the approved user; Step S104: Display the user's information in the approved area generated by the user's approval operation.
[0022] In this embodiment, the initiating user uploads the document to be signed to the server and sets the information of all users participating in the signing. The server creates a signing task, generates a task ID, puts it into a task queue, and then checks whether each signing user (i.e., all user terminals participating in the signing task) is online. If the user is online, the signing task is pushed in real time via WebSocket, and the signing user terminal that receives the push displays an instant notification and renders the signing task interface. If the user is offline, the signing task is pushed externally (e.g., via SMS, email, etc.), the signing user terminal actively retrieves the task details, the server returns complete task data, and renders the signing task interface.
[0023] After receiving the uploaded document to be signed, if the document is not in OFD format, the server needs to convert it to OFD format first.
[0024] The task package includes task data, canvas-related data, and co-signing user data. Task data typically includes task ID, status, participants, target approval document, and workflow control information.
[0025] In this embodiment, when creating a countersigning task, the server generates a shared canvas for the target OFD document based on HTML5 Canvas technology (a graphics drawing element provided by the HTML5 standard, which uses JavaScript to achieve dynamic 2D / 3D image rendering on web pages, supporting scenarios such as game development, data visualization, and animation production). Specifically, different pages of each target OFD document can correspond to the same shared canvas, with each page corresponding to a specific area on the canvas; or, each page of the target OFD document corresponds to a unique canvas ID, associated with the document ID and page number, that is, the same number of shared canvases are generated as needed for the pages requiring signature.
[0026] The shared canvas is not directly embedded in the task broadcast message. Instead, the canvas association data is included in the co-signing task data and broadcast to each co-signing user client. The co-signing user client loads the canvas component through the canvas association data. The canvas association data can be canvasUrl (a direct network address URL pointing to the shared canvas resource or editing interface, allowing the co-signing user client to access a specific canvas instance by loading this URL) or collaborationId (a string used internally by the collaboration service to uniquely identify the canvas document; the co-signing user client uses this string to actively connect to the unified canvas collaboration backend service via WebSocket or a specific API).
[0027] The co-signing user data includes the user IDs and user display information of all users who participated in the signing and approval process of the target OFD document. The user display information can be a user avatar or a user name, etc., and this embodiment does not make specific limitations on this.
[0028] The current approving user initiates the co-signing task by clicking the corresponding button on the co-signing task interface, thus starting the co-signing task on their client. At this point, the current approving user's client loads the OFD document rendering engine and a blank canvas using canvas-related data, rendering the approval operation interface. The current approving user's client sends a request to the server to retrieve the approval data of all approved users (users who have completed approval operations and those currently performing approval operations). The server returns all historical handwriting data. The current approving user's client uses the OFD standard SDK to convert the coordinate array of the current approving user's handwriting into OFD-supported vector graphics, writes it to the specified location on the corresponding page, and renders it line by line on the shared canvas.
[0029] The current signatory can perform the signing operation on the signing operation interface, generating corresponding handwriting. The current signatory's client uses the OFD standard SDK to convert the coordinate array of the current signatory's handwriting into an OFD-supported vector graphic, and writes it to the specified location on the corresponding page. This recreates the complete signing process, including the handwriting of the current signatory and other signatory users.
[0030] When the current approving user puts down their pen, the current approving user's client uses JavaScript to capture the coordinates of the mouse / touch input. The current approving user's client then uses the OFD standard SDK to convert the coordinate array of the current approving user's handwriting into a vector graphic supported by OFD, writes it to the specified location on the corresponding page, and uses a relational database to synchronously store the handwriting metadata (associated with user ID and document ID); the target OFD document is stored in a distributed file system.
[0031] Simultaneously, in response to the current approving user's approval operation on the target OFD document, the current approving user's client uploads the second approval data generated by the current approving user's operation to the server in real time. The server then broadcasts this information to other approving user clients via the WebSocket protocol. This second approval data includes the current approving user's user ID and a second array of handwriting coordinates. Of course, to achieve real-time synchronization of canvas states across multiple users, in addition to coordinates and user IDs, the current approving user client sends other information that is broadcast by the server, such as handwriting color, thickness, and timestamps.
[0032] In this embodiment, the first handwriting coordinate array contains all the coordinates corresponding to the handwriting generated by the approved user on the shared canvas, and the second handwriting coordinate array contains all the coordinates corresponding to the handwriting generated by the current approved user on the shared canvas.
[0033] The current approving user client can determine the approved area generated by the approving user's approval operation based on the first handwriting coordinate array. Optionally, the first handwriting coordinate array can be converted into multiple computable geometric regions (such as rectangles and polygons), and then spatial Boolean operations such as merging, intersecting, and subtracting multiple geometric regions can be performed to finally determine the approved area.
[0034] In step S104, for any signed user, after obtaining the signed area of the signed user, the user display information of the signed user is displayed in the signed area, so that the current sign user can intuitively perceive that the area has been occupied, reminding the current sign user not to perform the signing operation in the area, reducing the situation where multiple sign users perform the signing operation in the same location and the signing content is superimposed, and continues to be displayed until the current sign user finishes the current signing operation or leaves the area.
[0035] Of course, the current approving user's information can also be displayed in the approval area generated by the current approving user's current approval operation. The determination of this approval area can refer to the already approved area, which will not be elaborated here.
[0036] Optionally, user display information of the approving user can be displayed near the initial pen placement position to remind other approving users not to perform approval operations in this area.
[0037] Based on a real-time conflict avoidance mechanism using a shared canvas and avatar identifiers, a lightweight PenDown event is broadcast via WebSocket instead of synchronizing all handwriting data in real time, achieving efficient visual conflict alerts with minimal network overhead. Handwriting permission management with owner attributes binds each piece of data to an owner attribute, and when processing save requests on the server side, atomic transactions such as "search-delete-add" are performed at the user level, ensuring the independence and security of operations and enabling lock-free collaboration.
[0038] When the current approving user reopens the target OFD document, the current approving user's client responds to this reopening operation by retrieving and displaying the stored historical handwriting of the current approving user. When the current approving user performs an approval operation on the reopened target OFD document, the current approving user's client responds to this approval operation by first clearing the current approving user's historical handwriting, and then writing the new handwriting generated by the current approving user's approval operation on the reopened target OFD document.
[0039] In this embodiment, the approval operation includes approval modification operation and approval addition operation.
[0040] In some optional embodiments, when the current approving user modifies a certain approved content, the current approving user responds to the approval modification operation by obtaining the user ID to which the approved content belongs. If the user ID of the current approving user is inconsistent with the user ID to which the approved content belongs, the approval modification operation is not allowed to be executed, and a permission-unauthorized prompt message is displayed to indicate that the current approving user does not have permission to modify.
[0041] When a user generates a signature, the user client binds a unique owner attribute (i.e., user ID) to each user's signature. Only the owner is allowed to perform operations such as erasing and undoing on the signature. When a non-owner performs an operation, a permission prompt is triggered, restricting the non-owner from performing operations such as erasing and undoing on the signature.
[0042] In some optional embodiments, if the approval content generated by the current approving user for adding a signature to the target OFD document conflicts in position with other already approved content, it is not allowed.
[0043] Specifically, the current approving user responds to the current approving user's new approval operation on the target OFD document by determining whether the new approval area corresponding to the new approval operation overlaps with the already approved area; if so, the approval text in the overlapping area is not displayed.
[0044] Furthermore, to ensure the integrity of the signed signatures, when there are overlapping areas, not only will the signed signatures in the overlapping areas be not displayed, but the signed signatures in the other non-overlapping areas will also be not displayed.
[0045] In some optional embodiments, in response to the current approving user's countersigning task trigger operation on the target OFD document, the pending approving content of the current approving user and the unapproved content of the unapproved users are obtained in real time; based on the pending approving content, unapproved content, the approved area and the total approval area of the current page, a recommended approval area is determined; the recommended approval area is displayed to prompt the current approving user to perform the approval operation within the recommended approval area.
[0046] In this embodiment, before the current approving user performs the approval operation, the already approved area is determined based on the first handwriting coordinate array of all approved users. All already approved areas are then removed from the total approval area (the total area allowed for approval on the current page of the target OFD document), resulting in the area to be approved. The recommended approval area is derived from this area and is determined based on the content to be approved by the current approving user and the unapproved content of the unapproved users.
[0047] Optionally, obtain the first historical handwriting coordinate array corresponding to the content to be signed by the current signer, and determine the first habitual area occupied by the current signer based on the first historical handwriting coordinate array; obtain the second historical handwriting coordinate array corresponding to the unsigned content of the unsigned user, and determine the second habitual area occupied by the current signer based on the second historical handwriting coordinate array; dynamically divide the area to be signed on the current page into multiple sub-signing areas; allocate several sub-signing areas to the current signer and the unsigned user based on the first habitual area and the second habitual area.
[0048] Each first historical handwriting coordinate array and each second historical handwriting coordinate array are converted into its minimum bounding rectangle. Feature extraction is performed on these minimum bounding rectangles to obtain the size preference, position preference, and shape preference of the current approving user and the non-approving user. For any approving user, the total approval area is divided into multiple identical sub-grids. The center point of each minimum bounding rectangle contributes a heatmap to that grid, resulting in a heatmap. The continuous area with the highest heatmap temperature is the user's habitually occupied area. This habitually occupied area may be irregular.
[0049] For the current approving user, calculate the matching degree between the user's first habitually occupied area and each available sub-area (based on location overlap, size fit, etc.), select the sub-area with the highest matching degree, immediately lock that area, and directly use it as the recommended approving area. If the system also predicts that this area is the best match for a user who has not yet approved, then the decision is made according to preset priorities (such as role weight, task urgency), and the winner gets it.
[0050] For users who haven't signed off, a bipartite graph matching problem is modeled for all unsigned users and the remaining available sub-regions. Using the user-region matching degree as weights, a solver such as the Hungarian algorithm is run to obtain the globally optimal allocation scheme. This scheme is temporarily stored on the server, forming a region reservation table. When an unsigned user actually enters the signing interface, the sub-region assigned to them is directly retrieved from the reservation table as their recommended signing region.
[0051] In this embodiment, the recommended approval area is determined jointly by spatial calculation, process rules, and user history behavior. Essentially, it's a collaborative spatial resource scheduling system designed to intelligently, orderly, and efficiently allocate and guide user approval behavior within a limited document space, thereby improving the overall collaborative approval experience and quality. Approving users no longer need to manually search for blank spaces; the system intelligently guides them, reducing operation time and improving approval efficiency. It optimizes page layout, avoiding the stacking, overlapping, and clutter of approval content, resulting in a neat and orderly final document. Based on the approving user's habits, it recommends approval areas suitable for their preferences. Through prediction and reservation, it ensures that subsequent approvers also have reasonable approval space, preventing "first-come, first-served" space occupation issues. It fundamentally reduces approval conflicts or content overlays caused by space overlap.
[0052] Based on the same inventive concept, embodiments of the present invention provide a multi-person collaborative signing device based on OFD. Figure 2 This is a structural block diagram of a multi-user collaborative signature device 200 based on OFD provided in an embodiment of the present invention. Figure 2 As shown, the OFD-based multi-user collaborative signature device 200 mainly includes: The first acquisition module 201 is used to respond to the current approving user's countersigning task trigger operation on the target OFD document and acquire the first approval data generated by the approving user's approval operation on the shared canvas in real time; wherein, the first approval data includes the user ID of the approving user and the first handwriting coordinate array; the shared canvas is generated by the server for the target OFD document when creating the countersigning task; The first display module 202 is used to display the signed content generated by the signed user's signing operation in real time on the shared canvas of the current page based on the first handwriting coordinate array. The second acquisition module 203 is used to acquire user display information corresponding to the user ID of the approved user; The second display module 204 is used to display user information in the approved area generated by the approved user's approval operation.
[0053] In some optional embodiments, the device further includes: The upload module is used to respond to the current approving user's approval operation on the target OFD document, and upload the second approval data generated by the current approving user's approval operation to the server in real time, so that the server can broadcast the second approval data to other approving users in real time; wherein, the second approval data includes the user ID of the current approving user and the second handwriting coordinate array.
[0054] In some optional embodiments, the device further includes: The permission determination module is used to respond to the current approving user's approval and modification operation on the target OFD document, and to obtain the user ID of the user to which the approved content belongs. If the user ID of the current approving user is inconsistent with the user ID of the user to which the approved content belongs, the approval and modification operation is not allowed to be executed, and a permission-unauthorized prompt message is displayed to indicate that the current approving user does not have permission to modify.
[0055] In some optional embodiments, the device further includes: The handwriting update module is used to respond to the current approving user's reopening of the target OFD document, to obtain and display the stored historical handwriting of the current approving user; and to respond to the current approving user's signing operation on the reopened target OFD document, to first clear the current approving user's historical handwriting, and then write the new handwriting generated by the current approving user's signing operation on the reopened target OFD document.
[0056] In some optional embodiments, the device further includes: The handwriting overlap detection module is used to respond to the current approving user's new approval operation on the target OFD document and determine whether there is an overlap between the newly added approval area and the already approved area; if there is, the handwriting in the overlapping area will not be displayed.
[0057] In some optional embodiments, the device further includes: The recommendation module is used to respond to the current approving user's co-signing task trigger operation on the target OFD document, and to obtain the content to be signed by the current approving user and the unsigned content of the unsigned users in real time; based on the content to be signed, the unsigned content, the signed area, and the total signing area of the current page, it determines the recommended signing area; and displays the recommended signing area to prompt the current approving user to perform the signing operation within the recommended signing area.
[0058] In some optional embodiments, the device further includes: The task receiving module is used to receive the co-signing task broadcast by the server before the current approving user triggers the co-signing task on the target OFD document. The co-signing task package includes task data, canvas association data, and co-signing user data. The co-signing user data includes the user IDs and user display information of all approving users.
[0059] The functional modules in the embodiments of this invention can be integrated together to form an independent unit, such as integrated into a processing unit, or each module can exist physically separately, or two or more modules can be integrated to form an independent unit. The integrated unit can be implemented in hardware or as a software functional unit. If the function is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause an electronic device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.
[0060] Various variations and specific examples of the methods provided in the embodiments of the present invention are also applicable to the OFD-based multi-person collaborative signing device provided in this embodiment. Through the foregoing detailed description of the OFD-based multi-person collaborative signing method, those skilled in the art can clearly understand the implementation method of the OFD-based multi-person collaborative signing device in this embodiment. For the sake of brevity, it will not be described in detail here.
[0061] Figure 3 This is a structural block diagram of an electronic device 300 provided in an embodiment of the present invention. Figure 3 As shown, the electronic device 300 includes a memory 301, a processor 302, and a communication bus 303; the memory 301 and the processor 302 are connected through the communication bus 303.
[0062] The memory 301 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 301 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for at least one function, and instructions for implementing the OFD-based multi-user collaborative signature method provided in the above embodiments. The data storage area may store data involved in the OFD-based multi-user collaborative signature method provided in the above embodiments.
[0063] Processor 302 may include one or more processing cores. Processor 302 executes instructions, programs, code sets, or instruction sets stored in memory 301, and calls data stored in memory 301 to perform various functions and process data as described in this application. Processor 302 may be at least one of the following: Application Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), controller, microcontroller, and microprocessor. It is understood that for different devices, the electronic devices used to implement the functions of processor 302 may also be other types, and this embodiment of the invention does not specifically limit the specific devices used.
[0064] The communication bus 303 may include a path for transmitting information between the aforementioned components. The communication bus 303 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. The communication bus 303 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 3 The symbol is represented by only one double arrow, but this does not indicate that there is only one bus or one type of bus. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of the present invention.
[0065] This invention also provides a computer-readable storage medium storing a computer program that can be loaded by a processor and executed as described in the above embodiments for a multi-user collaborative signature method based on OFD.
[0066] In this embodiment, the computer-readable storage medium can be a tangible device that holds and stores instructions used by an instruction execution device. The computer-readable storage medium can be, but is not limited to, an electrical storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any combination thereof. Specifically, the computer-readable storage medium can be a portable computer disk, a hard disk, a USB flash drive, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), staging random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory stick, floppy disk, optical disk, magnetic disk, mechanical encoding device, or any combination thereof.
[0067] The computer program in this embodiment includes functions for executing... Figure 1 The program code for the method shown may include instructions corresponding to the execution of the method steps provided in the above embodiments. The computer program may be downloaded from a computer-readable storage medium to various computing / processing devices, or downloaded via a network (e.g., the Internet, local area network, wide area network, and / or wireless network) to an external computer or external storage device. The computer program may be executed entirely on the user's computer as a standalone software package.
[0068] In the embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.
[0069] Additionally, it should be understood that relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.
[0070] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.
Claims
1. A multi-person collaborative approval method based on OFD, characterized in that, Applied to the current approval user terminal, the method includes: In response to the current approving user's co-signing task trigger operation on the target OFD document, the system acquires the first approval data generated by the approving user's approval operation on the shared canvas in real time; wherein, the first approval data includes the user ID of the approving user and the first handwriting coordinate array; the shared canvas is generated by the server for the target OFD document when creating the co-signing task; Based on the first handwriting coordinate array, the signed content generated by the signed user's signing operation is displayed in real time on the shared canvas of the current page; Obtain the user display information corresponding to the user ID of the approved user; The user's information is displayed in the approved area generated by the approved user's approval operation.
2. The method as described in claim 1, characterized in that, The method further includes: In response to the current approving user's approval operation on the target OFD document, the second approval data generated by the current approving user's approval operation is uploaded to the server in real time, so that the server can broadcast the second approval data to other approving users in real time. The second approval data includes the user ID of the current approving user and a second handwriting coordinate array.
3. The method as described in claim 1 or 2, characterized in that, The method further includes: In response to the current approving user's approval and modification operation on the target OFD document, obtain the user ID to which the approved content belongs corresponding to the approval and modification operation; If the user ID of the current approving user is inconsistent with the user ID of the approved content corresponding to the approval modification operation, the approval modification operation will not be allowed to be executed, and a permission-unauthorized prompt message will be displayed to indicate that the current approving user does not have permission to modify.
4. The method as described in claim 1 or 2, characterized in that, The method further includes: In response to the current approving user's reopening operation of the target OFD document, the stored historical handwriting of the current approving user is obtained and displayed; In response to the current approving user performing an approval operation on the target OFD document that has been reopened, the current approving user's historical handwriting is first cleared, and then the new handwriting generated by the current approving user's approval operation on the target OFD document that has been reopened is written.
5. The method as described in claim 1 or 2, characterized in that, The method further includes: In response to the current approving user's new approval operation on the target OFD document, determine whether there is an overlapping area between the newly added approval area corresponding to the new approval operation and the already approved area; If present, the signatures in the overlapping areas will not be displayed.
6. The method as described in claim 1 or 2, characterized in that, The method further includes: In response to the current approving user's countersigning task triggering operation on the target OFD document, the pending approving content of the current approving user and the unapproved content of the unapproved users are obtained in real time. Based on the content to be approved, the unapproved content, the approved area, and the total approval area of the current page, a recommended approval area is determined. The recommended approval area is displayed to prompt the current approval user to perform the approval operation within the recommended approval area.
7. The method as described in claim 1 or 2, characterized in that, The method further includes: Before the current approving user triggers the co-signing task for the target OFD document, the server broadcasts and pushes the co-signing task; wherein, the co-signing task includes task data, canvas association data and co-signing user data, and the co-signing user data includes the user IDs and user display information of all approving users.
8. A multi-person collaborative signature device based on OFD, characterized in that, Applied to the current approval user terminal, the device includes: The first acquisition module is used to respond to the current approving user's countersigning task trigger operation on the target OFD document, and to acquire the first approval data generated by the approving user's approval operation on the shared canvas in real time; wherein, the first approval data includes the user ID of the approving user and the first handwriting coordinate array; the shared canvas is generated by the server for the target OFD document when creating the countersigning task; The first display module is used to display the signed content generated by the signed user's signing operation on the shared canvas of the current page in real time, based on the first handwriting coordinate array. The second acquisition module is used to acquire user display information corresponding to the user ID of the approved user; The second display module is used to display the user's information in the approved area generated by the approved user's approval operation.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the OFD-based multi-person collaborative signature method as described in any one of claims 1 to 7.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the OFD-based multi-person collaborative signature method as described in any one of claims 1 to 7.