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 .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1,3,5-8,10,12-15,17 and 19-23 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 (i.e., changing from AIA to pre-AIA ) 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, 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, 5-8, 12-15 and 19-23 are rejected under 35 U.S.C. 103 as being unpatentable over Hu (US 20170003995 A1) in view of Momchilov (US 20120324365 A1).
Regarding claim 1, Hu teaches:
A method, comprising. (Claim 1. A method of moving a virtual application into a virtual desktop, comprising:)
by a virtual desktop client operating on a client device, establishing a first virtual desktop session on a first virtual desktop and, by the virtual desktop client, establishing a second virtual desktop session on a second virtual desktop, the first virtual desktop and the second virtual desktop executing on one or more host servers. ([0011] FIG. 1 illustrates components of a virtualized desktop infrastructure (VDI) system 100 in which one or more embodiments of the present invention may be implemented. In VDI system 100, VDI client software programs (also referred to as “VDI clients” for short), e.g., VDI clients 110.sub.1-2, run on operating systems of local computing devices, e.g., client machine 108 on top of an operating system (OS) 111. [0012] Domain controller 135 and connection broker 137 may run on separate servers or in separate virtual machines running on the same server or different servers. In the embodiments of the present invention illustrated herein, desktops are running in VMs 157 which are instantiated on a plurality of physical computers 150, 152, 154, … . See also [0013, 0017]. EN: Hu teaches VDI clients operating on the client machine and connecting to virtual environments executing in separate VMs. )
detecting, by the virtual desktop client, that the first virtual desktop session and the second virtual desktop session are established and. ([0017] For example, to implement drag-and-drop modules 310 in the Windows® OS, a drag component object model (COM) interface and a drop COM interface may be integrated in VDI clients 320.sub.1-2. When a user drags the window of a VDI client 320.sub.1 connected to the virtual application in such a case, VDI client 320.sub.1 collects and bundles information for the VM in which the virtual application is running. The information that VDI client 320.sub.1 collects and bundles may include a name or identifier of the VM (e.g., VM 302 or 303), such as a universal name of the VM, and potentially other types of information such as connection broker information. EN: Hu shows that the client recognizes information concerning tow established VDI environments and responds to interaction between them)
in response to detecting that the first virtual desktop session and the second virtual desktop session are established, requesting, by the virtual desktop client, the first virtual desktop to establish a virtual channel directly with the second virtual desktop for exchanging data between the first virtual desktop and the second virtual desktop; ([0018] Each of the virtual channels serves as a multiplex over the PCoIP data transfer channel. Further, PCoIP virtual channels inherit NAT (Network Address Translation) penetration from the PCoIP protocol, allowing VDI clients 320.sub.1-2 to communicate with VMs 302-303 even when they are in different security zones. Illustratively, each PCoIP virtual channel includes two endpoints, one of which is a plugin (e.g., VChannel plugins 330.sub.1-2) on the client device 301 side and the other of which is an application or service (e.g., VChannel application 335) on the VM 302 or 303 side. After one of VDI clients 320.sub.1-2 connects to VM 302, a PCoIP client (library) running in the client device 301 loads the appropriate VChannel plugins and performs a handshake negotiation with PCoIP server 340.sub.3 running in VM 302 to start VChannel application 335. See also [0019-0020])
establishing the virtual channel between the first virtual desktop and the second virtual desktop for exchanging data between the first virtual desktop and the second virtual desktop in response to the request from the virtual desktop client; and ([0020] Once nested VDI client 355 connects to VM 303 in which the virtual application runs, the virtual application will appear as a native program inside the virtual desktop. As a result, the user does not need to switch between VDI client user interfaces or switch back to the local system to perform tasks such as copying-and-pasting text from the virtual application to the virtual desktop, or vice versa. Additionally, no data is copied out of the VM when such a copying-and-pasting operation is performed, so a security policy that forbids such copying of data out of the VM (e.g., because the data is copied outside a security zone) will not affect the operation.)
using the virtual channel between the first virtual desktop and the second virtual desktop, redirecting an application executing in the first virtual desktop to the second virtual desktop to enable a user of the client device to access and interact with the redirected application from within the second virtual desktop, ([0013] In one embodiment, a virtual application running in one VM is moved into a virtual desktop running in another VM. In response to a user dragging the user interface of a first VDI client (e.g., VDI client 110.sub.1) connected to the virtual application into the user interface of a second VDI client (e.g., VDI client 110.sub.2) connected to the virtual desktop, information on the VM in which the virtual application runs is collected and transmitted to the second VDI client. The second VDI client then passes the information via a virtual channel to the VM in which the virtual desktop runs, and a remote launcher in the VM launches another VDI client therein that connects to the VM in which the virtual application runs, as indicated by the collected and transmitted information. The user may then access the virtual application via the new VDI client as if the virtual application were running inside the virtual desktop, without having to switch user interfaces between the virtual application and the virtual desktop or the local system.)
Hu does not appear to explicitly teach: wherein redirecting the application comprises: streaming graphical data corresponding to an application window of the application from the first virtual desktop to the second virtual desktop over the virtual channel. presenting the application window within a graphical user interface of the second virtual desktop; and forwarding user input received in the second virtual desktop for the application window to the first virtual desktop over the virtual channel to be effectuated by the application.
However, Momchilov teaches: [0066]In some embodiments, this first process 206 may also be referred to as a remote application. In other embodiments, the first agent 202 receives graphical data and window attribute data from the second agent 204 and directs the display of the received graphical or window attribute data in a desktop environment including a plurality of data objects. In one of these embodiments, a data object is a window displayed in the desktop environment. In another one of these embodiments, the data object is a data structure storing attribute data and may or may not have an associated visible representation in the desktop environment. In still another of these embodiments, a data object is a data structure storing data associated with a user interface element--visual state, identification of associated functionality, location of graphical data, title bar contents, etc.--and a window is a graphical representation of the user interface element. In still even another of these embodiments, a shell 214 executing on a machine provides a display of user interface elements in a desktop environment. See also [0069][0183-0184][0218-0226][0282].
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to modify Hu’s virtual application and desktop interaction system with Momchilov seamless window virtual channel technique so that graphical window data and user interaction for applications are communicated over the virtual channel and presented within the destination desktop. One would have been motivated to make such a combination to provide an efficient user experience by allowing the remotely executing application to appear within the destination virtual desktop.
Regarding claim 5, Hu teaches:
The method of claim 1, further comprising: receiving a user request in the second virtual desktop to copy data from the redirected application and receiving a subsequent user request in the second virtual desktop to paste the data into an application executing in the second virtual desktop; and transferring the data from the first virtual desktop to the second virtual desktop over the established virtual channel between the first virtual desktop and the second virtual desktop to perform a paste operation. (At the same time, VM 210 and VM 220 cannot directly interact with each other, so a transformation back to local system 205 is required to accomplish even simple tasks. For example, copying text from a document open in VM 210 to another document open in VM 220 requires reading from the first document in VM 210, switching back to local system 205, switching from local system 205 to the user interface of a VDI client connected to VM 220, and then writing to the other document in VM 220. As another example, when copying data out of a VM to a local system is forbidden for security reasons (e.g., because the data is copied outside a security zone), the same operation to copy text from a document open in VM 210 to another document open in VM 220 may require the even more inconvenient steps of copying the text to an e-mail first, sending the e-mail, switching back to local system 205, switching from local system 205 to the user interface of a VDI client connected to VM 220, opening the e-mail in VM 220, and copying-and-pasting the text in the e-mail to the other document. See also [0020]. EN: Hu teaches data movement between virtual environments copy/paste)
Regarding claim 6 , Momchilov teaches:
The method of claim 1, further comprising redirecting a file from the first virtual desktop to the second virtual desktop including presenting a virtual drive mounted in the second virtual desktop that is mapped to the first virtual desktop. ( [0176] Normally, published applications may access local client drives as well as shared network drives. However, in many instances, these published applications may also need to access the VDA's drives, similar to applications running in the VDA. Therefore, in one embodiment of the system discussed herein, server drives from the parent VDA may be enumerated and accessible in the context of a corresponding client published application. This may be accomplished through enumeration of the server drives; mapping of the server drives to network drives or other accessible drives; and redirection of read and write requests to the mapped drives. In one embodiment, Server Message Block (SMB) protocol may be used to map remote server drives. See also [0317-0318] . EN: Momchilov teaches a mapping a drive from a virtual environment so that applications operating in the other environment can access the drive.)
Regarding claim 7, Momchilov teaches:
The method of claim 1, wherein the application is redirected from the first virtual desktop to the second virtual desktop as a seamless window. ([0182] Section C: Illustrative Embodiment for Seamless Windows Virtual Channel Protocol[0183] The following presents an illustrative embodiment for seamless window integration using a virtual channel protocol. Use of specific limiting language within this Section C should not be imputed to other embodiments described herein. For example, while certain items "must" occur in this embodiment, those items may be optional or merely illustrative in other embodiments described herein.[0184] Seamless Windows Interface (also sometimes known as Transparent Windows Interface or Seamless) is an add-on component for client-side systems, such as the Citrix Receiver for XenApp and XenDesktop manufactured by Citrix Systems, Inc. The seamless virtual channel protocol enhances the client with windows information, making each remote application appear in a separate resizable window on the client device. Users cannot tell the difference between local and remote applications; all of them are presented in the same way. Thus, the user interface is said to be "seamless" between locally and remotely executing applications.)
Regarding claim 21, Momchilov teaches:
The method of claim 1, wherein the virtual channel is established between a first application redirection module executing in the first virtual desktop and a second application redirection module executing in the second virtual desktop, and wherein the first application redirection module streams the graphical data corresponding to the application window directly to the second application redirection module over the virtual channel. ([0066] the first agent 202 receives graphical data and window attribute data from the second agent 204 … [0069] the first agent 202 may receive data, such as output data 208 and window attribute data 210 over one or more connections. In one embodiment, one or more connections may be multiplexed into one or more virtual channels. EN: Momchilov teaches corresponding UI components that exchange graphical information over virtual channels between computing environments )
Regarding claim 8, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale.
Regarding claim 12, the claim recites similar limitation as corresponding claim 5 and is rejected for similar reasons as claim 5 using similar teachings and rationale.
Regarding claim 13, the claim recites similar limitation as corresponding claim 6 and is rejected for similar reasons as claim 6 using similar teachings and rationale.
Regarding claim 14, the claim recites similar limitation as corresponding claim 7 and is rejected for similar reasons as claim 7 using similar teachings and rationale.
Regarding claim 15, the claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale
Regarding claim 19, the claim recites similar limitation as corresponding claim 5 and is rejected for similar reasons as claim 5 using similar teachings and rationale.
Regarding claim 20, the claim recites similar limitation as corresponding claim 6 and is rejected for similar reasons as claim 6 using similar teachings and rationale.
Regarding claim 22, the claim recites similar limitation as corresponding claim 21 and is rejected for similar reasons as claim 21 using similar teachings and rationale.
Regarding claim 23, the claim recites similar limitation as corresponding claim 21 and is rejected for similar reasons as claim 21 using similar teachings and rationale.
Claims 3, 10 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Hu (US 20170003995 A1) in view of Momchilov (US 20120324365 A1) and in further view of Thompson (US 20050125739 A1).
Regarding claim 3 , Hu does not appear to explicitly teach:
The method of claim 1, further comprising: redirecting a topmost application of the first virtual desktop to the second virtual desktop when the user switches to the second virtual desktop or redirecting a topmost application of the second virtual desktop to the first virtual desktop when the user switches to the first virtual desktop. (Paragraph 39 defines the “topmost app” can mean the app that is active in the desktop, the app with focus of the operating system (OS))
However, Thompson teaches: [0039] Tracking Topmost Application on Other Desktops[0040] In order to provide users with a more logical experience with virtual desktop software, the system of the present invention has the capability to track the last active application on each virtual desktop. Normally, virtual desktops will return the user to the topmost window on a virtual desktop. However, on Macintosh systems (and likely others) it is possible to have an application be active but not have any open windows. The present invention implements a method to track the last active application on a virtual desktop and make that application active again upon returning to that desktop, even if it does not have any windows present on that desktop.
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Hu and Thompson before them, to include Thompson’s tracking topmost/last active application on virtual desktop in Hu/ Momchilov system performing multiple virtual desktop sessions. . One would have been motivated to make this combination to improve the continuity of interacting with applications across multiple desktops.
Regarding claim 10, the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale.
Regarding claim 17, the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS A ESPANA whose telephone number is (703)756-1069. The examiner can normally be reached Monday - Friday 8 a.m - 5 p.m EST.
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, LEWIS BULLOCK JR can be reached at (571)272-3759. 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.
/C.A.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
