Smart watch notification priority scheduling method based on context awareness

Abstract

The invention discloses a smart watch notification priority scheduling method based on context awareness, and relates to the technical field of smart device notification scheduling, and the method comprises the steps: initial queue filing, unified access of notifications, field filing and index establishment; carrying out conflict judgment based on the notification attribute parameters and the context sensing parameters, and dynamically mediating a notification sending strategy; performing grouping display, content summarization and throttling control on the plurality of notifications according to the two parameters; finally, a final delivery decision is made through a bridging gating strategy in combination with the terminal state and the environment, notifications can be intelligently scheduled according to the user state and the environment, invalid disturbances are reduced, and the intelligence of notification management and the man-machine interaction experience are improved.

Description

Technical Field

[0001] This invention relates to the field of smart device notification scheduling technology, and more specifically, to a context-aware smartwatch notification priority scheduling method. Background Technology

[0002] With the popularization of smart wearable devices, smartwatches have become an important extension device for receiving mobile phone notifications. However, current smartwatches generally adopt a simple notification mirroring mechanism, which synchronizes notifications from the mobile phone to the watch almost indiscriminately. This has led to many problems: in scenarios where users are not suitable for receiving notifications, such as when they are in a meeting, driving, or resting, frequent reminders will cause unnecessary disturbances; while when users are idle, the proliferation of low-value notifications such as advertisements and application updates will interfere with their attention and cause notification overload. Existing technologies fail to dynamically and intelligently prioritize and schedule notifications based on their attributes, such as urgency and type. Therefore, there is an urgent need for a scheduling method that can understand the context and make intelligent decisions on when and how to deliver notifications, so as to ensure that important information is delivered in a timely manner while minimizing irrelevant interference to users and improving the human-computer interaction experience.

[0003] To address the above problems, this invention proposes a solution. Summary of the Invention

[0004] To overcome the aforementioned deficiencies of the prior art, embodiments of the present invention provide a context-aware smartwatch notification priority scheduling method to address the problems mentioned in the background section.

[0005] To achieve the above objectives, the present invention provides the following technical solution: A context-aware method for prioritizing smartwatch notifications, including the following steps; Step S1: Extract the identifier of the notification based on the provided sorted snapshot, generate content features for the notification text, construct group index relationships and same-origin retrieval relationships based on the fields, write the notification into the notification scheduling queue, and synchronously maintain the corresponding index structure and group statistics. Step S2: Based on the notification attribute parameters and context-aware parameters, compare the notification written to the notification scheduling queue with the existing notifications to determine whether they belong to the same event or the same message stream. If the same source condition is met, perform update replacement or merging processing on the notification. If the same source condition is not met, retain the notification as an independent entry. Step S3: Within a preset time window, statistics are collected on notifications with the same grouping index relationship. Based on queue changes and context status, the notifications are grouped, summarized, or throttled, and the output format of the notification in the scheduling queue is determined. Step S4: Based on the notification attribute information, sending format marker and terminal status information recorded in the notification scheduling queue, determine whether the notification has been delivered, the delivery method and the synchronization path, and deliver the qualified notifications to the watch end according to the predetermined bridging or mirroring mechanism.

[0006] In a preferred embodiment, step S1 includes the following: When a notification release or update event occurs, extract the fields from the notification object, including at least the application identifier, notification channel identifier, group key, session key, notification tag, notification identifier, notification generation timestamp, whether it can be updated flag, and bridging control flag. Get and provide the active notification sorting snapshot as the sorting snapshot field; The title text and body summary text of the notification object are standardized, and summary features are generated based on the standardized text. Based on the extracted fields, a grouping index key and a same-origin retrieval key are generated. The grouping index key is used to represent the grouping unit to which the notification belongs, and the same-origin retrieval key is used to represent the candidate location unit of the same matter or the same message stream. Create a queue record for the notification and write it to the notification scheduling queue. The queue record includes at least the unique identifier within the queue, the application identifier, the notification channel identifier, the group index key, the same-origin retrieval key, the notification tag, the notification identifier, the notification generation timestamp, the updatable flag, the bridging control flag, the sort snapshot field, and the initial alert level field. Build a group index based on the group index key and a same-origin index based on the same-origin retrieval key. Establish a reverse association between the queue record and the index key. Maintain group statistics by group index key, including at least the number of arrivals within the window, the number of currently active entries, the start time of the statistics window, and the most recent arrival time; update the corresponding group statistics synchronously when a queue record is written. When a notification revocation event occurs, locate the corresponding queue record and update its status to invalid. Delete the record from the index based on the reverse association and update the group statistics. Perform cleanup, recycling, or archiving on queue records that are invalid and have exceeded the preset retention period.

[0007] In a preferred embodiment, step S2 includes the following: The system makes a comprehensive judgment based on notification attribute parameters and context-aware parameters. The notification attribute parameters are determined based on the notification level predefined by the application, the notification priority set by the user, or the notification type. The context-aware parameters are determined based on the user's current activity, environmental status, time, or device status. When the priorities indicated by the two parameters are inconsistent, the adjustment is carried out according to the preset rules; If the notification attribute parameter is urgent and the threshold condition is met, a notification will be forcibly sent to the watch and a limited reminder will be used. If the notification attribute parameter is urgent but does not meet the threshold condition, or if the notification attribute parameter is important and the context-aware parameter is do not disturb or busy, then the notification will be marked as delayed. If the notification attribute parameter is set to "Important" and the context-aware parameter is set to "Lightly Busy", then a silent notification will be pushed.

