DETAILED ACTION
This office action is in response to the application filed on 05/12/2025. Claim(s) 1-20 is/are pending and are examined.
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 .
Priority
The present application claims priority to parent application No. 18/038,838 filed on 12/19/2022 and PRO 63/391,518 and 63/391,560 both filed on 07/22/2022.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 05/12/2025, 07/17/2025, 10/29/2025, 05/04/2026 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claim(s) 1-20 of the instant application is/are rejected on the ground of nonstatutory double patenting as being unpatentable over claim(s) 1-20 of parent U.S. Patent No. 18/083,838. Although the claims at issue are not identical, they are not patentably distinct from each other because:
Instant Application
Parent/Co-Application
A method comprising: receiving a learned control flow directed graph (CFDG) for executable code of an application; determining, based in part on a portion of the learned CFDG, at least one destination of an indirect transfer within the executable code, the indirect transfer to be computed at run time of the executable code by a disassembler; providing the at least one destination, the executable code, and the portion of the learned CFDG to the disassembler; and performing, by the disassembler and at run time, a disassembly of the executable code.
A method, comprising: receiving a learned control flow directed graph for executable code of an application, the learned control flow directed graph being generated by observing executions of transitions within the executable code during an observation period; determining, based on the learned control flow directed graph, one or more destinations of indirect transfers within the executable code, the indirect transfers to be computed at run time of the executable code by a disassembler; providing the one or more destinations of the indirect transfers, the executable code, and the learned control flow directed graph to the disassembler; and performing, by the disassembler and at run time, a disassembly of the executable code based at least in part on the learned control flow directed graph, the one or more destinations of indirect transfers, and the executable code.
10. A system comprising: one or more processors; and one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: receiving a learned control flow directed graph (CFDG) for executable code of an application; determining, based in part on a portion of the learned CFDG, at least one destination of an indirect transfer within the executable code, the indirect transfer to be computed at run time of the executable code by a disassembler; providing the at least one destination, the executable code, and the portion of the learned CFDG to the disassembler; and performing, by the disassembler and at run time, a disassembly of the executable code.
8. A system comprising: one or more processors; and one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising:
receiving a learned control flow directed graph for executable code of an application, the learned control flow directed graph being generated by observing executions of transitions within the executable code during an observation period; determining, based on the learned control flow directed graph, one or more destinations of indirect transfers within the executable code, the indirect transfers to be computed at run time of the executable code by a disassembler; providing the one or more destinations of the indirect transfers, the executable code, and the learned control flow directed graph to the disassembler; and performing, by the disassembler and at run time, a disassembly of the executable code based at least in part on the learned control flow directed graph, the one or more destinations of indirect transfers, and the executable code.
19. One or more non-transitory computer-readable media storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising: receiving a learned control flow directed graph (CFDG) for executable code of an application; determining, based in part on a portion of the learned CFDG, at least one destination of an indirect transfer within the executable code, the indirect transfer to be computed at run time of the executable code by a disassembler; providing the at least one destination, the executable code, and the portion of the learned CFDG to the disassembler; and performing, by the disassembler and at run time, a disassembly of the executable code.
15. One or more non-transitory computer-readable media storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to: receive, by a disassembler, a learned control flow directed graph for executable code of an application, the learned control flow directed graph being generated by observing executions of transitions within the executable code during an observation period; determine, by the disassembler, one or more destinations of indirect transfers within the executable code based on the learned control flow directed graph; and perform, by the disassembler and at run time, a disassembly of the executable code based at least in part on the learned control flow directed graph, the one or more destinations of direct transfers, and the executable code.
The dependent claims included in the statement of rejection but not specifically addressed in the body of the rejection have inherited the deficiencies of their parent claim and have not resolved the deficiencies. Therefore, they are rejected based on the same rationale as applied to their parent claims above. The dependent claims included in the statement of rejection but not specifically addressed in the body of the rejection are rejected similarly over corresponding claims in the ‘838 patent.
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.
Claim(s) 7 and 16 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. The specification at [0231] merely restates this limitation without providing any further detail. The remaining passages discussing “coverage” ([0049], [0163]) relate to the observation phase for building the CFDG and to monitoring/enforcement — not to how full coverage is determined during disassembly. The specification does not describe what constitutes “full coverage” in a disassembly context, how the CFDG is used to determine when full coverage is achieved, or any algorithm or steps for performing this determination. Accordingly, the specification fails to demonstrate that the inventor(s) had possession of the claimed “determining full coverage” limitation as applied to disassembly.
Claim(s) 7 and 16 rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the enablement requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to enable one skilled in the art to which it pertains, or with which it is most nearly connected, to make and/or use the invention. Applicant’s specification does not enable one of ordinary skill to practice “determining full coverage of the executable code” because it provides no guidance on the metric, the termination condition, or the mechanism by which the learned CFDG would be used to verify completeness of a disassembly — a non-trivial problem in binary analysis (the halting problem makes truly complete disassembly undecidable in general).
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-6, 9-15, and 18-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sultana (US 2018/0095764 A1), hereinafter Sultana in view of August (US 9,329,846 B1) hereinafter August in further view of Bardin (US 2019/0129825 A1), hereafter Bardin.
Regarding Claim(s) 1 Sultana teaches:
A method comprising: (Sultana ¶ 13 teaches, An apparatus, method and/or system are configured to utilize processor trace (PT) data captured from PT circuitry and a control flow graph (CFG) to determine whether a control flow violation exists in an executing target application, in real time.)
receiving a learned control flow directed graph (CFDG) for executable code of an application; (Sultana ¶ 34-36 teaches, Control flow validator circuitry 134 may be further configured to associate each static target address with the corresponding branch instruction in the application CFG and/or library CFG stored to CFG store.)
determining, based in part on a portion of the learned CFDG, at least one destination of an indirect transfer within the executable code, (Sultana ¶ 36 teaches, CFI circuitry may be configured to repeat these operations a number of times. The static target addresses identified during these preprocessing operations may correspond to at least a subset of all identifiable possible target addresses an indirect branch instruction.)
Sultana does not appear to explicitly teach but in related art:
the indirect transfer to be computed at run time of the executable code by a disassembler; (August Col. 6-7 Ln. 60-67 and 1-5 teaches, if the destination of an indirect jump instruction depends on some runtime condition, the statically disassembled code may be out of sync at the target of the indirect jump instruction. The determination is preferably made on the server side. In such cases, the server may be able to determine the possible targets of the jump instruction and convey this information to the clients in the hints. Based on hints about out of sync locations, the client-side disassembler can successfully disassemble program code. Col. Ln. 5 teaches, the client-side tool starts with the original binary without any additions or modifications. This binary is to be disassembled, transformed, and executed. During application run-time on the client, the original binary remains in memory to serve as a backup.)
performing, by the disassembler and at run time, a disassembly of the executable code. (August Col. Ln. 5 teaches, the client-side tool starts with the original binary without any additions or modifications. This binary is to be disassembled, transformed, and executed. During application run-time on the client, the original binary remains in memory to serve as a backup.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Sultana with August, to modify the method for control flow integrity of Sultana with the disassembler hints of August. The motivation to do so, August Col. 6 Ln. 30, to aid code disassembly on the client.
Sultana in view of August does not appear to explicitly teach but in related art:
providing the at least one destination, the executable code, and the portion of the learned CFDG to the disassembler; and (Bardin ¶ 74 teaches, the method allows improving the (partial) control flow graph recovery by going back to the beginning, taking infeasibility information into account. The method may use a static disassembly tool that does not disassemble branches of the control flow graph that are marked as infeasible (infeasible branch meaning the corresponding code is dead). ¶ 62 teaches, a dynamic program is analyzed to generate a control flow graph (CFG). Generally, most of the graphs generated are partial control flow graph (P-CFG). In some embodiments, the control flow graph is generated by a static analysis tools. Alternatively, the control flow graph may be generated by a dynamic analysis tool. A program is told dynamic when the whole code is not entirely visible from the initial textual description of the code and may cover assemble code, executable code (binary-level), javascript, etc.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Sultana in view of August with Bardin, to modify the method for control flow integrity of Sultana with the method for cooperative program code transformation of August with the partial control flow graph information analysis of Bardin. The motivation to do so, Bardin ¶ 11, for detecting obfuscation schemes, e.g. detecting that a branch is dead, or proving an absence, e.g. proving that a computed jump cannot lead to an improper address.
Regarding Claim(s) 2, 11 and 20 Sultana-August-Bardin teaches:
The method of claim 1, (Sultana-August-Bardin teaches the parent claim above.) wherein the portion of the learned CFDG comprises a set of system calls occurring prior to the indirect transfer. (Sultana ¶ 10 teaches, indirect branch instructions include, but are not limited to, jump instructions, function calls, function returns, interrupts, etc., that involve updating the instruction pointer from a register or a memory location. (i.e., a system call), Bardin ¶ 56 teaches, the nodes of the control flow graph represent instructions and the branches (or edges) represent links between the instructions.)
The motive given in Claim 1 is equally applicable to the above claim.
Regarding Claim(s) 3 and 12 Sultana-August-Bardin teaches:
The method of claim 1, (Sultana-August-Bardin teaches the parent claim above.) wherein determining the at least one destination is further based in part on system call information or functional call sequences. (Sultana ¶ 27 teaches, Control flow validator circuitry may be further configured to determine whether each constant and/or variable is used as an operand address of an indirect branch instruction. Thus, one or more target addresses of indirect branch instructions, e.g., an indirect call and/or indirect jump may be identified)
Regarding Claim(s) 4 and 13 Sultana-August-Bardin teaches:
The method of claim 1, (Sultana-August-Bardin teaches the parent claim above.) wherein the disassembler comprises a linear disassembler or a recursive disassembler. (Bardin ¶ 50, teaches a disassembler that can perform disassembly linearly, recursively, or dynamically.)
The motive given in Claim 1 is equally applicable to the above claim.
Regarding Claim(s) 5 and 14 Sultana-August-Bardin teaches:
The method of claim 1, (Sultana-August-Bardin teaches the parent claim above.) wherein providing the at least one destination comprises:
determining the at least one destination is a valid target and reachable; and
providing an indication that the at least one destination is the valid target to the disassembler for the indirect transfer. (Sultana ¶ 24 teaches, For example, one or more identifiable target addresses may be identified, statically. In another example, a set of possible identifiable target addresses may be determined for each indirect branch instruction that has associated identifiable but not uniquely identifiable target addresses. Thus, for each branch instruction, one identifiable target address may be identified, a set of identifiable target addresses may be identified or the branch instruction may be tagged with a not found tag, as described herein.)
Regarding Claim(s) 6 and 15 Sultana-August-Bardin eaches:
The method of claim 1, (Sultana-August-Bardin teaches the parent claim above.) wherein performing the disassembly comprises:
determining indirect transfers within the executable code; and (August Col. 6-7 Ln. 60-67 and 1-5 teaches, if the destination of an indirect jump instruction depends on some runtime condition, the statically disassembled code may be out of sync at the target of the indirect jump instruction. The determination is preferably made on the server side. In such cases, the server may be able to determine the possible targets of the jump instruction and convey this information to the clients in the hints. Based on hints about out of sync locations, the client-side disassembler can successfully disassemble program code. Col. Ln. 5 teaches, the client-side tool starts with the original binary without any additions or modifications. This binary is to be disassembled, transformed, and executed. During application run-time on the client, the original binary remains in memory to serve as a backup.)
providing the at least one destination as a valid target of the indirect transfer for the disassembly. (August Col. 6-7 Ln. 60-67 and 1-5 teaches, if the destination of an indirect jump instruction depends on some runtime condition, the statically disassembled code may be out of sync at the target of the indirect jump instruction. The determination is preferably made on the server side. In such cases, the server may be able to determine the possible targets of the jump instruction and convey this information to the clients in the hints. Based on hints about out of sync locations, the client-side disassembler can successfully disassemble program code. (i.e., provided destination for disassembly))
The motive given in Claim 1 is equally applicable to the above claim.
Regarding Claim(s) 9 and 18 Sultana-August-Bardin teaches:
The method of claim 1, (Sultana-August-Bardin teaches the parent claim above.) wherein the indirect transfer comprises an indirect jump, an indirect call, or an indirect transition. (Sultana ¶ 10 teaches, As used herein, indirect branch instructions include, but are not limited to, jump instructions, function calls, function returns, interrupts, etc.,)
Claim(s) 7 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sultana-August-Bardin in view of Marcuello (US 2004/0154010 A1), hereinafter Marcuello.
Regarding Claim(s) 7 and 16 Sultana-August-Bardin teaches:
The method of claim 1, (Sultana-August-Bardin teaches the parent claim above.)
Sultana-August-Bardin does not appear to explicitly teach but in related art:
wherein performing the disassembly comprises determining full coverage of the executable code based at least in part on the portion of the learned CFDG. (Marcuello ¶ 24 teaches, or at least one embodiment, the basic blocks are chosen from highest to lower execution count until a predetermined threshold percentage of the total executed instructions are included in the CFG 330. Accordingly, after weighting and pruning, the most frequently-executed basic blocks are represented in the CFG 330.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Sultana-August-Bardin with Marcuello, to modify the method for control flow integrity of Sultana with the method for cooperative program code transformation of August with the partial control flow graph information analysis of Bardin with the threshold amount of the CFG executed of Marcuello. The motivation to do so constitutes applying a known technique of determining an execution threshold to known devices and/or methods for control flow integrity ready for improvement to yield predictable results to determine when a satisfactory amount of information has been gathered.
Claim(s) 8 and 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sultana-August-Bardin in view of Farhady (US 2020/0162483 A1), hereinafter Farhady.
Regarding Claim(s) 8 and 17 Sultana-August-Bardin teaches:
The method of claim 1, (Sultana-August-Bardin teaches the parent limitation above.)
Sultana-August-Bardin does not appear to, but in related art, Farhady teaches:
wherein determining the learned control flow directed graph comprises observing at least a threshold percentage of the executable code. (Farhady ¶ 25 teaches, when the binary file is below the threshold then the binary is further analyzed.)
It would have been obvious to one with ordinary skill the art, prior to the applicant's earliest effective filing date, to combine the teachings of Sultana-August-Bardin with Farhady, t to modify the method for control flow integrity of Sultana with the method for cooperative program code transformation of August with the partial control flow graph information analysis of Bardin with the threshold limit of Farhady. The motivation to do so, Farhady ¶ 28, to provide malware detection that is reliable and accurate.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 12,340,188 B1 – A method for zero modification export hooking via A first request may be received from a loader to create a first file handle corresponding to a first library, where the first request may include a first identifier corresponding to the first library, and where the loader may be part of an operating system of a computer system.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACOB BENEDICT KNACKSTEDT whose telephone number is (703)756-5608. The examiner can normally be reached Monday-Friday 8:00 am - 5:00 pm.
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, Linglan Edwards can be reached on (571) 270-5440. 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.
/J.B.K./Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408
Prosecution Insights