Calendar information sharing method for sharing and synchronously storing schedules by multiple persons in family

Abstract

The invention discloses a method for sharing calendar information according to a synchronous storage schedule shared by multiple persons in a family, and relates to the field of calendars. The method comprises the following steps: storing schedule information in a server, wherein the schedule information comprises a participant list, a visible person list and creator information; the method comprises the following steps: acquiring schedule data of a third-party calendar in a client through an application programming interface provided by the third-party calendar, synchronizing a schedule of the third-party calendar to a server, and storing associated data related to the third-party calendar by the server; and according to the visible person list, sharing the synchronized third-party calendar schedule to a client of a corresponding family member, and carrying out permission limitation on a modification operation of the synchronized third-party calendar schedule based on creator identity information, fine-grained permission configuration information and a third-party log association identifier. Seamless sharing and intelligent pushing of the third-party calendar in a multi-person cross-time-zone scene are realized.

Description

Technical Field

[0001] This invention relates to the field of calendars, and more particularly to a method for sharing calendar information that allows multiple family members to synchronously store their schedules. Background Technology

[0002] In modern family life, each member's schedule is becoming increasingly complex, and traditional communication methods are insufficient for effective coordination, easily leading to planning conflicts. Therefore, families urgently need a shared calendar tool that can uniformly manage various tasks and support real-time collaboration among multiple people, serving as the family's time hub to improve coordination efficiency and ensure the orderly continuation of life.

[0003] Currently, these shared calendar applications (such as TimeTree) primarily achieve sharing by centrally storing schedule data on a server, with each member client synchronously pulling and displaying the data through an API. Additionally, to integrate external schedules, the application utilizes official APIs provided by Google Calendar, Apple Calendar, and others to directly obtain data from the user's local calendar on their phone and display it uniformly within the application.

[0004] For example, the invention patent announcement CN113806383B describes a method and apparatus for real-time calendar synchronization, which includes: a server subscribing to updates of calendar information in multiple third-party calendar accounts; when there are updates to the calendar information in the third-party calendar accounts, the server can immediately push the updates of the third-party calendar accounts to the electronic device to update the system calendar of the electronic device, and the electronic device does not need to periodically access the server.

[0005] For example, the invention patent with publication number CN115221239A discloses a method and system for bidirectional synchronization of calendar data from multiple data sources, which includes: a unified schedule center acquiring calendar data synchronized in real time from different types of calendar applications based on a standard schedule interface, configuring the synchronized calendar data according to the calendar writing interface provided by other calendar applications, and then writing the synchronized calendar data to other calendar applications in real time.

[0006] However, in the process of implementing the inventive technical solution in the embodiments of this application, it was found that the above-mentioned technology has at least the following technical problems: In existing technologies, because the calendar cannot be directly shared with other users after being synchronized with a third-party calendar, and there is a lack of an effective time zone adaptation mechanism, problems such as incomplete sharing function, inconsistent push time, and difficulty in adjusting the push time when users' time zones change occur when multiple people share the calendar. Summary of the Invention

[0007] This application provides a method for sharing and synchronizing calendar information for multiple family members. This method solves the problems in the prior art where, after synchronizing a third-party calendar, it cannot be directly shared with other users, and there is a lack of an effective time zone adaptation mechanism. This results in incomplete sharing functionality, inconsistent push times, and difficulty in adjusting push times when users' time zones change. The method achieves seamless sharing and intelligent push of third-party calendars in multi-person cross-time zone scenarios.

[0008] This application provides a method for synchronizing and storing shared calendar information for multiple family members, comprising the following steps: storing calendar information on a server, including a list of participants, a list of visible users, and creator information; obtaining calendar data from a third-party calendar on a client through an application programming interface provided by the third-party calendar, synchronizing the calendar data from the third-party calendar to the server, and storing associated data related to the third-party calendar on the server, including the calendar ID, time zone information at the time of calendar creation, and calendar identifier; sharing the synchronized third-party calendar schedule to the clients of the corresponding family members according to the list of visible users, and restricting the modification operations of the synchronized third-party calendar schedule based on the creator's identity information, fine-grained permission configuration information, and third-party log association identifier.

[0009] One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. By building a centralized server platform that integrates third-party calendar synchronization, fine-grained permission management, time zone adaptive notifications, and intelligent conflict resolution, data consistency and security are ensured, and accurate information push and collaboration across time zones are achieved. This enables secure, convenient, and intelligent sharing and collaborative management of third-party calendar events in multi-user scenarios such as families, effectively improving the efficiency and experience of schedule management.

[0010] 2. By storing and updating the time zone settings independently for each family member in real time, combined with a fine-grained access control system and a timed data synchronization mechanism, the system ensures accurate delivery of schedule notifications, secure and controllable data operations, and real-time consistency of data across multiple devices. This enables intelligent reminders across time zones, secure access management, and a reliable data synchronization experience in multi-user sharing scenarios.

[0011] 3. By employing multiple security measures, such as dynamically generated encryption keys bound to user accounts, layered encryption mechanisms, regular key rotation, and adding verification codes to transmitted data, the confidentiality, integrity, and authenticity of schedule data are comprehensively guaranteed at both the storage and transmission levels. This achieves a high level of security protection for family-shared schedule information in the cloud and network channels, effectively resisting the risks of data leakage and tampering.

[0012] 4. By combining custom multi-dimensional notification rules, intelligent conflict detection and hierarchical processing strategies based on feature vectors, and a strict permission verification mechanism, personalized and accurate notification push, intelligent resolution of schedule conflicts, and secure and controllable data operations are achieved, thereby significantly improving the overall experience of family shared calendars in terms of ease of use, intelligent collaboration, and management security. Attached Figure Description

[0013] Figure 1 This is a flowchart illustrating a method for synchronously storing shared calendar information for multiple family members, as provided in an embodiment of this application. Detailed Implementation

[0014] This application provides a method for synchronizing and storing shared calendar information among multiple family members. This solves the problems in existing technologies where synchronized third-party calendars cannot be directly shared with other users, and where there is a lack of effective time zone adaptation mechanisms. These problems lead to incomplete sharing functionality, inconsistent push times, and difficulties in adjusting push times when users' time zones change. The overall approach is as follows: By building a family shared calendar system that integrates third-party calendar synchronization, fine-grained access control, time zone adaptive notifications, data encryption protection, and intelligent conflict resolution mechanisms, seamless aggregation, secure sharing, and intelligent collaborative management of cross-platform schedule data are achieved. This solves the core pain points of traditional solutions, such as the lack of sharing functions, rigid time zone handling, coarse access control, and weak data security. Ultimately, it provides a unified, accurate, secure, and efficient schedule collaboration experience for multi-member families across time zones.

[0015] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0016] like Figure 1 The diagram shows a flowchart of a method for synchronizing and storing shared calendar information among multiple family members, as provided in an embodiment of this application. The method includes the following steps: The server stores schedule information, including a list of participants, a list of visible users, and information about the creator. On the client side, schedule data from the third-party calendar is obtained via an application programming interface (API) provided by the third-party calendar. The schedules from the third-party calendar are then synchronized to the server. The server stores associated data related to the third-party calendar, including the schedule ID, time zone information at the time of schedule creation, and calendar identifier. Based on the list of visible users, the synchronized third-party calendar schedules are shared to the clients of the corresponding family members. Modification operations on the synchronized third-party calendar schedules are restricted based on the creator's identity information, fine-grained permission configuration information, and third-party log association identifiers.