[0008] In a preferred embodiment, step S3 includes the following: The triggering condition of a group is determined by linking the cumulative number of notifications corresponding to the same group index key within the sliding time window with the level of the context-aware parameter. Adjust the level of detail displayed in groups based on context-aware parameter levels; generate summary content based on key information fields of notifications within a group set; add priority markers to the summary content if there are notifications with urgent attribute parameters within a group or if the number of important notifications reaches the summary importance threshold. Adjust the presentation triggering method of summary notifications based on context-aware parameter levels.

[0009] In a preferred embodiment, step S4 includes the following: Privacy information in notifications is identified using text keyword matching and entity recognition technologies, and the matching degree of privacy information is calculated. Determine the degree of environmental misfit by combining context-aware parameters; Based on the combination of privacy information matching degree and environmental incompatibility degree, adjust the presentation of notification content, including displaying only the privacy prompt logo, displaying de-identified content, or displaying the full content; The sending strategy is selected based on the terminal status determination result. The sending strategy includes direct sending, silent sending, alternative sending, or no sending. The conditions for direct sending include notification attribute parameters being urgent or important, stable connection quality, stable watch wearing status, and low mobile phone activity status. Silent sending conditions include notification attribute parameters being at the normal level and the phone's activity level being at the medium active level, or notification attribute parameters being at the low priority level and the watch having sufficient battery power, or connection quality being average and notification attribute parameters not being at the emergency level.

[0010] The technical effects and advantages of the context-aware smartwatch notification priority scheduling method of this invention are as follows: This invention can dynamically assess the importance of a notification and its suitability to the user's current state and environment. By performing conflict determination, grouping, and throttling before notification delivery, it can automatically suppress or delay low-priority notifications when the user is busy or in a sensitive environment, allowing only key information to be delivered in an appropriate manner. Through content sensitivity determination and environmental adaptability checks in the bridging gating strategy, the method can identify notifications containing privacy information and automatically hide or de-identify the specific content in inappropriate environments such as public places, effectively preventing the risk of information leakage and demonstrating respect for user privacy and contextual intelligence. It comprehensively considers the device status of the mobile phone and watch, and follows principles such as prioritizing the main device when making delivery decisions. This avoids sending invalid notifications to watches that are not being worn or have low battery, optimizes inter-device collaboration and overall system energy consumption, and ensures efficient and reliable delivery of notification resources. In summary, this invention transforms the notification system of smartwatches from passive forwarding to active scheduling, significantly improving the intelligence level of notification management, user experience, and device collaboration efficiency. Attached Figure Description

[0011] Figure 1 This is a schematic diagram of the context-aware smartwatch notification priority scheduling method of the present invention. Detailed Implementation

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

[0013] Please see Figure 1 As shown, this invention discloses a context-aware smartwatch notification priority scheduling method, including the following steps: Step S1: Extract the identifier of the notification based on the provided sorted snapshot, generate content features for the notification text, construct group index relationships and same-origin retrieval relationships based on the fields, write the notification into the notification scheduling queue, and synchronously maintain the corresponding index structure and group statistics. Step S2: Based on the notification attribute parameters and context-aware parameters, compare the notification written to the notification scheduling queue with the existing notifications to determine whether they belong to the same event or the same message stream. If the same source condition is met, perform update replacement or merging processing on the notification. If the same source condition is not met, retain the notification as an independent entry. Step S3: Within a preset time window, statistics are collected on notifications with the same grouping index relationship. Based on queue changes and context status, the notifications are grouped, summarized, or throttled, and the output format of the notification in the scheduling queue is determined. Step S4: Based on the notification attribute information, sending format marker and terminal status information recorded in the notification scheduling queue, determine whether the notification has been delivered, the delivery method and the synchronization path, and deliver the qualified notifications to the watch end according to the predetermined bridging or mirroring mechanism.

