Sharing resources between client devices in a virtual workspace environment

A system and method for sharing resources between client devices in a virtual computing environment. A method is disclosed that includes receiving a request from a first client device for a list of available resources that are locally connected to other client devices and that are unavailable to the first client device via an enterprise service within the virtual computing environment; providing the list of available resources to the first client device; receiving a selection of a resource included within the list of available resources from the first client device; providing a push notification to a second client device connected to the selected resource to establish a connection with the selected resource; and providing, to the first client device, access to the selected resource via the established connection.

BACKGROUND OF THE DISCLOSURE

Enterprise computing platforms, which are typically deployed via cloud systems, virtual networks, servers, etc., allow users to utilize and share services and features over a network from client devices. For example, in a virtual workspace environment, users can interact with virtual workspaces that appear on their client devices but are actually running elsewhere on a server.

BRIEF DESCRIPTION OF THE DISCLOSURE

Aspects of this disclosure provide a system and method for sharing locally connected resources between client devices in a virtual computing environment.

A first aspect of the disclosure provides a method implemented with a computing device for sharing resources in a virtual computing environment. The method includes receiving, by a computing system, a request from a first client device, the request being for a list of available resources, wherein the list of available resources include resources that are locally connected to at least one other client device and that are unavailable to the first client device via an enterprise service within the virtual computing environment. The method further includes providing, by the computing system, the list of available resources to the first client device, the list of available resources including an identifier (ID) and metadata for at least one of the available resources. Furthermore, the method includes receiving, by the computing system, a selection of a resource included within the list of available resources from the first client device; and providing, by the computing system, a push notification to a second client device connected to the selected resource to establish a connection with the selected resource.

A second aspect of the disclosure provides a computing device that provides for the sharing of resources within a virtual computing environment. The device includes a memory and a processor coupled to the memory that are configured to implement a process. The process includes storing information associated with a set of resources, the information including an identifier (ID) and metadata for each resource in the set of resources, wherein each resource is connected locally to a client device and each resource is unavailable to other client devices via an enterprise service within the virtual computing environment. The process further includes receiving from a first client device a request for a list of available resources, providing the list of available resources to the first client device, the list of available resources including the ID and metadata for each of the available resources, and receiving from the first client device a selected resource from the list of available resources, wherein the selected resource is connected to a second client device. The process further includes pushing a notification to the second client device to establish a connection with the selected resource.

The drawings are intended to depict only typical aspects of the disclosure, and therefore should not be considered as limiting the scope of the disclosure.

DETAILED DESCRIPTION OF THE DISCLOSURE

Embodiments of the disclosure provide technical solutions for sharing local resources connected to client devices with other client devices in a virtual computing environment without utilizing resource servers. In the past, sharing of a resource such as a printer amongst client devices required that the printer be managed by an enterprise service such as a universal print server (UPS), complex desktop delivery controller (DDC) and/or other policies. Accordingly, it was not possible to share a resource such as a printer, fax, etc., that was locally (e.g., directly) connected to a client device, unless the resource was managed by an enterprise service. The resource could only be accessed via the client device to which it is connected or locally from a virtual desktop agent (VDA) session connected to the client device.

The present embodiments provide methodologies for registering resources that are locally-connected to a set of client devices with a workspace (WS) resource server, e.g., located in a cloud. The WS resource server is also configured to receive requests from users of client devices for a list of currently available resources. Thereafter, a connection can be established between a locally connected resource on a first client with a second client. Each client includes a client side (CS) service that can manage the interface with the WS resource service, e.g., via a virtual desktop agent (VDA) session, WebSocket connection, etc.).

For the purposes of this disclosure, a “local resource” generally includes any resource that is readily accessible by or from a client device, including network-based resources, but cannot be accessed without traditional enterprise services such as authenticators, gateways, workspace applications, legacy Universal Print Servers, etc. Local resources may be connected to a client device using connections such as USB, Bluetooth, Wifi, etc.