[0017] In this embodiment, the server-side storage of the core schedule data, including a list of participants, a list of visible participants, and information about the creator, lays the foundation for subsequent definition of the sharing scope and division of responsibilities, avoiding the collaborative chaos caused by ambiguous participant roles and unclear attribution of responsibilities in traditional shared calendars. Simultaneously, the client obtains schedule data through the official application programming interface (API) of the third-party calendar and synchronizes it to the server, rather than being limited to local client storage. This completely breaks down the barrier of traditional third-party calendar synchronization data being visible only to the individual, allowing family members to collaboratively view the same third-party calendar content based on the server-side sharing mechanism. This solves the problem of personal third-party schedules being unable to be shared with family members in a family setting. This significantly improves the efficiency of family schedule collaboration by eliminating the inefficiency of manually forwarding notifications. The server synchronously stores associated data including third-party calendar event IDs, timezone information at the time of event creation, and calendar identifiers. The third-party calendar event IDs and calendar identifiers accurately pinpoint the original source of the synchronized data, preventing confusion between synchronized events and locally created family events. The timezone information at the time of event creation provides data support for schedule time adaptation for family members in different time zones, preventing cognitive biases due to time zone differences (e.g., overseas members misinterpreting a meeting as local time). Furthermore, the server can target synchronized third-party calendar events based on the visible person list. Enables on-demand sharing: The creator can flexibly control which family members can view the synchronized schedule by adjusting the visible list. This satisfies the sharing needs of all family members for common family matters such as family trips and meals, while also protecting the privacy of personal third-party schedules such as work meetings, thus balancing schedule sharing and privacy protection. A multi-level permission restriction mechanism based on the creator's identity information, fine-grained permission configuration information, and third-party calendar association identifiers forms a comprehensive synchronized schedule security management system: By verifying the creator's identity information, it is ensured that whoever initiates third-party synchronization has the right to modify it, preventing accidental operations (such as accidental deletion or modification) or malicious modifications to others' synchronized schedules by other family members from the source. This prevents data chaos. By using fine-grained permission configuration, the scope of modification operations is clearly defined, and modification permissions for non-creators are excluded. This further refines permission boundaries, allowing creators to reasonably adjust core content of synchronized schedules, such as reminder times and participants, while prohibiting them from modifying natively locked fields of third-party calendars, such as third-party schedule IDs. This ensures consistency between synchronized data and third-party source data. At the same time, only non-creators are granted viewing permissions to prevent unauthorized operations. The third-party calendar association identifier can effectively distinguish between synchronized third-party schedules and locally created family schedules, eliminating the risk of non-creators bypassing permission restrictions by disguising synchronized schedules as local schedules, and ensuring that permission control rules are not circumvented.This invention achieves precise sharing scope, transparent collaboration process, multi-level security control, and cross-time zone adaptation for family third-party calendar sharing. It effectively solves the pain points of traditional family shared calendars, such as the inability to share third-party synchronized data, difficulties in cross-time zone collaboration, and loose permission control. It significantly improves the security, efficiency, and flexibility of family schedule collaboration, and realizes efficient collaboration and secure control of family members sharing synchronized third-party calendars.

[0018] Furthermore, the server also stores the time zone settings of each family member. When the server sends a schedule notification to a family member's client, it calculates the local time corresponding to the schedule based on the time zone of the family member receiving the notification and triggers the notification push at the local time. If a family member's time zone changes, the server updates the member's time zone configuration in real time and recalculates the push time of subsequent schedule notifications.

[0019] In this embodiment, the server-side design, by storing the timezone settings of each family member and dynamically adapting the schedule notification push based on these settings, fundamentally solves the core pain points of traditional family shared calendars in cross-timezone scenarios, such as misaligned notification times and poor user experience. The overall technical effect is specifically manifested in the following ways: First, the pre-stored family member timezone data on the server provides an accurate data foundation for localized time conversion of notification pushes, completely avoiding time perception discrepancies caused by uniformly pushing notifications based on the schedule creator's timezone or the server's default timezone in traditional solutions. For example, if the parents in a family have synchronized a third-party calendar schedule for weekend family video calls in China (UTC+8), while their children are studying abroad (UTC+5), the server will automatically read the children's UTC+5 timezone settings and adjust the schedule to UTC+8. The server converts the local time (e.g., 7:00 PM on Saturday) to the child's local time (6:00 AM on Saturday) and triggers a notification push at that local time. This ensures that the child does not need to manually convert the time across time zones and can receive reminders at the accurate time, effectively avoiding schedule omissions caused by time zone differences, such as misinterpreting domestic time notifications as local time and missing calls. Secondly, for dynamic scenarios where family members' time zones change, such as children returning home for holidays and adjusting their time zone, or parents switching to their destination time zone for work trips, the server supports real-time updates to the member's time zone configuration and immediately recalculates the notification push time for all subsequent related schedules based on the new time zone. This eliminates the need for members to manually reset or trigger synchronization, reducing user operation costs and ensuring the continuity and accuracy of notifications after time zone changes. For example, if a parent travels from the UTC+8 time zone to the UTC+1 time zone, the server will automatically recalculate the Monday 9:00 AM work meeting schedule notification (originally calculated in the UTC+8 time zone) to Monday 2:00 AM in the UTC+1 time zone and push it to the parent at the new time. This avoids the parent receiving outdated or early notifications due to time zone mismatch. In addition, this invention further enhances the flexibility and reliability of family schedule collaboration, especially suitable for family scenarios where multiple members are located in different time zones, such as multinational families or families working or studying in multiple locations. It allows each family member to receive schedule notifications at their local time without having to worry about the details of cross-time zone conversion, significantly reducing the cognitive burden and operational costs of cross-time zone schedule collaboration, while ensuring the accuracy and timeliness of notification pushes, ultimately improving the practical value and user experience of family shared calendars in cross-time zone scenarios.

[0020] Furthermore, the server stores fine-grained permission information, including viewing, editing, and deleting permissions for synchronized third-party calendar events. Only the creator of the synchronized event has editing and deletion permissions, while other family members only have viewing permissions. When the server receives a request to modify a synchronized event, it first verifies the requester's identity and permission level. Only when the requester is the creator of the synchronized event is the corresponding modification operation allowed, and the event display on all visible clients is updated synchronously.