[0014] In step S1, the identifier of the notification is extracted based on the provided sorted snapshot, content features are generated for the notification text, grouping index relationships and same-origin retrieval relationships are constructed based on the fields, the notification is written into the notification scheduling queue, and the corresponding index structure and grouping statistics are maintained synchronously. Specific content includes: The initial queue archiving is used to uniformly access, archive, index, and maintain statistics of notifications generated on the mobile device before the notification is delivered to the smartwatch, thereby providing a directly callable data foundation for subsequent same-source conflict determination, grouping and summarizing throttling, and delivery gating; When a notification release event or notification update event is generated on the mobile device, the corresponding notification object is notified, and field extraction operations are performed on the notification object, including at least the application identifier, notification channel identifier, group key or session key, notification tag, notification identifier, notification generation timestamp, whether it can be updated flag, and bridging control flag. Obtain the provided active notification sorting snapshot and record the sorting snapshot as a sorting snapshot field. All of the above fields are used as the basic input fields for subsequent scheduling. Secondly, the notification performs a standardization process on the title text and body summary text of the notification recipient. The standardization process includes text normalization, removal of redundant whitespace, and length truncation. Based on the standardized title text and body summary text, a summary feature is generated. The summary feature is used to characterize the stable features of the notification content summary so that subsequent steps can quickly locate candidate notifications from the same source. The notification generates a grouping index key and a same-origin retrieval key based on the extracted fields. The grouping index key is used to represent the grouping unit to which the notification belongs. It is generated based on the session key first. If the session key is empty, it is generated based on the grouping key. If the grouping key is empty, it degenerates into generating based on the application identifier. The same-source retrieval key is used to characterize candidate locating units of the same matter or the same message flow. The same-source retrieval key is generated by at least the combination of application identifier, notification channel identifier, group index key, notification tag and summary feature. After generating the above key-value pairs, a queue record is created for the notification, and the queue record is written to the notification scheduling queue. The queue record includes at least a unique identifier within the queue, an application identifier, a notification channel identifier, a group index key, a same-origin retrieval key, a notification tag, a notification identifier, a notification generation timestamp, an updateability flag, a bridging control flag, a sorting snapshot field, and an initial alert level field. The queue record also includes a status field and a processing flag field. The status field is used to identify the valid status of the queue record, and the processing flag field is used to identify the update replacement result, aggregation candidate result, and sending format result of the notification in subsequent steps. The processing flag field is initialized to empty during initial archiving. The notification establishes a grouping index based on the grouping index key and a same-source index based on the same-source retrieval key; wherein, the grouping index is used to group queue records with the same grouping index key into the same group set, and the same-source index is used to group queue records with the same same-source retrieval key into the same same-source candidate set. To facilitate subsequent revocation and recycling processes, a reverse association is established between queue records and index keys to record the mapping between the unique identifier within the queue and its corresponding group index key and same-origin retrieval key. The notification maintains group statistics information according to the group index key; the group statistics information includes at least the number of arrivals within the window, the number of currently active entries, the start time of the statistics window, and the most recent arrival time. When a queue record is written to the notification scheduling queue, the corresponding group statistics are updated synchronously to determine the group backlog trend and throttling strategy in subsequent steps. When the mobile operating system generates a notification revocation event, the notification locates the corresponding queue record based on the application identifier, notification identifier, and notification tag, updates its status field to invalid, and deletes the queue record from the group index and the same source index according to the reverse association relationship. At the same time, the number of currently active entries in the corresponding group statistics is updated. For queue records that are invalid and have exceeded the preset retention period, perform cleanup, recycling, or archiving processes to limit the queue size and ensure index validity; Through the above implementation of the initial queue filing method, each notification forms a unified queue record before entering the subsequent scheduling steps, and establishes a traceable, searchable, and updatable structural foundation at the queue, index, and statistics levels. This ensures that subsequent steps can complete source conflict determination, grouping and summarizing, and delivery gating without relying on repeated parsing of notification objects.

