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 .
Examiner Notes
Examiner cites particular columns and line numbers in the references as applied to the claims below for convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references cited in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Response to Amendment
The Amendment filed 7/01/2026 has been entered. Claims 1-18 remain pending in the present Office Action.
The Amendments to the Specification and Abstract, in combination with the arguments regarding the Objections to the Specification have been fully considered and are sufficient to overcome the Objections previously presented.
The Amendments to the Claims have been fully considered and are sufficient to overcome the rejections under 35 U.S.C. 112(b) presented in the previous Office Action. The rejections under 35 U.S.C. 112(b) presented in the previous Office Action have been withdrawn.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-2, 4-8, 10-14, and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over SIENICKI et al. (U.S. Pub. No. 2022/0255966), hereinafter SIENICKI, in view of HALL et al. (U.S. Pub. No. 2021/0117175), hereinafter HALL, Amaro, JR. et al. (U.S. Pub. No. 2022/0404804), hereinafter Amaro, and Radev et al. (U.S. Pub. No. 2023/0130553), hereinafter Radev.
Regarding claim 1, SIENICKI teaches An information handling system (FIG. 12; [0180] – “FIG. 12 illustrates an example computing system 1200 suitable for implementing a secure container platform, executing secure containers, and/or implementing the various embodiments described above.”) comprising:
at least one processor (SOC 1202, processor 1208, 1210, 1212, and 1214; [0180] – “the computing system 1200 includes an SOC 1202, a clock 1204, and a voltage regulator 1206. The SOC 1202 may include a digital signal processor (DSP) 1208, a modem processor 1210, a graphics processor 1212, an application processor 1214 connected to one or more of the processors […] SOC 1202 may operate as central processing unit (CPU) that carries out the instructions of software application programs by performing the arithmetic, logical, control and input/output (I/O) operations specified by the instructions.”; [0182] – “Each processor 1208, 1210, 1212, 1214”); and
a memory (memory 1216; [0180] – “the computing system 1200 includes an SOC 1202, a clock 1204, and a voltage regulator 1206. The SOC 1202 may include a […] memory 1216”; [0183] – “The processors may be interconnected to one another and to the memory 1218”);
wherein the information handling system is configured to execute a secure containerization platform ([0180] – “FIG. 12 illustrates an example computing system 1200 suitable for implementing a secure container platform, executing secure containers, and/or implementing the various embodiments described above.”; [0065] – “ECG 110 includes […] a system image 220. The system image 220 may include a secure container platform 222”; [0096] – “Some embodiments may include an ECG 110 configured to run a service along with the modified container platform (secure container platform 222).”) configured to:
execute a plurality of containerized applications ([0030] – “the various embodiments include systems and components (e.g., ECGs, etc.) configured to create and use licenses and secure containers to run software applications at the edge of the network and/or to implement a secure container framework for running all or portions of a software application at the edge of the network.”; [0053] – “the ECG 110 may be classified as an edge computing device with a Lightweight Virtualization Framework (LVF). Using the LVF, the ECG 110 may implement and enable many applications using a compute distribution method. The use of a LVF may also enable the ECG 110 to implement applications as local containers.”; [0072] – “the platform and/or application containers of an ECG 110 may be governed by the secure container platform 222”; [0180] – “executing secure containers”);
provide an isolation mechanism to prevent data from being transferred among the containerized applications ([0034] – “The term “container” may used herein to refer to a software component that supports virtualization technology, enables the abstraction (or virtualization) of computing resources, implements a sandbox, and/or separates software applications from their underlying infrastructure (thus making them infrastructure agnostic). For example, a container may be one of a plurality of isolated user space instances operating on the kernel, each of which operates under the illusion of having full or exclusive access to the processors, peripherals, memory and I/O of the computing system. Application programs running inside of a container may only see the container's contents and devices assigned to that container. In addition to these isolation mechanisms, a container or kernel may include resource-management features that limit the impact of one container's activities on other containers.”; [0067] – “the secure container platform 222 solution may be configured to implement security restrictions on containers. These security restrictions may […] ensure that containers do not interfere with the host or other containers (both running processes and data).”; [0094] – “Some embodiments may run software applications in a sandbox called a container, which constrains subset of the system resources the software applications can access. The container may be modified into a secure container suitable for licensing or using licenses to allow, restrict, or control access or use of all or portions of the available hardware and services. Using the secure container, software applications can only access a specific piece of hardware or service if they have a license to access it.”);
provide security services for the containerized applications, the security services including […] authentication […] services ([0067] – “the secure container platform 222 solution may be configured to implement security restrictions on containers . These security restrictions may ensure that the source of a container may be authenticated” ; [0172] – “the secure container platform/environment may generate, include, issue or use specific self-sign certificates for authentication of containers”); […]
wherein the information handling system is an edge node ([0028] – “FIGS. 12 is a component block diagram of a computing system that could be included in an edge device (e.g., ECG, etc.) and/or used to implement various embodiments.”).
SIENICKI fails to expressly teach the security services including encryption, […] and monitoring services; provide a communication channel between the containerized applications and at least one other information handling system; provide a management and monitoring interface to the containerized applications that is accessible from the at least one other information handling system; and provide an integration component configured to integrate the secure containerization platform with infrastructure of a manufacturer of the information handling system, wherein the integration component is configured to interface the secure containerization platform with one or more management tools of the manufacturer such that the one or more management tools of the manufacturer are usable by the secure containerization platform to manage and monitor the containerized applications; and the edge node is an edge node a hyper-converged infrastructure (HCI) system.
However, HALL teaches wherein the information handling system is an edge node of a hyper-converged infrastructure (HCI) system ([0001]-[0002] – “Current hybrid cloud technologies allow software-defined data centers (SDDCs) to be deployed in a public cloud, such as the VMware Cloud on AWS solution, which allows entities, such as enterprises, to modernize, protect and scale their applications leveraging the public cloud. However, some entities cannot move their SDDCs to the public cloud, either because the data cannot leave their premises, or the compute power needs to be close to the applications at their edge locations. […] manage their SDDCs, especially those deployed at their edge locations.”; [0029] – “each on-premise hyper-converged system includes a physical edge appliance”; [0066] – “system integrator is requested to procure hardware components of the on-premise hyper-converged systems, including physical gateway appliances, to assemble the hardware components to produce assembled systems […] using the physical gateway appliances to initiate a bring-up process for each of the assembled systems.”).
SIENICKI and HALL are considered to be analogous art to the claimed invention because they reasonably pertinent to the problem faced by the inventor of providing a containerization platform at an edge node. It would have been obvious to one of ordinary skill in the art to have modified the teaching of SIENICKI to incorporate the teachings of HALL. The teachings of HALL allow for an on-premise hyper-converged system, which provides a software-defined data center with the complete infrastructure needed to process workloads using VMs or containers (HALL: [0018] and [0034]), to be implemented at the edge location for an entity to ensure their data does not leave their premises and keep compute power close to the applications (HALL: [0001]-[0002]).
The combination of SIENICKI in view of HALL fails to expressly teach the security services including encryption, […] and monitoring services; provide a communication channel between the containerized applications and at least one other information handling system; provide a management and monitoring interface to the containerized applications that is accessible from the at least one other information handling system; and provide an integration component configured to integrate the secure containerization platform with infrastructure of a manufacturer of the information handling system, wherein the integration component is configured to interface the secure containerization platform with one or more management tools of the manufacturer such that the one or more management tools of the manufacturer are usable by the secure containerization platform to manage and monitor the containerized applications.
However, Amaro teaches a containerization platform configured to provide security services for the containerized applications ([0090] – “The SDCS Hyper Converged Infrastructure (HCI) operating system 210 executes on the computing platform 208, and may be built based on any suitable general purpose HCI operating system (OS) such as Microsoft Azure Stack, VMWare HCI, Nutanix AOS, Kubernetes Orchestration, including Linux Containers (LXC/LXD), Docker Containers, Kata Containers, etc. […] in the SDCS 200 these SD HCI OS support services are dynamically responsive to the logical or abstracted process control system of the SDCS 200, e.g., to the software components of the application layer 212 of the SDCS 200.”; [0095] – “Within the architecture of the SDCS 200, the application layer software components 235-248 may execute in containers”), the security services including encryption, authentication, and monitoring services ([0021] – “security services with the SDCS […] authentication services, encryption services”; [0103] – “the other SD HCI OS services 225 may include a service life cycle management service, a discovery service, a security service, an encryptor service, a certificate authority subsystem service, a key management service, an authentication service, a time synchronization service, a service location service, and/or a console support service (all not shown in FIG. 2), to name a few.”; [0132] – “the performance-related services 252-260 of the SD HCI OS 210 may monitor performance parameters, resource usage, and/or criteria during run-time, detect any associated conditions which occur and/or which are predicted to occur, and provide and/or implement any changes in assignments of SD application layer software components (e.g., containers) 212 to hardware and/or software resources of the computing platform 208.”); provide a communication channel between the containerized applications and at least one other information handling system ([0013] – “the software defined networking layer communicatively couples and manages the networking or delivery of data between software defined application layer components and their respective endpoints, which may be other software defined application layer components, devices disposed in the process plant field environment, user interface devices, external systems, etc.”; [0076] – “user interfaces 20a-20e which are communicatively connected to the SDCS 100 […] laptops 20c, mobile devices 20d, and/or process plant-related applications executing in laptops 20c, mobile devices 20d, and/or vehicle systems 20e may be communicatively connected to SDCS 10”; [0105] – “any of the containerized SD control services 235 may communicatively connect, e.g., via the SD networking layer 210, with respective one or more devices disposed in the field environment 12 of the industrial process plant (e.g., process control field devices 60, 62, 70, 80, 90; user interface devices and/or other field environment devices) and/or with respective one or more user interfaces/user interface devices 20a-20e to transfer I/O data and/or other types of data there between when required to do so by the business logic of the containerized SD control service 235 and/or by the recipient device (or application or service executing on the recipient device).”); provide a management and monitoring interface to the containerized applications that is accessible from the at least one other information handling system ([0382] – “a visualization service, which may be one of the services 240 of FIG. 2, may be provided to generate one or more system configuration and/or runtime visualizations for a user (via a user interface) to assist the user in understanding the currently configured and operational relationships between the various logical and physical elements of the control system as well as to view one or more performance indicators for the logical and physical elements. […] this configuration interface may enable a user to change configuration details (such as pinning and nesting of logical and/or physical elements) on the fly or during run-time.”; [0383] – “The visualization service 3202 may subscribe to information from the orchestrator 222 for active visualizations, and/or may send one or more queries to the orchestrator 222 (and the configuration database 3203) when generating a visualization for a user via a user interface 3204. […] the user interface device 3204 (which may be any type of user interface, such as a laptop, a wireless device, a phone application, a workstation, etc.) […] logical elements (e.g., containers, such as control containers)”; [0389] – “the visualization service 3202 may create the hierarchy 3210 […] the hierarchy 3210 can be used to indicate dynamically assignable containers and may even be used or manipulated by the user to perform reassign of dynamically assignable containers during runtime. In this case, the visualization service 3202, upon receiving an instruction to reassign a container to another logical and/or physical element, will instruct the orchestrator 222 of the reassignment and the orchestrator 222 will perform the reassign of the container”; [0393] – “visualization or display screen 3500 that can be provided by or created by the visualization service 3202 […] the diagram 3500 illustrates various different performance indicators 3520 (indicating performance of the elements of the control system as currently running) for each of the logical elements or containers 3502, 3504, and 3506, including, in this example a message per second indicator, a storage utilization indicator, a network bandwidth indicator, and an error rate indicator”; [0132] – performance parameters, e.g. of the containers, are monitored, thus visualization 3500 may be considered a monitoring interface).
Amaro is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of ensuring the security of the containers. It would have been obvious to one of ordinary skill in the art to have modified the teachings of SIENICKI in view of HALL to incorporate the teachings of Amaro to incorporate the security services and the monitoring and management interface provided to at least one other information handling system as taught by Amaro. Incorporating the security services taught by Amaro, such as the authentication and encryption services would allow the secure containerization platform to control access to and data flow from the containers, and incorporating the monitoring service would allow for adjustment of the allocation of resources to containers to maintain a target level of performance and fidelity of operations (Amaro: Abstract, [0132], and [0260]). Incorporating the monitoring and management interface accessible from a communicatively connected information handling system would allow a user to easily view the current operational status of the containers of the system, diagnose and correct problems, and dynamically reassign containers (Amaro: [0380]-[0381] and [0386]).
The combination of SIENICKI in view of HALL and Amaro fails to expressly teach provide an integration component configured to integrate the secure containerization platform with infrastructure of a manufacturer of the information handling system, wherein the integration component is configured to interface the secure containerization platform with one or more management tools of the manufacturer such that the one or more management tools of the manufacturer are usable by the secure containerization platform to manage and monitor the containerized applications.
However, Radev teaches provide an integration component configured to integrate the secure containerization platform with infrastructure of a manufacturer of the information handling system, wherein the integration component is configured to interface the secure containerization platform with one or more management tools of the manufacturer such that the one or more management tools of the manufacturer are usable by the secure containerization platform to manage and monitor the containerized applications (FIG. 2 – virtualization layer 204 includes a hypervisor 210 (analogous to a “containerization platform”) and virtual rack manager (VRM) 125, 127 (“integration component”), which communicates with hardware management system (HMS) 108, 114 to manage the physical resources, such as physical servers (“infrastructure of a manufacturer of the information handling system”), where the HMS uses the operating systems (“management tools of the manufacturer”) of the physical equipment vendors to monitor and manage the physical resources. The hypervisor interfaces with the VRM to partition the physical resources to create and manage VMs (“containerized applications”). Monitoring the physical resources allocated to/used by the containerized applications is implicitly monitoring the containerized applications. [0023] – “a virtualization platform such as a hypervisor”; [0026] – “OS virtualization is also referred to herein as container virtualization. […] In a typical OS virtualization system, a host OS is installed on the server hardware. […] The host OS of an OS virtualization system is configured (e.g., utilizing a customized kernel, etc.) to provide isolation and resource management for processes that execute within the host OS (e.g., applications that execute on the host OS, etc.). The isolation of the processes is known as a container. […] Example OS virtualization environments include Linux Containers LXC and LXD, the DOCKER™ container platform, the OPENVZ™ container platform, etc.”; [0027]-[0028] – “a workload can be deployed to any of the virtualization environments. In some examples, techniques to monitor both physical and virtual infrastructure, provide visibility into the virtual infrastructure (e.g., VMs, virtual storage, virtual or virtualized networks and their control/management counterparts, etc.) and the physical infrastructure (e.g., servers, physical storage, network switches, etc.). Examples described herein can be employed with HCI-based SDDCs deployed using virtual server rack systems such as the virtual server rack 106 of FIG. 1. A virtual server rack system can be managed using a set of tools that is accessible to all modules of the virtual server rack system”; [0029]-[0031] – “A drawback of some virtual server rack systems is that different hardware components located therein can be procured from different equipment vendors, and each equipment vendor can have its own independent OS installed on its hardware […] virtual server rack systems additionally manage non-white label equipment such as original equipment manufacturer (OEM) equipment. Such OEM equipment includes OEM Servers […] each equipment vendor can have its own independent OS installed on its hardware. […] Each OS actively manages its hardware at the resource level […] Examples described herein provide HCI-based SDDCs with system-level governing features that can actively monitor and manage different hardware and software components of a virtual server rack system even when such different hardware and software components execute different OSs.”; [0036] – “An application in a virtualized environment may be deployed as a VM or a container.”; [0046]-[0048] – “the HMS 108, 114 is provided with in-band (IB) connectivity to individual server nodes (e.g., server nodes in example physical hardware resources 124, 126) of the physical rack 102, 104. In the illustrated example, the IB connection interfaces to physical hardware resources 124, 126 via an OS running on the server nodes using an OS-specific application programming interfaces (API) […] HMS 108, 114 uses IB management to periodically monitor status and health of the physical resources 124, 126 and to keep server objects and switch objects up to date. Example IB operations performed by the HMS 108, 114 include controlling power state, accessing temperature sensors, controlling BIOS (Basic Input/Output System) inventory of hardware (e.g., central processing units (CPUs), memory, disks, etc.), event monitoring, and logging events. The HMSs 108, 114 of the corresponding physical racks 102, 104 interface with example virtual rack managers (VRMs) 125, 127 of the corresponding physical racks 102, 104 to instantiate and manage the virtual server rack 106 using physical hardware resources 124, 126 (e.g., processors, NICs, servers, switches, storage devices, peripherals, power supplies, etc.) of the physical racks 102, 104. […] the term "host" refers to a functionally indivisible unit of the physical hardware resources 124, 126, such as a physical server that is configured or allocated, as a whole, to a virtual rack and/or workload”; [0055] – “The example virtualization layer 204 includes the VRM 125, 127. The example VRM 125, 127 communicates with the HMS 108, 114 to manage the physical hardware resources 124, 126. The example VRM 125, 127 creates the example virtual server rack 106 out of underlying physical hardware resources 124, 126 that may span one or more physical racks (or smaller units such as a hyper-appliance or half rack) and handles physical management of those resources. […] The example VRM 125, 127 interfaces with an example hypervisor 210 of the virtualization layer 204. The example hypervisor 210 is installed and runs on the example server hosts 128 in the example physical resources 124, 126 to enable the server hosts 128 to be partitioned into multiple logical servers to create VMs.”; [0060] – “distributed resource scheduler (DRS) 216 is provided to monitor resource utilization across resource pools, to manage resource allocations to different VMs, to deploy additional storage capacity to VM clusters 130A, 130B with substantially little or no service disruptions, and to work with the application upgrader 214 to automatically migrate virtual resources during maintenance with substantially little or no service disruptions to application(s).”; [0062] – “the virtualization layer 204 may additionally or alternatively be configured to run containers”).
Radev is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of managing containerized applications in a hyper-converged infrastructure system. Therefore, it would have been obvious to one of ordinary skill in the art to have modified the secure containerization platform executed on an information handling system that is an edge node of a hyper-converged infrastructure system taught by SIENICKI in view of HALL and Amaro to incorporate the teachings of Radev such that the secure containerization platform is able to interface with management tools of the manufacturer of the information handling system. Doing so would allow for simplified monitoring and management of a plurality of different hardware and software components in the hyper-converged infrastructure system even when the components execute different operating systems installed by different manufacturers (Radev: [0031]-[0033]).
Regarding claim 2, the combination of SIENICKI in view of HALL, Amaro, and Radev teaches the information handling system of claim 1. SIENICKI further teaches wherein the containerized applications are configured to execute within secure containers that encapsulate the containerized applications and their dependencies ([0050] – “the containers may be isolated from each other because they can have their own software, libraries and configuration files to run the application itself.”; [0143] – “A container may be designed to be isolated from other containers, such as by running the application entirely with itself. […] the container may be run on a host of environments without the worry of software dependencies. Everything needed by the application may be included in or accessible to the container.”; [0080] – “a secure container 402 may include one or more application images 404 and one or more security images 406.”; [0102] – “the secure container platform 803 may create a container from the image.”; [0162] – “At a high level there are three key steps to creating a secure container image: (1) secure the code and its dependencies”).
Regarding claim 4, the combination of SIENICKI in view of HALL, Amaro, and Radev teaches the information handling system of claim 1. SIENICKI further teaches wherein the secure containerization platform is configured to provide a deployment component operable to create containers for the containerized applications ([0068] – “The secure container platform 222 may deploy and manage containers at the edge”; [0102] – “the secure container platform 803 may create a container from the image.”; [0166] – “the secure container platform may be configured to use labels (instead of sysadmin) to configure devices, deploy containers, manage containers, or configure services.”; [0175] – “The secure container platform may permit containers to be deployed via bootstrap.”; [0177] – “the secure container platform may include software for container creation, container start, and/or container exit.”).
Regarding claim 5, the combination of SIENICKI in view of HALL, Amaro, and Radev teaches the information handling system of claim 4. SIENICKI further teaches wherein the containers are created in accordance with a Docker standard ([0050] – “One or more of the software components in the ECGs 110 may be Linux based and/or split into discrete user spaces, or containers, through the use of a secure container environment (e.g., Docker, etc.). A container may be an individual instance of an application. […] because containers are created from images, the image may contain specific content detailing exactly how the container, application, is supposed to function and behave.”; [0071] – “The secure container platform 222 may be implemented and used in any or all container environments that need enhanced security when deploying services dynamically.”; [0144] – “Container environments (e.g., docker, kubernetes, k8s, k3s, etc.) may perform more functions than just enabling and running containers. A container environment or platform may allow for the creation and usage of images, networks, plug ins, and a host of other items. The container environment may allow wireless operators, enterprises and utilities to easily create applications, and ship them in containers that may be deployed anywhere.”).
Regarding claim 6, the combination of SIENICKI in view of HALL, Amaro, and Radev teaches the information handling system of claim 4. SIENICKI further teaches wherein the containers are created in accordance with a Kubernetes standard ([0050] – “One or more of the software components in the ECGs 110 may be Linux based and/or split into discrete user spaces, or containers, through the use of a secure container environment (e.g., Docker, etc.). A container may be an individual instance of an application. […] because containers are created from images, the image may contain specific content detailing exactly how the container, application, is supposed to function and behave.”; [0071] – “The secure container platform 222 may be implemented and used in any or all container environments that need enhanced security when deploying services dynamically.”; [0144] – “Container environments (e.g., docker, kubernetes, k8s, k3s, etc.) may perform more functions than just enabling and running containers. A container environment or platform may allow for the creation and usage of images, networks, plug ins, and a host of other items. The container environment may allow wireless operators, enterprises and utilities to easily create applications, and ship them in containers that may be deployed anywhere.”).
Claims 7-8 and 10-12 are directed to A method comprising: the functions performed by the information handling system of claims 1-2 and 4-6, respectively. Accordingly, claims 7-8 and 10-12 are rejected as being unpatentable over SIENICKI in view of HALL, Amaro, and Radev for the same reasons presented with respect to claims 1-2 and 4-6.
Claims 13-14 and 16-18 are directed to An article of manufacture comprising a non-transitory, computer-readable medium having computer-executable instructions thereon that are executable by a processor of an information handling system (SIENICKI: [0191] – “the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable storage medium or non-transitory processor-readable storage medium. The operations of a method or algorithm disclosed herein may be embodied in a processor-executable software module or processor-executable instructions, which may reside on a non-transitory computer-readable or processor-readable storage medium”) for: performing the functions performed by the information handling system of claims 1-2 and 4-6, respectively. Accordingly, claims 13-14 and 16-18 are rejected as being unpatentable over SIENICKI in view of HALL, Amaro, and Radev for the same reasons presented with respect to claims 1-2 and 4-6.
Claims 3, 9, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over SIENICKI in view of HALL, Amaro, and Radev as applied to claims 1, 7, and 13 above, and further in view of CHEN et al. (U.S. Pub. No. 2023/0091915), hereinafter CHEN.
Regarding claim 3, the combination SIENICKI in view of HALL, Amaro, and Radev teaches the information handling system of claim 1, but fails to expressly teach wherein the secure containerization system is configured to provide updates to the containerized applications.
However, CHEN teaches wherein the secure containerization platform is configured to provide updates to the containerized applications ([0024] – “Containerization platform 110 accesses information regarding dependences from the image repository 140, as well as information from patch coverage database 160 to apply patches to the various container images, and then rebuild container images.”; [0025] – “containerization platform 110 contains, in various embodiments of the invention, software updater 112 , image build module 114, and container management 118.”; [0026] – “software updater 112 determines whether software associated with a base container image requires an update, such as one or more software patches (including, for example, security patches to improve the security of various software associated with container images). […] software updater 112 applies the necessary software updates to the base container image(s).”; [0031] – “when base container image(s) and or dependent container image(s) are re-built because of patching, container management 118 requests generation and/or modification of new container(s) 124 based upon the re-built container images. The newly generated or modified container 124 , in such circumstances, is deployed”).
CHEN is considered to be analogous art to the claimed invention because it is reasonably pertinent to the problem faced by the inventor of ensuring the security of the containers. It would have been obvious to one of ordinary skill in the art to have modified the secure containerization platform taught by SIENICKI in view of HALL, Amaro, and Radev to incorporate the teachings of CHEN such that the platform provides updates to the containerized applications. Updating the software of a container may improve the security of the software, e.g., when the software update comprises a security patch, and the methods of providing software updates to containerized applications taught by CHEN provide automatic and consistent methods for rolling out correct software updates quickly and efficiently, while avoiding instability and integration issues with dependent container images (CHEN: [0003]-[0004], [0018] and [0026]).
Claim 9 recites the same limitations as claim 3, applied to the method of claim 7. Accordingly, claim 9 is rejected as being unpatentable over SIENICKI in view of HALL, Amaro, and Radev, and further in view of CHEN for the same reasons presented with respect to claim 3.
Claim 15 recites the same limitations as claim 3, applied to the article of manufacture of claim 13. Accordingly, claim 15 is rejected as being unpatentable over SIENICKI in view of HALL, Amaro, and Radev, and further in view of CHEN for the same reasons presented with respect to claim 3.
Response to Arguments
Applicant’s arguments, see page 9 of the Remarks, filed 7/01/2026, with respect to the Objections to the Specification have been fully considered and are persuasive. The Objections to the Specification has been withdrawn.
Applicant’s arguments with respect to the rejection of claim 1 under 35 U.S.C. 103 as being unpatentable over SIENICKI in view of HALL and Amaro have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Specifically, the Examiner has relied upon new reference Radev et al. (U.S. Pub. No. 2023/0130553) to teach the claimed integration component as recited in the amended limitations.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
ALI et al. (U.S. Pub. No. 2021/0109735) teaches a networking-device-based HCI edge controller system, where HCI nodes are provided at an edge location in a network, and the networking device is configured to receive updated software and provides the updated software on the HCI nodes (see Abstract).
ALI et al. (U.S. Pub. No. 2018/0276019) teaches an operational integrity and performance validation (OIPV) module which communicates with a plurality of infrastructure/virtual machine managers, including Kubernetes and/or Docker container management resources as well as commercially distributed physical infrastructure management software products installed on the information handling resources (see [0032], [0034] and [0036]-[0037]).
Sawal et al. (U.S. Pub. No. 2022/0191063) teaches a physical infrastructure/virtual infrastructure integration system used to within a software-defined data center to automate and manage the integration of physical infrastructure management systems with the virtual infrastructure management systems (see Abstract, [0003]).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 nonprovisional extension fee (37 CFR 1.17(a)) 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 JENNIFER MARIE GUTMAN whose telephone number is (703)756-1572. The examiner can normally be reached M-F: 8: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, Kevin Young can be reached at 571-270-3180. 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.
/JENNIFER MARIE GUTMAN/Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights