SESSION RECONNECTS AND DYNAMIC RESOURCE ALLOCATION

Abstract

The disclosed computer-implemented method may include detecting, by a cloud-based software distribution host providing cloud-based access to an application to a client device, a pause in a user session of the application and in response to the detection, saving a user session state of the user session. The method may also include determining, based on one or more session characteristics relating to the user session, a session preservation time for preserving the user session state. The session preservation time may correspond to a predicted time for keeping the user session alive. The method may further include storing the saved user session state in a session state buffer for at least the determined session preservation time, and removing the user session state from the session state buffer after the session preservation time elapses. Various other methods, systems, and computer-readable media are also disclosed.

Description

CROSS REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Provisional Application No. 63/105,320, filed 25 Oct. 2020, and U.S. Provisional Application No. 63/194,821, filed 28 May 2021, the disclosures of each of which are incorporated, in their entirety, by this reference. Co-pending U.S. application Ser. No. 17/506,640, filed 20 Oct. 2021, is incorporated, in its entirety, by this reference.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings illustrate a number of exemplary embodiments and are a part of the specification. Together with the following description, these drawings demonstrate and explain various principles of the present disclosure.

FIG. 1 is a flow diagram of an exemplary method for managing session reconnects and dynamic resource allocation for a cloud hosting platform.

FIG. 2 is a block diagram of an exemplary system for managing session reconnects and dynamic resource allocation for a cloud hosting platform.

FIG. 3 is a block diagram of an exemplary network for managing session reconnects and dynamic resource allocation for a cloud hosting platform.

FIG. 4 is a block diagram of an exemplary architecture for a cloud hosting platform.

FIG. 5 is a diagram of a session reconnect.

FIG. 6 is a diagram of an exemplary buffer for managing session reconnects and dynamic resource allocation for a cloud hosting platform.

Throughout the drawings, identical reference characters and descriptions indicate similar, but not necessarily identical, elements. While the exemplary embodiments described herein are susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and will be described in detail herein. However, the exemplary embodiments described herein are not intended to be limited to the particular forms disclosed. Rather, the present disclosure covers all modifications, equivalents, and alternatives falling within the scope of the appended claims.

DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

A cloud platform may provide, to remote devices, cloud-based access to computing resources (e.g., data, applications, processing, etc.) available on the cloud platform, such as applications. A client device may connect to the cloud platform and run an application, hosted by the cloud platform, as if running natively on the client device. The server hosting environment of the cloud platform may maintain a user session data for the client device's application session to provide the native application experience. When the client device ends the session, the host server may no longer need to maintain the user session data and may therefore delete the user session data.

When users run applications natively on their own client device, the users may pause application sessions and later return. For example, a user may turn off his or her device, thereby pausing an application session of an active application running on the device. When the user turns on the device again, the application session for the active application may be resumed. The cloud platform may provide similar functionality of maintaining a user session by saving the user session data as a user session state when the client device pauses an application session. When the client device reconnects to the application session, the cloud platform may restore the user's session by retrieving the corresponding user session state.

However, storing the user session state indefinitely may be resource prohibitive. As application sessions increase, whether from the user using other applications or other users using applications, a number of user session states may increase such that storing all the user session states may quickly exhaust available memory. Although the user session states may be managed by deleting stale data, such schemes may cause a user's session state to be deleted before the user reconnects. The user's session may not be restored to the detriment of the user's experience.

The present disclosure is generally directed to managing session reconnects and dynamic resource allocation. As will be explained in greater detail below, embodiments of the present disclosure may detect a pause in a user session, determine a session preservation time for the user session, and storing a user session state of the user session for at least the session preservation time. By determining the session preservation time based on predicting a time for keeping the user session alive, the systems and methods described herein may provide a better user experience in reconnecting to sessions. The systems and methods described herein may improve the functioning of a computer itself by more efficiently storing and maintaining session state data. In addition, the systems and methods described herein may improve the field of state memory management by better predicting keep-alive times.

Features from any of the embodiments described herein may be used in combination with one another in accordance with the general principles described herein. These and other embodiments, features, and advantages will be more fully understood upon reading the following detailed description in conjunction with the accompanying drawings and claims.

The following will provide, with reference to FIGS. 1-6, detailed descriptions of systems and methods for managing session reconnects and dynamic resource allocation. Detailed descriptions of an exemplary method for managing session reconnects and dynamic resource allocation are provided with FIG. 1. Detailed descriptions of an exemplary computing system are provided with FIG. 2. Detailed descriptions of an exemplary network system are provided with FIG. 3. Detailed descriptions of an exemplary cloud-based software distribution host are provided with FIG. 4. Detailed descriptions of an example session reconnect are provided with FIG. 5. Detailed descriptions of an example buffer for maintaining user session states are provided with FIG. 6.

FIG. 1 is a flow diagram of an exemplary computer-implemented method 100 for managing session reconnects and dynamic resource allocation. The steps shown in FIG. 1 may be performed by any suitable computer-executable code and/or computing system, including the system(s) illustrated in FIGS. 2 and/or 3. In one example, each of the steps shown in FIG. 1 may represent an algorithm whose structure includes and/or is represented by multiple sub-steps, examples of which will be provided in greater detail below.

