Smart near field advertisement with optimization

Abstract

In non-limiting examples of the present disclosure, systems, methods, and devices for intelligent advertising with optimization. A first device may determine a scenario for completion with a second device. A first device may receive a device signal associated with a scene. The first device may analyze the device signal based on the scene using a rules engine. The first device may determine whether the second device is ready to participate in the scenario. In response to determining that the second device is ready to participate in the scenario, the first device may send an advertisement or listen for an advertisement from the second device.

Description

Background Art

[0001] For various reasons, computing devices need to communicate with each other. In many cases, a user-initiated communication is used. However, there are many situations where a user prefers that one device inform another device of an opportunity to start a scene or execute a scene without user input. A computing device communicating with other devices can announce a notification (e.g., broadcast message, beacon, etc.), and the other device can listen and respond. However, the action of continuously announcing and listening is power intensive, and therefore uses a lot of battery life for the computing devices involved.

[0002] Relative to this general technology environment, aspects of the technology disclosed herein have been conceived.In addition, although a general environment has been discussed, it should be understood that the examples described herein should not be limited to the general environment identified in the background. Summary of the invention

[0003] The present invention summary is provided to introduce in simplified form the selected concepts that will be further described in the following detailed description section. The present invention summary is not intended to identify the key features or essential features of the claimed subject matter, nor is it intended to be used as an aid to determine the scope of the claimed subject matter. Additional aspects, features, and / or advantages of the examples will be set forth in part in the subsequent description, and will be apparent from the description or can be learned through practice of the present disclosure.

[0004] Non-limiting examples of the present disclosure describe systems, methods, and devices for intelligent notifications with optimization. A system of one or more computers may be configured to perform a specific operation or action by having software, firmware, hardware, or a combination thereof installed on the system, which causes or causes the system to perform an action in operation. One or more computer programs may be configured to perform a specific operation or action by including instructions that, when executed by a data processing device, cause the device to perform an action. A general aspect includes a computer-implemented method for intelligent notifications. The computer-implemented method includes determining a scenario for completion between a sending device and a receiving device. The sending device receives a device signal associated with a scenario from the sending device. The sending device analyzes the device signal based on the scenario using a rule engine to determine whether the receiving device is ready to participate in the scenario. The rule engine may include a combination of static rules and machine learning models. In response to determining that the receiving device is ready to participate in the scenario, the sending device sends a notification to advance the scenario. Other embodiments of this aspect include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each of which is configured to perform the actions of the method.

[0005] Implementations may include one or more of the following features. In some embodiments, device signals may include device status signals, connectivity signals, sensor signals, operating system signals, application signals, or combinations thereof. In some embodiments, the sending device may select a transmission based on the scenario and the device signal, and send a notification on the selected transmission. In some embodiments, the sending device may receive static rules from a first remote hosting system and receive a general machine learning model from a second remote hosting system. The general machine learning model may include a model trained using general data from multiple devices attempting to complete the scenario. The sending device may also access a personal machine learning model that is trained using personal data from the sending device attempting to complete the scenario. The sending device may merge static rules, general machine learning models, and personal machine learning models into a rule engine for analyzing device signals based on scenarios. In some embodiments, the sending device may filter device signals based on scenarios, and the rule engine analyzes the filtered device signals. In some embodiments, the sending device may track the state of the scenario and provide the state to the rule engine so that the rule engine uses the state of the scenario when analyzing device signals. In some embodiments, the sending device may track the state of the scenario and use the state of the scenario to train a personal machine learning model for use in the rule engine. In some embodiments, the sending device may receive feedback from the receiving device regarding the execution of the scenario and use the feedback to train the personal machine learning model. Implementations of the described techniques may include hardware, methods or processes, or computer software on a computer-accessible medium.

[0006] Another general aspect includes a computer-implemented method for intelligent listening. The computer-implemented method includes determining a scenario for completion between a sending device and a receiving device. The receiving device may receive a device signal associated with the scenario from the receiving device. The receiving device may analyze the device signal based on the scenario using a rule engine to determine whether the sending device is ready to participate in the scenario. The rule engine may include a combination of static rules and machine learning models. In response to determining that the sending device is ready to participate in the scenario, the receiving device may listen for notifications to advance the scenario. Other embodiments of this aspect include corresponding computer systems, apparatuses, and computer programs recorded on one or more computer storage devices, each of which is configured to perform the actions of the method.

[0007] Implementations may include one or more of the following features. A receiving device may receive a notification and, in response to receiving the notification, perform an action to advance the scenario. A receiving device may track the state of the scenario and send feedback based on the state of the scenario and personal data associated with the scenario to a sending device. A receiving device may send feedback based on the state of the scenario and general data associated with the scenario to a remote training system. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Non-limiting and non-exhaustive examples are described with reference to the following figures:

[0009] Figure 1 is a schematic diagram illustrating an example computing environment for intelligent advertising with optimization.

[0010] Figure 2 is a schematic diagram illustrating an example transmitting device.

[0011] Figure 3 is a schematic diagram illustrating an example receiving device.

[0012] Figure 4 is an exemplary method for smart notifications with optimization.

[0013] Figure 5 is an exemplary method for intelligent monitoring with optimization.

[0014] Figure 6 and Figure 7 is a simplified diagram of a mobile computing device with which aspects of the disclosure may be practiced.

[0015] Figure 8 is a block diagram illustrating example physical components of a computing device with which aspects of the disclosure may be practiced.

[0016] Fig. 9 is a simplified block diagram of a distributed computing system in which aspects of the present disclosure may be practiced. DETAILED DESCRIPTION

[0017] Various embodiments will be described in detail with reference to the accompanying drawings, wherein the same reference numerals represent the same parts and components throughout the multiple views. Reference to the various embodiments does not limit the scope of the appended claims. Additionally, any examples set forth in this specification are not intended to be limiting and are merely set forth some of the many possible embodiments of the appended claims.

[0018] Examples of the present disclosure provide systems, methods, and devices for having optimized smart near-field notifications. As used herein, "notification" describes the transmission of a signal from a first device for reception by at least one other device, wherein the signal publishes a state so that other devices listening for the state can react. In some embodiments, the notification can be a broadcast message or any type of message sent without addressing a specific receiver. The notification can be sent on one or more transmissions. In some embodiments, near-field transmission technology (e.g., Near Field Communication (NFC) or other near field transmission) can be used to complete the announcement. However, any transmission technology that supports the concept of announcement can be used.

[0019] As used herein, "transport" describes a protocol or carrier used for communication between devices. A transport may include, for example, Near Field Communication (NFC) or other near field transmission, Direct connection, ultra-wideband (UWB), infrastructure network (such as cellular network, satellite network, or cable network), cloud / push, etc.

[0020] As used herein, a "scenario" describes multi-device communication and the execution of an action. For example, a scenario can take the form of a lure to "set up" (e.g., device X is ready to be set up), a call to action (e.g., device X reports a certain state, take an action; phone is in the vehicle and ready to pair, pair with phone), or other complex multi-device use cases (e.g., phone is nearby, use it to enter your signature).

[0021] The suitability of a transmission technology varies based on the scenario, but also based on factors such as user-specific usage patterns, environmental conditions that affect signal strength, external conditions involving the presence of other devices, etc. Therefore, determining which transmission to use in any scenario can be ambiguous. In addition, devices that require notification require battery-intensive operation, which makes notifications limited to mobile devices. Similarly, devices that require listening require battery-intensive operation, which makes listening limited. The resulting ambiguity about when to announce, when to listen, and which technology to use to send the announcement makes the scenario highly sensitive to dynamic factors.

[0022] The described solution optimizes announcements based on dynamic factors, such that if there is no high chance that a listening device will hear an announcement, then the announcement is not sent. Additionally, an optional solution may be applied to a listening device to optimize listening based on dynamic factors, such that if there is no high chance that an announcing device will send, then the device does not listen for an announcement.

