Remote Session Prelaunch Using Placeholder Files and Triggers
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional methods for prelaunching remote computing sessions are inefficient, cumbersome, and resource-intensive, often requiring the client application to remain in the foreground, impacting user experience and increasing battery usage, and may necessitate costly server farms for large organizations, with peak times exacerbating wait times.
Innovation Solution
A method for prelaunching remote computing sessions using a placeholder session file and a launch service application, allowing the session to be initiated based on trigger conditions such as proximity or elapsed time, without requiring the client application to remain in the foreground, and utilizing cloud resources for efficient workload distribution.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the client application remains in the foreground during prelaunch, then the prelaunch sequence can be initiated, but battery usage increases and user experience deteriorates
Solution Approach 1:
The patent introduces a background service as an intermediary component that handles the prelaunch operations without requiring the client application to remain in the foreground. This background service acts as a mediator between the user's prelaunch request and the remote computing session initialization, allowing the process to continue in the background while consuming minimal battery resources.
Solution Approach 2:
The system performs preliminary actions by initiating the prelaunch sequence in advance before the user actually needs to connect to the remote session. The background service can start authentication, resource allocation, and session preparation processes ahead of time, so that when the user needs to access the remote computing environment, everything is already ready or nearly ready, reducing actual wait time while avoiding continuous foreground presence.
2Reliability
If the client application remains active during prelaunch, then the session can be prelaunched, but the device must remain open and online, increasing inconvenience
Solution Approach 1:
The background service implements self-service capabilities by autonomously managing the entire prelaunch process without requiring continuous user interaction or device presence. Once triggered, the service can proceed with authentication, resource allocation, and session preparation in the background, automatically completing tasks without needing the client application to remain active or the device to stay online throughout the process.
Solution Approach 2:
A background service acts as an intermediary that decouples the prelaunch initiation from the actual session connection. This mediator can continue operations even when the client application is closed or the device goes offline, bridging the gap between user request and session establishment without requiring continuous device availability.
3Adaptability or versatility
If a dedicated server is used to run virtual desktop client application for prelaunch, then prelaunch can be triggered on demand, but scaling becomes problematic requiring server farms
Solution Approach 1:
Instead of requiring a dedicated physical server for each organization, the patent implements virtualization techniques that create virtual instances of the prelaunch service. These virtual copies can be distributed across existing infrastructure, allowing multiple organizations or departments to share the same physical server resources while maintaining isolated, on-demand prelaunch capabilities for each.
Solution Approach 2:
The prelaunch service is designed with universal functionality that can serve multiple purposes and multiple users simultaneously. A single server instance can handle prelaunch requests from different users, devices, and even organizations by dynamically allocating resources and managing multiple virtual desktop sessions, eliminating the need for separate dedicated servers for each user or department.
4Productivity
If virtualization system scales up to meet peak demand, then more users can be served, but prelaunch time increases during peak times
Solution Approach 1:
The system performs preliminary scaling and resource allocation in advance of peak demand periods. By monitoring usage patterns and anticipating peak times, the virtualization system can proactively provision additional resources and pre-position computing capacity before demand surges, rather than scaling reactively when users actually need access during peak times.
Solution Approach 2:
The background service maintains continuous operation and resource allocation readiness throughout off-peak periods, keeping virtual desktop environments pre-configured and resources pre-allocated. This continuous preparation ensures that when peak demand arrives, the system is already at full capacity and can immediately serve multiple users without experiencing scaling delays or increased wait times.
Data Source
AI summary
Methods and systems for a remote computing session prelaunch are described. A computing system may receive, from a computing device, a request to prelaunch a remote computing session. The computing system may receive a placeholder session file for the remote computing session. The computing system may initiate, using a launch service application hosted by the computing system, a prelaunch session. The prelaunch session may exist between internal components of the computing system but may represent a remote computing session between the computing system and a client device. The computing system may disconnect the prelaunch session until a trigger condition for establishing the remote computing session is identified. The computing system may establish, for a client device, the remote computing session based on the prelaunch session.