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”] in further view of Mestchian (US Patent No. 11,048,487).
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.
The combination of Smith, Chernov, D’Mello, Henderson and Chen does not explicitly teach wherein resolving the one or more inconsistency comprises: computing, for at least one vulnerable program statement, a forward intra procedure slice when a type of the vulnerable program statement is a definition statement (); detecting a callsite within the forward intra procedure slice that fetches a procedure corresponding to the callsite; and changing a declaration of the invoked procedure in accordance with a repair strategy applied to the vulnerable program statement, wherein when the repair strategy is replace, then changes to the declaration includes changing name of argument corresponding to an original definition of the program statement in the callsite and changing a type of variable in the declaration. Mestchian teaches wherein resolving the one or more inconsistency comprises: computing, for at least one vulnerable program statement, a forward intra procedure slice when a type of the vulnerable program statement is a definition statement (Col. 23, lines 30-40, detecting an inconsistent statement that could degrade reliability or needs to be repaired see Col. 4, lines 30-40 using different types of slicing including intraprocedural slicing see Col. 28, lines 50-62); detecting a callsite within the forward intra procedure slice that fetches a procedure corresponding to the callsite (Col. 10, lines 30-36, tracing function calls in code to different functionalities, i.e. procedures); and changing a declaration of the invoked procedure in accordance with a repair strategy applied to the vulnerable program statement, wherein when the repair strategy is replace, then changes to the declaration includes changing name of argument corresponding to an original definition of the program statement in the callsite and changing a type of variable in the declaration (Col. 10, lines 3-10, changes to code for improving reliability or repairing statements see Abstract and Col. 4, lines 30-40, including changing argument names and 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, Henderson and Chen with the teachings of Mestchian, wherein resolving the one or more inconsistency comprises: computing, for at least one vulnerable program statement, a forward intra procedure slice when a type of the vulnerable program statement is a definition statement; detecting a callsite within the forward intra procedure slice that fetches a procedure corresponding to the callsite; and changing a declaration of the invoked procedure in accordance with a repair strategy applied to the vulnerable program statement, wherein when the repair strategy is replace, then changes to the declaration includes changing name of argument corresponding to an original definition of the program statement in the callsite and changing a type of variable in the declaration, 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, Chen and Mestchian 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, Chen and Mestchian 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, Chen and Mestchian 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, Chen and Mestchian 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 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, Mestchian.
To expedite prosecution, Examiner is open to conducting an after-final 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. Vangala et al. (US PGPUB No. 2013/0179863), Reps et al. (US Patent No. 5,161,216), Kurita et al. (US PGPUB No. 2007/0074177), Wang (CN-107153610-A), Seddik et al. ("ARISE: A Repository-level Graph Representation and Toolset for Agentic Fault Localization and Program Repair," arXiv:2605.03117, May 4, 2026) and Zeng et al. ("A Slice-Level Code Vulnerability Detection Method Based on Self-Organizing Graph Neural Networks," 2025 7th (IAECST), Guangzhou, China, 2025, pp. 1267-1271, doi: 10.1109/IAECST68792.2025.11415009) all disclose various aspects of the claimed invention including remediating vulnerabilities found in binary and source code and analyzing the result.
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 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 July 2, 2026