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 .
This action is responsive to the Applicant’s amendments filed on 11/14/2025. Claims 1-20 remain pending in the application. Claims 1-2, 4-9, 11-16, and 19-20 have been amended. Any examiner’s note, objection, and rejection not repeated is withdrawn due to Applicant’s amendment.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 12/21/2022 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Examiner’s Note
The Examiner cites particular columns, paragraphs, figures, and line numbers in the references as applied to the claims below for the 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 also apply. It is respectfully requested that, in preparing responses, the Applicant fully consider the references in its 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.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 5, 8-9, 12, 15-16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Koster et al. (US 20180332012 A1) hereafter Koster in view of Dunnell et al. (US 20230028635 A1) hereafter Dunnell, further in view of Huo et al. (US 20230071714 A1) hereafter Huo, further in view of Shieh et al. (US 20170180421 A1) hereafter Shieh.
Regarding claim 1, Koster teaches:
A non-transitory computer-readable medium comprising program code (Paragraph 130; “The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device... A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se”) that is executable by a processor for causing the processor to perform operations comprising:
analyzing each individual container to determine whether the individual container has characteristics that match a predefined set of shim criteria (Paragraph 97; “a streams authorization engine may evaluate the requested computing configuration with respect to a set of computing configuration suitability criteria to determine an appropriate computing configuration for the first stream computing application” discloses analyzing a container configuration, thereby analyzing each individual container, against predefined criteria to determine a configuration. “streams authorization engine may transmit a configuration token to a container that manages the first stream computing application, and the container may use one or more shims to configure access permissions” teaches shim configuration occurs based on the evaluation against predefined criteria, in combination teaching determining whether each individual container has characteristics that satisfy predefined criteria prior to shim-based configuration, corresponding to shim criteria.);
based on the analyzing, determining that a subset of containers each individually have the characteristics that match the predefined set of shim criteria (Paragraph 97; “a streams authorization engine may evaluate the requested computing configuration with respect to a set of computing configuration suitability criteria to determine an appropriate computing configuration” discloses analyzing container-related config requests against predefined criteria. “a memory access protection criterion of the set of computing configuration suitability criteria may indicate that a first portion of the memory resource is configured for use by a second stream computing application” indicates that evaluation distinguishes between different applications/containers based on criteria, such as permitted configurations, thereby identifying a subset that satisfies predetermined criteria. “streams authorization engine may transmit a configuration token to a container that manages the first stream computing application, and the container may use one or more shims to configure access permissions for the memory resource to establish the appropriate computing configuration for the first stream computing application” discloses that only those containers determined to satisfy the criteria receive configuration via shim usage, corresponding to determining a subset of containers that match shim criteria.);
and responding to determining that the subset of containers each individually have the characteristics that match the predefined set of shim criteria (Paragraph 97; “a streams authorization engine may evaluate the requested computing configuration with respect to a set of computing configuration suitability criteria to determine an appropriate computing configuration for the first stream computing application”, which discloses analyzing each container-related configuration that satisfy predetermined criteria and performing actions in response, corresponding to in response to determining that the subset of containers each individually have characteristics that match predefined criteria.).
While Koster implies shim criteria can be used for injection, Koster does not explicitly teach shim-injection criteria; a plurality of containers executing in a distributed computing environment; while the respective container is running in the distributed computing environment; wherein each respective shim is configured to intercept calls between a respective set of software programs located inside the respective container into which the respective shim is injected; initiating shim operations that involve injecting a respective shim into each respective container of the subset of containers.
However, Dunnell teaches:
A plurality of containers in a distributed computing environment (Paragraph 56; “Containers 508(1)-(Z) are also used to deploy and execute shims 510(1)-(Z) (each of which is referred to individually as shim 510) associated with service 512.”);
shim-injection criteria and operations (Paragraph 63; “This packaging, deployment, and execution of shim 510 and service 512 within the same container 508 allows different services that provide similar functionality and corresponding shims to be added to or removed from the environment in a seamless, self-contained manner.”, which discloses conditional presence of shims in the environment, selective replacement, and environment-level shim lifecycle control.).
Koster and Dunnell are considered to be analogous to the claimed invention because they are in the same field of container management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Koster to incorporate the teachings of Dunnell to have a plurality of containers in a distributed computing environment. A person of ordinary skill in the art would have recognized the use of the known method of Kubernetes practices to yield the predictable result of deploying, scaling, and managing containerized applications. Further, a person of ordinary skill in the art would have found it obvious to apply the shim determination mechanism of Dunnell to the criteria-based evaluation mechanism of Koster to ensure that the deployed container includes a shim appropriate for the requested functionality. The application of known criteria-based decision mechanisms to govern shim inclusion would have been a predictable use of prior art elements according to their established functions.
Koster in view of Dunnell does not teach that the containers are executing; initiating shim operations that involve injecting a respective shim into each respective container of the subset of containers.
However, Huo teaches:
while the containers are executing (Paragraph 42; “In FIG. 3, worker node virtual machine 310 has kubelet 312 configured to use container runtime interface (CRI) 314 to create one or more shims”, where the usage of a CRI implies that the occurrence is at runtime);
initiating shim injection operations that involve injecting a respective shim into each respective container of the subset of containers (Paragraph 42; “worker node virtual machine 310 has kubelet 312 configured to use container runtime interface (CRI) 314 to create one or more shims 320_1, 320_2, 320_3. Shims 320_1, 320_2, and 320_3 can generally be referred to as shims 320. Each shim 320_1, 320_2, 320_3 has a one-to-one relationship to its own pod virtual machine 301, 302, 303, respectively.”, which discloses the kubelet uses the CRI to create shims, corresponding to deploying or injecting a shim, thus initiating shim injection operations. Each shim is mapped to its own virtual machine, corresponding to each individual container receiving its own corresponding shim. Worker node VMs and their pods represent a distributed environment context.).
Koster, Dunnell, and Huo are considered to be analogous to the claimed invention because they are in the same field of container management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Koster in view of Dunnell to incorporate the teachings of Huo and initiate shim injection operations that involve respective shims into each respective container of a subset of containers. A person of ordinary skill in the art would have recognized that the implementation of the known method of a container-runtime deployment mechanism as taught by Huo onto the system of criteria-based determination and shim utilization of Koster in view of Dunnell would have yielded the predictable result of selectively assigning and injecting appropriate shims into containers within a distributed computing environment. Koster, Dunnell, and Guo disclose the use of shims as modular control components in containerized systems and their combination does not alter their respective principles of operation.
Koster in view of Dunnell, further in view of Huo does not teach wherein each respective shim is configured to intercept calls between a respective set of software programs located inside the respective container into which the respective shim is injected.
However, Shieh teaches:
wherein each respective shim is configured to intercept calls between a respective set of software programs located inside the respective container into which the respective shim is injected (Paragraph 105; “For example, monitoring logic 1040 hooks (e.g., intercepts) library calls, function calls, messages, events, and the like passed between software components (e.g., in one or more containers 1020.sub.1-1020.sub.S).”, where the monitoring logic is interposed between software components and functions as an intermediary layer consistent with a shim. The claim requires the shim be configured to intercept calls between a set of software programs located inside the respective container and the prior art discloses that monitoring logic “hooks”, thereby intercepting, calls passed between software components in one or more containers.).
Koster, Dunnell, Huo, and Sheih are considered to be analogous to the claimed invention because they are in the same field of container management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Koster in view of Dunnell, further in view of Huo to incorporate the teachings of Shieh and configure each shim associated with a respective container to intercept calls between software programs. A person of ordinary skill in the art would have recognized hooking and intercepting calls between software components in a container to be a known method in the art and the application of the interception method onto the shim mechanism of Koster in view of Dunnell, further in view of Huo would have yielded the predictable result of enabling each container-specific shim to intercept internal software calls without needing to change the fundamental operation of the system.
Claim 8 contains similar limitations as those of claim 1. Claim 8 is rejected for similar reasons as those of claim 1.
Claim 15 contains similar limitations as those of claim 1, additionally reciting a processor and a memory including instructions executable by the processor. Koster teaches:
a processor (Paragraph 56; “The components of computer system/server 12 may include, but are not limited to, one or more processors or processing units 16”);
and a memory including instructions executable by the processor (Paragraph 55; “Computer system/server 12 may be described in the general context of computer system executable instructions, such as program modules, being executed by a computer system”, “program modules may be located in both local and remote computer system storage media including memory storage devices”).
Claim 15 is rejected for similar reasons as those of claim 1.
Regarding claim 2, Koster in view of Dunnell, further in view of Huo, further in view of Shieh teach the non-transitory computer-readable medium of claim 1. Koster teaches:
wherein controller software is configured to execute the operations (Paragraph 95; “the streams authorization engine may transmit a configuration token that indicates the appropriate computing configuration to the container for implementation (e.g., at container start-up time). The container may parse the configuration token and instruct one or more shims (e.g., lightweight libraries for operation handling) to implement the appropriate computing configuration”. The streams authorization engine performs centralized control functions by determining the appropriate computing configuration and transmitting instructions that cause shims to implement that configuration in the container. Because it evaluates criteria, determines configurations, and directs shim implementation, the streams authorization engine constitutes controller software to execute the recited operations.), and further comprising program code that is executable by the processor for causing the processor to:
determine the predefined set of shim-injection criteria by extracting the predefined set of shim-injection criteria from a specification used to deploy the controller software in the distributed computing environment (Paragraphs 94-95; “an appropriate computing configuration may be determined for the process in the stream computing environment”, “The appropriate computing configuration may include a collection of settings, regulations, stipulations, or parameters that define an operating configuration for the process that is ascertained to be suitable with respect to the security, performance, or other factors of the stream computing environment” discloses identifying a set of configuration criteria, corresponding to shim injection criteria, from a specification or requested configuration used to deploy a process in the distributed computing environment. Further, “in response to determining the appropriate computing configuration, the streams authorization engine may transmit a configuration token that indicates the appropriate computing configuration to the container for implementation (e.g., at container start-up time). The container may parse the configuration token and instruct one or more shims (e.g., lightweight libraries for operation handling) to implement the appropriate computing configuration with respect to the process of the stream computing application” teaches that criteria are extracted from the configuration token, corresponding to the configuration specification, used to deploy the streams authorization engine, corresponding to applicant’s controller software, is then used to configure shims in the deployed environment, thereby corresponding to extracting the predefined set of shim injection criteria from a specification used to deploy the container software.).
Claim 9 contains similar limitations as those of claim 2. Claim 9 is rejected for similar reasons as those of claim 2.
Claim 16 contains similar limitations as those of claim 2. Claim 16 is rejected for similar reasons as those of claim 2.
Regarding claim 5, Koster in view of Dunnell, further in view of Huo, further in view of Shieh teach the non-transitory computer-readable medium of claim 1. Shieh teaches:
for each respective container of the subset of containers (Paragraph 104; “For example, monitoring logic 1040 hooks (e.g., intercepts) library calls, function calls, messages, events, and the like passed between software components (e.g., in one or more containers 1020.sub.1-1020.sub.S).” describes multiple containers executing applications individually, corresponding to a subset of containers), insert the respective shim into the respective container of the subset of containers (Paragraph 105; “monitoring logic 1040 is logically interposed between host operating system 10 and (decoy) applications and/or services (APPs) 1025.sub.1-1025.sub.S.”. The logical interposition necessarily requires that the shim be inserted into the container, corresponding to the claimed limitation in functional terms. Logical interposition shows the shim is active, and the act of being active inside the container requires it to have been inserted into the container.) transparently to the respective set of software programs running inside the respective container (Paragraphs 105-106; “monitoring logic 1040 is logically interposed between host operating system 10 and (decoy) applications and/or services (APPs) 1025.sub.1-1025.sub.S. In some embodiments, monitoring logic 1040 can include one or more system monitors. For example, monitoring logic 1040 hooks (e.g., intercepts) library calls, function calls, messages, events, and the like passed between software components (e.g., in one or more containers 1020.sub.1-1020.sub.S).” Logically interposed means it is inserted between the OS and applications and acts as an intermediary, thereby corresponding to shim injection. The usage of LD_PRELOAD which dynamically injects shared libraries without modifying application code, ptrace, and strace, are mechanisms by which the injection is performed transparently to the applications, corresponding to software programs, running inside the respective container).
Claim 12 recites similar limitations as those of claim 5. Claim 12 is rejected for similar reasons as those of claim 5.
Claim 19 recites similar limitation as those of claim 5. Claim 19 is rejected for similar reasons as those of claim 5.
Claims 3-4, 6-7, 10-11, 13-14, 17-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Koster in view of Dunnell, further in view of Huo, further in view of Shieh, further in view of Kumar (US 20230065431 A1).
Regarding claim 3, Koster in view of Dunnell, further in view of Huo, further in view of Shieh teach the non-transitory computer-readable medium of claim 2. Huo teaches:
shim injection operations (Paragraph 42; “worker node virtual machine 310 has kubelet 312 configured to use container runtime interface (CRI) 314 to create one or more shims 320_1, 320_2, 320_3. Shims 320_1, 320_2, and 320_3 can generally be referred to as shims 320. Each shim 320_1, 320_2, 320_3 has a one-to-one relationship to its own pod virtual machine 301, 302, 303, respectively.”, which discloses the kubelet uses the CRI to create shims, corresponding to deploying or injecting a shim, thus initiating shim injection operations. Each shim is mapped to its own virtual machine, corresponding to each individual container receiving its own corresponding shim.).
Koster in view of Dunnell, further in view of Huo, further in view of Shieh does not teach update the specification to indicate a status of the operations associated with the subset of containers, wherein the status includes how many containers within the subset of containers have successfully received the update, how many containers have failed to receive the update, and how many containers are presently in a process of receiving the update.
However, Kumar teaches:
further comprising program code that is executable by the processor for causing the processor to update the specification to indicate a status of the shim-injection operations associated with the subset of containers, wherein the status includes how many containers within the subset of containers have successfully received the shim, how many containers have failed to receive the shim, and how many containers are presently in a process of receiving the shim (Paragraphs 84-88; “updated sidecar containers ae functional or have been tested” corresponds to the number of containers have successfully received the shim, as both identify the subset of sidecar containers having successfully received the update or injection. “status of sidecar containers… to which the update has already been applied” corresponds to how many containers failed to receive the shim, because the disclosed health indicator inherently distinguishes between successful and failed updates in determining pod health. “rate at which updates are applied” and “identifies an application pod… implementing a sidecar container” corresponds to how many containers are in the process of receiving the shim, both describe updates being incrementally applied across a subset, meaning some containers in accordance with the update rate may be mid-update at any given time. The “configuration objects 470/480” correspond to the specification in which the rolling update controller is explicitly described as updating, corresponding to modifying, the configuration objects during the injection/update process, in which the computed health indicator is “based on a status of sidecar containers to which the update has already been applied… if the update was applied selectively to a subset… a favorable health indicator may be generated”, showing that the health indicator reflects a status of injection operations already applied, where the “injection operations” correspond to the actions of the “mutating admission controller 420” associated with “a subset of sidecar containers”, corresponding to being associated with the subset of containers. Paragraph 83 further discloses “trigger[ing] new sidecar injection associated with the configuration object”, corresponding to shim injection. Sidecar injection corresponds to shim injection because the injected sidecar container is interposed between software programs to intercept, process, and act upon communications).
Koster, Dunnell, Huo, Sheih, and Kumar are considered to be analogous to the claimed invention because they are in the same field of container management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Koster in view of Dunnell, further in view of Huo, further in view of Shieh to incorporate the teachings of Kumar and update the specification to track the status of shim injection operations. A person of ordinary skill in the art would have recognized the use of status tracking for operations as routine in Kubernetes and other container orchestration platforms, and applying the known method to shim injection is a straightforward adaptation of existing monitoring techniques, yielding the predictable result of visibility into shim injection status across all containers.
Claim 10 recites similar limitations as those of claim 3. Claim 10 is rejected for similar reasons as those of claim 3.
Claim 17 recites similar limitation as those of claim 3. Claim 17 is rejected for similar reasons as those of claim 3.
Regarding claim 4, Koster in view of Dunnell, further in view of Huo, further in view of Shieh teach the non-transitory computer-readable medium of claim 1. Koster teaches:
determine respective characteristics of each respective container in the subset of containers (Paragraph 95; “container may parse the configuration token and instruct one or more shims... to implement the appropriate computing configuration with respect to the process of the stream computing application”, where parsing the configuration token involves determining the characteristics of the container and what settings to apply to the contained process. Thus, the container is individually evaluated to establish its operational characteristics, corresponding to determining respective characteristics of each respective container in the subset of containers.).
Koster in view of Dunnell, further in view of Huo, further in view of Shieh does not teach extracting the respective characteristics of each respective container in the subset of containers from a respective specification used to deploy the respective container in the distributed computing environment.
However, Kumar teaches:
extracting the respective characteristics of each respective container in the subset of containers from a respective specification used to deploy the respective container in the distributed computing environment (Paragraphs 91-94; “[a] target container of a plurality of containers”, “the deployed computing unit is then generated to include the target container... via injection of the target container into the deployed computing unit via the mutating admission controller 420”. The target container and plurality of containers correspond to each respective container as claimed because the specification is used for deployment and allows identifying and applying configuration objects to individual containers within that subset.).
Koster, Dunnell, Huo, Sheih, and Kumar are considered to be analogous to the claimed invention because they are in the same field of container management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Koster in view of Dunnell, further in view of Huo, further in view of Shieh to incorporate the teachings of Kumar and determine respective characteristics of each respective container in a subset of containers from specification data. A person of ordinary skill in the art would have recognized managing container configurations to be a known method in the art and applying the known method of retrieving container configuration data to identify characteristics relevant to shim injection would have yielded the predictable result of accurately identifying container characteristics matching particular shim injection types.
Claim 11 recites similar limitations as those of claim 4. Claim 11 is rejected for similar reasons as those of claim 4.
Claim 18 recites similar limitation as those of claim 4. Claim 18 is rejected for similar reasons as those of claim 4.
Regarding claim 6, Koster in view of Dunnell, further in view of Huo, further in view of Shieh teach the non-transitory computer-readable medium of claim 1. Dunnell teaches:
respective shims into respective containers (Paragraphs 62-63; “packaging, deployment, and execution of shim 510 and service 512 within the same container 508 allows different services that provide similar functionality and corresponding shims to be added to or removed from the environment in a seamless, self-contained manner. For example, a first service and a first shim executing in a first container could be replaced with a second service and a second shim executing in a second container” shows a one to one relationship where each shim is associated with and deployed into its corresponding container, which corresponds to inserting respective shims into respective containers.).
Koster in view of Dunnell, further in view of Huo, further in view of Shieh does not teach wherein initiating the shim-injection operations involves interacting with one or more container deployment engines of the distributed computing environment, the one or more container deployment engines being configured to inject respective shims into the subset of containers.
However, Kumar teaches:
wherein initiating the shim-injection operations involves interacting with one or more container deployment engines of the distributed computing environment, the one or more container deployment engines being configured to inject respective shims into the subset of containers (Paragraph 93; “a request is received to initiate the deployed computing unit… resulting in injection of a sidecar container” corresponds to initiating the shim injection operations because both describe a trigger that causes injection of a secondary container component. “by a mutating admission controller” corresponds to the one or more container deployment engines because the mutating admission controller is the deployment mechanism that modifies pod specifications to inject containers. “via injection of the target container into the deployed computing unit via the mutating admission controller 420” corresponds to injecting respective copies of the shim into the subset of containers, as both describe automatic container-level injection performed by the deployment engine. A new pod is created or regenerated and the mutating admission controller ensures that the sidecar container is injected into that pod, thereby ensuring that each pod has its own copy of the sidecar, corresponding to respective copies of the shim into the subset of containers. Paragraph 83 further discloses “trigger[ing] new sidecar injection associated with the configuration object”, corresponding to shim injection. Sidecar injection corresponds to shim injection because the injected sidecar container is interposed between software programs to intercept, process, and act upon communications).
Koster, Dunnell, Huo, Sheih, and Kumar are considered to be analogous to the claimed invention because they are in the same field of container management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Koster in view of Dunnell, further in view of Huo, further in view of Shieh to incorporate the teachings of Kumar and interact with container deployment engines configured to inject respective shims into each respective container. A person of ordinary skill in the art would have recognized interaction with those container deployment engines to be a known method in containerized environments. The implementation of the known method of container deployment engine interaction would have yielded the predictable result of deployment of each shim into its corresponding container without needing to redesign orchestration logic as common container deployment engines typically contain deterministic processes for injection into target containers.
Claim 13 recites similar limitations as those of claim 6. Claim 13 is rejected for similar reasons as those of claim 6.
Claim 20 recites similar limitation as those of claim 6. Claim 20 is rejected for similar reasons as those of claim 6.
Regarding claim 7, Koster in view of Dunnell, further in view of Huo, further in view of Shieh teach the non-transitory computer-readable medium of claim 1. Dunnell teaches:
corresponding shim-injection operation into respective containers (Paragraphs 62-63; “packaging, deployment, and execution of shim 510 and service 512 within the same container 508 allows different services that provide similar functionality and corresponding shims to be added to or removed from the environment in a seamless, self-contained manner. For example, a first service and a first shim executing in a first container could be replaced with a second service and a second shim executing in a second container” shows a one to one relationship where each shim is associated with and deployed into its corresponding container, which corresponds to inserting respective shims into respective containers.).
Koster in view of Dunnell, further in view of Huo, further in view of Shieh does not teach automatically detect deployment of a new container in the distributed computing environment; based on detecting the deployment of the new container in the distributed computing environment, automatically determining that the new container matches the predefined set of shim-injection criteria and responsively initiating a corresponding shim-injection operation for injecting a copy of the shim into the new container.
However, Kumar teaches:
automatically detect deployment of a new container in the distributed computing environment (Paragraph 80; “the mutating admission controller 420 intercepts requests sent to the API server 410 prior to generation of the application pod 430”, teaches detection of new requests occurring at the Kubernetes control plane, corresponding to detecting deployment of a new container in a distributed computing environment.);
based on detecting the deployment of the new container in the distributed computing environment, automatically determining that the new container matches the predefined set of injection criteria (Paragraph 80; “the mutating admission controller 420 utilizes the MutatingWebhookConfiguration, which controls which application pods are injected with which sidecar containers”, which discloses predefined criteria, the mutating webhook config, to determine which pods are injected with which sidecars. “first MutatingWebhookConfiguration object may include a reference label to a particular namespace” teaches matching criteria used to determine which containers qualify for injection), and responsively initiating a corresponding operation for injecting a copy of the shim into the new container (Paragraph 80; “mutating admission controller 420 ‘injects’ the sidecar container 440A into the application pod 430” teaches initiating injection operations in response to detecting and evaluating the deployment request. “The sidecar container 440A... can be of a particular type that is injected into other application pods” teaches injecting a copy of a sidecar container, functionally equivalent to a shim, into each new application pod, corresponding to container, that has matching criteria. Additionally, Paragraph 81 discloses “the rolling update controller 460 manages configuration objects of sidecar containers of the same type across multiple pods” which reinforces that copies of the same shim/sidecar type are injected into multiple containers.).
Koster, Dunnell, Huo, Sheih, and Kumar are considered to be analogous to the claimed invention because they are in the same field of container management. Therefore, it would have been obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Koster in view of Dunnell, further in view of Huo, further in view of Shieh to incorporate the teachings of Kumar and automatically detect deployment of a new container and determine whether the new container meets predefined criteria, and responsively initiate shim injection operations. A person of ordinary skill in the art would have recognized these steps as known container orchestration and rolling update mechanisms for monitoring container creation and applying predefined configurations in a predictable manner. The known method of applying rolling updates to automatically configure new containers would have yielded the predictable result of ensuring each new container receives the proper shim according to predefined rules.
Claim 14 recites similar limitations as those of claim 7. Claim 14 is rejected for similar reasons as those of claim 7.
Response to Arguments
Applicant's arguments filed 11/14/2025 has been fully considered but they are not persuasive. Applicant’s arguments is summarized below:
Independent claims are submitted as allowable in light of the amendments.
The Examiner respectfully disagrees.
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection relies on new references applied for the teaching or matter specifically challenged in the argument.
Therefore, the rejections under 35 U.S.C. 103 are maintained.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Yang et al. (US 20190335004 A1) discusses utilizing a controller to inject agents onto a subset of host containers and perform updates upon host creation/termination.
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 KENNETH P TRAN whose telephone number is (571)272-6926. The examiner can normally be reached M-TH 4:30 a.m. - 12:30 p.m. PT, F 4:30 a.m. - 8:30 a.m. PT, or at Kenneth.Tran@uspto.gov.
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, April Blair can be reached at (571) 270-1014. 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.
/KENNETH P TRAN/ Examiner, Art Unit 2196
/APRIL Y BLAIR/ Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights