DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 06 march, 2026 has been entered.
2. Claims 1-20 are pending. Claims 1, 11, and 20 are in independent forms. Claims 1, 11, and 20 has been amended.
Response to Amendment
3. Applicant’s arguments filed 02 February 2026 have been fully considered however they are moot due to new grounds of rejection below initiated by applicant’s amendment.
Drawings
4. The drawings filed on 12/14/2022 are accepted by the examiner.
Claim Rejections - 35 USC § 103
5. 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-3, 6-9, 11-12, 15-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Viswambharan et al. US Patent Application Publication No. 2020/0358802 (hereinafter Viswambharan) in view of Mir et al. US Patent Application Publication No. 2007/0294766 (hereinafter Mir) in view of Taft et al. US Patent Application Publication No. 2021/0392477 (hereinafter Taft).
Regarding claim 1, Viswambharan discloses a computer-implemented method for providing a threat aware service mesh, comprising:
“extending the threat aware service mesh to accept, in a control plane of the threat
aware service mesh, a plugin threat modeling management resource for managing threat model details to obtain an extended threat aware service mesh (see
Viswambharan pars. 0027, 0053-0054, A service mesh may be implemented using an array of network proxies alongside the containers. Each proxy, referred to as a “sidecar proxy”, serves as a gateway to interactions that occur between containers. A sidecar proxy assists in spreading (extending) compute load across the service mesh and directing a request to the appropriate downstream container that can serve the request. A central controller may orchestrate the connections in the service mesh, and a control plane may be configured to monitor the service traffic flowing between sidecar proxies. The control plane may deliver access control policies and collects performance metrics to be provided to the orchestrator. The control plane 310 may handle the control functions for the service mesh 302, as previously mentioned. For example, the control plane 310 may install and maintain policy and configuration on the service instances 328a-c (e.g., through respective sidecar proxies 324a-c). The control plane 310 may instructs the sidecar proxies 324a-c with dynamic updates to these policies and configurations in some examples. Accordingly, the control plane 310 may include different modules for carrying out these functions. For example, the control plane 310 may include a policy module 312 for defining and managing network policies, traffic policies, etc. The control plane 310 may also include a load balancer 314 for implementing load balancing schemes for balancing the traffic and workloads in the service mesh 302);
“assigning default not-allowed policies and only allowing access to restricted services for trust boundaries marked in the threat model of the extended threat aware service mesh” (see Viswambharan par. 0073, the sidecar proxy 324b is notified that the service instance B 328b has an identified vulnerability. The SVP 318 provides information such as the criticality score to the service instance B 328b. In some examples, the destination policy for the service instance B 328b may also be provided by the SVP 318. In some examples, the sidecar proxy 324b may already have the associated destination policy for service instance B 328b. The destination policy may define custom metrics or settings for the service instance B 328b that the sidecar proxy 324B watches. Examples of the settings include, for each of the criticality scores such as critical, high, medium, low, the associated level of impact. Additionally, the settings may also include, for each of the criticality scores, the count of the number of vulnerabilities tolerated for that score. Various other settings may be defined for each deployment of a service with different restrictions and rules. In some examples, the specific policies and criticality scores may be used for tripping circuit breakers of sidecar proxies);
Viswambharan does not explicitly discloses that devises a threat model from the threat model details by utilizing interfaces for the threat aware service mesh.
However, in analogues art, Mir discloses that devises a threat model from the threat model details by utilizing interfaces for the threat aware service mesh (see Mir pars. 0031-0032, Threat modeling application 120 may provide threat modeling interface 140. Interface 140 allows a user to enter business application information and view generated threats. Threat modeling application 120 is in communication with attack library 130. The attack library includes application attack data, vulnerability data, countermeasure data, relevancy data and relationships between attacks, core countermeasures, vulnerabilities and countermeasures. Threat modeling application 120 derives a threat model for a business application in part from the data of attack library 130).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Mir in to the system of Viswambharan in order to include a modeling system provides a user interface for configuring and viewing the threat model, and can access an attack library to develop a business application threat model (see Mir par 0005).
Viswambharan in view of Mir does not explicitly discloses automatically re-arranging a network policy from the threat model related to a given service with the extended threat aware service mesh responsive to a high severity vulnerability above a threshold and an associated threat probability being marked against the given service; performing a threshold based optimization of the network policy of the threat model by removing a particular service from a network policy allowed list responsive to one or more threats against the particular service at one of more different threat levels above a threshold.
However, in analogues art, Taft discloses automatically re-arranging a network policy from the threat model related to a given service with the extended threat aware service mesh responsive to a high severity vulnerability above a threshold and an associated threat probability being marked against the given service (see Taft par. 0095, malware detection and mitigation engine 750 may determine that a particular service mesh system 160 has exceeded a threshold (e.g., that the number of TCP connection in the particular service mesh system 160 has exceeded a threshold) and may isolate particular types of traffic from the particular service mesh system 160 to other service mesh systems 160. As another example, the ML model(s) used by malware detection and mitigation engine 750 may be trained to detect anomalies and used to detect zero-day attacks. Thus, malware detection and mitigation engine 750 may implement a global security policy that functions as a global security mesh for service mesh systems 160. Furthermore, a global security policy may be applied during deployment of new pods 246 by intercepting instructions from orchestration system 170 and applying a security policy to newly deployed NF containers 248 and/or service proxy containers 250. Based on the threat and associated risk, the policies applied to the different service meshes may be tailored to a particular service mesh and, therefore, policies applied using inter-mesh proxy 712-A in order to mitigate threats against service mesh system 160-A may be different from policies applied using inter-mesh proxy 712-B to service mesh system 160-B); performing a threshold based optimization of the network policy of the threat model by removing a particular service from a network policy allowed list responsive to one or more threats against the particular service at one of more different threat levels above a threshold (see Taft pars. 0104-0105, Process 900 may further include performing pattern analysis on the collected metrics (block 920) and detecting a security threat (block 930). For example, malware detection and mitigation engine 750 may use a trained ML model to identify a pattern associated with suspicious behavior, such as, for example, a new data pattern associated with a number of TCP connection requests that exceed a threshold. Process 900 may further include identifying service meshes associated with the detected security threat (block 940), updating a security policy based on the detected security threat (block 950), and instructing the identified service meshes to apply the updated security policy (block 960). As an example, malware detection and mitigation engine 750 may update a blacklist security policy to block packets that include the identified security threat from being sent using inter-mesh service 714. As another example, malware detection and mitigation engine 750 may select or isolate particular types of traffic from the particular service mesh system 160 to other service mesh systems 160. In response, inter-mesh manager 710 may instruct, via inter-mesh proxy 712, service mesh controller 210 to apply the updated security policy to traffic in the service mesh and/or to traffic to or from the service mesh to another service mesh.
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Taft in to the system of Viswambharan and Mir in order to include a malware detection and mitigation engine may select or isolate particular types of traffic from the particular service mesh system to other service mesh systems (see Taft par 0105).
Regarding claim 2, Viswambharan in view of Mir in further view of Taft discloses the computer-implemented method of claim 1,
Viswambharan further discloses wherein extending the threat aware service mesh further comprises configuring the threat aware service mesh to push threat model information received from the plugin threat modeling management resource to the control plane (see Viswambharan par. 0053, the control plane 310 may include different modules for carrying out these functions. For example, the control plane 310 may include a policy module 312 for defining and managing network policies, traffic policies, etc. The control plane 310 may also include a load balancer 314 for implementing load balancing schemes for balancing the traffic and workloads in the service mesh 302. One or more other modules which may be present in the control plane 310 are generically shown as the module 316, for performing the one or more control functions).
Regarding claims 3 and 12, Viswambharan in view of Mir in further view of Taft discloses the computer-implemented method of claim 1, the computer-implemented method of claim 11,
Viswambharan further discloses wherein assigning the default not-allowed policies further comprises automatically generating network policy restricting a first service from communicating with a second service responsive to the threat model details comprising only the first service being safe to communicate with the second service, and the second service being marked as a trust boundary (see Viswambharan par. 0073, The SVP 318 provides information such as the criticality score to the service instance B 328b. In some examples, the destination policy for the service instance B 328b may also be provided by the SVP 318. In some examples, the sidecar proxy 324b may already have the associated destination policy for service instance B 328b. The destination policy may define custom metrics or settings for the service instance B 328b that the sidecar proxy 324B watches. Examples of the settings include, for each of the criticality scores such as critical, high, medium, low, the associated level of impact. Additionally, the settings may also include, for each of the criticality scores, the count of the number of vulnerabilities tolerated for that score. Various other settings may be defined for each deployment of a service with different restrictions and rules. In some examples, the specific policies and criticality scores may be used for tripping circuit breakers of sidecar proxies).
Regarding claims 6 and 15, Viswambharan in view of Mir in further view of Taft discloses the computer-implemented method of claim 1, the computer-implemented method of claim 11,
Taft further discloses performing risk-based isolation in the threat aware service mesh (see Taft par. 0095, malware detection and mitigation engine 750 may determine that a particular service mesh system 160 has exceeded a threshold (e.g., that the number of TCP connection in the particular service mesh system 160 has exceeded a threshold) and may isolate particular types of traffic from the particular service mesh system 160 to other service mesh systems 160).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Taft in to the system of Viswambharan and Mir in order to include a malware detection and mitigation engine may select or isolate particular types of traffic from the particular service mesh system to other service mesh systems (see Taft par 0105).
Regarding claims 7 and 16, Viswambharan in view of Mir in further view of Taft discloses the computer-implemented method of claim 6, the computer-implemented method of claim 15,
Taft further discloses wherein the risk-based isolation imposes an isolation on one or more services responsive to one or more time limited risks (see Taft par. 0054, the control plane 310 may include a software vulnerability processor (SVP) 318 for handling the various functions related to identifying, isolating, and rectifying software vulnerabilities, for example. In one or more examples, the SVP 318 (or more generally, the control plane 310) may be in communication with a services catalog 320. The services catalog 320 may maintain a catalog of various details, such as the software versions, origin, release date, etc., for the software running in the various service instances 328a-c of the service mesh 302, for example. Accordingly in some examples, the services catalog 320 may contain an up to date mapping of the software (and version thereof) and the service instances 328a-c).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Taft in to the system of Viswambharan and Mir in order to include a malware detection and mitigation engine may select or isolate particular types of traffic from the particular service mesh system to other service mesh systems (see Taft par 0105).
Regarding claims 8 and 17, Viswambharan in view of Coffing in further view of Taft discloses the computer-implemented method of claim 1, the computer-implemented method of claim 11,
Taft further discloses wherein an application employing the threat aware service mesh comprises a first service, a second service, and a new third service for communicating with the first service and the second service, and wherein the threat aware service mesh isolates network policies common for all receiving services that receive traffic from the first service, and applies the second service to the new third service (see Taft par. 0095, malware detection and mitigation engine 750 may determine that a particular service mesh system 160 has exceeded a threshold (e.g., that the number of TCP connection in the particular service mesh system 160 has exceeded a threshold) and may isolate particular types of traffic from the particular service mesh system 160 to other service mesh systems 160. As another example, the ML model(s) used by malware detection and mitigation engine 750 may be trained to detect anomalies and used to detect zero-day attacks. Thus, malware detection and mitigation engine 750 may implement a global security policy that functions as a global security mesh for service mesh systems 160. Furthermore, a global security policy may be applied during deployment of new pods 246 by intercepting instructions from orchestration system 170 and applying a security policy to newly deployed NF containers 248 and/or service proxy containers 250. Based on the threat and associated risk, the policies applied to the different service meshes may be tailored to a particular service mesh and, therefore, policies applied using inter-mesh proxy 712-A in order to mitigate threats against service mesh system 160-A may be different from policies applied using inter-mesh proxy 712-B to service mesh system 160-B).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Taft in to the system of Viswambharan and Mir in order to include a malware detection and mitigation engine may select or isolate particular types of traffic from the particular service mesh system to other service mesh systems (see Taft par 0105).
Regarding claims 9 and 18, Viswambharan in view of Coffing in further view of Taft discloses the computer-implemented method of claim 1, the computer-implemented method of claim 11,
Taft further discloses the computer-implemented method of claim 1, further comprising performing rule-based automatic isolation for risky services having an associated risk level above a threshold (see Taft par. 0095, malware detection and mitigation engine 750 may determine that a particular service mesh system 160 has exceeded a threshold (e.g., that the number of TCP connection in the particular service mesh system 160 has exceeded a threshold) and may isolate particular types of traffic from the particular service mesh system 160 to other service mesh systems 160. Based on the threat and associated risk, the policies applied to the different service meshes may be tailored to a particular service mesh and, therefore, policies applied using inter-mesh proxy 712-A in order to mitigate threats against service mesh system 160-A may be different from policies applied using inter-mesh proxy 712-B to service mesh system 160-B).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Taft in to the system of Viswambharan and Mir in order to include a malware detection and mitigation engine may select or isolate particular types of traffic from the particular service mesh system to other service mesh systems (see Taft par 0105).
Regarding claim 11, Viswambharan discloses a computer-implemented method for providing a threat aware service mesh, comprising:
“extending the threat aware service mesh with a service mesh Application Programming Interface (API) and threat model management system in a control plane of the threat aware service mesh to obtain an extended threat aware service mesh ” (see
Viswambharan pars. 0027, 0053-0054, A service mesh may be implemented using an array of network proxies alongside the containers. Each proxy, referred to as a “sidecar proxy”, serves as a gateway to interactions that occur between containers. A sidecar proxy assists in spreading (extending) compute load across the service mesh and directing a request to the appropriate downstream container that can serve the request. A central controller may orchestrate the connections in the service mesh, and a control plane may be configured to monitor the service traffic flowing between sidecar proxies. The control plane may deliver access control policies and collects performance metrics to be provided to the orchestrator. The control plane 310 may handle the control functions for the service mesh 302, as previously mentioned. For example, the control plane 310 may install and maintain policy and configuration on the service instances 328a-c (e.g., through respective sidecar proxies 324a-c). The control plane 310 may instructs the sidecar proxies 324a-c with dynamic updates to these policies and configurations in some examples. Accordingly, the control plane 310 may include different modules for carrying out these functions. For example, the control plane 310 may include a policy module 312 for defining and managing network policies, traffic policies, etc. The control plane 310 may also include a load balancer 314 for implementing load balancing schemes for balancing the traffic and workloads in the service mesh 302);
“assigning default not-allowed policies and only allowing access to restricted services for trust boundaries marked in the threat model of the extended threat aware service mesh” (see Viswambharan par. 0073, the sidecar proxy 324b is notified that the service instance B 328b has an identified vulnerability. The SVP 318 provides information such as the criticality score to the service instance B 328b. In some examples, the destination policy for the service instance B 328b may also be provided by the SVP 318. In some examples, the sidecar proxy 324b may already have the associated destination policy for service instance B 328b. The destination policy may define custom metrics or settings for the service instance B 328b that the sidecar proxy 324B watches. Examples of the settings include, for each of the criticality scores such as critical, high, medium, low, the associated level of impact. Additionally, the settings may also include, for each of the criticality scores, the count of the number of vulnerabilities tolerated for that score. Various other settings may be defined for each deployment of a service with different restrictions and rules. In some examples, the specific policies and criticality scores may be used for tripping circuit breakers of sidecar proxies);
Viswambharan does not explicitly discloses that devises a threat model from the threat model details by utilizing interfaces for the threat aware service mesh.
However, in analogues art, Mir discloses that devises a threat model from the threat model details by utilizing interfaces for the threat aware service mesh (see Mir pars. 0031-0032, Threat modeling application 120 may provide threat modeling interface 140. Interface 140 allows a user to enter business application information and view generated threats. Threat modeling application 120 is in communication with attack library 130. The attack library includes application attack data, vulnerability data, countermeasure data, relevancy data and relationships between attacks, core countermeasures, vulnerabilities and countermeasures. Threat modeling application 120 derives a threat model for a business application in part from the data of attack library 130).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Mir in to the system of Viswambharan in order to include a modeling system provides a user interface for configuring and viewing the threat model, and can access an attack library to develop a business application threat model (see Mir par 0005).
Viswambharan in view of Coffing does not explicitly discloses automatically re-arranging a network policy from the threat model related to a given service with the extended threat aware service mesh responsive to a high severity vulnerability above a threshold and an associated threat probability being marked against the given service; performing a threshold based optimization of the network policy of the threat model by removing a particular service from a network policy allowed list responsive to one or more threats against the particular service at one of more different threat levels above a threshold.
However, in analogues art, Taft discloses automatically re-arranging a network policy from the threat model related to a given service with the extended threat aware service mesh responsive to a high severity vulnerability above a threshold and an associated threat probability being marked against the given service (see Taft par. 0095, malware detection and mitigation engine 750 may determine that a particular service mesh system 160 has exceeded a threshold (e.g., that the number of TCP connection in the particular service mesh system 160 has exceeded a threshold) and may isolate particular types of traffic from the particular service mesh system 160 to other service mesh systems 160. As another example, the ML model(s) used by malware detection and mitigation engine 750 may be trained to detect anomalies and used to detect zero-day attacks. Thus, malware detection and mitigation engine 750 may implement a global security policy that functions as a global security mesh for service mesh systems 160. Furthermore, a global security policy may be applied during deployment of new pods 246 by intercepting instructions from orchestration system 170 and applying a security policy to newly deployed NF containers 248 and/or service proxy containers 250. Based on the threat and associated risk, the policies applied to the different service meshes may be tailored to a particular service mesh and, therefore, policies applied using inter-mesh proxy 712-A in order to mitigate threats against service mesh system 160-A may be different from policies applied using inter-mesh proxy 712-B to service mesh system 160-B); performing a threshold based optimization of the network policy of the threat model by removing a particular service from a network policy allowed list responsive to one or more threats against the particular service at one of more different threat levels above a threshold (see Taft pars. 0104-0105, Process 900 may further include performing pattern analysis on the collected metrics (block 920) and detecting a security threat (block 930). For example, malware detection and mitigation engine 750 may use a trained ML model to identify a pattern associated with suspicious behavior, such as, for example, a new data pattern associated with a number of TCP connection requests that exceed a threshold. Process 900 may further include identifying service meshes associated with the detected security threat (block 940), updating a security policy based on the detected security threat (block 950), and instructing the identified service meshes to apply the updated security policy (block 960). As an example, malware detection and mitigation engine 750 may update a blacklist security policy to block packets that include the identified security threat from being sent using inter-mesh service 714. As another example, malware detection and mitigation engine 750 may select or isolate particular types of traffic from the particular service mesh system 160 to other service mesh systems 160. In response, inter-mesh manager 710 may instruct, via inter-mesh proxy 712, service mesh controller 210 to apply the updated security policy to traffic in the service mesh and/or to traffic to or from the service mesh to another service mesh.
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Taft in to the system of Viswambharan and Mir in order to include a malware detection and mitigation engine may select or isolate particular types of traffic from the particular service mesh system to other service mesh systems (see Taft par 0105).
Regarding claim 20, Viswambharan discloses a computer program product for providing a threat aware service mesh, the computer program product comprising a non-transitory computer readable storage medium (Fig. 6 Memory 606) having program instructions embodied therewith, the program instructions executable by a computer (Fig. 6, CPU 604) to cause the computer to perform a method comprising:
“extending, by a hardware processor of the computer, the threat aware service mesh to accept, in a control plane of the threat aware service mesh, a plugin threat modeling management resource for managing threat model details to obtain an extended threat aware service mesh ” (see Viswambharan pars. 0027, 0053-0054, A service mesh may be implemented using an array of network proxies alongside the containers. Each proxy, referred to as a “sidecar proxy”, serves as a gateway to interactions that occur between containers. A sidecar proxy assists in spreading (extending) compute load across the service mesh and directing a request to the appropriate downstream container that can serve the request. A central controller may orchestrate the connections in the service mesh, and a control plane may be configured to monitor the service traffic flowing between sidecar proxies. The control plane may deliver access control policies and collects performance metrics to be provided to the orchestrator. The control plane 310 may handle the control functions for the service mesh 302, as previously mentioned. For example, the control plane 310 may install and maintain policy and configuration on the service instances 328a-c (e.g., through respective sidecar proxies 324a-c). The control plane 310 may instructs the sidecar proxies 324a-c with dynamic updates to these policies and configurations in some examples. Accordingly, the control plane 310 may include different modules for carrying out these functions. For example, the control plane 310 may include a policy module 312 for defining and managing network policies, traffic policies, etc. The control plane 310 may also include a load balancer 314 for implementing load balancing schemes for balancing the traffic and workloads in the service mesh 302);
“assigning, by the hardware processor, default not-allowed policies and only allowing access to restricted services for trust boundaries marked in the threat model of the extended threat aware service mesh” (see Viswambharan par. 0073, the sidecar proxy 324b is notified that the service instance B 328b has an identified vulnerability. The SVP 318 provides information such as the criticality score to the service instance B 328b. In some examples, the destination policy for the service instance B 328b may also be provided by the SVP 318. In some examples, the sidecar proxy 324b may already have the associated destination policy for service instance B 328b. The destination policy may define custom metrics or settings for the service instance B 328b that the sidecar proxy 324B watches. Examples of the settings include, for each of the criticality scores such as critical, high, medium, low, the associated level of impact. Additionally, the settings may also include, for each of the criticality scores, the count of the number of vulnerabilities tolerated for that score. Various other settings may be defined for each deployment of a service with different restrictions and rules. In some examples, the specific policies and criticality scores may be used for tripping circuit breakers of sidecar proxies);
Viswambharan does not explicitly discloses that devises a threat model from the threat model details by utilizing interfaces for the threat aware service mesh.
However, in analogues art, Mir discloses that devises a threat model from the threat model details by utilizing interfaces for the threat aware service mesh (see Mir pars. 0031-0032, Threat modeling application 120 may provide threat modeling interface 140. Interface 140 allows a user to enter business application information and view generated threats. Threat modeling application 120 is in communication with attack library 130. The attack library includes application attack data, vulnerability data, countermeasure data, relevancy data and relationships between attacks, core countermeasures, vulnerabilities and countermeasures. Threat modeling application 120 derives a threat model for a business application in part from the data of attack library 130).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Mir in to the system of Viswambharan in order to include a modeling system provides a user interface for configuring and viewing the threat model, and can access an attack library to develop a business application threat model (see Mir par 0005).
Viswambharan in view of Mir does not explicitly discloses automatically re-arranging, by the hardware processor, a network policy from the threat model related to a given service with the extended threat aware service mesh responsive to a high severity vulnerability above a threshold and an associated threat probability being marked against the given service; performing, by the hardware processor, a threshold based optimization of the network policy of the threat model by removing a particular service from a network policy allowed list responsive to one or more threats against the particular service at one of more different threat levels above a threshold.
However, in analogues art, Taft discloses automatically re-arranging, by the hardware processor, a network policy related to a given service with the extended threat aware service mesh responsive to a high severity vulnerability above a threshold and an associated threat probability being marked against the given service (see Taft par. 0095, malware detection and mitigation engine 750 may determine that a particular service mesh system 160 has exceeded a threshold (e.g., that the number of TCP connection in the particular service mesh system 160 has exceeded a threshold) and may isolate particular types of traffic from the particular service mesh system 160 to other service mesh systems 160. As another example, the ML model(s) used by malware detection and mitigation engine 750 may be trained to detect anomalies and used to detect zero-day attacks. Thus, malware detection and mitigation engine 750 may implement a global security policy that functions as a global security mesh for service mesh systems 160. Furthermore, a global security policy may be applied during deployment of new pods 246 by intercepting instructions from orchestration system 170 and applying a security policy to newly deployed NF containers 248 and/or service proxy containers 250. Based on the threat and associated risk, the policies applied to the different service meshes may be tailored to a particular service mesh and, therefore, policies applied using inter-mesh proxy 712-A in order to mitigate threats against service mesh system 160-A may be different from policies applied using inter-mesh proxy 712-B to service mesh system 160-B); performing, by the hardware processor, a threshold based optimization of removing a particular service from a network policy allowed list responsive to one or more threats against the particular service at one of more different threat levels above a threshold (see Taft pars. 0104-0105, Process 900 may further include performing pattern analysis on the collected metrics (block 920) and detecting a security threat (block 930). For example, malware detection and mitigation engine 750 may use a trained ML model to identify a pattern associated with suspicious behavior, such as, for example, a new data pattern associated with a number of TCP connection requests that exceed a threshold. Process 900 may further include identifying service meshes associated with the detected security threat (block 940), updating a security policy based on the detected security threat (block 950), and instructing the identified service meshes to apply the updated security policy (block 960). As an example, malware detection and mitigation engine 750 may update a blacklist security policy to block packets that include the identified security threat from being sent using inter-mesh service 714. As another example, malware detection and mitigation engine 750 may select or isolate particular types of traffic from the particular service mesh system 160 to other service mesh systems 160. In response, inter-mesh manager 710 may instruct, via inter-mesh proxy 712, service mesh controller 210 to apply the updated security policy to traffic in the service mesh and/or to traffic to or from the service mesh to another service mesh.
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Taft in to the system of Viswambharan and Mir in order to include a malware detection and mitigation engine may select or isolate particular types of traffic from the particular service mesh system to other service mesh systems (see Taft par 0105).
7. Claims 4-5 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Viswambharan et al. US Patent Application Publication No. 2020/0358802 (hereinafter Viswambharan) in view of Mir et al. US Patent Application Publication No. 2007/0294766 (hereinafter Mir) in further view of Taft et al. US Patent Application Publication No. 2021/0392477 (hereinafter Taft) in further view of Coffing US . Patent Application Publication No. 2019/0273746 (hereinafter Coffing).
Regarding claims 4 and 13, Viswambharan in view of Mir in further view of Taft discloses the computer-implemented method of claim 1, the computer-implemented method of claim 11,
Viswambharan in view of Mir in further view of Taft does not explicitly discloses enabling mutual Transport Layer Security between a first service and a second service responsive to a data flow being marked between the first service and the second service.
However, in analogues art, Coffing discloses enabling mutual Transport Layer Security between a first service and a second service responsive to a data flow being marked between the first service and the second service (see Coffing par. 0023, Application development teams may therefore be freed to focus on product-specific functionality, as the microgateway handles security requirements such as user authentication, service authentication, dynamic authorization, access delegation and credentials exchange (e.g., OAuth, SAML, OIDC), transaction throttling, TLS and secret offload, brute-force protection, service discovery, service configuration, canary routing, and distributed PDP/PEP. As such, a combination of user and microservice identities allows for application of effective security controls at the end-service level, as well as at each microservice level that is part of the mesh).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Coffing in to the system of Viswambharan, Mir, and Taft in order to include proxies may be extended with a plugin that calls security sidecar to validate and transform requests (see Coffing par 0031).
Regarding claims 5 and 14, Viswambharan in view of Mir in further view of Taft discloses the computer-implemented method of claim 1, the computer-implemented method of claim 11,
Viswambharan in view of Mir in further view of Taft does not explicitly discloses extending default policies of the threat aware service mesh by considering the threat model details (see Coffing pars. 0031-0032, Security sidecar 160 allows in-place validation of policies (enforcement and decisions) for incoming requests and transformation of outgoing requests. In certain default scenarios, security sidecar 160 may validate if incoming requests were signed using a key generated by internal CA and inject a token (JWT)-signed using a private key of a microservice).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Coffing in to the system of Viswambharan, Mir, and Taft in order to include proxies may be extended with a plugin that calls security sidecar to validate and transform requests (see Coffing par 0031).
8. Claims 10 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Viswambharan et al. US Patent Application Publication No. 2020/0358802 (hereinafter Viswambharan) in view of Mir et al. US Patent Application Publication No. 2007/0294766 (hereinafter Mir) in further view of Taft et al. US Patent Application Publication No. 2021/0392477 (hereinafter Taft) in further view of Kumar et al. US . Patent Application Publication No. 2013/0298192 (hereinafter Kumar).
Regarding claims 10 and 19, Viswambharan in view of Mir in further view of Taft discloses the computer-implemented method of claim 1, the computer-implemented method of claim 11,
Viswambharan in view of Mir in further view of Taft does not explicitly discloses maintaining a threat model for the threat aware service mesh that comprises, for each of a plurality of services, a service name, threat details, a remediation plan, risk details, and trust boundary details.
However, in analogues art, Kumar discloses maintaining a threat model for the threat aware service mesh that comprises, for each of a plurality of services, a service name, threat details, a remediation plan, risk details, and trust boundary details (see Kumar pars. 0140-0142, According to the embodiments of FIGS. 4 and 8, the trust orchestrator 430 is an aggregation that includes functional components such as the trust broker 407, system event correlator 410, the trust supervisor 846, and remediation controller 848. In embodiments, the trust orchestrator 430 is configured to receive sensory threat intelligence from network analyzers 830, endpoint assessment services 820 and endpoint trust agents 510 on devices 560. Through a sequence of normalization, collation and risk correlation of events, directives 849 in the form of directives are dispatched to orchestration services to initiate remediation actions to deal with identified threats on devices 560).
Therefore it would have been obvious to a person of ordinary skill in the art before the effective filing date of the application to incorporate the teachings of Kumar in to the system of Viswambharan, Mir, and Taft in order to analyze and classify threats along with a forensic confidence score, sends real time actions to the remediation controller, and real time status indications to a dashboard controller. The remediation controller sends directives to orchestration and/or policy enforcement point services for machine, flow or transaction level remediation (see Kumar par 0142).
Conclusion
9. Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMUEL AMBAYE whose telephone number is (571)270-7635. The examiner can normally be reached M-F 9:00 AM - 6:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Pwu can be reached at (571) 272-6798. 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.
/SAMUEL AMBAYE/Examiner, Art Unit 2433
/JEFFREY C PWU/Supervisory Patent Examiner, Art Unit 2433