As illustrated in FIG. 1, at step 110 one or more of the systems described herein may detect, by a cloud-based software distribution host providing cloud-based access to an application to a client device, a pause in a user session of the application. For example, a session module 204 depicted in FIG. 2 may detect a pause in a user session 222.

In some embodiments, the term “user session” or “session” may refer to a temporary and interactive information interchange between communicating devices, such as a session of activity and/or interactions of a client referencing a resource that may be tracked by the resource's host. For example, a website host may track a user's activity during a session with a website provided by the website host. A user session may be used by a host to maintain user specific state, persistent objects, authenticated user identities, etc., and may further facilitate communication between the client and host by remembering previous interactions/communications. The state of the user session may be maintained in a memory during the session and as such, may be stored to a storage device and later retrieved. Thus, the user session may be paused, the session state stored, and the user session may be restored by retrieving the stored session state. For example, as will be discussed further below, the systems and methods described herein may manage user session states.

Various systems described herein may perform step 110. FIG. 2 is a block diagram of an example system 200 for managing session reconnects and dynamic resource allocation. As illustrated in this figure, example system 200 may include one or more modules 202 for performing one or more tasks. As will be explained in greater detail herein, modules 202 may include a session module 204, a state module 206, a preservation module 208, and a buffer module 210. Although illustrated as separate elements, one or more of modules 202 in FIG. 2 may represent portions of a single module or application.

In certain embodiments, one or more of modules 202 in FIG. 2 may represent one or more software applications or programs that, when executed by a computing device, may cause the computing device to perform one or more tasks. For example, and as will be described in greater detail below, one or more of modules 202 may represent modules stored and configured to run on one or more computing devices, such as the devices illustrated in FIG. 3 (e.g., computing device 302 and/or server 306). One or more of modules 202 in FIG. 2 may also represent all or portions of one or more special-purpose computers configured to perform one or more tasks.

As illustrated in FIG. 2, example system 200 may also include one or more memory devices, such as memory 240. Memory 240 generally represents any type or form of volatile or non-volatile storage device or medium capable of storing data and/or computer-readable instructions. In one example, memory 240 may store, load, and/or maintain one or more of modules 202. Examples of memory 240 include, without limitation, Random Access Memory (RAM), Read Only Memory (ROM), flash memory, Hard Disk Drives (HDDs), Solid-State Drives (SSDs), optical disk drives, caches, variations or combinations of one or more of the same, and/or any other suitable storage memory.

As illustrated in FIG. 2, example system 200 may also include one or more physical processors, such as physical processor 230. Physical processor 230 generally represents any type or form of hardware-implemented processing unit capable of interpreting and/or executing computer-readable instructions. In one example, physical processor 230 may access and/or modify one or more of modules 202 stored in memory 240. Additionally or alternatively, physical processor 230 may execute one or more of modules 202 to facilitate maintain the mapping system. Examples of physical processor 230 include, without limitation, microprocessors, microcontrollers, Central Processing Units (CPUs), Field-Programmable Gate Arrays (FPGAs) that implement softcore processors, Application-Specific Integrated Circuits (ASICs), portions of one or more of the same, variations or combinations of one or more of the same, and/or any other suitable physical processor.

As illustrated in FIG. 2, example system 200 may also include one or more additional elements 220, such as user session 222, user session state 224, session preservation time 226, and session state buffer 228. User session 222, user session state 224, session preservation time 226, and/or session state buffer 228 may be stored on a local storage device, such as memory 240, or may be accessed remotely. User session 222 may represent a memory state corresponding to a user's current application session, as will be explained further below. User session state 224 may represent data corresponding to the user session 222. Session preservation time 226 may represent a time for keeping user session state 224. Session state buffer 228 may represent a buffer for storing session states such as user session state 224, as will be explained further below.

Example system 200 in FIG. 2 may be implemented in a variety of ways. For example, all or a portion of example system 200 may represent portions of example network environment 300 in FIG. 3.

FIG. 3 illustrates an exemplary network environment 300 implementing aspects of the present disclosure. The network environment 300 includes computing device 302, a network 304, and server 306. Computing device 302 may be a client device or user device, such as a smartphone, a desktop computer, laptop computer, tablet device, smartphone, or other computing device. Computing device 302 may include a physical processor 230, which may be one or more processors, and memory 240, which may store data such as one or more of additional elements 220.

Server 306 may represent or include one or more servers capable of hosting cloud-based software distribution platform. Server 306 may provide cloud-based access to applications to computing device 302. Server 306 may include a physical processor 230, which may include one or more processors, memory 240, which may store modules 202, and one or more of additional elements 220.

Computing device 302 may be communicatively coupled to server 306 through network 304. Network 304 may represent any type or form of communication network, such as the Internet, and may comprise one or more physical connections, such as LAN, and/or wireless connections, such as WAN.

