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 filed 3/2/26 have been fully considered but they are not persuasive.
Applicant argues - “Talwar does not teach or suggest "supplementing the container management tool [i.e., the container orchestration platform 110] with a policy extension framework." First, the network policy evaluation framework 140 of Talwar is not a "policy extension framework" as required by Applicant's claim 1. The network policy evaluation framework 140 does not provide any policy extension to the container orchestration platform 110. The network policy evaluation framework 140 only provides the container orchestration platform 110 with conflict results (see, e.g., Talwar at paragraph [0034]).”
Examiner’s response –Talwar explicitly states:
“The plug-in-based architecture of the network policy evaluation framework makes it easier to extend the functionality across various CNI providers. The network policy evaluation framework introduces a network provider agnostic framework which encapsulates the core tenets of firewall functionality, thereby allowing a simplified and unified experience when debugging, analyzing, or performing diagnosis of network policy rule configuration anomalies across different CNI providers.” (Emphasis added – Paragraph 11)
“The network policy evaluation framework described in this document can evaluate network policies from multiple sources, e.g., from the container orchestration platform, any CNI plugin, and the underlying computing infrastructure on which the container orchestration platform runs, and determine the results of the policies. Such results can indicate whether there are any conflicts between the network policies and recommended conflict remediation actions for correcting the policies.” (Emphasis added – Paragraph 7)
“The network policy evaluation framework described in this document can evaluate network policies from multiple sources, evaluate the policies, determine conflicts between the policies, and prevent conflicting policies from being applied to an application (e.g., to a cluster of containers), thereby reducing errors and loss of service that would otherwise occur due to the conflicting policies…The network policy evaluation framework is network provider agnostic and can evaluate network policies from various network providers (e.g., CNI plugins) along with the network policies of the container orchestration platform and/or the network policies of the underlying infrastructure” (Paragraph 13)
This plain and explicit language makes it clear that there is a “framework” that is specific to evaluation of network policy. Further, this language clearly indicates policy “extension” in relation to extending across providers, providing an agnostic framework, and evaluation of network policies from multiple sources including those apart from the platform/underlying infrastructure. Talwar is not limited to only providing conflict results but also provides remedial actions specific to network policy. This leads to making “network policy management easier, faster, and more accurate than conventional techniques of simply submitting new network policies in text files.” (Paragraph 7). Applicant has not sufficiently explained how the just decribed “network policy evaluation framework“ of Talwar is somehow excluded from the scope of the claimed “policy extension framework”.
Applicant argues – “Second, Talwar does not describe supplementing the container orchestration platform 110 with anything. Talwar describes the container orchestration platform 110 as something that "can automate the deployment and management of containerized applications" (see paragraph [0025]). Talwar also teaches "[t]he container orchestration platform 110 can include virtual and physical computing infrastructure to host container orches-tration clusters 120. A container orchestration cluster 120, which is also referred to as a cluster for brevity, can include, among other things, multiple containers 122 and services 124 for the containers 122" (see Talwar at paragraphs [0025] - [0026]). Talwar does not teach or suggest any supplementation of the container orchestration platform 110, as required by claim 1.”
Examiner’s response – Talwar’s framework is directly interacting and providing functionality to the orchestration platform. Talwar’s framework is clearly supplementing the orchestration platform in some manner as such functionality is not present without the framework. Paragraph 13 succinctly summarizes the specific supplementation the network policy evaluation framework of Talwar provides. Talwar explicitly states in paragraph 13,
“The subject matter described in this specification can be implemented in particular embodiments so as to realize one or more of the following advantages. The network policy evaluation framework described in this document can evaluate network policies from multiple sources, evaluate the policies, determine conflicts between the policies, and prevent conflicting policies from being applied to an application (e.g., to a cluster of containers), thereby reducing errors and loss of service that would otherwise occur due to the conflicting policies. The network policy evaluation framework can perform this evaluation and implement corrective action without introducing additional containers or other workloads into the cluster, which prevents the addition of resource intense agents/containers to clusters. This reduces the utilization of compute, memory, network, and storage resources for the cluster, freeing up resources for the containers that are running in the cluster and/or enabling additional containers to run in place of any test containers that would have otherwise been added to perform functions of the network policy evaluation framework. The network policy evaluation framework is network provider agnostic and can evaluate network policies from various network providers (e.g., CNI plugins) along with the network policies of the container orchestration platform and/or the network policies of the underlying infrastructure, which can include a virtual computing infrastructure and/or a physical computing infrastructure. For example, the network policy evaluation framework can convert firewall rules into a canonical format and evaluate the various rules.”
Talwar clearly provides for evaluation of network policies extended in an agnostic framework. This evaluation allows for conflict management that occurs outside of the platform itself and provides specific benefits to the platform as described above. It is not clear how the functionality of Talwar’s framework along with the benefits provided thereof would not be considered as “supplementation” in relation to the container orchestration platform. Applicant’s arguments are not persuasive.
Applicant’s remaining arguments are addressed by the responses above.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-4, 6, 8, 11-13, 15, 17 and 20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by US 2023/0022134 by Talwar et al. (Talwar).
With respect to claim 1, Talwar teaches a method of managing and deploying network resources, comprising: employing a container management tool in a network that implements resources through one or more containers; (Paragraph 25 – container orchestration platform, such as Kubernetes, handling deployment and management of containers in a network) and
supplementing the container management tool with a policy extension framework (Paragraph 11 – network policy evaluation framework offers plug-in based architecture to extended functionality across providers. a network provider agnostic framework allowing a simplified and unified experience across different providers), the policy extension framework configured to dynamically define and enforce an intent of a user in a forwarding plane of the network. (Fig. 1, Paragraph 7, 11-13, 27, 33-37 –, policies include rules that define how traffic is handled for particular network resources (e.g. between particular ports/pods/namespaces), framework evaluates both active and new user policies for conflicts and can offer remedial actions that can lead to modifications of rules and/or priorities of the policies, the examiner interprets such evaluation and remedial actions as being dynamic in nature. Furthermore such remedial actions will determine the flow of traffic into,out and within the cluster in relation to the particular ports/pods/namespaces. This is also “dynamic” in nature based on paragraph 39 of the spec indicating “rules to indicate how data much past through the set of network services”)
With respect to claim 2, Talwar teaches the method of claim 1, further comprising using a declarative programming language to convey the intent of the user to the policy extension framework. (Paragraph 28-30 – policies may have multiple sources and may be in multiple formats including those using declarative programming language such as CRDs)
With respect to claim 3, Talwar teaches the method of claim 1, wherein the container management tool is Kubernetes. (Paragraph 25 – container orchestration platform, such as Kubernetes)
With respect to claim 4, Talwar teaches the method of claim 3, wherein the policy extension framework defines policy as a Custom Resource Definition (CRD). (Paragraph 28-30 Policies may be defined as CRDs)
With respect to claim 6, Talwar teaches the method of claim 1, further comprising: defining, by the user, at least one network resource; (Paragraph 27-29 – user defined policy can define particular IP addresses, ports, pods, namespaces) defining, by the user, at least one service (Paragraph 58, 70 – policy can define services as source or destination); defining, by the user, at least one policy (Paragraph 27-29, 42 – user defined policy); delivering network data traffic to the at least one service according to the at least one policy. (Paragraph 27-29, 58, 70 – policy defines how traffic between source and destination should be handled, which would include deliver to a service destination)
With respect to claim 8, Talwar teaches the method of claim 6, further comprising programming match selectors as match rules in the forwarding plane of the network, the match selectors being programmed according to the intent of the user. (paragraph 27 policies include matching rules, i.e. particular source and particular destination with an indication of allowing or denying based on the match)
Claims 11-13, 15, 17 and 20 are similar in scope to claims 1-4, 6, and 8 and are rejected based on the same rationale.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claim(s) 5 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Talwar in view of US 2021/0240540 by Wang et al. (Wang).
With respect to claim 5, Talwar teaches the method of claim 1, but does not explicitly disclose wherein the container comprises a microservice that is packaged along with associated dependencies and configurations.
Wang teaches containers as being defined as comprising microservices packaged with libraries, configurations, and dependencies in a manner that enables the software to run virtually anywhere (Paragraph 2).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have the containers of Talwar comprise a microservice as in Wang. One would be motivated to have this for the advantage of enabling the container software to run virtually anywhere.
Claim 14 is similar in scope to claim 9 and is rejected based on the same rationale.
Claim(s) 7 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Talwar in view of US 2024/0179071 by Zhou et al. (Zhou).
With respect to claim 7, Talwar teaches the method of claim 6, but does not explicitly disclose wherein the at least one network resource is defined on Open vSwitch.
Zhou teaches network policy with traffic rules that can be enforced in part through the use of Open vSwitch as a network resource in a cluster network (Paragraph 18, 120 – open vswitch receives rules for enforcing traffic service policies, open vswitch indicated as widely adopted).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have the network resource of Talwar include an open vSwitch as in Zhou. Using a widely adopted network resource known for enforcing policy for aiding in enforcement of the network policy in Talwar would be obvious.
Claim 16 is similar in scope to claim 7 and is rejected based on the same rationale.
Claim(s) 9-10, 18 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Talwar in view of US RE50,121 E by Olofsson et al. (Olofsson).
With respect to claim 9, Talwar teaches the method of claim 8, but does not explicitly disclose further comprising forwarding a data packet at an applied network port through a service function chain when the data packet matches the match selectors.
Olofsson teaches forwarding a data packet at an applied network port through a service function chain when the data packet matches the match selectors (Col. 5 line 20-37 traffic on inbound ports apply inbound policy for a firewall service chain based on matching action)
It would have been obvious to one of ordinary skill in the art to have the service source/destination policy of Talwar include matching for a service function chain as in Olofsson. Talwar already teaches network policy for traffic in relation to cluster services. Accordingly, extending the benefits of Talwar to services in the form of service function chains would have been obvious.
Claim 18 is similar in scope to claim 9 and is rejected based on the same rationale.
With respect to claim 10, Talwar teaches the method of claim 6, but does not explicitly disclose wherein the at least one policy causes the forwarding plane to configure an action list as a sequential service function chain in a data path.
Olofsson teaches forwarding a data packet at an applied network port through a service function chain. (Col. 5 line 20-37 — traffic on inbound ports apply inbound policy for a service chain based on matching action). This can be extended to action list of sequential service chains in a data path (Col. 5 lines 40 — Col. 6 line 9 - policy can also apply to requiring a sequence service chain, for example forwarding traffic through both a firewall service and an intrusion detection service )
It would have been obvious to one of ordinary skill in the art to have the service source/destination policy of Talwar include configuring for a sequential service function chain as in Olofsson. Talwar already teaches network policy for traffic in relation to cluster services. Accordingly, extending the benefits of Talwar to services in the form of sequential service function chains would have been obvious.
Claim 19 is similar in scope to claim 10 and is rejected based on the same rationale.
Conclusion
THIS ACTION IS MADE FINAL. 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 DAVID R LAZARO whose telephone number is (571)272-3986. The examiner can normally be reached M-F 8-4:30.
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, Emmanuel Moise can be reached at 571-272-3865. 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.
/DAVID R LAZARO/Primary Examiner, Art Unit 2455