Home sharing calendar photo frame system and control method based on websocket and incremental update

Abstract

The application discloses a family sharing calendar photo frame system and control method based on WebSocket and incremental update, comprising a server backend, a calendar photo frame device end and a mobile phone end, the three ends establish communication through a WebSocket long connection, and the server end attributes each terminal under the same family account to the same family session group. The mobile phone end or the calendar photo frame device end generates a change data packet containing a version number in response to a data editing operation and uploads the change data packet to the server end; the server end generates an incremental update packet based on the version number difference and pushes the incremental update packet to other terminals in the family session group through the WebSocket long connection; and the receiving terminal parses the incremental update packet and performs local data merging and interface refreshing. The application realizes multi-terminal data second-level real-time synchronization, reduces data transmission volume by more than 70%, and effectively solves the problems of family information fragmentation and high synchronization delay.

Description

Technical Field

[0001] This invention belongs to the field of home collaborative management and smart terminal interaction technology, and particularly relates to a home shared calendar photo frame system and control method based on WebSocket and incremental updates. Background Technology

[0002] Currently, home management products and electronic photo frames in the smart home field are generally independent and functionally fragmented. Traditional electronic photo frames only support photo slideshows within local storage cards or local area networks, making remote photo pushing difficult and lacking real-time interaction capabilities with external network services. Functions such as family schedule management, household chores assignment, family member message communication, weekly meal planning, and household item location recording are provided independently by different mobile applications. The data formats, account systems, and synchronization mechanisms of these applications are different, making data sharing impossible. Multi-terminal data synchronization is mostly achieved through timed HTTP polling or full data downloads, with terminals periodically sending query requests to the server to detect data changes or periodically downloading the complete database record set for local overwriting. The market lacks a complete solution that integrates six functions—family calendar schedule, household chores and reward points, photo frame slideshow, family message board, weekly meal planning, and household item list—into a single, deeply integrated solution with dedicated calendar photo frame hardware.

[0003] However, the aforementioned existing technologies have the following drawbacks. First, the multi-terminal synchronization mechanism is outdated. The timed polling method results in data synchronization delays of tens of seconds, and the frequent sending of invalid query requests by terminals causes a serious waste of network bandwidth and server resources. The full update method, as data volume increases, requires the transmission of hundreds of KB or even several MB of data per synchronization, leading to high bandwidth consumption, long synchronization times, and reduced battery life of terminal devices. Second, family information display is fragmented. Schedules, tasks, photos, messages, meals, items, and other information are scattered across different applications. The family lacks a centralized public terminal for displaying all information; the calendar frame only serves as a photo display device and cannot integrate family schedules, tasks, messages, points rewards, etc., resulting in low device utilization. Third, household task management lacks a closed-loop incentive mechanism. Existing task management applications only provide task assignment and completion marking functions; task completion is disconnected from points rewards, lacking immediate and visible incentive feedback, making it difficult to effectively cultivate children's sense of responsibility and good habits. Fourth, calendar synchronization has poor compatibility. Existing family calendar solutions cannot achieve stable two-way synchronization with mainstream external calendar platforms such as Google Calendar, Apple iCloud Calendar, and Microsoft Outlook Calendar. Users need to manually repeat the schedule across different platforms, making multi-terminal collaboration inconvenient. Summary of the Invention

[0004] To overcome the aforementioned shortcomings of the prior art, this invention provides a family shared calendar photo frame system and control method based on WebSocket and incremental updates, which solves the problems of fragmented family management functions, high synchronization latency, low photo frame utilization, lack of task incentives, poor compatibility with external calendars, and inability to achieve real-time collaboration and integrated information display across multiple terminals in the prior art.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] A family-shared calendar and photo frame system based on WebSocket and incremental updates, including:

[0007] Server backend, calendar frame device end and mobile phone end;

[0008] The calendar frame device and the mobile phone respectively establish a WebSocket long connection with the server backend. After the identity authentication is passed, the server backend assigns each terminal under the same family account to the same family-level session group.

[0009] The mobile phone terminal and / or the calendar frame device terminal generate a change data packet in response to the data editing operation and upload it to the server backend. The change data packet includes a version number, operation type, target data identifier, and change content. The version number is assigned by the server backend in a monotonically increasing sequence.

[0010] The server backend receives the change data packet and persists it, and generates an incremental update package based on the difference between the current latest version number and the version number in the change data packet. The incremental update package includes a baseline version number, a target version number, and a list of change records.

[0011] The server backend pushes the incremental update package to other terminals within the home session group via the WebSocket long connection.

[0012] The receiving terminal parses the incremental update package, performs insertion, update or deletion operations on the local data according to the change record list, and writes the target version number into the local storage as the updated current version number;

[0013] The calendar photo frame device renders family calendar information, household chores information, reward points information, family messages information, meal plan information, and photo carousel information as independent layers, and combines the layers into a single display screen according to a preset layer stacking order.

[0014] Preferably, the server backend further includes a family account and permission management module, which includes a user registration unit, a family group creation unit, an identity authentication unit, and a permission control unit. The user registration unit is configured to receive user registration requests, assign a unique user identifier to each registered user, and store it in a user table. The family group creation unit is configured to receive a family creation request from a first user, generate a unique family identifier and a family invitation code, receive a joining request from a second user by entering the family invitation code, associate the second user's user identifier with the family identifier to generate a family member record. The family member record includes at least a family identifier field, a user identifier field, and a role field. The role field can take the values ​​of parent role and child role. The identity authentication unit is configured to receive a WebSocket handshake request initiated by a terminal, verify the validity of the user credentials carried in the handshake request, and establish a WebSocket long connection after successful verification. The permission control unit is configured to control operation permissions according to the value of the role field when performing data operations. The parent role is allowed to perform all operation types, while the child role is only allowed to perform add operations, modify data created by itself or assigned to itself, and delete data created by itself.

[0015] Preferably, the server backend further includes an incremental update and version control module, which includes a conflict resolution unit. The conflict resolution unit is configured to: when a first change data packet and a second change data packet for the same data identifier are received within a first time period, compare their timestamps and write them sequentially according to the order of their timestamps; when a modification operation is performed on the same field for the same data identifier, overwrite the field value of the earlier timestamp with the field value of the later timestamp, and record the overwritten field value in the change history table; the first time period is 1 to 5 seconds; the version number is assigned separately for each family-level session group, all data changes within the same family-level session group share the same version number increment sequence, and the version numbers between different family-level session groups are independent of each other; the version number is stored in a version number counter table, which at least includes a current maximum version number field and a last update timestamp field.

[0016] Preferably, the WebSocket long connection is equipped with a keep-alive mechanism. The keep-alive mechanism sends ping frames to the terminal at preset time intervals. After receiving the ping frame, the terminal returns a pong frame. If the server backend does not receive the pong frame within a preset number of consecutive times, it determines that the WebSocket long connection is broken, and the session management module removes the corresponding terminal from the terminal connection list. The preset time interval is 30 seconds to 120 seconds, and the preset number of times is 3 to 5. If the WebSocket long connection corresponding to the terminal is in a broken state, the server backend stores the incremental update packet to be pushed for the terminal in a message queue, and reads and pushes it from the message queue after the terminal re-establishes the connection.

[0017] Preferably, the data persistence module includes a relational database and a non-relational database; the relational database stores structured data tables, including user tables, family tables, family member tables, calendar event tables, task tables, reward record tables, message tables, meal plan tables, and item list tables; the non-relational database stores photo file data, thumbnail data, and device configuration data; each change record in the change record list of the incremental update package also includes a checksum calculated using the SHA-256 algorithm. After receiving the incremental update package, the receiving terminal calculates its local checksum using the same algorithm and compares it with the received checksum. If they do not match, it sends a retransmission request to the server backend.

[0018] The control method for a family shared calendar photo frame based on WebSocket and incremental updates includes the following steps:

[0019] S1: The calendar frame device and the mobile phone terminal establish a WebSocket long connection with the server backend respectively to complete the family account binding and identity authentication. The server backend maintains a family-level session group for each terminal under the same family account.