FIG. 1depicts a computing infrastructure100having a virtual computing environment in accordance with an illustrative embodiment. In this case, a server desktop104running, e.g., MS Windows®, Linux®, etc., includes a set of virtual desktop agents (VDAs)122, that provide remote virtual access to the server desktop104for a set of client devices (e.g., laptops, smart devices, etc.). Server desktop104may for example be implemented as an on-premises system or via a cloud102. In the example shown, server desktop104is implemented as an on-premises system and interacts with cloud102via a cloud connector120and delivery controller118, which provides access to a workspace (WS) resource server110.

In the example shown, two client devices106,108are configured to remotely access the server desktop104. The first client device106includes a workspace (WS) application130(e.g., as provided by Citrix® Workspace commercially available from Citrix Systems of Fort Lauderdale, Fla. in the United States) running a client side (CS) resource service134, and is connected to the server desktop104via a VDA session128. Similarly, the second client device108includes a WS application140running a CS resource service138, and is connected to the server desktop104via a VDA session142.

In this case, a resource124such as a printer, scanner, fax, peripheral, etc., has been connected to client device106without using an enterprise service, e.g., via a universal serial bus (USB) connection. In past implementations, resource124would only be available via the local client device106, i.e., a user of remote client device108could not access the resource124without an enterprise service such as a print server. The present approach allows the second client device108to access the resource124on the first client device106with the use of: (1) the client side (CS) resource service134,138installed on client devices106,108, respectively; and (2) the WS resource server110implemented in cloud102. In some embodiments, the client side (CS) resource service134,138may be installed as part of the Workspace (WS) application130,140respectively.

In one illustrative embodiment, the WS resource server110communicates with CS resource services134,138over a virtual channel infrastructure, such as Citrix HDX (High Definition Experience) protocol, either in a full or lightweight headless session. A headless session utilizes a protocol such as Citrix Independent Computing Architecture (ICA) that is established automatically and silently as a background operation without direct user initiation and without user visible artifacts. Such an infrastructure renders a virtual version of a workspace on a client device and can for example: (1) examine screen activity, application commands, endpoint device, and network and server capabilities to instantly determine how and where to render an application or desktop activity; (2) provide data compression; and (3) optimize network traffic using techniques such as data deduplication. In a lightweight headless session, the session is for example run without rendering a graphical user interface or any additional virtual channels such as audio, multimedia, client drive mapping, clipboard mapping, etc., which are not required for resource124utilization.

The CS resource services134,138communicate with the WS resource server110using the associated WS application130,140via an active session, e.g., using an HDX VDA session, a headless VDA session, or some other protocol. Illustrative functions performed by CS resource services134,138include capturing resource connect and disconnect events, e.g., “plug and play” events, generated by the resource124and forwarding device metadata to the WS resource server110to effectuate registration of the resource124in the cloud102. The CS resource service134,138also allows the user to set access rights to grant access to the resource124to other users or devices. These rights are then forwarded to either the WS resource server110or to another server managing the access control. The CS resource services134,138can also send enumeration requests to the WS resource server110to list all the resources available to a user and the associated resource details. The CS resource services134,138can additionally listen for any incoming requests to access a locally connected resource124from a remote client device and grant access to the requestor after authenticating and checking the access rights of the requestor from the WS resource server110.

In one illustrative embodiment, when a new resource124is connected to a client device106, the WS resource server110registers the new client side resource124, e.g., in a resource database (DB)112. In one embodiment, when a new resource124is connected, the WS resource server110receives the resource metadata and generates a resource ID. The WS resource server110maintains a list of resource IDs in the resource DB112, which includes associated resource metadata.

In response to a user request, WS resource server110will generate a list all the client side resources124available to the user after verifying the access rights for that user. The WS resource server110may for example contact an authorization service114, which may or may not be part of the WS resource server110, to authenticate the user and authorize the user based on an authorization policy, e.g., using a directory service such as Active Directory by Microsoft. Once generated, WS resource server110will share the resource metadata to a requesting CS resource service138. Metadata may for example include: resource type, name, model, driver version; {Class GUID, Instance GUID} on Windows; {Product ID, Product Version} on LINUX; device Mac address; client name; etc. In some example embodiments, a user request could be triggered within a VDA session, for example, VDA session142. In other example embodiments, a user request could be triggered from a client device, for example, at WS application140of client device108, then relayed to the WS resource server110via the VDA session142.