[0021] In this embodiment, the server stores fine-grained permission information including viewing, editing, and deletion permissions, and strictly limits editing and deletion permissions to only the creator of the synchronized calendar, while other family members only have viewing permissions. Furthermore, upon receiving a modification request, the server first verifies the requester's identity and permission level, allowing only the creator to perform modification operations and synchronously updating the calendar display on all visible clients. From the three core dimensions of permission control precision, data security protection, and collaborative consistency, this design thoroughly solves the pain points of traditional family shared calendars: loose permissions leading to misoperation, unauthorized modifications damaging data integrity, and asynchronous information causing collaborative chaos. The overall technical effect is specifically manifested in the following ways: First, the precise division of fine-grained permissions breaks the traditional shared calendar... Traditional solutions, which often restrict permissions to a single level, are prone to issues such as family members accidentally deleting or modifying third-party schedules synchronized by others. This is because they only support single-permission modes that allow all members to modify the schedule or only the creator to see it. For example, a child might accidentally delete a family medical appointment schedule synchronized by their parents. Alternatively, overly restrictive permissions may prevent the realization of the shared value of the schedule. This invention breaks down permissions into three independent dimensions: viewing, editing, and deleting. This satisfies the core need of the creator to share schedule content while retaining control over modifications. For example, when the creator synchronizes work-related third-party schedules, family members can only see the schedule but cannot adjust the time. Furthermore, by restricting other family members to only viewing, this invention prevents data chaos caused by unauthorized modifications at the source, ensuring the originality and integrity of the synchronized schedule. Secondly, the exclusive permission locking system, granting editing and deletion rights only to the creator, establishes a unified responsibility mechanism for synchronized schedules. As the initiator of the third-party calendar data, the creator of the synchronized schedule bears primary responsibility for the accuracy and timeliness of the schedule content. Assigning editing and deletion permissions exclusively to the creator avoids version conflicts caused by multiple simultaneous modifications (e.g., schedule A synchronized is adjusted by B and C, resulting in chaotic schedule times stored on the server). It also ensures the traceability of modification operations, as all modifications are initiated by the creator. Subsequent verification of modification records allows for precise identification of the responsible party. Furthermore, it prevents non-creators from making invalid modifications due to a lack of understanding of the schedule's background information (e.g., family members unaware of the importance of the creator's work meetings might mistakenly advance the meeting time), further guaranteeing the consistency between synchronized schedules and third-party source data. Furthermore, the verification process that checks identity and permission levels before modification requests forms a security barrier against unauthorized operations. Before executing a modification operation, the server will first check whether the requester is the creator of the synchronized schedule and whether they have the corresponding modification permissions. If the modification request is initiated by someone other than the creator, such as a family member accidentally clicking the modification button or attempting to delete someone else's synchronized schedule without authorization, the operation will be rejected directly. This effectively avoids risks such as accidental modification and malicious unauthorized tampering, providing a rigid guarantee for the data security of synchronized schedules and preventing schedule data damage or loss due to lack of permission verification.Finally, the design of automatically updating the calendar display on all visible users' clients after the creator makes a change solves the pain point of information asymmetry in collaboration: In traditional shared calendars, if the creator modifies the schedule without manually informing other members, discrepancies can easily occur where some members' clients display the old schedule while others display the new one. For example, if the creator changes the departure time of a family trip from Monday to Tuesday, members who haven't synchronized will still prepare their luggage based on Monday. This invention, through its mechanism of automatically synchronizing all visible users' clients after a change, ensures that all family members authorized to view the schedule can obtain the latest schedule content in real time, without requiring additional communication from the creator. This reduces user operation costs, ensures information consistency in family schedule collaboration, and avoids schedule execution errors caused by information lag. In summary, this technical solution, through the synergistic effect of fine-grained permission division, exclusive permission locking, request verification barriers, and real-time synchronization mechanisms, achieves secure sharing of third-party calendar schedules in family sharing scenarios, ensures data integrity and consistency, reduces the complexity of collaborative operations, and significantly improves the security, reliability, and user experience of family-wide shared synchronization of third-party calendars.

[0022] Furthermore, the server sets up a scheduled synchronization task to send synchronization detection commands to the client at preset times, triggering the client to check the schedule updates of the third-party calendar through the third-party calendar's application programming interface. If newly added, modified, or deleted schedule data is detected, the client uploads the updated complete schedule data to the server. The server synchronously updates the stored schedule information and related data, and pushes update prompts to the clients of those who can see the schedule, ensuring the consistency of schedule data for all users.

[0023] In this embodiment, the server sets up a scheduled synchronization task and sends a synchronization detection command to the client at a preset time, triggering the client to call the third-party calendar application programming interface to check for schedule updates. From four core dimensions—automated operation to reduce workload, full-scene update capture, real-time data calibration, and collaborative information synchronization—it completely solves the key pain points of traditional family shared calendars: the reliance on manual triggering for third-party schedule synchronization is prone to delays, incomplete update detection leads to data incompleteness, and the lack of synchronization between the server and multiple clients causes collaborative chaos. On the one hand, the automated execution mechanism of the scheduled synchronization task greatly reduces the user's operational burden and avoids the risk of omissions in manual synchronization. In traditional solutions, the synchronization of third-party calendar schedules requires the user to manually send a command. Previously, if users failed to trigger synchronization due to busy work schedules, different work schedules, or forgetting to perform the operation, the calendar stored on the server could easily become disconnected from the third-party source data. For example, if a parent synchronizes a child's school activity schedule and adds weekend tutoring, but forgets to manually synchronize, other family members' clients will always display the old schedule. However, in this invention, the server can be flexibly configured with preset times according to family needs, such as automatically sending detection commands every 1 hour or every 3 hours. This can trigger the client to actively check for updates to the third-party calendar without user intervention. Even if family members are too busy to operate, the synchronization process can still be ensured to continue. This guarantees the timeliness of synchronization from the source of operation, and is especially suitable for family members such as the elderly and children who are not familiar with operating smart devices, thus lowering the barrier to entry for them. On the other hand, the client checks for updates through the official API of the third-party calendar, achieving accurate capture of all changes across all scenarios, including additions, modifications, and deletions. This avoids missing minor updates. Traditional non-API detection methods, such as text comparison and title matching, often fail to recognize subtle changes in the third-party calendar, such as a schedule time being slightly adjusted from 15:00 to 15:30, a participant being changed from parents to grandparents, or a destination being changed from a community hospital to a city hospital. This results in incomplete or distorted schedule data stored on the server. However, the official API allows direct reading of the complete change log of the third-party calendar. Whether the schedule is added (e.g., a suddenly added family dinner), modified (e.g., a delayed return from a business trip), or deleted (e.g., a canceled extracurricular class), all changes can be accurately identified. This ensures that the updated data uploaded by the client to the server is completely consistent with the third-party source data, eliminating discrepancies between old data on the server and updated information from the third party. This provides an accurate data foundation for subsequent family collaboration.After receiving the complete updated data uploaded by the client, the server synchronously updates its own stored core schedule information, including participant lists, visible person lists, and other data associated with third parties, as well as third-party schedule IDs and time zone information. It then immediately pushes update notifications to all visible clients of that schedule, completely resolving the collaborative chaos caused by information asynchrony across multiple devices. In traditional shared calendars, even if some clients complete synchronization, the server often fails to proactively push update notifications to other family members, leading to information asymmetry where some members see the new schedule while others see the old one. For example, if family member A's synchronized family trip departure time is changed from Sunday to Saturday and updated to the server, members B and C's clients still show Sunday, ultimately preparing their luggage according to the old time. In this approach, the server pushes notifications to visible users immediately after updating its storage. For instance, an in-app pop-up window will indicate that member A's synchronized travel schedule has been modified, with the new time being Saturday 9:00 AM. All authorized family members who view the schedule can obtain the latest information in real time, without the initiator needing to notify via WeChat or phone. This reduces communication costs and avoids itinerary conflicts and preparation errors caused by information lag, such as ensuring no one goes to the meeting point at the old time. It ensures that the client calendar data of all users, including the initiator of the synchronization and other family members, is completely consistent. The synchronized calendar displayed on the client of all visible users is synchronized with the third-party source data and the data stored on the server, completely eliminating the collaboration conflicts caused by data inconsistency. It is especially suitable for scenarios where multiple members are located in different places and rely on the same calendar for collaboration, significantly improving the reliability and efficiency of family calendar collaboration. At the same time, it strengthens users' trust in the shared calendar, allowing family members to arrange their lives with peace of mind based on the synchronized information without having to repeatedly check the accuracy of the calendar.

[0024] Furthermore, the server uses the AES symmetric encryption algorithm to encrypt the stored schedule information, associated data, and permission information. The encryption key is dynamically generated by the server and bound to the user account. Specifically, after the user successfully completes identity authentication, the server dynamically generates an encryption key by combining the user account's unique identifier and a randomly generated cryptographic salt value through a key derivation function. The encryption key is then bound to the user account and stored in the server's key management module. Each user account corresponds to an independent encryption key, and the encryption keys of different family members are isolated from each other. When transmitting various types of data between the client and the server, the TLS 1.3 transport layer security protocol is used to establish an encrypted channel, and a checksum is added to the transmitted data to prevent data tampering or theft.

[0025] In this embodiment, the server constructs a comprehensive security protection system from data storage to transmission for the family shared calendar's schedule information, third-party associated data, and permission configuration. This completely solves the core security pain points of traditional shared calendars, such as fixed keys that are easily cracked, non-isolated member keys leading to risk diffusion, and easy theft and tampering during transmission. On the one hand, in the data storage stage, the AES symmetric encryption algorithm is used to encrypt schedule information (such as family privacy schedules, member participation / visibility lists), third-party associated data (such as Google / Apple Calendar IDs, time zone information), and permission information (who can view / edit). The AES algorithm itself has high anti-cracking capabilities and can effectively resist the risk of decryption after the server-stored data is illegally stolen. Even if the storage system is attacked, attackers who do not obtain the encryption key cannot decipher the encrypted schedule content, thus avoiding the leakage of sensitive family information. More importantly, the encryption key is not generated in a fixed way. Instead, after the user completes identity authentication, the server combines the user's unique account identifier (such as a family member's exclusive account ID to ensure a strong binding between the key and the user) and a random cryptographic salt value. Each key salt value is different to prevent the same account identifier from generating the same key. It is dynamically generated through key derivation functions (such as PBKDF2 and Argon2), which completely eliminates the problem that if the key is leaked in the traditional fixed key mode, all historical data will be at risk. Even if an attacker obtains a key fragment at a certain moment, they will not be able to reverse deduce the key generated at other times, which greatly improves the key's resistance to brute-force attacks and collisions. At the same time, the key is bound to the user account and stored in the server's dedicated key management module, which not only ensures the security of the key itself, but also achieves independent keys for each user account and isolation between keys of different family members. For example, family member A's key can only decrypt their synchronized third-party schedules and related data. Family member B's key cannot access A's encrypted data. Even if A's key is accidentally leaked due to device loss or other reasons, it will only affect the schedule information under A's name and will not lead to unauthorized access to the synchronized schedules and permission configurations of other family members such as B and C. This completely avoids the chain risk of one person's key being leaked and the whole family's data being exposed, balancing the needs of family sharing and individual privacy protection. On the other hand, in the data transmission stage, the client and server establish an encrypted channel using the TLS 1.3 transport layer security protocol. Compared with the old version of the TLS protocol, TLS 1.3 not only simplifies the handshake process and reduces network latency, adapting to the synchronization scenario of multiple family devices (mobile phones, tablets, computers), but also removes insecure encryption suites such as RC4 and SHA-1, and adopts secure key exchange algorithms such as ECDHE and symmetric encryption algorithms such as AES-GCM, which can effectively resist man-in-the-middle attacks during transmission.For example, when family members synchronize third-party calendar events over public Wi-Fi, even with the risk of eavesdropping, the TLS 1.3 encrypted channel ensures that the transmitted calendar data is not illegally intercepted or interpreted. Simultaneously, an additional checksum is added to the transmitted data. Upon receiving the data, the server first compares the checksum with the data content. If the data is tampered with during transmission, the checksum will immediately become mismatched, and the server will refuse to receive the data and require the client to re-upload it. This completely eliminates calendar execution errors caused by data tampering, ensuring the integrity and accuracy of the transmitted data. This invention achieves four layers of security protection: storage leakage prevention, transmission theft prevention, data tampering prevention, and member dissemination prevention. It protects family privacy calendars from unauthorized access through high-strength encryption and dynamic keys, ensures independent security of member data through key isolation, and guarantees data security and accuracy during synchronization through TLS 1.3 and checksums. Ultimately, family members can confidently use a shared calendar to synchronize third-party events without worrying about sensitive information leakage, data tampering, or security risks during cross-device synchronization, significantly improving the security, reliability, and user trust of family shared calendars.

[0026] Furthermore, the server employs a layered encryption mechanism when storing encryption keys: the master key is used to encrypt and protect the encryption key, which is stored in a hardware security module; the encryption key is temporarily decrypted in memory only when user data needs to be encrypted or decrypted; the server periodically rotates the encryption key, and the key rotation process includes: generating a new encryption key; decrypting the encrypted data using the old key and then re-encrypting it using the new key; updating the key binding relationship and securely destroying the old key.

[0027] In this embodiment, the server constructs a high-level key protection system that far surpasses the traditional single-key storage model, encompassing three core dimensions: root-source key storage security, usage security, and long-term dynamic security. This system completely solves the key pain points of traditional key management, such as the vulnerability of the master key to theft, the risk of leakage due to persistent storage of encryption keys, and the accumulation of risks caused by the lack of key rotation over a long period. On the one hand, the layered encryption mechanism combined with the master key storage design of the hardware security module fundamentally blocks the path for the master key to be illegally obtained. In traditional solutions, if the protection key for the encryption key is stored in ordinary software storage areas (such as databases or file systems), it is vulnerable to attacks by hackers that can steal the master key through SQL injection, file tampering, and other attacks, thereby cracking all systems that rely on the master key for protection. Encryption key; In this invention, the server first encrypts and protects the user's encryption key with the master key, forming a layered encryption link of master key, encryption key, and user data. Then, the master key is stored in the hardware security module. The hardware security module, as a dedicated hardware device, has the characteristics of physical anti-tampering and logical anti-attack. For example, it supports the generation and operation of keys inside the hardware and never exports them to the external environment, resisting physical disassembly and other attack methods. Even if the server's software system is compromised, attackers cannot break through the hardware protection of the hardware security module to obtain the master key. Thus, the security of the encryption key is guaranteed from the root key level, avoiding the catastrophic risk of a chain reaction of cracking of all user encryption keys due to master key leakage, and protecting sensitive schedule data stored in the family shared calendar. On the other hand, the mechanism of temporarily decrypting in memory to obtain the encryption key only when encryption or decryption is needed significantly reduces the exposure window of the encryption key. In traditional solutions, encryption keys are often persistently stored on the server's disk or in memory. Even when no encryption or decryption operation is needed, the key remains accessible for a long time, increasing the risk of being stolen by attacks such as memory scanning and process hijacking. In this invention, the encryption key is only temporarily decrypted and generated in memory when the server needs to perform encryption or decryption operations on user data. Moreover, the decrypted key only exists within the cycle of this encryption or decryption task and is immediately cleared from memory after the task is completed, leaving no persistent trace. This on-demand generation and use-and-destruction mode minimizes the exposure time of the encryption key in memory, effectively avoiding the risk of key theft in scenarios such as memory attacks and malicious processes reading memory data. This ensures the security of the encryption key during use and prevents the user's encrypted data from being cracked due to the key being stolen in memory.The periodic key rotation mechanism completely solves the risk accumulation problem caused by long-term key use through a closed-loop process of generating new keys, decrypting and reencrypting old keys, updating bindings, and destroying old keys. In traditional solutions, if the encryption key is not changed for a long time, once the key is leaked at some point, such as through the leakage of historical backup data or the remnant of old device keys, attackers can use the key to crack all historical data and current data encrypted with that key, and the risk will continue to expand over time. In this invention, the server performs key rotation periodically: first, a brand new encryption key is generated through a security algorithm; then, the old key that is about to expire is used to decrypt the encrypted user data; and finally, the new key is used to decrypt the encrypted data. The data is re-encrypted and updated in storage, and the binding relationship between the new key and the user account is updated. Finally, the old key is completely destroyed through a secure erasure algorithm. This not only strictly controls the effective lifespan of each encryption key, but also ensures that even if a key is accidentally leaked during a certain period, attackers can only affect the data encrypted within the validity period of that key and cannot access subsequent data encrypted with the new key after the rotation, greatly reducing the impact of key leakage. At the same time, the complete destruction of the old key eliminates the possibility of it being illegally retained and used to crack historical data, ensuring that user data is always protected by the latest security key during long-term storage, further strengthening the long-term security protection capability of the data. This invention achieves triple security protection: root storage security, zero residual usage, and long-term dynamic protection. From hardware-level storage protection of the master key to temporary memory use protection of the encryption key, and dynamic risk control through regular key rotation, it forms a comprehensive protection covering the entire lifecycle of key generation, storage, use, update, and destruction. It completely plugs various security vulnerabilities in traditional key management, ensuring that users' encryption keys and sensitive schedule data protected by keys in the family shared calendar remain highly secure even in the face of various risk scenarios such as physical attacks, logical intrusions, and historical data leaks. Ultimately, it significantly enhances users' trust in the security of family shared calendar data, allowing family members to confidently synchronize and share third-party calendar schedules containing private information.

[0028] Furthermore, the steps for adding a checksum to the transmitted data include: generating a checksum using the HMAC algorithm based on a shared key; the shared key used by the HMAC algorithm is negotiated and generated through a key exchange protocol during the handshake phase of a preset security protocol, and each session uses a different shared key; attaching the checksum to the transmitted data and sending it together; the receiver verifies the validity of the checksum, and if the verification fails, it refuses to process the data; the scope of the checksum generation includes the complete payload and key header information of the transmitted data to ensure data integrity and authenticity of the source; when the server detects abnormal transmission behavior, it immediately terminates the current session and forces a re-establishment of the encrypted channel.

[0029] In this embodiment, the server and client of the present invention, through a data integrity protection design based on HMAC algorithm for checksum generation and verification, session-level dynamic shared key negotiation, full data verification, and abnormal session blocking, thoroughly solve the key pain points of traditional family shared calendar data transmission from four core dimensions: data source authentication, content integrity assurance, session security isolation, and abnormal risk mitigation. These pain points include simple and easily tampered verification mechanisms, risk propagation due to key reuse, incomplete data verification leaving vulnerabilities, and lack of proactive protection against abnormal transmission. On the one hand, the HMAC algorithm combined with the session-level dynamic shared key design ensures the authenticity of the transmitted data source and eliminates the security risks caused by key reuse. Traditional solutions using simple checksums without keys, such as CRC3, are far superior. 2. MD5: Attackers can easily tamper with data and regenerate the checksum to disguise it as legitimate data. In contrast, the checksum in this invention is generated using the HMAC algorithm. This algorithm relies on a shared key for computation, and the shared key is dynamically negotiated during the handshake phase of the TLS 1.3 security protocol through a key exchange protocol such as ECDHE. Each session uses an independent shared key, which becomes invalid immediately after the session ends. Even if the shared key of a session is leaked due to extreme circumstances, it only affects the current session and will not cause the verification mechanism of other sessions to fail. Furthermore, it cannot be used to forge the transmission data of other sessions, ensuring that every piece of transmission data received by the client comes from a legitimate server and is not maliciously forged, thus building a solid defense for the security of the transmission source of sensitive schedule information in the family shared calendar. On the other hand, the verification code covers the full verification scope of the transmitted data payload and key header information, completely plugging the integrity vulnerabilities left by traditional partial verification that only checks the payload or only checks the header. If traditional solutions only check the data payload, attackers may tamper with key header information, such as modifying the user identifier of the data owner, disguising member A's schedule data as member B's, causing member B's client to display an incorrect schedule; or modifying the data timestamp, causing expired schedules to be pushed as new schedules. However, only checking the header cannot detect that the payload content has been tampered with, such as changing the departure point of a family trip from airport A to airport B. In this invention, the verification code is generated by including not only the complete payload data such as schedule content and participant list, but also key header information such as user account identifier, data timestamp, and session ID. This ensures that the data is tamper-free throughout the entire chain from the owner identifier, time validity, and content integrity, avoiding schedule data misalignment caused by the separate modification of the header or payload, ensuring the accuracy of schedule data in family collaboration, and eliminating itinerary conflicts caused by data tampering.Meanwhile, the rigid blocking mechanism that rejects processing upon receiving verification failure, combined with the proactive protection measure of immediately terminating the session and rebuilding the encrypted channel upon detecting abnormal transmission behavior, forms a double safety net for transmission security: When the receiver verifies the verification code, if it finds that the data does not match the verification code, it will directly refuse to receive and process the data, preventing tampered data from entering the business process, thus blocking the interference of erroneous data on family schedule collaboration at the terminal level; When the server detects abnormal transmission behavior, such as frequent verification failures in a short period of time, abnormal data transmission fragments, or duplicate authentication requests in the session connection, it may be that an attacker is trying to tamper with the data or crack the session. It will immediately terminate the current encrypted session, forcing the client to re-negotiate a new shared key and encrypted channel through a secure handshake, preventing attackers from continuously launching attacks using the current session, such as repeatedly sending tampered data through abnormal sessions to test the protection mechanism. At the same time, session reconstruction eliminates potential security risks, ensuring that subsequent transmissions always take place within a secure channel. This invention achieves four layers of security protection: verifiable source, tamper-proof content, isolated sessions, and loss mitigation in case of anomalies. It ensures that the data comes from a legitimate entity through HMAC and dynamic keys, guarantees that the data content and identifiers are not tampered with through full verification, and prevents the spread of risks by blocking verification failures and rebuilding abnormal sessions. Ultimately, it ensures that the third-party schedule data synchronized in the family shared calendar remains secure, accurate, and reliable during transmission, completely eliminating family members' concerns about data tampering or impersonation, and significantly improving the security experience and collaborative reliability when synchronizing schedules across devices and networks.

[0030] Furthermore, the server supports creators to customize multi-dimensional schedule notification rules, including advance notification time, repetition frequency, and notification channels. Based on the start time of the synchronized schedule, the time zone configuration of family members, and the customized notification rules, the server sends precise notification messages to the clients of the corresponding family members in different time periods.

[0031] In this embodiment, the server supports creators to customize multi-dimensional schedule notification rules and combines the synchronization of schedule start time and family member time zone configuration to achieve precise time-segmented push notifications. From four core dimensions—notification flexibility, precise cross-time zone delivery, reliable reminders, and matching member habits—it completely solves the key pain points of traditional family shared calendar notification mechanisms: fixed rules that cannot adapt to diverse needs, lack of consideration for time zones leading to notification time misalignment, single reminder methods that are prone to omissions, and indiscriminate push notifications that disturb users regardless of the scenario. On the one hand, multi-dimensional customizable rules give creators refined control over notifications, completely breaking the limitations of fixed notification times, single frequency, and rigid channels in traditional solutions. In traditional scenarios, if the creator synchronizes important family affairs, fixed reminders may be delayed due to time zone constraints. Staff members often miss reminders due to busy schedules; manually setting reminders repeatedly for routine tasks increases the workload. However, this invention allows creators to flexibly configure reminders based on schedule importance and members' schedules: for important tasks, repeated notifications can be set 2 hours or 30 minutes in advance to ensure members have sufficient time to prepare; for routine tasks, single notifications can be set 1 hour in advance. Furthermore, notification channels can be tailored to members' habits, such as SMS notifications for the elderly to avoid missing reminders due to unfamiliarity with the app; and in-app pop-ups and WeChat notifications for younger users to accommodate their frequent use of social media apps. This satisfies reminder needs across different schedules and aligns with family members' preferences, preventing reminder failures due to incompatible methods and ensuring each member receives notifications in a familiar way. On the other hand, the server-side, by combining the start time of the synchronized schedule with the precise calculation of the family members' time zone configuration, completely solves the problem of notification time misalignment in cross-time zone scenarios. Traditional solutions, if push notifications according to the creator's time zone or the server's default time zone, are prone to situations where the member's receiving time is out of sync with their local time. In this invention, the server first reads the start time of the synchronized schedule, then retrieves the time zone configuration of the corresponding family member, automatically calculates the member's local meeting time, and then, combined with the creator's custom advance notification time, triggers the notification push at the member's local time. This ensures that the notification time received by members in cross-time zones is completely matched with their own local time, eliminating the need for manual time zone conversion. This avoids missing schedules due to time perception discrepancies and reduces the operational burden on members. It is especially suitable for families with multiple members distributed in different time zones, making the notification experience for cross-time zone schedule collaboration consistent with that of the same time zone.The mechanism of sending precise notification messages to corresponding family members' clients in different time slots ensures the reliability of reminders while avoiding the disturbance of invalid pushes. The server generates a personalized notification plan for different members based on each family member's visibility permissions, time zone configuration, and custom notification rules: notifications are only pushed to members in the visibility list, and the notification time, frequency, and channel for each member are independently adapted. This ensures that all relevant members receive precise reminders without disturbing irrelevant members due to uniform pushes. At the same time, compared with single pushes, time-slot pushes significantly reduce the probability of missing single reminders due to temporary busyness, further improving the effectiveness of notifications and ensuring the smooth progress of family schedule collaboration. This invention achieves personalized family shared calendar notifications by leveraging multi-dimensional customizable rules to adapt to needs, precise cross-time zone calculation of delivery time, and precise push notifications for different time periods and members. It satisfies the reminder intensity requirements of different schedule scenarios while adapting to the usage habits and time zone differences of different members. It ensures the reliability and accuracy of reminders while avoiding the disturbance of invalid pushes, completely solving the rigidity and inefficiency of traditional notification mechanisms. This allows family members to receive schedule reminders accurately and promptly regardless of their time zone, device, or lifestyle, significantly improving the efficiency of family schedule collaboration and user experience. Especially in family sharing needs involving multiple time zones, multiple members, and multiple scenarios, it demonstrates flexibility and practicality far exceeding traditional solutions.

[0032] Furthermore, when multiple family members synchronize the same third-party calendar, the server detects calendar conflicts by constructing a calendar feature vector. This feature vector includes a time range, a list of participants, a calendar topic, and a summary of core content. When a conflict is detected, the server sends a conflict alert message to the clients of the family members involved. The alert includes a comparison of key information about the conflicting calendars and dynamically provides conflict resolution options based on a preset priority strategy. These options include merging conflicting calendars, prioritizing calendars, and customizing time ranges. Merging conflicting calendars is suitable when the conflicting calendars have complementary information and the user wants to retain all information; the server will mark the source of the conflict in the merged calendar. Prioritizing calendars is suitable when there are significant priority differences among the conflicting calendars; the server will prioritize only one calendar based on the user's choice. Customizing time ranges is suitable when the user wants to avoid conflict by directly modifying the calendar time; the server will rearrange the calendars according to the user's new time range. The first priority judgment determines whether at least one of the conflicting calendars has participants. If the number of participants exceeds a preset participation threshold, or the matching degree between the event topic and the preset keyword list exceeds a third preset threshold, then an option to prioritize the event is provided. If a significant priority difference is determined, the display priority of the conflicting events is adjusted according to the user's selected priority event. Otherwise, the process proceeds directly to the second priority judgment process. Second priority judgment: Determine if the similarity of the conflicting events' topics is higher than the first preset threshold, but the repetition of the core content summary is lower than the second preset threshold. If so, an option to merge the conflicting events is provided. If the conflicting events' information is determined to be complementary, a new merged event is generated by retaining all conflicting event information and marking the source of the conflict. Otherwise, the process proceeds directly to the third priority judgment process. Third priority judgment: Determine if the proportion of the overlapping time interval of the conflicting events to the total duration of a single event is lower than a fourth preset threshold. If so, an option to customize the time interval is provided. If the time adjustment can effectively resolve the conflict, the server provides a time adjustment interface to receive the user's custom modification of the conflicting event's time interval. Otherwise, the process proceeds to the default strategy process. The default strategy process provides three conflict resolution options simultaneously in the conflict notification message for the user to choose from.

[0033] In this embodiment, the server-side design incorporates a full-process conflict management system. This system utilizes multi-dimensional schedule feature vectors for precise conflict detection, provides key conflict information comparison and alerts, and offers hierarchical resolution options based on dynamic priority strategies. It addresses the critical pain points of traditional family shared calendars—namely, incomplete conflict detection, ambiguous conflict information, limited resolution options, and lack of prioritization leading to the obscuring of important schedules—by focusing on four core dimensions: conflict detection accuracy, conflict awareness clarity, resolution option adaptability, and priority decision rationality. On one hand, the construction of multi-dimensional schedule feature vectors overcomes the limitations of traditional methods that rely solely on time overlap to determine conflict, achieving comprehensive and accurate conflict detection. Traditional solutions, which only detect overlapping time intervals, are prone to missing conflicts involving participants or content even when times don't overlap, or misjudging partially overlapping times with unrelated content. In this invention, the feature vectors simultaneously cover the core dimensions of time, participants, theme, and content. By comparing the consistency of these multi-dimensional features, the server can accurately identify time overlap, participant overlap, and content conflicts. The shield effectively addresses genuine conflicts, such as member A's synchronized Sunday outing from 9:00 to 12:00 and member B's synchronized third-party schedule from 10:00 to 13:00 on the same Sunday. While these events overlap in time, involve the same participants, and share the same theme, the conflicting time intervals prevent false conflicts (single-dimensional overlap but multi-dimensional irrelevance). This avoids invalid conflict prompts interfering with the user, laying a precise foundation for subsequent conflict resolution and ensuring that no conflicts of synchronized third-party schedules in the family shared calendar are missed or misjudged. Furthermore, the design of including a comparison of key information about the conflicting schedules in the conflict notification message significantly reduces the user's cognitive cost. Traditional solutions often only provide a simple notification of a schedule conflict after detection, requiring users to manually open each conflicting schedule to compare differences—a cumbersome process that easily leads to overlooking key conflict points. In this design, the server directly presents a comparison of key information about the conflicting schedules in the notification message. Users can quickly locate the core of the conflict without additional steps, intuitively understand its nature, and receive a clear basis for choosing resolution options, avoiding decision-making errors caused by ambiguous information. This invention utilizes a mechanism that dynamically provides tiered resolution options based on a preset priority strategy, achieving a balance between intelligent adaptation to conflict resolution and user-driven decision-making. Traditional solutions often only offer a single option to delete or retain one conflict, which cannot cope with diverse conflict scenarios. This forces users to either discard some information or manually perform multiple operations to resolve the conflict. In contrast, this invention dynamically matches options through a three-tiered priority system: the first priority is for high-importance conflicts involving many participants or key topics, providing a priority display option to ensure that important events are not obscured; the second priority is for conflicts with similar themes but complementary content, providing a merge event option and marking the source of the conflict, preserving all information while clearly tracing the source to avoid information loss; the third priority is for conflicts with slight time overlap, providing a custom time adjustment option to allow users to fine-tune the time to resolve the conflict; if none of the above priorities are met, three options are provided by default for users to choose from.This layered strategy reduces the user's decision-making burden through intelligent judgment and covers all scenarios with diverse options to meet users' personalized needs. It ensures efficient, comprehensive, and flexible conflict resolution, avoiding incomplete solutions or information loss due to limited options. This invention completely solves the conflict management problem when multiple members synchronize the same third-party calendar through a closed-loop process of accurate detection, clear prompts, and intelligent adaptation. It ensures accurate conflict identification, clear user understanding, and flexible resolution, reducing the cost of manual comparison and operation, and avoiding the risk of information loss or obscuring important schedules. It significantly improves the reliability and user experience of family shared calendars in scenarios where multiple members collaboratively synchronize third-party schedules, especially in families with many members, high synchronization frequency, and complex schedule scenarios, demonstrating intelligence and practicality far exceeding traditional solutions.

[0034] Furthermore, the steps for restricting access to modifying synchronized third-party calendar events based on creator identity information, fine-grained permission configuration information, and third-party log association identifiers include: when storing synchronized third-party calendar events, associating and recording the event's unique creator identifier and third-party log association identifier, and pre-setting standardized permission rules based on the third-party calendar events, and associating and saving these standardized permission rules with the event's stored data. The unique creator identifier includes the account ID or client device binding ID of the family member who initiated the third-party calendar synchronization operation. The third-party log association identifier includes the unique third-party calendar identifier and the third-party event's native ID. Based on the third-party log association identifier, the server locks the non-local creation attribute of the synchronized third-party calendar events and triggers exclusive permission rules. These exclusive permission rules allow only the creator to perform modification operations. When a requester attempts to disguise the synchronized third-party calendar event as a locally created event by a family member to bypass permission restrictions, the server verifies the existence of the third-party log association identifier, identifies the abnormal modification request, and rejects it. The standardized permission rules include permission type classification and permission exclusion rules. The permission type classification clearly defines the permissions for the synchronized third-party calendar events. The specific scope of schedule modification operations includes editing schedule content, adjusting schedule reminder times, modifying the participant list, modifying the visible person list, and deleting the schedule. By default, all types of modification permissions belong solely to the creator. The permission exclusion rules explicitly exclude non-creator family members from modifying synchronized third-party calendar schedules, retaining only viewing permissions for the schedule. Viewing permissions include viewing schedule details and receiving schedule notifications. Non-creator family members are prohibited from bypassing the permission exclusion rules to request modification permissions through any interface. When the server receives a modification request for a synchronized third-party calendar schedule, it verifies whether the request initiator's identity matches the creator's unique identifier. If the request initiator's identity does not match the creator's unique identifier, the modification request is directly rejected. If the request initiator's identity matches the creator's unique identifier, the execution of the modification operation is further controlled based on third-party log association identifiers and standardized permission rules. When controlling the execution of modification operations, it ensures that the creator can only modify content within their authorized scope, including prohibiting the creator from modifying fields natively locked by the third-party calendar. Natively locked fields include the schedule ID in the third-party calendar.

[0035] In this embodiment, the server employs a full-link permission restriction design that associates storage with the creator's unique identifier, locks the attribute of the third-party log association, refines the boundaries with standardized permission rules, and controls the execution of multi-level verification processes. From five core dimensions—defining attribution of rights and responsibilities, locking non-local attributes, refining permission boundaries, intercepting abnormal operations, and ensuring source data consistency—it thoroughly solves the key pain points of traditional family shared calendars: loose permissions for modifying third-party synchronized schedules, easy unauthorized operations by non-creators, malicious spoofing of local schedules to bypass permissions, creators accidentally modifying third-party native data, and security vulnerabilities caused by single permission verification. On the one hand, the storage synchronized schedule... The process is linked to a unique identifier of the creator, which fundamentally defines the subject of modification authority and solves the problem of modification chaos caused by unclear rights and responsibilities. Traditional solutions, if the creator's identity is not clearly bound, can easily lead to extreme situations where multiple people synchronize the same third-party schedule, and anyone can make changes or no one can make changes. In this invention, the creator, as the initiator of the synchronization operation, has their unique identifier strongly bound to the schedule. This ensures that the responsibility of whoever synchronizes has the right to modify, and provides an accurate basis for subsequent identity verification. It also prevents non-creators from accidentally or maliciously modifying sensitive schedules synchronized by others due to ambiguous identities, thus ensuring the security of synchronized schedules from the source of permissions. On the other hand, by locking the non-local creation attribute of the synchronized schedule through the third-party log association identifier and triggering exclusive permission rules that can only be modified by the creator, the vulnerability of bypassing permissions by faking a local schedule is completely plugged. If traditional solutions cannot distinguish between synchronized third-party schedules and locally created schedules, attackers or members who make mistakes may disguise synchronized schedules as local schedules, thereby bypassing the permission restrictions for third-party synchronized schedules. In this invention, the third-party log association identifier serves as the identity mark of the synchronized schedule. The server can quickly identify the non-local attribute of the schedule by verifying the existence of this identifier. If the request initiator attempts to disguise the synchronized schedule as a local schedule to modify it without authorization, the server will immediately detect the abnormal absence or tampering of the third-party identifier and directly reject the abnormal request, ensuring that the exclusive permission rules are not circumvented and avoiding the loss of control over permissions due to attribute faking. Meanwhile, the detailed design of standardized permission rules solves the problem of the imbalance between flexibility and security caused by the traditional one-size-fits-all permission approach. The permission type division clearly defines the specific scope of modification operations, and all modification permissions belong to the creator by default. This avoids the creator being unaware of the scope of modifications due to ambiguous permissions, and also prevents non-creators from accessing modification functions. The permission exclusion rules explicitly exclude modification permissions for non-creators, retaining only basic permissions such as viewing schedule details and receiving notifications. This meets the needs of family sharing while preventing unauthorized operations by non-creators, balancing the convenience of sharing with data security. It is especially suitable for family members such as the elderly and children who are not familiar with permission operations, reducing their risk of accidental operation.Furthermore, the multi-level execution control process, which includes identity verification, identifier and permission rule verification, and native field protection, further strengthens the rigor of permission restrictions and the consistency of source data. When the server receives a modification request, it first verifies whether the initiator's identity matches the creator's unique identifier. If they do not match, the request is rejected directly, filtering out the vast majority of unauthorized requests. If the identity matches, the server then confirms the schedule attributes by combining the identifier associated with the third-party logs. At the same time, it controls the scope of modification according to standardized permission rules, ensuring that the creator can only modify content within their permissions. Locked fields such as the native ID of the third-party schedule are key to the association between the synchronized schedule and the third-party source data. Prohibiting the creator from modifying this field can prevent the synchronized schedule from becoming disconnected from the third-party calendar source data due to field tampering, ensuring the consistency between the synchronized schedule and the third-party source data and avoiding collaborative chaos caused by data mismatch. This invention forms a closed-loop protection system covering permission attribution, attribute identification, rule execution, risk interception, and data consistency. It ensures that non-creators cannot modify data without authorization, prevents creators from tampering with third-party native data, and intercepts abnormal operations such as attribute spoofing. It completely solves the problems of crudeness and vulnerabilities in traditional permission restrictions, allowing family members to confidently synchronize and share third-party calendars without worrying about data being accidentally modified, tampered with, or losing control of permissions. It significantly improves the security, reliability, and user trust of family shared calendars, especially in complex family scenarios involving multiple members, multiple devices, and multiple third-party calendar synchronizations, demonstrating strong practicality and protection capabilities.

[0036] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0037] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0038] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0039] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0040] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0041] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A method for sharing and synchronously storing schedules among multiple family members, characterized in that, Includes the following steps: The schedule information is stored on the server side, including a list of participants, a list of visible people, and information about the creator. The client obtains the schedule data of the third-party calendar through the application programming interface provided by the third-party calendar, and synchronizes the schedule of the third-party calendar to the server. The server stores the associated data related to the third-party calendar, including the schedule ID, time zone information when the schedule was created, and calendar identifier in the third-party calendar. Based on the list of visible people, the synchronized third-party calendar events are shared to the clients of the corresponding family members, and permission restrictions are imposed on modification operations of the synchronized third-party calendar events based on the creator's identity information, fine-grained permission configuration information, and third-party log association identifier.