[0020] S2: In response to the data editing operation, the mobile phone terminal or the calendar frame device terminal generates a change data packet containing a version number, operation type, target data identifier, and changed content, and uploads it to the server backend; the version number is assigned by the server backend in a monotonically increasing sequence;

[0021] S3: The server backend receives the change data packet and persists it, and generates an incremental update package based on the difference between the current latest version number and the version number in the change data packet. The incremental update package includes a baseline version number, a target version number, and a list of change records.

[0022] S4: The server backend pushes the incremental update package to other terminals within the home session group via the WebSocket long connection;

[0023] S5: The receiving terminal parses the incremental update package, performs insertion, update or deletion operations on the local data according to the change record list, writes the target version number into the local storage as the updated current version number, and refreshes the interface display;

[0024] S6: The calendar frame device renders family calendar information, household chores information, reward points information, family message information, meal plan information and photo carousel information as independent layers, and combines the layers into the same display screen according to the preset layer stacking order.

[0025] Preferably, in step S3, the server backend maintains a version chain, which is constructed as a unidirectional linked list structure with version numbers as nodes and time sequence as edges. The version chain supports breakpoint resumption: when the receiving terminal detects a transmission interruption during the reception of incremental update packets, it sends a resumption request to the server backend containing the local current version number and the received target version number. The server backend regenerates the incremental update packet and pushes it with the received target version number as the starting version number and the first unsynchronized version number after the local current version number as the ending version number. The deletion operation is a logical deletion, that is, the record status field of the deleted data entry is set to the deleted state. The data entry itself is retained in the data persistence module. The record status field includes normal state and deleted state. The data query operation only reads data entries in the normal state.

[0026] Preferably, in step S4, the incremental update package includes a change record of structured data and / or photo data blocks; for photo data, the server backend transmits thumbnails and original images in stages: the server backend receives the original photo image uploaded by the mobile phone terminal, generates a first thumbnail according to a first preset size and pushes it to the calendar frame device terminal, the width of the first preset size is 200 pixels to 400 pixels, and the height is scaled proportionally according to the aspect ratio of the original image; the calendar frame device terminal receives and displays the first thumbnail and returns a confirmation message; after receiving the confirmation message, the server backend divides the original photo image into multiple data blocks according to a preset block size and pushes them sequentially, the preset block size is 4KB to 64KB; after receiving all data blocks, the calendar frame device terminal reassembles them into a complete original photo image according to the block sequence number and stores it.

[0027] Preferably, the system also includes a task reward closed-loop control step: Parents publish household chores tasks via the mobile phone, including a task title, task description, reward diamond quantity, and executor user identifier; the server backend writes the task record into the task table and pushes it to each terminal; the child submits a task completion request via the terminal, including a task identifier and submitter user identifier; the server backend updates the task status to pending review and pushes it; after parental approval, the server backend updates the task status to completed, generates a reward distribution record in the reward record table based on the reward diamond quantity, and updates the diamond points accumulation field in the family member table; if the parent rejects the request, the task status is updated to rejected and no reward distribution record is generated; the server backend pushes the task status change and diamond point change to the calendar frame device in the form of incremental update packages; the calendar frame device updates the status indicator of the corresponding task card and the total diamond points in the top status bar.

[0028] Preferably, it also includes at least one of the following steps:

[0029] Meal planning and shopping list generation steps: The mobile phone responds to the meal planning operation to generate a weekly meal plan data package containing date field, meal number field and dish name field and uploads it to the server backend. The server backend retrieves the ingredient list corresponding to each dish in the ingredient mapping table, aggregates and summarizes by ingredient name and calculates the total demand of each ingredient to generate a shopping list. The weekly meal plan is pushed to the calendar frame device and the shopping list is pushed to the mobile phone.

[0030] External calendar two-way synchronization steps: The server backend sends a synchronization request containing an authorization token and the last synchronization timestamp to the external calendar platform at a third preset time interval, which is 1 minute to 10 minutes. During the first synchronization, the last synchronization timestamp is empty, and schedule data is retrieved by looking back 30 days from the current time. The external calendar synchronization adapter parses the returned schedule data and writes it into the calendar event table, pushing it to each terminal in the form of incremental update packages. After a schedule event is created or modified locally, the server backend converts the schedule event into a format supported by the external calendar platform and synchronizes it to that platform. The external calendar platform includes at least one of Google Calendar, Apple iCloud Calendar, and Microsoft Outlook Calendar.

[0031] Household Items List Management Steps: The mobile app, in response to an item entry operation, generates an item data package containing the item name, location, and photo, which is then uploaded to the server backend. The server backend writes the item record into the item list table and pushes it as an incremental update package to all other terminals within the same household-level session group. Each terminal receives the data, stores it in its local data cache, and displays it in a list or grid view on the item list interface. In response to a search operation, the mobile app performs a string matching search in its local data cache based on item name and / or item location and displays the matching results.

[0032] The technical effects and advantages of this invention, which uses a WebSocket and incremental update-based family shared calendar photo frame system and control method, are as follows:

[0033] 1. This invention employs a version number-based incremental update mechanism. Terminals only upload changed fields, new entries, deletion identifiers, and version differences, without transmitting the full data. The server generates incremental update packages based on version number differences and establishes a version index, supporting range queries and breakpoint resumption. Compared to existing technologies that use periodic polling or full updates, this invention reduces data transmission volume by 70% to 95% in typical home use scenarios. Simultaneously, the server actively pushes incremental update packages downlink via a WebSocket long connection, with a push latency of less than 1 second, avoiding invalid requests and network resource waste caused by polling mechanisms, and achieving low-latency, low-traffic, and low-power real-time synchronization across multiple terminals.

[0034] 2. This invention incorporates a keep-alive mechanism on WebSocket long-lived connections. It detects connection status using ping / pong frames at preset time intervals, promptly clearing invalid connections and releasing resources. When the terminal goes offline, the server stores the incremental update packets to be pushed in a message queue. Upon re-establishing the connection, the terminal reads and pushes these packets from the message queue, supporting resume functionality. This mechanism effectively solves the problems of connection interruption and message loss caused by unstable Wi-Fi signals, router restarts, and device hibernation in real-world home network environments, ensuring reliable message delivery under unreliable network conditions.

[0035] 3. This invention integrates six functions—family calendar, household chores, reward points, family messages, meal plans, and photo carousel—into a single calendar frame device. These six types of information are simultaneously displayed on the same screen using layered rendering and semi-transparent overlay technology. Each layer has an independent Z-axis index value and display area, ensuring that information is not obscured and is clearly layered. Compared to existing solutions where various family management functions are scattered across different applications and platforms, and data cannot be shared, this invention eliminates information silos. Family members can view all family activities at a glance through the calendar frame device placed in a common area. The calendar frame device is upgraded from a simple photo player to a family information hub, significantly improving device utilization and family collaborative management efficiency.

[0036] 4. This invention provides a complete closed-loop control scheme for task rewards: Parents post household chores and specify reward points; after the child completes the task, it is submitted for review; upon parental approval, the system automatically issues points. Points are synchronized to the calendar frame device in real time and updated accordingly. Accumulated points can be redeemed for rewards. Compared to existing task management applications that only provide task assignment and completion markers, lack incentive mechanisms, and have a disconnect between task completion and reward distribution, this invention forms a complete automated closed loop from task posting to point redemption. All status changes are synchronized to the calendar frame in real time, making task status and point changes instantly visible. This creates immediate and visual positive incentives, effectively cultivating a sense of responsibility and time management skills among family members, especially children.

[0037] 5. This invention establishes a two-way synchronization mechanism with mainstream external calendar platforms such as Google Calendar, Apple iCloud Calendar, and Microsoft Outlook Calendar through an external calendar synchronization adapter. On one hand, it retrieves schedule changes from the external calendar platform at preset time intervals and pushes them to the calendar frame device; on the other hand, it converts locally created schedule events into a format supported by the external calendar platform and synchronizes them to that platform. Compared with existing technologies where home calendar systems only import data one way to external calendar platforms or cannot interconnect, this invention achieves two-way data consistency between the system and mainstream external calendar platforms. Users can manage schedules within the system or continue using their preferred external calendar applications, broadly adapting to the usage habits of different family users.

