阅读说明：本技术 工作空间中基于策略的通知保护服务 (Policy-based notification protection services in a workspace ) 是由 褚晓璐 李岱 于 2020-01-02 设计创作，主要内容包括：本文描述的系统和方法提供通知的管理。服务器可以接收指示客户机装置和客户机装置的用户之间的距离的接近度信息、以及客户机装置的空闲状态信息。服务器可以使用接近度信息和空闲状态信息来确定通知保护级别。服务器可以接收来自至少一个通知源的通知。该通知用于在客户机装置的屏幕上呈现。通知管理器可以根据所确定的通知保护级别来管理接收到的通知的输送。(The systems and methods described herein provide for management of notifications. The server may receive proximity information indicating a distance between the client device and a user of the client device, and idle state information of the client device. The server may use the proximity information and the idle state information to determine a notification protection level. The server may receive notifications from at least one notification source. The notification is for presentation on a screen of the client device. The notification manager may manage delivery of the received notification according to the determined notification protection level.)

1. A computing device, comprising:

a memory;

one or more processors operably coupled to the memory, the processors configured to:

receiving proximity information indicating a distance between a client device and a user of the client device, and idle state information of the client device; and

determining a notification protection level using the proximity information and the idle state information;

receiving a notification from at least one notification source, the notification for presentation on a screen of the client device; and

managing delivery of the received notification to the client device in accordance with the determined notification protection level to ensure privacy of the notification.

2. The computing device of claim 1, wherein the one or more processors are configured to determine the notification protection level using the proximity information, the idle state information, and context information about at least one of the client device or an application.

3. The computing device of claim 2, wherein the contextual information comprises at least one of: a duration of time the client device is in a quiescent state, a duration of time the screen is in a dimmed or low power consumption state, a duration of time the client device is in a locked state, whether the screen is covered by a cover, a duration of time since the client device was last unlocked, a power level of the client device, a reputation of the application, a category of the application, a time or date of the notification, location related information of the client device, whether the client device is in a trusted area, or a Wi-Fi network of the client device.

4. The computing device of claim 1, wherein the one or more processors are configured to receive the proximity information or determine the notification protection level in response to the one or more processors receiving the notification.

5. The computing device of claim 1, wherein the one or more processors are further configured to compare the notification protection level to a threshold and allow, modify, or block the received notification according to the comparison.

6. The computing device of claim 1, wherein the one or more processors are in communication with each of a plurality of notification sources via a respective Application Programming Interface (API) of the computing device.

7. The computing device of claim 1, wherein the idle state information of the client device comprises idle state information of an application executing on the client device.

8. The computing device of claim 1, wherein the one or more processors are configured to modify the received notification by at least one of removing, encoding, or obfuscating at least a portion of content of the notification.

9. The computing device of claim 1, wherein the one or more processors are configured to, if the computing device is unable to modify the received notification according to the determined notification protection level, at least one of: blocking notifications received from the client device, disabling notifications on the client device, or disabling features of the client device for previewing message content.

10. The computing device of claim 1, wherein the one or more processors are configured to:

receiving a notification from the at least one notification source for presentation on a screen of each of a plurality of client devices; and

for each of the plurality of client devices, allowing, modifying or blocking the received notification according to the notification protection level determined for the respective client device.

11. A method for managing delivery of notifications to client devices, the method comprising:

receiving, by a server in communication with a client device, a notification from at least one notification source, the notification for presentation on a screen of the client device;

receiving, by the server, proximity information indicating a distance between the client device and a user of the client device, and idle state information of the client device;

determining, by the server, a notification protection level using the proximity information and the idle state information of the client device; and

managing, by the server, delivery of the received notification to the client device based on the determined notification protection level to ensure privacy of the notification.

12. The method of claim 11, comprising determining the notification protection level using the proximity information, the idle state information, and context information about at least one of the client device or application.

13. The method of claim 11, comprising receiving the proximity information or determining the notification protection level in response to receiving the notification.

14. The method of claim 11, further comprising comparing, by the server, the notification protection level to a threshold and allowing, modifying, or blocking the received notification according to the comparison.

15. The method of claim 11, wherein the at least one notification source comprises a software as a service (SaaS) application, a virtual desktop, or a virtual application.

16. The method of claim 11, comprising modifying the received notification by at least one of removing, encoding, or obfuscating at least a portion of the content of the notification.

17. The method of claim 11, comprising: blocking a notification received from the client device, disabling a notification on the client device, or disabling a feature of the client device for previewing message content if the server is unable to modify the received notification according to the determined notification protection level.

18. The method of claim 11, comprising:

receiving a notification from the at least one notification source for presentation on a screen of each of a plurality of client devices; and

for each of the plurality of client devices, allowing, modifying or blocking the received notification according to the notification protection level determined for the respective client device.

19. A non-transitory computer-readable medium storing program instructions for causing one or more processors to:

receiving, at a server in communication with a client device, a notification from at least one notification source, the notification for presentation on a screen of the client device;

receiving, at the server, proximity information indicating a distance between the client device and a user of the client device, and idle state information of the client device;

determining, at the server, a notification protection level using the proximity information and the idle state information; and

managing delivery of the received notification in accordance with the determined notification protection level to ensure privacy of the notification.

20. The non-transitory computer-readable medium of claim 19, wherein the program instructions further cause the one or more processors to:

receiving a notification from the at least one notification source for presentation on a screen of each of a plurality of client devices; and

for each of the plurality of client devices, allowing, modifying or blocking the received notification according to the notification protection level determined for the respective client device.

Technical Field

The present application relates generally to computing and client devices, including but not limited to using policies to manage notifications for such devices.

Background

Various computing and client devices may receive notifications. Such client devices may receive notifications from notification sources. Notifications may be displayed on such client devices and may include sensitive information.

Disclosure of Invention

The present disclosure relates to systems and methods for managing delivery of notifications. Embodiments described herein protect notifications aggregated from multiple sources, such as native installed applications, virtualized applications, software as a service (SaaS) applications, and so forth. Embodiments described herein may manage notifications by introducing a policy-based service framework (also sometimes referred to herein as a policy engine). The policy engine may be configured to enable, disable, rewrite, or otherwise modify notifications in various context-based scenarios. Such embodiments may protect and ensure that the user device and/or workspace is protected from inadvertent exposure of information to unintended recipients.

Many mobile device (or other client device) vendors are providing features for securing devices and implementing Data Loss Prevention (DLP) policies. Some mobile devices include features such as a facial recognition system or other biometric detection system for unlocking the user's client device (and even, in some implementations, using applications and features within the client device) to prevent unauthorized use of the client device. On the other hand, some application and device vendors utilize notifications to notify end users of information in real time. To this end, some client devices may present (e.g., display or present) notifications even when the client device is in a locked screen mode (e.g., assuming that a user with or near the client device may be alerted or notified via the notification). As a result, security and/or privacy issues are introduced because notifications may be presented when a user is away from their client device and the device may be located in a public or other non-private environment. Notifications may include sensitive information and private data such as chat conversations, incoming email senders and email bodies, meeting requests, appointment locations, and the like. As one example, some enterprise-specific or otherwise private information may be pushed to the client device. In the event that the user is remote from their client device, the information may be inadvertently revealed to others outside and/or unrelated to the enterprise (e.g., untrusted recipients) rather than left inside the organization.

In one aspect, when the user is away from their client device, the application may continue to display notifications received via the cloud notification push service or via application background refreshes (e.g., set within preconfigured settings of the client device). Thus, when a person presents a notification on a device while away from their device, the privacy of such notifications may be compromised by inadvertently revealing information to others. To address privacy concerns, users may disable notification settings on their client devices. However, such actions may negatively impact the utility and goodness of notifications, as well as user-friendliness, as most users are accustomed to receiving notifications.

The present disclosure provides a solution to the presently implemented systems and methods by selectively presenting, modifying, or blocking/disabling notifications presented on a client device, for example, based on a determinable or estimated location of a user of the client device and/or a state of the client device. The systems and methods described herein may provide a policy-based notification protection framework to protect accurate or detailed notification information. The system and method may employ a policy engine to identify information in the notification and various protection techniques. The policy engine may determine a level of protection (sometimes referred to as a risk level) and assign it to various notifications. The policy engine may overwrite, remove, or modify content or information within the notification, thereby eliminating the possibility of inadvertent disclosure of sensitive information within the notification. The policy engine may use various factors to determine whether to display or present the notification, modify the content of the notification, or block the notification altogether. Such factors may include, for example, geographic information (e.g., Global Positioning System (GPS) or similar data), an idle state of the client device, and so forth.

