Detailed Action
1. This office action is in response to communication filed June 18, 2026. Claims 1-20 are currently pending and claims 1, 12, and 17 are the independent claims.
Notice of Pre-AIA or AIA Status
2. 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 Amendment
3. This Final Office Action is in response to the applicant’s remarks and arguments filed on June 18, 2026.
Claims 1, 5, 7-10, 12-13, 15-17, and 19-20 are amended. No claims have been cancelled. No claims are new. Claims 1-20 remain pending in the application.
Response to Arguments
4. Applicant’s arguments, see Remarks pages 6-20, filed June 18, 2026, with respect to the rejections of claims 1-20 under 35 U.S.C. 101 and 35 U.S.C. 103 have been fully considered and are persuasive. Therefore, the rejections have been withdrawn. However, upon further consideration, a new ground of rejection under 35 U.S.C. 103 is made via Kumar et al. (U.S. Patent No. 9,367,305) in view of Kinder et al. (U.S. Pub. No. 2017/0201490) for independent claims 1 and 17 and a new ground of rejection under 35 U.S.C. 103 is made via Kumar et al. (U.S. Patent No. 9,367,305) in view of Kinder et al. (U.S. Pub. No. 2017/0201490) and Du et al. (U.S. Patent No. 11,792,301) for independent claim 12.
In the Rejection of Claims 1-20 Under 35 U.S.C. 101 section on pages 6-15 of Remarks, the Applicant respectfully submitted that the rejection of claims 1-20 under 35 U.S.C. 101 as allegedly being directed towards abstract and non-patent eligible subject matter are false and are “clearly patent eligible, and thus, withdrawal of this rejection is respectfully requested.”
A. The Examiner appreciates the Applicant’s in depth submission of reasoning behind the patent eligibility of claims 1-20 under 35 U.S.C. 101. The Examiner respectfully agrees with the Applicant’s submission and has withdrawn the rejections of claims 1-20 under 35 U.S.C. 101 in this Office Action.
In the Rejection of Claims 1-20 Under 35 U.S.C. 103 section on pages 15-19 of Remarks, the Applicant respectfully submitted that the rejections made in the Non-Final Office Action by the Examiner “should be withdrawn for at least the following reason. Kumar, Du, and Kishimoto, alone or in combination, do not disclose, teach or suggest each and every element of the subject claims.”
B. The Examiner respectfully agrees with the Applicant’s submission and has withdrawn the rejections of claims 1-20 under 35 U.S.C. 103 in this Office Action. However, the Examiner ran further prior art searches following the amendment to the claims by the applicant and has found additional prior art references to reject claims 1-20 under 35 U.S.C. 103. A new ground of rejection under 35 U.S.C. 103 is made via Kumar et al. (U.S. Patent No. 9,367,305) in view of Kinder et al. (U.S. Pub. No. 2017/0201490) for independent claims 1 and 17 and a new ground of rejection under 35 U.S.C. 103 is made via Kumar et al. (U.S. Patent No. 9,367,305) in view of Kinder et al. (U.S. Pub. No. 2017/0201490) and Du et al. (U.S. Patent No. 11,792,301) for independent claim 12. All claims 1-20 have been rejected in detail below from sections 6-9 of this Final Office Action.
C. The Examiner has additionally included a claim objection to claim 8 following amendment to the claims in section 5 below. As such, claims 1-20 have been rejected by the Examiner under 35 U.S.C. 103 and claim 8 has been objected to by the Examiner. The Examiner submits this Office Action as final.
Claim Objections
5. Claim 8 is objected to because of the following informalities:
Claim 8 contains the claimed language “… wherein a value of the proxy variable is stored at a endpoint …” which should be amended to “… wherein a value of the proxy variable is stored at an endpoint …”
Appropriate correction is required.
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.
6. Claims 1-5, 11, 17-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kumar et al. (U.S. Patent No. 9,367,305) – hereinafter “Kumar” in view of Kinder et al. (U.S. Pub. No. 2017/0201490) – hereinafter “Kinder”.
Regarding independent claim 1, Kumar discloses:
A device, comprising:
a processor; and
a memory that stores executable instructions that, when executed by the processor, facilitate performance of operations, comprising:
determining that a build pipeline device of a container orchestration platform, configured to receive source code and build a containerized workload, has generated a container image associated with the source code; (Col. 12, Lines 38-42 “The method 400 includes receiving 410, by the processor, a source element associated with the source application. In some embodiments, receiving 410 a source element associated with the source application further includes receiving the source element from a source control system.” and Col. 13, Lines 1-7 “The method 400 also includes providing 440, by the processor, the container configuration for execution to an execution environment enabled to execute containers. In some embodiments, providing 440 the container configuration for execution creates a running container within the execution environment, the method further comprising generating a container image from the running container.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the source code/source element is received by the processor and soon after generates the container image from the running container.
Kumar does not explicitly disclose:
parsing the source code and the container image to identify an outbound hypertext transfer protocol request requiring proxy configuration;
in response to determining that a proxy setting is to be used for the outbound hypertext transfer protocol request, determining a proxy variable based on a deployment environment to which the containerized workload is to be deployed; and
updating a container specification for the containerized workload to include the proxy variable.
However, Kinder discloses:
parsing the source code and the container image to identify an outbound hypertext transfer protocol request requiring proxy configuration; ([0021] “The secure container control API 304 can create a container manager 308 and initialize security services 310, 312, and 314. Security services 310, 312, and 314 can include inbound and outbound proxies for network services, such as TCP, HTTP, HTTPS, and the like, as well as a DNS proxy server, network filters, and other services to secure communication.” and [0029] “At 416, outbound proxy services can be established. For example, outbound proxy services can be established for HTTP, HTTPS and other network protocols, depending on the configuration of the application and the container. The outbound proxy services can filter and route approved outbound traffic from the application within the container.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the secure container control API initializes security services to include outbound proxies for HTTP requests based on the specific container.
in response to determining that a proxy setting is to be used for the outbound hypertext transfer protocol request, determining a proxy variable based on a deployment environment to which the containerized workload is to be deployed; and ([0021] “The secure container control API 304 can create a container manager 308 and initialize security services 310, 312, and 314. Security services 310, 312, and 314 can include inbound and outbound proxies for network services, such as TCP, HTTP, HTTPS, and the like, as well as a DNS proxy server, network filters, and other services to secure communication.” and [0029] “At 416, outbound proxy services can be established. For example, outbound proxy services can be established for HTTP, HTTPS and other network protocols, depending on the configuration of the application and the container. The outbound proxy services can filter and route approved outbound traffic from the application within the container.” and [0025] “At 404, a private virtual network can be established between the application and the secure container service. The use of the private virtual network can substantially prevent intercepting of the traffic between the application and secure container service by a compromised neighboring container. At 406, a set of network filter rules can be established to restrict the flow of traffic to or from the application. The network filter rules can be based on the security policy. In this way, the secure container service can provide a firewall between the application and the environment outside of the container, be that neighboring containers, other servers within a server room, or the internet.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the secure container control API initializes security services to include outbound proxies for HTTP requests based on the specific container. Then, the network filter rules, mapped to proxy variable, are established and set for the container based upon its application usage.
updating a container specification for the containerized workload to include the proxy variable. ([0021] “The secure container control API 304 can create a container manager 308 and initialize security services 310, 312, and 314. Security services 310, 312, and 314 can include inbound and outbound proxies for network services, such as TCP, HTTP, HTTPS, and the like, as well as a DNS proxy server, network filters, and other services to secure communication.” and [0029] “At 416, outbound proxy services can be established. For example, outbound proxy services can be established for HTTP, HTTPS and other network protocols, depending on the configuration of the application and the container. The outbound proxy services can filter and route approved outbound traffic from the application within the container.” and [0025] “At 404, a private virtual network can be established between the application and the secure container service. The use of the private virtual network can substantially prevent intercepting of the traffic between the application and secure container service by a compromised neighboring container. At 406, a set of network filter rules can be established to restrict the flow of traffic to or from the application. The network filter rules can be based on the security policy. In this way, the secure container service can provide a firewall between the application and the environment outside of the container, be that neighboring containers, other servers within a server room, or the internet.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the secure container control API initializes security services to include outbound proxies for HTTP requests based on the specific container. Then, the network filter rules, mapped to proxy variable, are established and set for the container based upon its application usage.
Both Kumar and Kinder are in the same field of endeavor as they are both in the container configuration art and, therefore, are combinable/modifiable.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify Kumar's container specification because Kinder's container specification is based upon secure containerization via security services to handle outbound HTTP requests with proxies.
Motivation would improve container security based upon handling each container specification differently based upon outbound HTTP requests and the specific applications the container is handling to establish container privacy from the entire user’s network.
Regarding claim 2, Kumar discloses the device of claim 1, but does not explicitly disclose:
wherein the updating of the container specification results in an updated containerized workload comprising machine generated proxy settings, and wherein the updated containerized workload is deployed to a container runtime environment.
However, Kinder discloses:
wherein the updating of the container specification results in an updated containerized workload comprising machine generated proxy settings, and wherein the updated containerized workload is deployed to a container runtime environment. ([0021] “The secure container control API 304 can create a container manager 308 and initialize security services 310, 312, and 314. Security services 310, 312, and 314 can include inbound and outbound proxies for network services, such as TCP, HTTP, HTTPS, and the like, as well as a DNS proxy server, network filters, and other services to secure communication.” and [0029] “At 416, outbound proxy services can be established. For example, outbound proxy services can be established for HTTP, HTTPS and other network protocols, depending on the configuration of the application and the container. The outbound proxy services can filter and route approved outbound traffic from the application within the container.” and [0025] “At 404, a private virtual network can be established between the application and the secure container service. The use of the private virtual network can substantially prevent intercepting of the traffic between the application and secure container service by a compromised neighboring container. At 406, a set of network filter rules can be established to restrict the flow of traffic to or from the application. The network filter rules can be based on the security policy. In this way, the secure container service can provide a firewall between the application and the environment outside of the container, be that neighboring containers, other servers within a server room, or the internet.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the secure container control API initializes security services to include outbound proxies for HTTP requests based on the specific container. Then, the network filter rules, mapped to proxy variable, are established and set for the container based upon its application usage.
Both Kumar and Kinder are in the same field of endeavor as they are both in the container configuration art and, therefore, are combinable/modifiable.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify Kumar's container specification because Kinder's container specification is updated with security services to handle outbound HTTP requests with proxies based upon the applications the container is running and the outbound HTTP requests being sent by the applications.
Motivation would improve container security based upon handling each container specification differently based upon outbound HTTP requests and the specific applications the container is handling to establish container privacy from the entire user’s network.
Regarding claim 3, Kumar discloses the device of claim 1, wherein the containerized workload is at least one of a containerized microservice, a containerized application, or a containerized infrastructure service. (Col. 5, Lines 52-62 “Once created, the resultant container (or “target container”) 120 includes at least the dependency component(s) (not shown in FIG. 1) for running the application 130. In some embodiments, one or more of the source elements 132 also become target elements. In other words, a set of target elements is added to the target container configuration 120 that includes the dependency component(s) and, in some situations, one or more of the source elements 132. As such, the target container configuration 120 includes application components necessary for the execution environment 140 to run the application 130 within an executing container.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the target container configuration includes application components necessary for the execution environment to run the application within an executing container.
Regarding claim 4, Kumar discloses the device of claim 1, wherein the outbound hypertext transfer protocol request comprises a uniform resource identifier or a uniform resource locator. (Col. 17, Lines 19-26 “In some embodiments, the communications mapping module 610 inspects configurations files for uniform resource indicators (“URLs”). If a URL is identified within the source element of, for example, http server sub-application 710B which references the application server 710D, the communications mapping module 610 adds a dependency from node 710B to node 710D in graph 700.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the URL corresponds to the recited hypertext transfer protocol request and is identified within the configuration files.
Regarding claim 5, Kumar discloses the device of claim 1, but does not explicitly disclose:
wherein the outbound hypertext transfer protocol request represents a call to service that is performed by the containerized workload.
However, Kinder discloses:
wherein the outbound hypertext transfer protocol request represents a call to service that is performed by the containerized workload. ([0029] “At 416, outbound proxy services can be established. For example, outbound proxy services can be established for HTTP, HTTPS and other network protocols, depending on the configuration of the application and the container. The outbound proxy services can filter and route approved outbound traffic from the application within the container.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the containerized workload’s outbound HTTP request can be set to filter outbound traffic from the container’s application.
Both Kumar and Kinder are in the same field of endeavor as they are both in the container configuration art and, therefore, are combinable/modifiable.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify Kumar's container specification because Kinder's container specification is updated with security services to handle outbound HTTP requests with proxies such that the outbound HTTP request requires the container it is running on to handle the request.
Motivation would improve container security based upon handling each container specification differently based upon outbound HTTP requests and the specific applications the container is handling to establish container privacy from the entire user’s network.
Regarding claim 11, Kumar discloses the device of claim 1, but does not explicitly disclose:
wherein the updating of the container specification comprises inserting the proxy variable or overwriting an incorrectly specified proxy variable.
However, Kinder discloses:
wherein the updating of the container specification comprises inserting the proxy variable or overwriting an incorrectly specified proxy variable. ([0021] “The secure container control API 304 can create a container manager 308 and initialize security services 310, 312, and 314. Security services 310, 312, and 314 can include inbound and outbound proxies for network services, such as TCP, HTTP, HTTPS, and the like, as well as a DNS proxy server, network filters, and other services to secure communication.” and [0029] “At 416, outbound proxy services can be established. For example, outbound proxy services can be established for HTTP, HTTPS and other network protocols, depending on the configuration of the application and the container. The outbound proxy services can filter and route approved outbound traffic from the application within the container.” and [0025] “At 404, a private virtual network can be established between the application and the secure container service. The use of the private virtual network can substantially prevent intercepting of the traffic between the application and secure container service by a compromised neighboring container. At 406, a set of network filter rules can be established to restrict the flow of traffic to or from the application. The network filter rules can be based on the security policy. In this way, the secure container service can provide a firewall between the application and the environment outside of the container, be that neighboring containers, other servers within a server room, or the internet.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the secure container control API initializes security services to include outbound proxies for HTTP requests based on the specific container. Then, the network filter rules, mapped to proxy variable, are established and set for the container based upon its application usage.
Both Kumar and Kinder are in the same field of endeavor as they are both in the container configuration art and, therefore, are combinable/modifiable.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify Kumar's container specification because Kinder's container specification is updated with security services to handle outbound HTTP requests with proxies such that the outbound HTTP request requires the container it is running on to handle the request.
Motivation would improve container security based upon handling each container specification differently based upon outbound HTTP requests and the specific applications the container is handling to establish container privacy from the entire user’s network.
Regarding claims 17-18, they are method claims having the same limitations as cited in device claims 1-2, respectively. Thus, claims 17-18 are also rejected under the same rationale as addressed in the rejections of claims 1-2 above, respectively.
Regarding claim 20, Kumar discloses the method of claim 17, but does not explicitly disclose:
further comprising determining, by the device, the proxy variable by literal value or by reference.
However, Kinder discloses:
further comprising determining, by the device, the proxy variable by literal value or by reference to an application programming interface (API) object. ([0021] “The secure container control API 304 can create a container manager 308 and initialize security services 310, 312, and 314. Security services 310, 312, and 314 can include inbound and outbound proxies for network services, such as TCP, HTTP, HTTPS, and the like, as well as a DNS proxy server, network filters, and other services to secure communication.” and [0029] “At 416, outbound proxy services can be established. For example, outbound proxy services can be established for HTTP, HTTPS and other network protocols, depending on the configuration of the application and the container. The outbound proxy services can filter and route approved outbound traffic from the application within the container.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the secure container control API initializes security services to include outbound proxies for HTTP requests based on the specific container.
Both Kumar and Kinder are in the same field of endeavor as they are both in the container configuration art and, therefore, are combinable/modifiable.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify Kumar's container specification because Kinder's container specification is updated with security services to handle outbound HTTP requests with proxies such that the proxy is directly referenced by the secure container control API.
Motivation would improve container security based upon handling each container specification differently based upon outbound HTTP requests and the specific applications the container is handling to establish container privacy from the entire user’s network.
7. Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Kumar et al. (U.S. Patent No. 9,367,305) – hereinafter “Kumar” in view of Kinder et al. (U.S. Pub. No. 2017/0201490) – hereinafter “Kinder”, and further in view of Kishimoto (U.S. Pub. No. 2013/0194630).
Regarding claim 6, Kumar discloses the device of claim 1, but does not explicitly disclose:
wherein the proxy variable represents a setting for one or more HTTP_PROXY settings, one or more HTTPS_PROXY settings, or one or more NO_PROXY settings.
Kinder also does not disclose the claim limitation. However, Kishimoto discloses:
wherein the proxy variable represents a setting for one or more HTTP_PROXY settings, one or more HTTPS_PROXY settings, or one or more NO_PROXY settings. (Fig. 5 and [0092] “The line 518 declares "export:" and specifies that a setting item determined by an access key "sys/nw/tcpio/proxy/http" (setting value of the HTTP proxy server of the image forming apparatus) is extracted from the extraction-source image forming apparatus and that the extracted setting item is set in the distribution-destination image forming apparatus.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the proxy variable has a setting value of the HTTP proxy server of the image forming apparatus.
Kumar, Kinder, and Kishimoto are in the same field of endeavor as they are all in the HTTP communication request handling art and, therefore, are combinable/modifiable.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify Kumar and Kinder's HTTP request handling because Kishimoto’s HTTP setting is saved in an image forming apparatus to ensure the setting is dependent on the image’s purpose.
Motivation would improve container security based upon handling each container specification differently based upon outbound HTTP requests and the specific applications the container is handling to properly set HTTP request handling variable.
8. Claims 7-8, 10, 12, 14-16, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kumar et al. (U.S. Patent No. 9,367,305) – hereinafter “Kumar” in view of Kinder et al. (U.S. Pub. No. 2017/0201490) – hereinafter “Kinder” and Du et al. (U.S. Patent No. 11,792,301) – hereinafter “Du”.
Regarding claim 7, Kumar discloses the device of claim 1, but does not explicitly disclose:
wherein the proxy variable comprises a uniform resource identifier or a uniform resource locator of a proxy server or a domain associated with the hypertext transfer protocol request.
Kinder also does not disclose the claim limitation. However, Du discloses:
wherein the proxy variable comprises a uniform resource identifier or a uniform resource locator of a proxy server or a domain associated with the hypertext transfer protocol request. (Col. 3, Lines 53-65 “When a client sends a request for a virtual service 203 to virtual gateway 113, the virtual gateway 113 can evaluate the request. This can include evaluating the uniform resource locator (URL) path included in the request (e.g., in a hypertext transfer protocol (http) request), and determining which virtual node 103 is the destination of the request. The virtual gateway 113 could then forward the request to the appropriate virtual node 103. For example, if the virtual gateway 113 determined that the request was destined for the virtual node 103b, the virtual gateway 113 could forward the request to the sidecar proxy 106b. The virtual gateway 113 could then provide the request to the container 109b for processing.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the containerized workload including the virtual gateway evaluates requests including URL paths to determine where to route the request.
Kumar, Kinder, and Du are in the same field of endeavor as they are all in the container communication art and, therefore, are combinable/modifiable.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify Kumar and Kinder's container’s HTTP request handling because Du’s proxy variable handles HTTP request forwarding based on the URL path included in the request.
Motivation would improve container security based upon handling each container specification differently based upon outbound HTTP requests and the specific applications the container is handling to properly route HTTP requests via variable setting.
Regarding claim 8, Kumar discloses the device of claim 1, but does not explicitly disclose:
wherein a value of the proxy variable is stored at a known endpoint and deployment target pair data store that is configurable based on a deployment environment.
Kinder also does not disclose the claim limitation. However, Du discloses:
wherein a value of the proxy variable is stored at a endpoint and deployment target pair data store that is configurable based on a deployment environment. (Col. 2, Lines 49-53 “To process network traffic, individual side car proxies 106 can be provided with a manifest file that defines one or more routes or rules for processing traffic on behalf of the virtual node 103” and Col. 6, Lines 1-7 “Also, various data can be stored in a data store 316 that is accessible to the computing environment 303. The data store 316 can be representative of a plurality of data stores 316, which can include relational databases or non-relational databases such as object-oriented databases, hierarchical databases, hash tables or similar key-value data stores, as well as other data storage applications or data structures.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the key-value pairs in the data stores, an example of a configurable data store, can be retrieved in relation to the rules of the manifest file which corresponds to a proxy variable and handles traffic processing.
Kumar, Kinder, and Du are in the same field of endeavor as they are all in the container communication art and, therefore, are combinable/modifiable.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify Kumar and Kinder's container’s HTTP request handling because Du’s proxy variable storage is based upon the deployment environment such that it can be stored in a plurality of data stores rather than just in the container image.
Motivation would improve container communication based upon storing the container’s proxy variable in a plurality of locations to not limit the container’s specification to one device.
Regarding claim 10, Kumar discloses the device of claim 8, wherein the value of the proxy variable is stored as a reference to an API object. (Col. 17, Lines 19-37 “In some embodiments, the communications mapping module 610 inspects configurations files for uniform resource indicators (“URLs”). If a URL is identified within the source element of, for example, http server sub-application 710B which references the application server 710D, the communications mapping module 610 adds a dependency from node 710B to node 710D in graph 700. Some example environment variables that provide URLs indicating communications dependencies include, for example: FULL_API_DOMAIN=http://forrest-api-codenow.runnableapp.com GITHUB_CALLBACK_URL=http://forrest-api-codenow.runnableapp.com/auth/github/callback GITHUB_HOOK_URL=http://forrest-api-codenow.runnableapp.com/actions/github DOMAIN=runnable3.net REDIS_NAMESPACE=“runnable:ryan-api” ENABLE_BUILDS_ON_GIT_PUSH=false”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the URL corresponds to the recited hypertext transfer protocol request and is identified within the configuration files, so the proxy variable URL is stored as a reference to the API domain.
Regarding independent claim 12, Kumar discloses:
A non-transitory computer-readable medium comprising instructions that, in response to execution, cause a system comprising a processor to perform operations, comprising:
determining that a build pipeline device, comprising a capability to receive source code and to build a containerized workload, has generated a container image associated with the source code; (Col. 12, Lines 38-42 “The method 400 includes receiving 410, by the processor, a source element associated with the source application. In some embodiments, receiving 410 a source element associated with the source application further includes receiving the source element from a source control system.” and Col. 13, Lines 1-7 “The method 400 also includes providing 440, by the processor, the container configuration for execution to an execution environment enabled to execute containers. In some embodiments, providing 440 the container configuration for execution creates a running container within the execution environment, the method further comprising generating a container image from the running container.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the source code/source element is received by the processor and soon after generates the container image from the running container.
Kumar does not explicitly disclose:
parsing the source code and the container image to identify an outbound hypertext transfer protocol request requiring proxy configuration;
retrieving, from a key-value pair data store, key-value pairs that indicate proxy setting variables based on a deployment environment to which the containerized workload is to be deployed; and
updating a container specification for the containerized workload to include the proxy setting variables.
However, Kinder discloses:
parsing the source code and the container image to identify an outbound hypertext transfer protocol request requiring proxy configuration; ([0021] “The secure container control API 304 can create a container manager 308 and initialize security services 310, 312, and 314. Security services 310, 312, and 314 can include inbound and outbound proxies for network services, such as TCP, HTTP, HTTPS, and the like, as well as a DNS proxy server, network filters, and other services to secure communication.” and [0029] “At 416, outbound proxy services can be established. For example, outbound proxy services can be established for HTTP, HTTPS and other network protocols, depending on the configuration of the application and the container. The outbound proxy services can filter and route approved outbound traffic from the application within the container.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the secure container control API initializes security services to include outbound proxies for HTTP requests based on the specific container.
retrieving … proxy setting variables based on a deployment environment to which the containerized workload is to be deployed; and ([0021] “The secure container control API 304 can create a container manager 308 and initialize security services 310, 312, and 314. Security services 310, 312, and 314 can include inbound and outbound proxies for network services, such as TCP, HTTP, HTTPS, and the like, as well as a DNS proxy server, network filters, and other services to secure communication.” and [0029] “At 416, outbound proxy services can be established. For example, outbound proxy services can be established for HTTP, HTTPS and other network protocols, depending on the configuration of the application and the container. The outbound proxy services can filter and route approved outbound traffic from the application within the container.” and [0025] “At 404, a private virtual network can be established between the application and the secure container service. The use of the private virtual network can substantially prevent intercepting of the traffic between the application and secure container service by a compromised neighboring container. At 406, a set of network filter rules can be established to restrict the flow of traffic to or from the application. The network filter rules can be based on the security policy. In this way, the secure container service can provide a firewall between the application and the environment outside of the container, be that neighboring containers, other servers within a server room, or the internet.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the secure container control API initializes security services to include outbound proxies for HTTP requests based on the specific container. Then, the network filter rules, mapped to proxy variable, are established and set for the container based upon its application usage.
updating a container specification for the containerized workload to include the proxy setting variables. ([0021] “The secure container control API 304 can create a container manager 308 and initialize security services 310, 312, and 314. Security services 310, 312, and 314 can include inbound and outbound proxies for network services, such as TCP, HTTP, HTTPS, and the like, as well as a DNS proxy server, network filters, and other services to secure communication.” and [0029] “At 416, outbound proxy services can be established. For example, outbound proxy services can be established for HTTP, HTTPS and other network protocols, depending on the configuration of the application and the container. The outbound proxy services can filter and route approved outbound traffic from the application within the container.” and [0025] “At 404, a private virtual network can be established between the application and the secure container service. The use of the private virtual network can substantially prevent intercepting of the traffic between the application and secure container service by a compromised neighboring container. At 406, a set of network filter rules can be established to restrict the flow of traffic to or from the application. The network filter rules can be based on the security policy. In this way, the secure container service can provide a firewall between the application and the environment outside of the container, be that neighboring containers, other servers within a server room, or the internet.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the secure container control API initializes security services to include outbound proxies for HTTP requests based on the specific container. Then, the network filter rules, mapped to proxy variable, are established and set for the container based upon its application usage.
Both Kumar and Kinder are in the same field of endeavor as they are both in the container configuration art and, therefore, are combinable/modifiable.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify Kumar's container specification because Kinder's container specification is based upon secure containerization via security services to handle outbound HTTP requests with proxies.
Motivation would improve container security based upon handling each container specification differently based upon outbound HTTP requests and the specific applications the container is handling to establish container privacy from the entire user’s network.
In addition, Du discloses:
retrieving, from a key-value pair data store, key-value pairs that indicate … a deployment environment to which the containerized workload is to be deployed; and (Col. 2, Lines 49-53 “To process network traffic, individual side car proxies 106 can be provided with a manifest file that defines one or more routes or rules for processing traffic on behalf of the virtual node 103” and Col. 6, Lines 1-7 “Also, various data can be stored in a data store 316 that is accessible to the computing environment 303. The data store 316 can be representative of a plurality of data stores 316, which can include relational databases or non-relational databases such as object-oriented databases, hierarchical databases, hash tables or similar key-value data stores, as well as other data storage applications or data structures.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the key-value data stores can be retrieved in relation to the rules of the manifest file which corresponds to traffic processing for a container’s deployment.
Kumar, Kinder, and Du are in the same field of endeavor as they are all in the container deployment art and, therefore, are combinable/modifiable.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify Kumar and Kinder's container’s deployment environment because Du’s key-value pair clearly syncs up the container workspace and its network settings.
Motivation would improve container deployment based upon handling each container specification differently based upon outbound HTTP requests and the specific applications the container is handling to properly create key-value pairs for proxy variables and their deployment environment.
Regarding claims 14-16, they are non-transitory computer-readable medium claims having the same limitations as cited in device claims 3-4 and 8, respectively. Thus, claims 14-16 are also rejected under the same rationale as addressed in the rejections of claims 3-4 and 8 above, respectively.
Regarding claim 19, Kumar discloses the method of claim 17, but does not explicitly disclose:
further comprising retrieving, by the device, the proxy variable from a configurable data store based on the outbound hypertext transfer protocol request.
Kinder also does not disclose the claim limitation. However, Du discloses:
further comprising retrieving, by the device, the proxy variable from a configurable data store based on the outbound hypertext transfer protocol request. (Col. 2, Lines 49-53 “To process network traffic, individual side car proxies 106 can be provided with a manifest file that defines one or more routes or rules for processing traffic on behalf of the virtual node 103” and Col. 6, Lines 1-7 “Also, various data can be stored in a data store 316 that is accessible to the computing environment 303. The data store 316 can be representative of a plurality of data stores 316, which can include relational databases or non-relational databases such as object-oriented databases, hierarchical databases, hash tables or similar key-value data stores, as well as other data storage applications or data structures.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the key-value pairs in the data stores, an example of a configurable data store, can be retrieved in relation to the rules of the manifest file which corresponds to a proxy variable and handles traffic processing.
Kumar, Kinder, and Du are in the same field of endeavor as they are all in the container communication art and, therefore, are combinable/modifiable.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify Kumar and Kinder's container’s communication handling because Du’s container proxy variable that was previously stored is now retrieved for verification of the proxy settings of the container.
Motivation would improve container deployment based upon handling each container specification differently based upon outbound HTTP requests and the specific applications the container is handling to properly verify each container’s proxy settings is followed to ensure the user handles the requests as expected.
9. Claims 9 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Kumar et al. (U.S. Patent No. 9,367,305) – hereinafter “Kumar” in view of Kinder et al. (U.S. Pub. No. 2017/0201490) – hereinafter “Kinder” and Du et al. (U.S. Patent No. 11,792,301) – hereinafter “Du”, and further in view of Kishimoto (U.S. Pub. No. 2013/0194630).
Regarding claim 9, Kumar discloses the device of claim 8, but does not explicitly disclose:
wherein the value of the proxy variable is stored as a key-value pair that is paired with a domain of the outbound hypertext transfer protocol request.
Neither Kinder nor Du disclose the claim limitation. However, Kishimoto discloses:
wherein the value of the proxy variable is stored as a key-value pair that is paired with a domain of the outbound hypertext transfer protocol request. ([0113] “The line 615 specifies a correspondence between an access key and a real address for extracting (setting) a setting value of the DNS domain name set in the image forming apparatus 202. The line 616 specifies a correspondence between an access key and a real address for extracting (setting) a setting value of the HTTP proxy server set in the image forming apparatus 202.”) The citation is interpreted to read on the claimed invention because under broadest reasonable interpretation, the key-value pair/correspondence between access key and DNS domain name is set in the image forming apparatus. The key-value pair/correspondence between access key and proxy variable setting value is set in the image forming apparatus. As such, the proxy variable can be stored as a key-value pair with a domain of the HTTP request.
Kumar, Kinder, Du, and Kishimoto are in the same field of endeavor as they are all in the HTTP communication request handling art and, therefore, are combinable/modifiable.
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify Kumar, Kinder, and Du's container’s HTTP communication handling because Kishimoto’s container proxy variable key-value pair storage between access key and DNS domain name allows the proxy variable to be set in the image forming apparatus for a container.
Motivation would improve container deployment based upon handling each container specification differently based upon outbound HTTP requests and the specific applications the container is handling to properly verify each container’s proxy settings is followed to ensure the user handles the requests as expected.
Regarding claim 13, it is a non-transitory computer-readable medium claim having the same limitations as cited in device claim 6. Thus, claim 13 is also rejected under the same rationale as addressed in the rejection of claim 6 above.
Conclusion
10. 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.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Such prior art includes:
- Lenrow et al. (U.S. Pub. No. 2023/0047880) which discloses containerized systems that include containerized applications deployed in a service mesh architecture with each containerized application connected to other containerized applications and to a mesh controller through a sidecar proxy.
- Sharma et al. (U.S. Pub. No. 2024/0422107) which discloses a container platform with an included service proxy that monitors for the addition and removal of service and endpoints objects, and it maintains the network configuration of the computing device to ensure communication among pods and containers using services.
- Howarth et al. (U.S. Pub. No. 2024/0422248) which discloses an SIP proxy (that can be translated to HTTP) that receives SIP packets that are written into an outbound packet (in HTTP format).
- Veemboor et al. (U.S. Patent No. 12,028,386) which discloses a service proxy that performs a similar function on the container where the service runtime is deployed in which customer outbound requests have HTTP formatting.
- Eidelman et al. (U.S. Patent Nol. 7,873,734) which discloses intelligent proxy rules for repackaging inbound requests into outbound responses on container systems.
Examiner has cited particular columns/paragraphs/sections and line numbers in the references applied and not relied upon to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in 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.
When responding to the Office action, applicant is advised to clearly point out the patentable novelty the claims present in view of the state of the art disclosed by the reference(s) cited or the objections made. A showing of how the amendments avoid such references or objections must also be present. See 37 C.F.R. 1.111(c).
When responding to this Office action, applicant is advised to provide the line and page numbers in the application and/or reference(s) cited to assist in locating the appropriate paragraphs.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL B TRAINOR whose telephone number is (571)272-3710. The examiner can normally be reached Monday-Friday 9AM-5PM.
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, Pierre Vital can be reached at (571) 272-4215. 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.
/D.T./Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights