DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
2. 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 January 15, 2026 has been entered.
Response to Amendment
3. Claims 1, 19 and 20 have been amended. Claims 1-20 were presented for examination.
Response to Arguments
4. Applicant's arguments, see pages 6-8, filed on January 15, 2026, with respect to the rejection(s) of independent claims 1, 19 and 20 have been fully considered but are moot in view of the new grounds of rejection. The amended claims do not overcome the new ground of rejection made in view of newly found prior art references.
5. Applicant's arguments, see pages 6-8, filed on January 15, 2026, with respect to the rejection(s) of claims 2-18 have been fully considered but are moot in view of the new grounds of rejection. The claims do not overcome the new ground of rejection made in view of newly found prior art references.
Claim Objections
6. Claim 1 is objected to because of the following informality:
Claim 1 recites “a processor; and memory coupled to the processor…” should read “a processor; and a memory coupled to the processor…”.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
7. 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.
8. 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.
9. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
10. Claims 1-5, 7, 8, 10, 11, 13, 14, 16, 19 and 20 are rejected under 35 U.S.C. § 103 as being unpatentable over Baker et al. (US 2022/0255854 A1), hereafter Baker, in view of Eyada (US 11,729,146 B1), hereafter Eyada.
Regarding claim 1, Baker teaches a computer system comprising: a processor; and memory coupled to the processor and storing instructions that, when executed by the processor, are configurable to cause the computer system to: {Baker [Para. 0220, FIG. 21] “Computer system 2100 includes a processing unit 2104 that communicates with a number of peripheral subsystems via a bus subsystem 2102. These peripheral subsystems may include…a storage subsystem 2118...” [Para. 0227] “Computer system 2100 may comprise a storage subsystem 2118 that comprises software elements… System memory 2110 may store program instructions that are loadable and executable on processing unit 2104.”}
generate a data packet within a first functional domain; {Baker [Para. 0031] “When a compute instance generates and sends a packet addressed to a destination (egress or outbound traffic), the corresponding packet flow rule is used to determine whether the flow of the packet falls within the permitted network boundary(ies).” [Para. 0155] “In operation, the compute instance 1212 sends a packet that includes a header 1214 and a payload 1216. The packet is sent over the link from the host machine 1210 to the NVD (network virtualization device) 1220. The NVD 1220 determines, from the header 1214, that this packet is sent from the compute instance 1212.”} As indicated in paras. 0031, 0155 and 0162 in Baker, a source compute instance generates a packet.
determine whether the data packet is destined for a second functional domain; {Baker [Para. 0155] “The NVD 1220 also determines from the packet flow rule 1224 the permitted network boundary(ies) and/or prohibited network boundary(ies) for the flow of the packet from the compute instance 1212.” [Para. 0162] “At operation 1308, the network virtualization device determines whether the flow of the packet is permitted or prohibited. For instance, using mapping tables, routing tables, and/or other configuration information of a substrate network and/or virtual network, the network virtualization device determines whether a destination of the packet is within a permitted boundary. The destination may be the addressed destination in the packet or a next hop destination.”} As indicated in paras. 0155, 0157 and 0162, Baker’s system determines whether a destination of a packet falls within the permitted network boundaries.
and in response to determining that the data packet is destined for the second functional domain: encapsulate the data packet within a header comprising a fully qualified security group (FQSG) field associated with one or more cloud native security groups, {Baker [Para. 0155, Fig. 8] “If the flow is permitted, the NVD 1220 generates scoping data indicating the scope of the flow… The scoping data is included in an updated header 1226 of the packet. The NVD 1220 outputs the packet with the updated header 1226 and the payload 1216 onto a substrate network, whereby the updated header 1226 further includes encapsulation data for sending the packet through the substrate network. In FIG. 12, the updated header 1126 includes an overlay header 1227 and a scoping field 1229. The overlay header 1227 includes the encapsulation data.”} As indicated in paras. 0145, 0155, 0157 and 0162, an NVD generates scoping data based on a packet flow rule defined for the source compute instance. Scoping data defines the packet flow from a source compute instance, establishing the network boundaries within which traffic is permitted or prohibited. Therefore, scoping field 1229 corresponds to the security group (FQSG) field.
the FOSG field included within the header that wraps the data packet and carrying identity and security policy context to enable security enforcement at the second functional domain; {Baker [Para. 0146] “The scoping data 830 is included as a field in the header 810, where this field indicates network boundary identifier(s) 832 and permission(s) /prohibitions 834 related to the network boundary identifier(s) 832. For instance, the field can be a byte long. A first bit (e.g., the most significant bit) can indicate whether the packet structure 800 supports or includes scoping data (e.g., set to “1” to indicate the support and to “0” otherwise). The remaining seven bits can be used to indicate the permitted network boundaries.” [Para. 0031] “For ingress or inbound traffic, when a packet is addressed to the compute instance, a network virtualization device or a function hosted thereat can receive and process this packet to determine the scoping data and enforce the corresponding packet flow depending on whether the compute instance belongs to a permitted network boundary.”} Para. 0164 details how the destination compute instance uses scoping data to process received packets. Scoping data includes a network boundary identifier and establishes the limits within which traffic is permitted or prohibited.
and send the encapsulated data packet to the second functional domain, {Baker [Para. 0157] “The compute instance 1212 sends a packet destined to a compute instance within the VCN. The NVD 1220 receives and determines, using a VCN mapping table, that a destination tunnel endpoint is within the permitted network boundary. Accordingly, the NVD 1220 adds the scoping data and other encapsulation data to the packet and sends the packet forward.”} Also see para. 0162.
However, Baker does no teach wherein the first functional domain is a group of functions and/or processes that are separate and distinct from functions and/or processes of the second functional domain.
However, Eyada teaches wherein the first functional domain is a group of functions and/or processes that are separate and distinct from functions and/or processes of the second functional domain. {Eyada [Col. 5, lines 51-62] “The security policy allowing web server instances 220A-220K to communicate to database server instances 230A-230M listening on TCP port 3306, while preventing any other communications within the VPC 120 may be implemented by creating two security groups, referred herein as “web security group” (WSG) 302 and “database security group” (DSG) 304.” [Col. 7, lines 3-12] “The web server instances 220A-220K and the database server instances 230A-230N reside within the same VPC 120, in another illustrative example, the above-described security policies WSG and DSG may be implemented for web server instances 220A-220K residing within one VPC and database server instances 230A-230N residing within another VPC.”} A web server instance and a database server instance are considered distinct functional domains. Functions perform by a web server instance include receiving HTTP/HTTPS request from clients and delivering web content. Functions performed by a database server instance include data storage/retrieval, security and recovery.
Eyada is analogous art because each of Baker and Eyada pertains to securing communications between a source node and a destination node in a cloud network. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baker to include Eyada’s teaching of two functional domains, wherein the first functional domain is a group of functions and/or processes that are separate and distinct from functions and/or processes of the second functional domain. Doing so would “improve the security and scalability of virtual private clouds” (Eyada, Col. 2, lines 54-60).
Claim 2:
Regarding claim 2, Baker and Eyada teach the elements of claim 1 as stated.
Baker further teaches wherein the first functional domain and the second functional domain are within a common functional instance. {Baker [Para. 0069] “The customer may deploy various compute instances on VCN 104, where the compute instances may include virtual machines or bare metal instances. Examples of instances include applications, database, load balancers, and the like.” [Para. 0075] “Communications between compute instances on the same subnet are facilitated using VNICs associated with the source compute instance and the destination compute instance. For example, compute instance C1 in Subnet-1 may want to send packets to compute instance C2 in Subnet-1.”} As indicated in Baker, a source compute instance may send data packets to another compute instance in the same subnet in a VCN. Additionally, Eyada also teaches claim (see col. 7, lines 3-12).
Claim 3:
Regarding claim 3, Baker and Eyada teach the elements of claim 1 as stated.
Keane further teaches wherein the FQSG field comprises a unique identifier. {Baker [Para. 0146, Fig. 8] “In an example, the scoping data 830 is included as a field in the header 810, where this field indicates network boundary identifier(s) 832 and permission(s) /prohibitions 834 related to the network boundary identifier(s) 832. For instance, the field can be a byte long. A first bit (e.g., the most significant bit) can indicate whether the packet structure 800 supports or includes scoping data (e.g., set to “1” to indicate the support and to “0” otherwise). The remaining seven bits can be used to indicate the permitted network boundaries.”}
Claim 4:
Regarding claim 4, Baker and Eyada teach the elements of claim 1 as stated.
Baker further teaches wherein the encapsulated data packet is sent to the second functional domain via an overlay tunnel. {Baker [Para. 0038] “The virtual or overlay networks can include one or more virtual cloud networks (VCNs)…. Examples of protocols developed for virtual networks include IP-in-IP (or Generic Routing Encapsulation (GRE)), Virtual Extensible LAN (VXLAN—IETF RFC 7348), Virtual Private Networks (VPNs) (e.g., MPLS Layer-3 Virtual Private Networks (RFC 4364)), VMware's NSX, GENEVE (Generic Network Virtualization Encapsulation), and others.”}
Claim 5:
Regarding claim 5, Baker teaches the elements of claim 4 as outlined above.
Baker further teaches wherein the overlay tunnel comprises user datagram protocol (UDP) or transmission control protocol (TCP). {Baker [Para. 0079] “To enable such communications, a communication channel 124 is set up where one endpoint of the channel is in customer on-premise network 116 and the other endpoint is in CSPI 101 and connected to customer VCN 104. Communication channel 124 can be over public communication networks such as the Internet or private communication networks. Various different communication protocols may be used such as IPsec VPN technology over a public communication network such as the Internet, Oracle's FastConnect technology that uses a private network instead of a public network, and others.”} Also see para. 0079 in Baker. An VXLAN utilize UDP for encapsulation. IPSec VPN also utilizes UDP.
Claim 7:
Regarding claim 7, Baker and Eyada teach the elements of claim 1 as stated.
However, Baker further teaches wherein the first functional domain is a source domain having a first Internet protocol (IP) subnet, and wherein the second functional domain is a destination domain having a second IP subnet. {Baker [Para. 0070] “Customer VCN 104 comprises two subnets, namely, “Subnet-1” and “Subnet-2”, each subnet with its own CIDR (Classless Inter-Domain Routing) IP address range. In FIG. 1, the overlay IP address range for Subnet-1 is 10.0/16 and the address range for Subnet-2 is 10.1/16.” [Para. 0076] “For a packet to be communicated from a compute instance in a subnet to an endpoint in a different subnet in the same VCN, the communication is facilitated by the VNICs associated with the source and destination compute instances and the VCN VR (virtual router).”}
Claim 8:
Regarding claim 8, Baker teaches the elements of claim 7 as outlined above.
Baker further teaches wherein the first IP subnet and second IP subnet do not overlap. {Baker [Para. 0056] “A VCN (virtual cloud network) can be subdivided into one or more sub-networks such as one or more subnets. A subnet is thus a unit of configuration or a subdivision that can be created within a VCN. A VCN can have one or multiple subnets. Each subnet within a VCN is associated with a contiguous range of overlay IP addresses (e.g., 10.0.0.0/24 and 10.0.1.0/24) that do not overlap with other subnets in that VCN and which represent an address space subset within the address space of the VCN.”} Also see para. 0058 in Baker.
Claim 10:
Regarding claim 10, Baker and Eyada teach the elements of claim 1 as stated.
Baker further teaches wherein the FQSG field is associated with an FQSG policy comprising a plurality of parameters. {Baker [Para. 0150] “The control plane sends the customer data 1030 to the NVD 1020 indicating the network boundary and the compute instance(s) to which the customer data 1030 applies. In turn, the NVD 1020 determines the affected compute instance(s). For each affected compute instance, the NVD 1020 generates a packet flow rule 1024 indicating the permitted network boundary and/or a prohibited network boundary. For instance the packet flow rule 1024 identifies a network boundary and the permission or prohibition related thereto… In addition, each packet flow rule can indicate multiple permitted network boundaries and/or multiple prohibited network boundaries.” [Para. 0147] “At operation 904, adding scoping data to a packet generated by a compute instance based on a packet flow rule defined for the compute instance.”} Also see paras. 0091, 0142 and 0153 in Baker for additional examples of parameters included in the security or packet flow rules for a compute instance.
Claim 11:
Regarding claim 11, Baker teaches the elements of claim 10 as outlined above.
Baker further teaches wherein a parameter from the plurality of parameters in the FQSG policy is a destination parameter associated with the second functional domain. {Baker [Para. 0156] “Consider a first example, where the compute instance 1212 is within a VCN of the customer, and where the packet flow rule 1224 permits the flow of packets from the compute instance 1212 to any other compute instance within the VCN only. In this example, the compute instance 1212 sends a packet destined to a compute instance within the VCN.” [Para. 0142] “A packet flow rule can be defined per compute instance of the VCN. For instance, a first packet flow rule can be generated for a compute instance of a VCN to indicate that packets sent from the compute instance can cross a certain network boundary (e.g., the compute instance can send packets to a compute instance in a peered VCN).”} Additionally, Eyada also teaches claim 11, see col. 10 lines 32-42.
Claim 13:
Regarding claim 13, Baker teaches the elements of claim 11 as outlined above.
However, Baker does not explicitly teach wherein the destination parameter identifies a functional instance associated with the second functional domain.
However, Eyada teaches wherein the destination parameter identifies a functional instance associated with the second functional domain. {Eyada [Col. 10, lines 43-49] “At block 620, the firewall management service may create a first security group to be associated with for the cloud resource instances labeled by the destination tag.” [Col. 10, lines 50-56] “At block 630, the firewall management service may create a second security group to be associated with for the cloud resource instances labeled by the source tag. The security group definition may include an outbound firewall rule specifying a destination communication endpoint identifier, a transport layer protocol identifier, and a port identifier, as described in more detail herein above.” [Col. lines 61-64] “At block 650, the firewall management service may substitute, in the outbound firewall rule associated with the second security group, the destination communication endpoint identifier with the identifier of the first security group.” [Col. 10 lines 65-67] “At block 660, the firewall management service may associate, with the first security group, one or more cloud resource instances labeled by the destination tag.“}
Eyada is analogous art because each of Keane and Eyada pertains to securing communications between a source node and a destination node in a cloud network. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baker to include Eyada’s teaching of a destination parameter that identifies a functional instance associated with a second functional domain. Doing so would “improve the security and scalability of virtual private clouds” (Eyada, Col. 2, lines 54-60).
Claim 14:
Regarding claim 14, Baker teaches the elements of claim 10 as outlined above.
However, Baker does not explicitly teach wherein a parameter from the plurality of parameters in the FQSG policy is a source parameter associated with the first functional domain.
However, Eyada teaches wherein a parameter from the plurality of parameters in the FQSG policy is a source parameter associated with the first functional domain. {Eyada [Col. 10, lines 43-49] “At block 620, the firewall management service may create a first security group to be associated with for the cloud resource instances labeled by the destination tag. The security group definition may include an inbound firewall rule specifying a source communication endpoint identifier, a transport layer protocol identifier, and a port identifier, as described in more detail herein above.” [Col. 10, lines 50-56] “At block 630, the firewall management service may create a second security group to be associated with for the cloud resource instances labeled by the source tag.”} The inbound firewall rule specifies a source endpoint identifier, which corresponds to the source parameter.
Eyada is analogous art because each of Baker and Eyada pertains to securing communications between a source node and a destination node in a cloud network. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baker to include Eyada’s teaching of a source parameter in a FQSG policy that is associated with the first functional domain. Doing so would “improve the security and scalability of virtual private clouds” (Eyada, Col. 2, lines 54-60).
Claim 16:
Regarding claim 16, Eyada teaches the elements of claim 14 as outlined above.
However, Baker does not explicitly teach wherein the source parameter identifies a functional instance associated with the first functional domain.
However, Eyada teaches wherein the source parameter identifies a functional instance associated with the first functional domain. {Eyada [Col. 10, lines 43-49] “At block 620, the firewall management service may create a first security group to be associated with for the cloud resource instances labeled by the destination tag. The security group definition may include an inbound firewall rule specifying a source communication endpoint identifier, a transport layer protocol identifier, and a port identifier, as described in more detail herein above.” [Col. 10, lines 50-56] “At block 630, the firewall management service may create a second security group to be associated with for the cloud resource instances labeled by the source tag.” [Col. 10, lines 57-60] “At block 640, the firewall management service may substitute, in the inbound firewall rule associated with the first security group, the source communication endpoint identifier with the identifier of the second security group.” [Col. 11, lines 6-14] “At block 670, the firewall management service may associate, with the second security group, one or more cloud resource instances labeled by the source tag.”}
Eyada is analogous art because each of Baker and Eyada pertains to establishing secure communications between a source node and a destination node in a cloud network. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baker to include Eyada’s teaching of a source parameter that identifies a functional instance associated with a first functional domain. Doing so would “improve the security and scalability of virtual private clouds” (Eyada, Col. 2, lines 54-60).
Claim 19:
Regarding claim 19, the claim is directed to a tangible, non-transitory computer-readable medium storing instructions that, when executed by a computer system, cause the computer system to implement the operations recited by claim 1. Therefore, the rejection applied to claim 1 also applies to claim 19. Claim 1 is rejected under the same rationale as claim 19.
Claim 19 further recites a tangible, non-transitory computer-readable medium storing instructions that, when executed by a computer system, are configurable to cause the computer system to implement the operations recited by claim 1. {Baker [Para. 0220] “System 2100 includes a processing unit 2104.” [Para. 0229] “Storage subsystem 2118 may also provide a tangible computer-readable storage medium for storing the basic programming and data constructs... Software (programs, code modules, instructions) that, when executed by a processor, provides the functionality described above may be stored in storage subsystem 2118. These software modules or instructions may be executed by processing unit 2104.”}
Claim 20:
Regarding claim 20, the claim is directed to a method comprising the operations recited by claim 1. Therefore, the rejection applied to claim 1 also applies to claim 20. Claim 1 is rejected under the same rationale as claim 20.
Claim 20 further recites a method comprising: the operations recited by claim 1. {Baker [Para. 0154] “FIG. 12 illustrates an example of a system for generating a packet that includes data indicating a packet flow rule.”}
11. Claims 9, 12 and 15 are rejected under 35 U.S.C. § 103 as being unpatentable over Baker and Eyada as applied to claims 1, 7, 10, 11 and 14, and further in view of Nguyen (US 20210136118 A1), hereafter Nguyen.
Regarding claim 9, Baker teaches the elements of claim 7 as outlined above.
However, Baker and Eyada do not teach wherein the first IP subnet and the second IP subnet at least partially overlap.
However, Nguyen teaches wherein the first IP subnet and the second IP subnet at least partially overlap. {Nguyen [Para. 0044] “The network security language processor 205 generates permitted connections structures S1 and S2 corresponding to the network security specifications.” [Para. 0049] “To identify corresponding trees in two permitted connections structures S1 and S2, the comparison module 220 compares the subnetworks of the root nodes of the trees from the two structures. Tree T1 matches tree T2 if the subnetworks of their root nodes are identical, for example, if both subnetworks represent the same IP range. The tree T1 may also match tree T2 if the subnetwork of the root node of T2 is a superset of the subnetwork of the root of T1. A subnetwork representing an IP range I1 is a superset of another subnetwork representing IP range I2 if I2 is a subrange of I1.” [Para. 0050] “If there is no tree T2 corresponding to tree T1 such their corresponding root nodes have subnetworks that have exact match or subset relationship, the comparison module 220 identifies a tree T2 such that the root nodes of T1 and T2 have overlapping subnetworks.”} Nguyen teaches IP subnetworks that overlap.
Nguyen is analogous art because each of Baker, Eyada and Nguyen pertains to implementing security policies to secure communications between a source node and a destination node in a computer network. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baker and Eyada to include Nguyen’s teaching of two IP subnets that overlap. Doing so would allow a system to “identify discrepancies between the two network security specifications” (Nguyen, para. 0014) specified using different network security languages.
Claim 12:
Regarding claim 12, Baker teaches the elements of claim 11 as outlined above.
However, Baker and Eyada do not teach wherein the destination parameter identifies a service associated with the second functional domain.
However, Nguyen teaches wherein the destination parameter identifies a service associated with the second functional domain. {Nguyen [Para. 0022] “Following is another example of a network security specification using a different network security language that allows users to specify service groups and permitted connections between service groups.”
network_security_Rule Rule2 {
source_service_group: service1 service2 service3
destination_service_group: service4 service5
connection:
protocol: tcp port: 80 protocol: UDP port: 443 }
[Para. 0023] “The example network security specification shown above specifies a network security rule Rule2 that specifies fields including (1) a source service group, (2) a destination service group, and (3) one or more connections between the source service group and the destination service group. Each of the source service group and destination service group fields specify a list of services. The specification may further include information identifying an IP list corresponding to each service.”} See paras. 0020 to 0021 for additional examples of network security specification disclosed in Nguyen. Network security rule (e.g., Rule2) has a destination service group field that identifies a service in the destination service group. In this regard, the destination service group field corresponds to the destination parameter that identifies a service associated with the second functional domain.
Nguyen is analogous art because each of Baker, Eyada and Nguyen pertains to implementing security policies to secure communications between a source node and a destination node in a computer network. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baker and Eyada to include Nguyen’s teaching of a destination parameter that identifies a service associated with a second functional domain. Doing so would “identify discrepancies between the two network security specifications” (Nguyen, para. 14) specified using different network security languages.
Claim 15:
Regarding claim 15, Eyada teaches the elements of claim 14 as outlined above.
However, Baker and Eyada do not teach wherein the source parameter identifies a service associated with the first functional domain.
However, Nguyen teaches wherein the source parameter identifies a service associated with the first functional domain. {Nguyen [Para. 0022]
“network_security_Rule Rule2 {
source_service_group: service1 service2 service3
destination_service_group: service4 service5
connection:
protocol: tcp port: 80 protocol: UDP port: 443 }
[Para. 0023] “The example network security specification shown above specifies a network security rule Rule2 that specifies fields including (1) a source service group, (2) a destination service group, and (3) one or more connections between the source service group and the destination service group. Each of the source service group and destination service group fields specify a list of services. The specification may further include information identifying an IP list corresponding to each service.”} See paras. 0020 to 0021 for additional examples of network security specification disclosed in Nguyen. Network security rule (e.g., Rule2) has a source service group field that identifies a service in the source service group. In this regard, the source service group field corresponds to the source parameter that identifies a service associated with the first functional domain.
Nguyen is analogous art because each of Baker, Eyada and Nguyen pertains to implementing security policies to secure communications between a source node and a destination node in a computer network. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baker and Eyada to include Nguyen’s teaching of a source parameter that identifies a service associated with a first functional domain. Doing so would “identify discrepancies between the two network security specifications” (Nguyen, para. 0014) specified using different network security languages.
12. Claim 6 is rejected under 35 U.S.C. § 103 as being unpatentable over Baker and Eyada as applied to claim 1, and further in view of Meyers (US 2017/0104790 A1), hereafter Meyer.
Noted that indicates what the cited art does not teach.
Regarding claim 6, Baker and Eyada teach the elements of claim 1 as stated.
However, Baker further teaches wherein the one or more cloud native security groups is defined based on a risk profile. {Baker [Para. 0064] “Security rules configured for a VCN represent overlay firewall rules for the VCN. The security rules can include ingress and egress rules, and specify the types of traffic (e.g., based upon protocol and port) that is allowed in and out of the instances within the VCN. For instance, the customer can allow incoming SSH traffic from anywhere to a set of instances by setting up a stateful ingress rule with source CIDR 0.0.0.0/0, and destination TCP port 22. Security rules can be implemented using network security groups or security lists. A network security group consists of a set of security rules that apply only to the resources in that group.” [Para. 0116] “As part of this packet processing pipeline, the NVD may execute one or more virtual functions associated with the overlay network such as… the encapsulation and decapsulation of packets to facilitate forwarding or routing in the virtual network,… the implementation of Security Lists, Network Security Groups,…”} Additionally, Eyada also teaches claim 6 (see col. 2, lines 40-53).
However, Baker and Eyada do not teach wherein the one or more cloud native security groups is defined based on a risk profile.
However, Meyers teaches wherein the one or more cloud native security groups is defined based on a risk profile. {Meyers [Para. 0008] “Various examples described below relate to setting a security policy for an asset based on risk.” [Para. 0012] “The policy engine 104 can receive user input to define a security policy and the risk level associated with the security policy.” [Para. 0013] “A group represents any appropriate category, label, range, identifier, and/or container to associate with a risk level. A group associated with a security policy includes a risk level. A group is paired, mapped, or otherwise coupled with a risk level, and, in turn, a security policy associated with that risk level.” [Para. 0036] “The user interface module 414 can receive input 452 from a user, such as via an API 454, to define the risk levels 458 and security policies 460 to be applied on assets of the network. For example, the options module 440 can provide the configuration options, such as selection of risk levels to apply to a security policy, and the input module 442 can receive and/or identify the selections and definitions to be used by the policy module 404 and the group module 406 to define security policies 460 and groups 468.”}
Meyer is analogous art because each of Baker and Eyada pertains to configuring and implementing security policies for inspecting network traffic. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baker and Eyada to include Meyers’s teaching of defining cloud native security groups based on a risk profile. Doing so would “improve flexibility where the risk assessment achieves a flexible security policy” (Meyers, para. 0042).
13. Claim 17 is rejected under 35 U.S.C. § 103 as being unpatentable over Baker and Eyada as applied to claims 1, 10 and 14, and further in view of Jeong et al., (WO 2019/098678 A1, machine translation of patent application from European Patent Office website), hereafter Jeong.
Regarding claim 17, Eyada teaches the elements of claim 14 as outlined above.
However, Baker and Eyada do not teach wherein the source parameter identifies foundation and control telemetry features associated with the first functional domain.
However, Jeong teaches wherein the source parameter identifies foundation and control telemetry features associated with the first functional domain. {Jeong [Para. 0015] “An I2NSF (Interface to Network Security Functions) user device,… encodes security policy data for a security service; and transmits the security policy data to a security controller…, and may include a multi-tenancy field indicating multi-tenancy environment information to which the security policy is applied, an endpoint group field indicating a list of entities to which the security policy is applied, a policy field including rules of the security policy, a threat feed field for identifying a threat target, and a telemetry data field indicating information related to telemetry collection.” [Para. 0020] “The telemetry data field may include at least one of a telemetry data field identified by a telemetry data ID, a telemetry source field identified by a telemetry source ID, and a telemetry destination field identified by a telemetry destination ID.”} See also paras. 168-172 in Jeong for more details on the telemetry data field. Jeong generates security policies and the security policy data fields include a telemetry data field. The telemetry data field includes a telemetry source field.
Jeong is analogous art because each of Baker, Eyada and Jeong pertains to configuring and implementing security policies to facilitate communications between a source node and a destination node in a computer network. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baker and Eyada to include Jeong’s teaching of a source parameter that identifies foundation and control telemetry features associated with a first functional domain. Doing so would “support flexible and efficient security policies in NSF (Network Security Functions)” (Jeong, para. 0022).
14. Claim 18 is rejected under 35 U.S.C. § 103 as being unpatentable over Baker and Eyada as applied to claims 1 and 10, and further in view of Xing et al. (US 2016/0036860 A1), hereafter Xing.
Noted that indicates what the cited art does not teach.
Regarding claim 18, Baker teaches the elements of claim 10 as outlined above.
Baker further teaches wherein the FQSG field is associated with a second FQSG policy comprising a plurality of parameters and wherein the second FQSG policy is to override a pre-existing first FQSG policy. {Baker [Para. 0150] “The control plane sends the customer data 1030 to the NVD 1020 indicating the network boundary and the compute instance(s) to which the customer data 1030 applies. In turn, the NVD 1020 determines the affected compute instance(s). For each affected compute instance, the NVD 1020 generates a packet flow rule 1024 indicating the permitted network boundary and/or a prohibited network boundary. For instance the packet flow rule 1024 identifies a network boundary and the permission or prohibition related thereto… In addition, each packet flow rule can indicate multiple permitted network boundaries and/or multiple prohibited network boundaries.” [Para. 0147] “At operation 904, adding scoping data to a packet generated by a compute instance based on a packet flow rule defined for the compute instance.”} Also see paras. 0091, 0142 and 0153 in Baker for additional examples of parameters included in the security or packet flow rules for a compute instance.
However, Baker and Eyada do not teach wherein the FQSG field is associated with a second FQSG policy comprising a plurality of parameters and wherein the second FQSG policy is to override a pre-existing first FQSG policy.
However, Xing teaches wherein the second FQSG policy is to override a pre-existing first FQSG policy. {Xing [Para. 0019] “The suggested system… define a first policy for data items of a resource represented by a class, such that the first policy is applied for each data item represented by said class and each data item represented by that resources subclasses for which no policy has been defined, wherein for each data item represented by any of said subclasses for which a policy other than the first policy has been defined, such a policy overrides said first policy when executing a request involving at least one of the data items.”} Xing’s system generates policies (e.g., a first policy and a second policy other than the first policy) for data items. The second policy may override another pre-existing first policy.
Xing is analogous art because each of Baker, Eyada and Xing pertains to configuring and implementing policies that control access to resources in a data store. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Baker and Eyada to include Xing’s teaching of defining a second policy that override a pre-existing first policy. One could use the combination to implement features of claim 18. Doing so would enable a user “to flexibly define policies, as well as to amend and/or delete defined policies in an efficient way” (Xing, para. 0007).
Conclusion
15. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BIN QING ZHENG whose telephone number is (703)756-1535. The examiner can normally be reached on M-F 9:30 am - 5:30 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Philip J. Chea can be reached on 571-272-3951. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/BIN QING ZHENG/
Examiner, Art Unit 2499
/PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499
Prosecution Insights