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 . This office action is in response to the amendment filed on 12/22/2025. Claims 1, 3-4, 6-7, 9-10, and 12-13 are currently pending in the filing of 12/22/2025. Claims 5 and 11 were cancelled in the previous response / amendment filed 5/27/2025. Claims 2 and 8 are presently cancelled in the present response / amendment filed 12/22/2025.
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/22/2025 has been entered.
Response to Applicant’s Amendments / Arguments Regarding 35 U.S.C. § 103
The applicant’s remarks, on pages 6-9 of the response / amendment, the applicant argues the features which allegedly distinguish over the previously cited references cited in the 35 U.S.C. § 103 rejections.
Applicant’s arguments have been considered but are moot in view of the new ground(s) of rejection.
Claim Interpretation under U.S.C. 112(f):
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term "means" or "step" or a term used as a substitute for "means" that is a generic placeholder (also called a nonce term or a nonstructural term having no specific structural meaning) for performing the claimed function;
(B) the term "means" or "step" or the generic placeholder is modified by functional language, typically, but not always linked by the transition word "for" (e.g., "means for'') or another linking word or phrase, such as "configured to" or "so that"; and
(C) the term "means" or "step" or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word "means" (or "step") in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word "means" (or "step") in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
This application includes one or more claim limitations that do not use the word "means," but are nonetheless being interpreted under 35 U.S.C. 112(f) because the claim limitations uses a generic placeholder.
First, (e.g., policy management unit) that is coupled with functional language (e.g., " ... for generating and managing a security policy ... ") without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such limitations are in claim 1. Because these claim limitations are being interpreted under 35 U.S.C. 112(f), they are being interpreted to cover the corresponding structure described in the specification (e.g., the structural/physical connections shown in fig. 1 and paragraphs [0041] of the applicant’s printed publication.) as performing the claimed functions, and equivalents thereof.
Second, (e.g., policy enforcement unit) that is coupled with functional language (e.g., " ... for checking the set of rules ... ") without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such limitations are in claim 1. Because these claim limitations are being interpreted under 35 U.S.C. 112(f), they are being interpreted to cover the corresponding structure described in the specification (e.g., the structural/physical connections shown in paragraphs fig. 1 and paragraphs [0041] of the applicant’s printed publication.) as performing the claimed functions, and equivalents thereof.
Third, (e.g., policy operation decision unit) that is coupled with functional language (e.g., " ... for enforcing the policy received from ... ") without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such limitations are in claim 1. Because these claim limitations are being interpreted under 35 U.S.C. 112(f), they are being interpreted to cover the corresponding structure described in the specification (e.g., the structural/physical connections shown in fig. 1 and paragraphs [0041] of the applicant’s printed publication.) as performing the claimed functions, and equivalents thereof.
Fourth, (e.g., filtering unit) that is coupled with functional language (e.g., " ... for determining whether the received policy violates ... ") without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such limitations are in claim 1. Because these claim limitations are being interpreted under 35 U.S.C. 112(f), they are being interpreted to cover the corresponding structure described in the specification (e.g., the structural/physical connections shown in figs. 2 and 4 and paragraphs [0093] of the applicant’s printed publication.) as performing the claimed functions, and equivalents thereof.
Fifth, (e.g., kernel context pre-processing unit) that is coupled with functional language (e.g., " ... for pre-processing a kernel context necessary to ... ") without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such limitations are in claim 1. Because these claim limitations are being interpreted under 35 U.S.C. 112(f), they are being interpreted to cover the corresponding structure described in the specification (e.g., the structural/physical connections shown in paragraphs figs. 2 and 4 and paragraphs [0093] of the applicant’s printed publication.) as performing the claimed functions, and equivalents thereof.
Sixth, (e.g., parsing unit) that is coupled with functional language (e.g., " ... for parsing a condition ... ") without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such limitations are in claim 1. Because these claim limitations are being interpreted under 35 U.S.C. 112(f), they are being interpreted to cover the corresponding structure described in the specification (e.g., the structural/physical connections shown in figs. 2 and 4 and paragraphs [0093] of the applicant’s printed publication.) as performing the claimed functions, and equivalents thereof.
Seventh, (e.g., operation unit) that is coupled with functional language (e.g., " ... for generating a return value for ... ") without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such limitations are in claim 1. Because these claim limitations are being interpreted under 35 U.S.C. 112(f), they are being interpreted to cover the corresponding structure described in the specification (e.g., the structural/physical connections shown in figs. 2 and 4 and paragraphs [0093] of the applicant’s printed publication.) as performing the claimed functions, and equivalents thereof.
If applicant does not intend to have these limitations interpreted under 35 U.S.C.
112(f), applicant may: (1) amend the claim limitations to avoid them being interpreted under 35 U.S.C. 112(f) (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitations recite sufficient structure to perform the claimed function so as to avoid them being interpreted under 35 U.S.C. 112(f).
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 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.
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.
Claims 1, 3-4, 6-7, 9-10, and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over NPL - BPFCONTAIN: Fixing the Soft Underbelly of Container Security, to Findlay et al. 2021 (hereinafter Findlay) and US 20230066013 to Ball (hereinafter Ball), in view of US 20220129539 to Walsh et al. (hereinafter Walsh).
Regarding claim 1, Findlay teaches,
A dynamic security policy enforcement system for a container system comprising: (Title and Abstract teaches Linux containers and BFPContain)
a policy management unit for generating and managing a security policy for a container based on a structured format including a set of rules of a predetermined condition; (Abstract teaches flexible language policy and containers with separate namespaces. Page 3, col. 2, extended BPF. Page 6, col. 2, Listing 4.2 teaches policy including rules.)
a policy enforcement unit for checking the set of rules when the container requests a system call, (Page 3, col. 2, extended BPF makes system calls, with program safety verifier. Page 4, col. 1, first paragraph teaches checking eBPF to ensure it conforms to safety. See also page 3, Col 1, “System Call Filtering” security concerns) changing the security policy of the structured format into a code in a preset format, and (page 3, col. 2, last two full paragraphs, teach compiling native instructions. Page 3, col. 2, last partial paragraph teaches front end that compiles eBPF code, where front end is shown in fig. 2.2.) transferring the policy changed into the code to a kernel space; and (fig. 2.2, front end transfers eBPB(2) into kernel space. See also, fig. 3.1, updates (2).)
a policy operation decision unit for enforcing the policy received from the policy enforcement unit in the kernel space (page 4, col. 2, second full paragraph teaches policy enforcement in the kernel. See also fig. 2.2 and fig. 3.1, which includes enforce privilege (5).) (The examiner interprets this language as the “policy operation decision unit” in the kernel space, in accordance with fig. 1 of the application.) based on a policy enforcement program that hooks the system call (page 7, col. 2, last two paragraphs to page 8, col. 1 first full paragraph, teaches enforcing policy and LSM hooks.) and generating a return value for performing a predetermined operation. (page 7, col. 2, last two paragraphs teach denying access. See also page 6, col. 1, second full paragraph teaching the default denying of access of security sensitive resources.)
wherein the policy operation decision unit comprises,
a filtering unit for determining whether the received policy violates a security policy and passing a corresponding container based on a result of the determination; (page 1, col. 2, last paragraph, teaches extension of Berkeley Packet Filter (eBPF), which is filtering. Fig. 2.2 teaches eBPF programs in the kernel space. Abstract teaches the BPFContain utilizes containers for enforcement.)
a kernel context pre-processing unit for pre-processing a kernel context necessary to determine a validity of a path object included in a specific container if the security policy is not violated; (Page 6, col. 1, first paragraph, teaches BPFContain that enforces policy including pathnames. Page 2, col. 1, first full paragraph teaches that BPFContain attaches eBPF programs to hooks and functions within the kernel to enforce policy in the kernel space. Page 1, col. 2, last paragraph teaches load time verification.) (see also, Ball, further discussed below, which also teaches the flow context being used to pass / load data into memory at [0113], describing fig. 4B. Specifically, [0111-113] teach parsing iteratively, until the appropriate level is reached, where the kernel datapath is processed for decision making in [0112], where [0113] teaches learning from the parsing and applying the learning to additional received information. See discussion of [0111-112] of Ball below.)
wherein the security policy is dynamically applicable to the container in all states including . (Findlay, page 7, col. 2, last two paragraphs teach denying access to a running program that makes calls to the system kernel.)
Findlay does not appear to teach parsing in the kernel space,
However, Ball teaches,
a parsing unit for parsing a condition included in the pre-processed kernel context; and ([0111] describing fig. 4B, see also at least [0049]. Specifically, [0111-113] teach parsing iteratively, until the appropriate level is reached, where the kernel datapath is processed for decision making in [0112], where [0113] teaches learning from the parsing and applying the learning to additional received information. See discussion of [0111-112] of Ball below.)
an operation unit for generating a return value for performing a predetermined operation based on an operation according to the parsed condition, ([0112] teaches the eBPF XDP program 86 of fig. 4B in the kernel space performing operations without needing to access the user space.) (Findlay also teaches parsing in the description of fig. 3.1 on page 5, and teaches performing operations based on these conditions, as discussed above in the rejection of claim 1.)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine the teachings of Findlay, which teaches eBPF filtering and enforcement of security policies on containers located within the kernel space in order to prevent accessing of restricted resources within the kernel space (page 2), with Ball, which also teaches eBPF filtering and enforcement ([0108]) of policies, and additionally teaches parsing of data in the kernel space and enforcement of data paths by the kernel program ([0108-114]). One of ordinary skill in the art would have been motivated to perform such an addition to provide Findlay with the added ability to perform parsing of information and data path to determine whether to process further packets, as taught by Ball, for the purpose of increasing computational efficiency, by reducing data swaps to the user space ([0112]), while increasing security by the use of eBPF containment.
Findlay and Ball fail to explicitly teach security policy being applied to the container at an before the container is started,
However, Walsh teaches,
wherein the security policy is dynamically applicable to the container in all states including an initialization state and a running state. ([0029-31] teaches using eBPF programs \ tracing tool 320 throughout the lifecycle of the container, to enforce privileges on the container to prevent access to particular calls ([0028]) by limiting \ restricting the calls necessary for the operation of the function. [0029] teaches tracing tool 320 / eBPF that is used before the container is started to trace early system calls.)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine the teachings of Findlay, which teaches eBPF filtering and enforcement of security policies on containers located within the kernel space in order to prevent accessing of restricted resources within the kernel space (page 2), with Ball, which also teaches eBPF filtering and enforcement ([0108]) of policies, and additionally teaches parsing of data in the kernel space and enforcement of data paths by the kernel program ([0108-114]), with Walsh, which also teaches container security settings / rules (Abstract), and using eBPF to enforce containers privileges ([0028-31]), and additionally teaches the use of extended Berkely Packet Filter eBPF programs \ tracing tool 320 throughout the lifecycle of the container by tracing and restricting the container / VM, even before the container is started, to only the privileges assigned to the container ([0029-31]). One of ordinary skill in the art would have been motivated to perform such an addition to provide Findlay and Ball with the added ability to utilize security policies throughout the lifecycle of the container to prevent accessing / overwriting of memory that is not allocated to the container, as taught by Walsh, for the purpose of increasing security while increasing computational efficiency by implementing the policies at certain points, such as hooks ([0029]).
Regarding claim 3, Findlay, Ball, and Walsh teach,
The dynamic security policy enforcement system of claim 1,
wherein the set of rules of a predetermined condition is one of a system call rule set including a name of a system call (Findlay, page 7, col. 2, sec. 4.4. teaches policy which includes “allow” that enforces policy using LSM hooks.) and an LSM probe rule set including a name of an LSM function. (Page 2, col. 1, first partial paragraph, teaches LSM hooks allowing eBPF code to implement kernel level security.)
Regarding claim 4, Findlay, Ball, and Walsh teach,
The dynamic security policy enforcement system of claim 1,
wherein the policy enforcement program is a hooking program using an LSM (Linux Security Module) hooking technology. (Findlay, page 2, col. 1, first partial paragraph, teaches LSM hooks allowing eBPF code to implement kernel level security.)
Regarding claim 6, Findlay, Ball, and Walsh teach,
The dynamic security policy enforcement system of claim 1,
wherein the policy management unit and the policy enforcement unit are provided in a user space, and the policy operation decision unit is provided in a kernel space. (Findlay, figs. 2.2 and 3.1, User Space includes Policy, BPF Contain Daemon, Confined Applications. Kernel Space includes the Verifier and eBPF programs.)
Regarding claim 7, Findlay, Ball, and Walsh teach,
A dynamic security policy enforcement method for a container system performed by a dynamic security policy enforcement system comprising:
a step of generating and managing a security policy for a container based on a structured format including a set of rules of a predetermined condition;
a step of checking the set of rules when the container requests a system call and changing the security policy of the structured format into a code in a preset format based on the checked set of rules;
a step of transferring the policy changed into the code to a kernel space;
a step of enforcing the policy received from the step of transferring to the kernel space based on a policy enforcement program that hooks the system call; and
a step of generating a return value for performing a predetermined operation corresponding to a result of the enforcing,
wherein the step of enforcing the policy comprises,
a step of determining whether the received policy violates a security policy and passing a corresponding container based on a result of the determination;
a step of pre-processing a kernel context necessary to determine a validity of a path object included in a specific container if the security policy is not violated; and
a step of parsing a condition included in the pre-processed kernel context,
wherein the step of generating the return value comprises generating a return value for performing a predetermined operation based on an operation according to the parsed condition,
wherein the security policy is dynamically applicable to the container in all states including an initialization state and a running state.
Claim 7 is rejected using the same basis of arguments used to reject claim 1 above.
Regarding claim 9, Findlay, Ball, and Walsh teach,
The dynamic security policy enforcement system of claim 7, wherein the set of rules of the predetermined condition is one of a system call rule set including a name of a system call and an LSM probe rule set including a name of an LSM function.
Claim 9 is rejected using the same basis of arguments used to reject claim 3 above.
Regarding claim 10, Findlay, Ball, and Walsh teach,
The dynamic security policy enforcement method of claim 7,
wherein the policy enforcement program is a hooking program using an LSM (Linux Security Module) hooking technology.
Claim 10 is rejected using the same basis of arguments used to reject claim 4 above.
Regarding claim 12, Findlay, Ball, and Walsh teach,
The dynamic security policy enforcement method of claim 7, wherein the step of generating and managing the security policy, the step of changing the security policy into the code in the preset format and the step of transferring the policy changed into the code to the kernel space are performed in a user space, and the step of enforcing the received policy and the step of generating the return value are performed in a kernel space.
Claim 12 is rejected using the same basis of arguments used to reject claim 6 above.
Regarding claim 13, Findlay, Ball, and Walsh teach,
A computer-readable storage medium, on which a computer program for executing the dynamic security policy enforcement method of claim 7 is recorded. (Findlay, fig. 2.2, teaches front end for compiling eBPF code.)
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRIAN WILLIAM AVERY whose telephone number is (571) 272-3942. The examiner can normally be reached on 9AM-5PM.
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, Farid Homayounmehr can be reached on (571) 272-3739.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/B.W.A./
/FARID HOMAYOUNMEHR/Supervisory Patent Examiner, Art Unit 2495