DETAILED ACTION
Claims 1-20 are pending.
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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Claim Rejections - 35 USC § 103
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-6, 8-13 and 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Rutkowska et al., Qubes OS Architecture, January 2010, cited in IDS in view of in further view of Muller et al. (US 2015/0244608 A1).
Regarding claim 1, Rutkowska teaches the invention substantially as claimed including a method of executing an application, performed by an electronic device including a host system and a virtual machine system (page 5 discloses a desktop which is interpreted as an "electronic device"; fig. 1 on page 25 discloses Dom0 which is interpreted as a “host system" and App VM1, App VM2 which are interpreted as "virtual machine system". It is noted that the hardware of the device which is running the Qubes operating system is also interpreted as a "host system"), the method comprising:
obtaining, through the host system, a first execution request for a first guest application installed in the virtual machine system (page 27, section 5.4 teaches “In order to start a new application in AppVM the special program called the AppStub is executed in Dom0. This program should take care about first checking if the VM where the particular application is hosted has already been started, as well as the corresponding AppViewer in Dom0, and later to send a command to the GUI agent in the AppVM to start the particular application (e.g. /usr/bin/firefox) and make sure the application started successfully, or otherwise report a problem to the user.” This is interpreted as a request to start the application such as e.g. the Browser application of App VM1 of fig.1 of page 25);
transmitting, from the host system to the virtual machine system, in response to obtaining the first execution request, a first request for executing the first guest application (page 27, section 5.4 teaches to send a command to the GUI agent in the App VM to start the application.);
outputting a first execution result of the first guest application on the first virtual display that is generated based on the second request (page 25, fig. 1.; 5.3 Qubes GUI architecture teaches that when content is generated in the applications running on the AppVM1 and 2 they are output through the Xen Shared Memory to an App Viewer in Dom 0. Further, fig. 2 on page 26 shows content generated on the apps being is then output to the composition buffers of the X server and the dummy graphics driver, see also passage corresponding description for these steps in pages 25 and 26);
transmitting, from the virtual machine system to the host system, a first captured image of the first virtual display (page 26, fig. 2 shows that the captured image from the browser application is transmitted to the Dom0 host, see also page 26, second full paragraph); and
outputting, through the host system, the first captured image on a display of the electronic device (fig. 2 on page 26 discloses that the contents of the browser application window from AppVM1 are displayed on the user's desktop which is interpreted as the "display of the electronic device").
Rutkowska teaches an environment in which an application executing remotely is shown as if it was executing locally through the use of virtual windows in a display as shown in Fig. 1. While Rutkowska teaches a generated first virtual display corresponding to the first application and other applications, specifically the applications executed on both AppVm1 and AppVM2, Rutkowska does not explicitly teach transmitting, a second request for generating a first virtual display corresponding to the first guest application.
However, Muller teaches transmitting, a second request for generating a first virtual display corresponding to the first guest application ([0016] For example, a user of the client system 110 may transmit data to the one or more host systems 130 to request display data of a virtual machine from the virtual machine display network. In response, the one or more host systems 130 may transmit display data (e.g., return data traffic) to the client system 110. For example, the display data may be transmitted to the client system 110 through the gateway 141 that is assigned to a network device associated with the virtual machine display network.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Muller of requesting display information associated with the application with the teachings of applications displayed in Rutkowska. The modification would have been motivated by the desire of combining known elements such as a request to display information to yield predictable results of application data displayed in a user window/desktop.
Regarding claim 2, Rutkowska teaches further comprising:
outputting, on the display through the host system, a second captured image of a second virtual display on which a second execution result of a second guest application is output, wherein the first captured image is included in a first host window and the second captured image is included in a second host window (Page 26 Fig. 2 shows a browser application and an e-mail application running inside AppVM1, the content generated by these apps (i.e., virtual displays) are transmitted to Dom0 for display for a user’s desktop as different host windows, see below).
PNG
media_image1.png
542
691
media_image1.png
Greyscale
Regarding claim 3, Rutkowska teaches wherein the second guest application is executed based on a user input corresponding to the second guest application on a home screen output on the display (Page 6, section 1.4 shows different examples as to how a user may want to use a VM and install/request applications based on the purpose of it.; Page 10 section 2.5 states that a legitimate user can start and operate all the applications in all AppVMs; Page 27, 5.4).
Regarding claim 4, Rutkowska teaches further comprising:
receiving a user input corresponding to the first captured image output on the display (Page 17, Section 4 teaches all the user email will be kept in the AppVM where the user runs the email client…Qubes provides a special stub-application called AppViewer, that is used to bring all the user applications from various AppVMs onto a common desktop in Dom0 and allows the user to interact with them just as if the applications were natively running there, and not in other VMs.);
based on the user input corresponding to a second guest application, transmitting, from the host system to the virtual machine system, a third request for executing to the second guest application (Page 17, Section 4 teaches wherein the user interacts with the applications, particularly figure 1 shows a first app, Chrome, Firefox, and an E-mail app; page 27, section 5.4 teaches “In order to start a new application in AppVM the special program called the AppStub is executed in Dom0. This program should take care about first checking if the VM where the particular application is hosted has already been started, as well as the corresponding AppViewer in Dom0, and later to send a command to the GUI agent in the AppVM to start the particular application (e.g. /usr/bin/firefox) and make sure the application started successfully”);
outputting, through the virtual machine system, a second execution result on the first virtual display (Page 25, Section 5.3 steps 1 and 2)
transmitting, from the virtual machine system to the host system, an updated first captured image of the first virtual display on which the first execution result and the second execution result are output (Page 25; Page 26 Fig. 2 and “Even when the composition buffer is directly shared with the AppViewer, the AppViewer needs to know when the buffer changes, so it can inform the X server running in Dom0 about the need to re-render the AppViewer window content (via XRenderComposite() call). The Qubes agent running in AppVM registers to receive XDamage notifications from the local X server, whenever any of the window on the virtual desktop gets updates (even if it is obstructed). The agent passes those notifications to the AppViewer, using the ring buffer protocol mentioned earlier”); and
outputting, through the host system, the updated first captured image on the display (See Page 26 “the user’s desktop”).
Regarding claim 5, Rutkowska teaches wherein a first guest window including the first execution result and a second guest window including the second execution result are output on the first virtual display, and wherein a first host window including the updated first captured image is output on the display (See Page 26 “the user’s desktop” it shows the output from updated content from each app).
Regarding claim 6, Rutkowska teaches wherein the updated first captured image is generated by combining a partial image of the home screen provided by the host system with an area where the first guest window and the second guest window are not arranged from among a rectangular image including the first guest window and the second guest window (Page 26 Fig. 2, “The composition mode support is essential, because it allows our agent to get unobstructed image of each window content, no matter whether they obstruct each other on the virtual desktop or not.” And “Even when the composition buffer is directly shared with the AppViewer, the AppViewer needs to know when the buffer changes, so it can inform the X server running in Dom0 about the need to re-render the AppViewer window content (via XRenderComposite() call). The Qubes agent running in AppVM registers to receive XDamage notifications from the local X server, whenever any of the window on the virtual desktop gets updates (even if it is obstructed). The agent passes those notifications to the AppViewer, using the ring buffer protocol mentioned earlier”).
Regarding claim 8, it is a method type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above.
Regarding claim 9 it is a system type claim having similar limitations as claim 1 above. Therefore, it is rejected under the same rationale above. Further, the additional limitations of at least one memory storing at least one instruction, and at least one processor configured to execute the at least one instruction are taught by Rutkowska in at least Page 14 where it discusses a CPU executing code kept in pages/memory.
Regarding claim 10 it is a system type claim having similar limitations as claim 2 above. Therefore, it is rejected under the same rationale above.
Regarding claim 11 it is a system type claim having similar limitations as claim 4 above. Therefore, it is rejected under the same rationale above.
Regarding claim 12 it is a system type claim having similar limitations as claim 5 above. Therefore, it is rejected under the same rationale above.
Regarding claim 13 it is a system type claim having similar limitations as claim 6 above. Therefore, it is rejected under the same rationale above.
Regarding claim 15, Rutkowska teaches wherein the transmitting, from the host system to the virtual machine system, the first request and the generation request, comprises: transmitting the first request and the second request, from the host system to the virtual machine system, through a guest controller corresponding to the virtual machine system, from among a plurality of guest controllers each corresponding to a different virtual machine system on the electronic device (Page 17 Section 4 discusses that the AppVMs run the user’s applications and are accessed via Dom0. Further in Section 4 “Qubes provides a special stub-application called AppViewer, that is used to bring all the user applications from various AppVMs onto a common desktop in Dom0 and allows the user to interact with them just as if the applications were natively running there, and not in other VMs. For this to work, each AppVM must run a special agent called QubesWM, that can be thought of as of a dedicated Window Manager that the AppViewers interact with.” Also Section 5.4 shows AppStub in Dom0 used to start particular applications in the AppVMs).
Regarding claim 16, Rutkowska teaches further comprising: determining whether the third request for executing the second guest application is caused by the first guest application, and based on a determination that the third request is not caused by the first guest application, transmitting, from the host system to the virtual machine system, a fourth request for generating second virtual display that corresponds to the second guest application (Page 17, Section 4 “All the user files are kept in one or more of the AppVMs. E.g. all the user email will be kept in the AppVM where the user runs the email client (perhaps the user might want to have different email clients in different AppVMs, one for personal email, the other for corporate email, and in that case the emails are kept in the corresponding AppVMs). The user is offered, of course, an ability to move the files from one AppVM to another one”; Section 5.4).
Regarding claim 17, Rutkowska teaches further comprising: based on a determination that the third request is caused by the first guest application, outputting the second execution result on the first virtual display without generating the second virtual display (Page 17, Section 4 “All the user files are kept in one or more of the AppVMs. E.g. all the user email will be kept in the AppVM where the user runs the email client (perhaps the user might want to have different email clients in different AppVMs, one for personal email, the other for corporate email, and in that case the emails are kept in the corresponding AppVMs). The user is offered, of course, an ability to move the files from one AppVM to another one”; Section 4.2 Inter-VM file exchange teaches interaction among different AppVMs and Section 5.4).
Regarding claim 18 it is a system type claim having similar limitations as claim 15 above. Therefore, it is rejected under the same rationale above.
Regarding claim 19 it is a system type claim having similar limitations as claim 19 above. Therefore, it is rejected under the same rationale above.
Regarding claim 20, Rutkowska further comprising: transmitting, from the host system to the virtual machine system a third request for executing a second guest application installed in the virtual machine system without a fourth request for generating a second virtual display (page 27, section 5.4 teaches “In order to start a new application in AppVM the special program called the AppStub is executed in Dom0. This program should take care about first checking if the VM where the particular application is hosted has already been started, as well as the corresponding AppViewer in Dom0, and later to send a command to the GUI agent in the AppVM to start the particular application (e.g. /usr/bin/firefox)).
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Rutkowska and Muller, as applied to claim 1 above, in view of Anonymous : “App menu shortcut troubleshooting | Qubes OS” August 2021 (hereinafter WebArchive).
Regarding claim 7, Rutkowska teaches obtaining execution requests for particular apps depending on the type of VM see at least Page 6, section 1.4 shows different examples as to how a user may want to use a VM and install/request applications based on the purpose of it. Rutkowska nor Muller do not explicitly teach wherein the obtaining of the first execution request for the first guest application comprises: outputting, on the display through the host system, an application list of at least one host application installed in the host system and at least one guest application installed in the virtual machine system; and obtaining the first execution request based on the first guest application being selected from the application list by a user input corresponding to the first guest application.
However, WebArchive teaches wherein the obtaining of the first execution request for the first guest application comprises: outputting, on the display through the host system, an application list of at least one host application installed in the host system and at least one guest application installed in the virtual machine system; and obtaining the first execution request based on the first guest application being selected from the application list by a user input corresponding to the first guest application (Page 2 shows a list of available applications where the user can select to apply.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of WebArchive with the teachings of Rutkowska and Muller to allow the user to select from a list of available applications which to deploy on its Qubes environment with Rutkowska’s AppVMs. The modification would have been motivated by the desire of combining known methods to yield predictable results.
Regarding claim 14 it is a system type claim having similar limitations as claim 7 above. Therefore, it is rejected under the same rationale above.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 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.
Conclusion
Applicant's amendment necessitated the new grounds of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORGE A CHU JOY-DAVILA whose telephone number is (571)270-0692. The examiner can normally be reached Monday-Friday, 6:00am-5:00pm.
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, Aimee J Li can be reached at (571)272-4169. 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.
/JORGE A CHU JOY-DAVILA/Primary Examiner, Art Unit 2195