2. The method for sharing and synchronously storing schedules among multiple family members as described in claim 1, characterized in that, The server also stores the time zone settings of each family member. When the server sends a schedule notification to a family member's client, it calculates the local time corresponding to the schedule based on the time zone of the family member receiving the notification and triggers the notification push at the local time. If the time zone of a family member changes, the server updates the member's time zone configuration in real time and recalculates the push time of subsequent schedule notifications.

3. The method for sharing and synchronously storing schedules among multiple family members as described in claim 1, characterized in that, The server stores fine-grained permission information, which includes viewing, editing, and deleting permissions for synchronized third-party calendar events. Only the creator of the synchronized event has editing and deletion permissions, while other family members only have viewing permissions. When the server receives a request to modify the synchronized schedule, it first verifies the requester's identity and permission level. Only if the requester is the creator of the synchronized schedule will the corresponding modification operation be allowed, and the schedule display of all visible clients will be updated synchronously.

4. The method for sharing and synchronously storing schedules among multiple family members as described in claim 3, characterized in that, The server is configured with a scheduled synchronization task that sends synchronization detection commands to the client at preset times, triggering the client to check for schedule updates in the third-party calendar through the application programming interface of the third-party calendar. If new, modified, or deleted schedule data is detected, the client uploads the updated complete schedule data to the server. The server then updates the stored schedule information and related data synchronously and pushes update notifications to the clients of those who can see the schedule, ensuring the consistency of schedule data for all users.

