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
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/23/2025 has been entered.
The amendment filed 12/23/2025 has been entered. Claims 1-18 are pending. Claims 1 and 8 have been amended.
Response to Arguments
Applicant's arguments filed 12/23/2025 have been fully considered but they are not persuasive.
In that remark, the applicant argued in substance:
That: Shieh, alone or in combination with Mihelich, Jiang, and Hira does not disclose “performing a session lookup for the data packet and creating a hash comprising a 5 tuple and a firewall ID; responsive to a determination that more than one local firewall is available, selecting one local firewall to handle inspection of the SYN packet based on information derived from the hash”
In response to the applicant’s argument Shieh teaches performing a session lookup for the data packet (in [0033], when it receives the packets. The first is to look up the connection to which the packets belong to. It performs a lookup into the session table (e.g., table 251B) to determine if it has previously processed any packets of the connection)
Shieh clearly teaches performing a lookup into the session table.
However, Shieh does not explicitly disclose “creating a hash comprising a 5 tuple and a firewall ID; responsive to a determination that more than one local firewall is available, selecting one local firewall to handle inspection of the SYN packet based on information derived from the hash”
However, Mihelich teaches creating a hash comprising a 5 tuple and a firewall ID (i.e. The five tuples of routing information that may be used by load balancer module 202 to generate the hash value may be source internet protocol (IP) address, destination IP address, protocol, source port, and destination port, [0033]) and use of asymmetric hash of the IP source and destination addresses and TCP/UDP source and destination port numbers. In the context of the hash-based approaches, the result of the hash is used to index into a table containing the VLAN used to direct the packet to the firewall security device and the encoded service group ID, [0161]); responsive to a determination that more than one local firewall is available, selecting one local firewall to handle inspection of the SYN packet based on information derived from the hash (i.e. switch checks its session table for a matching session entry. As described further below, session entries may contain information such as a source port number, a destination port number, a protocol field, a source IP address, a destination IP address, and a VLAN Identification (ID), [0110]) and after switch selects one of firewall security devices 506a-e, switch 500 then processes and sends the data packet to the selected firewall security device using session entry, [0112], and selecting a firewall security device and forwarding the data packets to the selected firewall security device. In an embodiment, load balancing unit 702 may also be configured to create session entries for the data packets that ingress and egress switch 700. These session entries are stored in memory unit 704 of switch 700. In an embodiment, each session entry is 32 bytes and includes an IP source address, an IP destination address, a protocol field, a TCP/UDP port numbers and a VLAN ID, if available. The session entry may also contain a service group number and firewall security device slot VLAN tag (i.e., SvGP/FG VLAN), which associates the service group with the firewall security device that is processing that session, [0132]).
Therefore, Mihelich clearly teaches generate the hash value that contains source internet protocol (IP) address, destination IP address, protocol, source port, and destination port (corresponds to 5 tuple) and firewall security device slot VLAN ID or tag and selecting a firewall security device based on the session entry or hash value and forward the Syn packet to the selected firewall security device.
Based on Shieh in view of Mihelich, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Mihelich to the system of Shieh in order to overcome lack of granularity, which results in imprecise control over the service quality; (ii) limited processing capabilities; and (iii) vulnerability to malicious attacks, such as a Denial of Service (DoS) attack, (Mihelich, [0008]).
Therefore, the combination of Shieh in view of Mihelich clearly make the above limitations obvious.
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.
Claim(s) 1-2, 4, 6-9, and 11-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shieh et al. (US 20130291088) hereinafter Shieh in view of Mihelich et al. (US 20160087938) hereinafter Mihelich.
Regarding claim 1, Shieh teaches a computerized method for directing transmission of a data packet within a distributed cloud computing system (i.e. a network access device (network access device, which may be gateway, [0020]) receives a packet and forwards the packet to a security device for security inspection in cloud computing, [0048]-[0049]), the computerized method comprising: receiving the data packet by a receiving gateway instance deployed within a distributed cloud computing system (i.e. a network access device receives a packet from a source node destined to a destination node, [0049] and network access devices may be located within a physical site or a data center or alternatively, they may be allocated across multiple physical sites or data centers, [0024]); performing a session lookup for the data packet (i.e. when it receives the packets. The first is to look up the connection to which the packets belong to. It performs a lookup into the session table (e.g., table 251B) to determine if it has previously processed any packets of the connection, [0033]); responsive to the session lookup resulting in an error condition (i.e. If it cannot find the connection in the session table, [0033], determining if a peer firewall is available (i.e. if it cannot find an existing connection, decides which of security processing modules 309-311 is able to process the packets, [0042]); responsive to a determination that the peer firewall is available (i.e. the central controller 208 receives the packet, it decides which of security processing modules 309-311 is able to process the packets, and then forwards the packets to the designated security processing module, [0042]).
However, Shieh does not explicitly disclose creating a hash comprising a 5 tuple and a firewall ID; determining if the data packet is a SYN packet; responsive to a determination that the data packet is a SYN packet, determining, via the receiving gateway, whether the local firewall is available; responsive to a determination that more than one local firewall is available, selecting one local firewall to handle inspection of the SYN packet based on information derived from the hash.
However, Mihelich teaches creating a hash comprising a 5 tuple and a firewall ID (i.e. The five tuples of routing information that may be used by load balancer module 202 to generate the hash value may be source internet protocol (IP) address, destination IP address, protocol, source port, and destination port, [0033]) and use of asymmetric hash of the IP source and destination addresses and TCP/UDP source and destination port numbers. In the context of the hash-based approaches, the result of the hash is used to index into a table containing the VLAN used to direct the packet to the firewall security device and the encoded service group ID, [0161]); determining if the data packet is a SYN packet (i.e. a first data packet (e.g., a TCP SYN packet) for a particular session and having source address A and destination address B, [0110]); responsive to a determination that the data packet is a SYN packet, determining whether the local firewall is available (i.e. switches 108a-b are session-aware switches and determine a firewall security device, to which data packet is required to be sent, on the basis of one or more session tables maintained therein, [064]); responsive to a determination that more than one local firewall is available, selecting one local firewall to handle inspection of the SYN packet based on information derived from the hash (i.e. switch checks its session table for a matching session entry. As described further below, session entries may contain information such as a source port number, a destination port number, a protocol field, a source IP address, a destination IP address, and a VLAN Identification (ID), [0110]) and after switch selects one of firewall security devices 506a-e, switch 500 then processes and sends the data packet to the selected firewall security device using session entry, [0112], and selecting a firewall security device and forwarding the data packets to the selected firewall security device. In an embodiment, load balancing unit 702 may also be configured to create session entries for the data packets that ingress and egress switch 700. These session entries are stored in memory unit 704 of switch 700. In an embodiment, each session entry is 32 bytes and includes an IP source address, an IP destination address, a protocol field, a TCP/UDP port numbers and a VLAN ID, if available. The session entry may also contain a service group number and firewall security device slot VLAN tag (i.e., SvGP/FG VLAN), which associates the service group with the firewall security device that is processing that session, [0132]).
Based on Shieh in view of Mihelich, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Mihelich to the system of Shieh in order to overcome lack of granularity, which results in imprecise control over the service quality; (ii) limited processing capabilities; and (iii) vulnerability to malicious attacks, such as a Denial of Service (DoS) attack, (Mihelich, [0008]).
Regarding claim 2, Shieh teaches the data packet is a User Datagram Protocol (UDP) packet (i.e. a sequence of packets from a source computer to a destination, which may be another host, a multicast group, or a broadcast domain. For example, a TCP/IP flow can be uniquely identified by the following parameters within a certain time period: 1) Source and Destination IP address; 2) Source and Destination Port; and 3) Layer 4 Protocol (TCP/UDP/ICMP), [0027]).
Regarding claim 4, Shieh does not explicitly disclose session lookup includes a 5 tuple of the data packet including a Protocol, a Source internet protocol (IP) address, a Destination IP address, a Source Port, a Destination Port, and further includes a designation that indicates to the peer gateway instance that the receiving gateway did not find a session corresponding to the data packet.
However, Mihelich teaches session lookup includes a 5 tuple of the data packet including a Protocol, a Source internet protocol (IP) address, a Destination IP address, a Source Port, a Destination Port (i.e. session entry 706 contains the 5-tuple fields, which include a source IP address, a destination IP address, a protocol field, a source port number (e.g., a TCP source port, a UDP source port or an L4 source port number found in the transport layer header) and a destination port number (e.g., a TCP destination port, a UDP destination port or an L4 destination port number found in the transport layer header), [0138]), and further includes a designation that indicates to the peer gateway instance that the receiving gateway did not find a session corresponding to the data packet (i.e. the FPGA replaces the outer tag and sends the data packet back. After using the Y-tag from the pinhole session, at block 1434, the FPGA sets up a normal 5-T session entry and at block 1436 deletes the pinhole session entry. The fragment session is then set up. At block 1430, if a hit is not found then the process gets redirected, [0190]). Therefore, the limitations of claim 4 are rejected in the analysis of claim 1 above, and the claim is rejected on that basis.
Regarding claim 6, Shieh does not explicitly disclose generating a hash of the firewall session.
However, Mihelich teaches generating a hash of the firewall session (i.e. when a data packet is received at the switch (not shown), the FPGA parses the data packet and retrieves the 5-tuple fields and a VLAN tag. The FPGA then creates four 30-bit registers with the extracted fields and performs a non-linear hash composed of shifts and additions on those four registers to produce a 30-bit value 820. This hash mechanism may be implemented such that a single bit change results in a large change in the resulting hash and produces a more randomized index, [0142]). Therefore, the limitations of claim 6 are rejected in the analysis of claim 1 above, and the claim is rejected on that basis.
Regarding claim 7, Shieh does not explicitly disclose logging a 5 tuple associated with the data packet in a session table.
However, Mihelich teaches logging a 5 tuple associated with the data packet in a session table (i.e. session entry 706 contains the 5-tuple fields, which include a source IP address, a destination IP address, a protocol field, a source port number (e.g., a TCP source port, a UDP source port or an L4 source port number found in the transport layer header) and a destination port number (e.g., a TCP destination port, a UDP destination port or an L4 destination port number found in the transport layer header), [0138]). Therefore, the limitations of claim 7 are rejected in the analysis of claim 1 above, and the claim is rejected on that basis.
Regarding claim 13, Shieh does not explicitly disclose logging a hash of the session and information of the first firewall instance prior to forwarding the data packet to the first local firewall instance.
However, Mihelich teaches logging a hash of the session and information of the first firewall instance prior to forwarding the data packet to the first local firewall instance (i.e. when a data packet is received at the switcw, the FPGA parses the data packet and retrieves the 5-tuple fields and a VLAN tag. The FPGA then creates four 30-bit registers with the extracted fields and performs a non-linear hash composed of shifts and additions on those four registers to produce a 30-bit value 820. This hash mechanism may be implemented such that a single bit change results in a large change in the resulting hash and produces a more randomized index, [0142]). Therefore, the limitations of claim 13 are rejected in the analysis of claim 1 above, and the claim is rejected on that basis.
Regarding claims 8-9, 11-12 and 14, the limitations of claims 8-9, 11-12 and 14 are similar to the limitations of claims 1-2, 4 and 7. Shieh further teaches a non-transitory, computer-medium having logic stored thereon that, upon execution by one or more processors (i.e. A non-transitory computer-readable medium having instructions stored therein, which when executed by a computer, claim 8); responsive to a determination that the peer firewall is not available (i.e. If the tasks cannot be done in a security processing module, for example, due to a resource limitation, system load, or the requirement of a different operation system, [0041]). Therefore, the limitations of claims 8-9, 11-12 and 14 are rejected in the analysis of claims 1-2, 4 and 7 above, and the claims are rejected on that basis.
Claim(s) 3, 5, 10 and 15-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Shieh et al. (US 20130291088) hereinafter Shieh in view of Mihelich et al. (US 20160087938) hereinafter Mihelich and further in view of Hira et al. (US 20200067734) hereinafter Hira.
Regarding claim 3, Shieh in view of Mihelich teach the limitations of claim 1 above.
However, Shieh in view of Mihelich do not explicitly disclose the data packet is received from either a spoke gateway instance or a transit gateway instance, and wherein the spoke gateway instance or the transit gateway instance is deployed within the distributed cloud computing system.
However, Hira teaches the data packet is received from either a spoke gateway instance or a transit gateway instance (i.e. The cloud gateway can also send packets to destinations within an on-premises private datacenter, [0033]), and wherein the spoke gateway instance or the transit gateway instance is deployed within the distributed cloud computing system (i.e. The centralized overlay-network cloud gateway executing in the transit virtual cloud network (VCN), [0002]).
Based on Shieh in view of Mihelich and further in view of Hira, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Hira to the system of Shieh and Mihelich in order to increase packet transmission capability of Shieh and Mihelich system.
Regarding claim 5, Shieh in view of Mihelich teach the limitations of claim 1 above.
However, Shieh in view of Mihelich do not explicitly disclose the distributed cloud computing system includes a controller configured to deploy a first gateway in a spoke VPC network and the receiving gateway instance in a transit VPC network, wherein the receiving gateway instance is configured to connect to one or more local firewall instances deployed within the transit VPC network, and wherein the spoke VPC network and the transit VPC network are both located within a cloud computing network, and logic, stored on non-transitory, computer-medium, that, upon execution by one or more processors, causes performance of operations including: receiving network traffic transmitted between multiple gateways deployed within the distributed cloud computing system, providing the network traffic to a first firewall instance for inspection, and routing the network traffic to a destination VPC network deployed within the cloud computing network.
However, Hira teaches the distributed cloud computing system includes a controller configured to deploy a first gateway in a spoke VPC network and the receiving gateway instance in a transit VPC network (i.e. a cloud gateway 201 in the transit VPC 205. The tunnels in some embodiments use a peering relationship between compute VPC 210 and transit VPC 205 illustrated as network connection. the data message passes through additional managed forwarding elements in one of the compute VPC and the transit VPC or in both the compute and transit VPC between the illustrated MFE and the cloud gateway, [00325]), wherein the receiving gateway instance is configured to connect to one or more local firewall instances deployed within the transit VPC network (i.e. a transit VPC 205 implementing a cloud gateway 201, a set of service compute nodes (SVMs 202A-M), and cloud provider interne gateway 203. FIG. 2 also illustrates an external network 260, an on-premises datacenter 270 (e.g., a datacenter), [0029] and Upon receiving the data message, the MFE performs (at 520) ingress processing. In some embodiments, the ingress processing includes a distributed firewall operation. After ingress processing, in some embodiments the MFE consults an arbiter to determine (at 530) whether the data message requires processing by a cloud gateway executing in the transit VPC, [0044]), and wherein the spoke VPC network and the transit VPC network are both located within a cloud computing network (i.e. forwarding elements in one of the compute VPC and the transit VPC or in both the compute and transit VPC between the illustrated MFE and the cloud gateway, [0032]), and logic, stored on non-transitory, computer-medium, that, upon execution by one or more processors, causes performance of operations including (i.e. the computer-readable media may store a computer program that is executable by at least one processing unit and includes sets of instructions for performing various operations, [0072]): receiving network traffic transmitted between multiple gateways deployed within the distributed cloud computing system (i.e. receiving a data message from a compute node (e.g., a virtual machine or container) destined for another compute node. Different data messages are destined for different compute nodes in different virtual private clouds and require different services, [0043]), providing the network traffic to a first firewall instance for inspection (i.e. upon receiving the data message, the MFE performs (at 520) ingress processing. In some embodiments, the ingress processing includes a distributed firewall operation, [0044]), and routing the network traffic to a destination VPC network deployed within the cloud computing network (i.e. data messages that (1) require a service provided at the overlay cloud gateway or (2) that are destined for VPC for which no peering relationship exists from a source VPC to be routed to the cloud gateway, [0046]).
Based on Shieh in view of Mihelich and further in view of Hira, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Hira to the system of Shieh and Mihelich in order to increase packet transmission capability of Shieh and Mihelich system.
Regarding claims 10 and 15, the limitations of claims 10 and 15 are similar to the limitations of claims 3 and 5. Therefore, the limitations of claims 10 and 15 are rejected in the analysis of claims 3 and 5 above, and the claims are rejected on that basis.
Regarding claim 16, Shieh teaches the peer firewall instance is attached to a peer gateway and the local firewall instance is attached to the receiving gateway (i.e. network access device 204 is associated with a distributed firewall 212 that includes various firewall processing modules, for example, each being executed within a virtual machine (VM). In one embodiment, each firewall module is responsible for performing one or more firewall functions, but it does not include all of the firewall functions of a firewall. Examples of the firewall functions include, but are not limited to, network address translation (NAT), virtual private network (VPN), deep packet inspection (DPI), and/or anti-virus, etc. In one embodiment, some of the firewall processing modules are located within network access device 204 (e.g., firewall modules 209) and some are located external to network access device 204 (e.g., firewall modules 210 maintained by firewall processing node(s) 211, which may be a dedicated firewall processing machine, [0021]).
Regarding claim 17, Shieh in view of Mihelich teach the limitations of claim 1 above.
However, Shieh in view of Mihelich do not explicitly disclose each tunnel of the plurality of network tunnels is associated with a core of a multi-core CPU for performance scaling.
However, Hira teaches each tunnel of the plurality of network tunnels is associated with a core of a multi-core CPU for performance scaling (i.e. tunnels between the MFEs and the cloud gateway are used to forward traffic between compute nodes (e.g., VMs, containers, etc.) that are implemented by different VPCs, [0038] and the processing unit(s) may be a single processor or a multi-core processor, [0068]).
Based on Shieh in view of Mihelich and further in view of Hira, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Hira to the system of Shieh and Mihelich in order to increase packet transmission capability of Shieh and Mihelich system.
Regarding claim 18, the limitations of claim 18 are similar to the limitations of claim 17. Therefore, the limitations of claim 18 are rejected in the analysis of claim 17 above, and the claim is rejected on that basis.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AYELE F WOLDEMARIAM whose telephone number is (571)270-5196. The examiner can normally be reached M_F 8:30AM-5:00PM.
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, Joon H Hwang can be reached on 571-272-4036. 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.
/AW/
AYELE F. WOLDEMARIAM
Examiner
Art Unit 2447
2/4/2026
/SURAJ M JOSHI/Primary Examiner, Art Unit 2447