DETAILED ACTION
This action is responsive to Remarks and Claim Amendments filed on June 17, 2026.
Claims 1, 10 and 19 have been amended.
Claims 1-20 are pending and are presented to examination.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Examiner Notes
Examiner cites particular columns, paragraphs, figures 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 their 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.
Response to Arguments
Applicant’s arguments filed June 17, 2026 have been fully considered.
Regarding the Interview Summary, the Examiner acknowledges the courtesies extended during the telephonic interview of June 16, 2026, and confirms that, as indicated during the interview, the amendments to the independent claims required further search and consideration. In the Argument section of the Remarks, Applicant submits that the independent claims, as amended to recite identifying code blocks by identifying a start of a code block based on the code block including a predetermined type of function, call, or programming language and a close of the code block based on a predetermined type of command or notation, and extracting the identified code blocks from the start to the close, are distinguished and non-obvious over the cited art, and that the dependent claims are patentable at least by virtue of their dependency on the independent claims.
The Examiner agrees that the amended limitation is not taught by Balasubramanian in view of Polk, and the rejection of record relying on that combination has been withdrawn. Applicant’s argument is not persuasive of allowability, however, because the amendment necessitated further search, which located Nicolo (US Pat. No. 9,280,442). As set forth in detail in the rejection of claim 1 below, Nicolo teaches the newly added subject matter. In particular, Nicolo identifies a start of a code block based on the block including a function — for example, a “setter” function identified by a “=” symbol or a “getter” function identified by the “return” keyword — identifies a close of the code block based on the “@endcode” command, and extracts the code block from the start (“@code”) to the close (“@endcode”). Nicolo further teaches the surrounding recited operations of determining a project coverage metric, executing the code blocks, determining whether the code blocks execute correctly, and including the project coverage metric and an instruction validity metric in the generated report. The specific paragraph and figure citations supporting each of these limitations are provided in the rejection below.
Because the newly applied combination of Balasubramanian in view of Nicolo teaches each and every limitation of the amended independent claims, claims 1, 10, and 19 remain unpatentable under 35 U.S.C. 103. The dependent claims, which Applicant asserts are patentable only by virtue of their dependency, fall with their respective independent claims and are separately addressed in the rejections set forth below. Accordingly, Applicant’s request for allowance is not persuasive, and the claims stand rejected as set forth in this Office action.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3-7, 10, 12-16 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Balasubramanian et al. (US Pub. No. 2022/0276862, hereinafter Balasubramanian – previously presented) in view of Nicolo (US Pat. No. 9,280,442).
With respect to claim 1 (Currently Amended) Balasubramanian teaches a computer-implemented method (CIM), the CIM comprising:
validating code blocks in a software document by performing a first validation process, wherein the first validation process includes: (See Balasubramanian, abstract and paragraphs [0028], [0058] and [0070], “Another aspect is a method of automatically determining a quality score of a documentation of an open source software project, the method comprising steps of… validating the sections of the documentation with project or stack metrics; assessing a quality of sections of the documentation”. Balasubramanian discloses a computer-implemented method that performs a validation process on a software document, namely the documentation of a software project, thereby teaching validating content in a software document by performing a first validation process.)
generating a report characterizing the software document (See Balasubramanian, FIG. 3 (step 307) and paragraphs [0073]-[0074], “document quality score is calculated… The document quality score calculated for a documentation helps the developer to make a decision… It also helps the developer better understand the code that they are downloading and using”. Balasubramanian generates a report, namely the computed documentation quality score, that characterizes the software document.)
Balasubramanian is silent to disclose, however, in an analogous art, Nicolo teaches: iterating through lines in the software document to identify the code blocks by: (See Nicolo, FIG. 5 (functions 504 and 508) and column 3 line 49 – column 4 line 7, “As a Java or C compiler or interpreter parses a line of code beginning these particular characters…”; column 4 lines 26-51, “convert the file 104 into a searchable stream of text or other data, break the file 104 up into useful chunks of information (i.e., ‘tokenize’ the source code file)…”. Nicolo parses the software document line by line and tokenizes it in order to locate the comment and example sections that contain the code blocks, thereby teaching iterating through lines in the software document to identify the code blocks.)
identifying a start of a code block of the code blocks based on the code block including a predetermined type of function. call, or programming language (See Nicolo, FIG. 5 (function 510) and column 10 lines 12-25, “if the function 510 identifies a ‘=’ symbol within the unit description 204, the function 510 may identify the unit description 204 as a ‘setter’ function… if the function 510 serializes or tokenizes the unit description 204 and identifies the word ‘return’, the function 510 may identify the unit description 204 as corresponding to a ‘getter’ function”. Nicolo identifies the start of a code block by detecting that the block contains a predetermined type of function or programming-language construct — for example, a ‘setter’ function identified by a ‘=’ symbol or a ‘getter’ function identified by the ‘return’ keyword — thereby teaching identifying a start of a code block based on the code block including a predetermined type of function, call, or programming language.), and responsive to identifying the start of the code block, identifying a close of the code block based on a predetermined type of command or notation (See Nicolo, FIG. 5 (function 508) and column 5 lines 25-46, “a block of comments beginning with a ‘@code’ 208 command and ending with a ‘@endcode’ command 210”; column 9 line 55 – column 10 line 11, “the function 508 may read the text following that command until the function 508 encounters another command to signal the function 508 to stop reading the text (e.g., the ‘@endcode’ command)”. After the start of the code block is identified, Nicolo identifies the close of the code block by detecting the ‘@endcode’ command, which is a predetermined type of command or notation that signals the end of the block.)
extracting the identified code blocks from the start to the close (See Nicolo, column 9 line 55 – column 10 line 11 corresponding to FIG. 3 and FIG. 5 (function 508), “the text between the ‘code’ and ‘@endcode’ commands includes the unit description 204”; column 5 line 47 – column 6 line 3, “the ourdoc module 110 copies the unit description 204 into a unit test stub 300”. Nicolo extracts the identified code block, namely the unit description delimited from the ‘@code’ start to the ‘@endcode’ close, thereby teaching extracting the identified code blocks from the start to the close.)
determining a project coverage metric that indicates a portion of a codebase that is represented by the extracted code blocks, wherein the codebase is associated with the software document (See Nicolo, FIGS. 4a-4b and column 8 line 54 – column 9 line 10, “a report indicating sixty-eight percent test coverage may specify that, of a total of one hundred functions within a class, sixty-eight of those functions are tested properly and pass those tests”; column 10 line 51 – column 11 line 14, “a coverage measure… indicating how much of the testing process is complete”. Nicolo determines a coverage measure that quantifies the portion of the codebase — the functions or units within a class of the source code file — that is represented by the extracted code blocks, thereby teaching determining a project coverage metric that indicates a portion of a codebase that is represented by the extracted code blocks.)
executing the code blocks (See Nicolo, FIG. 5 (function 514) and column 10 lines 43-50, “a test harness such as the TestUp module 114 may run each unit test within the unit test suite 112 to determine how much of the source code file 104 is properly tested”. Nicolo executes the extracted code blocks by running the unit tests that include the executable portion of code, thereby teaching executing the code blocks.) and
determining whether the code blocks execute correctly (See Nicolo, FIG. 5 (function 514) and column 7 line 58 – column 8 line 13, “The TestUp module 114 may provide a test result indication (e.g., a pass, fail, or follow up indication) 316 for each unit test within the unit test suite 112”. Nicolo determines whether the code blocks execute correctly by generating, for each executed unit test, a pass, fail, or follow-up result, thereby teaching determining whether the code blocks execute correctly.) and
wherein the report includes the project coverage metric and an instruction validity metric that indicates an amount of the code blocks that executed correctly during execution of the code blocks, wherein the instruction validity metric is based on a validation of the code blocks (See Nicolo, FIGS. 4a-4b and column 8 lines 35-53, “the report 116b may include… an indication of how many of the total number of unit tests… are properly tested, a number that are not properly tested, and a coverage measure… indicating how much of the testing process is complete”. Nicolo’s unit test coverage report includes both the coverage measure (the project coverage metric) and an indication of how many unit tests passed and properly tested the code (the instruction validity metric indicating the amount of code blocks that executed correctly), where the latter is based on the testing, i.e., validation, of the code blocks.)
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the teaching of Balasubramanian, which discloses validating a software document and generating a report characterizing the software document, with the teaching of Nicolo, which discloses identifying code blocks by their start and close, extracting the code blocks, determining a coverage measure, executing the code blocks, determining whether the code blocks execute correctly, and including the coverage measure and the pass/fail results in the report, because doing so would enable the documentation-validation system of Balasubramanian to verify that the code contained in the software document actually executes correctly and to quantify the portion of the codebase that the code blocks represent, thereby improving the accuracy and completeness of the resulting characterization of the software document.
With respect to claim 3 (Original), Balasubramanian teaches comprising: characterizing a quality of writing that exists in the software document by inputting at least some of the software document into a Large Language Model (LLM) (See Balasubramanian, paragraphs [0052] and [0061]-[0063], “The present subject matter uses machine learning models and natural language processing models for evaluating different sections of the documentation to determine relevance, completeness, and ease of understanding of the documentation”. Balasubramanian inputs at least some of the software document into a machine learning / natural language processing model to characterize the quality of the documentation’s writing, which teaches the recited inputting of the software document into a Large Language Model.) With respect to claim 4 (Original), Balasubramanian teaches wherein an output of the LLM includes characterizations of the quality of writing that exists in the software document (See Balasubramanian, paragraph [0076], “The neural network model generates a machine learning model which analyzes a software documentation document and provides the quality of documentation as output”. The output of Balasubramanian’s model is a characterization of the documentation quality, which teaches that the output includes characterizations of the quality of writing in the software document.) With respect to claim 5 (Original), Balasubramanian teaches comprising: adding a lucidity metric in the generated report, wherein the lucidity metric indicates a readability of the software document and is based on the output of the LLM (See Balasubramanian, FIG. 6 (steps 604-605) and paragraph [0080], “the documentation data… is checked for consistency of usage of terminologies and readability of the documentation… a terminologies and readability score and flow score are computed”. Balasubramanian adds a readability score to the report based on the output of its model, which teaches adding a lucidity metric indicating readability of the software document.)
With respect to claim 6 (Original), Balasubramanian teaches wherein the LLM is configured to check content of the software document for grammatical and lexical correctness in order to generate the characterizations (See Balasubramanian, paragraph [0059], “The documentation assessor 107… also determine the consistency of usage of terminologies and readability using natural language processing techniques”. Balasubramanian’s model checks the documentation content for consistency of terminology and readability using natural language processing, which teaches checking the content for grammatical and lexical correctness to generate the characterizations.) With respect to claim 7 (Original), Balasubramanian teaches wherein the at least some of the software document input into the LLM does not include the identified code blocks (See Balasubramanian, FIG. 7 and paragraph [0082], “The project repository documentation is then processed to extract sentence level documentation data… The sentence level documentation data obtained is evaluated based on the ease of understanding criteria”. Balasubramanian’s language quality assessment operates on sentence-level documentation text rather than on the code, so that the portion of the software document input into the model for the writing-quality characterization does not include the identified code blocks.)
With respect to claim 10, the claim recites limitations similar to those of claim 1 and is rejected for the same reasons set forth for claim 1 above. Balasubramanian further teaches a computer program product (CPP), the CPP comprising: a set of one or more computer-readable storage media; and program instructions, collectively stored in the set of one or more storage media, for causing a processor set to perform the following computer operations (See Balasubramanian, paragraph [0037], “Another aspect is one or more non-transitory computer-readable media… the instructions when executed by one or more processors cause the one or more processors to…”), and Nicolo likewise teaches a tangible computer readable medium storing instructions for execution by a processor (See Nicolo, column 2 lines 17-28, “a tangible computer readable medium may cause a processor to receive a source code file”).
With respect to claims 12-16, the claims recite limitations similar to those of claims 3-7, respectively, in the form of a computer program product, and are rejected for the same reasons set forth for claims 3-7 above (see also the rejection of claim 10 regarding the computer program product).
With respect to claim 19, the claim recites limitations similar to those of claim 1 and is rejected for the same reasons set forth for claim 1 above. Balasubramanian further teaches a computer system (CS), the CS comprising: a processor set; a set of one or more computer-readable storage media; program instructions, collectively stored in the set of one or more storage media, for causing the processor set to perform the following computer operations (See Balasubramanian, FIGS. 1-2 and paragraphs [0017] and [0065], “a system… comprising: one or more processors and memory storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations”), and Nicolo likewise teaches a computer system having a processor and memory for performing the operations (See Nicolo, FIG. 6 and related text).
Claims 2, 11 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Balasubramanian et al. (US Pub. No. 2022/0276862, hereinafter Balasubramanian – previously presented) in view of Nicolo (US Pat. No. 9,280,442) and further in view of Bhate et al. (US Pub. No. 2010/0146340, hereinafter Bhate – previously presented).
With respect to claim 2 (Original), Balasubramanian in view of Nicolo is silent to disclose, however, in an analogous art, Bhate teaches wherein the code blocks are executed in a sandbox environment (See Bhate, FIG. 7 and paragraphs [0027]-[0028], “In programming context, a sandbox is a development area of a data processing system where developers incrementally build and test code… Developers build and test enhancements, modifications, or other changes to code in a sandbox build”. Bhate teaches building and testing code in a sandbox environment, which teaches executing the code blocks in a sandbox environment.)
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the combination of Balasubramanian and Nicolo with the teaching of Bhate of executing code in a sandbox environment, because doing so would allow the code blocks to be built and tested in an isolated development area separate from production code, thereby improving the safety and reliability of the validation process.
With respect to claim 11, the claim recites limitations similar to those of claim 2 in the form of a computer program product and is rejected for the same reasons set forth for claim 2 above. With respect to claim 20, the claim recites limitations similar to those of claim 2 in the form of a computer system and is rejected for the same reasons set forth for claim 2 above.
Claims 8-9 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Balasubramanian et al. (US Pub. No. 2022/0276862, hereinafter Balasubramanian – previously presented) in view of Nicolo (US Pat. No. 9,280,442) and further in view of Manoharan et al. (US Pub. No. 2025/0110704, hereinafter Manoharan). – previously presented).
With respect to claim 8 (Original), Balasubramanian in view of Nicolo is silent to disclose, however, in an analogous art, Manoharan teaches wherein the first validation process is performed in response to a determination that a trigger event has occurred (See Manoharan, paragraph [0034], “In a continuous integration and continuous development (CI/CD) environment, the audit engine 136 may integrate syntax validation into the CI/CD pipeline to ensure that code quality checks are performed at each stage of development”. Manoharan performs its validation/audit function in response to events of a CI/CD pipeline, which teaches performing the first validation process in response to a determination that a trigger event has occurred.)
It would have been obvious to one of ordinary skill in the art at the time the invention was made before the effective filing date of the claimed invention to modify the combination of Balasubramanian and Nicolo with the teaching of Manoharan of performing validation in response to a trigger event in a CI/CD pipeline, because doing so would ensure that code quality checks are automatically performed at appropriate stages of development, thereby improving the timeliness and consistency of the validation process.
With respect to claim 9 (Original), Balasubramanian in view of Nicolo is silent to disclose, however, in an analogous art, Manoharan teaches wherein the trigger event is selected from the group consisting of: a development platform release, a product release, and a manual request (See Manoharan, paragraph [0034], “the audit engine 136 may integrate syntax validation into the CI/CD pipeline to ensure that code quality checks are performed at each stage of development”. Manoharan’s trigger occurring at a stage of the CI/CD development pipeline, such as a release, teaches the recited trigger event selected from the recited group. The motivation set forth for claim 8 applies equally here, as claim 9 is directed to the same combination of Balasubramanian, Nicolo and Manoharan.)
With respect to claims 17-18, the claims recite limitations similar to those of claims 8-9, respectively, in the form of a computer program product and are rejected for the same reasons set forth for claims 8-9 above.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 ANIBAL RIVERACRUZ whose telephone number is (571)270-1200. The examiner can normally be reached Monday-Friday 9:30 AM-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) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hyung S Sough can be reached at 5712726799. 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.
/ANIBAL RIVERACRUZ/Primary Examiner, Art Unit 2192
Prosecution Insights