As described herein, server 306 may correspond to a cloud-based software distribution host. In some embodiments, the cloud-based software distribution host may host software applications for cloud-based access. Software applications, particularly games, are often developed for a specific OS and require porting to run on other OSes. However, the cloud-based software distribution host described herein (also referred to as the cloud-based software distribution platform herein) may provide cloud-based access to games designed for a particular OS on a device running an otherwise incompatible OS for the games. For example, the platform may host a desktop game and allow a mobile device (or other device running an OS that is not supported by the game) to interact with an instance of the desktop game as if running on the mobile device. Similarly, the platform may host a mobile game and allow a desktop computer (or other device running an OS that is not supported by the game) to interact with an instance of the mobile game as if running on the desktop computer. Although the examples herein refer to games as well as OS incompatibility, in other examples the software applications may correspond to any software application that may not be supported or is otherwise incompatible with another computing device, including but not limited to OS, hardware, etc.

FIG. 4 illustrates an exemplary cloud-based software distribution platform 400. The platform 400 may include a host 406, a network 404 (which may correspond to network 304), and computing devices 402 and 403. Host 406, which may correspond to server 306, may include containers 440 and 442, which may respectively include a virtual machine 430 and a virtual machine 432.

In some embodiments, the term “virtualization environment” may refer to an isolated application environment that may virtualize at least some aspects of the application environment such that an application may interface with the virtualized aspects as if running on the application's native environment. Examples of virtualization environments include, without limitation, containers and virtual machines (“VM”). In some embodiments, the term “container” may refer to an isolated application environment that virtualizes at least an operating system (“OS”) of the base host machine by sharing a system or OS kernel with the host machine. For example, if the base host machine runs Windows (or other desktop OS), the container may also run Windows (or other desktop OS) by sharing the OS kernel such that the container may not require a complete set of OS binaries and libraries. In some embodiments, the term “virtual machine” may refer to an isolated application environment that virtualizes hardware as well as an OS. Because a VM may virtualize hardware, an OS for the VM may not be restricted by the base host machine OS. For example, even if the base host machine is running Windows (or another desktop OS), a VM on the base host machine may be configured to run Android (or other mobile OS) by emulating mobile device hardware. In other examples, other combinations of OSes may be used.

VM 430 may run an application 420 and VM 432 may run an application 422. Host 406 may utilize nested virtualization environments (e.g., VM 430 running in container 440 and VM 432 running in container 442) to more efficiently manage virtualization environments. For instance, as a number of VMs are initiated and/or closed the nested virtualization may facilitate management of virtualization environments for various types of VMs as well as more efficiently scale the number of VMs running concurrently. Certain aspects which may be global across certain VMs may be better managed via containers.

Computing device 402, which may correspond to an instance of computing device 302, may access application 420 via network 404. Computing device 403, which may correspond to another instance of computing device 302, may access application 422 via network 404. As shown in FIG. 4, because application 420 and application 422 are actually running on host 406, host 406 may maintain individual sessions (e.g., user session 222) for each of application 420 with computing device 402 and application 422 with computing device 403.

Although FIG. 4 illustrates a virtualization environment with one nested level (e.g., VM 430 running in container 440 or VM 432 running in container 442), in other embodiments, the virtualization environment may include additional levels of nesting. For example, application 420 may run in another VM or container running in VM 430. Moreover, although FIG. 4 illustrates a single VM per container, in other embodiments there may be more than one nested virtualization environment per base virtualization environment.

Returning to FIG. 1, the systems described herein may perform step 110 in a variety of ways. In one example, session module 204 may establish and manage user session 222 that may be between a client device (e.g., computing device 302, computing device 402 and/or computing device 403) and a host (e.g., server 306 and/or host 406) for running an application (e.g., application 420 and/or application 422, respectively). FIG. 5 illustrates another exemplary session.

FIG. 5 illustrates an example timeline of a session 500. FIG. 5 may include a host 506 (which may correspond to server 306 and/or host 406), an application 520 (which may correspond to application 420 and/or application 422), a user session 522 (which may correspond to user session 222), a session state buffer 528 (which may correspond to session state buffer 228), and a user session state 524 (which may correspond to user session state 224).

For example, at time t0, session module 204, as part of host 506, may establish user session 522 for application 520 for a client device (not depicted). The client device may connect to host 506 to initiate user session 522 for using application 520. User session 522 may include state data for the user's activity using application 520. For example, if application 520 corresponds to a video game, user session 522 may correspond to a current state of the user's progress in the video game.

At time t1, host 506 may detect a pause in user session 522. The user may have minimized application 520. For example, the user may have actively minimized application 520 or passively minimized application 520 (e.g., the user may have shut off his or her device, the user may have timed out, another application or program may have minimized application 520, and/or the user may have otherwise performed an action causing application 520 to minimize, etc.). Accordingly, host 506 may receive a message from the client device that indicates that user session 522 should be paused. In other examples, host 506 may detect that the client device disconnected from host 506. For example, the client device may have timed out or its network connection may be intentionally or unintentionally be disconnected. Host 506 may determine that the client device has not responded to communications for an idle time threshold. Thus, at time t1 as illustrated in FIG. 5, user session 522 may no longer be active for application 520.