[0038] 6. This invention employs a phased transmission strategy for photo data, prioritizing thumbnails and transmitting the original image in chunks. After receiving the original photo, the server first generates thumbnails and pushes them to the calendar frame device, allowing users to preview the photo content instantly. Once the thumbnails are confirmed as received, the original image is then pushed in chunks of a preset size, with each chunk having a block number and checksum, supporting error retransmission and resume functionality. Compared to existing technologies that directly transmit complete photo files, this invention effectively avoids blocking the transmission of other structured data over the WebSocket long connection during large data transfers, ensuring a smooth photo browsing experience even under low-bandwidth network conditions.

[0039] 7. This invention implements hierarchical permission control for parent and child roles through a family account and permission management module. Parents are allowed to perform all operation types, including administrative operations such as creating tasks, approving tasks, and modifying family configurations; children are only allowed to perform add operations, modify data they created or assigned to themselves, and delete data they created. This hierarchical permission mechanism ensures that different family members share the same family data space while each having operation boundaries appropriate to their role, effectively preventing accidental data deletion and configuration changes, and improving the orderliness and security of family collaborative management.

[0040] 8. This invention provides an automatic meal plan and shopping list generation function. Based on the user's weekly meal plan, the server retrieves the corresponding ingredient list for each dish from the ingredient mapping table, aggregates and summarizes the ingredients by name, calculates the total demand for each ingredient, automatically generates a shopping list, and pushes it to all terminals, reducing the time cost of family shopping planning and preventing the omission of ingredients. It also provides a household item list management function. After the user enters the item name, location, and photo, the data is synchronized to all terminals within the same family-level session group in the form of incremental update packages. It supports multi-terminal fuzzy search, helping family members quickly locate items and improving the efficiency of household item management. Attached Figure Description

[0041] Figure 1 This is a system framework diagram of the family shared calendar photo frame system based on WebSocket and incremental updates proposed in this invention. Detailed Implementation

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

[0043] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include," "contain," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that includes 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 "includes..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0044] refer to Figure 1 This invention provides a home-shared calendar frame system based on WebSocket and incremental updates, consisting of three parts: a server backend, a calendar frame device, and a mobile phone client. The server backend is deployed on a cloud server or a local home server, running a Linux operating system, built using the Spring Boot framework, and embedding a Tomcat container as a web application server. The calendar frame device is a smart hardware device with a display screen, which is a liquid crystal display or an organic light-emitting diode display with a resolution of 1024×600 pixels to 1920×1080 pixels. The device has a built-in communication module, processor, and memory. The communication module includes at least one of a Wi-Fi communication unit and an Ethernet communication unit. The processor is an ARM Cortex-A series processor, and the memory is flash memory with a storage capacity of 8GB to 64GB. The mobile phone client is a smartphone running an iOS or Android operating system, with the corresponding mobile application of this invention installed.

[0045] The server backend includes a first WebSocket communication module and a session management module. The calendar frame device includes a second WebSocket communication module, and the mobile phone device includes a third WebSocket communication module. The calendar frame device and the server backend establish a first WebSocket long connection through the second WebSocket communication module and the first WebSocket communication module, and the mobile phone device and the server backend establish a second WebSocket long connection through the third WebSocket communication module and the first WebSocket communication module.

[0046] The session management module is configured to: verify the validity of user credentials carried by both the calendar frame device and the mobile phone; establish a corresponding WebSocket long connection upon successful verification; and assign the calendar frame device and mobile phone under the same family account to the same family-level session group. User credentials include a combination of user identifier and dynamic token, or a combination of username and password. Each family-level session group has a unique group identifier, and the session management module maintains a list of terminal connections within each family-level session group.

[0047] The server backend also includes an incremental update and version control module and a data persistence module. The incremental update and version control module is configured to receive change data packets and generate incremental update packets. The data persistence module includes relational and non-relational databases; the relational database uses MySQL or PostgreSQL, and the non-relational database uses MongoDB or MinIO object storage. The server backend also includes a push module, configured to push incremental update packets to other terminals within the home session group via a WebSocket persistent connection.

[0048] The calendar frame device also includes an incremental merging module, a display control module, and a layered rendering module. The incremental merging module is configured to parse the received incremental update packets and perform local data merging. The layered rendering module is configured to render family calendar information, household chores information, reward points information, family messages information, meal plans information, and photo carousel information as separate layers. The display control module combines these layers into a single display image according to a preset layer stacking order and outputs it to the calendar frame device's display screen.

[0049] The mobile app also includes a data operation response module, configured to generate change data packets in response to user data editing operations and upload them to the server backend.

[0050] In one specific implementation, when the mobile phone client launches the application for the first time, the user registers an account using their mobile phone number or email address. The server backend assigns a unique user identifier to each registered user and stores it in a user table. After the user logs in, the server backend issues a token containing a user identifier field and an expiration time field. When the calendar frame device is powered on for the first time, a device binding QR code is displayed. The user scans this QR code with their mobile phone to complete the binding of the device to their home. Subsequently, both the calendar frame device and the mobile phone client include user credentials in the handshake request each time a WebSocket connection is established. The server backend verifies the validity of the credentials, and allows the connection to be established after successful verification.

[0051] The control method provided by the present invention includes steps S1 to S6.

[0052] Step S1: Connection establishment and authentication.

[0053] The purpose of this step is to establish a secure communication channel between each terminal and the server, and to complete the terminal grouping at the home level.

[0054] Both the calendar frame device and the mobile phone initiate a WebSocket handshake request to the server backend, containing user credentials. The server backend's first WebSocket communication module receives the handshake request, and the session management module parses the user credentials in the request, verifying their validity and correctness. Upon successful verification, the server backend establishes a long-lived WebSocket connection and queries the family member table based on the user identifier in the user credentials to obtain the family identifier to which the user belongs, adding the terminal to the corresponding family-level session group. The session management module maintains the terminal connection list for the family-level session group, using the family identifier as the key and the list of session identifiers for all online terminals under that family as the value. The session management module maintains family-level session groups for all terminals under the same family account.

[0055] In a specific example, family A has three devices: the father's mobile phone, the mother's mobile phone, and a living room calendar picture frame. After each of the three devices establishes a WebSocket long connection with the server backend, the session management module maintains a list of device connections for the family in Redis, containing three session identifiers.

[0056] Step S2: Data editing and change data package generation.

[0057] The purpose of this step is to convert user data editing operations into standardized incremental change data packages, providing a data foundation for subsequent incremental updates.

[0058] In response to user data editing operations, the mobile app or calendar / photo frame device generates a data change log according to a preset format, retrieves the current version number assigned by the server backend, associates the version number with the data change log, generates a change data package, and uploads it to the server backend. Data editing operations include adding data entries, modifying partial field values ​​of existing data entries, and deleting existing data entries. Data uploaded after modification only includes the name and new value of the modified field, excluding the existing values ​​of unmodified fields. Version numbers are assigned by the server backend in a monotonically increasing sequence after each successful data change operation. Version numbers are assigned separately for each family-level session group; all data changes within the same family-level session group share the same version number increment sequence, while version numbers between different family-level session groups are independent. Version numbers are stored in a version number counter table, which contains at least the current maximum version number field and the last update timestamp field.

[0059] A change data packet must contain at least the following fields: version number, operation type, target data identifier, change content, and timestamp. The operation type field can contain values ​​for add, modify, and delete operations. For add operations, the change content field contains all field values ​​for the new entry. For modify operations, the change content field only contains the name and new value of the modified field. For delete operations, the change content field is empty, and the target data identifier field is a unique identifier for the deleted data entry.

