CTFR 18/590,196 CTFR 88162 Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia 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 This office action has been issued in response to amendment filed on 02/25/2026. Claims 1-20 are pending, of which claims, of which claim 1 and 14 are in independent form. Accordingly, this action has been made FINAL 12-151 AIA 26-51 12-51 Status of Claims Claims 1-20 are pending, of which claims, of which claim 1 and 14 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 § 103 07-20-aia AIA 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. 07-21-aia AIA 6. Claim s 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kimball (US 11042369 – hereinafter Kimball ) and further in view of Gudka (US 20210149783– hereinafter Gudka ) . Claim 1 is rejected, Kimball teaches a method, performed by at least one processor of a system upon executing instructions for implementing a large language model (LLM), comprising ( Kimball , abstract and summary): receiving a source code ( Kimball , US 11042369, column 10, line 59 to column 11, line 15, fig. 2 and At step 208, the computing device may execute an artificial intelligence (AI) model to perform source code analysis on the subset of inefficient functions and identify code violations within the source code of the inefficient functions); determining whether or not the source code violates at least one coding rule ( Kimball , fig. 2 and column 10, line 59 to column 11, line 15, The computing device may identify code violations within the source code of the subset of functions based on performing source code analysis according to a set of rules for code violation patterns… The rules for code violation identification may comprise the code violation patterns.); based on determining that the source code violates the at least one coding rule, presenting information associated with the violation of the at least one coding rule to a first user ( Kimball , fig. 2 and column 11, line 26 to 36, At step 210, the computing device may execute the AI model to generate one or more refactoring options to optimize the source code of the inefficient functions. The computing device may generate refactoring options on a graphical user interface for the user to select. Each refactoring option may comprise a change to the source code configured to remediate/correct the code violations. The refactoring options may comprise refactoring suggestions to optimize the inefficient functions. The user may implement the refactoring suggestions automatically or manually to optimize the inefficient functions/algorithms.); receiving, from the first user, a first user feedback associated with the presented information ( Kimball , fig. 2 and column, line 17 to 25, The computing device may train the AI model to determine and update the rules for code violation identification. The AI model may learn from historical data on the code violations and the use's feedbacks on the identified code violations. For example, if the user consistently selects “do nothing” for certain types of code violations, the AI model may update the rules for code violation identification accordingly, such that those types of code violations are no longer identified.); determining, based on the first user feedback, whether or not at least one rule deviation is to be implemented ( Kimball , fig. 2 and column 11, line 64 to column 12, line 11, The computing device may periodically retrain the AI model by learning from historical data on the code violations, the use's feedbacks and selections of refactoring options, and user manual refactoring operations for different code violations. The retrained AI model may update the rules for code violation identification and the rules for refactoring.); based on determining that the at least one rule deviation is to be implemented, performing at least one operation to manage at least one deviation report according to the first user feedback ( Kimball , fig. 2 and column 11, line 64 to column 12, line 11, The computing device may periodically retrain the AI model by learning from historical data on the code violations, the use's feedbacks and selections of refactoring options, and user manual refactoring operations for different code violations. The retrained AI model may update the rules for code violation identification and the rules for refactoring. Fig. 4 and column 17, line 1 to line 22, if the user consistently selects “do nothing” for certain types of code violations, the AI model 422 may update the rules for code violation identification 426 accordingly, such as those types of code violations are no longer identified.); and based on determining that the at least one rule deviation is not to be implemented, performing at least one operation to manage the source code (( Kimball , fig. 2 and column 12, line 12 to line 27, At step 212, upon receiving a selected refactoring option, the computing device may refactor the source code of the inefficient functions to remove the code violations based on the selected refactoring option. Upon receiving the user selection of the one or more refactoring options, the computing device may implement the selected options to the legacy software. For example, the computing device may alter the source code according to the selected refactoring option to remove the code violations. In some other embodiments, the computing device may automatically refactor the source code to remove the code violations based on the rules for refactoring. Accordingly, the computing device may automatically correct certain types of code violations, while other code violations may be displayed to the user for manual correction or for correction by the software refactoring module after user selection.). The Office would like to use prior art Gudka to back up Kimball to further teach limitation deviation report ( Gudka , US 20210149783, fig. 5 and para [0061], A process flow for a second embodiment of the invention is shown in FIG. 5. In this embodiment, the system is unable to find a fix event existing in runbook library 127 that addresses the error condition which caused the break event to be generated. The process is similar to that shown in FIG. 4. At 502, an alert is received by alert monitoring component 122 from monitoring component 110 which has generated a break event related to computer process 112. Alert monitoring component 122 may determine that either no runbook exists for new process 112 for that a runbook does exist for new process 112 but does not contain the received alert. At 504, correlation component 124 accesses one or more runbooks 126a . . . 126n stored in runbook library 127 on data storage 128. At 506, the process attempts to identify break events in the accessed runbooks having a high degree of correlation to the break event which caused the received alert. At 508, it is determined that none of the correlated break events is associated with a fix event that is likely to correct the error which caused the break event. At 510, a fix event may be identified by the human operator. The fix event may be, for example, literal instructions, a code snippet or script, or an automated fix event newly-created by the human operator. At 512 the fix event and the associated break event, which had been merged together at 340, are added to a runbook 350 for the new process 112.) 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 Gudka into Kimball to determine an alert for a computer-implemented process, where the alert is associated with a break event. The processor accesses multiple runbooks associated with the computer-implemented processes. The processor automatically identifies multiple correlated break events from the runbooks from the computer-implemented processes for the break event. The processor presents multiple fix events associated with the correlated break events on a display device. The processor receives selection of the fix event through an input device. The processor generates the runbook comprising the alert, the break event and the fix event.as suggested by Gudka (See abstract and summary). Claim 2 is rejected for the reasons set forth hereinabove for claim 1, Kimball and Gudka teach the method according to claim 1, wherein the presenting the information comprises: determining whether or not at least one code modification for modifying the source code to avoid the violation of the at least one coding rule is available; and based on determining that the at least one code modification is available, presenting information of the at least one code modification to the first user ( Kimball , Figs. 8 A-8B and column 18, line 59 to column 19, line 14, FIGS. 8A-8B illustrate graphical user interfaces 800A-800B for identifying code violations and configuring refactoring goals, according to an embodiment. The GUI 800A may display the list of code violations of the source code of legacy software. Each item in the list may be a warning describing how the source code violates the proper coding patterns. For example, a first warning 802 may describe that the method has too many lines and can be refactored to smaller methods. A second warning 804 may describe that a particular condition statement is nested several levels and require manual refactoring. A third warning 806 may describe that a condition statement is nested several levels and can be automatically refactored to reduce nests. The user may be able to select one or more warnings to address the corresponding code violations by interacting with the GUI 800A.). Claim 3 is rejected for the reasons set forth hereinabove for claim 2, Kimball and Gudka teach the method according to claim 2, wherein the presenting the information: based on determining that the at least one code modification is not available, determining whether or not at least one deviation report modification is available, wherein the deviation report modification comprises modification on an existing deviation report to avoid violation of the at least one coding rule; based on determining that the at least one deviation report modification is available, presenting information associated with the at least one deviation report modification to the first user; and based on determining that the at least one deviation report modification is not available, presenting a notification to notify the first user to create a new deviation report ( Gudka , para [0058-59], FIG. 3 is a block diagram illustrating the process described above. New process 112 may generate a break event. The break events may be correlated, at 320, with multiple other break events obtained from runbook library 127. Each break event 322 will be associated with a probability 324 indicating the degree of correlation between the received break event and the break event found in runbook library 127. The break events 322a . . . 322n may be ranked in an order in accordance with their degree of correlation 324a . . . 324n with the received break event. In addition, if more than one fix event is identified, fix events 330 may also be ranked in accordance with the likelihood 334a . . . 334n that they are able to fix the error condition which caused the received break event. Once a human operator has selected a fix event 332a and verifies that it works to address the error condition which caused the break event, the fix event 332a and break event 322a are merged at 340 and placed in new runbook 350 for new process 112.]). Claim 4 is rejected for the reasons set forth hereinabove for claim 2, Kimball and Gudka teach the method according to claim 2, wherein the determining whether or not the at least one rule deviation is to be implemented comprises ( Kimball , Figs. 8 A-8B and column 18, line 59 to column 19, line 14): determining whether the first user feedback comprises an approval or a rejection on the at least one code modification ( Kimball , fig. 2 and column, line 17 to 25, The computing device may train the AI model to determine and update the rules for code violation identification. The AI model may learn from historical data on the code violations and the use's feedbacks on the identified code violations. For example, if the user consistently selects “do nothing” for certain types of code violations, the AI model may update the rules for code violation identification accordingly, such that those types of code violations are no longer identified.); based on determining that the first user feedback comprises the approval, determining that the at least one rule deviation is not to be implemented ( Kimball , fig. 2 and column 11, line 64 to column 12, line 11, The computing device may periodically retrain the AI model by learning from historical data on the code violations, the use's feedbacks and selections of refactoring options, and user manual refactoring operations for different code violations. The retrained AI model may update the rules for code violation identification and the rules for refactoring. Fig. 4 and column 17, line 1 to line 22, if the user consistently selects “do nothing” for certain types of code violations, the AI model 422 may update the rules for code violation identification 426 accordingly, such as those types of code violations are no longer identified.). ; and based on determining that the first user feedback comprises the rejection, determining that the at least one rule deviation is to be implemented ( Kimball , fig. 2 and column 11, line 64 to column 12, line 11, The computing device may periodically retrain the AI model by learning from historical data on the code violations, the use's feedbacks and selections of refactoring options, and user manual refactoring operations for different code violations. The retrained AI model may update the rules for code violation identification and the rules for refactoring. Fig. 4 and column 17, line 1 to line 22, if the user consistently selects “do nothing” for certain types of code violations, the AI model 422 may update the rules for code violation identification 426 accordingly, such as those types of code violations are no longer identified.). Claim 5 is rejected for the reasons set forth hereinabove for claim 3, Kimball and Gudka teach the method according to claim 3, wherein the determining whether or not at least one rule deviation is to be implemented comprises ( Gudka , para [0058-0060]): determining whether the first user feedback comprises an approval or a rejection on the at least one deviation report modification; and based on determining that the first user feedback comprises the approval, determining that the at least one rule deviation is to be implemented ( Kimball , fig. 2 and column 11, line 64 to column 12, line 11, The computing device may periodically retrain the AI model by learning from historical data on the code violations, the use's feedbacks and selections of refactoring options, and user manual refactoring operations for different code violations. The retrained AI model may update the rules for code violation identification and the rules for refactoring. Fig. 4 and column 17, line 1 to line 22, if the user consistently selects “do nothing” for certain types of code violations, the AI model 422 may update the rules for code violation identification 426 accordingly, such as those types of code violations are no longer identified.). Claim 6 is rejected for the reasons set forth hereinabove for claim 3, Kimball and Gudka teach the method according to claim 3, wherein the determining whether or not at least one rule deviation is to be implemented comprises: determining whether the first user feedback comprises an approval or a rejection on the creation of the new deviation report; based on determining that the first user feedback comprises the approval, determining that the at least one rule deviation is to be implemented; and based on determining that the first user feedback comprises the rejection, determining that the at least one rule deviation is not to be implemented ( Kimball , fig. 2 and column 11, line 64 to column 12, line 11, The computing device may periodically retrain the AI model by learning from historical data on the code violations, the use's feedbacks and selections of refactoring options, and user manual refactoring operations for different code violations. The retrained AI model may update the rules for code violation identification and the rules for refactoring. Fig. 4 and column 17, line 1 to line 22, if the user consistently selects “do nothing” for certain types of code violations, the AI model 422 may update the rules for code violation identification 426 accordingly, such as those types of code violations are no longer identified.). Claim 7 is rejected for the reasons set forth hereinabove for claim 2, Kimball and Gudka teach the method according to claim 2, wherein the performing the at least one operation to manage the source code comprises modifying the source code based on the at least one code modification ( Kimball , fig. 2 and column 12, line 12 to line 27, At step 212, upon receiving a selected refactoring option, the computing device may refactor the source code of the inefficient functions to remove the code violations based on the selected refactoring option. Upon receiving the user selection of the one or more refactoring options, the computing device may implement the selected options to the legacy software. For example, the computing device may alter the source code according to the selected refactoring option to remove the code violations. In some other embodiments, the computing device may automatically refactor the source code to remove the code violations based on the rules for refactoring. Accordingly, the computing device may automatically correct certain types of code violations, while other code violations may be displayed to the user for manual correction or for correction by the software refactoring module after user selection. Kimball , Figs. 8 A-8B and column 18, line 59 to column 19, line 14). Claim 8 is rejected for the reasons set forth hereinabove for claim 3, Kimball and Gudka teach the method according to claim 3, wherein the performing the at least one operation to manage the at least one deviation report comprises modifying the existing deviation report based on the at least one deviation report modification ( Gudka , para [0058-59, FIG. 3 is a block diagram illustrating the process described above. New process 112 may generate a break event. The break events may be correlated, at 320, with multiple other break events obtained from runbook library 127. Each break event 322 will be associated with a probability 324 indicating the degree of correlation between the received break event and the break event found in runbook library 127. The break events 322a . . . 322n may be ranked in an order in accordance with their degree of correlation 324a . . . 324n with the received break event. In addition, if more than one fix event is identified, fix events 330 may also be ranked in accordance with the likelihood 334a . . . 334n that they are able to fix the error condition which caused the received break event. Once a human operator has selected a fix event 332a and verifies that it works to address the error condition which caused the break event, the fix event 332a and break event 322a are merged at 340 and placed in new runbook 350 for new process 112.]). Claim 9 is rejected for the reasons set forth hereinabove for claim 3, Kimball and Gudka teach the method according to claim 3, wherein the performing the at least one operation to manage the at least one deviation report comprises creating the new deviation report ( Gudka , para [0058-59], FIG. 3 is a block diagram illustrating the process described above. New process 112 may generate a break event. The break events may be correlated, at 320, with multiple other break events obtained from runbook library 127. Each break event 322 will be associated with a probability 324 indicating the degree of correlation between the received break event and the break event found in runbook library 127. The break events 322a . . . 322n may be ranked in an order in accordance with their degree of correlation 324a . . . 324n with the received break event. In addition, if more than one fix event is identified, fix events 330 may also be ranked in accordance with the likelihood 334a . . . 334n that they are able to fix the error condition which caused the received break event. Once a human operator has selected a fix event 332a and verifies that it works to address the error condition which caused the break event, the fix event 332a and break event 322a are merged at 340 and placed in new runbook 350 for new process 112.]). Claim 10 is rejected for the reasons set forth hereinabove for claim 9, Kimball and Gudka teach the method according to claim 9, wherein modifying the existing deviation report comprises: obtaining, from a database, the existing deviation report; summarizing the first user feedback; modifying the existing deviation report to include information of the summarized first user feedback; providing, to a second user, the modified deviation report; receiving, from the second user, a second user feedback on the modified deviation record; and storing, to the database, the modified deviation report and the second user feedback ( Gudka , fig. 5 and para [0061], A process flow for a second embodiment of the invention is shown in FIG. 5. In this embodiment, the system is unable to find a fix event existing in runbook library 127 that addresses the error condition which caused the break event to be generated. The process is similar to that shown in FIG. 4. At 502, an alert is received by alert monitoring component 122 from monitoring component 110 which has generated a break event related to computer process 112. Alert monitoring component 122 may determine that either no runbook exists for new process 112 for that a runbook does exist for new process 112 but does not contain the received alert. At 504, correlation component 124 accesses one or more runbooks 126a . . . 126n stored in runbook library 127 on data storage 128. At 506, the process attempts to identify break events in the accessed runbooks having a high degree of correlation to the break event which caused the received alert. At 508, it is determined that none of the correlated break events is associated with a fix event that is likely to correct the error which caused the break event. At 510, a fix event may be identified by the human operator. The fix event may be, for example, literal instructions, a code snippet or script, or an automated fix event newly-created by the human operator. At 512 the fix event and the associated break event, which had been merged together at 340, are added to a runbook 350 for the new process 112.). Claim 11 is rejected for the reasons set forth hereinabove for claim 9, Kimball and Gudka teach the method according to claim 9, wherein the creating the new deviation report comprises: summarizing the first user feedback; creating the new deviation report based on the summarized first user feedback; providing, to a second user, the new deviation report; receiving, from the second user, a second user feedback on the new deviation record; and storing, to a database, the new deviation report and the second user feedback (Gudka, fig. 4 and para [0059-0060], A process flow for one embodiment of the invention is shown in FIG. 4. In this embodiment, the system is successful in finding a fix event associated with a highly-correlated break event that fixes the error condition which caused the break event to be generated. At 402, an alert is received by alert monitoring component 122 from monitoring component 110 which has generated a break event related to computer process 112. Alert monitoring component 122 may determine that either no runbook exists for new process 112 for that a runbook does exist for new process 112 but does not contain the generated break event. At 404, correlation component 124 will access one or more runbooks 126a . . . 126n stored in runbook library 127 on data storage 128. At 406, correlation component 124 identifies break events in runbooks 126-1 . . . 126-n having a high degree of correlation with the break event reported in the received alert. At 408, one or more fix events associated with the highly-correlated break events may be presented to a human operator. Preferably, the fix events will be automated or automatable. At 410, the user selection of one of the fix events is received from the human operator and the fix event is executed, if automated. At 412, the human operator may indicate that the fix event has successfully addressed the break event which caused the received alert and, as a result, the selected fix event and the associated break event are added to a new runbook 350 for the new process 112.). Claim 12 is rejected for the reasons set forth hereinabove for claim 1, Kimball and Gudka teach the method according to claim 1, wherein the presenting the information associated with the violation comprises: generating at least one graphical user interface (GUI) including at least one chat window and at least one interactive element, wherein the at least one chat window comprises the information associated with the violation and the at least one interactive element allows the first user to interact with the at least one chat window to provide the first user feedback; and presenting, to the first user, the at least one GUI ( Kimball , Figs. 8 A-8B and column 18, line 59 to column 19, line 14, FIGS. 8A-8B illustrate graphical user interfaces 800A-800B for identifying code violations and configuring refactoring goals, according to an embodiment. The GUI 800A may display the list of code violations of the source code of legacy software. Each item in the list may be a warning describing how the source code violates the proper coding patterns. For example, a first warning 802 may describe that the method has too many lines and can be refactored to smaller methods. A second warning 804 may describe that a particular condition statement is nested several levels and require manual refactoring. A third warning 806 may describe that a condition statement is nested several levels and can be automatically refactored to reduce nests. The user may be able to select one or more warnings to address the corresponding code violations by interacting with the GUI 800A.). Claim 13 is rejected for the reasons set forth hereinabove for claim 12, Kimball and Gudka teach the method according to claim 12, further comprising: receiving the first user feedback via the at least one GUI; updating the at least one GUI based on the first user feedback; and presenting, to the first user, the at least one updated GUI ( Kimball , column 19, line 15 to 38, FIGS. 9A-9B illustrate graphical user interfaces 900A-900B for refactoring the source code of the legacy software, according to an embodiment. The GUI 900A may comprise the original source code 902 and the refactoring options 904 of the source code. The refactoring options 904 may include an indication of a particular code violation and suggested changes to correct or otherwise address that particular code violation. The indication of the particular code violation may be a highlight of the source code with the code violation in a particular color (or in any other patterns). For example, the computing device may mark improper source code (code violation) with red color and mark the suggested refactoring option in green color. The user may select to implement one or more suggested refactoring options by interacting with the refactoring options.). As per claim 14, this is the system claim to method claim 1. Therefore, it is rejected for the same reasons as above. As per claim 15, this is the system claim to method claim 2. Therefore, it is rejected for the same reasons as above. As per claim 16, this is the system claim to method claim 3. Therefore, it is rejected for the same reasons as above. As per claim 17, this is the system claim to method claim 4. Therefore, it is rejected for the same reasons as above. As per claim 18, this is the system claim to method claim 5. Therefore, it is rejected for the same reasons as above. As per claim 19, this is the system claim to method claim 6. Therefore, it is rejected for the same reasons as above. As per claim 20, this is the system claim to method claim 7. Therefore, it is rejected for the same reasons as above. Response to Argument 7. Applicant’s arguments are persuasive on 101 rejection, abstract ideas. The 101 rejection for claims 1-20 has been withdrawn. 8. With respect to claims 1 and 14, On pages 12-16, applicant argued that Kimball does not disclose “ based on determining that the at least one rule deviation is to be implemented, performing at least one operation to manage at least one deviation report according to the first user feedback; and based on determining that the at least one rule deviation is not to be implemented, performing at least one operation to manage the source code” The Office respectfully disagreed. On fig. 4 and column 17, line 1 to line 22, Kimball teaches “if the user consistently selects “do nothing” for certain types of code violations, the AI model 422 may update the rules for code violation identification 426 accordingly, such as those types of code violations are no longer identified.” The Office notes that ““if the user consistently selects “do nothing” for certain types of code violations, the AI model 422 may update the rules for code violation identification 426 accordingly” which means “ one rule deviation is to be implemented” . The Office notes that “such as those types of code violations are no longer identified” which means the report will no longer identified those types of code violations which means “ performing at least one operation to manage at least one deviation report according to the first user feedback” ); and On fig. 2 and column 12, line 12 to line 27, Kimball teaches “Accordingly, the computing device may automatically correct certain types of code violations, while other code violations may be displayed to the user for manual correction or for correction by the software refactoring module after user selection.” The Office notes that “while other code violations may be displayed to the user for manual correction or for correction by the software refactoring module after user selection” which means “ based on determining that the at least one rule deviation is not to be implemented, performing at least one operation to manage the source code” ). In conclusion, Kimball teaches “ based on determining that the at least one rule deviation is to be implemented, performing at least one operation to manage at least one deviation report according to the first user feedback; and based on determining that the at least one rule deviation is not to be implemented, performing at least one operation to manage the source code” Conclusion 07-39 AIA 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 at 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 Application/Control Number: 18/590,196 Page 2 Art Unit: 2199 Application/Control Number: 18/590,196 Page 3 Art Unit: 2199 Application/Control Number: 18/590,196 Page 4 Art Unit: 2199 Application/Control Number: 18/590,196 Page 5 Art Unit: 2199 Application/Control Number: 18/590,196 Page 6 Art Unit: 2199 Application/Control Number: 18/590,196 Page 7 Art Unit: 2199 Application/Control Number: 18/590,196 Page 8 Art Unit: 2199 Application/Control Number: 18/590,196 Page 9 Art Unit: 2199 Application/Control Number: 18/590,196 Page 10 Art Unit: 2199 Application/Control Number: 18/590,196 Page 11 Art Unit: 2199 Application/Control Number: 18/590,196 Page 12 Art Unit: 2199 Application/Control Number: 18/590,196 Page 13 Art Unit: 2199 Application/Control Number: 18/590,196 Page 14 Art Unit: 2199 Application/Control Number: 18/590,196 Page 15 Art Unit: 2199 Application/Control Number: 18/590,196 Page 16 Art Unit: 2199 Application/Control Number: 18/590,196 Page 17 Art Unit: 2199 Application/Control Number: 18/590,196 Page 18 Art Unit: 2199 Application/Control Number: 18/590,196 Page 19 Art Unit: 2199 Application/Control Number: 18/590,196 Page 20 Art Unit: 2199 Application/Control Number: 18/590,196 Page 21 Art Unit: 2199 Application/Control Number: 18/590,196 Page 22 Art Unit: 2199
Prosecution Insights