阅读说明：本技术 统一应用程序通知框架 (Unified application notification framework ) 是由 任明明 姚悦 于 2019-04-01 设计创作，主要内容包括：本文描述了用于统一应用程序通知框架的方法和系统。服务器可以接收来自服务提供商的通知。服务提供商可以与在虚拟机上可执行的应用程序相关联。虚拟机可以是包括用户界面的虚拟环境的一部分。服务器可以确定接收到的通知的标识符。标识符可以指示与服务提供商相关联的虚拟机上的应用程序。服务器可以将接收到的通知提供给用户界面以向用户显示。可以在虚拟机上不执行应用程序的情况下显示接收到的通知。(Methods and systems for a unified application notification framework are described herein. The server may receive a notification from the service provider. The service provider may be associated with an application that is executable on the virtual machine. The virtual machine may be part of a virtual environment that includes a user interface. The server may determine an identifier of the received notification. The identifier may indicate an application on a virtual machine associated with the service provider. The server may provide the received notification to a user interface for display to the user. The received notification may be displayed without executing the application on the virtual machine.)

1. A method, comprising:

receiving, by a server, a notification from a service provider, the service provider associated with an application executable on a virtual machine, the virtual machine being part of a virtual environment that includes a user interface;

determining, by the server, an identifier of the received notification, wherein the identifier indicates the application associated with the service provider; and

providing, by the server, the received notification to the user interface for display to a user, the received notification being displayed without executing the application on the virtual machine.

2. The method of claim 1, wherein determining the identifier comprises extracting, by the server, the identifier from the received notification.

3. The method of claim 1, wherein the service provider comprises a backend service that services the application.

4. The method of claim 1, wherein the service provider is at least one of a web server, a mail server, an application server, a messaging server, a location server, a content provider, an online streaming service, a social media service, a financial institution, a telecommunications service, an internet service provider, or a software-as-a-service provider.

5. The method of claim 1, wherein the virtual environment allows a user to access the virtual machine from a client device.

6. The method of claim 1, wherein the virtual environment comprises at least one of a web client, an application, a service, or an operating system.

7. The method of claim 1, wherein the virtual environment displays the notification to a user after receiving the provided notification.

8. The method of claim 7, wherein the notification is displayed as at least one of text, an icon, a pop-up window, a dialog box, a status bar, a prompt message, a tile, a logo, an alarm, or a counter.

9. The method of claim 1, wherein the method further comprises:

determining that the application is not executing on the virtual machine; and

causing, by the server, the application to execute on the virtual machine.

10. The method of claim 9, wherein the user interface displays the received notification when the application indicated by the identifier is not accessed through the user interface.

11. The method of claim 9, wherein causing the application to execute on the virtual machine comprises transmitting, by the server, a command to the virtual machine to launch the application.

12. The method of claim 1, wherein the method further comprises:

determining that the virtual machine is inoperable; and

making, by the server, the virtual machine operable by transmitting a command to the virtual environment to start the virtual machine.

13. The method of claim 1, wherein the method further comprises:

after receiving the notification, causing, by the server, the virtual machine to perform at least one of: downloading a file, terminating the application, or launching a related application associated with the application.

14. The method of claim 1, wherein the method further comprises:

scheduling the received notification to be provided to the virtual environment at a particular time.

15. The method of claim 1, wherein the method further comprises:

receiving, by the server, a second notification from the service provider;

determining that the second notification does not satisfy a filtering criteria; and

discarding the second notification without providing the second notification to the virtual environment.

16. The method of claim 15, wherein the filter criteria comprises at least one of: notification type, communication channel type, application type, time, priority, or repetition.

17. A system, comprising:

a memory; and

a processor coupled to the memory and configured to:

receiving a notification from a service provider, the service provider associated with an application executable on a virtual machine, the virtual machine being part of a virtual environment that includes a user interface;

determining an identifier of the received notification, wherein the identifier indicates the application associated with the service provider; and

providing the received notification to the user interface for display to a user, the received notification being displayed without executing the application on the virtual machine.

18. The system of claim 17, wherein the processor is also configured to:

causing the application to execute on the virtual machine after determining that the application is not executing on the virtual machine.

19. A non-transitory computer-readable storage medium storing instructions that, when executed by a processor, cause the processor to:

receiving a notification from a service provider, the service provider associated with an application executable on a virtual machine, the virtual machine being part of a virtual environment that includes a user interface;

determining an identifier of the received notification, wherein the identifier indicates the application associated with the service provider; and

providing the received notification to the user interface for display to a user, the received notification being displayed without executing the application on the virtual machine.

20. The non-transitory computer readable storage medium of claim 19, wherein the instructions, when executed by the processor, further cause the processor to:

causing the application to execute on the virtual machine after determining that the application is not executing on the virtual machine.

Technical Field

Aspects described herein relate generally to computer networking, remote computer access, virtualization, enterprise mobility management, and hardware and software related thereto. More specifically, aspects described herein relate to a notification framework for virtual applications.

Background

Current virtual desktop and application products typically consist of a front end through which users can interact with virtual applications and a back end that manages virtual resources and instances. The application may receive messages from the backend services and generate notifications for the user.

Disclosure of Invention

The following presents a simplified summary of various aspects described herein. This summary is not an extensive overview, and is not intended to identify key or critical elements or to delineate the scope of the claims. The following summary merely presents some concepts in a simplified form as an introductory prelude to the more detailed description provided below.

The unified application notification framework can receive notifications associated with virtual application instances via a notification Application Programming Interface (API), an operating system level intercept, and a service to service notification channel. Notifications may be classified and filtered.

The notification API notification may be received from the virtual application instance through a local API call of the unified application notification framework. The operating system level notification intercept message may be generated based on a virtual notification sent by a virtual application instance to a virtual operating system instance on which the virtual application instance executes. The service-to-service notification may be generated by a backend service of the service virtual application instance.

The unified application notification framework can send notifications to the client workspace.

These and additional aspects will be appreciated with the benefit of the disclosure discussed in further detail below.

Drawings

A more complete understanding of the various aspects and advantages thereof described herein may be acquired by referring to the following description in consideration of the accompanying drawings, in which like reference numbers indicate like features, and wherein:

FIG. 1 depicts an exemplary computer system architecture that may be used in accordance with one or more exemplary aspects described herein;

FIG. 2 depicts an exemplary remote access system architecture that may be used in accordance with one or more exemplary aspects described herein;

FIG. 3 depicts an example virtualization system architecture that may be used in accordance with one or more example aspects described herein;

FIG. 4 depicts an exemplary cloud-based system architecture that may be used in accordance with one or more exemplary aspects described herein;

FIG. 5 depicts an exemplary unified application notification framework;

FIG. 6 depicts an exemplary user interface for a client device;

FIG. 7 depicts an exemplary method for providing a unified application notification framework; and

FIG. 8 depicts an exemplary method for receiving notifications by a client workspace.

Detailed Description

In the following description of various embodiments, reference is made to the accompanying drawings, which are identified above and form a part hereof, and in which is shown by way of illustration various embodiments in which aspects described herein may be practiced. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope described herein. The various aspects are capable of other embodiments and of being practiced or of being carried out in various ways.

Traditional cloud products lack a reliable notification mechanism between the backend application instance and the front-end user interface. For example, a backend application instance may be in virtualMicrosoft Windows operating in a desktop EnvironmentAn email client application. The front-end user interface may be CitrixThe back-end application instance typically cannot alert the front-end user interface directly, and thus when an application issues a notification, the user may not receive the notification until she spontaneously opens the application. For example, if a user were to receive an email message via an email client running on a host operating system of a local computer, the email client may send a notification message to the host operating system running on the local computer and may immediately alert the user with the notification. However, if the email message reaches the virtual instance of the email client running on the virtual machine, the host operating system running on the local computer may not know that a new email has arrived and the user may not discover the arrival of the new email until she actively launches the virtual desktop user interface to access the virtual machine and/or launches the virtual instance of the email client. Therefore, there is a need for a reliable notification framework in a virtualized environment to improve the user experience.

