DETAILED ACTION
This action is in response to communication filed on 8/19/2026.
Claims 1-20 are pending.
Claims 1, 3, 5, 9-11, 15 and 18-19 have been amended.
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 .
Response to Arguments
Applicant’s arguments filed August 19, 2026, have been fully considered but are not persuasive. The Office Action identified the primary reference as Huston et al. (US 2013/0013605). Applicant correctly notes that US 2013/0013605 A1 is a different publication, and that the disclosure quoted in the rejection is Huston et al., US 2013/0031605 A1, issued as US 8,661,522 B2. The citation in the prior action was a transposition of digits. The rejection is maintained over Huston et al., US 2013/0031605, in view of Robert (US 2003/0226032). The teachings relied on are those quoted in the prior action and addressed in the Remarks. Applicant’s request to correct the record is granted. Correction of the publication number, where the body of the rejection quoted the intended disclosure and applicant responded to that disclosure, does not withdraw the rejection.
Applicant argues that amended claims 1, 11, and 18 require the TCP SYN to be transmitted by a protected computing device and the TCP SYN-ACK to be a response intended for that protected computing device, and that both references instead protect a victim server from an inbound SYN flood. This argument is not persuasive.
The amended language does not require a client-side deployment, an outbound-only monitor, or an inverted 4-tuple. Those features are not in claim 1. Claim 1 requires a network monitoring device that protects a computing device, detects a TCP SYN transmitted by that protected computing device, ingests information associated with that SYN into a probabilistic data structure, identifies a TCP SYN-ACK intended for that protected computing device, determines from a query of the structure that the SYN-ACK does not correspond to the request or to the plurality of requests, and drops the SYN-ACK.
Huston discloses a protection system that monitors network traffic to a protected network and protected devices, detects a TCP SYN used to establish a communication session, ingests host information from the SYN into a Bloom filter that stores information for a plurality of such requests, queries that probabilistic structure, and drops a packet that does not complete the corresponding authentication. See Huston, [0004], [0013], [0031], [0038], [0051], and [0055]. Huston also recognizes that handshake responses generated from a connection request can be directed at an innocent device, which Huston describes as a reflected attack, and Huston limits outstanding authentication responses for that reason. See Huston, [0019].
Huston does not, by itself, disclose dropping a received SYN-ACK intended for the protected computing device that transmitted the SYN. In Huston, the protection system sends the SYN-ACK, with a magic sequence number, as the authentication challenge to the external device. See Huston, FIG. 4 and [0038]. That difference is acknowledged. It is supplied by Robert, not by reading Huston alone onto the amended limitation.
Robert discloses processing of incoming TCP signaling packets expressly including SYN and SYN/ACK, mapping those packets with a hash into a probabilistic structure, determining whether a processed packet belongs to a flow initiated by a TCP SYN, and discarding the processed packet when it does not. See Robert, [0033], [0035], [0039], and [0056]. Robert states that incoming signaling packets (SYN, SYN/ACK, FIN, RST) are mapped to buckets by a secret hashing function, and that if the index calculated from a processed packet does not point to a current, previous, or next counter value greater than zero, the processed packet does not belong to any flow initiated by a TCP SYN and will be discarded. See Robert, [0033] and [0039]. Robert also identifies a Bloom filter with keyed hashing as a suitable structure for the insertion and membership query. See Robert, [0035].
The SYN/ACK in Robert is a response in the handshake initiated by the SYN. It is therefore a response intended for the device that transmitted the SYN. The device that transmitted the SYN is a computing device on the monitored connection. In the combination, that device is a computing device protected by the network monitoring device of Huston. The claim does not require the protected computing device to be the server inside Huston’s protected network, and it does not require the SYN to be the external host’s inbound SYN that Huston uses to start authentication. The combination uses Huston’s monitoring device, protected device, and probabilistic filter, and Robert’s identification, membership test, and discard of a SYN/ACK that does not belong to a flow initiated by a TCP SYN.
Applicant’s argument that Robert only matches a SYN to a later FIN, and only in the same direction, is not commensurate with claim 1 and is not persuasive as to the limitations Robert is relied on to teach. Robert lists SYN/ACK among the incoming signaling packets mapped to the hash structure. See Robert, [0033]. The discard rule is not limited to FIN packets. It applies to a processed packet whose index does not point to a live counter, in which case the packet does not belong to a flow initiated by a TCP SYN and is discarded. See Robert, [0039] and [0056]. Claim 1 does not recite sequence-number progression, a FIN, or an inverted comparison of source and destination fields. The fixed-order hash in Robert is relevant to claims 3 and 13. It is not a limitation of claim 1, and it does not remove Robert’s teaching that a SYN/ACK is mapped and that a non-corresponding processed packet is discarded.
Applicant’s hindsight argument is not persuasive. The reason to combine is not taken from applicant’s specification. Huston already monitors session-establishment traffic, already stores SYN-associated information in a Bloom filter, already drops packets that do not correspond to an authenticated request, and already identifies reflected handshake responses as a denial-of-service problem. See Huston, [0013], [0019], [0051], and [0055]. Robert already applies a probabilistic membership test to SYN/ACK signaling packets and already discards a packet that does not belong to a flow initiated by a TCP SYN. See Robert, [0033], [0035], and [0039]. Substituting Robert’s packet-level SYN-correspondence test for, or adding it to, Huston’s host-level filter is the use of a known membership test for the packet type Robert already names, on traffic Huston already inspects, in order to drop a SYN-ACK that does not correspond to a SYN. The result is a predictable use of Robert’s discard rule at Huston’s protection system. See MPEP 2141 and 2143.
The argument that Huston addresses reflection only by limiting outstanding authentication attempts does not show non-obviousness. Huston, paragraph [0019], is evidence that the reflected-response problem was known in this art. It is not an admission that limiting authentication attempts is the only way a person of ordinary skill would address an unsolicited handshake response. Robert provides the correspondence test and the discard.
Claims 2, 12, and 19 do not distinguish the combination. Robert determines that the processed packet does not belong to a flow initiated by a TCP SYN when information recorded for that SYN, the live counter at the computed index, is not found for the processed packet, and Robert discards that packet. See Robert, [0039] and [0056]. Under the broadest reasonable interpretation, that is a determination that information associated with the SYN is absent from the information associated with the processed signaling packet, which Robert identifies as including a SYN/ACK.
The arguments for claims 3 and 13 are not commensurate with claim 1. Claim 1 does not require that the first source address fail to match the second destination address, or any other inverted 4-tuple test. Those arguments do not overcome the rejection of claim 1. The fixed-order hash in Robert, [0047], is not relied on as the inverted comparison of claims 3 and 13.
The arguments for claims 6 and 16 are not commensurate with claim 1. Claim 1 does not require generating a second probabilistic data structure, terminating the first, and changing the designation of the second. Huston’s removal of entries after an idle timeout and Robert’s reset of bucket counts are not relied on for that limitation in claim 1.
Kumar is not relied on for claim 1. The argument that Kumar does not cure the asserted deficiencies of Huston and Robert is moot as to claim 1.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 9/18/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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 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 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 1-9, 11-20 are rejected under 35 U.S.C. 103 as being unpatentable over Huston et al. (US 2013/0013605) in view of Robert (US 2003/0226032).
Regarding claim 1, Huston discloses a system, comprising:
a network monitoring device comprising one or more memory devices storing executable instructions thereon that, when executed by one or more processors, cause the one or more processors to:
monitor network traffic transmitted across a communications network (Huston discloses a protection system that intercepts and processes incoming packets from external devices on the network; [0038] “In the first step 202, an incoming packet from an external host device 102 is intercepted by the protection system 108. The protection system 108 analyzes and validates the packet and applies pre-defined filter rules in step 204. All incoming packets are inspected and validity tests are performed to ensure that the packets are well formed”);
detect, based on the network traffic, at least one first data packet corresponding to a request to establish a communication session, wherein the request is a Transmission Control Protocol synchronize packet (Huston discloses detection of TCP SYN packets as connection establishment requests in the context of SYN flood attacks; [0004] “A common type of DoS attack is the SYN flood attack. A SYN flood exploits the TCP connection establishment protocol to consume state on the victim device. During a SYN flood attack an attacker(s) sends a rapid succession of SYN requests (connection establishment requests) to a victim device”, [0006] “In one example of authentication, after receiving a TCP SYN packet from an external host device, the protection system extracts the sender's internet protocol address (or IP address) from the TCP SYN packet”, [0055] “If the packet is a SYN packet, then the IP address is added to the Bloom filter in step 316 and the protection system 108 begins authentication in step 318”)
transmitted by a protected computing device, the protected computing device being protected by the network monitoring device (Huston discloses that the network monitoring device protects computing devices in the protected network; [0028] “the external host devices 102a, 102b . . . 102n (also referred to as external devices or host devices) attempt to connect to protected devices 114 within a protected network 112”, [0029] “the protected network 112 is protected by a protection system 108 located between the Internet 106 and the protected network 112. Usually, the protected network is an enterprise network, such as a school network, business network, and government network, to list a few examples”, [0035] “the protection system 108 authenticates all external host devices 102a, 102b . . . 102n before allowing the external devices to access the protected devices 114 within the protected network 112”);
responsive to detection of the at least one first data packet, ingest first information associated with the at least one first data packet into a probabilistic data structure, wherein the probabilistic data structure is configured to store one or more sets of information that correspond to a plurality of requests (Huston discloses ingesting source IP address information from the SYN packet into a Bloom filter (probabilistic data structure) that tracks multiple hosts/requests; [0013] “The solution proposed here is the implementation of a probabilistic filter such as a Bloom filter to track which host devices are attempting to access the protected network. New addresses are added to a Bloom filter to track which hosts addresses are being authenticated. A Bloom filter is a space-efficient probabilistic data structure that is used to test whether an element is a member of a set”, [0051] “In a preferred embodiment, the protection system 108 uses a Bloom filter as the probabilistic filter pf”, [0055] “If the packet is a SYN packet, then the IP address is added to the Bloom filter in step 316 and the protection system 108 begins authentication in step 318”).
However, the prior art does not explicitly disclose the following:
identify, based on at least one of the network traffic or subsequently generated network traffic, at least one second data packet corresponding to a response intended for the protected computing device, wherein the response is a Transmission Control Protocol synchronize-acknowledge packet;
determine, responsive to a query of the probabilistic data structure, that the response does not correspond to either (i) the request or (ii) the plurality of requests; and
drop, responsive to determination that the response does not correspond to either (i) the request or (ii) the plurality of requests, the at least one second data packet from the communications network.
Roberts in the fields of the same endeavor disclose techniques for using hashing including Bloom-filter structures) on TCP signaling packets (explicitly including SYN and SYN/ACK) to determine correspondence to a flow initiated by a TCP SYN and discarding non-corresponding packets. In particular, Roberts teaches the following:
identify, based on at least one of the network traffic or subsequently generated network traffic, at least one second data packet corresponding to a response, wherein the response is a Transmission Control Protocol synchronize-acknowledge packet (Robert disclose processing of TCP signaling packets that include SYN/ACK; [0033] “…incoming signaling packets (SYN, SYN/ACK, FIN, RST) can be mapped to buckets by a secret hashing function and the statistics can be maintained on each bucket, rather than the entire system”);
determine, responsive to a query of the probabilistic data structure, that the response does not correspond to either (i) the request or (ii) the plurality of requests (Robert discloses querying the hash structure (and notes Bloom filters) to determine whether a packet belongs to a flow initiated by a TCP SYN and if not, discard the packet; [0035] “any efficient data structures supporting insertion, membership queries and optionally, deletion could be used (e.g. Bloom-filter with keyed hashing functions)”, [0039] “If the index value calculated from a processed packet does not point to a current, previous, or next counter value that is greater than zero, then the processed packet does not belong to any flow initiated by a TCP SYN packet, and the processed packet will be discarded”, [0056] “The value SN refers to the packet sequence number. If this is the case, the packet is accepted. Otherwise, the packet is not recognized as belonging to the flow initiated by the TCP SYN packet”); and
drop, responsive to determination that the response does not correspond to either (i) the request or (ii) the plurality of requests, the at least one second data packet from the communications network (Robert discloses querying the hash structure (and notes Bloom filters) to determine whether a packet belongs to a flow initiated by a TCP SYN and if not, discard the packet; [0039] “if the index value calculated from a processed packet does not point to a current, previous, or next counter value that is greater than zero, then the processed packet does not belong to any flow initiated by a TCP SYN packet, and the processed packet will be discarded”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to combine Huston’s protection system and Bloom-filter tracking with Robert’s mapping and discard of a SYN/ACK that does not belong to a flow initiated by a TCP SYN. Huston [0005] discloses a protection system installed between the protected network and external networks that authenticates new connection requests to a host device within the protected network. Huston [0009] discloses that authentication responses can flood an innocent third-party device, “known as a reflected attack.” Huston [0013] and [0055] disclose storing SYN-associated address information in a Bloom filter. Robert [0033] and [0039] disclose mapping a SYN/ACK to the probabilistic structure and discarding a processed packet that does not belong to a flow initiated by a TCP SYN. Applying Robert’s correspondence test at Huston’s protection system, so that a SYN transmitted by a computing device the system protects is recorded and a SYN-ACK intended for that device is dropped when the query shows no corresponding request, is a predictable use of Robert’s discard rule on the session-establishment traffic Huston already inspects.
Regarding claim 2, Huston-Robert discloses the system of claim 1, wherein the executable instructions further cause the one or more processors to:
determine that the response does not correspond to the request based on second information associated with the Transmission Control Protocol synchronize packet being absent from third information associated with the Transmission Control Protocol synchronize-acknowledge packet (Robert [0039] “If the index value calculated from a processed packet does not point to a current, previous, or next counter value that is greater than zero, then the processed packet does not belong to any flow initiated by a TCP SYN packet, and the processed packet will be discarded”, [0056] “The value SN refers to the packet sequence number. If this is the case, the packet is accepted. Otherwise, the packet is not recognized as belonging to the flow initiated by the TCP SYN packet”, [0061] “If the previous bucket is also empty it is determined whether the next bucket is empty. If it is the packet is rejected otherwise it is accepted”); or
determine that the response does not correspond to the plurality of requests based on fourth information associated with corresponding Transmission Control Protocol synchronize packets for the plurality of requests being absent from the third information (Huston [0017] “For the preferred filters, if the source addresses match an address in the filter, then search results for the source address will always return true, but if the source addresses do not match an address in the filter, then search results return false, but there is the possibility the search results could return true”, [0051] “With Bloom filters, false positives are possible, but false negatives are not. That is, it is possible for a search of the Bloom filter to indicate that an element exists in the Bloom filter even when it does not. The bloom filter will never indicate, however, that an element does not exist in the bloom filter when it actually does”).
Regarding claim 3, Huston-Robert discloses the system of claim 1,
Wherein the first information associated with the at least one first data packet represents a first 4-tuple which includes (i) a first source Internet Protocol address, (ii) a first destination Internet Protocol address, (iii) a first source Transmission Control Protocol port, and (iv) a first destination Transmission Control Protocol port (Robert discloses using the source IP, destination IP, source port, and destination port as the input parameters for hashing TCP packets; [0034] “The mapping function could hash [source IP, destination IP, destination port, key] to n buckets”, [0047] “the hash uses the following input parameters (SecretValue, IP.sub.SOURCE, IP.sub.DEST, Port.sub.SOURCE, Port.sub.DEST)”);); and
Wherein second information associated with the at least one second data packet represents a second 4-tuple which includes (v) a second source Internet Protocol address, (vi) a second destination Internet Protocol address, (vii) a second source Transmission Control Protocol port, and (viii) a second destination Transmission Control Protocol port (Robert discloses using the source IP, destination IP, source port, and destination port as the input parameters for hashing TCP packets; [0039] “Information in the packets such as source and destination IP addresses, port numbers and a secret key are used to calculate a value using a hash function”, [0047] “the hash uses the following input parameters (SecretValue, IP.sub.SOURCE, IP.sub.DEST, Port.sub.SOURCE, Port.sub.DEST)”);
wherein the executable instructions further cause the one or more processors to:
determine that the response does not correspond to the request based on at least one of: the first source Internet Protocol address not matching the second destination Internet Protocol address; the first destination Internet Protocol address not matching the second source Internet Protocol address; the first source Transmission Control Protocol port not matching the second destination Transmission Control Protocol port; or the first destination Transmission Control Protocol port not matching the second source Transmission Control Protocol port (Robert discloses that the hash is computed from the full set of IP and port fields and that a packet is determined not to correspond (and is rejected when the computed index does not match an entry associated with a prior SYN. Because the hash incorporates all four fields, a mismatch is any one of the inverted fields produces a non-matching hash and therefore non-correspondence; [0039] “If the index value calculated from a processed packet does not point to a current, previous, or next counter value that is greater than zero, then the processed packet does not belong to any flow initiated by a TCP SYN packet, and the processed packet will be discarded”, [0056] “If this is the case, the packet is accepted. Otherwise, the packet is not recognized as belonging to the flow initiated by the TCP SYN packet”).
Regarding claim 4, Huston-Robert discloses the system of claim 1, wherein the probabilistic data structure is a bloom filter (Huston [0013] “The solution proposed here is the implementation of a probabilistic filter such as a Bloom filter to track which host devices are attempting to access the protected network. New addresses are added to a Bloom filter to track which hosts addresses are being authenticated. A Bloom filter is a space-efficient probabilistic data structure that is used to test whether an element is a member of a set”), and wherein the executable instructions further cause the one or more processors to:
extract, from the first information associated with the at least one first data packet, a 4-tuple which identifies at least one Internet Protocol address and at least one Transmission Control Protocol port (Robert [0034] “The mapping function could hash [source IP, destination IP, destination port, key] to n buckets…In fact, any efficient data structures supporting insertion, membership queries and optionally, deletion could be used (e.g. Bloom-filter with keyed hashing functions)”, [0047] “the hash uses the following input parameters (SecretValue, IP.sub.SOURCE, IP.sub.DEST, Port.sub.SOURCE, Port.sub.DEST). Such function can be based on one-way hashing functions like MD5 or SHA-1.”);
generate, responsive to execution of a hash function, a hash value to represent the 4-tuple (Huston [0015] “the method includes determining source addresses of the packets received from the external devices and adding the source addresses of the external devices to the filter if the source addresses are not already in the filter”, [0055] “If the packet is a SYN packet, then the IP address is added to the Bloom filter in step 316 and the protection system 108 begins authentication in step 318”); and
ingest, responsive to generation of the hash value, the hash value into the bloom filter (Robert [0050-0051] “Insert an element--e.g. by adding 1 to a counter--in the table entry at index
Hash (SecretValue, IP.sub.SOURCE, IP.sub.DEST, Port.sub.SOURCE, Port.sub.DEST)+Floor (ISN.sub.SOURCE/(TCP Window Size*t)) where t is some confidence number set to 2.sup.10. The Floor function can be defined as follow: Floor(x)=the greatest integer smaller than or equal to x”).
Regarding claim 5, Huston-Robert discloses the system of claim 1, wherein the executable instructions further cause the one or more processors to:
generate, responsive to execution of a hash function using the first information, a first hash value which represents the first information (Robert [0034] “The mapping function could hash [source IP, destination IP, destination port, key] to n buckets”, [0047] “the hash uses the following input parameters (SecretValue, IP.sub.SOURCE, IP.sub.DEST, Port.sub.SOURCE, Port.sub.DEST)”);
store, responsive to generation of the first hash value, the first hash value in the probabilistic data structure (Robert [0049-0050] “Upon reception of a TCP SYN packet with ISN.sub.SOURCE as initial sequence number, update the table T as follows… Insert an element--e.g. by adding 1 to a counter--in the table entry at index Hash (SecretValue, IP.sub.SOURCE, IP.sub.DEST, Port.sub.SOURCE, Port.sub.DEST)+Floor (ISN.sub.SOURCE/(TCP Window Size*t))”), wherein the probabilistic data structure includes a plurality of hash values (Robert [0034] “any efficient data structures supporting insertion, membership queries and optionally, deletion could be used (e.g. Bloom-filter with keyed hashing functions)”), and wherein a respective hash value of the plurality of hash values represents information for a corresponding request of the plurality of requests (Houston [0013] “New addresses are added to a Bloom filter to track which hosts addresses are being authenticated. A Bloom filter is a space-efficient probabilistic data structure that is used to test whether an element is a member of a set”, [0055] “If the packet is a SYN packet, then the IP address is added to the Bloom filter in step 316”);
generate, responsive to execution of the hash function using second information associated with the at least one second data packet, a second hash value which represents the second information (Robert [0033] “incoming signaling packets (SYN, SYN/ACK, FIN, RST) can be mapped to buckets by a secret hashing function and the statistics can be maintained on each bucket, rather than the entire system. A simple counter can be incremented on SYNs and decremented on FINs for each bucket. This way there can at least be a statistical correspondence between SYNs and FINs, and without knowledge of the mapping function, the attacker would have no way of faking the FINs to map to the same bucket (without corresponding to the same SYN)”, [0052-0056] “For each subsequent packet of the connection… Hash (SecretValue, IP.sub.SOURCE, IP.sub.DEST, Port.sub.SOURCE, Port.sub.DEST)+Floor (SN/(TCP Window Size*t))+1 (refer to as the next bucket) is greater than 0”); and
determine, responsive to a determination that the probabilistic data structure does not include the second hash value, that the response does not correspond to the request or the plurality of requests (Robert [0039] “If the index value calculated from a processed packet does not point to a current, previous, or next counter value that is greater than zero, then the processed packet does not belong to any flow initiated by a TCP SYN packet, and the processed packet will be discarded”, [0056] “Otherwise, the packet is not recognized as belonging to the flow initiated by the TCP SYN packet”).
Regarding claim 6, Huston-Robert discloses the system of claim 1, wherein the executable instructions further cause the one or more processors to:
modify, subsequent to a first amount of time having elapsed, a designation for the probabilistic data structure (Huston [0015] “The addresses of the external devices stored in the filter are overwritten after a predefined period of inactivity of the external devices”);
generate, responsive to modification of the designation, a second probabilistic data structure configured to store information associated with one or more subsequent requests to establish communication (Huston [0033] “Additionally, the protection system 108 includes an idle timeout length for entries stored in the host table ht. The idle timeout length is the length of time an entry remains in the host table before the entry is removed or overwritten by whitelisted entries. During normal operation the default timeout is sixty seconds, but when the protection system 108 is under attack the idle timeout length is reduced to five seconds. The purpose of the shortened idle timeout length is to continually free up system resources of the protection system 108 during an attack. The continual turnover of entries in the host table ht occurs because the protection system 108 treats all external host devices 102 as threats until authenticated”);
replace, subsequent to a second amount of time having elapsed, the probabilistic data structure with the second probabilistic data structure by: terminating the probabilistic data structure (Huston [0043] “When the protection system 108 is under attack, the timeout length and pending length for entries in the host table is shortened, to less than ten seconds and preferably about four seconds, for example. The timeout length is shortened so that the protection system is continually replacing older entries with new entries and freeing up system resources”); and
changing the second probabilistic data structure to the designation (Robert [0040] “Typically, the bucket counts are reset at the end of the time interval which will be either a continuous sliding window or a non-overlapping sliding window”).
Regarding claim 7, Huston-Robert discloses the system of claim 1, wherein the executable instructions further cause the one or more processors to:
apply one or more tags to the first information associated with the at least one first data packet, wherein the one or more tags identify an amount of time to store the first information in the probabilistic data structure (Huston [0033] “Additionally, the protection system 108 includes an idle timeout length for entries stored in the host table ht. The idle timeout length is the length of time an entry remains in the host table before the entry is removed or overwritten by whitelisted entries. During normal operation the default timeout is sixty seconds, but when the protection system 108 is under attack the idle timeout length is reduced to five seconds”); and
cause, responsive to the amount of time having elapsed, a removal of the first information from the probabilistic data structure (Huston [0043] “When the protection system 108 is under attack, the timeout length and pending length for entries in the host table is shortened, to less than ten seconds and preferably about four seconds, for example. The timeout length is shortened so that the protection system is continually replacing older entries with new entries and freeing up system resources”).
Regarding claim 8, Huston-Robert discloses the system of claim 1, wherein the probabilistic data structure includes a plurality of hash values which represent the request and the plurality of requests (Huston [0013] “The solution proposed here is the implementation of a probabilistic filter such as a Bloom filter to track which host devices are attempting to access the protected network. New addresses are added to a Bloom filter to track which hosts addresses are being authenticated. A Bloom filter is a space-efficient probabilistic data structure that is used to test whether an element is a member of a set”), and wherein the executable instructions further cause the one or more processors to:
generate, responsive to execution of a hash function, a hash value for second information associated with the at least one second data packet (Robert [0039] “If the index value calculated from a processed packet does not point to a current, previous, or next counter value that is greater than zero, then the processed packet does not belong to any flow initiated by a TCP SYN packet, and the processed packet will be discarded”);
query the probabilistic data structure using the hash value (Robert [0056] “f this is the case, the packet is accepted. Otherwise, the packet is not recognized as belonging to the flow initiated by the TCP SYN packet”); and
determine, based on the query not returning any matches, that the response does not correspond to either (i) the request or (ii) the plurality of requests (Huston [0055] “If the IP address was in the bloom filter (from step 302) then the protection system 108 determines if the packet completes authentication in step 320. If the packet does not complete authentication then the packet is dropped in step 322”).
Regarding claim 9, Huston-Robert discloses the system of claim 1, wherein the communications network is a protected network that includes the protected computing device, wherein the network monitoring device is included in the protected network, and wherein the executable instructions further cause the one or more processors to:
determine, prior to transmission across the protected network, that the at least one first data packet corresponds to the protected computing device (Huston [0040] “If the address is whitelisted, then the packet is allowed to continue to the destination in step 212. Likewise, packets from other whitelisted devices are allowed to continue to their destination unimpeded once authenticated”); and
forward the at least one first data packet to a device which was identified by the at least one first data packet (Huston [0056] “Once whitelisted, all future packets from that IP address will be allowed to continue to their destination”).
Regarding claim(s) 11-17 and 18-20, do(es) not teach or further define over the limitation in claim(s) 1-7 and 1-2, 4 respectively. Therefore claim(s) 11-17 and 18-20, is/are rejected for the same rationale of rejection as set forth in claim(s) 1-7 and 1-2, 4 respectively.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Huston et al. (US 2013/0013605) in view of Robert (US 2003/0226032) in view of Kumar et al. (US 2017/0171159).
Regarding claim 10, Huston-Robert discloses the invention substantially, however the prior art does not explicitly discloses the system of claim 1, wherein the executable instructions further cause the one or more processors to:
determine that the at least one first data packet is associated with the protected computing device; and
apply one or more tags to the first information to indicate that the at least one first data packet is associated with the protected computing device.
Kumar in the field of the same endeavor discloses techniques for monitoring network requests from a machine. In particular, Kumar teaches the following:
wherein the at least one first data packet is transmitted by a computing device protected by the network monitoring device (Kumar [0041] “the transport layer 242 establishes the connection and maintains the state (for TCP connections) for the connection. The transport layer 242 creates a synchronization (SYN) packet with a 5-tuple (i.e., source IP address, source port, destination IP address, destination port, protocol) to be sent to the destination server”), and wherein the executable instructions further cause the one or more processors to:
determine that the at least one first data packet is associated with the protected computing device (Kumar [0047] “interception module 262 of some embodiments intercepts the network request at the socket layer 235 in order to capture context information (e.g., application and/or user information for the user or application that initiated the network request) and intercepts the network request again at the transport layer 242 in order to capture connection information (e.g., source/destination addresses, ports, protocol, etc.)”); and
apply one or more tags to the first information to indicate that the at least one first data packet is associated with the computing device (Kumar [0052] “The interception module 262 captures the incoming request packets at the transport layer 242 and tagging module 264 tags the request packets in the buffer 255. Tagging module 264 also stores a mapping of the tag value to current packet information (e.g., 5-tuple) in the security storage 266”).
Therefore, it would have been obvious to a person of ordinary skill in the art at the time the invention was effectively filed to combine the prior art with Kumar. One would have been motivated enable the monitoring system to accurately distinguish and preserver association information for legitimate SYN requests generated by its own protected devices while still efficiently drooping unsolicited SYA-ACK floods).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
For the reason above, claims 1-20 have been rejected and remain pending.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JIMMY H TRAN whose telephone number is (571)270-5638. The examiner can normally be reached Monday-Friday 9am-5pm PST.
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, Chris Parry can be reached at 571-272-8328. 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.
JIMMY H TRAN
Primary Examiner
Art Unit 2451
/JIMMY H TRAN/Primary Examiner, Art Unit 2451
Prosecution Insights