DETAILED ACTION
This Non Final Office Action is in response to Application filed on 06/26/2023.
Claims 1-20 filed on 06/26/2023 are being considered on the merits.
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 .
Drawings
The drawings filed on 06/26/2023 are accepted.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 06/26/2023 have been considered. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly an initialed and dated copy of Applicant's IDS form 1449 filed 06/26/2023 are attached to the instant Office action.
Specification
The disclosure is objected to because of the following informalities: Published paragraph [0027] recites “ In addition to per-layer metadata, relationship information 208 may be gathered by the security scan 112 and may be stored in the scan cache 114. ”, emphasis in italic. The “relationship information” is labeled as 208, however 208 is not shown in Figure 2. Examiner recommends either removing 208 from the specification or replace Figure 2 to show 208 in Figure 2.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
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.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-7, 11-13, 15-18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Stopel (US 20170109536 A1).
Regarding claim 1, Stopel teaches a computer-implemented method for container management (Stopel Abstract “A system and method for detecting vulnerabilities in base images of software containers”), comprising:
scanning a plurality of layers of a first container image of a plurality of container images to generate scan metadata for the plurality of layers (Stopel [0050] “This process is further demonstrated in FIGS. 4A, 4B, and 4C of base images 410, 420, and 430 respectively. The base image 410 has been scanned for vulnerabilities and found safe. The unitary signatures generated for its layers 411 through 414 are “10001000”, “10101010”, 11100011”, and “11110000”, respectively.”, when each layer is considered safe, i.e. no vulnerability detected, a unitary signature is generated for each layer as disclosed in [0047] “The unitary signature may be a check-sum of a layer, a hash function computed over the contents of the layer”, where the system is aware of the layers that are considered safe, i.e. metadata, and use the data as reference of safe layers);
generating relationship information that identifies relationships between a first plurality of layers of the first container image and layers of additional container images of the plurality of container images (Stopel [0047, 0050-0051] discloses generating unitary signatures, i.e. relationship information, of the additional images 420 and 430 in order to identify relationship between the layers (411-414) of the first container image 410 and layers (421-424 and 431-434) of the additional images 420 and 430) ); and
scanning the additional container images (Stopel [0050] “An event indicating that the base image 420 (i.e. additional container image) should be scanned is received.”, [0051] “An event indicating that the base image 430 (i.e. additional container image) should be scanned is received.”),
omitting any layers in the additional container images that match a layer of the first plurality of layers based on the relationship information (Stopel [0047] “As layers can be shared among base images, skipping the scanning of previously scanned layers optimize the detection process.”, [0050] “An event indicating that the base image 420 should be scanned is received. Unitary signatures are computed for each of the layers 421 through 424. Such unitary signatures are “10001000”, “10101010”, 11100011”, and “11110000”, respectively. The unitary signatures of the layers 421 through 424 are compared to the unitary signatures of the layers 411 through 414, respectively. As the contents (and thus the signatures) of both images 410 and 420 are the same, the base image 420 is not scanned, but determined as safe.”, [0051] “An event indicating that the base image 430 should be scanned is received. The unitary signatures are computed for each of the layers 431 through 434. Such signatures are “10001000”, “10101010”, 11100011”, and “00001111”, respectively. The unitary signatures of layers 431 through 434 are compared to the unitary signatures of layers 411 through 414, respectively. As the contents (and thus the signature) of the layer 434 are not the same of as those of the layer 414 of the base image 410, the base image 430 or only the layer in difference (e.g., layer 434) is scanned, or otherwise determined as unsafe.”).
Regarding claim 11, claim 11 recites similar limitations to claim 11, therefore rejected with the same rationale/motivation applied to claim 1.
Regarding claim 12, claim 11 recites similar limitations to claim 1, therefore rejected with the same rationale/motivation applied to claim 1.
Regarding claim 2, Stopel teaches the computer-implemented method of claim 1, wherein scanning includes performing a security scan that identifies a vulnerability in a vulnerable layer of the first plurality of layers (Stopel Figure 6 S660,S680, S690 and [0050, 0067-0069]).
Regarding claim 13, claim 13 recites similar limitations to claim 2, therefore rejected with the same rationale/motivation applied to claim 2.
Regarding claim 4, Stopel teaches the computer-implemented method of claim 1, wherein the plurality of layers are DOCKER® layers (Stopel [0008] “As such, the multiple software containers 200 can share access to the same base image 210, each of which has its own data state. In the example demonstrated in FIG. 2, the software container 200 is a Docker container (e.g., compliant with the Docker platform).”, further in e.g. [0053, 0062]).
Regarding claim 15, claim 15 recites similar limitations to claim 4, therefore rejected with the same rationale/motivation applied to claim 4.
Regarding claim 5, Stopel teaches the computer-implemented method of claim 1, further comprising detecting a triggering event that affects the first container image, wherein scanning the plurality of layers is performed responsive to the triggering event (Stopel “[0037] According to the disclosed embodiments, the detector container 315 is configured to receive an event indicating that a base image (not shown) in an image registry 330 has been changed or added. In another embodiment, such an event may be received from a CI system 340 when a new image based is created. The event includes at least a source of the image (e.g., a registry's network address or a check-in system) and an identifier of the base image to be checked. In some embodiment, the event be generated by the host device 310 when a new base image is uploaded to the host and/or when an image locally stored in the device 310 is modified.”).
Regarding claim 16, claim 16 recites similar limitations to claim 5, therefore rejected with the same rationale/motivation applied to claim 5.
Regarding claim 6, Stopel teaches the computer-implemented method of claim 5, wherein the triggering event includes a change being made to the first container image (Stopel “[0037] According to the disclosed embodiments, the detector container 315 is configured to receive an event indicating that a base image (not shown) in an image registry 330 has been changed or added. In another embodiment, such an event may be received from a CI system 340 when a new image based is created. The event includes at least a source of the image (e.g., a registry's network address or a check-in system) and an identifier of the base image to be checked. In some embodiment, the event be generated by the host device 310 when a new base image is uploaded to the host and/or when an image locally stored in the device 310 is modified.”).
Regarding claim 17, claim 17 recites similar limitations to claim 6, therefore rejected with the same rationale/motivation applied to claim 6.
Regarding claim 7, the computer-implemented method of claim 6, wherein scanning the plurality of layers omits layers that are unaffected by the triggering event ([0039] “In an embodiment, upon receiving an event, it is checked if any layer of the base image was previously scanned. If no layer of the base image was previously scanned, it is determined that the base image requires scanning. A base image that requires scanning is exported to the host device 310 (an example for such a base image is shown as 312 in FIG. 3).”, [0047] “ skipping the scanning of previously scanned layers optimize the detection process.”, [0051] “As the contents (and thus the signature) of the layer 434 are not the same of as those of the layer 414 of the base image 410, the base image 430 or only the layer in difference (e.g., layer 434) is scanned, or otherwise determined as unsafe.”).
Regarding claim 18, claim 18 recites similar limitations to claim 7, therefore rejected with the same rationale/motivation applied to claim 7.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 3 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Stopel (US 20170109536 A1) in view of Rupprecht (US 20210096894 A1).
Regarding claim 3, Stopel teaches the computer-implemented method of claim 2.
Stopel does not disclose the below limitation.
Rupprecht discloses further comprising patching the vulnerable layer and layers of the additional container images that are related to the vulnerable layer based on the relationship information (Rupprecht [0019] “…registered images are scanned for vulnerabilities and patched accordingly.”, [0037] “…program 150 utilizes the identified and processed shared layers to identify and retrieve information and solutions for one or more security vulnerabilities present in one or more layers within the image. For example, program 150 reports that database layer contained in a modified image is out of date and is can be exploited by a plurality of security vulnerabilities. In an embodiment, program 150 patches the layer (e.g., images) with respective vulnerability patches or fixes based on the identified vulnerabilities. In this embodiment, program 150 adjust the file structure of a layer based on the modifications (e.g., patches, hardening, etc.).”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Stopel to incorporate the teaching of Rupprecht to utilize the above feature, with the motivation of mitigate any potential exploits for image layers, as recognized by (Rupprecht [0037]).
Regarding claim 14, claim 14 recites similar limitations to claim 3, therefore rejected with the same rationale/motivation applied to claim 3.
Claims 8 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Stopel (US 20170109536 A1) in view of Featonby (US 12190144 B1).
Regarding claim 8, Stopel teaches the computer-implemented method of claim 1.
Stopel does not explicitly disclose the below limitation.
Featonby discloses further comprising storing the relationship information in a graph database (Featonby Col. 4 line 45-50 “The layer dependency data 137 may indicate the dependencies (e.g., whether a layer depends on another layer, whether a layer builds on top of another layers, etc.) among the layers of a single container image (e.g., in the form of a directed graph, as shown in FIG. 3) and/or an aggregation of such dependencies across some or all of the container images stored in the repositories 132 (e.g., in the form of an aggregated directed graph, as shown in FIG. 4).”, further in e.g. Col. 12 line 24-50).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Stopel to incorporate the teaching of Featonby to utilize the above feature, with the motivation of reducing latency and improving the process, as recognized by (Featonby Abstract).
Claims 9-10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Stopel (US 20170109536 A1) in view of Rupprecht (US 20210096894 A1).
Regarding claim 9, Stopel teaches the computer-implemented method of claim 1.
Stopel does not disclose the below limitation.
Chen discloses wherein the scan metadata includes a vulnerability score corresponding to a vulnerable layer of the plurality of layers, further comprising assigning the vulnerability score to any of the additional container images that include a layer that matches the vulnerable layer (Chen [0010] “The system can arrange the container images in the queue so as to prioritize the scanning of higher-risk (i.e. high score) container images over lower-risk container images. This can reduce the vulnerability window discussed above. Additionally or alternatively, the system can arrange the container images in the queue so as to position container images with common contents adjacent to one another in the queue. The system can then maintain the common contents in memory between scans, so that the same contents are not repeatedly loaded and deleted from memory. The system may also flag the comment contents as having already been scanned, so that the same contents are not repeatedly virus scanned. This can reduce or eliminate the unnecessary latency and performance degradation discussed above.”, [0016] “Since the other container images 112 have already been virus scanned and designated safe, having more content in common with the other container images 112 can indicate that container image A is less risky (more likely safe), whereas having less content in common with the other container images 112 can indicate that container image A is more risky. As a result, the server 102 can place container image A later in the queue 108 if the score 114 is higher, so that container image A is virus scanned at a later time. Or the server 102 can place container image A earlier in the queue 108 if the score 114 is lower, so that container image A is virus scanned sooner.”, where the system assign image contents risk level/score and arrange the different images having the same contents adjacent to each other so that images with higher risk level/score are prioritized).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Stopel to incorporate the teaching of Chen to utilize the above feature, with the motivation of prioritizing the scanning of higher-risk container images over lower-risk container images, as recognized by (Chen [0010]).
Regarding claim 20, claim 20 recites similar limitations to claim 9, therefore rejected with the same rationale/motivation applied to claim 9.
Regarding claim 10, Stopel in view of Chen teaches the computer-implemented method of claim 9.
Stopel does not disclose the below limitation.
Chen discloses wherein scanning the additional container images includes prioritizing scans of the additional container images responsive to the vulnerability score (Chen [0010] “The system can arrange the container images in the queue so as to prioritize the scanning of higher-risk (i.e. high score) container images over lower-risk container images. This can reduce the vulnerability window discussed above. Additionally or alternatively, the system can arrange the container images in the queue so as to position container images with common contents adjacent to one another in the queue. The system can then maintain the common contents in memory between scans, so that the same contents are not repeatedly loaded and deleted from memory. The system may also flag the comment contents as having already been scanned, so that the same contents are not repeatedly virus scanned. This can reduce or eliminate the unnecessary latency and performance degradation discussed above.”, [0016] “Since the other container images 112 have already been virus scanned and designated safe, having more content in common with the other container images 112 can indicate that container image A is less risky (more likely safe), whereas having less content in common with the other container images 112 can indicate that container image A is more risky. As a result, the server 102 can place container image A later in the queue 108 if the score 114 is higher, so that container image A is virus scanned at a later time. Or the server 102 can place container image A earlier in the queue 108 if the score 114 is lower, so that container image A is virus scanned sooner.”, where the system assign image contents risk level/score and arrange the different images having the same contents adjacent to each other so that images with higher risk level/score are prioritized).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Stopel to incorporate the teaching of Chen to utilize the above feature, with the motivation of prioritizing the scanning of higher-risk container images over lower-risk container images, as recognized by (Chen [0010]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Wiest (US 20200159921 A1) discloses [0052] “…the portions of the new application image corresponding to previously-scanned and clean application image layers are identified. In one implementation, the previously-scanned and clean application image layers may correspond to core functionality base image(s) of the PaaS system used to build the application in combination with source code provided by an owner of the application. A central scan data store of the PaaS system may include information indicating which application images have been scanned with a clean result.”, [0053] “At block 340, the remaining portions of the new application image that are not part of the identified portions are scanned.
McPherson (US 20170147813 A1) discloses [0045] “skipping a scan of the layers of the built application image that have already been scanned in previous scans”
Pieczul (US 20230252157 A1) in e.g. [0051] “Usage of layers in a container image has several benefits, such as saving space in the container registries, reducing the amount of redundant data that needs to be downloaded to deploy container images. Given a particular container image, multiple instances of containers can be deployed having that particular container image.”, [0064] “As seen in FIG. 3, several layers are shared by different container images. For example, the Linux Slim base layer is shared by all the eight container images; the Java base layer is shared by container images for Services 1, 2, 3, and 4; the Jetty base layer is shared by container images for Services 2, 3, and 4; the Python base layer is shared by container images for Services 5, 6, 7, and 8; the Django base layer is shared by container images for Services 7 and 8. If a vulnerability exits in a particular layer, then that vulnerability impacts and exists in all the container images that contain that layer. For example, if a vulnerability is detected in the Django base, that the container images for Services 7 and 8, which contain the Django layer, will be impacted by that vulnerability.”, [0065] “Various different ways may be used to store and represent the various layers and their hierarchical relationships for a container image. In one implementation, the metadata for a container image may store information for a tree or graph, where the nodes of the tree or graph are indicative of the layers and the edges of the tree/graph represent the hierarchical relationships between the layers for that container image.”
Suarez (US 10032032 B2) discloses software container registry inspection.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BASSAM A NOAMAN whose telephone number is (571)272-2705. The examiner can normally be reached Monday-Friday 8:30 AM-5:00PM.
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, Eleni A. Shiferaw can be reached at (571) 272-3867. 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.
/BASSAM A NOAMAN/Primary Examiner, Art Unit 2497
Prosecution Insights