[0060] In a specific scenario, the mother adds a new event to the family calendar via a mobile phone. The mobile phone's data operation response module generates a change data packet corresponding to the local version number. The version number field is the current local version number of the terminal, the operation type field is "add operation", the target data identifier field is a temporary unique identifier generated locally by the mobile phone, the change content field includes the event's title, start time, end time, calendar identifier, and color identifier, and the timestamp field is the current Unix timestamp.

[0061] In another scenario, a user modifies the title of an existing scheduled event. The operation type field of the data packet is set to "modify," and the change content field only contains the new value of the title field, excluding the existing values ​​of unmodified fields such as start time and end time.

[0062] Step S3: Incremental update package generation.

[0063] The purpose of this step is to compare the received change data with the existing version chain on the server and generate an incremental update package containing only the difference data, so as to minimize the amount of data transmitted over the network.

[0064] The server backend receives change data packets, writes the changes to the data persistence module according to the operation type, and after successful writing, generates incremental update packets based on the difference between the current latest version number and the version number in the change data packet, establishing a version index. The incremental update packet includes a baseline version number field, a target version number field, and a change record list field. The change record list field contains at least one change record, and each change record includes the version number, operation type, target data identifier, and change content corresponding to the change.

[0065] The incremental update and version control module on the server backend first persistently stores the current changed data, assigns a globally unique identifier to the newly added data, writes the data into the corresponding data table, and then increments the current maximum version number in the version number counter table. Next, based on the difference between the current latest version number and the version number in the change data package, it queries the version index table to obtain all change records from the version number in the change data package plus 1 to the current latest version number, and organizes these change records into an incremental update package.

[0066] The version index table uses the version number as the key and the set of change records corresponding to that version number as the value. It is stored in the data persistence module using a B+ tree data structure and supports range queries based on any start version number and end version number.

[0067] In a specific example, the server backend receives a change data packet from the mother's mobile phone, with version number 1042. A query of the version number counter table shows the current maximum version number for this family is 1051. Therefore, the server backend needs to generate an incremental update package from version 1043 to version 1051. The incremental update and version control module queries the version index table to obtain all change records from version 1043 to 1051, constructs the incremental update package, where the baseline version number field is 1042, the target version number field is 1051, and the change record list field contains the change records for each version.

[0068] Each change record in the change record list of the incremental update package also includes a checksum field, which is the hash value calculated using the SHA-256 algorithm for all the contents of the change record.

[0069] Step S4: Push the incremental update package.

[0070] The purpose of this step is to proactively push incremental update packages to other terminals within the home via the established WebSocket long connection, achieving real-time synchronization within seconds.

[0071] The server backend pushes incremental update packets to other terminals within the home session group via a WebSocket long-lived connection. The push module iterates through the terminal connection list of the home session group. For each terminal in the list, it checks if the terminal's unique identifier matches the unique identifier of the terminal that uploaded the change data packet. If they do not match, the incremental update packet is sent through the corresponding WebSocket long-lived connection. The push latency is less than 1 second.

[0072] The incremental update package contains at least one of the following: a change log of structured data and photo data blocks. For photo data, the server backend transmits thumbnails and original images in stages: The server backend receives the original photo uploaded by the mobile phone, generates a first thumbnail according to a first preset size, and pushes it to the calendar frame device. The width of the first preset size is 200 to 400 pixels, and the height is scaled proportionally to the aspect ratio of the original image. After receiving and displaying the first thumbnail, the calendar frame device returns a confirmation message. After receiving the confirmation message, the server backend divides the original photo into multiple data blocks according to a preset block size, which are pushed sequentially. The preset block size is 4KB to 64KB. After receiving all the data blocks, the calendar frame device reassembles them into a complete original photo according to the block number and stores it.

[0073] The technical effect of this step is that by using the proactive push capability of WebSocket long connection, the delay of several seconds to tens of seconds of the traditional polling mechanism is avoided, and real-time synchronization of data of multiple terminals within the family is achieved.

[0074] Step S5: Incremental update package parsing and local merging.

[0075] The purpose of this step is to enable the receiving terminal to correctly parse the incremental update package and merge the changed data into local storage, thus maintaining the consistency between local data and server-side data.

[0076] The receiving terminal parses the incremental update package, performs insert, update, or delete operations on the corresponding data in the local storage according to each change record in the change record list field, writes the value of the target version number field in the incremental update package into the local storage of the receiving terminal as the updated current version number, and refreshes the interface display.

[0077] Upon receiving the incremental update packet, the incremental merging module of the receiving terminal extracts each change record from the change record list fields and performs the corresponding operation according to the value of the operation type field. For insert operations, a new record is created in the local database, with field values ​​taken from the change content field. For update operations, the corresponding local record is found based on the target data identifier field, and the field values ​​from the change content field are updated in that record; fields not appearing in the change content field retain their original values. For delete operations, the corresponding local record is found based on the target data identifier field, and the record status field of that record is set to deleted; the data entry itself is retained in the local database. Data query operations only read data entries whose record status field value is in the normal state.

[0078] After all changes are processed, the receiving terminal updates the current version number stored locally from the original baseline version number to the target version number and refreshes the interface display.

[0079] In a specific example, the living room calendar frame device receives an incremental update package with a baseline version number of 1042 and a target version number of 1051. The incremental merging module on the calendar frame device iterates through each change record in the change log list, processing each change from version 1043 to 1051 sequentially, including updating task status, adding messages, and adding schedule events. After all changes are processed, the locally stored current version number is updated from 1042 to 1051, and the display interface is refreshed. Schedule events are added to the calendar grid view, new messages are displayed in the message board area, and the corresponding tasks in the task cards are shown as completed.

[0080] Step S6: Multi-information fusion display.

[0081] The purpose of this step is to integrate and present six types of family information in a layered manner on the same display screen, making the calendar frame device a central hub for displaying family information.

[0082] The calendar frame device renders family calendar information, household chores information, reward points information, family messages information, meal plan information, and photo carousel information as separate layers, and combines the layers into a single display screen according to the preset layer stacking order.

[0083] The display is layered along the Z-axis. The photo carousel, as the background layer, is at the bottom with a Z-index of 0. It automatically switches photos at preset intervals of 5 to 30 seconds. The family calendar information is displayed as a calendar grid view on the second layer with a Z-index of 1. The background of the grid view is semi-transparent with a transparency of 30% to 60%. Meal plan information is displayed as a list at the bottom of the screen with a Z-index of 2, occupying 15% to 25% of the total screen height. Household chores are displayed as overlaid task cards with a Z-index of 3. These cards are arranged from top to bottom according to priority and are displayed in the middle of the screen. Each task card includes a task title, the executor's name, and the number of reward diamonds. Completed task cards are displayed in grayscale. Reward points are displayed as a status bar at the top of the screen with a Z-index of 4, occupying 5% to 10% of the total screen height. The status bar displays at least the current logged-in user's total diamond points and the number of rewards that can be redeemed. Family messages are displayed in the side area of ​​the screen as either a pop-up or a persistent note, with a Z-axis index of 5. When a new message update package is received, the floating pop-up appears with a sliding animation from right to left, and after being displayed for 5 to 15 seconds, it automatically shrinks into an icon and remains in the upper right corner of the screen.

[0084] The technical effect of this step is that, through layered rendering and semi-transparent overlay technology, six types of family information are presented simultaneously on the same display screen. The information does not obscure each other and is clearly layered, allowing users to easily obtain all family dynamics.

[0085] This invention sets up a keep-alive mechanism and an offline message queue mechanism for WebSocket long connections.

[0086] The specific implementation of the survival mechanism:

[0087] The session management module on the server backend starts an independent keep-alive timer for each WebSocket long-lived connection. Taking the first WebSocket long-lived connection between the calendar frame device and the server backend as an example: the keep-alive timer sends ping frames to the calendar frame device at a first preset time interval. The second WebSocket communication module on the calendar frame device returns a corresponding pong frame after receiving the ping frame. If the server backend does not receive a pong frame within a first preset number of consecutive times, it determines that the WebSocket long-lived connection has been broken, and the session management module removes the terminal from the terminal connection list. The first preset time interval is 30 seconds to 120 seconds, and the first preset number of times is 3 to 5.

