DETAILED 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 .
This Office Action is in response to the Amendment filed on 03/24/2026. In the instant Amendment, claims 1, 9, and 17 have been amended. Claims 7-8 and 15-16 have been cancelled without prejudice. Claims 2, 5-6, 10, 13-14, and 18 were previously cancelled. Claims 1, 9 and 17 are independent claims. Claims 1, 3-4, 9, 11-12, , and 17 have been examined and are pending. This Action is made FINAL.
Response to Arguments
The claim interpretation under 35 U.S.C. § 112(f) is maintained as the claims recite means-plus functions.
Applicant’s arguments in the instant Amendment, filed on 03/24/2026, with respect to the prior-art rejections to claims 1, 9, and 17, and limitation listed below, have been fully considered but they are not persuasive.
As to independent claims 1, 9, and 17, Applicants stated in arguments that XU does not disclose or suggest generating and applying a hot patch to remediate a kernel vulnerability while allowing the affected container to continue executing (Applicant Arguments/Remarks, 03/24/2026, page 8).
The Examiner disagrees with the Applicants. The Examiner respectfully that the combination of XU and LI do disclose the cited limitations. For example, XU discloses wherein the hot patch configuring unit configures an eBPF-based hot patch code so that a patching code for CVE (Common Vulnerabilities and Exposures), which is a kernel vulnerability, can be patched to a kernel space used by the target container (XU: page 6, par 8; the Kubelet component 401 is controlled to expel the target container; page 6, par 11 – page 7, par 2; the processor 300 searches the target container corresponding to the identity identification information ID and the target container is marked as a stain container, recording the target container 402 to execute the expelling operation through the controller 500 [] so as to prevent the problem of vulnerability or safety; page 7, par 4; the detector (i.e., the eBPF-user) 200 compiles the interception rule (i.e., the preset rule) of the eBPF from the pod to the operation "mvrunc .. /runc" [i.e., generate an eBPF-based hot patch code], which covers the runc. The command of the runc operation is extracted by writing the corresponding eBPF code; page 8, par 6; by eBPF for adjusting the kernel function [i.e., kernel vulnerability and remediate kernel vulnerability] in time capture the container operation, safety the container reliable safety, providing the safety k8s of the cloud original environment),
As to independent claims 1, 9, and 17, Applicants stated in arguments that LI does not disclose any container-aware logic or namespace-based isolation and neither XU nor LI teaches or suggests such conditional, namespace-restricted kernel patching (Applicant Arguments/Remarks, 03/24/2026, pages 8-9).
The Examiner carefully reviewed the currently amended claims. The Examiner unable to find “container-aware logic or namespace-based isolation” and “namespace-restricted kernel patching” from the currently amended claims. The currently amended claim limitation recited “a container-aware code” and “wherein the container-aware code includes a mount namespace ID (Identifier).”
Claim Interpretation
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 following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
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) or pre-AIA 35 U.S.C. 112, sixth paragraph, 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 non-structural 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) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, 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) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
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) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are: “container-aware code generating unit [] generating” recited in claims 1 and 3; “hot patch configuring unit [] attaching/patching” recited in claim 1.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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, 9, 11, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over XU et al. (“XU,” CN 113504971 A, published on 10/15/2021) in view of LI et al. (“LI,” CN 115268983 A, filed on 08/09/2022).
Regarding Claim 1;
XU discloses an eBPF(Extended Berkeley Packet Filter)-based hot patch engine device for protecting kernel vulnerabilities comprising (page 5, pars 2-3; eBPF the virtual machine 100 monitors the operation behaviour of different container operation, to detect the operation data of the container. step 104, the detector 200 determines the dangerous action information in the operation data based on the preset rule, and obtains the identity identification information ID of the corresponding container based on the dangerous action information):
a container-aware code generating unit for generating a container-aware code for identifying a target container, to which a hot patch is attached (page 5, par 4; the processor 300 looks up the target container 402 (the target container 402 is the container 402a, ..., one or more of the container 402n) corresponding to the identity identification information ID and marks the target container 402 as a taint container; page 7, pars 4-5; the detector (i.e., the eBPF-user) 200 compiles the interception rule (i.e., the preset rule) of the eBPF from the pod to the operation "mvrunc .. /runc", which covers the runc. The command of the runc operation is extracted by writing the corresponding eBPF code. Next, the eBPF -user obtains the ID of the corresponding container , and reports the ID to the processor (ebpf-controller) 300. eBPF-controller searches the target container corresponding to the ID in the k8s, and the target container is marked as stain container); and
a hot patch configuring unit for configuring an eBPF-based hot patch code for attaching a hot patch to the target container based on the container-aware code (page 6, par 8; the Kubelet component 401 is controlled to expel the target container; page 6, par 11 – page 7, par 1; the processor 300 searches the target container corresponding to the identity identification information ID and the target container is marked as a stain container, recording the target container 402 to execute the expelling operation through the controller 500 [] so as to prevent the problem of vulnerability or safety; page 7, par 8; in response to the edit input instruction (the user terminal automatically editing the formed instruction in the detector 200), and determining the dangerous behavior information in the mirror image information based on the relationship between the safety of the operation behavior in the preset rule and the operation content of the container),
wherein the hot patch configuring unit configures an eBPF-based hot patch code so that a patching code for CVE (Common Vulnerabilities and Exposures), which is a kernel vulnerability, can be patched to a kernel space used by the target container (XU: page 6, par 8; the Kubelet component 401 is controlled to expel the target container; page 6, par 11 – page 7, par 2; the processor 300 searches the target container corresponding to the identity identification information ID and the target container is marked as a stain container, recording the target container 402 to execute the expelling operation through the controller 500 [] so as to prevent the problem of vulnerability or safety; page 7, par 4; the detector (i.e., the eBPF-user) 200 compiles the interception rule (i.e., the preset rule) of the eBPF from the pod to the operation "mvrunc .. /runc" [i.e., generate an eBPF-based hot patch code], which covers the runc. The command of the runc operation is extracted by writing the corresponding eBPF code; page 8, par 6; by eBPF for adjusting the kernel function [i.e., kernel vulnerability and remediate kernel vulnerability] in time capture the container operation, safety the container reliable safety, providing the safety k8s of the cloud original environment),
wherein the hot patch configuring unit configures the eBPF-based hot patch code by loading a preset hot patch template and inputting information included in the patching code and the container-aware code into the hot patch template (page 6, par 8; the Kubelet component 401 is controlled to expel the target container; page 6, par 11 – page 6, par 1; the processor 300 searches the target container corresponding to the identity identification information ID and the target container is marked as a stain container, recording the target container 402 to execute the expelling operation through the controller 500 [] so as to prevent the problem of vulnerability or safety; page 8, par 3; the processor 300 is provided with a black and white list [i.e., hot patch template] for isolating the target container 402, so that the Kubelet component 401 according to the black and white list to the target container 402 performs isolation operation),
the device further comprises, a hot patch control unit for patching the hot patch code to a kernel space used by the target container using a BPF system call and receiving a notification when a vulnerability of the patched hot patch code is triggered (page 8, par 6; real-time detecting and analyzing the operation state of the whole k8s, to alarm for the presence of the safety container, when the attack behaviour occurs, the embodiment calls the kernel function of the operating system; by eBPF for adjusting the kernel function in time capture the container operation, safety the container reliable safety, providing the safety k8s of the cloud original environment; page 5, par 11; the processor 300 searches the target container corresponding to the identity identification information ID and the target container is marked as a stain container, recording the target container 402 to execute the expelling operation through the controller; page 7, par 8; in response to the edit input instruction (the user terminal automatically editing the formed instruction in the detector 200), and determining the dangerous behavior information in the mirror image information based on the relationship between the safety of the operation behavior in the preset rule and the operation content of the container),
wherein the device allows the hot patch code to be individually patched only in the target container using a corresponding kernel space, and a container system to be executable (XU: page 8, par 6; real-time detecting and analyzing the operation state of the whole k8s, to alarm for the presence of the safety container, when the attack behaviour occurs, the embodiment calls the kernel function of the operating system; by eBPF for adjusting the kernel function in time capture the container operation, safety the container reliable safety, providing the safety k8s of the cloud original environment; page 5, par 11 – page 6, par 1; the processor 300 searches the target container corresponding to the identity identification information ID and the target container is marked as a stain container, recording the target container 402 to execute the expelling operation through the controller [] detect the operation behavior of the pod in the kernel layer, so as to perform the expelling operation to the pod. so as to ensure the container in operation is safety reliable container, preventing the attacker from using container with dangerous action to attack; page 7, par 8; in response to the edit input instruction (the user terminal automatically editing the formed instruction in the detector 200), and determining the dangerous behavior information in the mirror image information based on the relationship between the safety of the operation behavior in the preset rule and the operation content of the container),
wherein the container-aware code includes a mount namespace ID (Identifier) (XU: page 5, par 4; the processor 300 looks up the target container 402 (the target container 402 is the container 402a, ..., one or more of the container 402n) corresponding to the identity identification information ID and marks the target container 402 as a taint container; page 7, pars 4-5; the detector (i.e., the eBPF-user) 200 compiles the interception rule (i.e., the preset rule) of the eBPF from the pod to the operation "mvrunc .. /runc", which covers the runc. The command of the runc operation is extracted by writing the corresponding eBPF code. Next, the eBPF -user obtains the ID of the corresponding container , and reports the ID to the processor (ebpf-controller) 300. eBPF-controller searches the target container corresponding to the ID in the k8s, and the target container is marked as stain container).
XU discloses receiving an alarm as recited above, but do not explicitly disclose receiving a notification when a vulnerability of the patched hot patch code is triggered.
However, in an analogous art, LI discloses device vulnerability system/method that includes:
receiving a notification when a vulnerability of the patched hot patch code is triggered (LI: page 7, par 6 – page 8, par 1; the eBPF Filter Patch code written for CVE-2020-17443 in the present invention is shown in the "eBPF Filter Patch" part in FIG. 3 [] check whether the value is legal, that is, whether it is possible to trigger the vulnerability. if detecting the malicious input of the trigger vulnerability, eBPF filter code will return the error operation code and optional return address [] the return value of the repair code will be strictly limited to OP-PASS, OP-REDIRECT and OP-DROP three kinds of operation code: OP-PASS represents the input is legal, the vulnerability is not triggered; OP-REDIRECT and OP-DROP represent input illegal).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of LI with the method/system of XU to include receiving a notification when a vulnerability of the patched hot patch code is triggered. One would have been motivated to automatically adapted and compiled by the Toolchain to all the firmware present with the vulnerability (LI: page 5, par 5).
Regarding Claim 3;
The combination of XU and LI disclose the device of claim 1,
XU discloses wherein the container- aware code generating unit generates the container-aware code based on container information included in a container system, wherein the container information includes at least one of a container ID (identifier) and container runtime information included in the container system (XU: page 5, par 4; the processor 300 looks up the target container 402 (the target container 402 is the container 402a, ..., one or more of the container 402n) corresponding to the identity identification information ID and marks the target container 402 as a taint container; page 7, pars 4-5; the detector (i.e., the eBPF-user) 200 compiles the interception rule (i.e., the preset rule) of the eBPF from the pod to the operation "mvrunc .. /runc", which covers the runc. The command of the runc operation is extracted by writing the corresponding eBPF code. Next, the eBPF -user obtains the ID of the corresponding container , and reports the ID to the processor (ebpf-controller) 300. eBPF-controller searches the target container corresponding to the ID in the k8s, and the target container is marked as stain container).
Regarding Claim 9;
This Claim recites a method that perform the same steps as device of Claim 1, and has limitations that are similar to Claim 1, thus are rejected with the same rationale applied against claim 1.
Regarding Claim 11;
This Claim recites a method that perform the same steps as device of Claim 3, and has limitations that are similar to Claim 3, thus are rejected with the same rationale applied against claim 3.
Regarding Claim 17;
This Claim recites a system that perform the same steps as device of Claim 1, and has limitations that are similar to Claim 1, thus are rejected with the same rationale applied against claim 1.
Claims 4 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over XU et al. (CN 113504971 A) in view of LI et al. (CN 115268983 A), and further in view of David et al. (“David,” US 20140108474, published on 04/17/2014).
Regarding Claim 4;
The combination of XU and LI disclose the device of claim 3,
XU discloses wherein the container ID includes a name of a corresponding container (XU: page 5, par 4; the processor 300 looks up the target container 402 (the target container 402 is the container 402a, ..., one or more of the container 402n) corresponding to the identity identification information ID and marks the target container 402 as a taint container; page 7, pars 4-5; the eBPF -user obtains the ID of the corresponding container , and reports the ID to the processor (ebpf-controller) 300. eBPF-controller searches the target container corresponding to the ID in the k8s, and the target container is marked as stain container).
The combination of XU and LI disclose wherein the container ID includes a name of a corresponding container as recited above, but do not explicitly disclose includes a name and hash of a corresponding container.
However, in an analogous art, David discloses cloud stored data system/method that includes:
includes a name and hash of a corresponding container (David: par 0236; Hash container 1216 includes a container name 1218 (".hash.sub.--1")).
Therefore, it would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to combine the teachings of David with the method/system of XU and LI to include includes a name and hash of a corresponding container. One would have been motivated to store configuration metadata for the data related to the content delivery network (David: abstract).
Regarding Claim 12;
This Claim recites a method that perform the same steps as device of Claim 4, and has limitations that are similar to Claim 4, thus are rejected with the same rationale applied against claim 4.
Conclusion
THIS ACTION IS MADE FINAL. 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 extension fee 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 CHAO WANG whose telephone number is (313)446-6644. The examiner can normally be reached on Monday-Friday 7:30-4:30PM EST.
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, Luu Pham can be reached at (571)270-5002. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
/C.W./Examiner, Art Unit 2439
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights