DETAILED ACTION
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 .
The following FINAL Office Action is in response to Applicant’s communication filed 12/11/2025 regarding Application 18/786,768.
Status of Claim(s)
Claim(s) 1-20 is/are currently pending and are rejected as follows.
Response to Arguments – 101 Rejection
Applicant’s arguments in regards to the previously applied 101 rejection have been fully considered and are not deemed persuasive.
Applicant argues that the claims do not recite methods of organizing human activity or a mental process, as the claims are directed towards an improvement onto a specific technology (specifically that of IT management).
Examiner disagrees for the following reasons. First the claims were previously determined under Step 1 of the Alice/Mayo framework to fall within the four statutory categories of invention, (product, method, and apparatus). The claims were then analyzed under Step 2A, Prong One to determine whether the claims recite any abstract ideas. The claims recite an invention for the creating a temporary workspace for a user where the temporary workspace is to be temporarily used by the end user only while the IHS (Information Handling System) is configured for ongoing use by the end user, configuring an IHS for use by the user and providing the temporary workspace for use by the user on the IHS, and when the configuration is completed, providing the IHS for use by the user. The amended claims are deemed to still fall within the abstract ideas of Organizing Human Activity and Mental Process, as the claims as currently presented do not provide actions that cannot be performed in the human mind as the acts of configuring and providing a workspace using an HIS (where an IHS in view of Applicant’s specification is defined as “…may include a variety of hardware and software components that may be configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems”) are evaluations and judgements that can be made, similar to the onboarding of an employee with equipment for use. Further, the example of onboarding an employee with a workstation is also the rationale for why the actions provided in Applicant’s claims recite an abstract idea. Finally, Under Step 2A, Prong Two, the additional elements of an IHS and a cloud based infrastructure were not recited in such a way such as to provide a meaningful limitation onto the abstract idea to render the claims eligible.
With regards to Applicant’s second argument, the claims do not provide an improvement onto a specific technology of IT, but instead focus on actions for how to utilize IT technology, which does not render claims as directed towards an improvement onto a technology. Therefore the claims remain ineligible under 101.
Further elaboration regarding this determination can be found in the amended 101 rejection below.
Response to Arguments – 102 Rejection
Applicant’s arguments in regards to the previously applied 102 rejection are rendered moot in view of the amended prior art rejection below.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 101 because the claimed invention is/are directed towards a judicial exception (i.e. law of nature, a natural phenomenon, or an abstract idea) without significantly more.
Claim(s) 1-20 are directed towards an invention for the creating a temporary workspace for a user where the temporary workspace is to be temporarily used by the end user only while the IHS (Information Handling System) is configured for ongoing use by the end user, configuring an IHS for use by the user and providing the temporary workspace for use by the user on the IHS, and when the configuration is completed, providing the IHS for use by the user. These actions fall under a subject matter grouping which the courts have considered ineligible (Mental Process and Organizing Human Activity). These claims do not integrate the abstract idea into a practical application, and do not include additional elements that provide an inventive concept (are sufficient to amount to significantly more than the abstract idea).
Under Step 1 of the Alice/Mayo framework it must be considered whether the claims are directed to one of the four statutory categories of invention. Claim(s) 1-9 are directed towards an product. Claim(s) 10-16 is directed towards a method comprising at least one step. Claim(s) 17-20 is directed towards an apparatus. Accordingly, the claims fall within the four statutory categories of invention, (product, method, and apparatus) and will be further analyzed under Step 2 of the Alice/Mayo framework).
Under Step 2A, Prong One, of the Alice/Mayo framework it must be considered whether the claims recite any abstract ideas.
Claim(s) 1, 10, and 17 recite an invention for the creating a temporary workspace for a user where the temporary workspace is to be temporarily used by the end user only while the IHS (Information Handling System) is configured for ongoing use by the end user, configuring an IHS for use by the user and providing the temporary workspace for use by the user on the IHS, and when the configuration is completed, providing the IHS for use by the user which recite the abstract ideas of Organizing Human Activity and a Mental Process in the following limitations:
create a temporary workspace for the end user, wherein the temporary workspaces is to be temporarily used by the end user only while the IHS is configured for ongoing use by the end user;
as the IHS is being configured for use by the end user, provide the temporary workspace for use by the end user on the IHS;
and when the configuration of the IHS is completed, begin providing the IHS for use by the end user.
Dependent claims 2-9, 11-16, and 18-20 merely further limit the abstract idea and are thus subject to the same rationale as above.
Under Step 2A, Prong Two, any additional elements are recited.
Independent claims 1, 10, and 17 recite:
An information handling system (IHS)
A processor
A memory
A cloud based infrastructure
Dependent claims 3 and 11 recite:
A cloud-based based virtual-desktop infrastructure (VDI)
Dependent claim 8 recites:
A Web View client
These additional elements, considered both individually and as an ordered pair do no more than represent mere instructions to implement the abstract idea ("apply it") computer (See MPEP 2106.05(f)). Additionally, the claims represent insignificant extra solution activity (See MPEP 2106.05(g)). These elements are recited with a high degree of generality, and the specification sets forth the general purpose nature of the technologies required to implement the invention (emphasis added).
Support for this can be found in Paragraph(s) [0018]-[0019] and [0022]-[0027] of Applicant's specification.
Under Step 2B eligibility analysis evaluates whether the claims as a whole amounts to significantly more than the recited exception, i.e. whether any additional element, or combination of elements, adds an inventive concept to the claims (MPEP 2106.05). As explained with respect to Step 2A, Prong Two, there are several additional elements. The IHS, processor, memory, cloud based infrastructure, VDI, and Web View client are all, at best, the equivalent of merely adding the words "apply it" to the abstract idea. Mere instructions to apply an exception cannot provide an inventive concept (See MPEP 2106.05(f)). Further, the IHS represents insignificant extra solution activity (See MPEP 2106.05(g)), specifically that of mere data gathering which is known to be well- understood, routine, or conventional within the art (See MPEP 2106.05(d)(II)). Insignificant extra solution activity, especially that which is well- understood, routine, or conventional in the art does not provide an inventive concept Even when considered in combination, these additional elements to are not deemed to be sufficient enough to provide an inventive concept onto the abstract idea, therefore, they are not eligible. (Alice Corp., 134 S. Ct. at 2358 USPQ2d at 1983. See also 134 S. Ct. at 2389, 110 USPQ2d at 1984 (warning against a§ 101 that turns on "the draftsman's art")).
Dependent claims 2, 4-7, 9, 12-16, and 18-20 do not recite any further additional elements, and are therefore rejected for the same reasons recited above.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Koushik (US 2016/0134616 A1) in view of Hamilton II (US 6,633,977 B1)
Claim(s) 1, 10, and 17 –
Koushik recites the following:
a processor; and a (Koushik: Paragraph 242, "System memory 1420 may be configured to store instructions and data accessible by processor(s) 1410. In various embodiments, system memory 1420 may be implemented using any suitable memory technology, such as static random access memory (SRAM), synchronous dynamic RAM (SDRAM), nonvolatile/Flash-type memory, or any other type of memory. In the illustrated embodiment, program instructions and data implementing one or more desired functions, such as those methods, techniques, and data described above for providing on-demand delivery of desktop applications to desktops on physical computing devices or virtual desktops in a cloud computing environment, are shown stored within system memory 1420 as code 1427 and data 1426. For example, data 1426 may include information representing the assignment of selected applications to particular end users and/or user groups, constraints and/or configuration parameter settings for the selected applications, users, and catalogs, and may be stored in any of a variety of data structures or database tables within memory 1420 on one or more computing nodes of a service provider system and/or client computing device used in providing on-demand delivery of desktop applications, as described herein. In some embodiments, data 1426 may also include security tokens and/or unique identifiers of users and/or devices (physical computing devices, virtualized computing resource instances and/or virtual desktop instances), as described herein. In some embodiments, at least some of the data 1426 may be stored on a user volume within system memory 1420. In some embodiments, code 1427 may include application binaries or virtualized application packages ( or portions thereof), a desktop application management module and/or an application delivery agent, at least some of which may be stored on a boot volume within system memory 1420.")
memory coupled to the processor (Koushik: Paragraph 242, "System memory 1420 may be configured to store instructions and data accessible by processor(s) 1410. In various embodiments, system memory 1420 may be implemented using any suitable memory technology, such as static random access memory (SRAM), synchronous dynamic RAM (SDRAM), nonvolatile/Flash-type memory, or any other type of memory. In the illustrated embodiment, program instructions and data implementing one or more desired functions, such as those methods, techniques, and data described above for providing on-demand delivery of desktop applications to desktops on physical computing devices or virtual desktops in a cloud computing environment, are shown stored within system memory 1420 as code 1427 and data 1426. For example, data 1426 may include information representing the assignment of selected applications to particular end users and/or user groups, constraints and/or configuration parameter settings for the selected applications, users, and catalogs, and may be stored in any of a variety of data structures or database tables within memory 1420 on one or more computing nodes of a service provider system and/or client computing device used in providing on-demand delivery of desktop applications, as described herein. In some embodiments, data 1426 may also include security tokens and/or unique identifiers of users and/or devices (physical computing devices, virtualized computing resource instances and/or virtual desktop instances), as described herein. In some embodiments, at least some of the data 1426 may be stored on a user volume within system memory 1420. In some embodiments, code 1427 may include application binaries or virtualized application packages ( or portions thereof), a desktop application management module and/or an application delivery agent, at least some of which may be stored on a boot volume within system memory 1420.")
a cloud-based workspace infrastructure configured to create a plurality of workspaces (Koushik: Paragraph 20, "Various embodiments of systems and methods for providing applications (e.g., desktop applications) through an application fulfillment platform in a service provider system that provides virtualized computing resources to clients are described herein. The systems and methods described herein may provide on-demand delivery and installation of desktop applications to virtual desktop instances in a cloud computing environment for the benefit of end users (e.g., employees or members of a business, enterprise, or other organization that is a customer of the service provider). In some embodiments, the application fulfillment platform may employ a variety of services to manage collections of applications (e.g., catalogs or portfolios of applications) and to deliver virtualized application packages to end user machines or virtual desktop instances. In some embodiments, the systems described herein for providing on-demand delivery and installation of desktop applications to virtual desktop instances may implement multiple authentication mechanisms (e.g., two or more authentication mechanisms with which end users may be registered and their identities authenticated and/or with which their computing resources instances may be separately registered and authenticated).")
create a temporary workspace for the end user…; (Koushik: Paragraph 5 2, "In some embodiments, various components of a service provider network may be configured for the generation and management of remote computing sessions between client computing devices and virtual desktop instances hosted by one or more remote data center computers of a Program Execution Service (PES) platform. A number of data centers may be organized as part of a single PES platform that can facilitate the utilization of resources of the data centers by customers of the PES. In some embodiments, the PES may include several hundreds or thousands of data center computers. For example, in some embodiments, client computing devices may access the virtual desktop instances during one or more remote computing sessions, and a virtual desktop instance may provide a user with all of the capabilities of a client desktop environment but with centralized provisioning of the services accessed by the client."; Paragraph 217, "If the end user is authenticated, shown as the positive exit from 1030, the method may include the control plane generating a unique resource name to serve as a user identifier and a temporary security token for the end user, and returning them to the application delivery agent ( or control plane agent thereof), as in 1040. The method may also include the application delivery agent securely storing the unique resource name (user identifier) and temporary security token on the local device (e.g., on the virtual workspace instance), as in 1050."; Paragraph 221, "As noted above, the security tokens generated by the control plane for the end user and/or the computing resource instance (e.g., virtual desktop instance) may eventually expire. In some embodiments, the system may employ an automatic token renew process, in which the following steps may be used to obtain a new security token without requiring the end user to re-enter their credentials:")
as the IHS is being configured for use by the end user, provide the temporary workspace for use by the end user on the IHS; and (Koushik: Paragraph 53, "In some embodiments, a user, via a client computing device, may transmit a request to load an application such as a remote computing application. Subsequent to the receipt of the request, the client computing device may communicate with a PES platform to start a remote computing session. In one embodiment, the communication between the client computing device and the PES platform may include login information. In other embodiments, the communication may also include information identifying resource usage information, processing requirements, or rules regarding the duration or conditions of the remote computing session for the user of the client computing device. The client computing device may further communicate various information relating to the device state, including, but not limited to, a current or future availability of device resources (e.g., processing power, memory, storage, network usage, etc.). Using the information received, the PES platform may identify one or more virtual desktop instances for execution in one or more remote computing sessions. In one example, the PES platform may instantiate, or cause to have instantiated, a virtual machine instance on a data center computer, and the virtual machine instance may include an operating system. The client computing device may then establish a remote computing session with the virtual machine, and the user interface of the operating system (e.g., the output of the operating system, such as a graphical user interface, sound, etc.) may be sent to the client computing device via a particular network interface of the virtual machine instance or virtual desktop instance and presented to the user (e.g., the graphical user interface may be rendered on a display of the client computing device). The operating system may use a desktop profile associated with the user and stored on a desktop store accessible by the PES to configure the virtual desktop instance for the user by setting the desktop background, screen saver, desktop layout, pointer preferences, sound settings, and the like. User input such as mouse and keyboard activity may then be sent to the virtual machine (via a particular network interface of the virtual machine instance or virtual desktop instance) and injected into the operating system as if the activity was performed by a user directly at the virtual machine."; Paragraph 55, "In some embodiments, the virtual desktop instance provided may be configured according to a user profile stored at a user profile store of the PES. The configuration of the virtual desktop instance may also be adjusted according to monitored usage of the instance. In some embodiments, the user profile may be set by an administrator associated with an entity governing the user's use. The user profile may indicate various memory and processing requirements associated with the PES computers executing the one or more virtual desktop instances as well as requirements for the virtual desktop instances. For example, the user profile may indicate the programs to which the user is given while using the virtual desktop instance. In some embodiments, this may include one or more desktop applications that are packaged as virtualized application packages and that are provided on -demand through an application fulfillment platform implemented on resources of the service provider network. The user profile may also indicate a maximum time or cost associated with the remote computing session. The PES may take a user profile for the user into consideration when placing and configuring the virtual desktop instances. In addition, placement and configuration decisions may also be adjusted based on a user's interaction with the virtual desktop over time."; Paragraph 66, "In some embodiments, the processing requirements associated with a user or a client computing device may be determined based on a variety of scenarios. In some embodiments, the determination may be based on a user request at launching of the remote computing application 430. For example, the user may be presented with a graphical user interface (GUI) displaying a variety of options for resources and applications. The user may then select the applications they wish to have access to, or, alternatively, the version of those applications. For example, one user may wish to access a basic version of an application while another user may wish to access a professional version of the same application. The determination may also be based on pre-selected options for certain users as determined by administrators of entities associated with the users. For example, the pre-selected options may be presented to the user as a list of different packages of applications to which the user may wish to have access. In some cases, the determination may be made on historical usage data of a user, which the PES platform 402 may determine once the request is received from the user. In other cases, the determination of the processing requirements may be based on ongoing monitoring of use of processes by the user once the remote computing session is initiated. In such cases, the selection of adequate resource instances may be dynamically changed after the session is established, and the dynamic change over to new instance(s) may be performed as described with respect to FIG. 4 above. In some embodiments, the remote computing application 430 may request that a virtual desktop session be opened on behalf of the client, in response to which a virtual desktop instance 414 may be instantiated, configured for the use of the client, and/or connected to the client computing device 406 over network 404 (e.g., via a network interface of the virtual desktop instance 414).")
when the configuration of the IHS is completed, begin providing the IHS for use by the end user. (Koushik: Paragraph 53, "In some embodiments, a user, via a client computing device, may transmit a request to load an application such as a remote computing application. Subsequent to the receipt of the request, the client computing device may communicate with a PES platform to start a remote computing session. In one embodiment, the communication between the client computing device and the PES platform may include login information. In other embodiments, the communication may also include information identifying resource usage information, processing requirements, or rules regarding the duration or conditions of the remote computing session for the user of the client computing device. The client computing device may further communicate various information relating to the device state, including, but not limited to, a current or future availability of device resources ( e.g., processing power, memory, storage, network usage, etc.). Using the information received, the PES platform may identify one or more virtual desktop instances for execution in one or more remote computing sessions. In one example, the PES platform may instantiate, or cause to have instantiated, a virtual machine instance on a data center computer, and the virtual machine instance may include an operating system. The client computing device may then establish a remote computing session with the virtual machine, and the user interface of the operating system (e.g., the output of the operating system, such as a graphical user interface, sound, etc.) may be sent to the client computing device via a particular network interface of the virtual machine instance or virtual desktop instance and presented to the user (e.g., the graphical user interface may be rendered on a display of the client computing device). The operating system may use a desktop profile associated with the user and stored on a desktop store accessible by the PES to configure the virtual desktop instance for the user by setting the desktop background, screen saver, desktop layout, pointer preferences, sound settings, and the like. User input such as mouse and keyboard activity may then be sent to the virtual machine (via a particular network interface of the virtual machine instance or virtual desktop instance) and injected into the operating system as if the activity was performed by a user directly at the virtual machine."; Paragraph 55, "In some embodiments, the virtual desktop instance provided may be configured according to a user profile stored at a user profile store of the PES. The configuration of the virtual desktop instance may also be adjusted according to monitored usage of the instance. In some embodiments, the user profile may be set by an administrator associated with an entity governing the user's use. The user profile may indicate various memory and processing requirements associated with the PES computers executing the one or more virtual desktop instances as well as requirements for the virtual desktop instances. For example, the user profile may indicate the programs to which the user is given while using the virtual desktop instance. In some embodiments, this may include one or more desktop applications that are packaged as virtualized application packages and that are provided on -demand through an application fulfillment platform implemented on resources of the service provider network. The user profile may also indicate a maximum time or cost associated with the remote computing session. The PES may take a user profile for the user into consideration when placing and configuring the virtual desktop instances. In addition, placement and configuration decisions may also be adjusted based on a user's interaction with the virtual desktop over time."; Paragraph 66, "In some embodiments, the processing requirements associated with a user or a client computing device may be determined based on a variety of scenarios. In some embodiments, the determination may be based on a user request at launching of the remote computing application 430. For example, the user may be presented with a graphical user interface (GUI) displaying a variety of options for resources and applications. The user may then select the applications they wish to have access to, or, alternatively, the version of those applications. For example, one user may wish to access a basic version of an application while another user may wish to access a professional version of the same application. The determination may also be based on pre-selected options for certain users as determined by administrators of entities associated with the users. For example, the pre-selected options may be presented to the user as a list of different packages of applications to which the user may wish to have access. In some cases, the determination may be made on historical usage data of a user, which the PES platform 402 may determine once the request is received from the user. In other cases, the determination of the processing requirements may be based on ongoing monitoring of use of processes by the user once the remote computing session is initiated. In such cases, the selection of adequate resource instances may be dynamically changed after the session is established, and the dynamic change over to new instance(s) may be performed as described with respect to FIG. 4 above. In some embodiments, the remote computing application 430 may request that a virtual desktop session be opened on behalf of the client, in response to which a virtual desktop instance 414 may be instantiated, configured for the use of the client, and/or connected to the client computing device 406 over network 404 (e.g., via a network interface of the virtual desktop instance 414)."; Paragraph 238, "The application fulfillment platforms described herein may deploy virtualized applications as isolated containers and provide user access to their applications on any authorized device without performing application installs. The application virtualization techniques employed by the application fulfillment platforms may allow applications and application data to be moved from one virtual desktop instance to another, and may allow multiple generations and/or versions of the same application to run concurrently on a single virtual desktop instance as long as there is operating system support. They may also allow legacy applications to be executed in a virtualized environment.")
Koushik does not explicitly disclose the following, however, in analogous art of creating workspaces Hamilton II discloses the following:
…wherein the temporary workspace is to be temporarily used by the end user only while the HIS is configured for ongoing use by the end user (Hamilton II: Column 9 lines 3 – 34, “n FIG. 3, old computer system 310 is shown with data collection process 320 collecting user environment data from storage device 330 attached to old computer system 310. Collection process 320 may be user-invoked or may be invoked as result of an event as described for FIGS. 1 and 2. Storage device 330 may be a direct access storage device (DASD), file system, hard drive, or other nonvolatile data storage connected to old computer system 310. Old terminal 340 is also shown connected to computer network 300 for user to log onto and use old computer system 310. Data collection process 320 collects the user's environment data and transfers the information through computer network 300 to new computer system 350. Data duplication process 360 is invoked on new computer system 350 duplicating the user's old environment settings from old computer 310 onto new computer system 350. The environment settings are saved on storage device 370 for use with new computer system 350. After data duplication process 360 is completed, the user can log onto new computer system 350 and be presented with the same customized environment previously set for the old computer system. Flexibility in the system also permits to allow data collection process 320 to collect the user's environment data and store the information onto old computer system 310. When the user has moved to new computer system 350, the user can invoke data duplication process 360 on new computer system 350 copying data, through remove copy commands (rcp) or other such command, transmitting the user's environment data through computer network 300 duplicating the user's old environment settings from old computer 310 onto new computer system 350.”; Column 11 lines 9 – 39, “FIG. 6 is a mid-level flowchart of the processing performed by duplication preparation and execution process 450 shown in FIG. 4. The process is commenced at start (step 450) whereupon duplication program is updated (step 610). Update duplication program (step 610) uses the information that was written to the NIM server (see FIG. 5, step 570) to update the duplication script that will be executed on the workstation. Next, during hostname IP address process (step 620) a permanent hostname and IP address is provided for the user's new workstation. This information will be used when duplicating the personality data previously collected from the old workstation. The duplication program is then transferred to the workstation (step 630) where it will be executed from a root user session on the new workstation. The duplication program (step 640) is then executed to duplicate the settings previously collected from the old workstation onto the new workstation. Details of the duplication (step 640) processing are shown in FIG. 10. The duplication program subsequently calls the X-Windows settings program (step 650) so that customization of X-Windows (in a UNIX environment) can occur. Details of the X-Windows settings program (step 650) are shown in FIG. 11. Next, file permissions are restored (step 660) using a custom permission list (perm.list). After file permissions are restored, unique filesystems are created (step 670) from the information previously collected from the old workstation. After the unique filesystems are created, data previously collected from the unique filesystems is restored (step 680) to the filesystems created during step 670. After the data has been restored, the duplication process ends at termination step 690.”; Column 13 line 22 – Column 14 line 17, “FIG. 10 shows a low-level flowchart for duplicating the collected workstation data onto a different workstation (see step 650 in FIG. 6). First, information about the new workstation is needed. A temporary workstation name (hostname) is input by the user (input 1005) along with a temporary IP address (input 1010). Next, the permanent workstation name (hostname) (input 1015) and permanent IP address (input 1020) are input by the user. These hostnames and IP addresses are used to load the duplicate workstation identity information that was previously captured from the old workstation. After the information has been provided by the user, the workstation is connected to the NIM server in order to locate and copy the user environment data that was previously collected (step 1025). In an alternative embodiment, the user environment data is stored to a removable nonvolatile computer medium, such as a diskette, and such medium is provided to and read by the workstation in order to copy the previously captured user environment data. After the workstation has been connected to the location (NIM server or removable medium) containing the user environment data, the networking files are restored (step 1030). Next, the unique system information that was previously captured is duplicated to the new workstation (step 1035). After the unique system information is duplicated, ADSM files are restored (step 1045). Next, the application data that was previously identified and captured is duplicated to the new workstation (step 1050). After application data is restored, the tty information that was captured from the old workstation is duplicated to the new workstation (step 1055). Then the remote printer definitions that were captured from the old workstation are duplicated to the new workstation (step 1060). After the printer definitions are duplicated, the workstation's IP address and workstation name (hostname) are changed (step 1065) from the temporary hostname and IP address provided by the user in steps 1005 and 1010 to the permanent hostname and IP address provided by the user in steps 1015 and 1020. After the hostname and IP address changes have taken place, the Ethernet interfaces are checked and verified (step 1070). Next, the file permissions of key files that have been duplicated onto the new workstation are modified to reflect the move from the old workstation to the new workstation (step 1075). After the monitor timeout has been disabled (step 1080), the license file data is modified (step 1085) to reflect the duplication of licensed data, such as software products, from the old workstation to the new workstation. Finally, temporary files are cleaned up (step 1090) before the processing terminates (step 1095). The above-outlined steps are for a UNIX environment. Alternative embodiments may have somewhat different processing steps due to differences in operating systems. In addition, the steps outlined above could be performed in a somewhat different order, however the order outlined above is preferred for a UNIX environment. FIG. 11 shows a low-level flowchart of details of modifying X-windows settings on the new workstation (see step 650 in FIG. 6). First, a new window is created (step 1110). Then the X-windows session is terminated (step 1120), followed by setting the landscape (step 1130) and portrait (step 1140) settings of the new workstation's X-windows. After the settings have been changed, processing of the X-windows settings is terminated (step 1190).”)
Koushik discloses a method for providing temporary workspaces based on access authorities. Hamilton II discloses a method for coordinating and configuring workspaces for use. At the time of Applicant’s filed invention, one of ordinary skill in the art would have deemed it obvious to combine the methods of Koushik with the teachings of Hamilton II in order to improve the capabilities and efficiency of allowing multiple users to access and share a computing system as disclosed by Hamilton II (Hamilton II: Column 1 line 30-35, “The UNIX operating system is a multi-user operating system supporting serial and network connected terminals for multiple users. UNIX is a multitasking operating system allowing multiple users to use the same system simultaneously.”)
Claim(s) 2 –
Koushik in view of Hamilton II discloses the limitations of claim 1
Koushik further discloses the following:
wherein the temporary workspace is executed external to the IHS. (Koushik: Paragraph 51, "While not shown in FIG. 3, the virtualization service(s) may also be accessed from resource instances within the provider network 300 via APl(s) 302. For example, a client, appliance service provider, or other entity may access a virtualization service from within a respective private network on the provider network 300 via an API 302 to request allocation of one or more resource instances within the private network or within another private network. Note that in some embodiments, the hardware virtualization service 320 may be configured to provide computation resources 324 that have been configured to implement a virtual desktop instance, which may appear to the user as a local desktop (implemented by a virtual computing system 392). Note also that in some embodiments, the computation resources 324 that are made available to the client via hardware virtualization service 320 may include multiple network interfaces. For example, some of them may include one network interface for communicating with various components of client network 350 and another network interface for communicating with computation resources or other network entities on another network that is external to provider network 200 (not shown)."; Paragraph 7 4, "In some embodiments, the data center 500 network may implement IP tunneling technology, mapping service technology, and a routing service technology to route traffic to and from virtualized resources, for example to route packets from the VMs 524 on hosts 520 in data center 500 to Internet destinations, and from Internet sources to the VMs 524. Internet sources and destinations may, for example, include computing systems 570 connected to the intermediate network 540 and computing systems 552 connected to local networks 550 that connect to the intermediate network 540 (e.g., via edge router(s) 514 that connect the network 550 to Internet transit providers). The provider data center 500 network may also route packets between resources in data center 500, for example from a VM 524 on a host 520 in data center 500 to other VMs 524 on the same host or on other hosts 520 in data center 500. In some embodiments, at least some of the VMs 524 may include two or more network interfaces. For example, they may include one network interface usable for communications between VMs 524 and the clients on whose behalf VMs 524 are hosted by the provider and a second (separate and distinct) network interface that is usable to access external resources, computing systems, data centers, or Internet destinations on networks other than the provider network and the client network, either or both of which may employ an IP tunneling technology, as described herein. In other embodiments, each of the VMs 524 may include only a single network interface.")
Claim(s) 3 –
Koushik in view of Hamilton II discloses the limitations of claims 1-2
Koushik further discloses the following:
wherein the temporary workspace comprises a cloud-based VDI environment. (Koushik: Paragraph 78, "In some embodiments, while there are physical computers executing client applications and other processes described herein, the client applications may be running as virtual machines on the physical computers. For example, internal processes of the cloud computing environment that are configured to manage the creation of these virtual machines, to provision resources for these virtual machines, and/or to perform other administrative tasks on behalf of clients and/or their applications (e.g., monitoring resource usage, customer accounting, billing for services, etc.) may execute in a control plane layer ( or hypervisor) in the cloud computing environment. By contrast, client applications (e.g., each resource instance that implements an application component) may execute in a data plane layer of the cloud computing environment. Underneath these layers, there may be only one physical network card for each host node (or for multiple host nodes), in some embodiments, but each resource instance may execute as if it has its own network (e.g., a virtual network). In some embodiments, each resource instance may have its own data plane network connection(s), but may make local API calls (e.g., calls to a component on the same node) without needing to rely on these data plane netwoik connections."; Paragraph 80, "In various embodiments, a service provider may employ one of the example provider networks described above (or another suitable provider network environment) to implement a hosted desktop service in a cloud computing environment. In such embodiments, a customer may access the provider network in the cloud computing environment to request the instantiation and/or configuration of one or more virtual desktop instances in the cloud, and may then provide access to those virtual desktop instances to one or more end users (e.g., through a client application). For example, an administrator within an organization or enterprise may set up an account with a service provider, may contract with the service provider to set up some number of virtual desktop instances, and (once the virtual desktop instances are set up), may provide credentials for accessing these virtual desktop instances. In this example, once the virtual desktop instances have been set up and credentials have been provided, one or more end users may launch a client application on their a client device (e.g., a computer, tablet device, or other mobile device) and enter the credentials for the virtual desktop instance, after which they may be logged into a virtual desktop environment. Although the virtual desktop environment is implemented by virtualized resource instances in the cloud computing environment, it may appear to the end user as if it were a local desktop and it may operate as if it were an independent computer to which the user is connected. In some embodiments, the virtual desktop environment may provide access to productivity software and other software programs to which the user would typically have access if the user were logged onto a physical computer owned by the organization or enterprise. In at least some embodiments, an application fulfillment platform of the service provider may be configured to provide on-demand delivery of desktop applications (e.g., as virtualized application packages) to virtual desktop instances, as described herein.")
Claim(s) 4, 12, and 18 –
Koushik in view of Hamilton II discloses the limitations of claims 1, 10, and 17
Koushik further discloses the following:
wherein the program instructions, upon execution, further cause the IHS to configure one or more applications on the IHS. (Koushik: Paragraph 80, "In various embodiments, a service provider may employ one of the example provider networks described above ( or another suitable provider network environment) to implement a hosted desktop service in a cloud computing environment. In such embodiments, a customer may access the provider network in the cloud computing environment to request the instantiation and/or configuration of one or more virtual desktop instances in the cloud, and may then provide access to those virtual desktop instances to one or more end users (e.g., through a client application). For example, an administrator within an organization or enterprise may set up an account with a service provider, may contract with the service provider to set up some number of virtual desktop instances, and ( once the virtual desktop instances are set up), may provide credentials for accessing these virtual desktop instances. In this example, once the virtual desktop instances have been set up and credentials have been provided, one or more end users may launch a client application on their a client device (e.g., a computer, tablet device, or other mobile device) and enter the credentials for the virtual desktop instance, after which they may be logged into a virtual desktop environment. Although the virtual desktop environment is implemented by virtualized resource instances in the cloud computing environment, it may appear to the end user as if it were a local desktop and it may operate as if it were an independent computer to which the user is connected. In some embodiments, the virtual desktop environment may provide access to productivity software and other software programs to which the user would typically have access if the user were logged onto a physical computer owned by the organization or enterprise. In at least some embodiments, an application fulfillment platform of the service provider may be configured to provide on-demand delivery of desktop applications (e.g., as virtualized application packages) to virtual desktop instances, as described herein."; Paragraph 82, "As noted above, in at least some embodiments, a service provider system may include an application fulfillment platform that is configured to provide on-demand delivery of applications (e.g., as virtualized application packages) to end users of service provider customers. FIG. 6 is a block diagram illustrating components of an application fulfillment platform, including components of the platform that execute on an enterprise system 602, a service provider network 600 (which includes a fulfillment platform control plane 606), and an end user system 608, that collectively provide on-demand delivery of desktop applications to various end users of service provider customers, according to at least some embodiments. The functionality of various ones of the components of the application fulfillment platform illustrated in FIG. 6 are described in more detail below. As illustrated in this example, an IT administrator may access a service provider system console 616 in the fulfillment platform control plane 606 through an interface mechanism of the enterprise system 602 (e.g., enterprise system browser 604). Note that, as described above in reference to FIG. 1, service provider network may also include physical and/or virtualized computing resource instances (e.g., computation resource instances and/or storage resource instance) and other storage resource ( e.g., storage resources managed by a storage service) within or outside of the application fulfillment platform and its control plane 606 (not shown).")
Claim(s) 5, 13, and 19 –
Koushik in view of Hamilton II discloses the limitations of claims 1, 10, and 17
Koushik further discloses the following:
further cause the IHS to configure one or more settings for the applications on the IHS. (Koushik: Paragraph 121, "In some embodiments, launching a virtual desktop instance may include making selected applications available to end users through a desktop application management module interface, according to the constraints and configuration parameter settings for the selected applications and users. In some cases, this may include installing any required applications and/or making certain applications (e.g., those applications that are assigned to a particular end user or those an end user is allowed to know about) visible and/or selectable through a desktop application management module interface or (once they are installed on an end user machine or in a virtual desktop instance) through an icon, shortcut, menu element, or other user interface mechanism or element thereof that was created on the desktop for the application and whose selection launches the application."; Paragraph 127, "In some embodiments, each of the virtualized applications that are packaged by the packager may be isolated into a container, such that the contents of each container is executed in isolation by the runtime engine and the individual applications do not know anything about each other. This isolation may allow multiple generations and/or versions of an application to execute on the same physical machine. In various embodiments, and depending on various settings (e.g., off-line or on-line only), the page blocks that make up a virtualized application may or may not be stored locally on the end user's machine during (or following) their execution by the runtime engine."; Paragraph 242, "System memory 1420 may be configured to store instructions and data accessible by processor(s) 1410. In various embodiments, system memory 1420 may be implemented using any suitable memory technology, such as static random access memory (SRAM), synchronous dynamic RAM (SDRAM), nonvolatile/Flash-type memory, or any other type of memory. In the illustrated embodiment, program instructions and data implementing one or more desired functions, such as those methods, techniques, and data described above for providing on-demand delivery of desktop applications to desktops on physical computing devices or virtual desktops in a cloud computing environment, are shown stored within system memory 1420 as code 1427 and data 1426. For example, data 1426 may include information representing the assignment of selected applications to particular end users and/or user groups, constraints and/or configuration parameter settings for the selected applications, users, and catalogs, and may be stored in any of a variety of data structures or database tables within memory 1420 on one or more computing nodes of a service provider system and/or client computing device used in providing on -demand delivery of desktop applications, as described herein. In some embodiments, data 1426 may also include security tokens and/or unique identifiers of users and/or devices (physical computing devices, virtualized computing resource instances and/or virtual desktop instances), as described herein. In some embodiments, at least some of the data 1426 may be stored on a user volume within system memory 1420. In some embodiments, code 1427 may include application binaries or virtualized application packages (or portions thereof), a desktop application management module and/or an application delivery agent, at least some of which may be stored on a boot volume within system memory 1420.")
Claim(s) 6 and 14 –
Koushik in view of Hamilton II discloses the limitations of claims 1 and 10
Koushik further discloses the following:
further cause the IHS to configure one or more user environment settings on the IHS. (Koushik: Paragraph 121, "In some embodiments, launching a virtual desktop instance may include making selected applications available to end users through a desktop application management module interface, according to the constraints and configuration parameter settings for the selected applications and users. In some cases, this may include installing any required applications and/or making certain applications (e.g., those applications that are assigned to a particular end user or those an end user is allowed to know about) visible and/or selectable through a desktop application management module interface or (once they are installed on an end user machine or in a virtual desktop instance) through an icon, shortcut, menu element, or other user interface mechanism or element thereof that was created on the desktop for the application and whose selection launches the application."; Paragraph 127, "In some embodiments, each of the virtualized applications that are packaged by the packager may be isolated into a container, such that the contents of each container is executed in isolation by the runtime engine and the individual applications do not know anything about each other. This isolation may allow multiple generations and/or versions of an application to execute on the same physical machine. In various embodiments, and depending on various settings (e.g., off-line or on-line only), the page blocks that make up a virtualized application may or may not be stored locally on the end user's machine during (or following) their execution by the runtime engine."; Paragraph 242, "System memory 1420 may be configured to store instructions and data accessible by processor(s) 1410. In various embodiments, system memory 1420 may be implemented using any suitable memory technology, such as static random access memory (SRAM), synchronous dynamic RAM (SDRAM), nonvolatile/Flash-type memory, or any other type of memory. In the illustrated embodiment, program instructions and data implementing one or more desired functions, such as those methods, techniques, and data described above for providing on-demand delivery of desktop applications to desktops on physical computing devices or virtual desktops in a cloud computing environment, are shown stored within system memory 1420 as code 1427 and data 1426. For example, data 1426 may include information representing the assignment of selected applications to particular end users and/or user groups, constraints and/or configuration parameter settings for the selected applications, users, and catalogs, and may be stored in any of a variety of data structures or database tables within memory 1420 on one or more computing nodes of a service provider system and/or client computing device used in providing on -demand delivery of desktop applications, as described herein. In some embodiments, data 1426 may also include security tokens and/or unique identifiers of users and/or devices (physical computing devices, virtualized computing resource instances and/or virtual desktop instances), as described herein. In some embodiments, at least some of the data 1426 may be stored on a user volume within system memory 1420. In some embodiments, code 1427 may include application binaries or virtualized application packages (or portions thereof), a desktop application management module and/or an application delivery agent, at least some of which may be stored on a boot volume within system memory 1420.")
Claim(s) 7, 15, and 20 –
Koushik in view of Hamilton II discloses the limitations of claims 1, 10, and 17
Koushik further discloses the following:
further cause the IHS to provide the temporary workspace to the end user via a thin client executed on the IHS. (Koushik: Paragraph 27, "As described in detail herein, an application fulfillment platform may off er customers ( or more specifically, IT administrators of those customers) the ability to provision applications on-demand at scale while maintaining centralized control, security and compliance. For example, in some embodiments, these platforms (and corresponding services thereof) may be integrated with a management console through which the IT administrators may discover and subscribe to a broad selection of applications from a variety of sources, build a catalog of applications from a variety of sources and having a variety of subscription/licensing models, control access to applications with granular access policy enforcement on a per user basis, manage application updates, access detailed usage reports for their enterprise, application portfolios and end users, and/or monitor real-time installs as well as license activation on a per application basis."; Paragraph 52, "In some embodiments, various components of a service provider network may be configured for the generation and management of remote computing sessions between client computing devices and virtual desktop instances hosted by one or more remote data center computers of a Program Execution Service (PES) platform. A number of data centers may be organized as part of a single PES platform that can facilitate the utilization of resources of the data centers by customers of the PES. In some embodiments, the PES may include several hundreds or thousands of data center computers. For example, in some embodiments, client computing devices may access the virtual desktop instances during one or more remote computing sessions, and a virtual desktop instance may provide a user with all of the capabilities of a client desktop environment but with centralized provisioning of the services accessed by the client."; Paragraph 72, "At least some networks in which embodiments of the techniques described herein for providing on -demand delivery of desktop applications to virtual desktops in a cloud computing environment may include hardware virtualization technology that enables multiple operating systems to run concurrently on a host computer (e.g., hosts 520A and 520B of FIG. 5), i.e. as virtual machines (VMs) 524 on the hosts 520. The VMs 524 (some of which may be configured to implement a virtual desktop instance for the use of a client) may, for example, be rented or leased to clients of a network provider. A hypervisor, or virtual machine monitor (VMM) 522, on a host 520 may serve as an instance manager for the VMs 524 and/or other virtualized resource instances on the hosts 520, which may include presenting the VMs 524 on the host with a virtual platform and monitoring the execution of the VMs 524. Each VM 524 may be provided with one or more private IP addresses; the VMM 522 on a host 520 may be aware of the private IP addresses of the VMs 524 on the host. A mapping service 530 may be aware of all network IP prefixes and the IP addresses of routers or other devices serving IP addresses on the local network. This includes the IP addresses of the VMMs 522 serving multiple VMs 524. The mapping service 530 may be centralized, for example on a server system, or alternatively may be distributed among two or more server systems or other devices on the network. A network may, for example, use the mapping service technology and IP tunneling technology to, for example, route data packets between VMs 524 on different hosts 520 within the data center 500 network; note that an interior gateway protocol (IGP) may be used to exchange routing information within such a local network.") Examiner equates the architectural structure disclosed for providing workspaces as shown in the cited portions to be equivalent to a thin client as understood both in view of Applicant's specification and under broadest reasonable interpretation by one of ordinary skill in the art.
Claim(s) 8 –
Koushik in view of Hamilton II discloses the limitations of claims 1 and 7
Koushik further discloses the following:
wherein the thin client comprises a Web View client (Koushik: Paragraph 48, "FIG. 3 is a block diagram of another example provider network environment, one that provides a storage virtualization service and a hard ware virtualization service to clients, according to at least some embodiments. In this example, hardware virtualization service 320 provides multiple computation resources 324 (e.g., VMs) to clients. The computation resources 324 may, for example, be rented or leased to clients of the provider network 300 (e.g., to a client that implements client network 350). As noted in the previous example, in some embodiments, provider network 300 may also provide application virtualization for the benefit of its customers and their end users (e.g., through a packaging service), and may provide on-demand delivery of desktop applications to desktops on physical computing devices and/or virtual desktops through an application fulfillment platform implemented using various resources of service provider network 300. In this example, each computation resource 324 may be provided with one or more private IP addresses. Provider network 300 may be configured to route packets from the private IP addresses of the computation resources 324 to public Internet destinations, and from public Internet sources to the computation resources 324."; Paragraph 77, "Note that a public network may be broadly defined as a network that provides open access to and interconnectivity among a plurality of entities. The Internet, or World Wide Web (WWW) is an example of a public network. A shared network may be broadly defined as a network to which access is limited to two or more entities, in contrast to a public network to which access is not generally limited. A shared network may, for example, include one or more local area networks (LANs) and/or data center networks, or two or more LAN s or data center networks that are interconnected to form a wide area network (WAN). Examples of shared networks may include, but are not limited to, corporate networks and other enterprise networks. A shared network may be anywhere in scope from a network that covers a local area to a global network. Note that a shared network may share at least some network infrastructure with a public network, and that a shared network may be coupled to one or more other networks, which may include a public network, with controlled access between the other network(s) and the shared network. A shared network may also be viewed as a private network, in contrast to a public network such as the Internet. In embodiments, either a shared network or a public network may serve as an intermediate network between a provider network and a client network, or between a provider network and other network entities (e.g., external resources, computing systems, data centers, or Internet destinations on networks other than the provider network and the client network on whose behalf VMs 524 are hosted by the provider)."; Paragraph 56, "FIG. 4 is a block diagram illustrating an example networked computing environment 400 that includes a client computing device 406 in communication with a service provider computer network 405 via the communication network 404. The client computing device 406 may be used for providing access to a remote operating system and applications to a user. In various embodiments, the client computing device 406 may correspond to a wide variety of computing devices including personal computing devices, laptop computing devices, hand-held computing devices, terminal computing devices, mobile devices (e.g., mobile phones, tablet computing devices, electronic book readers, etc.), wireless devices, various electronic devices and appliances, and the like. In some embodiments, the client computing device 406 includes necessary hardware and software components for establishing communications over a communication network 404, such as a wide area network or local area network. For example, the client computing device 406 may be equipped with networking equipment and browser software applications that facilitate communications via the Internet or an intranet. The client computing device 406 may have varied local computing resources such as central processing units and architectures, memory, mass storage, graphics processing units, communication network availability and bandwidth, etc."; Paragraph 80, "In various embodiments, a service provider may employ one of the example provider networks described above (or another suitable provider network environment) to implement a hosted desktop service in a cloud computing environment. In such embodiments, a customer may access the provider network in the cloud computing environment to request the instantiation and/or configuration of one or more virtual desktop instances in the cloud, and may then provide access to those virtual desktop instances to one or more end users (e.g., through a client application). For example, an administrator within an organization or enterprise may set up an account with a service provider, may contract with the service provider to set up some number of virtual desktop instances, and (once the virtual desktop instances are set up), may provide credentials for accessing these virtual desktop instances. In this example, once the virtual desktop instances have been set up and credentials have been provided, one or more end users may launch a client application on their a client device (e.g., a computer, tablet device, or other mobile device) and enter the credentials for the virtual desktop instance, after which they may be logged into a virtual desktop environment. Although the virtual desktop environment is implemented by virtualized resource instances in the cloud computing environment, it may appear to the end user as if it were a local desktop and it may operate as if it were an independent computer to which the user is connected. In some embodiments, the virtual desktop environment may provide access to productivity software and other software programs to which the user would typically have access if the user were logged onto a physical computer owned by the organization or enterprise. In at least some embodiments, an application fulfillment platform of the service provider may be configured to provide on-demand delivery of desktop applications (e.g., as virtualized application packages) to virtual desktop instances, as described herein.")
Claim(s) 9 and 16 –
Koushik in view of Hamilton II discloses the limitations of claims 1 and 10
Koushik further discloses the following:
when the IHS is to replace an existing IHS, copy one or more settings on the existing IHS to the temporary workspace. (Koushik: Paragraph 81, "In some embodiments, these virtual desktop instances may be intended to replace a desktop computer, e.g., they may be intended to run the same software programs that a member of the organization or enterprise on whose behalf they were instantiated and configured would access on a desktop computer in an office setting (e.g., applications that perform end-user productivity tasks). Note that these applications may or may not be stand-alone applications. For example, in some cases, each of the virtual desktop instances (and/or the applications running thereon) may be part of the active directory framework of the organization or enterprise and may be able to access shared files or other resources on the existing network of the organization or enterprise once the credentials presented by the user upon logging into the virtual desktop instance have been authenticated."; Paragraph 62, "In various embodiments, the desktop stores may be distributed across multiple servers, they may be replicated for performance purposes on servers in different network areas, or they may be replicated across multiple servers with independent failure profiles for backup or fault performance purposes. For example, the servers may be attached to different power sources or cooling systems, the servers may be located in different rooms of a data center or in different data centers, and/or the servers may be attached to different routers or network switches. In some embodiments, a desktop store may be located on one storage server, and changes made to the desktop store may be replicated to another desktop store on a different storage server. Such replication may create a backup copy of the user's data. If the desktop store fails or the virtual desktop instance 414 loses its connection to the desktop store, the PES 402 may switch the connection of the virtual desktop instance 414 from the desktop store to the backup desktop store."; Paragraph 141, "In some embodiments, when a software vendor provides an update to the application fulfillment platform ( or to the service provider) the service provider may (e.g., through the application fulfillment platform) publish the update and make it available to end users (e.g., through the desktop application management module. In some embodiments, the IT administrator may be able to control the maintenance window in which application updates are applied to the computing resource instances of its end users. In such embodiments, if an end user is using an application that is targeted for an update during the maintenance window, the end user will not experience any interruption, because the update will occur in the background. However, the next time the end user launches the application, the update will be applied. In some embodiments, there may be a notification engine within the desktop application management module that is configured to inform end users of upcoming application updates and newly available features. The notification engine may be accessed through the desktop application management module graphical user interface ( e.g., using the "notifications" tab shown in FIGS. 7 A and 7B), or using other mechanisms, in different embodiments. For example, if the IT administrator has made new optional applications available for end users to subscribe to, they may be notified through the desktop application management module. In some embodiments, the application fulfillment platform may preserve application state by automatically backing up applications and application data for subsequent copy or restore operations. For example, if the virtual desktop instance is rebuilt, the applications and application data may be automatically restored on the virtual desktop instance. Similarly, upon rebooting an end user's machine after a failure, the virtual desktop instance may automatically be rebuilt, and the applications and application data may be automatically restored.")
Claim(s) 11 –
Koushik in view of Hamilton II discloses the limitations of claim 10
Koushik further discloses the following:
further comprising executing the temporary workspace external to the IHS in a cloud-based VDI environment. (Koushik: Paragraph 51, "While not shown in FIG. 3, the virtualization service(s) may also be accessed from resource instances within the provider network 300 via API(s) 302. For example, a client, appliance service provider, or other entity may access a virtualization service from within a respective private network on the provider network 300 via an API 302 to request allocation of one or more resource instances within the private network or within another private network. Note that in some embodiments, the hardware virtualization service 320 may be configured to provide computation resources 324 that have been configured to implement a virtual desktop instance, which may appear to the user as a local desktop (implemented by a virtual computing system 392). Note also that in some embodiments, the computation resources 324 that are made available to the client via hardware virtualization service 320 may include multiple network interfaces. For example, some of them may include one network interface for communicating with various components of client network 350 and another network interface for communicating with computation resources or other network entities on another network that is external to provider network 200 (not shown)."; Paragraph 74, "In some embodiments, the data center 500 network may implement IP tunneling technology, mapping service technology, and a routing service technology to route traffic to and from virtualized resources, for example to route packets from the VMs 524 on hosts 520 in data center 500 to Internet destinations, and from Internet sources to the VMs 524. Internet sources and destinations may, for example, include computing systems 570 connected to the intermediate network 540 and computing systems 552 connected to local networks 550 that connect to the intermediate network 540 (e.g., via edge router(s) 514 that connect the network 550 to Internet transit providers). The provider data center 500 network may also route packets between resources in data center 500, for example from a VM 524 on a host 520 in data center 500 to other VMs 524 on the same host or on other hosts 520 in data center 500. In some embodiments, at least some of the VMs 524 may include two or more network interfaces. For example, they may include one network interface usable for communications between VMs 524 and the clients on whose behalf VMs 524 are hosted by the provider and a second (separate and distinct) network interface that is usable to access external resources, computing systems, data centers, or Internet destinations on networks other than the provider network and the client network, either or both of which may employ an IP tunneling technology, as described herein. In other embodiments, each of the VMs 524 may include only a single network interface.")
Conclusion
Applicant's amendment necessitated the new ground(s) 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 Philip N Warner whose telephone number is (571)270-7407. The examiner can normally be reached Monday-Friday 7am-4: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, Jerry O’Connor can be reached at 571-272-6787. 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.
/Philip N Warner/Examiner, Art Unit 3624
/Jerry O'Connor/Supervisory Patent Examiner,Group Art Unit 3624