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 .
Response to Arguments
Applicant’s arguments, see page 9, filed 07/10/2026, with respect to the previous rejection of claims 1-16 and 18-21 under 35 U.S.C. § 112(b) have been fully considered. The previous rejection of claims 1-16 and 18-21 under 35 U.S.C. § 112(b) have been withdrawn in response to the limitations being removed.
Applicant's arguments, see pages 9-12, filed 07/10/2026, with respect to the rejections of claims 1-16 and 18-21 under 35 U.S.C. § 112(a) written description have been fully considered but they are not persuasive.
Applicant first argues that the limitation “applying code obfuscation techniques to at least one of the anomalous blocks of code to thereby create secured computer code” in independent claims 1, 9, and 18 is properly supported by paragraph 3 and 48 of the published application.
The Examiner respectfully disagrees.
Applicant again reminded that support should be found from the originally filed disclosure instead of the published patent application.
Although the specification discloses applying “code security techniques” to anomalous blocks, that disclosure is generic and result-oriented. The claim, by contrast, recites a broad genus of specific obfuscation techniques, including instruction pattern transformation, renaming methods or variables, control flow obfuscation, string encryption, dummy code insertion, binary linking or merging, and opaque predicate insertion. The specification does not adequately describe this claimed genus in a manner commensurate with the full scope of the claim, and therefore does not reasonably convey possession of the claimed subject matter.
Although the specification states that anomalous blocks may be selected and that code security techniques may then be applied to create secured computer code, that disclosure is stated only at a high level and in generic functional terms. The specification does not provide a technical description of how the recited obfuscation techniques are selected or implemented. Rather, the disclosure describes the desired result of applying security techniques to code identified as anomalous, without adequately explaining the manner in which the claimed obfuscation operations are achieved.
The relevant disclosure is therefore result-oriented: it identifies that code may be protected after anomalous portions are found, but it does not provide sufficient technical details to support the present claim language that expressly recites a broad genus of obfuscation techniques. The written-description requirement is not satisfied by a mere statement of intended outcome or by generic language that code security techniques may be applied.
Applicant’s disclosure of a general concept of “code security techniques” is not sufficient to support the claim’s broad genus of obfuscation techniques. A specification must describe the invention, not merely state a desired result or define the outer boundary of a concept in generic terms. The disclosure does not provide representative species, structural details, or technical implementation guidance sufficient to support that claimed genus. Accordingly, even though the specification discloses the general concept of applying security techniques to anomalous code blocks, the disclosure is not commensurate with the full breadth of the claim. The claim recites a specific genus of obfuscation techniques, but the specification only provides a generic and result-oriented description of applying security techniques. This does not reasonably convey possession of the full claimed subject matter.
As in the Non-Final Rejection mailed 04/10/2026, code security technique applying module 218, is a black-box. Paragraph [0048] of the PGPUB as relied upon by Applicant discloses “Code security technique applying module 218 may be configured to apply code security techniques to at least one of the anomalous blocks of code to thereby create secured computer code”. There is no disclosure of how the module is capable of being configured so that it applied code security techniques to achieve the desired result of creating secured computer code. Applicant alleges that there is proper support for claim language, because “the specification … identifies module 218 as the actor and identifies, by name, the industry-standard obfuscation techniques that the module applies”.
The Examiner disagrees as code security technique applying module 218 is depicted as a rectangular box within Figure 2, and paragraphs [0058-0059] of the originally filed disclosure explain that the said module(s) found in the disclosure “may refer to any component or set of components that perform the functionality attributed to the module. This may include one or more physical processors during execution of processor readable instructions, the processor readable instructions, circuitry, hardware, storage media, or any other components”.
As in MPEP 2161.01 I. “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved. For software, this can occur when the algorithm or steps/procedure for performing the computer function are not explained at all or are not explained in sufficient detail (simply restating the function recited in the claim is not necessarily sufficient). In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed”. Stating that a black box implementation can be configured to perform the function of the claims is not a properly disclosed algorithm or steps/procedure taken to perform the function recited in the claim, and there is not any description that supports a conclusion of possession, and one of ordinary skill in the art, considering the totality of the originally filed disclosure, would not understand how the inventor intended to achieve the desired result. Applicant’s argument that the disclosure does not have to provide haec verba support, and that the Examiner is allegedly incorrect for requiring “line-by-line algorithmic pseudocode” for each named technique are unpersuasive as the Examiner has never alleged a requirement for haec verba support or “line-by-line algorithmic pseudocode” within the prosecution record.
Applicant then argues that the limitation “determine effectiveness of the code obfuscation techniques by comparing anomaly measures of the blocks of code before and after applying the code obfuscation techniques” has proper support in the originally filed disclosure.
The Examiner respectfully disagrees.
Applicant relies upon paragraph [0063] of the published application for written description support for the claim limitation, and specifically alleges that the paragraph discloses “the operation performed after obfuscation”, “the comparison performed”, and “three concrete quantitative metrics used to evaluate effectiveness”. Applicant has not refuted the previous arguments as presented in the Non-Final Rejection mailed 04/10/2026 aside from asserting that the level of description in [0063] conveys possession without any further evidence. Applicant alleges paragraph [0063] contains concrete qualitative metrics, it does not. Mere nominal recitation of maximum score, “fewer code blocks exceeding the threshold, and a lower standard deviation between blocks of code”, absent any disclosure whatsoever how these metrics are obtained, does not constitute “concrete qualitative metrics”. Applicant alleges that paragraph [0063] of the PGPUB describes a concrete procedure, the Examiner respectfully disagrees as it does not disclose how the inventor intended to achieve the intended function of “determine effectiveness of the code obfuscation techniques”. Paragraph [0063] merely describes that the encoding, modeling, and ranking can be performed on code again after protection, but there is no disclosure of the inventor intended to actually achieve the scoring, as the scoring itself is based upon an unsupported anomaly measure of which the inventor absolutely does not disclose how the anomaly measuring algorithm obtains any scores. There is no explanation of how the inventor intended to score/threshold the obfuscation, other than acquiring and utilizing a supposed “anomaly detection algorithm to the blocks of code”, which is only described in [0032] of the originally filed disclosure to be “building one or more unsupervised learning models for determining anomalies of the computer code. The models may include an isolation forest model”, while not even disclosing how to configure such a model such that it preferably scores obfuscations. There is no disclosure of how the exemplary percentage scores were derived, and there is no disclosure of how the claimed invention does any effectiveness measuring comparing the claimed “anomaly measures” or reduction thereof, outside of a mere recitation that it can be done using “an anomaly detection algorithm” (which has already been described as unsupported how the algorithm functions).
Applicant then argues that the limitation “determine a corresponding ranking of at least some of the blocks of code with an anomaly measure by applying an anomaly detection algorithm to the blocks of code” has proper support in the originally filed disclosure.
The Examiner respectfully disagrees.
Applicant relies upon paragraphs [0046], [0017-0018], and [0058] of the published application for support for the limitation. Paragraph [0046] fails to adequately support the claim limitation at issue as it fails to disclose how the inventor intended to achieve the desired results of determining a corresponding ranking according to an undisclosed anomaly metric by applying a “well known” supervised or unsupervised model without any further configuration of the said model being disclosed whatsoever, nor how the black-box module “Ranking determination module 214 may be configured to determine a relative corresponding ranking of at least some of the blocks of code”. There is no concrete “algorithmic embodiment” disclosed in the paragraph, as it merely recites that determining the ranking may include building one or more unsupervised learning models “for determining anomalies of the computer code”, without disclosing how such a preferred model is built nor how such a preferred model achieves the anomaly detection algorithm, measure, and ranking. Paragraphs [0017-0018] only make the admission that “various anomaly detection methods are well known and are generally classified as either supervised of unsupervised anomaly detection techniques”, lists examples of supervised and unsupervised machine learning models in name only, and names isolation forest models by name; all while not at all disclosing how the models are preferably configured to apply an anomaly detection algorithm, nor how to determine a corresponding ranking with an anomaly measure using the said algorithm as claimed. Lastly, paragraph [0058] of the PGPUB merely states that the model (the “new and novel unsupervised learning model” recited in paragraph [0057] of the PGPUB which is utterly not disclosed) “can be used to assign a score to each code block” which still does not disclose how the rankings are achieved because the determination of the score is not disclosed. There is no ranking operation as Applicant alleges, as the paragraph only recites that the model “can be used”. It is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. See, e.g., Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681-683, 114 USPQ2d 1349, 1356, 1357 (Fed. Cir. 2015).
Applicant lastly argues that the limitation “parsing of the code based on the format of the computer code” has proper support in the originally filed disclosure.
The Examiner respectfully disagrees.
The written description rejection at issue was made because the specification, taken as a whole, lacks any detail or implementation capable of parsing code of a variety of different computer code formats. The critical inquiry is whether the disclosure of the application relied upon reasonably conveys to those skilled in the art that the inventor had possession of the claimed subject matter as of the filing date. One of ordinary skill in the art, reading the originally filed disclosure, would conclude that it is more likely than not that the inventor is not in possession of such a custom parser that can in an arbitrary code format, and parse the arbitrary input code into the preferable format required by the claimed invention. Applicant points to paragraph [0028] of the PGPUB which states in full, “The encoding phase can convert code (e.g., a function) into a numerical representation that is language agnostic. The representation is not necessarily an encoding of the code functionality, but of the code properties, for example the number of conditional instructions. While the output representation can be independent of the input format, the encoding method itself is likely not independent of the input format. Every supported input format (e.g., source code of a specific language, or an intermediate representation such as LLVM IR) can have a corresponding encoding module unique to that format. In some cases, the encoding method could be trivial, simply searching within a file. In other cases, it can be more complex, such as including a custom parser based on the grammar of the input format”. Mere recitation of using a custom parser is insufficient to demonstrate possession of such a custom parser. It is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. See, e.g., Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681-683, 114 USPQ2d 1349, 1356, 1357 (Fed. Cir. 2015). The claim is drawn to every conceivable way of parsing the code based on the format of the computer code, without disclosing how the inventor achieved such a method of parsing every computer code input format. Applicant’s admission that “Selecting between simple text search and grammar-based parsing based on the code format is a routine choice within the skill of the art” is unpersuasive as this admission does not address how the claimed invention is capable of being configured to perform every conceivable way of parsing the code based on the format of the computer code. Applicant then relies upon paragraph [0044] of the PGPUB, which states “Computer code converting module 212 may be configured to convert the computer code into a numeric description of characteristics of the code. The converting may include parsing of the code based on the format of the computer code” while not disclosing how the module may be preferably configured to achieve such a parsing based on the format of the computer code.
Therefore, the written description rejections are maintained.
Applicant's arguments, see pages 12-15, filed 07/10/2026, with respect to the rejections of claims 1-16 and 18-21 under 35 U.S.C. § 103 have been fully considered but they are not persuasive.
Applicant first paraphrases the independent claims and then alleges that the combination of the previously presented Byrne, Desai, and Nicolson references fail to teach or suggest each of the recited elements.
Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references.
Applicant then argues that “Byrne is not directed to structural anomaly analysis of code… Byrne does not extract and characterize structural properties of individual functions. Byrne's "characteristics" are execution-derived, not structural: they capture what the code does when run on a virtual machine, not what the code looks like in terms of enumerated static properties”.
The Examiner respectfully disagrees.
The amended claims only require “partition computer code into blocks of code”, which is clearly met by Byrne disclosing at least in paragraph [0032] that the function identifier can divide the code into individual labelled functions; and the claims only require that “convert the blocks of code into a numeric description of characteristics of the code wherein the characteristics include at least one of: length of a function name, number of lines in a function, number of operations in a function body, number of parameters in a function signature, number of unique symbols, number of variables, or number of unique functions referenced by a function” which is clearly met by Byrne paragraph [0034] explicitly disclosing that the code can be divided into individual labeled functions. Applicant’s argument that “Byrne does not extract and characterize structural properties of individual functions” is wholly unpersuasive as this is not required by the amended claims. The claim only requires that the blocks of code be converted into a “numeric description of characteristics of the code” wherein the characteristic include at least one of length of a function name, number of lines, number of operations, number of parameters, number of symbols/variables/unique functions referenced. The claims make no distinction as Applicant attempts to argue “Byrne’s ‘characteristics’ are execution-derived, not structural” as this distinction is not required by the claims, nor does any such distinction appear in the originally filed disclosure, therefore Byrne disclosing at least “The function identifier 216 determines function bounds within the portion of binary code 130” (function bounds renders obvious at least number of lines in a function Byrne [0032]); “The function identifier 216 can receive the portion of binary code 130 and divide it into individual, labeled functions. For example, the function identifier 216 can divide the portion of binary code 130 into individual, labeled functions using metadata provided with the portion of binary code 130 and/or data provided by an operator. The function identifier 216 can determine function bounds. The function identifier 216 can utilize a disassembler component 152 to disassemble the portion of binary code 130 into a higher-level (than binary) representation, for example, assembly code. The function identifier 216 can utilize a translator component 154 to translate the assembly code into a platform-independent intermediate representation and produce a platform-independent intermediate representation function 218” (Byrne [0034]), and “The function identifier 216 can receive the portion of binary code 130 determine the function bounds, and output at least one individual function 318. The at least one individual function 318 can be in assembly language, as the function identifier 216 can utilize a disassembler component 152 to provide a higher-level (than binary) representation. The function identifier 216 can utilize metadata from the portion of binary code 130. The function identifier 216 can determine function bounds in a stripped binary by isolating basic blocks of binary code, eliminating function calls between nodes, and following the control flow (ignoring direction) between the basic blocks, thereby determining the basic blocks that compose an individual function” (Byrne [0040]).
Applicant next disparages the Desai reference, alleges that Desai’s anomaly detection is “inter-source”, alleges that the claims recite “intra-program anomaly detection—the unsupervised algorithm”, and that “(i) applying anomaly detection to blocks of code within a single program; (ii) treating code blocks as the units over which anomaly analysis is performed, nor (iii) intra- program comparison at all”.
The Examiner respectfully disagrees.
The amended claims recite in part, “determine a corresponding ranking of at least some of the blocks of code with an anomaly measure by applying an anomaly detection algorithm to the blocks of code, wherein the anomaly detection algorithm comprises an unsupervised algorithm that computes how anomalous each block of code is relative to other blocks of code within the computer code, and wherein the anomaly measure indicates a statistical deviation of each block of code from other blocks of code in the computer code; select anomalous blocks of the blocks of code by applying a threshold to the rankings”. The claims do not recite “intra-program anomaly detection”, “applying anomaly detection to blocks of code within a single program”, or “intra-program comparison” as argued. Applicant’s argument that the claims “recite a specific operation-computing an anomaly measure that reflects statistical deviation of each block of code relative to other blocks within the same computer code” as there is no specific operation-computing recited in the claims. Once more, the anomaly detection algorithm contained within the amended claims merely comprises a generically recited unsupervised algorithm which suffers from pervasive written description issues as of the current record. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993).
The claims only require ranking of a least some of the blocks of code by applying an anomaly detection algorithm comprising a generically recited unsupervised algorithm, the said anomaly detection algorithm computes how anomalous each block of code is relative to other blocks of code within the computer code, the claim then states “wherein the anomaly measure indicates a statistical deviation of each block of code from other blocks of code in the computer code” which comprises a mere recitation of the definition of an anomaly as an anomaly is something that is “inconsistent with or deviating from what is usual, normal, or expected” according to its plain meaning, and lastly the claim requires selecting anomalous blocks of the blocks of code by applying a threshold to the rankings. Desai, in combination with Byrne and Nicolson, teaches these limitations. Desai at Figs. 1A-1C teaches using anomaly detection models, paragraph [0046] explicitly teaches outputting an anomaly score “the score may identify a likelihood that the utility usage data (e.g., for a particular building) includes an anomaly, includes a particular type of anomaly, and/or the like”, Desai teaches at least in paragraph [0047] “the anomaly detection platform may determine a priority of possible anomalies relative to each other based on relative values of the scores” which meets the broadest reasonable interpretation of the determining a corresponding ranking. Desai teaches at least in [0043-0044] the claimed unsupervised algorithm by teaching an isolation forest model utilizing decision trees during training to output “a classification of whether the utility usage data includes an anomaly, a classification of a type of anomaly included in the utility usage data, and/or the like”. Desai further teaches at least in paragraph [0047] applying a threshold to the rankings “the anomaly detection platform may determine that a possible anomaly is present in the utility usage data when a score satisfies a threshold. For example, the anomaly detection platform may determine that the score satisfies a threshold, and may determine that a possible anomaly is present in the utility usage data based on the score satisfying the threshold”. Therefore, the combination of Byrne, Desai, and Nicolson teaches the claim limitations at issue as Desai teaches at least applying an anomaly detection algorithm to data, wherein the anomaly detection algorithm of Desai includes at least an isolation forest model which is an unsupervised algorithm, and the Desai reference further teaches applying a threshold to the anomaly scores.
Further, Applicant’s own originally filed disclosure admits in paragraph [0004] of the originally filed disclosure “it is known to attempt to focus the application of obfuscation techniques on the most security sensitive portions of the code”, in [0017] “Various anomaly detection methods are well known and are generally classified as either supervised of unsupervised anomaly detection techniques”, in [0018] “One known unsupervised method of anomaly detection, known as ‘isolation forest’, identifies anomalies by isolating outliers in the data… Disclosed implementations can use isolation forest and other known anomaly detection algorithms”, and in [0063] “As noted above, the phases of encoding, modelling, ranking and selection can fit within conventional systems for code protection”. Desai teaches explicitly these “well known” anomaly detection method of “unsupervised anomaly detection techniques”. Desai explicitly recites some motivations for one of ordinary skill in the art to combine and utilize the teachings of the reference “using the anomaly detection platform to process the utility usage data in this manner provides accurate identification of possible anomalies in the utility usage data. Further, using the anomaly detection platform in this manner conserves computing resources that would otherwise be wasted using conventional computing resources (e.g., that would be wasted as a result of crashes, freezes, and/or the like of the conventional computing resources). Further, by providing a tool that can be used to process utility usage data in a new and efficient manner, the anomaly detection platform provides a new tool for anomaly detection. Further, in this way, the anomaly detection platform removes human subjectivity and waste from anomaly detection, and may improve speed and efficiency of the process for anomaly detection and conserve computing resources (e.g., processor resources, memory resources, and/or the like)” (Desai [0011-0012]).
Applicant then disparages the Nicolson reference by alleging that the Nicolson reference does not teach the missing claim elements, that the claims recite a structural effectiveness measurement, nothing in Nicolson describes using an anomaly detection algorithm or using the same intra-program anomaly detection algorithm both to select blocks for obfuscation and to measure whether obfuscation was effective.
The Examiner respectfully disagrees.
The Examiner respectfully notes that the previously presented combination relied upon the Desai reference for anomaly detection, and the claimed anomaly measures suffer from written description issues as there is no disclosure regarding how the inventor intended to achieve “determine a corresponding ranking of at least some of the blocks of code with an anomaly measure by applying an anomaly detection algorithm to the blocks of code” in the first place, and therefore Nicolson utilizing before and after comparisons renders obvious the before and after effectiveness measurement the claimed invention takes in comparison. The Examiner respectfully notes that the claim does not require a “structural effectiveness measurement” as argued, the claims only require a determination of effectiveness of the code obfuscation techniques by comparing anomaly measures (wholly unsupported under § 112(a)) before and after applying techniques, and Nicolson explicitly teaches this before-and-after comparison (“Therefore, there is an unmet need for, and it would be highly useful to have, a system and method that can evaluate the quality of an obfuscation, or more specifically, a control flow graph obfuscation that replaces original code with obfuscated code that implements a more complex control flow, containing dummy code (that is, code that is never executed), fake-robust dummy code (code that is never executed but nonetheless appears to be valid), and clones of active code with different obfuscations, then feedback to the obfuscation process the results of this evaluation to enable the obfuscation process to produce more suitable results. The design of such a feedback system should be performed in a generic manner so that can be applied to any suitable existing or new obfuscation technique” Nicolson [0041]).
Applicant lastly argues against the motivation to combine the previously presented combination of the Byrne, Desai, and Nicolson references, summarizes the references, and that “none of these references teaches, suggests, or even hints that structural properties of individual functions within a single program… can be treated as an anomaly-detection input signal to identify security- relevant obfuscation targets, or that the same anomaly signal can be re-measured after obfuscation to determine effectiveness. Absent this recognition in the art, the proposed combination is available only through impermissible hindsight reconstruction”.
The Examiner respectfully disagrees.
As in MPEP 2141, "A person of ordinary skill in the art is also a person of ordinary creativity, not an automaton." KSR, 550 U.S. at 421, 82 USPQ2d at 1397. "[I]n many cases a person of ordinary skill will be able to fit the teachings of multiple patents together like pieces of a puzzle." Id. at 420, 82 USPQ2d at 1397. Office personnel may also take into account "the inferences and creative steps that a person of ordinary skill in the art would employ." Id. at 418, 82 USPQ2d at 1396. Applicant’s argument that “the combination would not arrive at the claimed integrated pipeline” amounts to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references, and there is no “integrated pipeline” claimed as argued. In response to applicant’s argument that the examiner’s conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant’s disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971). Here, the Byrne reference teaches at least code partitioning and conversion, and a person having ordinary skill in the art would be motivated to combine the Byrne reference with the anomaly score assignment/threshold measuring of Desai for at least the explicit teachings of the Desai reference determining a priority of possible anomalies relative to each other based on relative values of the scores (Desai [0047]). One of ordinary skill in the art would be further motivated to combine the Byrne and Desai references further with the Nicolson reference for at least the teachings of Nicolson describing an unmet need for a system and method that can evaluate the quality of an obfuscation that replaces original code with obfuscated code, then feedback to the obfuscation process the results of this evaluation to enable the obfuscation process to produce more suitable results; and have such a feedback system be performed in a generic manner so that can be applied to any suitable existing or new obfuscation technique (Nicolson [0041]).
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-16 and 18-21 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.
Independent claims 1, 9, and 18 recite the limitation “applying code obfuscation techniques to at least one of the anomalous blocks of code to thereby create secured computer code, wherein the code obfuscation techniques comprise at least one of instruction pattern transformation, renaming of methods or variables, control flow obfuscation, string encryption, dummy code insertion, binary linking or merging, or opaque predicate insertion” which is new matter and is rejected on the ground that it recites elements without support in the original disclosure. The specification is silent with regard to how the claimed invention applies code obfuscation techniques, to anomalous blocks of code …” wherein the techniques comprise at least one of...” the listed as claimed. It only recites, as the applicant alleges, “industry-standard” i.e. takes as “well-known code obfuscation techniques” applied to executable software code. There is no disclosure regarding the claimed invention applying any of these “industry-standard” either using one and much less how more than one of such techniques “at least one of” are implemented, since the specification merely and simply provide as applicant admitted in the remarks, “verbatim” claim functional language that the module is supposed to be capable of “may be configured to apply” (see page 9 of remarks referencing paragraph [0048] of what appears to correspond to not the originally filed specification but to the published application). As noted, the originally filed disclosure merely discloses “Code security technique applying module 218 may be configured to apply code security techniques to at least one of the anomalous blocks of code to thereby create secured computer code”. There is no disclosure of how the module is capable of being configured so that it applies code security techniques to achieve the desired result of creating secured computer code, nor how such at least one technique is applied to the blocks, hence are implemented. Furthermore, to Applicant’s assertion “the claim recites the same enumerated techniques”, indeed the claim includes the scope of applying multiple code obfuscation techniques as the claim recites “applying code obfuscation techniques” plural, whereas the originally filed disclosure is silent with regard to how the claimed invention applies code obfuscation to anomalous blocks of code.
As in MPEP 2161.01 I. “original claims may lack written description when the claims define the invention in functional language specifying a desired result but the specification does not sufficiently describe how the function is performed or the result is achieved. For software, this can occur when the algorithm or steps/procedure for performing the computer function are not explained at all or are not explained in sufficient detail (simply restating the function recited in the claim is not necessarily sufficient). In other words, the algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed”. It is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. See, e.g., Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681-683, 114 USPQ2d 1349, 1356, 1357 (Fed. Cir. 2015).
Independent claim 1 recites the limitation “determine effectiveness of the code obfuscation techniques by comparing anomaly measures of the blocks of code before and after applying the code obfuscation techniques” There is no support in the disclosure regarding how the inventor intended to perform these various claimed functionalities. The algorithm or steps/procedures for these claimed functions is not explained at all or is not explained in sufficient detail (simply restating the function reciting in the claim is not necessarily sufficient) so that one of ordinary skill in the art would recognize that the applicant had possession of the claimed invention.
The limitations in question do not satisfy the written description requirement under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph. The specification does not describe the limitation in sufficient detail so that one of ordinary skill in the art would recognize that the applicant had possession of the claimed invention.
In MPEP 2161.01, "computer-implemented functional claim language must still be evaluated for sufficient disclosure under the written description". And MPEP 2161.01(I) "generic claim language in the original disclosure does not satisfy the written description requirement if it fails to support the scope of the genus claimed." For computer-implemented inventions, the determination of the sufficiency of disclosure will require an inquiry into the sufficiency of both the disclosed hardware and the disclosed software due to the interrelationship and interdependence of computer hardware and software. The critical inquiry is whether the disclosure of the application relied upon reasonably conveys to those skilled in the art that the inventor had possession of the claimed subject matter as of the filing date.
As in MPEP 2161.01 (I), "The description requirement of the patent statute requires a description of an invention, not an indication of a result that one might achieve if one made that invention." It is not enough that one skilled in the art could write a program to achieve the claimed function because the specification must explain how the inventor intends to achieve the claimed function to satisfy the written description requirement. See, e.g., Vasudevan Software, Inc. v. MicroStrategy, Inc., 782 F.3d 671, 681-683, 114 USPQ2d 1349, 1356, 1357 (Fed. Cir. 2015).
AS in MPEP 2161.01 “For instance, generic claim language in the original disclosure does not satisfy the written description requirement if it fails to support the scope of the genus claimed. Ariad, 598 F.3d at 1349-50, 94 USPQ2d at 1171 ("[A]n adequate written description of a claimed genus requires more than a generic statement of an invention’s boundaries.") (citing Eli Lilly, 119 F.3d at 1568, 43 USPQ2d at 1405-06); Enzo Biochem, Inc. v. Gen-Probe, Inc., 323 F.3d 956, 968, 63 USPQ2d 1609, 1616 (Fed. Cir. 2002) (holding that generic claim language appearing in ipsis verbis in the original specification did not satisfy the written description requirement because it failed to support the scope of the genus claimed); Fiers v. Revel, 984 F.2d 1164, 1170, 25 USPQ2d 1601, 1606 (Fed. Cir. 1993) (rejecting the argument that "only similar language in the specification or original claims is necessary to satisfy the written description requirement").”
“The Federal Circuit has explained that a specification cannot always support expansive claim language and satisfy the requirements of 35 U.S.C. 112 "merely by clearly describing one embodiment of the thing claimed." LizardTech v. Earth Resource Mapping, Inc., 424 F.3d 1336, 1346, 76 USPQ2d 1731, 1733 (Fed. Cir. 2005). The issue is whether a person skilled in the art would understand applicant to have invented, and been in possession of, the invention as broadly claimed. In LizardTech, claims to a generic method of making a seamless discrete wavelet transformation (DWT) were held invalid under 35 U.S.C. 112, first paragraph, because the specification taught only one particular method for making a seamless DWT and there was no evidence that the specification contemplated a more generic method. "[T]he description of one method for creating a seamless DWT does not entitle the inventor . . . to claim any and all means for achieving that objective." LizardTech, 424 F.3d at 1346, 76 USPQ2d at 1733.”
Regarding Claims 1, 8, 9, 16, and 18:
Claims 1, 8, 9, 16, and 18 recite “determine a corresponding ranking of at least some of the blocks of code with an anomaly measure by applying an anomaly detection algorithm to the blocks of code…” and claims 1, 9, and 18 further recite and wherein the anomaly measure indicates a statistical deviation of each block of code from other blocks of code in the computer code”. There is no support in the disclosure regarding how the inventor intended to perform these various claimed functionalities. The algorithm or steps/procedures for these claimed functions is not explained at all or is not explained in sufficient detail (simply restating the function reciting in the claim is not necessarily sufficient) so that one of ordinary skill in the art would recognize that the applicant had possession of the claimed invention. For example, paragraph [0032] of the originally filed disclosure states, “Ranking determination module 214 may be configured to determine a relative corresponding ranking of at least some of the blocks of code in accordance with an anomaly metric by applying an anomaly detection algorithm to the blocks of code. Determining a corresponding ranking may include building one or more unsupervised learning models for determining anomalies of the computer code. The models may include an isolation forest model. The ranking may be the anomaly metric, a normalization or approximation thereof, or may be in accordance with any scale based on the metrics. In some implementations, determining a corresponding ranking may include assigning a score to each code block and ranking the code blocks based on the score”. This does not disclose how the inventor intended to achieve the desired results of determining a corresponding ranking according to an undisclosed anomaly metric by applying a “well known” supervised or unsupervised model without any further configuration of the said model being disclosed whatsoever.
Regarding Claims 2 and 10:
Dependent claims 2 and 10 recite the limitation “parsing of the code based on the format of the computer code”. The specification is not commensurate with the full scope of the claim because it is silent regarding how the claimed parsing based on the format of the computer code is actually performed, and the broadest reasonable interpretation . Paragraph [0025] of the disclosure recites “Computer code converting module 212 may be configured to convert the computer code into a numeric description of characteristics of the code. The converting may include parsing of the code based on the format of the computer code”; and paragraph [0037] only nominally mentions a custom parser without disclosing an algorithm, motivation, or method step in regards to how the inventor intended the claimed invention to perform the claimed functionality.
The dependent claims fall together accordingly.
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-16 and 18-21 are rejected under 35 U.S.C. 103 as being unpatentable over Byrne et. al. (US Publication No. US 2020/0394028 A1) hereinafter Byrne, in view of Desai et. al. (US Publication No. US 2020/0265119 A1) hereinafter Desai, further in view of Nicolson et. al. (US Publication No. US 2009/0119515 A1) hereinafter Nicolson.
Regarding Claim 1, 9, and 18:
Claim 1. Byrne discloses a system comprising: one or more hardware processors configured by machine-readable instructions to (Byrne [0019], Fig. 8): partition computer code into blocks of code (Byrne [0032] function identifier can divide the code into individual labelled functions); convert the blocks of code into a numeric description of characteristics of the code (Byrne [0032-0036], [0040-0041]) wherein the characteristics include at least one of: length of a function name, number of lines in a function, number of operations in a function body, number of parameters in a function signature, number of unique symbols, number of variables, or number of unique functions referenced by a function (Byrne [0032] function name, library name, library version, register and memory values, [0040-0041] function bounds determined).
Byrne does not disclose determine a corresponding ranking of at least some of the blocks of code with an anomaly measure by applying an anomaly detection algorithm to the blocks of code, wherein the anomaly detection algorithm comprises an unsupervised algorithm that computes how anomalous each block of code is relative to other blocks of code within the computer code, and wherein the anomaly measure indicates a statistical deviation of each block of code from other blocks of code in the computer code; select anomalous blocks of the blocks of code by applying a threshold to the rankings; apply code obfuscation techniques to at least one of the anomalous blocks of code to thereby create secured computer code, wherein the code obfuscation techniques comprise at least one of instruction pattern transformation, renaming of methods or variables, control flow obfuscation, string encryption, dummy code insertion, binary linking or merging, or opaque predicate insertion; and determine effectiveness of the code obfuscation techniques by comparing anomaly measures of the blocks of code before and after applying the code obfuscation techniques.
Desai teaches determine a corresponding ranking of at least some of the blocks of code with an anomaly measure by applying an anomaly detection algorithm to the blocks of code (Desai [0046] anomaly score, Fig. 1A-1C various models used to determine what are anomalies, [0047-0048] anomaly is determined based on a score satisfying a threshold, [0056] processing other data from other devices explicitly suggested; Applicant admitted anomaly detection methods are well known in the originally filed disclosure [0017-0018] “Various anomaly detection methods are well known and are generally classified as either supervised of unsupervised anomaly detection techniques … One known unsupervised method of anomaly detection, known as “isolation forest”, identifies anomalies by isolating outliers in the data… Disclosed implementations can use isolation forest and other known anomaly detection algorithms”), wherein the anomaly detection algorithm comprises an unsupervised algorithm that computes how anomalous each block of code is relative to other blocks of code within the computer code (Desai [0043-0048] isolation forest model explicitly taught and determines a priority of possible anomalies relative to each other based on relative values of the scores) and wherein the anomaly measure indicates a statistical deviation of each block of code from other blocks of code in the computer code (Desai Fig. 1D compare to peer data is explicitly suggested, [0044] anomaly detection platform may process first outputs to determine whether usage data includes an anomaly based on other usage data relative to peers; [0047-0048] anomaly is determined based on a score satisfying a threshold, [0056] processing other data from other devices explicitly suggested; Figure 2 multiple usage data statistics depicted and put through models to determine anomaly score, definition of an anomaly as an anomaly is something that is “inconsistent with or deviating from what is usual, normal, or expected” according to its plain meaning); select anomalous blocks of the blocks of code by applying a threshold to the rankings (Desai [0047] select anomalies based on the score satisfying a threshold; Applicant admitted “it is known to attempt to focus the application of obfuscation techniques on the most security sensitive portions of the code, i.e. code portions that are most likely to be attacked” originally filed disclosure paragraph [0004]).
It would have been obvious to one having ordinary skill in the art before the time the invention was effectively filed to combine the code partitioning and conversion of Byrne with the anomaly score assignment and anomaly threshold measuring taught by Desai. The motivation for this combination would be to be able to determine a priority of possible anomalies relative to each other, based on relative values of the scores as taught by Desai (Desai [0047]).
Desai does not teach apply code obfuscation techniques to at least one of the anomalous blocks of code to thereby create secured computer code, wherein the code obfuscation techniques comprise at least one of instruction pattern transformation, renaming of methods or variables, control flow obfuscation, string encryption, dummy code insertion, binary linking or merging, or opaque predicate insertion; and determine effectiveness of the code obfuscation techniques by comparing anomaly measures of the blocks of code before and after applying the code obfuscation techniques.
Nicolson teaches and apply code obfuscation techniques to at least one of the anomalous blocks of code to thereby create secured computer code, wherein the code obfuscation techniques comprise at least one of instruction pattern transformation, renaming of methods or variables, control flow obfuscation, string encryption, dummy code insertion, binary linking or merging, or opaque predicate insertion (Nicolson Fig. 6 and 8, [0084-0089], [0102]; Applicant admitted code obfuscation techniques well-known to one of ordinary skill in the art in the originally filed disclosure paragraph [0003], originally filed disclosure paragraph [0016] “a known process to create secure code”); and determine effectiveness of the code obfuscation techniques by comparing anomaly measures of the blocks of code before and after applying the code obfuscation techniques (Nicolson Fig. 5 and 7-11, [0066] degree of obfuscation and complexity evaluated, [0090-0095] and [0097-0109] obfuscation feedback loop taught, [0041-0044]).
It would have been obvious to one having ordinary skill in the art before the time the invention was effectively filed to combine the code partitioning and conversion of Byrne with the anomaly score assignment and anomaly threshold measuring taught by Desai, further with the code obfuscation and evaluation as taught by Nicolson. The motivation for this combination would be to ensure that the blocks of code which trigger the anomaly threshold are subjected to an obfuscation process and the results are then evaluated and feedback provided to enable the obfuscation process to produce more suitable results (Nicolson [0041-0044] “Therefore, there is an unmet need for, and it would be highly useful to have, a system and method that can evaluate the quality of an obfuscation, or more specifically, a control flow graph obfuscation that replaces original code with obfuscated code that implements a more complex control flow, containing dummy code (that is, code that is never executed), fake-robust dummy code (code that is never executed but nonetheless appears to be valid), and clones of active code with different obfuscations, then feedback to the obfuscation process the results of this evaluation to enable the obfuscation process to produce more suitable results. The design of such a feedback system should be performed in a generic manner so that can be applied to any suitable existing or new obfuscation technique”).
Independent claims 9 and 18 recite substantially the same content and are therefore rejected under the same rationales. Byrne discloses a method in paragraphs [0019] and [0085].
Regarding Claim 2 and 10:
Claim 2. The combination of Byrne, Desai, and Nicolson further teaches the system of claim 1 (Byrne [0019], Fig. 8), wherein the converting includes parsing of the code based on the format of the computer code (Byrne [0038] the function identifier can utilize a disassembler that is compatible with different binary languages such as C or C++ and output a platform-independent representation for further use; Applicant admitted is well-known to one of ordinary skill in the art), wherein the format can be determined from one of an encoding or grammar of the code (Byrne [0038] the function identifier can utilize a disassembler that is compatible with different binary languages such as C or C++ and output a platform-independent representation for further use; Applicant admitted is well-known to one of ordinary skill in the art).
Claim 10 recites substantially the same content and is therefore rejected under the same rationales.
Regarding Claim 3, 11, and 19:
Claim 3. The combination of Byrne, Desai, and Nicolson further teaches the system of claim 1 (Byrne [0019], Fig. 8), wherein the characteristics of the code include one or more of a length of a function name, a number of lines in a function, a number of operations in a function body, a number of parameters in a function signature, a number of unique symbols, a number of number of variables, a number of unique functions referenced a function, a number of errors encountered while parsing code, and/or a number of times particular symbols or strings of symbols are encountered (Byrne [0035] function can be fingerprinted).
Claims 11 and 19 recite substantially the same content and are therefore rejected under the same rationales.
Regarding Claim 4, 12, and 20:
Claim 4. The combination of Byrne, Desai, and Nicolson further teaches the system of claim 1 (Byrne [0019], Fig. 8), wherein determining a corresponding ranking includes building an unsupervised learning model for determining anomalies of the computer code (Desai Fig. 1A-1C various models used to determine what are anomalies).
Claims 12 and 20 recite substantially the same content and are therefore rejected under the same rationales.
Regarding Claim 5 and 13:
Claim 5. The combination of Byrne, Desai, and Nicolson further teaches the system of claim 4 (Byrne [0019], Fig. 8), wherein the model is an isolation forest model (Desai [0043] isolation forest model).
Claim 13 recites substantially the same content and is therefore rejected under the same rationales.
Regarding Claim 6, 14, and 21:
Claim 6. The combination of Byrne, Desai, and Nicolson further teaches the system of claim 1 (Byrne [0019], Fig. 8), wherein determining a corresponding ranking includes assigning a score to each code block and ranking the code blocks based on the score (Desai [0047] select anomalies based on the score satisfying a threshold, and apply to the code blocks disclosed by Byrne).
Claims 14 and 21 recite substantially the same content and are therefore rejected under the same rationales.
Regarding Claim 7 and 15:
Claim 7. The combination of Byrne, Desai, and Nicolson further teaches the system of claim 1 (Byrne [0019], Fig. 8), wherein the selecting is applied only to code blocks exceeding a threshold rank (Desai [0047] select anomalies based on the score satisfying a threshold).
Claim 15 recites substantially the same content and is therefore rejected under the same rationales.
Regarding Claim 8 and 16:
Claim 8. The combination of Byrne, Desai, and Nicolson further teaches the system of claim 1, wherein the one or more hardware processors configured by machine-readable instructions to (Byrne [0019], Fig. 8): partition the secured computer code into blocks of secured computer code (Nicolson Fig. 8-11 the now-obfuscated code is partitioned into blocks, [0089-0095]); convert the blocks of secured code into a numeric description of characteristics of the secured code (Nicolson Fig. 8-11 the now-obfuscated code is partitioned into blocks and information such as code coverage and executions enumerated, [0089-0095]); determine a corresponding ranking of at least some of the blocks of secured code with an anomaly measure by applying an anomaly detection algorithm to the blocks of secured code (Nicolson Fig. 8-11, [0089-0095], [0097-0109] obfuscation feedback loop taught, [0198] scores taught); and compare the corresponding ranking of the at least some of the blocks of secured code with the corresponding ranking of at least some of the blocks of code (Nicolson Fig. 8-11, [0089-0095], [0097-0109] obfuscation feedback loop taught, [0198] scores taught) to thereby determine effectiveness of code protection (Nicolson Fig. 8-11, [0089-0095], [0097-0109] obfuscation feedback loop, [0133-0136] taught to identify re-obfuscation candidates, [0198] scores taught).
Claim 16 recites substantially the same content and is therefore rejected under the same rationales.
Conclusion
The prior art made of record in the submitted PTO-892 Notice of References Cited and not relied upon is considered pertinent to applicant’s disclosure.
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 MIGUEL A LOPEZ whose telephone number is (703)756-1241. The examiner can normally be reached 8:00AM-5: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, Jorge Ortiz-Criado can be reached on 5712727624. 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.
/M.A.L./ Examiner, Art Unit 2496
/JORGE L ORTIZ CRIADO/Supervisory Patent Examiner, Art Unit 2496
Prosecution Insights