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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 03/10/2026 has been entered.
Response to Amendments
This non-final office action is in response to amendment filed on 02/16/2026.
Claims 1, 8, and 15 have been amended, no claims have been canceled. Claims 1 -
20 remain pending in the application.
Response to Amendment
The amended filed 02/16/2026 has been entered. See response to amendments.
Response to Arguments
Applicant’s amendments and arguments are fully considered and are
persuasive however arguments are moot in view of new ground of
rejection below.
Remarks regarding applicant’s amendment to dependent claims 2-7, 9-14, and 16-19 the applicant is relying on the newly added amendments of the independent claims 1, 8, and 15. Please see Examiner’s response above and the detail of the rejection..
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.
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, 8, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Ramasamy et al. (US-20210173935-A1hereafter Ramasamy), in view of Lee et al. (US-20240169062-A1 hereafter Lee), in further view of Dubey et al. (63507157 hereafter Dubey (the reference 63507157 is provisional application of publication US 20240411895 A1)).
Regarding claim 1 Ramasamy disclose a computer implemented method for managing containers (see Ramasamy par.0030: “a method, a computer readable
medium, or a platform-as-a-service (PaaS) product for scanning and rectifying security vulnerabilities in containerization platforms and updating security rules. In some examples, a technical advantage of the present disclosures described herein is the identification of security vulnerabilities in containers and/or their associated images. Another technical advantage may be correcting such security vulnerabilities by updating the containers and/or their associated images with security updates”.), the computer implemented method comprising: retrieving, by a processor set, a container image from a container repository (see Ramasamy par.0035: “The scan engine 101 may be further configured to receive container images 111, which may already be stored in the memory 106 or may be received from external systems 120. In an embodiment, a container image 111 may be received from a container image repository 121 of an external system 120.”, par.0061: “The system circuitry may implement any desired functionality of the system 100. As just one example, the system circuitry may include one or more instruction processor 107 and memory 106.”), wherein the container image is retrieved for a host, and wherein the host comprises a copy of the container image (see Ramasamy par.0031: “the system 100 may include a
computing device 105, which may include a memory 106 and a processor 107” par.0035: “container images 111, which may already be stored in the memory 106.”). Examiner interpret the computing device 105 as the host;
Ramasamy appear to be silence Lee teaches
updating, by the processor set, the copy of the container image on the host based on one or more filesystems in the container image retrieved from the container repository and metadata for one or more application packages associated with the container image retrieved from the container repository, wherein the metadata is obtained from one or more files in the one or more
filesystems in the container image and, wherein the metadata comprises Software Bill of Materials (SBOM) metadata that describes composition of the application packages and provides detail information related to open-source components, third-party libraries, frameworks, and other software components that are used to build and deploy application (see Lee par.0033: “when a download request for a container image stored in a database is received from a user account, the one or more processors (hereinafter referred to as a processor) may store the container image in a temporary directory, which is a virtual storage interworking with the database, by copying the container image stored in the database.”, par0035 – 0036: “the database is configured to store the container image, and may mean a storage space of a specific platform in which the container image is stored for providing the container image to a plurality of user accounts, when the processor receives the download request from at least one of the plurality of user accounts. the database is configured to store the container image, and may mean a storage space of a specific platform in which the container image is stored for providing the container image to a plurality of user accounts, when the processor receives the download request from at least one of the plurality of user accounts.”, par.0070-0072: “when the image analysis process is started, the processor may complete a vulnerability inspection for the container image by extracting policy information for the container image from the container image to store the policy information in a policy evaluation database, and extracting software bill of materials (SBOM) information from the container image from which the policy information is extracted… the processor may extract the SBOM information from the container image. The SBOM information may mean metadata representing components of software. In this regard, the processor may extract, from the container image, the SBOM information together with OS information, file information, sensitive information file list information, user access account information, package information in the image, and build information.”, par.0109: “when it is determined that the container image is normal by performing the function of the abnormality determination step.. the processor may allow the user account to download the container image by allowing the download of the container image… when it is determined that the container image is normal by performing the function of the abnormality determination step, the one or more processors (hereinafter referred to as a processor) may allow an access of the user account to the temporary directory…. Par.0114: “when the user account has downloaded the container image, the processor may delete the temporary directory, and simultaneously generate analysis completion information for the container image to store the analysis completion information by matching the analysis completion information to the container image stored in the database.” Examiner interpret that based on the extracted information obtain such as SBOM from the retrieve container an allow download (update) is perform in the user account (host) to download (update) the host container image.); and
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Ramasamy teaching “a scan engine 101 may: access a container image repository 121 (block 401); and, search for a container image 111 (block 402). For example, the scan engine 101 may access a Docker repository 121 and search for a Docker image 111. In an embodiment, the scan engine 101 may check the accessibility and permissions associated with the image 111 in order to determine any restrictions assigned by the repository 121 (block 403). The scan engine 101 may: receive and/or extract the image 111 (block 404); and, read the image 111 (block 405) (e.g., read the metadata 131 from the image layers 114 of the image file 111). These two steps may be performed by the image extractor 301 and the REST API 302, respectively. The scan engine 101 may analyze the individual image layers 114 of the image 111 (block 406).”, (see Ramasamy par.0042) with Lee teaching “when it is confirmed from the vulnerability inspection that the vulnerability exists in the container image and it is confirmed from the malicious code infection inspection step that the container image is not infected with the malicious code, the processor may generate first analysis result information including a content that the container image is not infected with the malicious code and the vulnerability exists in at least one of the SBOM information, the OS information, the file information, the sensitive information file list information, the user access account information, the package information in the image, and the build information”, (see Lee par.0082).
Ramasamy in view of Lee do not explicitly teach however Dubey teaches
creating, by the processor set, a data structure comprising information for fixing security vulnerabilities and exposures for one or more containers for the container image on the host based on the metadata for the application packages, information associated with the application packages, and information associated with containers for the container image on the host. (See Dubey par.0045: “The server (126) also may include a data structure generator (134). The data structure generator (134) is software or application specific hardware that is programmed, when executed, to generate the SBOM data structure (110). In an embodiment, the SBOM data structure (110) is generated from the dependency graph”, par.0058: “Collecting the usage data provides additional information which aids the construction of the SBOM data structure. For example, the usage data may indicate which image is deployed where, and by whom. Thus, it is easier to use the SBOM data structure to quickly locate containers, images, or components that may be affected by a vulnerable component.”, par.0059: “transforming the SBOM, the dependency graph, and the usage data into a SBOM data structure. The SBOM data structure includes a searchable data object that is searchable by at least one of: the containers, the software images, the one or more corresponding components of the software images, the metadata, and the usage data. By transforming, the SBOM data structure effectively maps component usage, application deployment, and vulnerability information together”, par.0064: “querying the SBOM data structure to determine a particular software image, in the software images, which includes the component. For example, a query command may be submitted to the SBOM data structure using the identified components as a basis for the search. The relationship of the identified component to other components, images, and containers may then be presented to a user, or may be submitted to an automated software process as described with respect to block 214. Block 214 includes remediating the component in the particular software image to generate a remediated software image. The software image may be remediated by several different techniques. For example, the software image may be remediated by replacing the component within the software image, and then saving the updated software image. In another example, the component may be updated, such as by permitting the component to be updated using an external updated provided by a third-party provider. In another example, a user may adjust one or more of the containers, the software images, the identified component, or perhaps other related containers, software images, or components in the software project.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Ramasamy in view of Lee described above with Dubey teaching “SBOM data structure is useful for security assessments, quality assurance, and compliance review management for software projects. Often in major business deals, a checkpoint is security and privacy concerns. The SBOM data structure may be used for customer audits and regulating compliances to provide security and privacy for the software project. Having the ability to generate SBOM data structures internally is a useful approach because, data scientists can produce multiple SBOM data structures throughout the development process in order to track component changes and search for vulnerabilities as new issues become known in older software.”, (see Dubey par.0096).
Regarding claim 8 is a system claim that recites similar limitations as the computer-method claim 1 and is rejected based on the same rational as claim 1.
Regarding claim 15 is a computer program product claim that recites similar limitations as the computer-method claim 1 and is rejected based on the same rational as claim 1. (see Ramasamy par.0065-0066: “All of the discussion, regardless of the particular implementation described, is exemplary in nature, rather than limiting. For example, although selected aspects, features, or components of the implementations are depicted as being stored in memories, all or part of the system or systems may be stored on, distributed across, or read from other computer readable storage media, for example, secondary storage devices such as hard disks, flash memory drives, floppy disks, and CD-ROMs… The respective logic, software or instructions for implementing the processes, methods and/or techniques discussed above may be provided on computer readable storage media. The functions, acts or tasks illustrated in the figures or described herein may be executed in response to one or more sets of logic or instructions stored in or on computer readable media.”).
Claims 2 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Ramasamy et al. (US-20210173935-A1hereafter Ramasamy), in view of Lee et al. (US-20240169062-A1 hereafter Lee), in view of Dubey et al. (63507157 hereafter Dubey (the reference 63507157 is provisional application of publication US 20240411895 A1)), in further view Tarasov et al. (GB-2604967-A hereafter Tarasov).
Regarding claim 2 Ramasamy in view of Lee, and Dubey disclose the computer implemented method of claim 1 Lee further teaches further comprising:
determining, by the processor set, whether the container image retrieved from the container repository comprises the metadata for the one or more application packages associated with the container image (see Lee par.0070-0072: “when the image analysis process is started, the processor may complete a vulnerability inspection for the container image by extracting policy information for the container image from the container image to store the policy information in a policy evaluation database, and extracting software bill of materials (SBOM) information from the container image from which the policy information is extracted… the processor may extract the SBOM information from the container image. The SBOM information may mean metadata representing components of software. In this regard, the processor may extract, from the container image, the SBOM information together with OS information, file information, sensitive information file list information, user access account information, package information in the image, and build information.”, par.0109: “when it is determined that the container image is normal by performing the function of the abnormality determination step.. the processor may allow the user account to download the container image by allowing the download of the container image”); and
Ramasamy in view of Lee, and Dubey appear to be silence however Tarasov teaches
in response to determining the container image received from the container
repository does not comprise the metadata for the one or more application packages associated with the container image (see Tarasov par.0087: “where a metadata package for the software package is retrieved. In one embodiment, the metadata package may be retrieved from a public repository (e.g., a database such as a public package metadata store, etc.).”, par.0093: “where a need for a file is identified during the installation of the software package. In one embodiment, a request for a specific file within the software package may be received during the installation of the software package. For example, request may be received from a compiler that is installing the software package. In another embodiment, the installation of the software package may require a file that is not present within the metadata package.”), generating, by the processor set, the metadata for the one or more application packages associated with the container image. (See Tarasov par.0094-0095: “in response to identifying the need for the file, a local cache of the node where the container image is being created may be searched to see if the file is located within the cache. In another embodiment, if the file is located at the cache, it may be retrieved from the cache. In yet another embodiment, if the file is not located at the cache, it may be retrieved from a file repository… The metadata placeholder for the file (e.g., the stub for the file), may be identified at the node. In another embodiment, a pointer to the location of the file may be associated with the metadata placeholder. In yet another embodiment, the pointer may be used to determine the location of the file and retrieve the file. In still another embodiment, the file may be retrieved and may be used to continue and/or complete the installation of the software package.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Ramasamy in view of Lee, and Dubey teaching of claim 1 with Tarasov teaching “the metadata package may contain only file metadata without the actual files contained within a container image. As a result, installing the metadata package may only require copying the metadata and associated pointers, without having to copy the data itself. Data needed during the installation of the software package may be retrieved on-demand as necessary. This may reduce an amount of storage necessary to install the software package, which may improve a performance of a hardware computing device implementing the installation of the software package.”, (see Tarasov par.0096).
Regarding claim 9 is a system claim that recites similar limitations as the computer-method claim 2 and is rejected based on the same rational as claim 2.
Claims 3, 10, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Ramasamy et al. (US-20210173935-A1hereafter Ramasamy), in view of Lee et al. (US-20240169062-A1 hereafter Lee), in view of Dubey et al. (63507157 hereafter Dubey (the reference 63507157 is provisional application of publication US 20240411895 A1)), in further view of Stopel et al. (US-20170116412-A1 hereafter Stopel).
Regarding claim 3 Ramasamy in view of Lee, and Dubey disclose the computer implemented method of claim 1 Ramasamy in view of Lee, and Dubey do not explicitly teach however Stopel teaches wherein the data structure is a table comprising: statuses of the one or more application packages and the one or more containers for the container image, identifiers for the one or more containers for the container image, versions of the one or more application packages, information associated with package management tools that are used to manage application packages, whether containers are using versions of application packages from container images or received updates, and file paths for the one or more application packages. (See Stopel par.0044: “a generated security profile (data structure) includes safe actions, authorized actions, or both, to be performed by the respective software (e.g., the container 311-C). The security profile may include, but is not limited to, a list of allowed system calls, a list of permissible network actions, a list of permissible filesystem actions, signatures of executable files of spawned processes, or a combination thereof.”, par.0058: “a security profile 400 is illustrated in FIG. 4. The metadata field 410 includes the container image unique identifier <ID>, profile creation time <Creation_Time>, and last update time <Last_Update>. The system calls field 420 lists the system calls <syscall> that can be triggered at runtime. The spawned processes field 430 includes the signature and name each spawned process(es) executed at runtime by the APP container <process_name.sub.1; signature>. The process name is identified in the executable file header. The permissible network actions field 440 includes a list of permissible network actions <Net_action>. The permissible filesystem actions field 450 includes the permissible filesystem actions <fs_action>. The security profile 400 may be saved in the database 340 and indexed using the container image identifier.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Ramasamy in view of Lee, and Dubey teaching of claim 1 with Stopel teaching “system for profiling container images to result in a security profile for each container image. The profiling is performed through static analysis of all layers in a container image. That is, the profiling of container images is performed prior to runtime of a container. A generated security profile includes safe actions, authorized actions, or both, to be performed by the respective application (APP) container when executed. In an embodiment, a security profile may include at least one of: a list of allowed (whitelist) system calls, a list of permissible network actions, a list of permissible filesystem actions, and signatures of executable files of spawned processes.”, (see Stopel par.0033).
Regarding claim 10 is a system claim that recites similar limitations as the computer-method claim 3 and is rejected based on the same rational as claim 3.
Regarding claim 16 is a computer program product claim that recites similar limitations as the computer-method claim 3 and is rejected based on the same rational as claim 3.
Claims 4 – 5, 11 – 12, and 17 - 18 are rejected under 35 U.S.C. 103 as being unpatentable over Ramasamy et al. (US-20210173935-A1hereafter Ramasamy), in view of Lee et al. (US-20240169062-A1 hereafter Lee), in view of Dubey et al. (63507157 hereafter Dubey (the reference 63507157 is provisional application of publication US 20240411895 A1)), in further view of Mamgain et al. (US-11243758-B2 hereafter Mamgain).
Regarding claim 4 Ramasamy in view of Lee, and Dubey disclose the computer implemented method of claim 1 Ramasamy in view of Lee, and Dubey do not explicitly teach however Mamgain teaches further comprising:
receiving, by the processor set, using a package management tool, an update for the one or more application packages associated with the container image (see Mamgain Col.4 lines 51-52: “Program 150 is a program for cognitively determining and applying image updates to one or more containers”, Col.5 lines 40-46: “program 150 identifies an image pull and pauses, delays, or halts the pull ( e.g., image storage) until program 150 can identify image parameters and determine if the image is required, as discussed below. In various embodiments, program 150 receives a notification, along with associated information and metadata, regarding a new pushed, updated, or stored image”);
determining, by the processor set, a set of one or more containers on the host that are affected by the update based on the data structure (see Mamgain Col.5 lines 24-26: “FIG. 2 is a flowchart depicting operational steps of program 150 for cognitively determining and applying image updates to one or more containers,” Col. 6 lines 6-17: “If program 150 determines that there is an updated image (decision step 204, yes branch), then program 150 identifies updated image parameters (step 206). Program 150 identifies updated image parameters. In an embodiment, program 150 scans (e.g., depth-first scanning, etc.) an image filesystem, identifying all subcomponents ( e.g., dependencies, subprograms, and sub-containers) subfiles and subfolders contained within a container. In this embodiment, program 150 identifies said subcomponents by creating one or more sets of filesystem information such as filenames, folder names, parent folders, subfolders, associated permissions, creation dates, modified dates, and associated metadata”, lines 48-62: “Program 150 determines that the updated image is required (step 208). Program 150 determines the scope (e.g., intention) of an update and reconciles said scope with the purpose of the container. Program 150 utilizes the update parameters, identified in step 206, contained within a set of update information to determine whether an updated image is required. Tn an embodiment, the term "require(s)" (e.g., mandatory, compulsory, recommended, etc.) represents a change (e.g., update, patch, version, etc.) containing a fix for one or more features utilized by a current container, image, or application. Program 150 identifies a purpose and/or one or more features associated with a current container. In this embodiment, program 150 receives, retrieves, or identifies one or more functions associated with a container and/or associated image.”); and
applying, by the processor set, using the package management tool, the update to the one or more application packages associated with the container image for the set of one or more containers. (See Mamgain Col.7 lines 62-67: “Program 150 deploys image (step 210). Responsive to program 150 determining that the updated is required or mandatory, then program 150 pulls, receives, or stores the updated image, detailed in the above steps, from registry 122 or one or more image repositories, into one or more production environments or containers.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Ramasamy in view of Lee, and Dubey teaching of claim 1 with Mamgain teaching “Embodiments of the present invention recognize that by determining, pre-pull, an impact of an updated image to an application, system efficiency and overall uptime are increased. Embodiments of the present invention identifies and determines new features and bug fixes of a detected new image to determine whether the updated image is required.”, (see Mamgain Col.2 lines 58-64).
Regarding claim 11 is a system claim that recites similar limitations as the computer-method claim 4 and is rejected based on the same rational as claim 4.
Regarding claim 17 is a computer program product claim that recites similar limitations as the computer-method claim 4 and is rejected based on the same rational as claim 4.
Regarding claim 5 Ramasamy in view of Lee, Dubey, and Mamgain disclose the computer implemented method of claim 4 Ramasamy further teaches further comprising:
initiating, by the processor set, a container in the set of one or more containers on the host (See Ramasamy par.0036: “A container 113 may be the instantiation of the image 111. Accordingly, the code in the initial image 111 may be executed in order to generate an interactive container 113 that may be modified.”);
performing, by the processor set, a health check to the initiated container (See Ramasamy par. 0037: “The CVEs 124 may list the identifiable security vulnerabilities 112 that may affect a containerized application 115, the source code and data of the container 113, the layers of the image 111, the container engine 128 (not shown), components shared across the containerization platform, the host operating system 129 and its kernel 130 (not shown), and/or the API server. The auto rule update engine 103 utilizes the CVEs 124 to enable automation of vulnerability management, security measurement, and compliance”); and
Ramasamy in view of Lee appear to be silence however Dubey teaches
updating, by the processor set, the data structure based on a result of the health check for the container. (See Dubey par. 0067: “the SBOM data structure may be updated. More specifically, the method also may include generating a revised SBOM data structure by repeating generating, building, retrieving, and transforming using the remediated software image. In this case, the method also may include storing the revised SBOM data structure in the non-transitory computer readable storage medium. Thus, the SBOM data structure may be updated over time in order to reflect the current state of the software project.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Ramasamy in view of Lee, Dubey and Mamgain teaching of claim 4 with Ramasamy teaching “The auto rule update engine 103 may also include a CVE data source parser 508 that may arrange CVE data 509 (not shown), which may be received from the CVE data source 501 in different formats, into a uniquely format compatible with the security vulnerability database 118. The reformatted CVE data 509 may include the CVE identification numbers 125 and the CVE descriptions 126 of CVEs 124”, (Ramasamy see par.0045), with Dubey teaching “During the runtime security stage (304), the software project is checked for vulnerabilities and other issues prior to release of the software project via a release pipeline (318). Data scientists may use the SBOM data structures in the SBOM database (310) to check the software project for vulnerabilities, and then remediate any vulnerabilities that are found.”, (see Dubey par.0076).
Regarding claim 12 is a system claim that recites similar limitations as the computer-method claim 5 and is rejected based on the same rational as claim 5.
Regarding claim 18 is a computer program product claim that recites similar limitations as the computer-method claim 5 and is rejected based on the same rational as claim 5.
Claims 6, 13 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Ramasamy et al. (US-20210173935-A1hereafter Ramasamy), in view of Lee et al. (US-20240169062-A1 hereafter Lee), in view of Dubey et al. (63507157 hereafter Dubey (the reference 63507157 is provisional application of publication US 20240411895 A1)), in view of Mamgain et al. (US-11243758-B2 hereafter Mamgain), in view of Dorrans et al. (US-20200074084-A1 hereafter Dorrans), in further view of Wong et al. (US-10379841-B2 hereafter Wong).
Regarding claim 6 Ramasamy in view of Lee, Dubey, and Mamgain disclose the computer implemented method of claim 5, Dubey further teaches wherein updating, by the processor set, the data structure based on the result of the health check for the container (See Dubey par. 0067: “the SBOM data structure may be updated. More specifically, the method also may include generating a revised SBOM data structure by repeating generating, building, retrieving, and transforming using the remediated software image. In this case, the method also may include storing the revised SBOM data structure in the non-transitory computer readable storage medium. Thus, the SBOM data structure may be updated over time in order to reflect the current state of the software project.”).comprises:
Ramasamy in view of Lee, Dubey and Mamgain do not explicitly teach however Dorrans teaches in response to determining that the container does not pass the health check, updating, by the processor set, the data structure to indicate that the container uses versions of the one or more application packages based on the copy of the container image (See Dorrans par.0307: “a vulnerability feed 232 which serves a list 220 of vulnerable component 218 descriptions, in the form of vulnerable package 902, 218 descriptions.
PNG
media_image1.png
835
283
media_image1.png
Greyscale
”);
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Ramasamy in view of Lee, Dubey, and Mamgain of claim 5 with teaching Dorrans teaching “A tool may ensure that the vulnerability list 220 it references is up to date on loading the tool, and continue to background refresh the list every K hours (K being configurable). When a solution 124 is loaded, or a package reference is added, a development tool may parse the solution or package information and compare it against the current vulnerability list. If a vulnerability is discovered, either in the packages, or the currently targeted runtime, then the tool would log a warning in an error window, and ensure that the window is brought into focus to highlight the vulnerability for developers.”, (see Dorrans par.0306).
Ramasamy in view of Lee, Dubey, Mamgain and Dorrans appear to be silence however Wong teaches
and
reinitiating, by the processor set, the container using versions of the one or more application packages based on the copy of the container image. (See Wong Col.9 lines 43-56: “it is conceivable that an error may be introduced where the container composes the layers, instead of first building an updated version of the container image from a Dockerfile. Therefore, in one or more aspects, a new command line, such as "Docker rollback", may be provided to account for an issue with running of the updated container. Although the above described GE_ version approach safeguards against unwanted upgrades to a base image version, an issue could conceivably still arise as a result of the update. A rollback command may use the backup copy to restore the previously workable application container, and may set the upgrade_switch to false to disable the unexpected unsafe upgrade from occurring again.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Ramasamy in view of Lee, Dubey, Mamgain, and Dorrans described above with Wong teaching “Based on identifying an issue with running of the updated container, processing may automatically rollback the updated container to the original application container. The automatically rolling back may include reestablishing the application container, at least in part, from the backup settings of the original application container.”, (see Wong Col.10 lines 48-54).
Regarding claim 13 is a system claim that recites similar limitations as the computer-method claim 6 and is rejected based on the same rational as claim 6.
Regarding claim 19 is a computer program product claim that recites similar limitations as the computer-method claim 6 and is rejected based on the same rational as claim 6.
Claims 7, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Ramasamy et al. (US-20210173935-A1hereafter Ramasamy), in view of Lee et al. (US-20240169062-A1 hereafter Lee), in view of Dubey et al. (63507157 hereafter Dubey (the reference 63507157 is provisional application of publication US 20240411895 A1)), in further view of Mamgain et al. (US-11243758-B2 hereafter Mamgain), in further view of Emeis et al. (US-10241778-B2 hereafter Emeis).
Regarding claim 7 Ramasamy in view of Lee, Dubey and Mamgain disclose the computer implemented method of claim 5, Dubey further teaches wherein updating, by the processor set, the data structure based on the result of the health check for the container (See Dubey par. 0067: “the SBOM data structure may be updated. More specifically, the method also may include generating a revised SBOM data structure by repeating generating, building, retrieving, and transforming using the remediated software image. In this case, the method also may include storing the revised SBOM data structure in the non-transitory computer readable storage medium. Thus, the SBOM data structure may be updated over time in order to reflect the current state of the software project.”). comprises:
Ramasamy in view of Lee, Dubey and Mamgain do not explicitly teach however Emeis teaches
in response to determining that the container passes the health check, updating, by the processor set, the data structure to indicate that a default option for running the one or more application packages for the container is based on the latest versions of the one or more application packages from the update. (See Emeis Col.14 lines 39-47: “version state visualizations are used to indicate version state information for each component (e.g., microservice container/container image) of the microservices application 300. The version state visualizations (data structure) in the illustrated examples include icons, emojis, and colors. For example, the illustrated examples use thumbs up and thumbs down symbols (e.g., 310c of FIGS. 3A and 3B) to indicate whether components designated as the “latest” version are up-to-date or out-of-date.”, Col.15 lines 44-60: “the HAProxy component 310 is using version “latest” (310b), and its version state visualizations include a thumbs up icon (310c). As explained throughout this disclosure, a software component designated as version “latest” may not necessarily be up-to-date, as a newer “latest” version of the software component may have been released. Thus, in some embodiments, checksums (health check) may be used to determine if an application is in fact using the most recent version of the software component (e.g., by comparing the checksum of the version used by the application with the checksum of the “latest” version from the developer or vendor). In the illustrated example, the thumbs up icon (310c) indicates that the most recent version of the HAProxy component 310 is in fact being used (e.g., based on the checksums, the version used by the microservices application 300 is the same as the “latest” version available from the developer, vendor, or a software registry”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Ramasamy in view of Lee, Dubey and Mamgain teaching of claim 5 with Emeis teaching “version state information may also be derived using checksums. For example, in some cases, each new version of a software package may simply be designated as the “latest” version, without a specific version number. In this manner, it may be difficult to determine whether a software application is using an updated or outdated version of the software package. For example, while a software application may be using a version of the software package designated as “latest,” a newer “latest” version of the software package may have been released. Thus, in some embodiments, version manager 233 may use checksums to determine if the application is using the most recent version of a software package. For example, version manager 233 may first retrieve the “latest” version of that software package (e.g., from a software registry), and then compare the checksums of the retrieved “latest” version and the version used by the application. If the checksum of the retrieved “latest” version of the software package is different from the checksum of the version used by the application, then the application may be using an outdated version of the software package.”, (see Emeis Col.12 lines 10-33:).
Regarding claim 14 is a system claim that recites similar limitations as the computer-method claim 7 and is rejected based on the same rational as claim 7.
Regarding claim 20 is a computer program product claim that recites similar limitations as the computer-method claim 7 and is rejected based on the same rational as claim 7.
Conclusion
The prior art made of record and not relied upon is considered pertinent to
applicant's disclosure:
Kumar et al. (US-12014162-B2) systems and methods for Implementing controlled updates of containers in a distributed application deployment environment. Receiving a request to update a target container of a plurality of containers within a deployed computing unit; identifying an updated configuration object to be applied to the target container based on the request; receiving or computing a health indicator representative of performance of the deployed computing unit or other containers to which the updated configuration object has been applied; and assigning the updated configuration object to the target container based on the health indicator.
Hufsmith et al. (US-20200097662-A1) Process for determining threat scores for container images or distributed applications that consider the results of a multitude of different scanners and other factors such as context information which may include information about a given execution environment The scanner properties determined by each vulnerability scanning engine are adjusted responsive to properties of the context and normalized to determine component threat scores for the container image. Then the component threat scores for the container image are combined to generate a combined threat score for the container image within the context of the execution environment. In this way, the combined threat score represents an overall measure of the exposure associated with that container image within the context of the execution environment.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUILIO MUNGUIA whose telephone number is (571)270-5277. The examiner can normally be reached M-F 7:30 - 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.
/DUILIO MUNGUIA/Examiner, Art Unit 2497 /BASSAM A NOAMAN/Primary Examiner, Art Unit 2497