Prosecution Insights
Last updated: October 25, 2026
Application No. 18/415,924

Method, System and Computer Program Product for Producing High-Level Report Data from Low-Level Data Extracted from a Version Control System

Non-Final OA §101
Filed
Jan 18, 2024
Priority
Mar 31, 2023 — provisional 63/493,342
Examiner
SLACHTA, DOUGLAS M
Art Unit
2193
Tech Center
2100 — Computer Architecture & Software
Assignee
Minware Inc.
OA Round
3 (Non-Final)
83%
Grant Probability
Favorable
3-4
OA Rounds
0m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 83% — above average
83%
Career Allowance Rate
299 granted / 361 resolved
+27.8% vs TC avg
Strong +18% interview lift
Without
With
+18.1%
Interview Lift
resolved cases with interview
Typical timeline
2y 3m
Avg Prosecution
18 currently pending
Career history
379
Total Applications
across all art units

Statute-Specific Performance

§101
21.1%
-18.9% vs TC avg
§103
48.0%
+8.0% vs TC avg
§102
8.0%
-32.0% vs TC avg
§112
16.4%
-23.6% vs TC avg
Black line = Tech Center average estimate • Based on career data from 361 resolved cases

Office Action

§101
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 . DETAILED ACTION This office action is in response to communication filed 8/4/2026. Claims 1-7, 9-16, and 18-19 are currently pending and claims 8 and 17 are cancelled. Claims 1, 10, and 19 are the independent claims. Claim Objections Claim 10 is objected to because of the following informalities: As per claim 10, it recites “…at least one hardware processor;…performing by the at least one hardware processor the commit-blame procedure…determining, by the at least one processor how long a plurality of…and performing, by the at least one hardware processor, a step of aggregating…” when, for grammar/clarity/consistency, it should recite “performing, by the at least one hardware processor, the commit-blame procedure…determining, by the at least one hardware processor, how long a plurality of…” Appropriate correction is required. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1-7, 9-16, and 18-19 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. As per independent claim 1, it recites “A computer-implemented method of producing high-level report data from low-level data by means of a processor unit configured to access a repository of one or more software objects in a software version control system which tracks changes to the one or more software objects over time, the method comprising the process steps of: operating the processor unit to access the repository to extract one or more software objects located in the repository; receiving sets of commit source data extracted from the repository of the one or more software objects in the software version control system, each set of commit source data including commit patches which describe how to modify the one or more software objects to arrive at a new state of the one or more software objects; processing the commit patches to obtain hunk records and a list of any renamed, deleted or created software objects, the hunk records comprising records for individual segments of changed content in each commit patch; processing the hunk records utilizing a commit-blame procedure to produce output records indicating history and original source of changes from the commit patches; performing, by the processor unit, the commit-blame procedure on input commits and commit patches, the commit blame procedure performing at least one difference of file contents between multiple commit parents, to produce intermediate data records for at least one of the input commits and software; analyzing the intermediate data records to obtain information relating to whether executable software code is still surviving in a software code base or when the executable software code was removed from the software code base; determining, by the processor unit, how long a plurality of code sub-segments of a plurality of executable software code files survived in the software code base, wherein the operation of determining includes the operation of analyzing a plurality of future change sets or commits to identify a plurality of change sets or commits that each removed or modified a subset of the code sub-segments; and performing, by at least one computer system, a step of aggregating the survived code-sub-segments to produce summary information.” The limitations “processing the commit patches to obtain hunk records and a list of any renamed, deleted or created software objects, the hunk records comprising records for individual segments of changed content in each commit patch”, “processing the hunk records utilizing a commit-blame procedure to produce output records indicating history and original source of changes from the commit patches”, “performing… the commit-blame procedure on input commits and commit patches, the commit blame procedure performing at least one difference of file contents between multiple commit parents, to produce intermediate data records for at least one of the input commits and software”, “analyzing the intermediate data records to obtain information relating to whether executable software code is still surviving in a software code base or when the executable software code was removed from the software code base”, and “determining… how long a plurality of code sub-segments of a plurality of executable software code files survived in the software code base, wherein the operation of determining includes the operation of analyzing a plurality of future change sets or commits to identify a plurality of change sets or commits that each removed or modified a subset of the code sub-segments” as drafted, recites a function that, under its broadest reasonable interpretation, covers a function that could reasonably be performed in the mind, including with the aid of pen and paper, but for the recitation of generic computer components. For example, a human may mentally/with pen and paper/etc. process/analyze/judge/etc. commit patches and determine/identify/locate/etc. record/changed content/etc., process/analyze/judge/etc. hunk records/records/data/etc. and determine/identify/decide/etc. history and origin of changes, judge/evaluate/analyze/etc. input commits/data/etc. including determining/judging/etc. differences between commits/commit parents/file contents of commits/etc. and determine/identify/decide/etc. data/intermediate data/etc. for input commits/data and software, judge/analyze/evaluate/etc. data/intermediate data records and decide/identify/determine/etc. whether code is still in code base or has been removed, and may judge/determine/observe/etc. how long code/software/code segments/sub-segments of code in software files/etc. has survived in the code base by evaluating/analyzing/judging/observing/etc. change sets/future commits/etc. and determining/identifying/observing/judging/etc. change sets/commits that removed or modified the code/subset of code/sub segments of code/etc.. As such, with broadest reasonable interpretation, the limitations cover a human mind carrying out the function through observation, evaluation, judgment, and/or opinion, or even with the aid of pen and paper. Thus, the limitations recite and falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea. This judicial exception is not integrated into a practical application. The claim recites the additional elements “A computer-implemented method of producing high-level report data from low-level data by means of a processor unit configured to access a repository of one or more software objects in a software version control system which tracks changes to the one or more software objects over time, the method comprising the process steps of”, “operating the processor unit to access the repository to extract one or more software objects located in the repository”, “receiving sets of commit source data extracted from the repository of the one or more software objects in the software version control system, each set of commit source data including commit patches which describe how to modify the one or more software objects to arrive at a new state of the one or more software objects”, “by the processor unit”, and “performing, by at least one computer system, a step of aggregating the survived code-sub-segments to produce summary information.” The additional elements “A computer-implemented method of producing high-level report data from low-level data by means of a processor unit configured to access a repository of one or more software objects in a software version control system which tracks changes to the one or more software objects over time, the method comprising the process steps of”, “operating the processor unit to”, “by the processor unit”, and “by at least one computer system” recites that high level/generic computer components/processor unit, repository, version control system, computer system, etc./etc. are used to perform/implement the abstract idea/mental process, and as such amount to mere instructions to apply the exception using generic computer components. The additional elements “access the repository to extract one or more software objects located in the repository”, “receiving sets of commit source data extracted from the repository of the one or more software objects in the software version control system, each set of commit source data including commit patches which describe how to modify the one or more software objects to arrive at a new state of the one or more software objects”, and “performing…a step of aggregating the survived code-sub-segments to produce summary information” recites insignificant extra solution activities of gathering/obtaining/receiving/accessing/updating/modifying/ aggregating/producing/etc. data/information/software objects/commit source data/code segments/summary information/etc. and the courts have identified functions such as gathering, displaying, updating, transmitting and storing data as well-understood, routine, conventional activity, (see MPEP 2106.05(d)). Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception. See MPEP 2016.05(f), 2106.05(g). The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements amount to mere instructions to apply the abstract idea using generic computer components, mere extra solution activities of gathering/obtaining/receiving/accessing/ aggregating/updating/producing/etc. data/information and the courts have identified functions such as gathering, displaying, updating, transmitting and storing data as well-understood, routine, conventional activity, and thus do not amount to significantly more than the judicial exception (see MPEP 2106.05(d)). Accordingly, the claims are not patent eligible under 35 USC 101. As per claim 2, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein each set of commit source data includes a list of commits and a list of refs which are names or tokens associated with particular commit identifiers” which, conceptually, with broadest reasonable interpretation, provides further clarification as to data/information/etc. gathered/received/obtained/etc. and used to perform the abstract idea/mental process/etc. and the courts have identified mere data gathering is well-understood, routine and conventional activity (see MPEP 2106.05(d)), and as such is not significantly more than the abstract idea and does not integrate the abstract idea into a practical application. As such, claim 2 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above. As per claim 3, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein each set of commit source data is extracted through an application programming interface (API) of the software version control system” which, conceptually, with broadest reasonable interpretation, provides further clarification as to data/information/etc. gathered/received/obtained/etc. and used to perform the abstract idea/mental process/etc. and the high level/generic computer components used to implement/perform the abstract idea/mental process, and the courts have identified mere data gathering is well-understood, routine and conventional activity (see MPEP 2106.05(d)), and as such is not significantly more than the abstract idea and does not integrate the abstract idea into a practical application. As such, claim 3 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above. As per claim 4, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein the output records include at least one of hunk fragment records, hunk removal records, hunk context records and blame records” which conceptually, with broadest reasonable interpretation, provides further clarification as to the performance of the abstract idea/mental process, and as such is not significantly more than the abstract idea and does not integrate the abstract idea into a practical application. As such, claim 4 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above. As per claim 5, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein the step of performing includes planning an execution order of the commit-blame procedure on each set of commit source data that was extracted and needs processing” which conceptually, with broadest reasonable interpretation, provides further clarification as to the performance of the abstract idea/mental process, and as such is not significantly more than the abstract idea and does not integrate the abstract idea into a practical application. As such, claim 5 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above. As per claim 6, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…wherein the step of producing includes identifying attributes associated with the executable software code” which conceptually, with broadest reasonable interpretation, provides further clarification as to the performance of the abstract idea/mental process, and as such is not significantly more than the abstract idea and does not integrate the abstract idea into a practical application. As such, claim 6 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above. As per claim 7, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…further comprising generating a grouping of the intermediate data records into groups based on the attributes and computing aggregate values for each group to produce the high-level report data which can be used to generate reports which can be presented to a user of the reports” which conceptually, with broadest reasonable interpretation, provides further clarification as to the performance of the abstract idea/mental process, and as such is not significantly more than the abstract idea and does not integrate the abstract idea into a practical application. As such, claim 7 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above. As per claim 9, it incorporates the deficiencies of claim 1, upon which it depends, and further recites “…further comprising determining amount of time it took to write the survived software code” which conceptually, with broadest reasonable interpretation, provides further clarification as to the performance of the abstract idea/mental process, and as such is not significantly more than the abstract idea and does not integrate the abstract idea into a practical application. As such, claim 9 fails to correct the deficiencies of claim 1, and is rejected for similar reasoning as claim 1, above. As per independent claim 10, it recites a system having similar limitations to the method of claim 1, and is therefore rejected for similar reasoning as claim 1, above, and claim 10 further recites “the system computing comprising: at least one hardware processor; and at least one storage device coupled to the at least one hardware processor for storing instructions that are operable when executed by the at least one hardware processor to cause the at least one hardware processor to perform operations comprising” which provides further clarification as to high level/generic computer components used to implement/perform the abstract idea/mental process/judicial exception, which amounts to no more than mere instructions to apply the exception using generic computer components which does not provide an inventive concept. Accordingly, these additional limitations/elements are not significantly more than the abstract idea and does not integrate the abstract idea into a practical application. As such, the additional limitations/elements of claim 10 fail to correct the deficiencies of claim 1, and therefore claim 10 is rejected for similar reasoning as claim 1, above. As per claims 11-16 and 18, they recite systems having similar reasoning as the methods of claims 2-7 and 9, respectively, and are therefore rejected for similar reasoning as claims 2-7 and 9, respectively, above. As per independent claim 19, it recites a non-transitory computer readable storage medium having similar limitations as the method of claim 1, and is therefore rejected for similar reasoning as claim 1, above. Claim 19 further recites the additional elements “a non-transitory computer readable storage medium storing a program of instructions executable by a machine to perform operations, the operations comprising” which, with broadest reasonable interpretation, provides further clarification as to the high level/generic computer components used to implement/perform the abstract idea/mental process, which amounts to no more than mere instructions to apply the exception using generic computer components which does not provide an inventive concept. Accordingly, these additional limitations/elements are not significantly more than the abstract idea and does not integrate the abstract idea into a practical application. As such, the additional limitations/elements of claim 19 fail to correct the deficiencies of claim 1, and therefore claim 19 is rejected for similar reasoning as claim 1, above. Allowability Over Prior Art The prior art of record (Turner et al. US Patent 10,289,407 B1, Gattu et al. US Patent 10,503,713 B1, Pidduck US PG Pub. 2016/0259799 A1, and Neatherway US Patent 10,467,004 B2) teaches extracting/obtaining/receiving/etc. data/information/commits/records/code/software/etc. including commit data/patches/modifications to software to make new version/etc. from a repository of a version control system that tracks/monitors/stores/etc. changes to/versions of/etc. software over time, processing the data/commit/records/etc. to determine records/hunk records/etc. of segments/code/lines/portions/etc. changed/removed/added/created in each commit, determining the origin/history/source/etc. of changes from the commit/patches/files/etc., producing/creating intermediate records for the commits/patches/code/etc., analyzing intermediate records and determining whether code is still surviving/retained/stored/etc. in or has been removed/deleted/etc. from the software/a codebase/etc., determining how long/the timespan/etc. a code has survived/been retained/has been current/etc. in the code/software/etc. before being removed/deleted/designated as non-current/etc., and producing/generating/etc. a report/summary by aggregating information/code changes/etc.. However, the prior art of record fails to render an obviousness of analyzing intermediate data records to obtain information relating to whether executable software code is still surviving in a software code base or when the executable software code was removed from the software code base; determining how long a plurality of code sub-segments of a plurality of executable software code files survived in the software code base, wherein the operation of determining includes the operation of analyzing a plurality of future change sets or commits to identify a plurality of change sets or commits that each removed or modified a subset of the code sub-segments; and performing a step of aggregating the survived code-sub-segments to produce summary information; when the intermediate data records are produced by accessing a repository of one or more software objects in a software version control system which tracks changes to the one or more software objects over time to extract one or more software objects located in the repository; receiving sets of commit source data extracted from the repository of the one or more software objects in the software version control system, each set of commit source data including commit patches which describe how to modify the one or more software objects to arrive at a new state of the one or more software objects; processing the commit patches to obtain hunk records and a list of any renamed, deleted or created software objects, the hunk records comprising records for individual segments of changed content in each commit patch; processing the hunk records utilizing a commit-blame procedure to produce output records indicating history and original source of changes from the commit patches; and performing the commit-blame procedure on input commits and commit patches, the commit blame procedure performing at least one difference of file contents between multiple commit parents, to produce intermediate data records for at least one of the input commits and software, as required by the independent claims. Response to Arguments Applicant's arguments filed 8/4/2026 have been fully considered but they are not persuasive. As per the 101 arguments on pg. 8 par. 5-pg. 9 par. 3 of the remarks that the amended independent claims are allowable under 35 USC 101 because they may not be practically performed by a human/manually/mentally/with pen and paper/etc. because source code repositories commonly have hundreds of thousands of lines of code, thousands of commits, and hundreds of files, and therefore executing a single iteration of the commit blame procedure for one commit would require going through each of the blame records for each modified file, removing segments for all removals in the commit, and adding segments for all the additions, and with a single commit having potentially hundreds of addition and removal hunks, doing this for all of the thousands of commits is impractical; and for a multi parent commit scenario it is even more impractical as it involves a step of computing differences in the file content of the output blame lists of each parent, which involves the longest common subsequence/LCS problem, and requires iteratively constructing an edit distance matrix having a number of rows and columns equal to the lengths of the sequences being diffed, which, for source code having hundreds or thousands of lines is excessively large (ex: determining the difference between a 100 line file and a 101 line file would require a matrix having 10,100 cells), and the matrix is iteratively filled with values based on whether pairs of lines are different and would require an edit, which requires looking at every character of every line to determine differences, and after filling the matrix the edit list is computed by iteratively walking the matrix and outputting an edit for each cell that requires an edit along the shortest path, which is the final diff output, and as this must be performed for each file in each commit that has multiple parent commits its impractical for a person to perform this diff algorithm by hand/mentally/with pen and paper/etc. even a single time, let alone the number of times that would be required to apply the commit-blame procedure to a source code repository, and therefore a human may not mentally/manually/with pen and paper perform the limitations of the amended independent claims, and therefore the claims are allowable under 35 USC 101, the examiner, respectfully, disagrees. The examiner would first like to point out that the actual wording/phrasing of the independent claims (ex: claim1) is “A computer-implemented method of producing high-level report data from low-level data by means of a processor unit configured to access a repository of one or more software objects in a software version control system which tracks changes to the one or more software objects over time, the method comprising the process steps of: operating the processor unit to access the repository to extract one or more software objects located in the repository; receiving sets of commit source data extracted from the repository of the one or more software objects in the software version control system, each set of commit source data including commit patches which describe how to modify the one or more software objects to arrive at a new state of the one or more software objects; processing the commit patches to obtain hunk records and a list of any renamed, deleted or created software objects, the hunk records comprising records for individual segments of changed content in each commit patch; processing the hunk records utilizing a commit-blame procedure to produce output records indicating history and original source of changes from the commit patches; performing, by the processor unit, the commit-blame procedure on input commits and commit patches, the commit blame procedure performing at least one difference of file contents between multiple commit parents, to produce intermediate data records for at least one of the input commits and software; analyzing the intermediate data records to obtain information relating to whether executable software code is still surviving in a software code base or when the executable software code was removed from the software code base; determining, by the processor unit, how long a plurality of code sub-segments of a plurality of executable software code files survived in the software code base, wherein the operation of determining includes the operation of analyzing a plurality of future change sets or commits to identify a plurality of change sets or commits that each removed or modified a subset of the code sub-segments; and performing, by at least one computer system, a step of aggregating the survived code-sub-segments to produce summary information.” and therefore the independent claims do not actually recite/clarify/require/etc. that the repositories are storing hundreds of thousands of lines of code, thousands of commits, hundreds of files, etc., and as such, with broadest reasonable interpretation, while the repository could store that many lines of code/commits/data, it could also only have few lines of code (ex: 10 or 20 lines, etc.), only have a couple commits (ex: 2 or 3 commits), and/or a couple of files (2 or 3, files), and as such, with broadest reasonable interpretation, the independent claims do not require that the repository be storing so much data that it is impractical for a human to perform the limitations mentally/manually/with pen and paper. Similarly, the actual wording/phrasing of the independent claims does not actually recite/require going through blame records for each modified file/each file in each commit/etc., removing segments for removals in the commit, and adding segments for additions; nor does it actually recite/require solving a longest common subsequence problem by iteratively constructing an edit distance matrix, that any matrix have a required number of cells/rows/columns/etc., determining values to fill cells of a matrix based on whether pairs of lines are different and require an edit, or iterative walking through a matrix and outputting an edit for each cell requiring an edit along a shortest path as the final diff output, and as such, with broadest reasonable interpretation, the actual wording/phrasing of the independent claims does not require these argued features/elements/limitations as part of the claimed invention. If applicant intended for these features/elements be included in the broadest reasonable interpretation of the independent claims, then the examiner would recommend further amendment/clarification to the independent claims so that the claims recite/include these features/elements. Therefore, the examiner finds these arguments unpersuasive and maintains that the rejection under 35 USC 101 is proper. Conclusion Any inquiry concerning this communication or earlier communications from the examiner should be directed to DOUGLAS M SLACHTA whose telephone number is (571)270-0653. The examiner can normally be reached Monday-Friday 6:30am-4pm. 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, Chat Do can be reached at 571-272-3721. 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. /DOUGLAS M SLACHTA/Examiner, Art Unit 2193
Read full office action