5. The method for sharing and synchronously storing schedules among multiple family members as described in claim 1, characterized in that, The server encrypts the stored schedule information, associated data, and permission information. The encryption key is dynamically generated by the server and bound to the user account. Specifically: After a user successfully completes identity authentication, the server dynamically generates an encryption key by combining the user's unique account identifier and a randomly generated cryptographic salt value through a key derivation function. The encryption key is bound to the user account and stored in the key management module on the server. Each user account corresponds to a unique encryption key, and the encryption keys of different family members are isolated from each other; When transmitting various types of data between the client and the server, an encrypted channel is established using a preset security protocol, and a verification code is added to the transmitted data.

6. The method for sharing and synchronously storing schedules among multiple family members as described in claim 5, characterized in that, The server employs a layered encryption mechanism when storing the encryption key: The encryption key is encrypted and protected using a master key, which is stored in a hardware security module. The encryption key is temporarily decrypted in memory only when it is necessary to encrypt or decrypt user data. The server periodically rotates the encryption key, and the key rotation process includes: Generate a new encryption key; After decrypting the encrypted data using the old key, re-encrypt it using the new key. Update the key binding relationship and securely destroy the old key.

7. The method for sharing and synchronously storing schedules among multiple family members as described in claim 5, characterized in that, The step of adding a checksum to the transmitted data includes: Generate a checksum based on the shared key pair for transmitted data; The verification code is appended to the transmitted data and sent together; The receiver verifies the validity of the checksum; if the verification fails, the receiver refuses to process the data. The range of the verification code generation includes the complete payload and key header information of the transmitted data, ensuring data integrity and authenticity of the source; When the server detects abnormal transmission behavior, it immediately terminates the current session and forces a re-establishment of the encrypted channel.