Turning back to FIG. 1, at step 120 one or more of the systems described herein may, in response to the detection, save a user session state of the user session. The user session state may include a memory state of the application corresponding to a user's activity during the user session. For example, state module 206 may save user session state 224 that may include a memory state of the application for user session 222 at the time the pause is detected.

In some embodiments, the term “session state” may refer to a data representation of a user session which may facilitate maintaining the user session. A session state may allow restoring a user session by preserving a memory state (e.g., relevant data and/or code stored in volatile and/or non-volatile memory used during current execution of the application) of the user session. Examples of session states include, without limitation, a memory state stored as a backup image, virtual image, or other replica of the memory state, a buffer dump of the current memory state, the memory state stored in a particular format, etc.

A session state may include current configurations of the application such that restoring the user session with the session state may include restoring a match or near-match to the user's experience with the application when the user session was paused. Some applications, such as video games, file editing software, etc., may allow the user to save a file (e.g., saving the user's progress in the video game, saving the user's edits to a file, etc.). Saving the file may allow the user to start a new session with the application and load the saved progress. The user may experience a new session, (e.g., having the application reinitialized) having some of the user's progress restored (e.g., by loading the user's saved file). However, restoring a session using a saved session state may allow the user to more closely resume the experience when the session was paused. For example, the session state may preserve temporary application states (e.g., cursor location, selections or other configurations made, etc.) as well as other unsaved progress. For example, if the user is playing a video game, the user may experience, for a new session, reinitializing the game and loading the user's saved game progress. However, if the user is reconnecting and restoring the user's previous session, the user may experience picking back up the game at the moment the session was paused as if the session were not interrupted.

The systems described herein may perform step 120 in a variety of ways. In one example, as illustrated in FIG. 5, at time t1 user session 522 may be stored as user session state 524. Host 506, after detecting the pause in user session 522, may store user session 522 as user session state 524, for instance by performing a memory dump of user session 522, formatting data needed for restoring user session 522, etc.

At step 130 one or more of the systems described herein may determine, based on one or more session characteristics relating to the user session, a session preservation time for preserving the user session state. The session preservation time may correspond to a predicted time for keeping the user session alive. For example, preservation module 208 may determine session preservation time 226 for preserving user session state 224.

In some embodiments, the term “session preservation time” may refer to a time for retaining a session state, which may further correspond to a time for keeping a corresponding user session alive. The session preservation time may correspond to a minimum time or floor for keeping the user session alive. In other words, after the session preservation time elapses, the corresponding session may not be guaranteed to be recoverable. After the session preservation time elapses, the corresponding session state may be deleted to free up resources (e.g., free up storage and/or memory for holding other session states).

The systems described herein may perform step 130 in a variety of ways. In one example, preservation module 208 may analyze various signals to predict how long to preserve user session 222. Session preservation time 226 may correspond to a predicted minimum time for storing user session state 224 such that user session state 224 may be available to restore user session 222 when the user reconnects without requiring indefinite storage of user session state 224.

For example, as illustrated in FIG. 5, the user (e.g., user's client device) may reconnect to host 506 at time t1 to resume user session 522 after pausing user session 522 at time t1. If user session state 524 is stored indefinitely, the user may resume user session 522 at any t2 after t1. However, because storing user session state 524 indefinitely may not be feasible, user session 522 may only be restored at a time t2 prior to deleting user session state 524. A corresponding session preservation time (e.g., session preservation time 226) may ensure that for a time t2 in which the session preservation time is greater than t2−t1, user session state 524 may be preserved and user session 522 may be restored. Thus, preservation module 208 may analyze various signals to predict an expected t2 for the user to reconnect to the session and accordingly determine a corresponding session preservation time 226.

In some examples, preservation module 208 may analyze session characteristics including an application characteristic of the application, a popularity of the application, or a return rate of users of the application. Certain types of applications may exhibit certain session behaviors. For example, entertainment applications (e.g., video games, social media applications, etc.) may exhibit short sessions with frequent pauses in sessions, and short time periods for resuming sessions. Entertainment applications may be associated with shorter session preservation times, which may further correspond to faster return rates of users. Productivity applications (e.g., office applications, specialized software for jobs, etc.), may exhibit longer sessions with less frequent pauses in sessions, and longer time periods for resuming sessions. Productivity applications may be associated with longer session preservation times, which may also correspond to slower return rates for users. Other characteristics of the application may be factored into the session preservation time. For instance, a popular application may exhibit a high turnover rate for sessions, which may be associated with shorter session preservation times to account for the high turnover. Resource requirements for the application may also factor into the session preservation time. For example, an application requiring large session states may be associated with shorter session preservation times compared to an application with small session states, in order to utilize limited resources more efficiently.

In other examples, preservation module 208 may analyze session characteristics including an application usage pattern of a user, or a return rate of the user. The user himself or herself may exhibit particular session behavior as may be determined from the user's history. For example, a given user may be inclined to use a given application at certain times of the day such that session preservation time 226 may account for the user's usage pattern. Session preservation time 226 may be longer when overlapping the expected use time (e.g., due to a higher probability of the user reconnecting to the session) and/or may be shorter otherwise. In another example, a given user's application usage pattern may indicate that the user tends to return quickly to sessions (which may correspond to shorter times for session preservation time 226) or may tend to return slowly to sessions (which may correspond to longer times for session preservation time 226). In some examples, the user may indicate, either via settings or at the time of pausing user session 222, whether the user expects and/or intends to return to user session 222 after a different than normal relative time (e.g., faster than average for the user and/or class of users, slower than average) and/or absolute time (e.g., indicating a specific expected return time such as within 1 hour or at a time such as 7:00 PM). In some examples, preservation module 208 may use an average reconnection time (e.g., average time for the user to reconnect to a given session) for determining session preservation time 226. For example, the average reconnection time may be used as a basis for session preservation time 226 that may be further modified based on the factors described herein.

Preservation module 208 may further consider additional factors and use various analysis schemes, such as statistical analysis, machine learning, etc., to balance optimal usage of available storage for session states with minimizing dropped sessions for users. In some examples, preservation module 208 may dynamically update session preservation time 226 based on success rates (e.g., session reconnects before deleting corresponding session states) of prior session preservation times.

At step 140 one or more of the systems described herein may store the saved user session state in a session state buffer for at least the determined session preservation time. For example, buffer module 210 (and/or preservation module 208) may store user session state 224 in session state buffer 228 for at least a time indicated by session preservation time 226.

Session state buffer 228 may correspond to any data structure implemented with any storage and/or memory device as described herein. For example, session state buffer 228 may be a queue, stack, heap, vector, array, series of registers, etc. FIG. 6 illustrates a session state buffer 628 which may correspond to session state buffer 228 and/or session state buffer 528. Session state buffer 628 is illustrated in FIG. 6 as an array, although in other examples session state buffer 628 may correspond to any other suitable data structure.

As illustrated in FIG. 6, session state buffer 628 may be associated with multiple user session states such as a user session state 624A, a user session state 624B, a user session state 624C, a user session state 624D, a user session state 624E, and a user session state 624N, each of which may correspond to different iterations of user session state 224 and/or user session state 524. Session state buffer 628 may be restricted in a number of user session states that session state buffer 628 may store.

Buffer module 210 may store user session states (e.g., at least user session states 624A, 624B, 624D, 624E) with corresponding session preservation times for each state. Buffer module 210 may store the corresponding session preservation times with each state (e.g., as a flag, bit, metadata, or other status indicator). Alternatively or in addition, buffer module 210 may maintain a lookup table or similar data structure for correlating session preservation times with session states.

As will be described further below, buffer module 210 may periodically and/or automatically flush stale entries (e.g., user session states having elapsed or expired session preservation times) from session state buffer 628. However, when adding a new user session state (e.g., user session state 624N) to session state buffer 628 when full, buffer module 210 may select one of the stored user session states for flushing. Buffer module 210 may select a candidate user session state for flushing based on, for example, a time to expire (e.g., a user session state having a session preservation time that is close to or already lapsed may be more likely to be selected), a time in buffer (e.g., a user session state having been stored in session state buffer 628 longer than other user session states may be more likely to be selected), and/or other factors to determine which user session state may be flushed with a least impact to overall user experiences (e.g., a user session unlikely or least likely to be reconnected). As illustrated in FIG. 6, buffer module 210 have selected and flushed user session state 624C to provide space for storing user session state 624N. In other examples, as will be discussed further below, user session state 624C may be flushed in other circumstances.

Returning to method 100, the systems described herein may perform step 140 in a variety of ways. In one example, as illustrated in FIG. 5, at time t1 buffer module 210 may store user session state 524 in session state buffer 528. At time t1, application 520 may no longer be active with user session 522 and instead the user session may be preserved as user session state 524 in session state buffer 528.

In some examples, session module 204 may detect, before session preservation time 226 elapses, a reconnection of user session 222. For example, in FIG. 5, time t2 may correspond to a time before the session preservation time for user session state 524 expires such that user session state 524 may be available for restoring user session 522 at time t2. Session module 204 may then load user session state 524 from session state buffer 528 to restore user session 522 and remove user session state 524 from session state buffer 528 (e.g., removing user session state 624C in FIG. 6). Restoring user session 522 may include restoring an application state for application 520 similar to that at time t1, which may include restoring data in volatile and/or non-volatile memory using data stored in user session state 524. The user may experience user session 522 as if there was little or no interruption to user session 522.

In some examples, session module 204 may track a reconnection time of user session 522. An average reconnection time for the user may be updated based on this reconnection time such that preservation module 208 may use the updated average reconnection time for determining session preservation times.

As described herein, successfully predicting a session preservation time may reduce a likelihood that a user will not be able to reconnect to a paused session. Thus, at time t2 in FIG. 5, user session 522 may be restored. However, if the corresponding session preservation time is too short, then at time t2, user session state 524 may have already been flushed such that user session 522 may not be restorable. In some examples, preservation module 208 may track successful and/or unsuccessful session preservation times along with a delta between the session preservation time and the actual reconnect time to improve predictions of session preservation times.

Turning back to FIG. 1, at step 150 one or more of the systems described herein may remove the user session state from the session state buffer after the session preservation time elapses. For example, buffer module 210 may remove user session state 224 from session state buffer 228 after session preservation time 226 elapses.

The systems described herein may perform step 150 in a variety of ways. In one example, buffer module 210 may automatically and/or periodically check whether each user session state in session state buffer 228 is valid or have elapsed. In some examples, preservation module 208 may dynamically update session preservation time 226 such that buffer module 210 may require active management and flushing of stale entries. In other examples, buffer module 210 may be given instructions to flush a particular entry. For example, the user may indicate that the user does not intend to reconnect to a session such that buffer module 210 may be instructed to flush the corresponding user session state. In another example, the user's account may be terminated or otherwise suspended such that all of the user's session states may be flushed. In yet another example, the corresponding application may have changed (e.g., updated, modified, deleted, etc.), such that related user session states may no longer be data compliant with the application and therefore may be flushed.

By identifying and flushing stale entries, buffer module 210 may maintain session state buffer 228 such that new entries may be added. For example, in FIG. 6, flushing user session state 624C from session state buffer 628 may allow storing user session state 624N.

As referenced above, the systems and methods described herein are directed to dynamic resource allocation for managing user session states. A cloud application platform may provide a user with virtualized access to an application. On a client device, the user may normally expect to be able to pause a current application session and later seamlessly return to the session. However, providing such an experience via a server hosting a virtualized application may be prohibitively resource (e.g., memory) intensive. For example, keeping a user session alive may require saving the user's session state, which may be a waste of resources if the user does not intend to reconnect to the same session. The systems and methods described herein may determine which user sessions to keep alive and which user sessions to close in order to free up resources. The systems and methods described herein may use various signals, such as aspects relating to the application and aspects relating to the user, to determine how long to preserve each session.

Example Embodiments

Example 1: A computer-implemented method comprising: (i) detecting, by a cloud-based software distribution host providing cloud-based access to an application to a client device, a pause in a user session of the application; (ii) in response to the detection, saving a user session state of the user session, wherein the user session state includes a memory state of the application corresponding to a user's activity during the user session; (iii) determining, based on one or more session characteristics relating to the user session, a session preservation time for preserving the user session state, wherein the session preservation time corresponds to a predicted time for keeping the user session alive; (iv) storing the saved user session state in a session state buffer for at least the determined session preservation time; and (v) removing the user session state from the session state buffer after the session preservation time elapses.

Example 2: The method of Example 1, further comprising: detecting, before the session preservation time elapses, a reconnection of the user session; and loading the user session state from the session state buffer to restore the user session.

Example 3: The method of Example 2, further comprising tracking a reconnection time of the user session, wherein the one or more session characteristics includes an average reconnection time for the user and the session preservation time is further based on the average reconnection time.

Example 4: The method of Examples 1, 2, or 3, wherein the one or more session characteristics includes at least one of an application characteristic of the application, a popularity of the application, or a return rate of users of the application.

Example 5: The method of any of Examples 1-4, wherein the one or more session characteristics includes at least one of an application usage pattern of a user, or a return rate of the user.

Example 6: The method of any of Examples 1-5, wherein the pause corresponds to at least one of the client device disconnecting from the cloud-based software distribution host, or the user minimizing the application.

Example 7: The method of any of Examples 1-6, wherein the application comprises a video game and the user session state corresponds to a progress of the user in the video game.

Example 8: A system comprising: at least one physical processor; physical memory comprising computer-executable instructions that, when executed by the physical processor, cause the physical processor to: (i) detect, by a cloud-based software distribution host providing cloud-based access to an application to a client device, a pause in a user session of the application; (ii) in response to the detection, save a user session state of the user session, wherein the user session state includes a memory state of the application corresponding to a user's activity during the user session; (iii) determine, based on one or more session characteristics relating to the user session, a session preservation time for preserving the user session state, wherein the session preservation time corresponds to a predicted time for keeping the user session alive; (iv) store the saved user session state in a session state buffer for at least the determined session preservation time; and (v) remove the user session state from the session state buffer after the session preservation time elapses.

Example 9: The system of Example 8, wherein the instructions further comprise instructions for: detecting, before the session preservation time elapses, a reconnection of the user session; and loading the user session state from the session state buffer to restore the user session.

Example 10: The system of Example 9, wherein the instructions further comprise instructions for tracking a reconnection time of the user session, wherein the one or more session characteristics includes an average reconnection time for the user and the session preservation time is further based on the average reconnection time.

Example 11: The system of Example 8, 9, or 10, wherein the one or more session characteristics includes at least one of an application characteristic of the application, a popularity of the application, or a return rate of users of the application.

Example 12: The system of any of Examples 8-11, wherein the one or more session characteristics includes at least one of an application usage pattern of a user, or a return rate of the user.

Example 13: The system of any of Examples 8-12, wherein the pause corresponds to at least one of the client device disconnecting from the cloud-based software distribution host, or the user minimizing the application.

Example 14: A non-transitory computer-readable medium comprising one or more computer-executable instructions that, when executed by at least one processor of a computing device, cause the computing device to: (i) detect, by a cloud-based software distribution host providing cloud-based access to an application to a client device, a pause in a user session of the application; (ii) in response to the detection, save a user session state of the user session, wherein the user session state includes a memory state of the application corresponding to a user's activity during the user session; (iii) determine, based on one or more session characteristics relating to the user session, a session preservation time for preserving the user session state, wherein the session preservation time corresponds to a predicted time for keeping the user session alive; (iv) store the saved user session state in a session state buffer for at least the determined session preservation time; and (v) remove the user session state from the session state buffer after the session preservation time elapses.

Example 15: The non-transitory computer-readable medium of Example 14, wherein the instructions further comprise instructions for: detecting, before the session preservation time elapses, a reconnection of the user session; and loading the user session state from the session state buffer to restore the user session.

Example 16: The non-transitory computer-readable medium of Example 15, wherein the instructions further comprise instructions for tracking a reconnection time of the user session, wherein the one or more session characteristics includes an average reconnection time for the user and the session preservation time is further based on the average reconnection time.

Example 17: The non-transitory computer-readable medium of Example 14, 15, or 16, wherein the one or more session characteristics includes at least one of an application characteristic of the application, a popularity of the application, or a return rate of users of the application.

Example 18: The non-transitory computer-readable medium of any of Examples 14-17, wherein the one or more session characteristics includes at least one of an application usage pattern of a user, or a return rate of the user.

Example 19: The non-transitory computer-readable medium of any of Examples 14-18, wherein the pause corresponds to at least one of the client device disconnecting from the cloud-based software distribution host, or the user minimizing the application.

Example 20: The non-transitory computer-readable medium of any of Examples 14-19, wherein the application comprises a video game and the user session state corresponds to a progress of the user in the video game.

As detailed above, the computing devices and systems described and/or illustrated herein broadly represent any type or form of computing device or system capable of executing computer-readable instructions, such as those contained within the modules described herein. In their most basic configuration, these computing device(s) may each include at least one memory device and at least one physical processor.

In some examples, the term “memory device” generally refers to any type or form of volatile or non-volatile storage device or medium capable of storing data and/or computer-readable instructions. In one example, a memory device may store, load, and/or maintain one or more of the modules described herein. Examples of memory devices include, without limitation, Random Access Memory (RAM), Read Only Memory (ROM), flash memory, Hard Disk Drives (HDDs), Solid-State Drives (SSDs), optical disk drives, caches, variations or combinations of one or more of the same, or any other suitable storage memory.

In some examples, the term “physical processor” generally refers to any type or form of hardware-implemented processing unit capable of interpreting and/or executing computer-readable instructions. In one example, a physical processor may access and/or modify one or more modules stored in the above-described memory device. Examples of physical processors include, without limitation, microprocessors, microcontrollers, Central Processing Units (CPUs), Field-Programmable Gate Arrays (FPGAs) that implement softcore processors, Application-Specific Integrated Circuits (ASICs), portions of one or more of the same, variations or combinations of one or more of the same, or any other suitable physical processor.

Although illustrated as separate elements, the modules described and/or illustrated herein may represent portions of a single module or application. In addition, in certain embodiments one or more of these modules may represent one or more software applications or programs that, when executed by a computing device, may cause the computing device to perform one or more tasks. For example, one or more of the modules described and/or illustrated herein may represent modules stored and configured to run on one or more of the computing devices or systems described and/or illustrated herein. One or more of these modules may also represent all or portions of one or more special-purpose computers configured to perform one or more tasks.

In addition, one or more of the modules described herein may transform data, physical devices, and/or representations of physical devices from one form to another. For example, one or more of the modules recited herein may receive session data to be transformed, transform the session data, output a result of the transformation to manage session data, use the result of the transformation to maintain the session data, and store the result of the transformation to store the session data. Additionally or alternatively, one or more of the modules recited herein may transform a processor, volatile memory, non-volatile memory, and/or any other portion of a physical computing device from one form to another by executing on the computing device, storing data on the computing device, and/or otherwise interacting with the computing device.

In some embodiments, the term “computer-readable medium” generally refers to any form of device, carrier, or medium capable of storing or carrying computer-readable instructions. Examples of computer-readable media include, without limitation, transmission-type media, such as carrier waves, and non-transitory-type media, such as magnetic-storage media (e.g., hard disk drives, tape drives, and floppy disks), optical-storage media (e.g., Compact Disks (CDs), Digital Video Disks (DVDs), and BLU-RAY disks), electronic-storage media (e.g., solid-state drives and flash media), and other distribution systems.

The process parameters and sequence of the steps described and/or illustrated herein are given by way of example only and can be varied as desired. For example, while the steps illustrated and/or described herein may be shown or discussed in a particular order, these steps do not necessarily need to be performed in the order illustrated or discussed. The various exemplary methods described and/or illustrated herein may also omit one or more of the steps described or illustrated herein or include additional steps in addition to those disclosed.

The preceding description has been provided to enable others skilled in the art to best utilize various aspects of the exemplary embodiments disclosed herein. This exemplary description is not intended to be exhaustive or to be limited to any precise form disclosed. Many modifications and variations are possible without departing from the spirit and scope of the present disclosure. The embodiments disclosed herein should be considered in all respects illustrative and not restrictive. Reference should be made to the appended claims and their equivalents in determining the scope of the present disclosure.

Unless otherwise noted, the terms “connected to” and “coupled to” (and their derivatives), as used in the specification and claims, are to be construed as permitting both direct and indirect (i.e., via other elements or components) connection. In addition, the terms “a” or “an,” as used in the specification and claims, are to be construed as meaning “at least one of.” Finally, for ease of use, the terms “including” and “having” (and their derivatives), as used in the specification and claims, are interchangeable with and have the same meaning as the word “comprising.”

Claims

1. A computer-implemented method comprising:

detecting, by a cloud-based software distribution host providing cloud-based access to an application to a client device, a pause in a user session of the application;

in response to the detection, saving a user session state of the user session, wherein the user session state includes a memory state of the application corresponding to a user's activity during the user session;

determining, based on one or more session characteristics relating to the user session, a session preservation time for preserving the user session state, wherein the session preservation time corresponds to a predicted time for keeping the user session alive;

storing the saved user session state in a session state buffer for at least the determined session preservation time; and

removing the user session state from the session state buffer after the session preservation time elapses.

2. The method of claim 1, further comprising:

detecting, before the session preservation time elapses, a reconnection of the user session; and

loading the user session state from the session state buffer to restore the user session.

3. The method of claim 2, further comprising tracking a reconnection time of the user session, wherein the one or more session characteristics includes an average reconnection time for the user and the session preservation time is further based on the average reconnection time.

4. The method of claim 1, wherein the one or more session characteristics includes at least one of an application characteristic of the application, a popularity of the application, or a return rate of users of the application.

5. The method of claim 1, wherein the one or more session characteristics includes at least one of an application usage pattern of a user or a return rate of the user.

6. The method of claim 1, wherein the pause corresponds to at least one of the client device disconnecting from the cloud-based software distribution host or the user minimizing the application.

7. The method of claim 1, wherein the application comprises a video game and the user session state corresponds to a progress of the user in the video game.

8. A system comprising:

at least one physical processor; and

physical memory comprising computer-executable instructions that, when executed by the physical processor, cause the physical processor to: detect, by a cloud-based software distribution host providing cloud-based access to an application to a client device, a pause in a user session of the application; in response to the detection, save a user session state of the user session, wherein the user session state includes a memory state of the application corresponding to a user's activity during the user session; determine, based on one or more session characteristics relating to the user session, a session preservation time for preserving the user session state, wherein the session preservation time corresponds to a predicted time for keeping the user session alive; store the saved user session state in a session state buffer for at least the determined session preservation time; and remove the user session state from the session state buffer after the session preservation time elapses.

9. The system of claim 8, wherein the instructions further comprise instructions for:

detecting, before the session preservation time elapses, a reconnection of the user session; and

loading the user session state from the session state buffer to restore the user session.

10. The system of claim 9, wherein the instructions further comprise instructions for tracking a reconnection time of the user session, wherein the one or more session characteristics includes an average reconnection time for the user and the session preservation time is further based on the average reconnection time.

11. The system of claim 8, wherein the one or more session characteristics includes at least one of an application characteristic of the application, a popularity of the application, or a return rate of users of the application.

12. The system of claim 8, wherein the one or more session characteristics includes at least one of an application usage pattern of a user, or a return rate of the user.

13. The system of claim 8, wherein the pause corresponds to at least one of the client device disconnecting from the cloud-based software distribution host, or the user minimizing the application.

14. A non-transitory computer-readable medium comprising one or more computer-executable instructions that, when executed by at least one processor of a computing device, cause the computing device to:

detect, by a cloud-based software distribution host providing cloud-based access to an application to a client device, a pause in a user session of the application;

in response to the detection, save a user session state of the user session, wherein the user session state includes a memory state of the application corresponding to a user's activity during the user session;

determine, based on one or more session characteristics relating to the user session, a session preservation time for preserving the user session state, wherein the session preservation time corresponds to a predicted time for keeping the user session alive;

store the saved user session state in a session state buffer for at least the determined session preservation time; and

remove the user session state from the session state buffer after the session preservation time elapses.

15. The non-transitory computer-readable medium of claim 14, wherein the instructions further comprise instructions for:

detecting, before the session preservation time elapses, a reconnection of the user session; and

loading the user session state from the session state buffer to restore the user session.

16. The non-transitory computer-readable medium of claim 15, wherein the instructions further comprise instructions for tracking a reconnection time of the user session, wherein the one or more session characteristics includes an average reconnection time for the user and the session preservation time is further based on the average reconnection time.

17. The non-transitory computer-readable medium of claim 14, wherein the one or more session characteristics includes at least one of an application characteristic of the application, a popularity of the application, or a return rate of users of the application.

18. The non-transitory computer-readable medium of claim 14, wherein the one or more session characteristics includes at least one of an application usage pattern of a user, or a return rate of the user.

19. The non-transitory computer-readable medium of claim 14, wherein the pause corresponds to at least one of the client device disconnecting from the cloud-based software distribution host, or the user minimizing the application.

20. The non-transitory computer-readable medium of claim 14, wherein the application comprises a video game and the user session state corresponds to a progress of the user in the video game.