Conference file synchronization method and device and storage medium

Abstract

The invention provides a conference file synchronization method and device and a storage medium, relates to the technical field of file synchronization, and aims to improve the timeliness, convenience and safety of conference file synchronization. The method comprises the following steps: receiving a file storage request sent by a first terminal; in response to the file storage request, storing the conference file, the target conference identifier and a conference file synchronization strategy, and establishing a mapping relationship among the target conference identifier, the conference file synchronization strategy and the conference file; receiving a file synchronization request sent by a second terminal, wherein the file synchronization request carries the target conference identifier; in response to the file synchronization request, acquiring a conference file synchronization strategy corresponding to the target conference identifier, and verifying the file synchronization request based on the conference file synchronization strategy; and under the condition that the time of the file synchronization request is within the conference validity period, sending a conference file corresponding to the target conference identifier to the second terminal based on the mapping relationship.

Description

Technical Field

[0001] This application relates to the field of document synchronization technology, and in particular to a method, device and storage medium for synchronizing conference documents. Background Technology

[0002] In daily work scenarios, meetings are held frequently. For important meetings, it is usually necessary to prepare relevant meeting materials in advance for participants' reference. With the continuous advancement of paperless office models, electronic devices have gradually replaced traditional paper materials and are widely used in the presentation and use of meeting materials. Currently, the transmission of meeting materials via electronic devices is mostly done by assistants copying them using portable storage devices such as USB flash drives. This method not only consumes a lot of time and manpower but also suffers from the problem of meeting materials not being updated in a timely manner, and file security is difficult to guarantee effectively. Summary of the Invention

[0003] The purpose of this application is to provide a method, device, and storage medium for synchronizing meeting documents, aiming to improve the timeliness, convenience, and security of meeting document synchronization.

[0004] To achieve the above objectives, the embodiments of this application provide the following technical solutions: In a first aspect, this application provides a meeting file synchronization method applied to a server. The method includes: receiving a file storage request sent by a first terminal, the file storage request including at least one meeting file, an associated target meeting identifier, and a meeting file synchronization policy; responding to the file storage request, storing the meeting file, the target meeting identifier, and the meeting file synchronization policy, and establishing a mapping relationship between the target meeting identifier, the meeting file synchronization policy, and the meeting file; receiving a file synchronization request sent by a second terminal, the file synchronization request carrying a target meeting identifier; responding to the file synchronization request, obtaining the meeting file synchronization policy corresponding to the target meeting identifier, and verifying the file synchronization request based on the meeting file synchronization policy; wherein the meeting file synchronization policy includes a meeting validity period; and if the time of the file synchronization request is within the meeting validity period, sending the meeting file corresponding to the target meeting identifier to the second terminal based on the mapping relationship.

[0005] The meeting document synchronization method provided in this application effectively solves the efficiency and security problems in traditional meeting document management by constructing an automated file distribution mechanism based on network transmission. First, this method achieves unified maintenance and on-demand synchronization of meeting documents through centralized server-side storage and policy-based management, completely eliminating reliance on physical media and improving the efficiency and convenience of file distribution. Second, by introducing a meeting document synchronization policy verification mechanism that includes the meeting's validity period, it ensures that meeting documents are accessed by authorized terminals within the preset validity period. This improves collaboration efficiency while effectively preventing unauthorized dissemination and expired use of meeting materials, balancing the timeliness and security of information sharing. It can be seen that this method eliminates the need to copy meeting documents through physical media, significantly saving manpower and time costs. Simultaneously, it relies on the meeting document synchronization policy to ensure file synchronization within a reasonable timeframe, guaranteeing meeting document security and avoiding the problem of materials not being updated in a timely manner in traditional methods, effectively adapting to the meeting material management needs of paperless office scenarios.

[0006] In some embodiments, a deletion operation on the meeting file is triggered when a cleanup condition associated with the target meeting identifier is met; wherein, meeting the cleanup condition associated with the target meeting identifier includes at least one of the following: the meeting validity period has expired, or a cleanup instruction has been received from the first terminal.

[0007] In some embodiments, the meeting file synchronization policy further includes a user permission list; verifying the file synchronization request based on the meeting file synchronization policy includes: verifying whether the user identity of the second terminal is in the user permission list, and whether the time of the file synchronization request is within the meeting validity period.

[0008] In some embodiments, if it is detected that all terminals in the user permission list have completed file synchronization, the deletion operation of the meeting files is triggered.

[0009] Secondly, this application also provides a method for synchronizing meeting files, applied to a second terminal. The method includes: sending a file synchronization request to a server, the file synchronization request carrying a target meeting identifier; receiving a response returned by the server based on the file synchronization request; wherein the response is issued by the server after verifying the file synchronization request according to a meeting file synchronization policy corresponding to the target meeting identifier, the meeting file synchronization policy including the meeting validity period; if the time of the file synchronization request is within the meeting validity period, the response is identified as successful verification, and the meeting file corresponding to the target meeting identifier returned by the storage server is stored.

[0010] This application also provides a method for synchronizing meeting documents. This method enables a second terminal to accurately initiate a meeting document synchronization request. The timeliness and legality of the obtained documents are ensured through server-side policy verification. This avoids invalid requests and enables the rapid acquisition of compliant meeting documents. It further improves the terminal-side management process of meeting documents in paperless office scenarios and enhances the convenience and security of meeting participants in obtaining meeting materials.

[0011] In some embodiments, upon detecting a predefined meeting end event, the locally stored meeting file is deleted; wherein the meeting end event includes at least one of the following: detecting a user's triggering operation on the end meeting control, detecting that the meeting validity period has expired, or detecting that the connection with the meeting LAN has been lost.

[0012] In some embodiments, the system receives personalized settings input by the user, calls the operating system interface of the second terminal, and configures the operating system desktop environment where the synchronized meeting files are located.

[0013] In some embodiments, if a verification failure is detected and the reason for rejection is that the current time is not within the validity period of the meeting, the corresponding error message is displayed.

[0014] Thirdly, this application provides a meeting file synchronization device applied to a server. The device includes a first receiving module, a first storage module, a verification module, and a first sending module. Specifically, the first receiving module is used to: receive a file storage request sent by a first terminal, the file storage request including at least one meeting file, an associated target meeting identifier, and a meeting file synchronization policy; the first storage module is used to: in response to the file storage request, store the meeting file, the target meeting identifier, and the meeting file synchronization policy, and establish a mapping relationship between the target meeting identifier, the meeting file synchronization policy, and the meeting file; the first receiving module is used to: receive a file synchronization request sent by a second terminal, the file synchronization request carrying the target meeting identifier; the verification module is used to: in response to the file synchronization request, obtain the meeting file synchronization policy corresponding to the target meeting identifier, and verify the file synchronization request based on the meeting file synchronization policy; wherein, the meeting file synchronization policy includes a meeting validity period; the first sending module is used to: when the time of the file synchronization request is within the meeting validity period, send the meeting file corresponding to the target meeting identifier to the second terminal based on the mapping relationship.

