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 .
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1, 8 and 15 are rejected under 35 U.S.C. 102 (a)(1) as being anticipated by Applicant’s IDS Panchalingam et al (2020/0389432).
For claim 1, Panchalingam teaches a method (abstract) comprising: receiving, at a fabric edge device and from a host device, an ingress data packet with the host device as a source and a destination of a data center device (Panchalingam teaches application-centric enforcement for multi-tenant workloads with multi-site data center fabrics, the method including: receiving, at a local switch at a first site which is fabric edge device, a packet from a first host at the first site intended for a second host located at a second site at a different geographical location from the first site as Panchalingam teaches in par.11);
transmitting, by the fabric edge device and to a host tracking database (DB), a request
for a security group associated with the data center device (Panchalingam teaches that identifying a second class identifier (ID) for the second host as host tracking database from a database maintained at the first site, wherein a first class ID for the first host is known to the local switch; determining, based on the first class ID and the second class ID, a security policy for transmitting data from the first host to the second host as Panchalingam teaches in par.11 and 21); and
in response to receiving the security group associated with the data center device,
applying, by the fabric edge device a security policy associated with the security group to the ingress data packet (Panchalingam teaches in response to determining that the security policy indicates that the second site exclusively manages security policies for a software defined network including the first host and the second host: setting a policy applied indicator, derived from a policy override indicator, on the packet indicating that enforcement of the security policy is delegated from the first switch to a second switch connected to the second host at the second site; including the first class ID and the second class ID in the packet; and transmitting the packet to the second site as Panchalingam teaches in par.11 and 31-32, 36-42).
For claim 8, Panchalingam teaches A system (abstract) comprising:
one or more processors; and one or more 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 (Panchalingam teaches computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus as Panchalingam teaches in par.52) comprising: receiving, at a fabric edge device and from a host device, an ingress data packet with the host device as a source and a destination of a data center device (Panchalingam teaches application-centric enforcement for multi-tenant workloads with multi-site data center fabrics, the method including: receiving, at a local switch at a first site which is fabric edge device, a packet from a first host at the first site intended for a second host located at a second site at a different geographical location from the first site as Panchalingam teaches in par.11);
transmitting, by the fabric edge device and to a host tracking database (DB), a request
for a security group associated with the data center device (Panchalingam teaches that identifying a second class identifier (ID) for the second host as host tracking database from a database maintained at the first site, wherein a first class ID for the first host is known to the local switch; determining, based on the first class ID and the second class ID, a security policy for transmitting data from the first host to the second host as Panchalingam teaches in par.11 and 21); and
in response to receiving the security group associated with the data center device,
applying, by the fabric edge device a security policy associated with the security group to the ingress data packet (Panchalingam teaches in response to determining that the security policy indicates that the second site exclusively manages security policies for a software defined network including the first host and the second host: setting a policy applied indicator, derived from a policy override indicator, on the packet indicating that enforcement of the security policy is delegated from the first switch to a second switch connected to the second host at the second site; including the first class ID and the second class ID in the packet; and transmitting the packet to the second site as Panchalingam teaches in par.11 and 31-32).
For claim 15, Panchalingam teaches One or more non-transitory computer-readable media storing instructions that, when executed, cause one or more processors to perform operations (Panchalingam teaches computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus as Panchalingam teaches in par.52) comprising:
receiving, at a fabric edge device and from a host device, an ingress data packet with the host device as a source and a destination of a data center device (Panchalingam teaches application-centric enforcement for multi-tenant workloads with multi-site data center fabrics, the method including: receiving, at a local switch at a first site which is fabric edge device, a packet from a first host at the first site intended for a second host located at a second site at a different geographical location from the first site as Panchalingam teaches in par.11);
transmitting, by the fabric edge device and to a host tracking database (DB), a request
for a security group associated with the data center device (Panchalingam teaches that identifying a second class identifier (ID) for the second host as host tracking database from a database maintained at the first site, wherein a first class ID for the first host is known to the local switch; determining, based on the first class ID and the second class ID, a security policy for transmitting data from the first host to the second host as Panchalingam teaches in par.11 and 21); and
in response to receiving the security group associated with the data center device,
applying, by the fabric edge device a security policy associated with the security group to the ingress data packet (Panchalingam teaches in response to determining that the security policy indicates that the second site exclusively manages security policies for a software defined network including the first host and the second host: setting a policy applied indicator, derived from a policy override indicator, on the packet indicating that enforcement of the security policy is delegated from the first switch to a second switch connected to the second host at the second site; including the first class ID and the second class ID in the packet; and transmitting the packet to the second site as Panchalingam teaches in par.11 and 31-32. 36-42).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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.
Claims 2-7, 9-14 and 16-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Applicant’s IDS Panchalingam et al (2020/0389432) in view of Applicant’s IDS Hooda et al (2020/0177503).
For claims 2, 9 and 16, Panchalingam teaches all the limitations as previsouly set forth except for wherein the host tracking DB receives information
associated with the data center device from a service border device, the information including an Internet Protocol (IP) prefix of the data center device and the security group as determined by a security infrastructure.
Hooda teaches, similar system, wherein the host tracking DB receives information associated with the data center device from a service border device, the information including an Internet Protocol (IP) prefix of the data center device and the security group as determined by a security infrastructure (Hooda teaches that Each WAN site 204 can include one or more hosts 206 (sometimes also referred to as endpoints, computing devices, computing systems, etc.) connected to one or more WAN aggregation devices 208 (sometimes also referred to as access, edge, or border devices, nodes, or leafs, etc.) as Hooda teaches in par.43). It would have been obvious to one ordinary skill in the art before effective filling date to modify Panchalingam to include service border device as taught and suggested by Hooda for the purpose of building and maintaining a network topology and make decisions on where traffic flows and establishing secure connections to each WAN edge device (Hooda, par.40).
For claims 3, 10 and 17, Panchalingam teaches all the limitations as previously set forth except for wherein the service border device is configured by a
Software Defined Network (SDN) controller to learn data center device IP prefixes to security group bindings from the security infrastructure.
Hooda further teaches wherein the service border device is configured by a
Software Defined Network (SDN) controller to learn data center device IP prefixes to security group bindings from the security infrastructure (Hooda teaches that SD-WAN is part of a broader technology of software-defined networking (SDN) as Hooda teaches in par.5). It would have been obvious to one ordinary skill in the art before effective filling date to modify Panchalingam to include service border device with Software Defined Network (SDN) as taught and suggested by Hooda for the purpose of building and maintaining a network topology and make decisions on where traffic flows and establishing secure connections to each WAN edge device (Hooda, par.40).
For claims 4, 11 and 18, Panchalingam teaches all the limitations as previously set forth and Panchalingam further teaches wherein the security infrastructure receives IP prefixes and associated security groups from at least one of a Software Defined Network (SDN) controller, a data center policy engine, or applications (Panchalingam teaches that network fabric 100 is a Software Defined Network (SDN) that includes a first site 110a (generally, site 110), a second site 110b, and a third site 110c, where each of the sites 110 are located at different geographic locations from one another (i.e., are remotely located) as Panchalingam teaches in par.15).
For claims 5, 12 and 19, Panchalingam teaches all the limitations as previously set forth except for wherein the service border device receives IP prefix to
security group bindings from the security infrastructure via a security tag exchange protocol (SXP).
Hooda further teaches wherein the service border device receives IP prefix to
security group bindings from the security infrastructure via a security tag exchange protocol (SXP) (Hooda teaches that traffic through the network, which can be accomplished either through inline tagging or the SGT Exchange Protocol (SXP) as Hooda teaches in par.81). It would have been obvious to one ordinary skill in the art before effective filling date to modify Panchalingam to include service border device with Software Defined Network (SDN) as taught and suggested by Hooda for the purpose of doing Enforcement that can implement a permit or deny policy decision based on the source and destination SGTs (e.g., using Security Group ACL (SGACL) on network devices and Security Group Firewall (SGFW) on firewalls) (Hooda, par.81).
For claims 6, 13 and 20, Panchalingam teaches all the limitations as previously set forth except for wherein the information associated with the data center
device indicates an absence of a preexisting IP prefix to security group binding, and further comprising receiving, at the host tracking DB and from the service border device, an indication that the IP prefix is associated with a reserved unassigned data center security group, and wherein the service border device corresponds to an egress tunnel endpoint.
Hooda further teaches that wherein the information associated with the data center device indicates an absence of a preexisting IP prefix to security group binding, and further comprising receiving, at the host tracking DB and from the service border device, an indication that the IP prefix is associated with a reserved unassigned data center security group, and wherein the service border device corresponds to an egress tunnel endpoint (Hooda teaches that Each WAN site 204 can include one or more hosts 206 (sometimes also referred to as endpoints, computing devices, computing systems, etc.) connected to one or more WAN aggregation devices 208 (sometimes also referred to as access, edge, or border devices, nodes, or leafs, etc.) as Hooda teaches in par.43). It would have been obvious to one ordinary skill in the art before effective filling date to modify Panchalingam to include service border device as taught and suggested by Hooda for the purpose of building and maintaining a network topology and make decisions on where traffic flows and establishing secure connections to each WAN edge device (Hooda, par.40).
For claims 7, and 14, Panchalingam teaches all the limitations as previously set forth except for wherein the data center device security group is mapped
to a data center device IP prefix in a Forwarding Information Base (FIB).
Hooda further teaches that wherein the data center device security group is mapped to a data center device IP prefix in a Forwarding Information Base (FIB) (Hooda teaches that An OMP route may be installed in the forwarding table, which is Forwarding Information Base, if the TLOC to which it points is active. [0051] TLOC routes, which can correspond to logical tunnel termination points on the WAN edge devices 142 that connect into the transport networks 160 as Hooda teaches in par.49-51). It would have been obvious to one ordinary skill in the art before effective filling date to modify Panchalingam to include Forwarding Information Base as taught and suggested by Hooda for the purpose of uniquely identified and represented by a three-tuple, including an IP address, link color, and encapsulation (e.g., Generic Routing Encapsulation (GRE), IPSec, etc.). In addition to system IP address, color, and encapsulation, TLOC routes can also carry attributes such as TLOC private and public IP addresses, carrier, preference, site identifier, tag, and weight (Hooda, par.51).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AYUB A MAYE whose telephone number is (571)270-5037. The examiner can normally be reached Monday-Friday 9AM-5PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, SHEWAYE GELAGAY can be reached at 571-272-4219. 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.
/AYUB A MAYE/Examiner, Art Unit 2436
/SHEWAYE GELAGAY/Supervisory Patent Examiner, Art Unit 2436
Prosecution Insights