DETAILED ACTION
This communication is in response to applicants’ amendments filed on February 20, 2026. Claims 1-19 are pending.
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 .
Response to Arguments
Applicant's arguments with respect to amended claims have been fully considered but are moot in view of the new ground(s) of 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.
Claims 1, 3-7, 11, and 13-17 are rejected under 35 U.S.C. 103 as being unpatentable over US 10972503 B1 to Mohan et al (hereinafter Mohan) in view of US 20240378107 A1 to Merchant et al (hereinafter Merchant).
As per claim 1, Mohan teaches a computer-implemented method for implementing cyber deception in a container orchestration system (Mohan, Abstract, “Provided are systems, methods, and computer-program products for deception mechanisms in a containerized environment.”) comprising:
installing a deception manager on a cluster of a container orchestration system (Mohan, Col 1, Lines 16-19, “In various implementations, a deception platform can determine, deploy, and manage deceptions, in the form of decoy containers, in a containerized environment such as Kubernetes.”, Mohan, Col 2, Lines 58-60, “Honeypot-type deception mechanisms can be installed in a network for a particular site, such as a business office, to act as decoys in the site’s network.”);
configuring a storage medium on the cluster of the container orchestration system (Mohan, Col 43, Lines 15-19, “A container can be a light-weight, standalone, executable package that contains a piece of software and everything needed to run the software, including program code, system tools, system libraries, and settings, among other things.” See also Merchant, par 0028, “The webhook can set configuration variables, alter files inside the container image, or any other desired change, to allow the container image(s) it manages to be acceptably deployed in the customer’s environment.”; Examiner Note — In Kubernetes, making software artifacts (such as shared libraries) available to containers on a cluster requires configuring a storage medium, such as creating a PersistentVolume, ConfigMap, or emptyDir volume on the cluster. Mohan teaches that containers include system libraries and settings (Col 43, Lines 15-19), and Merchant teaches that the webhook can alter files inside the container image and set configuration variables (par 0028), which includes configuring the storage resources necessary to make the interception library accessible within the container. Configuring storage on a Kubernetes cluster to make files available to containers is a routine, well-understood administrative step that one of ordinary skill in the art would perform as part of deploying software in a containerized environment.);
registering, by the deception manager, the deception manager with a control plane of the container orchestration system (Mohan, Col 50, Line 66 – Col 51, Line 4, “In various examples, a deception deployment for a containerized environment, such as Kubernetes, can use breadcrumbs that align with the microservices in environment and uses the control plane and the data plane provided by the environment to seamlessly blend with the environment.”);
Mohan does not explicitly teach receiving a deployment request from the control plane, modifying a deployment manifest for the given application to include a reference to a particular shared library in the storage medium, or sending the modified deployment manifest to the control plane of the container orchestration system in response to receiving the request;
In an analogous art in container orchestration and library interposition, Merchant teaches:
registering, by the deception manager, the deception manager with a control plane of the container orchestration system (Merchant, par 0028, “The webhook can insert itself into the Kubernetes work flow and the webhook can act as an admission controller for allowing a container or mutated container to be used and can mutate a container as needed.”, Merchant, par 0140, “The user may load a webhook via a helm chart that causes an intelligent webhook to be installed into the user’s environment.”, Examiner Note — In the Kubernetes architecture, a mutating admission webhook is registered with the API server (control plane) by creating a MutatingWebhookConfiguration resource. Merchant’s description of the webhook “inserting itself into the Kubernetes work flow” (par 0028) and being installed via helm chart (par 0140) inherently involves registration with the control plane. The combination of Mohan’s deception platform, which uses the Kubernetes control plane and data plane (Col 50, Line 66 - Col 51, Line 4), with Merchant’s webhook registration mechanism yields a deception manager registered with the control plane of the container orchestration system.);
receiving, by the deception manager, a request to deploy a given application on the cluster from the control plane of the container orchestration system (Merchant, par 0147, “the orchestration service (e.g., K8s) may be instructed to instantiate one or more containers associated with an application. This can happen when the user deploys an application using the orchestration service’s environment (e.g., a K8s environment using Helm). As part of the instantiation of each container, the orchestration service can provide the (now dormant) webhook with container information such as a container image name, an orchestration module’s namespace name (e.g., k8s namespace name), and an orchestration service’s cluster name (e.g., k8s cluster name).”, Merchant, par 0158, “The webhook may remain dormant until the customer subsequently deploys a new container into his or her orchestration (e.g., K8s) environment.”; Examiner Note — In the Kubernetes mutating admission webhook architecture, the API server (control plane) sends an AdmissionReview request to the registered webhook when a matching resource (e.g., Pod, Deployment) is submitted for creation. Merchant’s par 0147 describes this mechanism — when a user deploys an application, the orchestration service (control plane) provides the webhook with container and deployment information. The webhook receiving this container information from the orchestration service corresponds to “receiving, by the deception manager, a request to deploy a given application on the cluster from the control plane of the container orchestration system.”);
modifying, by the deception manager, a deployment manifest for the given application to include a reference to a particular shared library in the storage medium, wherein the deployment manifest specifies a configuration for executing the given application (Merchant, par 0028, “The webhook is a piece of code that is afforded the opportunity to alter (mutate) a container image that is about to be started by K8s. The webhook can set configuration variables, alter files inside the container image, or any other desired change, to allow the container image(s) it manages to be acceptably deployed in the customer’s environment.”, Merchant, par 0088, “One way to ensure that interception library is accessed first is to set a pre-loader (e.g., preloader 441) to interception library 430. The pre-loader is commonly referred to as LD_PRELOAD. For example, LD_PRELOAD is set to Interception Library. This results in pre-loader instructing loader 440 to access interception library 430 first before accessing any other libraries such as native library 410.”, Merchant, par 0080, “The interception library can include the same functions of the native library or subset thereof and any proprietary APIs, but is associated with analysis platform and enables extraction of telemetry events related to operation of the application.”, Merchant, par 0026, “Kubernetes provide orchestration capabilities for containers (which K8s refer to as ‘pods’), providing resource management, resource limiting, scheduling, scaling (replicating) pods, and the network fabric between pods.”; Examiner Note — In Kubernetes, a mutating admission webhook operates on the API object (pod specification/deployment manifest) submitted to the API server. Merchant’s webhook “set[ting] configuration variables” (par 0028) in the context of a Kubernetes deployment corresponds to modifying the pod specification, i.e., the deployment manifest that specifies a configuration for executing the given application. Setting the LD_PRELOAD environment variable (par 0088) to reference the interception library constitutes “modifying … a deployment manifest for the given application to include a reference to a particular shared library in the storage medium.” Merchant’s interception library is a particular shared library, as it includes the same functions as the native library (par 0080). The Kubernetes pod specification defines the execution configuration for containers, including resource management, scheduling, and scaling (par 0026), thereby satisfying “wherein the deployment manifest specifies a configuration for executing the given application.”);
sending, by the deception manager, the modified deployment manifest for the given application to the control plane of the container orchestration system in response to receiving the request (Merchant, par 0153-0154, “the mutated container is checked to confirm whether it passes an internal review before being admitted at step 974. … the mutated container is admitted and starts execution in connection with the application. The mutated container may be admitted by an orchestration service (e.g., K8s 813 or admission controller 814).”, Merchant, par 0158, “The webhook may remain dormant until the customer subsequently deploys a new container into his or her orchestration (e.g., K8s) environment.”; Examiner Note — In the Kubernetes mutating admission webhook architecture, after the webhook modifies the pod specification, it returns an AdmissionReview response (containing a JSON patch with the modifications) to the API server (control plane). The API server then applies the modifications and proceeds with admission. Merchant’s description of the webhook mutating a container and then having it admitted by the orchestration service (par 0153-0154) corresponds to “sending, by the deception manager, the modified deployment manifest for the given application to the control plane of the container orchestration system.” The entire mutation-and-admission sequence occurs in response to the deployment request, as the webhook is dormant until deployment occurs (par 0158), thereby satisfying “in response to receiving the request.”);
where the modified deployment manifest references a particular shared library in the storage medium (Merchant, par 0088, “LD_PRELOAD is set to Interception Library. This results in pre-loader instructing loader 440 to access interception library 430 first before accessing any other libraries.”; Examiner Note — The LD_PRELOAD environment variable in the modified deployment configuration contains a path reference to the interception library, which is a particular shared library stored in accessible storage. Setting LD_PRELOAD to reference the interception library in the modified pod specification satisfies “where the modified deployment manifest references a particular shared library in the storage medium.”);
and wherein the particular shared library is loaded first by an operating system running the container orchestration system (Merchant, par 0088, “This results in pre-loader instructing loader 440 to access interception library 430 first before accessing any other libraries such as native library 410.”, Merchant, par 0079, “The application is programmed via an instrumentation or system loading process … to interact with the interception library first before calling the original command with the native application.”, Merchant, par 0104, “the TIAP runtime can act as a replacement for the system run-time link-editor. The run-time link-editor (‘loader’) resolves symbols from required libraries and creates the appropriate linkages.”; Examiner Note — LD_PRELOAD is an environment variable recognized by the operating system’s dynamic linker/loader. When LD_PRELOAD is set, the operating system’s dynamic linker loads the specified shared library before any other libraries, including the application’s native libraries. Merchant explicitly teaches that setting LD_PRELOAD causes the interception library to be loaded “first before accessing any other libraries” (par 0088). The dynamic linker is a component of the operating system, thereby satisfying “wherein the particular shared library is loaded first by an operating system running the container orchestration system.”);
It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify the invention of Mohan to incorporate the mutating admission webhook mechanism of Merchant, including modifying container deployment configuration to inject a shared library loaded first via LD_PRELOAD, as taught by Merchant, in order to seamlessly integrate deception capabilities into containerized applications during deployment without requiring modification to the application code itself (Merchant, par 0029). One of ordinary skill in the art would have been motivated to combine these references because Mohan expressly teaches that deception deployment should “seamlessly blend with the environment” (Mohan, Col 50, Line 66 - Col 51, Line 4), and Merchant’s mutating admission webhook provides the standard Kubernetes-native mechanism for transparently modifying container deployments (Merchant, par 0028). Furthermore, Merchant explicitly contemplates security products as a use case for the webhook and library interposition framework (Merchant, par 0029).
As per claim 3, Mohan-Merchant teaches the method of claim 1 wherein the container orchestration system is further defined as Kubernetes container orchestration system (Mohan, Col 1, Lines 16-19, “In various implementations, a deception platform can determine, deploy, and manage deceptions, in the form of decoy containers, in a containerized environment such as Kubernetes.”; See also Merchant, par 0026, “Kubernetes provide orchestration capabilities for containers (which K8s refer to as ‘pods’), providing resource management, resource limiting, scheduling, scaling (replicating) pods, and the network fabric between pods.”. The reasons of obviousness have been noted in the rejection of claim 1 above and applicable herein).
As per claim 4, Mohan-Merchant teaches the method of claim 1 further comprising mounting the storage medium and setting value of LD_PRELOAD environmental variable to reference the particular shared library in the storage medium in response to receiving the request to deploy the given application (Merchant, par 0088, “One way to ensure that interception library is accessed first is to set a pre-loader (e.g., preloader 441) to interception library 430. The pre-loader is commonly referred to as LD_PRELOAD. For example, LD_PRELOAD is set to Interception Library. This results in pre-loader instructing loader 440 to access interception library 430 first before accessing any other libraries such as native library 410.”, Merchant, par 0028, “The webhook can set configuration variables, alter files inside the container image, or any other desired change, to allow the container image(s) it manages to be acceptably deployed in the customer’s environment.”, Merchant, par 0147-0148, the webhook receives container information from the orchestration service when a user deploys an application and determines whether to mutate the container, Merchant, par 0158, “The webhook may remain dormant until the customer subsequently deploys a new container into his or her orchestration (e.g., K8s) environment.”; Examiner Note — Merchant explicitly teaches setting the LD_PRELOAD environment variable to reference the interception library (par 0088), which directly corresponds to “setting value of LD_PRELOAD environmental variable to reference the particular shared library in the storage medium.” This setting is performed by the webhook as part of the container mutation during deployment (par 0028, par 0147-0148), satisfying “in response to receiving the request to deploy the given application.” Regarding “mounting the storage medium,” in the Kubernetes environment, for the LD_PRELOAD environment variable to reference a shared library at a specific path within a container, the storage medium containing that library must be mounted as a volume (e.g., a ConfigMap, PersistentVolume, or emptyDir volume) in the pod specification. Merchant’s webhook, which can “set configuration variables” and make “any other desired change” to the container configuration (par 0028), inherently performs the necessary volume mount configuration to make the shared library accessible at the path referenced by LD_PRELOAD. Mounting a volume in a Kubernetes pod specification to make files accessible to a container is a routine, well-understood configuration step that one of ordinary skill in the art would perform as part of setting LD_PRELOAD to reference a library. The reasons of obviousness have been noted in the rejection of claim 1 above and applicable herein).
As per claim 5, Mohan-Merchant teaches the method of claim 1 further comprising receiving, by the control plane, a request to start the given application (Merchant, par 0147, “the orchestration service (e.g., K8s) may be instructed to instantiate one or more containers associated with an application. This can happen when the user deploys an application using the orchestration service’s environment (e.g., a K8s environment using Helm).”); and starting, by the control plane, a pod for the given application in accordance with the modified deployment manifest (Merchant, par 0154, “the mutated container is admitted and starts execution in connection with the application. The mutated container may be admitted by an orchestration service (e.g., K8s 813 or admission controller 814).”, Merchant, par 0026, “Kubernetes provide orchestration capabilities for containers (which K8s refer to as ‘pods’), providing resource management, resource limiting, scheduling, scaling (replicating) pods, and the network fabric between pods.”; Examiner Note — Merchant teaches that after the webhook mutates the container (modifying the deployment manifest), the orchestration service (control plane) admits the mutated container and it starts execution (par 0154). In Kubernetes, containers run within pods (par 0026). The orchestration service admitting and starting the mutated container corresponds to “starting, by the control plane, a pod for the given application in accordance with the modified deployment manifest,” because the mutated container starts execution with the modifications (e.g., LD_PRELOAD set to reference the interception library) applied by the webhook. The reasons of obviousness have been noted in the rejection of claim 1 above and applicable herein.).
As per claim 6, Mohan-Merchant teaches the method of claim 1 further comprising receiving a network request for the given application (Merchant, par 0117, “Network events can be sent when various network operations (e.g., listen/accept/bind) occur. These are sent for individual operations, when the runtime is in maximum telemetry collection mode.”, Merchant, par 0069, “Telemetry module 112 can include computer-readable code that is operative to intercept application programming interface (API) calls originating from the application at the library level”) and executing a hook residing in the particular shared library in response to the network request (Merchant, par 0069, “The TIAP runtime can interpose on any function in any library used by any component by inserting interception hooks or trampoline functions into the application’s dependency chain (e.g., IAT/PLT/GOT). These trampoline functions redirect control flow from the native library API functions to the TIAP runtime, which then collects information about the API request (parameters, call stack information, performance metrics, etc.) as telemetry events, and then passes the original call to the native library.”, Merchant, par 0080, “When a function is called in the interception library, the telemetry event collection is performed and actual code in the native library is accessed to implement the function call.”; Examiner Note — Merchant teaches that the interception library (particular shared library) contains hooks and trampoline functions that reside in the shared library and execute when the application invokes functions, including network-related functions such as listen, accept, and bind (par 0117). When a network request is received for the given application, the network accept/bind function is intercepted by the hook residing in the interception library, and the hook executes (par 0069, par 0080) before passing the call to the native library. This corresponds to “receiving a network request for the given application and executing a hook residing in the particular shared library in response to the network request.” In the combination with Mohan, the hook implements a cyber deception function rather than telemetry collection, as discussed in the motivation to combine in the rejection of claim 1 above. The reasons of obviousness have been noted in the rejection of claim 1 above and applicable herein.).
As per claim 7, Mohan-Merchant teaches the method of claim 6 further comprising starting a process for the given application (Merchant, par 0154, “the mutated container is admitted and starts execution in connection with the application.”); loading, by the process, the particular shared library (Merchant, par 0088, “LD_PRELOAD is set to Interception Library. This results in pre-loader instructing loader 440 to access interception library 430 first before accessing any other libraries such as native library 410.”); identifying functions used by the process to receive network requests and to send network responses (Merchant, par 0069, “The TIAP runtime can interpose on any function in any library used by any component by inserting interception hooks or trampoline functions into the application’s dependency chain (e.g., IAT/PLT/GOT).”, Merchant, par 0117, “Network events can be sent when various network operations (e.g., listen/accept/bind) occur. These are sent for individual operations, when the runtime is in maximum telemetry collection mode.”); and inserting hooks into the identified functions (Merchant, par 0069, “inserting interception hooks or trampoline functions into the application’s dependency chain (e.g., IAT/PLT/GOT). These trampoline functions redirect control flow from the native library API functions to the TIAP runtime, which then collects information about the API request (parameters, call stack information, performance metrics, etc.) as telemetry events, and then passes the original call to the native library.”). Examiner Note — Merchant teaches that when the mutated container starts execution (par 0154), the process loads the interception library first via LD_PRELOAD (par 0088). The TIAP runtime then interposes on functions in the application’s dependency chain by inserting interception hooks or trampoline functions (par 0069), including functions used for network operations such as listen, accept, and bind (par 0117). These hooks redirect control flow from native library functions to the TIAP runtime. This corresponds to “starting a process for the given application; loading, by the process, the particular shared library; identifying functions used by the process to receive network requests and to send network responses; and inserting hooks into the identified functions.” The reasons of obviousness have been noted in the rejection of claim 1 above and applicable herein.
As per claim 11, Mohan-Merchant teaches a non-transitory computer-readable medium having computer-executable instructions for implementing cyber deception in a container orchestration system (Mohan, Abstract, “Provided are systems, methods, and computer-program products for deception mechanisms in a containerized environment.”) that, upon execution of the instructions by a processor of a computer, cause the computer to:
register a deception manager with a control plane of a container orchestration system (Mohan, Col 50, Line 66 - Col 51, Line 4, “In various examples, a deception deployment for a containerized environment, such as Kubernetes, can use breadcrumbs that align with the microservices in environment and uses the control plane and the data plane provided by the environment to seamlessly blend with the environment.” See also Merchant, par 0028, “The webhook can insert itself into the Kubernetes work flow and the webhook can act as an admission controller for allowing a container or mutated container to be used and can mutate a container as needed.”, Merchant, par 0140, “The user may load a webhook via a helm chart that causes an intelligent webhook to be installed into the user’s environment.”);
receive a request to deploy a given application on the cluster from the control plane of the container orchestration system (Merchant, par 0147, “the orchestration service (e.g., K8s) may be instructed to instantiate one or more containers associated with an application. This can happen when the user deploys an application using the orchestration service’s environment (e.g., a K8s environment using Helm). As part of the instantiation of each container, the orchestration service can provide the (now dormant) webhook with container information such as a container image name, an orchestration module’s namespace name (e.g., k8s namespace name), and an orchestration service’s cluster name (e.g., k8s cluster name).”, Merchant, par 0158, “The webhook may remain dormant until the customer subsequently deploys a new container into his or her orchestration (e.g., K8s) environment.”);
modify a deployment manifest for the given application to include a reference to a particular shared library in the storage medium, wherein the deployment manifest specifies a configuration for executing the given application (Merchant, par 0028, “The webhook is a piece of code that is afforded the opportunity to alter (mutate) a container image that is about to be started by K8s. The webhook can set configuration variables, alter files inside the container image, or any other desired change, to allow the container image(s) it manages to be acceptably deployed in the customer’s environment.”, Merchant, par 0088, "One way to ensure that interception library is accessed first is to set a pre-loader (e.g., preloader 441) to interception library 430. The pre-loader is commonly referred to as LD_PRELOAD. For example, LD_PRELOAD is set to Interception Library. This results in pre-loader instructing loader 440 to access interception library 430 first before accessing any other libraries such as native library 410.", Merchant, par 0026, “Kubernetes provide orchestration capabilities for containers (which K8s refer to as ‘pods’), providing resource management, resource limiting, scheduling, scaling (replicating) pods, and the network fabric between pods.”);
send the modified deployment manifest for the given application from the deception manager to the control plane of the container orchestration system, where the modified deployment manifest references a particular shared library in the storage medium and wherein the particular shared library is loaded first by an operating system running the container orchestration system (Merchant, par 0153-0154, “the mutated container is checked to confirm whether it passes an internal review before being admitted at step 974. … the mutated container is admitted and starts execution in connection with the application. The mutated container may be admitted by an orchestration service (e.g., K8s 813 or admission controller 814).”, Merchant, par 0088, “LD_PRELOAD is set to Interception Library. This results in pre-loader instructing loader 440 to access interception library 430 first before accessing any other libraries such as native library 410.”, Merchant, par 0079, “The application is programmed via an instrumentation or system loading process … to interact with the interception library first before calling the original command with the native application.”, Merchant, par 0104, “the TIAP runtime can act as a replacement for the system run-time link-editor. The run-time link-editor (‘loader’) resolves symbols from required libraries and creates the appropriate linkages.”); and
execute a hook residing in the particular shared library, where the hook implements a cyber deception method (Merchant, par 0069, “The TIAP runtime can interpose on any function in any library used by any component by inserting interception hooks or trampoline functions into the application’s dependency chain (e.g., IAT/PLT/GOT). These trampoline functions redirect control flow from the native library API functions to the TIAP runtime, which then collects information about the API request (parameters, call stack information, performance metrics, etc.) as telemetry events, and then passes the original call to the native library.”, Merchant, par 0080, “When a function is called in the interception library, the telemetry event collection is performed and actual code in the native library is accessed to implement the function call.”, Merchant, par 0061, “a trampoline or trampoline function is a runtime internal technique of hooking/intercepting API/library calls used by a component.” See also Mohan, Abstract, “Provided are systems, methods, and computer-program products for deception mechanisms in a containerized environment.”, Mohan, Col 49, Lines 9-18, “breadcrumbs… can be configured to appear attractive to an attacker while at the same time blending in with legitimate data stored in the Kubernetes components.”). Examiner Note — Merchant teaches hooks (trampoline functions) residing in the interception library (particular shared library) that execute when the application invokes functions (par 0069, par 0080). Merchant’s hook framework is architecturally purpose-agnostic — the hooks intercept function calls and perform defined actions before passing the call to the native library (par 0069). Merchant explicitly contemplates security products as a use case for this framework (par 0029, “These software products might include security products, performance monitoring products, network analytics products, and so on”). The hook implements a method (telemetry collection in Merchant). In combination with Mohan, the hook implements a cyber deception method instead of or in addition to telemetry collection, as Mohan teaches deception mechanisms in containerized environments that are configured to “appear attractive to an attacker while at the same time blending in with legitimate data” (Col 49, Lines 9-18). One of ordinary skill in the art would recognize that the action performed by the hook (monitoring vs. deception) is an implementation choice that does not alter the underlying hook mechanism taught by Merchant. It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify the invention of Mohan to incorporate the mutating admission webhook mechanism of Merchant, including modifying container deployment configuration to inject a shared library loaded first via LD_PRELOAD and executing hooks residing in the shared library, as taught by Merchant, in order to seamlessly integrate deception capabilities into containerized applications during deployment without requiring modification to the application code itself (Merchant, par 0029). One of ordinary skill in the art would have been motivated to combine these references because Mohan expressly teaches that deception deployment should “seamlessly blend with the environment” (Mohan, Col 50, Line 66 - Col 51, Line 4), and Merchant’s mutating admission webhook provides the standard Kubernetes-native mechanism for transparently modifying container deployments (Merchant, par 0028). Furthermore, Merchant explicitly contemplates security products as a use case for the webhook and library interposition framework (Merchant, par 0029).
As per claim 13, Mohan-Merchant teaches the non-transitory computer-readable medium of claim 11 wherein the container orchestration system is further defined as Kubernetes container orchestration system (Mohan, Col 1, Lines 16-19, “In various implementations, a deception platform can determine, deploy, and manage deceptions, in the form of decoy containers, in a containerized environment such as Kubernetes.” See also Merchant, par 0026, “Kubernetes provide orchestration capabilities for containers (which K8s refer to as ‘pods’), providing resource management, resource limiting, scheduling, scaling (replicating) pods, and the network fabric between pods.”). The reasons of obviousness have been noted in the rejection of claim 11 above and applicable herein.
As per claim 14, Mohan-Merchant teaches the non-transitory computer-readable medium of claim 11 wherein the computer-executable instructions further cause the computer to mount the storage medium and set value of LD_PRELOAD environmental variable to reference the particular shared library in the storage medium in response to receiving the request to deploy the given application (Merchant, par 0088, “One way to ensure that interception library is accessed first is to set a pre-loader (e.g., preloader 441) to interception library 430. The pre-loader is commonly referred to as LD_PRELOAD. For example, LD_PRELOAD is set to Interception Library. This results in pre-loader instructing loader 440 to access interception library 430 first before accessing any other libraries such as native library 410.”, Merchant, par 0028, “The webhook can set configuration variables, alter files inside the container image, or any other desired change, to allow the container image(s) it manages to be acceptably deployed in the customer’s environment.”, Merchant, par 0147-0148, the webhook receives container information from the orchestration service when a user deploys an application and determines whether to mutate the container, Merchant, par 0158, “The webhook may remain dormant until the customer subsequently deploys a new container into his or her orchestration (e.g., K8s) environment.”). Examiner Note — Merchant explicitly teaches setting the LD_PRELOAD environment variable to reference the interception library (par 0088), which directly corresponds to “set value of LD_PRELOAD environmental variable to reference the particular shared library in the storage medium.” This setting is performed by the webhook as part of the container mutation during deployment (par 0028, par 0147-0148), satisfying “in response to receiving the request to deploy the given application.” Regarding “mount the storage medium,” in the Kubernetes environment, for the LD_PRELOAD environment variable to reference a shared library at a specific path within a container, the storage medium containing that library must be mounted as a volume (e.g., a ConfigMap, PersistentVolume, or emptyDir volume) in the pod specification. Merchant’s webhook, which can “set configuration variables” and make “any other desired change” to the container configuration (par 0028), inherently performs the necessary volume mount configuration to make the shared library accessible at the path referenced by LD_PRELOAD. Mounting a volume in a Kubernetes pod specification to make files accessible to a container is a routine, well-understood configuration step that one of ordinary skill in the art would perform as part of setting LD_PRELOAD to reference a library. The reasons of obviousness have been noted in the rejection of claim 11 above and applicable herein.
As per claim 15, Mohan-Merchant teaches the non-transitory computer-readable medium of claim 11 wherein the computer-executable instructions further cause the computer to receive a request to start the given application (Merchant, par 0147, “the orchestration service (e.g., K8s) may be instructed to instantiate one or more containers associated with an application. This can happen when the user deploys an application using the orchestration service’s environment (e.g., a K8s environment using Helm).”); and start a pod for the given application in accordance with the modified deployment manifest (Merchant, par 0154, “the mutated container is admitted and starts execution in connection with the application. The mutated container may be admitted by an orchestration service (e.g., K8s 813 or admission controller 814).”, Merchant, par 0026, “Kubernetes provide orchestration capabilities for containers (which K8s refer to as ‘pods’), providing resource management, resource limiting, scheduling, scaling (replicating) pods, and the network fabric between pods.”). Examiner Note — Merchant teaches that after the webhook mutates the container (modifying the deployment manifest), the orchestration service (control plane) admits the mutated container and it starts execution (par 0154). In Kubernetes, containers run within pods (par 0026). The orchestration service admitting and starting the mutated container corresponds to “receive a request to start the given application; and start a pod for the given application in accordance with the modified deployment manifest,” because the mutated container starts execution with the modifications (e.g., LD_PRELOAD set to reference the interception library) applied by the webhook. The reasons of obviousness have been noted in the rejection of claim 11 above and applicable herein.
As per claim 16, claim 16 recites substantially the same limitation as claim 6, in which a hook executes in response to a network request, in the form of a non-transitory computer-readable medium, therefore, it is rejected under the same rationale provided for claim 6 above. Specifically, Mohan-Merchant teaches the non-transitory computer-readable medium of claim 11 wherein the computer-executable instructions further cause the computer to receive a network request for the given application and execute a hook residing in the particular shared library in response to the network request (Merchant, par 0117, “Network events can be sent when various network operations (e.g., listen/accept/bind) occur. These are sent for individual operations, when the runtime is in maximum telemetry collection mode.”, Merchant, par 0069, “The TIAP runtime can interpose on any function in any library used by any component by inserting interception hooks or trampoline functions into the application’s dependency chain (e.g., IAT/PLT/GOT). These trampoline functions redirect control flow from the native library API functions to the TIAP runtime.”, Merchant, par 0080, “When a function is called in the interception library, the telemetry event collection is performed and actual code in the native library is accessed to implement the function call.”). The reasons of obviousness have been noted in the rejection of claim 11 above and applicable herein.
As per claim 17, Mohan-Merchant teaches the non-transitory computer-readable medium of claim 16 wherein the computer-executable instructions further cause the computer to load the particular shared library (Merchant, par 0088, “LD_PRELOAD is set to Interception Library. This results in pre-loader instructing loader 440 to access interception library 430 first before accessing any other libraries such as native library 410.”); identify functions used by a process to receive network request (Merchant, par 0069, “The TIAP runtime can interpose on any function in any library used by any component by inserting interception hooks or trampoline functions into the application’s dependency chain (e.g., IAT/PLT/GOT).”, Merchant, par 0117, “Network events can be sent when various network operations (e.g., listen/accept/bind) occur. These are sent for individual operations, when the runtime is in maximum telemetry collection mode.”); and insert hooks into the identified functions (Merchant, par 0069, “inserting interception hooks or trampoline functions into the application’s dependency chain (e.g., IAT/PLT/GOT). These trampoline functions redirect control flow from the native library API functions to the TIAP runtime, which then collects information about the API request (parameters, call stack information, performance metrics, etc.) as telemetry events, and then passes the original call to the native library.”). The reasons of obviousness have been noted in the rejection of claims 7 and 11 above and applicable herein.
Claims 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Mohan in view of Merchant as applied to claims 1 and 11 above, and further in view of US 20240111550 A1 Wang et al (hereinafter Wang).
As per claim 2, Mohan-Merchant teaches the method of claim 1; Mohan-Merchant does not explicitly teach wherein configuring the storage medium further comprises copying the particular shared library into the storage medium. In an analogous art in the field of shared library management, Wang teaches configuring the storage medium further comprises copying the particular shared library into the storage medium (Wang, par 0009, “Based upon the loading count and the loading policy, a selection is made between loading the target shared library as a shared library container, and loading the target shared library into the local address space.”). It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify the invention of Mohan-Merchant by incorporating the copying of the particular shared library into the storage medium as taught by Wang in order to ensure the shared library is accessible in local storage for loading by the operating system and to prevent errors from improperly accessing a protected memory location (Wang, par 0004).
As per claim 12, Mohan-Merchant teaches the non-transitory computer-readable medium of claim 11. Mohan-Merchant does not explicitly teach wherein the computer-executable instructions further cause the computer to copy the particular shared library into the storage medium. In an analogous art in the field of shared library management, Wang teaches the computer-executable instructions further cause the computer to copy the particular shared library into the storage medium (Wang, par 0009, “Based upon the loading count and the loading policy, a selection is made between loading the target shared library as a shared library container, and loading the target shared library into the local address space.”). The reasons of obviousness have been noted in the rejection of claim 2 above and applicable herein.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Mohan in view of Merchant as applied to claims 6 and 16 above, and further in view of US 20240348637 A1 to Bennett et al (hereinafter Bennett).
As per claim 8, Mohan-Merchant teaches the method of claim 6. Mohan-Merchant does not explicitly teach wherein the hook is configured to change a response status code or modify a header field in a response to the network request. In an analogous art in deception responses, Bennett teaches the hook is configured to change a response status code or modify a header field in a response to the network request (Bennett, par 0040, “When requests are received at the network interface 206, then can routed to corresponding web services 208a-n, which may in turn route the risk and deceptive response assessment to the web security system 210 in parallel to their preliminary processing of the request.”, Bennett, par 0042, “The web service 302 includes native web service code 304, which can include a response engine 306 that is configured to receive client requests and to generate appropriate responses, a deception generator 308 that is configured to change the content generated by the response engine”). Examiner Note — An HTTP response generated by a web service response engine includes a status code, header fields, and body content. Bennett’s deception generator, which is “configured to change the content generated by the response engine” (par 0042), encompasses changing any component of the response, including a response status code or a header field, to inject deceptive information. It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify the invention of Mohan-Merchant to incorporate the hook changing a response status code or modifying a header field in a response to the network request as taught by Bennett in order to improve overall security by injecting deceptive content into responses to mislead potential attackers (Bennett, par 0042).
As per claim 18, Mohan-Merchant teaches the non-transitory computer-readable medium of claim 16. Mohan-Merchant does not explicitly teach wherein the hook is configured to change a response status code or modify a header field in a response to the network request. In an analogous art in deception responses, Bennett teaches the hook is configured to change a response status code or modify a header field in a response to the network request (Bennett, par 0040, “When requests are received at the network interface 206, then can routed to corresponding web services 208a-n, which may in turn route the risk and deceptive response assessment to the web security system 210 in parallel to their preliminary processing of the request.”, Bennett, par 0042, “The web service 302 includes native web service code 304, which can include a response engine 306 that is configured to receive client requests and to generate appropriate responses, a deception generator 308 that is configured to change the content generated by the response engine”). Examiner Note — An HTTP response generated by a web service response engine includes a status code, header fields, and body content. Bennett’s deception generator, which is “configured to change the content generated by the response engine” (par 0042), encompasses changing any component of the response, including a response status code or a header field, to inject deceptive information. The reasons of obviousness have been noted in the rejection of claim 8 above and applicable herein.
Claims 9-10, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Mohan in view of Merchant and Bennett as applied to claims 8 and 18 above, and further in view of US 20240103494 A1 to Sandler et al (hereinafter Sandler).
As per claim 9, Mohan-Merchant-Bennett teaches the method of claim 8. Mohan-Merchant-Bennett does not explicitly teach reading, by the hook, a configuration file from the storage medium; comparing the network request to the configuration file; and changing the response to the network request according to the configuration file. In an analogous art in managing containers, Sandler teaches reading, by the hook, a configuration file from the storage medium (Sandler, par 0024, “After the containers are deployed to their respective devices, the container deployment system may update a registry that records the identity or type of container that has been deployed to each device.”, Sandler, par 0085, “In some embodiments, the received properties may be compared to the deployment configuration file to determine whether the deployed containers are operating as set forth in the deployment configuration file.”); comparing the network request to the configuration file (Sandler, par 0085, “the received properties may be compared to the deployment configuration file to determine whether the deployed containers are operating as set forth in the deployment configuration file. At block 170, the received properties may be compared to data stored in the container registry and the container registry updated to reflect any discrepancies.”); and changing the response to the network request according to the configuration file (Sandler, par 0085-0086, comparing properties to configuration file and updating to reflect any discrepancies). Examiner Note — Sandler teaches a technique of reading a configuration file, comparing received information against the configuration file, and modifying behavior based on the comparison result (par 0085-0086). In Sandler, this technique is applied to container deployment properties, but the underlying principle — reading a configuration file and adjusting responses based on comparing incoming data to configuration rules — is a well-known software design pattern applicable across contexts. In the combination with Mohan-Merchant-Bennett, one of ordinary skill in the art would apply this configuration-driven comparison technique to the deception hook of the modified system, such that the hook reads a configuration file from the storage medium, compares the incoming network request to the configuration file (e.g., matching request attributes such as URL paths, headers, or source addresses against deception rules), and changes the response to the network request according to the configuration file. This application of a known technique (configuration-driven response modification) to a known system (deception hook intercepting network requests) yields the predictable result of configurable, rule-based deceptive responses. See KSR Int’l Co. v. Teleflex Inc., 550 U.S. 398, 417 (2007). It would have been obvious for one of ordinary skill in the art before the effective filing date of the invention to modify the invention of Mohan-Merchant-Bennett to incorporate the reading and comparing of a configuration file and changing the response accordingly as taught by Sandler in order to enable configurable, rule-based behavior for the deception hook, allowing deployed deception responses to be updated and customized without modifying the underlying code (Sandler, par 0086).
As per claim 10, Mohan-Merchant-Bennett teaches the method of claim 8. Mohan-Merchant-Bennett does not explicitly teach reading, by the hook, a configuration file from the storage medium; comparing the network request to the configuration file; and changing the response to the network request in response to the network request and according to the configuration file. In an analogous art in managing containers, Sandler teaches reading, by the hook, a configuration file from the storage medium; comparing the network request to the configuration file; and changing the response to the network request in response to the network request and according to the configuration file (Sandler, par 0024, “After the containers are deployed to their respective devices, the container deployment system may update a registry that records the identity or type of container that has been deployed to each device.”, Sandler, par 0085, “In some embodiments, the received properties may be compared to the deployment configuration file to determine whether the deployed containers are operating as set forth in the deployment configuration file. At block 170, the received properties may be compared to data stored in the container registry and the container registry updated to reflect any discrepancies.”). Examiner Note — Claim 10 differs from claim 9 in that the response is changed “in response to the network request and according to the configuration file,” requiring both the network request and the configuration file to determine the response modification. Sandler’s technique of comparing received data to a configuration file and adjusting behavior accordingly (par 0085-0086) addresses the configuration-file-driven component. In the combination with Mohan-Merchant-Bennett, the hook (executing in response to the network request as established in claim 6) reads the configuration file, compares the network request to the configuration, and changes the response based on both the network request and the configuration file — the network request triggers the hook and provides the data to compare, while the configuration file provides the rules for how to change the response. The reasons of obviousness have been noted in the rejection of claim 9 above and applicable herein.
As per claim 19, Mohan-Merchant-Bennett teaches the non-transitory computer-readable medium of claim 18. Mohan-Merchant-Bennett does not explicitly teach wherein the computer-executable instructions further cause the computer to read a configuration file from the storage medium; compare the network request to the configuration file; and change the response to the network request according to the configuration file. In an analogous art in managing containers, Sandler teaches the computer-executable instructions further cause the computer to read a configuration file from the storage medium; compare the network request to the configuration file; and change the response to the network request according to the configuration file (Sandler, par 0024, “After the containers are deployed to their respective devices, the container deployment system may update a registry that records the identity or type of container that has been deployed to each device.”, Sandler, par 0085, “In some embodiments, the received properties may be compared to the deployment configuration file to determine whether the deployed containers are operating as set forth in the deployment configuration file. At block 170, the received properties may be compared to data stored in the container registry and the container registry updated to reflect any discrepancies.”). The reasons of obviousness have been noted in the rejection of claim 9 above and applicable herein.
Conclusion
The prior art is made of record and not relied upon is considered pertinent to applicant’s disclosure:
Shayevitz (US 20190089737 A1) discloses a method for organizing deceptions that target containerized clusters on a network.
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 Linglan Edwards whose telephone number is (571)270-5440. The examiner can normally be reached 8:30am - 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.
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.
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408
Prosecution Insights