[0015] Fourthly, this application also provides a conference file synchronization device applied to a second terminal. The device includes a second sending module, a second receiving module, and a second storage module. Specifically, the second sending module is used to: send a file synchronization request to a server, the file synchronization request carrying a target conference identifier; the second receiving module is used to: receive a response returned by the server based on the file synchronization request; wherein the response is issued by the server after verifying the file synchronization request according to the conference file synchronization policy corresponding to the target conference identifier, the conference file synchronization policy including the conference validity period; the second storage module is used to: if the time of the file synchronization request is within the conference validity period, recognize that the response is a successful verification, and store the conference file returned by the server corresponding to the target conference identifier.

[0016] Fifthly, this application also provides an electronic device comprising: a processor and a memory; the memory storing processor-executable instructions; when the processor is configured to execute the instructions, causing the electronic device to implement the methods of the first or second aspect described above.

[0017] Sixthly, this application also provides a computer-readable storage medium comprising: computer software instructions; when the computer software instructions are executed in an electronic device, the electronic device causes the electronic device to implement the methods of the first or second aspect described above.

[0018] In a seventh aspect, this application also provides a computer program product comprising a computer program that, when run on an electronic device, causes the electronic device to perform the methods described in the first or second aspect.

[0019] The beneficial effects of the third to seventh aspects mentioned above can be referred to the corresponding descriptions of the first or second aspects, and will not be repeated here. Attached Figure Description

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

[0021] Figure 1 A schematic diagram of the architecture of a conference document synchronization system provided in this application embodiment; Figure 2 A flowchart illustrating a meeting document synchronization method provided in this application embodiment; Figure 3 A flowchart illustrating another method for synchronizing meeting documents provided in this application embodiment; Figure 4 A flowchart illustrating a meeting document synchronization method provided in this application embodiment. Figure 1 ; Figure 5 A flowchart illustrating a meeting document synchronization method provided in this application embodiment. Figure 2 ; Figure 6 A schematic diagram of the composition of a conference document synchronization device provided in this application embodiment; Figure 7 A schematic diagram illustrating the composition of another conference document synchronization device provided in this application embodiment; Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

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

[0023] It should be noted that in the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0024] In the embodiments of this application, the terms "first," "second," "third," "fourth," "fifth," and "sixth" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," "third," "fourth," "fifth," and "sixth" may explicitly or implicitly include one or more of that feature.

[0025] In embodiments of this application, 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 a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. For "A and / or B," this includes three combinations: A only, B only, and a combination of A and B.

[0026] With the continuous deepening of information technology construction, paperless office models have been widely applied in various work scenarios. In the process of organizing meetings, the use of electronic devices such as tablets to replace traditional paper materials has become a common trend. In related technologies, staff usually need to rely on mobile storage devices to transmit and distribute meeting materials, but this operation has several aspects that need optimization. For example, before the marketing department gives an important report to the board of directors, assistants often need to copy hundreds of pages of PPT slides and data analysis reports one by one to the tablets of multiple directors via USB drives, a process that can take several hours. If data errors are discovered at the last minute before the meeting, updating the files on all tablets becomes extremely difficult, easily leading to meeting delays. Furthermore, in meetings involving sensitive content (such as legal due diligence or M&A negotiations), using USB drives to copy documents makes it impossible to effectively track the flow of documents, posing a risk of leakage; and having assistants collect the tablets and manually delete confidential materials after the meeting also inevitably raises concerns about omissions.

[0027] In summary, there are many problems with the technology for synchronizing meeting materials in a paperless office model: First, material transmission relies on manual operation, which requires a lot of time and manpower; second, it is difficult to achieve rapid synchronization when meeting materials need to be updated temporarily; third, there may be risks to data security management during file transmission; and fourth, it is necessary to clean up the files on the device after the meeting, which increases the workload of subsequent maintenance.

[0028] To address the aforementioned issues, this application provides a method for synchronizing meeting files. This method includes: a server first receiving a file storage request from a first terminal, the request containing at least one meeting file, an associated target meeting identifier, and a meeting file synchronization policy (including the meeting validity period). The server then responds by storing this information and establishing a mapping relationship between the target meeting identifier, the meeting file synchronization policy, and the meeting file. When a file synchronization request carrying a target meeting identifier is received from a second terminal, the server first obtains the corresponding meeting file synchronization policy, verifies the request based on this policy, and, if the file synchronization request time falls within the meeting validity period, sends the corresponding meeting file to the second terminal according to the mapping relationship. It can be seen that this method eliminates the need to copy meeting files using physical media, significantly saving manpower and time costs. Simultaneously, it ensures file synchronization within a reasonable timeframe by relying on the meeting file synchronization policy, guaranteeing meeting file security and avoiding the problem of materials not being updated in a timely manner in traditional methods, effectively adapting to the meeting material management needs in paperless office scenarios.

[0029] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0030] In some embodiments, the meeting file synchronization method provided in this application can be applied to, for example... Figure 1 The conference file synchronization system shown includes a first terminal 101, a server 102, or a second terminal 103. Please refer to... Figure 1 The conference document synchronization system includes: a first terminal 101, a server 102, and a second terminal 103. The first terminal 101 and the second terminal 103 are respectively connected to the server 102.

[0031] The first terminal 101 is a client device for uploading meeting files, used to submit meeting files, target meeting identifiers, and meeting file synchronization strategies to the server 102. The first terminal 101 can be a personal computer (PC), laptop computer, mobile device, tablet computer, laptop computer, etc., and this application embodiment does not limit the specific form of the first terminal.

[0032] In some embodiments, the first terminal 101 sends a file storage request to the server 102. The file storage request includes at least one meeting file, an associated target meeting identifier, and a meeting file synchronization policy. The first terminal 101 is also used to receive file upload confirmation information returned by the server 102.

[0033] For example, the first terminal 101 selects meeting files through the management interface, sets meeting validity period, access permissions and other meeting file synchronization policies, and submits this information to the server 102.

[0034] Server 102 is the backend server for meeting file management and synchronization services. It is used to store meeting files, maintain the mapping relationship between meeting synchronization policies and meeting files, process synchronization requests from the second terminal 103, and control file distribution. It should be understood that server 102 can be a single server or a server cluster consisting of multiple servers. In some implementations, the server cluster can be a distributed cluster server. This application embodiment does not limit the specific form of the server.

[0035] In some embodiments, in response to receiving a file storage request from the first terminal 101, the server 102 stores the meeting files and related policy information, and establishes a mapping relationship between the target meeting identifier, the meeting file synchronization policy and the meeting files; the server 102 also responds to a file synchronization request from the second terminal 103, performs verification based on the associated meeting file synchronization policy, and sends the corresponding meeting files to the second terminal 103 after successful verification.

[0036] The second terminal 103 is a file-receiving terminal used by participants to obtain meeting files from the server 102 and automatically configure the local environment. The second terminal 103 can be a personal computer, laptop computer, mobile device, tablet computer, or laptop computer, etc. This application embodiment does not limit the specific form of the second terminal. Furthermore, the number of second terminals can be adjusted according to the scale of the meeting; this application does not limit the specific number of second terminals.

[0037] In some embodiments, the second terminal 103 sends a file synchronization request to the server 102, the request carrying a target meeting identifier; receives a response from the server 102 based on the verification result; and receives and stores the meeting file when the verification is successful. For example, the second terminal 103 selects the target meeting through the application and automatically completes file synchronization.