8. The method for sharing and synchronously storing schedules among multiple family members as described in claim 1, characterized in that, The server supports creators to customize multi-dimensional schedule notification rules, which include advance notification time, repetition frequency, and notification channels. The server sends precise notification messages to the clients of corresponding family members in different time periods based on the start time of the synchronized schedule, the time zone configuration of family members, and the customized notification rules.

9. The method for sharing and synchronously storing schedules among multiple family members as described in claim 1, characterized in that, When multiple family members synchronize the same third-party calendar, the server detects whether there is a schedule conflict by constructing a schedule feature vector. The constructed schedule feature vector includes a time range, a list of participants, a schedule topic, and a summary of core content. When a conflict is detected, the server sends a conflict alert message to the clients of the family members involved in the conflict and dynamically provides conflict resolution options based on a preset priority strategy, including: The conflict resolution options include merging conflicting schedules, selecting schedules to display first, and customizing the time range. First priority judgment: Determine whether the number of participants in at least one of the conflicting schedules exceeds the preset participation threshold, or whether the matching degree between the schedule topic and the preset keyword list exceeds the third preset threshold. If so, provide the option to select the schedule to be displayed first; otherwise, proceed directly to the second priority judgment process. Second priority judgment: Determine whether the topic similarity of the conflicting schedules is higher than the first preset threshold, but the repetition of the core content summary is lower than the second preset threshold. If so, provide the option to merge the conflicting schedules; otherwise, proceed directly to the third priority judgment process. Third priority judgment: Determine whether the proportion of the overlapping part of the time interval of conflicting schedules to the total duration of a single schedule is lower than the fourth preset threshold. If so, provide the option to adjust the time interval; otherwise, enter the default strategy process. The default strategy process involves providing three conflict resolution options simultaneously in the conflict notification message, allowing users to choose the option that best suits their needs.

10. The method for sharing and synchronously storing schedules among multiple family members as described in claim 1, characterized in that, The steps for restricting access to modifying synchronized third-party calendar events based on the creator's identity information, fine-grained permission configuration information, and third-party log association identifiers include: When storing synchronized third-party calendar events, the unique identifier of the event creator and the third-party log association identifier are associated and recorded. Based on the preset standardized permission rules of the third-party calendar events, the standardized permission rules are associated and saved with the stored data of the event. The unique identifier of the creator includes the account ID or client device binding ID of the family member who initiated the third-party calendar synchronization operation. The third-party log association identifier includes the unique identifier of the third-party calendar and the native ID of the third-party event. The standardized permission rules include permission type division and permission exclusion rules. When the server receives a request to modify a synchronized third-party calendar event, it verifies whether the identity of the request initiator matches the unique identifier of the creator. If the identity of the request initiator does not match the unique identity of the creator, the modification request will be rejected directly. If the identity of the request initiator matches the unique identifier of the creator, the execution of the modification operation is further controlled based on the third-party log association identifier and the standardized permission rules.

Images