Patent Application
20250234164
This disclosure is generally directed to systems and methods for notification routing to a user's devices based on real-time user interaction with one or more of the user's devices. In particular, systems and methods are provided herein that enable selective delivery of notifications to one or more of a user's devices based on the real-time context of how the user is presently using the devices. The real-time context may aid in determining whether the user devices are being presently used or not used, determining the purpose for which user devices are being presently used, and determining whether one of the user's devices is in proximity to another of user's devices, among other factors. In addition, the systems and methods enable customization of user preferences to provide greater user control for notification delivery to the user's devices.
In today's digitally connected world, many individuals own at least two personal electronic devices (“user devices”), which may include a smartphone, a smart watch, a tablet computer, a laptop computer, a desktop computer, a smart home assistant, a smart TV, a streaming media player (SMP), a gaming system, and a VR/AR headset, among others. Some of these user devices may provide the user with notifications of things that are important to the user: birthdays, anniversaries, appointments, daily schedules, missed phone calls, voice mails, text communications, emails, news stories, and doorbell rings, among many other types of notifications. Some of the notifications that appear on these user devices are application specific, and therefore also application dependent, such that many types of user devices (e.g., some smart TVs, tablets, and laptop/desktop computers) may receive and display a notification if and only if the application originating the notification (e.g., a calendar application may originate a birthday notification because the calendar application hosts data about birthdays) is present on the user device. Still other user devices, such as smart watches, may be able to receive notifications even without the application installed, yet the display screens of these devices are small and often not capable of displaying certain types of media (e.g., media content having frame rates higher than 15 fps) that may be included as part of the notification. These designs give rise to multiple shortcomings relating to how, when, and where an owner of multiple user devices receives notifications about things that are important to them.
As an illustrative example, at present a user with multiple user devices, such as a smartphone, a smartwatch, a tablet computer, and a smart TV, may not be able to receive and view a notification on the smart TV when that notification relates to an incoming message in a messaging application. The reason for this shortcoming is that the application isn't, and frequently can't be, installed on the smart TV, and current messaging routing requires that the application be on the device to which the notification is routed. That same user may receive the notification on both the smartphone and the tablet computer if the application is installed on each respective user device. As for the smart watch, the user may receive the notification on the smart watch if the smart watch is paired with the user's smartphone, the application is installed on the smartphone, and the smart watch has an application installed that enables the display of notifications for the application on the smartphone.
Another shortcoming is found in the ability to customize the delivery and display of notifications. By way of example, a user may have a smartphone, a smartwatch, a tablet computer, and a laptop computer, all of which can receive and display notifications associated with an installed application. However, the user may prefer to receive notifications for this application on their smartphone during certain periods of the day, on their laptop computer during other periods of the day, and on their tablet computer during still other periods of the day. The user may also wish to receive notifications on their smart watch during parts of the day that overlaps portions of these other periods. To accomplish this, the user must access each user device separately to set up customizations for display of notifications. And, when the user is in situations or at locations that the existing customizations don't adequately meet the user's needs, the user must again access each user device separately to change the customizations for display of notifications. In addition to customization of notifications on each device, the user may also wish to customize the display of notifications according to the associated applications. To accomplish such customizations, the user must once again access each device separately to set up customizations for display of notifications for each individual application.
A need, therefore, exists to improve the process in which notifications are routed to a user's multiple user devices. To overcome such shortcomings, systems and methods that provide adaptive notification routing may be employed to take into account real-time contextual circumstances of the user devices, including the real-time status of multiple user devices, real-time user interactions with one or more of the user devices, and the proximity, or lack thereof, between user devices, among other factors. In addition, the systems and methods may advantageously route notifications to user devices based on notification parameters established by the user and the real-time device status, without the requirement that the application originating the notification be present on the user device. Also, the systems and methods may advantageously provide the user with centralized customizable control over certain aspects of the notification routing, thereby alleviating the need to configure each device individually.
To this end, systems and methods are presented for contextually and dynamically routing notifications to one or more of a user's devices. In some embodiments, before any notifications are routed, the user sets up a notification account with a notification service, associates user devices with the notification account, and establishes notification parameters, which define the user's preferences for routing notifications. These notification parameters form part of the basis for determining how notifications are routed to the user's devices. Once the notification account is set up with the user devices and the notification parameters, the notification service receives real-time device status data based on real-time user interaction with at least one of the user devices associated with the notification account. The notification service determines routing parameters based on the real-time device status data, and when notification data from an application service is received for the notification account, the notification service generates a notification based on the notification data. The notification service thereafter identifies, based on the notification parameters and the routing parameters, one or more recipient user devices, from among the user devices associated with the notification account, to which the notification is then sent.
Advantages are realized in the systems and methods described herein by using contextual and dynamic routing in combination with notification parameters established by the user. This combination advantageously provides the user with notification routing that is highly flexible, easy to configure from a single user device, and takes into account real-time user device interaction when determining to which of the user's devices a notification should be routed. With these advantages and other aspects of the described systems and methods herein, the notification routing of the present disclosure addresses the aforementioned shortcomings of existing notification services.
The present disclosure, in accordance with one or more various embodiments, is described in detail with reference to the following figures. The drawings are provided for purposes of illustration only and merely depict typical or example embodiments. These drawings are provided to facilitate an understanding of the concepts disclosed herein and should not be considered limiting of the breadth, scope, or applicability of these concepts. It should be noted that for clarity and ease of illustration, these drawings are not necessarily made to scale. The figures include:
Systems and methods are described herein for contextually routing notifications to one or more user devices using routing parameters, which are based on real-time user interaction with one or more of the user devices, and notification parameters, which are user-designated preferences and policies for routing notifications.
As described herein, the term “user device” and its variants refer to any electronic device with which a person, the user, may interact with to send, receive, view, edit, and/or store data, regardless of the form of the data. Variants of the term “user device” may be used to differentiate between different user devices for purposes of this disclosure, even though the user devices may otherwise be of identical construction. Such variants may include “primary user device”, “secondary user device”, “first user device”, and “second user device”, among others, and the use of a variant is not intended to indicate any differences between user devices unless such differences are expressly indicated herein.
Turning in detail to the drawings,
The communication paths 112 enable communications between respective services and user devices. Each communication path 112 may separately or together include one or more distinct communication paths, such as a satellite path, a fiber-optic path, a cable path, a path that supports Internet communications (e.g., IPTV), free-space connections (e.g., for broadcast or other wireless signals), or any other suitable wired or wireless communication path or combination of such communication paths. The communication paths 112, however, are shown as a single path to avoid overcomplicating the drawing.
In the context of the example environment 100, the user device 104 is the primary user device, and the user device 106 is a secondary user device. The user device 104 is the primary user device because it is the user device that the user interacts with and has in their presence most frequently. The user device 106 is a secondary user device because it is one of the user's devices and it is not the primary user device. In some embodiments, the user may designate a user device as the primary user device. In some embodiments, there may be no designated difference between user devices for a notification account, such that there is no designated primary user device and no designated secondary user devices associated with the user's notification account.
The notification service 102 includes various modules and engines which add functionality to the notification service 102, including the account maintenance module 120, the proximity detection module 122, the analytics engine 124, and the routing engine 126. The notification service 102 may also include other engines, modules, and/or sub-services that add functionality to notification routing. In some embodiments, the notification service 102 may provide options for the notifications to include user device control instructions with notifications that meet pre-determined criteria and/or with notifications that are being sent to predetermined user devices. In some embodiments, in which notifications are sandboxed, as described below, the user device control instructions included with notifications may be limited to only a few select functions, an example being functions to pause and play media content.
The account maintenance module 120 enables interaction between the user and the notification service 102 so that the user may set up a notification account and establish or select notification parameters. The notification account also serves as a link between the application services 108, 110 and the user devices 104, 106. In general, when an application is launched on one of the user devices 104, 106, the application communicates with the notification service 102 to receive a unique identifier for delivery of notifications for that application. In addition, the application also communicates with the related application service 108, 110 to provide the unique identifier supplied by the notification service 102. When the application service 108, 110 generates notification data for sending a notification to one of the user devices 104, 106, the notification data communicated to the notification service 102 references the unique identifier so that the notification service 102 may route the notification to the correct user device 104, 106.
The notification parameters provide the user with customization options for routing notifications to one or more of the user devices 104,106. In some embodiments, the notification parameters may be user-defined policies that determine how notifications from specified applications should be routed to designated user devices 104, 106. In some embodiments, the notification parameters may be time-based policies that are used to determine how notifications during a certain time of day or night should be routed to designated user devices. In general, the notification parameters available to the user, through the implementation of user-defined routing policies and other types of notification routing options, provide the user with the ability to make broad customizations for notification routing in advance of receiving notifications, the customizations being based on applications that originate notifications, user devices, geographical locations of the user, geographical locations of the user devices, geographical locations of the user devices with respect to other user devices associated with the notification account, and time of the notifications, among other possible customization options.
The proximity detection module 122 enables determining the location of the user devices 104, 106, and the determined location of each user device 104, 106 may be used to help determine the proximity of the user devices 104, 106 to each other. The notification service 102 may make notification routing determinations based on the location of one or both user devices 104, 106 and/or based on the proximity of the user devices 104, 106 to one another. The real-time device status data received by the notification service 102 from the user devices 104, 106 may be used by the proximity detection module 122 to determine the location of the respective user devices 104, 106. To this end, the real-time device status data may include geolocation data (e.g., geofencing) via a global positioning system, wireless local area network connection data (e.g., Wi-Fi networks), cellular network connection data (e.g., LTE, 4G, and/or 5G networks), and signal strength from an RF protocol such as Bluetooth, among others and without limitation. The real-time device status data may also be used to determine when any two user devices 104, 106 are in proximity to each other and/or connected to the same wireless networks. For example, the real-time device status data may indicate that the two user devices 104, 106 are in proximity to each other, by geolocation, and connected to the same wireless network. This may be an indication that both devices are presently located in the same room of a house. In another example, the real-time device status data may indicate that the two user devices 104, 106 are in somewhat close proximity to each other, with geolocation and wireless network connections placing the user devices 104, 106 in the same house, but with the Bluetooth signals between the two user devices 104, 106 being weak. This may be an indication that even though both user devices 104, 106 are in the same house, they are not within the same room. There are many other types and combinations of real-time device status data that may be used to determine the present location of a user device, and thus also the proximity of one user device to another user device. As such, the nature of the real-time device status data received by the notification service from user devices, for purposes of determining user device location, is not intended to be limiting.
As another example, referring to
The analytics engine 124 also processes parts of the real-time user device status data received from the user devices. Whereas the proximity detection module 122 determines the location of the user devices 104, 106 from the real-time user device status data, the analytics engine 124 determines the operational status of the user devices 104, 106 from the real-time user device status data. To this end, the real-time user device status data may reflect real-time user interaction with one or both user devices 104, 106. In some embodiments, real-time user interaction may be determined by factors such how long the screen has been on (or off), touch interaction with a touch sensitive device, interaction with a specific application, among other indicators of a user's activity with a user device. In some embodiments, the real-time user device status data may indicate that the user is not presently using a user device 104, 106 (e.g. the display of the user device is off, the user device 104 has had no user input in several minutes, or if the user device 104 has a front-facing camera, the camera is receiving no light (e.g., the user device 104 is in a pocket, in a purse, or face-down on a table, and the like), among other similar indicators of present non-use), that the user is presently using a particular application on the user device 104, 106, or that the user device 104, 106 is presently displaying media content. In some embodiments, the real-time user device status data may also indicate that the user device 104 is in the user's possession, even if the user device 104 is not actively being used (e.g., the user device 104 was recently in motion). The type and nature of the real-time user device status data received from the user devices 104, 106 and analyzed by the analytics engine 124 are not intended to be limiting. Unlike analytics that attempt to analyze data from user devices in order to determine a user's habits, likes, dislikes, etc., one goal of the analytics engine 124 may be to determine what a user is doing right now in the present so that when notifications are routed, they may be routed to one of the user's user devices that is most probable for getting the notification seen by the user. Of course, as discussed herein, the real-time device status data is only one factor in determining to which user devices 104, 106 a notification should be routed.
Continuing with the example from above in which the user devices 104, 106 are determined to be located in the same house by the proximity detection module 122, the analytics engine 124 may determine the manner in which both user devices 104, 106 are presently being used, which will help determine how a notification from one of the application services 108, 110 is routed to most effectively be presented to the user. In this example, the analytics engine 124 may determine that the user is not actively using the user device 104, as the real-time device status data from the user device 106 indicates that the user device 104 has not moved for many minutes. The analytics engine 124 may also determine that the user is actively consuming media on the user device 106 (e.g., watching a TV show), as the real-time device data from the user device 106 indicates that media content is being actively displayed. Absent further real-time device status data relating to the proximity of the two user devices 104, 106, the analytics engine 124 may determine that a notification should be routed to both devices. However, if the real-time device status data indicates that the two user devices 104, 106 are located in the same room in the house, then the analytics engine 124 may determine that a notification should be routed to only the user device 106.
The routing engine 126 performs the notification routing for the notification service 102. The routing engine 126 receives notification data from the application services 108, 110, the notification data being identified for the user's notification account. From the notification data, the routing engine 126 generates a notification for routing to one or more of the user devices 104, 106. The routing engine 126 identifies which of the user devices 104, 106 are to be the recipients of the notification (also referred to herein as the recipient user devices) based on a combination of the notification parameters, which are defined by the user, and the routing parameters, which are based on the real-time device status data. Once the recipient user devices have been identified from among the user devices 104, 106, then the routing engine routes the notification to the recipient user devices. As shown in
Continuing with the example from above, from the real-time device status data the proximity detection module 122 determines that the user devices 104, 106 are located in the same room in the same house, and the analytics engine 124 determines that the user is consuming content on the user device 106 and the user device 104 has been inactive for several minutes. The co-location of the user devices 104, 106 and the level of user engagement (or non-engagement) with each user device 104, 106 are used by the routing engine 126 to determine the routing parameters for routing the notification. The routing engine 126 determines which of the user devices 104, 106 are to be recipient user devices based on both the routing parameters and the notification parameters established by the user. This determination for notification routing by the routing engine 126, in some embodiments, may be made based on preexisting statistical analysis of data relating to users' interactions with multiple user devices, with the notification parameters set by the user acting as boundaries and definitive decision points for the routing engine 126. Thus, in some embodiments, the notification parameters may be given more weight than the routing parameters as the routing engine 126 identifies the recipient user devices from among the user devices 104, 106.
The routing engine 126 also generates the notification from the notification data received from the application service 108. The routing engine 126 may base the notification on substantial portions, or all, of the notification data when generating the notification, as appropriate. In some embodiments, the notification may include instructions to one or more of the recipient user devices. Such instructions may instruct one (or all) of the recipient user devices to perform an action, such as pausing media content playback when displaying the notification and resuming media content playback when the notification is dismissed by the user. In some embodiments, the instructed action may be to retrieve content from a network-connected source and incorporate that content into display of the notification. Other types of actions, without limitation, may be included as part of the notification routed to the recipient user devices. Once the notification service 102 has identified the recipient user devices and the notification has been generated, then the routing engine 126 routes the notification to the recipient devices.
As indicated above, the notification generated by the routing engine 126 is based on the notification data received from the application service 108, which may be any application service associated with an application on at least one of the user's user devices 104, 106. The application need not be on all the user's user devices, as the notification service 102 may still route the notification to a user device that does not have the application installed (e.g., user device 106 is a smart TV and therefore may not have a social media application installed, yet notifications from a social media application service may still be routed to the user device 106). In some embodiments, the application may not be installed on either of the user devices 104, 106, but in such embodiments, the application would be installed on a third user device associated with the user's notification account but not shown in
The process of the notification service 102 routing notifications to the user devices 104, 106 may be further elucidated by another example, which is based on the application service 108 being a doorbell application. In this example, the user may be at home and have a doorbell camera installed at the front door of their home, and the doorbell camera is connected to a network for communications with the application service 108 and with one or more of the user devices 104, 106. The user device 104 may have the associated doorbell application installed, so that the user device 104 may communicate with the doorbell camera over the network. The doorbell camera may be configured to record and store video in response to predetermined conditions occurring, such as a visitor ringing the doorbell or motion being detected by the doorbell camera. The doorbell camera may be configured to store the video locally, on the device, or it may be configured to store the video on a remote device or server, or it may be configured to store the video with a remote cloud storage service. For purposes of this example, the doorbell camera video may be directly accessed by the application service 108 and by the user device 104 through the application installed on the user device 104, but the user device 106 does not have direct access to the doorbell camera video, as user device 106 does not have the doorbell application installed.
Continuing with the example, a visitor may ring the doorbell which triggers the doorbell camera to begin recording video of the visitor. The doorbell camera may alert the application service 108 about the doorbell ring and that video recording is being performed. The application service 108 may then communicate notification data to the notification service 102, and that notification data may include information about the doorbell ring (e.g., time of the ring, an identifier of the doorbell camera, and other pertinent information) along with a location identifier (e.g., a network address) indicating where the video recording is stored. The notification service 102 generates a notification based on the notification data and determines which of the user devices 104, 106 are to receive the notification based upon the notification parameters and the routing parameters. For purposes of this example, the proximity detection module 122 may determine, based on the most recent data received from each user device 104, 106, that the user device 104 is in close proximity to the user device 106, with both being in the same physical location and in the same room. The analytics engine 124 may determine, based on the most recent data received from each user device 104, 106, that the user device 104 has not been actively used by the user for more than 15 minutes and that the user device 106 is displaying media content, such as a television show. The notification service 102 therefore determines, based on analysis from the proximity detection module 122 and the analytics engine 124, that the notification is to be routed to both user devices 104, 106. In an alternate version of this example, the notification service 102 may determine that the notification is to be routed only to the user device 106, since that user device 106 is being actively used by the user and user device 104 is not.
In this example, the notification sent to each user device 104, 106 by the notification service 102 may be slightly different. The notification sent to the user device 104 may include the location identifier of the doorbell video along with instructions configured to instruct the user device 104 to retrieve a copy of the doorbell video using the location identifier. Since the user device 104 has the doorbell application installed, the user device 104 possesses the credentials for accessing the doorbell video using the location identifier. In comparison, the notification sent to the user device 106 may include instructions configured to instruct the user device 106 to retrieve a copy of the doorbell video from the user device 104, to pause playback of the media content when displaying the notification, and to resume playback of the media content when the notification is dismissed by the user (regardless of which user device 104, 106 is used to dismiss the notification). The user device 106, which does not have the doorbell application installed, does not possess the credentials for accessing the doorbell video directly from the doorbell camera using the location identifier. Alternatively, the notification sent to the user device 106 may include instructions to the user device 106 to receive the doorbell video from the user device 104 as streaming content. Upon receipt of the notification from the notification service 102, the user device 104 may automatically retrieve the doorbell video using the included location identifier and display the notification 140, including the doorbell video, on the display screen 130. Similarly, upon receipt of the notification from the notification service 102, the user device 106 may retrieve the doorbell video from the user device 104, pause playback of the media content 144 and display the notification 146, including the doorbell video 148, on the display screen 132. The automatic pause in playback of the media content 144 enables the user to focus on the notification 146 without missing any of the media content 144. When the user dismisses the notification 146, the user device 106 resumes playback of the media content.
In some embodiments, the instructions to the user device 104 may include stream casting instructions to the user device 106. For example, the routed notification may include instructions to the user device 104 that instruct the user device 104 to automatically stream-cast content associated with the notification to the user device 106. The user device 106 may be identified in the notification routed to the user device 104 by a device ID, a network address, or by other information sufficient to locate the user device 106 on a network for purposes of initiating the stream casting. The user device 104 may be instructed to retrieve the media content and transmit that media content to user device 106. As an alternative, the user device 104 may provide the user device 106 with a network address where the media content may be retrieved directly from a content source.
User devices 220 may include a desktop computer 221, a smartphone 222, VR/AR head-mounted display 223, a smart TV 224, and a laptop computer 225. The user devices 220 may also include additional devices that the user may interact with. Each of the user devices 220 is communicably connected to the communication network 210, by either a wired connection or a wireless connection, and the user devices 220 may receive notifications via this network connection. Although each of the user devices 220 include a display, user devices without a display may also be included as part of the user devices 220. For example, a smart home speaker may be one of the user devices, and such user devices, while not having a display, may provide notifications to the user via an audio announcement (e.g., speaking a calendar reminder). The user devices 220 may also include devices with displays that are not capable of displaying certain media content. For example, the user devices 220 may include a wearable device, such as a smart watch, with a display that isn't designed to show frame rates that are common to movies and other types of digital video media (e.g., frame rates of 15 fps and higher). Such wearable devices may still receive and display a notification from the notification service, and such wearable devices may display the notification with an indicator that media content is included as part of the notification. In some embodiments, such a wearable device may display the notification with prompt that enables the user to display the notification, including the media content, on another of the user devices 220 that is capable of displaying the media content.
In some embodiments, the notification system 202, or a sub-service thereof, may be executed at one or more of the control circuitry 231 of the notification server 230 and/or control circuitry of the user devices 220 and/or the control circuitry of other servers connected to the communication network 210. As referred to herein, control circuitry should be understood to mean circuitry based on one or more microprocessors, microcontrollers, digital signal processors, programmable logic devices, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc., and may include a multi-core processor (e.g., dual-core, quad-core, hexa-core, or any suitable number of cores) or supercomputer. Any device, equipment, etc. described herein may include control circuitry. The notification server 230 may be coupled to a database 235. In some embodiments, one or more data structures discussed herein may be stored at the database 235. The data structures may be maintained at or otherwise associated with the notification server 230, and/or at the storage 235, and/or at storage of one or more of the user devices 220, and/or at any other storage communicably coupled to the database 235 via the communication network 210. The communication network 210 may comprise one or more networks including the Internet, a mobile phone network, a mobile voice or data network (e.g., a 5G, 4G, or LTE network), cable network, public switched telephone network, or other types of communication network or combinations of communication networks. Although communication paths may not be shown between the user devices 220, the individual user devices 221-225 may communicate directly with each other via one or more communication paths as well as other short-range, point-to-point communication paths, such as USB cables, IEEE 1394 cables, wireless paths (e.g., Bluetooth, infrared, IEEE 802-11x, etc.), or other short-range communication via wired or wireless paths. The user devices 220 may also communicate with each other through an indirect path the via communication network 210.
In some embodiments, a notification service may include a client/server application where only the client application resides on one or more user devices 220, and a server application resides on an external server. For example, a notification service may be implemented partially as a client application on control circuitry of one or more of the user devices 220 and partially on the notification server 230 as a server application running on control circuitry 231. The notification server 230 may be part of a local area network or may be part of a cloud computing environment accessed via the Internet. In a cloud computing environment, various types of computing services for performing searches on the Internet or informational databases, generating virtualized components, providing encoding/decoding capabilities, providing storage (e.g., for a database), or processing and parsing data (e.g., using algorithms, which may include machine learning algorithms) are provided by a collection of network-accessible computing and storage resources (e.g., the notification server 230), referred to as “the cloud.” For example, the user devices 220 may include a cloud client that relies on the cloud computing capabilities from the notification system 202 to receive and process data for notification routing. When executed by the control circuitry 231 of the notification server 230 and/or another cloud accessible resource, a notification service, or parts thereof, may instruct the control circuitry 231 and/or accessible resources to perform processing tasks for notification routing to the user devices 220 and facilitate execution of the various processes.
In some embodiments, the notification server 230 may include control circuitry 231 and storage 234 (e.g., RAM, ROM, hard disk, removable disk, etc.). The storage 234 may store one or more databases. The notification server 230 may also include input/output (I/O) circuitry 232 that may provide protocol for communicating data, device information, or other data, over a local area network (LAN) or wide area network (WAN), and/or other content and data to and from the control circuitry 231, which may include processing circuitry, and the storage 234. The control circuitry 231 may be used to send and receive commands, requests, and other suitable data using the I/O circuitry 232, which may comprise I/O circuitry. The I/O circuitry 232 may connect the control circuitry 231 to one or more communication paths.
The control circuitry 231 may be based on any suitable control circuitry. As referred to herein, control circuitry should be understood to mean circuitry based on one or more microprocessors, microcontrollers, digital signal processors, programmable logic devices, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc., and may include a multi-core processor (e.g., dual-core, quad-core, hexa-core, or any suitable number of cores) or supercomputer. In some embodiments, the control circuitry 231 may be distributed across multiple separate processors or processing units, for example, multiple of the same type of processing units (e.g., two Intel Core i7 processors) or multiple different processors (e.g., an Intel Core i5 processor and an Intel Core i7 processor). In some embodiments, the control circuitry 231 executes instructions for an emulation system application stored in memory (e.g., the storage 234). Although not shown, memory may be an electronic storage device provided as the storage 234 that is part of the respective control circuitry 231.
In some embodiments, as indicated above, some or all of the notification service processes may be performed by the control circuitry 306. In such embodiments, the user device 300 may effectively route a notification to itself for display on the display screen 304.
The user device 300 may access, transmit, receive, and/or retrieve content and data via the I/O circuitry 310. As an illustrative example, the I/O circuitry 310 may be used by the control circuitry 306 to access content (e.g., broadcast programming, on-demand programming, Internet content, content available over a local area network (LAN) or wide area network (WAN), and/or other content) and data. The control circuitry 306 may be used to send and receive commands, requests, and other data using the I/O circuitry 310. The I/O circuitry 310 may communicably couple the control circuitry 306 to many other devices, servers, content sources, application services, among other types of connected computing devices and services.
The display 304 is depicted as a generalized embodiment of a display device. The display 304 may be, for example, a standard touch sensitive display incorporated into a smartphone, a standard laptop display, or a standard desktop computer display, among other types of displays. Some non-limiting examples of a display include a tensor display, a light field display, a volumetric display, a multi-layer display, an LCD display, amorphous silicon display, low-temperature polysilicon display, electronic ink display, electrophoretic display, active matrix display, electro-wetting display, electro-fluidic display, cathode ray tube display, light-emitting diode display, electroluminescent display, plasma display panel, high-performance addressing display, thin-film transistor display, organic light-emitting diode display, surface-conduction electron-emitter display (SED), laser television, carbon nanotubes, quantum dot display, interferometric modulator display, or any other suitable display equipment.
The control circuitry 306 may be based on any suitable control circuitry. As referred to herein, control circuitry should be understood to mean circuitry based on one or more microprocessors, microcontrollers, digital signal processors, programmable logic devices, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc., and may include a multi-core processor (e.g., dual-core, quad-core, hexa-core, or any suitable number of cores) or supercomputer. The control circuitry 306 may include video processing circuitry (e.g., integrated and/or a discrete graphics processor). In some embodiments, the control circuitry 306 may be distributed across multiple separate processors or processing units, for example, multiple of the same type of processing units (e.g., two Intel Core i7 processors) or multiple different processors (e.g., an Intel Core i5 processor and an Intel Core i7 processor). In some embodiments, the control circuitry 306 executes instructions for a notification service, or parts thereof, stored in memory (e.g., the storage 308). Specifically, the control circuitry 306 may be instructed by a notification service, or parts thereof, to perform any of the functions described herein. In some implementations, processing or actions performed by the control circuitry 306 may be based on instructions received from a notification service or parts thereof.
The control circuitry 306 may include or be communicatively coupled to video generating circuitry and tuning circuitry, such as one or more analog tuners, one or more H.265 decoders or any other suitable digital decoding circuitry, high-definition tuners, or any other suitable tuning or video circuits or combinations of such circuits. Conversion circuitry (e.g., for converting over-the-air, analog, or digital signals to MPEG signals for storage) may also be provided. The control circuitry 306 may also include scaler circuitry for upconverting and down-converting content into a suitable output format for display. The control circuitry 306 may also include or be communicatively coupled to digital-to-analog converter circuitry and analog-to-digital converter circuitry for converting between digital and analog signals. The tuning and generating circuitry may be used by the user device 300 to receive and to display, to play, and/or to record content. The tuning and generating circuitry may also be used to receive video generating data. The circuitry described herein, including, for example, the tuning, video generating, encoding, decoding, encrypting, decrypting, scaler, and analog/digital circuitry, may be implemented using software running on one or more general purpose or specialized processors. Multiple tuners may be provided to handle simultaneous tuning functions (e.g., watch and record functions, picture-in-picture (PIP) functions, multiple-tuner recording, etc.). If the storage 308 is provided or supplemented by a separate device from the user device 300, the tuning and generating circuitry (including multiple tuners) may be associated with the storage 308.
The storage 308 may be any circuitry or device for storing electronic data, such as random-access memory, solid state devices, quantum storage devices, hard disk drives, non-volatile memory or any other suitable fixed or removable storage devices, and/or any combination of the same. The storage 308 may be an electronic storage device that is part of the respective control circuitry 306. As referred to herein, the phrase “electronic storage device” or “storage device” should be understood to mean any circuitry or device for storing electronic data, computer software, or firmware, such as random-access memory, read-only memory, hard drives, optical drives, digital video disc (DVD) recorders, compact disc (CD) recorders, BLU-RAY disc (BD) recorders, BLU-RAY 3D disc recorders, digital video recorders (DVR, sometimes called a personal video recorder, or PVR), solid state devices, quantum storage devices, gaming consoles, gaming media, or any other suitable fixed or removable storage devices, and/or any combination of the same. The storage 308 may store data defining images for display by the user device 300. The storage 308 may be used to store various types of content described herein. Nonvolatile memory may also be used (e.g., to launch a boot-up routine and other instructions). Cloud-based storage may be used to supplement the storage 308 or instead of the storage 308.
The control circuitry 306 may include or be coupled to the I/O circuitry 310, which is suitable for communicating with a server or other network accessible devices, a table or database server, or other networks or servers. The instructions for carrying out the above-mentioned functionality may be stored on a server. Such communications may involve the Internet or any other suitable communication networks. In addition, the I/O circuitry 310 may include circuitry that enables peer-to-peer communication of user devices, or communication of user devices in locations remote from each other. In some embodiments, the I/O circuitry 310 may include circuitry that communicatively couples the user device 300 to one or more other devices over a network. For example, the I/O circuitry 310 may include a network adaptor and associated circuitry. The I/O circuitry 310 may include wires and/or busses for connecting to a physical network port (e.g., an ethernet port, a wireless WiFi port, cellular communication port, or any other type of suitable physical port). Although communication paths are not shown between the different user devices 220 of
The power source 312 may include a source of power or an interface for coupling to an external power source, or combinations thereof, without limitation. While not shown, the power source 316 may be coupled to other components of the user device 300. Some non-limiting examples of a power source 312 include a battery, solar generator, and/or a wired power source.
The microphone 316 and the speaker 318 may be included as integrated equipment with other elements of the user device 300. The microphone 316 and speaker 318 of the user device 300 may also be included as integrated equipment with other elements of the user device 300. In some embodiments, the microphone 316 and the speaker 318 may be external to the user device 300 as stand-alone units. An audio component of videos and other audio content may be played through the speaker 318 (or external headphones or other external audio device). The camera 320 may be any suitable still or video camera integrated with the user device 300. In some embodiments, the camera 320 may be external to the user device 300 as a stand-alone unit. In some embodiments, the camera 320 may be a digital camera that includes a charge-coupled device (CCD) and/or a complementary metal-oxide semiconductor (CMOS) image sensor. In some embodiments, the camera 320 may be an analog camera that converts still analogue images to digital images via the control circuitry 306 or via a video card (not shown).
The I/O circuitry 410 may be configured so that the user device 400 has two network addresses. In some embodiments, the first network address may be a device address 430, and this device address 430 may used by the control circuitry 406 for most regular network communications. In such embodiments, the second network address may be a notification address 432, and this notification address 432 may be used exclusively for notifications routed to the user device 400 from the notification service. In some embodiments, the I/O circuitry 410 may include two physical network adapters, each being associated with a unique network address, one for the device address 430 and the other for the notification address 432. In some embodiments, the I/O circuitry 410 may include a multi-homed network adaptor that may be associated with multiple network addresses to enable each of the device address 430 and the notification address 432 to be distinct. In still other embodiments, the I/O circuitry 410 may assign different network ports to the device address 430 and the notification address 432. In such an embodiment, the device address 430 and the notification address 432 may use the same base network address, but the I/O circuitry 410 may be configured to only receive notifications through a designated network port, whereas the device address 430 may use a range of ports that does not include the network port designated for notifications.
Having a separate notification address 432 may help the control circuitry 406 of the user device 400 to place all data received relating to notifications into a digital sandbox, thus enhancing the digital security profile of the user device 400. In addition, by placing all data received for notification purposes into a digital sandbox, the notifications routed to the user device 400 may have access to systems and resources existing on the user device 400, but with a substantially reduced risk of regular operations of the user device 400 being disrupted, whether that disruption is unintentional or otherwise. The concept, design, and implementation of digital sandboxes are known in the art of computing, and therefore implementation of the digital sandbox with the notification address 432 are not discussed in further detail herein. In some embodiments, the separate notification address 432 may be effectuated by the control circuitry 406 and/or by a combination of the control circuitry 406 and the I/O circuitry 410.
Placing notifications within a digital sandbox by the control circuitry 406 of the user device 400 enables some distinct advantages for the communication, processing, and display of notifications. For example, in some embodiments in which the user device 400 receives a routed notification via the I/O circuitry 410, the control circuitry 406 may process the routed notification along with any associated content, whether the content originates from the notification service, the application service, or from some other network-connected source, separately from other processes active on the user device 400. In some embodiments, the display screen 404 may be used to display notifications to the user by overlaying the notification on the screen and the then-current content being displayed to the user. Such an overlay may take up only a portion of the screen, and such partial overlays are referred to herein as a “notification island” (see, for example, 146 in
In some embodiments, the notification island may be dynamically controlled by the control circuitry 406 to adjust the size, opacity, and/or position of the notification island based on the user's real-time interaction with the user device 400. For example, if the user is not currently and actively using the user device 400, the notification island might be in a larger window and opaque. In contrast, if the user is presently and actively using the user device 400, the notification island, when displaying a routed notification, might be smaller and more transparent, and thereby less distracting to the user. Further, when the user interacts with the notification island that is already presented in a more transparent and smaller frame, or if the user disengages with the user device 400, the control circuitry 406 may automatically enlarge the notification island and reduce the transparency of the notification island to bring more attention to the notification. In some embodiments, if the user is consuming media content, when the notification island is presented to display the notification, the control circuitry 406 may be configured to automatically pause the media content so that the user may give attention to the notification and not miss any of the media content. Pausing media content may be particularly advantageous when the user is consuming multi-media content on a user device 400, and most especially if the user device 400 is a smart TV. In some embodiments, the user device 400 may display a notification without pausing playback of media content on the user device 400 or on any other associated user device.
In some embodiments, by assigning the notification address 432 for notification use exclusively, the notification service, application services, and other content services providing data incorporated into the routing and display of notifications may communicate directly with the user device 400 while still enabling the user device 400 to remain secure from inadvertent problems and/or unwanted intrusions arising from notification processing. In some embodiments, the notification address 432 may be used to stream content directly to the user device 400 for display in the notification island. The streamed content may originate from the notification service, the application service, a third-party media content source, another of the user's devices, and/or any other streaming-capable source. In some embodiments, the user device 400 may initiate the content streaming by accessing the media content via the I/O circuitry 410. In some embodiments, the control circuitry 406 may be configured to enable other devices and/or services to connect to the user device 400 via the notification address 432 and use the notification island as an external display for stream casting content.
In some embodiments, having a dedicated notification address 432 available on a user device, along with an accompanying notification island, may be used to enable a guest mode for notifications on user devices such as smart TVs. In some embodiments, a guest mode may also be made available on other types of user devices which may be shared with another user. Smart TVs are particularly well-suited for inclusion of a guest mode, as the owner of the smart TV may want to enable house guests to receive and display notifications, particularly important notifications, the smart TV while the owner and the house guest consume content on the smart TV together, e.g., while watching a movie, playing video games, and the like.
Guest mode may be enabled by the control circuitry of the smart TV sharing the notification address with a house guest's user device, e.g., a smartphone, for purposes of notification routing. The control circuitry of the house guest's user device, when presented with the opportunity to access the smart tv via guest mode, may be configured to associate the notification address of the smart TV with the house guest's notification account maintained by the notification service. In some embodiments, the notification service may enable this guest mode association upon request. In some embodiments, the notification service may enable this guest mode association upon verification of physical proximity between the house guest's user device with the smart TV. In some embodiments, the notification service may remove this guest mode association upon receiving real-time device status data from the house guest's user device that the house guest's user device and the smart TV are no longer in proximity, i.e., the house guest has left the house where the smart TV is located.
When guest mode is enabled on a smart TV, or any other type of user device, and a guest user device associates the smart TV with the guest's notification account, then notifications routed to the guest user device may also be routed to the notification island of the smart TV. Since many users may not want every single notification routed to their personal user device to be displayed to others on a smart TV, in some embodiments the notification service may allow users to configure their notification parameters so select the types of notifications that should be routed to other devices when a device providing guest mode access is associated with the notification account. The notification service thus enables a user a high degree of customization, through notification policy management implemented via the notification parameters, for routing notifications to a user device that is associated with a notification account through guest mode. For example, a user can customize routing of notifications from specific applications (e.g., home security apps and the like) so that such notifications are routed to the smart TV (or the notification island of a smart TV). Additionally, users may also customize routing by specifying routing for a subset of notifications from a specific application. For example, the user may elect to have only notifications related to motion detection from a doorbell camera routed to the notification island, while notifications related to general account management from the application that controls the doorbell camera, such as billing notifications, may not be routed or have delayed routing.
At step 506, the notification service determines routing parameters based on the real-time device status data. As indicated above, the routing parameters play a role in determining how the notification service routes a notification is to be routed to the associated user devices. At step 508, the notification service receives notification data from an application service, and at step 510, the notification service generates a notification based on the notification data. At step 512, the notification service identifies recipient user devices based on the notification parameters and the routing parameters. The recipient user devices are one or more of the user devices associated with the notification account that are to receive the notification. At step 514, the notification service routes the notification to the recipient user devices. As discussed herein, the notification may include instructions to one or more of the recipient user devices to perform specified actions, such as retrieving media content, streaming media content, receiving streamed media content, dismissing the notification upon the occurrence of a specified event, among many other possible actions.
The analytics engine 614 analyzes the user interaction data 612, 620 to generate analytics metrics, and the analytics engine 614 provides the analytics metrics 624 to the routing engine 626. Similarly, the proximity detection module 618 analyzes the location data 616, 622 to determine the respective locations of the primary user device 606 and the secondary user device 610, and the proximity detection module 618 provides the locations to the routing engine 626. Based on the analytics metrics and the locations, the routing engine 626 determines routing parameters for a current notification. The routing engine 626 determines whether one or both devices are to receive the current notification based on the analytics metrics (indicating the user's current level of engagement with each respective user device 606, 610) and the locations (which also indicates the proximity of the user devices 606, 610 to each other) combined with any user preferences or policies established by notification parameters. The last steps of the sequence 600 are the routing engine 626 routing the notification 630 to the primary user device 606 and routing the notification 632 to the secondary user device 610. In circumstances when user engagement is high with the primary user device 606, the notification engine 626 may route the notification only to the primary user device 606. Conversely, in circumstances when user engagement is low or absent from the primary user device 606, and when the secondary user devices 610 has indicia of being actively used, then the notification engine 626 may route the notification only to the secondary user device 610. Alternatively, the notification engine 626 may determine in either circumstance that the notification should be routed to both user devices 606, 610.
The sequence 700 of
The notification routed to the secondary user device 706 may include instructions configured to instruct the secondary user device 706 to receive the media content from the primary user device 704 and to incorporate the media content into the notification when the notification is displayed. Through this sequence 700, the secondary user device 706 may display a notification with media content even if the secondary user device 706 cannot access the media content directly from the media source using the location identifier (e.g., access to the media content requires credentials associated with an application that is not installed on the secondary media device 706). In some embodiments, the media content may be received and stored by the secondary user device 706 prior to displaying the notification. In some embodiments, the primary user device 704 may stream the media content to the secondary user device 706 for immediate display as part of the notification.
The sequence 800 of
The sequence 900 of
The sequence 1000 of
Based on the analytics metrics (and location data that may also be available), the routing engine 1014 may determine that while the user is interacting with the notification 1004, the media content being displayed on the secondary user device 1008 should be paused. The routing engine 1014 may therefore send a pause instruction 1016 to the secondary user device 1008. The pause instruction 1016 may be incorporated into an updated notification if a notification is currently being displayed by the secondary user device 1008. In some embodiments, the routing engine 1014 may be configured to send a null notification to the secondary user device 1008, the null notification including instructions configured to instruct the secondary user device 1008 to perform an action. In such embodiments, the null notification does not incorporate any notification data. In some embodiments that enable null notifications, the null notifications may be limited to those user devices that have implemented a sandboxed notification island.
In embodiments with the content pausing feature shown in
The sequence 1100 of
Through implementation of this sequence 1100, with minimal effort the user may elect receive notifications on the secondary user device 1106 when the notifications are related to the activity displayed on the secondary user device 1106. Moreover, this change in the routing of notifications may be temporary and therefore may automatically revert to the user's established notification parameters without requiring the user to actively revert the parameters.
The sequence 1200 of
The sequence 1300 of
The sequence 1400 of
The sequence 1500 of
The second set of notification parameters 1506 may be for any purpose the user desires. Such a second set of notification parameters may cause all notifications to be routed 1514 to the secondary user device 1516 only, may allow only certain notifications to be routed to a selected device while other notifications are delayed for a predetermined time (e.g., an absolute time, until the end of a calendar event, until a movie is finished playing, until a game application is no longer active, until the user leaves the current location, and the like), may delay all notifications, except highly time-sensitive notifications, until the user switches to a different set of notification parameters, among other options without limitation. The notification service 1504 may provide highly configurable options to the user 1502 for determining when to switch sets of notification parameters, including time options, event options, device activity options, device location options, and device proximity options, among others. By way of example, the user 1502 may establish a focus set of notification parameters that is for use while the user watches media content on the secondary user device 1516, which may be a smart TV. Having a focus set of notification parameters allows the user to quickly switch from the default set to the focus set of notification parameters by accessing the notification service 1504 via the primary user device 1508. The focus set of notification parameters may direct notifications from select application services to the secondary user device while delaying routing of all other notifications. The user 1502 may activate the focus set of notification parameters with an option to switch back to the default set of notification parameters when the secondary user device 1514. As an example for automatic activation of the focus set of notification parameters, the user may configure the focus set of notification parameters to activate when the notification service 1504 determines that the primary user device 1508 is in the same room as the secondary user device 1514, when the primary user device 1508 has not had any user interaction for a predetermined amount of time (e.g., 5 minutes), and the secondary user device 1514 is displaying media content.
The sequence 1600 of
In some embodiments, the second set of notification parameters may also provide the user with control over notifications on the secondary user device 1608 via input at the primary user device 1602 when the two user devices 1602, 1608 are in or near predetermined proximity. The input may be effectuated via gestures, voice commands, or other interactions between the user and the primary user device 1602. The predetermined proximity may be determined from the two user devices 1602, 1608 being within, or in some cases near, the same pre-defined home zone, which in some instances may be the user's home, office, or other location. In some embodiments, when the primary user device 1602 is detected as being near or entering the home zone, the notification service may automatically switch to and activate the second set of notification parameters. In some embodiments, the control over notifications on the secondary user device 1608 may be implemented using null notifications, which may be configured to include instructions to the secondary user device 1608, the instructions configured to instruct the secondary user device 1608 to perform actions, such as dismissing notifications on the secondary user device 1608.
In some embodiments, switching from one set of notification parameters to a second set of notification parameters may occur automatically when the primary user device 1602 leaves the home zone. In such embodiments, the second set of notification parameters may be implemented to minimize or turn off notifications to the secondary user device 1608. Such an embodiment may ensure that notifications do not continue to be displayed on the secondary user device 1608 to potentially display sensitive or personal information when the user is not around to engage with and dismiss the notifications.
The sequence 1700 of
The processes and systems described above are intended to be illustrative and not limiting. One skilled in the art would appreciate that the steps of the processes discussed herein may be omitted, modified, combined, and/or rearranged, and any additional steps may be performed without departing from the scope of the invention. More generally, the above disclosure is meant to be illustrative and not limiting. Only the claims that follow are meant to set bounds as to what the present invention includes. Furthermore, it should be noted that the features and limitations described in any one embodiment may be applied to any other embodiment herein, and flowcharts or examples relating to one embodiment may be combined with any other embodiment in a suitable manner, done in different orders, or done in parallel. In addition, the systems and methods described herein may be performed in real time. It should also be noted that the systems and/or methods described above may be applied to, or used in accordance with, other systems and/or methods.
