DETAILED ACTION
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 .
Applicant's submission filed on 05/22/2025 has been entered. Claims 1-20 have been examined.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Torrington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claims 1-2,4-8,10-11,13-17,19 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-18 of the Patent No. US 12,335,237 B2 in view of Oswal.
Claims 3,12,20 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-18 of the Patent No. US 12,335,237 B2 in view of Oswal further in view of Wang.
Claims 9,18 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-18 of the Patent No. US 12,335,237 B2 in view of Oswal further in view of Jeong
Below are the analysis to the claims.
Claims of Instant application
Claims of Patent No. US 12,335,237
Claims 1,10,19
A method/system/medium 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 comprising:
identifying, by a first network device located at a first site of a network and based on receiving a data packet, a first firewall policy associated with the first network device;
receiving metadata associated with the first firewall policy from a cloud service of the network;
inspecting, based at least in part on the first firewall policy and by a first firewall of the network, the data packet by the first network device;
adding, by the first network device and based on the metadata, a marker to a header of the data packet to indicate inspection by the first firewall, the marker comprising unified threat defense (UTD) metadata; and
transmitting, via the network, the data packet to a second network device at a second site, wherein the second network device refrains from inspecting the data packet based on the UTD metadata.
Claims 1,8,15
A method/system/medium 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 comprising
receiving, by a first network device located at a first site, a data packet, wherein the data packet corresponds to a data flow between the first network device and a second network device over a network;
identifying a first firewall policy associated with the first network device, the first firewall policy being provided by a controller and identifying a first firewall of the network configured to inspect the data packet;
inspecting, based at least in part on the first firewall policy and by the first firewall of the network, the data packet by the first network device;
adding, by the first network device, a marker to a header of the data packet to indicate inspection by the first firewall, the marker comprising unified threat defense (UTD) metadata;
transmitting, via the network, the data packet to the second network device at a second site;
identifying, based on receiving the data packet and by the second network device, a second firewall policy associated with the second network device, wherein the UTD metadata indicates a profile identifier applied to the data packet by the first firewall, wherein identifying the second firewall policy is based on extracting the profile identifier; and determining, by the second network device, based at least in part on the second firewall policy and extracting the marker from the header, to refrain from inspecting the data packet.
Claims 2,11
wherein the data packet further comprises an initial data packet of a data flow, the method further comprising refraining from adding the marker to subsequent data packets of the data flow..
Claims 2,9
wherein the data packet further comprises an initial data packet of the data flow, the method further comprising refraining from adding the marker to subsequent data packets of the data flow.
Claims 3,12,20
wherein the second network device refrains from inspecting the data packet based on:
extracting, by the second network device, a profile identifier included in the UTD metadata, the profile identifier being applied to the data packet by the first firewall;
identifying, based on the profile identifier, a second firewall policy associated with the second network device;
receiving second metadata associated with the second firewall policy from the cloud service of the network; and
determining, by the second network device, based at least in part on the second firewall policy, the second metadata, and extracting the marker from the header, to refrain from inspecting the data packet.
Claims 1,8,15
identifying, based on receiving the data packet and by the second network device, a second firewall policy associated with the second network device, wherein the UTD metadata indicates a profile identifier applied to the data packet by the first firewall, wherein identifying the second firewall policy is based on extracting the profile identifier; and
determining, by the second network device, based at least in part on the second firewall policy and
extracting the marker from the header, to refrain from inspecting the data packet.
Claims 4,13
wherein refraining from inspecting the data packet comprises refraining from processing a Layer 7 Firewall inspection by the second network device.
Claims 3,10,17
wherein refraining from inspecting the data packet comprises refraining from processing a Layer 7 Firewall inspection by the second network device.
Claims 5,14
wherein the first network device comprises a software defined cloud interconnect (SDCI) router and the second network device comprises a SDCI headend device.
Claims 4,11
wherein the first network device comprises a software defined cloud interconnect (SDCI) router and the second network device comprises a SDCI headend device.
Claims 6 ,15
wherein the network comprises a software defined cloud interconnect wide area network, and wherein data included in the header of the data packet is encrypted.
Claims 7,14,
wherein the network comprises a software defined cloud interconnect wide area network and wherein the data packet comprises a header, wherein data included in the header of the data packet is encrypted.
Claims 7, 16
wherein the marker comprises a flag included in the UTD metadata, wherein the flag is included as part of a security level tag length value.
Claims 6,13,16
wherein the marker comprises a flag included in the UTD metadata, wherein the flag is included as part of a security level tag length value.
Claims 8,17
wherein the UTD metadata is added to a software-defined wide area network header of the data packet in a tag length value format.
Claims 5,12
herein the UTD metadata is added to a software-defined wide area network header of the data packet in a tag length value format.
With regards to claims 1,10,19, the patent No. US 12,335,237 does not teach receiving metadata associated with the first firewall policy from a cloud service of the network. However, Oswal teaches receiving metadata associated with the first firewall policy from a cloud service of the network (Col.5, lines 60-70 , Col. 6, lines 4-20).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of patent No. US 12,335,237 to include the teachings of Oswal. The motivation for doing so is to allow system to perform security policy enforcement, network routing, and/or other actions using the meta data information associated with a given flow without having to perform the inspection (Oswal – Col.6, lines 24-30).
With regards to claims 3,12,20, the patent No. US 12,335,237 does not teach receiving second metadata associated with the second firewall policy from the cloud service of the network and determining, by the second network device, based at least in part on the second firewall policy, the second metadata, to refrain from inspecting.
However, Wang et al. Patent No. US 10,805,320 B1 teaches receiving second metadata associated with the second firewall policy from the cloud service of the network and determining, by the second network device, based at least in part on the second firewall policy, the second metadata, to refrain from inspecting (Col.3, lines 60-70 , Col. 4, lines 1-20).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of patent No. US 12,335,237 to include the teachings of Wang. The motivation for doing so is to allow system to bypass inspection for traffic of application with good reputation (Wang – Col.3, lines 60-70 , Col. 4, lines 1-20).
With regards to claims 9,18, the patent No. US 12,335,237 does not teach wherein the metadata includes intelligence data indicating whether additional inspections should be performed on the data packet.
However, Jeong teaches metadata includes intelligence data indicating whether additional inspections should be performed on the data packet (Abstract, Page 4).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of patent No. US 12,335,237 to include the teachings of Jeong. The motivation for doing so is to allow the system to perform deeper security check when the first inspection indicates a suspicious packet.
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.
Claims 1,10,19 are rejected under 35 U.S.C. 103 as being unpatentable Sundararajan et al. Publication No. US 2021/0266291 A1 ( Sundararajan hereinafter) in view of Oswal et al. Patent No. US 11,095,612 B1 ( Oswal hereinafter) further in view of Valluri et al. Publication No. US 2020/0177606 A1 ( Valluri hereinafter)
Regarding claim 1,
Sundararajan teaches a method comprising:
identifying, by a first network device located at a first site of a network and based on receiving a data packet, a first firewall policy associated with the first network device ( ¶ 0019 -Source site 110 of system 100 may include a source machine 120 (shown as a client computer), a source router 130, and a first firewall 140 associated with the source site – ¶ 0022 - The source data packet sent from the source machine 120 may arrive at the source router 130. The source
router 130 may check the source data packet and determine whether it has a flow table entry in its header; the flow table entry may indicate that the data packet has previously been seen by the source router 130. If the source data packet is a SYN packet, it would not have a flow table entry as it is its first session with source router 130. Next, per an application policy of the source site 110, the source router 130 may forward the source data packet to the first firewall 140 at the source site 110 for inspection);
inspecting, based at least in part on the first firewall policy and by a first firewall of the network, the data packet by the first network device; adding, by the first network device and based on the metadata, a marker to a header of the data packet to indicate inspection by the first firewall, the marker comprising [..] metadata (¶ 0022 - the source router 130 may forward the source data packet to the first firewall 140 at the source site 110 for inspection. The first firewall 140 may inspect the source data packet and then return the source data packet back to the source router 130. The source router 130 may then mark the source data packet with a marker to indicate firewall inspection has been completed by the first firewall 140. In an embodiment, the source router 130 may mark the source data packet with a flag using TCP options. In an embodiment, the flag may comprise a custom "R"("redirect") flag available in an Options field of the TCP header of the source data packet);
and transmitting, via the network, the data packet to a second network device at a second site, wherein the second network device refrains from inspecting the data packet based on the [..] metadata (¶ 0022 - the source router 130 may transmit the source data packet over an encapsulated, encrypted tunnel to the destination site 150. While the description above indicates that the first firewall 140 may inspect the source data packet prior to marking the source data packet by the source router 130. ¶ 0023 - At the destination site 150, the destination router may receive the source data packet. The destination router 160 may determine, based on the existence of the marker, i.e., R flag, that the source data packet has been inspected by a firewall , namely the first firewall 140. the destination router 160 may determine that there is no need to forward the source data packet to its local firewall, i.e., the second firewall 170. As a result, the destination router 160 may cache the flow table entry associated with the source data packet and then forward the source data packet to the destination machine
180 at the destination site 150 without inspection of the source data packet by the second firewall 170 associated with the destination site 150).
However, Sundararajan does not explicitly teach
receiving metadata associated with the first firewall policy from a cloud service of the network and the metadata is Unified threat defense (UTD).
Oswal teaches
receiving metadata associated with the first firewall policy from a cloud service of the network (Col.5, lines 60-70 - processes for determining such meta data information associated with each flow (e.g., App ID, User ID, Device ID, Content ID, and/or other meta data associated with a flow) can be performed at one of the computing devices/elements/locations ( e.g., at the cloud-based security service, such as provided via Prisma Access. Col. 6, lines 4-20 - the cloud-based security service can be provided using a private cloud, one or more public cloud service providers, and/or any combination thereof). The determined meta data information associated with each flow can then be communicated to SD-WAN device. The SD-WAN device perform security policy enforcement, network routing, and/or other actions using the meta data information associated with a given flow).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan to include the teachings of Oswal. The motivation for doing so is to allow system to perform security policy enforcement, network routing, and/or other actions using the meta data information associated with a given flow without having to perform the inspection (Oswal – Col.6, lines 24-30).
Sundararajan in view of Oswal does not explicitly teach that the metadata is UTD metadata.
Valluri teaches
UTD metadata (¶ 0009 - the DNS security platform may maintain a list of IPs and/or domains associated with threats, and once a flow has passed the security platform, it may be processed by a unified threat defense (UTD) policy, which detects threats based on the actual behavior of the application. Claim 10 - receive, via a network controller appliance of a software- defined wide-area network, an upstream update from an edge network device that comprises a threat signature associated with a threat detected by the edge network device; trigger a temporary update to add the detected threat as a negative unified threat defense (UTD) result in a local domain name system (DNS) blacklist; and push a downstream update that comprises the threat signature to other edge network devices that have not
seen the threat).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan in view of Oswal to include the teachings of Valluri. The motivation for doing so is to allow system to push the update including UTD signature to other devices that have not yet seen the threat or clearance (Valluri – Abstract).
Regarding claim 10,
Sundararajan teaches 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 comprising: identifying, by a first network device located at a first site of a network and based on receiving a data packet, a first firewall policy associated with the first network device ( ¶ 0019 -Source site 110 of system 100 may include a source machine 120 (shown as a client computer), a source router 130, and a first firewall 140 associated with the source site – ¶ 0022 - The source data packet sent from the source machine 120 may arrive at the source router 130. The source router 130 may check the source data packet and determine whether it has a flow table entry in its header; the flow table entry may indicate that the data packet has previously been seen by the source router 130. If the source data packet is a SYN packet, it would not have a flow table entry as it is its first session with source router 130. Next, per an application policy of the source site 110, the source router 130 may forward the source data packet to the first firewall 140 at the source site 110 for inspection);
inspecting, based at least in part on the first firewall policy and by a first firewall of the network, the data packet by the first network device; adding, by the first network device and based on the metadata, a marker to a header of the data packet to indicate inspection by the first firewall, the marker comprising [..] metadata (¶ 0022 - the source router 130 may forward the source data packet to the first firewall 140 at the source site 110 for inspection. The first firewall 140 may inspect the source data packet and then return the source data packet back to the source router 130. The source router 130 may then mark the source data packet with a marker to indicate firewall inspection has been completed by the first firewall 140. In an embodiment, the source router 130 may mark the source data packet with a flag using TCP options. In an embodiment, the flag may comprise a custom "R"("redirect") flag available in an Options field of the TCP header of the source data packet);
transmitting, via the network, the data packet to a second network device at a second site, wherein the second network device refrains from inspecting the data packet based on the [..] metadata (¶ 0022 - the source router 130 may transmit the source data packet over an encapsulated, encrypted tunnel to the destination site 150. While the description above indicates that the first firewall 140 may inspect the source data packet prior to marking the source data packet by the source router 130. ¶ 0023 - At the destination site 150, the destination router may receive the source data packet. The destination router 160 may determine, based on the existence of the marker, i.e., R flag, that the source data packet has been inspected by a firewall , namely the first firewall 140. the destination router 160 may determine that there is no need to forward the source data packet to its local firewall, i.e., the second firewall 170. As a result, the destination router 160 may cache the flow table entry associated with the source data packet and then forward the source data packet to the destination machine 180 at the destination site 150 without inspection of the source data packet by the second firewall 170 associated with the destination site 150);
However, Sundararajan does not explicitly teach
receiving metadata associated with the first firewall policy from a cloud service of the network and the metadata is Unified threat defense (UTD).
Oswal teaches
receiving metadata associated with the first firewall policy from a cloud service of the network (Col.5, lines 60-70 - processes for determining such meta data information associated with each flow (e.g., App ID, User ID, Device ID, Content ID, and/or other meta data associated with a flow) can be performed at one of the computing devices/elements/locations ( e.g., at the cloud-based security service, such as provided via Prisma Access. Col. 6, lines 4-20 - the cloud-based security service can be provided using a private cloud, one or more public cloud service providers, and/or any combination thereof). The determined meta data information associated with each flow can then be communicated to SD-WAN device. The SD-WAN device perform security policy enforcement, network routing, and/or other actions using the meta data information associated with a given flow).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan to include the teachings of Oswal. The motivation for doing so is to allow system to perform security policy enforcement, network routing, and/or other actions using the meta data information associated with a given flow without having to perform the inspection (Oswal – Col.6, lines 24-30).
Sundararajan in view of Oswal does not explicitly teach that the metadata is UTD metadata.
Valluri teaches
UTD metadata (¶ 0009 - the DNS security platform may maintain a list of IPs and/or domains associated with threats, and once a flow has passed the security platform, it may be processed by a unified threat defense (UTD) policy, which detects threats based on the actual behavior of the application. Claim 10 - receive, via a network controller appliance of a software- defined wide-area network, an upstream update from an edge network device that comprises a threat signature associated with a threat detected by the edge network device; trigger a temporary update to add the detected threat as a negative unified threat defense (UTD) result in a local domain name system (DNS) blacklist; and push a downstream update that comprises the threat signature to other edge network devices that have not
seen the threat).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan in view of Oswal to include the teachings of Valluri. The motivation for doing so is to allow system to push the update including UTD signature to other devices that have not yet seen the threat or clearance. (Valluri – Abstract).
Regarding claim 19,
Sundararajan teaches One or more non-transitory computer-readable media storing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising:
identifying, by a first network device located at a first site of a network and based on receiving a data packet, a first firewall policy associated with the first network device ( ¶ 0019 -Source site 110 of system 100 may include a source machine 120 (shown as a client computer), a source router 130, and a first firewall 140 associated with the source site – ¶ 0022 - The source data packet sent from the source machine 120 may arrive at the source router 130. The source
router 130 may check the source data packet and determine whether it has a flow table entry in its header; the flow table entry may indicate that the data packet has previously been seen by the source router 130. If the source data packet is a SYN packet, it would not have a flow table entry as it is its first session with source router 130. Next, per an application policy of the source site 110, the source router 130 may forward the source data packet to the first firewall 140 at the source site 110 for inspection);
inspecting, based at least in part on the first firewall policy and by a first firewall of the network, the data packet by the first network device; adding, by the first network device and based on the metadata, a marker to a header of the data packet to indicate inspection by the first firewall, the marker comprising [..] metadata (¶ 0022 - the source router 130 may forward the source data packet to the first firewall 140 at the source site 110 for inspection. The first firewall 140 may inspect the source data packet and then return the source data packet back to the source router 130. The source router 130 may then mark the source data packet with a marker to indicate firewall inspection has been completed by the first firewall 140. In an embodiment, the source router 130 may mark the source data packet with a flag using TCP options. In an embodiment, the flag may comprise a custom "R"("redirect") flag available in an Options field of the TCP header of the source data packet);
transmitting, via the network, the data packet to a second network device at a second site, wherein the second network device refrains from inspecting the data packet based on the [..] metadata (¶ 0022 - the source router 130 may transmit the source data packet over an encapsulated, encrypted tunnel to the destination site 150. While the description above indicates that the first firewall 140 may inspect the source data packet prior to marking the source data packet by the source router 130. ¶ 0023 - At the destination site 150, the destination router may receive the source data packet. The destination router 160 may determine, based on the existence of the marker, i.e., R flag, that the source data packet has been inspected by a firewall , namely the first firewall 140. the destination router 160 may determine that there is no need to forward the source data packet to its local firewall, i.e., the second firewall 170. As a result, the destination router 160 may cache the flow table entry associated with the source data packet and then forward the source data packet to the destination machine
180 at the destination site 150 without inspection of the source data packet by the second firewall 170 associated with the destination site 150).
However, Sundararajan does not explicitly teach
receiving metadata associated with the first firewall policy from a cloud service of the network and the metadata is Unified threat defense (UTD).
Oswal teaches
receiving metadata associated with the first firewall policy from a cloud service of the network (Col.5, lines 60-70 - processes for determining such meta data information associated with each flow (e.g., App ID, User ID, Device ID, Content ID, and/or other meta data associated with a flow) can be performed at one of the computing devices/elements/locations ( e.g., at the cloud-based security service, such as provided via Prisma Access. Col. 6, lines 4-20 - the cloud-based security service can be provided using a private cloud, one or more public cloud service providers, and/or any combination thereof). The determined meta data information associated with each flow can then be communicated to SD-WAN device. The SD-WAN device perform security policy enforcement, network routing, and/or other actions using the meta data information associated with a given flow).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan to include the teachings of Oswal. The motivation for doing so is to allow system to perform security policy enforcement, network routing, and/or other actions using the meta data information associated with a given flow without having to perform the inspection (Oswal – Col.6, lines 24-30).
Sundararajan in view of Oswal does not explicitly teach that the metadata is UTD metadata.
Valluri teaches
UTD metadata (¶ 0009 - the DNS security platform may maintain a list of IPs and/or domains associated with threats, and once a flow has passed the security platform, it may be processed by a unified threat defense (UTD) policy, which detects threats based on the actual behavior of the application. Claim 10 - receive, via a network controller appliance of a software- defined wide-area network, an upstream update from an edge network device that comprises a threat signature associated with a threat detected by the edge network device; trigger a temporary update to add the detected threat as a negative unified threat defense (UTD) result in a local domain name system (DNS) blacklist; and push a downstream update that comprises the threat signature to other edge network devices that have not
seen the threat).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan in view of Oswal to include the teachings of Valluri. The motivation for doing so is to allow system to push the update including UTD signature to other devices that have not yet seen the threat or clearance. (Valluri – Abstract).
Claims 2,11 are rejected under 35 U.S.C. 103 as being unpatentable Sundararajan in view of Oswal further in view of Valluri further in view of Jain et al. Publication No. US 2018/0097778 A1 ( Jain hereinafter).
Regarding claim 2,
Sundararajan teaches wherein the data packet further comprises an initial data packet of a data flow (¶ 0019, ¶ 0022). However, Sundararajan does not explicitly teach
refraining from adding the marker to subsequent data packets of the data flow.
Jain teaches
wherein the data packet further comprises an initial data packet of a data flow, the method further comprising refraining from adding the marker to subsequent data packets of the data flow (¶ 0080 - The process 900 starts when it receives a new incoming packet from network. In some embodiments, the hardware performs stateless lookup only for the first packet of a L4 connection, ( e.g., the "SYN" packet of a TCP connection). This is because the result of the stateless lookup for "SYN' packet is applicable to all packets of the connection, and the software would not need the result of stateless lookup after the first packet. ¶ 0106 - As there is already an entry for connection D from the previous packet 1212, the conn-track table 525 has a corresponding entry for the connection ( operation labeled ' 6'). Since there is already an entry for the connection in the conn-track table, the stateful engine does not check the rules database but instead rely on the state and status stored in the conn-track table to perform stateful packet classification. ¶ 0050 - the process finds applicable rule by using the information in the metadata or the packet marking of the incoming packet. As mentioned, such metadata can include a rule ID, one or more container IDs, and the hash value of the connection identifiers).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan to include the teachings of Jain. The motivation for doing so is to allow system to perform stateless lookup only for the first packet of a L4 connection (Jain – ¶ 0080).
Regarding claim 11,
Sundararajan teaches wherein the data packet further comprises an initial data packet of a data flow (¶ 0019, ¶ 0022). However, Sundararajan does not explicitly teach
refraining from adding the marker to subsequent data packets of the data flow.
Jain teaches
wherein the data packet further comprises an initial data packet of a data flow, the method further comprising refraining from adding the marker to subsequent data packets of the data flow (¶ 0080 - The process 900 starts when it receives a new incoming packet from network. In some embodiments, the hardware performs stateless lookup only for the first packet of a L4 connection, ( e.g., the "SYN" packet of a TCP connection). This is because the result of the stateless lookup for "SYN' packet is applicable to all packets of the connection, and the software would not need the result of stateless lookup after the first packet. ¶ 0106 - As there is already an entry for connection D from the previous packet 1212, the conn-track table 525 has a corresponding entry for the connection ( operation labeled ' 6'). Since there is already an entry for the connection in the conn-track table, the stateful engine does not check the rules database but instead rely on the state and status stored in the conn-track table to perform stateful packet classification. ¶ 0050 - the process finds applicable rule by using the information in the metadata or the packet marking of the incoming packet. As mentioned, such metadata can include a rule ID, one or more container IDs, and the hash value of the connection identifiers).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan to include the teachings of Jain. The motivation for doing so is to allow system to perform stateless lookup only for the first packet of a L4 connection (Jain – ¶ 0080).
Claims 4,13 are rejected under 35 U.S.C. 103 as being unpatentable Sundararajan in view of Oswal further in view of Valluri further in view of Mao et al. Publication No. US 2003/0065944 A1 ( Mao hereinafter).
Regarding claim 4,
Sundararajan teaches wherein refraining from inspecting the data packet comprises refraining from processing a [..] Firewall inspection by the second network device (¶ 0030). However, Sundararajan does not explicitly teach that the processing inspection is a processing a layer 7 firewall inspection.
Mao teaches
processing inspection is a processing a layer 7 firewall inspection ( ¶ (0013 - The inspection device can be a firewall including a layer 3 firewall device, a layer 4 firewall device and a layer 7 firewall device. The inspection device can be a firewall that filters based on layer information other than layer 2 header information. The controller can determine each packet that is to pass between security zones and the inspection device only processes inter-zone traffic. The controller can determine each packet that is to remain in a single security zone and the inspection device immediately routes intra-zone packets -See Also ¶ 0052).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan to include the teachings of Mao. The motivation for doing so is to allow system to inspect and filter packets identified by the controller based on layer information other than layer header information (Abstract, ¶ 0030- Mao).
Regarding claim 13,
Sundararajan teaches wherein refraining from inspecting the data packet comprises refraining from processing a [..] Firewall inspection by the second network device (¶ 0030). However, Sundararajan does not explicitly teach that the processing inspection is a processing a layer 7 firewall inspection.
Mao teaches
processing inspection is a processing a layer 7 firewall inspection ( ¶ (0013 - The inspection device can be a firewall including a layer 3 firewall device, a layer 4 firewall device and a layer 7 firewall device. The inspection device can be a firewall that filters based on layer information other than layer 2 header information. The controller can determine each packet that is to pass between security zones and the inspection device only processes inter-zone traffic. The controller can determine each packet that is to remain in a single security zone and the inspection device immediately routes intra-zone packets -See Also ¶ 0052).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan to include the teachings of Mao. The motivation for doing so is to allow system to inspect and filter packets identified by the controller based on layer information other than layer header information (Abstract, ¶ 0030- Mao).
Claims 5-6,14-15 are rejected under 35 U.S.C. 103 as being unpatentable Sundararajan in view of Oswal further in view of Valluri further in view of Kevin et al. “Equinix and Cisco Optimize Software Defined Cloud Interconnection” Published on 3/31/2021 ( Kevin hereinafter).
Regarding claim 5,
Sundararajan further teaches
wherein the first network device comprises a [..] router and the second network device comprises a [..] headend device (¶ 0019 - Source site 110 of system 100 may include a source machine 120 (shown as a client computer), a source router 130, and a first firewall 140 associated with the source site 110. Destination site 150 may include a destination machine 180 (shown as a server), a destination router 160, and a second firewall 170 associated with the destination site 150- ¶ 0020 - the destination machine 180 at the destination site 150 may correspond to a server at a corporate data center. System may be applicable to other use cases, as determined by those of skill in the art – Note: the examiner interprets the headend device as a server).
However, Sundararajan does not explicitly teach the SDCI router and SDCI headend device
Kevin teaches the SDCI router and SDCI headend device (Page 2-4, Fig.1).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan to include the teachings of Kevin. The motivation for doing so is to allow the system to directly and securely interconnecting cloud, network and internet service providers. It allows businesses to connect to an SDCI hub via a single physical port and access multiple private and public clouds (Page 1 - Kevin).
Regarding claim 6,
Sundararajan teaches
wherein the network comprises a SDWAN wherein the data packet comprises a header, wherein data included in the header of the data packet is encrypted (¶ 0022 - Then, the source router 130 may transmit the source data packet over an encapsulated, encrypted tunnel to the destination site 150. While the description above indicates that the first firewall 140 may inspect the source data packet prior to marking the source data packet by the source router 130, it is to be understood that in some embodiments, the source router 130 may mark the source data packet before forwarding it to the first firewall 140. In other words, the sequence of certain actions may be modified, without departing from the scope of the present disclosure.. The source router 130 may then mark the source data packet with a marker to indicate firewall inspection has been completed by the first firewall 140. In an embodiment, the source router 130 may mark the source data packet with a flag using TCP options. In an embodiment, the flag may comprise a custom "R" ("redirect") flag available in an Options field of the TCP) -See ¶ 0018 & ¶ 030 – SDWAN network).
However, Sundararajan does not explicitly teach that the network is SDCI WAN.
Kevin teaches
wherein the network comprises a software defined cloud interconnect wide area network (Pages 2-4, Fig.1).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan to include the teachings of Kevin. The motivation for doing so is to allow the system to directly and securely interconnecting cloud, network and internet service providers. It allows businesses to connect to an SDCI hub via a single physical port and access multiple private and public clouds (Page 1 - Kevin).
Regarding claim 14,
Sundararajan further teaches
wherein the first network device comprises a [..] router and the second network device comprises a [..] headend device (¶ 0019 - Source site 110 of system 100 may include a source machine 120 (shown as a client computer), a source router 130, and a first firewall 140 associated with the source site 110. Destination site 150 may include a destination machine 180 (shown as a server), a destination router 160, and a second firewall 170 associated with the destination site 150- ¶ 0020 - the destination machine 180 at the destination site 150 may correspond to a server at a corporate data center. System may be applicable to other use cases, as determined by those of skill in the art – Note: the examiner interprets the headend device as a server).
However, Sundararajan does not explicitly teach the SDCI router and SDCI headend device
Kevin teaches the SDCI router and SDCI headend device (Page 2-4, Fig.1).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan to include the teachings of Kevin. The motivation for doing so is to allow the system to directly and securely interconnecting cloud, network and internet service providers. It allows businesses to connect to an SDCI hub via a single physical port and access multiple private and public clouds (Page 1 - Kevin).
Regarding claim 15,
Sundararajan teaches
wherein the network comprises a SDWAN wherein the data packet comprises a header, wherein data included in the header of the data packet is encrypted (¶ 0022 - Then, the source router 130 may transmit the source data packet over an encapsulated, encrypted tunnel to the destination site 150. While the description above indicates that the first firewall 140 may inspect the source data packet prior to marking the source data packet by the source router 130, it is to be understood that in some embodiments, the source router 130 may mark the source data packet before forwarding it to the first firewall 140. In other words, the sequence of certain actions may be modified, without departing from the scope of the present disclosure.. The source router 130 may then mark the source data packet with a marker to indicate firewall inspection has been completed by the first firewall 140. In an embodiment, the source router 130 may mark the source data packet with a flag using TCP options. In an embodiment, the flag may comprise a custom "R" ("redirect") flag available in an Options field of the TCP) -See ¶ 030 & ¶0018 – SD-WAN network).
However, Sundararajan does not explicitly teach that the network is software defined cloud interconnect wide area network
Kevin teaches
network comprises a software defined cloud interconnect wide area network (Pages 2-4, Fig.1).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan to include the teachings of Kevin. The motivation for doing so is to allow the system to directly and securely interconnecting cloud, network and internet service providers. It allows businesses to connect to an SDCI hub via a single physical port and access multiple private and public clouds (Page 1 - Kevin).
Claims 7,16 are rejected under 35 U.S.C. 103 as being unpatentable Sundararajan in view of Oswal further in view of Valluri further in view of Tai et al. Publication No. WO 2021147372 A1 ( Tai hereinafter).
Regarding claim 7,
Sundararajan further teaches wherein the marker comprises a flag included in [..] metadata in a header of the data packet, wherein the flag is included [--] (¶ 0022, ¶ 0030).
However, Sundararajan does not explicitly teach that the metadata is UTD metadata and the flag is included in a security level tag length value.
Valluri teaches
the metadata is UTD metadata (Fig.5A, ¶ 0055 - in step 502, one or more network controller appliances 132 can receive an upstream message 107a that can include a threat signature 105 associated with the threat detected by the locally - implemented advanced security policies 103b of the particular edge network device 142a. In order to improve response to emerging threats, in step 504, based on a deployed rules-based model, when the threat is detected across one or several edge network devices 142, a temporary update is triggered to add the threat as a negative UTD result collected by the network controller appliance 132 in a local DNS blacklist as the threats are received – See Also Claim 1).
Sundararajan in view of Valluri does not explicitly teach that the flag is included in a security level tag length value
However, Tai teaches
flag is included in a security level tag length value (Fig.5a shows the format of the Flags field in the newly added Security attribute TLV)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan in view of Valluri to include the teachings of Tai. The motivation for doing so is to allow the system to utilize the TLV format because it makes parsing faster and the data smaller than in comparable text based protocol.
Regarding claim 16,
Sundararajan further teaches wherein the marker comprises a flag included in [..] metadata in a header of the data packet, wherein the flag is included [--] (¶ 0022, ¶ 0030).
However, Sundararajan does not explicitly teach that the metadata is UTD metadata and the flag is included in a security level tag length value.
Valluri teaches
the metadata is UTD metadata (Fig.5A, ¶ 0055 - in step 502, one or more network controller appliances 132 can receive an upstream message 107a that can include a threat signature 105 associated with the threat detected by the locally - implemented advanced security policies 103b of the particular edge network device 142a. In order to improve response to emerging threats, in step 504, based on a deployed rules-based model, when the threat is detected across one or several edge network devices 142, a temporary update is triggered to add the threat as a negative UTD result collected by the network controller appliance 132 in a local DNS blacklist as the threats are received – See Also Claim 1).
Sundararajan in view of Valluri does not explicitly teach that the flag is included in a security level tag length value
However, Tai teaches
flag is included in a security level TLV (Fig.5a shows the format of the Flags field in the newly added Security attribute TLV)
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan in view of Valluri to include the teachings of Tai. The motivation for doing so is to allow the system to utilize the TLV format because it makes parsing faster and the data smaller than in comparable text based protocol.
Claims 8,17 are rejected under 35 U.S.C. 103 as being unpatentable Sundararajan in view of Oswal further in view of Valluri further in view of Jazra et al. Publication No. US 2012/0033590 A1 ( Jazra hereinafter).
Regarding claim 8,
Sundararajan further teaches wherein the metadata is added to an SDWAN header of the data packet ( ¶ 0029, ¶ 0022, ¶ 0001)\ However, Sundararajan does not explicitly teach that UTD metadata is added to SDWAN header in tag length format .
Valluri teaches
UTD metadata is added to SDWAN header in format (Fig.5A, ¶ 0055 - in step 502, one or more network controller appliances 132 can receive an upstream message 107a that can include a threat signature 105 associated with the threat detected by the locally-implemented advanced security policies 103b of the particular edge network device 142a. In order to improve response to emerging threats, in step 504, based on a deployed rules-based model, when the threat is detected across one or several edge network devices 142, a temporary update is triggered to add the threat as a negative UTD result collected by the network controller appliance 132 in a local DNS blacklist as the threats are received -See Also Claim 1, Abstract - system may be configured to collect positive and/or negative unified threat defense (UTD) results, deploy a rules-based model that, when a threat or clearance is detected across several SD-WAN edge network devices).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan to include the teachings of Valluri. The motivation for doing so is to allow the system to detect threat across several edge network devices (Abstract - Valluri).
Sundararajan in view of Valluri does not explicitly teach that the format is a tag length value format.
However, Jazra teaches
format is a Tag length value format. (¶ 0032 - A packet that can specify QoS configurations in a recognized format (such as a tag length value TLV format) can also be used with a marker in one of the field headers that identifies packet when initially configuring which parameters to use).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan in view of Valluri to include the teachings of Jazra. The motivation for doing so is to allow the system to utilize the TLV format because it makes parsing faster and the data smaller than in a comparable text based protocol.
Regarding claim 17,
Sundararajan further teaches wherein the metadata is added to an SDWAN header of the data packet ( ¶ 0029, ¶ 0022, ¶ 0001)\ However, Sundararajan does not explicitly teach that UTD metadata is added to SDWAN header in tag length value format .
Valluri teaches
UTD metadata is added to SDWAN header in format (Fig.5A, ¶ 0055 - in step 502, one or more network controller appliances 132 can receive an upstream message 107a that can include a threat signature 105 associated with the threat detected by the locally-implemented advanced security policies 103b of the particular edge network device 142a. In order to improve response to emerging threats, in step 504, based on a deployed rules-based model, when the threat is detected across one or several edge network devices 142, a temporary update is triggered to add the threat as a negative UTD result collected by the network controller appliance 132 in a local DNS blacklist as the threats are received -See Also Claim 1, Abstract - system may be configured to collect positive and/or negative unified threat defense (UTD) results, deploy a rules-based model that, when a threat or clearance is detected across several SD-WAN edge network devices).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan to include the teachings of Valluri. The motivation for doing so is to allow the system to detect threat across several edge network devices (Abstract - Valluri).
Sundararajan in view of Valluri does not explicitly teach that the format is a tag length value format.
However, Jazra teaches
format is a Tag length value format. (¶ 0032 - A packet that can specify QoS configurations in a recognized format (such as a tag length value TLV format) can also be used with a marker in one of the field headers that identifies packet when initially configuring which parameters to use).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan in view of Valluri to include the teachings of Jazra. The motivation for doing SO is to allow the system to utilize the TLV format because it makes parsing faster and the data smaller than in a comparable text based protocol.
Claims 9,18 are rejected under 35 U.S.C. 103 as being unpatentable Sundararajan in view of Oswal further in view of Valluri further in view of Jeong et al. Publication No. WO 2018097422 A1 ( Jeong hereinafter).
Regarding claim 9,
Sundararajan further teaches wherein the metadata includes data indicating whether inspections should be performed on the data packet (¶ 0019 & ¶ 0022). However, Sundararajan does not explicitly teach
metadata includes intelligence data indicating whether additional inspections should be performed on the data packet.
Jeong teaches
metadata includes intelligence data indicating whether additional inspections should be performed on the data packet (Abstract - system for supporting traffic steering triggered by an NSF can comprise an NSF forwarder (NSFF) for: performing a security check on a packet introduced to the system; determining whether an additional check by another NSF is necessary, on the basis of the result of the security check; attaching, to the packet, a packet forwarding header for summoning the additional check if the additional check is necessary – Page 4 Packet Forwarding Header / Encapsulation: The Packet Forwarding Header is used to forward packets from one NSF to another for further inspection. The former NSF(ie, source NSF) constructs a Packet Forwarding Header with an NSF profile of the latter NSF (ie, target NSF), and delivers the packet to the NSFF. The required field may include an action code, a number of metadata, and metadata. In this case, the metadata may include a part or all of the NSF profile, and may be referred to as a spec info field in a Packet Forwarding Header to be described later).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan to include the teachings of Jeong. The motivation for doing so is to allow the system to perform deeper security check when the first inspection indicates a suspicious packet.
Regarding claim 18,
Sundararajan further teaches wherein the metadata includes data indicating whether inspections should be performed on the data packet (¶ 0019 & ¶ 0022). However, Sundararajan does not explicitly teach
metadata includes intelligence data indicating whether additional inspections should be performed on the data packet.
Jeong teaches
metadata includes intelligence data indicating whether additional inspections should be performed on the data packet (Abstract - system for supporting traffic steering triggered by an NSF can comprise an NSF forwarder (NSFF) for: performing a security check on a packet introduced to the system; determining whether an additional check by another NSF is necessary, on the basis of the result of the security check; attaching, to the packet, a packet forwarding header for summoning the additional check if the additional check is necessary – Page 4 Packet Forwarding Header / Encapsulation: The Packet Forwarding Header is used to forward packets from one NSF to another for further inspection. The former NSF(ie, source NSF) constructs a Packet Forwarding Header with an NSF profile of the latter NSF (ie, target NSF), and delivers the packet to the NSFF. The required field may include an action code, a number of metadata, and metadata. In this case, the metadata may include a part or all of the NSF profile, and may be referred to as a spec info field in a Packet Forwarding Header to be described later).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sundararajan in view of Valluri to include the teachings of Jeong. The motivation for doing so is to allow the system to perform deeper security check when the first inspection indicates a suspicious packet.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YOUNES NAJI whose telephone number is (571)272-2659. The examiner can normally be reached Monday - Friday 8:30 AM -5:30 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, Oscar A Louie can be reached on (571) 270-1684. 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.
/YOUNES NAJI/Primary Examiner, Art Unit 2445
Prosecution Insights