Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-3 and 5-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Where applicant acts as his or her own lexicographer to specifically define a term of a claim contrary to its ordinary meaning, the written description must clearly redefine the claim term and set forth the uncommon definition so as to put one reasonably skilled in the art on notice that the applicant intended to so redefine that claim term. Process Control Corp. v. HydReclaim Corp., 190 F.3d 1350, 1357, 52 USPQ2d 1029, 1033 (Fed. Cir. 1999). The term “host operating system” in claim 5, 7and 10 are used by the claim to mean “an operating system that is run on a virtual machine,” while the accepted meaning is “a operating system that is host a virtual machine itself.” The term is indefinite because the specification does not clearly redefine the term. Note attached NPL reference Sangfor that indicates the difference between the two. A host operating system is a primary operating system that runs on a computer hardware. It creates a virtual layer that virtual machines further run on to operate their systems. A guest operating system runs within a virtual machine and is used to host and run programs and applications on it. The context used in the specification and the claims appear to equate the identified host operating system to the functionality of the guest operating system in that it is used to run the programs and applications in the instantiated virtual machine that is imaged and deployed to the user computing environment. Thus for the remaining examination of the application, “host operating system” is considered to be the either the “guest operating system” or a “required program”, as a host operating system is considered a program, necessary for execution of the application.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 5-6, 9-10, 12-16 and 18-20 are is/are rejected under 35 U.S.C. 103 as being unpatentable over STEINWAGNER (Publication 2008/0082976) in view of CHAKRABORTY (Publication 2006/0218544) in further view of STEFANOV (Publication 2023/0176839).
As to claim 1, STEINWAGNER teaches a method for smart image preparation for secure workspaces, the method comprising:
receiving, at a management service executing on a management server, a request to deploy an application to a first user computing device ([0074] In the example of FIG. 4, an order from a customer for a product application may be received (402). For example, as shown in FIG. 1, the customer 134 may submit an order 138 that may be received at the host device 126. The order 138, for example, may contain information specifying one or more of a guest operating system 114, prerequisite applications and/or which end user devices 136A,B may need to be provided the product application 118. Or, the order 138 may simply contain a request for the product application 118, and the software provider may determine these and other parameters.);
in response to the request, obtaining an image of an operating system that is installed on the first user computing device ([0075] The operating environment of a virtual machine running on virtualization software of a host device may be configured, based on the order (404). For example, the configuration logic 104 may configure the operating environment 112 of the virtual machine 122 running on the workstation virtualization software (workstation virtualization software) 124 or the server virtualization software of the host device 126, based on the order 138.
[0076] A guest operating system to include on the operating environment may be determined, based on the product application and/or the order (406). For example, the configuration logic 104 may determine which operating system to install on the operating environment 112 as the guest operating system 114. In an example embodiment, the order 138 may include an operating system required by the customer 134, such as Microsoft Windows.TM.. In another embodiment the guest operating system 114 may be determined based on compatibility with the product application 118.
[0077] The guest operating system may then be configured on the operating environment (408). For example, after the configuration logic 104 determines which operating system to use as the guest operating system 114, the configuration logic 104 may then be used to install the guest operating system 114 onto the operating environment 112 of the virtual machine 122.
[0078] After the guest operating system is configured on the operating environment, it may be determined whether the product application requires a prerequisite application (410). If a prerequisite application is required, then the prerequisite application may be configured (412). For example, the configuration logic 104 may determine that the product application 118 requires a prerequisite application 116 (such as a database) in order to function properly. Then for example, the configuration logic 104 may install the prerequisite application 116 on the guest operating system 114. In another example, the customer 134 may specify a prerequisite application 116 to be configured on the guest operating system 114.
[0079] If no prerequisite application is required, or else after any required prerequisite application(s) are configured, the product application may be installed (414). For example, the installation logic 106 may install the product application 118 onto the guest operating system 114.
[0080] After the product application has been installed, it may be determined whether the product application needs to be instantiated (416). If so, then product application may be instantiated. For example, product application 118 may require a long boot-up and set-up time upon execution. In such a case, the installation logic 106 may instantiate the product application 118 to avoid the customer 134 from having to re-instantiate the product application 118 on each execution.
[0081] After the product application is instantiated, or else after it is determined that no instantiation is required, an image of the virtual machine, including the product application, may be captured (420). For example, the capture logic 108 of the application distribution system 102 may capture an image 120 of the virtual machine 122, including the product application 118. The image 120 may include a snapshot of each virtual machine 122 component, including the operating environment 112, guest operating system 114, prerequisite application 116, and product application 118. As shown in FIG. 3, the image 120 may also include some capture logic 108 functionality, wherein additional images 120 may be captured. The captured image 120 may allow the virtual machine 122 to be restored back to the state it was in when the image 120 was captured.);
in response to the request, providing the application and the image of the operation system to an deployment service (product application distribution system that includes configuration logic, installation logic, capture logic and deployment logic) ([0018] Thus, the product application distribution system 102, running on the virtual machine 122 of the workstation virtualization software 124, may be used to install a product application 118 on the virtual machine 122. As referenced above, the product application 118 may represent or include software provided by a software provider that is ready for deployment to a customer or other recipient. The software developer, for example, may have already coded, debugged, and tested the product application 118 and may be ready to deploy the product application 118 (or an updated version of the product application 118) to one or more of its customers, represented in FIG. 1 by customer 134.
[0020] In the example of FIG. 1, the product application distribution system 102 may include configuration logic 104, installation logic 106, capture logic 108, and deployment logic 110. The product application distribution system 102 and the logic components 104-110 represent example components that may be constructed and used in the manner(s) described below. However, such examples are not limiting, and it should be understood that features and functionalities of the product application distribution system 102 and the logic components 104-110, and other components (not shown) may overlap and/or be shared there-between, and/or may be located elsewhere than is illustrated in FIG. 1. For example, the product application distribution system 102, or components 104-110 thereof, may be run in an operating environment 112 and/or a guest operating system 114. Further, various aspects of the product application distribution system 102 and/or the logic components 104-110 may be performed or directed by human users, as well.;
[0075-0079]; [0080] After the product application has been installed, it may be determined whether the product application needs to be instantiated (416). If so, then product application may be instantiated. For example, product application 118 may require a long boot-up and set-up time upon execution. In such a case, the installation logic 106 may instantiate the product application 118 to avoid the customer 134 from having to re-instantiate the product application 118 on each execution.
[0081] After the product application is instantiated, or else after it is determined that no instantiation is required, an image of the virtual machine, including the product application, may be captured (420). For example, the capture logic 108 of the application distribution system 102 may capture an image 120 of the virtual machine 122, including the product application 118. The image 120 may include a snapshot of each virtual machine 122 component, including the operating environment 112, guest operating system 114, prerequisite application 116, and product application 118. As shown in FIG. 3, the image 120 may also include some capture logic 108 functionality, wherein additional images 120 may be captured. The captured image 120 may allow the virtual machine 122 to be restored back to the state it was in when the image 120 was captured.
[0082] After the image is captured, an expiration date may be applied to the image (422, 424). For example, the capture logic 108 may determine that an expiration date 128 should be applied to the image 120, and then the capture logic 108 may apply the expiration date 128. The expiration date 128 may be a date or time period that when reached, may alter the operation of at least part of the image 120.
[0083] After the image is captured, a seal may be applied to the image if is determined that the customer needs to be prevented from accessing a part of the image (426, 428). For example, the capture logic 108 may determine that the customer 134 (or any other user) may not remove the product application 118 from the guest operating system 114 and thus may apply a seal 130 preventing removal of the product application 118 to the image 122.);
creating, by the deployment service, a virtual machine using the image of the operating system such that the virtual machine includes the operating system ([0025] The prerequisite application 116 may include any software program, application, plug-in, or code that may be required or recommended in order for the product application 118 to be installed and/or operated on the guest operating system 114. The prerequisite application 116 may provide a utility, library, database, and/or function used by the guest operating system 114 and/or the product application. For example, the prerequisite application 116 may be a database or database product application that may be accessed by the product application 118, so that the prerequisite application 116 must be installed or the product application 118 to function properly. In another example, the prerequisite application 116 may include a suite of tools, such as in the Java.TM. Development Kit example just mentioned, which may include, for example, a compiler, software libraries, a document generator and a debugger.
[0081] After the product application is instantiated, or else after it is determined that no instantiation is required, an image of the virtual machine, including the product application, may be captured (420). For example, the capture logic 108 of the application distribution system 102 may capture an image 120 of the virtual machine 122, including the product application 118. The image 120 may include a snapshot of each virtual machine 122 component, including the operating environment 112, guest operating system 114, prerequisite application 116, and product application 118. As shown in FIG. 3, the image 120 may also include some capture logic 108 functionality, wherein additional images 120 may be captured. The captured image 120 may allow the virtual machine 122 to be restored back to the state it was in when the image 120 was captured.
[0082] After the image is captured, an expiration date may be applied to the image (422, 424). For example, the capture logic 108 may determine that an expiration date 128 should be applied to the image 120, and then the capture logic 108 may apply the expiration date 128. The expiration date 128 may be a date or time period that when reached, may alter the operation of at least part of the image 120.
[0083] After the image is captured, a seal may be applied to the image if is determined that the customer needs to be prevented from accessing a part of the image (426, 428). For example, the capture logic 108 may determine that the customer 134 (or any other user) may not remove the product application 118 from the guest operating system 114 and thus may apply a seal 130 preventing removal of the product application 118 to the image 122.
[0084] Instructions for the customer to operate the product application based on the image may be provided (430). For example, the deployment logic 110 may provide instructions 132 to the local end user device 136A that detail how to install the player virtualization software (PVS) 124B, implement the image 120 with the PVS 124B and/or operate the product application 118.
[0085] Finally, the image may be provided wherein the customer may access the host device through a browser or remote desktop connection and operate the application (432, 434). For example, in FIG. 3, the image 120 has already been captured. Then for example, the end user device 306A may use either a browser 308 or remote desktop connection 310 to communicate with the host device 126 running the server virtualization software (server virtualization software) 302 over a network. Upon receiving the connection from the end user device 306A, the server virtualization software 302 may instantiate a virtual machine instance 122 based on the image 120. Then for example, the end user device 306A may operate the product application 118 in the guest operating system 114 of the operating environment 112 of the virtual machine 122 running on the server virtualization software 302 of the host device 126. Then for example, the end user device 306B may also connect to the host device 126 and may operate the product application 118 based on the image 120 (or another image, not shown) in a second virtual machine instance 304.
[0086] Although the above examples have been provided for the sake of explanation, it should be understood that many other embodiments may be implemented. For example, the image 120 may be provided in numerous other ways, other than those presented above.);
installing the application in the virtual machine ([0081-0086]);
creating an image of the virtual machine, the image of the virtual machine including the operating system and the application ([0081-0086]); and
providing the image of the virtual machine to the first user computing device for deployment to the first user computing device ([0081-0086], abstract; [0018] Thus, the product application distribution system 102, running on the virtual machine 122 of the workstation virtualization software 124, may be used to install a product application 118 on the virtual machine 122. As referenced above, the product application 118 may represent or include software provided by a software provider that is ready for deployment to a customer or other recipient. The software developer, for example, may have already coded, debugged, and tested the product application 118 and may be ready to deploy the product application 118 (or an updated version of the product application 118) to one or more of its customers, represented in FIG. 1 by customer 134.
[0019] By anticipating, for example, that the customer 134 will be running virtualization software that is the same or similar to the workstation virtualization software 124, the software provider may simply install the product application 118 directly onto the virtual machine 122, e.g., in whatever manner is considered to be the most efficient and effective. Then, as described in more detail below, the product application distribution system 102 may be used to capture an image 120 of the virtual machine 122, for shipment to the customer 134 and subsequent execution thereof on the virtualization software anticipated to be installed on the customer side. In this way, the customer 134 may simply run the virtual machine 122, including the product application 118, without performing any installation or configuration thereof. Accordingly, an experience of the customer 134 may be improved, and the opportunity for error in installing the product application 118 on the customer side may be reduced or eliminated.).
PNG
media_image1.png
723
577
media_image1.png
Greyscale
STEINWAGNER does not explicitly state that the operating system is a host operating system. In the context used in the disclosure, the host operating system appears to run within the virtual machine and thus appears to operate as a guest virtual machine. Thus it would be obvious to one of ordinary skill in the art before the effective filing of the claimed invention that the guest operating system or required programs are considered to be the host operating system in instantiating a virtual machine image for deployment for a user computing environment.
Further CHAKRABORTY teaches when creating a virtual machine image for distribution the host operating system is factored into generation of the image ([0020; 0055; 0080-0081; 0102]; Fig. 2A; abstract). Therefore, it would be obvious to one of ordinary skill in the art before the effective filing of the claimed invention to combine CHAKRABORTY to the algorithm of STEINWAGNER in order to distribute a virtual disk image with a particular application in it to a number of users wherein the image caters to the applications system requirements ([0020]).
Further STEINWAGNER does not explicitly state that the image distribution system is an orchestrator system for distributing VM images.
STEFANOV teaches that a well known type of system for distributing systems are an orchestrator system (0038] In some instances, solution image(s) 240 can be initially created to include binary files and other dependencies (e.g., libraries or other resources) necessary for executing the binary files at the host infrastructure 202. The solution image(s) 240 can be published, as provided by the solution provider 210, at the central repository 240.
[0039] In some instances, a collection of files that describe the resources, including the solution images, of a containerized application and descriptor information including dependency information associated with the resources can be provided for the containerized application to the platform 230. For example, the collection of files can be Kubernetes manifest files that can describe a desired state of deployed artifacts at the host infrastructure 250. The collection of files and the descriptor information can be provided to a lifecycle management repository 220 at the platform 230. In some instances, the collection of files and the descriptor information associated with the containerized application can be simultaneously or sequentially provided with the publishing of the corresponding solution image associated with the containerized application.
[0050] In some instances, a user may request, through a lifecycle management orchestrator at the technology platform, to execute an operation to manage a containerized application. To be able to run a containerized application at a host infrastructure, a solution image can be initially created including binary files and other dependencies (e.g., libraries, or other resources) that are required to be able to run the containerized application at a container runtime environment (e.g., Docker). The solution image may be published at a central repository associated with the technology platform and the container runtime environment. Further, a collection of files that describe the resources of the containerized application and descriptor information including dependency information associated with the resources can be provided for the containerized application (e.g., from an end user associated with a solution provider that provides the containerized application). The collection of files and the descriptor information can define how to model the containerized application as a deployed image.
[0051] For example, a user (e.g., an end user of a customer of a provider of containerized application) can interact with the lifecycle management orchestrator to request to deploy a containerized application from a list of applications provided by an application provider. In some implementations, the lifecycle management orchestrator can provide a list of applications, as previously discussed, that can be based on created solution images at a central repository associated with the technology platform. The technology platform can be communicatively coupled to the host infrastructure to securely send instructions associated with execution of operations associated with containerized application to a node cluster on the host infrastructure.
[0024] In some instances, container orchestration can automate the deployment, management, scaling, and networking of containers. For example, container orchestration systems, in hand with underlying containers, enable applications to be executed across different environments (e.g., cloud computing environments) without needing to redesign the application for each environment. Enterprises that need to deploy and manage a significant number of containers (e.g., hundreds or thousands of containers) leverage container orchestration systems. An example container orchestration system is the Kubernetes platform, maintained by the Cloud Native Computing Foundation, which can be described as an open-source container orchestration system for automating computer application deployment, scaling, and management.
[0025] In some instances, customers of containerized application may need to process data on-premise because they cannot rely entirely on a cloud-based software. For example, customers in manufacturing plants, on oil rigs, and in many other operations often face the situation that their Internet connectivity is not reliable or has latency issues. In those cases, the operations of the customer need to proceed even if there are connectivity issues with cloud software. In those cases, part or a whole of a software solution can be executed on-premise as an alternative to the cloud environment that can be associated with connectivity drawbacks.
[0026] In some instances, an application can be executed in a hybrid environment where part of the application can run on the cloud and other parts can be on-premise. In some instances, cloud-based applications may need to consider computing scenarios where parts of a cloud solution (e.g., the application or the system) can be redeployed to run on network computing devices in an isolated customer's network (e.g., with no access from the Internet). In some instances, a customer may consider using customer network computing devices to run containerized application. The computing devices can include node clusters as a container runtime environment. In some instances, the network computing devices can support execution of containerized application at the container runtime environment, and/or the lifecycle of containerized applications can be managed through a lifecycle management orchestrator at a technology platform accessible to customers. The technology platform can provide services that support bringing data processing, analytics, integrations, and extensibility, among other capabilities, at a single place accessible to end customers.).
Therefore, it would be obvious to implement the algorithm of STEINWAGNER using an orchestrator of STEFANOV in order to replicate an image of an application for deployment ([0012]).
As to claim 2, STEFANOV teaches the application is uploaded to the management server before the request is received ([0011] In some instances, the example method can further comprise: receiving, at a lifecycle management orchestrator, a request from a user to deploy the containerized application at the container runtime environment; in response to receiving the request, obtaining the collection of files and the descriptor information from a lifecycle management repository, wherein the collection of files is organized as a directory tree; and providing the obtained collection of files and the descriptor information to a container orchestration server running at the node cluster of the container runtime environment, wherein the container orchestration server registers the request from the user as the event associated with the containerized application that is detected.; FURTHER NOTE STEINWAGNER, [0018]).
As to claim 3, STEINWAGNER teaches creating the virtual machine comprises installing the operating system on the virtual machine ([0030-0034]). STEINWAGNER does not explicitly state that the operating system is a host operating system. In the context used in the disclosure, the host operating system appears to run within the virtual machine and thus appears to operate as a guest virtual machine. Thus it would be obvious to one of ordinary skill in the art before the effective filing of the claimed invention that the guest operating system or required programs are considered to be the host operating system in instantiating a virtual machine image for deployment for a user computing environment.
Further CHAKRABORTY teaches when creating a virtual machine image for distribution the host operating system is factored into generation of the image ([0020; 0055; 0080-0081; 0102]; Fig. 2A; abstract). Therefore, it would be obvious to one of ordinary skill in the art before the effective filing of the claimed invention to combine CHAKRABORTY to the algorithm of STEINWAGNER in order to distribute a virtual disk image with a particular application in it to a number of users wherein the image caters to the applications system requirements ([0020]).
As to claim 5, STEINWAGNER teaches the deployment service stores the image of the virtual machine and the management service accesses the image of the virtual machine and provides the image of the virtual machine to the first user computing device ([0018-0020, 0025, 0074-0086]).
Further STEINWAGNER does not explicitly state that the image distribution system is an orchestrator system for distributing VM images.
STEFANOV teaches that a well known type of system for distributing systems are an orchestrator system ([0024-0026, 0038-0039, 0050-0051]).
Therefore, it would be obvious to implement the algorithm of STEINWAGNER using an orchestrator of STEFANOV in order to replicate an image of an application for deployment ([0012]).
As to claim 6, STEINWAGNER teaches a plurality of user devices and providing the image to the devices ([0042-0044]) and thus teaches receiving, at the management service executing on the management server, a second request to deploy the application to a second user computing device ([0018-0020, 0025, 0074-0086]);
in response to the second request, obtaining a second image of a second operating system that is installed on the second user computing device ([0018-0020, 0025, 0074-0086]);
in response to the second request, providing the application and the second image of the second operation system to the deployment service ([0018-0020, 0025, 0074-0086]);
creating, by the deployment service, a second virtual machine using the second image of the second operating system such that the second virtual machine includes the second operating system ([0018-0020, 0025, 0074-0086]);
installing the application in the second virtual machine ([0018-0020, 0025, 0074-0086]);
creating a second image of the second virtual machine, the second image of the second virtual machine including the second operating system and the application ([0018-0020, 0025, 0074-0086]); and
providing the second image of the second virtual machine to the second user computing device for deployment to the second user computing device ([0018-0020, 0025, 0074-0086]).
STEINWAGNER does not explicitly state that the operating system is a host operating system. In the context used in the disclosure, the host operating system appears to run within the virtual machine and thus appears to operate as a guest virtual machine. Thus it would be obvious to one of ordinary skill in the art before the effective filing of the claimed invention that the guest operating system or required programs are considered to be the host operating system in instantiating a virtual machine image for deployment for a user computing environment.
Further CHAKRABORTY teaches when creating a virtual machine image for distribution the host operating system is factored into generation of the image ([0020; 0055; 0080-0081; 0102]; Fig. 2A; abstract). Therefore, it would be obvious to one of ordinary skill in the art before the effective filing of the claimed invention to combine CHAKRABORTY to the algorithm of STEINWAGNER in order to distribute a virtual disk image with a particular application in it to a number of users wherein the image caters to the applications system requirements ([0020]).
Further STEINWAGNER does not explicitly state that the image distribution system is an orchestrator system for distributing VM images to secure environments.
STEFANOV teaches that a well known type of system for distributing systems are an orchestrator system ([0024-0026, 0038-0039, 0050-0051]).
Therefore, it would be obvious to implement the algorithm of STEINWAGNER using an orchestrator of STEFANOV in order to replicate an image of an application for deployment ([0012]).
As to claims 9-10 and 14, reference is made to a computer storage media that corresponds to the method of claims 1, 6 and 5 respectfully and thus is rejected by claims 1, 6 and 5 above.
As to claim 12, STEFANOV teaches the request is received from an administrator ([0037] In some instances, a solution provider 210 can be a user (e.g., a developer or administrator) or an application associated with a provider of software application. The solution provider 210 can be an entity associated with a provider of software application that can publish the solution images 240 at a central repository 235. The central repository 235 can be a central container registry where all solution images 240 associated with the platform 230 (and, in some instances, with multiple corresponding customers) are stored.).
As to claim 13, STEFANOV teaches creating the secure workspace on the first user computing device; and attaching the image of the virtual machine to the secure workspace (running of the deployed containerized application in a Docker / cluster / partially cloud and on-premise) ([0050-0055]).
As to claim 15, STEINWAGNER teaches a plurality of user devices and providing the image to the devices ([0042-0044]) and thus teaches in response to a second request to deploy a second application on a second user computing device, requesting that the deployment service install the second application in a second virtual machine ([0018-0020, 0025, 0074-0086]);
during the installation of the second application, monitoring artifacts that are created or modified by the installation (required files / programs) ([0018-0020, 0025, 0074-0086]);
creating a second image that includes the artifacts ([0018-0020, 0025, 0074-0086]); and
providing the second image to the second user computing device for deployment to the second user computing device ([0018-0020, 0025, 0074-0086]).
Further STEINWAGNER does not explicitly state that the image distribution system is an orchestrator system for distributing VM images to secure environments.
STEFANOV teaches that a well known type of system for distributing systems are an orchestrator system that installs to secure environments ([0024-0026, 0038-0039, 0050-0051]).
Therefore, it would be obvious to implement the algorithm of STEINWAGNER using an orchestrator of STEFANOV in order to replicate an image of an application for deployment ([0012]).
As to claim 16, STEINWAGNER teaches the artifacts include files and registry entries (0024-0026).
As to claims 18 and 19, reference is made to a system that corresponds to the method of claims 1 and 6 respectfully and thus is rejected by claims 1 and 6 above. Claim 18 further details the system comprise a management server having a management service; an orchestrator having an orchestrator service; and one or more user computing devices including a first user computing device.
As to claim 20, STEINWAGNER teaches a plurality of user devices and providing the image to the devices ([0042-0044]) and thus teaches receiving, at the management service, a second request to deploy a second application to a second user computing device of the one or more user computing devices([0018-0020, 0025, 0074-0086]);
requesting that the deployment service installs the second application in a second virtual machine ([0018-0020, 0025, 0074-0086]);
during installation of the second application, monitoring artifacts (required programs) that are created or modified by the installation ([0018-0020, 0025, 0074-0086]);
creating a second image that includes the artifacts ([0018-0020, 0025, 0074-0086]); and
providing the second image to the second user computing device to cause the second image to be attached to the second user computing device ([0018-0020, 0025, 0074-0086]).
Further STEINWAGNER does not explicitly state that the image distribution system is an orchestrator system for distributing VM images to secure environments.
STEFANOV teaches that a well known type of system for distributing systems are an orchestrator system that installs to secure environments ([0024-0026, 0038-0039, 0050-0051]).
Therefore, it would be obvious to implement the algorithm of STEINWAGNER using an orchestrator of STEFANOV in order to replicate an image of an application for deployment ([0012]).
Claims 7, 8, 11 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over STEINWAGNER (Publication 2008/0082976) in view of CHAKRABORTY (Publication 2006/0218544) in further view of STEFANOV (Publication 2023/0176839) in further view of NIGUL (Publication 2017/0060556).
As to claim 7, STEINWAGNER teaches a plurality of user devices and providing the image to the devices ([0042-0044]) and thus teaches receiving, at the management service, a second request to deploy a second application to a second user computing device ([0018-0020, 0025, 0074-0086]);
in response to the second request, providing the second application to the orchestrator service ([0018-0020, 0025, 0074-0086]);
creating, by the deployment service, a second virtual machine ([0018-0020, 0025, 0074-0086]);
during installation of the second application on the second virtual machine, identifying, artifacts that are created or modified by the installation of the second application (required files) ([0018-0020, 0025, 0074-0086]);
creating a second image that includes the artifacts ([0018-0020, 0025, 0074-0086]); and
providing the second image to the second user computing device for deployment to the second user computing device ([0018-0020, 0025, 0074-0086]).
Further note STEFANOV [0046-0059]
Further STEINWAGNER does not explicitly state that the image distribution system is an orchestrator system for distributing VM images to secure environments.
STEFANOV teaches that a well known type of system for distributing systems are an orchestrator system that installs to secure environments ([0024-0026, 0038-0039, 0050-0051]).
Therefore, it would be obvious to implement the algorithm of STEINWAGNER using an orchestrator of STEFANOV in order to replicate an image of an application for deployment ([0012]).
While STEINWAGNER- STEFANOV teaches monitoring of files for deployment and installation, it does not teach installing agents for such purpose.
NIGUL teaches installing a file system monitor agent and a file system monitor driver on the second virtual machine; identifying, by the file system monitor driver, artifacts that are created or modified by the installation of the second application ([0023] In some embodiments, the support products are installed on production server 120. In other embodiments, the support products are installed on support system monitor 220. Monitoring agent 221 is a computer agent (e.g., application or product), running on support system monitor 220, that detects requests for artifacts corresponding to the installed software image. Monitoring agent 221 may provide details of the requested artifacts to rule definition module 112.
[0024] When an updated software image is deployed, the previously deployed software image may be either removed or completely overlaid. After the deployment operation, modifications may be required to various configuration files to enable the newly deployed software image to become available for use. Additionally, during day to day operation of the deployed software image, various artifacts (i.e., log files, trace files, dump files, and the like) may be modified. Application monitor 224 may detect any modifications to artifacts in the deployed software image. Additionally, monitoring agent 225 may report to monitoring server 110 the detected modifications. Application monitor 224 and monitoring agent 225 continually monitor the deployed software image for activity that modifies any artifacts, and monitoring agent 225 continually reports modifications to monitoring server 110.
[0025] Additionally, environment monitor 222 also continually monitors the environment for modifications affecting the deployed software image. For example, environment monitor 222 may detect changes to database connection documents, files system permissions, antivirus automated updates, system configuration files, and the like. Monitoring agent 223 may report to monitoring server 110 any environmental modifications detected that may affect the deployed software image.)
Therefore, it would be obvious to one of ordinary skilled in the art before the effective filing of the claimed invention to combine the teachings of NIGUL to the invention of STEINWAGNER- CHAKRABORTY-STEFANOV in order to determine whether required artifacts should be preserved ([0003]).
As to claim 8, While STEINWAGNER- STEFANOV teaches monitoring of files for deployment and installation, it does not teach installing agents for such purpose.
NIGUL teaches the file system monitor driver provides the artifacts to the file system monitor agent ([0023-0025]).
Therefore, it would be obvious to one of ordinary skilled in the art before the effective filing of the claimed invention to combine the teachings of NIGUL to the invention of STEINWAGNER- CHAKRABORTY-STEFANOV in order to determine whether required artifacts should be preserved ([0003]).
As to claim 17, While STEINWAGNER- STEFANOV teaches monitoring of files for deployment and installation, it does not teach installing agents for such purpose.
NIGUL teaches a file system monitor driver is installed in the second virtual machine to monitor the artifacts ([0023-0025]).
Therefore, it would be obvious to one of ordinary skilled in the art before the effective filing of the claimed invention to combine the teachings of NIGUL to the invention of STEINWAGNER- CHAKRABORTY-STEFANOV in order to determine whether required artifacts should be preserved ([0003]).
As to claims 11, reference is made to a computer storage media that corresponds to the method of claim 7 respectfully and thus is rejected by claim 7 above.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-3 and 5-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 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 LEWIS ALEXANDER BULLOCK JR whose telephone number is (571)272-3759. The examiner can normally be reached Monday-Friday, 9:00-5:00 pm.
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, Cordelia Zecher can be reached at 571-272-7771. 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.
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199