Prosecution Timeline

Show 1 earlier event
Sep 30, 2025
Non-Final Rejection mailed — §101
Jan 30, 2026
Response Filed
Mar 04, 2026
Final Rejection mailed — §101
May 14, 2026
Applicant Interview (Telephonic)
May 15, 2026
Examiner Interview Summary
Aug 04, 2026
Request for Continued Examination
Aug 06, 2026
Response after Non-Final Action
Sep 30, 2026
Non-Final Rejection mailed — §101 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12769548
MEMORY MODIFICATION TECHNIQUE USING METRICS
3y 5m to grant Granted Oct 20, 2026
Patent 12762041
Generating Constraints In A Target Programming Language From Traces Of Operations Specified In An Input
2y 3m to grant Granted Oct 13, 2026
Patent 12739217
GENERATING EDITABLE EMAIL COMPONENTS UTILIZING A CONSTRAINT-BASED KNOWLEDGE REPRESENTATION
3y 10m to grant Granted Sep 15, 2026
Patent 12737124
SYSTEMS AND METHODS FOR UPDATING WITNESS SLEDS
3y 4m to grant Granted Sep 15, 2026
Patent 12737169
AUTONOMOUS CONFIGURATION-BASED RELEASE ORCHESTRATION
2y 7m to grant Granted Sep 15, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
83%
Grant Probability
99%
With Interview (+18.1%)
2y 3m (~0m remaining)
Median Time to Grant
High
PTA Risk
Based on 361 resolved cases by this examiner. Grant probability derived from career allowance 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