Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-5,7-15 and 17-23 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-5,7-8, 10-15, 17-18 and 20- 23 are rejected under 35 U.S.C. 103 as being unpatentable over Zada (US 20150154039 A6) in view of Moore (US 9530022 B1) and further view of Fries (US 20090328030 A1).
A method for installing an agent at one or more virtual machines (VMs) of a VM fleet, the method comprising. ([0105] As mentioned above, example methods and apparatus disclosed herein facilitate the automatic monitoring of resources in cloud environments and/or the automatic updating of monitoring configurations)
analyzing, by one or more processors, VM fleet data of the VM fleet. ([0007] FIG. 4 is a flowchart representative of example machine readable instructions which may be executed to implement the example service analyzer of FIG. 1 to determine VMs in an application. [0033] The example virtual infrastructure navigator 108 of FIG. 1 analyzes the application 102 including the VMs 114 to identify the configurations of the VMs 114. As VMs 114 are deployed, modified, and/or destroyed in the application 102, the example virtual infrastructure navigator 108 continues to analyze the configurations to identify changes in real time or near real time. To analyze the application 102 and/or the VMs 114, the example virtual infrastructure navigator 108 of FIG. 1 includes a service analyzer 120, a VM analyzer 122, an application configuration database 124, and an agent installer 126. The example virtual infrastructure navigator 108 of FIG. 1 is in communication with a discovery script repository 146. See also [0036] and [0075-0078])
determining, by the one or more processors, whether or not to transmit a message to a user interface based on the analysis of the VM fleet data, the message requesting a user input for updating the installation policy to install the agent at the VMs of the VM fleet, wherein the analysis of the VM fleet data includes at least one of: (I)determining a number of VMs in the VM fleet that do not have the agent installed or the agent is not up to date thereon, determining to transmit the message if the number of VMs meets or exceeds a predetermined threshold value, and determining not to transmit the message if the number of VMs is less than the predetermined threshold value; or. ([0051] FIG. 10 illustrates an example interface 1000 that may be presented by the example performance monitoring server 106 of FIG. 1. The example interface 1000 illustrates agent statuses 1002 for example VMs 1004-1016 following discovery of the VMs 1004-1016 in a deployment environment (e.g., the deployment environment 104 of FIG. 1). In the example of FIG. 10, the example VM 1004 has an installed agent, VMs 1006-1014 do not have an installed agent, and the VM 1016 has an unknown agent status (e.g., because the VM 1016 may be suspended).; See also [0019, 0043-0046, 0066-0071, 0080])
after creation of the one or more VMs of the VM fleet: receiving, by the one or more processors, the user input for updating the installation policy to install the agent at the one or more VMs of the VM fleet; updating, by the one or more processors, the installation policy based on the user input. ([0043-0046, 0066-0071] For example, the performance monitoring server 106 of FIG. 1 stores policies and/or rules to be implemented based on configurations of the VMs 114 and/or resources executing on the VMs 114. In some examples, the rules are defined by the administrator 116 and/or the developer 118 of FIG. 1 based on a desired monitoring configuration of the application 102. See also [0086-0089])
and installing, by the one or more processors, the agent at the one or more VMs according including the installation package to the policy. ([0043-0046, 0066-0071, 0084], If the selected VM 114 has a primary workload designated in the policy, the agent installer 126 initiates installation of an agent 132 on the selected VM 114 (block 510). For example, the agent installer 126 may instruct the VM 114 to install the agent 132 and provide the agent 132 to be installed or provide a pointer (e.g., a URL or other location) to the agent 132 and/or an installation package for the agent 132.)
Zada does not appear to teach performing an installation based on: (ii)an amount of time since the agent has been installed at any of the VMs in the VM fleet, determining to transmit the message if the amount of time is above a first threshold amount of time, and determining not to transmit the message if the amount of time is below the first threshold amount of time; or (iii) determining the amount of time since the agent has been installed at any of the VMs in the VM fleet, determining to transmit the message if the amount of time is below a second threshold amount of time, and determining not to transmit the message if the amount of time is above the second threshold amount of time in response to the determination to transmit the message, transmitting, by the one or more processors, the message to the user interface.
However, Moore teaches a well-known technique for performing an installation by considering ii)an amount of time since that software has been installed at any of the environments, determining to transmit the message if the amount of time is above a first threshold amount of time, and determining not to transmit the message if the amount of time is below the first threshold amount of time; or (iii) determining the amount of time since the software has been installed at any of the environments; determining to transmit the message if the amount of time is below a second threshold amount of time, and determining not to transmit the message if the amount of time is above the second threshold amount of time in response to the determination to transmit the message, transmitting, by the one or more processors, the message to the user interface.: col 7, line 55 - col 8, line 39. At block 204, one of the implementations is selected by the configuration controller, for example, for installation on one or more target systems. The selected implementation is installed on a target system at block 206. The installation of the implementation and further configuration of the target system, including actions of the identification function and operational functions of the implementation, are further shown in FIG. 3. For purposes of periodically selecting a new implementation to use in a subsequent installation(s), at block 207, the configuration controller tracks the installations of the current implementation by time or by number of target systems on which the implementation has been installed. The configuration controller also tracks the total number of target systems on which all implementations have been installed. For example, a manufacturer may be authorized to build only a certain number of systems and install the implementations on that number of systems. Decision block 208 tests whether or not a periodic threshold has been satisfied for use of the current implementation. For example, if the current implementation has been used for installations for a certain period of time, the periodic threshold is satisfied. Alternatively, if the current implementation has been installed on a threshold number of target systems, the periodic threshold is satisfied. If the periodic threshold has not yet been satisfied, the process returns to block 206, and installation of the current implementation on one or more target systems continues. If the periodic threshold is satisfied, the configuration controller determines at decision block 210 whether or not an installation threshold is satisfied. The installation threshold may be used to control the total number of target systems on which the alternative implementations are installed. If the installation threshold is not satisfied, another one of the implementations is selected at block 212. The implementation may be selected at random from a set of implementations that had been previously generated, for example. Once the periodic threshold has been reached for an implementation, that implementation may be removed from the set of implementations available for selection. The process then returns to block 206 and repeats installations of the newly selected implementation on one or more target systems. If the installation threshold has been satisfied, decision block 210 directs the process to block 214, where the configuration controller disables further installations of implementations on any target systems. FIG. 3 is a flowchart of a process showing installation of an implementation on a target electronic system 301. The process of FIG. 3 is an example of actions performed in support of the process block 206 of FIG. 2. At block 302, the configuration controller 102 downloads an implementation to a target system.
Accordingly, it would be obvious that the installation techniques of Moore is applicable to the base environment of Zada that installs agents into a VM based environment without undue experimentation and would lead to predictable results to one of ordinary skill in the art under MPEP 2143 (Use of Known Technique to Improve Similar Devices in the Same Way and Applying a Known Technique to a Known Device Ready for Improvement to Yield Predictable Results). Further, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, to have applied the well-known technique of Moore’s in the environment of Zada to use time based and installation based considerations in applying software installations into the VM environment and thereby improve maintenance and keep the systems up date.
Zada or Moore do not appear to teach: creating, by one or more processors, the one or more VMs of the VM fleet using a VM image, wherein the VM image is pre-packaged with an installation package for installation of the agent, wherein the installation package is installed at VMs created using the VM image, and wherein the agent is installed at the VMs including the installation package in accordance with a user-controlled installation policy;
However, Fries teaches: [0020] Implementations of the present invention extend to systems, methods, and computer program products configured to simplify installation of an operating system, such as a virtual machine operating system, and accompanying agents, such as third-party agents. In at least one implementation, for example, a management service can automatically insert an agent application into an operating system image prior to installation. The management service can further provide any required customizations or policies to the agent. The combined operating system image and inserted agent, and the provided policies can then be installed together at the same time at the appropriate installation location. Accordingly, implementations of the present invention allow for agents to begin executing immediately with installation of an instantiation of a given operating system (e.g., an instantiation of the virtual machine image), and in a much more reliable fashion. [0031] As shown in FIG. 1B for example, virtual machine management service 100 sends one or more instructions 170 which instruct physical host 140 to combine or insert the copied agent 110b and rules 120b into the virtual machine 135b image. With respect to a MICROSOFT operating environment, for example, the virtual machine management service 100 sends one or more commands such as "copy scom.exe to c:/windows/system32" to modify the image registry so that the agent "scom.exe" runs as a service when booted. As a preliminary matter, however, one will appreciate that reference to any particular operating system or operating environment is done by way of convenience in explanation. Specifically, implementations of the present invention can be applied to any operating system or operating environment. [0034] In any event, once all of the appropriate agent configurations and rules have been inserted into the virtual machine 135b template, this effectively creates a modified virtual machine image. Accordingly, FIG. 1B shows that physical host 140 now has a modified operating system image 175, which, in the illustrated case comprises the virtual machine image 135b from library 130 into which has been inserted agent 110b, and rules 120b. In this state, the modified operating system image 175 is now ready to be installed. Accordingly, FIG. 1B shows that virtual machine management service 100 sends one or more commands/instructions 180 to install the combined operating system image with the inserted agent(s) at physical host 140. See also [0045-0046]
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Zada, Moore, and Fries before them, to additionally include Fries’s pre-package of VM images with agents/configuration/policies so that the VMs created from that image already include the agent installation package and associated policy. One of ordinary skill in the art would have been motivated to use Fries’s image based agent insertion into Zada’s VM monitoring and management environment to improve agent roll out and ensure newly created VMs come with the needed management package and governing policy already embedded.
Regarding claims 2, Zada teaches:
The method of claim 1, wherein the message includes an indication of a plurality of the VMs included in the VM image, and wherein the user input includes a selection of VMs from the plurality of VMs indicated in the message, wherein the installation policy is updated for the selection of VMs based on the user input. (0043, FIG. 9 illustrates an example interface 900 that may be presented by the example virtual infrastructure navigator 108 (e.g., to the administrator 116 and/or the developer 118) of FIG. 1 to enable an initial configuration of agents 132 for installation on VMs 114 based on a management policy.; See also [0019, 0043-0046, 0066-0071, 0080])
Regarding claims 3, Zada teaches:
The method of claim 2, wherein the selection of VMs specifies at least one of a project, an operating system (OS), a distributed network region or a distributed network zone at which the policy is activated. (0043, Example configuration information includes a monitoring server IP address 902, an agent user name 904, an agent user password 906, an installation package location 908, a Linux platform installation directory 910, a Windows platform installation directory 912, an agent version 914, configuration of the agent 132 as a service 916, a secure connection configuration 918 to the performance monitoring server 106, a performance agent server port 920, a performance agent secure server port 922, a performance agent port 924, a unidirectional configuration 926 (e.g., configuring either the agent or the server to initiate all communications, or configuring the agent and the server to initiate respective communications), and/or a checksum hash value 928.; See also [0019, 0043-0046, 0066-0071, 0080])
Regarding claims 4, Zada teaches:
The method of claim 1, wherein the method further comprises: detecting, by the one or more processors, a user action; and transmitting, by the one or more processors, the message to the user interface in response to the user action. ([0043] In some examples, the policy or rule determines an initial configuration of the agent 132 installed on the VM 114. Example policies include configuring the agent 132 to communicate with one of multiple performance monitoring servers 106. FIG. 9; See also [0019, 0043-0046, 0066-0071, 0080])
Regarding claims 5, Zada teaches:
The method of claim 1, wherein the method further comprises: detecting, by the one or more processors, a user action; and transmitting, by the one or more processors, the message to the user interface in response to the user action. ([0043] In some examples, the policy or rule determines an initial configuration of the agent 132 installed on the VM 114. Example policies include configuring the agent 132 to communicate with one of multiple performance monitoring servers 106. FIG. 9 illustrates an example interface 900 that may be presented by the example virtual infrastructure navigator 108 (e.g., to the administrator 116 and/or the developer 118) of FIG. 1 to enable an initial configuration of agents 132 for installation on VMs 114 based on a management policy). This shows that the system sends a configuration message to the user interface on detected user inputs or actions; See also [0019, 0043-0046, 0066-0071, 0080])
Regarding claims 7, Zada teaches:
The method of claim 1, wherein transmitting the message to the user interface is performed at regular intervals. ([0067-0068, 0071] The example virtual infrastructure navigator 108 of FIG. 1 determines VMs 114 within an application definition (block 304). For example, the service analyzer 120 of FIG. 1 may determine whether any VMs have been added, removed, and/or modified from a previous application definition for the application 102. Following performance (e.g., execution of instructions) of block 304, the example performance monitoring server 106 may present an interface, such as the interface 1000 of FIG. 10, illustrating statuses of VMs 1004-1016 included in an application. (Fig.3 flowchart shows this process repeats))
Regarding claims 8, Zada teaches:
The method of claim 1, wherein installing the agent at the one or more VMs comprises assigning, by the one or more processors, a label to a plurality of VMs, the label indicating to install or update the agent at the plurality of VMs. (Fig 10 and 11 shows VMs with the label “Agent not installed”; see also [0051-0053])
Regarding claims 10, Zada teaches:
The method of claim 1, wherein the agent is an operational agent configured to collect telemetry data from the one or more VMs of the VM fleet. ([0071] The example agent monitors 130 of FIG. 1 receives resource report(s) for the new VM(s) from the installed agents (block 312). The resource reports may be generated by the agents 132 of FIG. 1 periodically, aperiodically, and/or in response to an event (e.g., on initial installation and/or execution of the agents 132).)
Regarding claims 11, Zada also teaches:
A system for installing an agent at one or more virtual machines (VMs) of a VM fleet comprising: one or more processors; and memory in communication with the one or more processors, wherein the memory contains instructions configured to cause the one or more processors to. ([0105] As mentioned above, example methods and apparatus disclosed herein facilitate the automatic monitoring of resources in cloud environments and/or the automatic updating of monitoring configurations)
The claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale.
Regarding claims 20, Zada also teaches:
The system of claim 11, further comprising a plurality of VMs included in the VM fleet. ([0030] The example application 102 of FIG. 1 includes multiple VMs 114. The example VMs 114 of FIG. 1 provide different functions within the application 102 (e.g., services, portions of the application 102, etc.).)
Regarding claims 21, Zada also teaches:
The method of claim 1, wherein the analysis of the VM fleet data includes determining the number of VMs in the VM fleet that do not have the agent installed or the agent is not up to date thereon, determining to transmit the message if the number of VMs meets or exceeds the predetermined threshold value, and determining not to transmit the message if the number of VMs is less than the predetermined threshold value. ([0051] FIG. 10 illustrates an example interface 1000 that may be presented by the example performance monitoring server 106 of FIG. 1. The example interface 1000 illustrates agent statuses 1002 for example VMs 1004-1016 following discovery of the VMs 1004-1016 in a deployment environment (e.g., the deployment environment 104 of FIG. 1). In the example of FIG. 10, the example VM 1004 has an installed agent, VMs 1006-1014 do not have an installed agent, and the VM 1016 has an unknown agent status (e.g., because the VM 1016 may be suspended); (see also figure 10-11 ([0013-0014]) that is presenting to a user that visually shows VM fleet and agent status).
Regarding claims 22, Moore also teaches:
The method of claim 1, wherein the analysis of the VM fleet data includes determining the amount of time since the agent has been installed at any of the VMs in the VM fleet, determining to transmit the message if the amount of time is above the first threshold amount of time, and determining not to transmit the message if the amount of time is below the first threshold amount of time, and wherein the first threshold amount of time corresponds to a maximum amount of time for the VM fleet to go without maintenance. (Moore col 7, line 55 - col 8, line 39)
Same motivation as claim 1.
Regarding claims 23, Zada also teaches:
The method of claim 1, wherein the analysis of the VM fleet data includes determining the amount of time since the agent has been installed at any of the VMs in the VM fleet, determining to transmit the message if the amount of time is below the second threshold amount of time, and determining not to transmit the message if the amount of time is above the second threshold amount of time, wherein the second threshold amount of time corresponds an amount of time after the user's previous installation of the agent in the VM fleet that the user's willingness to install the agent at other VMs is increased. (Moore col 7, line 55 - col 8, line 39)
Same motivation as claim 1.
Regarding claim 12, the claim recites similar limitation as corresponding claim 2 and is rejected for similar reasons as claim 2 using similar teachings and rationale.
Regarding claim 13, the claim recites similar limitation as corresponding claim 3 and is rejected for similar reasons as claim 3 using similar teachings and rationale.
Regarding claim 14, the claim recites similar limitation as corresponding claim 4 and is rejected for similar reasons as claim 4 using similar teachings and rationale.
Regarding claim 15, the claim recites similar limitation as corresponding claim 5 and is rejected for similar reasons as claim 5 using similar teachings and rationale.
Regarding claim 17, the claim recites similar limitation as corresponding claim 7 and is rejected for similar reasons as claim 7 using similar teachings and rationale.
Regarding claim 18, the claim recites similar limitation as corresponding claim 8 and is rejected for similar reasons as claim 8 using similar teachings and rationale.
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Zada (US 20150154039 A6) in view of Moore (US 9530022 B1) and Fries (US 20090328030 A1).and further view of Shah (US 20130326505 A1).
Regarding claims 9, Zada does not appear to teach:
The method of claim 8, wherein installing the agent at the plurality of VMs is performed asynchronously at regular intervals, wherein an order in which the agent is installed at the plurality of VMs is based on the assigned labels.
However, Shah teaches [0038] In one embodiment, the VM monitor 305 may monitor a virtual machine to determine when the virtual machine is changed (e.g., when a guest OS is updated, a new guest OS is installed, new software or virtual hardware is installed, etc.). The VM monitor 305 may provide data indicative of the changes in the virtual machine (e.g., virtual machine configuration data), to a VM manager (e.g., VM manager 119), as discussed above. In another embodiment, the VM monitor 305 may periodically analyze (e.g., once every 1 minute, 1 hour, 1 day, etc.) a virtual machine to obtain the virtual machine configuration data (e.g., current guest OS used by the virtual machine, current virtual hardware components used by the virtual machine, current software used by the virtual machine etc.). The VM monitor 305 may also periodically provide the virtual machine configuration data to the VM manager. In a further embodiment, the VM monitory 305 may analyze a virtual machine and obtain virtual machine configuration data for the virtual machine in response to a request for the virtual machine configuration data is received from the VM manager. See also [0032-0034, 0039] and [0042-0043]
Accordingly, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention, having the teachings of Zada and Shah before them, to include Shah’s periodic VMs configuration (where agents are install and/or updated) with Zada’s methods to configure and manage virtual machines. One would have been motivated to make such a combination to enable automated installation across a VM fleet while optimizing installation timing a system resources.
Regarding claim 19, the claim recites similar limitation as corresponding claim 9 and is rejected for similar reasons as claim 9 using similar teachings and rationale.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CARLOS A ESPANA whose telephone number is (703)756-1069. The examiner can normally be reached Monday - Friday 8 a.m - 5 p.m EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, LEWIS BULLOCK JR can be reached at (571)272-3759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/C.A.E./Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/Supervisory Patent Examiner, Art Unit 2199
Prosecution Insights