DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is in response to Request for Continued Examination and Applicant Amendment and Arguments filed on 02 October, 2025.
Claims 1-2, 7-9, 14-16 and 21-32 are pending in this application. Claims 3-6, 10-13, and 17-20 were cancelled.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02 October, 2025 has been entered.
Claim Rejections - 35 USC § 103
The following is a quotation of pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 8, 15, 21-22, 24-26, 28-30 and 32 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. (US Patent. 8,572,679 B1) in view of Chan et al. (US Pub. 2014/0289385 A1) and further in view of Lotem et al. (US Patent. 8,621,552 B1), SHEPARD et al. (US Pub. 2018/0300180 A1) and Carter (US Patent. 8,370,915 B2).
SHEPARD was cited in the PTO-892 on 07/29/2025.
Carter was cited in the PTO-892 on 11/06/2024.
Wang, Chan and Lotem were cited in the previous Office Action.
As per claim 1, Wang teaches the invention substantially as claimed including A data processing system comprising (Wang, Fig. 1 and Fig. 10):
at least one processor (Wang, Fig. 10, 1002 processing unit); and
a machine-readable medium storing executable instructions that, when executed, cause the data processing system to perform operations comprising (Wang, Fig. 10, 1004 system memory; Col 3, lines 4-8, The computer program product may be a computer storage medium readable by a computer system and encoding a computer program that comprises instructions for causing a computer or computing system to perform example process(es)):
receiving a job definition defining job attributes pertaining to a job to be deployed in a cloud-based service (Wang, Fig. 5, 500 define your deployment; 502, type, security patch, 504 deploy change to All, 508 Risk level of your change Medium (as a job definition defining job attributes); Col 7, lines 47-53, One or more users may submit a change request and patches for upgrading a system to an orchestrator component for automatically deploying and implementing the upgrade to the system. In an example user interface as demonstrated in diagram 500, the user, or an administrator, may be able to submit a change request to the orchestrator using a form for providing additional information about the change request; Col 3, lines 38-39, manage and coordinate the change across the system involving multiple sites, servers);
determining whether the job definition complies with predefined rules for job creation in the cloud-based service using a validation component of a job creation and deployment system of the cloud-based service (Wang, Fig. 1, 100 (as job creation and deployment system of the cloud-based service) 114 validation component; Col 8, lines 2-5, The user may also be able to define validation criteria 510 (as including predefined rules) which the validation component may follow to validate the change request at a number of validation points; Col 4, lines 44-52, the change request 102 may be deployed and propagated through a series of deployment scopes 116. The deployment scopes 116 may become increasingly larger in order to test the applied change at a number of stages before fully implementing the change on the target system. At initial deployment through a first deployment scope, and at every deployment scope advancement, the orchestrator 110 may submit the applied change to a validation component 114 for validating the change request; Col 4, lines 61-66, The validation component 114 may evaluate the quality of the applied change, and may ensure that the applied change meets specifications for the system and fulfills its intended purpose. If the applied change is validated, then the orchestrator may proceed with deploying the change to the next deployment scope
the job definition to define a scope attribute indicating a scope of deployment for the job and a risk attribute indicating a risk level associated with the job (Wang, Fig. 5, 500 define your deployment; 504 deploy change to All (as scope of deployment for the job, i.e., deploy to all), 508 Risk level of your change Medium (as risk attribute); Col 7, line 57-Col 8, line 5, The user interface may also include further options for enabling the user to select the target system 504 or systems to which the changes are to be applied, the urgency 506 of the change request, and the risk level 508 of the change request…A risk level of the change request may be, for example, high, medium, or low, and the selected risk level may provide information to the orchestrator about the servers involved in the change request…);
determining a deployment technique for the job based on the job definition, where the deployment technique includes a throttling procedure indicating a bake time between deployment scopes based on the risk attribute and where the deployment technique includes a configuration of deployment scopes and a type of deployment scopes (Wang, Fig. 3, 300 (as whole as deployment technique for each deployment job/request received from Fig. 5; 305, 315 and 322 waiting validation between SIPs (as a throttling procedure indicating a bake time between deployment scopes); Fig. 5, 504 deploy change to ALL (as configuration of deployment scopes), 502 type security patch (as type of deployment rings, and these information are all used within the deployment technique as indicated in Fig. 3) Fig. 5, Fig. 7 and Fig. 8 (as deployment job definition); Fig. 7, wait time 30 Minutes, 706 risk level; Col 8, lines 29-35, validation component may be configured to evaluate the results of deployment for each of a series of deployment scopes. and to provide results of the deployment of the successful and failure servers to the orchestrator. The progress window may provide information about the validation at each validation point associated with deployment scopes, such as SDF, SIP1, SIP2, and SIP3; Col 9, lines 5-10, The orchestrator may employ different deployment scopes depending on the risk level and varying processing times to implement the change may be needed. The submitting user may also specify the time (as bake time) for validating the change request before proceeding with the deployment workflow), and
in response to the job definition being determined to comply with the predefined rules for job creation in the cloud-based service, deploying the job to the cloud-based service based on the deployment technique where the deploying of the job includes (Wang, Fig. 11, 1120 performing security check and validation, 1140 continually validate between scopes advancements, 1150 deploy change to target system; Col 4, lines 61-66, The validation component 114 may evaluate the quality of the applied change, and may ensure that the applied change meets specifications for the system and fulfills its intended purpose. If the applied change is validated, then the orchestrator may proceed with deploying the change to the next deployment scope).
deploying the job to a first deployment scope (Wang, Fig. 3, 304 deploy to SDF; Fig. 11, deploy change through deployment scopes) ,
collecting, during the bake time between deployment to the first deployment scope and a subsequent deployment scope, data regarding with the deployment to the first deployment ring (Wang, Fig. 3, 305 waiting validation; Col 6, lines 15-28, A first deployment scope may be the SDF deployment scope 304 where the new build is applied and tested internally on local users. After applying the new build within the SDF deployment scope 304, the results of the new build may be returned to the validation component 305 for evaluating the results and determining the success of the new build within the SDF scope. Upon deployment to the SDF deployment scope 304, the orchestrator may provide notification 303 of a successful deployment… If the new build results are returned as valid 306, the orchestrator may proceed with the deployment process, and the orchestrator may deploy the new build to the SIP series 310 of deployment scopes, which may include SIP 1, SIP 2, and SIP 3), and
after the bake time after the deploying the job to the first deployment scope, deploying the job to the subsequent deployment scope (Wang, Col 6, lines 15-28, A first deployment scope may be the SDF deployment scope 304 where the new build is applied and tested internally on local users. After applying the new build within the SDF deployment scope 304, the results of the new build may be returned to the validation component 305 for evaluating the results and determining the success of the new build within the SDF scope. Upon deployment to the SDF deployment scope 304, the orchestrator may provide notification 303 of a successful deployment… If the new build results are returned as valid 306, the orchestrator may proceed with the deployment process, and the orchestrator may deploy the new build to the SIP series 310 of deployment scopes, which may include SIP 1, SIP 2, and SIP 3; Col 6, lines 36-40, The results of the SIP 1 deployment may then sent to the validation component to await validation 315. If the validation component approves 318 the build in the SIP1 deployment scope, the deployment process may be repeated with the SIP 2 deployment scope).
Although Wang teaches the job definition defines a scope attribute and a risk attribute, Wang fails to specifically teach wherein the predefined rules include: a first rule requiring the job definition to define these attributes, and a second rule requiring an authorization when the job definition defines one or more of a high risk attribute and a large scope attribute, wherein the second rule does not require the authorization when the job definition defines a low risk attribute and a small scope attribute.
However, Chan teaches wherein the predefined rules include: a first rule requiring the job definition to define these attributes (Chan, [0002] lines 1-4, To execute policy(s) in a device usually a user is required to go through a process of specifying the policy(s) and its settings or choosing from several policy(s) before the policy can be executed (please notes: scope attribute and risk attribute were taught by Wang)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Wang with Chan because Chan’s teaching of requirement that the user is required to specifying the setting before the action can be processed would have provided Wang’s system with the advantage and capability to ensuring the user are correctly input all the necessary information before the deployment which improving the system performance and efficiency.
Wang and Chan fail to specifically teach a second rule requiring an authorization when the job definition defines one or more of a high risk attribute and a large scope attribute, wherein the second rule does not require the authorization when the job definition defines a low risk attribute and a small scope attribute.
However, Lotem teaches a second rule requiring an authorization when the job definition defines one or more of a high risk attribute and a large scope attribute, wherein the second rule does not require the authorization when the job definition defines a low risk attribute and a small scope attribute (Lotem, Col 10, line 15, Access change requests (ACRs); Col 15, lines 25-27, This check includes evaluating a risk associated with a deployment of the network access change request. Assessing risk change might include checks at various levels; Col 11, lines 58-64, Network access policy specifies constraints on the permitted access in the network. The policy might specify for example a list of ports that are not allowed to be used, services that the access to them is not allowed from particular network areas (or zones), limitation on the amount of sources or targets that can access a service; Col 12, line 1, The policy is typically specified using Access Policy Rules; lines 14-16, Rule 2, which specifies that the access from external network to DNS ports in DMZ networks should be limited to no more than 5 different IP addresses; Col 27, lines 41-44, When the specifications or the implementation checks find issues (incompliance, significant risk increase, inconsistency between the implementation and the specifications, etc.) the system or the user has to address the situation; Col 27, lines 60-63, Approving the Firewall ACR can be done automatically by the system if no issues were found during the specification and implementation checks, or might require the approval of authorized users; also see Col 15, lines 45-53, When the specifications are found to be incompliant with the network access policy or when the specifications imply a significant increase in the risk level, the system or the user has to address the situation. The possible actions of handling specification issues are, according to an embodiment of the invention:…(d) to accept the risk and approve the request [Examiner noted: a second rule requiring an authorization when the job definition defines one or more of a high risk attribute and a large scope attribute (i.e., risk is high (significant increase in the risk level), and issue with Network access policy (i.e., access from external network to DNS ports in DMZ networks should be limited to no more than 5 different IP addresses, i.e., if above 5, which means large scope), wherein the second rule does not require the authorization when the job definition defines a low risk attribute and a small scope attribute (i.e., if no issue, the system just automatically approved and continuing proceed]).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Wang and Chan with Lotem because Lotem’s teaching of further authorization is needed when the system determining there are issues with the deployment request (i.e., risk increases, and issue with Network access policy) would have provided Wang and Chan’s system with the advantage and capability to preventing potential system risk which improving the system reliability and performance (see Lotem, Col 1, lines 40-42, “To reduce such risks, IT organizations apply processes for approving requested changes and verifying their proper implementation”).
Wang, Chan and Lotem fail to explicitly teach deployment scope is deployment ring, where the deployment policy includes a configuration of deployment rings specifying a number of deployment rings, and where the deploying of the job includes: collecting, during the bake time between deployment to the first deployment ring and a subsequent deployment ring, telemetry data regarding problems with the deployment to the first deployment ring.
However, SHEPARD teaches deployment scope is deployment ring, where the deployment plan includes a configuration of deployment rings specifying a number of deployment rings (SHEPARD, [0097] Each strata may be mapped to corresponding strata generated from an entire set of all commercial devices sending telemetry to the analytics component 106. The commercial strata which have already deployed the given change may be identified and promotion criteria 722 are analyzed. Strata with the best results may be weighted with higher priority while strata with the worse results (e.g., poor results or lower CI/higher MoE) are prioritized lower. These weightings may be used to construct an initial deployment plan within the organization 732. The number of deployment rings 736 may be calculated based on a function of the number of strata and/or the number of devices in each strata)., and
where the deploying of the job includes: collecting, during the bake time between deployment to the first deployment ring and a subsequent deployment ring, telemetry data regarding problems with the deployment to the first deployment ring (SHEPARD, [0030] a set of deployment rings may be larger for larger organizations. Accordingly, telemetry may be used to automatically create or assist in the creation of deployment rings by determining or locating devices with a target diversity level in different flighting rings. Further, promotion criteria (e.g., quality validation criteria) may be formed by IT to control the flow or deployment of software from one deployment ring to a next deployment ring. For example, the promotion criteria may need to be satisfied before software may be allowed to flow to the next deployment ring; [0096] organizations may deploy software (e.g., software upgrades, updates, and/or policy configurations) to a small group of computer devices, then if there are no problems they deploy it more broadly. The goal of the organization may be to identify a representative sample of their devices which they can test a given change (operating system, application, driver updates, new configurations or policies, etc.) against before risking deployment to their entire device population…. As such, telemetry data 752 may be used to automatically create or assist in the creation of deployment rings 736 along with promotion criteria 722 (e.g., quality validation criteria) that may be met before software 740 should be allowed to flow to a subsequent deployment ring. As such, telemetry data 752 may be used to automatically create or assist in the creation of deployment rings 736 along with promotion criteria 722 (e.g., quality validation criteria) that may be met before software 740 should be allowed to flow to a subsequent deployment ring; also see [0117] As part of block 816, the method 800 may determine whether the one or more devices within the at least one deployment ring satisfy the promotion criteria. For example, as described herein, the computer device 102 may execute flighting ring component 114 and/or deployment determination component 730 to determine, during deployment of the software 740, whether the one or more devices (e.g., one or more devices 714) within the at least one deployment ring (e.g., first deployment ring 712) satisfy the promotion criteria 722).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Wang, Chan and Lotem with SHEPARD because SHEPARD’s teaching of constructing the deployment rings would have provided Wang, Chan and Lotem’s system with the advantage and capability to allowing the system to easily deploying the tasks into cloud based on the deployment rings in order to improving the system performance and reliability (see SHEPARD, [0043] “install success rate, post-install reliability, performance, and/or user sentiment criteria) and/or a set of configurations.”).
Wang, Chan, Lotem and SHEPARD fail to specifically teach deployment technique/plan is deployment policy.
However, Carter teaches the deployment technique/plan is deployment policy (Carter, Col 8, lines 60-63, distribute one or more virtual distributions. Each virtual distribution includes its own identity that can be subsequently validated or verified; Col 6, lines 23-24, deployment policies; Fig. 2, 200 receive a virtual distribution (VD) to install, 220 verify an identity (as job definition) for the VD (as to validate job), 230 identify a deployment policy for the VD when the identity is verified, 240 deploy the VD…when the identity is verified and when directed to do so by the deployment policy).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Wang, Chan, Lotem and SHEPARD with Carter because Carter’s teaching of validating the job before identifying the deployment policy would have provided Wang, Chan, Lotem and SHEPARD’s system with the advantage and capability to allowing the system to ensuring the identity of the deployment which improving the system security and performance (see Carter, Col 1, lines 60-61, “improved edge computing with security-enhanced features”).
As per claim 8, it is a method claim of claim 1 above. Therefore, it is rejected for the same reason as claim 1 above.
As per claim 15, it is a non-transitory computer readable medium claim of claim 1 above. Therefore, it is rejected for the same reason as claim 1 above.
As per claim 21, Wang, Chan, Lotem, SHEPARD and Carter teach the invention according to claim 1 above. Wang further teaches wherein the operations further comprise: determining a deployment technique for the job based on the job definition, where the deployment technique includes a deployment scope configuration specifying a number of scopes and a type of scopes (Wang, Fig. 3, 300 (as whole as deployment technique); Fig. 5, 500 Job definition; Fig. 2, 200 as deployment scope configuration, 202, TEST, 204, SDF, 206 Slip 1-3 and 210 service (as including number of scopes and type of scopes); Col 9, lines 5-8, The orchestrator may employ different deployment scopes depending on the risk level, and varying processing times to implement the change may be needed; Col 4, lines 25-44, once the orchestrator 110 receives the submitted change requests 102, the orchestrator 110 may employ a multitude of steps for approving, validating, deploying and implementing the change requests to the system. The deployment process at the orchestrator may initially be triggered upon the availability and submission of the change requests. Before a change can be fully implemented in the system, the change request may be associated with approval 106 and validation 108. When a change request is initially submitted to the orchestrator, the orchestrator may first perform a security check at a security component 112. The security component 112 may be responsible for verifying licenses and certificates associated with the submitted change request for the system, and for ensuring that deployment of the change request is within policy and/or request approval. If the change request receives approval 106 at the security component 112, the orchestrator 110 may initiate the deployment process to apply the changes to the system (as whole as deployment technique); Col 5, lines 30-33, The deployment scopes may become increasingly larger in order to extensively test the applied change at a number of stages before fully implementing the change on the target system.)
In addition, Carter teaches the deployment technique is deployment policy (Carter, Col 8, lines 60-63, distribute one or more virtual distributions. Each virtual distribution includes its own identity that can be subsequently validated or verified; Col 6, lines 23-24, deployment policies; Fig. 2, 200 receive a virtual distribution (VD) to install, 220 verify an identity for the VD, 230 identify a deployment policy for the VD when the identity is verified, 240 deploy the VD…when the identity is verified and when directed to do so by the deployment policy).
Further, SHEPARD teaches deployment scope is deployment ring (SHEPARD, Fig. 7, 712, 714, 716, 718; [0096] lines 5-14, The goal of the organization may be to identify a representative sample of their devices which they can test a given change (operating system, application, driver updates, new configurations or policies, etc.) against before risking deployment to their entire device population. Constructing the optimal set of deployment rings 736 and associated promotion criteria 722 can prove difficult without telemetry data 752. As such, telemetry data 752 may be used to automatically create or assist in the creation of deployment rings 736 along with promotion criteria 722; [0097] lines 14-18, The number of deployment rings 736 may be calculated based on a function of the number of strata and/or the number of devices in each strata. For instance, the deployment rings 736 may include a first deployment ring 712 including one or more devices 714 and a second deployment ring 714 including one or more devices 716).
As per claim 22, Wang, Chan, Lotem, SHEPARD and Carter teach the invention according to claim 1 above. Wang further teaches wherein the operations further comprise: determining a deployment technique for the job based on the job definition, where the deployment technique includes a deployment timing (Wang, Fig. 3, 300 (as whole as deployment technique for deployment job/request that including the job definition received from Fig. 5); Col 5, lines 26-37, FIG. 2 illustrates deployment scopes of a workflow for implementing changes to a system, according to embodiments. As briefly described above, in an example embodiment, the change request may be deployed and propagated through a series of deployment scopes. The deployment scopes may become increasingly larger in order to extensively test the applied change at a number of stages before fully implementing the change on the target system. At an initial deployment scope, the change request is verified while in the initial stages 202. If validated by the validation component, then the orchestrator may proceed with deploying the change request through the next deployment scope; also see Col 5, line 56- Col 6 line 3, the protocol servers may be tested in groups, such that only a small percentage of the servers are tested at a time. For example, the change request may be applied to 20% of the protocol servers at a time for a total of 5 groups or waves. If the applied change receives validation at the validation component, the change request may be applied within a third SIP deployment scope, SIP 3, where the change request may be applied to mailbox servers associated with the protocol servers. As with SIP 2, the mailbox servers may be tested in groups, such that the change request may be applied to one group at a time. If the applied change to SIP 3 receives validation at the validation component, the change request may be applied to the target system for globally implementing the changes to the system, and ultimately, the end users of the system 210 (as deployment timing, how each scopes are processed orderly/timing)). In addition, Carter teaches the deployment technique is deployment policy (Carter, Col 8, lines 60-63, distribute one or more virtual distributions. Each virtual distribution includes its own identity that can be subsequently validated or verified; Col 6, lines 23-24, deployment policies; Fig. 2, 200 receive a virtual distribution (VD) to install, 220 verify an identity for the VD, 230 identify a deployment policy for the VD when the identity is verified, 240 deploy the VD…when the identity is verified and when directed to do so by the deployment policy).
As per claim 24, Wang, Chan, Lotem, SHEPARD and Carter teach the invention according to claim 22 above. Wang further teaches wherein the deployment timing includes a throttling procedure based on the risk attribute from the job definition (Wang, Fig. 5, 500, 508 Risk level of your change (as risk attribute); Col 5, lines 21-25, when a change request is submitted, the orchestrator may identify the payload profile and the risk level of the change request in order to efficiently select the scopes, approvals, validations 108 and processing time based on the identified payload profile; Col 9, lines 5-8, The orchestrator may employ different deployment scopes depending on the risk level, and varying processing times to implement the change may be needed (as including throttling procedure); Col 11, lines 40-43, The deployment scopes may become increasingly larger in order to extensively test the applied change at a number of stages before fully implementing the change on the target system).
As per claims 25-26 and 28, they are method claims of claims 21-22 and 24 respectively above. Therefore, they are rejected for the same reasons as claims 21-22 and 24 respectively above.
As per claims 29-30 and 32, they are non-transitory computer readable medium claims of claims 21-22 and 24 respectively above. Therefore, they are rejected for the same reasons as claims 21-22 and 24 respectively above.
Claims 2, 9 and 16, are rejected under 35 U.S.C. 103 as being unpatentable over Wang, Chan, Lotem, SHEPARD and Carter, as applied to claims 1, 8 and 15 respectively above, and further in view of Voskuil et al. (US Pub. 2010/0241603 A1).
As per claim 2, Wang, Chan, Lotem, SHEPARD and Carter teach the invention according to claim 1 above. Carter teaches deployment policy (Carter, Col 8, lines 60-63, distribute one or more virtual distributions. Each virtual distribution includes its own identity that can be subsequently validated or verified; Col 6, lines 23-24, deployment policies; Fig. 2, 200 receive a virtual distribution (VD) to install, 220 verify an identity (as job definition) for the VD (as to validate job), 230 identify a deployment policy for the VD when the identity is verified, 240 deploy the VD…when the identity is verified and when directed to do so by the deployment policy). In addition, Chan teaches wherein deployment policy is not determined for the job when to the job definition is not determined (Chan, [0002] lines 1-4, To execute policy(s) in a device usually a user is required to go through a process of specifying the policy(s) and its settings or choosing from several policy(s) before the policy can be executed (as teaching the concept of if the user is not defining settings., the policy also cannot be determined for execution).
Wang, Chan, Lotem, SHEPARD and Carter fail to explicitly teach the wherein deployment policy is not determined for the job when to the job definition is not determined to comply with the predefined rules.
However, Voskuil teaches wherein deployment policy is not determined for the job when to the job definition is not determined to comply with the predefined rules (Voskuil, [0099] A solution may not be possible, for example, if the constraint expression of the policy rule identified in step 604 is not mutually satisifiable with respect to a constraint expression included within an in-effect policy rule in the set of in-effect policy rules. In contrast, a solution may be possible, for example, if the constraint expression of the policy rule identified in step 604 is mutually satisifiable with respect to all the constraint expressions included within the set of in-effect policy rules. Graph processing logic 224 may also determine that a solution cannot be provided if, for example, the policy rule that includes the constraint expression is part of a cycle of policy rules in the disconnected sub-graph that cannot be satisfied or if at least one variable needed to solve the constraint expression is not available (as policy cannot be determined if the definition is not determined to comply with predefined rules)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Wang, Chan, Lotem, SHEPARD and Carter with Voskuil because Voskuil’s teaching of determining that constraint expression is part of a cycle of policy rules in the disconnected sub-graph that cannot be satisfied and therefore the solution cannot be provided would have provided Wang, Chan, Lotem, SHEPARD and Carter’s system with the advantage and capability to allowing the system to ensuring all the rules need to comply before providing the solutions in order to improving the system performance and efficiency.
As per claim 9, it is a method claim of claim 2 above. Therefore, it is rejected for the same reason as claim 2 above.
As per claim 16, it is a non-transitory computer readable medium claim of claim 2 above. Therefore, it is rejected for the same reason as claim 2 above.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Wang, Chan, Lotem, SHEPARD and Carter, as applied to claims 1 and 8 respectively above, and further in view of Holbrook (US Pub. 2019/0138431 A1).
Holbrook was cited in the previous Office Action.
As per claim 7, Wang, Chan, Lotem, SHEPARD and Carter teach the invention according to claim 1 above. Wang teaches job definitions having attributes indicating a global scope and a lower risk level (Wang, Fig. 5, 500 define your deployment; 504 deploy change to All (as global scope), 508 Risk level of your change; Col 7, lines 63-65, A risk level of the change request may be, for example, high, medium, or low).
Wang, Chan, Lotem, SHEPARD and Carter fail to specifically teach a global scope and a lower risk level are assigned a high risk level.
However, Holbrook teaches a global scope and a lower risk level are assigned a high risk level (Holbrook, [0031] lines 1-14, a risk identifier 108 configured to determine a risk level 109 for one or more of the software features 116. The risk level 109 indicates a likelihood of the software feature causing a defect or software malfunction. Indeed, each software feature 116 may be treated differently in a software update. In some application updates, any one particular feature may or may not be updated…If the feature is updated it will likely need to be tested more in depth. This is especially true if that feature has a lot of connections 117 to other software features or elements. Features that have a large number of connections and are updated (as jobs having a global scope and lower risk level, i.e., application updates that related to large number of connections) in a given update will have a higher risk level 109 (as jobs having a global scope and low risk level are assigned a high risk level, since the risk level is updated to higher, therefore, the previous risk level is lower); also see Fig. 1, 108, 109 risk level; Figs 4-5, table include features that assigned with high risk; [0046] lines 5-6, The risk identifier 108 may identify a risk level 109 for each software feature).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Wang, Chan, Lotem, SHEPARD and Carter with Holbrook because Holbrook’s teaching of identifying and assigning the high risk to the features/updates that involving large scope (as global scope) would have provided Wang, Chan, Lotem, SHEPARD and Carter’s system with the advantage and capability to allow the system to easily determining and testing the potential defect of the software updates based on the high risk level associated with which improving the system performance and efficiency (see Holbrook, [0006] “determined likelihood of the software feature causing a defect or software malfunction, and then initializing unit tests configured to test the portion of the software application”).
As per claim 14, it is a method claim of claim 7 above. Therefore, it is rejected for the same reason as claim 7 above.
Claims 23, 27 and 31 are rejected under 35 U.S.C. 103 as being unpatentable over Wang, Chan, Lotem, SHEPARD and Carter, as applied to claims 22, 26 and 30 respectively above, and further in view of Vaidya et al. (US Pub. 2007/0038726 A1).
Vaidya was cited in the previous Office Action.
As per claim 23, Wang, Chan, Lotem, SHEPARD and Carter teach the invention according to claim 22 above. Wang further teaches wherein job definition includes a job type attribute, and the deployment timing includes a deployment start time (Wang, Fig. 5, 500 define your deployment, 502 type security patch; Col 5, line 56- Col 6 line 3, the protocol servers may be tested in groups, such that only a small percentage of the servers are tested at a time. For example, the change request may be applied to 20% of the protocol servers at a time for a total of 5 groups or waves. If the applied change receives validation at the validation component, the change request may be applied within a third SIP deployment scope, SIP 3, where the change request may be applied to mailbox servers associated with the protocol servers. As with SIP 2, the mailbox servers may be tested in groups, such that the change request may be applied to one group at a time. If the applied change to SIP 3 receives validation at the validation component, the change request may be applied to the target system for globally implementing the changes to the system, and ultimately, the end users of the system 210 (as deployment start time, how each scopes are started orderly/timing)).
Wang, Chan, Lotem, SHEPARD and Carter fail to specifically teach deployment start time based on the job type attribute.
However, Vaidya teaches deployment start time based on the job type attribute (Vaidya, [0029] lines 3-12, deployment module 202, when "woken up" by timing module 208, accesses path/job list 212 and quick deploy list 214 to determine: if there are jobs are scheduled to be performed at this time…deployment module 202 first checks quick deploy list 214 for any quick deploy jobs to be performed, and then checks path/job list 212 for jobs scheduled to be performed; [0055] lines 1-5, the deployment module inspects a job type property of the indication provided at block 502 to determine whether the job type is a quick deploy type or a normal deploy type. If it is determined that the job type is a quick deploy type, operational flow proceeds to a block 512. (as deployment start time based on the job type attribute (i.e., quick deployment needed)).
It would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to have combined the teaching of Wang, Chan, Lotem, SHEPARD and Carter with Vaidya because Vaidya’s teaching of determining the time (i.e., quick deployment) based on the job type would have provided Wang, Chan, Lotem, SHEPARD and Carter’s system with the advantage and capability to allowing the system to easily determining which deployment job should be processed fast as compare to the normal deployment which improving the system efficiency and performance.
As per claim 27, it is a method claim of claim 23 above. Therefore, it is rejected for the same reason as claim 23 above.
As per claim 31, it is a non-transitory computer readable medium claim of claim 23 above. Therefore, it is rejected for the same reason as claim 23 above.
Response to Arguments
Applicant’s arguments with respect to claims 1-2, 7-9, 14-16 and 21-32 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 (i.e., argument regarding to Wang, Chan and Lotem).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZUJIA XU whose telephone number is (571)272-0954. The examiner can normally be reached M-F 9:30-5:30 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, Aimee J Li can be reached at (571) 272-4169. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ZUJIA XU/Examiner, Art Unit 2195