To overcome limitations in the prior art described above, and to overcome other limitations that will be apparent upon reading and understanding the present specification, aspects described herein relate to a unified application notification framework.

As an overview of the subject matter described in more detail below, aspects described herein relate to a unified notification framework for cloud and/or virtualized applications. The user may receive notifications without having to open a virtualization or cloud application to individually check each notification, thereby improving user experience and customer satisfaction. More specifically, the present disclosure allows a front-end user interface to receive notification messages related to a back-end application instance via a unified application notification framework and over one of a plurality of communication channels. Thus, the user may receive relevant information about the backend application instance more quickly and efficiently because the user is more readily able to obtain such information.

It is to be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. Rather, the phrases and terms used herein are to be given their broadest interpretation and meaning. The use of "including" and "comprising" and variations thereof is meant to encompass the items listed thereafter and equivalents thereof as well as additional items and equivalents thereof. The use of the terms "connected," "coupled," and "engaged" and similar terms is intended to encompass both direct and indirect connections, couplings, and engagements.

As used herein and depicted in the figures, the term "notification" (also referred to as a message or notification message) refers to any type of data or information generated by an application or operating system and containing messages for the same or other applications and operating systems. Although there is no limit to its size, the size of the notification is typically relatively small (e.g., a few bytes to a few kilobytes). The sender and recipient of the notification message may need to agree on the format and delivery method of the message in advance. The recipient of the notification may further process the notification by presenting the relevant information to the user. For example, the notification may be presented to the user visually on a screen (e.g., text, an icon, a pop-up window, a dialog box, a status bar, a reminder (toast), a sticker, a logo, an alarm, a counter, etc.), audibly through a speaker (e.g., an alarm clock, a ringtone, an audio alarm, etc.), or by any other means (e.g., vibration, haptic feedback, etc.). As an example, the email client may send a notification to the operating system on which the email client is executing when a new email is received so that the operating system may alert the user of the new email via a pop-up dialog.

Once the user manually confirms (e.g., reads) the notification or automatically clears after the notification is presented to the user, the received notification may be "cleared" or otherwise removed from the application or system. Alternatively, the notification may be cleared after a certain time (e.g., 1 hour, 1 day, 2 weeks, 3 months, etc.) has elapsed after receipt of the notification. The cleared (or expired) notification may no longer be presented to the user.

Computing architecture

Computer software, hardware, and networks may be used in a variety of different system environments, including stand-alone environments, networked environments, remote access environments (also known as remote desktops), virtualized environments, and/or cloud-based environments, among others. FIG. 1 illustrates one example of a system architecture and data processing device that may be used to implement one or more exemplary aspects described herein in a standalone environment and/or a networked environment. Various network nodes 103, 105, 107, and 109 may be interconnected via a Wide Area Network (WAN)101, such as the internet. Other networks may also or alternatively be used, including private intranets, corporate networks, Local Area Networks (LANs), Metropolitan Area Networks (MANs), wireless networks, personal networks (PANs), and the like. Network 101 is for illustrative purposes and fewer or more computer networks may be substituted. The local area network 133 may have one or more of any known LAN topology and may use one or more of a variety of different protocols, such as ethernet. Devices 103, 105, 107, and 109, as well as other devices (not shown), may be connected to one or more of the networks via twisted pair, coaxial cable, optical fiber, radio waves, or other communication media.

The term "network" as used herein and depicted in the accompanying drawings refers not only to systems in which remote storage devices are coupled together via one or more communication paths, but also to stand-alone devices that may be coupled to such systems having storage capabilities from time to time. Thus, the term "network" includes not only "physical networks" but also "content networks" which are composed of data attributed to a single entity residing on all physical networks.

These components may include a data server 103, a web server 105, and client computers 107, 109. The data server 103 provides overall access, control, and management of the database and control software for performing one or more of the exemplary aspects described herein. The data server 103 may be connected to a web server 105 through which the user interacts with and retrieves the requested data. Alternatively, the data server 103 acts as a web server itself and is directly connected to the internet. The data server 103 may be connected to the network server 105 through a local area network 133, a wide area network 101 (e.g., the internet), via a direct or indirect connection, or via some other network. A user may interact with the data server 103 using a remote computer 107, 109, for example, using a web browser to connect to the data server 103 via one or more externally published websites hosted by the web server 105. Client computers 107, 109 may be used in conjunction with data server 103 to access data stored therein, or may be used for other purposes. For example, a user may access web server 105 from client device 107 using an internet browser as known in the art, or by executing a software application that communicates with web server 105 and/or data server 103 over a computer network (such as the internet).

The server and application may be combined on the same physical machine and maintain separate virtual or logical addresses, or may reside on separate physical machines. Fig. 1 illustrates only one example of a network architecture that may be used, and those skilled in the art will appreciate that the particular network architecture and data processing devices used may vary and be secondary to the functionality they provide, as described further herein. For example, the services provided by the web server 105 and the data server 103 may be combined on a single server.

Each component 103, 105, 107, 109 may be any type of known computer, server, or data processing device. For example, the data server 103 may include a processor 111 that controls the overall operation of the data server 103. The data server 103 may also include Random Access Memory (RAM)113, Read Only Memory (ROM)115, network interface 117, input/output interface 119 (e.g., keyboard, mouse, display, printer, etc.), and memory 121. Input/output (I/O)119 may include various interface units and drivers for reading, writing, displaying, and/or printing data or files. The memory 121 may also store operating system software 123 for controlling the overall operation of the data processing device 103, control logic 125 for instructing the data server 103 to perform the aspects described herein, and other application software 127 that provides auxiliary, support, and/or other functionality that may or may not be used in conjunction with the aspects described herein. The control logic 125 may also be referred to herein as data server software 125. The functionality of the data server software 125 may refer to a combination of operations or decisions made automatically based on rules encoded into the control logic 125, made manually by a user providing input into the system, and/or automated processing based on user input (e.g., queries, data updates, etc.).

Memory 121 may also store data for performing one or more aspects described herein, including a first database 129 and a second database 131. In some embodiments, the first database 129 may include the second database 131 (e.g., as a separate table, report, etc.). That is, depending on the system design, the information may be stored in a single database, or separated into different logical, virtual, or physical databases. Devices 105, 107, and 109 may have similar or different architectures as described with respect to device 103. Those skilled in the art will appreciate that the functionality of the data processing device 103 (or devices 105, 107, or 109) described herein may be distributed across multiple data processing devices, for example, to distribute processing load across multiple computers, to isolate transactions based on geographic location, user access level, quality of service (QoS), and the like.

One or more aspects may be embodied in computer-usable or computer-readable data and/or computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices described herein. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device. The modules may be written in a source code programming language that is then compiled for execution, or may be written in a scripting language such as, but not limited to, hypertext markup language (HTML) or extensible markup language (XML). The computer executable instructions may be stored on a computer readable medium such as a non-volatile storage device. Any suitable computer readable storage medium may be utilized including hard disks, CD-ROMs, optical storage devices, magnetic storage devices, and/or any combination thereof. In addition, various transmission (non-storage) media representing data or events described herein can be transmitted between a source and a destination in the form of electromagnetic waves propagating through signal-conducting media such as wire, fiber optics, and/or wireless transmission media (e.g., air and/or space). Various aspects described herein may be implemented as a method, data processing system, or computer program product. Accordingly, various functions may be embodied in whole or in part in software, firmware, and/or hardware equivalents such as integrated circuits, Field Programmable Gate Arrays (FPGAs), and the like. Particular data structures may be used to more effectively implement one or more aspects described herein, and such data structures are contemplated to be within the scope of computer-executable instructions and computer-usable data described herein.

