DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Remarks
This Office Action is in response to an RCE filed 01/28/2026.
Claims 1, 15 and 21 are currently amended via Applicant’s amendment.
Claims 16-20 have been canceled via previous amendment.
Claims 1-15 and 21-25 are currently pending.
This Office Action is made non-final after the RCE.
Request Continuation for Examination
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 01/28/2026 has been entered.
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
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 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.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-14 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Independent claim 1 has been amended to recite, in relevant part, “based on an association of the progress data and the task identifier, updating a user interface with the progress data indicative of the progress of the task to modify, by the system in accordance with the task, the production environment to conform with the declarative descriptions in the associated source code repository, wherein the progress data is updated in response to completion of actions defined by the declarative descriptions.”
The originally filed specification describes that the progress monitoring service obtains “progress data indicative of a progress of the task” and uses that progress data to update a user interface, see, e.g., paragraphs [0020-0024] . The disclosure thus supports that progress data reflects the progress of a task in terms of task events or milestones. However, the specification does not describe any “actions defined by the declarative descriptions,” nor does it describe updating the task’s progress data specifically “in response to completion of actions defined by the declarative descriptions.” In particular, while the specification separately discusses (i) declarative descriptions that define a desired configuration/state of a production environment and (ii) generic task progress data, it does not disclose that the actions defined in the declarative descriptions themselves are used as the basis for updating the progress data or that completion of such declaratively defined actions is what triggers progress updates.
The newly added language therefore introduces a specific functional relationship between (a) “actions defined by the declarative descriptions” and (b) updating of “progress data indicative of a progress of the task” that is neither expressly described nor reasonably conveyed by the original disclosure. One of ordinary skill in the art, reading the application as filed, would not have reasonably concluded that the inventor had possession of a system in which task progress data is updated “in response to completion of actions defined by the declarative descriptions,” as now claimed.
Accordingly, claim 1 is rejected under 35 U.S.C. § 112(a) for lack of written description.
Dependent claims 2-14 are rejected for the same reasons discussed above for claim 1 based on virtue of their dependency to independent claim 1.
Claim Rejections - 35 USC § 103
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 of this title, 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, 3-4, 6, 11, 15 and 21 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Zhang et al. (US 2017/0208144 A1) (hereinafter Zhang) in view of Sharma et al. (US 2013/0117444 A1) (hereinafter Sharma), Treptow et al. (US 2020/0138564 A1) (hereinafter Treptow) and further in view of Bansal et al. (US 2023/0244594 A1) (hereinafter Bansal).
As per claim 1, (Currently Amended) A computer-implemented method performed by a progress monitoring service for monitoring progress of a task, the progress monitoring service and the task executing in a computing network of a cloud computing system comprising a plurality of computing devices (e.g. Zhang: [Abstract] discloses system, methods and devices for monitoring the performance of activities executed at a computing device. Also see [0052] [0072] [Fig. 4 and related description]), the method comprising:
receiving, from a process manager managing the task, a request for a task identifier, the task identifier identifying an instance of the task; returning the task identifier to the process manager (e.g. Zhang: [0068] discloses executing pre-work operations to obtain an identifier of the activity that the task is associated with. [0079] discloses code outputs an identifier of the activity to which the task pertains. [Fig. 4][0072] discloses the activity tracker logs a unique activity ID, a unique task ID, the current status of activity, accumulated duration of the activity, and timestamps that identify when events occurred such as the beginning and end of execution of a task. Also see [Fig. 3 and related description] [0066] and [0081].); sending, by the process manager, the task identifier to a system executing at least part of the task (e.g. Zhang: [0068] [0079] discloses executing pre-work operations to obtain an identifier of the activity that the task is associated with, and outputting an identifier of the activity to which the task pertains.); receiving, from the system executing at least part of the task, the task identifier and progress data indicative of a progress of the task (e.g. Zhang: [Fig. 4][0072] discloses the activity tracker logs a unique activity ID, a unique task ID, the current status of activity, accumulated duration of the activity, and timestamps that identify when events occurred such as the beginning and end of execution of a task. Also see [Fig. 3 and related description] [0066].); based on an association of the progress data and the task identifier, updating a user interface with the progress data indicative of the progress of the task (e.g. Zhang: [0069] discloses updating current status of the activity. [Fig. 1] [0042] [0044] discloses updating activity status. [0022-0023] rendering engine can be enabled to generate presentation of a web page for display to a user. This implies that rendering engine can update and present current activity/task status to the user via a web page. Also see [0046-0048] [0050-0051] [Fig. 3] [56-58].)
Zhang does not expressly disclose sending the task identifier to a system executing at least part of the task; modifying, by the system in accordance with the task, a production environment to conform with declarative descriptions in an associated source code repository, the declarative descriptions comprising a configuration that specifies a desired state of the production environment; receiving, from the system executing at least part of the task, the task identifier and progress data indicative of a progress of the task to modify the production environment to conform with declarative descriptions in the associated source code repository; and based on an association of the progress data and the task identifier, updating a user interface with the progress data indicative of the progress of the task.
However, Sharma discloses obtaining a task identifier and sending, by the process manager, the task identifier to a system executing at least part of the task (e.g. Sharma: [0104-0105] discloses a routine obtains a job identifier to identify the requested job and then provides the job identifier to the selected worker device.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the method of acquiring job identifier and forwarding the acquired job identifier to dynamic-web-service worker device as taught by Sharma into Zhang because it would allow the worker device to transform the web service invocation into one or more transactions requests, and send them to server for processing the transaction and in return receive the transaction result. The worker device can store the requested result and notify the web-service manager server that results for the job are available (See Sharma: [0073-0074]).
Furthermore, Treptow discloses based on an association of the progress data and the task identifier, updating a user interface with the progress data indicative of the progress of the task (e.g. Treptow: [Fig. 5] [0062] discloses rendering a consumer web page that displays status information including job name, a progress bar and a status. [0041] discloses job status indicates the current progress of the requested job.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the well-known technique of updating and displaying job status via webpage as taught by Treptow into the combination of Zhang and Sharma because visual presentation of the job status would help users understand the status of their job requests and to help the system admin to administer them (See Treptow: [0041])
The combination of Zhang, Sharma and Treptow does not expressly disclose modifying, by the system in accordance with the task, a production environment to conform with declarative descriptions in an associated source code repository, the declarative descriptions comprising a configuration that specifies a desired state of the production environment.
However, Bansal discloses modifying, by the system in accordance with the task, a production environment to conform with declarative descriptions in an associated source code repository, the declarative descriptions comprising a configuration that specifies a desired state of the production environment (e.g. Bansal: [Abstract] discloses identifying a security policy update from a security as code repository, wherein the identified security policy update is a candidate for deployment to a production environment having a plurality of attributes defined by an infrastructure as code repository; identify, from the plurality of attributes and using the infrastructure as code repository, individual attributes that correspond to the identified security policy update. [0039] discloses infrastructure as a code where all the deployment descriptors are available as pard of a code repository. [0049-0051] discloses code repository may define configuration details or other physical information of the production environment. The validation module identifies security policy update using information from the security as code repository. The validation module may identify attributes of the production environment and configuration details from the repository, the identified attributes and configuration details may be all the attributes and configuration details of the production environment. [0054] discloses based on the validation result, the production environment is modified by deploying security update in the production environment. [0058-0059] discloses identifying attributes and configuration details of a production environment using an infrastructure as code repository. The configuration details is based on a repository containing physical information about the production environment. [0062] discloses deploying the security policy update to the production environment based on the validation results obtained using attributes and configuration details of the production environment. Also see [Claim 11].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the method of updating/modifying a production environment based on attributes and configuration information of the production environment provided in an associated code repository as taught by Bansal into the combination of Zhang, Sharma and Treptow because updating/modifying production environment based on the validation result will eliminate a misconfiguration of the production environment, which could lead to either a security exception or an availability exception in the production environment. Furthermore, the validation result based on attributes and configuration information of production environment obtained from the code repository would allow an administrator or any other module/entity to determine whether to update/modify the production environment or not (See Bansal: [0041] [0054]).
As discussed above the combination of Zhang, Sharma, Treptow and Bansal discloses updating a user interface…to modify, by the system in accordance with the task, the production environment to conform with the declarative descriptions in the associated source code repository, wherein the progress data is updated in response to completion of actions defined by the declarative descriptions (e.g. Zhang: [0069] discloses updating current status of the activity. [Fig. 1] [0042] [0044] discloses updating activity status. [0022-0023] rendering engine can be enabled to generate presentation of a web page for display to a user. This implies that rendering engine can update and present current activity/task status to the user via a web page. [Fig. 4][0072] discloses the activity tracker logs a unique activity ID, a unique task ID, the current status of activity, accumulated duration of the activity, and timestamps that identify when events occurred such as the beginning and end of execution of a task. Also see [0046-0048] [0050-0051] [Fig. 3] [56-58]. Zhang discloses that an activity tracker logs, for each task/activity, a unique activity ID, task ID, current status, accumulated duration, and timestamps indicating when execution events such as the beginning and end of execution occur, and that current activity status is updated for display to a user. Treptow: [Fig. 5] [0062] also discloses rendering a consumer web page that displays status information including job name, a progress bar and a status. [0041] discloses job status indicates the current progress of the requested job. Treptow also discloses rendering a consumer web page with a job name, status, and progress bar that is updated as job events complete, such that the job status indicates the current progress of the requested job. Bansal: [Abstract] discloses identifying a security policy update from a security as code repository, wherein the identified security policy update is a candidate for deployment to a production environment having a plurality of attributes defined by an infrastructure as code repository; identify, from the plurality of attributes and using the infrastructure as code repository, individual attributes that correspond to the identified security policy update. [0039] discloses infrastructure as a code where all the deployment descriptors are available as pard of a code repository. [0049-0051] discloses code repository may define configuration details or other physical information of the production environment. The validation module identifies security policy update using information from the security as code repository. The validation module may identify attributes of the production environment and configuration details from the repository, the identified attributes and configuration details may be all the attributes and configuration details of the production environment. [0054] discloses based on the validation result, the production environment is modified by deploying security update in the production environment. [0058-0059] discloses identifying attributes and configuration details of a production environment using an infrastructure as code repository. The configuration details is based on a repository containing physical information about the production environment. [0062] discloses deploying the security policy update to the production environment based on the validation results obtained using attributes and configuration details of the production environment. Also see [Claim 11]. Bansal discloses that the production environment’s configuration is defined declaratively in an infrastructure-as-code repository and that security policy updates from a security-as-code repository define configuration changes (actions) to be applied to the production environment, which are deployed to modify the production environment to conform with the desired state defined by the declarative descriptions.).
It would have been obvious to one of ordinary skill in the art, when implementing progress monitoring for Bansal’s declarative deployment task using the known progress-tracking and UI-update techniques of Zhang and Treptow, to update the progress data each time one of the declaratively specified deployment actions (e.g., application of a configuration change or portion of a security policy update) completes, thereby updating the progress data “in response to completion of actions defined by the declarative descriptions,” as claimed.
As per claim 3, the combination of Zhang, Sharma, Treptow and Bansal discloses (Previously presented) The method of claim 1 [See rejection to claim 1 above], Zhang further discloses wherein the identifier is unique (e.g. Zhang: [0072] discloses activity entry includes a unique activity ID, a unique task ID, etc. Also see [0081].).
As per claim 4, the combination of Zhang, Sharma, Treptow and Bansal discloses (Previously presented) The method of claim 1 [See rejection to claim 1 above], Zhang further discloses wherein receiving the task comprises receiving either a task with events specified by an end user or receiving a task and events which were learnt from historical data (e.g. Zhang: [0011][0044] discloses specifying events like active, pending or ended for activity. [Fig. 1][0041] discloses how asynchronous tasks for an activity may be scheduled and executed and how a status of the activity can change over time t0 to t7. Also see [0046] [0050-0051].).
As per claim 6, the combination of Zhang, Sharma, Treptow and Bansal discloses (Previously presented) The method of claim 1 [See rejection to claim 1 above], Sharma further discloses further comprising, after the identifier is returned to the process manager, using the process manager to send the identifier to the system (e.g. Sharma: [0104-0105] discloses a routine obtains a job identifier to identify the requested job and then provides the job identifier to the selected worker device.).
As per claim 11, the combination of Zhang, Sharma, Treptow and Bansal discloses (Previously presented) The method of claim 1 [See rejection to claim 1 above], Treptow further discloses further comprising updating a web page with the progress data by updating a progress bar according to events of the task which are completed (e.g. Treptow: [Fig. 5] [0062].).
As per claim 15, this is a system claim having similar limitations as cited in method claim 1. Thus, claim 15 is also rejected under the same rationale as cited in the rejection of rejected claim 1.
As per claim 21, this is a medium claim having similar limitations as cited in method claim 1. Thus, claim 21 is also rejected under the same rationale as cited in the rejection of rejected claim 1.
Claims 2, 5, 13-14 and 23-25 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Zhang in view of Sharma, Treptow and Bansal and further in view of Rucker et al. (US 2017/0061360 A1) (hereinafter Rucker).
As per claim 2, the combination of Zhang, Sharma, Treptow and Bansal discloses (Previously presented) The method of claim 1 [See rejection to claim 1 above], but does not expressly disclose wherein the task is completed by reaching a plurality of milestones each having an associated event, and wherein the process manager associates the task identifier with the events.
However, Rucker discloses wherein the task is completed by reaching a plurality of milestones each having an associated event, and wherein the process manager associates the task identifier with the events (e.g. Rucker: [0035] FIGS. 3A and 3B are screen shots of a portion of an interactive chart that illustrate a transition from a first view 260 (FIG. 3A) to a dynamic progress view 270 (FIG. 3B) for a task row 220. In the example shown in FIG. 3A, a group task bar 240A has small triangles at either end indicating the extent of a corresponding group of tasks (Task 1 and Task 2) and milestones (Milestone 1 and Milestone 2). Task bars 240B represent tasks. In the first view 260, the task bar that represents Task 1 (from which Task 2 depends) includes a progress bar 244. Alternatively, a different first view (e.g., without a progress bar) may be used. Milestone markers 248 represent milestones. Milestone markers (a diamond shape) can be considered a special type of task bar associated with a milestone. [0083] disclose different states can be presented in response to different events. Also see [0031-0033] [0041] [Figs. 5, 6A, and 6B].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the well-known technique of updating and displaying job status via webpage as taught by Rucker into the combination of Zhang, Sharma, Treptow and Bansal because dynamic progress view of Rucker will allow user to interact with the view, where a user can obtain information about a task, cause a notification to be generated, cause updates to resource allocation for a task, adjust projected completion time for a task, or invoke a combination of such functionality to ensure task is completed on time (See Rucker: [0044]).
As per claim 5, the combination of Zhang, Sharma, Treptow and Bansal discloses (Previously presented) The method of claim 1 [See rejection to claim 1 above], but does not disclose further comprising, during a learning mode, identifying events from the progress data and storing and publishing a task having the identified events.
However, Rucker discloses during a learning mode, identifying events from the progress data and storing and publishing a task having the identified events (e.g. Rucker: [0033] the dynamic progress view may depict a present rate, a historic rate, and/or a projected future rate of task completion. The dynamic progress view also may depict the present, historic, or projected future rate versus a planned rate of completion (e.g., with separate lines to represent each). [0035] FIGS. 3A and 3B are screen shots of a portion of an interactive chart that illustrate a transition from a first view 260 (FIG. 3A) to a dynamic progress view 270 (FIG. 3B) for a task row 220. In the example shown in FIG. 3A, a group task bar 240A has small triangles at either end indicating the extent of a corresponding group of tasks (Task 1 and Task 2) and milestones (Milestone 1 and Milestone 2). Task bars 240B represent tasks. In the first view 260, the task bar that represents Task 1 (from which Task 2 depends) includes a progress bar 244. Alternatively, a different first view (e.g., without a progress bar) may be used. Milestone markers 248 represent milestones. Milestone markers (e.g., a diamond shape) can be considered a special type of task bar associated with a milestone. Task name labels, task bars, and the like may be customizable in terms of border, color, etc. For example, task bars can be customized to represent different types of tasks, types of milestones, task status, milestone status, etc. [Figs. 7 and 8] [0043] disclose the interactive elements include a start point element 710 (diamond-shaped marker) to indicate start point for a task, a current time element 720 to indicate a current time for the task, and an end-of-time element 730. Also see [0064].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the dynamic progress view that displays different task events and milestones in the progress bar as taught by Rucker into the combination of Zhang, Sharma, Treptow and Bansal because dynamic progress view of Rucker will allow user to interact with the view, where a user can obtain information about a task, cause a notification to be generated, cause updates to resource allocation for a task, adjust projected completion time for a task, or invoke a combination of such functionality to ensure task is completed on time. It will also inform user when task is not expected to finish on time, and the projection may lead user to make decisions whether to reallocated resources to the task, extend allotted time for the task, or other potential changes based on the analysis/alerts (See Rucker: [0044] [0047]).
As per claim 13, the combination of Zhang, Sharma, Treptow and Bansal discloses (Previously presented) The method of claim 1 [See rejection to claim 1 above], but does not expressly disclose further comprising using the process manager to trigger an alert on the basis of the progress data.
However, Rucker discloses using the process manager to trigger an alert on the basis of the progress data (e.g. Rucker: [0011] [0057] discloses generating a notification associated with interactive chart based on a dynamic progress view. Also see [0032] [0044] [0049] [0052].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the method of generating a notification based on dynamic progress of the task as taught by Rucker into the combination of Zhang, Sharma, Treptow and Bansal because dynamic progress view of Rucker will allow user to cause updates to resource allocation for a task, adjust projected completion time for a task, or invoke a combination of such functionality based on the notification to ensure task is completed on time. It will also inform user when task is not expected to finish on time, and the projection may lead user to make decisions whether to reallocated resources to the task, extend allotted time for the task, or other potential changes based on the analysis/alerts (See Rucker: [0044] [0047]).
As per claim 14, the combination of Zhang, Sharma, Treptow and Bansal discloses (Previously presented) The method of claim 1 [See rejection to claim 1 above], but does not expressly disclose further comprising using the process manager to take automated corrective action on the basis of the progress data.
However, Rucker discloses using the process manager to take automated corrective action on the basis of the progress data (e.g. Rucker: [0011] [0057] discloses automatically taking corrective actions, such as updating resource allocation for a task or adjust a projected completion time for a task. Also see [0044] [0049].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the method of generating a notification based on dynamic progress of the task as taught by Rucker into the combination of Zhang, Sharma, Treptow and Bansal because dynamic progress view of Rucker will allow user to cause updates to resource allocation for a task, adjust projected completion time for a task, or invoke a combination of such functionality based on the notification to ensure task is completed on time. It will also inform user when task is not expected to finish on time, and the projection may lead user to make decisions whether to reallocated resources to the task, extend allotted time for the task, or other potential changes based on the analysis/alerts (See Rucker: [0044] [0047]).
As per claim 23, the combination of Zhang, Sharma, Treptow and Bansal discloses (Previously presented) The computer-readable storage medium of claim 21 [See rejection to claim 21 above], but does not expressly disclose further comprising computer-executable instructions stored thereupon which, when executed by the one or more processors of the computing device, cause the computing device to perform operations comprising querying a progress monitoring service to obtain progress data for the task, comparing the progress data with a threshold and, in response to the comparison, triggering an alert
However, Rucker discloses further comprising computer-executable instructions stored thereupon which, when executed by the one or more processors of the computing device, cause the computing device to perform operations comprising querying a progress monitoring service to obtain progress data for the task, comparing the progress data with a threshold and, in response to the comparison, triggering an alert (e.g. Rucker: [0051-0052] discloses message engine generates messages based on data that indicates current status. For example, if a projected rate of completion indicates that a task is stalled based on a specified threshold, a warning message may be sent to a manager or other responsible parties. [0057] discloses generating a notification based on information about task associated with the interactive chart.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the method of generating a notification based on dynamic progress of the task as taught by Rucker into the combination of Zhang, Sharma, Treptow and Bansal because dynamic progress view of Rucker will allow user to cause updates to resource allocation for a task, adjust projected completion time for a task, or invoke a combination of such functionality based on the notification to ensure task is completed on time. It will also inform user when task is not expected to finish on time, and the projection may lead user to make decisions whether to reallocated resources to the task, extend allotted time for the task, or other potential changes based on the analysis/alerts (See Rucker: [0044] [0047]).
As per claim 24, the combination of Zhang, Sharma, Treptow, Bansal and Rucker discloses (Previously presented) The computer-readable storage medium of claim 23 [See rejection to claim 23 above], further comprising computer-executable instructions stored thereupon which, when executed by the one or more processors of the computing device, cause the computing device to perform operations comprising querying a progress monitoring service to obtain progress data for the task, comparing the progress data with a threshold and, in response to the comparison, taking automated action to modify a process associated with the task (e.g. Rucker: [0051-0052] discloses message engine generates messages based on data that indicates current status. For example, if a projected rate of completion indicates that a task is stalled based on a specified threshold, a warning message may be sent to a manager or other responsible parties. [0011] [0057] discloses generating a notification based on information about task associated with the interactive chart and taking corrective action such as updating resource allocation for a task associated with the interactive chart or adjusting a projected completion time for a task. For example, the notification may include information related to the adjusted projected completion time or updated resource allocation. [0044] discloses a notification is generated based on information obtained about a task, and updating resource allocation for a task, adjust a projected completion time for a task, or a combination of such functionality or other functionality. [0049] discloses message includes information whether a task has been classified as stalled based on a specified threshold. If the task is determined to be stalled, corrected actions such as adjustments to reallocation of workers, time, other resources, etc.).
As per claim 25, the combination of Zhang, Sharma, Treptow, Bansal and Rucker discloses (Previously presented) The computer-readable storage medium of claim 24 [See rejection to claim 24 above], wherein comparing the progress data with the threshold identifies a bottleneck in the task and wherein the automated action comprises removing the bottleneck (e.g. Rucker: [0052] discloses message engine generates messages based on data that indicates current status. For example, if a projected rate of completion indicates that a task is stalled [bottleneck] based on a specified threshold, a warning message may be sent to a manager or other responsible parties. [0057] discloses generating a notification based on information about task associated with the interactive chart and taking corrective action such as updating resource allocation [automated action that removes the bottleneck] for a task associated with the interactive chart or adjusting a projected completion time for a task. For example, the notification may include information related to the adjusted projected completion time or updated resource allocation.).
Claims 7-9 and 22 are rejected under AIA 35 U.S.C. 103 as being unpatentable over Zhang in view of Sharma, Treptow and Bansal and further in view of Grube et al. (US 2013/0232392 A1) (hereinafter Grube).
As per claim 7, the combination of Zhang, Sharma, Treptow and Bansal discloses (Previously presented) The method of claim 1 [See rejection to claim 1 above], Zhang discloses further comprising receiving, from a system used to carry out the task, the identifier and progress data about progress of the task (e.g. Zhang: [Fig. 4][0072] discloses receiving, from the activity tracker, a unique activity ID, a unique task ID, the current status of activity, accumulated duration of the activity, and timestamps that identify when events occurred such as the beginning and end of execution of a task. Also see [Fig. 3 and related description] [0066] [0069] [Fig. 1] [0042] [0044] [0046-0048] [0050-0051] [Fig. 3] [56-58].).
The combination of Zhang, Sharma, Treptow and Bansal does not expressly disclose receiving, from a plurality of systems used to carry out the task, the identifier and progress data about progress of the task.
However, Grube discloses receiving, from a plurality of systems used to carry out the task, the identifier and progress data about progress of the task (e.g. Grube: [0278] discloses assigning set of partial tasks to multiple servers, each server executes the individually assigned partial task and sends the task status. The task status received from multiple servers indicates whether a corresponding partial task has been completed or not.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the method of assigning partial task (sub-task) to a plurality of servers and retrieving partial task status from the plurality of servers as taught by Grube into the combination of Zhang, Sharma, Treptow and Bansal because it would enable parallel processing of requested task to complete an overall task within a desired task execution time period. Furthermore, it is required to receive status of partial task from each server to determine to determine when the overall task is competed (See Grube: [0248] [0278]).
As per claim 8, the combination of Zhang, Sharma, Treptow and Bansal discloses (Previously presented) The method of claim 1 [See rejection to claim 1 above], but does not expressly disclose further comprising receiving, from a subsystem used to carry out at least part of the task, the identifier and progress data about progress of the task.
However, Grube discloses receiving, from a subsystem used to carry out at least part of the task, the identifier and progress data about progress of the task (e.g. Grube: [0278] discloses assigning set of partial tasks to multiple servers, each server executes the individually assigned partial task and sends the task status. The task status received from multiple servers indicates whether a corresponding partial task has been completed or not.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the method of assigning partial task (sub-task) to a plurality of servers and retrieving partial task status from the plurality of servers as taught by Grube into the combination of Zhang, Sharma, Treptow and Bansal because it would enable parallel processing of requested task to complete an overall task within a desired task execution time period. Furthermore, it is required to receive status of partial task from each server to determine to determine when the overall task is competed (See Grube: [0248] [0278]).
As per claim 9, the combination of Zhang, Sharma, Treptow, Bansal and Grube discloses (Previously presented) The method of claim 8 [See rejection to claim 8 above], wherein the subsystem has received the identifier from the system (e.g. Zhang: [0068] discloses executing pre-work operations to obtain an identifier of the activity that the task is associated with. [0079] discloses code outputs an identifier of the activity to which the task pertains. Also see [0072] [0081]. Grube: [0181] further discloses entry of task code identifying information includes task ID or another type of identifier to identify the task. [0183-0186] discloses DST client module selects task ID and sends it to a distribution module. The distribution module generates task allocation information from the selected task ID, the allocation information includes partitioning information, task execution information and intermediate result information.).
As per claim 22, the combination of Zhang, Sharma, Treptow and Bansal discloses (Previously presented) The computer-readable storage medium of claim 21 [See rejection to claim 21 above], further comprising computer-executable instructions stored thereupon which, when executed by the one or more processors of the computing device, cause the computing device to perform operations comprising sending the task identifier to a plurality of systems for carrying out the task (e.g. Zhang: [0068] [0079] discloses executing pre-work operations to obtain an identifier of the activity that the task is associated with, and outputting an identifier of the activity to which the task pertains. Also see [Figs. 3-4 and related description]. Sharma: [0104-0105] further discloses a routine obtains a job identifier to identify the requested job and then provides the job identifier to the selected worker device.).
The combination of Zhang, Sharma, Treptow and Bansal does not expressly disclose sending the task identifier to a plurality of systems for carrying out the task.
However, Grube discloses sending the task identifier to a plurality of systems for carrying out the task (e.g. Grube: [0181] discloses entry of task code identifying information includes task ID or another type of identifier to identify the task. [0183-0186] discloses DST client module selects task ID and sends it to a distribution module. The distribution module generates task allocation information from the selected task ID, the allocation information includes partitioning information, task execution information and intermediate result information. [0278] discloses assigning set of partial tasks to multiple servers, each server executes the individually assigned partial task and sends the task status. The task status received from multiple servers indicates whether a corresponding partial task has been completed or not.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the method of assigning task to a plurality of servers using task ID as taught by Grube into the combination of Zhang, Sharma, Treptow and Bansal because it would enable parallel processing of requested task to complete an overall task within a desired task execution time period (See Grube: [0248] [0278]).
Claim 10 is rejected under AIA 35 U.S.C. 103 as being unpatentable over Zhang in view of Sharma, Treptow and Bansal and further in view of Ma et al. (US 9,811,390 B1) (hereinafter Ma).
As per claim 10, the combination of Zhang, Sharma, Treptow and Bansal discloses (Previously presented) The method of claim 1 [See rejection to claim 1 above], but does not expressly disclose wherein the request for the task identifier is part of an HTTP request.
However, Ma discloses wherein the request for the task identifier is part of an HTTP request (e.g. Ma: [Claim 7] discloses receiving a composite HTTP POST job request and returning job identifier. [claim 14] receives HTTP POST job request from a client and returns a composite job identifier to the client.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the method of HTTP protocol to request and transmit information as taught by Ma into the combination of Zhang, Sharma, Treptow and Bansal because it provides communication encryption and secure way to transmit information (See Ma: [Col. 6, lines 12-50]).
Claim 12 is rejected under AIA 35 U.S.C. 103 as being unpatentable over Zhang in view of Sharma, Treptow and Bansal and further in view of Bell et al. (US 2007/0168861 A) (hereinafter Bell).
As per claim 12, the combination of Zhang, Sharma, Treptow and Bansal discloses (Previously presented) The method of claim 1 [See rejection to claim 1 above], further comprising updating a web page with the progress data by displaying a progress bar for the task (e.g. Treptow: [Fig. 5] [0062].).
The combination of Zhang, Sharma, Treptow and Bansal does not expressly disclose displaying a plurality of progress bars, one for the task and one for each of a plurality of previous tasks of the same type as the task.
However, Bell discloses updating a web page with the progress data by displaying a plurality of progress bars, one for the task and one for each of a plurality of previous tasks of the same type as the task (e.g. Bell: [Figs. 4, 5 and related description] [0018-0019] [0029] [0031].).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the method of displaying a plurality of progress bars corresponding to respective tasks including completed task and active task as taught by Bell into the combination of Zhang, Sharma, Treptow and Bansal because it is a convenient way of providing statuses of plurality of tasks that are being executed or completed in the system. Such progress indicator has the advantage of simultaneously informing the user that the number of tasks that are completed and some tasks are in fact executing and are progressing to completion (See Bell: [0002-0003] [0018-0019]).
Response to Arguments
Applicant’s arguments with respect to 35 U.S.C. § 103, filed 01/28/2026, have been fully considered but they are not persuasive.
Applicant argues that none of Zhang, Sharma, Treptow, or Bansal teach or suggest “modifying, by the system in accordance with the task, the production environment to conform with the declarative descriptions in the associated source code repository” and that the newly added clause “wherein the progress data is updated in response to completion of actions defined by the declarative descriptions” further distinguishes the claims. These arguments are not persuasive because they (i) rely on limitations not recited in the independent claims and (ii) are not commensurate in scope with the full teachings of the cited references.
As explained above and in the prior Office action, Bansal teaches a production environment whose configuration is defined declaratively in code repositories and that is modified to conform with those declarative descriptions. Bansal describes “infrastructure as code” where deployment descriptors and configuration details of a production environment are stored in a repository, i.e., declarative descriptions that specify a desired state of the production environment. Bansal further teaches identifying a security policy update from a “security-as-code” repository, validating the update using attributes and configuration details obtained from the infrastructure-as-code repository, and, based on the validation result, modifying the production environment by deploying the security policy update. These disclosures meet the limitation “modifying, by the system in accordance with the task, a production environment to conform with declarative descriptions in an associated source code repository, the declarative descriptions comprising a configuration that specifies a desired state of the production environment.”
With respect to the new language “wherein the progress data is updated in response to completion of actions defined by the declarative descriptions,” the claim does not require any particular type of “action” or any special form of “milestone-based” data. The claim broadly requires that the progress data be updated when actions defined in the declarative descriptions complete. Zhang teaches monitoring progress of a task/activity by logging an activity ID, task ID, current status, accumulated duration, and timestamps indicating when execution events such as the beginning and end of execution occur, and updating the current status of the activity for presentation to a user. Treptow teaches rendering a consumer web page that displays job status, including a progress bar and status, where job status indicates the current progress of the requested job and is updated as job events complete. In Bansal, the declarative descriptions (infrastructure-as-code and security-as-code repositories) define deployment actions—e.g., the attributes and configuration changes to be applied when deploying a security policy update—whose completion transitions the production environment toward the desired state. It would have been obvious to one of ordinary skill in the art to use the known progress-tracking and UI-update mechanisms of Zhang and Treptow to update progress data as those declaratively defined deployment actions (e.g., application of portions of the security policy update) complete, thereby updating progress data “in response to completion of actions defined by the declarative descriptions.”
Applicant’s arguments that the prior arts fail to disclose “progress monitoring of a declarative configuration-driven cloud deployment task,” “sending progress events as the system conforms to the declarative state,” or an external progress-monitoring architecture are not commensurate in scope with the claims. Independent claim 1, as amended, does not recite that the task must be a “declarative configuration-driven cloud deployment task,” that the progress data must be limited to “deployment-specific” events, or that the monitoring service must be external to the system performing the deployment; it only requires generic “progress data indicative of a progress of the task” that is updated in response to completion of actions defined in declarative descriptions. Zhang and Treptow provide such generic progress monitoring and UI updating, and Bansal provides the declarative configuration–driven deployment context. The combination therefore continues to render obvious the subject matter of claims 1, 15, and 21.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Hiren Patel whose telephone number is (571) 270-3366. The examiner can normally be reached on Monday-Friday 9:30 AM to 6:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
If attempts to reach the above noted Examiner by telephone are unsuccessful, the Examiner’s supervisor, April Y. Blair, can be reached at the following telephone number: (571) 270-1014. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center or Private PAIR to authorized users only. Should you have questions on access to Patent Center or the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
March 17, 2026
/HIREN P PATEL/Primary Examiner, Art Unit 2196