In one aspect, the present disclosure relates to a notification server (sometimes referred to as a server or computing device) in communication with a client device and/or at least one notification source. The notification server may include a policy engine and a notification manager. The notification server may include a memory and one or more processors operably coupled to the memory. One or more processors may implement a policy engine and/or a notification manager. The policy engine (or one or more processors) may receive first information (or proximity information) indicating a distance or proximity between the client device and a user of the client device (e.g., an authorized user), and second information (or idle state information) of the client device (e.g., idle state information of at least one of the client device or an application executing on the client device). The policy engine may use the first information and the second information to determine a notification protection level. The notification manager may receive a first notification from at least one notification source. The first notification may be for presentation on at least a screen of the client device. The notification manager may manage (e.g., allow, modify, or block) delivery of the received first notification according to the determined notification protection level, e.g., to ensure privacy of the notification.

In some embodiments, the policy engine (or one or more processors) may determine the notification protection level using the first information, the second information, and the third information. The third information may include contextual information about at least one of the client device or the application. In some embodiments, the third information comprises at least one of: a duration of time that the client device is in a quiescent state, a duration of time that the screen is in a dimmed or low power consumption state, a duration of time that the client device is in a locked state, whether the screen is covered by an accessory cover, a duration of time since the client device was last unlocked, a power level of the client device, a reputation of an application, a category of the application, a time or date of notification, location related information of the client device, whether the client device is in a trusted area, or a Wi-Fi network of the client device.

In some embodiments, the policy engine may receive first (or proximity) information or determine a notification protection level in response to the notification manager (or computing device, or one or more processors) receiving the first notification. In some embodiments, the policy engine may compare the notification protection level to a threshold, and the notification manager is configured to allow, modify or block the received first notification according to the comparison. In some embodiments, the notification server communicates with each of the plurality of notification sources via a respective Application Programming Interface (API) of the notification server. In some embodiments, the at least one notification source comprises a software as a service (SaaS) application, a virtual desktop, or a virtual application.

In some embodiments, the notification manager may modify the received notification by at least one of removing, encoding, or obfuscating at least a portion of the content of the notification. In some embodiments, if the notification manager is unable to modify the received first notification according to the determined notification protection level, the notification manager may at least one of: blocking a first notification received from the client device, disabling the notification on the client device, or disabling a feature of the client device for previewing message content. In some embodiments, a notification manager may receive a first notification from at least one notification source. The first notification may be for presentation on a screen of each of the plurality of client devices. For each of the plurality of client devices, the notification manager may allow, modify or block the received first notification according to the notification protection level determined for the respective client device.

According to another aspect of the present disclosure, a method for managing delivery of notifications is described. The method may include receiving, by a notification server (sometimes referred to as a server or computing device) in communication with the client device and/or at least one notification source, a notification from the at least one notification source. The first notification may be for presentation on at least a screen of the client device. The method may include receiving, by a notification server, first information (or proximity information) indicating a distance or proximity between a client device and a user of the client device (e.g., an authorized user) and second information (e.g., idle state information) of at least one of the client device or an application executing on the client device. The method may include determining, by the notification server, a notification protection level using the first information and the second information. The method may include allowing, modifying, or blocking the received first notification according to the determined notification protection level.

In some embodiments, the method further comprises determining a notification protection level using the first information, the second information, and the third information. The third information may include contextual information about at least one of the client device or the application. In some embodiments, the method further comprises receiving the first information or determining a notification protection level in response to receiving the first notification. In some embodiments, the method further includes comparing, by the notification server, the notification protection level to a threshold and allowing, modifying, or blocking the received first notification based on the comparison. In some embodiments, the at least one notification source comprises a software as a service (SaaS) application, a virtual desktop, or a virtual application.

In some embodiments, the method further comprises modifying the received first notification by at least one of removing, encoding, or obfuscating at least a portion of the content of the notification. In some embodiments, the method further comprises: the notification server is further configured to block the first notification received from the client device, disable the notification on the client device, or disable a feature of the client device for previewing message content if the notification server is unable to modify the received first notification according to the determined notification protection level. In some embodiments, the method further includes receiving a first notification from at least one notification source, the first notification for presentation on a screen of each of the plurality of client devices. The method may further include, for each of the plurality of client devices, allowing, modifying, or blocking the received first notification according to the notification protection level determined for the respective client device.

According to another aspect of the disclosure, a non-transitory computer-readable medium is described. A non-transitory computer readable medium may store program instructions. The instructions may cause the one or more processors to receive, at a notification server (sometimes referred to as a server or computing device) in communication with the client device and/or at least one notification source, a first notification from the at least one notification source, the first notification for presentation on at least a screen of the client device. The instructions may cause the one or more processors to receive, at the notification server, first information (e.g., proximity information) indicative of a distance or proximity between the client device and an authorized user of the client device and second information (e.g., idle state information) of at least one of the client device or an application executing on the client device. The instructions may cause the one or more processors to determine, at the notification server, a notification protection level using the first information and the second information. The instructions may cause the one or more processors to allow, modify, or block the received first notification according to the determined notification protection level.

In some embodiments, the program instructions further cause the one or more processors to receive a first notification from the at least one notification source for presentation on a screen of each of the plurality of client devices. The program instructions may also cause the one or more processors to allow, modify, or block the received first notification for each of the plurality of client devices according to the notification protection level determined for the respective client device.

Drawings

The foregoing and other objects, aspects, features and advantages of the present solution will become more apparent and better understood by referring to the following description in conjunction with the accompanying drawings, in which:

FIG. 1 is a block diagram of an embodiment of a computing device;

FIG. 2 is a block diagram of an example embodiment of a system for managing delivery of notifications.

FIG. 3 is a flow diagram of a method for managing delivery of notifications.

The features and advantages of the present solution will become more apparent from the detailed description set forth below when taken in conjunction with the drawings, in which like reference characters identify corresponding elements throughout. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements.

Detailed Description

In order to read the description of the various embodiments below, the following description of the various parts of this specification and their respective contents may be helpful:

section a describes a computing environment that may be useful for practicing the embodiments described herein.

Section B describes systems and methods for managing notifications.

A. Computing environment

Before discussing the details of embodiments of the systems and methods detailed in section B herein, it may be helpful to discuss a computing environment in which such embodiments may be deployed.

As shown in fig. 1, computer 101 may include one or more processors 103, volatile memory 122 (e.g., Random Access Memory (RAM)), non-volatile memory 128 (e.g., one or more Hard Disk Drives (HDDs) or other magnetic or optical storage media, one or more Solid State Drives (SSDs) (e.g., flash drives or other solid state storage media), one or more hybrid magnetic and solid state drives, and/or one or more virtual storage volumes (e.g., cloud storage), or a combination of such physical and virtual storage volumes or arrays thereof), User Interface (UI)123, one or more communication interfaces 118, and communication bus 150. The user interface 123 may include a Graphical User Interface (GUI)124 (e.g., a touch screen, a display, etc.) and one or more input/output (I/O) devices 126 (e.g., a mouse, a keyboard, a microphone, one or more speakers, one or more cameras, one or more biometric scanners, one or more environmental sensors, one or more accelerometers, etc.). Non-volatile memory 128 stores operating system 115, one or more applications 116, and data 117 such that computer instructions for operating system 115 and/or applications 116 are executed by, for example, processor 103, out of volatile memory 122. In some embodiments, volatile memory 122 may include one or more types of RAM and/or cache memory, which may provide faster response times than main memory. Data may be input using an input device of GUI 124 or received from I/O device 126. The various elements of computer 101 may communicate via one or more communication buses, shown as communication bus 150.

The computer 101 as shown in fig. 1 is shown as a client, server, intermediary device, and other network device by way of example only and may be implemented by any computing or processing environment and with any type of machine or collection of machines having the appropriate hardware and/or software capable of operating as described herein. The processor 103 may be implemented by one or more programmable processors to execute one or more executable instructions (e.g., computer programs) to perform the functions of the system. As used herein, the term "processor" describes a circuit that performs a function, an operation, or a sequence of operations. The functions, operations, or sequence of operations may be hard coded into the circuitry or soft coded with instructions held in the memory device and executed by the circuitry. A "processor" may perform a function, an operation, or a sequence of operations using digital values and/or using analog signals. In some embodiments, a "processor" may be embodied in one or more Application Specific Integrated Circuits (ASICs), microprocessors, Digital Signal Processors (DSPs), Graphics Processing Units (GPUs), microcontrollers, Field Programmable Gate Arrays (FPGAs), Programmable Logic Arrays (PLAs), multi-core processors, or general purpose computers with associated memory. The "processor" may be an analog, digital, or mixed signal. In some embodiments, a "processor" may be one or more physical processors or one or more "virtual" (e.g., remotely located or "cloud") processors. A processor and/or processors comprising multiple processor cores may provide functionality for executing instructions in parallel, concurrently or on more than one piece of data in parallel, concurrently.

