DETAILED ACTION
Claims 1, 3-7, 9-13 and 15 are pending in this 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 .
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 3-7, 9-13 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Smith (US PGPUB No. 2017/0357809) in view of Chernov (US PGPUB No. 2023/0177168) in further view of D’Mello et al. (US PGPUB No. 2006/0021052) [hereinafter “D’Mello”] in further view of Henderson et al. (US PGPUB No. 2019/0342323) [hereinafter “Henderson”] in further view of Chen et al. (US PGPUB No. 2016/0321069) [hereinafter “Chen”]
As per claim 1, Smith teaches a processor implemented method, comprising: receiving, via an input/output interface, an application in binary form, ([0019], a software binary is sent to an analyzer to detect vulnerability); detecting, via a first module executed by one or more hardware processors, a plurality of vulnerable program fragments in the received application in binary form ([0019], detecting in the binary vulnerabilities with corresponding line numbers); creating, via a second module executed by the one or more hardware processors, a mapping between the application in binary form and a plurality of source code files corresponding to the application in binary form to identify a plurality of vulnerable source code program fragments ([0019], report contains various information regarding a particular vulnerability including the line number for both the binary and the source code); performing, via a third module executed by the one or more hardware processors, an repairing process on each of the identified plurality of vulnerable source code program fragments to obtain a plurality of safe source code program fragments ([0033], vulnerabilities are remediated which produces safe source code), wherein the auto repairing process comprises: extracting, one or more paths representing a functionality aspect of the application in binary form ([0019], vulnerability information includes location and function identifiers) and a plurality of vulnerable program statements for each vulnerable source code program fragment from the plurality of vulnerable source code program fragments in the application in binary form based on the created mapping ([0019], report contains various information regarding a particular vulnerability including the line number for both the binary and the source code which together is considered a mapping).
Smith does not explicitly teach a set of predefined vulnerability detection rules (Examiner Note: it could be argued that the static and dynamic analyzer inherently has vulnerability detection rules, however another reference is provided to explicitly show that such analyzers have such rules). Chernov teaches a set of predefined vulnerability detection rules (Abstract, detecting vulnerabilities using a rule module provided to the analyzer).
At the time of filing, it would have been obvious to one of ordinary skill in the art to combine Smith with the teachings of Chernov, a set of predefined vulnerability detection rules, to show that vulnerability analyzers are set with rules to detect vulnerabilities in code allowing users to specifically discover known types of vulnerabilities.
The combination of Smith and Chernov does not explicitly teach an auto repair process and applying, a functional ordered auto repair rule from a plurality of functional ordered auto repair rules in accordance with a plurality of predefined criterions to each of the plurality of vulnerable program statements of each path from the one or more paths; computing, an effect of applying the functional ordered auto repair rule on a plurality of non-vulnerable program statements within a first set of procedures from a set of procedures associated with each of the one or more paths, wherein the functional ordered auto repair rule utilizes one or more repair strategies, and wherein one or more inconsistencies are generated in the plurality of non-vulnerable program statements within the first set of procedures from the set of procedures associated with each of the one or more paths when the one or more repair strategies are used; resolving, the one or more inconsistency generated in the plurality of non-vulnerable program statements within the first set of procedures from the set of procedures associated with each of the one or more paths; and iteratively computing, an effect of use of the one or more repair strategies on a second set of the procedures from the set of procedures and resolving the one or more inconsistency generated in the second set of procedures from the set of procedures associated with each of the one or more paths. D'Mello teaches an auto repair process ([0016], remediations are translated into a machine-actionable format, i.e. auto-repair) and applying, a functional ordered auto repair rule from a plurality of functional ordered auto repair rules in accordance with a plurality of predefined criterions to each of the plurality of vulnerable program statements of each path from the one or more paths ([0034]-[0036], using parameters of a vulnerability via its VID to locate a list of appliable remediations, RID); computing, an effect of applying the functional ordered auto repair rule on a plurality of non-vulnerable program statements within a first set of procedures from a set of procedures associated with each of the one or more paths (Abstract, assessing susceptibility of remediated machine to vulnerabilities), wherein the functional ordered auto repair rule utilizes one or more repair strategies ([0020]-[0021], mapping particular remediations to vulnerabilities as a form of remediation “strategy”), and wherein one or more inconsistencies are generated in the plurality of non-vulnerable program statements within the first set of procedures from the set of procedures associated with each of the one or more paths when the one or more repair strategies are used ([0047], code is scanned again for remaining and additional vulnerabilities, i.e. inconsistencies); resolving, the one or more inconsistency generated in the plurality of non-vulnerable program statements within the first set of procedures from the set of procedures associated with each of the one or more paths ([0049], other remediations are used to resolve any remaining vulnerabilities); and iteratively computing, an effect of use of the one or more repair strategies on a second set of the procedures from the set of procedures and resolving the one or more inconsistency generated in the second set of procedures from the set of procedures associated with each of the one or more paths ([0052]-[0054], continuing to determine if there are remainder vulnerabilities to remediate).
At the time of filing it would have been obvious to one of ordinary skill of the art to combine Smith and Chernov with the teachings of D’Mello, an auto repair process and applying, a functional ordered auto repair rule from a plurality of functional ordered auto repair rules in accordance with a plurality of predefined criterions to each of the plurality of vulnerable program statements of each path from the one or more paths; computing, an effect of applying the functional ordered auto repair rule on a plurality of non-vulnerable program statements within a first set of procedures from a set of procedures associated with each of the one or more paths, wherein the functional ordered auto repair rule utilizes one or more repair strategies, and wherein one or more inconsistencies are generated in the plurality of non-vulnerable program statements within the first set of procedures from the set of procedures associated with each of the one or more paths when the one or more repair strategies are used; resolving, the one or more inconsistency generated in the plurality of non-vulnerable program statements within the first set of procedures from the set of procedures associated with each of the one or more paths; and iteratively computing, an effect of use of the one or more repair strategies on a second set of the procedures from the set of procedures and resolving the one or more inconsistency generated in the second set of procedures from the set of procedures associated with each of the one or more paths, to fully remediate the discovered vulnerabilities without creating further vulnerabilities and inconsistencies which would lead to inefficiencies in the future.
The combination of Smith, Chernov and D’Mello does not explicitly teach wherein the functionality aspect is characterized by a functional group attribute and an order attribute, wherein all the functional ordered auto repair rules belonging to the functional group attribute are extracted, and the auto repair rules are sorted based on a value of the order attribute, wherein when the functional ordered auto repair rule is applicable to the vulnerable program statement, then the vulnerable program statement is annotated with the value of order attribute, and a procedure corresponding to the vulnerable program statement is also annotated with the value of order attribute and a value of functional group attribute describing functionality, and wherein all annotated procedures are categorized into varied functional groups based on values of the functional group attribute for each functional group category, methods are arranged in a call order based on the values of the order attribute, wherein once all methods belonging to a functional group category are placed in the call order, the path is generated by combining all annotated nodes as per the call order. Henderson teaches wherein the functionality aspect is characterized by a functional group attribute ([0012], key defining groups of vulnerabilities and grouping rules) and an order attribute ([0012], priorities including among other things an ordering of assignment rules), wherein all the functional ordered auto repair rules belonging to the functional group attribute are extracted ([0013], comparison of an item to the assignment rules which are extracted, i.e. queried, from the attributes and rules database see [0011]), and the auto repair rules are sorted based on a value of the order attribute ([0013], the assignment rules are sorted in the order of priorities), wherein when the functional ordered auto repair rule is applicable to the vulnerable program statement, then the vulnerable program statement is annotated with the value of order attribute (Examiner Note: The specification does not explain what annotating a program statement with a value would entail. See 112 rejection above. This statement will be interpreted to be an ordering of vulnerabilities.) (Abstract, assignment rules are assigned an order for comparison to a configuration item), and a procedure corresponding to the vulnerable program statement is also annotated with the value of order attribute and a value of functional group attribute describing functionality ([0013], storing a reference indicating a particular group), and wherein all annotated procedures are categorized into varied functional groups based on values of the functional group attribute for each functional group category ([0004], grouping are based on various different functional attributes including department, OS, etc.), methods are arranged in a call order based on the values of the order attribute (Abstract, assignment rules are assigned an order for comparison to a configuration item), wherein once all methods belonging to a functional group category are placed in the call order (Abstract, configuration items may be grouped based on various functions see [0004]), the path is generated by combining all annotated nodes as per the call order (Examiner Note: The claim has not mentioned or defined a node or nodes. See 112 rejection above. For this action, this will be interpreted to be the ordering of priority rules, i.e. annotated ordering) (Abstract, assignment rules are assigned an order for comparison to a configuration item).
At the time of filing, it would have been obvious to one of ordinary skill in the art to combine Smith, Chernov and D’Mello with the teachings of Henderson, does not explicitly teach wherein the functionality aspect is characterized by a functional group attribute and an order attribute, wherein all the functional ordered auto repair rules belonging to the functional group attribute are extracted, and the auto repair rules are sorted based on a value of the order attribute, wherein when the functional ordered auto repair rule is applicable to the vulnerable program statement, then the vulnerable program statement is annotated with the value of order attribute, and a procedure corresponding to the vulnerable program statement is also annotated with the value of order attribute and a value of functional group attribute describing functionality, and wherein all annotated procedures are categorized into varied functional groups based on values of the functional group attribute for each functional group category, methods are arranged in a call order based on the values of the order attribute, wherein once all methods belonging to a functional group category are placed in the call order, the path is generated by combining all annotated nodes as per the call order, to efficiently analyze and correct all identified vulnerabilities in a system with minimal human intervention.
The combination of Smith, Chernov, D’Mello and Henderson does not explicitly teach a particular path is generated by combining all annotated program statements as per the call order. Chen teaches a particular path is generated by combining all annotated program statements as per the call order ([0047]-[0048], all method call statements with behavior signatures are sequenced in a path order).
At the time of filing, it would have been obvious to one of ordinary skill in the art to combine Smith, Chernov, D’Mello and Henderson with the teachings of Chen, a particular path is generated by combining all annotated program statements as per the call order, to efficiently analyze and correct all identified vulnerabilities in a system with minimal human intervention.
As per claim 3, the combination of Smith, Chernov, D’Mello, Henderson and Chen teaches the processor implemented method of claim 1, wherein the plurality of predefined criterions include (i) determining type of each of the plurality of vulnerable program statements (Smith; [0019], class of the vulnerability with its location and line/s) (ii) determining a functional ordered auto repair rule from the plurality of functional ordered auto repair rules matching to each of the plurality of vulnerable program statements (D’Mello; [0034], assigning various remediation via its RID to one or more vulnerabilities), and (iii) determining a rule type of the functional ordered auto repair rule from the plurality of functional ordered auto repair rules matching to each of the plurality of vulnerable program statements (D’Mello; [0028] and [0031], fields that define a type of remediation based on associated technologies or invasiveness level, etc.).
As per claim 4, the combination of Smith, Chernov, D’Mello, Henderson and Chen teaches the processor implemented method of claim 1, wherein the first set of procedures represents a set of vulnerability located procedures (D’Mello; [0021] and [0034], mapping and remediation procedures located using vulnerability ID) combined with (Smith; [0019], location and line number of vulnerability) motivated to remediate the correct lines and statements in the binary and/or source code.
As per claim 5, the combination of Smith, Chernov, D’Mello, Henderson and Chen teaches the processor implemented method of claim 1, wherein the second set of procedures represents a set of non-vulnerability located procedures (D’Mello; Abstract, determining a second set of vulnerabilities that may appear in procedures that were once non-vulnerable see also [0047]-[0048]).
As per claim 6, the combination of Smith, Chernov, D’Mello, Henderson and Chen teaches the processor implemented method of claim 1, wherein the one or more repair strategies are utilized based on the rule type of the functional ordered auto repair rule from the plurality of functional ordered auto repair rules matching to each of the plurality of vulnerable program statements (D’Mello; [0040], selecting a remediation based on the type of technology it is associated with and mapped to be effective against).
As per claim 7, the substance of the claimed invention is identical to that of claim 1. Accordingly, this claim is rejected under the same rationale.
As per claim 9, the substance of the claimed invention is identical to that of claim 3. Accordingly, this claim is rejected under the same rationale.
As per claim 10, the substance of the claimed invention is identical to that of claim 4. Accordingly, this claim is rejected under the same rationale.
As per claim 11, the substance of the claimed invention is identical to that of claim 5. Accordingly, this claim is rejected under the same rationale.
As per claim 12, the substance of the claimed invention is identical to that of claim 6. Accordingly, this claim is rejected under the same rationale.
As per claim 13, the substance of the claimed invention is identical to that of claim 1. Accordingly, this claim is rejected under the same rationale.
As per claim 15, the substance of the claimed invention is identical to that of claim 3. Accordingly, this claim is rejected under the same rationale.
Response to Arguments
Applicant’s arguments with respect to the objections to claims 1, 7 and 13 have been fully considered and persuasive. The objections are hereby withdrawn.
Applicant’s arguments with respect to the rejection of claims 1, 7 and 13 under 35 U.S.C. 112 have been fully considered and are persuasive. The rejections are herby withdrawn.
Applicant’s arguments with respect to the rejection of claims 1, 3-7, 9-13 and 15 under 35 U.S.C. 103 have been fully considered. In light of the new amendments, a new prior art reference has been introduced and cited to, Chen.
To expedite prosecution, Examiner is open to conducting an interview to discuss claim amendments to overcome the current rejection and/or place the application in condition for allowance.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Fox et al. (US PGPUB No. 2020/0310763), Rioux (US PGPUB No. 2006/0253841), Grechanik (US Patent No. 8,799,869), Gremme et al. ("GenomeTools: A Comprehensive Software Library for Efficient Processing of Structured Genome Annotations," in IEEE/ACM Transactions on Computational Biology and Bioinformatics, vol. 10, no. 3, pp. 645-656, May 2013, doi: 10.1109/TCBB.2013.68) and Moser et al. ("RbG: A documentation generator for scientific and engineering software," 2015 IEEE 22nd International Conference on Software Analysis, Evolution, and Reengineering (SANER), Montreal, QC, Canada, 2015, pp. 464-468, doi: 10.1109/SANER.2015.7081857) all disclose various aspects of the claimed invention including remediating vulnerabilities found in binary and source code and analyzing the result.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PETER C SHAW whose telephone number is (571)270-7179. The examiner can normally be reached Max Flex.
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, Carl Colin can be reached at 571-272-3862. 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.
/PETER C SHAW/Primary Examiner, Art Unit 2493 February 13, 2026