[0038] It should be noted that, Figure 1 An exemplary architecture consisting of a first terminal 101, a server 102, and a second terminal 103 is shown. In actual deployment, the number of each entity can be flexibly adjusted according to the meeting size and data load requirements. This application does not limit the specific number of each entity.

[0039] The meeting document synchronization method provided in this application will be described below with reference to specific embodiments and the accompanying drawings: Figure 2 This is a flowchart illustrating a meeting file synchronization method provided in an embodiment of this application. Figure 2 As shown, the meeting document synchronization method provided in this application embodiment can be applied to... Figure 1The server-side components of the meeting document synchronization system shown include S201-S205: S201. The server receives a file storage request sent by the first terminal. The file storage request includes at least one meeting file, the associated target meeting identifier, and the meeting file synchronization strategy.

[0040] The first terminal refers to a client device with the authority to establish a secure connection with the server and upload meeting files. Meeting files may include documents, presentations, or spreadsheets.

[0041] For example, the meeting host or meeting creator uploads meeting files using their personal computer or dedicated terminal device. Either the personal computer or the dedicated terminal device can serve as the primary terminal.

[0042] In one possible implementation, the first terminal needs to register and authorize with the server beforehand. For example, the user must first enter valid identity credentials (such as an account password or dynamic token) and pass the server's verification; only after a secure connection is successfully established will the server grant file upload permissions, allowing the user to submit file storage requests, thereby ensuring the security of meeting materials and the traceability of operations.

[0043] The associated target meeting identifier refers to the identity verification identifier of the current meeting corresponding to the meeting file that needs to be synchronized. This identifier is used to accurately locate the target meeting, ensure that the uploaded meeting files can be accurately distributed to the meeting space specified by the server, and respond to the file synchronization request of the second terminal in a timely manner, thereby avoiding the files being synchronized to the wrong meeting and ensuring the accuracy and order of meeting data management.

[0044] The target meeting identifier can be actively created and defined by the first terminal when preparing meeting materials. It adopts a coding rule with sufficient complexity and uniqueness to ensure that it can accurately distinguish different meeting scenarios. The target meeting identifier can take various forms, such as meeting number, unique link, or code containing date and topic.

[0045] For example, when a meeting host needs to upload and synchronize an agenda document to all participants, they can explicitly specify or select a unique identifier (such as a specific meeting ID or meeting number) corresponding to this meeting. Based on this target meeting identifier, the file can be accurately associated with the correct meeting name, preventing it from mistakenly appearing in the file lists of other meetings. For instance, a file named "Product Roadmap A.pdf" needs to be synchronized to the "First Quarter Product Review Meeting," which has a synchronization identifier (such as meeting number xxxx). During file upload, this identifier is affixed to the file like a label, establishing a correspondence between "Meeting xxxx" and the meeting file "Product Roadmap A.pdf." Subsequently, the server stores it in the designated meeting space based on this identifier. When a participant using a second terminal uses the meeting number xxxx to retrieve the meeting file, the server can accurately identify all files with the same label by recognizing this "tag" and provide them to the participant, ensuring that irrelevant files from other meetings are not mistakenly sent.

[0046] The meeting file synchronization strategy can be sent from the first terminal to the server, which will then verify subsequent file synchronization requests.

[0047] In one possible implementation, when the first terminal initiates a file storage request to the server, it includes the target meeting identifier and the meeting file synchronization policy as parameters in the request message. After receiving the file storage request, the server will first verify the validity of the identifier and the existence status of the corresponding meeting. Only after the verification is successful will the subsequent file storage and synchronization process continue, thereby eliminating the possibility of accidental file synchronization from the process perspective.

[0048] In one possible implementation, when the server receives a file synchronization request from the second terminal, it extracts the target meeting identifier carried in the request and queries the associated meeting file synchronization policy accordingly. Then, it makes a comprehensive judgment on the legality of the file synchronization request based on the rules defined in the meeting file synchronization policy.

[0049] In some implementations, the file storage request may also include the uploader's user identifier, the file's upload timestamp, and the file's metadata (such as file size, file type, version number, etc.). Upon receiving the file storage request, the server will first perform security checks and permission verification to confirm whether the first terminal has the authority to upload files to the target meeting. After successful verification, the server will not only store the meeting file's binary data in object storage or a file system, but also persist the file's metadata, associated meeting identifier, synchronization policy, and other relevant information as a record to the database, thereby constructing a complete, queryable, and manageable meeting file resource library.

[0050] In this embodiment, the server can simultaneously obtain the target meeting identifier and meeting file synchronization strategy at the initial stage of receiving meeting files, laying a precise and efficient foundation for subsequent file synchronization.

[0051] S202. The server responds to the file storage request by storing the meeting files, the target meeting identifier, and the meeting file synchronization policy, and establishes a mapping relationship between the target meeting identifier, the meeting file synchronization policy, and the meeting files.

[0052] In one possible implementation, the server's response is an automatically triggered process executed according to preset logic. For example, when the network interface receives a "file storage request" from the first terminal, the server immediately parses the request packet, extracts key fields, and then initiates a transactional processing flow. This flow includes, but is not limited to: identity authentication and permission verification (confirming whether the sender is a legitimate participant), request validity checks (such as whether the file is complete and whether the format is supported), and malicious attack detection (such as file virus scanning). Only after all these processing flows have successfully passed verification will the server execute the subsequent storage and mapping steps; if any step fails, the server will interrupt processing and return a response containing the specific error reason to the first terminal, such as "insufficient permissions" or "incorrect file format."

[0053] In one possible implementation, the server can employ a hierarchical and categorized approach to storage. For example, the binary data of the meeting files themselves is stored in an object storage service or distributed file system, generating a unique file ID or URL for internal access. Meanwhile, the target meeting identifier, meeting file synchronization strategy, file metadata (e.g., name, size, uploader, upload time), and pointers to the actual file storage location (i.e., the file ID generated in the previous step) are stored as a single record in a relational or document-oriented database (such as MySQL or MongoDB) table. By separating the binary data of the files from the different types of data, both the efficiency and cost of large-scale file storage are ensured, while leveraging the powerful query capabilities of the database for file management.

[0054] In one possible implementation, the mapping relationship between the target meeting identifier, the meeting file synchronization strategy, and the meeting files can be established in the database records through foreign key associations or embedded documents.

[0055] For example, in the data table storing different types of information in the above instance, several key fields would be designed, such as unique file identifiers, target meeting identifiers, file synchronization policies, and other related metadata. Through this table structure, each record can explicitly associate a meeting identifier with a synchronization policy and a specific file identifier. When the server needs to query all files corresponding to a particular meeting, it only needs to filter all matching records from the database based on the specified meeting identifier; and when the server needs to determine which synchronization policy should be used for a particular file, it can directly access the `sync_policy` field in that record.

[0056] For example, in a table named `meeting_files`, the following key fields can be set: `file_id` (primary key, storing a unique identifier for the file), `meeting_id` (identifying the meeting to which it belongs), `sync_policy` (file synchronization policy), and other metadata fields. Assuming there is a record `{file_id:"F001",meeting_id:"M123",sync_policy:"AUTO_SYNC"}`, it means that file "F001" belongs to meeting "M123", and its synchronization policy is "AUTO_SYNC". Based on this structure, the server can retrieve all files under meeting "M123" by executing a query; the server can then read the `sync_policy` field from the record corresponding to `file_id="F001"` to obtain and execute the synchronization policy for that file.

