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 .
DETAILED ACTION
This action is in response to the application filed on 07/04/2024.
Claims 1-18 are pending.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. CN 2024104549204, filed on 04/16/2024.
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 1-10 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 recites “(e) repeating steps (b) to (d) to obtain a plurality of indicator file identification results for determining a software component identification result of the firmware file” is unclear whether this function can be performed since the claim is unclear whether it has multiple indicator files. Based on the current claim language, there is only a single indicator file, thus for the purpose of examination, the repeating step (e) is most likely for the repeating steps c and d, not b to d.
Claim 2-9 are rejected for depending on claim 1.
Claim limitation 10 has been evaluated under the three-prong test set forth in MPEP § 2181, subsection I, but the result is inconclusive. Thus, it is unclear whether this limitation should be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the “indicator file identification module”, “indicator file extraction module”, and “feature extraction module” lack a structure. The boundaries of this claim limitation are ambiguous; therefore, the claim is indefinite and is rejected under 35 U.S.C. 112(b) or pre-AIA 35 U.S.C. 112, second paragraph.
In response to this rejection, applicant must clarify whether this limitation should be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Mere assertion regarding applicant’s intent to invoke or not invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph is insufficient. Applicant may:
(a) Amend the claim to clearly invoke 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, by reciting “means” or a generic placeholder for means, or by reciting “step.” The “means,” generic placeholder, or “step” must be modified by functional language, and must not be modified by sufficient structure, material, or acts for performing the claimed function;
(b) Present a sufficient showing that 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, should apply because the claim limitation recites a function to be performed and does not recite sufficient structure, material, or acts to perform that function;
(c) Amend the claim to clearly avoid invoking 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, by deleting the function or by reciting sufficient structure, material or acts to perform the recited function; or
(d) Present a sufficient showing that 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, does not apply because the limitation does not recite a function or does recite a function along with sufficient structure, material or acts to perform that function.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: an indicator file extraction module, an indicator file identification module, and a feature extraction module in claim 10.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-18 rejected under 35 U.S.C. 101 because the claimed invention is directed to (an) abstract idea(s) without significantly more.
Regarding claim 1, this claim is within at least one of the four categories of patent eligible subject matter as it is directing to a method claim under Step 1.
However, the limitations “(b) extracting an indicator file”, “(c) extracting features from the indicator file, wherein the features comprise the following information: a hash value; semantic information; control flow graph information; and function-level feature information”, and “(d) comparing the features of the indicator file with a database to derive an indicator file identification result” as drafted, are functions that, under its broadest reasonable interpretation, recite the abstract idea of a mental process. These limitations encompass a human mind carrying out these functions through observation, evaluation judgement and/or opinion, or even with the aid of pen and paper. Thus, this limitation recites and falls within the “Mental Processes” grouping of abstract ideas under Prong 1 Step 2A.
Under Prong 2 Step 2A, the judicial exception is not integrated into a practical application. This claim recites the following additional elements “(a) receiving a firmware file” and “(e) repeating steps (b) to (d) to obtain a plurality of indicator file identification results for determining a software component identification result of the firmware file”. The additional elements “(a) receiving a firmware file” do nothing more than add insignificant extra solution activity to the judicial exception of merely gathering and transmitting data. Further, the additional element “(e) repeating steps (b) to (d) to obtain a plurality of indicator file identification results for determining a software component identification result of the firmware file” fails to meaningfully limit the claim and is at best the equivalent of merely repeating instructions to apply the exception using generic computer, and/or mere computer components, therefore the element is at best the equivalent of merely adding the wors “apply it” to the judicial exception. Accordingly, the additional elements do not integrate the recited judicial exception into a practical application, and the claim is therefore direct to the judicial exception. See MPEP 2106.05(f).
Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above, the limitations “(a) receiving a firmware file” have been identified by the courts as mere data gathering which are well-understood, routine and conventional activity. See MPEP 2106.05(d). Furthermore, the limitation “(e) repeating steps (b) to (d) to obtain a plurality of indicator file identification results for determining a software component identification result of the firmware file” does not require any particular application of the recited evaluation and is at best the equivalent of merely adding the words “apply it’ to the judicial exception. Mere instructions to apply an exception cannot provide an inventive concept. Accordingly, the claim is not patent eligible under 35 U.S.C. 101.
Regarding claims 2, 9, 12-14 recites non-functional descriptive language that does not integrate the judicial exception into a practical application nor amount to significantly more than the judicial exception.
Regarding claim 3-5, the limitations “disassembling…”, “converting…”, “identifying…”, “detecting…”, and “extracting…” recites additional mental processes under Prong 1. Regarding claim 6-7, the limitations “comparing…” and determining when the similarity score is either above or below a threshold recites additional mental processes under Prong 1. Regarding claim 8, the limitation “determining the software component identification result based on the package management file” recites additional mental process under Prong 1.
Claims 10-11, 15-18 are also rejected under the same rational as 1-2, 6-9 for having similar limitations.
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.
Claim(s) 1-2, 5, and 10-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Regev et al. (US 20220237300 A1) hereinafter Regev in view of Carback, III et al. (US 20150363294 A1) hereinafter Carback, III.
Regarding claim 1, Regev discloses
A method of software component identification in an embedded system firmware, the method comprising the steps of: (a) receiving a firmware file; (Regev [0040] and [0058] discloses receiving code for identification, e.g., firmware code/firmware file).
(b) extracting an indicator file from the firmware file; (Regev [0051] and [0086] discloses firmware files uploaded comprise of firmware image with a plurality of different executable portions where the files use several different open-source libraries. The firmware image is decompressed in order to extract each file to analyze to identify an origin of any open-source libraries. As described in the application [0018], an indicator file may be an executable file or library file).
(d) comparing the features of the indicator file with a database to derive an indicator file identification result; and (Regev [0054]-[0055] discloses comparing the code portions to code stored in a code repository looking for matching portions in order to identify the origin of each code library, an associated code library version, or any other information associated with the library. By comparing code, the firmware identifier may identify an origin of a code library or libraries used in the firmware code).
(e) repeating steps (b) to (d) to obtain a plurality of indicator file identification results for determining a software component identification result of the firmware file. (Regev [0066] and [0067] discloses a token comparator comparing one or more generated tokens generated based on firmware code with tokens stored in code repository to identify a matching token or set of matching tokens that may be determined to identify the origin of firmware code. This token comparator may repeat such a search for each token present in the neutralized code in attempting to identify a matching code in the code database, thus showing the steps (b)-(d) being repeated until a matching code is identified).
Regev lacks explicitly
(c) extracting features from the indicator file, wherein the features comprise the following information: a hash value; semantic information; control flow graph information; and function-level feature information;
Carback, III teaches
(c) extracting features from the indicator file, wherein the features comprise the following information: a hash value (Carback, III [0073], [0007]-[0009], and [0076] discloses determining one or more of the meta data artifacts by extracting a string of characters from the software file, including when the software file is in source code format or binary code format. Further, disclosed in Carback [0037] the software files obtained include make files, libraries, documentation files, commit logs, revision histories, etc., where indicated in the specification [0018], library files are referred to as indicator files. The meta data artifacts extracted include hash values, where these artifacts are used to identifying the software file); semantic information (Carback, III [0009] and [0098] discloses artifacts for the software file containing branch semantic and semantic information being extracted from the document artifacts); control flow graph information (Carback, III [0009] discloses control flow graph as apart of the plurality of artifacts); and function-level feature information; (Carback, III [0006], [0047] and [0051] disclose artifacts including function, where information stored consist of function parameters, local variables, or global variables).
It would have been obvious to one of ordinary skill in the art before the effective filing date of claimed invention to have modified Regev to incorporate the teachings of Carback, III to “(c) extracting features from the indicator file, wherein the features comprise the following information: a hash value; semantic information; control flow graph information; and function-level feature information” in order to have more detailed information of the software component, allowing for more accurate matching and identification results.
Regarding claim 2, Regev discloses
The method according to claim 1, wherein the indicator file is an executable file, a library file, or a configuration file. (Regev [0041] and [0086] discloses the indicator file being executable files or library files which are used for matching).
Regarding claim 5, Regev in view of Carback, III discloses
The method according to claim 1, wherein the step (c) further comprises the following steps to extract the semantic information: (c9) extracting a plurality of strings from the indicator file; (Regev [0048] discloses human-readable strings and characters generated by the firmware dissembler that is a translation of a binary code or machine language of the firmware code)
(c10) disassembling the indicator file to generate a disassembled file; (Regev [0027] discloses a firmware disassembler configured to disassemble firmware code obtained from a device to generate assembly code)
(c11) converting the disassembled file into an intermediate representation file; and (Regev [0051]-[0053] discloses converting the disassembled file into an intermediate representation called a code neutralizer)
(c12) extracting a plurality of external library names from the intermediate representation file; wherein the semantic information is obtained according to the plurality of strings and external library names. (Regev [0055], and [0057] discloses neutralized code generated from open-source code libraries, along with an identification of an origin of each code library by a library name, developer, vendor, or designer and receiving an indication of known vulnerabilities for one or more code libraries from an external source. Further, [0048] discloses human-readable strings and characters generated by the firmware dissembler that is a translation of a binary code or machine language of the firmware code).
With regards to claim 10, it is a system claim having similar limitations as cited in claim 1. Thus, claim 10 is also rejected under the same rationale as cited in the rejection of claim 1 above.
With regards to claim 11, it is a system claim having similar limitations as cited in claim 2. Thus, claim 2 is also rejected under the same rationale as cited in the rejection of claim 2 above.
Regarding claim 12, Regev discloses
The system according to claim 10, wherein the indicator file extraction module further extracts a plurality of indicator files and the system further comprises: a software component identification module to determine a software component identification result of the firmware file based on the indicator file identification results of the plurality of indicator files. (Regev [0054]-[0055] discloses comparing neutralized code to code in the code repository, identifying one or more matching cods. The matching codes may be partial or identical matches. Then, based on identifying a matching code, the firmware identifier may identify an origin of the firmware code).
Claim(s) 3-4, 6-7, 9, 13, 15-16, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Regev et al. (US 20220237300 A1) hereinafter Regev in view of Carback, III et al. (US 20150363294 A1) hereinafter Carback, III in further view of Zimmerman (US 20170372068 A1).
Regarding claim 3, Regev in view of Carback, III discloses
The method of claim 1,
(c1) disassembling the indicator file to generate a disassembled file; (Regev [0027] discloses a firmware disassembler configured to disassemble firmware code obtained from a device to generate assembly code)
(c2) converting the disassembled file into an intermediate representation file; (Regev [0051]-[0053] discloses converting the disassembled file into an intermediate representation called a code neutralizer)
(c4) detecting jumps, branches, or returns in the intermediate representation file (Carback, III [0053]-[0055] discloses branch semantics as a static artifact, where the static artifacts are automatically determined from an intermediate representation of the source code files) so as to derive a plurality of nodes (Carback, III [0047] and [0049] discloses each node in the control flow graph), directed edges (Carback, III [0047] discloses edges between nodes are directional and show potential paths in the flow), caller (Carback, III [0058] discloses of a distributed computer system automatically obtaining files from a repository to covert to LLVM IR and determining artifacts for the files. This calling process is done by employing slave machines and Hadoop, which is an open-source software framework for distributed storage/processing) and callee information to form the control flow graph information. (Carback, III [0037]-[0039] discloses the files obtained for a variety of source either public or private, and all revision history, directory files, revision history, commit logs, and software changes)
Regev in view of Carback, III lacks explicitly
c3) identifying each function entry point based on the intermediate representation file; and
Zimmerman teaches
c3) identifying each function entry point based on the intermediate representation file; and (Zimmerman [0093] discloses each function containing function name, size of the function, array of the function relocation virtual address, size, and position. Based on [0023] of the specification, function entry point uses function name as a label, and location representing the function entry point, therefore this reference teaches this limitation by providing both function name and function location).
It would have been obvious to one of ordinary skill in the art before the effective filing date of claimed invention to have modified Regev in view of Carback, III to incorporate the teachings of Zimmerman to “c3) identifying each function entry point based on the intermediate representation file; and” in order to allow each function to be processed, further aiding in identifying the software component more accurately.
Regarding claim 4, Regev in view of Carback, III discloses
The method according to claim 1, wherein the step (c) further comprises the following steps to extract the function-level feature information: (c5) disassembling the indicator file to generate a disassembled file; (Regev [0048] discloses a firmware disassembler to disassemble firmware code to generate assembly code. This would in turn disassemble the indicator file).
(c6) converting the disassembled file into an intermediate representation file; (Regev [0051]-[0053] discloses turning the decompiled source code into a neutralized code, acting as an intermediate language that removes certain languages that may be specific to a computing architecture or compiler)
Regev in view of Carback, III lacks explicitly
(c7) extracting a plurality of function names from the intermediate representation file; and
(c8) extracting a plurality of readable strings from the intermediate representation file; wherein the function-level feature information is obtained according to the plurality of function names and readable strings.
Zimmerman teaches
(c7) extracting a plurality of function names from the intermediate representation file; and (Zimmerman [0093] discloses each function extracted consists of compiler name, target type, and function name).
(c8) extracting a plurality of readable strings from the intermediate representation file; wherein the function-level feature information is obtained according to the plurality of function names and readable strings. (Zimmerman [0012], [0088], [0093], and [0097]-[0100] discloses using strings either in source code format, and thus readable, or binary code format, and function names, along with size of function, target type, compiler name, array of function size and position and hash, thus creating function-level feature information. When the name of the function is unknown, a calculated has function is matched to the function hash in order to identify its type and corresponding function information).
It would have been obvious to one of ordinary skill in the art before the effective filing date of claimed invention to have modified Regev in view of Carback, III to incorporate the teachings of Zimmerman to “(c8) extracting a plurality of readable strings from the intermediate representation file; wherein the function-level feature information is obtained according to the plurality of function names and readable strings” in order to further obtain information necessary to accurately/effectively identify the software component.
Regarding claim 6, Regev in view of Carback, III discloses
The method of claim 1
(d2) comparing the semantic information of the indicator file with the database to obtain a plurality of candidate indicator files; (Carback, III [0044]-[0045], [0021], and [0102]-[0103] discloses semantic information being a static artifact, where the plurality of artifacts are compared to the plurality of reference artifacts, and identify the software file by identifying the reference having the plurality of reference artifacts the match the plurality of artifacts. Further, artifacts compared increase the confidence level based on matching, and in combination with Regev [0069] we see plurality of possible matching does using the most similar matching codes, thus showing obtaining candidate indicator files/possible matches).
calculating a similarity score and a confidence score between the indicator file and the plurality of candidate indicator files; and (Regev [0068]- [0071] discloses similarity being identified based on matching all of the tokens of code and code stored in code repository by using a minimum number or percentage of matching tokens, thus a similarity score. Then, identified are the top most similar matching codes based on those scores. Then, a confidence score is generated that comprises a measure of confidence that an identification of an origin of the firmware code is accurate).
(d4) when the similarity score of the candidate indicator file with the highest similarity and confidence score is greater than or equal to a first threshold, and the confidence score is greater than or equal to a second threshold, selecting the candidate indicator file as the indicator file identification result. (Regev [0070]-[0072] discloses that after the top most similar matching code is given a high confidence score, the code analyzer UI indicates, via through user interface elements, of the code identified with the high confidence score and the portions of the code matched or did not match as well as the next closest match in the code repository).
Regev in view of Carback, III lacks explicitly
wherein the step (d) further comprises: (d1) comparing the hash value of the indicator file with the database, if the hash value is found in the database, the indicator file with the same hash value found in the database is designated as the indicator file identification result
(d3) comparing the control flow graph information and the function-level feature information of the indicator file with the plurality of candidate indicator files,
Zimmerman teaches
wherein the step (d) further comprises: (d1) comparing the hash value of the indicator file with the database, if the hash value is found in the database, the indicator file with the same hash value found in the database is designated as the indicator file identification result; (Zimmerman [0013] – [0023] discloses matching a hash value from the functions to a calculated hash result stored in the database and upon finding a match, determining that the function, library, or object has been identified)
(d3) comparing the control flow graph information and the function-level feature information of the indicator file with the plurality of candidate indicator files, (Zimmerman [0093] discloses the function-level feature information. While Zimmerman lacks control flow graph information, in combination with Carback, III [0045]-[0046] discloses control flow graph as a static artifact that will be used in the comparison in order to determine that plurality of candidate indicator files, i.e. the potential code matches).
It would have been obvious to one of ordinary skill in the art before the effective filing date of claimed invention to have modified Regev in view of Carback, III to incorporate the teachings of Zimmerman to “wherein the step (d) further comprises: (d1) comparing the hash value of the indicator file with the database, if the hash value is found in the database, the indicator file with the same hash value found in the database is designated as the indicator file identification result;” and “(d3) comparing the control flow graph information and the function-level feature information of the indicator file with the plurality of candidate indicator files,” in order to match all the features collected from the software component to the database, thus increasing the accuracy of the identification.
Regarding claim 7, Regev in view of Carback, III in further view of Zimmerman discloses,
The method according to claim 6, the method further comprises: when the similarity score of the candidate indicator file with the highest similarity and confidence score is less than the first threshold, or the confidence score is less than the second threshold, adding a new entry of indicator file data to the database based on the features of the indicator file extracted in step (c). (Carback, III [0042], [0059], and [0102]-[0103] discloses software files and the intermediate representation can be stored unless the code is already stored in the database, thus choosing not to store the file again. This indicates that if there is not a match between the received file and the database, i.e., indicating that either of the thresholds not being met, that the file is then added to the database, otherwise if there was a match, i.e., indicating the thresholds are met, the file would not be added to the database to avoid duplication. The artifacts are given more or less weight and evaluating weighting in the identification process can include expressing an identification threshold such as in percentages of matching artifacts).
Regarding claim 9, Regev in view of Carback, III discloses
The method of claim 1,
Regev in view of Carback, III lacks explicitly
wherein the firmware file is a Linux-based embedded system firmware file.
Zimmerman teaches
wherein the firmware file is a Linux-based embedded system firmware file. (Zimmerman [0025] discloses the executable file may be executable and linkable format in Linux OS, where the executable code may be embedded in a data file).
It would have been obvious to one of ordinary skill in the art before the effective filing date of claimed invention to have modified Regev in view of Carback, III to incorporate the teachings of Zimmerman to “wherein the firmware file is a Linux-based embedded system firmware file” in order to have better security and customization.
With regards to claim 13, it is a system claim having similar limitations as cited in claim 3-5. Thus, claim 13 is also rejected under the same rationale as cited in the rejection of claim 3-5 above. Additionally, the hash value calculation is disclosed in Zimmerman [0014] – [0023] and [0095]-[0096], where the hash is calculated and compared to the hash results in the database.
With regards to claim 15, it is a system claim having similar limitations as cited in claim 6. Thus, claim 15 is also rejected under the same rationale as cited in the rejection of claim 6 above.
With regards to claim 16, it is a system claim having similar limitations as cited in claim 7. Thus, claim 16 is also rejected under the same rationale as cited in the rejection of claim 7 above.
With regards to claim 18, it is a system claim having similar limitations as cited in claim 9. Thus, claim 18 is also rejected under the same rationale as cited in the rejection of claim 9 above.
Claim(s) 8 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Regev et al. (US 20220237300 A1) hereinafter Regev in view of Carback, III et al. (US 20150363294 A1) hereinafter Carback, III in further view of Kurtakov (US 8495614 B2).
Regarding claim 8, Regev in view of Carback, III discloses
Method of claim 1
Regev in view of Carback, III lacks explicitly
Extracting a package management file from the firmware file and determining the software component identification result based on the package management file.
Kurtakov teaches
Extracting a package management file from the firmware file and determining the software component identification result based on the package management file. (Kurtakov column 4, lines 1-16 and column 5, lines 15-45 discloses extracting necessary files in order to identify software package, and information extract such as identification description and configuration information is used to create a package manager spec file).
It would have been obvious to one of ordinary skill in the art before the effective filing date of claimed invention to have modified Regev in view of Carback, III to incorporate the teachings of Zurtakov to “Extracting a package management file from the firmware file and determining the software component identification result based on the package management file” in order to provide the system more accurate information to be used in the identification mechanism.
With regards to claim 17, it is a system claim having similar limitations as cited in claim 8. Thus, claim 17 is also rejected under the same rationale as cited in the rejection of claim 8 above.
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Regev et al. (US 20220237300 A1) hereinafter Regev in view of Carback, III et al. (US 20150363294 A1) hereinafter Carback, III in further view of Zimmerman (US 20170372068 A1) in further view of Vangala et al. (US 20140013304 A1) hereinafter Vangala.
Regarding Claim 14, Regev in view of Carback, III in further view of Zimmerman disclose
The system according to claim 13, wherein the function-level feature information and control flow graph information extraction module further comprises: an intermediate representation conversion module to perform intermediate representation conversion on the disassembled file, generate an intermediate representation file; (See claim 3 rational above)
a symbolic information extraction module to extract symbolic information comprising function names, external library names, and variable names from the intermediate representation file; (See claim 3-5 rational above)
a function entry point extraction module to identify the function entry points in the intermediate representation file based on the output of the symbolic information extraction module; (See claim 3 rational above)
a control flow graph information extraction module to derive control flow graph information of the indicator file based on the function entry points, wherein the control flow graph information comprises nodes, directed edges, caller, and callee information; (See claim 3 rational above)
and a function-level feature information extraction module to generate function-level feature information of the indicator file based on the readable strings extracted from a function and the function names output by the symbolic information extraction module. (See claim 4 rational)
Regev in view of Carback, III in further view of Zimmerman lacks explicitly
a function prologue extraction module to detect function prologue
Vangala teaches
a function prologue extraction module to detect function prologue (Vangala [0035] discloses function having a prologue to describe the function, thus the analytics platform may extract artifacts by using the prologue).
It would have been obvious to one of ordinary skill in the art before the effective filing date of claimed invention to have modified Regev in view of Carback, III in further view of Zimmerman to incorporate the teachings of Vangala to “a function prologue extraction module to detect function prologue” in order to more accurately describe the function, allowing for easier identification and comparison.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTOPHER J SALLEY whose telephone number is (571)272-6355. The examiner can normally be reached Mon-Fri, 7:30am-5pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chat Do can be reached at (571) 272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHRISTOPHER J SALLEY/Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193
Prosecution Insights