[0015] In step S2, the notifications written to the notification scheduling queue are compared with existing notifications based on notification attribute parameters and context-aware parameters to determine whether they belong to the same event or the same message stream. If the same-origin condition is met, the notifications are updated, replaced, or merged. If the same-origin condition is not met, the notifications are retained as independent entries. Specific details include: The decision on the appropriate handling strategy for a notification is based on a comprehensive assessment of two key parameters: notification attribute parameters and context-aware parameters. Notification attribute parameters relate to the inherent attributes of the notification itself, mainly reflecting its inherent importance or urgency. Context-aware parameters, on the other hand, are derived from context-aware information, reflecting the influence of the current environment or user state on notification handling. When the tendencies given by the two parameters are inconsistent, a conflict is determined, and mediation is required according to preset rules. The notification attribute parameter reflects the importance or category priority of the notification itself. It can be determined based on the notification level predefined by the application, the notification priority set by the user for the application, the notification type, etc. Notification types include emergency alarms, critical event notifications, daily messages, advertising promotions, application update prompts, etc. The notification level predefined by the application can be read directly through the system interface, and the notification priority set by the user for the application is obtained from the system notification settings. Notifications are typically categorized into several levels: lowest, low, medium, high, and highest. Alternatively, importance can be classified by the notification channel. Notification attribute parameters can be enumerated in terms of levels, specifically including urgent, important, normal, and low priority. The determination rules are as follows: If the notification type belongs to the emergency alarm set, or the application predefined notification level is the highest level and the user has not manually lowered the notification priority of the application, then the notification attribute parameter is determined to be emergency level. If the above emergency level conditions are not met, and the notification type belongs to the critical transaction notification set, or the application's predefined notification level is high and the user has not disabled the application's notifications, then the notification attribute parameter is determined to be of the importance level. If the above importance level conditions are not met, and the notification type belongs to the daily message set, or the notification level predefined by the application is medium, then the notification attribute parameter is determined to be ordinary level. If none of the above conditions are met, the notification attribute parameters will be judged as low priority. The emergency alarm set includes predefined system types such as fire alarm, medical emergency reminder, and emergency contact call. Users can add custom types. The set of critical transaction notifications includes bank transaction confirmations, work meeting notifications, important schedule reminders, etc., and also supports user-defined extensions. Context-aware parameters are derived from the perception of the user's current context and represent the impact of the environment and user state on the user's tolerance for notification disturbances. Context-aware technology can obtain information from many sources, such as sensor data from mobile phones and watches, system modes, and user schedules. Typical contextual factors include the user's current activity, ambient sound or light, time, and device status. The user's current activity includes walking, running, driving, attending a meeting, or sitting quietly. Ambient sound or light includes quiet, noisy, bright, or dark environments. Time includes work hours, rest hours, and sleep periods. Device status includes whether the phone screen is on, whether it is in Do Not Disturb mode, and whether the watch is worn on the wrist. These discrete pieces of information are aggregated into quantifiable context priority indicators. The context-aware parameters are in the form of enumeration levels, specifically including Do Not Disturb, Busy, Lightly Busy, and Idle levels, and the determination rules are as follows: If the system mode is Do Not Disturb mode and no exception notification is set, or the user's current activity is driving, or the user's current activity is a meeting, or the time is within the user's preset sleep period, then the context-aware parameter is determined to be Do Not Disturb level. If the above-mentioned conditions for not disturbing are not met, and the user's current activity is running, or the user's current activity is strenuous exercise, or the ambient sound reaches the noisy environment threshold, or the time is within the user's preset work period and the user's schedule shows as busy, then the context-aware parameter is determined to be busy. If the above busy level conditions are not met, and the user's current activity is walking, or the ambient light is in an unsuitable reading range, or the time is within the user's preset work interval, then the context awareness parameter is determined to be slightly busy. If none of the above conditions are met, the context-aware parameter is determined to be idle. The noisy environment threshold is set based on existing environmental acoustic standards and can be configured by default by the system, allowing users to fine-tune it according to their usage habits. The unsuitable reading area refers to the range where the light is too dim or too bright, which can also be fine-tuned by the user. The user's current activity is determined by combining data from accelerometers and gyroscopes with an activity recognition algorithm. The device status is read directly through the system API, ensuring the feasibility and accuracy of parameter acquisition. Perform conflict determination on notifications, that is, determine whether the notification attribute parameters are consistent with the notification processing priority indicated by the context-aware parameters; If both are high, it means the notification is very important and the user is currently able to receive it, so it can be processed directly according to the higher priority. If both are low, the notification is not important and the user context is not urgent, so it can be handled with low priority, such as being delivered later or displayed silently. Conflicts mainly occur in the following two situations: Scenario 1: High priority for notifications and low priority for context. That is, the notification attribute parameter is urgent or important, while the context-aware parameter is do-not-disturb or busy. For example, if a user is currently in a meeting, the context-aware parameter is do-not-disturb, but the phone receives a bank transaction confirmation notification, the notification attribute parameter is important. In this case, the notification attribute parameter requires to remind the user immediately, while the context-aware parameter tends to not disturb the user, and the two conflict. The solution is to allow notifications in a limited way, with the following specific rules: If the notification attribute parameter is urgent and the threshold condition is met, a notification will be forcibly sent to the watch, using a limited reminder format, such as a short vibration plus a screen icon notification, without triggering a sound reminder. The threshold conditions refer to the notification type belonging to the user's preset exception set, or the notification content containing key keywords marked by the user. The user's preset exception set can be added by the user, such as emergency contact messages and medical reminders. If the notification attribute parameter is urgent but does not meet the threshold condition, or if the notification attribute parameter is important, the notification will be marked as delayed and pushed to the watch will be postponed. At the same time, the queue record of the notification will be cached. If the notification attribute parameter is of the importance level and the context awareness parameter is of the light busy level, a silent reminder will be used to push the notification to the watch without triggering vibration or sound, and only a reminder icon will be displayed on the screen. Scenario 2: Notification low priority and context high priority. This means the notification attribute parameter is at the normal or low priority level, while the context-aware parameter is at the idle level. For example, if the user is currently idle (the context-aware parameter is idle), but the phone receives an application update notification, the notification attribute parameter is low priority. Differential processing is applied, with the specific rules as follows: The instant push threshold associated with the notification type is used for determination. The instant push threshold means that the notification type belongs to the set of types that the user is interested in and the notification has not been marked as a rejection category by the user. If the threshold for instant push is met, the notification will be pushed to the watch immediately, using a lightweight reminder format, such as simply turning on the screen without triggering vibration; If the threshold for immediate push is not met, the notification will be temporarily stored in the batch processing queue and pushed in summary form when the conditions are met later, such as when the cumulative number reaches the summary trigger threshold or when the user actively views the notification. The notification update strategy for handling conflict situations also includes a notification update strategy to dynamically adjust the subsequent presentation of the notification; If a notification is postponed due to contextual constraints, when the user's context changes, such as leaving meeting mode or ending driving, and the context awareness parameter level increases, the previously delayed notification will be re-evaluated. There are two update processes at this time: one is to resend the notification, that is, to supplement the important notification that was not delivered before on the watch in an appropriate form, possibly in a grouped summary, see step S3 for details; the other is to update the status, if a notification has become outdated during the delay period or has been processed by the user on the phone, then its delivery will be canceled. To ensure that notifications are not permanently lost due to temporary contextual conflicts, and to avoid forcibly disturbing users when they do not need them, the specific rules are as follows: When the context-aware parameter level changes, re-evaluate the queue records of all delayed or paused notifications; For urgent and important notifications that are delayed, if the notification is still within its valid time limit (the valid time limit is defined as the current time minus the notification generation timestamp being less than or equal to the time limit threshold corresponding to the notification type, where the time limit threshold for urgent notifications is 2 hours and for important notifications is 6 hours), then the notification will be resent in the form of a reminder according to the corresponding priority. If the valid time limit has expired or the user has already processed the notification on their mobile device, then the sending will be cancelled. For temporary ordinary and low priority notifications, if the conditions for summary push are met (the temporary number reaches the summary trigger threshold, or the time interval since the last summary push reaches the summary interval), they will be pushed to the watch in summary form. For notifications that have been pushed to the watch but are in silent notification mode, when the context awareness parameter level is switched to idle or lightly busy, a slight prompt is triggered, such as the screen icon flashing for 3 seconds, to remind the user to check unread notifications; An intelligent decision-making mechanism based on notification attribute parameters and context-aware parameters has been established, which can detect and handle inconsistencies between the two, thus laying the foundation for subsequent notification grouping and throttling. Context awareness, as one of the decision-making criteria, enables notification priority to dynamically adapt to the user's current state.

