Prosecution Insights
Last updated: April 19, 2026
Application No. 18/524,017

SYSTEMS AND METHOD FOR ZERO DOWNTIME DURING CODE DEPLOYMENT AND PRODUCTION

Final Rejection §103§112
Filed
Nov 30, 2023
Examiner
NGUYEN, DUY KHUONG THANH
Art Unit
2199
Tech Center
2100 — Computer Architecture & Software
Assignee
Truist Bank
OA Round
2 (Final)
82%
Grant Probability
Favorable
3-4
OA Rounds
2y 9m
To Grant
99%
With Interview

Examiner Intelligence

Grants 82% — above average
82%
Career Allow Rate
440 granted / 539 resolved
+26.6% vs TC avg
Strong +35% interview lift
Without
With
+35.2%
Interview Lift
resolved cases with interview
Typical timeline
2y 9m
Avg Prosecution
38 currently pending
Career history
577
Total Applications
across all art units

Statute-Specific Performance

§101
13.3%
-26.7% vs TC avg
§103
59.8%
+19.8% vs TC avg
§102
6.3%
-33.7% vs TC avg
§112
9.6%
-30.4% vs TC avg
Black line = Tech Center average estimate • Based on career data from 539 resolved cases

Office Action

§103 §112
Notice of Pre-AIA or AIA Status 1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . Response to Amendment 2. This office action has been issued in response to amendment filed on 10/28/2025. Claims 1, 8 and 15 have been amended. Claims 1-20 are pending, of which claims, of which claim 1, claim 8 and 15 are in independent form. Accordingly, this action has been made FINAL. Response to Argument 3. The Office will maintain the non-statutory double rejection. Applicant's arguments with respect to claims 1-20 have been considered but are moot in view of the new ground(s) of rejection. Status of Claims 4. Claims 1-20 are pending, of which claims, of which claim 1, 8 and 15 are in independent form. The Office's Note: 5. The Office has cited particular paragraphs / columns and line numbers in the reference(s) applied to the claims above for the convenience of the Applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim(s), other passages and figures may apply as well. It is respectfully requested from the Applicant in preparing responses, to fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the cited passages as taught by the prior art or relied upon by the Examiner. Claim Rejections - 35 USC § 112 The following is a quotation of 35 U.S.C. 112(b): (b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention. The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph: The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention. 6. Claim 1, claim 8 and claim 15 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 1, claim 8 and claim 15 recite “wherein the new version of code designates changes in the new version of code as optional for the prior version of code used for processing the first request;” which is unclear. Does a datastore (database) needs to modify to add a column into a table? Does the new version of code need the datastore (database) to be modified? Appropriate correction is requested. 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, 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. 7. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Wagner (US 20180039506– hereinafter Wagner) , in view of Siddiqui (US 9,268,663– hereinafter Siddiqui) and further in view of Shankar (US 20080281845– hereinafter Shankar). Claim 1 is rejected, Wagner teaches a computer-implemented method, comprising: downloading, by a first computing device, code associated with processing requests directed toward a datastore, wherein the code is a new version of code to replace a prior version of code associated with processing requests directed toward the datastore (Wagner, US 20180039506, para [0069], At block 706, the versioning and deployment manager 150 initiates a download of the updated version of the code onto the virtual compute system 110. For example, the versioning and deployment manager 150 cause the updated version of the code to be downloaded onto an internal data store of the virtual compute system 110 (e.g., internal data store 160 of FIG. 1), a code cache on one of the instances (e.g., code cache 158C of FIG. 1), or one or more containers created on the virtual compute system 110. Para [0054-0062], the versioning and deployment manager 150 maintains the internal data store 160 that is used to store data accessed by one or more instances.); receiving, by the first computing device, a first request directed toward the datastore, wherein the first request is received while downloading the new version of code (Wagner, para [0067], At block 702 of the illustrative routine 700, the versioning and deployment manager 150 receives a code execution request associated a user code. For example, the versioning and deployment manager 150 may receive the request from the frontend 120 after the frontend has performed any initial processing on the request. As discussed above, the request may specify the code to be executed on the virtual compute system 110, and any operating conditions such as the amount of compute power to be used for processing the request, the type of the request (e.g., HTTP vs. a triggered event), the timeout for the request (e.g., threshold time after which the request may be terminated), security policies (e.g., may control which instances in the warming pool 130A are usable by which user), etc. Para [0050-0051], the versioning and deployment manager 150 allows the older version of the code to be used while the new version is being downloaded onto an internal data store, a code cache of a particular instance, and/or a container. Para [0054-0062], the versioning and deployment manager 150 maintains the internal data store 160 that is used to store data accessed by one or more instances); processing, by the first computing device, the first request directed toward the datastore using the prior version of code while the first computing device is downloading the new version of code (Wagner, para [0070], At block 708, the versioning and deployment manager 150 causes the code execution request associated with the updated version of the code to be processed with an older version of the code that was previously loaded on one of the containers before the code execution request was received at block 702. Para [0050-0051], the versioning and deployment manager 150 allows the older version of the code to be used while the new version is being downloaded onto an internal data store, a code cache of a particular instance, and/or a container.); switching, by the first computing device, from the prior version of code to the new version of code (Wagner, para [0059], FIG. 5 illustrates the configuration after all the containers have switched to the code (2) and are running the code (2) in connection with incoming code execution requests. In FIG. 5, the code (1) has also been removed from the code cache 159C, for example, by the versioning and deployment manager 150 after it has determined (e.g., based on the time elapsed since the code (1) was updated, or based on a user indication to eventually phase out the code (1)) that the code (1) is no longer needed.); and The Office would like to use prior art Siddiqui to back up Wagner to further teach limitation code associated with processing requests directed toward a datastore((Siddiqui, US 9,268,663, column 2, line 10 to 26, the analysis of the different software versions may include an analysis of system performance resulting from operation of each software version. System performance may be based on resource consumption such as server workload, processor workload, memory allocation storage use, bandwidth, response time, and so forth. System performance may be analyzed using business metrics, system level metrics (e.g., memory, processor, etc.), and/or application level metrics (e.g., bugs, errors, etc.). In some embodiments, the analysis of different software versions may include an analysis of results of user interaction (use data) with one of the software versions. For example, the results may indicate a better or worse conversion rate (e.g., click through, purchase, etc.), a better or worse completion rate (e.g., premature expiration of code, early exit, etc.), and/or other results from user interaction with each software version.) It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Siddiqui into Wagner to analyze and control software testing. The minimal disruption, delay, or latency are enabled when allocating the users to the versions of software. The controller can easily update the allocation rules dynamically based on data received directly from the metrics analyze as suggested by Siddiqui (See abstract and summary). Wagner and Siddiqui do not explicitly teach wherein the new version of code designates changes in the new version of code as optional for the prior version of code used for processing the first request; However, Shankar teaches wherein the new version of code designates changes in the new version of code as optional for the prior version of code used for processing the first request(Shankar, US 20080281845, para [0004], Applications are upgraded from time to time. For instance, an installed application may be upgraded when a new version of the application code becomes available. With database and related applications, upgrading to a new version frequently requires that a column be added to an existing table, e.g., stored in a relational database. Para [0005], Upon adding a new column, one of two conditions are is typically satisfied. Either all existing rows in the table store a null value for the column being added, or all existing rows store a default value for that column. Fig. 1 and para [0018-0022], computing the query may include, in effect, rewriting a query the query to replace reference to column with a function whose input is the column. If the column value is Non-Null, the function returns the Non-Null value. If the column value is NULL, the default value is returned.); It would have obvious to one having ordinary skill in the art before the effecting filing date of the claimed invention to combine the teachings of cited references. Thus, one of ordinary skill in the art before the effecting filing date of the claimed invention would have been motivated to incorporate Shankar into Wagner and Siddiqui to hold null values in an attribute of a body of records in a database, where metadata of the database defines a constraint of the attribute. A value is generated for the attribute to compute a query. The null values held in the attribute are dynamically translated to default values as suggested by Shankar (See abstract and summary). Claim 2 is rejected for the reasons set forth hereinabove for claim 1, Wagner, Siddiqui and Shankar teach the computer-implemented method of claim 1, further comprising directing a second request to be processed by a second computing device, wherein the second request is directed toward the datastore to be processed by the second computing device while the first computing device is switching from the prior version of code to the new version of code(Siddiqui, US 9,268,663, fig. 6 and column 10, line 15 to line 59, At 604, the allocation module 112 may receive a request from a user, such as the user 102. At 606, the allocation module 112 may determine whether the user is a previous user that has been allocated to one of the plurality of versions of software available via the framework 202 (e.g., the version A, the version B, the version N, etc.). Fig. 1 and column 3 line 57 to column 4, line 12, As shown in FIG. 1, each version of the software (e.g., the version A 108 and the version B 110) is associated with system resources 120. The system resources 120 may be cloud computing services, server farm(s), or other types of resources that can be allocated to execute the various versions of the software. For example, the controller 116 may allocate a percentage, computational time value, or other amount of the system resources 120 to one of the versions of the software. As more users are allocated to a particular version of the software (e.g., the version B 110), the controller 116 may reallocate more system resources previously used to support another version of the software (e.g., the version A 108) to the particular version of the software. ). Claim 3 is rejected for the reasons set forth hereinabove for claim 1, Wagner, Siddiqui and Shankar teach the computer-implemented method of claim 1 further comprising validating the new version of code for a first plurality of nodes serviced by the first computing device, wherein a second computing device services a second plurality of nodes(Siddiqui, column 8, line 61 to column 9 line 6, At 412, the metrics analyzer 118 may measure system performance and/or results of user interaction. For example, the metrics analyzer 118 may extract an output of the version of software assigned at the operation 408, including a measurement of system resources for the execution of the version (or approximation based on batch processes of many uses of the version). At 414, the metrics analyzer 118 may aggregate the measure data from the user and other users. The measured data may include use results and/or system performance data. The aggregation may be performed on a one by one basis or via batch processing at intervals (e.g., predetermined, periodic, random, etc.). Fig. 1 and column 3 line 57 to column 4, line 12, As shown in FIG. 1, each version of the software (e.g., the version A 108 and the version B 110) is associated with system resources 120. The system resources 120 may be cloud computing services, server farm(s), or other types of resources that can be allocated to execute the various versions of the software. For example, the controller 116 may allocate a percentage, computational time value, or other amount of the system resources 120 to one of the versions of the software. As more users are allocated to a particular version of the software (e.g., the version B 110), the controller 116 may reallocate more system resources previously used to support another version of the software (e.g., the version A 108) to the particular version of the software. ). Claim 4 is rejected for the reasons set forth hereinabove for claim 3, Wagner, Siddiqui and Shankar teach the computer-implemented method of claim 3, wherein validating the new version of code for the first plurality of nodes serviced by the first computing device includes monitoring at least one of a log, an application status, and live traffic (Siddiqui, column 8, line 61 to column 9 line 6, At 412, the metrics analyzer 118 may measure system performance and/or results of user interaction. For example, the metrics analyzer 118 may extract an output of the version of software assigned at the operation 408, including a measurement of system resources for the execution of the version (or approximation based on batch processes of many uses of the version). At 414, the metrics analyzer 118 may aggregate the measure data from the user and other users. The measured data may include use results and/or system performance data. The aggregation may be performed on a one by one basis or via batch processing at intervals (e.g., predetermined, periodic, random, etc.).). Claim 5 is rejected for the reasons set forth hereinabove for claim 3, Wagner, Siddiqui and Shankar teach the computer-implemented method of claim 3, further comprising shutting down the second computing device based upon, at least in part, a successful validation of the new version of code for the first plurality of nodes serviced by the first computing device(Wagner, para [0059], FIG. 5 illustrates the configuration after all the containers have switched to the code (2) and are running the code (2) in connection with incoming code execution requests. In FIG. 5, the code (1) has also been removed from the code cache 159C, for example, by the versioning and deployment manager 150 after it has determined (e.g., based on the time elapsed since the code (1) was updated, or based on a user indication to eventually phase out the code (1)) that the code (1) is no longer needed. Siddiqui, Fig. 1 and column 3 line 57 to column 4, line 12, As shown in FIG. 1, each version of the software (e.g., the version A 108 and the version B 110) is associated with system resources 120. The system resources 120 may be cloud computing services, server farm(s), or other types of resources that can be allocated to execute the various versions of the software. For example, the controller 116 may allocate a percentage, computational time value, or other amount of the system resources 120 to one of the versions of the software. As more users are allocated to a particular version of the software (e.g., the version B 110), the controller 116 may reallocate more system resources previously used to support another version of the software (e.g., the version A 108) to the particular version of the software. ). Claim 6 is rejected for the reasons set forth hereinabove for claim 5, Wagner, Siddiqui and Shankar teach the computer-implemented method of claim 5, wherein shutting down the second computing device includes servicing the second plurality of nodes to process a fourth request directed toward the datastore using the new version of code(Wagner, para [0059], FIG. 5 illustrates the configuration after all the containers have switched to the code (2) and are running the code (2) in connection with incoming code execution requests. In FIG. 5, the code (1) has also been removed from the code cache 159C, for example, by the versioning and deployment manager 150 after it has determined (e.g., based on the time elapsed since the code (1) was updated, or based on a user indication to eventually phase out the code (1)) that the code (1) is no longer needed. Siddiqui, Fig. 1 and column 3 line 57 to column 4, line 12, As shown in FIG. 1, each version of the software (e.g., the version A 108 and the version B 110) is associated with system resources 120. The system resources 120 may be cloud computing services, server farm(s), or other types of resources that can be allocated to execute the various versions of the software. For example, the controller 116 may allocate a percentage, computational time value, or other amount of the system resources 120 to one of the versions of the software. As more users are allocated to a particular version of the software (e.g., the version B 110), the controller 116 may reallocate more system resources previously used to support another version of the software (e.g., the version A 108) to the particular version of the software.). Claim 7 is rejected for the reasons set forth hereinabove for claim 6, Wagner, Siddiqui and Shankar teach the computer-implemented method of claim 6, further comprising deploying the new version of code to the second computing device(Wagner, para [0059], FIG. 5 illustrates the configuration after all the containers have switched to the code (2) and are running the code (2) in connection with incoming code execution requests. In FIG. 5, the code (1) has also been removed from the code cache 159C, for example, by the versioning and deployment manager 150 after it has determined (e.g., based on the time elapsed since the code (1) was updated, or based on a user indication to eventually phase out the code (1)) that the code (1) is no longer needed. Siddiqui, column 9, line 25 to line 40, the version B may be an updated version of the software used in the version A or both the version A and the version B may be new software subjected to a comparison test. Siddiqui, Fig. 1 and column 3 line 57 to column 4, line 12, As shown in FIG. 1, each version of the software (e.g., the version A 108 and the version B 110) is associated with system resources 120. The system resources 120 may be cloud computing services, server farm(s), or other types of resources that can be allocated to execute the various versions of the software. For example, the controller 116 may allocate a percentage, computational time value, or other amount of the system resources 120 to one of the versions of the software. As more users are allocated to a particular version of the software (e.g., the version B 110), the controller 116 may reallocate more system resources previously used to support another version of the software (e.g., the version A 108) to the particular version of the software.). As per claim 8, this is the medium claim to method claim 1. Therefore, it is rejected for the same reasons as above. As per claim 9, this is the medium claim to method claim 2. Therefore, it is rejected for the same reasons as above. As per claim 10, this is the medium claim to method claim 3. Therefore, it is rejected for the same reasons as above. As per claim 11, this is the medium claim to method claim 4. Therefore, it is rejected for the same reasons as above. As per claim 12, this is the medium claim to method claim 5. Therefore, it is rejected for the same reasons as above. As per claim 13, this is the medium claim to method claim 6. Therefore, it is rejected for the same reasons as above. As per claim 14, this is the medium claim to method claim 7. Therefore, it is rejected for the same reasons as above. As per claim 15, this is the medium claim to method claim 1. Therefore, it is rejected for the same reasons as above. As per claim 16, this is the medium claim to method claim 2. Therefore, it is rejected for the same reasons as above. As per claim 17, this is the medium claim to method claim 3. Therefore, it is rejected for the same reasons as above. As per claim 18, this is the medium claim to method claim 4. Therefore, it is rejected for the same reasons as above. As per claim 19, this is the medium claim to method claim 5. Therefore, it is rejected for the same reasons as above. As per claim 20, this is the medium claim to method claim 6. Therefore, it is rejected for the same reasons as above. Conclusion 8. THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUY KHUONG THANH NGUYEN whose telephone number is (571)270-7139. The examiner can normally be reached Monday - Friday 0800-1630. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lewis Bullock can be reached on 5712723759. 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. /DUY KHUONG T NGUYEN/ Primary Examiner, Art Unit 2199
Read full office action

Prosecution Timeline

Nov 30, 2023
Application Filed
Aug 06, 2025
Non-Final Rejection — §103, §112
Oct 28, 2025
Response Filed
Oct 28, 2025
Applicant Interview (Telephonic)
Oct 29, 2025
Examiner Interview Summary
Nov 18, 2025
Final Rejection — §103, §112
Jan 09, 2026
Interview Requested

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12596634
TESTING A MACHINE LEARNING MODEL
2y 5m to grant Granted Apr 07, 2026
Patent 12596534
Spreadsheet-Based Software Application Development
2y 5m to grant Granted Apr 07, 2026
Patent 12578935
COMPOSITION OF PATTERN-DRIVEN REACTIONS IN REAL-TIME DATAFLOW PROGRAMMING
2y 5m to grant Granted Mar 17, 2026
Patent 12578960
DISTINGUISHING PATTERN DIFFERENCES FROM NON-PATTERN DIFFERENCES
2y 5m to grant Granted Mar 17, 2026
Patent 12572333
Vehicle Electronic Control Device and Program Rewriting Method
2y 5m to grant Granted Mar 10, 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
82%
Grant Probability
99%
With Interview (+35.2%)
2y 9m
Median Time to Grant
Moderate
PTA Risk
Based on 539 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