With further reference to FIG. 2, one or more aspects described herein may be implemented in a remote access environment. FIG. 2 depicts an example system architecture including a computing device 201 in an example computing environment 200 that may be used according to one or more example aspects described herein. The computing device 201 may function as a server 206a in a single-server or multi-server desktop virtualization system (e.g., a remote access or cloud system) and may be configured to provide a virtual machine for a client access device. The computing device 201 may have a processor 203 for controlling the overall operation of the device 201 and its associated components, including RAM 205, ROM 207, input/output (I/O) module 209, and memory 215.

The I/O module 209 may include a mouse, keypad, touch screen, scanner, optical reader, and/or stylus (or other input device) through which a user of the computing device 201 may provide input, and may also include one or more speakers for providing audio output and one or more video display devices for providing textual, audiovisual, and/or graphical output. Software may be stored within memory 215 and/or other storage to provide instructions to processor 203 for configuring computing device 201 as a special-purpose computing device to perform the various functions described herein. For example, memory 215 may store software used by computing device 201, such as an operating system 217, application programs 219, and associated databases 221.

The computing device 201 may operate in a networked environment using connections to one or more remote computers, such as a terminal 240 (also referred to as a client device and/or client machine). The terminal 240 may be a personal computer, mobile device, laptop computer, tablet computer, or server that includes many or all of the elements described above with respect to the computing device 103 or 201. The network connections depicted in FIG. 2 include a Local Area Network (LAN)225 and a Wide Area Network (WAN)229, but may also include other networks. When used in a LAN networking environment, the computing device 201 can be connected to the LAN 225 through a network interface or adapter 223. When used in a WAN networking environment, the computing device 201 may include a modem or other wide area network interface 227 for establishing communications over the WAN 229, such as computer network 230 (e.g., the Internet). It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used. Computing device 201 and/or terminal 240 may also be a mobile terminal (e.g., mobile phone, smartphone, Personal Digital Assistant (PDA), notebook, etc.) that includes various other components, such as a battery, speaker, and antenna (not shown).

Aspects described herein are operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of other computing systems, environments, and/or configurations that may be suitable for use with aspects described herein include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network Personal Computers (PCs), minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

As shown in FIG. 2, one or more client devices 240 may communicate with one or more servers 206a-206n (generally referred to herein as "servers 206"). In one embodiment, computing environment 200 may include a network device installed between server 206 and client machine 240. The network device may manage client/server connections and, in some cases, may load balance client connections among multiple backend servers 206.

In some embodiments, the client machine 240 may be referred to as a single client machine 240 or a single group of client machines 240, while the server 206 may be referred to as a single server 206 or a single group of servers 206. In one embodiment, a single client machine 240 communicates with more than one server 206, while in another embodiment, a single server 206 communicates with more than one client machine 240. In yet another embodiment, a single client machine 240 communicates with a single server 206.

In some embodiments, client machine 240 may be referenced by any of the following non-exhaustive terms: a client machine; a client; a client computer; a client device; a client computing device; a local machine; a remote machine; a client node; a terminal point; or an endpoint node. In some embodiments, the server 206 may be referenced by any one of the following non-exhaustive terms: a server, a local machine; a remote machine; a server farm or a host computing device.

In one embodiment, client machine 240 may be a virtual machine. The virtual machine may be any virtual machine, and in some embodiments, the virtual machine may be any virtual machine managed by a type 1 or type 2 hypervisor, such as a hypervisor developed by Sijie Systems, International Business machines corporation (IBM), Borui (VMware), or any other hypervisor. In some aspects, the virtual machines may be managed by a hypervisor, while in other aspects, the virtual machines may be managed by a hypervisor executing on server 206 or a hypervisor executing on client 240.

Some embodiments include a client device 240 that displays application output generated by an application executing remotely on a server 206 or other remotely located machine. In these embodiments, the client device 240 may execute a virtual machine receiver program or application to display output in an application window, browser, or other output window. In one instance, the application is a desktop, while in other instances, the application is an application that generates or renders a desktop. The desktop may include a graphical shell that provides a user interface for instances of an operating system in which local and/or remote applications may be integrated. An application program, as used herein, is a program that executes after an instance of the operating system (and optionally the desktop as well) has been loaded.

In some embodiments, the server 206 uses a remote presentation protocol or other program to send data to a thin client or remote display application executing on the client to present display output generated by the application executing on the server 206. The thin client or remote display protocol may be any one of the following non-exhaustive list of protocols: independent Computing Architecture (ICA) protocol developed by the system of the singer, ltydarberg, florida (Citrix Systems, Inc.); or the Remote Desktop Protocol (RDP) manufactured by Microsoft Corporation of redmond, washington.

The remote computing environment may include more than one server 206a-206n such that the servers 206a-206n are logically grouped together in a server farm 206, such as in a cloud computing environment. The server farm 206 may include servers 206 that are geographically dispersed but logically grouped together, or servers 206 that are located proximate to each other when logically grouped together. In some embodiments, geographically dispersed servers 206a-206n within a server farm 206 may communicate using a WAN (wide area), MAN (metropolitan area), or LAN (local area), where different geographic regions may be characterized as: a different continent; different regions of the continent; different countries; a different state; different cities; a different campus; different rooms; or any combination of the aforementioned geographic locations. In some embodiments, the server farm 206 may be managed as a single entity, while in other embodiments, the server farm 206 may include multiple server farms.

In some embodiments, the server farm may include servers 206 executing a substantially similar type of operating system platform (e.g., WINDOWS, UNIX, LINUX, iOS, ANDROID, SYMBIAN, etc.). In other embodiments, the server farm 206 may include a first group of one or more servers executing a first type of operating system platform and a second group of one or more servers executing a second type of operating system platform.

The server 206 may be configured as any type of server as desired, such as a file server, an application server, a web server, a proxy server, an appliance, a network appliance, a gateway, an application gateway, a gateway server, a virtualization server, a deployment server, a Secure Socket Layer (SSL) VPN server, a firewall, a web server, an application server, or as a host application server, a server executing an active directory, or a server executing an application acceleration program that provides firewall functionality, application functionality, or load balancing functionality. Other server types may also be used.

Some embodiments include a first server 206a that receives a request from a client machine 240, forwards the request to a second server 206b (not shown), and responds to the request generated by the client machine 240 with a response from the second server 206b (not shown). The first server 206a may obtain an enumeration of applications available to the client machine 240 and address information associated with the application servers 206 hosting applications identified within the enumeration of applications. The first server 206a may then present a response to the client request using the network interface and communicate directly with the client 240 to provide the client 240 access to the identified application. One or more clients 240 and/or one or more servers 206 may transmit data over network 230 (e.g., network 101).

FIG. 3 illustrates a high-level architecture of an exemplary desktop virtualization system. As shown, the desktop virtualization system may be a single server or multi-server system, or a cloud system, including at least one virtualization server 301 configured to provide virtual desktops and/or virtual applications to one or more client access devices 240. As used herein, a desktop refers to a graphical environment or space in which one or more applications may be hosted and/or executed. The desktop may include a graphical shell that provides a user interface for instances of an operating system in which local and/or remote applications may be integrated. The application programs may include programs that are executed after an instance of the operating system (and optionally, the desktop) is loaded. Each instance of an operating system may be physical (e.g., one operating system per device) or virtual (e.g., multiple instances of an OS running on a single device). Each application may execute on a local device or may execute on a remotely located device (e.g., remotely).