Communication interface 118 may include one or more interfaces to enable computer 101 to access a computer network, such as a Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or the internet, through various wired and/or wireless or cellular connections.

In the described embodiment, the computing device 101 may execute applications on behalf of a user of a client computing device. For example, computing device 101 may execute a virtual machine that provides an execution session within which applications execute on behalf of a user or client computing device, such as a hosted desktop session. Computing device 101 may also execute terminal services sessions to provide a hosted desktop environment. The computing device 101 may provide access to a computing environment that includes one or more of the following: one or more applications, one or more desktop applications, and one or more desktop sessions in which the one or more applications may execute.

Additional details of the implementation and operation of the network environment, the computer 101, and the client and server computers may be as described in U.S. patent No.9,538,345 to Citrix Systems, inc. of laddolburg, florida, 2017, the teachings of which are incorporated herein by reference.

B. System and method for managing delivery of notifications

The present disclosure relates to systems and methods for managing delivery of notifications. Embodiments described herein protect notifications aggregated from multiple sources, such as native installed applications, virtualized applications, software as a service (SaaS) applications, and so forth. Embodiments described herein may manage notifications by introducing a policy-based service framework (also sometimes referred to herein as a policy engine). The policy engine may be configured to enable, disable, rewrite, or otherwise modify notifications in various context-based scenarios. Such embodiments may protect and ensure that the user device and/or workspace is protected from inadvertent exposure of information to unintended recipients.

Many mobile device (or other client device) vendors are providing features for securing devices and implementing Data Loss Prevention (DLP) policies. Some mobile devices include features such as a facial recognition system or other biometric detection system for unlocking the user's client device (and even, in some implementations, using applications and features within the client device) to prevent unauthorized use of the client device. On the other hand, some application and device vendors utilize notifications to notify end users of information in real time. To this end, some client devices may present (e.g., display or present) notifications even when the client device is in a locked screen mode (e.g., assuming that a user with or near the client device may be alerted or notified via the notification). As a result, security and/or privacy issues are introduced because notifications may be presented when a user is away from their client device and the device may be located in a public or other non-private environment. Notifications may include sensitive information and private data such as chat conversations, incoming email senders and email bodies, meeting requests, appointment locations, and the like. As one example, some enterprise-specific or otherwise private information may be pushed to the client device. In the event that the user is remote from their client device, the information may be inadvertently revealed to others outside and/or unrelated to the enterprise (e.g., untrusted recipients) rather than left inside the organization.

In one aspect, when the user is away from their client device, the application may continue to display notifications received via the cloud notification push service or via application background refreshes (e.g., set within preconfigured settings of the client device). Thus, when a person presents a notification on a device while away from their device, the privacy of such notifications may be compromised by inadvertently revealing information to others. To address privacy concerns, users may disable notification settings on their client devices. However, such actions may negatively impact the utility and goodness of notifications, as well as user-friendliness, as most users are accustomed to receiving notifications (e.g., incoming text or email messages, or application updates on their mobile devices).

The present disclosure provides a solution to the presently implemented systems and methods by selectively presenting, modifying, or blocking/disabling notifications presented on a client device, for example, based on a determinable or estimated location of a user of the client device and/or a state of the client device. The systems and methods described herein may provide a policy-based notification protection framework to protect accurate or detailed notification information, or to limit the amount of such information that is inadvertently exposed. The system and method may employ a policy engine to identify information in the notification and various protection techniques. The policy engine may determine a level of protection (sometimes referred to as a risk level) and assign it to various notifications, which may indicate whether security or privacy issues may arise when allowing the presentation of some or all of the notifications, e.g., based on contextual information indicating whether an authorized user is proximate to the receiving client device, the status of the client device, the content of the notification, etc. The policy engine may overwrite, remove, or modify content or information within the notification (e.g., according to an assigned level of protection), thereby eliminating the possibility of inadvertent disclosure of sensitive information within the notification. The policy engine may use various factors to determine whether to display or present the notification, modify the content of the notification, or block the notification altogether. Such factors may include, for example, geographic information (e.g., Global Positioning System (GPS) or similar data), an idle state or other condition of the client device (e.g., including time information indicating long periods of inactivity or separation from authorized users), transmitting notifications using a reputable Wi-Fi network, and so forth. Thus, privacy and security are enhanced and improved over existing systems that do not manage notifications, and are less likely to employ policy-based context considerations to manage notifications (e.g., clients that receive direct notification pushes from a notification source).

Reference is now made toFIG. 2, depicts a block diagram of a system 200 for managing notifications, according to an illustrative embodiment. System 200 is shown to include a plurality of client devices 202, a notification server 204, and a plurality of notification sources 206. The notification source 206 (e.g.,outlook or other email services, such asGoogleSuch as a document sharing and storage application, social media server/service) may deliver notifications to notification server 204 (e.g., through at least one API 208). Policy engine 210 of notification server 204 may be configured to receive information indicative of a physical or geographic proximity between client device 202 and an authorized user (e.g., an owner or an assigned user) of client device 202. Policy engine 210 may be configured to receive additional information related to the context associated with the client device (and/or its applications), its network, and/or an authorized user, such as idle state information corresponding to client device 202 (or an application executing on client device 202). The idle state information (sometimes referred to as user activity information or active usage information) may be or include information or data corresponding to whether a user is using (e.g., actively or otherwise) and/or has used (or not used) the client device 202 (or an application of the client device 202), e.g., associated with any time period, window, frequency, and/or activity pattern. The policy engine 210 may be configured to determine a notification protection level based on information received and/or evaluated by the policy engine 210. The notification protection level may indicate a risk (e.g., privacy and/or security risk) associated with presenting the notification on the client device, and/or an amount of effort or processing that may or should be applied to address the risk. The notification protection level may be, for example, a numerical representation of the proximity of an authorized user to client device 202, corresponding to client device 202 (or on client device 202)An executing application), and/or context information corresponding to the client device 202, its network, its user, and/or its applications.

The notification manager 212 of the notification server 204 can be configured to receive notifications from one of the notification sources 206 for presentation on (at least) a screen or other interface (e.g., a speaker or other output/communication/feedback system) of the client device 202. The notification manager 212 may be configured to allow, modify, or block received notifications according to the determined notification protection level.

The system and method of the present solution may be implemented in any type and form of apparatus, including clients, servers, and/or devices as described above with reference to fig. 1. As referred to herein, "server" may sometimes refer to any device in a client-server relationship, such as notification server 204 that handshakes with client device 202 and/or notification source 206. Client device 202, notification server 204, and/or notification source 206 may include or incorporate components and devices similar in some respects to those described above with reference to fig. 1, such as a memory and/or one or more processors operatively coupled to the memory. The present systems and methods may be implemented in any embodiment or aspect of a device or apparatus described herein.

The system 200 is shown to include a plurality of client devices 202, including a first client device 202a, a second client device 202b, a third client device 202c, and so on (sometimes referred to as client devices 202). Although three client devices 202a-202c are shown, the system 200 may include any number of client devices 202. Accordingly, the present disclosure is not limited to the particular arrangement depicted in fig. 2. Client device 202 may be or include similar aspects, features, and components as computing device 101 described above. The client device 202 may be or comprise, for example, a desktop computer, a laptop computer, a smart phone or a mobile device, a tablet, to name a few possibilities. Client device 202 may host, execute, transport, or otherwise provide applications or resources to a user. For example, the client device 202 may include a display or screen that presents a user interface that includes various icons for selecting applications. The user may select an icon and launch a corresponding application (which may be configured to execute on a cloud-based server that delivers or streams content to the client device 202, or which may be configured to execute natively on the client device 202). In some embodiments, client device 202 may be configured to present (e.g., display, stream, play, in a visible and/or audible form, or otherwise) notifications from various applications and sources (such as notification source 206) on a screen/interface of client device 202. In some embodiments, one of the client devices 202 may be different from the other client devices 202. For example, the first client device 202a may be or include a desktop computer, while the second client device 202b may be or include a mobile device. Both the first client device 202a and the second client device 202b may be associated with or correspond to authorized users. Client devices 202a-202c may be collectively referred to hereinafter as "client devices 202". It should be understood that at least one of the client devices 202 may be configured according to the following description. In some implementations, each of the client devices 202 can be configured according to the following description.

Client device 202 may be configured to monitor, evaluate, provide, and/or determine various status or condition information (e.g., idle state information) corresponding to client device 202. One or more monitoring systems, such as or including an agent (e.g., resident on client device 202 and/or executing on client device 202) and/or an endpoint detection system (e.g., resident on a server and/or client device 202), may detect, identify, monitor, track, determine, and/or provide any such information. In some embodiments, idle state information (sometimes referred to as user activity information or active usage information) may be or include information or data corresponding to whether a user is using (e.g., actively or otherwise) and/or has used (or not used) client device 202 (or an application of client device 202), such as associated with any time period, window, frequency, and/or activity pattern. Client device 202 may be configured to identify, determine, generate, etc., idle state information based on, for example, an elapsed duration between inputs received from a user, a duration that client device 202 is turned off or in a "sleep mode" or has not received user input or has not detected movement, etc. Client device 202 may be configured to generate idle state information based on data corresponding to user input to client device 202 or user usage or interaction with client device 202 (or an application thereof). In some embodiments, the client device 202 may be configured to perform various functions in response to the generation of idle state information. The idle state information may indicate that the client device 202 is in an idle state (e.g., not in use for an extended duration), or that the client device 202 has been turned off (e.g., automatically) or the screen of the client device 202 is dimmed. Although the client device 202 is described above as being in an idle state (e.g., low power consumption, power saving, or sleep mode), in some embodiments, a client device 202 in such a state may be configured to detect an idle state of an application executing on the client device 202.

In some embodiments, the client device 202 may be configured to monitor contextual information of the client device 202. As used herein, "context information" may refer to data corresponding to conditions, states, operating modes, and/or conditions of client device 202 and/or applications accessed via client device 202. As some non-limiting examples, client device 202 may be configured to monitor the duration that client device 202 is in a stationary/stationary state (e.g., based on GPS data remaining unchanged, the gyroscope sensor display is limited to no movement), the duration that the screen is in a darkened or low power consumption state, the duration that client device 202 is in a locked state (e.g., the length of time that the device screen is darkened or in a low power consumption state or locked is calculated using a clock/timer), whether the screen is covered by an accessory cover (e.g., using one or more camera sensors or ranging sensors located in or near client device 202), the duration since client device 202 was last unlocked (e.g., using a clock/timer), the battery level of client device 202 (e.g., remaining battery, percentage of full/empty, or estimated remaining operating duration), A reputation of the application (e.g., according to a rating from the application store, from an internet comment, etc.), a category of the application (e.g., based on data from the application store, its developer, its features, or an internet comment, etc.), a time or date of the notification (e.g., based on data from a user calendar, etc., whether a notification was received while using the application or the client device 202, during work, or at other times), location-related information of the client device 202 (e.g., from GPS data or Wi-Fi location), whether the client device 202 is in a trusted area (e.g., based on a location of the client device 202, a network connection of the client device 202, a geo-fence, etc.), or a Wi-Fi network of the client device 202 (e.g., based on a Wi-Fi name and type, a Wi-Fi reputation, a Wi-Fi signal strength, etc.), or a location-Fi network of the client device 202, Wi-Fi encryption level, Wi-Fi authentication method, Wi-Fi related security settings, etc.). Client device 202 may be configured to generate data corresponding to such monitored conditions, states, operating modes, and conditions, which may be or correspond to contextual information. The context information may include miscellaneous or supporting information that may be, for example, independent of or related to the idle state information. As an example, the context information (e.g., "duration" in a low power consumption mode) may supplement the idle state information (e.g., in a low power consumption mode).

Client device 202 and/or the monitoring system may be configured to convey various information and data to notification server 204. The client device 202 and/or the monitoring system may be configured to communicate idle state information and context information to the notification server 204, for example. Client device 202, monitoring system, and/or notification server 204 may be communicatively coupled to one another such that they may transmit and/or receive information between one another. The client device 202, monitoring system, and/or notification server may be communicatively coupled to each other via a network. In some embodiments, the network may be a Local Area Network (LAN), a Wide Area Network (WAN), a Wireless Local Area Network (WLAN), a Virtual Private Network (VPN), and so forth. Client device 202, monitoring system, and/or notification server 204 may be configured to exchange data with each other across such a network.

Notification server 204 may be configured to receive data and information (e.g., context information, idle state information) from various sources and locations. Notification server 204 may be configured to receive data from monitoring systems, client devices 202, and/or from notification sources 206. The notification server 204 may be configured to intercept, detect, receive, transmit, route, process, and/or manage notifications from the notification sources 206, and the notification server 204 may be configured to receive various information (such as idle state information, context information, etc.) from the monitoring system and/or the client device 202. Notification server 204 may be configured to use such information to detect, identify, calculate, evaluate, or otherwise determine a notification protection level based at least on information from monitoring system and/or client device 202. Notification server 204 may be configured to selectively allow, modify, or block notifications from notification sources 206 based on the determined notification protection level, as described in more detail below.

By way of example, notification server 204 is shown to include policy engine 210, but policy engine 210 may be external to notification server 204, for example, in some embodiments. Policy engine 210 may be any device or component designed or implemented to apply at least one policy to data and information received from various sources. In general, policy engine 210 may be configured to receive information indicating proximity between client device 202 and an authorized user of client device 202. Policy engine 210 may be configured to receive idle state information corresponding to client device 202 and/or an application executing on client device 202. Policy engine 210 may be configured to use such information to determine a notification protection level. Although illustrated as being embodied on notification server 204, in some embodiments, policy engine 210 (and/or notification manager 212) may be communicatively coupled to notification server 204, remotely accessible by notification server 204, or the like. Accordingly, the present disclosure is not limited to the particular arrangement shown in fig. 2.

Policy engine 210 may be configured to identify, retrieve, collect, access, aggregate, or otherwise receive information corresponding to or indicative of proximity between client device 202 and an authorized user of client device 202. The authorized user may be a user who may (e.g., successfully) log into the client device 202, a user who is registered with the client device 202 and/or owns the client device 202, a user who has permission to use the device 202 permanently or temporarily, and so forth. Policy engine 210 may be configured to receive information indicative of proximity between client device 202 and an authorized user by identifying a location of client device 202 and identifying or estimating a location of the authorized user.

The policy engine 210 and/or monitoring system may be configured to identify or determine the location of the client device 202. The policy engine 210 and/or monitoring system may be configured to identify the location of the client device 202 by receiving GPS or other location data (e.g., network connection data, such as an IP address, Wi-Fi network information, and/or port connection information) corresponding to the client device 202. In some embodiments, client device 202 and/or monitoring system may deliver GPS/location data to policy engine 210 at various time intervals, dynamically or as the location of client device 202 changes, continuously (or near continuously), and so forth. Policy engine 210 may be configured to determine a location of client 202 based on location data received from client device 202. In some embodiments, policy engine 210 may be configured to determine the location of client device 202 based on the location of the access point via which client device 202 accesses the network. In the case where the client device 202 accesses a network, the client device 202 may use or form a connection with an access point, which may be used to identify the location of the client device 202 (e.g., based on the network device to which the client device 202 is connected via handshake data during initial access negotiation, physical port connection, Wi-Fi hotspot connection, etc.).

Policy engine 210 may be configured to identify, determine, retrieve, or otherwise receive information or data corresponding to the location of an authorized user. The policy engine 210 and/or monitoring system may be configured to estimate the location of authorized users in a variety of ways. As one non-limiting example, policy engine 210 may be configured to receive information or data corresponding to a Local Area Network (LAN), Enterprise Private Network (EPN), or other enterprise network that a user may access (e.g., using another client device). Policy engine 210 may be configured to identify a source network Internet Protocol (IP) address (e.g., associated with a device that is authorized for use by a user). The policy engine 210 and/or monitoring system may be configured to determine whether a user is located within an enterprise based on whether the IP address of a device used by the user is accessing the enterprise network. As another example, the policy engine 210 may be configured to determine which of several possible client devices 202a user is accessing by receiving data corresponding to an indication of the client device 202 that the user is currently or recently accessing. For example, where a user logs into a first client device 202a and subsequently logs into a second client device 202b or endpoint device (different from the first client device 202a), the policy engine 210 may be configured to determine that the user is no longer in the vicinity of the first client device 202a (e.g., via the most recently logged-in IP address from the second client device 202b, which is different from the earlier logged-in IP address from the first client device 202 a). As yet another example, where a user accesses (e.g., on a client device 202) a mobile application associated with and/or managed by an enterprise, the policy server 210 and/or monitoring system may be configured to generate a prompt (e.g., a request directed or transmitted to a known IP address of the client device 202 to request a response providing a GPS location of the client device 202) that causes the client device 202 that the user is accessing to transmit a current location of the client device 202. As yet another example, where a user accesses a virtualized application or desktop, the user may request, register, authenticate, and/or login at a network/IP address (such as an ab address of a personal computer, tablet, thin client, etc.) that indicates the user's location. The user's location may be identified when the user reports, signs in, logs in, registers, authenticates, conducts transactions/payments, etc., at a device (e.g., a security gateway or portal, transaction terminal, networked node). Thus, the policy engine 210 may obtain location information for the user even in the case where the user accesses a virtualized application or desktop, for example, using a device other than the first client device 202 a. While these examples are provided, it should be understood that the present disclosure is not limited to these particular examples. A person's location may be identified or inferred by a number of different methods, means, approaches, etc. Accordingly, the examples provided above are merely illustrative in nature.