FIG. 2depicts a flow diagram showing an illustrative resource registration process200and an illustrative resource disconnect process202, with reference toFIG. 1. During a resource registration process200, the user connects a resource124to a client device106, which causes the resource124to generate an event, such as a “plug and play” event, which is then handled by the CS resource service134running on the WS application130. The event is then communicated via a virtual channel, e.g., over HDX using an active full or headless HDX VDA session128. Next, the WS application130makes a registration call to the WS resource server110via the cloud connector120. The WS application130also sends the resource metadata along with the request.

In an illustrative embodiment, during a registration process when a device is detected, the CS resource service134sends resource metadata (i.e., device information) to the WS resource server110that may for example include interface call GUID, handle, type, name, model, product ID, product version, driver information, IP address, etc. The WS resource server110then sends a resource ID back to the CS resource service134, which is used for subsequent events.

Accordingly, in response to a received request, the WS resource server110verifies the resource metadata (e.g., checks for duplicates, etc.), which may include evaluating the resource type, resource drivers, resource IP address (internal/external), etc. Next, the WS resource server110generates the resource ID, assigns the resource ID to the resource metadata and sends the resource ID to the WS application130and the CS resource service134, which keeps track of the resource124.

During a resource disconnect process202, e.g., the resource124is unplugged from the client device106, and, e.g., a “plug and play” disconnect event is generated. The CS resource service134running on the WS application130captures the event and forwards a request to the WS resource server110along with the resource ID to mark the resource as inactive in the resource database112.

FIG. 3depicts an illustrative resource access process, with reference toFIG. 1. In this example, a user of WS application140on client device108provides user credentials and requests a list of available resources. The CS resource service138running on WS application140sends a request to the WS resource server110via the cloud connector120. Next, the WS resource server110calls the authentication service114to verify the credentials of the user. Any authentication process could be used such as an active directory (AD) integration (e.g., a lookup in an AD database), Microsoft Azure AD, integration with any third-party identity provider (IDP), etc. Additionally, using Cloud Connectors, the authorization could be integrated with a local AD account (e.g., if the customer enterprise already supports it).

Once the user is authorized, the WS resource server110determines a list of resources available to the user, based on the user's authorization and associated policies. The WS resource server110then sends a list of available resources to the user via WS application140. The user selects a resource124they want to access and sends the request to the WS resource server110. The WS resource server110then sends a push notification to the client device106, to wake up the WS Application130/VDA session128connected to the resource124. A push notification service116may be incorporated into, or be independent, from the WS resource server110. Once the push notification is received, the user can directly access the resource124via the resource metadata information. In an illustrative VDA embodiment, HDX manages any data required by the resource124, such as print data. In this case, an HDX Printing Virtual Channel is utilized to map the local resource124into the session as a virtual printer.

Push notifications from the WS resource server110are first sent to a push notification service116that is part of the WS resource server110or provided by a third party. The notification is then forwarded to the operating system of the client device106, which forwards the notification to the WS application130. The notification is then forwarded to the CS resource service134, which issues a wake up or connect signal to the resource124.

Note that push notifications are an ideal approach because they leverage efficient native platform capabilities (e.g., Windows, Apple, Android, etc., employ push notifications and respective cloud push notification services). However, existing active connections could alternatively be utilized to send notifications, e.g., active WS application130to WS resource server110WebSocket connections, or active WS application130to VDA HDX connections, e.g. active VDA session128.

For performance and availability, a client resource124may be woken up via a push notification triggered by the WS resource server110via the WS application130(which maintains a mapping of connected resources on the client device106). Initially, at the time of resource registration with the WS resource server110, the WS application130may also register with the push notification service116and obtain a device token, which is sent along with the resource information to the WS resource server110. In this embodiment, WS application130running on the client device106owning the resource124does not need to maintain an active resource session128. In the event another client device requests use of the resource124, the WS resource server110sends the available resource IDs and metadata to the client device106. After selection of the resource, a request for the same is sent to the WS resource server110. The WS resource server110uses the device token of the client device106previously received to send a push notification.

This push notification wakes up the WS application130connected to the resource124. Upon receiving the wake up request, the WS application130then activates the resource session132, and is then able to receive the request to communicate with the resource. If a session already exists (e.g., from a prior request), then that session is utilized. If the session does not exist, then a new headless resource session can be created.

Referring toFIG. 4andFIGS. 6A and 6B, the use of push notification services in a resource sharing environment220is further described. As shown in flow diagram ofFIG. 6A(with reference toFIG. 4andFIG. 1), the WS application130registers with a push notification service (PNS)230at51, such as a Window Notification Service, Android PNS, Apple PNS, etc. At S2, the WS application130runs the client side resource service134and establishes an active remote session with VDA228. At S3, the WS application130sends, e.g., a secret ID, secret key, device token, device type, etc., to WS resource service222(e.g., running on WS resource server110), e.g., via VDA host agent236or directly.

At S4, it is noted that VDA228may have an enabled session lingering and at S5another user issues a request to the WS resource service222to access the resource124. At S6, WS resource service222generates a notification and at S7prepares the notification for dispatch, e.g., encrypts the notification context with a secret key and adds a device token, secret key ID, metadata, etc. At S8, the WS service222sends the notification to a VDA host agent236. At S9, a determination is made whether the WS application130has an active connection.

If no active connection exists, then the WS resource service222notifies the push notification provider232to dispatch a notification via PNS based on the device type at S10. Then at S11, the PNS230relays a silent notification to the target device (i.e., client device106connected to resource124). At S12, the target device (i.e., client device106) receives the push notification for WS application130and at S13the target device OS agent227relays the notification to the WS application130. The client side resource service134then receives the notification from the WS application130at S14and decrypts the notification at S15. At S16, the client side resource service134wakes up/reconnects with the resource124.

In the event there is an active connection at S9, then a wake up notification is dispatched at S17, e.g., over HDX connector or other protocol such as WebSocket. The process then continues at S14, in which the client side resource service134receives the notification from the WS application130. The process continues below withFIG. 6B.

In an alternative embodiment, rather than using a WS application and virtual channel protocol such as HDX to provide a communication path, a technology such as WebSocket can instead be utilized. WebSocket is a computer communications protocol, providing full-duplex communication channels over a single TCP connection. This approach would remove the need for the CS resource service134,138(FIG. 1) to connect to the VDA or run a headless HDX session. The WebSocket would allow a two-way communication with the WS resource server110and sharing of the device metadata. The resource may be awakened via a push notification, as previously described. Alternatively, the resource could be awaked using an existing active WebSocket connection, as previously described. In one implementation, the CS resource service134,138may maintain an open WebSocket and listen to incoming data from the WS resource server110. In an embodiment where the CS resource service138maintains a permanent WebSocket connection, the WS application need not be involved. In an embodiment involving a native platform-integrated push notification, e.g., Apple Push Notification Service (APS), Windows Push Notification Service (WPS), etc., the WS application could be registered to receive the push notifications and relay them to the CS resource service138.

FIG. 5depicts an architecture250that does not utilize HDX. Instead, resource sharing via a WS resource server110leverages a direct Peer-to-Peer (P2P) connection252(e.g., WebSocket, TCP, UDP, HTTPS, etc.) or a P2P indirect connection. As noted, a WebSocket connection can be established with the computing device (e.g., WS resource server110). P2P direct connections between the first and second devices106,108are utilized whenever possible. Alternatively, a P2P indirect connection, e.g., utilizing help from Session Traversal Utilities for Network Address Translation (STUN)/Traversal Using Relays around Network Address Translation (TURN) servers254between the first and second devices may be utilized.