The computer device 301 may be configured as a virtualization server in a virtualization environment (e.g., a single server, a multi-server, or a cloud computing environment). The virtualization server 301 shown in FIG. 3 may be deployed as and/or implemented by one or more embodiments of the server 206 shown in FIG. 2 or by other known computing devices. Included in the virtualization server 301 is a hardware layer, which may include one or more physical disks 304, one or more physical devices 306, one or more physical processors 308, and one or more physical memories 316. In some embodiments, firmware 312 may be stored within memory elements in physical memory 316 and may be executed by one or more of physical processors 308. Virtualization server 301 may also include an operating system 314, which may be stored in memory elements in physical memory 316 and executed by one or more of physical processors 308. Further, the hypervisor 302 may be stored in a storage element in the physical memory 316 and may be executed by one or more of the physical processors 308.

Executing on one or more of the physical processors 308 may be one or more virtual machines 332A-C (collectively 332). Each virtual machine 332 may have virtual disks 326A-C and virtual processors 328A-C. In some embodiments, the first virtual machine 332A may execute the control program 320 including the tool stack 324 using the virtual processor 328A. Control program 320 may be referred to as a control virtual machine, Dom0, Domain 0, or other virtual machine for system management and/or control. In some embodiments, one or more virtual machines 332B-C may execute guest operating systems 330A-B (collectively 330) using virtual processors 328B-C.

The virtualization server 301 may include a hardware layer 310 having one or more pieces of hardware in communication with the virtualization server 301. In some embodiments, the hardware layer 310 may include one or more physical disks 304, one or more physical devices 306, one or more physical processors 308, and one or more physical memories 316. The physical components 304, 306, 308, and 316 may include, for example, any of the components described above. The physical devices 306 may include, for example, network interface cards, video cards, keyboards, mice, input devices, monitors, display devices, speakers, optical drives, storage devices, universal serial bus connections, printers, scanners, network elements (e.g., routers, firewalls, network address translators, load balancers, Virtual Private Network (VPN) gateways, Dynamic Host Configuration Protocol (DHCP) routers, etc.), or any device connected to or in communication with the virtualization server 301. The physical memory 316 in the hardware layer 310 may include any type of memory. Physical memory 316 may store data, and in some embodiments may store one or more programs or a set of executable instructions. FIG. 3 illustrates an embodiment in which firmware 312 is stored within physical memory 316 of virtualization server 301. The programs or executable instructions stored in the physical memory 316 may be executed by the one or more processors 308 of the virtualization server 301.

The virtualization server 301 may also include a hypervisor 302. In some embodiments, the hypervisor 302 may be a program executed by the processors 308 on the virtualization server 301 to create and manage any number of virtual machines 332. Hypervisor 302 may be referred to as a virtual machine monitor or platform virtualization software. In some embodiments, hypervisor 302 may be any combination of executable instructions and hardware that monitor virtual machines executing on a computing machine. The hypervisor 302 may be a type 2 hypervisor, where the hypervisor executes within an operating system 314 executing on the virtualization server 301. The virtual machine may then execute at a level higher than hypervisor 302. In some embodiments, the type 2 hypervisor may execute in the context of the user's operating system, such that the type 2 hypervisor interacts with the user's operating system. In other embodiments, one or more virtualization servers 301 in a virtualization environment may instead include a type 1 hypervisor (not shown). The type 1 hypervisor may execute on the virtualization server 301 by directly accessing the hardware and resources within the hardware layer 310. That is, when the type 2 hypervisor 302 accesses system resources through the host operating system 314, as shown, the type 1 hypervisor may directly access all system resources without the host operating system 314. The type 1 hypervisor may execute directly on one or more physical processors 308 of the virtualization server 301 and may include program data stored in physical memory 316.

In some embodiments, hypervisor 302 may provide virtual resources to operating system 330 or control program 320 executing on virtual machine 332 in any manner that emulates operating system 330 or control program 320 with direct access to system resources. The system resources may include, but are not limited to, physical devices 306, physical disks 304, physical processors 308, physical memory 316, and any other components included in the hardware layer 310 of the virtualization server 301. Hypervisor 302 may be used to emulate virtual hardware, partition physical hardware, virtualize physical hardware, and/or execute virtual machines that provide access to a computing environment. In still other embodiments, the hypervisor 302 may control processor scheduling and memory partitioning of the virtual machines 332 executing on the virtualization server 301. Hypervisor 302 can include a hypervisor manufactured by Borui corporation (VMWare, Inc.) of Palo alto, Calif.; XENPROJECT hypervisor, an open source product developed by open source XENPROJECT. HyperV, VirtualServer, or virtual PC hypervisor provided by Microsoft, or other hypervisor. In some embodiments, virtualization server 301 may execute a hypervisor 302 that creates a virtual machine platform on which a guest operating system may execute. In these embodiments, virtualization server 301 may be referred to as a host server. An example of such a virtualization server is the smith hypervisor offered by smith systems, inc.

Hypervisor 302 may create one or more virtual machines 332B-C (collectively 332) in which guest operating system 330 executes. In some embodiments, hypervisor 302 may load a virtual machine image to create virtual machine 332. In other embodiments, hypervisor 302 may execute guest operating system 330 within virtual machine 332. In still other embodiments, virtual machine 332 may execute guest operating system 330.

In addition to creating virtual machines 332, hypervisor 302 can also control the execution of at least one virtual machine 332. In other embodiments, the hypervisor 302 may present at least one virtual machine 332 with an abstraction of at least one hardware resource (e.g., any hardware resource available within the hardware layer 310) provided by the virtualization server 301. In other embodiments, the hypervisor 302 may control the manner in which the virtual machines 332 access the physical processors 308 available in the virtualization server 301. Controlling access to the physical processor 308 may include determining whether the virtual machine 332 should access the processor 308, and how physical processor capabilities are presented to the virtual machine 332.

As shown in fig. 3, virtualization server 301 may host or execute one or more virtual machines 332. The virtual machine 332 is a set of executable instructions that, when executed by the processor 308, may mimic the operation of a physical computer, such that the virtual machine 332 may execute programs and processes like a physical computing device. Although fig. 3 illustrates an embodiment in which the virtualization server 301 hosts three virtual machines 332, in other embodiments, the virtualization server 301 may host any number of virtual machines 332. In some embodiments, the hypervisor 302 may provide each virtual machine 332 with a unique virtual view of the physical hardware, memory, processors, and other system resources available to that virtual machine 332. In some embodiments, the unique virtual view may be based on one or more of the following: virtual machine permissions, application of one or more virtual machine identifiers by the policy engine, a user accessing the virtual machine, an application executing on the virtual machine, a network accessed by the virtual machine, or any other desired criteria. For example, hypervisor 302 may create one or more insecure virtual machines 332 and one or more secure virtual machines 332. The unsecure virtual machine 332 may be prevented from accessing resources, hardware, memory locations, and programs that the secure virtual machine 332 may be allowed to access. In other embodiments, hypervisor 302 may provide each virtual machine 332 with a substantially similar virtual view of the physical hardware, memory, processors, and other system resources available to virtual machine 332.

Each virtual machine 332 may include virtual disks 326A-C (collectively 326) and virtual processors 328A-C (collectively 328). In some embodiments, virtual disk 326 is a virtualized view of one or more physical disks 304 of virtualization server 301 or a portion of one or more physical disks 304 of virtualization server 301. A virtualized view of the physical disks 304 may be generated, provided, and managed by the hypervisor 302. In some embodiments, the hypervisor 302 provides each virtual machine 332 with a unique view of the physical disks 304. Thus, in these embodiments, the particular virtual disk 326 included in each virtual machine 332 may be unique when compared to the other virtual disks 326.

The virtual processor 328 may be a virtualized view of one or more physical processors 308 of the virtualization server 301. In some embodiments, a virtualized view of the physical processors 308 may be generated, provided, and managed by the hypervisor 302. In some embodiments, the virtual processor 328 has substantially all of the same characteristics of the at least one physical processor 308. In other embodiments, the virtual processor 308 provides a modified view of the physical processors 308 such that at least some of the characteristics of the virtual processor 328 are different from the characteristics of the corresponding physical processor 308.

