DETAILED ACTION
The present application is being examined under the pre-AIA first to invent provisions.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Objections
Claims 8 and 17 are objected to because of the following informalities:
In Claim 8, line 2, the colon after “metadata” should be replaced by a semicolon or comma.
In Claim 17, line 2, the colon after “metadata” should be replaced by a semicolon or comma.
Appropriate correction is required.
Claim Rejections - 35 USC § 101
It is acknowledged that Applicant’s specification explicitly defines the term “computer readable storage medium” to exclude transitory signals (see paragraph 0020). Therefore, no rejection is set forth under 35 U.S.C. 101.
Claim Rejections - 35 USC § 112
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 attachment points” in line 6. There is not clear antecedent basis for plural attachment points in the claim. The claim further recites “in response to a determination that the metadata is validated against the policy and the integrity measurement is verified, loading the kernel extension code in the kernel state” in lines 9-11. First, the claim does not positively recite the determination that the metadata is validated and the integrity measurement is verified, and therefore, this appears to be a gap in the claim. Further, the claim does not recite what occurs when the metadata is not validated and/or the integrity measurement is not verified, which also constitutes a gap in the claim and/or an omission of essential subject matter. The above ambiguities render the claim indefinite.
Claim 2 recites “in response to a determination that the signature is verified, loading the kernel extension code in the kernel space”. First, the claim des not positively recite the determination that the signature is verified, and therefore, this appears to be a gap in the claim. Further, it is not clear whether the kernel extension is loaded a second time here, or if this is intended as a further limitation on when the kernel extension is loaded as recited in Claim 1.
Claim 3 recites “in response to a determination that the policy has been updated”. However, the claim does not positively recite such a determination of a policy update, and therefore, this appears to constitute a gap in the claim.
Claim 4 recites “in response to a determination that the metadata is not validated against the updated policy and/or the integrity measurement is not verified subsequent to the policy being updated”. The claim des not positively recite the determination that the metadata is not validated or the integrity measurement is not verified, and therefore, this appears to be a gap in the claim. Further, the use of “and/or” makes it unclear which elements are required to be present.
Claim 9 recites “in response to a determination that the metadata is not validated against the policy and/or the integrity measurement is not verified” in lines 2-3. The claim des not positively recite the determination that the metadata is not validated or the integrity measurement is not verified, and therefore, this appears to be a gap in the claim. Further, the use of “and/or” makes it unclear which elements are required to be present.
Claim 10 recites “the attachment points” in line 9. There is not clear antecedent basis for plural attachment points in the claim. The claim further recites “in response to a determination that the metadata is validated against the policy and the integrity measurement is verified, load the kernel extension code in the kernel state” in lines 12-14. First, the claim does not positively recite the determination that the metadata is validated and the integrity measurement is verified, and therefore, this appears to be a gap in the claim. Further, the claim does not recite what occurs when the metadata is not validated and/or the integrity measurement is not verified, which also constitutes a gap in the claim and/or an omission of essential subject matter. The above ambiguities render the claim indefinite.
Claim 11 recites “in response to a determination that the signature is verified, load the kernel extension code in the kernel space”. First, the claim des not positively recite the determination that the signature is verified, and therefore, this appears to be a gap in the claim. Further, it is not clear whether the kernel extension is loaded a second time here, or if this is intended as a further limitation on when the kernel extension is loaded as recited in Claim 10.
Claim 12 recites “in response to a determination that the policy has been updated”. However, the claim does not positively recite such a determination of a policy update, and therefore, this appears to constitute a gap in the claim.
Claim 13 recites “in response to a determination that the metadata is not validated against the updated policy and/or the integrity measurement is not verified subsequent to the policy being updated”. The claim des not positively recite the determination that the metadata is not validated or the integrity measurement is not verified, and therefore, this appears to be a gap in the claim. Further, the use of “and/or” makes it unclear which elements are required to be present.
Claim 9 recites “in response to a determination that the metadata is not validated against the policy and/or the integrity measurement is not verified” in lines 3-4. The claim des not positively recite the determination that the metadata is not validated or the integrity measurement is not verified, and therefore, this appears to be a gap in the claim. Further, the use of “and/or” makes it unclear which elements are required to be present.
Claim 19 recites “the attachment points” in line 11. There is not clear antecedent basis for plural attachment points in the claim. The claim further recites “in response to a determination that the metadata is validated against the policy and the integrity measurement is verified, load the kernel extension code in the kernel state” in lines 13-15. First, the claim does not positively recite the determination that the metadata is validated and the integrity measurement is verified, and therefore, this appears to be a gap in the claim. Further, the claim does not recite what occurs when the metadata is not validated and/or the integrity measurement is not verified, which also constitutes a gap in the claim and/or an omission of essential subject matter. The above ambiguities render the claim indefinite.
Claim 20 recites “in response to a determination that the signature is verified, load the kernel extension code in the kernel space”. First, the claim des not positively recite the determination that the signature is verified, and therefore, this appears to be a gap in the claim. Further, it is not clear whether the kernel extension is loaded a second time here, or if this is intended as a further limitation on when the kernel extension is loaded as recited in Claim 1.
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 (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); validating the metadata against the policy (column 9, lines 6-38, verifies policies); performing an integrity measurement on the kernel extension code (column 9, lines 13-38, validates signatures and hashes); 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, 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). 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).
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
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Ober et al, US Patent 6397331, discloses a method that authenticates kernel extensions using signatures.
Murase et al, US Patent 7886162, discloses a method that includes validating and authenticating kernel extensions.
Fitzgerald et al, US Patent 8234640, discloses a technique that performs policy enforcement using whitelists and blacklists.
Plouffe, Jr. et al, US Patent 8332635, discloses a method that includes validating kernel extensions.
Filali-Adib et al, US Patent 8397245, discloses a system that validates kernel extensions.
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