Returning toFIG. 6B, the device sharing process is further described and continues from connector A fromFIG. 6A. At S18, a determination is made whether the requested machine (e.g., client device106or client device108) is reachable via a P2P method. If yes, then the client side resource service sets up the connection via a direct address, or via an indirect (e.g., STUN/TURN) server at S19and access to the shared resource is provided at S20. If the requested machine is not reachable via P2P at S18, then at S21a determination is made whether to use HDX protocol. If yes, then at S23the WS application acts as a relay and sets up the connection over HDX and the shared resource is accessed at S20. If not, then at S22the WS application acts as a relay and sets up a connection via WebSocket and the shared resource is accessed at S20.

Referring toFIG. 7, an illustrative network environment400is depicted suitable for implementing an enterprise computing platform. Network environment400may include one or more clients402(1)-402(n) (also generally referred to as local machine(s)402or client(s)402) in communication with one or more servers406(1)-406(n) (also generally referred to as remote machine(s)406or server(s)406) via one or more networks404(1)-404n(generally referred to as network(s)404). In some embodiments, a client402may communicate with a server406via one or more appliances410(1)-410n(generally referred to as appliance(s)410or gateway(s)410).

Although the embodiment shown inFIG. 7shows one or more networks404between clients402and servers406, in other embodiments, clients402and servers406may be on the same network404. The various networks404may be the same type of network or different types of networks. For example, in some embodiments, network404(1) may be a private network such as a local area network (LAN) or a company Intranet, while network404(2) and/or network404(n) may be a public network, such as a wide area network (WAN) or the Internet. In other embodiments, both network404(1) and network404(n) may be private networks. Networks404may employ one or more types of physical networks and/or network topologies, such as wired and/or wireless networks, and may employ one or more communication transport protocols, such as transmission control protocol (TCP), internet protocol (IP), user datagram protocol (UDP) or other similar protocols.

As shown inFIG. 7, one or more appliances410may be located at various points or in various communication paths of network environment400. For example, appliance410(1) may be deployed between two networks404(1) and404(2), and appliances410may communicate with one another to work in conjunction to, for example, accelerate network traffic between clients402and servers406. In other embodiments, the appliance410may be located on a network404. For example, appliance410may be implemented as part of one of clients402and/or servers406. In an embodiment, appliance410may be implemented as a network device such as Citrix networking (formerly NetScaler®) products sold by Citrix Systems, Inc. of Fort Lauderdale, Fla.

As shown inFIG. 7, one or more servers406may operate as a server farm408. Servers406of server farm408may be logically grouped, and may either be geographically co-located (e.g., on premises) or geographically dispersed (e.g., cloud based) from clients402and/or other servers406. In an embodiment, server farm408executes one or more applications on behalf of one or more of clients402(e.g., as an application server), although other uses are possible, such as a file server, gateway server, proxy server, or other similar server uses. Clients402may seek access to hosted applications on servers406.

As shown inFIG. 7, in some embodiments, appliances410may include, be replaced by, or be in communication with, one or more additional appliances, such as WAN optimization appliances412(1)-412(n), referred to generally as WAN optimization appliance(s)412. For example, WAN optimization appliance412may accelerate, cache, compress or otherwise optimize or improve performance, operation, flow control, or quality of feature of network traffic, such as traffic to and/or from a WAN connection, such as optimizing Wide Area File Features (WAFS), accelerating Server Message Block (SMB) or Common Internet File System (CIFS). In some embodiments, appliance(s)412may be a performance enhancing proxy or a WAN optimization controller. In one embodiment, appliance412may be implemented as Citrix SD-WAN products sold by Citrix Systems, Inc. of Fort Lauderdale, Fla.

