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 .
Claim Objections
Claim 11 and 13 objected to because of the following informalities: the claim numbering is non-consecutive because claim number 12 was omitted from the sequence, which violates 37 CFR 1.126. Appropriate correction is required.
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, 8, 9, 13, and 16-18 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 is rejected under 35 U.S.C. 112(b) as being indefinite because the limitation “two or more methods to conduct an investigation” does not reasonably apprise a person of
ordinary skill in the art of the metes and bounds of the claims. Claim 1 does not clearly identify what constitutes a distinct method, which two or more methods are required, or what specific acts must be performed by each method beyond generally accessing and copying data from the target container. Therefore, the scope of claim 1 is unclear.
Claim 1 is further rejected under 35 U.S.C. 112(b) as being indefinite because the phrase “commands and/or steps that satisfy 1) a container platform's policies and 2) a container platform architecture's limitations or settings” uses “and/or” in a manner that renders the scope unclear. It is unclear whether the claim requires commands, steps, or both, and whether both listed requirements must be satisfied or only one of them.
Claim 8 is rejected under 35 U.S.C. 112(b) as being indefinite because the phrase “full chain of custody” is a term of degree and does not reasonably apprise a person of ordinary skill in the art of the metes and bounds of the claims. Claim 8 recites copying data “in a form and format that preserves a forensic nature of the copied data to maintain a full chain of custody for a forensic investigation.” However, the claim does not define what makes a chain of custody “full” or what minimum steps, records, metadata, timestamps, hash values, or verification procedures are required to satisfy the limitation. Therefore, the scope of claim 8 is unclear.
Claim 9 is rejected under 35 U.S.C. 112(b) as being indefinite because the limitation “two or more methods to conduct an investigation” does not reasonably apprise a person of
ordinary skill in the art of the metes and bounds of the claims. Claim 9 does not clearly identify what constitutes a distinct method, which two or more methods are required, or what specific acts must be performed by each method beyond generally accessing and copying data from the target container. Therefore, the scope of claim 9 is unclear.
Claim 9 is further rejected under 35 U.S.C. 112(b) as being indefinite because the phrase “commands and/or steps that satisfy 1) a container platform's policies and 2) a container platform architecture's limitations or settings” uses “and/or” in a manner that renders the scope unclear. It is unclear whether the claim requires commands, steps, or both, and whether the claim requires satisfying both the container platform’s policies and the container platform architecture’s limitations or settings, or only one of those requirements. Therefore, the scope of claim 9 is unclear.
Claim 13 is rejected under 35 U.S.C. 112(b) as being indefinite because claim 13 depends from claim 12, but claim 12 is not present in the claim set. Therefore, the metes and bounds of claim 13 cannot be determined.
Claim 16 is rejected under 35 U.S.C. 112(b) as being indefinite because claim 16 depends from claim 12, but claim 12 is not present in the claim set. Therefore, the metes and bounds of claim 16 cannot be determined.
Claim 17 is rejected under 35 U.S.C. 112(b) as being indefinite because the phrase “full chain of custody” is a term of degree and does not reasonably apprise a person of ordinary skill in the art of the metes and bounds of the claims. Claim 17 recites copying data “in a form and format that preserves a forensic nature of the copied data to maintain a full chain of custody for a forensic investigation.” However, the claim does not define what makes a chain of custody “full” or what minimum steps, records, metadata, timestamps, hash values, or verification procedures are required to satisfy the limitation. Therefore, the scope of claim 17 is unclear.
Claim 18 is rejected under 35 U.S.C. 112(b) as being indefinite because the limitation “two or more methods to conduct an investigation” does not reasonably apprise a person of
ordinary skill in the art of the metes and bounds of the claims. Claim 18 does not clearly identify what constitutes a distinct method, which two or more methods are required, or what specific acts must be performed by each method beyond generally accessing and copying data from the target container. Therefore, the scope of claim 18 is unclear.
Claim 18 is further rejected under 35 U.S.C. 112(b) as being indefinite because the phrase “commands and/or steps that satisfy 1) a container platform's policies and 2) a container platform architecture's limitations or settings” uses “and/or” in a manner that renders the scope unclear. It is unclear whether the claim requires commands, steps, or both, and whether the claim requires satisfying both the container platform’s policies and the container platform architecture’s limitations or settings, or only one of those requirements. Therefore, the scope of claim 18 is unclear.
Claims depending from the rejected claims inherit the indefiniteness of their respective
parent claims. Accordingly, claims 2-8 depend directly or indirectly from claim 1 and inherit
the indefiniteness of claim 1; claims 10-11 and 13-17 depend directly or indirectly from claim 9 and inherit the indefiniteness of claim 9; and claims 19 and 20 depend directly or indirectly from claim 18 and inherit the indefiniteness of claim 18;
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 13 and 16 rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends. Claim 13 purports to depend from claim 12; however, claim 12 is not present in the claim set. Claim 16 purports to depend from claim 12; however, claim 12 is not present in the claim set. Therefore, claims 13 and 16 fail to contain a reference to a claim previously set forth. Applicant may cancel the claim(s), amend the claim(s) to place the claim(s) in proper dependent form, rewrite the claim(s) in independent form, or present a sufficient showing that the dependent claim(s) complies with the statutory requirements.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 9, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over CONTAIN4n6: a systematic evaluation of container artifacts, (hereinafter Mishra) in view of Hyder et al, (U.S. Pub. No. 2024/0256659 A1, hereinafter Hyder).
As to claim 1, the combination Mishra in view of Hyder teaches:
An apparatus, comprising: a security engine configured to access a container platform through an Application Programming Interface to send one or more commands into the container platform to support accessing and copying data from a target container: (See Mishra., pg.2, L. 35-40): Docker CLI interacts with Docker Daemon using REST API as shown in Fig. 1. (pg.6, L. 15-20): python libraries for the Docker Engine API which manages Docker objects such as image, containers, volumes, etc. (pg.6, L. 28-34): Environmental Information using Container Introspection- A container-based system provides logs, and environmental information using introspection commands in Docker daemon. There are approximately fifteen management commands in the Docker engine to manage Docker objects. Some of these commands help to extract logs, contents from container’s filesystem and low-level information to support the introspection of Docker objects. This information is further processed by an analysis engine to generate logs and reports. (pg.8, L. 16-21): For a container object, the inspect command provides more than one hundred fifty information including container basic details, its process ID assigned by Host OS, image name and ID, related directories, host configuration details, drivers, and detail of network settings. (pg.8, L. 26): docker export can export the container’s filesystem.);
(Mishra’s CONTAIN4n6 accesses docker through REST API/Docker Engine API, sends docker introspection commands to an identified container object, and extracts or exports logs and filesystem contents from a specific container.)
where the security engine is configured to implement two or more methods to conduct an investigation that accesses and copies the data from the target container running in the container platform in with commands and/or steps that satisfy 1) a container platform's policies and 2) a container platform architecture's limitations or settings, in order to access and copy the data from the target container: (See Mishra., Abstract): CONTAIN4n6 is developed to collect data from container environment that extracts the data using introspection libraries, container file systems, and is also capable to trace the system call of running container. (pg.2, L. 27-41): Container’s environmental information is collected using introspection to find correlation of attack data. Data collection of various objects (container, images, storage driver, etc.) of containerization platform to examine the evidentiary values. A system call trace functionality is enabled in an open source project of Docker, called, Moby project. The sequence of system calls is analyzed to detect malicious processes. (pg.2, L. 48-53): Linux kernel features have been used in Docker Engine to provide container services as follows: ‘namespaces’ for isolated workspace, ‘control groups’ for a specific set of resources, ‘union file systems’ for layering the Docker images, and ‘libcontainer’ for container formatting. (pg.6, L. 48-53): We have focused on three areas from where container related data can be collected for forensic purpose- (i) system calls of a running container (ii)environmental information of container system from Docker daemon (iii) dynamic data libraries and files from host OS.);
(Mishra’s CONTAIN4n6 gives multiple container investigation method using introspection, file system extraction, and system call tracing. It also identifies Docker architecture settings, including namespaces, control groups, union files system, libcontainer, host configuration details, etc. Hyder supplies the container policy compliance environment. Together the collection steps would operate within Docker’s architecture settings and comply with container policies so the extraction is permitted.)
Mishra does not teach, but Hyder teaches:
where the security engine is configured to be hosted on a cloud computing network, where the security engine is configured to have a data analysis system with a processing pipeline to analyze the data from the target container as a part of the investigation to detect for one or more of i) a violation of a policy and ii) malicious activity, associated with the target container: (see Hyder, [¶¶0016, 0023, 0028-0030]: “The cloud environments 130 may be datacenters, enterprise clouds, or any other networked environment in which containers may be deployed. In the embodiment shown, the container security system 140 includes a cloud security posture management module 320, a cloud detection and response module 330. monitors the behavior of containers (and other resources) for compliance with these policies. The cloud detection and response module 330 monitors activities of deployed containers to detect potentially malicious activities, determine whether the anomaly is associated with a malicious activity, such as, accessing a known malicious web address, violating a policy, or otherwise exhibiting malware-like behavior, etc.”);
an action recommendation engine of the security engine configured to suggest one or more remediation actions based upon the analyzed data from the target container: (see Hyder, [¶¶0027-0028, 0034]: “If a container image does not meet the security criteria, an appropriate user (e.g., the responsible developer) may be notified and, where appropriate, provided with suggestions for how to address the identified security risk. The cloud security posture management module 320 may make recommendations or configuration changes so that the monitored resources are hardened and configured to be accessed only by authorized resources based on best practices and any policies set by the relevant system administrators. The cloud detection and response module 330 may take one or more security actions in response to detected anomalies.”);
a user interface of the security engine to convey the analyzed data from the target container and the suggested remediation actions to a user in at least one of 1) on a display device and II) in a report: (see Hyder, [¶¶0004, 0006, 0028]: “In various embodiments, an end-to-end container security system can detect vulnerabilities, track detected vulnerabilities, allow only verified images to run in production, detect behavioral anomalies in production containers, notify users of detected anomalies, notify users of policy violations, and/or take security actions to prevent or reduce harm. The container security system may generate a notification of the anomaly for display to a user, then the cloud security posture management module 320 may generate a notification for display to the relevant system administrator.”);
and where instructions implemented in software for the security engine are configured to be stored in one or more non-transitory storage mediums to be executed by one or more processing units: (see Hyder, [¶¶0043, 0045-0046]: “FIG. 5 is a block diagram illustrating components of an example machine able to read instructions from a machine-readable medium and execute them in a processor. The example computer system 500 includes a processor 502 a main memory 504, and a static memory 506.The storage unit 516 includes a machine-readable medium 522 on which is stored instructions 524 (e.g., software) embodying any one or more of the methodologies or functions described in this disclosure.”);
Therefore, it would have been obvious to a person of ordinary skill in the art to combine Mishra’s CONTAIN4n6 container forensic collection techniques with Hyder’s container security system. Mishra provides Docker API introspection-based collection of container artifacts, logs, filesystem contents, and system call traces, while Hyder provides cloud container security analysis for policy violation and malicious activity. A person of ordinary skill in the art would have been motivated to use Mishra’s collection methods in Hyder’s container security environment to obtain investigation data from a target container and feed that data in to Hyder’s analysis pipeline. The combination provides the predictable benefit of collecting container specific investigation data and using it to detect threats, identify policy violations, provide remediation suggestions, and notify a user.
As to claim 9, the combination Mishra in view of Hyder teaches:
providing a security engine to access a container platform through an Application Programming Interface to send one or more commands into the container platform to support accessing and copying data from a target container: (See Mishra., pg.2, L. 35-40): Docker CLI interacts with Docker Daemon using REST API as shown in Fig. 1. (pg.6, L. 15-20): python libraries for the Docker Engine API which manages Docker objects such as image, containers, volumes, etc. (pg.6, L. 28-34): Environmental Information using Container Introspection- A container-based system provides logs, and environmental information using introspection commands in Docker daemon. There are approximately fifteen management commands in the Docker engine to manage Docker objects. Some of these commands help to extract logs, contents from container’s filesystem and low-level information to support the introspection of Docker objects. This information is further processed by an analysis engine to generate logs and reports. (pg.8, L. 16-21): For a container object, the inspect command provides more than one hundred fifty information including container basic details, its process ID assigned by Host OS, image name and ID, related directories, host configuration details, drivers, and detail of network settings. (pg.8, L. 26): docker export can export the container’s filesystem.);
(Mishra’s CONTAIN4n6 accesses docker through REST API/Docker Engine API, sends docker introspection commands to an identified container object, and extracts or exports logs and filesystem contents from a specific container.)
providing the security engine to implement two or more methods to conduct a forensic investigation that accesses and copies the data from the target container running in the container platform in with commands and/or steps that satisfy 1) a container platform's policies and 2) a container platform architecture's limitations or settings, in order to access and copy the data from the target container: (See Mishra., Abstract): CONTAIN4n6 is developed to collect data from container environment that extracts the data using introspection libraries, container file systems, and is also capable to trace the system call of running container. (pg.2, L. 27-41): Container’s environmental information is collected using introspection to find correlation of attack data. Data collection of various objects (container, images, storage driver, etc.) of containerization platform to examine the evidentiary values. A system call trace functionality is enabled in an open-source project of Docker, called, Moby project. The sequence of system calls is analyzed to detect malicious processes. (pg.2, L. 48-53): Linux kernel features have been used in Docker Engine to provide container services as follows: ‘namespaces’ for isolated workspace, ‘control groups’ for a specific set of resources, ‘union file systems’ for layering the Docker images, and ‘libcontainer’ for container formatting. (pg.6, L. 48-53): We have focused on three areas from where container related data can be collected for forensic purpose- (i) system calls of a running container (ii)environmental information of container system from Docker daemon (iii) dynamic data libraries and files from host OS.);
(Mishra’s CONTAIN4n6 gives multiple container investigation method using introspection, file system extraction, and system call tracing. It also identifies Docker architecture settings, including namespaces, control groups, union files system, libcontainer, host configuration details, etc. Hyder supplies the container policy compliance environment.)
Mishra does not, but Hyder teaches:
A machine readable medium configured to store instructions and data to be executed by one or more processors, where the instructions when executed cause one or more computing devices to perform steps as follows, comprising: (see Hyder, [¶¶0043, 0045-0046]: “FIG. 5 is a block diagram illustrating components of an example machine able to read instructions from a machine-readable medium and execute them in a processor. The example computer system 500 includes a processor 502 a main memory 504, and a static memory 506.The storage unit 516 includes a machine-readable medium 522 on which is stored instructions 524 (e.g., software) embodying any one or more of the methodologies or functions described in this disclosure.”);
providing the security engine to be hosted on a cloud computing network: (see Hyder, [¶¶0016, 0020]: “The cloud environments 130 may be datacenters, enterprise clouds, or any other networked environment in which containers may be deployed. The cloud environment 130 includes a host 210 that is running a set of one or more containers 212.”);
providing the security engine to have a data analysis system with a processing pipeline to analyze the data from the target container as a part of the forensic investigation to detect for one or more of i) a violation of a policy and ii) malicious activity, associated with the target container: (see Hyder, [¶¶0023, 0028-0030]: “In the embodiment shown, the container security system 140 includes a cloud security posture management module 320, a cloud detection and response module 330. monitors the behavior of containers (and other resources) for compliance with these policies. The cloud detection and response module 330 monitors activities of deployed containers to detect potentially malicious activities, determine whether the anomaly is associated with a malicious activity, such as, accessing a known malicious web address, violating a policy, or otherwise exhibiting malware-like behavior, etc.”);
providing an action recommendation engine in the security engine to suggest one or more remediation actions based upon the analyzed data from the target container: (see Hyder, [¶¶0027-0028, 0034]: “If a container image does not meet the security criteria, an appropriate user (e.g., the responsible developer) may be notified and, where appropriate, provided with suggestions for how to address the identified security risk. The cloud security posture management module 320 may make recommendations or configuration changes so that the monitored resources are hardened and configured to be accessed only by authorized resources based on best practices and any policies set by the relevant system administrators. The cloud detection and response module 330 may take one or more security actions in response to detected anomalies.”);
and providing a user interface of the security engine to convey the analyzed data from the target container and the suggested remediation actions to a user in at least one of I) on a display device and II) in a report: (see Hyder, [¶¶0004, 0006, 0028]: “In various embodiments, an end-to-end container security system can detect vulnerabilities, track detected vulnerabilities, allow only verified images to run in production, detect behavioral anomalies in production containers, notify users of detected anomalies, notify users of policy violations, and/or take security actions to prevent or reduce harm. The container security system may generate a notification of the anomaly for display to a user, then the cloud security posture management module 320 may generate a notification for display to the relevant system administrator.”);
Therefore, it would have been obvious to a person of ordinary skill in the art to combine Mishra’s CONTAIN4n6 container forensic collection methods with Hyder’s container security analysis step. Mishra provides Docker API introspection-based collection of container artifacts, logs, filesystem contents, and system call traces, while Hyder provides cloud container security analysis for policy violation and malicious activity. A person of ordinary skill in the art would have been motivated to configure the machine-readable instruction to perform Mishra’s collection methods in Hyder’s container security environment to obtain investigation data from a target container and feed that data in to Hyder’s analysis pipeline. The combination provides the predictable benefit of collecting container specific investigation data and using it to detect threats, identify policy violations, provide remediation suggestions, and notify a user.
As to claim 18, the combination Mishra in view of Hyder teaches:
A method for a security engine to conduct an investigation by performing operations, comprising: accessing a container platform through an Application Programming Interface to send one or more commands into the container platform to support accessing and copying data from a target container: (See Mishra., pg.2, L. 35-40): Docker CLI interacts with Docker Daemon using REST API as shown in Fig. 1. (pg.6, L. 15-20): python libraries for the Docker Engine API which manages Docker objects such as image, containers, volumes, etc. (pg.6, L. 28-34): Environmental Information using Container Introspection- A container-based system provides logs, and environmental information using introspection commands in Docker daemon. There are approximately fifteen management commands in the Docker engine to manage Docker objects. Some of these commands help to extract logs, contents from container’s filesystem and low-level information to support the introspection of Docker objects. This information is further processed by an analysis engine to generate logs and reports. (pg.8, L. 16-21): For a container object, the inspect command provides more than one hundred fifty information including container basic details, its process ID assigned by Host OS, image name and ID, related directories, host configuration details, drivers, and detail of network settings. (pg.8, L. 26): docker export can export the container’s filesystem.);
(Mishra’s CONTAIN4n6 accesses docker through REST API/Docker Engine API, sends docker introspection commands to an identified container object, and extracts or exports logs and filesystem contents from a specific container.)
implementing two or more methods to conduct the investigation that accesses and copies the data from the target container running in the container platform in with commands and/or steps that satisfy 1) a container platform's policies and 2) a container platform architecture's limitations or settings, in order to access and copy the data from the target container: (See Mishra., Abstract): CONTAIN4n6 is developed to collect data from container environment that extracts the data using introspection libraries, container file systems, and is also capable to trace the system call of running container. (pg.2, L. 27-41): Container’s environmental information is collected using introspection to find correlation of attack data. Data collection of various objects (container, images, storage driver, etc.) of containerization platform to examine the evidentiary values. A system call trace functionality is enabled in an open source project of Docker, called, Moby project. The sequence of system calls is analyzed to detect malicious processes. (pg.2, L. 48-53): Linux kernel features have been used in Docker Engine to provide container services as follows: ‘namespaces’ for isolated workspace, ‘control groups’ for a specific set of resources, ‘union file systems’ for layering the Docker images, and ‘libcontainer’ for container formatting. (pg.6, L. 48-53): We have focused on three areas from where container related data can be collected for forensic purpose- (i) system calls of a running container (ii)environmental information of container system from Docker daemon (iii) dynamic data libraries and files from host OS.);
(Mishra’s CONTAIN4n6 gives multiple container investigation method using introspection, file system extraction, and system call tracing. It also identifies Docker architecture settings, including namespaces, control groups, union files system, libcontainer, host configuration details, etc. Hyder supplies the container policy compliance environment. Together the collection steps would operate within Docker’s architecture settings and comply with container policies so the extraction is permitted.)
Mishra does not teach, but Hyder teaches:
operating on a cloud computing network: (see Hyder, [¶¶0016, 0020]: “The cloud environments 130 may be datacenters, enterprise clouds, or any other networked environment in which containers may be deployed. The cloud environment 130 includes a host 210 that is running a set of one or more containers 212.”);
using a data analysis system with a processing pipeline to analyze the data from the target container as a part of the investigation to detect for one or more of i) a violation of a policy and ii) malicious activity, associated with the target container: (see Hyder, [¶¶0023, 0028-0030]: “In the embodiment shown, the container security system 140 includes a cloud security posture management module 320, a cloud detection and response module 330. monitors the behavior of containers (and other resources) for compliance with these policies. The cloud detection and response module 330 monitors activities of deployed containers to detect potentially malicious activities, determine whether the anomaly is associated with a malicious activity, such as, accessing a known malicious web address, violating a policy, or otherwise exhibiting malware-like behavior, etc.”);
suggesting one or more remediation actions based upon the analyzed data from the target container: (see Hyder, [¶¶0027-0028, 0034]: “If a container image does not meet the security criteria, an appropriate user (e.g., the responsible developer) may be notified and, where appropriate, provided with suggestions for how to address the identified security risk. The cloud security posture management module 320 may make recommendations or configuration changes so that the monitored resources are hardened and configured to be accessed only by authorized resources based on best practices and any policies set by the relevant system administrators. The cloud detection and response module 330 may take one or more security actions in response to detected anomalies.”);
and using a user interface of the security engine to convey the analyzed data from the target container and the suggested remediation actions to a user in at least one of I) on a display device and II) in a report: (see Hyder, [¶¶0004, 0006, 0028]: “In various embodiments, an end-to-end container security system can detect vulnerabilities, track detected vulnerabilities, allow only verified images to run in production, detect behavioral anomalies in production containers, notify users of detected anomalies, notify users of policy violations, and/or take security actions to prevent or reduce harm. The container security system may generate a notification of the anomaly for display to a user, then the cloud security posture management module 320 may generate a notification for display to the relevant system administrator.”);
Therefore, it would have been obvious to a person of ordinary skill in the art to combine Mishra’s CONTAIN4n6 container forensic collection methods with Hyder’s container security analysis method. Mishra provides Docker API introspection-based collection of container artifacts, logs, filesystem contents, and system call traces, while Hyder provides steps for cloud container security analysis for policy violation and malicious activity. A person of ordinary skill in the art would have been motivated to perform Mishra’s collection steps in Hyder’s container security environment to obtain investigation data from a target container and feed that data in to Hyder’s analysis pipeline. The combination provides the predictable benefit of collecting container specific investigation data and using it to detect threats, identify policy violations, provide remediation suggestions, and notify a user.
Claims 2, 10, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over CONTAIN4n6: a systematic evaluation of container artifacts, (hereinafter Mishra) in view of Hyder et al, (U.S. Pub. No. 2024/0256659 A1, hereinafter Hyder), and in further view of Shua et al, (U.S. Pub. No. 2022/0374520 A1, hereinafter Shua).
As to claim 2, the combination of Mishra in view of Hyder teaches all the limitations
recites in claim 1 above.
The combination of Mishra in view of Hyder does not teach, but Shua teaches:
where the security engine is configured to use a first method to access the container platform and create a disk image that includes the target container with commands and/or steps that satisfy 1) the container platform's policies and 2) the container platform architecture's limitations or settings, in order to access and copy the data from the target container: (see Shua, [¶¶0015, 0120-0121, 0125, 0248, 0251]: “Embodiments of the present disclosure may further use an out-of-band process to reach cloud workloads through the runtime storage layer, combining this with information gathered from cloud provider APIs, including but not limited to K8S APIs. Aspects of this disclosure may include using the cloud provider APIs to access block storage volumes of the at least one workload. The role definition includes read-only permissions and permissions to read a block storage layer. Mounting may include creating a snapshot of the block storage volumes; and mounting the snapshot of the block storage volumes on the scanner. A block storage volume may be connected, disconnected, or reconnected to a system without interfering the operation status of the system or other running tasks on the system. For example, a block storage volume may be implemented as a virtual disk. A workload may be a virtual machine, a database, a container, a Hadoop node, an application, a storage object, a load balancer, or an IAM (Identity and Access Management) configuration.”);
(Shua teaches accessing workload storage through cloud provider API’s, creating/mounting snapshots of block storage volumes, and treating block storage a virtual disk, where the workload may be a container.)
Therefore, it would have been obvious to modify to Mishra’s CONTAIN4n6 container forensic collection with Shua’s side-scanning techniques because Shua provides cloud provider API access to workload block storage and snapshot/virtual disk-based scanning without disrupting the running workload. A person of ordinary skill in the art would have been motivated to use Shua’s disk/volume-based access as a first method to preserve and copy target container data for deeper forensic investigation.
Regarding claims 10 and 19, these claims are rejected under the same reasoning as corresponding Claim 2, where Mishra’s CONTAIN4n6 and Hyder teaches the base container-forensic and security engine limitations, and Shua further teaches using cloud provider APIs to access workload block, storage volumes, creating or mounting snapshots of the block storage volumes, and block storage implemented as a virtual disk, where the workload may be a container. (See Shua, [¶¶0015, 0120-0121, 0125, 0248, 0251].
Claims 3-4, 7-8, 11, 13, 16-17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over CONTAIN4n6: a systematic evaluation of container artifacts, (hereinafter Mishra) in view of Hyder et al, (U.S. Pub. No. 2024/0256659 A1, hereinafter Hyder), and in further view of Saliba et al, (U.S. Pub. No. 2022/0043907 A1, hereinafter Saliba).
As to claim 3, the combination of Mishra in view of Hyder teaches all the limitations
recites in claim 1 above.
The combination of Mishra in view of Hyder does not teach, but Saliba teaches:
where the security engine is configured to use a first method to invoke a security host to create and send down a security host binary executable application to run in a first container and work with the target container with commands and/or steps that satisfy 1) the container platform's policies and 2) the container platform architecture's limitations or settings, in order to access and copy the data from the target container: (see Saliba, [¶¶0125, 0086, 0089]: “Agent deploying module 316 deploys the deployable agent 337 as an executable program to the target endpoint device. In an embodiment, the evidence collection module 821 may be configured to call, via an API or the like, an agent of the system 850 that is configured to identify activity which agent may then feed data (e.g. files) back to the requesting module of the cloud service 820 (e.g. evidence collection module 821).”);
(Saliba teaches deploying an executable forensic agent that collects and returns file data over an API. Applied to the containerized environment of the base rejection, it would have been obvious to run that executable in a separate first container so it can work with the target container while preserving platform isolation, policies, and architecture setting.)
Therefore, it would have been obvious to a person of ordinary skill in the art to modify the container forensic security system of Mishra’s CONTAIN4n6 container and Hyder’s to use Saliba’s remote executable agent deployment. Saliba teaches deploying an executable forensic agent to collect and return files or data through an API. A person of ordinary skill in the art would have been motivated to package that executable agent to run in a separate first container within the container platform so the agent cloud safely accesses and copy data from the target container while preserving isolation, complying, with platform policies, and returning collected forensic data for analysis.
Regarding claims 11 and 20, these claims are rejected under the same reasoning as corresponding Claim 3, where Mishra’s CONTAIN4n6 and Hyder cheches the base container-forensic and security engine limitations, and Saliba further teaches deploying an executable forensic agent to collect and return files data through an API. A PHOSITA would have found it obvious to deploy Saliba’s executable forensic agent within Mishra’s CONTAIN4n6 containerized framework so that the agent runs in a first container to work with the target container while satisfying Hyder ‘s policy compliance environment and CONTAIN4n6 docker architecture limitations. (see Saliba, [¶¶0125, 0086, 0089].
As to claim 4, Mishra in view of Hyder and in further view of Saliba teaches:
where the security engine is configured to use the first method to run the security host binary executable application i) within the target container or ii) create a sidecar container to link with the target container in a same pod as the target container, with commands and/or steps that satisfy 1) the container platform's policies and 2) the container platform architecture's limitations or settings, in order to access and copy the data from the target container: (see Saliba, [¶¶0125, 0086, 0089]: “Agent deploying module 316 deploys the deployable agent 337 as an executable program to the target endpoint device. In an embodiment, the evidence collection module 821 may be configured to call, via an API or the like, an agent of the system 850 that is configured to identify activity which agent may then feed data (e.g. files) back to the requesting module of the cloud service 820 (e.g. evidence collection module 821).”);
(See Mishra., Abstract): CONTAIN4n6 is developed to collect data from container environment that extracts the data using introspection libraries, container file systems, and is also capable to trace the system call of running container. (pg.10, L. 17-20): We obtained the process ID(PID) of the running container. It records the system call used by a running container.
(see Hyder, [¶¶0021, 0028]: “Use of the cloud environment 130 may be controlled by one or more policies that limit access to the hosts 210 and/or containers 212 to users with appropriate credentials (e.g., issued by the entity). The cloud security posture management module 320 monitors the behavior of containers (and other resources) for compliance with these policies.”);
(Saliba teaches deploying an executable forensic agent that collects and returns files data. Mishra’s CONTAIN4n6 teaches collecting forensic data from a running target container. Since claim is written in the alternative it is enough to satisfy running the application “within the target container”.)
Therefore, it would have been obvious to run Saliba’s deployable executable agent within the target container because Mishra’s CONTAIN4n6 teaches collecting container artifacts and runtime data from an identified container, and Saliba teaches using an executable agent to scan an asset and return data over an API. This would provide direct access to local container data while preserving the container’s architecture limits, resources settings, and policy compliance.
Regarding claims 13, this claim is rejected under the same reasoning as corresponding Claim 4, where Saliba teaches deploying an executable forensic agent, Mishra’s CONTAIN4n6 teaches collecting forensic data from a running target container, and Hyder teaches monitoring container behavior for policy compliance. (see Saliba, [¶¶0125, 0086, 0089]
As to claim 7, Mishra in view of Saliba teaches:
where the security host binary executable application is further configured to inspect a plurality of objects in the target container and then capture the plurality of objects from a memory and one or more instances of applications running on the target container and then send collected data from the target container, over to a cloud storage location: (See Mishra., pg.7, L. 2-4): Container forensics requires data from host OS which is generally stored as a file system, network packets, and memory dumps, etc. (pg.7, L. 6-10): three areas from where container related data can be collected for forensic purpose- (i) system calls of a running container(ii)environmental information of container system from Docker daemon (iii) dynamic data libraries and files from host OS. (pg.10, L. 17-20): We obtained the process ID(PID) of the running container. It records the system call used by a running container.
(see Saliba, [¶¶0125, 0185]: “Agent deploying module 316 deploys the deployable agent 337 as an executable program to the target endpoint device. At the target endpoint device the deployable agent 337 searches the target endpoint device for forensic artifacts matching the search criteria and sends the forensic artifacts to the cloud server identified by the cloud server data 336 (or other cloud server otherwise identified). In an embodiment, the evidence collection module 821 may be configured to call, via an API or the like, an agent of the system 850 that is configured to identify activity which agent may then feed data (e.g. files) back to the requesting module of the cloud service 820 (e.g. evidence collection module 821).”);
(Mishra teaches container forensic collection memory dumps and PID/system call tracing of a running container. Saliba teaches a deployable executable agent that collects forensic artifacts and sends them to a cloud server requesting module.)
Therefore, it would have been obvious to further configure the deployable executable agent of claim 3 to inspect and capture runtime target container data because Mishra’s CONTAIN4n6 teaches that container forensic includes memory dumps and PID/system call tracing a running container. A person of ordinary skill in the art would have been motivated to combine those container forensic collection techniques with Saliba’s executable agent return mechanism so the collected memory and runtime artifacts and application activity data could be transmitted to cloud storage for forensic analysis.
Regarding claims 16, this claim is rejected under the same reasoning as corresponding Claim 7, where Mishra’s CONTAIN4n6 teaches collecting container forensic data including memory dumps and tracing running container using PID or system calls, and Saliba teaches deploying an executable forensic agent that searches for forensic artifacts and sends collected artifacts or data to a cloud server or requesting module. (see Saliba, [¶¶0125, 0185]
As to claim 8, Mishra in view of Hyder and in further view of Saliba teaches:
where the security engine is configured to invoke a security host that is hosted on one or more U R Ls, where the security host is configured to create and download a version of a security host binary executable application based upon a category of operating system utilized by a computing system supporting the container platform with the target container, where the security host binary executable application is further configured to run in a first container and work with the target container in order to access and copy the data from the target container in a form and format that preserves a forensic nature of the copied data to maintain a full chain of custody for a forensic investigation: (see Saliba, [¶¶0023, 0116, 0119, 0123, 0125]: “The client may log into a forensic service provider website to select the search criteria. the agent configuration module 312 allows the client device or forensic service provider device to configure a deployable agent which is deployed to a target endpoint device. Identification/access module 315 is used to provide information regarding the specific identity of the target endpoint device and any credentials needed to access the target endpoint device. The configurable deployable agent data 335 may include a base agent. The base agent may be stored in the cloud. The base agent is configured using the agent configuration data 331 to generate a deployable agent (e.g. executable). Agent deploying module 316 deploys the deployable agent 337 as an executable program to the target endpoint device.”);
(See Mishra., pg.1, L. 10-11): Data collected from multiple sources are stored in a database and created a hash values to maintain the integrity of collected data. (pg.6, L. 48-53): We have focused on three areas from where container related data can be collected for forensic purpose- (i) system calls of a running container (ii)environmental information of container system from Docker daemon (iii) dynamic data libraries and files from host OS. (pg.7, L. 2-4): Container forensics requires data from host OS which is generally stored as a file system, network packets, and memory dumps, etc.
(Saliba teaches a website/cloud hosted service that deploys an executable forensic agent. Mishra teaches collecting container artifacts like system calls, filesystems, memory dumps and hashing the data to guarantee integrity.)
Therefore, it would have been obvious to a person of ordinary skill in the art to modify Mishra’s CONTAIN4n6 container-forensic framework and Hyder’s container security environment with Saliba’s cloud hosted deployable agent system. Mishra’s CONTAIN4n6 teaches collecting forensic container data using Docker/container mechanisms, and Saliba teaches configuring and deploying an executable forensic agent from a cloud based forensic website service. A person of ordinary skill in the art would have been motivated to select and download an executable binary version matching the target system’s OS category so the deployed agent could properly execute within the container platform. Using Mishra’s low level container collection with hash value generation would preserve the copied data in an unaltered forensic form and maintain chain of custody for the investigation.
Regarding claims 17, this claim is rejected under the same reasoning as corresponding Claim 8, where Saliba teaches a website/cloud-hosted forensic service that configures and deploys an executable forensic agent, and Mishra teaches collecting container forensic data and generating hash values to maintain integrity of the collected data. (see Saliba, [¶¶0023, 0116, 0119, 0123, 0125].
Claims 5-6, and 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over CONTAIN4n6: a systematic evaluation of container artifacts, (hereinafter Mishra) in view of Hyder et al, (U.S. Pub. No. 2024/0256659 A1, hereinafter Hyder), and in further view of Caldato et al, (U.S. Pub. No. 2019/0102280 A1, hereinafter Caldato).
As to claim 5, the combination of Mishra in view of Hyder teaches all the limitations
recites in claim 1 above.
The combination of Mishra in view of Hyder does not teach, but Caldato teaches:
where the security engine is configured to use a first method to generate a sidecar container, via a command line API, in order to support accessing the data from the target container, where the sidecar container is constructed as an ephemeral container that shares a same namespace and resource space with the target container with commands and/or steps that satisfy 1) the container platform's policies and 2) the container platform architecture's limitations or settings, in order to access and copy the data from the target container: (see Caldato, [¶¶0008, 0011, 0059, 0123]: “The method may also include determining that instantiating the debug instance of the service. The debug instance may be encapsulated in second one or more containers and may include code implementing the service and one or more debugging utilities. The first one or more containers may be organized into a container pod. The one or more debugging utilities may be encapsulated in at least one container other than the single container. A pod is an abstraction that represents a group of one or more application containers (e.g., Docker or rkt). A pod may also include some shared resources that are commonly available to all of the containers within the pod. For example, the pod 2300 includes an additional container 2302 that includes a debug daemon 2304. The container 2302 may also include additional debug utilities 2006, such as utilities that track memory usage, processor usage, bandwidth usage, and other computing characteristics while the service receives real-time, live data requests.”);
(Caldato teaches instantiating an additional debug container with Mishra’s CONTAIN4n6 container forensic system because Caldato teaches using a separate container with debugging utilities in the same pod environment.)
Therefore, it would have been obvious to a person of ordinary skill in the art to modify Mishra’s CONTAIN4n6 container forensic collection system, as applied with Hyder’s policy compliance container security environment, to use Caldato’s additional debug container in the same pod environment. Mishra teaches collecting forensic data from a running container using Docker container platform mechanism, and Caldato teaches instantiating an additional container with debugging utilities in a pod where containers share common resources. A person of ordinary skill in the art would have been motivated to use Caldato’s sidecar/ephemeral style debug container to access and copy data from the target container while preserving container platform isolation, shred pod resources, and policy-compliant operation.
Regarding claims 14, this claim is rejected under the same reasoning as corresponding Claim 5, where Caldato teaches instantiating an additional debug container in a pod with shared resources and debugging utilities. (see Caldato, [¶¶0008, 0011, 0059, 0123].
As to claim 6, Mishra in view of Hyder in further view of Caldato teaches:
where the target container is at least one of 1) a private cluster of nodes that utilize internal IP addresses for all of the nodes, which means the private cluster of nodes is isolated from access from a public Internet in the container platform and 2) a distroless container in the container platform: (see Caldato, [¶¶0056, 0066]: “The container platform 210 may be implemented by any publicly available container platform, such as Kubernetes, that runs containers organized in nodes and pods. The API registry 404 can be made privately available to any of the other containers in the container platform 210.”);
(see Hyder, [¶¶0016, 0028]: “The cloud environments 130 may be datacenters, enterprise clouds, or any other networked environment in which containers may be deployed. The cloud security posture management module 320 monitors the behavior of containers (and other resources) for compliance with these policies. The cloud security posture management module 320 may make recommendations or configuration changes so that the monitored resources are hardened and configured to be accessed only by authorized resources based on best practices and any policies set by the relevant system administrators.”);
(Caldato teaches a Kubernetes type container platform organized in nodes and pods, with service made privately available to other containers in the platform. Hyder teaches enterprise/cloud container environment where monitored resources are hardened and accessed only by authorized resources.)
Therefore, it would have been obvious to a person of ordinary skill in the art to combine Mishra’s CONTAIN4n6 container forensic framework with Hyder’s enterprise cloud environment. Mishra teaches collecting forensic data from containers, Caldato teaches Kubernetes type nodes and pods with private availability between platform resources, and Hyder teaches enterprise cloud container deployment. A person of ordinary skill in the art would have been motivated to use internal Ip addresses for the cluster nodes to reduce public internet exposure, protect forensic collection traffic, and preserve target container data integrity.
Regarding claims 15, this claim is rejected under the same reasoning as corresponding Claim 6, where’re Caldato and Hyder together a private inter container platform environment using nodes and pods with restricted access to authorized resources. (see Caldato, [¶¶0056, 0066].
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARHAM AHMED whose telephone number is (571)272-8950. The examiner can normally be reached Monday-Friday 7:30 am - 5 pm. Alternate Friday off..
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, Alexander Lagor can be reached at (571) 270-5143. 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.
/A.N.A./Examiner, Art Unit 2437
/ALI S ABYANEH/Primary Examiner, Art Unit 2437
Prosecution Insights