[0057] In one possible implementation, the server will first check the meeting file uploaded by the first terminal to see if it is a new file that has been modified. Then, depending on whether the meeting file is new or old, the server will perform corresponding operations, namely, storing the meeting file, the target meeting identifier, and the meeting file synchronization policy, and establishing a mapping relationship between these three.

[0058] For example, the server can determine whether the meeting file uploaded by the first terminal is a new file by comparing the content fingerprint (such as SHA-256 hash value) of the meeting file.

[0059] For example, when the server responds to a file storage request and the calculated file hash value does not exist globally on the server, it determines that the meeting file is a brand new file. At this point, the server executes the standard storage process: it uploads the file's binary data as a new object to object storage, generates a unique file identifier, and updates the database with the target meeting identifier, meeting file synchronization policy, and this new file identifier as a new record, thus establishing a complete mapping relationship. This approach ensures the uniqueness of file content, avoids duplicate storage, and lays the foundation for subsequent file deduplication and accelerated distribution.

[0060] For example, when the server identifies through content fingerprinting that the file to be stored already exists in the system (i.e., it is an "old" file or a duplicate file), a "storage optimization" strategy is adopted. The server will not store the file's binary data again, but will directly reuse the existing file object and its `file_id`. Subsequently, a new mapping record will be created in the database, associating the new target meeting identifier and the specific meeting file synchronization strategy in this request with this existing `file_id`. This method saves valuable storage space and network bandwidth while ensuring that different meetings or different file references within the same meeting can independently manage their synchronization strategies.

[0061] S203. The server receives a file synchronization request sent by the second terminal, which carries the target meeting identifier.

[0062] In one possible implementation, the server receiving file synchronization requests sent by the second terminal can rely on the server's network communication module continuously listening to specific network ports and protocols.

[0063] Different ports correspond to different services or functions. Listening to a specific port allows the server to accurately identify file synchronization requests sent to the second terminal. The protocol is the rule agreed upon by the two communicating parties (such as data format, transmission method, etc.). Listening according to a specific protocol can ensure that the server correctly parses the information in the request.

[0064] For example, when a second terminal (such as a participant's computer or mobile application) sends a data packet containing a "file synchronization request" to the server's interface address via a network (such as HTTP, WebSocket, or a persistent TCP connection), the server first parses this request. This process includes verifying the data format, checking the legitimacy of the network connection, and then extracting key information from the received data stream or data packet according to a predefined protocol format (such as JSON, XML, or Protobuf), which includes the "file synchronization request" instruction and the data it carries.

[0065] The target meeting identifier enables the server to accurately and quickly locate all files belonging to that meeting from a massive amount of file records.

[0066] For example, when the server receives a synchronization request from the second terminal for the meeting "project_kickoff_2024", it will immediately use the target meeting identifier to execute a query (e.g., SELECT * FROM meeting_files WHERE meeting_id = 'project_kickoff_2024'), thereby accurately returning all file records under that meeting (such as product requirement documents, UI design drafts, meeting minutes, etc.) without having to traverse the entire file repository.

[0067] This application embodiment processes file synchronization requests based on a target meeting identifier on the server side, which can directly and accurately locate the specific meeting scenario corresponding to the identifier, avoiding confusion or range deviation of the synchronization object due to the lack of a clear scenario.

[0068] S204. The server responds to the file synchronization request, obtains the meeting file synchronization policy corresponding to the target meeting identifier, and verifies the file synchronization request based on the meeting file synchronization policy.

[0069] The meeting document synchronization strategy includes the meeting validity period.

[0070] In one possible implementation, after successfully receiving and parsing the file synchronization request from the second terminal, the server formally enters the response processing flow. This response does not immediately return the file data; instead, it initiates a business logic process that includes policy verification. The server first uses the target meeting identifier carried in the request to find and apply the corresponding rules to determine whether the synchronization request is permitted. This process ensures that all file synchronization operations are performed under the control of preset policies, and is a crucial step in guaranteeing the security and data compliance of meeting file synchronization.

[0071] In one possible implementation, the server obtains the corresponding meeting file synchronization strategy by using the target meeting identifier as a key condition for database queries.

[0072] For example, the server retrieves the specific configuration of the meeting synchronization policy by querying the database. When it needs to determine the synchronization rules for a particular meeting, the system sends a query request to the data table storing meeting metadata and retrieves the corresponding policy configuration field based on the target meeting identifier. This field is typically stored in a structured data format and fully defines the various control parameters for file synchronization. For instance, after obtaining the policy data through the database query, the system can parse configuration information containing key parameters such as the meeting validity period and automatic synchronization switch. The meeting validity period serves as an important basis for determining whether the synchronization request is compliant.

[0073] In one possible implementation, when the meeting file synchronization policy includes a meeting expiration period, the server compares the current system time with the expiration date specified in the policy. If the current time has exceeded the expiration date, the verification fails, the server rejects the synchronization request, and typically returns a clear error message informing the client that "the meeting has ended and the file cannot be synchronized."

[0074] For example, when the server receives a file synchronization request for the meeting "2024Q3 Product Planning Meeting" (ID: Q3_2024_Product_Summit), it will immediately query the synchronization policy of the meeting to obtain the policy configuration, including the meeting validity period "2024-06-30T23:59:59". During verification, if the server finds that the current time (July 15, 2024) has exceeded the validity period, it will immediately reject the synchronization request and return an error message "The meeting has ended and the file synchronization service has stopped" to the requesting terminal.

[0075] In some embodiments, the meeting file synchronization policy also includes a user permission list; the server verifies the file synchronization request based on the meeting file synchronization policy, including: verifying whether the user identity of the second terminal is in the user permission list, and whether the time of the file synchronization request is within the meeting validity period.

[0076] A user permission list is a predefined collection of authorized user identifiers (such as User IDs or roles) that are bound to a specific meeting identifier. It is used to precisely control which users have the right to access or synchronize files for the meeting.

[0077] For example, the meeting file synchronization policy further includes a user permission list, which specifies the set of users authorized to synchronize meeting files. The server first needs to verify whether the currently logged-in user's identity (such as a User ID) on the second terminal is within this user permission list to confirm their access rights. Based on this, it also verifies whether the file synchronization request is made within the meeting's validity period. Verification will only pass if both conditions are met, ensuring that file access is controlled by user identity and limited by the meeting's time window.

[0078] In another possible implementation, upon receiving a file synchronization request, the server immediately queries the corresponding meeting file policy based on the target meeting identifier carried in the request. This policy includes not only the meeting validity period and user identity but also geographical location. For example, the server can determine whether the second terminal is in the meeting room via the local area network it is connected to; file downloads are only permitted if the terminal is in the meeting room.

[0079] For example, when the server receives a synchronization request, it extracts and analyzes the network connection characteristics traversed by the request, such as the wireless network service set identifier (i.e., Wi-Fi name SSID) accessed by the terminal, the IP address range assigned by the router, or the physical address (MAC address) of the network gateway. The server compares these real-time network characteristics with the network information of legitimate meeting rooms pre-registered for the meeting. Only when all characteristics match successfully does the server determine that the second terminal is in a trusted physical space (i.e., the meeting room) and authorize it to download confidential files.

[0080] In this embodiment, the server first obtains the synchronization policy corresponding to the target meeting identifier, and then verifies the file synchronization request according to the policy. It can accurately filter requests based on the validity period of the meeting file, avoiding invalid requests that are not for the corresponding meeting or have exceeded the validity period from wasting resources. At the same time, by incorporating the meeting validity period into the verification dimension, it can automatically intercept synchronization operations initiated after the meeting has expired, ensuring that file synchronization is only performed within a reasonable meeting cycle. This not only guarantees the timeliness and compliance of meeting file synchronization, but also reduces the server processing pressure and data management risks caused by invalid synchronization from the source.

[0081] S205. If the time of the file synchronization request is within the validity period of the meeting, the server sends the meeting file corresponding to the target meeting identifier to the second terminal based on the mapping relationship.

[0082] For example, when the server verifies that the file synchronization request time is within the meeting's validity period, it will immediately send the corresponding meeting files to the second terminal based on the established mapping relationship. For instance, after confirming that the current time (May 20, 2024) is earlier than the validity period of the meeting "2024Q2 Technical Review Meeting" (May 31, 2024), the server will then locate all files associated with that meeting ID (including technical solution documents, test reports, and meeting minutes) by querying the mapping relationship in the database, and package the download link list or file data stream of these files, returning them to the requesting second terminal (such as a participant's laptop) via HTTP / HTTPS protocol, thus completing the real-time file synchronization.

[0083] In one possible implementation, the meeting files support multiple file configurations, and each meeting file is associated with the permission system of the participants. When a second terminal initiates a meeting file download request, the server first verifies the permission information of the participants bound to the second terminal, and then pushes the meeting files within the corresponding permission range to the second terminal based on permission matching rules, ultimately achieving a precise correspondence between the participants' permissions and the meeting files they can access.

[0084] For example, there is a clear distinction in the scope of document access for participants at different levels. From a management perspective, the general manager, who has the highest decision-making authority, can access all meeting documents, including the meeting agenda, core data, draft decisions, and risk assessment reports, to support overall decision-making. Department heads, on the other hand, can only access documents directly related to their department's business, such as departmental reports and cross-departmental collaboration documents, satisfying their business needs while preventing the leakage of irrelevant information. From a functional perspective, technical participants can access professional documents such as technical solutions and system architecture diagrams, while administrative participants primarily access administrative documents such as meeting notices, attendance sheets, and logistical support plans. Furthermore, for external partners or consultants who attend temporarily, the system will configure temporary permissions, granting access only to specific documents related to the collaboration, and automatically revoking permissions after the meeting, further ensuring the security and confidentiality of meeting information.

[0085] In some embodiments, the server triggers a deletion operation on the meeting file when the cleanup conditions associated with the target meeting identifier are met; wherein, meeting the cleanup conditions associated with the target meeting identifier includes at least one of the following: the meeting validity period has expired, or a cleanup instruction has been received from the first terminal.

[0086] For example, the server will set up an automatic cleanup mechanism associated with the target meeting identifier, triggering the deletion of meeting files when certain conditions are met, in order to free up storage space and manage the data lifecycle. These cleanup conditions include, but are not limited to, the following: First, the server detects that the current time has exceeded the meeting validity period defined in the meeting policy, such as automatically cleaning up all related files 7 days after the meeting ends; Second, the server receives a forced cleanup instruction initiated by the meeting creator or administrator (first terminal), such as the project manager manually triggering immediate cleanup after the project is completed.

[0087] In one possible implementation, the server can trigger the deletion operation through a separate background task scheduler. This scheduler periodically scans the database, searching for meeting records that meet any of the aforementioned cleanup conditions. Once a target meeting is identified, the scheduler first calls the file service interface and, based on the mapping relationship between the target meeting identifier and the storage path in the database, initiates a batch deletion request to the object storage system to remove the physical files. Subsequently, it executes a database transaction to delete all file metadata records associated with that meeting identifier, thereby ensuring that meeting files are completely and consistently cleaned up and guaranteeing the security of the meeting file synchronization process.

[0088] In one possible implementation, the cleanup conditions associated with the target meeting identifier may also include server-side storage quota, session activity, etc.

[0089] For example, when the server detects that the storage space allocated for a meeting associated with the target meeting identifier is about to run out, it can automatically trigger the cleanup of the oldest uploaded or marked "temporary" files to release quota; if the server detects that a meeting has not had any user access or synchronization behavior for a long period of time during its validity period (i.e., the session activity is extremely low), it can determine that its files are no longer valuable and start the automatic archiving or deletion process.

[0090] In some embodiments, the server triggers the deletion of meeting files when it detects that all terminals in the user permission list have completed file synchronization. For example, by monitoring and recording, the server can determine whether all authorized users or terminals in the user permission list have successfully completed file synchronization. Once it detects that all terminals in the list have completed file synchronization, the server can trigger the deletion of the meeting files, thus ensuring both information delivery and timely reclamation of storage resources.

[0091] For example, the server determines completion status by maintaining a synchronization status record for each user-file pair in the database. When a second terminal successfully downloads a file and sends a confirmation receipt to the server, the server marks the synchronization status of that user for that file as "completed." By periodically querying the database to verify whether all users in the permission list have marked all files under the meeting as "completed," if so, it is determined that all file synchronization is complete, and the server can then trigger the deletion operation of the meeting files.

[0092] This application also provides a method for synchronizing meeting files, applicable to, for example... Figure 1 The second terminal in the conference document synchronization system shown in this application embodiment does not impose any restrictions on the specific form of the second terminal. For example, the second terminal can be a personal computer, laptop computer, mobile device, tablet computer, laptop computer, etc. This application embodiment does not limit the specific form of the second terminal. In actual deployment, the number of second terminals can be flexibly adjusted according to the conference scale and data load requirements. This application does not limit the specific number of second terminals.

[0093] Figure 3 This is a flowchart illustrating another method for synchronizing meeting documents provided in an embodiment of this application. Figure 3 As shown, another method for synchronizing meeting documents provided in this application embodiment specifically includes steps S301-S303: S301. The second terminal sends a file synchronization request to the server, and the file synchronization request carries the target meeting identifier.

[0094] The second terminal refers to the client terminal device that initiates a file synchronization request to the server to obtain meeting files during the meeting file synchronization process. Operated by the participants, it serves as both the receiving and user end of the meeting files. Examples include personal laptops used by participants to view synchronized documents and take notes during the meeting; smartphones or tablets for quick access to meeting files while on the go or at the meeting venue; dedicated meeting terminal equipment provided by the company, such as a smart display screen in the conference room, which can directly synchronize files for multiple people to view simultaneously; and desktop computers used for professional office work, suitable for in-depth editing or long-term storage of synchronized meeting files.

[0095] In one possible implementation, the second terminal can send a file synchronization request by calling a pre-defined server-side API interface. For example, the second terminal first encodes and serializes parameters such as the target meeting identifier, terminal information, and timestamp locally, and attaches a digital signature to prevent request tampering; then, it sends the encapsulated request data packet to the synchronization interface specified by the server via the HTTPS protocol, while simultaneously monitoring the network connection health in real time to ensure the reliability of the communication link.

