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 .
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.
Claim 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception without significantly more.
Claim 1 recite(s):
detecting … a request for a code change to be merged into a main repository for a source code;
determining … based on an analysis of the code change, an estimated risk level of the code change;
predicting … based on the analysis of the code change, an estimated amount of time needed to review the code change;
identifying … based on the analysis of the code change and on an analysis of the request, an individual to whom to assign the code change for review;
generating … a notification that includes a description of the code change and the estimated amount of time; and
delivering … the notification to the individual.
The detecting, determining predicting, identifying, and generating limitations describe observations, analysis and judgements which can be performed in the human mind (at least with the aid of pen and paper). Accordingly, the claim is directed to an abstract mental process.
This judicial exception is not integrated into a practical application because the additional element(s) (i.e. a “processing system”) is only recited at a high level of generality and provides only basic computing functionality and the “delivering” only constitutes insignificant extra solution activity. Accordingly, the additional element(s) do not integrate the practical application into a practical application.
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional element(s) (i.e. a “processing system”) is only recited at a high level of generality and provides only basic computing functionality. Accordingly, the claim is directed to a judicial exception without significantly more.
Claims 2-4 recite further details of the mental steps of claim 1 and do not introduce anything which would move the determining, predicting, identifying, and generating outside of what can be performed in the human mind. Further the claims do not introduce and new additional elements. Accordingly, the claims are directed to a judicial exception without significantly more.
Claims 5-7 recite details of the analysis discussed above. The recitation of “providing data extracted from the request as input to a machine learning model that is trained to predict the estimated risk” merely uses the model (presumably executing on a processor(s)) as a tool. Accordingly, the limitation provides nothing more than instructions to implement the judicial exception using a generic computer (see e.g. MPEP 2106.05(f)). Accordingly, the claims are directed to a judicial exception without significantly more.
Claims 8-11 recite further details of the analysis and do not introduce new additional elements. Accordingly, the claims are directed to a judicial exception without significantly more.
Claims 12-13 recite delivering and receiving steps. This merely describes data gathering and output and are thus insignificant extra-solution activity. Accordingly, the claims are directed to a judicial exception without significantly more.
Claims 14-15 recite details of the analysis discussed above. The recitation indicating the description is generated using a generative machine learning technique merely uses the model (presumably executing on a processor(s)) as a tool. The recitation of inputting data to, and outputting data from the model only amounts to extra-solution activity. Accordingly, the limitation(s) provides nothing more than instructions to implement the judicial exception using a generic computer (see e.g. MPEP 2106.05(f)). Accordingly, the claims are directed to a judicial exception without significantly more.
Claims 16-18 further describe details of the notification that is output from the system, and thus merely describes insignificant extra solution activity.
Claims 19-20 recite the judicial exception discussed in conjunction with claim 1. The addition elements of a “non-transitory computer readable medium” and “processing system including at least one processor; and a non-transitory computer-readable medium”. These additional elements are only recited at a high level of generality and provides only basic computing functionality and the “delivering” only constitutes insignificant extra solution activity. Accordingly, the additional element(s) do not integrate the practical application into a practical application.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-13, 16 and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0303140 to Kelly (Kelly) in view of US 2023/0153225 to Azad et al. (Azad) in view of US 2023/0168883 to Sreedharan et al. (Sreedharan).
Claim 1: and 19-20: A method comprising:
detecting, by a processing system including at least one processor, a request for a code change to be merged into a main repository for a source code (par. [0036] “a “pull request” may be made”);
identifying, by the processing system based on the analysis of the code change and on an analysis of the request, an individual to whom to assign the code change for review (par. [0040] “identify a set of users (e.g., 410) … selection of one or more candidate peer reviewers”);
generating, by the processing system, a notification that includes a description of the code change and the estimated amount of time (par. [0027] “generate a corresponding electronic message”, par. [0045] “automatically generate a corresponding … assignment … instructions … a link to or copy of the code”); and
delivering, by the processing system, the notification to the individual (par. [0045] “sent to a user computer”).
Kelly does not disclose:
determining, by the processing system based on an analysis of the code change, an estimated risk level of the code change;
predicting, by the processing system based on the analysis of the code change, an estimated amount of time needed to review the code change.
Azad teaches:
determining, based on an analysis of a code change, an estimated risk level of the code change (par. [0017] “predicts the risk of a pull request introducing a bug”).
Sreedharan teaches:
predicting an estimated amount of time needed to review the code change (par. [0056] “generating a predicted completion time for the monitored pull request”).
It would have been obvious before the effective filing date of the claimed invention to estimate a risk level and completion time for the review. Those of ordinary skill in the art would have been motivated to do so to improve efficiency of the process (see e.g. Azad par. [0013] “efficiency may be gained”, Sreedharan par. [0055] “recommending an allocation of additional resources”, Kelly par. [0040] “availability of the user”).
Claim 2: Kelly, Azad and Sreedharan teach the method of claim 1, wherein the request for the code change comprises a pull request, and wherein the pull request is a part of a code review process for a software program with which that the source code is associated (Kelly par. [0036] “pull request”).
Claim 3: Kelly, Azad and Sreedharan teach the method of claim 1, wherein the request includes at least one of:
a description of the code change, an origin branch of the code change in the source code, a target branch of the code change in the source code, a list of individuals who are authorized to approve or reject the request, or a markup showing changes to the source code that are introduced by the code change (e.g. Kelly par. [0036] “a repository branch”).
Claim 4: Kelly, Azad and Sreedharan teach the method of claim 1, wherein the estimated risk level indicates a likelihood that a bug is present in the code change (Azad par. [0017] “predicts the risk of a pull request introducing a bug”).
Claim 5: Kelly, Azad and Sreedharan teach the method of claim 1, wherein the determining comprises providing data extracted from the request as input to a machine learning model that is trained to predict the estimated risk level (Azad par. [0037] “applies a machine learning model to the extracted and computed file features”), wherein the data extracted from the request comprises at least one of:
an author of the code change, an individual to whom the request is directed for review of the code change, a timestamp indicating when the request was received by a ticketing system, a file attached to the request, or a line number in each file attached to the request (e.g. Kelly par. 0033] “user data 285”).
Claim 6: Kelly, Azad and Sreedharan teach the method of claim 5, wherein at least one of the following is provided as a further input to the machine learning model:
an author of a code change contained in a historical request received by the ticketing system, an individual to whom the historical request was directed for review of the code change contained in the historical request, a timestamp indicating when the historical request was received by the ticketing system, a file attached to the historical request, or a line number in each file attached to the historical request (e.g. Azad par. [0046] “lines added and/or subtracted”, par. [0039] “pull request database 114”).
Claim 7: Kelly, Azad and Sreedharan teach the method of claim 6, wherein at least one of the following is provided as a further input to the machine learning model:
a work item type associated with the request, a bug status of the request, a severity of any bugs that have been automatically detected in the code change, a security issue that has been automatically detected in the code change, or a severity of a security issue detected by a security scan tool (e.g. Azad par. [0039] “a number of problematic bug-inducing commits”).
Claim 8: Kelly, Azad and Sreedharan teach the method of claim 1, wherein the determining is based at least in part on at least one of:
a presence of bugs in historical instances of source code that are directed to a same field of technology or a same function as the code change, a number of different individuals who worked on the code change, a type of technology to which the source code is directed, or whether a security scan tool has reported an open issue in the code change (e.g. Kelly par. [0032] “solutions to issues or bugs found to exist in the subject code’s author’s code”).
Claim 9: Kelly, Azad and Sreedharan teach the method of claim 1, wherein the estimated amount of time is calculated based on a number of lines of code that are changed in the code change and a file type of the code change (Azad par. [0017] “a churn value, e.g., a number of lines added and/or subtracted”).
Claim 10: Kelly, Azad and Sreedharan teach the method of claim 1, wherein the identifying comprises ranking a plurality of individuals to whom the code change can be assigned, wherein the individual to whom the notification is delivered is one of the plurality of individuals (Kelly par. [0032] “scoring, ranking, or otherwise identifying potential peer reviewers”).
Claim 11: Kelly, Azad and Sreedharan teach the method of claim 10, wherein the identifying further comprises identifying, subsequent to the ranking, a highest ranked individual of the plurality of individuals whose current workload does not exceed a threshold number of code review tasks, and wherein the highest ranked individual of the plurality of individuals whose current workload does not exceed the threshold number of code review tasks is the individual to whom the notification is delivered (Kelly par. [0040] “the user with the highest grade or score is ranked as the top candidate … availability of the user”).
Claim 12: The method of claim 11, further comprising: delivering, by the processing system to an author of the code change, a recommendation, wherein the recommendation suggests at least one individual to whom to send the request, and wherein the at least one individual includes the highest ranked individual of the plurality of individuals whose current workload does not exceed the threshold number of code review tasks (Kelly par. [0040] “the user with the highest grade or score is ranked as the top candidate … availability of the user”, par. [0025] “recommendation of a peer reviewer”).
Claim 13: Kelly, Azad and Sreedharan teach the method of claim 12, further comprising:
receiving, by the processing system from the author of the code change, an authorization to send the request to a selected individual of the at least one individual (Kelly par. [0035] “govern access and permissions for the various code components”, it would at least have been obvious to authorize the reviewer to enable access to the code), wherein the selected individual is the individual to whom the notification is delivered (Kelly par. [0025] “recommendation of a peer reviewer”).
Claim 16: Kelly, Azad and Sreedharan teach the method of claim 1, wherein the notification further includes an explanation as to why the individual was selected to review the code change (Kelly par. [0041] “candidates 410 determined for the code correlation analysis 405 would benefit, from the code base exposure … notify the respective users … of their involvement … facilitate the selected peer reviewer’s 420 participation”, it would at least have been obvious to include this information to facilitate understanding).
Claim(s) 14-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0303140 to Kelly (Kelly) in view of US 2023/0153225 to Azad et al. (Azad) in view of US 2023/0168883 to Sreedharan et al. (Sreedharan) in view of US 2024/0362017 to Parhi et al. (Parhi).
Claim 14: Kelly, Azad and Sreedharan teach the method of claim 1, but do not teach:
wherein the description of the code change is generated using a generative machine learning technique that takes as an input a description of the code change that is provided in the request and generates as an output the description of the code change that describes why changed lines of code in the code change were changed, and what the changed lines of code are intended to accomplish.
Parhi teaches:
a generative machine learning technique that takes as an input a description of the code change and generates as an output a description of the code change that describes why changed lines of code in the code change were changed, and what the changed lines of code are intended to accomplish (par. [0047] “generate a natural language description of the functionality change caused by the code change”).
It would have been obvious before the effective filing date of the claimed invention to generate a description of the code changes using a generative machine learning technique. Those of ordinary skill in the art would have been motivated to do so to provide further understanding of the code to the reviewer.
Claim 15: Kelly, Azad, Sreedharan and Parhi teach the method of claim 14, wherein the description of the code change further includes a number of lines of code that have been changed in the code change (Azad par. [0017] “a churn value, e.g., a number of lines added and/or subtracted”).
Claim(s) 17-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 2019/0303140 to Kelly (Kelly) in view of US 2023/0153225 to Azad et al. (Azad) in view of US 2023/0168883 to Sreedharan et al. (Sreedharan) in view of official notice.
Claim 17: Kelly, Azad and Sreedharan teach the method of claim 1, but do not explicitly disclose wherein the notification further includes an object that includes an embedded hyperlink (Kelly par. [0045] “a link to … the code”), wherein the embedded hyperlink, when activated, initiates a review process for reviewing the code change.
Kelly, Azad and Sreedharan do not explicitly teach:
wherein the embedded hyperlink, when activated, initiates a review process for reviewing the code change.
It is officially noted that hyperlinks were well known of initiating computer functionality at the time of filing.
It would have been obvious before the effective filing date of the claimed invention to include an embedded hyperlink. Those of ordinary skill in the art would have been motivated to do so as a means of initiating the review process which would have produced only the expected results.
Claim 18: Kelly, Azad and Sreedharan teach the method of claim 17, further comprising:
receiving, by the processing system, a confirmation that the individual has begun reviewing the code change in response to an activation of the embedded hyperlink by the individual (Kelly par. [0025] “track and manage progress of an assigned peer review”, it would at least have been obvious to tract initiation of the review).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASON D MITCHELL whose telephone number is (571)272-3728. The examiner can normally be reached Monday through Thursday 7:00am - 4:30pm and alternate Fridays 7:00am 3:30pm.
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 (571)272-3759. 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.
/JASON D MITCHELL/Primary Examiner, Art Unit 2199
Prosecution Insights