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 .
Detailed Action
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1 – 20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 1 line 5/claim 7 line 9 recites “…a first unique IP address…”; however, it is unclear to The Examiner how uniqueness is defined in a way that is not different than “…a second unique IP address…” recited in claim 1 line 11/claim 7 line 17. This is unclear because claim 4/claim 10 explicitly states the first unique IP address is different than the second unique IP address, so it follows that the uniqueness of Claim 1/Claim 7 is some form of uniqueness that does not require the addresses to be different and this is not clear to The Examiner how this is possible. In addition, it is not clear to The Examiner by what criteria uniqueness is defined for claim 13 line 7. Applicant’s disclosure provides no limiting definition of determining how to determine if an address is unique. In addition, claim 15 lines 2 – 3 recite “…a return flow from a destination device…having the unique source IP address in a source field…”; however, it is unclear to The Examiner how a source address can indicate a destination address. It is not clear if a limitation is missing or if this is a typo. In addition, claim 19 lines 3 and 6 recite “optimized” without specifying an objective criteria to determine optimization. As a result, the metes and bounds of the claims are unclear. Appropriate correction is required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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 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.
Claims 13, 14 and 16 – 18 are rejected under 35 U.S.C. 103 as being unpatentable over Fayazbakhsh (Enforcing Network-Wide Policies in the Presence of Dynamic Middlebox Actions using FlowTags, 2014) in view of Belamaric (US Pub. No. 2018/0013793 A1) in view of Fayaz (FlowTags: Enforcing Network-Wide Policies in the presence of Dynamic Middlebox Actions, 2013).
Per claim 13, Fayazbakhsh (Enforcing Network-Wide Policies in the Presence of Dynamic Middlebox Actions using FlowTags, 2014) suggests: receiving (reads on the SDN controllers interact with middleboxes via FlowTags API, see Fayazbakhsh Abstract), at a software-defined networking (SDN) controller of a network (reads on a SDN, see Fayazbakhsh Abstract), an indication of a mapping (reads on the SDN controller configures the tag generation and tag consumption operations which requires the controller to receive information about tag mappings, see Fayazbakhsh Abstract and 3.2) between a unique source Internet Protocol (IP) address (reads on the tags that serve as unique identifiers that are functionally equivalent to unique source IP addresses, see Fayazbakhsh Figure 5) associated with a network flow and context data associated with the network flow (reads on middleboxes export tags to provide the necessary causal context which is associated with the flows, see Fayazbakhsh Abstract, 3.2 and 5.3 Subsection Corser tags), wherein: the unique source IP address maps to an actual source IP address of a client device that originated the network flow (reads on tags enable mapping to the packet’s true endpoints and the original hosts and the original host IP addresses, see Fayazbakhsh Section 1, 3.1 and Figure 5. The Examiner asserts the tag/unique identifier maps to the actual source IP address of the client device that originated the flow and the tag allows decoding to obtain the original/actual source IP despite NAT inducted modifications); and the unique source IP address (reads on the tag/unique identifier, see Fayazbakhsh Section 1, 3.1 and Figure 5) is different than the actual source IP address (reads on the SrcIP/OrigHdr, see Fayazbakhsh Section 1, 3.1, 5.2 and Figure 5) of the client device (reads on the leftmost devices of Figure 5); identifying network policy to apply to (reads on meeting the PATHSFOLLOWPOLICY requirement by exemplary allowing packets with tag 2 to pass through without going to the firewall, see Fayazbakhsh Section 3.1, 5.2 and Figure 6) the network flow based at least in part on the context data (reads on the tags encode processing context and the controller uses this information to assign tags and tag-related rules and enforce the policy the administrator wants to enforce, see Fayazbakhsh Abstract, Section 1, 3.1, 3.2, 5, 5.1 and 5.2); and sending (reads on the controller configures the firewall and switches and provides a new flow table entry, see Fayazbakhsh Section 3.1 and 4), from the SDN controller (reads on the controller, see Fayazbakhsh Section 3.1 and 4), an instruction to a network device in the network (reads on the controller configures the firewall and switches and provides a new flow table entry, see Fayazbakhsh Section 3.1 and 4) to enforce the network policy (reads on the combination of configuring the firewall so it can decode the tags to map the observed IP addresses to the original hosts and configuring the switches to allow packets with tag 2 to pass through without going to the firewall, see Fayazbakhsh Section 3.1 and 4) on the network flow having the unique source IP address (reads on using the incoming unique tag to determine the forwarding entry, see Fayazbakhsh Figure 5 and Section 3.2, 4, 5.2 and 5.4). The prior art of record is silent on explicitly stating a system comprising: one or more processors; and one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations; and unique source IP address maps to an actual source IP address.
Belamaric (US Pub. No. 2018/0013793 A1) suggests one or more processors (see Belamaric para 0011 and claim 21); and one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations (see Belamaric para 0011 and claim 21); and sending (reads on the SDN network controller receives DNS/network metadata policy/IP address addition/deletion, see Belamaric para 0073 – 0074 and Figure 5), to a network controller of a network (reads on a SDN controller, see Belamaric para 0073 – 0074 and Figure 5) through which the first network flow is destined (see Belamaric Figure 3), a first mapping between the source IP address and the first unique IP address (reads on routing rules/IP address changes, see Belamaric para 0024 – 0026 and 0074); and sending (reads on the SDN network controller receives DNS/network metadata policy/IP address addition/deletion, see Belamaric para 0073 – 0074 and Figure 5), to the network controller (reads on a SDN controller, see Belamaric para 0073 – 0074 and Figure 5), a second mapping (reads on routing rules/IP address changes, see Belamaric para 0024 – 0026 and 0074).
[0024] In some embodiments, a system, process, and/or computer program product for a DNS or network metadata policy for network control includes receiving a DNS update at a DNS server (e.g., an authoritative or recursive DNS server) or an IP Address Management (IPAM) server, in which the DNS update is determined to be relevant to the DNS or network metadata policy for network control; and sending the DNS update to a network controller for a network, in which the network controller configures a plurality of network devices on the network based on the DNS or network metadata policy for network control. For example, the network controller can configure/control a plurality of network devices, such as physical, virtual, and/or SDN based routers, switches, load balancers, security/firewall devices, and/or other networking devices (e.g., that can implement a policy for allowing network access, routing network traffic, filtering network traffic based on rules, ACLs, zones, subzones, DNS wildcards, etc.), based on a DNS or network metadata policy for network control that includes a policy based on a Fully Qualified Domain Name(s) (FQDN(s)).
[0025] In one embodiment, the network device controller automatically configures the plurality of network devices on a heterogeneous network based on the DNS or network metadata policy for network control. For example, the plurality of network devices can include physical, virtual, or SDN based routers and/or switches, and the heterogeneous network can include network devices from a plurality of different vendors (e.g., Cisco Systems, Juniper Networks, EMC/VMware, and/or other vendors). In an example implementation, the DNS or network metadata policy can include access and/or routing rules/configurations for a router and/or switch based on a DNS wildcard. For example, the DNS or network metadata policy can include a rule-list based on FQDNs that match a particular DNS wildcard (e.g., including routing ACLs for a router). A rule can include an Access Control Entry (ACE) inside an ACL or a rule inside a DNS or network metadata policy (e.g., a network policy that includes a policy based on FQDNs that match a DNS wildcard). As an example, a rule can provide a description of a network flow and/or a filtering access (e.g., allow or deny, such as to allow/deny from <Source> to <Destination> for Service).
[0026] In one embodiment, the network device controller supports SDN-based devices (e.g., OpenFlow switches, etc.). For example, SDN is an approach that can be used to simplify computer networking. SDN allows network administrators to manage network services through abstraction of lower level networking functionality. Generally, this is implemented by decoupling the control plane (e.g., the system that makes decisions about where traffic is sent) from the data plane (e.g., the underlying systems that forward traffic to the selected destination). SDN generally provides a mechanism for the control plane to communicate with the data plane. OpenFlow is an example SDN standard that provides such a mechanism. Other mechanisms can also be used to allow for the control plane to communicate with the data plane.
[0073] At 504, the DNS or network metadata update is determined to be relevant to a DNS or network metadata policy for network control/configuration. For example, the DNS update can be determined to be an IP address addition, deletion, and/or change that matches a DNS wildcard specified in the DNS or network metadata policy, such as similarly described above. As another example, the network metadata update can be determined to be a network CIDR block addition, deletion, and/or change that matches a metadata association specified in the DNS or network metadata policy, such as similarly described above.
[0074] At 506, the relevant DNS or network metadata update is sent to a network controller for the network. For example, the network controller can be an SDN controller that configures a plurality of network devices on the enterprise network based on the DNS or network metadata policy for network control. For example, the SDN controller can configure/control a plurality of network devices, such as physical, virtual, and/or SDN based routers and/or switches, based on a DNS or network metadata policy for network control that includes a policy based on a DNS wildcard or metadata association such as similarly described above.
PNG
media_image1.png
1060
624
media_image1.png
Greyscale
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the proxy teachings of the prior art of record by integrating the SDN controller-based network policy enforcement of Belamaric to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Both references address network address translation and policy-based network control. Accordingly, one of ordinary skill in the art would have recognized that applying the known technique of Belamaric would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the ability to receiving mappings and use them to enforce policy across network devices to the proxy generating address mappings teachings of the prior art of record would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such mapping features into similar systems, resulting in an improved system that receives mappings and uses them to enforce policy based on context derived from address translation mappings across network devices. The motivation to combine the references is applied to all claims below this heading.
Fayaz (FlowTags: Enforcing Network-Wide Policies in the presence of Dynamic Middlebox Actions, 2013) suggests an indication of a mapping between a unique source Internet Protocol (IP) address associated with a network flow and context data associated with the network flow (see Fayaz mapping between S1 and S2 of Figure 2), wherein: the unique source IP address maps to an actual source IP address of a client device that originated the network flow (see <H1,D1> , <H2,D2> and <H2,D3> of Fayaz Figure 2); and the unique source IP address is different than the actual source IP address of the client device (reads on <P1,D1> and <P2,D1> of Fayaz Figure 2); identifying network policy to apply to the network flow based at least in part on the context data (reads on each packet carries contextual information necessary for correct policy enforcement, see Fayaz Figure 5 caption); and sending, from the SDN controller, an instruction to a network device in the network to enforce the network policy on the network flow having the unique source IP address (see Fayaz Figure 5).
Before the effective filing date of the invention it would have been obvious to one of ordinary skill in the art to modify the mapping teachings of the prior art of record by integrating the mapping of different IP address teachings of Fayaz to realize the instant limitation. One or more of the underpinning rational(s), as discussed in KSR international Co, v, Teleflex inc,s etai,s 550 U,S. 398 (2007) U.S.P.Q.2d 1385, also see MPEP § 2141 {IN), are used to support this conclusion of obviousness. Accordingly, one of ordinary skill in the art would have recognized that applying the known technique of Fayaz would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the ability to have different IP addresses for source devices based on policy would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such mapping features into similar systems, resulting in an improved system that receives mappings and uses them to enforce policy based on context derived from address translation mappings across network devices. The motivation to combine the references is applied to all claims below this heading.
Per claim 14, the prior art of record further suggests receiving, at the network device, the network policy (see Belamaric para 0024 and Fayazbakhsh Section 4 subsection: switch actions); identifying, at the network device, the network flow based at least in part on the unique source IP address being in a source field of the network flow (see Fayaz Figure 2 and 5); and enforcing the network policy on the network flow (see Belamaric para 0002).
Per claim 16, the prior art of record further suggests identifying, from the context data, a user identity of a user of a source device of the network flow (reads on a user or system defined metadata such as tenant/endpoint group, see Belamaric para 0020, 0022 and 0025), wherein the network policy is identified based at least in part on the user identity (reads on policy rules based on per-group/user policies, see Belamaric para 0025, 0038, 0068 and Fayazbakhsh Figure 1).
Per claim 17, the prior art of record further suggests identifying, from the context data, at least one of: an application running on the client device that initiated the network flow; or a service associated with a destination device to which the network flow is being transmitted, wherein the network policy is identified based at least in part on at least one of the application or the service (reads on network metadata policy can include rules/objects based on arbitrary associations between user or system defined metadata such as application, application type, application-level classification see Belamaric para 0020, 0022 and 0025 and Fayazbakhsh Sections 5.1 and 5.2).
Per claim 18, the prior art of record further suggests determining, using the context data, that the network flow is to be sent through at least one of an inspection node (reads on route suspicious packets to the heavy IPS, see Fayazbakhsh Section 2.1 and Figure 3) or a firewall node; and the instruction to enforce the network policy includes a command for the network device to route the network flow through at least one of the inspection node or the firewall node (reads on firewall configured to block hosts H1 and H3 ad policy routes specific traffic through firewall based on source identity, see Fayazbakhsh Figure 1 and Section 3.1).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Brian Shaw whose telephone number is (571)270-5191. The examiner can normally be reached on Mon-Thurs from 6:00 AM-3:30 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeff Nickerson can be reached on (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 703-872-9306.
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.
/BRIAN F SHAW/
Primary Examiner, Art Unit 2432