[0096] For example, the second terminal constructs a standard data request that explicitly includes key information such as the target meeting identifier, the local device fingerprint, and the required file synchronization range. This request is sent to the server's designated address via a secure network connection, with an additional signature generated by an encryption algorithm attached to verify the request's legitimacy on the server side. For instance, the second terminal constructs a JSON request body containing the meeting identifier `meeting_id="DESIGN_REVIEW_2024Q4"`, the device fingerprint `device_fingerprint`, and the synchronization range parameter `sync_scope`, and sends it via the POST method to `https: / / api.company.com / v2 / sync / meeting_files`, including an encrypted Request-Signature in the header for authentication.

[0097] S302, The second terminal receives the response returned by the server based on the file synchronization request.

[0098] The response is issued by the server after verifying the file synchronization request according to the meeting file synchronization policy corresponding to the target meeting identifier. The meeting file synchronization policy includes the meeting validity period.

[0099] In one possible implementation, after the second terminal verifies the request based on the synchronization strategy, it uses the HTTP status code to characterize the request status and transmits structured data such as synchronization mode, file list or error details through the response body to determine the current response status.

[0100] For example, HTTP status codes are carried in communication responses and can be used to determine the response result. These status codes use three digits to immediately inform the client of the processing result of their request: 1xx indicates the request has been received and needs further processing; 2xx indicates the request was successful (e.g., 200 OK); 3xx indicates a redirection operation is required; 4xx indicates a client request error (e.g., 404 Resource Not Found); and 5xx indicates a server malfunction during request processing (e.g., 500 Internal Server Error).

[0101] For example, after receiving an HTTP status code 200 response, the second terminal parses the response body {"status":"SUCCESS","sync_mode":"INCREMENTAL","files":[{"file_id":"F_003","version":"v3"}]}, indicating that the server has successfully verified its file synchronization request and is ready to provide the latest list of meeting files using incremental synchronization mode. The second terminal can then securely begin downloading the meeting files. If an HTTP status code 403 is received, the response body {"status":"EXPIRED","effective_time":"2024-05-20"} is parsed, indicating that its synchronization request was rejected by the server because the target meeting has expired, and its request permission has expired. The second terminal should stop the synchronization process and display a clear error message to the user. Simultaneously, the second terminal will also verify the digital signature of the response data to ensure data integrity.

[0102] S303. If the file synchronization request time is within the meeting validity period, the second terminal recognizes the response as successful verification and stores the meeting file corresponding to the target meeting identifier returned by the storage server.

[0103] After the server verifies that the current time is within the meeting validity period, the second terminal receives a "verification successful" response and the corresponding meeting file. After recognizing the successful response, the second terminal will automatically store the received meeting file that matches the target meeting identifier locally.

[0104] In one possible implementation, the second terminal first parses the conference file from the success response, starts the segmented download method to acquire file blocks according to a preset number of concurrent processes, and finally writes the file to local storage after verifying its integrity.

[0105] For example, when the PPT file information returned in the response (including the file download address and the hash value calculated using the SHA-256 algorithm), the second terminal first creates a chunked download task, dividing the file into several fixed-size data blocks (e.g., each chunk is 4MB) for transmission. After all chunks are downloaded, the data integrity is verified by comparing the hash value of the received file with the original hash value provided by the server. After successful verification, the second terminal decrypts the encrypted file and stores it in a dedicated directory named after the target meeting identifier in the local conference file system. Finally, the local file index database is updated synchronously to record the latest status of the file.

[0106] In one possible implementation, the second terminal first performs deep parsing of the structured file metadata returned by the server, accurately obtaining important parameters such as the download address, fragment size, SHA-256 verification hash, and encryption key for each file. Then, the terminal's download engine creates multiple concurrent download threads based on the fragmentation strategy, initiating fragment download tasks with byte-range requests to distributed CDN nodes, and receiving the returned encrypted data fragments in real time. During data reception, the second terminal performs real-time verification on each fragment to ensure transmission integrity. After all fragments are received, the file is reassembled in order, and the overall file hash value is compared for final integrity verification. Upon successful verification, the obtained decryption key is used to decrypt the reassembled encrypted file, restoring the original file content, and securely writing it to the designated meeting directory in the second terminal's local storage system. Finally, the second terminal's file management system updates the local file index database, accurately recording the file's storage path, synchronization timestamp, and version information, establishing a complete meeting-file mapping relationship. Through the process of network acquisition, secure transmission, decryption verification, and local storage, users can efficiently and securely access the required meeting files.

[0107] In some embodiments, if the second terminal detects that the response is a verification failure and the reason for rejection is that the current time is not within the validity period of the meeting, it displays the corresponding error message.

[0108] In one possible implementation, when the second terminal detects that the server's response indicates a verification failure, and determines the reason for rejection as "meeting validity period expired" or a similar expression (e.g., MEETING_EXPIRED) by parsing the error code or error message field, the second terminal triggers specific error handling logic. This logic displays a user-friendly error message at the user interface level that precisely corresponds to this reason. This message not only clearly informs the user that the synchronization failure is due to the meeting ending, but may also provide supplementary information such as the meeting's validity period and suggestions to contact the meeting organizer, thus guiding the user through subsequent operations, rather than simply displaying a general failure message.

[0109] For example, after the conferencing application on the second terminal parses the HTTP 403 status code and response body {"code": "MEETING_EXPIRED", "message": "Meeting has ended", "effective_until":"2024-05-20T18:00:00Z"} returned by the server, a customized prompt box will pop up on its graphical interface. The content may be: "Synchronization failed: The meeting you tried to access ended at 18:00 on May 20, 2024, and the file synchronization service has been automatically closed. To obtain meeting materials, please contact the meeting host." This concrete error message greatly improves the clarity and user-friendliness of the user experience.

[0110] In another possible implementation, when the second terminal recognizes that the response returned by the server is a verification failure, it will trigger a unified error handling mechanism and display the corresponding precise error message on the user interface based on the specific rejection reason carried in the response.

[0111] For example, this mechanism achieves precise prompts through a predefined error code mapping table. When the terminal parses the response and identifies the failure status, it immediately queries the mapping table to obtain the user-friendly prompt text corresponding to the specific error code and displays it to the user.

[0112] For example, if the reason for rejection is MEETING_EXPIRED (meeting expired), the message "Meeting has ended, file synchronization service is closed" will be displayed; if the reason is PERMISSION_DENIED (insufficient permissions), the message "You do not have permission to access the files for this meeting" will be displayed; if the reason is NETWORK_ERROR (network error), the message "Network connection error, please check and try again" will be displayed. This design ensures that users receive clear instructions regardless of the reason for the failure, thus significantly improving the user experience.

[0113] In some embodiments, the second terminal deletes the locally stored meeting file upon detecting a predefined meeting end event; wherein the meeting end event includes at least one of the following: detecting a user's trigger operation on the end meeting control, detecting that the meeting validity period has expired, or detecting that the connection with the meeting LAN has been lost.

[0114] Specifically, the second terminal detecting a user's triggering of the "End Meeting" control means that the second terminal, through an event listener, captures the user's active interaction with specific UI elements in the graphical interface (such as the "End Meeting," "Leave Meeting," or "Exit" buttons). This action is considered an explicit instruction from the user to clearly end the current meeting session, and to ensure the security of the meeting files, the locally stored meeting files will be deleted.

