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 .
1.This action is responsive to the communication filed on September 13, 2024. At this time, claims 1-20 are pending and addressed below.
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.
Double patenting
2. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the "right to exclude" granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Omum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claims 1, 3, 5-7, 8-10, 12, 14, 16, and 18-20 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-11, 13-14 and 16-20 of US Patent number 12124561. The conflicting claims are not identical, they are not patentably distinct from each other because the current application contains claims that are broader in scope than the claims of the patent number 12124561 and are anticipated by the claims 1-11, 13-14 and 16-20.
This is a Non-provisional double patenting rejection.
Claims Comparison Table
Application Number 18/884,681
Patent Application Number 12124561
1. A system comprising: a memory; and a processing device operatively coupled to the memory, the processing device to: trace, using a trace tool, system calls made by an application to determine a system call that is necessary for the application to operate, wherein the system call corresponds to a minimum level of security for the application; and embed, based on the system call, a custom security setting into a container image corresponding to the application.
1. A system comprising: a memory; and a processing device operatively coupled to the memory, the processing device to: trace, using a trace tool, system calls made by an application to determine a set of system calls that are necessary for the application to operate, wherein the set of system calls that are necessary for the application to operate correspond to a minimum level of security for the application; define custom security settings based on the set of system calls that are necessary for the application to operate, wherein the custom security settings indicate the set of system calls that are necessary for the application to operate as authorized system calls for a system call filter; and embed the custom security settings into a container image corresponding to the application.
9. The non-transitory computer-readable medium of claim 8, wherein the custom security setting comprises a custom seccomp profile.
2. The system of claim 1, wherein the custom security settings comprise a custom seccomp profile.
3. The system of claim 1, wherein to embed the custom security settings into the container image, the processing device is to include the custom security settings as part of image metadata of the container image.
3. The system of claim 1, wherein to embed the custom security settings into the container image, the processing device is to: include the custom security settings as part of image metadata of the container image.
5. The system of claim 1, wherein to embed the custom security setting into the container image, the processing device is to include the custom security setting into a layer of the container image as a file system object.
4. The system of claim 1, wherein to embed the custom security settings into the container image, the processing device is to: include the custom security settings into a layer of the container image as a file system object.
6. The system of claim 1, wherein to trace the system calls made by the application, the processing device is to: utilize the trace tool to trace the system calls made by the application during a pre-start phase of a container in which the application is running, wherein during the pre-start phase an initialization process of the container is created but not yet started.
5. The system of claim 1, wherein to trace the system calls made by the application, the processing device is to: utilize the trace tool to trace the system calls made by the application during a pre-start phase of a container in which the application is running, wherein during the pre-start phase an initialization process of the container is created but not yet started.
7. The system of claim 5, wherein the processing device implements the trace tool as a run time hook.
6. The system of claim 5, wherein the processing device implements the trace tool as a run time hook.
20. The method of claim 14, wherein a container building tool is used to embed the custom security settings into the container image corresponding to the application.
7. The system of claim 1, further comprising: compiling the custom security settings into the system call filter prior to embedding the custom security settings into the container image corresponding to the application.
8. A non-transitory computer-readable medium having instructions stored thereon which, when executed by a processing device, cause the processing device to: trace, using a trace tool executed by the processing device, system calls made by an application to determine a system call that are necessary for the application to operate, wherein the system call that is necessary for the application to operate correspond to a minimum level of security for the application; and embed, based on the system call, a custom security setting into a container image corresponding to the application.
8. A non-transitory computer-readable medium having instructions stored thereon which, when executed by a processing device, cause the processing device to: trace, using a trace tool, system calls made by an application to determine a set of system calls that are necessary for the application to operate, wherein the set of system calls that are necessary for the application to operate correspond to a minimum level of security for the application; define custom security settings based on the set of system calls that are necessary for the application to operate, wherein the custom security settings indicate the set of system calls that are necessary for the application to operate as authorized system calls for a system call filter; and embed, by the processing device, the custom security settings into a container image corresponding to the application.
9. The non-transitory computer-readable medium of claim 8, wherein the custom security setting comprises a custom seccomp profile.
9. The non-transitory computer-readable medium of claim 8, wherein the custom security settings comprise a custom seccomp profile.
10. The non-transitory computer-readable medium of claim 8, wherein to embed the custom security setting into the container image, the processing device is to include the custom security settings as part of image metadata of the container image.
10. The non-transitory computer-readable medium of claim 8, wherein to embed the custom security settings into the container image, the processing device is to: include the custom security settings as part of image metadata of the container image.
5. The system of claim 1, wherein to embed the custom security setting into the container image, the processing device is to include the custom security setting into a layer of the container image as a file system object.
11. The non-transitory computer-readable medium of claim 8, wherein to embed the custom security settings into the container image, the processing device is to: include the custom security settings into a layer of the container image as a file system object.
6. The system of claim 1, wherein to trace the system calls made by the application, the processing device is to: utilize the trace tool to trace the system calls made by the application during a pre-start phase of a container in which the application is running, wherein during the pre-start phase an initialization process of the container is created but not yet started.
12. The non-transitory computer-readable medium of claim 8, wherein to trace the system calls made by the application, the processing device is to: utilize the trace tool to trace the system calls made by the application during a pre-start phase of a container in which the application is running, wherein during the pre-start phase an initialization process of the container is created but not yet started.
7. The system of claim 5, wherein the processing device implements the trace tool as a run time hook.
13. The non-transitory computer-readable medium of claim 8, wherein the processing device implements the trace tool as a run time hook.
14. A method comprising: tracing, using a privilege tracing tool, privileges used by an application to determine a privilege that is necessary for the application to operate, wherein the privilege that is necessary for the application to operate correspond to a minimum level of security for the application; embedding, based on the privilege, a custom security setting into a container image corresponding to the application.
14. A method comprising: tracing, using a tracing tool, system calls used by an application to determine a set of system calls that are necessary for the application to operate, wherein the set of system calls that are necessary for the application to operate correspond to a minimum level of security for the application; defining custom security settings based on the set of system calls that are necessary for the application to operate; and embedding the custom security settings into a container image corresponding to the application.
16. The method of claim 14, wherein embedding the custom security setting into the container image comprises including the custom security settings as part of image metadata of the container image.
16. The method of claim 14, wherein embedding the custom security settings into the container image comprises: including the custom security settings as part of image metadata of the container image.
5. The system of claim 1, wherein to embed the custom security setting into the container image, the processing device is to include the custom security setting into a layer of the container image as a file system object.
17. The method of claim 14, wherein embedding the custom security settings into the container image comprises: including the custom security settings into a layer of the container image as a file system object.
18. The method of claim 14, wherein tracing the privileges used by the application comprises: utilizing the privilege tracing tool to trace privileges used by the application during a pre-start phase of a container in which the application is running, wherein during the pre-start phase an initialization process of the container is created but not yet started.
18. The method of claim 14, wherein tracing the system calls used by the application comprises: utilizing the tracing tool to trace system calls used by the application during a pre-start phase of a container in which the application is running, wherein during the pre-start phase an initialization process of the container is created but not yet started.
19. The method of claim 15, wherein each of the one or more labels comprise a set of key/value pairs that are not visible to the application.
19. The method of claim 15, wherein each of the one or more labels comprise a set of key/value pairs that are not visible to the application.
20. The method of claim 14, wherein a container building tool is used to embed the custom security settings into the container image corresponding to the application.
20. The method of claim 14, wherein a container building tool is used to embed the custom security settings into the container image corresponding to the application.
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-18 and 20 are rejected under 35 U.S.C 103 as being unpatentable over KIM, US 20200285733 A1 in view of Ghavamnia, NPL document, title “ Confine: Automated System Call Policy Generation for Container Attack Surface Reduction “, published October 16, 2020.
1.The combination of Kim and Ghavamnia discloses a system (See KIM, abstract; generating a Secure Computing Mode (SECCOMP) security profile based on the system call list. [0006]; generating a security profile for a container instance) comprising: a memory; (See Kim, [0017], memory) and a processing device operatively coupled to the memory, (See Kim, [0017] A system for generating a security profile of a security instance according to an embodiment of the present invention may include at least one processor; and memory for storing at least one instruction executed by the at least one processor.) the processing device to: trace, using a trace tool, system calls made by an application to determine a system call that is necessary for the application to operate, (See Kim, [0089-0092] The binary static analysis subsystem 220 may identify a dynamic linking relationship between the received executable code and the received library file at step S121. The binary static analysis subsystem 220 may identify direct/indirect system calls invoked in the executable code and the library file at step S122. If necessary, the binary static analysis subsystem 220 may perform detailed control flow analysis for tracing the value of the EAX register, which is referred to by a system call. See also [0094] The processor 1100 may generate a security profile through which privileges that allow a container instance to invoke system calls may be minimized and through which high availability of the container instance may be ensured in a container virtualization environment, thereby minimizing the possibility of a container escape problem (i.e., necessary to operate), which exploits the vulnerability of system calls, and solving the problem in which the availability of a container is reduced due to the application of the wrong security profile, as described above.)[[ wherein the system call corresponds to a minimum level of security for the application]];
and embed, based on the system call, a custom security setting into a container image corresponding to the application. (See Kim, [0091] The security profile generation subsystem 230 may convert the received system call list into a SECCOMP security profile in a format that can be used in the target container platform at step S131. The security profile generation subsystem 230 may record the generated security profile and meta information pertaining to the target image in the security profile database at step S132. The security profile generation subsystem 230 may deliver the generated security profile to the security profile save location 122 in the container host 120 at step S133. The security profile generation subsystem 230 may use the save location as a SECCOMP argument at step S133 when the container host 120 runs the target container.)
Kim does not appear to explicitly disclose wherein the system call corresponds to a minimum level of security for the application.
However, Ghavamnia discloses wherein the system call corresponds to a minimum level of security for the application.(See Ghavamnia, sections 1 and 2: The attack surface of the OS kernel used by containers can be reduced by restricting the set of system calls ( I.e., minimum level ) available to each container. In this section, we describe how Linux containers provide isolation to different “containerized” processes, and how SECure COMPuting with filters (SeccompBPF)[23]can be used to reduce the kernel code exposed to containers.)
Kim and Ghavamnia are analogous art because they are from the same field of endeavor which is Application container security. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Kim with the teaching of Ghavamnia to include the minimum level of security because it would have allowed access to application based on the tracing tool observation.
2. The combination of Kim and Ghavamnia discloses the system of claim 1, wherein to embed the custom security settings into the container image, the processing device is to include the custom security settings as part of one or more layers of the container image. (See Kim, [0091] The security profile generation subsystem 230 may convert the received system call list into a SECCOMP security profile in a format that can be used in the target container platform at step S131. The security profile generation subsystem 230 may record the generated security profile and meta information pertaining to the target image in the security profile database at step S132. The security profile generation subsystem 230 may deliver the generated security profile to the security profile save location 122 in the container host 120 at step S133. The security profile generation subsystem 230 may use the save location as a SECCOMP argument at step S133 when the container host 120 runs the target container. For example, at step S134, the “docker run” command may be executed with the option “--security-opt SECCOMP=[the file path of A.json]” in a docker container environment, whereby the security profile described in A.json may be applied when the container instance A is run.)
3.The combination of Kim and Ghavamnia discloses the system of claim 1, wherein to embed the custom security settings into the container image, the processing device is to include the custom security settings as part of image metadata of the container image. (See Kim, [0091] The security profile generation subsystem 230 may convert the received system call list into a SECCOMP security profile in a format that can be used in the target container platform at step S131. The security profile generation subsystem 230 may record the generated security profile and meta information pertaining to the target image in the security profile database at step S132. The security profile generation subsystem 230 may deliver the generated security profile to the security profile save location 122 in the container host 120 at step S133. The security profile generation subsystem 230 may use the save location as a SECCOMP argument at step S133 when the container host 120 runs the target container. For example, at step S134, the “docker run” command may be executed with the option “--security-opt SECCOMP=[the file path of A.json]” in a docker container environment, whereby the security profile described in A.json may be applied when the container instance A is run.)
4. The combination of Kim and Ghavamnia discloses the system of claim 1, wherein the processing device is further to define the custom security setting based on the system call that is necessary for the application to operate. (See Kim, [0090] Generating and applying the security profile at step S130 may be configured to generate a SECCOMP security profile based on the system call list received at step S120 and deliver the same to the container host 120, thereby enabling the SECCOMP security profile to be referred to when the target container is run. Generating and applying the security profile at step S130 may include the follows steps. See also [0094] The processor 1100 may generate a security profile through which privileges that allow a container instance to invoke system calls may be minimized and through which high availability of the container instance may be ensured in a container virtualization environment, thereby minimizing the possibility of a container escape problem (i.e., necessary to operate), which exploits the vulnerability of system calls, and solving the problem in which the availability of a container is reduced due to the application of the wrong security profile, as described above.))
5. The combination of Kim and Ghavamnia discloses the system of claim 1, wherein to embed the custom security setting into the container image, the processing device is to include the custom security setting into a layer of the container image as a file system object. (See Kim, [0090-0091] The security profile generation subsystem 230 may convert the received system call list into a SECCOMP security profile in a format that can be used in the target container platform at step S131. The security profile generation subsystem 230 may record the generated security profile and meta information pertaining to the target image in the security profile database at step S132. The security profile generation subsystem 230 may deliver the generated security profile to the security profile save location 122 in the container host 120 at step S133. The security profile generation subsystem 230 may use the save location as a SECCOMP argument at step S133 when the container host 120 runs the target container. For example, at step S134, the “docker run” command may be executed with the option “--security-opt SECCOMP=[the file path of A.json]” in a docker container environment, whereby the security profile described in A.json may be applied when the container instance A is run. )
6. The combination of Kim and Ghavamnia discloses the system of claim 1, wherein to trace the system calls made by the application, the processing device is to: utilize the trace tool to trace the system calls made by the application during a pre-start phase of a container in which the application is running, wherein during the pre-start phase an initialization process of the container is created but not yet started. (See Kim, [0071] The analysis target identification subsystem 210 may function to detect the executable code of an application and a shared library, which are executed when container A is initiated. [0072] The container instance execution module 212 may receive an image corresponding to the container A from the container image storage 110 by requesting the image therefrom, and may run the container A.
[0073] The information collection module 214, which is executed when the container A is initiated, may collect information about the application running inside the container A and shared libraries. In an embodiment, in order to collect the information, the ‘maps’ file, which is saved in the folder generated with a name corresponding to the process ID of the application to be analyzed in the proc filesystem of the Linux OS, may be referred to. In an embodiment, the information collection module 214 may deliver the collected information to the analysis target identification module 216. [0074] The analysis target identification module 216 may extract the executable code and the shared library, for which binary static analysis is to be performed, from the filesystem of the container A based on the collected information. Se also [0089] The binary static analysis subsystem 220 may identify a dynamic linking relationship between the received executable code and the received library file at step S121. The binary static analysis subsystem 220 may identify direct/indirect system calls invoked in the executable code and the library file at step S122. If necessary, the binary static analysis subsystem 220 may perform detailed control flow analysis for tracing the value of the EAX register, which is referred to by a system call, at step S123. The binary static analysis subsystem 220 may generate a list comprising the identified system calls and deliver the same to the security profile generation subsystem 230 at step S124. [0088] Performing binary static analysis at step S120 may be configured to perform binary static analysis for the executable code and the library file received at step S110, thereby generating a whitelist for system calls. Performing binary static analysis at step S120 may include the following steps.)
7. The combination of Kim and Ghavamnia discloses the system of claim 5, wherein the processing device implements the trace tool as a run time hook. (See Kim, [0067] FIG. 5 is an exemplary view that shows information about external shared libraries identified using a readelf command, which is a binary analysis tool. Referring to FIG. 5, the output shows that a binary named samplebin refers to libssl.so.1.0.0 and libc.so.6 at runtime.)
8. As to claim 8, the claim is rejected under the same rationale as claim 1. See the rejection of claim 1 above.
9. The combination of Kim and Ghavamnia discloses the non-transitory computer-readable medium of claim 8, wherein the custom security setting comprises a custom seccomp profile. (See Kim, [0017] )
10. As to claim 10, the claim is rejected under the same rationale as claim 3. See the rejection of claim 3 above.
11. The combination of Kim and Ghavamnia discloses the non-transitory computer-readable medium of claim 8, wherein to embed the custom security settings into the container image, the processing device is to include the custom security setting as part of one or more layers of the container image. (See Kim, [0091] The security profile generation subsystem 230 may convert the received system call list into a SECCOMP security profile in a format that can be used in the target container platform at step S131. The security profile generation subsystem 230 may record the generated security profile and meta information pertaining to the target image in the security profile database at step S132. The security profile generation subsystem 230 may deliver the generated security profile to the security profile save location 122 in the container host 120 at step S133. The security profile generation subsystem 230 may use the save location as a SECCOMP argument at step S133 when the container host 120 runs the target container. For example, at step S134, the “docker run” command may be executed with the option “--security-opt SECCOMP=[the file path of A.json]” in a docker container environment, whereby the security profile described in A.json may be applied when the container instance A is run.)
12. As to claim 12, the claim is rejected under the same rationale as claim 6. See the rejection of claim 6 above.
13. As to claim 13, the claim is rejected under the same rationale as claim 7. See the rejection of claim 7 above. The non-transitory computer-readable medium of claim 8, wherein the processing device implements the trace tool as a run time hook.
14. As to claim 14, the claim is rejected under the same rationale as claim 1. See the rejection of claim 1 above.
15. The combination of Kim and Ghavamnia discloses the method of claim 14, further comprising defining the custom security setting based on the privilege that is necessary for the application to operate. (See Kim, [0090] Generating and applying the security profile at step S130 may be configured to generate a SECCOMP security profile based on the system call list received at step S120 and deliver the same to the container host 120, thereby enabling the SECCOMP security profile to be referred to when the target container is run. Generating and applying the security profile at step S130 may include the follows steps. See also [0094] The processor 1100 may generate a security profile through which privileges that allow a container instance to invoke system calls may be minimized and through which high availability of the container instance may be ensured in a container virtualization environment, thereby minimizing the possibility of a container escape problem (i.e., necessary to operate), which exploits the vulnerability of system calls, and solving the problem in which the availability of a container is reduced due to the application of the wrong security profile, as described above.))
16. As to claim 16, the claim is rejected under the same rationale as claim 3. See the rejection of claim 3 above.
17. As to claim 17, the claim is rejected under the same rationale as claim 2. See the rejection of claim 2 above.
18. As to claim 18, the claim is rejected under the same rationale as claim 6. See the rejection of claim 6 above.
20. The method of claim 14, wherein a container building tool is used to embed the custom security settings into the container image corresponding to the application. (See Kim, [0091] The security profile generation subsystem 230 may convert the received system call list into a SECCOMP security profile in a format that can be used in the target container platform at step S131. The security profile generation subsystem 230 may record the generated security profile and meta information pertaining to the target image in the security profile database at step S132. The security profile generation subsystem 230 may deliver the generated security profile to the security profile save location 122 in the container host 120 at step S133. The security profile generation subsystem 230 may use the save location as a SECCOMP argument at step S133 when the container host 120 runs the target container.)
Claim 19 is rejected under 35 U.S.C 103 as being unpatentable over KIM, US 20200285733 A1 in view of Ghavamnia, NPL document, title “ Confine: Automated System Call Policy Generation for Container Attack Surface Reduction “, published October 16, 2020 in further view of Dayan, US pat.No 20180239602 (IDS Submitted, 09/13/2024)
19.The combination of Kim and Ghavamnia does not appear to explicitly the method of claim 15, wherein each of the one or more labels comprise a set of key/value pairs that are not visible to the application. However, Dayan discloses wherein each of the one or more labels comprise a set of key/value pairs that are not visible to the application. (See Dayan, [0004] )
Kim, Ghavamnia and Dayan are analogous art because they are from the same field of endeavor which is Application container security. It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the invention of Kim and Ghavamnia with the teaching of Dayan to include the key-value pair because it would have allowed secure access to
information.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Mishra Gupta, US 20240080342 A1, title “ GENERATION OF SECURITY POLICIES FOR CONTAINER EXECUTION.“
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOSNEL JEUDY whose telephone number is (571)270-7476. The examiner can normally be reached M-F 10:00-8:00.
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, Arani T Taghi can be reached at (571)272-3787. 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.
Date: 02/11/2026
/JOSNEL JEUDY/ Primary Examiner, Art Unit 2438