Policy engine 210 may be configured to determine the proximity of client device 202 and an authorized user of client device 202. The policy engine 210 may be configured to compare the determined location of the first client device 202a (e.g., based on location data from the client device 202a, data corresponding to an access point of the client device 202a) with the location of the authorized user estimated, identified, inferred, etc. (e.g., based on the determined location of the second client device 202b, which may be a mobile device of the authorized user). The policy engine 210 may be configured to determine whether the authorized user is in possession, in proximity to, near, in the same room as the client device 202a (used to receive the notification), and the like, based on the comparison and the relative location. For example, policy engine 210 may compare the location or relative location to a site map and/or a predetermined separation/distance threshold (e.g., indicating that the user owns or is in the same room, etc.). Such a threshold may be set at a particular distance (e.g., 1 meter, 5 meters, etc.). The location of the user (based on the location of the second client device 202 b) and the location of the client device 202a may be mapped or translated to a location within the site map and compared to the boundaries of the room or partition described in the site map.

Policy engine 210 may be configured to receive data and/or information corresponding to an idle state of client device 202a and/or an application executing on client device 202 a. The idle state may indicate an activity level and/or idle of the client device 202a (or an application thereof) and may be a value (e.g., a numerical value, such as ranging from 1 to 10) or a state, condition, or mode (e.g., a low or power saving mode, an active or awake mode). As described above, client device 202a and/or monitoring system (e.g., assigned to or otherwise associated with an authorized user) may determine, communicate, transport, provide, or otherwise communicate idle state information to notification server 204 (e.g., via a network connecting client device 202a, monitoring system, and/or notification server 204). Notification server 204 may be configured to receive idle state information from client device 202 and/or a monitoring system. In some examples, the idle state information may indicate that the client device 202a (or an application executing on the client device 202a) is idle (e.g., not actively used by a user, or in a locked state, a low/reduced power consumption state, or in a sleep mode). In some examples, the idle state information received from the client device 202a may indicate that the client device 202a (or an application executing on the client device 202a) is being actively or recently used, controlled, operated, etc., by a user, or otherwise.

Policy engine 210 may be configured to receive contextual information corresponding to client device 202 a. Similar to the idle state information, the client device 202a and/or the monitoring system may be configured to transmit the context information to the notification server 204 via a network connecting the client device 202a, the monitoring system, and/or the notification server 204. Notification server 204 may receive the context information in any form or manner (e.g., periodically, continuously or dynamically in response to sending a request for information) as new/updated information is available.

The policy engine 210 may be configured to evaluate, calculate, identify, generate, or otherwise determine a notification protection level. The notification protection level may correspond to or be generated by the client device 202a transmitting the idle state information. Where a particular user is an authorized user of multiple client devices (e.g., client device 202a, client device 202b, client device 202c, etc.), policy engine 210 may be configured to determine a notification protection level for each client device 202.

Policy engine 210 may be configured to determine a notification protection level by performing an operation or application function on, for example, 1) proximity information (e.g., a numerical value of the relative distance) corresponding to the relative distance of the authorized user and client device 202a and 2) idle state information and/or context information (e.g., in a numerical representation or otherwise). The policy engine 210 may compute a numerical representation of idle state information and/or context information by assigning an integer (or other number or value) to a particular response or information from the idle state information or context information. In some embodiments, policy engine 210 may be configured to weight (e.g., apply a weight to) some information differently than other information. For example, some contextual information may be weighted differently than other contextual information according to the relative importance or relevance of the various information. As another example, idle state information may be weighted differently than one or more types of context information. Policy engine 210 may be configured to perform operations (such as addition, multiplication, division, etc.) or mathematical functions on the relative distance and value representations of the idle state information and/or context information. Note that policy engine 210 may apply any combination and subcombination of operations, weightings, numerical representation calculations, and the like to proximity information, idle state information, and/or one or more types of context information to determine a notification protection level based on the proximity information, idle state information, and/or context information. The policy engine 210 may determine the notification protection level by assigning or determining values to different types of information (which may be weighted differently) and performing operations or functions on these values to calculate the notification protection level. Thus, a notification protection level may be a numerical representation of the proximity of an authorized user to a respective client device 202, idle state information corresponding to the client device 202 (or an application executing on the client device 202), and/or context information corresponding to the client device 202, its network, its user, and/or its applications.

Policy engine 210 may be configured to maintain, include, store, access, or otherwise use thresholds. The threshold may be compared to a notification protection level to determine whether to allow, modify, or block the respective notification to the respective client device 202. In some embodiments, policy engine 210 may include or access any number of thresholds. Each threshold may correspond to a particular action to be performed on an incoming notification destined for a particular client device 202. For example, policy engine 210 may be configured to store or access the first threshold and the second threshold. The first threshold may be a threshold that separates the case where the notification is delivered completely to client device 202 from the case where the notification is modified prior to delivery to client device 202. In some examples, the second threshold may be a threshold that separates a case where the notification is modified prior to delivery to client device 202 from a case where the notification is prevented from being delivered to client device 202. Policy engine 210 may be configured to compare the notification protection level of client device 202 to a first threshold and a second threshold (or a range defined by the thresholds). As described in more detail below, notification manager 212 can be configured to selectively allow, modify, or block notifications (e.g., received or intercepted from notification sources 206) based on such comparisons by policy engine 210.

The notification source 206 can be any device, component, server, program, resource, application, etc., configured to generate notifications for the client device 202. Notification source 206 may include any application or resource that remotely generates data (including notifications) and delivers such data to client device 202. In some embodiments, notification source 206 may be or include a software as a service (SaaS) application, a virtual desktop, a virtual application, and/or the like. Various non-limiting examples of such notification sources 206 may include, for example, applications related to mobile devices available on an application store, a user interface, a display, and a display,outlook or other email service, document sharing and storage applications (such asGoogle) Social media servers/services, etc. Each of such notification sources 206 may be designed or implemented to generate notifications (e.g., updates, alerts, reminders, unicasts, broadcasts) and transmit these notifications to client device 202.

In some embodiments, notification source 206 may be configured to deliver notifications to client device 202 through notification server 204. Thus, notification source 206 may direct, transmit, or route notifications destined for client device 202 to notification server 204, and notification server 204 may selectively route those notifications to client device 202, as described in more detail herein.

Notification source 206 may be configured to transmit notifications to notification server 204 via one or more Application Program Interfaces (APIs) 208. The API208 may be any device or component configured to define the language, protocol, or format of data between elements. API208 may be configured to define the language, protocol, or format of data between notification source 206 and client device 202 (or a particular application operating on the client device). In some embodiments, system 200 may include a plurality of APIs 208 that are structured according to, for example, the type of client device 202, the operating system and/or applications executing on client device 202, and so forth. As two non-limiting examples, system 200 may include an Apple Push Notification Service (APNS) for client device 202 using the iOS operating system, and for usingGoogle Cloud Messaging (GCM) of the client device 202 of the operating system. API208 may define at least the structure of notifications delivered from notification sources 206 to client device 202 (and routed through notification server 204). API208 can push, route, or deliver notifications (and/or other data) to notification server 204 (or intercepted by notification server 204) for delivery to client device 202.

Notification server 204 is shown to include, for example, notification manager 212 in fig. 2. In some embodiments, notification manager 212 may be part of policy engine 210 or combined with policy engine 210. The notification manager 212 may be designed or implemented to receive notifications from the notification sources 206 and may perform one or more actions on the notifications based on, for example, the notification protection level. Notification manager 212 may be configured to allow delivery of notifications to client device 202, modify notifications and deliver modified notifications to client device 202, and/or prevent notifications from being delivered to client device 202.

Notification manager 212 of notification server 204 can be configured to receive notifications from notification sources 206. The notification manager 212 may be configured to receive the notification prior to transmission, routing, and/or delivery of the notification to the intended client device 202. In some embodiments, notification manager 212 may be configured to intercept notifications from notification sources 206. In some embodiments, notification manager 212 may be configured to receive notifications from notification sources 206 via API 208. In such embodiments, notification source 206 may deliver a notification (received by notification manager 212) to the intended client device 202 through notification server 204 via a corresponding API 208.

The notification manager 212 may retrieve, receive, or otherwise identify a notification protection level for a particular client device 202 from the policy engine 210 in response to receiving a notification destined for the particular client device 202. The notification manager 212 can request and/or receive instructions and/or a notification protection level from the policy engine 210 in response to receiving a notification to manage (e.g., allow, modify, or block) the corresponding notification destined for a particular client device 202. In some embodiments, policy engine 210 may be configured to receive proximity information, idle state information, and/or context information in response to notification manager 212 receiving a notification. In some embodiments, the policy engine 210 may be configured to calculate the notification protection level in response to the notification manager 212 receiving the notification.

