DETAILED ACTION
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 .
This action is responsive to communication received on 09/01/2025. Claims 1-6, 8-16, and 18-20, are pending of which claims 1, 8, 11 and 20 are amended.
The Examiner recommends filing a written authorization for Internet communication in response to the present action. Doing so permits the USPTO to communicate with Applicant using Internet email to schedule interviews or discuss other aspects of the application. Without a written authorization in place, the USPTO cannot respond to Internet correspondence received from Applicant. The preferred method of providing authorization is by filing form PTO/SB/439, available at: https://www.uspto.gov/patent/forms/forms. See MPEP § 502.03 for other methods of providing written authorization.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1-6, 8-16 and 18-20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. The claims recite providing the NL description and the cryptographic hash to a second classification model trained to generate a refined maliciousness score based on the NL description,
The specification provides no support for providing the NL description and cryptographic has to a second classification model to generate a refined maliciousness score. The claim language appears to combine multiple distinct aspects of the disclosure that are not clearly supported. For example, with respect to hashing/hash the specification discusses in ¶35 creating hashes of files and associating NL descriptions with the hash of the file with indications that the file malicious or non-malicious as a means to identify the file in the database. No language in the disclosure combines the NL descriptions and hashes of the file into a second classification model to generate a refined maliciousness score. Regarding a second classification model while ¶s47,48 discusses generation of a second maliciousness score using a second classification model the second malicious score does not appear to be a refinement/retraining. The second malicious score and second model is discussed with respect to a different programming language. The claim originally recites a first score generated from a classification model and as amended recites a second score as a refinement using a second classification model. The specification does not describe that the first score is refined by the second malicious score using the second model. With respect to refine, fine-tune the specific discusses refinement/tuning of the classification model but does not relate or associate such with a second malicious score from a second classification model.
Regarding the amendment and associating, in the database, the refined maliciousness score with the cryptographic hash independently of the maliciousness score generated by the classification model. There no support for associating the database refined maliciousness scores in the specification. There is no description of associating in a database a malicious score, let alone a refined maliciousness score with a cryptographic hash. There is no description of regarding associating in a database a refined maliciousness score and the maliciousness score generation by the classification model. The specification does not does not recite a refined maliciousness model.
Thus, claims 1, 11 and 20 as amended lack written description sufficient to support the amendments and are rejection under 35 US 112 1st ¶ as being directed to new matter. Claims 2-6, 8-10, 12-16 and 18-20 are rejected based upon their dependence of claims 1 and 11.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 9, 11, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Chan US 2024/0411666, further in view of Briliauskas US 2024/0232355 and Johns US 2019/0132334.
Regarding claims 1 11 and 20, Chan teaches a method, device and non-transitory CRM comprising instructions executed by a device performing the steps of determining that a file comprises source code for causing malicious activity;
[0014] The present disclosure relates to the detection of a software vulnerability and the one or more tokens of a source code snippet attributable to the software vulnerability. In a first stage, a classifier model is used to identify token positions in the source code snippet that are associated with the type of the detected software vulnerability. In a second stage, a large language model is used to determine if the source code snippet contains the detected software vulnerability given the identified software vulnerability type and a few-shot examples having the same type of software vulnerability. When the large language model identifies the source code snippet as having the vulnerability, a repair code model is used to predict the repair for the vulnerable source code snippet.
[0026] In the case where the neural encoder transformer identifies the source code snippet as having an identified type of software vulnerability 122—yes, the system uses a large language model 110 to identify the vulnerability. The large language model 110 is a deep learning model that contains billions of parameters. Parameters are the parts of the model 110 learned from the training datasets that define the skill of the model to generate predictions for a target task. In an aspect, the large language model is a unified cross-modal neural transformer model with attention. A unified cross-modal neural transformer model with attention is a type of neural transformer model that is pre-trained on multi-modal contents, such as natural language text and source code to support various code-related tasks. The large language model may be implemented as a neural transformer model with attention in an encoder-decoder configuration or in a decoder-only configuration.
generating, by a processing device and using one or more large language models (LLMs), a natural language (NL) description(i.e. vulnerability type/class ) of the source code responsive to determining that the file comprises the source code for causing the malicious activity(LLMs and natural language processor convert source code into text based tokens attributable to the source code snippets that contain vulnerabilities and a vulnerability type that describes a type vulnerability)
[0014] The present disclosure relates to the detection of a software vulnerability and the one or more tokens of a source code snippet attributable to the software vulnerability. In a first stage, a classifier model is used to identify token positions in the source code snippet that are associated with the type of the detected software vulnerability. In a second stage, a large language model is used to determine if the source code snippet contains the detected software vulnerability given the identified software vulnerability type and a few-shot examples having the same type of software vulnerability. When the large language model identifies the source code snippet as having the vulnerability, a repair code model is used to predict the repair for the vulnerable source code snippet.
[0017] The tokenizer 102 accepts a source code snippet 116 and converts the source code snippet 116 into a sequence of tokens 118. The source code snippet 116 may consist of a source code program or a portion of a source code program, such as a method, expression, or line of source code. A token is a basic element of source code that cannot be subdivided. A token has an assigned meaning in the programming language of the source code. The tokenizer 102 may be a lexical analyzer or parser that reads a string of characters from the source code snippet and converts the string into a sequence of tokens.
providing the NL description of the source code to a classification model trained to generate a first set of maliciousness scores each indicating whether the source code is associated with one or more types of malicious activity(tokens fed into classifier that determines type of vulnerability)
[0018] The classifier model 104 receives the token sequence, as a sequence of token embeddings, and identifies a type of software vulnerability and positions in the token sequence that are associated with the type of software vulnerability. In an aspect, the token sequence consists of at most T tokens and can identify n types of software vulnerabilities. The classifier model generates an output probability for each class which consists of the t token positions and the n software vulnerabilities, P(t.sub.1, . . . t.sub.T), P(v.sub.1, . . . , P(v.sub.n). When a probability exceeds a threshold, such as greater than 0.5, the associated token or vulnerability class is considered vulnerable. In an aspect, T is 512 tokens and n is 27 vulnerability classes. P(t) represents the probability of the token in position t and P(v) represents the probability of vulnerability class v.
and generating, using the classification model, a maliciousness score for the source code indicating whether the source code is associated with the one or more types of malicious activity(classifier model scores and determines vulnerability type of the source code, ¶s 24,26).
[0024] The attention mechanism indicates how much attention a particular input should pay to other elements in a given input sequence. The attention mechanism can be implemented in a self-attention layer of the model. In the self-attention layer, each token in an input sequence is transformed into a query (Q), key (K), and value (V) that are used to calculate a score that indicates how much attention that particular token should attend to other tokens in the input sequence. The self-attention layers are integrated into the encoder neural encoder transformer model with attention.
[0026] In the case where the neural encoder transformer identifies the source code snippet as having an identified type of software vulnerability 122—yes, the system uses a large language model 110 to identify the vulnerability. The large language model 110 is a deep learning model that contains billions of parameters. Parameters are the parts of the model 110 learned from the training datasets that define the skill of the model to generate predictions for a target task. In an aspect, the large language model is a unified cross-modal neural transformer model with attention. A unified cross-modal neural transformer model with attention is a type of neural transformer model that is pre-trained on multi-modal contents, such as natural language text and source code to support various code-related tasks. The large language model may be implemented as a neural transformer model with attention in an encoder-decoder configuration or in a decoder-only configuration.
Chan teaches maintaining a database of NL descriptions(¶31) but does not teach hashing the source code and this does not teach maintaining, in a database, a plurality of NL descriptions generated by the one or more LLMs, each NL description respectively associated with a cryptographic hash of the source code from which it was generated. Briliauskas in the same field of endeavor as the invention teaches a machine learning malware classification system. Briliauskas teaches maintaining, in a database, a plurality of NL descriptions generated by the one or more LLMs, each NL description respectively associated with a cryptographic hash of the source code from which it was generated.
[0060] In the example shown in FIG. 1A, service provider computing system 102 includes a set of model generation modules 106 (shown as 106a, 106b) configured to generate a model 108 for a locality-sensitive hashing model having a vantage-point tree data structure and a machine learning classification model 110 for malware detection from libraries of known malware 112 and known non-malware code 114 (shown stored in “Malware Database” 112′ and “Non-Malware Database” 114′). The malware and non-malware code (112, 114) may be binary files or snippets/portions of binary files. Non-binary instruction libraries may be converted to binary files as a part of data preparation or normalization process.
[0091] In some embodiments, the vantage point tree structure can be maintained at the back-end server, and the client device can determine the fuzzy hash of the target code (e.g., 119) and transmit the fuzzy hash to the malware service, e.g., located on cloud infrastructure. The cloud infrastructure can search the vantage point tree structure, per FIGS. 3 and 5, with the fuzzy hash of the target code, and provide the results back via a response. In this embodiment, the cloud infrastructure may add the fuzzy hash of new target code to the database or malware and non-malware code once appropriate labels for them have been generated (e.g., subsequent to the second classification operation). The addition of fuzzy hash of the new target code may be added as a batch once they have been confirmed as being malware and non-malware code.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Chan with a malicious file databases containing labels of known malware code and hashes malware code. The reason for this modification would be to provide a database for users obtain and share training data to train machine learning based code malware/vulnerability detection and provide a method(ie. hashing the code) to determine a file contains the malicious/vulnerable code.
The combination of Chan/Briliauskas do not teach providing the NL description and the cryptographic hash to a second classification model trained to generate a refined maliciousness score based on the NL description. Johns in the same field of endeavor as the invention teaches a machine learning based malware detection system. Johns teaches providing the NL description and the cryptographic hash to a second classification model trained to generate a refined maliciousness score based on the NL description(Johns, teaches a second classifier to generate a second threat score and that analysis of malicious executable files is based on signatures(hashes), ¶s 106, 116, 120)
[0106] Communicatively coupled to the CNN-based logic 430, a classifier is configured to receive the output 665 from the CNN-based logic 430 and determine a classification assigned to the executable file. As shown in FIG. 6H, this classification may be accomplished by generating a threat score 678 based on the received output 665. As shown, a weighting vector 670 and a bias 672 is “tuned” during the training session, where the output 665 processed with the weighting vector 670 and the bias 672 provides a scalar value 674. Based on the scalar value 674, a threat score 678 is generating using a scoring function 676 (e.g., sigmoid function as shown), which identifies the likelihood of the executable file 600 being associated with a cyber-attack.
[0116] According to one embodiment of the disclosure, the indicators may be based on intelligence generated by cyber-security analysts and captured in digital signatures (hashes) of known malicious executable files, heuristics and pattern matching based on known executable files, or the like. The comparison of the known indicators associated with malicious and/or benign executable files with the contents of the executable file 410 enables a determination as to whether the executable file includes malware. Thereafter, the static analysis logic 460 produces an output including features representing the detected indicators, which is provided to the static encoding logic 465.
[0120] Referring now to FIG. 8, a third illustrative embodiment of the cyber-security system 100 deploying the computational analysis subsystem 400, the intelligence-driven analysis subsystem 450 and another type of post-analysis subsystem 800 is shown. Herein, the post-analysis subsystem 800 includes a first classifier 810 communicatively coupled to the FCN logic 116 to produce a first threat score 815 based on the features extracted by the computational analysis system 400. Similarly, the post-analysis subsystem 800 includes a second classifier 820 to produce a second threat score 825 based on indicators detected by the static analysis logic 460. Hence, the computational analysis subsystem 400 and the intelligence-driven analysis subsystem 450 may operate concurrently.
It would have been obvious to a person of ordinary skill in the art before the effective filing of the invention to modify Chan/Briliauskas with generate a refined maliciousness score. The reason for this modification would be to provide stronger threat detection by determination of a second thread score on a second classifier.
Chan further teaches associating, in the database, the refined maliciousness score with the cryptographic hash independently of the maliciousness score generated by the classification model(the database i.e. few show database having positive and negative examples of vulnerability is separate from the probability score that code contains vulnerabilities, ¶s18,31) .
[0018] The classifier model 104 receives the token sequence, as a sequence of token embeddings, and identifies a type of software vulnerability and positions in the token sequence that are associated with the type of software vulnerability. In an aspect, the token sequence consists of at most T tokens and can identify n types of software vulnerabilities. The classifier model generates an output probability for each class which consists of the t token positions and the n software vulnerabilities, P(t.sub.1, . . . t.sub.T), P(v.sub.1, . . . , P(v.sub.n). When a probability exceeds a threshold, such as greater than 0.5, the associated token or vulnerability class is considered vulnerable. In an aspect, T is 512 tokens and n is 27 vulnerability classes. P(t) represents the probability of the token in position t and P(v) represents the probability of vulnerability class v.
[0031] A few-shot example consists of a source code snippet having an identified software vulnerability type and token positions in the source code snippet identified as being associated with the software vulnerability type. The few-shot examples are used to guide the large language model on the vulnerability detection task. The few-shot examples are obtained from a few-shot example database 108 which stores positive and negative samples for each vulnerability type. A positive sample includes a source code snippet having an identified vulnerability and a negative sample includes a source code snippet without an identified vulnerability. In an aspect, the few-shot example database 108 may include a template for each vulnerability type that includes positive and negative samples
Regarding claims 3 and 13, Chan teaches wherein at least one of: determining that the file comprises source code for causing malicious activity is without executing executable code associated with the source code; generating, using the one or more large language models (LLMs), the NL description of the source code is without executing the executable code associated with the source code(detecting of code performed by parsing the code, tokenizing the code and determining probability of a vulnerability type instead of executing the code to detect malicious actions by the code, ¶70)
or generating, using the classification model, the maliciousness score for the source code is without executing the executable code associated with the source code(detecting of code performed by parsing the code and tokenizing the code and determining probability of a vulnerability type instead of executing the code to detect malicious actions by the code, ¶70).
[0070] Attention now turns to a description of the inference phase. Turning to FIG. 6, there is shown an exemplary method of the vulnerability detection and repair system 600. The method receives a source code snippet to analyze for a vulnerability (block 602). The source code snippet is parsed into a syntax tree from which tokens are extracted to generate an input sequence of tokens of length T (block 604). Each token in the input sequence is replaced with a corresponding token embedding and the sequence of embeddings is applied to the neural encoder transformer model with attention (block 604).
Regarding claim 9, Chan teaches sending, to an administrative device, an alert indicating at least one of: the NL description of the source code, the maliciousness score for the source code, or a maliciousness category corresponding to the maliciousness score.
[0041] FIGS. 3A and 3B illustrate exemplary systems utilizing the vulnerability detection and repair system. Turning to FIG. 3A, there is shown a system 300 where the vulnerability detection and repair system 308 operates within an integrated development environment (IDE) 302. The IDE 302 is a software development tool that provides tools for software development, such as without limitation, source code editors, compilers, debuggers, build automation tools, and the like. The vulnerability detection and repair system 308 receives a request from a source code editor 304 to check a source code snippet for a vulnerability. The vulnerability detection and repair system 308 analyzes the predicted source code snippet 306 for software vulnerabilities using the classifier model 310 and the large language model 312 and optionally, generates a repair for the identified vulnerability. A vulnerability notification is sent to the source code editor 304 along with a repaired source code snippet, if vulnerable code is detected 314.
Claims 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Chan/Briliauskas/Johns as applied to claims 1 and 11 above, and further in view of Nguyen US 2020/0159916.
Regarding claim 2 and 12, Chan does not teach acquiring event data indicating that an endpoint device downloaded the file or attempted to execute the file. Nguyen in the same field of endeavor as the invention teaches a system for vulnerability detection. Nguyen teaches acquiring event data indicating that an endpoint device downloaded the file or attempted to execute the file.
[0121] Throughout this document, an event record 112, or any other record described herein, can include one or more fields, each of which can have a name or other identifier, and each of which can include or be associated with one or more values. For example, event record 112 or other records herein can be represented as ASN.1-defined data structures, GOOGLE protobufs, JSON records, XML documents or subtrees, associative arrays, or other forms of tagged or key-value storage. Examples of fields can include, but are not limited to, timestamps, filenames, filehandles, userids (e.g., Windows SIDs), groupids, process identifiers, session identifiers (e.g., process command lines), command-line histories, universally unique identifiers (UUIDs), operating-system identifiers, e.g., from uname(1), permissions, access-control lists (ACLs), login types (e.g., with or without secure attention sequence), timestamps, blocks of data (e.g., headers or full contents of files or of regions of memory), hashes of data (e.g., of the blocks of data, such as file contents), IP or other network addresses (e.g., of computing device 104 or peers with which it is communicating or is attempting to communicate), network port numbers (e.g., local or remote), identifiers of detection module 226 (e.g., a version number), values from the registry, dotfiles, or other configuration data (e.g., crontab entries), call-stack entries, domain names (e.g., relative or fully-qualified, FQDN), names or other identifiers of mutexes, named pipes, or other inter-thread communication or inter-process communication (IPC) mechanisms, or counts (e.g., of VIRUSTOTAL dirty indications).
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Chan/Briliauskas with maintaining event information associated with code vulnerabilities including filenames and devices names associated with the event. The reason for this modification would be to record event information related to vulnerable code to be displayed to user.
Claims 4-6 and 14-16 are rejected under 35 U.S.C. 103 as being unpatentable over Chan/Briliauskas/Johns as applied to claims 3 and 13 above, and further in view of Qian et al CN11715512A(PTO machine translation).
Regarding claims 4 and 14, Chan teaches use of an LLM to analyze source code but does not teach determining that the source code is associated with a particular programming language; and selecting, based on the particular programming language, a first LLM from a plurality of LLMs associated with a plurality of programming languages, each LLM is trained to ingest source code associated with a respective programming language of the plurality of programming languages. Qian in the same field of endeavor as the invention teaches an attack detection method using LLM. Qian teaches determining that the source code is associated with a particular programming language; and selecting, based on the particular programming language, a first LLM from a plurality of LLMs associated with a plurality of programming languages, each LLM is trained to ingest source code associated with a respective programming language of the plurality of programming languages(LLM is trained to process multiple programming languages C# , Java etc, Page 2,9).
[Page2 Network security risks are becoming the first and foremost concern in the world because once vulnerabilities are exploited by malicious attacks, the security of the system will be greatly endangered and catastrophic losses may be caused. The main channel used by hacker attacks is software applications, in which billions of rows of codes are written in various programming languages, and each language may become a potential carrier for security vulnerabilities. At present, in the software development process, the traditional technology for detecting the security vulnerability in the source code is limited to partial programming language.
Some automated tools, including currently popular large language models, can achieve transcoding between different languages, but this also causes the vulnerabilities contained in some source codes to be inherited together into the translated target code. The traditional source code vulnerability detection technology is mainly based on vulnerability code clone detection, which requires that the detected target is the same kind of code, and the code after language conversion is difficult to detect the vulnerability.
The purpose of the application is to realize a cross-language source code vulnerability detection method, capable of representing the characteristics of the source code control vector and the data stream vector, detecting code segments of different languages homologous to the code with vulnerability, so as to determine the existence of the vulnerability, the method can solve many problems, It comprises the problem that the code cannot be detected after being transplanted to other language platforms based on the clone code detection technology in the traditional technology, the problem that some unpopular languages do not provide corresponding code vulnerability detection tools, and the code fragment data set needs to be pre-marked when using machine learning to perform code fragment vulnerability identification, The method cannot detect the problem of the language which does not support the marked data set. ]
[page 9 In the embodiment, the initial detection set of the source code is collected and the initial detection set of the source code is scanned to obtain the tag set of the segment to be detected; invoking a source ode vulnerability detection model; wherein the source code vulnerability detection model is obtained by the above embodiments; inputting the tag set of the segment to be detected to the source code vulnerability detection model to obtain the source code vulnerability detection result. selecting one or more source code vulnerability detection clustering models and source code vulnerability detection classification models to perform code similarity detection based on the knowledge map label, which can reduce the influence during cross-language detection and improve the accuracy of the detection result.
In one embodiment, the step of inputting the tag set of the fragment to be detected to the source code vulnerability detection model to obtain the source code vulnerability detection result comprises: under the condition that the to-be-detected segment label set comprises a single to-be-detected segment label, using the source code vulnerability detection model corresponding to the single to-be-detected segment label to detect, obtaining the source code vulnerability detection result; under the condition that the to-be-detected segment label set comprises multiple to-be-detected segment labels, when the output result of the target to-be-detected segment label corresponding to the source code vulnerability detection model is greater than the threshold value, outputting the detection result of the source code vulnerability detection model corresponding to the target to-be-detected segment label; when the output result of the source code vulnerability detection model corresponding to the target segment label to be detected is not greater than the threshold value, sequencing all output results and outputting the maximum detection result.]
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Chan/Briliauskas with pretraining models for teach source code language of multi-languages as taught by Qian. The reason for this modification would be to implement natural language detection of code that is customized to the specific source code language.
Regarding claims 5 and 15, Chan teaches use of an LLM to analyze source code but does not teach source code to cause the malicious activity further comprises: providing the source code to a second classification model trained to generate a second set of maliciousness scores indicating whether the source codes are associated with the one or more types of malicious activity; and generating, using the second classification model, a second maliciousness score for the source code indicating that the source code is associated with the one or more types of malicious activity. Qian in the same field of endeavor as the invention teaches an attack detection method using LLM. Qian teaches source code to cause the malicious activity further comprises: providing the source code to a second classification model trained to generate a second set of maliciousness scores indicating whether the source codes are associated with the one or more types of malicious activity; and generating, using the second classification model, a second maliciousness score for the source code indicating that the source code is associated with the one or more types of malicious activity(classification models are created to detect malicious code for multiple differing programming languages ie. C C#, Java, page9,10).
[Page9 In the embodiment, the initial detection set of the source code is collected and the initial detection set of the source code is scanned to obtain the tag set of the segment to be detected; invoking a source code vulnerability detection model; wherein the source code vulnerability detection model is obtained by the above embodiments; inputting the tag set of the segment to be detected to the source code vulnerability detection model to obtain the source code vulnerability detection result. selecting one or more source code vulnerability detection clustering models and source code vulnerability detection classification models to perform code similarity detection based on the knowledge map label, which can reduce the influence during cross-language detection and improve the accuracy of the detection result.]
[Page10 In one embodiment, a cross-language source code vulnerability detection is described by taking a specific scenario in which the C# code is detected by a JAVA source code vulnerability detection model and the vulnerability is found as an example. As shown in FIG. 3, a code segment of the language to be detected is input, which is written in the Bail language. As shown in FIG. 4, the evolution source language of the language obtained on the programming language knowledge map is C language, and the group label corresponding to the C language is obtained. As shown in FIG. 5, the code segment of the language to be detected is formalized and separated to obtain the key words of the control stream and the data stream. As shown in FIG. 6, the word embedding vector of the control stream key word is calculated, and the cluster head matching is performed by using the source code vulnerability detection cluster model of the C language, and the input vector of the code segment of the language to be detected is calculated. Further, the source code vulnerability detection classification model of the group in which the C language is located is obtained, the vulnerability detection of the model is performed by using the generated input vector, and the tag for outputting the vulnerability detection is CWE-121.]
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Chan/Briliauskas with pretraining models for teach source code language of multi-languages as taught by Qian. The reason for this modification would be to implement natural language detection of code that is customized to the specific source code language.
Regarding claims 6 and 16, Qian teaches determining that the source code is associated with a particular programming language; and selecting, based on the particular programming language, the second classification model from a plurality of classification models associated with a plurality of programming languages, each classification model of the plurality of classification models is trained to ingest source code associated with a respective programming language of the plurality of programming languages(each language trained and stores the trained model for each language for, Page4 7).
[Page4 The source code vulnerability detecting method, model training method, device, computer device and storage medium collect source code vulnerability sample set; classifying the source code of the source code vulnerability sample set, and obtaining the source code vulnerability detection clustering model and the source code vulnerability detection classification model of the type according to the classification result; based on the source code vulnerability sample set and the source code vulnerability detection clustering model, obtaining the control flow direction quantity and the data flow vector, and based on the control flow direction quantity and the data flow vector, constructing the input vector of the source code vulnerability detection classification model; The input vector is input to the source code vulnerability detection classification model for training to generate and store the source code vulnerability detection model; at the same time, by collecting the source code initial detection set, and scanning the source code initial detection set, obtaining the fragment label set to be detected; invoking a source code vulnerability detection model; the tag set of the segment to be detected is input to the source code vulnerability detection model to obtain the source code vulnerability detection result, and multiple tags are mapped to multiple models in the process to enhance the accuracy of the detection result.]
[Page7 In the training method of the source code vulnerability detection model, the source code vulnerability sample set is collected; classifying the source code of the source code vulnerability sample set, and obtaining the source code vulnerability detection clustering model and the source code vulnerability detection classification model of the type according to the classification result; based on the source ode vulnerability sample set and the source code vulnerability detection clustering model, obtaining the control flow direction quantity and the data flow vector, and based on the control flow direction quantity and the data flow vector, constructing the input vector of the source code vulnerability detection classification model; inputting the input vector to the source code vulnerability detection classification model for training, generating and storing the source code vulnerability detection model.in the training process, the control stream and the data stream are separated to further reduce the keyword difference in the cross-language, the source code vulnerability sample set is identified and the class label is marked, different labels are corresponding to different models, which can enhance the accuracy of the source code vulnerability detection model identification result.]
Claims 8, 10, 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Chan/Briliauskas/Johns as applied to claims 1 and 7 above, and further in view of Zhang US 2025/0028840.
Regarding claims 8 and 18, Chan/Briliauskas/Johns do not teach at least one or more of: retraining, using the plurality of NL descriptions, the classification model to generate a second set of maliciousness scores each indicating whether the source codes are associated with the one or more types of malicious activity; or retraining, using the plurality of NL descriptions, the one or more LLMs to generate a set of NL descriptions of source codes. Zhang in the same field of endeavor as the invention teaches a vulnerability detection system. Zhang teaches at least one or more of: retraining, using the plurality of NL descriptions, the classification model to generate a second set of maliciousness scores each indicating whether the source codes are associated with the one or more types of malicious activity (generating risk score that identifying vulnerability of a certain type, ¶35,36).
[0035] Security evaluation code 200 generates or constructs a risk data model at operation 210. The risk data model is constructed to store, and perform initial categorization of, a history of security data (e.g., risk or risk identifier, issue description, etc.). The risk data model is integrated with additional information at operation 215. The additional information may include vulnerability type, risk score/type, explanation of risk score type, function attributes (e.g., function name, variables, comments, paths, file name, etc.), etc. The risk data model stores security data, including extracted valid data from a history including a significant number of software or code scan reports, and an initialized risk score for each category of scan findings. The risk data model provides a basis for comparison of newly scanned issues.
[0036] A risk data model 300 is illustrated, by way of example only, in FIG. 3. Risk data model 300 is shown in the form of a table with columns or fields for indicating a risk, issue description, file, codes (raising the issue), a risk score and/or type, and an explanation of the risk score and/or type. Risk field 305 indicates an identified risk. This may be accomplished by providing a description of the risk and/or an identifier (e.g., common weakness enumeration (CWE) identification and/or description, etc.). Issue description field 310 provides a description of the issue, while file field 315 indicates a path and/or file name for the file containing the code. Codes field 320 indicates the code statement containing the issue. Risk score field 330 provides a risk score and/or type (e.g., true or false positive, etc.) for the security issue, and explanation field 325 provides an explanation for the risk score and/or type (e.g., explanation of a false positive, etc.).
; or retraining, using the plurality of NL descriptions, the one or more LLMs to generate a set of NL descriptions of source codes(retraining to improve scores to increase detection accuracy, ¶44)
[0044] Security evaluation code 200 performs an analysis based on the risk factor and risk weight machine learning models and variable lifecycle chain at operation 240 to render a determination with respect to the security issue (associated with the problematic variable) being a valid security issue or a false positive. The determination and corresponding information (e.g., the final risk factor score, function attributes, etc.) is fed back to the risk factor and risk weight machine learning models at operation 245 for continuous re-training to improve results.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Chan/Briliauskas/Johns with continual retraining as taught by Zhang of the classifier models of Chan. The reason for this modification would be to refine and improve vulnerability detection.
Regarding claims 10 and 19, Chan does not teach determining whether the source code is for causing malicious activity by comparing the maliciousness score to a predetermined threshold value; and reducing a number of false positives by redefining the file as non-malicious responsive to determining that the source code is not for malicious activity. Zhang in the same field of endeavor as the invention teaches vulnerability detection system. Zhang teaches determining whether the source code is for causing malicious activity by comparing the maliciousness score to a predetermined threshold value; and reducing a number of false positives by redefining the file as non-malicious responsive to determining that the source code is not for malicious activity(retraining of classification models improves detection and reduces false positives, ¶s64,70).
[0064] When the security issue is a false positive, the security issue is reported as a false positive at operation 590. A report may be sent to one or more persons associated with the code portion or security issue, and may include any information (e.g., function name, variable, explanation, risk factor score, severity, false positive indication, etc.). The determination and corresponding information (e.g., risk factor score, function name, variable, etc.) is fed back to the machine learning models for continuous re-training to improve accuracy. The security issues or findings in the security evaluation may each be processed in substantially the same manner described above to determine or predict valid security issues and/or false positives and severity of the security issues.
[0070] Present invention embodiments may provide various technical and other advantages. In an embodiment, the machine learning models may be continuously updated (or trained) based on user feedback, new security scan information, and/or determinations/predictions of the machine learning models. For example, user feedback (e.g., overrides, corrections, etc.), new security scan information, and/or determinations/predictions may indicate more preferable determinations for security issues for a user. This information may be used to update or train the machine learning models with new or different training data (e.g., derived from attributes of the information, etc.) to enable determination of security issues with greater accuracy and closer to user preferences (e.g., the machine learning models may be updated with respect to determination of valid security issues or false positives, etc.). Thus, the machine learning models may continuously evolve (or be trained) to learn characteristics of valid issues, false positives, and a specific user and/or improve accuracy or relevancy to the user.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Chan/Briliauskas with continual retraining to reduce false positives as taught by Zhang of the classifier models of Chan. The reason for this modification would be to refine and improve vulnerability detection reducing misclassifications.
Applicant Remarks
Applicant’s arguments with respect to claims 1-6, 8-16, and 18-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tom Y. Chang whose telephone number is 571-270-5938. The examiner can normally be reached on Monday-Friday from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Emmanuel Moise, can be reached on (571)272-3865. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/TOM Y CHANG/
Primary Examiner, Art Unit 2455
Prosecution Insights