In described embodiments, clients402, servers406, and appliances410and412may be deployed as and/or executed on any type and form of computing device, such as any desktop computer, laptop computer, or mobile device capable of communication over at least one network and performing the operations described herein. For example, clients402, servers406and/or appliances410and412may each correspond to one computer, a plurality of computers, or a network of distributed computers such as computing system300shown inFIG. 9.

Referring toFIG. 8, a cloud computing environment500is depicted, which may also be referred to as a cloud environment, cloud computing or cloud network. The cloud computing environment500can provide the delivery of shared computing services and/or resources to multiple users or tenants. For example, the shared resources and services can include, but are not limited to, networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, databases, software, hardware, analytics, and intelligence.

In the cloud computing environment500, one or more clients402a-402n(such as those described above) are in communication with a cloud network504. The cloud network504may include back-end platforms, e.g., servers, storage, server farms or data centers. The users or clients402a-402ncan correspond to a single organization/tenant or multiple organizations/tenants. More particularly, in one example implementation the cloud computing environment500may provide a private cloud serving a single organization (e.g., enterprise cloud). In another example, the cloud computing environment500may provide a community or public cloud serving multiple organizations/tenants.

In some embodiments, a gateway appliance(s) or service may be utilized to provide access to cloud computing resources and virtual sessions. By way of example, Citrix Gateway, provided by Citrix Systems, Inc., may be deployed on-premises or on public clouds to provide users with secure access and single sign-on to virtual, SaaS and web applications. Furthermore, to protect users from web threats, a gateway such as Citrix Secure Web Gateway may be used. Citrix Secure Web Gateway uses a cloud-based service and a local cache to check for URL reputation and category.

In still further embodiments, the cloud computing environment500may provide a hybrid cloud that is a combination of a public cloud and a private cloud. Public clouds may include public servers that are maintained by third parties to the clients402a-402nor the enterprise/tenant. The servers may be located off-site in remote geographical locations or otherwise.

The cloud computing environment500can provide resource pooling to serve multiple users via clients402a-402nthrough a multi-tenant environment or multi-tenant model with different physical and virtual resources dynamically assigned and reassigned responsive to different demands within the respective environment. The multi-tenant environment can include a system or architecture that can provide a single instance of software, an application or a software application to serve multiple users. In some embodiments, the cloud computing environment500can provide on-demand self-service to unilaterally provision computing capabilities (e.g., server time, network storage) across a network for multiple clients402a-402n. By way of example, provisioning services may be provided through a system such as Citrix Provisioning Services (Citrix PVS). Citrix PVS is a software-streaming technology that delivers patches, updates, and other configuration information to multiple virtual desktop endpoints through a shared desktop image. The cloud computing environment500can provide an elasticity to dynamically scale out or scale in response to different demands from one or more clients402. In some embodiments, the cloud computing environment500can include or provide monitoring services to monitor, control and/or generate reports corresponding to the provided shared services and resources.

In some embodiments, the cloud computing environment500may provide cloud-based delivery of different types of cloud computing services, such as Software as a service (SaaS)508, Platform as a Service (PaaS)512, Infrastructure as a Service (IaaS)516, and Desktop as a Service (DaaS)520, for example. IaaS may refer to a user renting the use of infrastructure resources that are needed during a specified time period. IaaS providers may offer storage, networking, servers or virtualization resources from large pools, allowing the users to quickly scale up by accessing more resources as needed. Examples of IaaS include AMAZON WEB SERVICES provided by Amazon.com, Inc., of Seattle, Wash., RACKSPACE CLOUD provided by Rackspace US, Inc., of San Antonio, Tex., Google Compute Engine provided by Google Inc. of Mountain View, Calif., or RIGHTSCALE provided by RightScale, Inc., of Santa Barbara, Calif.

PaaS providers may offer functionality provided by IaaS, including, e.g., storage, networking, servers or virtualization, as well as additional resources such as, e.g., the operating system, middleware, or runtime resources. Examples of PaaS include WINDOWS AZURE provided by Microsoft Corporation of Redmond, Wash., Google App Engine provided by Google Inc., and HEROKU provided by Heroku, Inc. of San Francisco, Calif.