[0088] Ping and pong frames are control frames natively supported by the WebSocket protocol. They do not carry application-layer data and are used only for connection liveness detection.

[0089] Specific implementation of the offline message queue mechanism:

[0090] If the WebSocket long connection corresponding to a certain terminal is in a disconnected state, the push module stores the incremental update packets to be pushed to that terminal in a message queue. The message queue uses the terminal identifier as the partition key and stores messages in a first-in-first-out order. Each message has an expiration time, and messages that have not been consumed after the expiration time are automatically deleted.

[0091] When an offline terminal re-establishes a WebSocket persistent connection, it includes its current version number in the WebSocket handshake request. After successful authentication by the server's backend authentication unit, a new connection is established, and the session management module re-adds the terminal to the home-level session group's terminal connection list. Subsequently, the push module reads all pending incremental update packages from the message queue and pushes them sequentially in ascending order of version number. If there are many accumulated changes during the offline period, the push module merges multiple incremental update packages into a single batch for push.

[0092] In one specific example, the living room calendar frame went offline for two hours due to a home router restart. During this time, family members added three schedule events, modified the status of two tasks, and posted one message via their mobile phones. After the calendar frame came back online, the server backend merged all six change records into a single incremental update package and pushed it to the calendar frame, allowing the calendar frame to complete the merging of all local data and a refresh of the interface in one go.

[0093] The technical advantages of this embodiment are: timely detection of connection status through the ping / pong keep-alive mechanism, and ensuring that messages from offline terminals are not lost through the offline message queue, thereby achieving reliable message delivery under unreliable network conditions and improving the robustness of the system.

[0094] Example of closed-loop control for task rewards:

[0095] The purpose of this embodiment is to fully describe the automated closed-loop control process of household chores from posting, execution, review to the distribution of points rewards, so that those skilled in the art can understand each link of the task reward closed loop and its data flow.

[0096] Scenario setting: In a family, the father and mother are the parents, and the child, Xiaoming, is the child. The calendar frame in the living room displays task and points information in real time.

[0097] Step 1: Parents assign tasks.

[0098] The purpose of this step is to enable parents to create household chores and assign responsibilities and reward points via mobile devices.

[0099] Parents access the task posting interface via their mobile phones, entering the task title, description, reward diamond quantity, and designated executor. The mobile phone's data operation response module generates a task data package and uploads it to the server backend. This task data package includes at least the following fields: task title, task description, reward diamond quantity, executor user identifier, and posting user identifier. The server backend receives the task data package, writes the task record to the task table in the data persistence module, initially setting the task status field to "pending execution." It then generates a corresponding incremental update package and pushes it to both the calendar frame device and the mobile phone via a WebSocket long connection.

[0100] After the calendar frame device receives the incremental update package, it creates a new task card in the middle area of ​​the display screen. The card displays the task title, task description, executor's name, and the number of reward diamonds. The task status indicator shows that it is in the pending execution state.

[0101] Step 2: The child submits a task completion request.

[0102] The purpose of this step is to enable children to submit a completion request via a calendar frame or mobile phone after completing the task, thus triggering the review process.

[0103] The child submits a task completion request via a mobile phone or calendar / photo frame device. The request must include at least a task identifier and the submitter's user identifier. The mobile phone or calendar / photo frame device encapsulates the task completion request into a change data packet and uploads it to the server backend. The operation type field of the change data packet is set to "modify," and the new value for the task status field in the change content field is "pending review." The server backend receives the task completion request, updates the task status field of the corresponding task record in the task table to "pending review," and generates a corresponding incremental update packet, which is then pushed to both the calendar / photo frame device and the mobile phone.

[0104] The status indicator for the task card on the calendar frame changes from "Pending Execution" to "Pending Review".

[0105] Step 3: Parental review.

[0106] The purpose of this step is to enable parents to review their children's task completion requests and decide whether to award reward points based on the actual completion status.