The notification manager 212 may be designed or implemented to perform one or more actions on notifications received from the notification sources 206 that are destined for a particular client device 202. The notification manager 212 may be configured to perform one or more actions based on the notification protection level from the policy engine 210 or based on instructions determined by the policy engine 210 according to the notification protection level. In some embodiments, notification manager 212 may be configured to perform one or more actions based on a comparison of the notification protection level to various thresholds by policy engine 210. Thus, the notification manager 212 may perform various actions on the received notification according to the notification protection level determined from the policy engine 210.

Notification manager 212 may be configured to perform various actions on the received notification, including but not limited to allowing delivery of the notification to the intended client device 202 (e.g., without any change to the content of the notification), modifying the notification (e.g., modification of the content and/or format) and delivering the notification to the client device 202, and/or blocking the notification (e.g., not delivering to the intended client device 202, or by turning off the notification feature on the client device 202). The notification manager 212 may be configured to perform such actions based on the notification protection level.

In some embodiments, notification manager 212 may be configured to allow delivery of notifications to intended client devices 202. Notification manager 212 may be configured to allow delivery of notifications to intended client devices 202 when a notification protection level is determined based on a scenario in which an authorized user is, for example, in the vicinity of client device 202, client device 202 is in a secure location, client device 202 is not idle (or not idle for a long period of time), etc. Notification manager 212 may be configured to allow delivery of notifications to intended client devices 202 based on a comparison of the notification protection level to a first threshold (as described above). For example, in the event the notification protection level is less than a first threshold, notification manager 212 may be configured to allow delivery of the notification to the intended client device 202. The notification manager 212 can push notifications to the client device 202 for presentation, and the client device 202 can receive and present the notifications.

In some embodiments, notification manager 212 may be configured to modify notifications to be delivered to intended client devices 202. The notification manager 212 may retain or include information or data corresponding to the structure of the various notification data transmitted from the notification sources 206. The notification manager 212 may access such information via the API 208. The notification manager 212 may be configured to determine whether the notification is modifiable based on whether the notification manager includes or has access to a structure or format of the notification data. The notification manager 212 may be configured to modify some notifications (where possible), as described in more detail below. In the event that the notification manager is unable to modify the notification, the notification manager 212 can be configured to, for example, block the notification from being sent to the client, allow the notification but transmit a signal to the client device 202 to disable the notification preview feature on the client device 202 (so that the notification is not rendered/displayed on the client device 202), and so forth.

The notification manager 212 may be configured to determine whether to modify the notification. The notification manager 212 may be configured to determine whether to modify the notification based on the notification protection level. The notification manager 212 may be configured to modify the notification when determining the notification protection level based on the context of an authorized user, for example, in a public location or other area that is near the client device 202 but where sensitive information should not be displayed or presented on the client device. The notification manager 212 may be configured to modify the notification based on a comparison of the notification protection level to the first and second thresholds (as described above). For example, the notification manager 212 may be configured to modify the notification when the notification protection level is, for example, between the first and second thresholds.

The notification manager 212 can be configured to modify the notification by manipulating, modifying, replacing, removing, obfuscating, altering, randomizing, transforming, or otherwise changing at least a portion of the notification data received from the notification sources 206. In some embodiments, the notification manager 212 may be configured to encode at least some of the notification data. The notification manager 212 may be designed or implemented to change the notification data corresponding to the content of the notification. For example, notification manager 212 may be configured to modify the notification data to remove content (e.g., sensitive information such as personal identification data, meeting time and place, confidential information) from the notification (while maintaining certain identifying information such as the identity of the source, the time of the notification, etc.). The notification manager 212 may be configured to modify the notification data to obfuscate the content of the notification. The notification manager 212 may modify the notification data to encrypt, protect, render unreadable, or otherwise encode the content of the notification. The notification manager 212 may modify the format of the notification data, for example, to minimize or otherwise change the font of the text, change the color and/or transparency of the text, to increase the difficulty of reading the content by unintended recipients. In each of these embodiments, the notification manager 212 may be configured to modify or change one or more aspects of the notification (and/or various ranges of modification) based on the notification protection level (e.g., according to a predetermined range of values for the notification protection level). For example, the higher the value of the notification protection level, the greater the scope of the modification applied and/or the number of aspects of the notification that are modified. Such embodiments may protect the content of notifications, thereby reducing the likelihood of interception and promoting DLP motivation.

Notification manager 212 may be configured to block notifications received from notification sources 206. Notification manager 212 may be configured to block notifications received from notification sources 206 from intended client devices 202. In some embodiments, notification manager 212 may intercept the notification and prevent the delivery of the notification to client device 202. The notification manager 212 may be configured to block received notifications when determining a level of notification protection based on a scenario in which the client device 202 has been idle for a long period of time, an authorized user is not near the client device 202, the client device 202 is in an unsecured location, and so forth, for example. The notification manager 212 may block notifications based on a comparison of the notification protection level to a second threshold (as described above). For example, the notification manager 212 may be configured to modify the notification when the notification protection level is, for example, greater than a second threshold.

In some embodiments, the notification manager 212 may be configured to generate a signal for transmission to the client device 202 that is to receive the notification. The signal may be a signal that, when received by the client device 202, causes the client device 202 to modify one or more settings of the client device 202. The settings may be or include, for example, settings corresponding to features for previewing, displaying, or rendering message content in the notification. The notification manager 212 may be configured to generate a signal for transmission to the client device 202 instead of (or in conjunction with) preventing notifications from being sent to the client device 202. For example, the notification manager 212 may be configured to generate a signal when determining a notification protection level based on a scenario in which the client device 202 has been idle for a long period of time, an authorized user is not near the client device 202, the client device 202 is in an unsecured location, and so forth, for example. For example, the notification manager 212 may generate a signal based on a comparison of the notification protection level to a second threshold (as described above). For example, the notification manager 212 may generate a signal when the notification protection level is, for example, greater than a second threshold. In each of these embodiments, the signal may disable the features of the client device 202 for previewing/displaying/rendering the message content of the notification. In such embodiments, the notification may (or may not) still be delivered to the client device 202. However, the content of the notification will not be presented on the screen of the client device 202.

Upon receiving a notification for each client device 202, the policy engine 210 and the notification manager 212 may determine a notification protection level and selectively allow, modify, or block the received notification according to the notification protection level determined for the respective client device 202. In some embodiments, a given notification may be for several client devices 202. In such embodiments, the policy engine 210 may be configured to determine a notification protection level for each client device 202, and the notification manager 212 may be configured to selectively allow, modify, or block received notifications according to the notification protection level determined for each of the respective client devices 202. Thus, notifications may be allowed, modified, or blocked on a client device-by-client device basis according to the determined notification protection level for each of the client devices 202.

It should be noted that the present system may be adapted, modified, configured, etc. to perform various other functions and include other features. For example, the notification server may be implemented in a Cloud environment (such as Citrix Cloud) such that the local devices (e.g., client device 202, API208, notification source 206, etc.) may not change to support certain features discussed herein. Rather, a notification server implemented in a cloud-based environment may manage local devices and/or local applications (as well as any other applications that may be managed by the cloud environment). Thus, the notification server may provide a notification push management service. In such embodiments, the cloud-based server may receive information (e.g., proximity information, idle state information, context information, etc.) from the client device 202 or corresponding to the client device 202. As described above, the cloud-based server may push a full notification, a modified notification, or a block notification to the client device 202 according to the notification protection level.

Such information informs of the protection level that may be used in other environments and contexts. For example, the notification protection level may be used by an Analytics Service, such as Citrix Analytics Service (CAS). The analytics service may receive the notification protection level as a report for different applications and how to compute/execute the notification protection level in various client devices and in various context situations. Such information may be very helpful in understanding how to protect and safeguard notification privacy from a big data perspective. Furthermore, by incorporating the relative locations of the client device and authorized user into the algorithm, the user may be informed how to better protect privacy and data, which may increase user behavior and features over time.

In some embodiments, notification server 204 may be deployed and managed in an environment such as Citrix software defined boundaries (SDP). In such embodiments, policies may be unified and replicated to various devices and applications. Based on the context involving client device 202 and the application, policy engine 210 may apply the policies described herein individually to operate under various scenarios and conditions.