SaaS providers may offer the resources that PaaS provides, including storage, networking, servers, virtualization, operating system, middleware, or runtime resources. In some embodiments, SaaS providers may offer additional resources including, e.g., data and application resources. Examples of SaaS include GOOGLE APPS provided by Google Inc., SALESFORCE provided by Salesforce.com Inc. of San Francisco, Calif., or OFFICE 365 provided by Microsoft Corporation. Examples of SaaS may also include data storage providers, e.g. Citrix ShareFile from Citrix Systems, DROPBOX provided by Dropbox, Inc. of San Francisco, Calif., Microsoft SKYDRIVE provided by Microsoft Corporation, Google Drive provided by Google Inc., or Apple ICLOUD provided by Apple Inc. of Cupertino, Calif.

Similar to SaaS, DaaS (which is also known as hosted desktop services) is a form of virtual desktop infrastructure (VDI) in which virtual desktop sessions are typically delivered as a cloud service along with the apps used on the virtual desktop. Citrix Cloud from Citrix Systems is one example of a DaaS delivery platform. DaaS delivery platforms may be hosted on a public cloud computing infrastructure such as AZURE CLOUD from Microsoft Corporation of Redmond, Wash. (herein “Azure”), or AMAZON WEB SERVICES provided by Amazon.com, Inc., of Seattle, Wash. (herein “AWS”), for example. In the case of Citrix Cloud, Citrix Workspace app may be used as a single-entry point for bringing apps, files and desktops together (whether on-premises or in the cloud) to deliver a unified experience.

Elements of the described solution may be embodied in a computing system, such as that shown inFIG. 9in which a computer300may include one or more processors302, volatile memory304(e.g., RAM), non-volatile memory308(e.g., one or more hard disk drives (HDDs) or other magnetic or optical storage media, one or more solid state drives (SSDs) such as a flash drive or other solid state storage media, one or more hybrid magnetic and solid state drives, and/or one or more virtual storage volumes, such as a cloud storage, or a combination of such physical storage volumes and virtual storage volumes or arrays thereof), user interface (UI)310, one or more communications interfaces306, and communication bus312. User interface310may include graphical user interface (GUI)320(e.g., a touchscreen, a display, etc.) and one or more input/output (I/O) devices322(e.g., a mouse, a keyboard, etc.). Non-volatile memory308stores operating system314, one or more applications316, and data318such that, for example, computer instructions of operating system314and/or applications316are executed by processor(s)302out of volatile memory304. Data may be entered using an input device of GUI320or received from I/O device(s)322. Various elements of computer300may communicate via communication bus312. Computer300as shown inFIG. 9is shown merely as an example, as clients, servers and/or appliances and may be implemented by any computing or processing environment and with any type of machine or set of machines that may have suitable hardware and/or software capable of operating as described herein.

Communications interfaces306may include one or more interfaces to enable computer300to access a computer network such as a LAN, a WAN, or the Internet through a variety of wired and/or wireless or cellular connections.

The foregoing drawings show some of the processing associated according to several embodiments of this disclosure. In this regard, each drawing or block within a flow diagram of the drawings represents a process associated with embodiments of the method described. It should also be noted that in some alternative implementations, the acts noted in the drawings or blocks may occur out of the order noted in the figure or, for example, may in fact be executed substantially concurrently or in the reverse order, depending upon the act involved. Also, one of ordinary skill in the art will recognize that additional blocks that describe the processing may be added.

As will be appreciated by one of skill in the art upon reading the following disclosure, various aspects described herein may be embodied as a system, a device, a method or a computer program product (e.g., a non-transitory computer-readable medium having computer executable instruction for performing the noted operations or steps). Accordingly, those aspects may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, such aspects may take the form of a computer program product stored by one or more computer-readable storage media having computer-readable program code, or instructions, embodied in or on the storage media. Any suitable computer readable storage media may be utilized, including hard disks, CD-ROMs, optical storage devices, magnetic storage devices, and/or any combination thereof.