[0107] Parents review task completion requests via mobile app, with review options including approval or rejection. If a parent approves, the server backend updates the task status field of the corresponding task record in the task table to "completed." Based on the reward diamond quantity field in the task record, a reward distribution record is generated in the reward record table. This record includes a user identifier field (valued as the executor's user identifier), a diamond quantity change field (valued as positive and equal to the reward diamond quantity), and a reason for change field (valued as "task completion reward"). Simultaneously, the accumulated diamond points field for that user in the family member table is updated. If a parent rejects, the server backend updates the task status field of the corresponding task record in the task table to "rejected," but no reward distribution record is generated.

[0108] The server backend pushes changes to task status and diamond points to the calendar frame device in the form of incremental update packages.

[0109] Step 4: Interface update and points redemption.

[0110] The purpose of this step is to reflect the task status and score changes in real time on the calendar frame display interface, forming a visual incentive feedback.

[0111] The calendar frame device receives an incremental update package, updating the status indicator of the corresponding task card in the display interface and updating the total number of diamond points for the corresponding user in the top status bar. The task card changes from pending review to completed, and the entire card becomes grayscale; the child's total number of diamond points in the top status bar increases by the corresponding number of reward diamonds. When the child's accumulated diamond points reach the redemption threshold, the child opens the reward shop interface on their mobile phone and selects a reward to redeem. After the server backend verifies that the points balance is sufficient, it deducts the corresponding points, updates the accumulated diamond points field in the family member table, and pushes the points change to the calendar frame in the form of an incremental update package. The total number of diamond points in the top status bar of the calendar frame decreases accordingly.

[0112] The technical effect of this embodiment is that it forms a complete automated closed loop from task posting to points redemption. All status changes are synchronized to the calendar frame in real time. Children can view the task progress and points changes in real time on the calendar frame without opening their mobile phones, which effectively cultivates children's sense of responsibility and time management ability.

[0113] V. Example of phased photo transmission and external calendar synchronization

[0114] The purpose of this embodiment is to describe the efficient photo data transmission strategy and the two-way synchronization mechanism of the external calendar platform in this invention, so that those skilled in the art can realize the reliable phased transmission of large files and the interconnection of calendar data across multiple platforms.

[0115] The specific implementation of phased photo transmission:

[0116] Photo data is typically large in size. If the original image is transmitted directly via a WebSocket long connection, it may block the real-time push of other structured data. Therefore, this invention adopts a phased strategy of prioritizing thumbnails and transmitting the original image in chunks.

[0117] Phase 1: Quick thumbnail display.

[0118] The goal of this stage is to enable the calendar frame to quickly preview photo content, thereby improving the user experience.

[0119] The mobile app responds to the user's photo selection by reading the photo file, which can be in JPEG, PNG, or HEIC format. If the original image is in HEIC format, the mobile app converts it to JPEG before uploading. The mobile app then generates a photo data packet and uploads it to the server backend. This photo data packet contains the photo's binary data, photo name, uploader's user identifier, and upload timestamp.

[0120] After receiving the original photo, the server backend calls the image processing service to generate two thumbnails of different sizes. The first thumbnail is 200 to 400 pixels wide and its height is scaled proportionally to the original image's aspect ratio; it is used for the carousel display on the calendar frame device. The second thumbnail is 50 to 100 pixels wide and its height is scaled proportionally to the original image's aspect ratio; it is used for the thumbnail index view on the calendar frame device.

[0121] The server backend encapsulates the binary data of the first thumbnail and its corresponding metadata into an incremental update package, which is then pushed to the calendar frame device via a WebSocket long connection. Because the first thumbnail is small, the push time is typically less than 50 milliseconds, allowing the calendar frame device to display a preview of the photo almost instantly. After receiving and displaying the first thumbnail, the calendar frame device sends a thumbnail reception confirmation message back to the server backend.

[0122] Second stage: Transmission of original image in chunks.

[0123] The goal of this phase is to achieve reliable transmission of large file photos and support resume transmission when interrupted.

[0124] After receiving the thumbnail reception confirmation message, the server backend begins transmitting the original photo. The server backend divides the binary data of the original photo into multiple data blocks according to a preset block size, assigning a block number to each data block. These data blocks are then pushed sequentially to the calendar frame device via a WebSocket long connection. The preset block size is 4KB to 64KB. Each data block message includes a photo identifier, block number, total number of blocks, binary data, and a checksum. Upon receiving each data block, the calendar frame device calculates its checksum and compares it with the checksum in the message. If they match, the data block is stored; otherwise, a retransmission request is sent to the server backend. After receiving all data blocks, the calendar frame device reassembles them into a complete original photo image according to the block numbers in ascending order, stores it in local flash memory, and adjusts the display resolution of the original photo image to match the screen resolution of the calendar frame device before outputting it for display.

[0125] If the transmission is interrupted, the calendar frame device may have already received some data blocks. After the connection is re-established, the calendar frame device sends a resume request to the server backend, including the photo identifier and the sequence number of the largest block already received. The server backend then continues pushing data starting from the next block sequence number.

[0126] Specific implementation of external calendar two-way synchronization:

[0127] This invention supports bidirectional synchronization with mainstream external calendar platforms such as Google Calendar, Apple iCloud Calendar, and Microsoft Outlook Calendar.

[0128] Synchronization Direction 1: Synchronization from external calendars to this system.

[0129] The purpose of this stage is to import the schedule events that users have created on external calendar platforms into this system and push them to the calendar frame in real time.

[0130] The server backend establishes a connection with the external calendar platform through an external calendar synchronization adapter. The communication protocol between the external calendar synchronization adapter and the external calendar platform is HTTPS, and the data exchange format is JSON or iCalendar. The external calendar synchronization adapter implements corresponding authentication and authorization submodules and data format conversion submodules for each external calendar platform.

[0131] The external calendar sync adapter sends a synchronization request to the external calendar platform via the application programming interface provided by the external calendar platform at a third preset time interval. The synchronization request includes an authorization token and the last synchronization timestamp. The third preset time interval is 1 to 10 minutes. During the first synchronization, the last synchronization timestamp is empty, and the external calendar sync adapter retrieves schedule data 30 days backward from the current time.

[0132] The external calendar platform returns schedule data that has changed since the last synchronization timestamp. The external calendar synchronization adapter parses the schedule data and writes the parsed schedule events into the calendar event table of the data persistence module. Each schedule event must include at least the event unique identifier from the external calendar platform, title, start time, end time, all-day flag, and repetition rule. The server backend pushes the newly added or changed schedule events to the calendar frame device and mobile phone client via a WebSocket long connection in the form of incremental update packets.

[0133] Synchronization direction two: Synchronization between this system and external calendars.

[0134] The purpose of this stage is to synchronize the schedule events created by users in this system to external calendar platforms to achieve two-way data consistency.

[0135] When a schedule event is created or modified locally on a mobile phone or calendar frame device, the server backend converts the schedule event into a schedule data format supported by the external calendar platform. Then, through the external calendar synchronization adapter, it calls the external calendar platform's application programming interface to synchronize the schedule event to the external calendar platform. After synchronization is complete, the external calendar synchronization adapter receives a unique event identifier from the external calendar platform and stores this identifier in the corresponding record in the calendar event table.

[0136] In a specific example, the mother creates a new event in the family calendar via her mobile phone. This event is pushed to the calendar frame and the father's phone in real time via an incremental update mechanism. Simultaneously, the external calendar sync adapter synchronizes the event to the mother's Google Calendar in the next sync cycle. Subsequently, if the mother modifies the event time on the Google Calendar web client, the external calendar sync adapter will retrieve the change in the next sync cycle, synchronize the change to the local system, and push it to the calendar frame.

[0137] The technical advantages of this embodiment are as follows: by prioritizing thumbnails and using a chunked transmission strategy, smooth transmission and resume transmission of large-size photos under low bandwidth conditions are achieved; by using a bidirectional synchronization adapter, bidirectional data consistency between this system and mainstream external calendar platforms is achieved, allowing users to manage their schedules in this system or continue using their preferred external calendar applications.

[0138] The purpose of this invention is to describe specific implementation methods for meal planning, automatic generation of shopping lists, and management of household items lists, so that those skilled in the art can understand the data flow and interaction logic of the household life management auxiliary functions.

[0139] Specific implementation of meal planning and shopping list generation:

[0140] Users access the meal plan interface via their mobile phones. The interface displays the meal plan from Monday to Sunday in a weekly view, with each day divided into four meal sessions: breakfast, lunch, dinner, and a snack. Users select dishes for each meal session.

[0141] The mobile app responds to the user's meal planning actions by generating a weekly meal plan data package and uploading it to the server backend. This weekly meal plan data package includes at least the following fields: family identifier, date, meal number, dish name, and recipe link. The meal number field can contain values ​​for breakfast, lunch, dinner, and snacks. The server backend receives the weekly meal plan data package and writes the meal plan records into the meal plan table of the data persistence module.

[0142] The server backend retrieves the corresponding ingredient list for each dish name from the ingredient mapping table based on the dish name field for each meal and date in the weekly meal plan data package. The ingredient mapping table is pre-stored in the data persistence module and includes at least the dish name field, ingredient name field, and ingredient quantity field. The server backend then aggregates and summarizes the ingredient lists for all dates and all meals by ingredient name, calculates the total demand for each ingredient, and generates a shopping list.

[0143] For example, a weekly meal plan includes three servings of scrambled eggs with tomatoes and two servings of braised fish. The ingredient map shows that scrambled eggs with tomatoes requires 200g of tomatoes and 2 eggs, while braised fish requires 500g of grass carp and 10g of ginger. The server backend aggregates and generates a shopping list: 600g of tomatoes, 6 eggs, 1000g of grass carp, and 20g of ginger.

[0144] The server backend pushes the weekly meal plan as an incremental update package to the calendar frame device, and simultaneously pushes the shopping list as an incremental update package to all mobile devices within the same family-level chat group. After receiving the weekly meal plan update package, the calendar frame device displays the names of the three daily meals in a weekly view at the bottom of the screen, with the column corresponding to the current date highlighted. After receiving the shopping list update package, the mobile devices display all ingredient names and their corresponding total quantities in a list format. Each ingredient item has a checkbox on the left; when a user checks a checkbox, the ingredient item is marked as purchased with a strikethrough, and the purchased status is synchronized to all mobile devices within the same family-level chat group.

[0145] Specific implementation of household items inventory management:

[0146] In response to the user's item entry operation, the mobile app generates an item data package and uploads it to the server backend. The item data package includes at least three fields: item name, item location, and item photo. The item photo field contains either the binary data of the photo file or the photo file's storage path. The server backend receives the item data package, generates an item identifier, writes the item record to the item list table in the data persistence module, and stores the binary data of the item photo in a non-relational database. The server backend then pushes the item record as incremental update packets to all other terminals within the same home-level session group via a WebSocket persistent connection.

[0147] After receiving the incremental update package, the mobile phone and calendar / photo frame devices store the item records in the local data cache and display the item name, location, and photo of each item in a list or grid view on the item list interface. In response to the user's search operation, the mobile phone performs a string matching search in the local data cache based on at least one of the item name and item location fields. String matching search supports fuzzy matching, meaning that a successful match is considered achieved when the search keyword matches part of the characters in the item name or item location fields, and the matching item records are displayed in list format.

[0148] In a specific scenario, an elderly person in the family urgently needs a band-aid but cannot remember where they put it. By opening the item list interface on the calendar frame device and entering search keywords, the system can retrieve and display the matching item records and their location information from the local cache.

[0149] The technical advantages of this embodiment are as follows: the automatic generation of meal plans and shopping lists reduces the time cost of family purchasing planning and avoids missing ingredients; the family item list, through multi-terminal sharing and fuzzy search functions, helps family members quickly locate the items, improving the efficiency of family item management.

[0150] Comparative Example 1

[0151] Traditional electronic photo frame systems based on polling mechanisms.

[0152] Traditional electronic photo frame systems in the present technology use an HTTP polling mechanism to update data. The photo frame device sends an HTTP GET request to the server every 30 to 60 seconds to inquire whether there are any new photos or messages. After receiving the request, the server returns the current full data or a simple yes / no indicator.

[0153] Compared with the present invention, this solution has the following technical defects:

[0154] First, the real-time performance is poor. The polling interval is 30 to 60 seconds, meaning there could be a delay of up to 60 seconds from the time a data change occurs to the actual display update in the picture frame. In this invention, the latency of WebSocket long-connection push is less than 1 second, improving real-time performance by more than 60 times. In emergency task notification scenarios, after a parent posts a time-limited task, the child needs to see the task on the picture frame almost instantly. A 60-second delay might cause the child to miss the task notification, while the second-level push of this invention ensures that the child sees the task update immediately.

[0155] Secondly, there is significant resource waste. Even without any data changes, the picture frame still needs to send an HTTP request every 30 seconds, and the server needs to process the request and return a response. Assuming a picture frame runs 24 hours a day, this results in approximately 2880 invalid requests per day. If a household has multiple terminals, the server would need to handle a large number of invalid polling requests each month. In this invention, the WebSocket long connection only transmits data when data changes; otherwise, it only transmits ping / pong keep-alive frames, reducing network overhead by over 99%.

[0156] Third, high power consumption. Frequent HTTP request and response processing requires the frame's Wi-Fi module and processor to be frequently woken up, resulting in a significant reduction in the battery life of battery-powered devices. The long-connection push mechanism adopted in this invention only briefly wakes up the processor when receiving push data, and remains in a low-power standby state most of the time.

[0157] Fourth, full data transmission. Traditional solutions often transmit the entire photo file when new photos are added. If multiple new photos are added simultaneously, the data transmission volume is large and the time consumption is long. The incremental update mechanism of this invention only transmits changed fields and differential data. The photos adopt a thumbnail-first and original image block transmission strategy, resulting in a smooth user experience.

[0158] Comparative Example 2

[0159] A collection of home management applications with fragmented functions.

[0160] In existing technologies, functions such as family schedule management, family task management, family photo albums, and family message boards are scattered across different applications or platforms, and data cannot be shared. A family may need to use multiple different applications simultaneously to perform functions such as calendar viewing, task assignment, photo sharing, and message communication.

[0161] Compared with the present invention, this solution has the following technical defects:

[0162] First, there's the issue of information silos. Scheduled events and household chores are unrelated; parents might set a timer for a family cleaning in the calendar, but this timer cannot be automatically converted into an assignable, trackable, and rewarding task. This invention's six-in-one integrated display presents the calendar, tasks, rewards, messages, meals, and photos all within the same calendar frame interface, allowing scheduled events and task cards to interact in the same view.

[0163] Second, multi-device synchronization is inconvenient. Each application maintains its own independent account system and synchronization mechanism, requiring family members to add each other and set sharing permissions separately in each application. The unified family account system and family-level session group mechanism of this invention allow for one-time family creation and one-time member addition, with all functional modules sharing the same family data and synchronization channel.

[0164] Third, there is a lack of a unified terminal for displaying family information. Schedules are viewed on mobile phones, tasks are viewed in task management apps, and photos are viewed in photo album apps; there is no single device to centrally display all family information. The calendar photo frame device of this invention serves as a central hub for family information, placed in public areas such as the living room, allowing all family members to view all family information at a glance as they pass by.

[0165] Fourth, there is a lack of task incentives. Existing task management applications only provide task assignment and completion marking functions, lacking a closed-loop reward system. After a child completes a task, they are only marked as completed within the application, lacking immediate and visible incentive feedback. The task reward closed loop of this invention provides diamond points immediately upon task completion, points are displayed in real-time in the status bar at the top of the calendar frame, and points can be redeemed for rewards, forming a complete incentive loop.

[0166] Comparative Example 3

[0167] A calendar synchronization solution without incremental updates.

[0168] Existing calendar synchronization solutions typically use a full synchronization method. Each time the client synchronizes, it downloads all calendar events from the server, compares them with all local events, and then determines whether to add, modify, or delete them. As the number of calendar events accumulates, the data volume of each full synchronization can reach hundreds of KB or even several MB, resulting in long synchronization times and high data consumption.

[0169] The incremental update mechanism based on version numbers in this invention requires each terminal to maintain only its current local version number. During each synchronization, the server only pushes the difference in change records between that version number and the latest version number. In typical home use scenarios, the number of daily changed schedule events usually does not exceed 10, and the data size of the incremental update package is usually between 1KB and 5KB. Compared with the hundreds of KB of full synchronization, the data transmission volume is reduced by more than 95%.

[0170] Technical Effect Comparison Summary:

[0171] Regarding push latency, traditional polling schemes take 30 to 60 seconds, while this invention takes less than 1 second. Regarding network request volume, traditional polling schemes require 2880 HTTP requests per terminal per day, while this invention only requires 1440 ping / pong keep-alive frames. Regarding data synchronization methods, traditional schemes use full data transmission, while this invention uses incremental and differential transmission. Regarding functional integration, traditional schemes have functions scattered across multiple applications, while this invention provides a unified interface for all six functions. Regarding task incentive loops, traditional schemes lack this feature, while this invention provides a complete loop for tasks, points, and rewards. Regarding external calendar synchronization, traditional schemes are unidirectional or asynchronous, while this invention provides bidirectional real-time synchronization. Regarding photo transmission strategies, traditional schemes transmit the original image directly, while this invention prioritizes thumbnails and then transmits the original image in chunks.

[0172] In summary, this invention effectively solves the technical problems of poor real-time performance, resource waste, functional fragmentation, and lack of incentives in existing technologies by using WebSocket long-connection and home-level session group mechanism, version number-based incremental update mechanism, six-in-one multi-information fusion display, automated closed-loop task reward, and bidirectional synchronization with external calendar, achieving significant technical results.

[0173] 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 protection of the claims.

[0174] In conclusion, the above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A family-shared calendar photo frame system based on WebSocket and incremental updates, characterized in that: include: Server backend, calendar frame device end and mobile phone end; The calendar frame device and the mobile phone respectively establish a WebSocket long connection with the server backend. After the identity authentication is passed, the server backend assigns each terminal under the same family account to the same family-level session group. The mobile phone terminal and / or the calendar frame device terminal generate a change data packet in response to the data editing operation and upload it to the server backend. The change data packet includes a version number, operation type, target data identifier, and change content. The version number is assigned by the server backend in a monotonically increasing sequence. The server backend receives the change data packet and persists it, and generates an incremental update package based on the difference between the current latest version number and the version number in the change data packet. The incremental update package includes a baseline version number, a target version number, and a list of change records. The server backend pushes the incremental update package to other terminals within the home session group via the WebSocket long connection. The receiving terminal parses the incremental update package, performs insertion, update or deletion operations on the local data according to the change record list, and writes the target version number into the local storage as the updated current version number; The calendar photo frame device renders family calendar information, household chores information, reward points information, family messages information, meal plan information, and photo carousel information as independent layers, and combines the layers into a single display screen according to a preset layer stacking order.

2. The family shared calendar photo frame system based on WebSocket and incremental updates as described in claim 1, characterized in that, The server backend also includes a family account and permission management module, which includes a user registration unit, a family group creation unit, an identity authentication unit, and a permission control unit. The user registration unit is configured to receive user registration requests, assign a unique user identifier to each registered user, and store it in the user table. The family group creation unit is configured to receive a family creation request from a first user, generate a unique family identifier and a family invitation code, receive a joining request initiated by a second user by entering the family invitation code, associate the second user's user identifier with the family identifier to generate a family member record, the family member record includes at least a family identifier field, a user identifier field, and a role field, the role field including parent role and child role; the identity authentication unit is configured to receive a WebSocket handshake request initiated by a terminal, verify the validity of the user credentials carried in the handshake request, and establish a WebSocket long connection after successful verification; the permission control unit is configured to control operation permissions according to the value of the role field when performing data operations, the parent role is allowed to perform all operation types, the child role is only allowed to perform add operations, modify data created by itself or assigned to itself, and delete data created by itself.

3. The family shared calendar photo frame system based on WebSocket and incremental updates as described in claim 1, characterized in that, The server backend also includes an incremental update and version control module, which includes a conflict resolution unit. The conflict resolution unit is configured to: when a first change data packet and a second change data packet for the same data identifier are received within a first time period, compare their timestamps and write them sequentially according to the order of their timestamps. When modifying the same field for the same data identifier, the field value with the later timestamp is overwritten with the field value with the earlier timestamp, and the overwritten field value is recorded in the change history table. The first time period is from 1 second to 5 seconds; the version number is assigned separately for each family-level session group, and all data changes within the same family-level session group share the same version number increment sequence, while the version numbers of different family-level session groups are independent of each other; the version number is stored in a version number counter table, which at least includes a current maximum version number field and a last update timestamp field.

4. The family shared calendar photo frame system based on WebSocket and incremental updates as described in claim 1, characterized in that, The WebSocket long connection is equipped with a keep-alive mechanism. The keep-alive mechanism sends ping frames to the terminal at preset time intervals. After receiving the ping frame, the terminal returns a pong frame. If the server backend does not receive the pong frame within a preset number of consecutive times, it determines that the WebSocket long connection is broken, and the session management module removes the corresponding terminal from the terminal connection list. The preset time interval is 30 seconds to 120 seconds, and the preset number of times is 3 to 5. If the WebSocket long connection corresponding to the terminal is in a broken state, the server backend stores the incremental update packet to be pushed for the terminal in a message queue, and reads and pushes it from the message queue after the terminal re-establishes the connection.

5. The family shared calendar photo frame system based on WebSocket and incremental updates as described in claim 1, characterized in that, The data persistence module includes a relational database and a non-relational database. The relational database stores structured data tables, including user tables, family tables, family member tables, calendar event tables, task tables, reward record tables, message tables, meal plan tables, and item list tables. The non-relational database stores photo file data, thumbnail data, and device configuration data. Each change record in the change record list of the incremental update package also includes a checksum calculated using the SHA-256 algorithm. After receiving the incremental update package, the receiving terminal calculates its local checksum using the same algorithm and compares it with the received checksum. If they do not match, a retransmission request is sent to the server backend.

6. A control method for a family shared calendar photo frame based on WebSocket and incremental updates, applied to the family shared calendar photo frame system based on WebSocket and incremental updates as described in any one of claims 1-5, characterized in that, Includes the following steps: S1: The calendar frame device and the mobile phone terminal establish a WebSocket long connection with the server backend respectively to complete the family account binding and identity authentication. The server backend maintains a family-level session group for each terminal under the same family account. S2: In response to the data editing operation, the mobile phone terminal or the calendar frame device terminal generates a change data packet containing a version number, operation type, target data identifier, and changed content, and uploads it to the server backend; the version number is assigned by the server backend in a monotonically increasing sequence; S3: The server backend receives the change data packet and persists it, and generates an incremental update package based on the difference between the current latest version number and the version number in the change data packet. The incremental update package includes a baseline version number, a target version number, and a list of change records. S4: The server backend pushes the incremental update package to other terminals within the home session group via the WebSocket long connection; S5: The receiving terminal parses the incremental update package, performs insertion, update or deletion operations on the local data according to the change record list, writes the target version number into the local storage as the updated current version number, and refreshes the interface display; S6: The calendar frame device renders family calendar information, household chores information, reward points information, family message information, meal plan information and photo carousel information as independent layers, and combines the layers into the same display screen according to the preset layer stacking order.

7. The control method for a family shared calendar photo frame based on WebSocket and incremental updates as described in claim 6, characterized in that, In step S3, the server backend maintains a version chain, which is constructed as a singly linked list structure with version numbers as nodes and time sequence as edges. The version chain supports breakpoint resumption: when the receiving terminal detects a transmission interruption during the reception of incremental update packets, it sends a resumption request to the server backend containing the local current version number and the received target version number. The server backend regenerates the incremental update packet and pushes it with the received target version number as the starting version number and the first unsynchronized version number after the local current version number as the ending version number. The deletion operation is a logical deletion, that is, the record status field of the deleted data entry is set to the value of "deleted". The data entry itself is retained in the data persistence module. The value of the record status field includes normal status and deleted status. The data query operation only reads data entries in the normal status.

8. The control method for a family shared calendar photo frame based on WebSocket and incremental updates as described in claim 6, characterized in that, In step S4, the incremental update package includes a change record of structured data and / or a photo data block; for the photo data, the server backend transmits the thumbnail and the original image in stages: the server backend receives the original photo uploaded by the mobile phone terminal, generates a first thumbnail according to a first preset size and pushes it to the calendar frame device terminal, the width of the first preset size is 200 pixels to 400 pixels, and the height is scaled proportionally according to the aspect ratio of the original image; After receiving and displaying the first thumbnail, the calendar photo frame device returns a confirmation message; after receiving the confirmation message, the server backend divides the original photo into multiple data blocks according to a preset block size and pushes them sequentially, with the preset block size ranging from 4KB to 64KB; after receiving all the data blocks, the calendar photo frame device reassembles them into a complete original photo according to the block number and stores it.

9. The control method for a family shared calendar photo frame based on WebSocket and incremental updates as described in claim 6, characterized in that, The system also includes a closed-loop control process for task rewards: Parents publish household chores tasks via the mobile app, including a task title, task description, reward diamond quantity, and executor user identifier. The server backend writes the task record into the task table and pushes it to each terminal. Children submit task completion requests via the terminal, including a task identifier and submitter user identifier. The server backend updates the task status to pending review and pushes it. After parental approval, the server backend updates the task status to completed, generates a reward distribution record in the reward record table based on the reward diamond quantity, and updates the diamond points accumulation field in the family member table. If the parent rejects the request, the task status is updated to rejected and no reward distribution record is generated. The server backend pushes task status changes and diamond point changes to the calendar frame device in the form of incremental update packages. The calendar frame device updates the status indicator of the corresponding task card and the total number of diamond points in the top status bar.

10. The control method for a family shared calendar photo frame based on WebSocket and incremental updates as described in claim 6, characterized in that, It also includes at least one of the following steps: Meal planning and shopping list generation steps: The mobile phone responds to the meal planning operation to generate a weekly meal plan data package containing date field, meal number field and dish name field and uploads it to the server backend. The server backend retrieves the ingredient list corresponding to each dish in the ingredient mapping table, aggregates and summarizes by ingredient name and calculates the total demand of each ingredient to generate a shopping list. The weekly meal plan is pushed to the calendar frame device and the shopping list is pushed to the mobile phone. External calendar two-way synchronization steps: The server backend sends a synchronization request containing an authorization token and the last synchronization timestamp to the external calendar platform through the external calendar synchronization adapter at a third preset time interval. The third preset time interval is 1 minute to 10 minutes. The last synchronization timestamp is empty during the first synchronization. The schedule data is obtained by going back 30 days from the current moment. The external calendar synchronization adapter parses the returned schedule data and writes it into the calendar event table, then pushes it to each terminal in the form of incremental update packages. After a schedule event is created or modified locally, the server backend converts the schedule event into a format supported by the external calendar platform and synchronizes it to that platform. The external calendar platform includes at least one of Google Calendar, Apple iCloud Calendar, and Microsoft Outlook Calendar. Household Items List Management Steps: The mobile phone terminal responds to the item entry operation by generating an item data package containing the item name, item location, and item photo, which is then uploaded to the server backend. The server backend writes the item record into the item list table and pushes it to all other terminals in the same household-level session group in the form of incremental update packages. Each terminal receives the data and stores it in its local data cache, then displays it in a list or grid view on the item list interface. The mobile phone responds to the search operation by performing string matching search in the local data cache according to the item name and / or item location and displays the matching results.

Images