DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application is being examined under the pre-AIA first to invent provisions.
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-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. Claim 1 claims, “wherein the vector embedding model is specifically trained to process binary code”. The examiner has not been able to find anywhere in the specification that teaches or suggests this limitation.
Claim 2-7 are rejected to being dependent on rejected claim 1.
Claims 8-20, have similar limitations to claim 1-7 and are therefore rejected for the same reasons.
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.
Claims 1-20 are 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 1 claims, “wherein the vector embedding model is specifically trained to process binary code”. However claim 1 also claims, “disassembling a reference binary to generate a first control flow graph…normalizing the first control flow graph…traversing the first normalizing graph to generate a first plurality of execution traces…generating a plurality of library vector embeddings… processing the execution trace by a vector embedding model…” and claim 2 claims, “disassembling target software to generate a second control flow graph….processing the second plurality of the execution traces by the vector embedding model…”. Therefore, the vector embedding model is processing execution traces generated from the binary not the binary. Therefore, the vector embedding model is not specifically trained to process binary code. The examiner is interpreting this limitation to mean that the vector embedding model is trained to process execution traces generated from binary code.
Claim 2-7 are rejected to being dependent on rejected claim 1.
Claims 8-20, have similar limitations to claim 1-7 and are therefore rejected for the same reasons.
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 pre-AIA 35 U.S.C. 103(a) which forms the basis for all obviousness rejections set forth in this Office action:
(a) A patent may not be obtained through the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 6-11 and 13-14 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Bryne et al. (US 2020/0394028 A1) and further in view of Ji et al. (US 2022/0244953 A1), Alomari (US 2020/0218535 A1), Kumar et al. (US 2021/0374229 A1) and Wu et al. (US 2023/0185568 A1).
As per claim 1 (Amended), Bryne et al. teaches, “A method comprising:
disassembling a reference binary of a library to generate a first control flow graph of the reference binary;”
Bryne et al. teaches, third party components such as libraries can contain vulnerabilities (0018). A binary is dissembled and translated into an intermediate representation (0019, 0030, 0034, and 0041).
“Normalizing the first control flow graph by replacing a plurality of hardware specific operand with a placeholder representing a type of operand while maintaining a corresponding operator in the first control glow graph, wherein normalizing the first control flow graph generates
traversing the first normalized graph to generate a first plurality of execution traces from the first normalized graph;
generating a plurality of library vector embeddings by, for each execution trace of at least a subset of the first plurality of execution traces, processing the execution trace by a vector embedding model to generate a library vector embedding of the execution trace, wherein the vector embedding model is specifically rained to process binary code; and
relating, in storage, a library identifier of the library to the plurality of library vector embeddings as a fingerprint of the library.
Binary is disassembled and translated into an intermediate representation and symbolic expressions are extracted. Symbolic execution is performed to generate the fingerprint (0046). A fingerprint of binary functions is produced. An execution component executes the filtered representation of the virtual machine to generate an output vector (0019, 0029). Population component can populate a database, with the output vector. The output vector can be labeled including a function name, library name and/or library version. In the database the output vector can server as a vulnerability fingerprint of the portion of binary code. A machine learning model can search for the fingerprint based on, similarity with another fingerprint or set of fingerprints. The fingerprint can be classified (0030-0032). (0054). A database or machine learning model can receive a function fingerprint, which can comprise or consist of the output vector. The database or machine learning model can store, compare, and/or classify the function fingerprint (0036).
However, Bryne et al. does not explicitly teach,
“disassembling a reference binary of a library to generate a first control flow graph of the referenced binary;” and
“normalizing the first control flow graph by replacing a plurality of hardware specific operand with a placeholder representing a type of operand while maintaining a corresponding operator in the first control glow graph, wherein normalizing the first control flow graph generates normalized graph;
traversing the first normalized graph to generate a first plurality of execution traces from the first normalized graph;
generating a plurality of library vector embeddings by, for each execution trace of at least a subset of the first plurality of execution traces, processing the execution trace by a vector embedding model to generate a library vector embedding of the execution trace; and”
Ji et al. teaches generating a control flow graph of one or more functions in the target binary code. A control flow graph is a representation, using graph notation of all paths that might be traversed though a program during its execution (0058). The system normalizes the control flow graph (0060). The system extracts function-level features by extracting different subgraphs from the normalized CFG (0061).
Alomari teaches, Source code is converted into tokens associated with a plurality of blocks of programming statements. Tokens are modified by normalizing at least one value of the plurality of blocks of programming statements. A representation is created which is associated with control flow of a plurality of blocks associated with a respective token. The control flow includes a plurality of possible operational paths associated with the blocks in each of the modified tokens. A digital fingerprint representing a respective operational path associated with the control flow for a given token is generated (0005). Source code is processed and represented by generic control flow programming blocks. The blocks are transformed to generate unique digital fingerprints. The digital fingerprints represent code semantics as well as code execution behavior. The fingerprints can be stored and later used for searching for duplicate source code (0031).
Kumar et al. teaches normalizing includes replacing functions with placeholder’s representative of the data type of the arguments to generated normalized functions. A placeholder representative of a register data type is R. An example placeholder representative of a memory data type is m. An example placeholder representative of an integer datatype is i (0037).
Wu et al. teaches the computer utilizes the information contained in a program function call graph (CFG) as training data to train graph neural network to identify features or each respective function of the program. Once the graph neural network is trained the computer utilizes the graph neural network to generate feature embeddings of functions. Each feature embedding is a vector representation of a particular features of a corresponding function (0060).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Bryne et al. with Ji et al, Alomari, Kumar et al. and Wu et al. because all teach some form of matching code/text to another. Bryne et al. teaches disassembling binary of a library into an intermediate representation. Output vectors (fingerprints) are generated for the library by executing a filtered representation of the intermediate representation and the fingerprints are saved in order to be used to be compared against other binaries. However, Bryne et al. does not teach the intermediate representation being a CFG, normalizing the CFG, traversing the normalized CFG to generate execution traces and using embedding model to generate a plurality of library vector embeddings for each execution trace. Jai et al. teaches that a binary can be disassembled to generated a CFG and that the CFG can be normalized prior to using it for the generation of code fingerprints for code comparison. Alomari teaches a generated CFG includes a plurality of possible operational paths associated with blocks and that a digital fingerprint of source code is generated representing a respective path associated with the control flow and normalizing values. Therefore, together Ji et al. and Alomari et al. would make it obvious to one of ordinary skill for the intermediate representation of Bryne et al. to be a CFG. A CFG can be used to generate fingerprints of source code for comparison and replacing it as the intermediate representation in Bryne et al. would produce similar results and therefore be obvious to try. Bothe methods generate source code fingerprints. However, neither explicitly teach what is exactly done in the normalizing step. Kumar et al. teaches normalizing by replacing arguments of functions with placeholder’s representative of a register data type, a memory data type or at integer data type. Replacing specific data types with placeholders to normalize them is a known technique to improve the comparison of data. Wu et al. teaches the use of a trained graph neural network in order to generate a feature embedding (fingerprint) of source code from a call graph (CFG). This is nothing more than a design choice and would have been obvious to try.
As per claim 2, Bryne et al, Ji et al, Alomari and Wu et al. further teach, “The method of claim 1, further comprising:
disassembling target software to generate a second control flow graph of the target software; normalizing the second control flow graph to generate a second normalized graph;
traversing the second normalized graph to generate a second plurality of execution traces from the second normalized graph;
generating a plurality of target vector embeddings by processing the second plurality of the execution traces by the vector embedding model; and
selecting the library as being in the target software when the plurality of target vector embeddings matching the plurality of library vector embeddings satisfy a threshold.”
Bryne et al. teaches a binary is disassembled and translated into an intermediate representation and symbolic expressions are extracted. Symbolic execution is performed to generate the fingerprint (0046). A fingerprint of binary functions is produced. An execution component executes the filtered representation of the virtual machine to generate an output vector (0019, 0029). Population component can populate a database, with the output vector. The output vector can be labeled including a function name, library name and/or library version. In the database the output vector can server as a vulnerability fingerprint of the portion of binary code. A machine learning model can search for the fingerprint based on, similarity with another fingerprint or set of fingerprints. The fingerprint can be classified (0030-0032, 0054). A database or machine learning model can receive a function fingerprint, which can comprise or consist of the output vector. The database or machine learning model can store, compare, and/or classify the function fingerprint (0036).
Ji et al. teaches generating a control flow graph of one or more functions in the target binary code. A control flow graph is a representation, using graph notation of all paths that might be traversed though a program during its execution (0058). The system normalizes the control flow graph (0060). The system extracts function-level features by extracting different subgraphs from the normalized CFG (0061).
Alomari (US 2020/0218535 A1) teaches, Source code is converted into tokens associated with a plurality of blocks of programming statements. Tokens are modified by normalizing at least one value of the plurality of blocks of programming statements. A representation is created which is associated with control flow of a plurality of blocks associated with a respective token. The control flow includes a plurality of possible operational paths associated with the blocks in each of the modified tokens. A digital fingerprint representing a respective operational path associated with the control flow for a given token is generated. Source code within at least one block of a given token is determined and identifiable as being a duplicate of source code stored in a repository by comparing at least one of the generated digital fingerprints and at least on previously generated digital fingerprint (0005). Source code is processed and represented by generic control flow programming blocks. The blocks are transformed to generate unique digital fingerprints. The digital fingerprints represent code semantics as well as code execution behavior. The fingerprints can be stored and later used for searching for duplicate source code (0031). Blocks in a respective fingerprint are compared to blocks in a group or cluster using threshold of similarity to determine if the code is the same (0059).
Wu et al. teaches the computer utilizes the information contained in program function call graph (CFG) as training data to train graph neural network to identify features or each respective function of the program. Once the graph neural network is trained the computer utilizes the graph neural network to generate feature embeddings of functions (functions). Each feature embedding is a vector representation of a particular features of a corresponding function (0060).
As per claim 3, Bryne et al. and Alomari further teach “The method of claim 1, further comprising:
obtaining source code for each library version of a plurality of library versions of the library;
generating a plurality of library version fingerprints from the source code for each library version of the plurality of library versions; and
processing target software using the plurality of library version fingerprints to detect a library version of the library in the target software.”
Bryne et al. teaches a binary is disassembled and translated into an intermediate representation and symbolic expressions are extracted. Symbolic execution is performed to generate the fingerprint (0046). A fingerprint of binary functions is produced. An execution component executes the filtered representation of the virtual machine to generate an output vector (0019, 0029). Population component can populate a database, with the output vector. The output vector can be labeled including a function name, library name and/or library version. In the database the output vector can server as a vulnerability fingerprint of the portion of binary code. A machine learning model can search for the fingerprint based on, similarity with another fingerprint or set of fingerprints. The fingerprint can be classified (0030-0032). (0054). A database or machine learning model can receive a function fingerprint, which can comprise or consist of the output vector. The database or machine learning model can store, compare, and/or classify the function fingerprint (0036).
Alomari (US 2020/0218535 A1) teaches, Source code is converted into tokens associated with a plurality of blocks of programming statements. Tokens are modified by normalizing at least one value of the plurality of blocks of programming statements. A representation is created which is associated with control flow of a plurality of blocks associated with a respective token. The control flow includes a plurality of possible operational paths associated with the blocks in each of the modified tokens. A digital fingerprint representing a respective operational path associated with the control flow for a given token is generated. Source code within at least one block of a given token is determined and identifiable as being a duplicate of source code stored in a repository by comparing at least one of the generated digital fingerprints and at least on previously generated digital fingerprint (0005).
The examiner states that Bryne et al. teaches the disassembly of binary to generate a fingerprint, while Alomari et al. teaches using source code. This is nothing more than a design choice since both produce similar results and would have been obvious to try before the effective filing date of the invention.
As per claim 4, Bryne et al. and Alomari further teach “The method of claim 3, wherein generating the plurality of library version fingerprints comprises, for the library version:
parsing the source code of the library version to obtain parsed source code;
selecting a compiler agnostic portion of the source code;
processing the compiler agnostic portion through the vector embedding model to generate a version vector embedding of the library version; and
relating, in storage a library version identifier of the library version with the version vector embedding of the library version.” Bryne et al. teaches a binary is disassembled and translated into an intermediate representation and symbolic expressions are extracted. Symbolic execution is performed to generate the fingerprint (0046). A fingerprint of binary functions is produced. An execution component executes the filtered representation of the virtual machine to generate an output vector. The platform-independent intermediate representation can be filtered and the filtered representation is executed to create the output vector to make it compiler independent (0019, 0029). Population component can populate a database, with the output vector. The output vector can be labeled including a function name, library name and/or library version. In the database the output vector can server as a vulnerability fingerprint of the portion of binary code. A machine learning model can search for the fingerprint based on, similarity with another fingerprint or set of fingerprints. The fingerprint can be classified (0030-0032). (0054). A database or machine learning model can receive a function fingerprint, which can comprise or consist of the output vector. The database or machine learning model can store, compare, and/or classify the function fingerprint (0036).
Alomari (US 2020/0218535 A1) teaches, Source code is converted into tokens associated with a plurality of blocks of programming statements. Tokens are modified by normalizing at least one value of the plurality of blocks of programming statements. A representation is created which is associated with control flow of a plurality of blocks associated with a respective token. The control flow includes a plurality of possible operational paths associated with the blocks in each of the modified tokens. A digital fingerprint representing a respective operational path associated with the control flow for a given token is generated. Source code within at least one block of a given token is determined and identifiable as being a duplicate of source code stored in a repository by comparing at least one of the generated digital fingerprints and at least on previously generated digital fingerprint (0005). Also see 0041-0042.
The examiner states that Bryne et al. teaches the disassembly of binary to generate a fingerprint, while Alomari et al. teaches using source code. This is nothing more than a design choice since both produce similar results and would have been obvious to try before the effective filing date of the invention.
As per claim 6, Bryne et al. further teaches, “The method of claim 1, further comprising:
grouping a plurality of training execution traces by function to obtain a function training dataset;
and training the vector embedding model using the function training dataset.”
Binary is disassembled and translated into an intermediate representation and symbolic expressions are extracted. Symbolic execution is performed to generate the fingerprint (0046). A fingerprint of binary functions is produced. An execution component executes the filtered representation of the virtual machine to generate an output vector (0019, 0029). Population component can populate a database, with the output vector. The output vector can be labeled including a function name, library name and/or library function. In the database the output vector can server as a vulnerability fingerprint of the portion of binary code. A machine learning model can search for the fingerprint based on, similarity with another fingerprint or set of fingerprints. The fingerprint can be classified (grouped) (0030-0032). (0054). A database or machine learning model can receive a function fingerprint, which can comprise or consist of the output vector. The database or machine learning model can store (train), compare, and/or classify (group) the function fingerprint (0036).
Alomari (US 2020/0218535 A1) teaches, Source code is converted into tokens associated with a plurality of blocks of programming statements. Tokens are modified by normalizing at least one value of the plurality of blocks of programming statements. A representation is created which is associated with control flow of a plurality of blocks associated with a respective token. The control flow includes a plurality of possible operational paths associated with the blocks in each of the modified tokens. A digital fingerprint representing a respective operational path associated with the control flow for a given token is generated. Source code within at least one block of a given token is determined and identifiable as being a duplicate of source code stored in a repository by comparing at least one of the generated digital fingerprints and at least on previously generated digital fingerprint (0005). Also see 0041-0042.
As per claim 7, Bryne et al. further teaches, “The method of claim 6, wherein training the vector embedding model comprises:
training the vector embedding model to predict whether at least two of the training execution traces are members of a same function training dataset.”
Binary is disassembled and translated into an intermediate representation and symbolic expressions are extracted. Symbolic execution is performed to generate the fingerprint (0046). A fingerprint of binary functions is produced. An execution component executes the filtered representation of the virtual machine to generate an output vector (0019, 0029). Population component can populate a database, with the output vector. The output vector can be labeled including a function name, library name and/or library function. In the database the output vector can server as a vulnerability fingerprint of the portion of binary code. A machine learning model can search for the fingerprint based on, similarity with another fingerprint or set of fingerprints. The fingerprint can be classified (0030-0032). (0054). A database or machine learning model can receive a function fingerprint, which can comprise or consist of the output vector. The database or machine learning model can store, compare, and/or classify the function fingerprint (0036). A cosine similarity (threshold) can be used to match (0030). Also see figures 1 and 2. Also see figure 6 (252 and paragraph 0032), see figure 3 and paragraph 0044 and 0069. Therefore, the examiner states, as shown above, after the machine learning model stores the fingerprint of the portion of the binary. A target binary or any other binary can be fed into the trained model do determine a fingerprint of the binary and to compare the fingerprint to stored fingerprints containing vulnerabilities to determine if the target binary has a vulnerability. This vulnerability can be part of a library that is found to have a similar fingerprint which has a vulnerability.
Alomari (US 2020/0218535 A1) teaches, Source code is converted into tokens associated with a plurality of blocks of programming statements. Tokens are modified by normalizing at least one value of the plurality of blocks of programming statements. A representation is created which is associated with control flow of a plurality of blocks associated with a respective token. The control flow includes a plurality of possible operational paths associated with the blocks in each of the modified tokens. A digital fingerprint representing a respective operational path associated with the control flow for a given token is generated. Source code within at least one block of a given token is determined and identifiable as being a duplicate of source code stored in a repository by comparing at least one of the generated digital fingerprints and at least on previously generated digital fingerprint (0005). Also see 0041-0042.
As per claim 8-11 and 13-14, contain similar limitation to claim 1-4 and 6-7. Therefore, they are rejected for similar reasons.
Claims 15-20 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Bryne et al. (US 2020/0394028 A1) and further in view of Ji et al. (US 2022/0244953 A1), Alomari (US 2020/0218535 A1) and Kumar et al. (US 2021/0374229 A1).
As per claim 15 (Amended), Bryne et al. teaches, “A method comprising:
disassembling target software to generate a control flow graph;”
Bryne et al. teaches, third party components such as libraries can contain vulnerabilities (0018). A binary is dissembled and translated into an intermediate representation (0019, 0030, 0034, and 0041).
“normalizing the control flow graph by replacing a plurality of hardware specific operand with a placeholder representing a type of operation while maintaining a corresponding operator in the first control flow graph, wherein normalizing the control flow graph generates
traversing the normalized graph to generate a plurality of execution traces from the normalized graph;
processing, by a vector embedding model specifically trained on binary code, the plurality of execution traces to generate a plurality of target vector embeddings of the target software;
selecting, from a plurality of libraries, a library in which the plurality of target vector embeddings matches a first threshold of a library fingerprint of the library to obtain a selected library; and
processing the target software based on the selected library.”
Binary is disassembled and translated into an intermediate representation and symbolic expressions are extracted. Symbolic execution is performed to generate the fingerprint (0046). A fingerprint of binary functions is produced. An execution component executes the filtered representation of the virtual machine to generate an output vector (0019, 0029). Population component can populate a database, with the output vector. The output vector can be labeled including a function name, library name and/or library version. In the database the output vector can server as a vulnerability fingerprint of the portion of binary code. A machine learning model can search for the fingerprint based on, similarity with another fingerprint or set of fingerprints. The fingerprint can be classified (0030-0032). (0054). A database or machine learning model can receive a function fingerprint, which can comprise or consist of the output vector. The database or machine learning model can store, compare, and/or classify the function fingerprint (0036). A cosine similarity (threshold) can be used to match (0030). Also see figures 1 and 2. Also see figure 6 (252 and paragraph 0032), see figure 3 and paragraph 0044 and 0069. Therefore, the examiner states, as shown above, after the machine learning model stores the fingerprint of the portion of the binary. A target binary or any other binary can be fed into the trained model do determine a fingerprint of the binary and to compare the fingerprint to stored fingerprints containing vulnerabilities to determine if the target binary has a vulnerability. This vulnerability can be part of a library that is found to have a similar fingerprint which has a vulnerability.
Bryne does not explicitly appear to teach, “disassembling target software to generate a control flow graph;
normalizing the control flow graph to by replacing a plurality of hardware specific operand with a placeholder representing a type of operation while maintaining a corresponding operator in the first control flow graph, wherein normalizing the control flow graph generates
traversing the normalized graph to generate a plurality of execution traces from the normalized graph;
processing the plurality of execution traces to generate a plurality of target vector embeddings of the target software;”
Ji et al. teaches generating a control flow graph of one or more functions in the target binary code. A control flow graph is a representation, using graph notation of all paths that might be traversed though a program during its execution (0058). The system normalizes the control flow graph (0060). The system extracts function-level features by extracting different subgraphs from the normalized CFG (0061).
Alomari (US 2020/0218535 A1) teaches, Source code is converted into tokens associated with a plurality of blocks of programming statements. Tokens are modified by normalizing at least one value of the plurality of blocks of programming statements. A representation is created which is associated with control flow of a plurality of blocks associated with a respective token. The control flow includes a plurality of possible operational paths associated with the blocks in each of the modified tokens. A digital fingerprint representing a respective operational path associated with the control flow for a given token is generated (0005). Source code is processed and represented by generic control flow programming blocks. The blocks are transformed to generate unique digital fingerprints. The digital fingerprints represent code semantics as well as code execution behavior. The fingerprints can be stored and later used for searching for duplicate source code (0031).
Kumar et al. teaches normalizing includes replacing functions with placeholder’s representative of the data type of the arguments to generated normalized functions. A placeholder representative of a register data type is R. An example placeholder representative of a memory data type is m. An example placeholder representative of an integer datatype is i (0037).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Bryne et al. with Ji et al, Alomari and Kumar et al. because all teach some form of matching code/text to another. Bryne et al. teaches disassembling binary of a library into an intermediate representation. Output vectors (fingerprints) are generated for the library by executing a filtered representation of the intermediate representation and the fingerprints are saved in order to be used to be compared against other binaries. However, Bryne et al. does not teach the intermediate representation being a CFG, normalizing the CFG, traversing the normalized CFG to generate execution traces and using embedding model to generate a plurality of library vector embeddings for each execution trace. Jai et al. teaches that a binary can be disassembled to generated a CFG and that the CFG can be normalized prior to using it for the generation of code fingerprints for code comparison. Alomari teaches a generated CFG includes a plurality of possible operational paths associated with blocks and that a digital fingerprint of source code is generated representing a respective path associated with the control flow and normalizing values. Therefore, together Ji et al. and Alomari et al. would make it obvious to one of ordinary skill for the intermediate representation of Bryne et al. to be a CFG. A CFG can be used to generate fingerprints of source code for comparison and replacing it as the intermediate representation in Bryne et al. would produce similar results and therefore be obvious to try. Both methods generate source code fingerprints. However, neither explicitly teach what is exactly done in the normalizing step. Kumar et al. teaches normalizing by replacing arguments of functions with placeholder’s representative of a register data type, a memory data type or at integer data type. Replacing specific data types with placeholders to normalize them is a known technique to improve the comparison of data.
As per claim 16, Bryne et al. and Alomari further teach, “The method of claim 15, further comprising:
selecting, from a plurality of library versions of the selected library, a library in which the plurality of target vector embeddings matches a second threshold of a library version fingerprint to obtain a selected library version,
wherein processing the target software is further based on the selected library version.”
Binary is disassembled and translated into an intermediate representation and symbolic expressions are extracted. Symbolic execution is performed to generate the fingerprint (0046). A fingerprint of binary functions is produced. An execution component executes the filtered representation of the virtual machine to generate an output vector (0019, 0029). Population component can populate a database, with the output vector. The output vector can be labeled including a function name, library name and/or library version. In the database the output vector can server as a vulnerability fingerprint of the portion of binary code. A machine learning model can search for the fingerprint based on, similarity with another fingerprint or set of fingerprints. The fingerprint can be classified (0030-0032). (0054). A database or machine learning model can receive a function fingerprint, which can comprise or consist of the output vector. The database or machine learning model can store, compare, and/or classify the function fingerprint (0036). A cosine similarity (threshold) can be used to match (0030). Also see figures 1 and 2. Also see figure 6 (252 and paragraph 0032), see figure 3 and paragraph 0044 and 0069. Therefore, the examiner states, as shown above, after the machine learning model stores the fingerprint of the portion of the binary. A target binary or any other binary can be fed into the trained model do determine a fingerprint of the binary and to compare the fingerprint to stored fingerprints containing vulnerabilities to determine if the target binary has a vulnerability. This vulnerability can be part of a library that is found to have a similar fingerprint which has a vulnerability.
Alomari teaches, Source code is converted into tokens associated with a plurality of blocks of programming statements. Tokens are modified by normalizing at least one value of the plurality of blocks of programming statements. A representation is created which is associated with control flow of a plurality of blocks associated with a respective token. The control flow includes a plurality of possible operational paths associated with the blocks in each of the modified tokens. A digital fingerprint representing a respective operational path associated with the control flow for a given token is generated (0005). Source code is processed and represented by generic control flow programming blocks. The blocks are transformed to generate unique digital fingerprints. The digital fingerprints represent code semantics as well as code execution behavior. The fingerprints can be stored and later used for searching for duplicate source code (0031). Blocks in a respective fingerprint are compared to blocks in a group or cluster using threshold of similarity to determine if the code is the same (0059).
As per claim 17, Bryne et al. and Alomari further teach, “The method of claim 15, wherein processing the target software comprises:
accessing a vulnerability repository with the selected library and a selected library version to detect a vulnerability in the target software; and
reporting the vulnerability.”
Binary is disassembled and translated into an intermediate representation and symbolic expressions are extracted. Symbolic execution is performed to generate the fingerprint (0046). A fingerprint of binary functions is produced. An execution component executes the filtered representation of the virtual machine to generate an output vector (0019, 0029). Population component can populate a database, with the output vector. The output vector can be labeled including a function name, library name and/or library version. In the database the output vector can server as a vulnerability fingerprint of the portion of binary code. A machine learning model can search for the fingerprint based on, similarity with another fingerprint or set of fingerprints. The fingerprint can be classified (0030-0032). (0054). A database or machine learning model can receive a function fingerprint, which can comprise or consist of the output vector. The database or machine learning model can store, compare, and/or classify the function fingerprint (0036). A cosine similarity (threshold) can be used to match (0030). Also see figures 1 and 2. Also see figure 6 (252 and paragraph 0032 (reporting)), see figure 3 and paragraph 0044. The system can populate a database and/or machine learning model with the function fingerprint. Populating, by the system a database with the output vector can include storing the function fingerprint in the database and/or machine learning model, comparing the function fingerprint against others in the database and/or machine learning model and/or classifying the function fingerprint. The function fingerprint can be labeled with a function name, library name, and/or library version (0060). The database can be searched 0069.
As per claim 18, Bryne et al. further teaches “The method of claim 15, wherein selecting the selected library comprises:
comparing a plurality of library vector embeddings of the selected library with the plurality of target vector embeddings of the target software to determine a percentage of the plurality of library vector embeddings matching the plurality of target vector embeddings; and
comparing the percentage to the first threshold to determine that the first threshold is satisfied.”
Bryne et al. teaches, a database or machine learning model can receive a function fingerprint, which can comprise or consist of the output vector. The database (vulnerability repository) or machine learning model can store, compare, and/or classify the function fingerprint (0036). A cosine similarity (threshold) can use used to match (0030). Also see figure 1 and 2. Also see figure 6 (252 and paragraph 0032) (reporting). Also see figure 3 and paragraphs 0044 and 0069.
Alomari teaches, blocks in a respective fingerprint are compared to blocks in a group or cluster using threshold of similarity to determine if the code is the same (0059).
The examiner states that it would have been well known to one of ordinary skill in the art before the effective filing date for the similarity threshold to be a percentage. There are many well know ways to show the amount of similarity between two item and thy can be interchanged to produce similar results and therefore would have been obvious to try.
As per claim 19, Bryne et al. and Alomari further teach, “The method of claim 15, further comprising:
obtaining source code for each library version of a plurality of library versions of the library;
generating a plurality of library version fingerprints from the source code for each library version of the plurality of library versions; and
processing target software using the plurality of library version fingerprints to detect a library version of the library in the target software.
Bryne et al. teaches a binary is disassembled and translated into an intermediate representation and symbolic expressions are extracted. Symbolic execution is performed to generate the fingerprint (0046). A fingerprint of binary functions is produced. An execution component executes the filtered representation of the virtual machine to generate an output vector (0019, 0029). Population component can populate a database, with the output vector. The output vector can be labeled including a function name, library name and/or library version. In the database the output vector can server as a vulnerability fingerprint of the portion of binary code. A machine learning model can search for the fingerprint based on, similarity with another fingerprint or set of fingerprints. The fingerprint can be classified (0030-0032). (0054). A database or machine learning model can receive a function fingerprint, which can comprise or consist of the output vector. The database or machine learning model can store, compare, and/or classify the function fingerprint (0036).
Alomari teaches, Source code is converted into tokens associated with a plurality of blocks of programming statements. Tokens are modified by normalizing at least one value of the plurality of blocks of programming statements. A representation is created which is associated with control flow of a plurality of blocks associated with a respective token. The control flow includes a plurality of possible operational paths associated with the blocks in each of the modified tokens. A digital fingerprint representing a respective operational path associated with the control flow for a given token is generated. Source code within at least one block of a given token is determined and identifiable as being a duplicate of source code stored in a repository by comparing at least one of the generated digital fingerprints and at least on previously generated digital fingerprint (0005).
The examiner states that Bryne et al. teaches the disassembly of binary to generate a fingerprint, while Alomari et al. teaches using source code. This is nothing more than a design choice since both produce similar results and would have been obvious to try before the effective filing date of the invention.
As per claim 20, Bryne et al. and Alomari further teach, “The method of claim 19, wherein generating the plurality of library version fingerprints comprises, for the library version: parsing the source code of the library version to obtain parsed source code; selecting a compiler agnostic portion of the source code; processing the compiler agnostic portion through the vector embedding model to generate a version vector embedding of the library version; and relating, in storage a library version identifier of the library version with the version vector embedding of the library version.
Bryne et al. teaches a binary is disassembled and translated into an intermediate representation and symbolic expressions are extracted. Symbolic execution is performed to generate the fingerprint (0046). A fingerprint of binary functions is produced. An execution component executes the filtered representation of the virtual machine to generate an output vector. The platform-independent intermediate representation can be filtered and the filtered representation is executed to create the output vector to make it compiler independent (0019, 0029). Population component can populate a database, with the output vector. The output vector can be labeled including a function name, library name and/or library version. In the database the output vector can server as a vulnerability fingerprint of the portion of binary code. A machine learning model can search for the fingerprint based on, similarity with another fingerprint or set of fingerprints. The fingerprint can be classified (0030-0032). (0054). A database or machine learning model can receive a function fingerprint, which can comprise or consist of the output vector. The database or machine learning model can store, compare, and/or classify the function fingerprint (0036).
Alomari (US 2020/0218535 A1) teaches, Source code is converted into tokens associated with a plurality of blocks of programming statements. Tokens are modified by normalizing at least one value of the plurality of blocks of programming statements. A representation is created which is associated with control flow of a plurality of blocks associated with a respective token. The control flow includes a plurality of possible operational paths associated with the blocks in each of the modified tokens. A digital fingerprint representing a respective operational path associated with the control flow for a given token is generated. Source code within at least one block of a given token is determined and identifiable as being a duplicate of source code stored in a repository by comparing at least one of the generated digital fingerprints and at least on previously generated digital fingerprint (0005). Also see 0041-0042.
The examiner states that Bryne et al. teaches the disassembly of binary to generate a fingerprint, while Alomari et al. teaches using source code. This is nothing more than a design choice sine both produce similar results and would have been obvious to try before the effective filing date of the invention.
Claims 5 and 12 are rejected under pre-AIA 35 U.S.C. 103(a) as being unpatentable over Bryne et al. (US 2020/0394028 A1), Ji et al. (US 2022/0244953 A1), Alomari (US 2020/0218535 A1), Kumar et al. (US 2021/0374229 A1) and Wu et al. (US 2023/0185568 A1) as applied to claims 1 and 8 above and further in view of Bronevetsky (US 2023/0176838 A1).
As per claim 5, Bryne et al, Alomari, Ji et al. and Wu et al. do not explicit appear to teach, “The method of claim 1, further comprising:
masking a portion of a training execution trace generated from a training binary of a training library to obtain a masked training execution trace having a masked portion; and
training the vector embedding model using the training binary to predict the masked portion.”
Bronevetsky teaches encoding comments into semantic embeddings may strip away syntactic differences between source code snippets and/or edits of source code snippets, enabling more robust comparison so source code edits that appear syntactically different but are in fact related. Various types of machine learning models may be trained and used to perform such encoding (0024). Also see 0031-0033 and 0035. The system may recommend a second edit in response to a first edit (0063).
It would have been obvious to one of ordinary skill in the art before the effective filing date to modify Bryne et al. with Bronevetsky et al. because both teach code comparison. Bryne et al. teaches gather information on different code such as libraries which contain vulnerabilities in order to compare new code do determine vulnerabilities. Bronevetsky et al. teaches a method of comparing code snippets in order to determine a second edit from a first edit. The process of comparing and finding similar code such as matching code to detect errors and vulnerabilities can use a similar type of comparison in order to predict fixes to errors, code completion or suggestion. Once similar code is found using embeddings, the similar code direct one to a recommendation. This is nothing more than a design choice and would have been obvious to try.
As per claim 12, claims 12 contains a similar limitation to claim 5 and is therefore rejected for the same reasons.
Response to Arguments
Applicant's arguments filed 19/12/2025 have been fully considered but are moot due to the amendment. Please see the above rejection further in view of Bryne et al. (US 2020/0394028 A1), Ji et al. (US 2022/0244953 A1), Alomari (US 2020/0218535 A1), Wu et al. (US 2023/0185568 A1) and now Kumar et al. (US 2021/0374229 A1).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARK A GOORAY whose telephone number is (571)270-7805. The examiner can normally be reached Monday - Friday 10:00am - 6:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lewis Bullock can be reached at 571-272-3759. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MARK A GOORAY/ Examiner, Art Unit 2199
/LEWIS A BULLOCK JR/ Supervisory Patent Examiner, Art Unit 2199