DETAILED ACTION
Response to Amendment
This action is in response to amendment filed December 30, 2025 for the application # 18/847,751 filed on September 17, 2024. By preliminary amendment Claims 1-20 are pending and are directed toward METHOD FOR SECURELY OPERATING A SOFTWARE COMPONENT.
Any claim objection/rejection not repeated below is withdrawn due to Applicant's amendment.
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 . 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.
Response to Arguments
Applicant’s arguments with regards to claims 1-20 have been fully considered, but they are not persuasive.
“neither Prasad nor Kim” argument – Applicant argues that neither Prasad nor Kim, alone or in combination, teaches "determining, in response to the checking, a runtime restriction for the at least one program component identified as having a vulnerability" as recited in claim 1 (REMARKS, page 7).
Response: Both Prasad and Kim teach determining step as currently amended. The difference of their approach is that a runtime restriction of Prasad based on replacing a detected vulnerable component with a benign one, and a runtime restriction of Kim based on restricting runtime by generated SECCOMP: “When the container A is run, the container host 120 may restrict system calls that the container A can invoke using SECCOMP with reference to A.json” (Kim, [0053]). Further, Applicant’s argument that determination of Kim based on static analysis is not relevant, because no specific determination method was actually claimed by Applicant.
Examiner also points Applicant attention that explicit limitation “without replacing” was cited only in Claim 16.
Conclusion: Examiner maintains rejections.
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-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Prasad et al. (US 2021/0103450, Pub. Date: Apr. 8, 2021) in view of KIM et al. (US 2020/0285733, Pub. Date: Sep. 10, 2020), hereinafter referred to as Prasad and KIM.
As per claim 1, Prasad teaches a method for securely operating a software component (The computer removes vulnerabilities corresponding to the add-on libraries of the container image assembly file. Prasad, [0006]), the method comprising:
retrieving deployment information for the software component, wherein the deployment information includes information about program components of the software component (Application containerization is an operating system-level virtualization method used to deploy and run distributed applications without launching an entire virtual machine for each application. Prasad, [0002]) and a runtime configuration thereof (Application containers include runtime components, such as files, environment variables, and libraries, which are necessary to run the desired application. Application containers consume fewer resources than a comparable deployment on virtual machines because containers share resources without a full operating system to underpin each application. The complete set of information to execute in a container is a container image. Prasad, [0003]);
checking whether at least one program component has a vulnerability and identifying the at least one program component (Container image assembly manager 218 controls the process of automatically generating a container image assembly file with add-on library vulnerabilities removed and with container image size minimized (i.e., number of layers of the container image are reduced to a minimum number). Container image assembly manager 218 may be comprised of a plurality of different modules, such as, for example, a library dependency graph builder module, a knowledge base builder module, a container image optimizer module, a library vulnerability remediator module, and the like. Prasad, [0031]);
determining in response to the checking, a runtime restriction for the at least one program component identified as having a vulnerability (When optimizing layers of the container image, illustrative embodiments remove vulnerabilities corresponding to the application libraries. Moreover, illustrative embodiments recommend replacements for vulnerable container images by providing alternate paths for installation of application add-on libraries with vulnerabilities removed. Prasad, [0053]);
inserting runtime restriction information into the deployment information for the software component (When preparing the initial container image assembly file, illustrative embodiments utilize the selected base image variant with minimum size and the generated list of libraries needed as add-ons. Further, based on information in the knowledge base, illustrative embodiments assign a sequence number to each add-on library in the list. Furthermore, illustrative embodiments generate the container image assembly file by adding one layer for each add-on library in the list to the container image. Prasad, [0052]); and
implementing a deployment of the software component on a basis of the deployment information, wherein on being executed, the software component is subject to the runtime restriction in accordance with the runtime restriction information (Illustrative embodiments also merge multiple sequential layers of the initial container image assembly file based on rules, such as, for example, affinity of files in those layers according to information in the knowledge base, size of a layer after merging layers does not exceed a pre-defined layer size, and any other rule defined by the developer. Furthermore, illustrative embodiments can add most frequently changed layers (e.g., determined by information in the knowledge base) after less frequently changed layers taking into consideration library dependencies. Prasad, [0053]).
Applicant argues that “Put simply, Prasad eliminates the vulnerability entirely by removing the vulnerable component before execution, whereas the claimed method allows the vulnerable component to remain but constrains its behavior during execution by inserting runtime restriction information.” (REMARKS, page 7). Examiner in agreement with Applicant that Prasad does not allow a vulnerable component to be executed by replacing in with a benign component and adjusting the runtime restriction information.
KIM, however teaches to allow the vulnerable component to remain (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. KIM, [0073]) but constrains its behavior during execution by inserting runtime restriction information.” (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. KIM, [0090]).
Prasad in view of KIM are analogous art to the claimed invention, because they are from a similar field of endeavor of systems, components and methodologies for providing secure communication between computer systems. 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 Prasad in view of KIM. This would have been desirable because generally, a Secure Computing Mode (SECCOMP) is a kind of system-hardening technique, which is used to reduce the attack surface of an operating system (OS) kernel. SECCOMP blocks access to system calls that are not necessary for the operation of a process, thereby eliminating the possibility that the corresponding system calls will be used to exploit a vulnerability. (KIM, [0003]).
As per claim 2, Prasad in view of KIM teaches the method as claimed in claim 1, the software component is implemented as an instance of a software container (Prasad, [0003]) and an associated software container image comprises package information, binaries, libraries and configuration data as program components (Prasad, [0003]-[0004]).
As per claim 3, Prasad in view of KIM teaches the method as claimed in claim 2, the deployment comprises a creation of a modified software container image for the software component in accordance with the deployment information supplemented by the runtime restriction (Prasad, [0004]).
As per claim 4, Prasad in view of KIM teaches the method as claimed in claim 3, before deployment a functional test of the modified software container image is carried out in a secure processing environment (Prasad, [0067]).
As per claim 5, Prasad in view of KIM teaches the method as claimed in claim 1, wherein the software component is deployed in a runtime environment (The computer system of claim 10, wherein the processor further executes the program instructions to: generate a container image for the application using the container image assembly file that was generated based on the library dependency graph of flow from the base container image to the add-on libraries for the application. Prasad, Claim 14).
As per claim 6, Prasad in view of KIM teaches the method as claimed in claim 1, wherein the deployment information references one or more software container image(s) (Furthermore, container image assembly manager 218 may deploy the generated container image to a set of one or more host nodes in a production environment for running. Prasad, [0033]).
As per claim 7, Prasad in view of KIM teaches the method as claimed in claim 1, wherein the inserting the runtime restriction information is carried out via a merge request for a build pipeline that causes the software component to be updated (Prasad, [0075]).
As per claim 8, Prasad in view of KIM teaches the method as claimed in claim 1, wherein the checking comprises a search of the deployment information and/or a scan of the software container image (Prasad, [0067]).
As per claim 9, Prasad in view of KIM teaches the method as claimed in claim 1, wherein the runtime restriction comprises an access rights restriction and/or a limitation of an output of passed-in parameters to other software components or function calls (Prasad, [0063]).
As per claim 10, Prasad in view of KIM teaches the method as claimed in claim 1, further comprising:
extending the deployment information to include vulnerability information which is assigned to the identified software component and/or the at least one program component identified as having the vulnerability, wherein the vulnerability information includes a presence of a vulnerability and/or a correction of the vulnerability by the runtime restriction, and/or storing the vulnerability information, which is assigned to the identified software component and/or to the at least one program component identified as having the vulnerability, in a vulnerability database (Prasad, [0024], [0045], [0071]-[0074]).
As per claim 11, Prasad in view of KIM teaches the method as claimed in claim 1, further comprising:
searching the deployment information for the software component for vulnerability information that is assigned to the software component and/or the identified program component; and implementing the deployment of the software component on the basis of the vulnerability information (Prasad, [0071]-[0074]).
As per claim 12, Prasad in view of KIM teaches the method as claimed in claim 10, wherein the checking further comprises: storing the vulnerability information as configuration data in a vulnerability database for a vulnerability scanning process (Prasad, [0031]).
As per claim 13, Prasad in view of KIM teaches the method as claimed in claim 1, wherein a vulnerability involves a possibility of passing unchecked parameters and/or a function call by the software component, (For example, most application containers running with user permissions do not need the init_module system call, which is used to load a kernel module. When access to the corresponding system call is allowed, a malicious user may tamper with a shared kernel image, and thus it is desirable to deny access thereto. KIM, [0042]).
Prasad in view of KIM are analogous art to the claimed invention, because they are from a similar field of endeavor of systems, components and methodologies for providing secure communication between computer systems. 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 Prasad in view of KIM. This would have been desirable because generally, a Secure Computing Mode (SECCOMP) is a kind of system-hardening technique, which is used to reduce the attack surface of an operating system (OS) kernel. SECCOMP blocks access to system calls that are not necessary for the operation of a process, thereby eliminating the possibility that the corresponding system calls will be used to exploit a vulnerability. (KIM, [0003]).
Claims 14 and 15 have limitations similar to those treated in the above rejection, and are met by the references as discussed above, and are rejected for the same reasons of anticipation as used above.
As per claim 16, Prasad in view of KIM teaches the method as claimed in claim 1, wherein the inserting runtime restriction information into the deployment information is performed in response to detecting the vulnerability during a vulnerability scanning process, and wherein the runtime restriction is applied without replacing the at least one program component identified as having the vulnerability (KIM, [0090]).
Prasad in view of KIM are analogous art to the claimed invention, because they are from a similar field of endeavor of systems, components and methodologies for providing secure communication between computer systems. 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 Prasad in view of KIM. This would have been desirable because generally, a Secure Computing Mode (SECCOMP) is a kind of system-hardening technique, which is used to reduce the attack surface of an operating system (OS) kernel. SECCOMP blocks access to system calls that are not necessary for the operation of a process, thereby eliminating the possibility that the corresponding system calls will be used to exploit a vulnerability. (KIM, [0003]).
As per claim 17, Prasad in view of KIM teaches the method as claimed in claim 1, wherein the runtime restriction comprises at least one of: revocation of process privileges of a runtime user by assignment of specific security profiles (KIM, [0016]), assignment of special mount options for file systems, or parameter validation using regular expressions to detect and block inappropriately structured calls.
Prasad in view of KIM are analogous art to the claimed invention, because they are from a similar field of endeavor of systems, components and methodologies for providing secure communication between computer systems. 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 Prasad in view of KIM. This would have been desirable because generally, a Secure Computing Mode (SECCOMP) is a kind of system-hardening technique, which is used to reduce the attack surface of an operating system (OS) kernel. SECCOMP blocks access to system calls that are not necessary for the operation of a process, thereby eliminating the possibility that the corresponding system calls will be used to exploit a vulnerability. (KIM, [0003]).
As per claim 20, Prasad in view of KIM teaches the method as claimed in claim 1, wherein the runtime restriction information is marked for traceability and referenced with the identified vulnerability (For example, the detailed control flow analysis module 226 may use a method such as control flow tracking, symbolic execution, concolic testing, or the like. Kim, [0080]).
Prasad in view of KIM are analogous art to the claimed invention, because they are from a similar field of endeavor of systems, components and methodologies for providing secure communication between computer systems. 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 Prasad in view of KIM. This would have been desirable because generally, a Secure Computing Mode (SECCOMP) is a kind of system-hardening technique, which is used to reduce the attack surface of an operating system (OS) kernel. SECCOMP blocks access to system calls that are not necessary for the operation of a process, thereby eliminating the possibility that the corresponding system calls will be used to exploit a vulnerability. (KIM, [0003]).
Claims 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Prasad et al. (US 2021/0103450, Pub. Date: Apr. 8, 2021) in view of KIM et al. (US 2020/0285733, Pub. Date: Sep. 10, 2020) in view of Loukidis et al. (Docker-sec: A Fully Automated Container Security Enhancement Mechanism, 2018 IEEE 38th International Conference on Distributed Computing Systems, pages 1561-1564, 2018), hereinafter referred to as Prasad, KIM, and Loukidis.
As per claim 18, Prasad in view of KIM teaches the method as claimed in claim 1, but does not teach interim solution, Loukidis however teaches wherein the runtime restriction is implemented as an interim solution until a software update containing a patch for the vulnerability becomes available, and, in response to determining that the vulnerability is no longer detected, undoing the runtime restrictions (Since runC directly interacts with container processes through commands like docker run, docker exec or docker stats, we have opted for a separate AppArmor profile for it. The runC profile contains the appropriate rules, one per container, that allow runC to set each container’s root mount point through the pivot_root system call and assign it a separate temporary profile. This temporary profile, used during the initialization of the specific container, protects the container until its transition (via aa_change_profile or aa_change_onexec functions) to the final container profile, used during the container runtime as described earlier. Loukidis, page 1563).
Prasad in view of KIM in view of Loukidis are analogous art to the claimed invention, because they are from a similar field of endeavor of systems, components and methodologies for providing secure communication between computer systems. 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 Prasad in view of KIM in view of Loukidis. This would have been desirable because generally, a Secure Computing Mode (SECCOMP) is a kind of system-hardening technique, which is used to reduce the attack surface of an operating system (OS) kernel. SECCOMP blocks access to system calls that are not necessary for the operation of a process, thereby eliminating the possibility that the corresponding system calls will be used to exploit a vulnerability. (KIM, [0003]), and because Dynamic Monitoring allows the user to specify a training period for a specific container, during which Docker-sec will collect data about the behavior of the container. After initiating the training session, the user utilizes the part of the application she is interested in, making use of all the required application functionality, so that Docker-sec can determine the privileges (e.g., network access, file-system access, capabilities) that are necessary for the container to function properly. At the end of the training period Docker-sec analyzes the audit log
that records the legitimate container accesses and adds the corresponding rules to the containers runtime profile, possibly discarding unnecessary privileges that were initially granted to it by the runtime profile generated by the static analysis phase (Loukidis, page 1563).
As per claim 19, Prasad in view of KIM teaches the method as claimed in claim 1, but does not teach interim solution, Loukidis however teaches wherein the runtime restriction is determined based on interim solutions defined in a vulnerability database for the identified vulnerability (By knowing this information, Docker-sec can enforce runC to transition to a temporary AppArmor profile, which is designed for the initialization phase of the specific container. After this phase ends and before handing the control over to the container process, runC transitions to the AppArmor profile which will be used (and possibly enhanced by the Dynamic Monitoring mechanism) during the container’s runtime, Loukidis, page 1563).
Prasad in view of KIM in view of Loukidis are analogous art to the claimed invention, because they are from a similar field of endeavor of systems, components and methodologies for providing secure communication between computer systems. 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 Prasad in view of KIM in view of Loukidis. This would have been desirable because generally, a Secure Computing Mode (SECCOMP) is a kind of system-hardening technique, which is used to reduce the attack surface of an operating system (OS) kernel. SECCOMP blocks access to system calls that are not necessary for the operation of a process, thereby eliminating the possibility that the corresponding system calls will be used to exploit a vulnerability. (KIM, [0003]), and because Dynamic Monitoring allows the user to specify a training period for a specific container, during which Docker-sec will collect data about the behavior of the container. After initiating the training session, the user utilizes the part of the application she is interested in, making use of all the required application functionality, so that Docker-sec can determine the privileges (e.g., network access, file-system access, capabilities) that are necessary for the container to function properly. At the end of the training period Docker-sec analyzes the audit log
that records the legitimate container accesses and adds the corresponding rules to the containers runtime profile, possibly discarding unnecessary privileges that were initially granted to it by the runtime profile generated by the static analysis phase (Loukidis, page 1563).
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 OLEG KORSAK whose telephone number is (571)270-1938. The examiner can normally be reached on 5:00 AM- 4:00 PM.
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, Rupal Dharia can be reached on (571) 272-3880. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
/OLEG KORSAK/Primary Examiner, Art Unit 2492
Prosecution Insights