DETAILED ACTION
A response was received on 24 March 2026. By this response, Claims 1-5, 7-14, and 16-20 have been amended. No claims have been added or canceled. Claims 1-20 are currently pending in the present application.
Response to Arguments
Applicant's arguments filed 24 March 2026 have been fully considered but they are not persuasive.
Regarding the rejection of Claims 1-20 under 35 U.S.C. 103 as unpatentable over Moore et al, US Patent 12380215, in view of Sugandhi et al, US Patent 11354402, and with particular reference to amended independent Claim 1, Applicant argues that the art of record does not appear to teach or suggest and allowlist or blocklist that contain portions of types of metadata (page 12 of the present response, no evidence cited). Applicant has not provided any explanation or evidence in support of this assertion. Further, as detailed below, this new limitation is unclear and indefinite as to what is meant by a portion of a type of metadata. To the extent that this limitation can be interpreted, it is submitted that both Moore and Sugandhi disclose types of metadata (see Moore, column 8, line 64-column 9, line 38, as previously cited, describing metadata such as permissions, noting also various types of permissions, i.e. types of metadata, at column 9, line 51-column 10, line 8; see further Sugandhi, column 11, line 58-column 12, line 14, as previously cited, explicitly disclosing types of metadata), and at least Sughandi discloses allowlists and blocklists containing such metadata (see Sughandi, column 4, lines 3-63, as previously cited, where a whitelist and blacklist are used to validate metadata against a policy, where allowed or prevented programs are also types of metadata as claimed, noting that there are no limits in the claims on what constitutes a “type” of metadata). Therefore, at least in combination and to the extent the limitation can be interpreted, the cited prior art at least suggests an allowlist and blocklist that contain types of metadata.
Applicant also argues that the art of record does not appear to teach or suggest performing a measured boot by executing a cryptographic hash on program instructions and storing integrity measurements in a system log (page 12 of the present response, no evidence cited). Again, Applicant has not provided any explanation or evidence in support of this assertion. It is submitted that both Moore and Sughandi disclose integrity measurements include a measured boot matching cryptographic hashes of program instructions (see Moore, column 9, lines 13-38, as previously cited, signature and hash of boot processes and kernel code, i.e. program instructions; see also Sughandi, column 12, line 40-column 13, line 3, measuring computer instructions by hashing them during secure boot) and at least Moore discloses logging integrity measurements (see Moore, column 13, lines 3-38, each boot process is logged including results such as failure of booting and the which drivers or other software failed or caused errors). Therefore, at least in combination, the cited prior art at least suggests performing a measured boot by executing a cryptographic hash of program instructions and storing the integrity measurements in a system log.
Therefore, for the reasons detailed above, the Examiner maintains the rejections as set forth below.
Specification
The specification is objected to as failing to provide proper antecedent basis for the claimed subject matter. See 37 CFR 1.75(d)(1) and MPEP § 608.01(o). Correction of the following is required: Claims 7 and 16 have been amended to recite “the program instructions are in Extended Berkeley Packet Filter (eBPF)”. There is no mention in the specification of the term “Extended Berkeley Packet Filter” (although “eBPF” does appear) and there is no mention of instructions being “in eBPF”, which is also indefinite as detailed below. Therefore, there is not clearly proper antecedent basis for the claimed subject matter in the specification. See also the rejection under 35 U.S.C. 112(a) for failure to comply with the written description requirement.
Claim Objections
The objections to Claims 8 and 17 for informalities are withdrawn in light of the amendments thereto.
Claims 1, 10, and 19 are objected to because of the following informalities:
In Claim 1, lines 9 and 10, “contain” should read “contains” for agreement with the respective singular subjects “allowlist” and “blocklist”.
In Claim 10, lines 13 and 14, “contain” should read “contains” for agreement with the respective singular subjects “allowlist” and “blocklist”.
In Claim 19, lines 13 and 14, “contain” should read “contains” for agreement with the respective singular subjects “allowlist” and “blocklist”.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The rejection of Claims 1-20 under 35 U.S.C. 112(b) as indefinite is NOT withdrawn, because not all issues have been addressed and/or because the amendments have raised new issues, as detailed below.
The following is a quotation 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 7 and 16 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 claims contain 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.
Claims 7 and 16 have been amended to recite “the program instructions are in Extended Berkeley Packet Filter (eBPF)”. Applicant has pointed to paragraphs 0046, 0048, and 0052 of the specification for support of the claims as amended (see page 12 of the present response, in reference to amended independent Claim 1). However, there is no mention in these paragraphs or elsewhere in the specification of the term “Extended Berkeley Packet Filter” (although “eBPF” does appear in paragraph 0049 without being defined). There is also no mention in these paragraphs or elsewhere in the specification of instructions being “in eBPF”, which is also indefinite as detailed below. Therefore, there is not clearly sufficient written description of the claimed subject matter in the specification.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites “the allowlist contain [sic] portions of the types of metadata that are to be allowed” and “the blocklist contain [sic] portions of the types of metadata that are to be or blocked” in lines 9-11. It is not clear what is meant by a portion of a type in this context, or how the allowlist or blocklist could contain a portion of a type of metadata. It does not appear that a “type” is something that could be divided into portions. For purposes of interpreting the prior art, these limitations have been interpreted as the lists containing types of metadata that are to be allowed or blocked, respectively. Further, the phrase “are to be or blocked” is grammatically unclear, although it appears that “or” should be deleted from this phrase. The claim further recites “in response to the metadata being validated against the policy and the integrity measurement being verified, loading the kernel extension code in the kernel state” in lines 17-19. However, the claim does not recite what occurs when the metadata is not validated and/or the integrity measurement is not verified, which constitutes a gap in the claim and/or an omission of essential subject matter. The above ambiguities render the claim indefinite.
Claim 2 recites “preforming the loading of the kernel extension code” in lines 3-4. It is not clear how loading a kernel extension could be “preformed” (or “formed” for that matter). It appears that this may be intended to read “performing”.
Claim 4 recites “in response to the metadata not being validated against the updated policy and the integrity measurement is not verified subsequent to the policy being updated” in lines 1-4. It is not grammatically clear what the phrase “and the integrity measurement is not verified” is intended to modify or be coordinated with, nor is it clear how this phrase relates grammatically to the remainder of the claim.
Claim 7 recites “the program instructions are in Extended Berkeley Packet Filter” in lines 3-4. First, it is not clear whether the limitation “the program instructions” is intended to refer to the program instructions of Claim 1, line 15, or the instructions of Claim 7, line 3. Further, it is not clear what is meant by the phrase that the instructions “are in… eBPF”. In context, it is not clear how instructions could be in the eBPF.
Claim 9 recites “in response to the metadata not being validated against the policy and the integrity measurement is not verified” in lines 2-3. It is not grammatically clear what the phrase “and the integrity measurement is not verified” is intended to modify or be coordinated with, nor is it clear how this phrase relates grammatically to the remainder of the claim.
Claim 10 recites “the allowlist contain [sic] portions of the types of metadata that are to be allowed” and “the blocklist contain [sic] portions of the types of metadata that are to be or blocked” in lines 13-15. It is not clear what is meant by a portion of a type in this context, or how the allowlist or blocklist could contain a portion of a type of metadata. It does not appear that a “type” is something that could be divided into portions. For purposes of interpreting the prior art, these limitations have been interpreted as the lists containing types of metadata that are to be allowed or blocked, respectively. Further, the phrase “are to be or blocked” is grammatically unclear, although it appears that “or” should be deleted from this phrase. The claim further recites “in response to the metadata being validated against the policy and the integrity measurement being verified, load the kernel extension code in the kernel state” in lines 21-23. However, the claim does not recite what occurs when the metadata is not validated and/or the integrity measurement is not verified, which constitutes a gap in the claim and/or an omission of essential subject matter. The above ambiguities render the claim indefinite.
Claim 11 recites “preform the load of the kernel extension code” in lines 5-6. It is not clear how loading a kernel extension could be “preformed” (or “formed” for that matter). It appears that this may be intended to read “perform”.
Claim 13 recites “in response to the metadata not being validated against the updated policy and the integrity measurement is not verified subsequent to the policy being updated” in lines 3-6. It is not grammatically clear what the phrase “and the integrity measurement is not verified” is intended to modify or be coordinated with, nor is it clear how this phrase relates grammatically to the remainder of the claim.
Claim 16 recites “the program instructions are in Extended Berkeley Packet Filter” in lines 3-4. First, it is not clear whether the limitation “the program instructions” is intended to refer to the program instructions of Claim 10, line 19, or the instructions of Claim 16, line 3. Further, it is not clear what is meant by the phrase that the instructions “are in… eBPF”. In context, it is not clear how instructions could be in the eBPF.
Claim 18 recites “in response to the metadata not being validated against the policy and the integrity measurement is not verified” in lines 3-5. It is not grammatically clear what the phrase “and the integrity measurement is not verified” is intended to modify or be coordinated with, nor is it clear how this phrase relates grammatically to the remainder of the claim.
Claim 19 recites “the allowlist contain [sic] portions of the types of metadata that are to be allowed” and “the blocklist contain [sic] portions of the types of metadata that are to be or blocked” in lines 13-15. It is not clear what is meant by a portion of a type in this context, or how the allowlist or blocklist could contain a portion of a type of metadata. It does not appear that a “type” is something that could be divided into portions. For purposes of interpreting the prior art, these limitations have been interpreted as the lists containing types of metadata that are to be allowed or blocked, respectively. Further, the phrase “are to be or blocked” is grammatically unclear, although it appears that “or” should be deleted from this phrase. The claim further recites “in response to the metadata being validated against the policy and the integrity measurement being verified, loading the kernel extension code in the kernel state” in lines 21-23. However, the claim does not recite what occurs when the metadata is not validated and/or the integrity measurement is not verified, which constitutes a gap in the claim and/or an omission of essential subject matter. The above ambiguities render the claim indefinite.
Claim 20 recites “preform the loading of the kernel extension code” in lines 3-4. It is not clear how loading a kernel extension could be “preformed” (or “formed” for that matter). It appears that this may be intended to read “perform”.
Claims not explicitly referred to above are rejected due to their dependence on a rejected base claim.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Moore et al, US Patent 12380215, in view of Sugandhi et al, US Patent 11354402.
In reference to Claims 1 and 9, Moore discloses a method that includes receiving a policy, kernel extension code, and metadata at a kernel space from a user space, where the metadata describes a type of attachment point in the kernel space and there are types of metadata to be allowed or blocked, where the kernel extension code and metadata are received independently (column 8, line 64-column 9, line 38, verifies kernel extensions and security policies as well as metadata such as permissions, noting that the attachment point may be the function that is invoked or the kernel as per the present specification; see also column 9, line 51-column 10, line 8, describing types of permissions, i.e. types of metadata); validating the metadata against the policy (column 9, lines 6-38, verifies policies); performing an integrity measurement on the kernel extension code where the integrity measurement includes performing a measured boot by executing a cryptographic hash of program instructions and storing the measurements in a system log (column 9, lines 13-38, validates signatures and hashes of boot processes and kernel code; column 13, lines 3-38, logging each boot process); and if the metadata is validated against the policy and the integrity measurement is verified, loading the kernel extension code in the kernel space and if not, preventing loading (again, see column 8, line 64-column 9, line 38, noting also column 4, line 60-column 5, line 24, where the boot status marker sets whether a driver or extension will be allowed to load or be blocked). However, Moore does not explicitly disclose an allowlist and blocklist.
Sugandhi discloses a method that includes receiving a policy and metadata, where the metadata describes a type of attachment point, where the policy includes a blocklist and allowlist for metadata that include types of metadata that are to be allowed and blocked, respectively; and validating the metadata against the policy (column 4, lines 3-63, whitelist and blacklist; column 11, line 58-column 12, line 14, validating metadata against policy including validating environment type), as well as performing a measured boot by executing a cryptographic hash of program instructions (column 12, line 40-column 13, line 3, measuring computer instructions by hashing them during secure boot). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Moore to include the blocklist and allowlist of Sugandhi, in order to provide additional code integrity protections (see Sugandhi, column 4, lines 3-15).
In reference to Claim 2, Moore and Sugandhi further disclose performing a verification of a signature and loading the kernel extension code if the signature is verified (Moore, column 9, lines 13-38).
In reference to Claims 3-5, Moore and Sugandhi further disclose validating the metadata when the policy has been updated based on a trigger such as initiation of a boot phase and performing the integrity measurement after the update (see Sugandhi, column 12, line 29-column 13, line 3, verifying at boot) as well as unloading kernel extension when the metadata is not validated or the integrity measurement is not verified (Moore, column 8, line 64-column 9, line 38).
In reference to Claims 6 and 7, Moore and Sugandhi further disclose iteratively verifying different types of metadata including program type or instructions (see Sugandhi, column 11, line 58-column 12, line 28) as well as instructions to be executed in a sandbox (see Sughandi, column 12, line 29-column 13, line 3).
In reference to Claim 8, Moore and Sugandhi further disclose the blocklist details restricted metadata including a location, function, and identity (see Sugandhi, column 4, lines 3-63).
Claims 10-18 are directed to software implementations of the methods of Claims 1-9, and are rejected by a similar rationale.
Claims 19 and 20 are directed to systems having functionality corresponding substantially to the methods of Claims 1 and 2, and are rejected by a similar rationale, mutatis mutandis.
Conclusion
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 Zachary A Davis whose telephone number is (571)272-3870. The examiner can normally be reached Monday-Friday, 9:00am-5:30pm, Eastern Time.
Examiner interviews are available via telephone 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, Rupal D Dharia can be reached at (571) 272-3880. 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.
/Zachary A. Davis/Primary Examiner, Art Unit 2492
Prosecution Insights