[0016] In step S3, within a preset time window, notifications with the same grouping index relationship are statistically analyzed. Based on queue changes and context status, the notifications are grouped, summarized, or throttled, and the output format of the notification in the scheduling queue is determined. Specific details include: After completing the initial judgment of a single notification, the focus is on the overall scheduling of multiple notifications within a certain time window based on notification attribute parameters and context-aware parameters, including three strategies: group display, content summarization, and throttling control. When a new notification is received, the grouping index is used to check if there is already a notification with the same grouping index key in the queue to be sent. Notifications with higher attribute parameters are usually not merged with other notifications to prevent important information from being buried. The context-aware parameters determine the triggering conditions and granularity of the grouping, and the specific rules are as follows: Group triggering conditions: The cumulative number of notifications within the sliding time window is linked with the context-aware parameter level. The conditions for group triggering are: the number of arrivals within the window corresponding to the same group index key within the sliding time window reaches the group number threshold and the context-aware parameter level is not equal to the idle level; or the number of arrivals within the window corresponding to the same group index key within the sliding time window reaches the high-load group threshold. It should be noted that the sliding time window can use a fixed 5-minute window. The group number threshold is related to the context awareness parameter level. When the context awareness parameter is at the "Do Not Disturb" or "Busy" level, the group number threshold is 2; when the context awareness parameter is at the "Lightly Busy" level, the group number threshold is 3; the high load group threshold is a fixed threshold preset by the system, with a value of 5, which is used to deal with the scenario of a burst of notifications in a short period of time. Grouping granularity adjustment: The level of detail in group display is adjusted based on the context-aware parameter level. If the context-aware parameter level is Do Not Disturb or Busy, the group display granularity is minimal, showing only the application name and the number of notifications. If the context-aware parameter level is Lightly Busy, the group display granularity is basic, showing the application name, the number of notifications, and a brief summary of the latest notification. If the context-aware parameter level is Idle, the group display granularity is detailed, showing the application name, the sender or subject of each notification, and the number of notifications. Notification summarization strategies are typically used in conjunction with grouping. This involves generating summary information output for notifications in a set of groups corresponding to the same group index key. After notification grouping is executed, corresponding summary content is created, and the richness of the summary details is adjusted according to the user's environment. For example, when a user is driving, the context-aware parameter determines that it is not appropriate to read detailed content, so the summary notification text will be concise and general. When the user is idle and the environment is quiet, the summary notification can provide more details. Summary notifications also carry certain priority attributes. If the notification attribute parameter of one of the sub-notifications included in the summary is urgent or important, a mark can be made on the summary notification to prompt the user. Once the user clicks to expand the summary notification, the watch or phone can display the contents of each expanded sub-notification. The specific rules are as follows: Summary content generation: Based on key information fields of notifications within the group set, such as sender, subject, and timestamp, the core information is extracted using existing text digest generation technology. If the context-aware parameter level is Do Not Disturb or Busy, the summary content can apply the total number of notifications and the number of notifications within the group. If the context-aware parameter level is set to "lightly busy", the summary content includes the total number of notifications within the group, the number of notifications, the number of core keywords, and the corresponding topics. If the context-aware parameter level is idle, the summary content can be the total number of notifications in the application group, the number of notifications, the number of main senders, the number of core keywords, and the corresponding topics. The core keywords are extracted from all notification content in the group using the TFIDF algorithm. The main senders are the top N senders in the group with the most notifications. N is adjusted according to the context-aware parameter level: 3 for idle level, 2 for lightly busy level, and 1 for busy level and above. Summary Priority Marker: If there are notifications with the "urgent" attribute parameter in the group set, an "urgent" mark is added to the summary content; if there are no "urgent" notifications in the group set, but the number of "important" notifications reaches the summary importance threshold (which is 50% of the total number of notifications in the group), an "important" mark is added to the summary content. If neither of the above two conditions is met, then no priority marker will be added to the summarized content; Summary presentation format: The presentation triggering method of summary notifications is adjusted according to the context awareness parameter level. If the context awareness parameter level is Do Not Disturb, it will only be presented when the user actively raises their wrist to view the notification; if the context awareness parameter level is Busy, it will be delayed until the end of the sliding time window; if the context awareness parameter level is Lightly Busy or Idle, it will be presented in real time, but the reminder will not be triggered repeatedly. It should be noted that the aggregation strategy ensures that when the context is not conducive to frequent interruptions, only one notification is sent to the user so that the user is aware of the situation; when the user has the energy to view the details, the detailed information is then presented. The notification throttling strategy is used to limit the frequency of notification reminders within a unit of time to prevent a large number of notifications from flooding the user in a short period of time and causing inconvenience. Maintain a notification throttling counter or time window to control the rate of notification pushes. When multiple notifications arrive within a very short time interval and all need to be sent to the watch, they will be processed according to a preset throttling threshold. The throttling intensity is dynamically adjusted by context-aware parameters. When users are busy or unable to receive notifications, the threshold can be more stringent, while when users are idle and expect real-time updates, the restrictions can be relaxed appropriately. Additionally, notification attribute parameters also affect the throttling strategy; notifications with high attribute parameters can partially or completely bypass throttling restrictions. Specific rules are as follows: Throttling threshold setting: The maximum number of reminders per unit time is linked to the context awareness parameter level. If the context awareness parameter level is "Do Not Disturb," the maximum number of reminders per unit time is 1 every 10 minutes; if the context awareness parameter level is "Busy," the maximum number of reminders per unit time is 1 every 5 minutes; if the context awareness parameter level is "Lightly Busy," the maximum number of reminders per unit time is 2 every 3 minutes; and if the context awareness parameter level is "Idle," the maximum number of reminders per unit time is 3 per minute. The unit time uses the existing sliding time window algorithm to ensure the accuracy of frequency statistics. Reminder frequency control: This is achieved by maintaining a throttling counter. The number of reminders per unit time is the number of notification reminders that have been triggered within the sliding time window. If a new notification requires a reminder (not a silent push), and the number of reminders per unit time is less than the maximum number of reminders per unit time, then the reminder is allowed to be triggered, and the throttling counter is updated. If the number of reminders per unit time has reached or exceeded the maximum number of reminders per unit time, then the reminder triggering permission for that notification is temporarily stored and re-evaluated when the next sliding time window opens. Priority bypass rule: The condition for bypassing the throttling is that the notification attribute parameter is urgent, or the notification attribute parameter is important and the current number of reminders per unit time is less than 150% of the maximum number of reminders per unit time. If the throttling bypass condition is met, the notification can still be triggered even if the maximum number of reminders per unit time has been reached, but a differentiated reminder form must be used. For example, urgent notifications trigger a long ring, and important notifications trigger a short ring to avoid confusion with ordinary notification reminders. Redundant notification filtering: For notifications with low priority attribute parameters, a duplicate filtering rule is adopted. The condition for redundancy filtering is that the number of times the notification corresponding to the same group index key is repeatedly sent within the sliding time window reaches the redundancy threshold, which is 3 times. For notifications that meet the redundancy filtering conditions, the reminder trigger will be canceled directly, and only the content of the already pushed notifications will be updated, such as updating the count. No new independent reminders will be added. For example, when a news app pushes multiple news articles in a short period of time, the option will be selected to only remind once every certain period of time, and this will be noted in the summary notification. By combining the above three strategies of grouping, summarizing, and throttling, the notification output can be dynamically adjusted when the notification volume is large. This enables batch optimization of notification scheduling, and utilizes dual-parameter drive to flexibly group and summarize information based on environment and user status, while controlling the push frequency, thus improving the intelligence and user-friendliness of notification management.

[0017] In step S4, based on the notification attribute information, sending format flag, and terminal status information recorded in the notification scheduling queue, it is determined whether the notification has been delivered, the delivery method, and the synchronization path. Notifications meeting the conditions are then delivered to the watch according to a predetermined bridging or mirroring mechanism. Specific details include: The bridging gating strategy and notification delivery terminal are the last checkpoints before the notification is actually sent to the smartwatch. The bridging gating strategy is the application of the bridging gating strategy. The bridging gating is a notification transmission channel based on the bridging architecture. At the exit, a policy judgment gate is set up to determine whether to allow the notification and how to allow it based on the notification content and the terminal context state. Based on the decision results of the preceding steps and the latest context, the following strategy is implemented: The content sensitivity assessment further examines the characteristics of the notification content, such as whether the notification contains sensitive or private information, and its matching degree with the current environment. This is an extension of the notification content parameters. If the notification content involves user privacy, such as SMS content containing one-time verification codes or medical information, and the context is not suitable for publicly displaying detailed content, such as when there are people around the user or the watch is in public mode, the bridging gating strategy will adjust the presentation of the notification. This ensures that the notification content is appropriate for the environmental context, preventing potential information leaks or embarrassment caused by blindly mirroring notifications. The specific rules are as follows: Privacy information identification: Employing existing text keyword matching and entity recognition technologies, the privacy information matching degree is calculated by dividing the number of privacy keywords matched in the notification content by the total number of keywords in the notification content and then multiplying by 100%. The privacy keyword set includes verification codes, bank card numbers, ID card numbers, medical terms, privacy contact names, etc., which are predefined by the system and can be added by users. Entity recognition uses existing named entity recognition models to accurately identify privacy-related entities. Environmental Adaptability Determination: Combining the environmental state and user state in the context-aware parameters, the environmental incompatibility is determined to be high if the ambient sound intensity reaches the public environment threshold, or the ambient light intensity reaches the strong light threshold, or the user's current activity is in a public scene. The public environment threshold and strong light threshold are set based on existing public scene environment standards. Public scene activities are determined by activity recognition algorithms combined with geographical location information, such as being in public areas like shopping malls or subways. If none of the above conditions are met, the environmental incompatibility is determined to be low. Content presentation adjustments: The decision is based on a combination of privacy information matching degree and environmental incompatibility. If the privacy information matching degree reaches the privacy sensitivity threshold (30%) and the environmental incompatibility is high, only a privacy warning icon will be displayed, hiding the specific content. If the privacy information matching degree reaches the privacy sensitivity threshold and the environmental incompatibility is low, de-identified content will be displayed, replacing privacy keywords with *. If the privacy information matching degree does not reach the privacy sensitivity threshold, the full content will be displayed. The privacy sensitivity threshold can be adjusted by the user according to their privacy protection needs. The de-identification process uses existing text de-identification technology to ensure that privacy information is not leaked. Terminal status determination: Terminal context status mainly refers to the current usage status and connection status of the mobile phone and watch. The bridging gate will select a strategy based on these statuses: Mobile phone usage status: If it is detected that the mobile phone is currently being actively used by the user, the bridging gate will follow the principle of master device priority and will not push or will push silently to the watch. If the smartwatch is currently in a state where it is not suitable to receive notifications, the bridging gate can choose to postpone the sending of notifications. The state of not wearing the watch can be detected by the watch's sensors, such as the heart rate sensor not detecting a signal. When the watch is detected to be off-wear, most notifications do not need to be pushed immediately. They can be sent after the watch is put back on or only appear on the phone. If the watch is locked or the user has enabled some focus modes, the watch's settings should be respected, and appropriate interception or delay should be performed on the bridging end to avoid invalid notifications. The specific judgment rules are as follows: Wearing status: The condition for determining the watch to be worn stably is that the duration of the contact signal detected by the skin contact sensor reaches the wearing detection threshold, and the heart rate sensor detects valid heart rate data; if the stable wearing condition is not met, the condition for determining it to be worn temporarily is that the duration of the contact signal does not reach the wearing detection threshold but there is an intermittent signal; if none of the above conditions are met, it is determined to be not worn. The wearing detection threshold adopts the existing watch wearing detection standard and is set to 10 seconds. The sensor data is obtained in real time through the watch system interface. Battery status: The watch is considered to have sufficient battery when the remaining battery level reaches the sufficient battery threshold, for example, 50%. If the sufficient battery level is not met, it is considered to have medium battery level when the remaining battery level reaches the low battery warning threshold, which is 20%. If none of the above conditions are met, it is considered to have low battery. Mode Status: Directly reads the watch's system mode, including Normal Mode, Power Saving Mode, Focus Mode, etc. Connection and Synchronization Status: When the connection between the phone and watch is poor, such as a temporary Bluetooth disconnection or being outside the communication range, the bridging gate will cache notifications to be sent. When the connection is restored, they will be sent in batches or selectively based on the current context. Based on notification attribute parameters and context-aware parameters, notifications with higher notification attribute parameters are prioritized for direct delivery, even if it is necessary to overcome limitations in certain states; when context-aware parameters indicate that the environment is not suitable, the notifications are preferred to be sent silently or with a delay, as follows: Direct Sending Strategy: The conditions for direct sending are that the notification attribute parameter is urgent or important, the connection quality level is stable, the watch is worn stably, and the phone is in low activity. The execution method is to push according to the reminder format of the notification. Urgent notifications trigger a long vibration, screen highlight and sound prompt, important notifications trigger a short vibration and screen light up, and ordinary notifications only light up the screen to display the full or desensitized content. Silent Sending Strategy: Silent sending is triggered when the notification attribute parameter is set to "Normal" and the phone's activity level is "Medium Active," or when the notification attribute parameter is set to "Low Priority" and the watch's battery level is "Sufficient," or when the connection quality level is "Moderate" and the notification attribute parameter is not "Urgent." The notification is then synced to the watch's notification center without triggering vibration, sound, or screen activation alerts; it is only displayed when the user actively views the watch. Alternative Sending Strategy: The conditions for alternative sending are that the number of notifications to be sent reaches the alternative sending threshold, which is 5, and the notification attribute parameters are all at the normal or low priority level, or the watch battery level is medium and the context awareness parameter level is lightly busy. The execution method is to merge multiple notifications into a summary notification and send it. The summary content is generated according to the summary rules in step S3, triggering a light reminder, such as a short vibration. No-send policy: The conditions for not sending are: the notification attribute parameter is low priority and the watch battery level is low, or the connection quality level is unstable and the notification attribute parameter is not urgent, or the watch is not worn and the notification attribute parameter is normal or low priority, or the phone activity level is high and the notification attribute parameter is not urgent. Ultimately, only notifications that meet the criteria are delivered to the smartwatch, and the method has been optimized based on priority and context.

