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.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Independent claims 1, 11 and 20:
Claims 1 is drawn to “method”, claim 13 is drawn to “a non-transitory computer readable medium”, and claim 17 is drawn to “apparatus”, therefore each of these claim groups falls under one of four categories of statutory subject matter (process/method, machines/products/apparatus, manufactures, and compositions of matter).
Claims 1, 13 and 17 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claims 1, 13 and 17 calculating a first change between a first version of a section of the computer code and a second version of the section of the computer code, the section of the computer code being similar to a computer-code vulnerability, and the second version is a version prior to the first version; and determining whether the section of the computer code comprises the computer-code vulnerability based on a similarity between the first change and a second change, the second change being a change between the computer-code vulnerability and a fix for the computer-code vulnerability. The limitation steps under its broadest reasonable interpretation, covers performance of the limitation in the mind. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind then it falls within the mental process/human activity grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application because the claim does not recite additional elements that integrate the judicial exception into a practical application.
Claims 13 and 17 recite the additional elements of “computer device” and “one or more processors” as recited in the claims. However, one or more hardware processors and computer device are recited at a high level of generality and are generic computer components such that they amount to no more than mere instructions to apply the exception using a generic computer. Mere instructions to apply an exception using a generic computer cannot provide an inventive concept. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Considering the claims as a whole, looking at the elements individually and in an ordered combination, does not integrate the abstract idea into a practical application using the considerations set forth above.
The claims do 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 of the processor and the memory including computer program codes are recited at a high level of generality and are generic computer components such that they amount to no more than mere instructions to apply the exception using a generic computer. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. Thus, the claimed elements, either individually, or in the ordered combination do not add significantly more to the abstract idea.
Dependent claims 2-12 and 18-20 further clarify the concept recited in independent claims, however this clarification still falls under the concept recited in the independent claims and do not amount to significantly more than the judicial exception.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 7-11, and 13-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kwon et al (KR 102526302) in view of Schweitz et al (6594822).
For claim 1, Kwon teaches A method for detecting vulnerabilities in computer code (Kwon teaches that finding software bugs and a method for generating a vulnerability classification model for software testing are disclosed as Kwon teaches in abstract), comprising: calculating a first change between a first version of a section of the computer code and a second version of the section of the computer code (Kwon teaches that the computing device learns a vulnerability classification model using the difference between source codes before and after the update and vulnerability data (S230). Vulnerability data is labeled for the source code differences before and after the update, and the computing device tokenizes the source code before and after the update to extract the differences between the source code before and after the update. The computing device may pre-process the source code in a token form, such as an abstract syntax tree (AST), to extract differences between the source code before and after the update in the form of binary code Kwon teaches par.40 on machine translation and abstract), the section of the computer code being similar to a computer-code vulnerability (Kwon teaches that the vulnerability classification model receives the source code before and after the update, can compare how similar the source code change pattern is to the source code change pattern used as training data, receives the source code change history and vulnerability information, Among the source code changes, you can check if another similar vulnerability exists as Kwon teaches in par.48 on machine translation), and the second version is a version prior to the first version (Kwon teaches that receives source codes for each version of software for training (S210). As the source code is updated, the version is updated, and therefore, the source code for each version corresponds to the source code before and after the update as Kwon teaches in par.40 on machine translation); and determining whether the section of the computer code comprises the computer-code vulnerability based on a similarity between the first change and a second change (Kwon teaches that The machine learning unit 113 compares the source code before the update with the source code after the update, that is, uses a code modified in a patch and a label for the modified code to learn a vulnerability classification model. Here, the source code after update is code updated from the source code before update, and includes a part of the source code before update and the updated code. And the label is vulnerability data for the modified code. The vulnerability classification model classifies a patch including an updated code as a vulnerability fixing patch or a general patch, and can classify a class of vulnerabilities corresponding to the updated code in the vulnerability fixing patch as Kwon teaches in par.34 on machine translation).
Kwon fails to teach that the second change being a change between the computer-code vulnerability and a fix for the computer-code vulnerability.
Schweitz teaches, similar system, the second change being a change between the computer-code vulnerability and a fix for the computer-code vulnerability (Schweitz teaches Functions f1' and f2' in the RPDG for the new software code 155 will be compared to functions f1 and f2 in the RPDG for the old software code 150 to determine the upgraded changes between the old and new software codes. Once the changes between the new software code and old software code are determined, a patch file 160 is created. The patch file is comprised of changed and added functions and their interdependencies. The patch illustrated in FIG. 2 will be comprised of the changes for f1. In the old software code, f1 was linked to A and T.sub.1. In the new software code f1' is linked to D and T.sub.4. The patch, therefore, will contain only the replacement code for f1, which is shown as f1', which includes D and T.sub.4 as Schweitz teaches in col.5, lines 65-68 to col.6, lines 1-10). It would have been obvious to one ordinary skill in the art before effective filling date to modify Kwon to include the second change being a change between the computer-code vulnerability and a fix for the computer-code vulnerability as taught and suggested by Schweitz for the purpose of creating a patch includes decomposing the object file into cantles, examining fix-up information, creating reduced program dependency graphs, and comparing the graphs to determine the changes and create the patch (Schweitz, abstract).
For claims 2, 14 and 18, Kwon fails to teaches calculating the second change between the computer-code vulnerability and the fix for the computer-code vulnerability.
Schweitz further teaches that calculating the second change between the computer-code vulnerability and the fix for the computer-code vulnerability (Schweitz teaches Functions f1' and f2' in the RPDG for the new software code 155 will be compared to functions f1 and f2 in the RPDG for the old software code 150 to determine the upgraded changes between the old and new software codes. Once the changes between the new software code and old software code are determined, a patch file 160 is created. The patch file is comprised of changed and added functions and their interdependencies. The patch illustrated in FIG. 2 will be comprised of the changes for f1. In the old software code, f1 was linked to A and T.sub.1. In the new software code f1' is linked to D and T.sub.4. The patch, therefore, will contain only the replacement code for f1, which is shown as f1', which includes D and T.sub.4 as Schweitz teaches in col.5, lines 65-68 to col.6, lines 1-10). It would have been obvious to one ordinary skill in the art before effective filling date to modify Kwon to include the second change being a change between the computer-code vulnerability and a fix for the computer-code vulnerability as taught and suggested by Schweitz for the purpose of creating a patch includes decomposing the object file into cantles, examining fix-up information, creating reduced program dependency graphs, and comparing the graphs to determine the changes and create the patch (Schweitz, abstract).
For claims 3, 15 and 19, Kwon, as modified by Schweitz, further teaches that locating the section of the computer code that is similar to the computer-code vulnerability (Kwon teaches that when a function related to a memory error detection device such as Address Sanitizer is called, the computing device identifies that the vulnerability class is “Address sanitizer allocation” type, and the vulnerability-related functions and objects as Kwon teaches in par.45 on machine translation).
For claims 7, 16 and 20, Kwon, as modified by Schweitz, further teaches that calculating a plurality of changes between the first version of the section of the computer code and a plurality of other versions of the section of the computer code, wherein the plurality of other versions are versions prior to the first version (Kwon teaches that the computing device learns a vulnerability classification model using the difference between source codes before and after the update and vulnerability data (S230). Vulnerability data is labeled for the source code differences before and after the update, and the computing device tokenizes the source code before and after the update to extract the differences between the source code before and after the update. The computing device may pre-process the source code in a token form, such as an abstract syntax tree (AST), to extract differences between the source code before and after the update in the form of binary code, receives source codes for each version of software for training (S210). As the source code is updated, the version is updated, and therefore, the source code for each version corresponds to the source code before and after the update Kwon teaches par.40 and 48 on machine translation and abstract).
For claim 8, Kwon, as modified by Schweitz, further teaches that wherein determining whether the section of the computer code comprises the computer-code vulnerability is based on the similarity of the second change and any one of the plurality of changes (Kwon teaches that The machine learning unit 113 compares the source code before the update with the source code after the update, that is, uses a code modified in a patch and a label for the modified code to learn a vulnerability classification model. Here, the source code after update is code updated from the source code before update, and includes a part of the source code before update and the updated code. And the label is vulnerability data for the modified code. The vulnerability classification model classifies a patch including an updated code as a vulnerability fixing patch or a general patch, and can classify a class of vulnerabilities corresponding to the updated code in the vulnerability fixing patch as Kwon teaches in par.34 on machine translation).
For claim 9, Kwon, as modified by Schweitz, further teaches that wherein determining whether the section of the computer code comprises the computer-code vulnerability comprises determining that the section of the computer code does not comprise the computer-code vulnerability when the first change is similar to the second change (Kwon teaches determining the test target point are performed in parallel or when a code having a vulnerability is not detected after analyzing the update message and the updated code, a method using a vulnerability classification model and the computing device calculates an input file triggering the vulnerability, a static analysis result, and a fuzzing log generated when a crash occurs as final output. Since it is difficult to fully consider and execute context information due to the nature of fuzzing, the user may set the maximum number of reaching the target point in consideration of the case where a crash does not occur at the target point as Kwon teaches in par.55-56 on machine translation).
For claim 10, Kwon, as modified by Schweitz, further teaches that wherein determining whether the section of the computer code comprises the computer-code vulnerability comprises determining that the section of the computer code comprises the computer-code vulnerability when the first change is not similar to the second change (Kwon teaches Learning is performed through differences in source codes before and after update labeled with vulnerability data, so when differences in source codes before and after update for target software are input to a vulnerability classification model, a class of vulnerabilities corresponding to the input differences is classified. Can, In this way, the vulnerability classification model receives the source code before and after the update, can compare how similar the source code change pattern is to the source code change pattern used as training data, receives the source code change history and vulnerability information, Among the source code changes, you can check if another similar vulnerability exists. The learned vulnerability classification model may be stored in a machine learning database as Kwon teaches in par.47-48on machine translation).
For claim 11, Kwon, as modified by Schweitz, further teaches that receiving the computer-code vulnerability from a security advisory service (Kwon teaches that when a function related to a memory error detection device such as Address Sanitizer is called, the computing device identifies that the vulnerability class is “Address sanitizer allocation” type, and the vulnerability-related functions and objects as Kwon teaches in par.45 on machine translation).
For claim 13, Kwon teaches A non-transitory computer-readable medium comprising computer instructions stored thereon for detecting vulnerabilities in computer code, wherein the computer instructions, when executed by one or more processors, causes the one or more processors to perform a method comprising (Kwon teaches that generating a vulnerability classification model for software testing according to an embodiment of the present invention may be performed in a computing device including a processor and a memory as Kwon teaches par.27 on machine translation): calculating a first change between a first version of a section of the computer code and a second version of the section of the computer code (Kwon teaches that the computing device learns a vulnerability classification model using the difference between source codes before and after the update and vulnerability data (S230). Vulnerability data is labeled for the source code differences before and after the update, and the computing device tokenizes the source code before and after the update to extract the differences between the source code before and after the update. The computing device may pre-process the source code in a token form, such as an abstract syntax tree (AST), to extract differences between the source code before and after the update in the form of binary code Kwon teaches par.40 on machine translation and abstract), the section of the computer code being similar to a computer-code vulnerability (Kwon teaches that the vulnerability classification model receives the source code before and after the update, can compare how similar the source code change pattern is to the source code change pattern used as training data, receives the source code change history and vulnerability information, Among the source code changes, you can check if another similar vulnerability exists as Kwon teaches in par.48 on machine translation), and the second version is a version prior to the first version (Kwon teaches that receives source codes for each version of software for training (S210). As the source code is updated, the version is updated, and therefore, the source code for each version corresponds to the source code before and after the update as Kwon teaches in par.40 on machine translation); and determining whether the section of the computer code comprises the computer-code vulnerability based on a similarity between the first change and a second change (Kwon teaches that The machine learning unit 113 compares the source code before the update with the source code after the update, that is, uses a code modified in a patch and a label for the modified code to learn a vulnerability classification model. Here, the source code after update is code updated from the source code before update, and includes a part of the source code before update and the updated code. And the label is vulnerability data for the modified code. The vulnerability classification model classifies a patch including an updated code as a vulnerability fixing patch or a general patch, and can classify a class of vulnerabilities corresponding to the updated code in the vulnerability fixing patch as Kwon teaches in par.34 on machine translation).
Kwon fails to teach that the second change being a change between the computer-code vulnerability and a fix for the computer-code vulnerability.
Schweitz teaches, similar system, the second change being a change between the computer-code vulnerability and a fix for the computer-code vulnerability (Schweitz teaches Functions f1' and f2' in the RPDG for the new software code 155 will be compared to functions f1 and f2 in the RPDG for the old software code 150 to determine the upgraded changes between the old and new software codes. Once the changes between the new software code and old software code are determined, a patch file 160 is created. The patch file is comprised of changed and added functions and their interdependencies. The patch illustrated in FIG. 2 will be comprised of the changes for f1. In the old software code, f1 was linked to A and T.sub.1. In the new software code f1' is linked to D and T.sub.4. The patch, therefore, will contain only the replacement code for f1, which is shown as f1', which includes D and T.sub.4 as Schweitz teaches in col.5, lines 65-68 to col.6, lines 1-10). It would have been obvious to one ordinary skill in the art before effective filling date to modify Kwon to include the second change being a change between the computer-code vulnerability and a fix for the computer-code vulnerability as taught and suggested by Schweitz for the purpose of creating a patch includes decomposing the object file into cantles, examining fix-up information, creating reduced program dependency graphs, and comparing the graphs to determine the changes and create the patch (Schweitz, abstract).
For claim 17, Kwon teaches A computing device comprising one or more processors operable to perform a method for detecting vulnerabilities in computer code, wherein the method (Kwon teaches that generating a vulnerability classification model for software testing according to an embodiment of the present invention may be performed in a computing device including a processor and a memory as Kwon teaches par.27 on machine translation), comprising: calculating a first change between a first version of a section of the computer code and a second version of the section of the computer code (Kwon teaches that the computing device learns a vulnerability classification model using the difference between source codes before and after the update and vulnerability data (S230). Vulnerability data is labeled for the source code differences before and after the update, and the computing device tokenizes the source code before and after the update to extract the differences between the source code before and after the update. The computing device may pre-process the source code in a token form, such as an abstract syntax tree (AST), to extract differences between the source code before and after the update in the form of binary code Kwon teaches par.40 on machine translation and abstract), the section of the computer code being similar to a computer-code vulnerability (Kwon teaches that the vulnerability classification model receives the source code before and after the update, can compare how similar the source code change pattern is to the source code change pattern used as training data, receives the source code change history and vulnerability information, Among the source code changes, you can check if another similar vulnerability exists as Kwon teaches in par.48 on machine translation), and the second version is a version prior to the first version (Kwon teaches that receives source codes for each version of software for training (S210). As the source code is updated, the version is updated, and therefore, the source code for each version corresponds to the source code before and after the update as Kwon teaches in par.40 on machine translation); and determining whether the section of the computer code comprises the computer-code vulnerability based on a similarity between the first change and a second change (Kwon teaches that The machine learning unit 113 compares the source code before the update with the source code after the update, that is, uses a code modified in a patch and a label for the modified code to learn a vulnerability classification model. Here, the source code after update is code updated from the source code before update, and includes a part of the source code before update and the updated code. And the label is vulnerability data for the modified code. The vulnerability classification model classifies a patch including an updated code as a vulnerability fixing patch or a general patch, and can classify a class of vulnerabilities corresponding to the updated code in the vulnerability fixing patch as Kwon teaches in par.34 on machine translation).
Kwon fails to teach that the second change being a change between the computer-code vulnerability and a fix for the computer-code vulnerability.
Schweitz teaches, similar system, the second change being a change between the computer-code vulnerability and a fix for the computer-code vulnerability (Schweitz teaches Functions f1' and f2' in the RPDG for the new software code 155 will be compared to functions f1 and f2 in the RPDG for the old software code 150 to determine the upgraded changes between the old and new software codes. Once the changes between the new software code and old software code are determined, a patch file 160 is created. The patch file is comprised of changed and added functions and their interdependencies. The patch illustrated in FIG. 2 will be comprised of the changes for f1. In the old software code, f1 was linked to A and T.sub.1. In the new software code f1' is linked to D and T.sub.4. The patch, therefore, will contain only the replacement code for f1, which is shown as f1', which includes D and T.sub.4 as Schweitz teaches in col.5, lines 65-68 to col.6, lines 1-10). It would have been obvious to one ordinary skill in the art before effective filling date to modify Kwon to include the second change being a change between the computer-code vulnerability and a fix for the computer-code vulnerability as taught and suggested by Schweitz for the purpose of creating a patch includes decomposing the object file into cantles, examining fix-up information, creating reduced program dependency graphs, and comparing the graphs to determine the changes and create the patch (Schweitz, abstract).
Claims 4-6 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Kwon et al (KR 102526302) in views of Schweitz et al (6594822) as applied to claims above, and further in view of Togni et al (2024/0111522).
For claim 4, Kwon, as modified by Schweitz, teaches all the limitations as previously set forth except for wherein locating the section of the computer code that is similar to the computer-code vulnerability comprises using code clone detection.
Togni teaches, similar system, wherein locating the section of the computer code that is similar to the computer-code vulnerability comprises using code clone detection (Togni teaches that identified based on their content. For example, this can be done using an approximated method that uses state of the art code clone detection techniques as Togni teaches in par.30). It would have been obvious to one ordinary skill in the art before effective filling date to modify Kwon, as modified by Schweitz, to include code clone detection as taught and suggested by Togni for the purpose of creating better computational efficiency and reduced redundancy when considering changes in a control flow of code edits (Togni, par.12).
For claim 5, Kwon, as modified by Schweitz, teaches all the limitations as previously set forth except for wherein the code clone detection uses artificial intelligence.
Togni further teaches wherein the code clone detection uses artificial intelligence (Togni teaches that training data for a machine learning model or as input to a trained machine learning modelas Togni teaches in par.42). It would have been obvious to one ordinary skill in the art before effective filling date to modify Kwon, as modified by Schweitz, to include code clone detection as taught and suggested by Togni for the purpose of creating better computational efficiency and reduced redundancy when considering changes in a control flow of code edits (Togni, par.12).
For claim 6, Kwon, as modified by Schweitz, teaches all the limitations as previously set forth except for determining the similarity of the first change and the second change using code clone detection.
Togni further teaches determining the similarity of the first change and the second change using code clone detection (Togni teaches that identified based on their content. For example, this can be done using an approximated method that uses state of the art code clone detection techniques as Togni teaches in par.10 and 30). It would have been obvious to one ordinary skill in the art before effective filling date to modify Kwon, as modified by Schweitz, to include code clone detection as taught and suggested by Togni for the purpose of creating better computational efficiency and reduced redundancy when considering changes in a control flow of code edits (Togni, par.12).
For claim 12, Kwon, as modified by Schweitz, teaches all the limitations as previously set forth except for displaying the section of the computer code when the section of the computer code comprises the computer-code vulnerability.
Togni further teaches displaying the section of the computer code when the section of the computer code comprises the computer-code vulnerability (Togni teaches that a display module (not shown) to display information (e.g., in the form of user interfaces). as Togni teaches in par.14). It would have been obvious to one ordinary skill in the art before effective filling date to modify Kwon, as modified by Schweitz, to include displaying the section of the computer code as taught and suggested by Togni for the purpose of creating better computational efficiency and reduced redundancy when considering changes in a control flow of code edits (Togni, par.12).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The prior arts are: Wareus et al (2024/0241963), Ben Salem et al (2024/0045971), Lewandowski et al (2023/0281316) and Zhang (2021/0192321).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AYUB A MAYE whose telephone number is (571)270-5037. The examiner can normally be reached Monday-Friday 9AM-5PM.
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, SHEWAYE GELAGAY can be reached at 571-272-4219. 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.
/AYUB A MAYE/Examiner, Art Unit 2436 /SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436
Prosecution Insights