Prosecution Insights
Last updated: April 19, 2026
Application No. 17/591,179

SERVICE UPDATE MANAGEMENT

Non-Final OA §103
Filed
Feb 02, 2022
Examiner
MOTTER, JORDAN SCOTT
Art Unit
2198
Tech Center
2100 — Computer Architecture & Software
Assignee
International Business Machines Corporation
OA Round
3 (Non-Final)
77%
Grant Probability
Favorable
3-4
OA Rounds
3y 6m
To Grant
99%
With Interview

Examiner Intelligence

Grants 77% — above average
77%
Career Allow Rate
24 granted / 31 resolved
+22.4% vs TC avg
Strong +27% interview lift
Without
With
+27.1%
Interview Lift
resolved cases with interview
Typical timeline
3y 6m
Avg Prosecution
14 currently pending
Career history
45
Total Applications
across all art units

Statute-Specific Performance

§101
18.8%
-21.2% vs TC avg
§103
58.3%
+18.3% vs TC avg
§102
2.6%
-37.4% vs TC avg
§112
16.2%
-23.8% vs TC avg
Black line = Tech Center average estimate • Based on career data from 31 resolved cases

Office Action

§103
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 . 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 12/10/2025 has been entered. Response to Amendment This communication is in response to the RCE filed on 12/10/25. Claims 1-20 remain pending in the application and as such are being considered on the merits. Response to Arguments Applicant’s arguments filed 12/10/25 have been fully considered and are persuasive. However, upon further search and consideration, a new ground of rejection is made in view of newly found prior art. For further details please refer to the 103 rejection section below. Specification The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claim(s) 1-3, 8-10, and 15-17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zoll et al. (US 20130232496) in view of Tsujino et al. (US 20070118838), Farchi et al. (US 20070143766), Ashirvad et al. (US 20210294596), and Wahlert et al. (US 20060053305). Regarding claims 1, 8, and 15, Zoll teaches: A method / system / computer program product comprising a computer readable storage medium and processor, comprising during a first update procedure for a first service in a computing system: in response to a detection that the first update procedure is failed (a process is detected to have fallen into a time-out state par. 0030), checking, by one or more processors, a state of a second service on which the first service depends in the computing system (checking on different process that the waiting/time-out process is relying on through a hang manager or by reviewing process state information par. 0031 and 0042-0044); releasing, by the one or more processors, resources allocated to the first update procedure by the computing system (releasing resource of blocked process par. 0051); allocating, by the one or more processors, the released resources to the second update procedure of the second service (resources being released to the waiting process par. 0029 – 0031); and implementing, by the one or more processors, the second update procedure based on the allocated released resources (proceeding with execution of the waiting process once resources are released to it par. 0035, 0038, and 0051). Although Zoll does not explicitly teach its processes being update procedures, it would be obvious to one of ordinary skill in the art that due to the current BRI of the claim language, an update procedure is an example of a process and therefore it would be obvious to try to one of ordinary skill in the art to apply the known process outlined in Zoll to a known entity as an update procedure as proper under MPEP 2143(I)). Further, Zoll does not explicitly teach suspending an update procedure to begin a different update procedure/service. However, Tsujino teaches: in response to the second service being in a first state which indicates that a second update procedure of the second service is waiting for the computing system to allocate resources (task going into a wait state when it is determined that the needed resources are being used par. 0010 and 0021), suspending, by the one or more processors, the first update procedure (the task currently using the resources is determined to have a lower priority than the task requestion the resources, therefore the current task is placed into the pause state par. 0021); It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zoll with the teachings of Tsujino since the method of task management as shown in Tsujino would enhance Zoll with the ability to manage various tasks through the use of a priority inheritance scheme, ensuring that tasks do not stay in a waiting state for a long time (Tsujino: par. 0026 – 0027). Further, the implementation of the state changing techniques as shown in Tsujino would further enhance the hang avoidance techniques by showing that each process of Tsujino is given a priority. This priority gives each resource access to the necessary resource for execution, so when a higher priority is recognized, the current process is put into a wait state and the higher priority process is executed. The combination of this process in the environment of Zoll applies a known technique to improve similar devices, since applying the combination of Zoll and Tsujino has a blocking task that would be given a higher priority, in an effort to get rid of the potential deadlock. The other tasks running would be put into a wait state, resources would be released to the blocking task to execute, and once done the resources will go back to the necessary tasks and execution continues (See Tsujino par. 0010 and Zoll par. 0030 – 0032). Zoll and Tsujino do not explicitly teach monitoring for completeness and invoking an API for state information. However, Farchi teaches: utilizing a detector to request an application programming interface (API) server to provide states about the first service and a second service (deadlock detection tool being activated by invoking an API and specifying synchronization objects par. 0046); monitoring, by the one or more processors, whether the second update procedure of the second service is finished when the released resources are allocated (monitoring of threads to determine failure or completion of execution by another thread par. 0023); and continuing, by the one or more processors, the first update procedure once the second update procedure of the second service is finished (thread properly releasing locks and allowing for the other thread to resume execution as expected par. 0012 – 0015 and 0030). It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zoll and Tsujino with the teachings of Farchi since the deadlock detection tool as outlined in Farchi provides methodology for determining and preventing deadlocks which may negatively affect/disrupt execution in a multiprocessing environment, thereby creating a less intrusive approach for program code testing (Farchi: par. 006 – 0011). Farchi does not explicitly teach the creation of a state object for storing information about failed states and dependencies or the use of a timer for update states. However, Ashirvad teaches: triggering, by the one or more processors, the detector periodically, using a timer, to obtain a latest state for the corresponding dependent service to determine whether the corresponding dependent service has been updated to a latest version (polling computing device receiving current software version indicators of software installed at monitored devices, using polling intervals for polling computing devices which can be adjusted par. 0014, 0018, 0030 – 0042); It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the applications to combine the teachings of Zoll, Tsujino, and Farchi with the teachings of Ashirvad since the polling methodology, as outlined in Ashirvad, provides the ability for checking current software version indicators as quickly as possible without overwhelming computing resources. Ashirvad does not explicitly teach state objects for tracking failed updates. However, Wahlert teaches: creating, by the one or more processors, a state object, using the detector, for tracking a status of services undergoing updates and storing information about the failed first update procedure for the first service and its corresponding dependent service (when failure occurs, the task of the job that failed updates a physical object state and fails, then proceeds to further recover/cleanup activities par. 0110 and 0321, the jobs may be to update par. 0090); It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zoll, Tsujino, Farchi, and Ashirvad with the teachings of Wahlert since the failure/cleanup activities taught by Wahlert would further enhance the states taught by the previous references by recording failures in task and job trails, simultaneously allowing for prompt and automated recovery activity or the creation of makeup jobs if necessary. Regarding claims 2, 9, and 16, Tsujino teaches: wherein implementing the second update procedure based on the allocated released resources further comprises: in response to the second update procedure being executed but not finished (task in the process of running but not yet put into END par. 0017 – 0021), updating, by the one or more processors, the state of the second service to a second state which indicates that the second update procedure of the second service is executing (updating the task information when the task having been placed in a wait state finally enters its critical section and begins execution par. 0021); and in response to the second update procedure being finished, updating, by the one or more processors, the state of the second service to a third state which indicates that the second update procedure of the second service is finished (updating task information to END whenever the task completes the exclusive process or exits the critical section par. 0021 and 0017). For motivation to combine see claim 1 above. Regarding claims 3, 10, and 17, Tsujino teaches: in response to the second service being in the second state, continuing, by the one or more processors, suspending the first update procedure (when a task is executing an exclusive process, the other task will be placed into a wait state until resources are released par. 0021 and 0066); in response to the second service being in the third state, allocating, by the one or more processors, resources to the first update procedure of the first service (releasing resources back to the task in the wait state so it can begin execution of its own critical state or exclusive process par. 0021 and 0066); and continuing, by the one or more processors, the first update procedure based on the allocated resources (restarting the suspended exclusive process or allowing the task to enter its critical section and execute par. 0021 – 0025). For motivation to combine see claim 1 above. Claim(s) 4-6, 11-13, and 18-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zoll in view of Tsujino, Farchi, Ashirvad, and Wahlert, and further in view of Giannetti (US 20190294504). Regarding claims 4, 11, and 18, Giannetti teaches: wherein the first and second services are developed based on a Kubernetes architecture, and the second service is provided by at least one instance that is defined in a Kubernetes deployment of the second service (server representing a computer executing a containerized Kubernetes program system, in which there are various tasks implementing multi-tasking through state machines with the addition of rollback capabilities for the workflow of the services par. 0001 – 0007, and 0103 – 0105). It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zoll, Tsujino, Farchi, Ashirvad, and Wahlert with the Kubernetes program system of Giannetti since the process of Giannetti is directed towards task management with rollback capabilities alongside the use of state machines, thereby enhancing the teachings of the other references with the ability for the listed processes/tasks to be included in a Kubernetes system without the loss of any functionality (Giannetti: par. 0001 – 0007, and 0103 – 0105). Regarding claims 5, 12, and 19, Tsujino teaches: wherein the first state further comprises a state which indicates that at least one instance of the second service is waiting for the computing system to allocate resources (since multiple tasks are being run at once, with varying critical sections and exclusive processes that need control of the shared resources, then only one task will be executing at a time until the release of the resources to the next task which has been placed in either the wait or pause state par. 0010 and 0021). It would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zoll, Farchi, Ashirvad, Wahlert, and Giannetti with the teachings of Tsujino since the method of task management as shown in Tsujino would enhance Zoll with the ability to manage various tasks through the use of a priority inheritance scheme, ensuring that tasks do not stay in a waiting state for a long time (Tsujino: par. 0026 – 0027). Regarding claims 6 and 13, Tsujino teaches: wherein allocating the released resources to the second service comprises: allocating, by the one or more processors, the released resources to the at least one instance of the second service (the resources are released and used by the waiting task as soon as a running task is placed into an END state par. 0008 – 0014 and 0066 – 0071). For motivation to combine see claim 4 above. Claim(s) 7 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zoll in view of Tsujino, Farchi, Ashirvad, and Wahlert, and further in view of Pogrebinsky (US 20170168797). Regarding claims 7 and 14, Pogrebinsky teaches: wherein the computing system is provided in a developing environment, in which resources of the computing system are not enough for supporting both the first update procedure and the second update procedure (par. 0034 – 0039). It would be obvious to one of ordinary skill in the art prior to the effective filing date of the application that since resource deadlocks exist that the resources are not enough to support both the update procedures. Further, it would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zoll, Tsujino, Farchi, Ashirvad, and Wahlert with the Pogrebinsky since the well-known environment of Pogrebinsky allows for deadlock performance associated with resources in a known software development environment, e.g. environment used by developers (Pogrebinsky: par. 0019-0021, 0037-0039). Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zoll in view of Tsujino, Farchi, Ashirvad, Wahlert, and Giannetti, and further in view of Pogrebinsky (US 20170168797). Regarding claim 20, Pogrebinsky teaches: wherein allocating the released resources to the second service comprises: allocating, by the one or more processors, the released resources to the at least one instance of the second service (par. 0037-0039) and wherein the computing system is provided in a developing environment, in which resources of the computing system are not enough for supporting both the first update procedure and the second update procedure (par. 0034 – 0039). It would be obvious to one of ordinary skill in the art prior to the effective filing date of the application that since resource deadlocks exist that the resources are not enough to support both the update procedures. Further, it would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the application to combine the teachings of Zoll, Tsujino, Farchi, Ashirvad, Wahlert, and Giannetti with the Pogrebinsky since the well-known environment of Pogrebinsky allows for deadlock performance associated with resources in a known software development environment, e.g. environment used by developers (Pogrebinsky: par. 0019-0021, 0037-0039). Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Jagtiani et al. (US 20140201564) which discloses polling nodes individually for software or hardware faults. Any inquiry concerning this communication or earlier communications from the examiner should be directed to JORDAN SCOTT MOTTER whose telephone number is (703)756-1550. The examiner can normally be reached Monday - Friday 7:30 a.m. - 4:30 p.m.. 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, Pierre Vital can be reached at 571-272-4215. 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. /J.S.M./Examiner, Art Unit 2198 /PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Read full office action

Prosecution Timeline

Feb 02, 2022
Application Filed
Oct 17, 2023
Response after Non-Final Action
Mar 20, 2025
Non-Final Rejection — §103
Jul 01, 2025
Response Filed
Jul 09, 2025
Applicant Interview (Telephonic)
Jul 10, 2025
Examiner Interview Summary
Oct 08, 2025
Final Rejection — §103
Dec 10, 2025
Request for Continued Examination
Dec 21, 2025
Response after Non-Final Action
Feb 05, 2026
Non-Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12596571
INSTRUCTION SETS FOR GENERATING SCHEDULES FOR TASK EXECUTION IN COMPUTING SYSTEMS
2y 5m to grant Granted Apr 07, 2026
Patent 12585482
MANAGEMENT THROUGH ON-PREMISES AND OFF-PREMISES SYSTEMS
2y 5m to grant Granted Mar 24, 2026
Patent 12578982
SYSTEM ON CHIP, CONTROLLER AND VEHICLE
2y 5m to grant Granted Mar 17, 2026
Patent 12572380
CONTROL DEVICE, SYSTEM ON CHIP, AND ELECTRONIC DEVICE
2y 5m to grant Granted Mar 10, 2026
Patent 12561171
OPTIMIZATION FUNCTION GENERATION APPARATUS, OPTIMIZATION FUNCTION GENERATION METHOD, AND PROGRAM
2y 5m to grant Granted Feb 24, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
77%
Grant Probability
99%
With Interview (+27.1%)
3y 6m
Median Time to Grant
High
PTA Risk
Based on 31 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month