[0115] The second terminal detecting that the meeting validity period has expired means that the second terminal compares its system clock with the meeting validity period timestamp obtained from the server and stored locally, and finds that the current system time has exceeded the expiration time. If this condition is met, it indicates that the meeting has officially ended in terms of time, and to ensure the security of the meeting files, the locally stored meeting files will be deleted.

[0116] The second terminal detecting a disconnection from the conference LAN means that the second terminal, through its operating system API, continuously monitors the connection status of its terminal to a specific network identifier representing the conference's physical environment (such as a Wi-Fi network with a specific SSID), and the connection status changes from "connected" to "disconnected," failing to automatically reconnect within a preset timeout window. This event is identified as the user leaving the main physical venue of the conference, and to ensure the security of the conference files, the locally stored conference files will be deleted.

[0117] For example, the second terminal, through an event listening mechanism, automatically executes a local meeting file cleanup task when it detects that one of the predefined meeting end events has been triggered. The logic for determining the meeting end event includes, but is not limited to, the following dimensions: the terminal interface captures an explicit triggering operation of the "End Meeting" or "Exit Meeting" control by the user; the terminal service detects that the meeting validity period has expired by comparing the terminal system time with policy data; and the network management layer detects that the continuous connection between the device and the dedicated meeting LAN (such as enterprise meeting Wi-Fi) has been disconnected. The event listening mechanism is used to enable the second terminal to respond to specific events (such as user operations, system status changes, message arrivals, etc.).

[0118] For example, the local file cleanup service will be activated if a user actively clicks the "Leave Meeting" button in the meeting application (the corresponding control triggers the operation), the terminal detects that the system time has exceeded the valid_until timestamp set in the meeting policy (corresponding to the validity period expiring), or the device leaves the meeting room area, causing the Wi-Fi connection with SSID ConfRoom_501 to be lost for more than 5 minutes (corresponding to network disconnection). This service will locate and securely delete all local cache files and temporary data belonging to the meeting based on the meeting identifier meeting_id, while updating the local file index to ensure that sensitive information is not leaked and storage space is released in a timely manner.

[0119] In some embodiments, the second terminal receives personalized settings input by the user, calls the operating system interface of the second terminal, and configures the operating system desktop environment where the synchronized meeting files are located.

[0120] Personalized settings revolve around user operating habits and file management needs, and may include at least one of the following: desktop display and quick operations, storage path and management, permissions and access control, and linked reminders and operations.

[0121] For example, users can configure as needed whether to create desktop shortcuts and custom icons for synchronized files, group files by meeting time or type, and even add desktop widgets to preview key information; they can also manually specify file storage paths, set automatic backup rules and expiration cleanup intervals to avoid occupying too much terminal storage; they can also set local access permissions via password or biometrics, preset file sharing scope, and ensure information security; and they can also configure file opening reminders before the meeting starts and customize the default application for opening files.

[0122] In one possible implementation, after the second terminal completes the synchronization of meeting files, it can receive and execute personalized settings input by the user. By calling the native API provided by the operating system, it can dynamically configure the desktop environment where the synchronized meeting files are located, thereby realizing the combination of meeting content and user work scenario.

[0123] For example, a graphical settings interface receives user commands and translates them into specific system call commands to change the desktop environment. For instance, after a product design review meeting, a user can use the meeting application's personalization settings to set the synchronized "final product panorama.jpg" as their desktop wallpaper. The system will then automatically call the operating system interface: in Windows, it modifies the desktop background path using system parameter configuration functions; in macOS, it updates the desktop and screensaver settings using script commands; and in the Linux GNOME desktop, it modifies the background image parameters using configuration tools, ultimately integrating the meeting results directly into the user's work environment.

[0124] As can be seen from steps S301-S303, the alternative meeting document synchronization method provided in this application allows the second terminal to accurately initiate meeting document synchronization requests. The timeliness and legality of obtaining the documents are ensured through server-side policy verification, which avoids invalid requests and enables the rapid acquisition of compliant meeting documents. At the same time, the personalized settings after document synchronization further improve the terminal-side management process of meeting documents in paperless office scenarios, and enhance the convenience and security of meeting participants in obtaining meeting materials.

[0125] For example, such as Figure 4 As shown, an embodiment of a meeting file synchronization method is given in conjunction with the above embodiments. Figure 4 A flowchart illustrating a meeting document synchronization method provided in this application embodiment. Figure 1 .

[0126] The process begins with the following steps: Step 1: The person preparing the meeting materials uploads files to the file server from the first terminal. The first terminal also has the function of sending file deletion requests. Step 2: The file server sets user access permissions; if not, the process will restart. Step 3: The meeting assistant operates the second terminal. First, the user enters their username and password for authentication. The second terminal determines whether the authentication was successful based on the local area network. If not, the user returns to the second terminal to enter their username and password again for authentication. If successful, the file server is accessed to retrieve the files. The second terminal determines whether the file retrieval was successful. If successful, the file position, sorting, and desktop background are adjusted, and logs are recorded. If not, the logs are directly output. The meeting assistant can also destroy meeting files, after which logs will be output.

[0127] For example, such as Figure 5 As shown, a detailed flowchart of a meeting file synchronization method is given in conjunction with the above embodiments. Figure 5 A flowchart illustrating a meeting document synchronization method provided in this application embodiment. Figure 2 .

[0128] S1. The first terminal enters its account and password to log in to the server.

[0129] S2. The first terminal failed to log in, and the server returned information to the first terminal.

[0130] S3. The first terminal has successfully logged in and uploaded the meeting files to the server.

[0131] S4. The first terminal failed to upload, and the server sent an error message to the first terminal.

[0132] S5, the second terminal can perform file backup operations and clean up old files.

[0133] S6. The second terminal enters its username and password to authenticate and log in to the server.

[0134] S7. The second terminal verification failed, and the server returned information to the second terminal.

[0135] S8. The second terminal successfully verifies the data and sends a file synchronization request to the server, establishing a communication connection.

[0136] S9. If the communication connection fails to be established, the server returns information to the second terminal.

[0137] S10. After the communication connection is successfully established, the second terminal initiates a request to obtain file list information from the server.

[0138] S11. The server returns a file list to the second terminal.

[0139] S12. The second terminal initiates a request to obtain a file stream, and the server returns the file stream. Finally, the second terminal writes the file stream to a local file.

[0140] S13. Set the local device background file on the second terminal.

[0141] S14. The first terminal sends a file deletion request to the server.

[0142] S15. The server successfully deleted the file and returned a message.

[0143] In this embodiment, the user first logs into the server on the first terminal using their account and password. After successful verification, they can upload meeting files according to system rules. If the upload fails, a retry is prompted. The meeting assistant on the second terminal uses a meeting file synchronization program to perform operations such as backing up files, cleaning up old files, and setting a default background. They then verify their identity using their username and password and establish a secure connection with the server. Connection failures or verification failures are displayed with relevant information. After successful verification, the meeting assistant on the second terminal selects the meeting category and personalized settings, initiates a file synchronization request, and the second terminal sequentially obtains the file list and corresponding file streams. Finally, the files are stored on the second terminal, and the desktop background and file sorting are updated according to the settings. Furthermore, the user can also initiate a request to delete files on the server, which executes the deletion and returns the result. This method automates the management of meeting files from uploading and synchronization to terminal display and cleanup, ensuring the security and reliability of file access, improving the efficiency of meeting material distribution, and enhancing the uniformity and cleanliness of the terminal desktop, effectively supporting the efficient conduct of paperless meetings.