Finally, embodiments described herein (such as notification server 204) may be incorporated into various mobile interface managers (such as Citrix's endpoint management). Moreover, certain functions of notification server 204 (e.g., policy engine 210 and notification manager 212) may be moved into client device 202 or an application of client device 202, built into client device 202 or an application of client device 202, executed in client device 202 or an application of client device 202, or otherwise incorporated into client device 202 or an application of client device 202 to achieve similar or identical results, and are within the contemplation of the present disclosure.

Referring now to FIG. 3, a flow diagram of a method 300 for managing notifications is depicted. The functions of method 300 may be implemented using or performed by the components described in fig. 1-2, such as client device 202, notification server 204, and so forth. Briefly, a notification server (sometimes referred to as a server or computing device) receives a notification (302). The notification server receives first (e.g., proximity) information and second (e.g., idle state) information (304), for example, from at least one client device 202 and/or at least one monitoring system. The notification server determines a notification protection level (306). The notification server determines whether the notification protection level is less than a first threshold (308). In the event that the notification protection level is less than a first threshold, the notification server allows the notification (310). In the event the notification protection level is greater than the first threshold, the notification server determines whether the notification protection level is between the first threshold and a second threshold (312). In the event that the notification protection level is between the first and second thresholds, the notification server modifies and allows the notification (314). In the event that the notification protection level is not between the first and second thresholds, the notification server blocks the notification (316).

At operation (302), and in some embodiments, the notification server receives the notification. In some embodiments, a notification server receives or intercepts notifications (and/or other notifications) from at least one notification source. The notification server may be in communication with the client device and at least one notification source. The notification may be for presentation on at least a screen of the client device. The notification may be a push notification from a notification source. In some embodiments, when a notification is generated by a source (e.g., based on a triggering event), the notification may be pushed from the notification source to the notification server. In some embodiments, the notification may be pushed to the notification server at a predetermined time. In each of the embodiments, the notification server may receive the notification. In some embodiments, the notification may include sensitive information (such as confidential, business, personal identity, private, etc. information). Accordingly, it may be desirable to protect the information contained in the notification from unintended people that may intercept information from the client device or intercept information prior to being received by the client device (e.g., via a Wi-Fi network of the client device for which security is inadequate).

In some embodiments, the at least one notification source comprises a SaaS application, a virtual desktop, or a virtual application (e.g., a hosting or provisioning server for such an application).Various non-limiting examples of such notification sources include, for example, applications related to mobile devices available on an application store, a user interface, and a user interface,Outlook or other email service, document sharing and storage application or service (such as) Etc. of the communication. Each of such notification sources may generate notifications and transmit those notifications (e.g., through a notification server) to the client device. The notification server may intercept or receive notifications from the notification sources.

At operation (304), the notification server receives first (e.g., proximity or other) information and second (e.g., idle state or other) information. In some embodiments, the notification server may receive first information (or proximity information) indicating a distance, physical or spatial separation, or proximity between the client device and a user of the client device (e.g., an authorized user), which may be measured or provided using any unit of distance (e.g., meters, feet, codes). The notification server may receive second information including idle state information of the client device (e.g., idle state information of at least one of 1) the client device or 2) an application executing on the client device). Accordingly, the notification server may receive proximity information and/or idle state information. In some embodiments, the first information and/or the second information may be any other type of information (e.g., context information). The first information and the second information may be different types of information. The notification server may use context information, proximity information, idle state information, and/or other types of information to determine a notification protection level, as schematically described below.

The notification server may identify the proximity between the client device and the authorized user by identifying the location of the client device and identifying or estimating the location of the authorized user. For example, the notification server may determine the location of the client device. The notification server may determine the location of the client device based on GPS or other positioning data of the client device (e.g., Wi-Fi network-based or cellular-based triangulation or positioning) which is then transmitted to the notification server by the client device or monitoring system (e.g., at intervals, on-demand, continuously or near-continuously, etc.). When the client device accesses the network, the notification server may determine the location of the client device based on the access point of the client device.

The notification server may determine or estimate the location of an authorized user corresponding to the client device. The notification server may receive various information corresponding to the location of the authorized user. As one non-limiting example, the notification server may receive information or data corresponding to a LAN, Enterprise Private Network (EPN), or other enterprise network that the user may access using a client device other than the client device assigned to the user. The notification server may identify a source network Internet Protocol (IP) address that the user accesses or uses with other client devices. The notification server may determine whether the user is located based on whether the user is accessing the enterprise network using the IP addresses of other client devices. As another example, the notification server may determine which client device the user is currently accessing. For example, where a user logs into a first client device and subsequently logs into a second or different client device or endpoint device, the notification server may determine (e.g., via a change in IP or network address at which the login occurred) that the user is no longer located near the first client device. As yet another example, where a user accesses (e.g., on a client device) a mobile application associated with and/or managed by an enterprise, the notification server may generate a prompt that causes the client device to transmit a current location of another client device that the user is using. As another example, where a user accesses a virtualized application or desktop, the notification server may access a network address (such as an address of a personal computer, tablet, thin client, etc.) where the user is accessing the virtualized application or desktop. Thus, the notification server may determine the location of the user.

The notification server may determine the proximity of the client device and an authorized user of the client device. The notification server may compare the determined location of the client device (e.g., based on location data from the client device, data corresponding to the access point of the client device) with the estimated, identified, inferred, etc. location of the authorized user (e.g., based on the above-described information). The notification server may determine whether the authorized user is in possession of, near, in the same room as the client device, etc., based on the comparison and the relative location. For example, the notification server may compare the location or relative location to a site map and/or a predetermined separation/distance threshold (e.g., indicating that the user is in possession of or in the same room, etc.). For example, such a threshold may be set at a particular distance (e.g., 1 meter, 5 meters, etc.) for determining that the user owns the client device. The locations of the user and client device 202 may be mapped or translated to locations within the site map and compared to the boundaries of the room or partition depicted in the site map.

Client device 202 may monitor, evaluate, and/or determine various idle state information corresponding to the client device and/or its applications. In some embodiments, the idle state information may be or include information or data corresponding to whether the user is currently using or has used (e.g., recently or within a certain time window) the client device (or an application of the client device). The client device may identify, determine, generate, etc., idle state information based on, for example, a duration of time elapsed between inputs received from a user, a duration of time the client device is off or in a "sleep mode," etc. The client device may generate idle state information based on such data corresponding to user input to the client device or other interactions with the client device. In some embodiments, the client device may perform various functions in response to the generation of idle state information. For example, where the client device generates idle state information indicating that the client device is in an idle state (e.g., an extended duration of non-use), the client device may automatically turn off or dim the screen of the client device. Although described above as the client device being in an idle state, in some embodiments, the client device may detect an idle state of an application accessible to a user via the client device.