[0018] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation.

[0019] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product.

[0020] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and inventive constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0021] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

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

[0023] In conclusion, the above description is only a preferred embodiment of the present invention and is 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 context-aware smartwatch notification priority scheduling method, characterized in that, Includes steps; Step S1: Extract the identifier of the notification based on the provided sorted snapshot, generate content features for the notification text, construct group index relationships and same-origin retrieval relationships based on the fields, write the notification into the notification scheduling queue, and synchronously maintain the corresponding index structure and group statistics. Step S2: Based on the notification attribute parameters and context-aware parameters, compare the notification written to the notification scheduling queue with the existing notifications to determine whether they belong to the same event or the same message stream. If the same source condition is met, perform update replacement or merging processing on the notification. If the same source condition is not met, retain the notification as an independent entry. Step S3: Within a preset time window, statistics are collected on notifications with the same grouping index relationship. Based on queue changes and context status, the notifications are grouped, summarized, or throttled, and the output format of the notification in the scheduling queue is determined. Step S4: Based on the notification attribute information, sending format marker and terminal status information recorded in the notification scheduling queue, determine whether the notification has been delivered, the delivery method and the synchronization path, and deliver the qualified notifications to the watch end according to the predetermined bridging or mirroring mechanism.

2. The context-aware smartwatch notification priority scheduling method according to claim 1, characterized in that, The initial queue archiving steps include: when a notification release or update event occurs, extracting fields from the notification object, including at least the application identifier, notification channel identifier, group key, session key, notification tag, notification identifier, notification generation timestamp, whether it can be updated flag, and bridging control flag; obtaining and providing an active notification sorting snapshot as the sorting snapshot field.