[0144] This application also provides a meeting file synchronization device, which may include one or more functional modules for implementing the meeting file synchronization method of the above method embodiments.

[0145] In an exemplary embodiment, this application also provides a meeting document synchronization device. Figure 6This is a schematic diagram of a meeting file synchronization device provided in an embodiment of this application. The device is applied to a server and includes a first receiving module 601, a first storage module 602, a verification module 603, and a first sending module 604. The first receiving module 601 is specifically used to: receive a file storage request sent by a first terminal, the file storage request including at least one meeting file, an associated target meeting identifier, and a meeting file synchronization policy; the first storage module 602 is specifically used to: in response to the file storage request, store the meeting file, the target meeting identifier, and the meeting file synchronization policy, and establish a mapping relationship between the target meeting identifier, the meeting file synchronization policy, and the meeting file; the first receiving module 601 is specifically used to: receive a file synchronization request sent by a second terminal, the file synchronization request carrying the target meeting identifier; the verification module 603 is specifically used to: in response to the file synchronization request, obtain the meeting file synchronization policy corresponding to the target meeting identifier, and verify the file synchronization request based on the meeting file synchronization policy; wherein, the meeting file synchronization policy includes a meeting validity period; the first sending module 604 is specifically used to: when the time of the file synchronization request is within the meeting validity period, send the meeting file corresponding to the target meeting identifier to the second terminal based on the mapping relationship.

[0146] In an exemplary embodiment, this application also provides another meeting document synchronization device. Figure 7 This is a schematic diagram of another conference file synchronization device provided in an embodiment of this application. The device is applied to a second terminal and includes a second sending module 701, a second receiving module 702, and a second storage module 703. The second sending module 701 is specifically used to: send a file synchronization request to the server, the file synchronization request carrying a target conference identifier; the second receiving module 702 is specifically used to: receive a response returned by the server based on the file synchronization request; wherein the response is issued by the server after verifying the file synchronization request according to the conference file synchronization policy corresponding to the target conference identifier, the conference file synchronization policy including the conference validity period; the second storage module 703 is specifically used to: if the time of the file synchronization request is within the conference validity period, recognize that the response is a successful verification, and store the conference file returned by the server corresponding to the target conference identifier.

[0147] This application also provides an electronic device, which may be a first terminal, a second terminal, or a server. Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application, such as... Figure 8 As shown, the electronic device includes a processor 801 and a memory 802; the memory 802 stores instructions executable by the processor 801; when the processor 801 is configured to execute the instructions, the electronic device implements the method described in the foregoing method embodiments.

[0148] This application also provides a computer-readable storage medium storing computer program instructions thereon; when the computer program instructions are executed by a computer, the computer causes the computer to implement the methods described in the foregoing embodiments. The computer may be an electronic device, a network device, or a manager. The computer-readable storage medium may be a non-transitory computer-readable storage medium, such as a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0149] This application also provides a computer program product that, when run on a computer, causes the computer to execute the relevant method steps described in the above method embodiments.

[0150] The electronic devices, computer-readable storage media, or computer program products provided in this application are all used to execute the corresponding methods provided above. Therefore, the beneficial effects they can achieve can be referred to the beneficial effects in the corresponding methods provided above, and will not be repeated here.

[0151] Through the above description of the embodiments, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0152] In the several embodiments provided in this application, it should be understood that the disclosed apparatus 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 apparatus, or some features may be ignored or not executed. Furthermore, the mutual 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.

[0153] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0154] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0155] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods of 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, ROM, RAM, magnetic disks, or optical disks.

[0156] In the description of the embodiments of this application, specific features, structures, materials or characteristics may be combined in any suitable manner in one or more embodiments or examples.

[0157] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method of synchronizing conference documents, characterized by, Applied to a server, the method comprises: Receiving a file storage request sent by a first terminal, the file storage request comprising at least one conference file, an associated target conference identifier, and a conference file synchronization strategy; In response to the file storage request, storing the conference file, the target conference identifier, and the conference file synchronization strategy, and establishing a mapping relationship between the target conference identifier, the conference file synchronization strategy, and the conference file; Receiving a file synchronization request sent by a second terminal, the file synchronization request carrying the target conference identifier; In response to the file synchronization request, obtaining the conference file synchronization strategy corresponding to the target conference identifier, and verifying the file synchronization request based on the conference file synchronization strategy; wherein the conference file synchronization strategy comprises a conference validity period; If the time of the file synchronization request is within the conference validity period, based on the mapping relationship, sending the conference file corresponding to the target conference identifier to the second terminal.

2. The method of claim 1, wherein, The method further comprises: When a cleaning condition associated with the target conference identifier is met, triggering a deletion operation on the conference file; Wherein, the cleaning condition associated with the target conference identifier comprises at least one of the following: the conference validity period has expired, a cleaning instruction is received from the first terminal.

3. The method of claim 1, wherein, The conference file synchronization strategy further comprises a user permission list; Verifying the file synchronization request based on the conference file synchronization strategy comprises: Verifying whether the user identity of the second terminal is located in the user permission list and whether the time of the file synchronization request is within the conference validity period.

4. The method of claim 3, wherein, The method further comprises: When it is monitored that all terminals in the user permission list have completed file synchronization, triggering a deletion operation on the conference file.

5. A method of synchronizing conference documents, characterized by, Applied to a second terminal, the method comprises: Sending a file synchronization request to a server, the file synchronization request carrying a target conference identifier; Receiving a response returned by the server based on the file synchronization request; wherein the response is sent by the server after verifying the file synchronization request according to a conference file synchronization strategy corresponding to the target conference identifier, and the conference file synchronization strategy comprises a conference validity period; If the time of the file synchronization request is within the conference validity period, it is identified that the response is a verification success, and the conference file corresponding to the target conference identifier returned by the server is stored.

6. The method of claim 5, wherein, The method further comprises: In the case of detecting a predefined conference end event, deleting the locally stored conference file; wherein the conference end event comprises at least one of the following: detecting a user's triggering operation on an end conference control, detecting that the conference validity period has expired, and detecting that the connection with the conference local area network is disconnected.

7. The method of claim 5, wherein, The method further comprises: Receiving a user inputted individualized setting, calling an operating system interface of the second terminal, and configuring an operating system desktop environment where the conference file has been synchronized.

8. The method of claim 5, wherein, The method further comprises: In a case where it is identified that the response is a verification failure and the rejection reason is that the current time is not within a valid period of the conference, corresponding error prompt information is displayed.

9. An electronic device, comprising: The electronic device includes a processor and a memory; The memory stores instructions executable by the processor; The processor is configured to execute the instructions, so that the controller implements the method of any one of claims 1-4 or 5-8.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium includes computer software instructions; When the computer software instructions run in the electronic device, the electronic device implements the method of any one of claims 1-4 or 5-8.

Images