In some embodiments, the client device may monitor contextual information about the client device and/or the application. As some non-limiting examples, the client device may monitor the duration that the client device is in a stationary/static state (e.g., the gyroscope sensor display is limited to no movement based on GPS data remaining stationary), the duration that the screen is in a darkened or low power state, the duration that the client device is in a locked state (e.g., the length of time that the device screen is darkened or in a low power state or locked is calculated using a clock/timer), whether the screen is covered by an accessory cover (e.g., based on one or more camera sensors or ranging sensors located in or near the client device), the duration since the client device was last unlocked (e.g., tracked using a clock/timer), the power level of the client device (e.g., percentage of remaining power or duration of remaining use), or a combination thereof, Reputation of the application (e.g., according to ratings from application stores, from internet reviews, etc.), category of the application (e.g., based on data from application stores, features/functions of the application), time or date of notification (e.g., whether while the application or client device is in use, during business hours, based on data from a user's calendar, etc.), location related information of the client device (e.g., from GPS data), whether the client device is located in a trusted area (e.g., based on a location of the client device, a network connection of the client device, a geo-fence, etc.), or a Wi-Fi network of the client device (e.g., based on Wi-Fi name and type, Wi-Fi reputation, Wi-Fi signal strength, Wi-Fi encryption level, Wi-Fi authentication methods, Wi-Fi related security settings, etc.). The client device may generate data corresponding to such monitored conditions and states, which may be or correspond to contextual information.

Client devices may convey various types of information and data to notification server 204. The client device may convey, for example, idle state information and/or context information to the notification server. Accordingly, the notification server may receive first information (e.g., information corresponding to a proximity of the client device to an authorized user of the client device) and second information (e.g., idle state information corresponding to the client device and/or an application of the client device). In some embodiments, the notification server may receive third information (e.g., contextual information about the client device and/or the application).

At operation (306), the notification server determines a notification protection level. In some embodiments, the notification server may use the first information and the second information (e.g., received at operation (304)) to determine the notification protection level. The notification server may determine the notification protection level by assigning, calculating, or otherwise determining a value or representation of the first and second information. The notification server may apply one or more weights to the various information when calculating and/or combining the various information to produce a notification protection level. The notification server may perform a mathematical operation or apply a function to the values assigned to the first and second information. For example, the notification server may multiply a value representing the first information by a value representing the second information to generate a notification protection level.

In some embodiments, the notification server may use the first information, the second information, and/or the third information (e.g., contextual information about at least one of the client device or the application) to determine the notification protection level. In such embodiments, the notification server may assign a numerical value to the third information (including optionally weighting various components or subsets of the information included in the context information). The notification server may calculate the notification protection level by performing a mathematical operation or function on the values assigned to the first, second and/or third information. The notification protection level may be calculated, for example, by multiplying numerical values of the first, second and/or third information, or by adding up these numerical values to which a predefined weight is applied.

In some embodiments, the notification server may receive the first, second, and/or third information and/or determine a notification protection level in response to receiving the notification. In such embodiments, operations (304) and (306) may be performed, for example, in response to operation (302). Thus, the notification protection level may be determined as desired. In some embodiments, the notification server may receive the first information and/or determine the notification protection level on a rolling basis, regardless of when the notification is. In such embodiments, for example, operations (304) and (306) may be performed prior to operation (306) and/or concurrently with operation (306).

At operation (308), the notification server determines whether the notification protection level is less than a first threshold. In some embodiments, to manage the delivery of notifications, the notification server may compare the notification protection level to a threshold (e.g., a first and/or second threshold). The notification server may store or otherwise access the threshold (e.g., a threshold determined or predefined based on a desired privacy or protection level of the notification). The threshold may indicate or correspond to a notification protection level that the notification server allows or modifies the notification. The threshold may separate a case where the notification protection level indicates that the authorized user is, for example, near the client device, the client device is in a secure location, the client device is not idle (or not idle for a long period of time), etc., from a case where the notification protection level indicates that the authorized user is, for example, near the client device but in a common location or other area where sensitive information should not be provided to the user. The threshold may indicate or correspond to a notification protection level at which the notification server modifies or blocks the notification. The threshold may separate a case where the notification protection level indicates that the authorized user is, for example, near the client device but in a public location or other area where sensitive information should not be provided to the user, from a case where the notification protection level indicates that the client device is idle for a long period of time, that the authorized user is not near the client device, that the client device is in an unsecure location, and so forth. In some embodiments, the notification server may include, store, or otherwise access two thresholds (e.g., a first threshold indicating or corresponding to a notification protection level at which the notification server allows or modifies notifications, and a second threshold indicating or corresponding to a notification protection level at which the notification server modifies or blocks notifications).

At operation (310), and in some embodiments, the notification server allows the notification. In some embodiments, the notification server allows the received notification (e.g., to be delivered to and/or presented on the client device) according to the determined notification protection level. In some embodiments, notification manager 212 may be configured to allow delivery of notifications to intended client devices 202. The notification manager 212 may be configured to allow delivery of notifications to intended client devices 202 when the notification protection level indicates that an authorized user is, for example, near the client device 202, the client device 202 is in a secure location, the client device 202 is not idle (or not idle for a long time), and so forth. Notification manager 212 may allow delivery of the notification to the intended client device 202 based on a comparison of the notification protection level to a first threshold (e.g., as described above). For example, in the event the notification protection level is less than a first threshold, notification manager 212 may allow delivery of the notification to the intended client device 202. The notification manager 212 can push notifications to the client device 202 for presentation, and the client device 202 can receive and present the notifications.

At operation (312), the notification server determines whether the notification protection level is between a first threshold and a second threshold. In some embodiments, operation (312) may be similar in at least some respects to operation (308). The notification server may compare the notification protection level to the first and second thresholds. The notification server may determine whether the notification protection level is between the first and second thresholds.

At operation (314), and in some embodiments, the notification server modifies and allows the notification. In some embodiments, the notification server modifies the received notification according to the determined notification protection level. The notification server may include or retain information/data corresponding to the structure of the notification data received from the notification source via the API. The notification server may identify a portion of the notification (e.g., received at operation (302)) that contains the content of the notification. The notification server may remove, encode, or obfuscate at least part of the content of the notification. Such embodiments may protect the content of notifications, thereby reducing the likelihood of interception and promoting DLP motivation.

The notification server may modify the notification by manipulating, modifying, replacing, removing, altering, or otherwise changing the notification data received from the notification source. In some embodiments, the notification server may encode at least some of the notification data. The notification server may change the notification data corresponding to the content of the notification. For example, the notification server may modify the notification data to remove content (e.g., sensitive, confidential data) from the notification (while retaining certain identifying information, such as the identity of the source, the time of the notification, etc.). The notification server may modify the notification data to obfuscate portions of the content of the notification. The notification server may modify the notification data to encrypt, protect, or otherwise encode the content of the notification. In each of these embodiments, the notification server may modify or change one or more aspects of the notification based on the notification protection level.

In some embodiments, if the notification server is unable to modify the received notification according to the determined notification protection level, the notification server may block sending notifications to the client device, disable notifications on the client device, or disable features of the client device for previewing/displaying/rendering message content. The notification server may determine whether the notification data from the notification server is modifiable. The notification server may determine whether the notification data is modifiable based on whether the notification server includes information corresponding to the structure of the notification data, whether the notification server is able to identify data corresponding to the content of the notification, and so on.

In the event that the notification server is unable to modify the notification data, in some embodiments, the notification server may generate a signal for transmission to the client device 202 that is to receive the notification. The signal may be a signal that, when received by the client device, causes the client device to modify one or more settings of the client device. The settings may be or include, for example, settings corresponding to features for previewing/displaying/rendering message content in the notification, settings to disable the notification, and the like. The notification server may generate a signal for transmission to the client device instead of (or in combination with) blocking the notification. For example, the notification server may generate a signal when the notification protection level indicates that the client device has been idle for a long period of time, that an authorized user is not near the client device, that the client device is in an unsecured location, or the like. The notification server may generate a signal based on a comparison of the notification protection level to a second threshold (as described above). For example, the notification server may generate a signal when the notification protection level is, for example, greater than a second threshold. In each of these embodiments, the signal may disable features of the message content for previewing/displaying/rendering notifications, disable notifications on the client device, and so forth. In such embodiments, the notification may (or may not) be delivered to the client device. However, the content of the notification is not presented on the screen of the client device.

At operation (316), and in some embodiments, the notification server manages delivery of notifications to the client device by blocking notifications to the client device. In some embodiments, the notification server blocks received notifications according to the determined level of protection. The notification server may block notifications received from the notification source. The notification server may block notifications received from the notification source from being sent to the intended client device. In some embodiments, the notification server may intercept the notification and prevent the notification from being delivered to the client device. The notification server may block received notifications when the notification protection level indicates that the client device has been idle for a long period of time, that an authorized user is not near the client device, that the client device is in an unsecured location, or the like, for example. The notification server may block the notification based on a comparison of the notification protection level to a second threshold (e.g., as described above). For example, the notification server may modify the notification when the notification protection level is, for example, greater than a second threshold.

In some embodiments, the notification may be for presentation on a screen or other interface of each of the plurality of client devices. The notification server may allow, modify or block notifications for each of the plurality of client devices according to the determined notification protection level for the respective client device. In such embodiments, the notification server may determine a notification protection level for each of the client devices and selectively allow, modify, or block received notifications according to the notification protection level determined for each of the respective client devices. Thus, certain notifications may be allowed, modified, or blocked on an instance-by-instance basis, depending on the level of notification protection determined for the respective client device.

It should be understood that the above-described system may provide multiple components in any one or each of those components, and that these components may be provided on separate machines or, in some embodiments, on multiple machines in a distributed system. The above described systems and methods may be implemented as a method, apparatus or article of manufacture using programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof. In addition, the above-described systems and methods may be provided as one or more computer-readable programs embodied on or in one or more articles of manufacture. The term "article of manufacture" as used herein is intended to encompass code or logic, firmware, programmable logic, storage devices (e.g., EEPROM, ROM, PROM, RAM, SRAM, etc.), hardware (e.g., an integrated circuit chip, Field Programmable Gate Array (FPGA), Application Specific Integrated Circuit (ASIC), etc.), electronic devices, a computer readable non-volatile memory unit (e.g., CD-ROM, USB flash, hard drive, etc.) available from, and embedded in, one or more computer readable devices. The article of manufacture may be accessed from a file server that provides access to the computer readable program via a network transmission line, wireless transmission media, signals propagating through space, radio waves, infrared signals, etc. The article of manufacture may be a flash memory card or a magnetic tape. The article of manufacture includes hardware logic and software or programmable code embedded in a computer readable medium for execution by a processor. Generally, the computer readable program may be implemented in any programming language (e.g., LISP, PERL, C + +, C #, PROLOG) or any bytecode language (e.g., JAVA). The software programs may be stored on or in one or more articles of manufacture as object code.

While various embodiments of the methods and systems have been described, these embodiments are illustrative and do not in any way limit the scope of the described methods or systems. Workers skilled in the relevant art may change the form and details of the described methods and systems without departing from their broadest scope. Thus, the scope of the methods and systems described herein should not be limited by any of the illustrative embodiments, but should be defined in accordance with the following claims and their equivalents.