Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made
Claims 1-6, 8, and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Madishetti et al. (US 2023/0266979, Madishetti) in view of Schultz et al. (US 2022/0224684, hereinafter Schultz).
Regarding claim 1, Madishetti discloses
A computerized system comprising:
one or more computer processors; and
computer memory storing computer-useable instructions that, when used by the one or more computer processors, cause the one or more computer processors to perform operations, the operations comprising (Fig. 12, 13):
receiving a request to launch a remote client, the request associated with a local client (paragraph [0104]: a user of the remote display device 520 first explicitly requests connection (810). This request is received by the client 210. This request is received by the client 210 and reported to the compute resource optimization service 260 (812). The compute resource optimization service 260 directs the Cloud virtual infrastructure provider 530 to resume (814). The Cloud virtual infrastructure provider 530 then resumes the virtual desktop 222 (516));
determining whether the local client is associated with a connected state, an express connection state, or a disconnected state (paragraph [0089]: Another capability is to quickly resume, or reallocate compute resources that were previously paused, restoring the exact memory and processor state of the virtual machine; paragraph [0100]: FIG. 6 is a virtual desktop state diagram of the compute resource optimization service 260 that includes a paused state 610, a pausing state 614, a resuming state 616, a disconnected state 618, and a connected state 620), and
based on determining that the local client is associated with the express connection state, establishing a remote client session between the remote client and the local client based on the express connection state (paragraph [0104]: The compute resource optimization service 260 directs the Cloud virtual infrastructure provider 530 to resume (814). The Cloud virtual infrastructure provider 530 then resumes the virtual desktop 222 (516); paragraph [0110]: If the virtual desktop 222 is in a paused state, the client 210 ignores the reactivation, as a connection still exists and a user may access the virtual desktop 222 through the client 210).
Madishetti does not disclose wherein the express connection state is identified from the following: a pre-connect connection state or a cloned network context state. Schultz discloses wherein the express connection state is identified from the following: a pre-connect connection state or a cloned network context state (paragraph [0006]: sessions and tunnels for communications may be quickly re-established using tokens without user intervention in accordance with various protocols, such as the Multipath-TCP (RFC6824) under which a network identifier may be used to associate multiple paths to a single connection; paragraph [0090]: The session information may be stored on the database 560 with a session state that the associated session 570 is active; paragraph [0099]: the token 590′ may have been stored and maintained on the database 560 with an indication as to whether the previous token 590′ was validated. In determining, the token validator 550 may access the database 560 to identify the indication of validation for the previous token 590′ associated with the initiator 505; paragraph [0100]: The identified session state may at least include that of the session associated with the previous token 590′. If any of the session states of the other session is indicated as active, the token validator 550 may permit or allow the current session 570 for communications; Note: Schultz teaches that sessions and tunnels for communications may be quickly re-established using tokens without user intervention, and that stored session information and token validation may be used to permit communications based on prior session activity. Schultz further teaches associating multiple paths to a single connection using a network identifier). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Madishetti’s remote desktop state-management and reconnect framework to incorporate Schultz’s token-based quick re-establishment of sessions and network-identifier-based association of multiple paths to a single connection, in order to reduce reconnection latency and enable faster re-establishment of remote desktop sessions without user intervention (Schultz paragraph [0006]).
Regarding claim 2, Madishetti discloses
wherein establishing the remote client session comprises: communicating a request to complete a remote logon process; and activating a local client interface for the remote client (paragraph [0104]: a user of the remote display device 520 first explicitly requests connection (810). This request is received by the client 210. This request is received by the client 210 and reported to the compute resource optimization service 260 (812). The compute resource optimization service 260 directs the Cloud virtual infrastructure provider 530 to resume (814). The Cloud virtual infrastructure provider 530 then resumes the virtual desktop 222 (516)).
Regarding claim 3, Madishetti discloses
the operations further comprising: determining that the local client is associated with the connected state; and activating the local client interface for the remote client without communicating (paragraph [0100]: The connected state 620 is a state that represents that the client has a remote display protocol session with the virtual desktop, and application scenarios are able to be used interactively. The connected state 620 implies that the virtual desktop is running normally).
Regarding claim 4, Madishetti discloses
the operations further comprising: determining that the local client is associated with a disconnected state; communicating a request for a new connection for establishing the remote client session; communicating a request to complete a remote logon process; and activating a local client interface for the remote client (paragraph [0100]: The connected state 620 is a state that represents that the client has a remote display protocol session with the virtual desktop, and application scenarios are able to be used interactively. The connected state 620 implies that the virtual desktop is running normally; paragraph [0109]: If the virtual desktop 222 is simply in the disconnected state, the client will automatically attempt to reconnect; paragraph [0110]: If the virtual desktop 222 is disconnected, the client 210 performs a simple reconnection (1014)).
Regarding claim 5, Madishetti does not disclose wherein the pre-connect connected state is associated with a pre-connect connection of the local client, the pre-connect connection is an active lightweight connection that enables an express connection between the local client and the remote client. Schultz discloses wherein the pre-connect connected state is associated with a pre-connect connection of the local client, the pre-connect connection is an active lightweight connection that enables an express connection between the local client and the remote client (paragraph [0006]: sessions and tunnels for communications may be quickly re-established using tokens without user intervention in accordance with various protocols, such as the Multipath-TCP (RFC6824) under which a network identifier may be used to associate multiple paths to a single connection; paragraph [0090]: The session information may be stored on the database 560 with a session state that the associated session 570 is active; paragraph [0099]: the token 590′ may have been stored and maintained on the database 560 with an indication as to whether the previous token 590′ was validated. In determining, the token validator 550 may access the database 560 to identify the indication of validation for the previous token 590′ associated with the initiator 505; paragraph [0100]: The identified session state may at least include that of the session associated with the previous token 590′. If any of the session states of the other session is indicated as active, the token validator 550 may permit or allow the current session 570 for communications; Note: Schultz teaches that sessions and tunnels for communications may be quickly re-established using tokens without user intervention, and that stored session information and token validation may be used to permit communications based on prior session activity. Schultz further teaches associating multiple paths to a single connection using a network identifier). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Madishetti’s remote desktop state-management and reconnect framework to incorporate Schultz’s token-based quick re-establishment of sessions and network-identifier-based association of multiple paths to a single connection, in order to reduce reconnection latency and enable faster re-establishment of remote desktop sessions without user intervention (Schultz paragraph [0006]).
Regarding claim 6, Madishetti does not disclose wherein the cloned network context state is associated with the local client of a user when a second local client of the user is connected to an existing remote client session, wherein a cloned network context from the second local client enables an express connection between the local client and the remote client. Schultz discloses wherein the cloned network context state is associated with the local client of a user when a second local client of the user is connected to an existing remote client session, wherein a cloned network context from the second local client enables an express connection between the local client and the remote client (paragraph [0006]: sessions and tunnels for communications may be quickly re-established using tokens without user intervention in accordance with various protocols, such as the Multipath-TCP (RFC6824) under which a network identifier may be used to associate multiple paths to a single connection; paragraph [0015]: the first device may validate a second session token identified from an initiation of a second session between the first device and a third device via a second network path based at least on a property of the second network path. In some embodiments, the first device may provide, responsive to validating the second session token, the second session token to the first device and the third device for use in communications over a third network path between the second device and the third device; paragraph [0090]: The session information may be stored on the database 560 with a session state that the associated session 570 is active; paragraph [0099]: the token 590′ may have been stored and maintained on the database 560 with an indication as to whether the previous token 590′ was validated. In determining, the token validator 550 may access the database 560 to identify the indication of validation for the previous token 590′ associated with the initiator 505; paragraph [0100]: The identified session state may at least include that of the session associated with the previous token 590′. If any of the session states of the other session is indicated as active, the token validator 550 may permit or allow the current session 570 for communications; Note 1: Schultz’s teaching of utilizing a validated session token from a connection involving a third device to establish communications for a second device corresponds to the claimed cloned network context from a second local client enabling an express connection; Note 2: While Schultz does not explicitly state that the first and second devices belong to the same user, it would have been obvious to a person of ordinary skill in the art that multiple devices sharing a session token and maintaining multiple paths to a single connection would be associated with the same user (e.g., a single user accessing a remote workspace simultaneously from both a laptop and a mobile device). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Madishetti’s remote desktop state-management framework to incorporate Schultz’s token-based sharing of session context across multiple devices to support simultaneous active connections to the remote client session across multiple devices and network paths, in order to reduce reconnection latency and enable faster re-establishment of remote desktop sessions without user intervention (Schultz paragraph [0006]).
Regarding claim 8, Madishetti does not disclose wherein the remote client session is used to connect a second local client associated with a user of the local client, wherein the local client and the second local client are simultaneous active connections to the remote client session. Schultz discloses wherein the remote client session is used to connect a second local client associated with a user of the local client, wherein the local client and the second local client are simultaneous active connections to the remote client session (paragraph [0006]: sessions and tunnels for communications may be quickly re-established using tokens without user intervention in accordance with various protocols, such as the Multipath-TCP (RFC6824) under which a network identifier may be used to associate multiple paths to a single connection; paragraph [0015]: the first device may validate a second session token identified from an initiation of a second session between the first device and a third device via a second network path based at least on a property of the second network path. In some embodiments, the first device may provide, responsive to validating the second session token, the second session token to the first device and the third device for use in communications over a third network path between the second device and the third device; paragraph [0090]: The session information may be stored on the database 560 with a session state that the associated session 570 is active; paragraph [0099]: the token 590′ may have been stored and maintained on the database 560 with an indication as to whether the previous token 590′ was validated. In determining, the token validator 550 may access the database 560 to identify the indication of validation for the previous token 590′ associated with the initiator 505; paragraph [0100]: The identified session state may at least include that of the session associated with the previous token 590′. If any of the session states of the other session is indicated as active, the token validator 550 may permit or allow the current session 570 for communications; Note 1: Schultz’s teaching of utilizing a validated session token from a connection involving a third device to establish communications for a second device corresponds to the claimed cloned network context from a second local client enabling an express connection; Note 2: While Schultz does not explicitly state that the first and second devices belong to the same user, it would have been obvious to a person of ordinary skill in the art that multiple devices sharing a session token and maintaining multiple paths to a single connection would be associated with the same user (e.g., a single user accessing a remote workspace simultaneously from both a laptop and a mobile device). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Madishetti’s remote desktop framework to incorporate Schultz’s token-based sharing of session context across multiple devices to support simultaneous active connections to the remote client session, in order to reduce reconnection latency and enable faster re-establishment of remote desktop sessions without user intervention (Schultz paragraph [0006]).
Regarding claim 9, Madishetti does not disclose wherein the local client or the second local client is simultaneously connected to the remote client session in full control mode, viewing mode, or pre-connect mode. Schultz discloses wherein the local client or the second local client is simultaneously connected to the remote client session in full control mode, viewing mode, or pre-connect mode (paragraph [0006]: sessions and tunnels for communications may be quickly re-established using tokens without user intervention in accordance with various protocols, such as the Multipath-TCP (RFC6824) under which a network identifier may be used to associate multiple paths to a single connection; paragraph [0015]: the first device may validate a second session token identified from an initiation of a second session between the first device and a third device via a second network path based at least on a property of the second network path. In some embodiments, the first device may provide, responsive to validating the second session token, the second session token to the first device and the third device for use in communications over a third network path between the second device and the third device; paragraph [0090]: The session information may be stored on the database 560 with a session state that the associated session 570 is active; paragraph [0099]: the token 590′ may have been stored and maintained on the database 560 with an indication as to whether the previous token 590′ was validated. In determining, the token validator 550 may access the database 560 to identify the indication of validation for the previous token 590′ associated with the initiator 505; paragraph [0100]: The identified session state may at least include that of the session associated with the previous token 590′. If any of the session states of the other session is indicated as active, the token validator 550 may permit or allow the current session 570 for communications; Note 1: Schultz’s teaching of utilizing a validated session token from a connection involving a third device to establish communications for a second device corresponds to the claimed cloned network context from a second local client enabling an express connection; Note 2: While Schultz does not explicitly state that the first and second devices belong to the same user, it would have been obvious to a person of ordinary skill in the art that multiple devices sharing a session token and maintaining multiple paths to a single connection would be associated with the same user (e.g., a single user accessing a remote workspace simultaneously from both a laptop and a mobile device). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Madishetti’s remote desktop framework to incorporate Schultz’s token-based sharing of session context across multiple devices to support simultaneous active connections to the remote client session, in order to reduce reconnection latency and enable faster re-establishment of remote desktop sessions without user intervention (Schultz paragraph [0006]).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Madishetti et al. (US 2023/0266979, Madishetti) in view of Schultz et al. (US 2022/0224684, hereinafter Schultz) as applied to claim 1, and further in view of Chauhan et al. (US 2020/0145385, hereinafter Chauhan).
Regarding claim 7, Madishetti in view of Schultz does not disclose wherein establishing the remote client session is based on a remote logon process associated with a first set of operations that configure an un-finalized connection and a second set of operations that configure a finalized connection using the un-finalized connection, wherein the first set of operations are pre-graphics operations and the second set of operations are graphics operations. Chauhan discloses wherein establishing the remote client session is based on a remote logon process associated with a first set of operations that configure an un-finalized connection and a second set of operations that configure a finalized connection using the un-finalized connection, wherein the first set of operations are pre-graphics operations and the second set of operations are graphics operations (paragraph [0011]: storing the received data in the memory of the client application without providing visual output to the embedded browser includes instantiating a new tab or window of the embedded browser having disabled visibility, the received data of the first network application provided to the instantiated new tab or window for rendering; paragraph [0134]: Remote Desktop Protocol (RDP); paragraph [0157]: Session logs may be analyzed to identify an application or secure communication sessions likely to be accessed, and prior to receiving a request to establish the session, an intermediary (e.g. another device such as an intermediary appliance or other device, or an intermediary agent on a client such as a client application) may pre-establish the session, performing any necessary handshaking or credential or key exchange processes. When the session is subsequently requested (e.g. in response to a user request), the system may immediately begin using the pre-established session; paragraph [0172]: If the requested application corresponds to one of the pre-launched applications—e.g., if data has been requested and received—then at step 1212, the client application may provide the received data for rendering by the embedded browser; Note: Chauhan’s teaching of pre-establishing the session and loading data with disabled visibility corresponds to the claimed first set of pre-graphics operations configuring an un-finalized connection, while the subsequent enabling of visibility for display to the user corresponds to the claimed second set of graphics operations configuring a finalized connection). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the remote desktop session establishment framework of Madishetti and Schultz to incorporate Chauhan’s two-stage pre-launch sequence separating hidden background operations from visible display operations, in order to drastically accelerate access to the applications and eliminate perceived latency by retrieving data and performing connection handshakes in advance of the user’s request, so that the graphical interface is instantly available when requested (Chauhan paragraphs [0158], [0175]).
Claims 10-14 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Madishetti et al. (US 2023/0266979, Madishetti) in view of Chauhan et al. (US 2020/0145385, hereinafter Chauhan).
Regarding claim 10, Madishetti discloses
A computerized system comprising:
One or more computer-storage media having computer-executable instructions embodied thereon that, when executed by a computing system having a processor and memory, cause the processor to perform operations, the operations comprising (Fig. 12, 13):
determining a status associated with a remote client (paragraph [0089]: Another capability is to quickly resume, or reallocate compute resources that were previously paused, restoring the exact memory and processor state of the virtual machine; paragraph [0100]: FIG. 6 is a virtual desktop state diagram of the compute resource optimization service 260 that includes a paused state 610, a pausing state 614, a resuming state 616, a disconnected state 618, and a connected state 620);
based on determining the status, executing one or more connection management operations … ; and based on executing the one or more connection management operations, establishing a remote client session between the remote client and a local client (paragraph [0104]: The compute resource optimization service 260 directs the Cloud virtual infrastructure provider 530 to resume (814). The Cloud virtual infrastructure provider 530 then resumes the virtual desktop 222 (516); paragraph [0110]: If the virtual desktop 222 is in a paused state, the client 210 ignores the reactivation, as a connection still exists and a user may access the virtual desktop 222 through the client 210).
Madishetti does not disclose the one or more connection management operations executed to configure an un-finalized connection using a first set of operations, the first set of operations associated with a second set of operations that configure a finalized connection using the un-finalized connection, wherein the first set of operations are pre-graphics operations and the second set of operations are graphics operations. Chauhan discloses the one or more connection management operations executed to configure an un-finalized connection using a first set of operations, the first set of operations associated with a second set of operations that configure a finalized connection using the un-finalized connection, wherein the first set of operations are pre-graphics operations and the second set of operations are graphics operations (paragraph [0011]: storing the received data in the memory of the client application without providing visual output to the embedded browser includes instantiating a new tab or window of the embedded browser having disabled visibility, the received data of the first network application provided to the instantiated new tab or window for rendering; paragraph [0134]: Remote Desktop Protocol (RDP); paragraph [0157]: Session logs may be analyzed to identify an application or secure communication sessions likely to be accessed, and prior to receiving a request to establish the session, an intermediary (e.g. another device such as an intermediary appliance or other device, or an intermediary agent on a client such as a client application) may pre-establish the session, performing any necessary handshaking or credential or key exchange processes. When the session is subsequently requested (e.g. in response to a user request), the system may immediately begin using the pre-established session; paragraph [0172]: If the requested application corresponds to one of the pre-launched applications—e.g., if data has been requested and received—then at step 1212, the client application may provide the received data for rendering by the embedded browser; Note: Chauhan’s teaching of pre-establishing the session and loading data with disabled visibility corresponds to the claimed first set of pre-graphics operations configuring an un-finalized connection, while the subsequent enabling of visibility for display to the user corresponds to the claimed second set of graphics operations configuring a finalized connection). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the remote desktop session establishment framework of Madishetti to incorporate Chauhan’s two-stage pre-launch sequence separating hidden background operations from visible display operations, in order to drastically accelerate access to the applications and eliminate perceived latency by retrieving data and performing connection handshakes in advance of the user’s request, so that the graphical interface is instantly available when requested (Chauhan paragraphs [0158], [0175]).
Regarding claim 11, Madishetti discloses
wherein the status is identified from one of the following: an existing remote client session that is not active; an existing remote client session that is active on an alternate local client; and no existing remote existing remote client session (paragraph [0089]: Another capability is to quickly resume, or reallocate compute resources that were previously paused, restoring the exact memory and processor state of the virtual machine; paragraph [0100]: FIG. 6 is a virtual desktop state diagram of the compute resource optimization service 260 that includes a paused state 610, a pausing state 614, a resuming state 616, a disconnected state 618, and a connected state 620).
Regarding claim 12, Madishetti discloses
wherein the status is identified from one of the following: an existing remote client session that is not active; an existing remote client session that is active on an alternate local client; and no existing remote existing remote client session (paragraph [0089]: Another capability is to quickly resume, or reallocate compute resources that were previously paused, restoring the exact memory and processor state of the virtual machine; paragraph [0100]: FIG. 6 is a virtual desktop state diagram of the compute resource optimization service 260 that includes a paused state 610, a pausing state 614, a resuming state 616, a disconnected state 618, and a connected state 620).
Regarding claim 13, Madishetti does not disclose wherein the un-finalized connection is configured for the remote client session based on the status indicating the remote client session exists and not active. Chauhan discloses wherein the un-finalized connection is configured for the remote client session based on the status indicating the remote client session exists and not active (paragraph [0011]: storing the received data in the memory of the client application without providing visual output to the embedded browser includes instantiating a new tab or window of the embedded browser having disabled visibility, the received data of the first network application provided to the instantiated new tab or window for rendering; paragraph [0134]: Remote Desktop Protocol (RDP); paragraph [0157]: Session logs may be analyzed to identify an application or secure communication sessions likely to be accessed, and prior to receiving a request to establish the session, an intermediary (e.g. another device such as an intermediary appliance or other device, or an intermediary agent on a client such as a client application) may pre-establish the session, performing any necessary handshaking or credential or key exchange processes. When the session is subsequently requested (e.g. in response to a user request), the system may immediately begin using the pre-established session; paragraph [0172]: If the requested application corresponds to one of the pre-launched applications—e.g., if data has been requested and received—then at step 1212, the client application may provide the received data for rendering by the embedded browser; paragraph [0173]: If the requested application does not correspond to a pre-launched application, then at step 1214, the client application may request access to the network application normally (e.g. transmitting a request to an application server to access the application, initiating execution of the network application or instantiating a virtual machine for the network application, etc.); Note: Chauhan’s teaching of pre-establishing the session and loading data with disabled visibility corresponds to the claimed first set of pre-graphics operations configuring an un-finalized connection, while the subsequent enabling of visibility for display to the user corresponds to the claimed second set of graphics operations configuring a finalized connection). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the remote desktop session establishment framework of Madishetti to incorporate Chauhan’s two-stage pre-launch sequence separating hidden background operations from visible display operations, in order to drastically accelerate access to the applications and eliminate perceived latency by retrieving data and performing connection handshakes in advance of the user’s request, so that the graphical interface is instantly available when requested (Chauhan paragraphs [0158], [0175]).
Regarding claim 14, Madishetti not disclose wherein the un-finalized connection is configured for the remote client session based on the status indicating the remote client session exists and not active. Chauhan discloses wherein the un-finalized connection is configured for the remote client session based on the status indicating the remote client session exists and not active (paragraph [0011]: storing the received data in the memory of the client application without providing visual output to the embedded browser includes instantiating a new tab or window of the embedded browser having disabled visibility, the received data of the first network application provided to the instantiated new tab or window for rendering; paragraph [0134]: Remote Desktop Protocol (RDP); paragraph [0157]: Session logs may be analyzed to identify an application or secure communication sessions likely to be accessed, and prior to receiving a request to establish the session, an intermediary (e.g. another device such as an intermediary appliance or other device, or an intermediary agent on a client such as a client application) may pre-establish the session, performing any necessary handshaking or credential or key exchange processes. When the session is subsequently requested (e.g. in response to a user request), the system may immediately begin using the pre-established session; paragraph [0172]: If the requested application corresponds to one of the pre-launched applications—e.g., if data has been requested and received—then at step 1212, the client application may provide the received data for rendering by the embedded browser; paragraph [0173]: If the requested application does not correspond to a pre-launched application, then at step 1214, the client application may request access to the network application normally (e.g. transmitting a request to an application server to access the application, initiating execution of the network application or instantiating a virtual machine for the network application, etc.); Note: Chauhan’s teaching of pre-establishing the session and loading data with disabled visibility corresponds to the claimed first set of pre-graphics operations configuring an un-finalized connection, while the subsequent enabling of visibility for display to the user corresponds to the claimed second set of graphics operations configuring a finalized connection). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the remote desktop session establishment framework of Madishetti to incorporate Chauhan’s two-stage pre-launch sequence separating hidden background operations from visible display operations, in order to drastically accelerate access to the applications and eliminate perceived latency by retrieving data and performing connection handshakes in advance of the user’s request, so that the graphical interface is instantly available when requested (Chauhan paragraphs [0158], [0175]).
Regarding claim 17, Madishetti discloses
A computer-implemented method, the method comprising: … receiving a request to establish the remote client session (paragraph [0089]: Another capability is to quickly resume, or reallocate compute resources that were previously paused, restoring the exact memory and processor state of the virtual machine; paragraph [0100]: FIG. 6 is a virtual desktop state diagram of the compute resource optimization service 260 that includes a paused state 610, a pausing state 614, a resuming state 616, a disconnected state 618, and a connected state 620).
Madishetti does not disclose executing a first set of operations to configure an un-finalized connection associated with a remote client, the first set of operations being pre-graphics operations associated with a remote client session configuration sequence that enables establishing a remote client session between the remote client and a local client … based on receiving the request to establish the remote client session, executing a second set of operations to configure a finalized connection based on the un-finalized connection to establish the remote client session, the second set of operations being graphics operations associated with the remote client session configuration sequence. Chauhan discloses executing a first set of operations to configure an un-finalized connection associated with a remote client, the first set of operations being pre-graphics operations associated with a remote client session configuration sequence that enables establishing a remote client session between the remote client and a local client … based on receiving the request to establish the remote client session, executing a second set of operations to configure a finalized connection based on the un-finalized connection to establish the remote client session, the second set of operations being graphics operations associated with the remote client session configuration sequence (paragraph [0011]: storing the received data in the memory of the client application without providing visual output to the embedded browser includes instantiating a new tab or window of the embedded browser having disabled visibility, the received data of the first network application provided to the instantiated new tab or window for rendering; paragraph [0134]: Remote Desktop Protocol (RDP); paragraph [0157]: Session logs may be analyzed to identify an application or secure communication sessions likely to be accessed, and prior to receiving a request to establish the session, an intermediary (e.g. another device such as an intermediary appliance or other device, or an intermediary agent on a client such as a client application) may pre-establish the session, performing any necessary handshaking or credential or key exchange processes. When the session is subsequently requested (e.g. in response to a user request), the system may immediately begin using the pre-established session; paragraph [0172]: If the requested application corresponds to one of the pre-launched applications—e.g., if data has been requested and received—then at step 1212, the client application may provide the received data for rendering by the embedded browser; Note: Chauhan’s teaching of pre-establishing the session and loading data with disabled visibility corresponds to the claimed first set of pre-graphics operations configuring an un-finalized connection, while the subsequent enabling of visibility for display to the user corresponds to the claimed second set of graphics operations configuring a finalized connection). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the remote desktop session establishment framework of Madishetti to incorporate Chauhan’s two-stage pre-launch sequence separating hidden background operations from visible display operations, in order to drastically accelerate access to the applications and eliminate perceived latency by retrieving data and performing connection handshakes in advance of the user’s request, so that the graphical interface is instantly available when requested (Chauhan paragraphs [0158], [0175]).
Regarding claim 18, Madishetti does not disclose wherein the second set of operations further comprise peripheral operations. Chauhan discloses wherein the second set of operations further comprise peripheral operations (paragraph [0011]: storing the received data in the memory of the client application without providing visual output to the embedded browser includes instantiating a new tab or window of the embedded browser having disabled visibility, the received data of the first network application provided to the instantiated new tab or window for rendering; paragraph [0134]: Remote Desktop Protocol (RDP); paragraph [0157]: Session logs may be analyzed to identify an application or secure communication sessions likely to be accessed, and prior to receiving a request to establish the session, an intermediary (e.g. another device such as an intermediary appliance or other device, or an intermediary agent on a client such as a client application) may pre-establish the session, performing any necessary handshaking or credential or key exchange processes. When the session is subsequently requested (e.g. in response to a user request), the system may immediately begin using the pre-established session; paragraph [0172]: If the requested application corresponds to one of the pre-launched applications—e.g., if data has been requested and received—then at step 1212, the client application may provide the received data for rendering by the embedded browser; paragraph [0173]: If the requested application does not correspond to a pre-launched application, then at step 1214, the client application may request access to the network application normally (e.g. transmitting a request to an application server to access the application, initiating execution of the network application or instantiating a virtual machine for the network application, etc.); Note: Chauhan’s teaching of pre-establishing the session and loading data with disabled visibility corresponds to the claimed first set of pre-graphics operations configuring an un-finalized connection, while the subsequent enabling of visibility for display to the user corresponds to the claimed second set of graphics operations configuring a finalized connection). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the remote desktop session establishment framework of Madishetti to incorporate Chauhan’s two-stage pre-launch sequence separating hidden background operations from visible display operations, in order to drastically accelerate access to the applications and eliminate perceived latency by retrieving data and performing connection handshakes in advance of the user’s request, so that the graphical interface is instantly available when requested (Chauhan paragraphs [0158], [0175]).
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Madishetti et al. (US 2023/0266979, Madishetti) in view of Chauhan et al. (US 2020/0145385, hereinafter Chauhan) as applied to claim 10, and further in view of Oh et al. (US 2016/0378535, hereinafter Oh).
Regarding claim 15, Madishetti in view of Chauhan does not disclose the operations further comprising: determining that a virtual machine associated with the remote client is hibernating; and communicating a notification to the local client to initiate a connection automatically. Oh discloses the operations further comprising: determining that a virtual machine associated with the remote client is hibernating; and communicating a notification to the local client to initiate a connection automatically (paragraph [0008]: Remote Desktop Protocol (RDP); paragraph [0084]: the connection broker commands the virtual machine infrastructure to allocate a new idle virtual machine instance in response to a newly received request … the connection broker may request the virtual machine infrastructure to prepare a new cloud virtual machine for a newly logged-in user session (login user session)). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the remote desktop session establishment framework of Madishetti in view of Chauhan to incorporate Oh’s allocating new idle VM in response to a newly received request (or a newly logged-in user session (login user session)), in order to provide real-time virtual desktop service based on the VM (Oh paragraphs [0017]).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Madishetti et al. (US 2023/0266979, Madishetti) in view of Chauhan et al. (US 2020/0145385, hereinafter Chauhan) as applied to claim 10, and further in view of Hobbs (US 8,341,624, hereinafter Hobbs).
Regarding claim 16, Madishetti not disclose wherein the one or more connection management operations further comprise: … and preserving virtual channels that maintain redirections associated with remote client sessions. Chauhan discloses wherein the one or more connection management operations further comprise: … and preserving virtual channels that maintain redirections associated with remote client sessions (paragraph [0011]: storing the received data in the memory of the client application without providing visual output to the embedded browser includes instantiating a new tab or window of the embedded browser having disabled visibility, the received data of the first network application provided to the instantiated new tab or window for rendering; paragraph [0057]: The client device may connect to enterprise resources 204 and enterprise services 208 through virtual private network connections; paragraph [0134]: Remote Desktop Protocol (RDP); paragraph [0157]: Session logs may be analyzed to identify an application or secure communication sessions likely to be accessed, and prior to receiving a request to establish the session, an intermediary (e.g. another device such as an intermediary appliance or other device, or an intermediary agent on a client such as a client application) may pre-establish the session, performing any necessary handshaking or credential or key exchange processes. When the session is subsequently requested (e.g. in response to a user request), the system may immediately begin using the pre-established session; paragraph [0172]: If the requested application corresponds to one of the pre-launched applications—e.g., if data has been requested and received—then at step 1212, the client application may provide the received data for rendering by the embedded browser; paragraph [0173]: If the requested application does not correspond to a pre-launched application, then at step 1214, the client application may request access to the network application normally (e.g. transmitting a request to an application server to access the application, initiating execution of the network application or instantiating a virtual machine for the network application, etc.); Note: Chauhan’s teaching of pre-establishing the session and loading data with disabled visibility corresponds to the claimed first set of pre-graphics operations configuring an un-finalized connection, while the subsequent enabling of visibility for display to the user corresponds to the claimed second set of graphics operations configuring a finalized connection). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the remote desktop session establishment framework of Madishetti to incorporate Chauhan’s two-stage pre-launch sequence separating hidden background operations from visible display operations, in order to drastically accelerate access to the applications and eliminate perceived latency by retrieving data and performing connection handshakes in advance of the user’s request through virtual private network connections, so that the graphical interface is instantly available when requested (Chauhan paragraphs [0158], [0175]).
Madishetti in view of Chauhan does not disclose retaining graphics driver data and peripheral driver data on virtual machines that support remote clients. Oh discloses retaining graphics driver data and peripheral driver data on virtual machines that support remote clients (col. 4, lines 3-5: The user may use any of the devices 114 to manipulate data and perform tasks on the remote desktop enabled through the one of the virtual machines 110; col. 6, lines 31-37: Each of the virtual machines 110 comprises application software 304 (i.e., illustrated as application software 304.sub.1, application software 304.sub.2 . . . application software 304.sub.N) and graphics drivers 306 (i.e., illustrated as graphics drivers 306.sub.1, graphics drivers 306.sub.2 . . . graphics drivers 306.sub.N), typically under the control of an operating system such as MICROSOFT WINDOWS, LINUX, UNIX or the like; col. 8, lines 32-43: The I/O VM 400 also comprises graphics drivers 402, which are similar to the graphics drivers 306 as illustrated in FIG. 3 but better suited to supporting multiple virtual machines. The Front-End (FE) drivers 408 exchange input/output (I/O) commands with the complementary Back End (BE) drivers 406 within the I/O VM 400. The I/O VM 400 further comprises I/O drivers for devices associated with the different remote computers. In some embodiments, one or more I/O virtual machines host different drivers. For example, the I/O VM 400 supports graphics processing and another I/O VM hosts peripheral device drivers). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the remote desktop session establishment framework of Madishetti in view of Chauhan to incorporate Hobbs’ utilizing VM including graphics drivers and peripheral derivers to perform tasks on the remote desktop, in order to improved virtualized support for remote computing (Hobbs paragraphs col. 1, lines 61-62).
Claims 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Madishetti et al. (US 2023/0266979, Madishetti) in view of Chauhan et al. (US 2020/0145385, hereinafter Chauhan) as applied to claim 17, and further in view of Schultz et al. (US 2022/0224684, hereinafter Schultz).
Regarding claim 19, Madishetti not disclose un-finalized connection. Chauhan discloses un-finalized connection (paragraph [0011]: storing the received data in the memory of the client application without providing visual output to the embedded browser includes instantiating a new tab or window of the embedded browser having disabled visibility, the received data of the first network application provided to the instantiated new tab or window for rendering; paragraph [0057]: The client device may connect to enterprise resources 204 and enterprise services 208 through virtual private network connections; paragraph [0134]: Remote Desktop Protocol (RDP); paragraph [0157]: Session logs may be analyzed to identify an application or secure communication sessions likely to be accessed, and prior to receiving a request to establish the session, an intermediary (e.g. another device such as an intermediary appliance or other device, or an intermediary agent on a client such as a client application) may pre-establish the session, performing any necessary handshaking or credential or key exchange processes. When the session is subsequently requested (e.g. in response to a user request), the system may immediately begin using the pre-established session; paragraph [0172]: If the requested application corresponds to one of the pre-launched applications—e.g., if data has been requested and received—then at step 1212, the client application may provide the received data for rendering by the embedded browser; paragraph [0173]: If the requested application does not correspond to a pre-launched application, then at step 1214, the client application may request access to the network application normally (e.g. transmitting a request to an application server to access the application, initiating execution of the network application or instantiating a virtual machine for the network application, etc.); Note: Chauhan’s teaching of pre-establishing the session and loading data with disabled visibility corresponds to the claimed first set of pre-graphics operations configuring an un-finalized connection, while the subsequent enabling of visibility for display to the user corresponds to the claimed second set of graphics operations configuring a finalized connection). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the remote desktop session establishment framework of Madishetti to incorporate Chauhan’s two-stage pre-launch sequence separating hidden background operations from visible display operations, in order to drastically accelerate access to the applications and eliminate perceived latency by retrieving data and performing connection handshakes in advance of the user’s request through virtual private network connections, so that the graphical interface is instantly available when requested (Chauhan paragraphs [0158], [0175]).
Madishetti in view of Chauhan does not disclose the operations further comprising: executing the first set of operations to configure a second un-finalized connection associated a user, wherein the un-finalized connection and the second un-finalized connection are associated with user; and connecting to a second client using the second un-finalized connection and the remote client, wherein the local client and the second local client are simultaneous active connections to the remote client session. Schultz discloses the operations further comprising: executing the first set of operations to configure a second … connection associated a user, wherein the … connection and the second … connection are associated with user; and connecting to a second client using the second … connection and the remote client, wherein the local client and the second local client are simultaneous active connections to the remote client session (paragraph [0006]: sessions and tunnels for communications may be quickly re-established using tokens without user intervention in accordance with various protocols, such as the Multipath-TCP (RFC6824) under which a network identifier may be used to associate multiple paths to a single connection; paragraph [0015]: the first device may validate a second session token identified from an initiation of a second session between the first device and a third device via a second network path based at least on a property of the second network path. In some embodiments, the first device may provide, responsive to validating the second session token, the second session token to the first device and the third device for use in communications over a third network path between the second device and the third device; paragraph [0090]: The session information may be stored on the database 560 with a session state that the associated session 570 is active; paragraph [0099]: the token 590′ may have been stored and maintained on the database 560 with an indication as to whether the previous token 590′ was validated. In determining, the token validator 550 may access the database 560 to identify the indication of validation for the previous token 590′ associated with the initiator 505; paragraph [0100]: The identified session state may at least include that of the session associated with the previous token 590′. If any of the session states of the other session is indicated as active, the token validator 550 may permit or allow the current session 570 for communications; Note 1: Schultz’s teaching of utilizing a validated session token from a connection involving a third device to establish communications for a second device corresponds to the claimed cloned network context from a second local client enabling an express connection; Note 2: While Schultz does not explicitly state that the first and second devices belong to the same user, it would have been obvious to a person of ordinary skill in the art that multiple devices sharing a session token and maintaining multiple paths to a single connection would be associated with the same user (e.g., a single user accessing a remote workspace simultaneously from both a laptop and a mobile device). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Madishetti in view of Chauhan’s remote desktop state-management framework through two-stage pre-launch sequence separating hidden background operations from visible display operations to incorporate Schultz’s token-based sharing of session context across multiple devices to support simultaneous active connections to the remote client session across multiple devices and network paths, in order to reduce reconnection latency and enable faster re-establishment of remote desktop sessions without user intervention (Schultz paragraph [0006]).
Regarding claim 20, Madishetti in view of Chauhan does not disclose wherein the local client or the second local client is simultaneously connected to the remote client session in full control mode, viewing mode, or pre-connect mode. Schultz discloses wherein the local client or the second local client is simultaneously connected to the remote client session in full control mode, viewing mode, or pre-connect mode (paragraph [0006]: sessions and tunnels for communications may be quickly re-established using tokens without user intervention in accordance with various protocols, such as the Multipath-TCP (RFC6824) under which a network identifier may be used to associate multiple paths to a single connection; paragraph [0015]: the first device may validate a second session token identified from an initiation of a second session between the first device and a third device via a second network path based at least on a property of the second network path. In some embodiments, the first device may provide, responsive to validating the second session token, the second session token to the first device and the third device for use in communications over a third network path between the second device and the third device; paragraph [0090]: The session information may be stored on the database 560 with a session state that the associated session 570 is active; paragraph [0099]: the token 590′ may have been stored and maintained on the database 560 with an indication as to whether the previous token 590′ was validated. In determining, the token validator 550 may access the database 560 to identify the indication of validation for the previous token 590′ associated with the initiator 505; paragraph [0100]: The identified session state may at least include that of the session associated with the previous token 590′. If any of the session states of the other session is indicated as active, the token validator 550 may permit or allow the current session 570 for communications; Note 1: Schultz’s teaching of utilizing a validated session token from a connection involving a third device to establish communications for a second device corresponds to the claimed cloned network context from a second local client enabling an express connection; Note 2: While Schultz does not explicitly state that the first and second devices belong to the same user, it would have been obvious to a person of ordinary skill in the art that multiple devices sharing a session token and maintaining multiple paths to a single connection would be associated with the same user (e.g., a single user accessing a remote workspace simultaneously from both a laptop and a mobile device). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Madishetti in view of Chauhan’s remote desktop state-management framework through two-stage pre-launch sequence separating hidden background operations from visible display operations to incorporate Schultz’s token-based sharing of session context across multiple devices to support simultaneous active connections to the remote client session across multiple devices and network paths, in order to reduce reconnection latency and enable faster re-establishment of remote desktop sessions without user intervention (Schultz paragraph [0006]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Singh et al. (US 2024/0015162) discloses “To expedite the presentation of the content to the user while the remote browser application and session are being initiated, the client application may obtain one or more pre-cached or pre-stored content files (or other data structure) corresponding to the requested content” (paragraph [0061]).
Singh (US 2019/0391712) discloses “By preparing to launch the URLs while the base virtual session is being launched, the system may more efficiently and quickly launch the URLs and the appropriate settings after the base virtual session becomes available” (paragraph [0139]) and “assume that the previous session was initiated at a mobile device with weaker graphics capabilities. During the previous session, a graphics intensive URL may have been launched by the secured browser 741 having access to a vGPU that satisfies the graphics requirements of the URL. The user may reconnect to the session via a client device having more powerful graphics capabilities that satisfy the graphics requirement of the URL, such as a personal computer, a laptop computer with a dedicated GPU, etc.” (paragraph [0144]).
Ramareddy et al. (US 2017/0279927) discloses “By storing the application state where it can easily be retrieved and resume processing, the connection can be quickly re-established and the client computer may continue receiving data from the virtualized application without re-entering credentials or waiting for a session with the server to be re-created” (paragraph [0009]).
Frost et al. (US 2019/0349338) discloses “A database (not shown) may maintain the states of one or more sessions on target machines, and the computing device 717 (e.g., via the session manager 720) may consult the database to determine, for example, the number of sessions that are in use or available” (paragraph [0103]), “, the operating system of the target machine 740 may report, to the server agent 725, that the helper 735 is running, so that the anonymous session 730 is maintained. Accordingly, the session 730 may be kept running so that a client device may quickly connect to the session 730” (paragraph [0113]), and “The connection may comprise, for example, mouse, keyboard, and/or graphics connection(s)” (paragraph [0118]).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SISLEY N. KIM whose telephone number is (571)270-7832. The examiner can normally be reached M-F 11:30AM -7:30PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y. Blair can be reached on (571)270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SISLEY N KIM/Primary Examiner, Art Unit 2196 6/3/2026
Prosecution Insights