4Notice 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 the application filed on 03/19/2024. Claims 1-
13 are pending in this application. Claims 1 is an independent claim.
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-13 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Regarding claim 1:
Step 1: Is the claim a process, machine, manufacture or composition of matter?
Yes. Claim 1 is a method.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature or natural phenomenon?
Yes , the claim is directed towards abstract ideas.
The limitations:
“labeling data with a possibility of generating a defect by using an identification algorithm for the collected data”
”learning context and meaning of the data embedded in the embedding step”,
“evaluating a learning result based on the context and meaning of the data learned”,
As drafted are functions that under its broadest reasonable interpretation, recite the abstract idea of a mental process. These limitations encompass a human mind carrying out these functions through observation, evaluation judgment and /or opinion, or even with the aid of pen and paper. Thus, these limitations recite and falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
The limitation:
“embedding the labeled data”
As drafted is a function that under its broadest reasonable interpretation, recite the abstract idea of a mathematical concept . The limitation includes organizing information and manipulating information through mathematical correlations. Thus, the limitation recites and falls within the “Mathematical Concept” grouping of abstract ideas under Prong 1.
Step 2A Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
Under Prong 2, the judicial exception is not integrated into a practical application.
The additional elements of “collecting data on software”, and “receiving the labeled data”, can be classified as insignificant extra solution activity directed to the judicial exception of mere data gathering and outputting. See MPEP 21.06.05(g).
The element, “based on deep learning” merely recites instructions to implement an abstract idea using a mathematical algorithm being applied on a general-purpose computer, thus is not a practical application under Prong 2. See MPEP 2106.05(f)
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As stated above in prong 2, the additional elements “collecting data on software”, and “receiving the labeled data” is merely gathering data which the courts have identified as well-understood, routine conventional activity. See for example Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362, MPEP 2106.05(d).
The additional element, “based on deep learning” merely recite instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea.
Therefore, the additional elements do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claims are not patent eligible under 35 USC 101.
Regarding claim 2 and 3 , the limitations recited in these claims merely describe the data being collected and the mode for identifying the data in the labeling step respectively. The claims do not include additional elements that integrate into a practical application or are sufficient to amount to significantly more that the judicial exception.
Regarding claim 4:
Step 1: Is the claim a process, machine, manufacture or composition of matter?
Yes. Claim 1 is a method.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature or natural phenomenon?
Yes , the claim is directed towards an abstract idea.
The limitations:
“searching for a keyword of the defect-causing change data and identifying a commit corresponding to the keyword”
“identifying changed code lines of a previous version and a modified version in the commit corresponding to the keyword”
“generating a change by performing at least one of modification and deletion of a code line in a previous modification for a last commit of commits corresponding to the identified code lines”
As drafted are functions that under its broadest reasonable interpretation, recite the abstract idea of a mental process. These limitations encompass a human mind carrying out these functions through observation, evaluation judgment and /or opinion, or even with the aid of pen and paper. Thus, these limitations recite and falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Step 2A Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
Under Prong 2, the judicial exception is not integrated into a practical application.
The additional element of “labeling the commit data subject to the change as defective, and the commit data not subject to the change as defect-free”, can be classified as can be classified as insignificant extra solution activity directed to the judicial exception of mere data gathering and outputting. See MPEP 21.06.05(g).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No, the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As stated above in prong 2 the additional element of “labeling the commit data subject to the change as defective, and the commit data not subject to the change as defect-free” is merely data labeling which the courts have identified as well-understood, routine conventional activity as outlined in the rejection of claim 1. Therefore, the additional elements do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claim is not patent eligible under 35 USC 101.
Regarding claim 5:
Step 1: Is the claim a process, machine, manufacture or composition of matter?
Yes. Claim 5 is a method.
Step 2A Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
Under Prong 2, the judicial exception is not integrated into a practical application.
The additional element ” wherein the identification algorithm includes an SZZ algorithm”, can be classified as field of use and technical environment as limiting the abstract idea to a particular algorithm does not apply any meaningful limits on the claim . See MPEP 21.06.05(h).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No . As discussed above with respect to integration of the abstract idea(s) into a practical application. The aforementioned additional element amounts to no more than field of use and technical environment. Limiting the abstract idea to include the use of a generic computer algorithm do not apply meaningful limits on the claim nor does the limitation alone or in combination with the abstract idea amount to significantly more than the identified judicial exception. Therefore, the additional elements do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claim is not patent eligible under 35 USC 101.
Regarding claim 6:
Step 1: Is the claim a process, machine, manufacture or composition of matter?
Yes. Claim 6 is a method.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature or natural phenomenon?
Yes , the claim is directed towards an abstract idea.
The limitations:
“the embedding is performed by considering context and semantics, a hierarchical structure and semantic information of a source code, and a relationship between a commit message and a code change”
As drafted is a function that under its broadest reasonable interpretation, recite the abstract idea of a mathematical concept . The limitation includes organizing information and manipulating information through mathematical correlations. Thus, the limitation recites and falls within the “Mathematical Concept” grouping of abstract ideas under Prong 1.
Step 2A Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
Under Prong 2, the judicial exception is not integrated into a practical application.
The element, “by using a pre-trained embedding model based on the commit data and the code change data”, can be classified as mere instructions to apply an exception as it merely recites instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea, thus is not a practical application. See MPEP 21.06.05(f).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No . As discussed above with respect to integration of the abstract idea(s) into a practical application. The aforementioned additional element amounts to no more than merely reciting instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components as a tool to perform the abstract idea . Applying a particular model does not apply meaningful limits on the claim nor does the limitation alone or in combination with the abstract idea amount to significantly more than the identified judicial exception.
Therefore, the additional elements do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claim is not patent eligible under 35 USC 101.
Regarding claim 7:
Step 1: Is the claim a process, machine, manufacture or composition of matter?
Yes. Claim 7 is a method.
Step 2A Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
Under Prong 2, the judicial exception is not integrated into a practical application.
The element, “the embedding model includes a UniXCoder model”, can be classified as field of use and technical environment as limiting the abstract idea to a particular embedding model does not apply any meaningful limits on the claim . See MPEP 21.06.05(h).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No . As discussed above with respect to integration of the abstract idea(s) into a practical application. The aforementioned additional element amounts to no more than field of use and technical environment. Limiting the abstract idea to include the use of a particular embedding model does not apply meaningful limits on the claim nor does the limitation alone or in combination with the abstract idea amount to significantly more than the identified judicial exception.
Therefore, the additional elements do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claim is not patent eligible under 35 USC 101.
Regarding claim 8:
Step 1: Is the claim a process, machine, manufacture or composition of matter?
Yes. Claim 8 is a method.
Step 2A Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
Under Prong 2, the judicial exception is not integrated into a practical application.
The additional elements of “a preprocessing step of preprocessing for tokenization on the commit data and the code change data before the embedding step” can be classified as insignificant extra-solution activity in the form of pre-solution activity by manipulating the data prior to the practicing of the abstract idea.
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No . As discussed above with respect to integration of the abstract idea(s) into a practical application. The aforementioned additional element amounts to no more that insignificant extra-solution activity in the form of pre-solution activity. Tokenizing the data prior to embedding does not add a meaningful limitation to abstract idea nor does the limitation alone or in combination with the abstract idea amount to significantly more than the identified judicial exception.
Therefore, the additional elements do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claim is not patent eligible under 35 USC 101.
Regarding claim 9:
Step 1: Is the claim a process, machine, manufacture or composition of matter?
Yes. Claim 9 is a method.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature or natural phenomenon?
Yes , the claim is directed towards an abstract idea.
The limitations:
“the context and meaning of the embedded data are learned based on the deep learning … learning a relationship between previous data and subsequent data for the embedded data”
As drafted are functions that under its broadest reasonable interpretation, recite the abstract idea of a mental process. These limitations encompass a human mind carrying out these functions through observation, evaluation judgment and /or opinion, or even with the aid of pen and paper. Thus, these limitations recite and falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Step 2A Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
Under Prong 2, the judicial exception is not integrated into a practical application.
The element, “by using a two-way learning model”, can be classified as field of use and technical environment as limiting the abstract idea to a particular learning model does not apply any meaningful limits on the claim . See MPEP 21.06.05(h).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No . As discussed above with respect to integration of the abstract idea(s) into a practical application. The aforementioned additional element amounts to no more than field of use and technical environment. Limiting the abstract idea to include the use of a particular learning model does not apply meaningful limits on the claim nor does the limitation alone or in combination with the abstract idea amount to significantly more than the identified judicial exception. Therefore, the additional elements do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claim is not patent eligible under 35 USC 101.
Regarding claim 10:
Step 1: Is the claim a process, machine, manufacture or composition of matter?
Yes. Claim 10 is a method.
Step 2A Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
Under Prong 2, the judicial exception is not integrated into a practical application.
The element, “the two-way learning model includes a Bi-LSTM model”, can be classified as field of use and technical environment as limiting the abstract idea to a particular learning model does not apply any meaningful limits on the claim . See MPEP 21.06.05(h).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No . As discussed above with respect to integration of the abstract idea(s) into a practical application. The aforementioned additional element amounts to no more than field of use and technical environment. Limiting the abstract idea to include the use of a particular learning model does not apply meaningful limits on the claim nor does the limitation alone or in combination with the abstract idea amount to significantly more than the identified judicial exception. Therefore, the additional elements do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claim is not patent eligible under 35 USC 101.
Regarding claim 11:
Step 1: Is the claim a process, machine, manufacture or composition of matter?
Yes. Claim 11 is a method.
Step 2A, Prong I: Does the claim recite an abstract idea, law of nature or natural phenomenon?
Yes , the claim is directed towards an abstract idea.
The limitations:
“learning of classification by using the another learning data”
“evaluating the learning of the classification by using a loss function.”
As drafted are functions that under its broadest reasonable interpretation, recite the abstract idea of a mental process. These limitations encompass a human mind carrying out these functions through observation, evaluation judgment and /or opinion, or even with the aid of pen and paper. Thus, these limitations recite and falls within the “Mental Processes” grouping of abstract ideas under Prong 1.
Step 2A Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
Under Prong 2, the judicial exception is not integrated into a practical application.
The limitation “generating another learning data represented by combining the commit data and the code change data” can be classified as insignificant extra-solution activity in the form of pre-solution activity by generating data for use in the practicing of the abstract idea.
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No . As discussed above with respect to integration of the abstract idea(s) into a practical application. The aforementioned additional element amounts to no more that insignificant extra-solution activity in the form of pre-solution activity. Generating data for use in the learning step does not add a meaningful limitation to abstract idea nor does the limitation alone or in combination with the abstract idea amount to significantly more than the identified judicial exception.
Regarding claim 12:
Step 1: Is the claim a process, machine, manufacture or composition of matter?
Yes. Claim 12 is a method.
Step 2A Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
Under Prong 2, the judicial exception is not integrated into a practical application. The additional element of “outputting final data based on the evaluation step”, can be classified as insignificant extra solution activity directed to the judicial exception of mere data gathering and outputting. See MPEP 21.06.05(g).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
As discussed above with respect to integration of the abstract idea(s) into a practical application. The aforementioned additional element amounts to no more than mere data outputting which the courts have identified as well-understood, routine conventional activity. See for example OIP Technologies, 788 F.3d at 1363, 115 USPQ2d at 1092-93. Therefore, the additional elements do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claim is not patent eligible under 35 USC 101.
Regarding claim 13:
Step 1: Is the claim a process, machine, manufacture or composition of matter?
Yes. Claim 13 is a method.
Step 2A Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
Under Prong 2, the judicial exception is not integrated into a practical application.
The element, “the software includes an edge computing application”, can be classified as field of use and technical environment as limiting the abstract idea to an input field does not apply any meaningful limits on the claim . See MPEP 21.06.05(h).
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No . As discussed above with respect to integration of the abstract idea(s) into a practical application. The aforementioned additional element amounts to no more than field of use and technical environment. Limiting the abstract idea to include the use of a particular inputs does not apply meaningful limits on the claim nor does the limitation alone or in combination with the abstract idea amount to significantly more than the identified judicial exception. Therefore, the additional elements do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claim is not patent eligible under 35 USC 101
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 11 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 11 recites the limitations “ the commit data” and “ the code change data“ as being “ learned in the learning step”; However it is unclear if this data is in reference to the commit and code change data collected in the labeling step of claim 2 or a different data as referenced by Specification [79] and Fig 4 (S400) as vector output from the Bi-LSTM model , “learned commit data (e.g., a message vector in FIG. 4) and code change data (e.g., a change vector in FIG. 4)”. For examination purposes the latter will be used and the examiner will consider “ the commit data” and “ the code change data“ as referencing vector output from the Bi-LSTM model.
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.
Claims 1-3, 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Uddin et. al ( Software defect prediction employing BiLSTM and BERT-based semantic feature, soft computing, volume 26, pages 7877-7891,) hereafter Uddin in view of Sobran et. al (US20190287029A1) hereafter Sobran.
Regarding claim 1, Uddin teaches: a software defect prediction method comprising:
a data collection step of collecting data on software;
([[4.8] Cross-project defect prediction (CPDP) is another form to
evaluate the SDP models…. CPDP methods use the data from source projects to train the model and then predict defects for target or new projects using the model. This approach, we use one or more projects dataset to train a model and then use another project to evaluate the performance of that trained model. In our work, we have used ten projects and concatenated all historical version datasets from a project into one dataset. Then, we use each project dataset as the target project dataset. Once a project is selected as the target project, the rest of the nine projects of the dataset concatenate as a training set for the models.)
Data from source projects used to train the model corresponds to collecting data on software.
Uddin does not teach , however Sobran Teaches:
a data labeling step of labeling data with a possibility of generating a defect by using an identification algorithm for the collected data;
([0016] for each commit made to a code base, a determination is made of the lines of code changed by the commit. If the commit comprises a bug fix, a determination is made of a previous commit changing the line of code changed by the commit comprising the bug fix and indication is made in a label that the previous commit introduced a bug. [0017] a bug detection algorithm 114, which may comprise a machine learning program to classify input code in code files 116 of a code base 118 in the storage 106 as introducing a bug or not introducing a bug. The bug detection algorithm 114 may implement a machine learning technique such as decision tree learning, association rule learning, neural network, inductive programming logic, support vector machines, Bayesian network, etc. The labeling of a commit indicating the commit introduces a bug through the bug detection algorithm which may use machine learning techniques corresponds to labeling data with a possibility of generating a defect using an identification algorithm.
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Uddin with a data labeling step of labeling data with a possibility of generating a defect by using an identification algorithm for the collected data; as taught by Sobran because [Sobran, 0002] “ in order to properly train the machine learning program to properly predict defects in code, the developer needs to label the code provided in the training, such as a commit, as either introducing a bug or not introducing a bug, which requires the developer to review the code to determine its likely effects in the source code.” Datasets collected in Uddin already contain an indication of defective data ( see Uddin ,Table 2 , Average defect rate) , Uddin states [Uddin 4.8] “Due to the shortage of defect data, it is usually challenging to build an appropriate prediction model for the new projects.” Clearly labeling the input data with a possibility of generating a defect allows for more data sets to be used as input, improving the scope of the embedding, classification and evaluation steps.
Uddin further teaches :
an embedding step of receiving the [] data and embedding the [] data
([3] The architecture of the model is depicted in Fig. 2. This model
consists of a five-step procedure: (a) data pre-processing,(b) input embedding, (c) context information learning and feature generation, (d) features concatenation, and (e) the training. In particular, at the first step, we serialize the elements of the source codes and filter the tokens in order
to extract the semantic model. Next, we convert the token sequences into vectors by employing the pre-trained BERT model.) The vectors produced correspond to an embedding of the data.
Uddin does not explicitly teach that the data is labeled however when the data in Uddin is the labeled data as motivated by Sobran in the rejection of limitation b above, the data passed to the embedding is labeled.
a learning step of learning context and meaning of the data embedded in the embedding step based on deep learning
([3.3.1]The proposed model employs BiLSTM method to learn the contextual and semantic features from the embedded token vectors learned in the previous step.)The BiLSTM model which learns contextual and semantic features from an embedding corresponds to a deep learning model which learns context and meaning of embedded data.
an evaluation step of evaluating a learning result based on the context and meaning of the data learned in the learning step.
([4.3] To evaluate the proposed SDP (Software Defect Prediction) model in terms of Precision, Recall, and F1-score, which is quite popular in software
defect prediction (Jiang et al. 2013; Nam et al. 2013; Jing
et al. 2014). In particular, we use the metrics are defined as
follows: Precision measures the rate of accurately predicted defective
instances across all the defected instances. Precision = TP/(TP+FP) where TP represents true positive and FP denotes false positive results delivered. TP is the number of predicted defective example whose true label is defected. On the other hand, FP denotes the number of predicted defective example whose true label is clean. Recall measures the rate of accurately predicted defective instances across all the true defected instances. Recall = TP/(TP+FN) where FN denotes false negative. FN is the number of predicted clean example whose true label is defect. [Fig.5] F1-score is the harmonic mean of precision and recall and balances the trade-off between precision and recall.) The evaluation of the output of the model by calculating Precision , Recall and F1-Score to determine how accurately the model was able to predict a defect corresponds to evaluating a learning result based on the context and meaning of the data learned
Regarding claim 2, Uddin in view of Sobran, teach the method of claim 1 above.
Sobran further teaches:
The software defect prediction method of claim 1, wherein in the data labeling step, the collected data includes commit data and code change data. ([0015-0017]To detect bugs when introducing commits in a software repository, the software developer may build a labeled dataset for machine learning usage such as a building a model for defect prediction… The computing device 100 includes a processor 102, a main memory 104, and a storage 106. The main memory 104 includes various program components including an operating system 108 and a label generator 110 and an algorithm training program 112 to assist in training a bug detection algorithm 114, which may comprise a machine learning program to classify input code in code files 116 of a code base 118 in the storage 106 as introducing a bug or not introducing a bug.)
Data stored in the storage unit referred to as input files in code of a codebase are shown in Fig.1 Storage(106), as CodeFiles(116) and Commit History(300). Commit History(300) entries in Storage(106) are shown in Fig.3 as containing “Commit Metadata(308)“ and “Changes to lines from Commit” which correlate to commit data and code change data respectively.
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Uddin with wherein in the data labeling step, the collected data includes commit data and code change data, as taught by Sobran because collecting commit data and code change data allows for information contained in the commit data to be used to infer information about the corresponding commit, [Sobran, 0025] ”commit type 312 may be determined by … natural language processing of the commit metadata 308, such as a commit message.” Furthermore, while Uddin does not explicitly state that commit data and code change data are collected in the input data , the method of Uddin collects repositories of projects ( Table 2 , Project column) (Figure 2, Step (a), Repository input) which are the same type of input that Sobran extracts its input from.
Regarding claim 3, Uddin in view of Sobran teach the method of claim 2 above.
Sobran further teaches:
wherein in the data labeling step, the identification algorithm is configured for automatically identifying defect-causing change data. ([0017]” The label generator 110 processes the code files 116, an issue tracking system 200, and a commit history 300 to generate a line change list 400 of lines of code changed by commits identified in the commit history 300, and to classify the lines of code indicated in the line change list 400 as introducing a bug or not introducing a bug. The label generator 110 further generates commit labels classifying whether the commits identified in the commit history 300 introduce a bug or do not introduce a bug and file labels 600 classifying whether code files 116 introduce a bug or do not introduce a bug.” )The label generator classifies lines of code and file labels within the commits as introducing a bug or not introducing a bug which corresponds to automatically identifying defect-causing change data.
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Uddin with wherein in the data labeling step, the identification algorithm is configured for automatically identifying defect-causing change data as taught by Sobran because [Sobran , 1, par 1] ” Buggy codes are considered to be the primary reason for software failures (Liu et al. 2011). Reviewing the codes manually and testing all units of the codes is unrealistic and costly.” Using an algorithm to label the defect causing data reduces manual effort required by users in generating a labeled dataset for use in a learning model.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Uddin in view of Sobran, and Geddes et. al (US11775414B2) hereafter Geddes.
Regarding claim 4, Uddin and Sobran teaches the method of claim 3 above.
Sobran further teaches:
wherein the identification algorithm includes: a step of searching for a keyword of the defect-causing change data and identifying a commit corresponding to the keyword; ([claim 19] for each of the lines of code determined to be changed by one of the commits, further performing: adding a line entry to a change line list indicating the commit that changed the line of code, the change to the line of code introduced by the commit, and whether the commit comprised a bug fix; wherein the determining the previous commit changing the line of code changed by the commit comprising the bug fix comprises processing the changed line list to determine a previous entry for the line of code, wherein the previous commit is indicated in the previous entry for the line of code as having changed the line.) Processing the change line list to determine a previous entry based on the line of code comprising the bug fix searches the change line list for changes corresponding to each code line which correlates to searching for a keyword of the defect-causing change data, the commit identified which is the previous commit changing the line of code changed by the commit comprising the bug fix corresponds to a commit corresponding to the keyword.
a step of identifying changed code lines of a previous version and a modified version in the commit corresponding to the keyword;
([0033] With the embodiment of FIGS. 7a, and 7b , a label generator 110 automatically classifies lines of code, a commit, and code file as introducing a bug in response to determining that a line of code in a code file that was changed by a commit was later changed by another bug fix commit that needed to change the line of code to address the bug introduced by the earlier commit. The classified lines of code in the bug introducing commit corresponds to changed code lines of a previous version. The another bug fix commit that needed to change the line of code to address the bug corresponds to a modified version in the commit corresponding to the keyword.
Uddin and Sobran do not teach however Geddes Teaches:
a step of generating a change by performing at least one of modification and deletion of a code line… corresponding to the identified code lines;([Claim 1] receive source code comprising a section of source code associated with at least one bug or vulnerability; generate a formatted code section based at least partly on the section of source code associated with at least one bug or vulnerability; identify a matching patch model based on the formatted code section; provide the formatted code section to the matching patch model; receive a remedied code section from the matching patch model; and apply the remedied code section to the section of source code associated with at least one bug or vulnerability,[col 2, lines 61-64] Patch generator 100 may… implement and/or verify various remedies or other improvements to generate optimized, improved, and/or otherwise updated output code 120.) The patch generation model generates remedies updated source code for sections of source code corresponding to a bug which correlates to generating a change by performing at least one of modification and deletion of a code line… corresponding to the identified code lines.
Geddes does not explicitly teach that the code remedy is for a previous modification for a last commit of commits corresponding to the identified code lines however when the identified commit in Sobran is applied to the method of Geddes , the label generator processes a change line list to identify the previous commit making a change to the previous line entry. The previous line entry corresponds to the most recent prior modification to that line; thus, its associated commit corresponds to the last commit of commits and is the bug introducing commit .
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Uddin with a step of generating a change by performing at least one of modification and deletion of a code line in a previous modification for a last commit of commits corresponding to the identified code lines and a step of labeling the commit data subject to the change as defective, and the commit data not subject to the change as defect-free as taught by Geddes because Uddin, Sobran and Geddes operate in the same field of automated software detection. A person of ordinary skill in the art would have recognized that combining Geddes’s change generation on a commit identified as a bug introducing commit through the method of Sobran would yield the predictable result of producing a bug fixing change corresponding to the bug introducing commit and correctly labeling data corresponding to the bug introducing change and generated bug fixing.
Sobran further teaches :
a step of labeling the commit data … as defective, and the commit data not subject to the change as defect-free([[0029] Upon initiating the classification processing, the label generator 110 creates (at block 702) a file label 600 i, for each code file 116 having lines of code, identifying the code file 602 and indicating in the flag 604 that the file does not introduce a bug as a default value. [0032] If (at block 726) there is a previous line entry 400 d in the change line list 400 for line j subject to the change, then the label generator 110 determines (at block 728) the previous commit 300 c making a change to the previous line entry 400 d. This determined previous commit 300 c is presumed to have introduced a bug because a later bug fix commit was needed to correct a line of code changed by this previous commit. For this reason, the label generator 110 indicates (at block 730) in field 504 of the commit label 500 c for the previous commit 300 c, having a commit ID 502 matching the commit ID 302 of the previous commit 300 c, that the previous commit 300 c introduces a bug.) All commits are default labeled as non-bug introducing (defect free), and commits that through processing can be linked to causing a bug are labeled as introducing a bug (defective).
Sobran does not explicitly teach that, that the labeling of defect- free is on the data subject to the change, however when combined with the change generation method of Geddes where the remedied code section is applied to the buggy section of source code. The bug causing file would be labeled as defect causing in [Sobran 0032] and in Fig. 7b step 730 . The new change generated by the method of Geddes would be recorded as a subsequent modification in the commit history representing a bug fix file. When the new commit representing the bug fix is processed as done in Fig. 7A, the newly introduced bug fix would be labeled in step 702 as defect free.
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Uddin with wherein the identification algorithm includes: a step of searching for a keyword of the defect-causing change data and identifying a commit corresponding to the keyword; and a step of identifying changed code lines of a previous version and a modified version in the commit corresponding to the keyword; and a step of labeling the commit data subject to the change as defective, and the commit data not subject to the change as defect-free as taught by Sobran because identifying bug introducing commits allows for the accurate labeling of input files , and an improved classification result as evidenced by Sobran , [Sobran 0035]” These data structures and computer technologies to efficiently determine lines of code, commits and code files introducing bugs improves the efficiency of classifying lines of code, commits and code files as introducing or not introducing bugs to use to train a bug detection algorithm”
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Uddin in view of Sobran and Tan et. al (US 20190138731 A1) hereafter Tan.
Regarding claim 5, Uddin in view of Sobran teach the method of claim 3 above, Uddin and Sobran do not teach, however Tan teaches:
wherein the identification algorithm includes an SZZ algorithm.( [0053] Different from labelling file-level defect data, labelling change-level defect data requires a further link between bug-fixing changes and bug-introducing changes. A line that is deleted or changed by a bug-fixing change is a faulty line, and the most recent change that introduced the faulty line is considered a bug-introducing change. The bug-introducing changes can be identified by a blame technique provided by a VCS, e.g., git or SZZ algorithm.) A SZZ algorithm may be used in the identification of bug-introducing changes which correlates to wherein the identification algorithm includes an SZZ algorithm.
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Uddin and Sobran with wherein the identification algorithm includes an SZZ algorithm as taught by Tan because the use of an SZZ algorithm is well understood in the art as a common a blame technique for identifying defect causing data and linked commit changes and may have improvements over other methods as evidenced by [Tan 0053] above. In addition, the SZZ algorithm may provide improvement or enhanced features over other blame techniques. [0048] ”bug-introducing changes can be collected (406). In one embodiment, this can be performed by an improved SZZ algorithm. These improvements include, but are not limited to, at least one of filtering out test cases, git blame in the previous commit of a fix commit.” One of ordinary skill in the art could have substituted the processing of the line change list in Sobran with the features of the SZZ algorithm as taught by Tan which uses git blame in the previous commit of a fix commit to identify bug introducing commits and the results of the substitution would have been predictable and consistent with the processing done in Sobran using the change line list to identify corresponding bug fix and bug introducing commits.
Claim 6-10 are rejected under 35 U.S.C. 103 as being unpatentable over Uddin in view of Sobran, and Guo et. al (UniXCoder: Unified Cross-Modal Pre-training for Code Representation) hereafter Guo.
Regarding claim 6, Uddin in view of Sobran, teach the method of claim 2 above. Uddin further teaches:
wherein in the embedding step, the embedding is performed by considering context and semantics, a hierarchical structure and semantic information of a source code ([3.2.1] To capture the contextual and the semantic features of the tokens, we use sequentially two sentences as the training example of the input layer and split those sentences into tokens. Next, the model concatenates the token embeddings, position embedding, and segment embedding to obtain the fixed-length vectors. we employ the pre-trained BERT model, which trains a character-level context over the syntax features for a sequence. This model consists of a stack of multi-layer bidirectional transformer encoder (Vaswani et al. 2017) so that each token can incorporate both forward and backward information. The settings of the model consist of (a) the number of layers such as transformer block, (b) the hidden size, and (c) the amount of self-attention heads in a transformer block. To capture the contextual and the semantic features of the tokens, we use sequentially two sentences as the training example of the input layer and split those sentences into tokens. Next, the model concatenates the token embeddings, position embedding, and segment embedding to obtain the fixed-length vectors. Finally, the BERT encoder exploits the semantic of the same word in different contexts) The contextual features of the tokens correspond to context , the semantic features correspond to semantics and semantic information. The position embedding of the tokens ensures that the placement of each token in the code is retained in the embedding which corresponds to a hierarchical structure of a source code.
Uddin and Sobran do not teach however Guo teaches: wherein in the embedding step, the embedding is performed by considering:
a relationship between a [] message and a code change by using a pre-trained embedding model based on the [] data and the code change data. ([1] UniXcoder, a unified cross-modal pre-trained model for programming languages to support both code-related understanding and generation tasks… Instead of taking code as the only input, we also consider multi-modal contents like code comment and abstract syntax tree (AST) to enhance code representation…user-written code comments provide crucial semantic information about source … and AST contains rich syntax …which helps the model better understand source code. To encode AST that is represented as a tree in parallel, we pro pose a one-to-one mapping method to transform AST in a sequence structure that retains all information of the tree and then the sequence can be used as the input to enhance code representation. UniXcoder corresponds to the pre trained embedding model, the code-related understanding using the code comment and AST code representation correspond to the relationship between the commit message and code change data as the AST input is parsed from the input code .
While Guo does not explicitly teach a commit message, the multimodal input data in Guo is comprised of code comment (natural language) and a source code (programming language) which are structurally equivalent to a commit message (natural language) and code change(programming language) respectively as claimed by the applicant. [Specification 73] “The UniXcoder may process both commit message (natural language) and code change (programming language). “ Therefore, the commit data collected and labeled in Sobran which contains natural language metadata as commit messages [Sobran 0025] and code changes together are compatible input with UniXcoder.
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Uddin and Sobran with, wherein in the embedding step, the embedding is performed by considering … a relationship between a commit message and a code change by using a pre-trained embedding model based on the commit data and the code change data as taught by Guo because the data collected in the storage unit of Sobran contains multimodal data that are compatible inputs to UniXcoder. Additionally, the use of multimodal data leads to an enhanced embedding through UniXcoder because combining natural language input with programming language input [Guo, 3.1, par 1] “can be used as additional knowledge to enhance code representation in pre-trained models.”
Regarding claim 7, Uddin, Sobran and Guo teach the method of claim 6 above. Additionally, Uddin and Sobran and Guo teach: wherein the embedding model includes a UniXcoder model , as outlined in the rejection of claim 6 above which uses UniXcoder as the embedding model. Therefore claim 7 is rejected for the same reasons as claim 6.
Regarding claim 8, Uddin, Sobran and Guo teach the method of claim 6 above.
Guo further teaches:
a preprocessing step of preprocessing for tokenization on the commit data and the code change data before the embedding step.([3.1, par 3] In order to encode AST in parallel with code comments, we propose a one-to one mapping function F, described in Algorithm 1, to transform an AST into a sequence that retains all structural information…. given a source code C, we take its comment W={w0,w1,…,wm−1} and the flattened AST token sequence ℱ(𝒯(C))={c_0,c_1,…,c_k−1} as input, where 𝒯(C) is the root of the AST of the code. For input format, we concatenate them with a prefix as an input sequence, as shown at the bottom of Figure 2,) The code comment and source code C which correspond to the commit data and code change data respectively are tokenized as resented by W={w_0,w_1,…,w_m−1} , and ℱ(𝒯(C))={c_0,c_1,…,c_k−1} .
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Uddin and Sobran with a preprocessing step of preprocessing for tokenization on the commit data and the code change data before the embedding step as taught by Guo because tokenizing AST to use as input for an embedding is well understood in the art. [GUO 3.1 par 1] “ AST is usually expressed as a tree and cannot be used directly as input to Transformer. In order to encode AST in parallel with code comments, we propose a one-to-one mapping function ℱ, described in Algorithm 1, to transform an AST into a sequence that retains all structural information. … [par 3] There can be various ways to transform a tree to a sequence of tokens, e.g. pre-order traversal.”
Regarding claim 9, Uddin, Sobran and Guo teach the method of claim 6 above.
Uddin further teaches :
wherein in the learning step, the context and meaning of the embedded data are learned based on the deep learning by using a two-way learning model capable of learning a relationship between previous data and subsequent data for the embedded data.([3.3.1, par. 1] The proposed model employs BiLSTM method to learn the contextual and semantic features from the embedded token vectors learned in the previous step. We chose this model since it captures the long-term dependency and alleviate the vanishing gradient problem (Schuster and Paliwal 1997).Also, notice that, as long as the sequence length keeps growing, in a regular RNN model the gradients may vanish due to back-propagation mechanism. To overcome this issue, we employ the BiLSTM which is an extension of LSTM in which the layers are parallel. These layers keep long and short-term memory from backward and forward propagation. The BiLSTM is able to learn contextual and semantic features from the embedding which corresponds to learning the context and meaning of the embedded data based on deep learning by using a two-way learning model. The layers of the BiLSTM keep long and short-term memory from backward and forward propagation meaning that the forward and backward LSTM layer are able to process tokens in the context of those preceding and following each token of the embedding which corresponds to capable of learning a relationship between previous data and subsequent data for the embedded data.
Regarding claim 10, Uddin, Sobran and Guo teach the method of claim 9 above. Uddin, Sobran and Guo also teach wherein the two-way learning model includes a Bi-LSTM model as stated in the rejection of claim 9 where Uddin uses a BiLSTM model. Therefore claim 10 is rejected for the same reasons as stated in the rejection of claim 9.
Regarding claim 11, Uddin and Sobran teach the method of claim 2 above.
Uddin further teaches:
wherein the evaluation step includes: a step of generating another learning data represented by combining the [] data and the [] data, both learned during the learning step, into one; The ([3.4, par 1 ]we concatenate the three features generated by the attention, global max, and global average pooling, and feed them as an input to a logistics regression classifier that is responsible for final predictions. The concatenation of the features is described in the following equation: f = Att ⊕ Max ⊕ Avg.) Applicant shows the “another learning data” is created by concatenating output of the BiLSTM model which are vectors. (Figure 4, S400-S500). In Uddin the output features generated by the BiLSTM are combined to create a new data “f”.
Uddin does not explicitly teach that the learned data is based on commit data and the code change data, however when Uddin takes the UniXcoder embedding as taught by Guo using the commit data and code change data of Sobran as input to the BiLSTM model , the output generated and combined as f in Uddin is a new learning data based on commit data and the code change data .
a classification learning step of learning of classification by using the another learning data; ([3.4, par 1 ] we concatenate the three features … and feed them as an input to a logistics regression classifier responsible for final predictions.”)The logistics regression classifier which takes the concatenated data corresponds to learning of classification by using the another learning data.
a classification learning evaluation step of evaluating the learning of the classification by using a loss function.([3.5] We train our model by applying logistics regression, which is the very commonly utilized algorithms in the software defect prediction tasks (Schneidewind 2001; Salem et al. 2004). The model adopts the cross-entropy as the loss function and calculates probabilities for two labels correspond to each class.) The use of cross-entropy as the loss function for the logistics regression model corresponds to evaluating the learning of the classification by using a loss function.
Regarding claim 12, Uddin in view of Sobran teach the method of claim 1 above. Uddin further teaches:
a step of outputting final data based on the evaluation step. ( [Fig.5] F1-score is the harmonic mean of precision and recall and balances the trade-off between precision and recall.) As stated in the rejection of claim 1, the output of the evaluation step which is a calculated F-1 score is shown in figure 5.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Uddin in view of Sobran and Fawwaz et. al ( Real-Time and Robust Hydraulic System Fault Detection via Edge Computing) hereafter Fawwaz.
Regarding claim 13, Uddin in view of Sobran teach the method of claim 1 above, Uddin and Sobran do not teach however Fawwaz teaches:
wherein the software includes an edge computing application.
([Abstract] We consider fault detection in a hydraulic system that maintains multivariate time-series sensor data. Such a real-world industrial environment could suffer from noisy data resulting from inaccuracies in hardware sensing or external interference. Thus, we propose a real-time and robust fault detection method for hydraulic systems that leverages cooperation between cloud and edge servers. [1, par. 2] real-time responses are essential for fault detection systems. Edge computing is designed to overcome this challenge by offering computational resources near the data source resulting in decreased latency and transmission costs [13]. Cooperation between cloud and edge servers must occur for real-time fault detection in hydraulic systems. ) In addition, see Fig. 2 , where the Hydraulic sensor data lifecycle is illustrated by the edge layer. The hydraulic system corresponds to an edge computing application.
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Uddin and Sobran with wherein the software includes an edge computing application as taught by Fawwaz because [Fawwaz 1, par 1] “conducting automated and real-time fault detection without human intervention is difficult because of the time-sensitive requirements to maintain proper system functionality [7].” One of ordinary skill in the art would have recognized that the data collecting method of Uddin does not restrict the software purpose or application type and that substituting the data collected in Uddin with the data of the hydraulic system in Fawwaz would produce results that are predictable and ordinary. Furthermore, Uddin states that its method may be extended to projects in other programming languages.[7, par. 2] ” As a future direction, we will extend our BERT-based semantic feature learning model to more projects developed in different programming languages such as C/C++, Python, JavaScript. Furthermore, we will implement other domain adaptation processes to software defect prediction.”
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LAWRENCE O'CONNOR EMANUEL whose telephone number is (571)272-8975. The examiner can normally be reached M-F 9:00 - 5: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, 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.
/L.S.O./Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193
Prosecution Insights