With further reference to fig. 4, some aspects described herein may be implemented in a cloud-based environment. Fig. 4 illustrates an example of a cloud computing environment (or cloud system) 400. As shown in fig. 4, client computers 411-414 may communicate with cloud management server 410 to access computing resources (e.g., host servers 403a-403b (collectively referred to herein as "host servers 403"), storage resources 404a-404b (collectively referred to herein as "storage resources 404"), and network elements 405a-405b (collectively referred to herein as "network resources 405") of the cloud system.

The management server 410 may be implemented on one or more physical servers. The management server 410 may run, for example, Citrix works space or OpenStack, etc., provided by setjg Systems, Inc. The management server 410 may manage various computing resources, including cloud hardware and software resources, such as host computers 403, data storage devices 404, and networking devices 405. The cloud hardware and software resources may include private components and/or public components. For example, the cloud may be configured as a private cloud for use by one or more particular customer or client computers 411 and 414 and/or over a private network. In other embodiments, the public cloud or hybrid public-private cloud may be used by other customers over an open or hybrid network.

The management server 410 may be configured to provide a user interface through which cloud operators and cloud customers may interact with the cloud system 400. For example, the management server 410 may provide a user interface to a set of Application Programming Interfaces (APIs) and/or one or more cloud operator console applications (e.g., web-based or standalone applications) to allow a cloud operator to manage cloud resources, configure virtualization layers, manage customer accounts, and perform other cloud management tasks. The management server 410 may also include a set of APIs and/or one or more client console applications, the user interface of which is configured to receive cloud computing requests from end users, such as requests to create, modify, or destroy virtual machines within the cloud, via client computers 411 and 414. Client computers 411-414 may be connected to management server 410 via the internet or some other communications network and may request access to one or more of the computing resources managed by management server 410. In response to the client request, the management server 410 may include a resource manager configured to select and provide physical resources in a hardware layer of the cloud system based on the client request. For example, the management server 410 and additional components of the cloud system may be configured to provide, create, and manage virtual machines and their operating environments (e.g., hypervisors, storage resources, services provided by network elements, etc.) for customers at client computers 411 and 414 over a network (e.g., the internet), provide computing resources, data storage services, networking capabilities, and computer platform and application support for the customers. The cloud system may also be configured to provide a variety of specific services, including security systems, development environments, user interfaces, and the like.

For example, some clients 411-414 may be associated with different client computers that create virtual machines on behalf of the same end user or different users affiliated with the same company or organization. In other instances, some of clients 411-414 may be unrelated, such as users affiliated with different companies or organizations. For unrelated clients, the virtual machine or stored information of any one user may be hidden from other users.

Referring now to the physical hardware layer of the cloud computing environment, availability zone 401 and 402 (or zones) may refer to a set of collocated physical computing resources. The region may be geographically separated from other regions throughout the cloud of computing resources. For example, region 401 may be a first cloud data center located in california, while region 402 may be a second cloud data center located in florida. The management server 410 may be located in one of the availability areas or in a separate location. Each zone may include an internal network that interfaces with devices outside the zone (such as management server 410) through a gateway. The end user of the cloud (e.g., client 411-414) may or may not be aware of the distinction between the regions. For example, an end user may request to create a virtual machine having a specified amount of memory, processing power, and network capabilities. The management server 410 can respond to a user's request and can allocate resources to create a virtual machine without requiring the user to know whether the virtual machine was created using resources from zone 401 or zone 402. In other instances, the cloud system may allow end users to request allocation of virtual machines (or other cloud resources) in a particular region or on particular resources 403 and 405 within a region.

In this example, each area 401-. The physical hosting resources in cloud area 401 and 402 may include one or more computer servers 403, such as virtualization server 301 described above, which may be configured to create and host virtual machine instances. The physical network resources in cloud zones 401 or 402 may include one or more network elements 405 (e.g., network service providers) that include hardware and/or software configured to provide network services to cloud customers, such as firewalls, network address translators, load balancers, Virtual Private Network (VPN) gateways, Dynamic Host Configuration Protocol (DHCP) routers, and so forth. The storage resources in cloud region 401 and 402 may include storage disks (e.g., Solid State Drives (SSDs), magnetic hard disks, etc.) and other storage devices.

The example cloud computing environment shown in fig. 4 may also include a virtualization layer (e.g., as shown in fig. 1-3) with additional hardware and/or software resources configured to create and manage virtual machines and provide other services to customers using physical resources in the cloud. The virtualization layer may include a hypervisor as described above in fig. 3, as well as other components that provide network virtualization, storage virtualization, and the like. The virtualization layer may be a separate layer from the physical resource layer, or may share some or all of the same hardware and/or software resources with the physical resource layer. For example, the virtualization layer may include a hypervisor installed in each of the virtualization servers 403 having physical computing resources. Known CLOUD systems may alternatively be used, such as WINDOWS AZURE (Microsoft Corporation, redmond, washington), AMAZON EC2 (AMAZON. com Inc.) of seattle, washington, IBM BLUE CLOUD (IBM Corporation, armonk, new york), and the like.

Unified notification framework

FIG. 5 depicts an exemplary unified application notification framework. In some embodiments, unified application notification environment 500 can include unified application notification framework 501 that collects notifications from virtual machine 502 and relays all or portions of the notifications to client device 503. In particular, the notification may be issued by an application 504 executing on virtual machine 502 and forwarded to a workspace of client device 503 so that a user 506 of client device 503 may be notified. Virtual machine 502 can be, for example, one of virtual machines 332 of FIG. 3. The client device 503 may be one of the network nodes 103, 105, 107, 109 of fig. 1 or the terminal 240 of fig. 2. Client device 503 may have a workspace environment (also referred to as a workspace or virtual environment) that allows user 506 to access virtual machine 502, operating system 505, and/or application programs 504. Throughout this disclosure, client device 503 may refer to hardware (e.g., a physical device such as a desktop computer, mobile device, etc.) and/or any software (e.g., a workspace environment) running on hardware. The workspace may be a network interface, a desktop application, a mobile application, etc. While application 504 and/or operating system 505 running on virtual machine 502 can send notifications directly to client device 503 when client device 503 is online and connected to virtual machine 502 (e.g., participating in a remote session), direct delivery of such notifications is not available to application 504 and operating system 505 when client device 503 is offline or otherwise unavailable to communicate with application 504 or operating system 505. In this case, unified application notification framework 501 can receive or intercept notifications associated with application 504 and forward these messages to client device 503 in real time or at a later time.

Unified application notification framework 501 can be a collection of software and/or hardware components that enable client device 503 to receive notifications associated with application 504 even when client device 503 is not actively communicating with application 504 and/or virtual machine 502. For example, all or part of unified application notification framework 501 may run on server 206 or client machine 240 of fig. 2. Although fig. 5 shows the unified application notification framework 501 as receiving notifications from a single virtual instance and forwarding the notifications to a single client device 503 for ease of illustration, the unified application notification framework 501 may receive notifications from multiple virtual machines and forward notifications to multiple corresponding client devices. For clarity of illustration, it is assumed in this disclosure that unified application notification framework 501 is included in hypervisor 302 of FIG. 3. However, in some embodiments, all or part of unified application notification framework 501 may be included in hypervisor 302, operating system 314, control program 320, and/or guest operating system 330 of FIG. 3. In other embodiments, the unified application notification framework 501 may be part of an entity (e.g., a server) that is logically and/or physically separate from the client machines 240, the servers 206, and the virtualization server 301. For example, the unified application notification framework 501 may reside in the management server 410 or other device.

Unified application notification framework 501 can have at least three communication channels (also referred to as notification channels) over which notifications are received from virtual machines 502. These communication channels may include notification API 507, operating system level notification interception 508, and service-to-service notification 509. These may be separate notification channels through which various types of notifications may be retrieved and collected. Regardless of which communication channel or path is used to deliver the notification, the notification can be delivered to the unified application notification framework 501 via a network 512 (e.g., the internet). For example, the application 504 may make a local notification API call (i.e., the notification API 507) and send the notification over the internet, a wireless broadband communication network, a Local Area Network (LAN), a Wide Area Network (WAN), a virtual network, and so forth. In some embodiments, one or more of the communication channels 507, 508, 509 may not need to traverse the network 512 as when, for example, the virtual machine 502 and the unified application notification framework 501 are located within the same physical server.

The unified application notification framework 501 may also include a notification filtering and scheduling module 510 that further processes received notifications before forwarding them to the client device 503. In particular, the notification filtering and scheduling module 510 may sort and filter messages according to policy or preference. The policies or preferences may be predetermined (e.g., by an administrator or user) or dynamically updated. For example, the filtering policy may indicate that any redundant or duplicate messages may be dropped and prevented from being forwarded to the client device 503. For example, the filtering policy may be updated based on message history (e.g., blocking certain types of duplicate messages) or user preferences (e.g., whitelisting all messages originating from an application). The notification filtering and scheduling module 510 may also decide to forward one or more notifications to the client device 503 at a time later than the time the notifications are received at the unified application notification framework 501. In other words, the unified application notification framework 501 may schedule or reschedule the delivery of notifications to the client device 503 according to a policy or setting. For example, when a notification arrives at unified application notification framework 501 at a time when user 506 cannot see the notification, notification filtering and scheduling module 510 may schedule delivery of the message at a future time when user 506 can see the notification. As another example, when the client device 503 is powered off, offline, or otherwise unavailable to receive notifications (e.g., when the unified notification framework 501 fails to receive a notification reception acknowledgement message back from the client device 503), the unified application notification framework 501 may reschedule the delivery for a retry at a future time.

Some notifications may be received via the notification API 507. The notification API notification channel 507 may be based on a local API of the unified application notification framework 501 and may therefore also be referred to as a local notification API. An API refers to a set of functions, methods, procedures, subroutines, definitions, protocols, and/or data that are intended to allow applications, operating systems, services, etc. to access the functions or data of the same or other applications, operating systems, services, etc. The native API (also referred to as a proprietary API) of the unified application notification framework 501 may be an API specifically written or designed for accessing the functions of the unified application notification framework 501. An application 504 designed to utilize this local API (e.g., the API is integrated into the application 504) can make an appropriate API call to issue a notification (e.g., SendNotif ()) to send the notification message directly to the unified application notification framework 501.

Other notifications may be received via operating system level notification intercept 508. Operating system level notification interception 508 can rely on a notification API integrated into the operating system 505 to intercept any operating system level notifications sent from the application programs 504 to the operating system 505. Operating system 505 may be a virtual operating system instance, such as guest operating system 330 of FIG. 3. A notification API (also referred to as an OS-level notification API) integrated into the operating system 505 may be part of an API provided by the operating system 505 that allows applications running on the operating system 505 to initiate calls and send notifications to the operating system 505. For example, a calendar application program may notify the operating system 505 that a calendar event is imminent, or an Instant Messaging (IM) application program may notify the operating system 505 of an incoming IM request from another user. In another example, the navigation application may notify and request permission from the operating system 505 to receive Global Positioning System (GPS) signals. Examples of operating system level notification APIs include the prompt information/tile/logo notification API in the Windows operating system, manufactured by Microsoft corporation of Redmond, Washington, and the libnotify library in the Linux operating system.

Operating system level notifications may be intercepted by the notification interception layer 513. The notification interception layer 513 can be an application, program, service, background process, and/or foreground process that is tasked with monitoring any OS API calls made by applications running on the operating system 505 and intercepting or snooping those API calls for further processing. Processing the API call may include creating a shadow notification of the original API call made by the application and/or forwarding the original API call to the operating system 505. Notification interception layer 513 can be implemented into virtual machine 502 between application 504 and operating system 505 (e.g., an OS notification API). Alternatively, the notification interception layer 513 can be part of the operating system 505. In some other embodiments, the notification interception layer 513 can be included in the unified application notification framework 501. Whenever an application 504 calls the notification API, a shadow notification that is the same or substantially similar in content to the original notification call may be generated by the notification interception layer 513 and sent to the unified application notification framework 501. The shadow notifications may conform to the local notification API of the unified application notification framework 501 (which may be different from the OS-level notification API of the operating system 505), as discussed above with reference to the local notification API notification channel 507. For example, the shadow notification may be a duplicate copy of the original notification call, or it may contain only part of the information included in the original notification call. The notification interception layer 513 may create shadow notifications for all or only part of the intercepted OS level API calls. For example, the notification interception layer 513 can be programmed to ignore or filter out certain API calls, such as repeated or repeated calls within a certain period of time. Other API calls may be ignored or filtered out based on their type, priority, size, etc. Alternatively, instead of generating and sending shadow notifications to the unified application notification framework 501, the notification interception layer 513 can intercept raw API calls from the application 504 and forward the raw API calls to the unified application notification framework 501.

Other notifications may also be received via the service-to-service notification channel 509. Service-to-service notification channel 509 refers to a communication channel used to deliver notification messages from one service (e.g., backend services) to another service (e.g., unified application notification framework 501). The service-to-service notification 509 may rely on a back-end service 511 (also referred to as a backup service) to send notifications directly to the unified application notification framework 501. In particular, the application notification may be generated and pushed by one or more backend services associated with the application. For example, the back-end service 511 may be a mail server that pushes messages or notifications to the application 504 (e.g., an email client), which then sends its own notification messages to the operating system 505. However, the unified application notification framework 501 may expose its interface (e.g., service-to-service notification channel 509) to the back-end service 511 so that the back-end service 511 may send the notification directly to the unified application notification framework 501. Backend services 511 may be service providers (e.g., third party servers) that provide services to client device 503, application 504, operating system 505, and/or virtual machine 502. Thus, backend services 511 may be comprised of various hardware and/or software components and may include, for example, web servers, mail servers, application servers, messaging servers, location servers, content providers, online streaming media services, social media services, financial institutions, telecommunication services, Internet Service Providers (ISPs), software as a service (SaaS) providers, etc., that provide services to application 504. The back-end service 511 may issue separate and possibly repeated notifications to both the application 504 and the unified application notification framework 501, either simultaneously or serially. Alternatively, virtual machine 502 can forward any notification messages sent by backend services 511 to unified application notification framework 501, rather than backend services 511 sending notification messages directly to unified application notification framework 501. The service-to-service notification message may be sent via a network 512, such as the internet. Because backend services 511 are not part of virtual machine 502, notifications from backend services 511 can be received by unified application notification framework 501 even when virtual machine 502 is offline or otherwise unavailable for communication. For example, a backend service 511, such as a social media service, that has integrated the native APIs of unified application notification framework 501 may send friend request notifications to unified application notification framework 501, even when virtual machine 502 is offline or out of service. In other instances, the service-to-service notification message may be a new email alert from an email server, a new instant messaging alert from an instant messaging server, a download complete message from a File Transfer Protocol (FTP) server, a transaction alert from an online retailer, and the like. Unified application notification framework 501 can then forward the friend request notification to client device 503. The unified application notification framework 501 may also support notification multicasting so that an application can easily send notifications to all or a group of users. For example, notification messages for the service notification channel 509 by the service may be sent to multiple users through an API provided by the back-end service 511 for the application 504.

The three communication channels (i.e., notification API 507, operating system level notification interception 508, and service-to-service notification 509) may be employed separately or simultaneously. Although the three communication channels shown herein may be logically distinct from each other, two or more of these communication channels may be physically combined into one communication channel. For example, notification API call 507 and OS level intercept 508 may share the same physical communication channel between virtual machine 502 and unified application notification framework 501. The notification API 507 and service-to-service notification 509 communication channel may require a third party (e.g., an application developer, a backend service provider, etc.) to integrate specific code or instructions (e.g., a local API for the unified application notification framework 501), while the operating system level notification interception 508 may not make such a requirement. Additionally, the notification API 507 and operating system level notification intercept 508 communication channel may require that the application 504 be running (e.g., in the background), while the service-to-service notification 509 communication channel may operate even when the application 504 and/or virtual machine 502 are shut down, because the service-to-service notification 509 originates from a backend service 511 that generally operates independently of the virtual machine 502. For example, when a new email for user 506 is received by a back-end service 511, such as an email server, the email server may send a new email alert message directly to the unified application notification framework 501 through the service-to-service notification channel 509 and ultimately to the client device 503, even if the virtual machine 502 is offline or inoperable. Further, when a notification associated with the application 504 is received from the backend service 511 via the service-to-service notification channel 509 but the application 504 is not currently running on the virtual machine 502, the unified application notification framework 501 may cause the application 504 to run on the virtual machine 502 (e.g., send a message or command to the virtual machine 502 to launch the application 504) (e.g., run as a background process) in order to speed up user access. For example, when user 506 receives a new email alert message from backend service 511 at client device 503 via unified application notification framework 501 (i.e., service-to-service notification 509), unified application notification framework 501 may preemptively launch application 504 within virtual machine 502 such that when user 506 accesses virtual machine 504 via a workspace in client device 503, application 504 will have already been launched and run in virtual machine 502 and ready to display the new email, rather than user 506 having to manually launch application 504. Similarly, in response to notifying unified application notification framework 501 receiving a notification associated with application 504 from backend service 511 via service-to-service notification channel 509, unified application notification framework 501 may also cause operating system 505 and/or virtual machine 502 to run if they are not already running. In particular, the unified application notification framework 501 can first determine whether the operating system 505 and/or the virtual machine 502 are currently operational (e.g., running, online, powered on, etc.) and, if not, make the operating system 505 and/or the virtual machine 502 operational. This may be accomplished by transmitting a specific message or command (e.g., a data packet) to virtual machine 502 or a hypervisor associated with virtual machine 502 that triggers the startup of operating system 505 and/or virtual machine 502. Such messages or commands may be sent via one of the three communication channels described above or via a communication channel separate from the communication channel described above.

Fig. 6 depicts an example User Interface (UI) for a client device to receive notifications in accordance with one or more aspects described herein. The client device may be, for example, client device 503 of fig. 5. A user of a client device can access a user interface, such as a workspace environment 600 (also referred to as a client workspace or virtual environment) on the client device, to access one or more virtual machines, such as virtual machine 502 of fig. 5. The client workspace may be a front end through which a user may interact with the virtual application. The workspace environment 600 may be, for example, a network interface presented in a web browser, a mobile application running on a mobile device, a desktop application running on a PC, a module integrated into the operating system of a client device (e.g., integrated into a Windows file explorer or macOS Finder). Workspace environment 600 may be a stand-alone application or part of a client application that communicates with a server. In particular, the workspace environment 600 may be provided to client devices by a server (such as the management server 410 of FIG. 4).

A user of a client device can interact with workspace environment 600 to access remote desktops (e.g., operating system 505), virtual applications (e.g., application 504), and the like. In the example embodiment illustrated in FIG. 6, the workspace environment 600 may allow a user (e.g., "John Smith") to log in and access one of the UI elements (e.g., icons) representing the virtual desktop environments 601A, 601B, 601C (collectively 601). For example, virtual desktop 601A may be a virtual instance of the Windows 10 operating system, virtual desktop 601B may be a virtual instance of the macOS operating system, and virtual desktop 601C may be a virtual instance of the Linux operating system. Thus, when a user selects, for example, virtual desktop 601A on workspace environment 600, a remote desktop Graphical User Interface (GUI) of a virtual instance of the Windows 10 operating system running on a remotely located computing device can be launched and displayed on the client device.

Additionally, the workspace environment 600 may also include UI elements (e.g., icons) representing the virtual applications 602A, 602B (collectively 602). For example, virtual application 602A may be an email application running on a virtual machine (e.g., virtual machine 502) provided by a remotely located computing device (e.g., server 206). In other instances, virtual application 602B may be a calendar application. Virtual application 602A and virtual application 602B may run on the same or separate virtual machines. Thus, when a user selects, for example, virtual application 602A on workspace environment 600, the client device may display output generated by a corresponding virtual instance of an email application executing on a remotely located computing device (e.g., server 206).

The workspace environment 600 may receive notifications from a unified application notification framework, such as the unified application notification framework 501 of FIG. 1. Notifications may originate from an application, an operating system instance, or a backend service, depending on which of the three communication channels listed above is used for notification delivery. Once the workspace environment 600 receives the notification, the workspace environment 600 may present the notification to the user. For example, the notification can be visually displayed (e.g., text, an icon, a pop-up window, a dialog box, a status bar, a reminder, a sticker, a logo, an alarm, a counter, etc.) or audibly played (e.g., an alarm clock, a ringtone, an audio alert, etc.). In the example embodiment shown in fig. 6, the notifications appear as logos 603A, 603B, 603C, 603D (collectively 603) and a status bar 604.

Logos 603A, 603B, 603C, 603D may each indicate the number of notifications that have been received from the respective virtual desktop and virtual application, but not purged. Thus, for example, logo 603A may indicate that there are currently two pending notifications from virtual desktop 601A. These notifications may originate from virtual desktop 601A (i.e., the virtual instance of the operating system) itself or from any of the applications running on virtual desktop 601A. In another example, logo 603B may indicate that there are currently 29 pending (i.e., not cleared) notifications from virtual application 602A. In particular, these notifications may represent 29 new unread email messages. Further, the absence of a notification logo associated with virtual desktop 601B can indicate that no notification associated with virtual desktop 601B was received or that all notifications thereof have been cleared. Finally, the workspace environment 600 may display a global notification message, such as through the status bar 604.

Although logo 603 is used in the example embodiment shown in FIG. 6, other methods may be used to indicate the presence or absence of notifications regarding virtual desktop environment 601 and/or virtual application 602. For example, icons representing virtual desktop environment 601 and/or virtual application 602 can be highlighted, colored, shaded, animated, enlarged, reduced, etc. to indicate the presence or absence of pending (i.e., not cleared) notifications. The icons may be visually changed in different ways depending on the number of notifications and/or the priority of the notifications. For example, an icon with a normal priority notification may be displayed as a green logo, while another icon with a high priority notification may be displayed as a red logo. The logo 603 may be located on the top, bottom, left side, right side, etc. of the icon or above the icon. In addition, the icons may be automatically rearranged based on the notification. For example, the icon with the highest notification count may be placed at a position most noticeable to the user, such as the top left corner of the first page, and the remaining icons may be arranged in descending order. In some example embodiments, when the user selects the icon with the notification, the content of the notification message may be displayed on the screen. In some example embodiments, a preview of a notification message (e.g., a partial message) may be displayed when a mouse pointer hovers over an icon with a notification or a long touch input (i.e., touch and hold) is received over the icon.

Having disclosed some basic system components and concepts, the present disclosure now turns to the example method embodiments shown in fig. 7 and 8. For clarity, the methods are described in terms of a unified application notification environment 500 configured to practice the methods as shown in FIG. 5. However, any of the other devices or systems discussed above, such as computing environment 200, virtualization server 301, cloud computing environment 400, etc., may also perform any of the steps disclosed herein. The steps outlined herein are exemplary and may be implemented in any combination thereof, including combinations that exclude, add, or modify certain steps. For example, operations 701, 702, 703 of fig. 7 may be performed in any order, or two or more of operations 701, 702, 703 may be performed simultaneously.

FIG. 7 depicts an exemplary method for providing a unified application notification framework. The example method of fig. 7 may be performed by a unified application notification framework, such as unified application notification framework 501. First, the unified application notification framework can check if there are any notifications received via one of the available communication channels. The checking and receiving of notifications may be performed synchronously or asynchronously. The unified application notification framework can poll periodically (e.g., every 1 second, 10 seconds, 1 minute, 5 minutes, 1 hour, etc.) to see if there are pending notifications, or can push notifications to the unified application notification framework.

The unified application notification framework can determine if there is a notification to be received via the notification API channel (701). If there are one or more notifications to receive, the method proceeds to operation 704. If not, the unified application notification framework can determine if there is a notification to be received via the operating system level intercept channel (702). If there are one or more notifications to receive, the method proceeds to operation 704. If not, the unified application notification framework may determine if there is a notification to receive via the service-to-service notification channel (703). If there are one or more notifications to receive, the method returns to operation 701 and the unified application notification framework continues to monitor for pending notifications.

At operation 704, the unified application notification framework can receive a notification associated with the virtual application via one of the plurality of communication channels. The plurality of communication channels may include a local notification API channel, an operating system level notification intercept channel, and/or a service-to-service notification channel.

For a unified application notification framework that receives notifications via a local notification API channel, the virtual application may need to request API calls. For example, when an application encounters a particular event (e.g., receipt of a new email, receipt of a new instant message, completion of download, fatal error, etc.), the application may make a call (e.g., SendNotif ()) according to an API provided by the unified application notification framework. Appropriate notification messages (e.g., data packets) can then be transmitted from the application to the unified application notification framework according to the API. The notification message may be transmitted via a network such as the internet.

When a notification is received via the operating system level notification intercept channel, a notification is received from the virtual operating system on which the virtual application is executing. The notification may be generated based on a virtual notification sent by the virtual application to the virtual operating system. Virtual notifications refer to operating system level notification messages generated by a virtual application to a virtual operating system (e.g., Windows hint information/tile/logo API, Linux libnotify library). Notifications (e.g., shadow notifications) may be generated by a notification interception layer (e.g., an application, service, and/or process executing on a virtual operating system and/or virtual machine) after intercepting a virtual notification.

When a notification is received via a service-to-service notification channel, the notification may be received from a backend service (e.g., a third party server such as a web server, email server, content server, etc.) that serves the virtual application.

The unified application notification framework can determine an Identifier (ID) of the received notification. The identifier may indicate a virtual application associated with the notification and/or the backend service. For example, the identifier may be a string of alphanumeric characters that uniquely identifies the application within a certain namespace. The identifier may be inserted into the notification by the sender (e.g., application, notification interception layer, backend service, etc.) and extracted by the unified application notification framework. The unified application notification framework can store the received identifier in a database that stores associations between identifiers and applications. This database can later be used, for example, to identify duplicate notifications originating from the same application.

The unified application notification framework can filter the received notifications (705). In other words, received notifications may be classified and notifications that do not meet certain conditions or thresholds may be filtered out. For example, after receiving a notification associated with a virtual application via one of the plurality of communication channels, the unified application notification framework can determine whether the notification satisfies filtering criteria. The filter criteria may include notification type (e.g., reminder information, logo, pop-up window, etc.), communication channel type (e.g., notification API, operating system level intercept, service-to-service notification, etc.), application type (e.g., email client, instant messenger, calendar application, etc.), time (e.g., time or receipt), priority (e.g., high priority, normal priority, low priority, etc.), and/or repetition (e.g., whether a repeated or similar notification has been recently received). If the notification does not meet the filter criteria, the notification may be discarded and therefore not sent to the client workspace. The filtering process may be performed based on an identifier included in the received notification.

The unified application notification framework can then send the received notification to the client workspace (706). The client workspace may be a network client, an application, a service, and/or an operating system. The unified application notification framework can also send other relevant information, such as an application Identifier (ID) corresponding to the virtual application, a notification type (e.g., reminder information, logo, pop-up window, etc.), a timestamp, notification priority information, and the like. The additional information to be transmitted may be determined based on the communication channel type of the reception notification. In addition to sending notifications to the client workspace immediately, the unified application notification framework may schedule notifications to be sent to the client workspace at a particular time (e.g., 6:00 am on Monday, 12 hours later, etc.). Upon receiving the notification at the client workspace, the workspace may display the notification (707). For example, the notification may be displayed as text, a pop-up window, a dialog box, a status bar update, a logo, a reminder, an icon, a tile, an alarm, a counter, and so forth. The notification may be displayed partially (e.g., as a summary) or fully.

If a notification is received via the service-to-service notification channel (708), the unified application notification framework can launch the virtual application (709). In other words, the unified application notification framework can cause the virtual application to execute as a foreground or background process when it is not already running in order to speed up user access to the application. The unified application notification framework may first determine whether the virtual application has executed on the virtual machine and cause the virtual application to launch only if the virtual application is not executing. In addition, upon receiving the service-to-service notification message, the unified application notification framework may trigger other appropriate actions for the virtual machine, operating system, and/or application, such as downloading a file, terminating an application, launching a related application, and so forth. For example, if a new update for a desktop application is available from a file server, the server may send a service-to-service notification to the client device via the unified application notification framework. At this point, the unified application framework may also cause the desktop application to launch on the virtual machine so that updates to the application may be downloaded and/or installed even before the user reacts to the notification. If no notification is received via the service to service notification channel, the method proceeds to operation 710.

The unified application notification framework can determine whether the client workspace has sent a receipt acknowledgement in response to the sent notification (710). If sending the notification to the client workspace fails (e.g., no acknowledgement of receipt is received within a threshold time limit), the notification can be saved (e.g., at the unified application notification framework) and a retry mechanism can be applied. For example, the notification may be immediately resent (706), or may be scheduled to be resent to the client workspace at a later time. However, if an acknowledgement of receipt is received from the client workspace within the threshold time limit, the unified application notification framework can mark the notification as cleared and also delete the notification from the unified application notification framework. Notifications may be marked as cleared and deleted only after the user of the client workspace has acknowledged the notification.

FIG. 8 depicts an exemplary method for receiving notifications by a client workspace. The example method of fig. 8 may be performed by a client workspace, such as client device 503. The client workspace may receive notifications from a unified application notification framework, such as unified application notification framework 501 of fig. 5 (801). The client workspace can send a receipt acknowledgement back to the unified application notification framework. The client workspace may extract the application ID included in the notification (802) to confirm whether the application ID matches one of the applications associated with the client workspace. If the application IDs do not match, the client workspace may give up notifications without further processing. Accordingly, the method may return to operation 801 to monitor for any other notifications.

If a match to the application ID is found, the client workspace may present a notification to the user (803). For example, the client workspace may display a notification message and/or play an alarm sound as described above. Alternatively, the notification message may be encrypted by the unified application notification framework and decrypted by the client workspace to improve security. In particular, encryption/decryption may be performed via symmetric or asymmetric cryptography. For example, the unified application may encrypt the notification message with the client's public key before transmission, and the client may decrypt the received notification message with its private key. The client workspace may then determine whether the notification has been acknowledged by the user (e.g., within a threshold time limit) at operation 804. The user may acknowledge the notification by dismissing the displayed notification message, for example, by clicking on the notification message and/or accessing a virtual application associated with the notification. Alternatively, the notification may be automatically confirmed without user intervention. If the user does not acknowledge the notification, the client workspace may continue to wait for its acknowledgement. However, once the notification is successfully acknowledged, the notification may be cleared from the client workspace (805). The client workspace may clear the notification by calling an operating system notification API of the virtual operating system, calling a local notification API of the unified application notification framework, and/or notifying a backend service, which will then call the local notification API. The unified application notification framework may then mark the notification as cleared. Upon clearing the message, the unified application notification framework will no longer attempt to deliver or re-deliver the message to the client workspace.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are described as example implementations of the following claims.