[0023] According to an example, a scenario is selected by a sending device. For example, the sending device may be a mobile phone. The scenario may be that the mobile phone should automatically pair with a capable radio in any vehicle that the mobile phone enters periodically. In order to determine whether to announce that the mobile phone is ready for pairing, multiple dynamic factors should be considered. At least some of the dynamic factors may be scenario-specific, and other factors may be common to most or all scenarios. Dynamic factors may include information about the environment, device usage, device status, connectivity strength, hardware options, software options, and the like. The sending device may receive device signals from multiple sources that provide information about dynamic factors. For example, a sensor may provide information related to the environment and status of the device, including, for this example, whether the device has entered a vehicle. The sending device may use static rules that operate as initial thresholds for further analysis of the signal. For example, threshold proximity values, signal strength, and the like may be included in the static rules. The sending device may also use general dynamic rules including a machine learning model that is generated and trained based on general (non-personal) information from many devices. General information may include, for example, whether the device is connected to a vehicle. The access point and whether the connection is public or private. In addition, the sending device can use personal dynamic rules including a machine learning model that is generated and trained based on personal information from the sending device. The personal information can include, for example, the name of the access point. Static rules, universal dynamic rules, and personal dynamic rules can be incorporated into a rule engine. The rule engine can analyze signals based on scenarios using static rules, universal dynamic rules, and personal dynamic rules associated with scenarios. Based on the analysis, the sending device can select a transmission for the announcement. The analysis can indicate that the receiving device is ready to participate in the scenario. For example, in this example of a phone paired with a vehicle, the rules engine can analyze the signal and determine that the sending device is in a vehicle that the user enters frequently enough and has not yet been paired with the sending device. In response to a determination that the receiving device (e.g., the vehicle's in-car stereo system) may be ready to participate in the scenario, the sending device can send an announcement. For example, the sending device can send an indication that it is ready to pair. Signals. By using a trained model to analyze relevant signals to determine whether a receiving device is likely ready to participate in a scenario, the sending device optimizes the chances of the receiving device receiving the announcement. In addition, battery usage of the sending device is minimized. Additionally, the user does not need to initiate the send. By automatically initiating the send, the user does not need to know the feature or know how to invoke the communication, making the entire experience broader and easier for the user.

[0024] According to other examples, the receiving device can intelligently listen and optimize resources. For example, the scenario is selected by the receiving device. For example, the receiving device can be a car stereo in a vehicle. The scenario can be that the stereo should automatically pair with any mobile device that enters the vehicle regularly. In order to determine whether to listen to the mobile device, multiple dynamic factors should be considered. At least some of the dynamic factors can be scenario-specific, and other factors can be common to most or all scenarios. Dynamic factors can include information about the environment, device usage, device status, connectivity strength, hardware options, software options, etc. The receiving device can receive device signals from multiple sources that provide information about dynamic factors. For example, a sensor can provide information related to the environment and status of the device, which includes, for this example, whether other mobile devices are nearby. The receiving device can use static rules that operate as initial thresholds for further analysis of the signal. For example, threshold proximity values, signal strength, etc. can be included in the static rules. The receiving device can also use general dynamic rules including machine learning models that are generated and trained based on general (non-personal) information from many devices. General information can include, for example, whether the device is connected to The access point and whether the connection is public or private. In addition, the receiving device can use personal dynamic rules including a machine learning model that is generated and trained based on personal information from the receiving device. The personal information can include, for example, the name of the access point. Static rules, universal dynamic rules, and personal dynamic rules can be incorporated into the rule engine. The rule engine can analyze signals based on the scenario using static rules, universal dynamic rules, and personal dynamic rules associated with the scenario. The analysis can indicate that the sending device may be ready to participate in the scenario. For example, in this example of a phone paired with a radio in a vehicle, the rule engine can analyze the signal and determine that the sending device is in a vehicle that the user enters frequently enough and has not yet been paired with the receiving device. In response to a determination that the sending device (e.g., a mobile phone) may be ready to participate in the scenario, the receiving device can listen for announcements. For example, the sending device can send an indication that it is ready to pair. The receiving device may receive the transmission and initiate pairing with the mobile device. By using the trained model to analyze the relevant signals to determine whether the transmitting device is likely ready to participate in the scenario, the receiving device optimizes the chances of the transmitting device sending notifications relevant to the receiving device. In addition, the battery usage of the receiving device is minimized. Additionally, the user does not need to initiate or complete the scenario. By automatically listening for the transmission, the user does not need to know the feature or know how to invoke the communication, making the entire experience more extensive and easier for the user.

[0025] The systems, methods, and devices described herein provide technical advantages for optimizing near-field notifications and monitoring such notifications. Battery life on mobile devices is limited, and the functions of sending notifications and monitoring the notifications are power-intensive, so the functions quickly consume battery life. Optimization of sending and monitoring notifications helps to limit unnecessary battery consumption. Existing systems do not optimize or intelligently solve this problem. One solution is periodic transmission and monitoring, but this still requires a lot of unnecessary battery use. In addition, in the case of periodic transmission and reception, in many cases, the transmitter transmits when no other device monitors, and the receiving device monitors when no other device transmits. Another solution is to limit the operation to a narrow range of user actions, so that the transmission of notifications only occurs when a specific user action occurs. This unnecessarily limits the user experience. The solution described herein provides intelligent optimization that extends the user experience and minimizes unnecessary battery consumption.

[0026] Figure 1 is a schematic diagram of a system 100 for intelligent notification and optimization. The system may include a sending device 105, a receiving device 110, cloud-hosted static rules 115, and cloud-hosted model training 120.

[0027] The cloud-hosted static rules 115 may include static rules that act as guardrails for scenario-specific machine learning models used in the rule engine 140. The cloud-hosted static rules 115 may allow for definition of pre-filtering criteria or thresholds for machine learning model execution. As a cloud-hosted system, rules stored locally (e.g., in the rule database 130 and the rule database 155) may be updated via the cloud service. For example, static rules may be sent to devices such as the sending device 105 and the receiving device 110 when rules are modified, added, or deleted based on devices that subscribe to the cloud service. In addition, for example, static rules may be scenario-specific such that devices may subscribe to only relevant rule updates based on the scenario.

[0028] The cloud-hosted model training 120 may include dynamic rules that include a machine learning model based on generic information that is useful for all devices. The generic machine learning model may be scenario-specific. The generic machine learning model trained and provided by the cloud-hosted model training 120 may include a generic and impersonal model such that, for example, the information used to train the model does not include location, specific Name, and other information that is private to the device or user. The general model training and fine-tuning achieves privacy-aware solutions and efficiency by modeling and training as much general information as possible on a powerful cloud-hosted server. The general machine learning model provided by the cloud-hosted model training 120 can be adjusted by information that is continuously provided by the device based on the scene state and execution. In some embodiments, the general machine learning model can also be used as a basis for the personal machine learning model 125. In some embodiments, the general machine learning model can be scene-specific. As a cloud-hosted system, the general machine learning model stored locally (e.g., in the rule database 130 and the rule database 155) can be updated via the cloud service. For example, when the model is modified, added, or deleted based on the device subscribing to the cloud service, the model can be sent to devices such as the sending device 105 and the receiving device 110. In some embodiments, the model can be updated periodically to avoid constant updates when the model can be continuously fine-tuned. For example, in some embodiments, the model can be scene-specific so that the device can subscribe to the model for the relevant scene.

[0029] The sending device 105 may be a computing device (such as a mobile device) that may need to inform another device of an opportunity to start a scene or execute a scene. The sending device 105 may be, for example, a computing device 600, a computing device 700, a computing device 800, a mobile computing device 908, and / or a tablet computing device 906. The sending device 105 may include a personal machine learning model 125, a rule database 130, a signal and state receiver and processing 135, a rule engine 140, and a scene publishing 145. The sending device 105 may include more components that are not shown for ease of description. The sending device 105 may include fewer components while still providing the same functionality as described herein because the components may be combined or otherwise unified.

[0030] The personal machine learning model 125 may be a model generated and trained using personal information from the sending device 105 executing various scenarios. In some embodiments, the general machine learning model provided by the cloud-hosted model training 120 may provide a basis for the generation of the personal machine learning model 125. For example, the personal machine learning model 125 may also include personal embeddings (e.g., location information, The privacy settings may be a personalized adaptation of a generic model of a network (such as a wireless access point name, an Internet Protocol (IP) address, etc.). For example, personal information may include any information about the sending device 105 that should not leave the sending device 105 for privacy reasons. In some embodiments, the privacy settings may establish which data is considered personal or which data is considered general. For example, the sending device 105 is connected to a network. The name of the access point may be considered personal information that may not be made public and should instead be kept private on the sending device 105. Other examples of personal information may include location information, IP address, Name, names of other connected devices, access point names, etc. In some embodiments, the personal machine learning model 125 can be a scenario-specific model. The personal machine learning model 125 can be trained based on data collected from the sending device 105 during scenario execution, data collected from the receiving device 110 during scenario execution, scenario state information from the sending device 105 and / or the receiving device 110, etc., and can be trained and fine-tuned locally on the sending device 105 to maintain privacy and efficiency. The personal machine learning model can be used by the rule engine 140 to analyze signals from the signal and state receiver and processing 135, as described below with respect to Figure 2 and Figure 3 Described in more detail.

[0031] The rules database 130 may include static rules obtained from the cloud-hosted static rules 115 and from the cloud-hosted model training 120 as described above. The rules database 130 may be updated, for example, periodically, as needed, by subscription, etc. As shown, the personal machine learning model 125 is provided directly to the rule engine 140. In some embodiments, the personal machine learning model 125 may also be stored in the rules database 130. In some embodiments, the rules database 130 may include merged rules that include static rules, general dynamic models, and personal dynamic models used by the rules engine 140 to analyze signals for a given scenario. In some embodiments, the merged rules include a collection of rules and models that are scene-specific for a given scenario and stored in the rules database 130.

[0032] In some embodiments, the rules engine 140 can process static rules and general dynamic models from the rules database 130 and personal dynamic models from the personal machine learning model 125 to generate merged rules for analyzing signals for scenarios. The rules engine 140 can use rules and models to analyze signals from the signal and state receiver and processing 135 to determine whether another device is ready to participate in the selected scenario. When the rules engine 140 determines that another device may be ready to participate in the selected scenario, an indication is provided to the scenario publishing 145. The rules engine 140 can also select a transmission for sending a notification based on the analysis. For example, based on the analysis and available options for notification transmissions in a given scenario, a transmission with a stronger signal can be used instead of a transmission with a weaker signal.

[0033] The signal and state receiver and processing 135 may include components for receiving signals, filtering signals, tracking the state of the scene from both the sending device 105 and the receiving device 110, etc. Figure 2 130. Once received and optionally filtered, the signal may be provided to the rules engine 140 for analysis. In some embodiments, the state tracking component of the signal and state receiver and process 135 may select a scenario for execution.

[0034] Scenario publication 145 may include hardware components and / or software components capable of sending announcements intended to advance the selected scenario.Scenario publication 145 may send announcements on the selected transport once rules engine 140 provides an indication that receiving device 110 may be ready to listen and receive announcements.

[0035] Receiving device 110 may be a computing device (such as a mobile device) that may be interested in engaging in a scenario with sending device 105. Receiving device may be, for example, computing device 600, computing device 700, computing device 800, mobile computing device 908, and / or tablet computing device 906. Receiving device 110 may be a computing device such as a mobile device. Figure 1 The receiving device depicted in is much simpler. For example, the receiving device does not need to intelligently listen for announcements. Instead, in e.g. Existing devices listening for announcements on the transport may still receive the announcements sent by the sending device 105. In such an embodiment, the receiving device 110 may include a receiving component that receives the signal and performs an action in response to receiving the announcement. In some embodiments, the receiving device 110 may also include a component that can provide feedback to the cloud-hosted model training 120 for fine-tuning the general dynamic model. The receiving device 110 may also include a component that can provide feedback to the sending device 105, which can be used to fine-tune the personal machine learning model 125.

[0036] exist Figure 1 In the embodiment shown in , the receiving device 110 also includes a component for intelligently listening to notifications from the sending device 105. The receiving device 110 may include a personal machine learning model 150, a rule database 155, a signal and state receiver and processing 160, a rule engine 165, a scenario subscriber 170, and a scenario execution 175. The receiving device 110 may include more components that are not shown for ease of description. The receiving device 110 may include fewer components while still providing the same functionality as described herein, because the components may be combined or otherwise unified.

[0037] The personal machine learning model 150 may be a model generated and trained using personal information from the receiving device 110 executing various scenarios. The personal machine learning model 150 may be substantially the same as the personal machine learning model 125 in the sending device 105. In some embodiments, both the sending device 105 and the receiving device 110 may have complementary components so that each can intelligently send and intelligently listen. In such an embodiment, corresponding components may be used for intelligently sending and intelligently listening.

[0038] The rules database 155 may include static rules obtained from the cloud-hosted static rules 115 and from the cloud-hosted model training 120 as described above. The rules database 155 may be substantially the same as the rules database 130 described with respect to the sending device 105.

[0039] In some embodiments, the rules engine 165 can process static rules and general dynamic models from the rules database 155 and personal dynamic models from the personal machine learning model 150 to generate merged rules for analyzing signals for the scene. The rules engine 165 can be substantially the same as the rules engine 140 described with respect to the sending device 105. Once the rules engine 165 determines that the sending device 105 may be sending a notification to advance the scene, the rules engine 165 provides an indication to the scene subscriber 170.

[0040] The signal and state receiver and processing 160 may include components for receiving signals, filtering signals, tracking the state of the scene from both the sending device 105 and the receiving device 110, etc. Figure 3 160. Once received and optionally filtered, the signal may be provided to the rules engine 165 for analysis. In some embodiments, the state tracking component of the signal and state receiver and process 160 may select a scenario for execution.

[0041] The context subscriber 170 may include a hardware component and / or a software component capable of listening to the announcements. Once the rules engine 165 provides an indication that the sending device 105 may be sending an announcement, the context subscriber 170 may listen to the announcements.

[0042] Scenario execution 175 may receive a signal from scenario subscriber 170 that a notification was received and perform actions to advance the scenario. For example, if the scenario is a setup scenario, for example, to pair a sending device 105 with a receiving device 110, and a pairing request is received as a notification, scenario execution 175 may perform the next action required to complete the pairing. Scenario execution 175 may provide feedback on the execution to the signal and state receiver and processing 135 in the sending device 105, which may be used to fine-tune the personal machine learning model 125. Scenario execution 175 may provide feedback on the execution to cloud-hosted model training 120, which may be used to fine-tune the general machine learning model.

[0043] will be relative to Figure 2 and Figure 3 The components described above are discussed in more detail. Figure 2-Figure 5 The use and flow of data is further explained and discussed in more detail.

[0044] Figure 2 2 is a simplified block diagram illustrating an exemplary transmitting device 200. The transmitting device 200 may be, for example, Figure 1 The sending device 105 is described. The sending device 200 may include a rules database 220, dynamic personal rules 225, signal and state receiver and processing 230, a rules engine 255, and scenario publishing 260.

[0045] Dynamic personal rules 225 may be substantially similar to Figure 1 The dynamic personal rules 225 may include a machine learning model generated and trained using personal information from the sending device 200, particularly with respect to attempting to execute various scenarios. The dynamic personal rules 225 may include components for training and fine-tuning machine learning models locally. In some embodiments, the general machine learning model provided by the cloud-hosted model training 120 may provide a basis for the generation of dynamic personal rules 225. For example, the dynamic personal rules 225 may also include personal embeddings (e.g., location information, The personal information may include any information about the sending device 200 that is kept locally for privacy reasons. For example, the sending device 200 is connected to a The name of the access point may be considered personal information that may not be generalized and instead should only be maintained locally on the sending device 200. Other examples of personal information may include location information, IP address, Names, names of other connected devices, access point names, etc. In some embodiments, the dynamic personal rules 225 can be scenario-specific models. The dynamic personal rules 225 can be trained based on data collected from the sending device 200 during scenario execution and data collected from any receiving device that provides information about scenario execution, scenario state information from the sending device 200, etc. The dynamic personal rules 225 can be trained and fine-tuned locally on the sending device 200 to maintain privacy and efficiency.

[0046] The rule database 220 may include static rules 205, dynamic general rules 210, and merged rules 215. In some embodiments, dynamic personal rules 225 may also be included in the rule database 220. The rule database 220 may be substantially the same as the one described above with respect to Figure 1 The static rules 205 may be obtained from any source. In some embodiments, the static rules 205 are provided by a cloud hosting service (e.g., Figure 1 The static rules 115 described above can be provided by the cloud-hosted static rules 115 described above. The static rules can provide thresholds or pre-filtering criteria for the dynamic model used by the rule engine 255. The dynamic general rules 210 can be obtained from any source. In some embodiments, the dynamic general rules 210 are provided by a cloud-hosted service (e.g., with respect to Figure 1 The dynamic generic rules 210 may include a generic machine learning model trained and provided by a remote server, and may include a generic and impersonal model such that, for example, the information used to train the model does not include location, specific Name, and other information that is private to the device or user. The rule database 220 may also include merged rules 215. The merged rules 215 may include static rules 205, dynamic general rules 210, and dynamic personal rules 225. The merged rules 215 may be a set of scenario-specific rules that include merged rules from static rules 205, dynamic general rules 210, and dynamic personal rules 225 associated with the corresponding scenario. Rules may be merged by components in the rule database 220, or in some embodiments, by the rule engine 255.

[0047] In some embodiments, the rules engine 255 can process the static rules 205 and dynamic general rules 210 from the rules database 220 and process the dynamic personal rules 225 to generate the merged rules 215. The rules engine 255 can use the merged rules 215 to analyze the signals from the signal and status receiver and processing 230 to determine whether another device is ready to participate in the selected scenario. For example, based on analyzing the relevant signals using the relevant merged rules 215 for the scenario, the rules engine 255 can identify the transmission for the announcement and whether there is another device that may be listening for the announcement. As an example, in a scenario for pairing with a vehicle stereo, the rules engine 255 can analyze the signal to determine whether the sending device 200 may be in a vehicle that meets the parameters (e.g., a vehicle that the user regularly enters) and has not yet been paired with the sending device 200. As another example, the sending device 200 may have a scenario for transferring a call from the sending device 200 to another device. The rules engine 255 can evaluate the signal to determine whether the sending device 200 may be near the device (e.g., a home computer) to which the user wants the call to be transferred. In such an example, the rules engine 255 may determine that a receiving device may be available and listen for such an announcement. When the rules engine 255 determines that another device may be ready to participate in the selected scenario, an indication is provided to the scenario publication 260. The rules engine 255 may also select a transmission for sending the announcement based on the analysis. For example, based on the analysis and available options for the announcement transmission in a given scenario, a transmission with a stronger signal may be used instead of a transmission with a weaker signal.

[0048] The signal and status receiver and processing 230 may be substantially similar to that with respect to Figure 1The described signal and state receiver and processing 135 are the same. The signal and state receiver and processing 230 may include a signal source 235, a signal receiver 240, a signal filter 245, and a scene state tracking 250. Although the signal source 235 is shown as part of the signal and state receiver and processing 230, the signal source 235 may include many sources outside the signal and state receiver and processing 230 components. For example, a sensor including a motion sensor may be part of the transmitting device 200 and may include hardware components and software components that are included in the transmitting device 200 with or without the signal and state receiver and processing module 230. The signal source 235 may include any source of signals including components that provide information about device status, connectivity, sensors, etc. For example, the transmitting device 200 may include a transceiver that sends and receives communication signals that may provide data related to, for example, signal strength. For example, as another example, a signal related to whether the transmitting device 200 is in sleep mode or is being actively used may be received from an operating system. The signal receiver 240 receives a signal from the signal source 235. For example, in some embodiments, the signal receiver 240 can subscribe to certain signals. In some embodiments, the original signal from the signal source 235 can be noisy. The signal filter 245 can be used to filter the signal received by the signal receiver 240. The static rule 205 can be used to filter the signal in the signal filter 245. The filtered signal from the signal filter 245 can be provided to the rule engine 255 for analysis, and provided to the scene state tracking 250 for tracking the state of the scene. In some embodiments, the scene state tracking 250 can use the scene state to determine which scenes will be executed. In some embodiments, the received signal can indicate that the scene should be executed. For example, user interaction (direct-e.g., button click to find a device; indirect-e.g., user launches an application) can be between signals for affecting the suitability of a given scene. For example, the signal can be defined in the rule as an enable or disable criterion for determining whether a given scene will be executed. In the case where multiple scenes can meet the execution criteria, the static rule 205 can provide a guardrail to break the tie (e.g., via a priority or a calculated threshold), or in some embodiments, the system can indicate that user input is required to select a scene. The scenario state tracking 250 may provide the state of the scenario to the rule engine 255 as an additional input for analysis of the filtered signal from the signal filter 245. The scenario state tracking 350 may include state information about the scenario, including which steps are completed in a given scenario, which steps have been attempted and failed, etc. The scenario state tracking 250 may also provide data about the state of the scenario to the dynamic personal rules 225 for fine-tuning the model.Once the receiving device receives the notification and performs actions to facilitate the scenario, the scenario state tracking 250 can also receive information about the scenario execution from the receiving device. The information from the receiving device can be provided to the dynamic personal rules 225 for additional fine-tuning of the machine learning model.

[0049] Scenario publication 260 may include hardware and / or software components capable of sending announcements intended to advance the selected scenario.Scenario publication 260 may send announcements on the selected transport once rules engine 255 provides an indication that a receiving device may be ready to listen and receive announcements.

[0050] In use, the transmitting device 200 is operating and a signal is being generated by a signal source 235. The signal receiver 240 can receive the signal, and the signal filter 245 can filter the signal and provide the signal to the scene state tracking 250. The scene state tracking 250 can select a scene for execution. The selected scene can be provided to the rule engine 255 by the scene state tracking 250 together with the scene state. The rule database 220 can be updated periodically as needed, by subscription, by request, or in accordance with any other schedule. Static rules 205 can be obtained and used by the signal filter 245 and the rule engine 255. Dynamic general rules 210 can also be updated periodically as needed, by subscription, by request, or in accordance with any other schedule. Dynamic personal rules 225 can be generated and trained periodically as needed, by request, or in accordance with any other schedule. The merged rules 215 can be created for scenes by, for example, the rule engine 255 or by components in the rule database 220. Once the rule engine 255 has the selected scenario, it can access the relevant merged rules 215. The rule engine 255 can also receive relevant signals from the signal filter 245. In some embodiments, the signal filter 245 can also know which scenario is being executed and can provide only relevant signals to the rule engine 255. The rule engine can use the merged rules to analyze the filtered signals for a given scenario to determine whether the receiving device is likely to be listening for announcements to advance the scenario. The rule engine 255 can also select a transmission for sending the announcement based on the analysis. In response to making such a determination, the rule engine 255 can provide an indication to the scenario publication 260 that the receiving device may be ready to listen for announcements. If an announcement is selected in the analysis, the rule engine 255 can also provide a preferred transmission for sending the announcement. In response to receiving the indication, the scenario publication 260 can send the announcement.

[0051] Figure 3 is a simplified block diagram of a receiving device 300. For example, the receiving device 300 may be a Figure 1The receiving device 110 is depicted. The receiving device 300 may include a rules database 320, dynamic personal rules 325, signal and state receiver and processing 330, a rules engine 355, a scenario subscriber 360, and a scenario execution 365.

[0052] Dynamic personal rules 325 may be substantially similar to Figure 1 The described personal machine learning model 150 and relative to Figure 2 The dynamic personal rules 325 are the same as the dynamic personal rules 225 described above. The dynamic personal rules 325 can be used for both smart listening and smart reception in a single device. The dynamic personal rules 325 may include a machine learning model generated and trained using personal information from the receiving device 300, particularly with respect to attempting to execute various scenarios. The dynamic personal rules 325 may include components for training and fine-tuning the machine learning model locally. In some embodiments, the general machine learning model provided by the cloud-hosted model training 120 may provide a basis for the generation of dynamic personal rules 325. For example, the dynamic personal rules 325 may also include personal embeddings (e.g., location information, Personal information may include any information about the receiving device 300 that is kept locally for privacy reasons. For example, the receiving device 300 is connected to a The name of the access point may be considered personal information that may not be generalized and instead should only be maintained locally on the receiving device 300. Other examples of personal information may include location information, IP address, Names, names of other connected devices, access point names, etc. In some embodiments, dynamic personal rules 325 can be scenario-specific models. Dynamic personal rules 325 can be trained based on data collected from receiving device 300 during scenario execution and data collected from any receiving device that provides information about scenario execution, scenario state information from receiving device 300, etc. Dynamic personal rules 325 can be trained and fine-tuned locally on receiving device 300 to maintain privacy and efficiency.

[0053] The rule database 320 may include static rules 305, dynamic general rules 310, and merged rules 315. In some embodiments, once the machine learning model is trained, dynamic personal rules 325 may also be included in the rule database 320. The rule database 320 may be substantially similar to the rule database 320 with respect to Figure 1 The rules database 155 described and relative to Figure 2The static rules 305 may be obtained from any source. In some embodiments, the static rules 305 may be provided by a cloud hosting service (e.g., a server hosting a server, such as a server hosting a server, or a server hosting a server, such as ... Figure 1 The static rules 305 may provide thresholds or pre-filtering criteria for the dynamic model used by the rule engine 355. The dynamic general rules 310 may be obtained from any source. In some embodiments, the dynamic general rules 310 are provided by a cloud hosting service (e.g., with respect to Figure 1 Dynamic generic rules 310 may include a generic machine learning model trained and provided by a remote server, and may include a generic and impersonal model such that, for example, the information used to train the model does not include location, specific The rules database 320 may also include merged rules 315. The merged rules 315 may include static rules 305, dynamic general rules 310, and dynamic personal rules 325. The merged rules 315 may be a set of scenario-specific rules that include merged rules from static rules 305, dynamic general rules 310, and dynamic personal rules 325 associated with the corresponding scenario. The rules may be merged by components in the rules database 320, or in some embodiments, by the rules engine 355.

[0054] The rules engine 355 can be substantially similar to Figure 1 The rules engine 165 described and relative to Figure 2The rule engine 255 described is the same. The rule engine 355 can be used for both smart listening and smart reception in a single device. In some embodiments, the rule engine 355 can process static rules 305 and dynamic general rules 310 from the rule database 320 and process dynamic personal rules 325 to generate merged rules 315. The rule engine 355 can use the merged rules 315 to analyze the signals from the signal and state receiver and processing 330 to determine whether another device is ready to participate in the selected scene. For example, based on analyzing the relevant signals using the relevant merged rules 315 for the scene, the rule engine 355 can determine that there is another device that may be announcing. As an example, in a scene for pairing with a vehicle stereo, the rule engine 355 can analyze the signal to determine whether the sending device may be in a vehicle that meets the parameters (e.g., a vehicle that the user regularly enters) and has not yet been paired with the sending device 200. As another example, the receiving device 300 can have a scene for transferring a call from another device to the receiving device 300. The rules engine 355 can evaluate the signal to determine whether the sending device may be nearby, and the user wants the call to be transferred from the sending device. In such an example, the rules engine 355 can determine that the sending device may be announcing. When the rules engine 355 determines that another device may be ready to participate in the selected scene, an indication is provided to the scene subscriber 360.

[0055] The signal and status receiver and processing 330 can be substantially the same as with respect to Figure 1 The signal and status receiver and processing 160 described and relative to Figure 2The described signal and state receiver and processing 230 are the same. The signal and state receiver and processing 330 can be used for both smart listening and smart reception in a single device. The signal and state receiver and processing 330 may include a signal source 335, a signal receiver 340, a signal filter 345, and a scene state tracking 350. Although the signal source 335 is shown as part of the signal and state receiver and processing 330, the signal source 335 may include many sources outside the signal and state receiver and processing 330 components. For example, a sensor including a motion sensor may be part of the receiving device 300 and may include hardware components and software components that are included in the receiving device 300 with or without the signal and state receiver and processing 330 module. The signal source 335 may include any source of a signal, including components that provide information about device status, connectivity, sensors, etc. For example, the receiving device 300 may include a transceiver that sends and receives communication signals that can provide data such as signal strength. For example, as another example, a signal related to whether the receiving device 300 is in sleep mode or is being actively used can be received from an operating system. The signal receiver 340 receives a signal from a signal source 335. For example, in some embodiments, the signal receiver 340 may subscribe to certain signals. In some embodiments, the original signal from the signal source 335 may be noisy. The signal filter 345 may be used to filter the signal received by the signal receiver 340. The static rule 305 may be used to filter the signal in the signal filter 345. The filtered signal from the signal filter 345 may be provided to the rule engine 355 for analysis, and provided to the scene state tracking 350 for tracking the state of the scene. In some embodiments, the scene state tracking 350 may use the scene state to determine which scenes will be executed. In some embodiments, the received signal may indicate that the scene should be executed. For example, user interaction (direct - for example, a button click to find a device; indirect - for example, a user starts an application) may be between signals for affecting the suitability of a given scene. For example, the signal may be defined in a rule as an enable or disable criterion for determining whether a given scene will be executed. In the event that multiple scenarios may meet the execution criteria, the static rules 305 may provide guardrails to break ties (e.g., via priorities or calculated thresholds), or in some embodiments, the system may indicate that user input is required to select a scenario. The scenario state tracking 350 may provide the state of the scenario to the rule engine 355 as an additional input for analysis of the filtered signal from the signal filter 345. The scenario state tracking 350 may also provide data about the state of the scenario to the dynamic personal rules 325 for fine-tuning the model. For example, a scenario may require multiple actions and steps to complete.The scenario state tracking 350 may include state information about the scenario, including which steps are completed in a given scenario, which steps have been attempted and failed, etc. Once the receiving device 300 receives the notification and performs actions to facilitate the scenario, the scenario state tracking 350 may also send information about the scenario execution from the receiving device 300 to the sending device. The sending device may use the feedback about the scenario execution for additional fine-tuning of the machine learning model in the sending device.

[0056] The context subscriber 360 may include a hardware component and / or software component capable of listening for announcements intended to advance the selected context. Once the rules engine 355 provides an indication that a sending device may be advertising, the context subscriber 360 may listen for announcements.

[0057] The scenario execution 365 can receive notifications from the scenario subscribers 360 and perform actions to advance the scenario. For example, if the scenario is to pair the receiving device 300 with the sending device and the notification includes a pairing request, the scenario execution 365 can use the scenario state information from the scenario state tracking to determine the next action it should take to pair the devices. The scenario execution 365 can also provide feedback to the source of the dynamic universal rules 310 (e.g., cloud-hosted model training 120) for training and fine-tuning the dynamic universal rules 310, and to the sending device to track the state of the scenario and train and fine-tune the sending device's machine learning model in the dynamic personal rules maintained on the sending device.

[0058] In use, the receiving device 300 is operating and a signal is being generated by a signal source 335. The signal receiver 340 can receive the signal, and the signal filter 345 can filter the signal and provide the signal to the scene state tracking 350. The scene state tracking 350 can select a scene for execution. The selected scene can be provided to the rule engine 355 by the scene state tracking 350 together with the scene state. The rule database 320 can be updated periodically as needed, by subscription, by request, or in accordance with any other schedule. Static rules 305 can be obtained and used by the signal filter 345 and the rule engine 355. Dynamic general rules 310 can also be updated periodically as needed, by subscription, by request, or in accordance with any other schedule. Dynamic personal rules 325 can be generated, trained, and fine-tuned periodically as needed, by request, or in accordance with any other schedule. The merged rules 315 can be created for scenes by, for example, the rule engine 355 or by components in the rule database 320. Once the rule engine 355 has the selected scenario, it can access the relevant merged rules 315. The rule engine 355 can also receive relevant signals from the signal filter 345. In some embodiments, the signal filter 345 can also know which scenario is being executed and can provide only relevant signals to the rule engine 355. The rule engine 355 can use the merged rules 315 to analyze the filtered signals for a given scenario to determine whether the sending device may be announcing to advance the scenario. In response to making such a determination, the rule engine 355 can provide an indication to the scenario subscriber 360 that the sending device may be announcing. In response to receiving the indication, the scenario subscriber 360 can listen for the announcement. Once received, the scenario subscriber 360 can provide the announcement to the scenario execution 365. The scenario execution 365 can retrieve the state of the scenario from the scenario state tracking 350 and perform actions in response to receiving the announcement to advance the scenario. Once the scenario execution 365 performs the action, the scenario execution can provide feedback to the sending device, the source of dynamic universal rules, and the scenario state tracking 350.

[0059] Figure 4 is an exemplary method 400 for having an optimized smart notification. The method 400 may be performed by a sending device (such as, for example, Figure 1 The transmitting device 105 described or relative to Figure 2 The method begins by determining (402) a scene for completion. For example, the scene state tracking 250 can be used to determine a scene of interest based on, for example, the state of the scene and a received related signal indicating that some advancement of the scene is possible.

[0060] At 404, the transmitting device may receive a device signal associated with the scene. For example, a signal source (e.g., signal source 235) may continuously generate a signal, and a signal receiver (e.g., signal receiver 240) may receive the signal for processing.

[0061] At optional step 406 , the signal may be filtered by a signal filter (eg, signal filter 245 ), and the relevant signal associated with the scenario may be provided to a rule engine (eg, rule engine 255 ).

[0062] At optional step 408, static rules and dynamic rules from the remote hosting system may be received, personal dynamic rules may be accessed, and related rules may be merged into a merged set of rules. For example, static rules 205, dynamic general rules 210, and dynamic personal rules 225 may be merged into merged rules 215 by, for example, a component in rules engine 255 or rules database 220, which is configured to merge associated rules into a set of (e.g., scenario-specific) rules.

[0063] At optional step 410, the state of the scene can be provided to the rule engine and / or as feedback to further train and fine-tune the dynamic personal rules. For example, the scene state tracking 250 can provide the state of the scene to the rule engine 255 for analyzing relevant signals associated with the scene, and / or provide the state of the scene to the dynamic personal rules 225 for fine-tuning the machine learning model used by the rule engine 255 to analyze the signals.

[0064] At step 412, the rule engine can analyze the device signal based on the scene. For example, the rule engine 255 can analyze the relevant scene signal received from the signal receiver 240 or the optional signal filter 245 based on the relevant merged rules 215 for the selected scene, given the state of the scene received from the scene state tracking 250.

[0065] At optional step 414, the rules engine may select a transmission based on the scenario and device signals. For example, the rules engine 255 may select the transmission for the announcement that is most likely to succeed based on analyzing the relevant signals using the merged rules 215. For example, a transmission may be selected based on signal strength information for various transmissions received by the rules engine.

[0066] In response to determining that the receiving device may be ready to participate in the scenario, an announcement is sent at step 416. For example, the rules engine 255 may determine that the receiving device may be ready to participate in the scenario and provide an indication to the scenario publisher 260. In response, the scenario publisher 260 sends the relevant announcement for the receiving device to hear and respond to.

[0067] At optional step 418, the sending device may receive feedback from the receiving device regarding the execution of the scenario. For example, the scenario state tracking 250 may receive feedback from the receiving device regarding the state of the scenario and the execution of the next action for the scenario, including, for example, whether the next action succeeded or failed and the state of the scenario from the perspective of the receiving device.

[0068] At optional step 420, feedback can be used to train or fine-tune personal dynamic rules. For example, scene state tracking 250 can provide feedback to dynamic personal rules 225 for fine-tuning and training machine learning models stored locally on the sending device 200.

[0069] Figure 5 is an exemplary method 500 for intelligent monitoring with optimization. The method 500 may be performed by a receiving device, such as with respect to Figure 1 The receiving device 110 described or relative to Figure 3 The receiving device 300 is described. The method begins by determining (502) a scene for completion. For example, scene state tracking 350 can be used to determine a scene of interest based on, for example, the state of the scene and a received related signal indicating that some advancement of the scene is possible.

[0070] At 504, the receiving device may receive a device signal associated with the scene. For example, a signal source (e.g., signal source 335) may continuously generate a signal, and a signal receiver (e.g., signal receiver 340) may receive the signal for processing.

[0071] At optional step 506 , the signal may be filtered by a signal filter (eg, signal filter 345 ), and the relevant signal associated with the scenario may be provided to a rule engine (eg, rule engine 355 ).

[0072] At optional step 508, static rules and dynamic rules from the remote hosting system may be received, personal dynamic rules may be accessed, and related rules may be merged into a merged set of rules. For example, static rules 305, dynamic general rules 310, and dynamic personal rules 325 may be merged into merged rules 315 by, for example, a component in rules engine 355 or rules database 320, which is configured to merge associated rules into a set of (e.g., scenario-specific) rules.

[0073] At optional step 510, the state of the scene can be provided to the rule engine and / or as feedback to further train and fine-tune the dynamic personal rules. For example, the scene state tracking 350 can provide the state of the scene to the rule engine 355 to analyze relevant signals associated with the scene, and / or provide the state of the scene to the dynamic personal rules 325 to fine-tune the machine learning model used by the rule engine 355 to analyze the signals.

[0074] At step 512, the rule engine can analyze the device signal based on the scene. For example, the rule engine 355 can analyze the relevant scene signal received from the signal receiver 340 or the optional signal filter 345 based on the relevant merged rules 315 for the selected scene, given the state of the scene received from the scene state tracking 350.

[0075] At step 514, in response to determining that the sending device may be ready to participate in the scene, the receiving device may listen for announcements. For example, the rules engine 355 may determine that the sending device may be ready to participate in the scene and provide an indication to the scene subscriber 360. In response, the scene subscriber 360 may listen for announcements.

[0076] At optional step 516, the receiving device may receive the notification and in response perform an action to advance the scene. For example, scene subscriber 360 may receive the notification and provide the notification to scene execution 365. In response to receiving the notification, scene execution 365 may perform an action to advance the scene.

[0077] At optional step 518, the receiving device may send feedback based on the state of the scenario after the action is executed and the personal data associated with the scenario to the sending device. For example, scenario execution 365 may send feedback to the sending device regarding the state of the scenario and the execution of the next action for the scenario, including, for example, whether the next action succeeded or failed and the state of the scenario from the perspective of the receiving device 300. The feedback may be used by the sending device to further train and fine-tune the dynamic personal machine learning model stored locally on the sending device.

[0078] At optional step 520, the receiving device may send feedback based on the state of the scene after the action execution and general data associated with the scene to the remote training system. For example, the scene execution 365 may send feedback about the state of the scene and the execution of the next action for the scene to the cloud-hosted model training 120, including, for example, whether the next action succeeded or failed. The feedback may be used to further train and fine-tune the dynamic general machine learning model hosted by the service.

[0079] Feedback used to train local and hosted models from both the sending and receiving devices provides for continuous optimization of the system to improve the accuracy of determining whether a receiving or sending device is likely ready to participate in a scenario, where the corresponding device makes such a determination. Advantageously, the solutions provided herein help limit unnecessary signal transmission, listening for such signals, and prevent the associated battery consumption of participating in unnecessary transmissions and listening.

[0080] Figure 6 and Figure 7 A mobile computing device 600 is illustrated, such as a mobile phone, a smart phone, a wearable computer (such as smart glasses), a tablet computer, an e-reader, a laptop computer, or other AR-compatible computing device with which embodiments of the present disclosure may be practiced. Figure 6 , one aspect of a mobile computing device 600 for implementing aspects is illustrated. In a basic configuration, the mobile computing device 600 is a handheld computer having both input elements and output elements. The mobile computing device 600 typically includes a display 605 and one or more input buttons 610 that allow a user to enter information into the mobile computing device 600. The display 605 of the mobile computing device 600 can also act as an input device (e.g., a touch screen display). If an optional side input element 615 is included, it allows further user input. The side input element 615 can be a rotary switch, a button, or any other type of manual input element. In an alternative aspect, the mobile computing device 600 can incorporate more or fewer input elements. For example, in some embodiments, the display 605 may not be a touch screen. In another alternative embodiment, the mobile computing device 600 is a portable telephone system, such as a cellular phone. The mobile computing device 600 can also include an optional keypad 635. The optional keypad 635 can be a physical keyboard or a "soft" keyboard generated on the touch screen display. In various embodiments, output elements include a display 605 for showing a graphical user interface (GUI), a visual indicator 620 (e.g., a light emitting diode), and / or an audio transducer 625 (e.g., a speaker). In some aspects, the mobile computing device 600 incorporates a vibration transducer for providing tactile feedback to the user. In yet another aspect, the mobile computing device 600 incorporates input and / or output ports for sending or receiving signals to or from external devices, such as an audio input (e.g., a microphone jack), an audio output (e.g., a headphone jack), and a video output (e.g., an HDMI port).

[0081] Figure 7700 is a block diagram illustrating the architecture of one aspect of a mobile computing device 700. That is, the mobile computing device 700 may incorporate a system (e.g., architecture) 702 to implement some aspects. In one embodiment, the system 702 is implemented as a "smart phone" capable of running one or more applications (e.g., browsers, email, calendars, contact managers, messaging clients, games, and media clients / players). In some aspects, the system 702 is integrated into a computing device, such as an integrated personal digital assistant (PDA) and wireless phone.

[0082] One or more application programs 766 may be loaded into the memory 762 and run on or in association with the operating system 764. Examples of application programs include a phone dialer program, an email program, a personal information management (PIM) program, a word processing program, a spreadsheet program, an Internet browser program, a messaging program, and the like. The system 702 also includes a non-volatile storage area 768 within the memory 762. The non-volatile storage area 768 may be used to store persistent information that should not be lost if the system 702 loses power. The application programs 766 may use information and store the information in the non-volatile storage area 768, such as emails or other messages used by the email application, and the like. A synchronization application (not shown) also resides on the system 702 and is programmed to interact with a corresponding synchronization application residing on a hosted computer to keep the information stored in the non-volatile storage area 768 synchronized with the corresponding information stored at the hosted computer. It should be understood that other applications may be loaded into the memory 762 and run on the mobile computing device 700, including instructions for providing and operating the focus state notification platform.

[0083] System 702 has a power source 770, which can be implemented as one or more batteries. Power source 770 can also include an external power source, such as an AC adapter or a powered docking station that replenishes or recharges the batteries.

[0084] The system 702 may also include a radio interface layer 772 that performs the functions of sending and receiving radio frequency communications. The radio interface layer 772 facilitates wireless connectivity between the system 702 and the "outside world" via a communications carrier or service provider. Transmissions to and from the radio interface layer 772 are performed under the control of the operating system 764. In other words, communications received by the radio interface layer 772 may be disseminated to the application 766 via the operating system 764, and vice versa. The radio communications may include near field communication transmissions, such as Near Field Communication (NFC), Ultra Wideband (UWB), Direct, etc.

[0085] The visual indicator 620 can be used to provide a visual notification, and / or the audio interface 774 can be used to generate an audible notification via an audio transducer 625. In the illustrated embodiment, the visual indicator 620 is a light emitting diode (LED), and the audio transducer 625 is a speaker. The device can be directly coupled to a power supply 770 so that when the device is activated, even if the processor 760 and other components may be turned off to save battery power, the device remains open for a duration determined by the notification mechanism. The LED can be programmed to remain open indefinitely until the user takes action to indicate the power-on state of the device. The audio interface 774 is used to provide an audible signal to the user and to receive an audible signal from the user. For example, in addition to being coupled to the audio transducer 625, the audio interface 774 can also be coupled to a microphone to receive an audible input, such as to facilitate a telephone conversation. According to an embodiment of the present disclosure, the microphone can also act as an audio sensor to facilitate the control of notifications, as will be described below. The system 702 may also include a video interface 776 that enables operation of the onboard camera 630 to record still images, video streams, and the like.

[0086] The mobile computing device 700 implementing the system 702 may have additional features or functionality. For example, the mobile computing device 700 may also include additional data storage devices (removable and / or non-removable) such as magnetic disks, optical disks, or tapes. Such additional storage devices may include a plurality of storage devices, such as a plurality of storage devices, such as a plurality of storage devices, and a plurality of storage devices. Figure 7 , illustrated by non-volatile storage area 768.

[0087] As described above, data / information generated or captured by the mobile computing device 700 and stored via the system 702 may be stored locally on the mobile computing device 700, or the data may be stored on any number of storage media that may be accessed by the device via the radio interface layer 772 or via a wired connection between the mobile computing device 700 and a separate computing device associated with the mobile computing device 700 (e.g., a server computer in a distributed computing network such as the Internet). It should be understood that such data / information may be accessed via the mobile computing device 700 via the radio interface layer 772 or via a distributed computing network. Similarly, such data / information may be readily transferred between computing devices for storage and use according to well-known data / information transfer means and storage means, including email and collaborative data / information sharing systems.

[0088] Figure 8is a block diagram illustrating the physical components (e.g., hardware) of a computing device 800, with which aspects of the present disclosure may be practiced. The computing device components described below may have computer executable instructions for performing operations associated with the smart notification and / or reception system. In a basic configuration, the computing device 800 may include at least one processing unit 802 and a system memory 804. Depending on the configuration and type of the computing device, the system memory 804 may include, but is not limited to, volatile storage (e.g., random access memory), non-volatile storage (e.g., read-only memory), flash memory, or any combination of such memories. The system memory 804 may include an operating system 805 suitable for running one or more applications. For example, the operating system 805 may be suitable for controlling the operation of the computing device 800. In addition, embodiments of the present disclosure may be practiced in conjunction with a graphics library, other operating systems, or any other application and is not limited to any particular application or system. The basic configuration is Figure 8 800 is illustrated by those components within dashed line 808. Computing device 800 may have additional features or functionality. For example, computing device 800 may also include additional data storage devices (removable and / or non-removable) such as, for example, magnetic disks, optical disks, or tapes. Such additional storage Figure 8 8 is illustrated by a removable storage device 809 and a non-removable storage device 810.

[0089] As stated above, a plurality of program modules and data files may be stored in the system memory 804. When executed on the processing unit 802, the program module 806 (e.g., the scene component 820) may perform processes including, but not limited to, aspects as described herein. According to an example, the rule engine 811 may perform one or more operations associated with obtaining rules and machine learning models for analyzing signals for a given scene. The scene state tracking 813 may perform one or more operations associated with tracking the state of the scene and sending the state to the rule engine 811 and / or the personal ML training 815. The personal machine learning model training 815 may perform one or more operations associated with training a machine learning model used by the rule engine 811 in the scene. The scene component 820 may include more or fewer modules for performing the functions described herein.

[0090] In addition, embodiments of the present disclosure may be practiced in electronic circuits including discrete electronic components, packaged or integrated electronic chips containing logic gates, circuits utilizing microprocessors, or on a single chip containing electronic components or microprocessors. For example, embodiments of the present disclosure may be practiced via a system on a chip (SOC) in which Figure 8Each component or many of the components illustrated in the figure can be integrated into a single integrated circuit. Such a SOC device may include one or more processing units, a graphics unit, a communication unit, a system virtualization unit, and various application functions, all of which are integrated (or "burned") into a chip substrate as a single integrated circuit. When operated via the SOC, the functions described herein with respect to the ability to switch protocols for the client can be operated via application-specific logic integrated with other components of the computing device 800 on a single integrated circuit (chip). The embodiments of the present disclosure can also be practiced using other technologies capable of performing logical operations (such as, for example, AND, OR, and NOT), including but not limited to mechanical technology, optical technology, fluidic technology, and quantum technology. In addition, the embodiments of the present disclosure can be practiced in a general-purpose computer or in any other circuit or system.

[0091] The computing device 800 may also have one or more input devices 812, such as a keyboard, a mouse, a pen, a sound or voice input device, a touch or sliding input device, etc. Output device(s) 814 (such as a display, a speaker, a printer, etc.) may also be included. The above devices are examples and other devices may be used. The computing device 800 may include one or more communication connections 816 that allow communication with other computing devices 850. Examples of suitable communication connections 816 include, but are not limited to, radio frequency (RF) transmitters, receivers, and / or transceiver circuits; universal serial bus (USB), parallel ports, and / or serial ports.

[0092] The term computer-readable medium used herein may include computer storage media. Computer storage media may include volatile and non-volatile, removable, and non-removable media implemented in any method or technology for the storage of information (such as computer-readable instructions, data structures, or program modules). System memory 804, removable storage device 809, and non-removable storage device 810 are all examples of computer storage media (e.g., memory storage). Computer storage media may include RAM, ROM, electrically erasable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, cassette, tape, disk storage or other magnetic storage device, or any other manufactured product that can be used to store information and can be accessed by computing device 800. Any such computer storage medium may be part of computing device 800. Computer storage media does not include carrier waves or other propagated or modulated data signals. Computer storage devices do not include carrier waves or other propagated or modulated data signals.

[0093] Communication media may be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and includes any information delivery media. The term "modulated data signal" may describe a signal having one or more characteristics set or changed in a manner that encodes information in the signal. By way of example and not limitation, communication media may include wired media such as a wired network or direct-wired connection and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media.

[0094] Fig. 9 An aspect of the architecture of a system for processing data received from a remote source (such as a personal / general purpose computer 904, a tablet computing device 906, or a mobile computing device 908) at a computing system is illustrated, as described above. The content displayed at the server device 902 can be stored in different communication channels or other storage types. For example, various documents can be stored using a directory service 922, a web portal 924, a mailbox service 926, an instant messaging repository 928, or a social networking site 930. Program modules 806 can be adopted by a client communicating with the server device 902, and / or program modules 806 can be adopted by the server device 902. The server device 902 can provide data to a client computing device (such as a personal / general purpose computer 904, a tablet computing device 906, and / or a mobile computing device 908 (e.g., a smart phone)) and provide data from the client computing device through a network 915. By way of example, the computer systems described herein may be embodied in a personal / general purpose computer 904, a tablet computing device 906, and / or a mobile computing device 908 (e.g., a smartphone). In addition to receiving graphics data available for pre-processing at a graphics originating system or post-processing at a receiving computing system, any of the embodiments of the computing device may obtain content from a repository 916.

[0095] For example, aspects of the present disclosure are described above with reference to the block diagrams and / or operational diagrams of the methods, systems, and computer program products according to aspects of the present disclosure. The functions / actions indicated in the blocks may not occur in the order shown in any flow chart. For example, depending on the functions / actions involved, two blocks shown in succession may actually be executed substantially simultaneously, or the blocks may sometimes be executed in reverse order.

[0096] The description and illustration of one or more aspects provided in this application are not intended to limit or constrain the scope of the disclosure claimed in any way. The aspects, examples, and details provided in this application are considered to be sufficient to convey ownership and enable others to make and use the best mode of the disclosure claimed. The disclosure claimed should not be interpreted as being limited to any aspect, example, or details provided in this application. Whether it is in a combined form or shown and described individually, various features (both structurally and methodically) are intended to be selectively included or omitted to produce an embodiment with a specific set of features. Description and explanation of the disclosure have been provided, and those skilled in the art can imagine changes, modifications, and alternative aspects within the spirit of the broader aspects of the general inventive concept embodied in this application, which do not depart from the broader scope of the disclosure claimed.

[0097] The various embodiments described above are provided by way of illustration only and should not be construed as limiting the claims appended hereto. Those skilled in the art will readily appreciate that various modifications and changes may be made without following the example embodiments and applications illustrated and described herein, and without departing from the true spirit and scope of the appended claims.

Claims

1. A computer-implemented method for intelligent notification, the method comprising: Determine a scenario between a sending device and a receiving device for completion; receiving a device signal associated with the scenario from the sending device; analyzing the device signal based on the scenario using a rules engine to determine whether the receiving device is ready to participate in the scenario, wherein the rules engine includes a combination of static rules and a machine learning model; as well as In response to determining that the receiving device is ready to participate in the scenario, a notification is sent to advance the scenario. 2 . The computer-implemented method of claim 1 , wherein the device signal comprises a device status signal, a connectivity signal, a sensor signal, an operating system signal, an application signal, or a combination thereof.

3. The computer-implemented method of claim 1 , further comprising: A transmission is selected based on the scenario and the device signal, wherein the announcement is sent on the selected transmission.

4. The computer-implemented method of claim 1 , further comprising: receiving the static rules from a first remote hosting system; receiving a general machine learning model from a second remotely hosted system, wherein the general machine learning model comprises a trained model trained using general data from a plurality of devices attempting to complete the scenario; accessing a personal machine learning model, wherein the personal machine learning model comprises a trained model trained using personal data from the sending device attempting to complete the scenario; and The static rules, the general machine learning model, and the personal machine learning model are merged into a set of merged rules for the rules engine for analyzing the device signals based on the scenario.

5. The computer-implemented method of claim 1 , further comprising: The device signal is filtered based on the scenario, wherein the rules engine analyzes the filtered device signal.

6. The computer-implemented method of claim 1 , further comprising: Tracking the status of the scene; as well as The state of the scenario is provided to the rules engine, wherein the rules engine uses the state of the scenario in the analyzing of the device signal.

7. The computer-implemented method of claim 1 , further comprising: Tracking the status of the scene; as well as The state of the scenario is used to train a personal machine learning model for use in the rules engine.

8. The computer-implemented method of claim 7, further comprising: receiving feedback from the receiving device regarding the execution of the scenario; as well as The feedback is used to train the personal machine learning model.

9. A sending device for smart notification, the sending device comprising: A memory for storing executable program codes; as well as a processor functionally coupled to the memory, the processor responsive to computer executable instructions contained in the program code and operable to: Determining a scenario for completion between the sending device and the receiving device; receiving a device signal associated with the scenario from the sending device; analyzing the device signal based on the scenario using a rules engine to determine whether the receiving device is ready to participate in the scenario, wherein the rules engine includes a combination of static rules and a machine learning model; as well as In response to determining that the receiving device is ready to participate in the scenario, a notification is sent to advance the scenario.

10. A transmitting device according to claim 9, wherein the processor is responsive to further computer executable instructions contained in the program code and is operable to: selecting a transmission based on the scenario and the device signal; and The notification is sent on the selected transport.

11. The transmitting device of claim 9, wherein the processor is responsive to further computer executable instructions contained in the program code and is operable to: The device signal is filtered based on the scenario, wherein the rules engine analyzes the filtered device signal.

12. A computer-implemented method for intelligent monitoring, the method comprising: Determine a scenario between a sending device and a receiving device for completion; receiving a device signal associated with the scenario from the receiving device; analyzing the device signal based on the scenario using a rules engine to determine whether the sending device is ready to participate in the scenario, wherein the rules engine includes a combination of static rules and a machine learning model; as well as In response to determining that the sending device is ready to participate in the scenario, listening for announcements to advance the scenario.

13. The computer-implemented method of claim 12, further comprising: receiving the notification; as well as In response to receiving the notification, an action is performed to advance the scenario.

14. The computer-implemented method of claim 12, further comprising: Tracking the status of the scene; as well as Feedback based on the state of the scenario and personal data associated with the scenario are sent to the sending device.

15. The computer-implemented method of claim 12, further comprising: Tracking the status of the scene; as well as Feedback based on the state of the scenario and general data associated with the scenario are sent to a remote training system.

Images