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 Ugur-Ozekinciin (US 20230236860 A1) view of Zada (US 20150154039 A1) and Moore (US 9530022 B1).
Regarding claim 1, Ugur-Ozekinciin teaches:
A method for installing an agent at one or more virtual machines (VMs) of a VM fleet, the method comprising: (Claim 1. A method of automatically updating an application agent in a network resource, comprising)
creating, by one or more processors, the one or more VMs of the VM fleet using a VM image. ([0027] In a data protection system, the application management agent is deployed on every VM that needs or may need to be protected. In an embodiment, the AMA can be deployed as part of a standard (Gold Image) deployment for any VM that needs to be presently backed up, or may need to be backed up in the future.[0028-0029] . EN: Ugur-Ozekinciin expressly uses Gold images templates to deploy VMs. )
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 ([0029] For organizations that use Gold Images (e.g., VMware templates) to deploy VMs, the application management agent is preferably deployed as part of the Gold Image. That is, it is included within the definition of the structural, non-content data of the VM. See also [0058] . )
wherein the agent is installed at the VMs including the installation package in accordance with a user-controlled installation policy; ([0038] Data protection systems like PowerProtect Data Manager allow users to set agent deployment policies that the AMA controller can use to automatically instruct the AMAs for certain classes of changes.)
after creating the one or more VMs of the VM fleet: analyzing, by one or more processors, VM fleet data of the VM fleet; ([0036] During operation of a VM, the workload may change, such as through evolution of application usage, exception processing, redeployment, and so on. As shown in process 300, once workload determination is completed, the AMA continuously monitors the VM and reports any workload type changes, 304. In this step, the AMA discovers the workload type on the VM during regular intervals, and when it detects a new workload type and/or change in the type, it will send a Workload Detection Message to the AMA controller 202. EN: Ugur-Ozekinciin analysis occurs on operating VMs after deployment )
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: ([0036] During operation of a VM, the workload may change, such as through evolution of application usage, exception processing, redeployment, and so on. As shown in process 300, once workload determination is completed, the AMA continuously monitors the VM and reports any workload type changes, 304. In this step, the AMA discovers the workload type on the VM during regular intervals, and when it detects a new workload type and/or change in the type, it will send a Workload Detection Message to the AMA controller 202.[0037] The AMA controller 202 is be responsible for communication with each AMA 206, and any one of a number of various ways can be used for the AMA to locate and communicate with the AMA controller. For example, the AMA can broadcast a message and AMA controller can listen to those messages. Alternatively, the AMA can use a well-known DNS name and port number to contact the AMA controller. This DNS name can be wired in the Gold Image as well as a configuration file. Other network resource or service location lookups such as DNS service location records can also be used. The AMA controller 202 will read messages that have been sent by the various AMAs and take the appropriate action. [0040] This information is sent by the AMA in the workload detection notification message. This display can also show the discovered application types and what level of protection they currently have (e.g., none, crash consistent, application consistent, and so on). This view will also be actionable in that the user may choose to change the protection level of any workload in any grouping of VMs. This action will be sent to the AMA controller 202, which will co-ordinate with each AMA 204 as appropriate to perform the desired actions. When a user selects, or a policy automatically triggers an actionable event, the AMA controller 202 or other server process will send the appropriate message to the specific AMA, and the AMA controller 202 can then push the full package for installation on the VM. Alternatively, the AMA can pull the full package to install the entire WSA. EN: Ugur-Ozekinciin provides the user with a message based on the analyzed VMs. )
in response to the determination to transmit the message, transmitting, by the one or more processors, the message to the user interface; and 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; ([0040] This display can also show the discovered application types and what level of protection they currently have (e.g., none, crash consistent, application consistent, and so on). This view will also be actionable in that the user may choose to change the protection level of any workload in any grouping of VMs. This action will be sent to the AMA controller 202, which will co-ordinate with each AMA 204 as appropriate to perform the desired actions. When a user selects, or a policy automatically triggers an actionable event, the AMA controller 202 or other server process will send the appropriate message to the specific AMA, and the AMA controller 202 can then push the full package for installation on the VM. Alternatively, the AMA can pull the full package to install the entire WSA. [0059] The user can define their own agent installation policies to allow the lightweight AMAs embedded in their VMs to install and upgrade to full blown workload-specific agents, 708. The AMA continuously monitors the VM for any change in workload type and reports any such change to the application manager, 710. Any workload change causes the AMA to install the respective WSA agent for the new workload in the VM, 712. The AMA accesses the new WSA from the AMA controller and application manager though a push or pull operation. In this way, applications and WSAs in a VM can be upgraded automatically using automatic detection mechanisms and application push/pull routines. The user or system admin need only update the upgrade rules and provide the upgraded software to an application manager. The AMA, through the AMA controller and any WSA agent services coordinates the automatic upgrade of the WSA in the VM. EN: Ugur-Ozekinciin expressly allows the user to define or change deployment rules after the VM is operating and the rules for subsequent agent installation)
updating, by the one or more processors, the installation policy based on the user input;( [0059] The user or system admin need only update the upgrade rules and provide the upgraded software to an application manager. The AMA, through the AMA controller and any WSA agent services coordinates the automatic upgrade of the WSA in the VM.)
and installing, by the one or more processors, the agent at the one or more VMs including the installation package according to the updated policy.( [0047]In an embodiment, the VM resident AMA (e.g., 412) can initiate the upgrade of a VM when there is a new version of the WSA agent based on agent installation policies or user driven workflow. If there is a change in the workload, the AMA will install the new WSA agent accordingly.)
Ugur-Ozekinciin does not appear to explicitly teach (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
However, Zada teaches: ([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])
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 Ugur-Ozekinciin and Zada before them, to include Zada’s VM agent status monitoring technique into Ugur-Ozekinciin automated VM agent management system so that the system determines which VMs have an agent installed which do not and which require installation or updating. One would have been motivated to make such combination to improve automated management agents across VM fleet. The combination would have involved applying a known monitoring technique to a known vm agent system to obtain predictable results.
Ugur-Ozekinciin does not appear to explicitly teach (ii) determining 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;
However Moore teaches: 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 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 Ugur-Ozekinciin and Moore before them, to include Moore’s known threshold based installation technique to the VM agent status information of Ugur-Ozekinciin such that a user notification or installation management action is triggered when a predetermine number or time is satisfied. One would have been motivated to make such combination to improve automated management agents across VM fleet. The combination would have involved applying a known monitoring technique to a known vm agent system to obtain predictable results.
Regarding claim 2, Ugur-Ozekinciin 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. ([0038-0039][0040] As shown in FIG. 3, the application management agent 206 is also responsible for installation and upgrades of the WSAs on a VM, 306. For this step, the backup system (e.g., DPS) management console can periodically query the AMA controller 202 and display the details (on one or any arbitrary grouping of VMs) that includes the workload type (e.g. SQL Server), application server instances (e.g., SQL MSSQLPROD), and database names residing on each VM…. . This view will also be actionable in that the user may choose to change the protection level of any workload in any grouping of VMs… . EN: Ugur-Ozekinciin‘s management console displays groups of VMs and permits the user to change the treatment of workloads in the group this corresponds to updating the installation policy for that selection.)
Regarding claim 3, Ugur-Ozekinciin 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. ([0038] For example a policy may specify that VMs within a certain subnet with AMAs reporting “SQL-Server” as the workload type are always approved and to have the most recently approved version of the MS-SQL backup agent deployed and running. In this case, the AMA will automatically ensure that a matching VM does so by directing (or sending) the currently approved version of the MS-SQL backup agent to AMA running on VMs that match this criteria.)
Regarding claim 4, Ugur-Ozekinciin 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. ([0040] This view will also be actionable in that the user may choose to change the protection level of any workload in any grouping of VMs. This action will be sent to the AMA controller 202, which will co-ordinate with each AMA 204 as appropriate to perform the desired actions. When a user selects, or a policy automatically triggers an actionable event, the AMA controller 202 or other server process will send the appropriate message to the specific AMA, and the AMA controller 202 can then push the full package for installation on the VM. Alternatively, the AMA can pull the full package to install the entire WSA.)
Regarding claim 5, Ugur-Ozekinciin teaches:
The method of claim 4, wherein the user action is: a user instruction to install the agent at a VM of the VM fleet; or a user instruction to create a new VM at the VM fleet. ([0059] The user can define their own agent installation policies to allow the lightweight AMAs embedded in their VMs to install and upgrade to full blown workload-specific agents, 708.)
Regarding claim 7, Ugur-Ozekinciin teaches:
The method of claim 1, wherein transmitting the message to the user interface is performed at regular intervals. ([0036] During operation of a VM, the workload may change, such as through evolution of application usage, exception processing, redeployment, and so on. As shown in process 300, once workload determination is completed, the AMA continuously monitors the VM and reports any workload type changes, 304. In this step, the AMA discovers the workload type on the VM during regular intervals, and when it detects a new workload type and/or change in the type, it will send a Workload Detection Message to the AMA controller 202. See also [0040])
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 claim 10, Ugur-Ozekinciin 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. ([0036] During operation of a VM, the workload may change, such as through evolution of application usage, exception processing, redeployment, and so on. As shown in process 300, once workload determination is completed, the AMA continuously monitors the VM and reports any workload type changes, 304. In this step, the AMA discovers the workload type on the VM during regular intervals, and when it detects a new workload type and/or change in the type, it will send a Workload Detection Message to the AMA controller 202.)
Regarding claims 11, Ugur-Ozekinciin 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. (Claim 18. A system for automatically updating an application agent in a virtual machine (VM) comprising a data storage target in a network, the system comprising:)
The claim recites similar limitation as corresponding claim 1 and is rejected for similar reasons as claim 1 using similar teachings and rationale.
Regarding claim 20, Ugur-Ozekinciin also teaches:
The system of claim 11, further comprising a plurality of VMs included in the VM fleet. ([0021] FIG. 1 is a diagram of a network implementing an automatic backup agent management system for VM-based data storage systems, under some embodiments. In system 100, a storage server 102 executes a data storage or backup management process 112 that coordinates or manages the backup of data from one or more data sources 108 to storage devices, such as network storage 114, client storage, and/or virtual storage devices 104. With regard to virtual storage 104, any number of virtual machines (VMs) or groups of VMs may be provided to serve as backup targets. FIG. 1 illustrates a virtualized data center (vCenter) 108 that includes any number of VMs for target storage.)
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 Ugur-Ozekinciin (US 20230236860 A1) view of Zada (US 20150154039 A1) and Moore (US 9530022 B1) and further view of Shah (US 20130326505 A1).
Regarding claims 9, Ugur-Ozekinciin 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 Ugur-Ozekinciin and Shah before them, to include Shah’s periodic VMs configuration (where agents are install and/or updated) with Ugur-Ozekinciin’s automated agent installation and update system. 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
THIS ACTION IS MADE FINAL. 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 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
