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
This final office action is prepared in response to amendments and arguments filed by Applicant on June 16, 2026 as a reply to the non-final office action mailed on May 29, 2026.
Claims 1-20 are pending.
Claims 1-20 are rejected.
Response to Arguments
The claim amendments and Applicant’s arguments filed on June 16, 2026 have been carefully considered but deemed unpersuasive in view of the new grounds of rejection as set forth below, necessitated by Applicant’s substantial amendments to the claims which significantly affected the scope thereof, and will require further search and consideration.
Accordingly, THIS ACTION IS MADE FINAL. See MPEP 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
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-5, 7-14 and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Pazi et al. (U.S. 2003/0110274) and in view of Shimada et al. (US 2018/0176248).
Regarding claim 1, Pazi disclosed a system comprising:
a network monitoring device connected to a communications network, the network monitoring device configured to monitor network traffic transmitted to and from a server across the communications network (Pazi, Fig. 1 and [0030] disclosed a guard device 28, which anticipates the “network monitoring device” in the claim), the network monitoring device comprising one or more processors coupled with memory, the memory storing executable instructions that, when executed by the one or more processors, cause the one or more processors to:
detect, based on the network traffic, a plurality of data packet exchanges between the server and a plurality of network devices (Pazi disclosed in Fig. 2 and [0048] that “the guard device receives an incoming packet from the network, at a packet interception step 40.” and in [0007] that “a network guard system screens the number of hops traversed by incoming packets in order to assess which packets constitute legitimate network traffic, and which are spoofed”), the plurality of data packet exchanges representing establishments of communication sessions between the server and the plurality of network devices (Pazi disclosed in [0048] that “guard device 28 may become active when it detects an unusually large number of incoming TCP SYN-ACK or DNS request packets.” According to the TCP protocol standard, TCP SYN-ACK packets are the packets exchanged between a source device and a destination device to establish a TCP connection/session);
while operating in an observation mode:
extracting, from first information associated with the plurality of data packet exchanges, a plurality of time to live (TTL) values that correspond to the plurality of data packet exchanges (Pazi disclosed in [0007] that “in IP networks, the number of hops is indicated by the TTL field in the header of each packet” and in [0021] that “In a preferred embodiment, receiving the data packet includes receiving an Internet Protocol (IP) packet, and reading the value of the field includes reading a Time-To-Live (TTL) of the IP packet.” The IP header disclosed by Pazi may anticipate the ”first information” in the claim. Note that this is other possible interpretation of “first information”); and
storing, responsive to extraction of the plurality of TTL values, second information that represents the plurality of TTL values in a data structure (Pazi disclosed in [0007] that “The guard system stores records of IP source addresses together with the expected TTL value (or number of hops) of packets arriving from each source address”), the data structure configured to store the second information according to a Classless Inter-Domain Routing (CIDR) block that indicates a list of internet protocol (IP) addresses associated with the communications network (Pazi further disclosed in [0047] that “database 30 may hold TTL values by subnet (a TTL value for each different 24-bit IP address prefix, for example), in addition to or instead of entries for individual IP source addresses.” Said “subnet” or “each different 24-bit IP address prefix” anticipates the CIDR block in the claim); and
responsive to detecting an ongoing attack condition, change operation from the observation mode to an idle mode in which the one or more processors prevent storage of information associated with subsequently established communication sessions (Pazi disclosed in [0056] that “guard device 28 limits the number of new source addresses that it will validate during any given period of time. Otherwise, a hacker could bombard the guard device with packets from so many new addresses requiring validation, that the guard device might be unable to process the flow of legitimate packets” which means that the guard device can stop storing information into the database 30 during a DDoS attack); and
responsive to operating in a mitigation mode, allow network traffic associated with TTL values that are within the TTL value ranges to bypass an authentication process, and subject network traffic associated with TTL values that are outside of the TTL value ranges to the authentication process (Pazi disclosed in Fig. 2 and [0055] that when guard device 28 has received a suspect packet for which there is no entry in database 30, or does not match stored value in step 42, the guard device follows the “no” branch and attempts to verify that the TTL value of the packet is correct, at a TTL validation step 48, which is disclosed in detail in Pazi, Fig. 3. Pazi’s validation step corresponds to the “authentication process” in the claim. Pazi’s Fig. 3 also shows that packets with IP/TTL correspondence that matches stored value (i.e. the packets with TTL values within the stored range) are delivered by following the “yes” branch without having to go through the validation step 48).
Pazi might not have disclosed that
prior to any detection of an attack condition, build TTL value ranges only for communication sessions successfully established by:
extracting, from first information associated with the plurality of data packet exchanges, a plurality of time to live (TTL) values that correspond to the plurality of data packet exchanges ();
analyzing the plurality of TTL values to determine one or more statistical metrics, the TTL value ranges based on the one or more statistical metrics;
However, Shimada disclosed a source address-fabricated packet detection unit that detects a packet with a fabricated source IP address (Shimada, Abstract). In particular, Shimada disclosed
prior to any detection of an attack condition, build TTL value ranges only for communication sessions successfully established by:
extracting, from first information associated with the plurality of data packet exchanges, a plurality of time to live (TTL) values that correspond to the plurality of data packet exchanges (Shimada, Abstract, [0011, 0078], “a packet controller that controls the input/output of a packet and acquires a source address and time to live of the input packet”);
analyzing the plurality of TTL values to determine one or more statistical metrics, the TTL value ranges based on the one or more statistical metrics (Shimada, Abstract, Fig. 5 and [0023, 0025, 0079], “a reference TTL value calculation section that calculates a reference TTL value for each source IP address based on the TTL value that the TTL value storage section has stored for each source IP address” and “the reference TTL value table stores reference TTL values indicating a normal TTL value range for each source IP address in correspondence with the respective source IP addresses.”);
One of ordinary skill in the art would have been motivated to combine Pazi and Shimada, before the effective filing date of the claimed invention, because both references disclosed the need to detect spoofed IP packets and denial of service attacks by looking into the TTL values (i.e. hop counts) that corresponds to a source IP address (Pazi, [0004]; Shimada, Abstract).
Therefore, it would have been obvious for one of ordinary skill in the art to combine Pazi with Shimada teaching to realize that the reference TTL values in Pazi could be represented by the reference TTL in Shimada that is a TTL value range as shown in Shimada’s Fig. 5.
Claim 10 lists substantially the same elements as claim 1 in method form rather than system form. Therefore, the rejection rationale for claim 1 applies equally as well to claim 10.
Claim 18 lists substantially the same elements as claim 1 in computer readable storage medium form rather than system form. Therefore, the rejection rationale for claim 1 applies equally as well to claim 18.
Regarding claims 2, 11 and 19, Pazi and Shimada disclosed the subject matter of claims 1, 10 and 18.
Pazi might not have explicitly disclosed
wherein the instructions cause the one or more processors to determine that the network characteristic of the monitored network traffic satisfies the condition by:
determining a first number of data packet exchanges included in the plurality of data packet exchanges; determining, based on the network traffic, a second number of data packet exchanges associated with failures to establish communication between the server and one or more network devices; and detecting, based on a difference between the first number of data packet exchanges and the second number of data packet exchanges, an attack on the communications network.
However, Pazi disclosed in paragraph [0048] that “guard device 28 may become active only under stress conditions, in which a DDoS attack on server 22 is suspected, due to particularly heavy incoming traffic or to other traffic statistics. In this case, some additional trigger is required for step 40. For example, guard device 28 may become active when it detects an unusually large number of incoming TCP SYN-ACK or DNS request packets.”
Pazi’s disclosure would have made it obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention that an unusually large number of incoming TCP SYN-ACK or DNS request packets is an indication of failure to establish TCP connections between the server and one or more network devices. Therefore, Pazi’s disclosure would have made the subject matter in claim 2 obvious.
Regarding claims 3, 12 and 20, Pazi and Shimada disclosed the subject matter of claims 1, 10 and 18.
Pazi further disclosed wherein the instructions cause the one or more processors to determine that the network characteristic of the monitored network traffic satisfies the condition by:
selecting, based on one or more rules, a subset of data packet exchanges of the plurality of data packet exchanges; executing, responsive to selection of the subset of data packet exchanges, an authentication routine to evaluate the subset of data packet exchanges; determining a number of data packet exchanges of the subset of data packet exchanges identified as non-malicious during the authentication routine; and determining that the number of data packet exchanges exceeds a predetermined threshold (Pazi disclosed in [0051] that “ guard device 28 may validate an IP source address based on the TTL value. … the IP source address may be validated if the fraction of packets arriving from the address that have the correct TTL value is reasonably large (say 20%).”).
Even though Pazi did not explicitly disclose identifying malicious packets based on the number exceeding a predetermined threshold, Pazi’s disclosure in para. [0051] of a method for identifying valid (i.e. non-malicious) packets based on the number of valid data packets exceeding a predetermined threshold would have made it obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention that malicious traffic could be similarly identified based on the number of malicious data packets exceeding a predetermined threshold.
Regarding claims 4 and 13, Pazi and Shimada disclosed the subject matter of claims 1 and 10.
Pazi further disclosed wherein the instructions cause the one or more processor to determine that the network characteristic of the monitored network traffic satisfies the condition by:
extracting, from the first information, a plurality of IP addresses associated with the plurality of network devices (Pazi disclosed in [0007] that “The guard system stores records of IP source addresses together with the expected TTL value (or number of hops) of packets arriving from each source address”); and
determining that a number of IP addresses of the plurality of IP addresses that represent a predetermined IP address type exceed a predetermined threshold (Pazi, [0051], “the IP source address may be validated if the fraction of packets arriving from the address that have the correct TTL value is reasonably large (say 20%).”).
Regarding claims 5 and 14, Pazi and Shimada disclosed the subject matter of claims 1 and 10.
Pazi further disclosed wherein the instructions cause the one or more processors to:
determine that the network characteristic of the monitored network traffic satisfies the condition responsive to receipt of an indication of an attack from a computing device (Pazi disclosed in [0048] that “guard device 28 may become active only under stress conditions, in which a DDoS attack on server 22 is suspected, due to particularly heavy incoming traffic or to other traffic statistics”. Said “stress conditions” anticipates the “condition” in the claim);
obtain, responsive to monitoring of the communications network subsequent to the determination, a plurality of data packets corresponding to a second plurality of data packet exchanges with the server (Pazi, [0050], “Guard device 28 checks the IP source address of the incoming packet against database 30, at a record checking step 42.” Said “incoming packet” anticipates the plurality of data packets);
identify, based on information included in the plurality of data packets, a plurality of IP addresses associated with the plurality of data packets (Pazi, [0050], “Guard device 28 checks the IP source address of the incoming packet against database 30, at a record checking step 42); and
determine, based on a difference between one or more TTL values associated with the plurality of IP addresses and the second information that represents the plurality of TTL values, that one or more IP addresses are malicious (Pazi disclosed in [0050] that “the guard device checks the TTL value held in the database against the TTL value recorded in the packet header” and in [0054] that “ If the TTL value of the incoming packet does not match a value in database 30 (either because there is no entry for the IP source address of the packet, or because the TTL value in the database is different), guard device 28 treats the packet as suspect, at an invalid packet processing step 46”).
Regarding claims 7 and 16, Pazi and Shimada disclosed the subject matter of claims 1 and 10.
Pazi further disclosed wherein the instructions cause the one or more processors to:
determine that the network characteristic of the monitored network traffic satisfies the condition responsive to a predetermined amount of time (Pazi disclosed in [0048] that “guard device 28 may become active when it detects an unusually large number of incoming TCP SYN-ACK or DNS request packets.”); and
transmit, via one or more signals, the second information that represents the plurality of TTL values to a computing device, wherein the computing device is configured to subsequently monitor the communications network based on the second information that represents the plurality of TTL values (Pazi, [0055], “When guard device 28 has received a suspect packet for which there is no entry in database 30, or in any case in which there is a likelihood that the suspect packet is, in fact, valid, the guard device attempts to verify that the TTL value of the packet is correct, at a TTL validation step 48. Preferably, the guard device sends a message to the IP source address of the suspect packet, and then examines the reply in order to verify the TTL value, at a TTL verification step 50. This method is described in detail hereinbelow with reference to FIG. 3. If the TTL value is successfully verified, guard device 28 stores the value in database 30 along with the corresponding IP source address, at a database update step 52. The verified TTL value is then available for use in validating packets received subsequently by the guard device”).
Regarding claims 8 and 17, Pazi and Shimada disclosed the subject matter of claims 1 and 10.
Pazi further disclosed wherein the instructions cause the one or more processors to: retrieve, from a remote database, the CIDR block associated with the communications network; store third information that represents the CIDR block in the data structure; and while in a monitor mode: compare subsequent TTL values with the second information that represents the plurality of TTL values; and compare subsequent IP addresses with the third information that represents the CIDR block (Pazi disclosed in [0047] that “ database 30 may hold TTL values by subnet (a TTL value for each different 24-bit IP address prefix, for example), in addition to or instead of entries for individual IP source addresses.” Pazi further disclosed in [0050] that “Guard device 28 checks the IP source address of the incoming packet against database 30, at a record checking step 42. If there is a record in the database corresponding to this source address, the guard device checks the TTL value held in the database against the TTL value recorded in the packet header.” And in claim 4 of “comparing the value to an aggregate reference value associated with a subnet to which the source address belongs” Pazi’s disclosure as cited is substantially the same as what is claimed here).
Regarding claim 9, Pazi and Shimada disclosed the system of claim 1.
Pazi further disclosed wherein the instructions cause the one or more processors to apply one or more tags to data packets identified as malicious responsive to a detection of differences between the plurality of TTL values and TTL values extracted subsequent to the change from observation mode to the idle mode (Pazi disclosed in [0031] that “if the source address and TTL value do not match an entry in the database, the guard device regards the packet as suspect and, typically, either discards the packet or passes it on to the server with limiting conditions. For example, the packet may be passed on with reduced priority …” Pazi’s method of passing the packet on with reduced priority is an example of applying one or more tags to the packet in the claim).
Claims 6 and 15 are rejected under 35 U.S.C. 103 as being obvious over Pazi et al. and Shimada et al., further in view of Konda et al. (U.S. 2023/0093904).
Regarding claims 6 and 15, Pazi and Shimada disclosed the subject matter of claims 1 and 10.
Pazi might not have explicitly disclosed the subject matter in these two claims as a whole.
However, in the same field of endeavor, Konda disclosed a method and system for inspecting IP address and associated TTL values in the network traffic to determine non-malicious or malicious traffic. In particular, Konda disclosed wherein the instructions cause the one or more processors to:
generate, based on the second information that represents the plurality of TTL values and the CIDR block associated with the communications network, an access control list to control access to the communications network subsequent to the plurality of data packet exchanges (Konda disclosed in Fig. 4 and [0060-0064] the process that “generate ASN greenlists and handle reputation requests from the example network traffic monitoring circuitry”),
the access control list comprising a plurality of combinations of given IP addresses included in the CIDR block and given TTL values included in the plurality of TTL values (Konda disclosed in [0041] that “Even when the IP address is contained in the example TTL greenlist, the example ASN reputation request handling circuitry 207 still compares the handshake parameters obtained by the example handshake parameter receiver circuitry 209 to the values stored with the corresponding IP address in the example TTL greenlist data store 213” which shows that the TTL greenlist stores IP addresses and TTL values);
obtain a data packet associated with a data packet exchange subsequent to generation of the access control list, the data packet exchange between the server and a mobile device, the data packet including a TTL value and an IP address (Konda disclosed in [0042] that “The example handshake parameter receiver circuitry 209 gathers handshake parameters from the inspection received prior and stores them in the example TTL greenlist data store 213 along with the destination IP address, domain name, and TTL value associated with the data flow”); and
identify the mobile device as malicious based on a difference between the TTL value, the IP address, and one or more combinations of the plurality of combinations (Konda disclosed in [0075] that “When inspection shows that the connection is not secure and/or a security threat was detected that would put the client devices 110 at risk, the flow controlling circuitry 319 redirects client devices 110 away from the threat and to safety (e.g., a block page)”).
One of the ordinary skill in the art, before the effective filing date of the claimed invention (AIA ), would have been motivated to combine Pazi and Konda because both references disclosed methods for identifying service attack / malicious network traffic by using associating IP addresses with TTL values (Pazi, [0050], “IP/TTL correspondence”; Konda, [0042], “The example handshake parameter receiver circuitry 209 gathers handshake parameters from the inspection received prior and stores them in the example TTL greenlist data store 213 along with the destination IP address, domain name, and TTL value associated with the data flow”).
Therefore, before the effective filing date of the claimed invention (AIA ), it would have been obvious for one of ordinary skill in the art to integrate Konda’s teaching of using a TTL greenlist into Pazi as such that Pazi could maintain TTL greenlists for quick malicious traffic detection.
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 extension fee 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHIRLEY X ZHANG whose telephone number is (571)270-5012. The examiner can normally be reached 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 at 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.
/SHIRLEY X ZHANG/Primary Examiner, Art Unit 2447
Prosecution Insights