3. The context-aware smartwatch notification priority scheduling method according to claim 2, characterized in that, The title text and body summary text of the notification object are standardized, and summary features are generated based on the standardized text. Based on the extracted fields, a grouping index key and a same-origin retrieval key are generated. The grouping index key is used to represent the grouping unit to which the notification belongs, and the same-origin retrieval key is used to represent the candidate location unit of the same matter or the same message stream.

4. The context-aware smartwatch notification priority scheduling method according to claim 2, characterized in that, Create a queue record for the notification and write it to the notification scheduling queue. The queue record shall include at least the unique identifier within the queue, the application identifier, the notification channel identifier, the group index key, the same-origin retrieval key, the notification tag, the notification identifier, the notification generation timestamp, the updatable flag, the bridging control flag, the sort snapshot field, and the initial alert level field. A grouped index is created based on the grouped index key, and a same-source index is created based on the same-source retrieval key; a reverse association relationship is established between queue records and index keys.

5. The context-aware smartwatch notification priority scheduling method according to claim 2, characterized in that, Maintain group statistics by group index key, including arrival count within window, number of currently active entries, start time of statistics window and most recent arrival time; When a queue record is written, the corresponding group statistics are updated synchronously; when a notification revocation event is generated, the corresponding queue record is located and its status is updated to invalid, the record is deleted from the index according to the reverse association relationship and the group statistics are updated. Perform cleanup, recycling, or archiving on queue records that are invalid and have exceeded the preset retention period.

6. The context-aware smartwatch notification priority scheduling method according to claim 1, characterized in that, The same-source conflict determination and update steps include: making a comprehensive judgment based on notification attribute parameters and context-aware parameters, wherein the notification attribute parameters are determined based on the application's predefined notification level, the user's set notification priority or notification type, and the context-aware parameters are determined based on the user's current activity, environmental state, time or device state; When the priorities indicated by the two parameters are inconsistent, the adjustment is carried out according to the preset rules.

7. The context-aware smartwatch notification priority scheduling method according to claim 6, characterized in that, The mediation process includes: if the notification attribute parameter is urgent and the threshold condition is met, then a notification will be forcibly sent to the watch and a limited reminder will be used; If the notification attribute parameter is urgent but does not meet the threshold condition, or if the notification attribute parameter is important and the context-aware parameter is do not disturb or busy, then the notification will be marked as delayed. If the notification attribute parameter is set to "Important" and the context-aware parameter is set to "Lightly Busy", then a silent notification will be pushed.

8. The context-aware smartwatch notification priority scheduling method according to claim 1, characterized in that, Grouping and throttling include: determining grouping trigger conditions based on the cumulative number of notifications corresponding to the same group index key within the sliding time window and the linkage between the context-aware parameter level; Adjust the level of detail displayed for groupings based on context-aware parameter levels; The summary content is generated based on the key information fields of the notifications in the group set. If there are notifications with the emergency level in the group or the number of important notifications reaches the summary importance threshold, a priority mark is added to the summary content. Adjust the presentation triggering method of summary notifications based on context-aware parameter levels.

9. The context-aware smartwatch notification priority scheduling method according to claim 1, characterized in that, Bridging gating and notification delivery includes: identifying privacy information in notifications through text keyword matching and entity recognition technologies, and calculating the matching degree of privacy information; Determine the degree of environmental misfit by combining context-aware parameters; Based on the combination of privacy information matching degree and environmental incompatibility degree, the presentation of notification content is adjusted, including displaying only the privacy prompt logo, displaying de-identified content, or displaying the full content.

10. The context-aware smartwatch notification priority scheduling method according to claim 9, characterized in that, The sending strategy is selected based on the terminal status determination result. The sending strategy includes direct sending, silent sending, alternative sending, or no sending. The conditions for direct sending include notification attribute parameters being urgent or important, stable connection quality, stable watch wearing status, and low mobile phone activity status. Silent sending conditions include notification attribute parameters being at the normal level and the phone's activity level being at the medium active level, or notification attribute parameters being at the low priority level and the watch having sufficient battery power, or connection quality being average and notification attribute parameters not being at the emergency level.

Images