DETAILED ACTION
This Office Action is with regard to the most recent papers filed 10/13/2025.
Response to Arguments
Applicant's arguments filed 10/13/2025 have been fully considered but they are not persuasive.
On pages 1-9, Applicant again argues that the prior art fails to teach “wherein the AppAttributes represent the applicative behavior of the protected entity.” On pages 1-2, Applicant reiterates previous arguments, where these are addressed in the Office Action mailed 7/11/2025.
On pages 3-4, Applicant argues that the specification refers to the Application layer many times to counter the assertion that the specification fails to reference the OSI model directly, but fails to address that the OSI model, itself, is mentioned. Applicant proceeds to argue that the application layer is well known by those of ordinary skill in the art and that layer-7 does not fit within the TCP/IP model.
However, the well-known nature of OSI was never called into question. Rather, the scope of the application layer, as mentioned in the instant claim, is in question. Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). In this case, the “application layer” is not given a definition in the specification that has a specific limiting effect, and the claims as well as the instant specification fail to provide enough detail to specifically limit the term.
Nothing in Applicant’s remaining rationale appears to provide any detail that would establish Medvedovsky’s teachings are not within the actual claim language. Nor do any of Applicant’s arguments address the teachings of Medvedovsky’s paragraph [0066] versus the instant paragraph [00103] of the instant specification, even if we improperly limit the instant claim scope based on the instant specification and Applicant’s arguably improper characterization of the application requiring the OSI model. Accordingly, the rejection of the instant claims has been maintained. Going forward, it is recommended that if Applicant regards the instant claim as having certain requirements, or if a term is regarded as requiring certain details, the instant claim be amended to clearly reflect such.
However, it should be noted that Medvedovsky specifically looks at HTTPS traffic, where HTTPS is an application layer protocol. Thus, this argument is irrelevant, as Medvedovsky looks at HTTPS traffic, and thus processes such application-layer traffic.
On pages 4-6, Applicants argue that none of the rate-invariant anomalies of Medvedovsky are based on a plurality of AppAttributes that represent the applicative behavior of the protected entity modeled based on the application-layer transactions. Applicant proceeds to argue that Medvedovsky is basing rate-invariant anomalies on rate invariant features of the traffic which may include a distribution of HTTPS request sizes, a distribution of HTTPS response sizes, an ingress/egress ratio measured as the ratio between an ingress number of HTTPS requests per second and an egress HTTPS response volume measured in bytes per second, and an egress/ingress ratio measured as the ratio between an egress HTTPS response volume in bytes per second and an ingress number of requests per second, and argues that none of these things represent the applicative behavior of the protected entity modeled based on the application-layer transactions. Applicant then proceeds to argue that the specification teaches different items. However, these are not claimed, where although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). In this case, the “application layer” is not given a definition in the specification that has a specific limiting effect, and the claims as well as the instant specification fail to provide enough detail to specifically limit the term. If Applicant intends for the examples in the instant specification to be required, these should be in the instant claim. Otherwise, the claims must be afforded their broadest reasonable interpretation in light of, but not limited by the instant specification. In this case, the attributes merely “represent the applicative behavior of the protected entity modeled based on the application layer transactions.” This does not provide any detail of what the app attributes are, only what they represent. Further, how the instant claim does not even present that how the AppAttributes are generated, such as whether the modelling actually is performed or what performs such modelling. Instead, the AppAttributes merely “represent,” where the different parameters listed in wolf serve to represent such behavior.
Accordingly, it appears that Applicant is interpreting the claim language in an overly narrow fashion, where if Applicant regards the claims as having certain requirements, such should be provided in the claim language instead of attempting to rely on the instant specification (See, for example, paragraph [00130] of the instant specification).
On page 6, Applicant argues “applicative behavior of the protected entity.” First, as addressed above, the AppAttributes merely represent such behavior, which provides that such behavior does not need to be determined or even known to the system. Further, the term “applicative behavior of the protected entity” does not appear to have specific requirements in the instant claim. Applicant indicates that there is no need to define terms that are known or understood to one of the art, then cites paragraph 38 for how the term is to be interpreted. First, if the term “applicative behavior” is known in the art, and thus would have limitations based on such knowledge, evidence of this should be provided. Further, as stated before, although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). In this case, the “application layer” is not given a definition in the specification that has a specific limiting effect, and the claims as well as the instant specification fail to provide enough detail to specifically limit the term. The reliance of paragraph 38 and other teachings to limit the term “applicative behavior” is inappropriate, where if Applicant intends for the term to have certain limitations, evidence should be provided that one of ordinary skill in the art would have unambiguously interpreted the terms in the fashion argued by Applicant or amend the instant claim to include such requirements.
On page 8, Applicant argues that AppAttributes are defined in the specification, and refers to paragraph 37. Paragraph 37 does not provide a definition, but merely links the term “application specific attributes” to the term “AppAttributes,” then proceeds to provide what the attributes are in the disclosed embodiment. For such a term to be a definition, the specification would need to unambiguously provide that the language should be interpreted in a certain way (e.g. “as used herein, is defined as”). Instead, the disclosure states what the term “can be,” which clearly provides no limitation.
Thus, as Applicant’s arguments appear to all rely on details disclosed in the instant specification but not in the instant claims, such arguments cannot be deemed persuasive. It is highly recommended that if Applicant intends for the claims to have certain requirements, that such requirements be unambiguously recited in the instant claims. Otherwise, without such amendments, it would appear that Applicant does not actually intend for the claims to have the argued requirements, clearly countering any arguments based on details only appearing in the instant specification.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-6, 8-26, and 28-39 is/are rejected under 35 U.S.C. 102a1 as being anticipated by US 2021/0194903 (Medvedovsky).
With regard to claim 1, Medvedovsky discloses a method for detecting application layer flood denial-of-service (DDoS) attacks carried by attackers utilizing advanced application layer flood attack tools, comprising:
processing application-layer transactions received during a current time window to detect a rate-based anomaly in a traffic directed to a protected entity (Medvedovsky: Figure 2 and Paragraph [0065]-[0066] and [0072]. Transactions are monitored and processed to establish a baseline, such as for rate-based traffic features, where the baseline is then used to detect an anomaly in the rate-based features. Medvedovsky utilizes a sliding window (Medvedovsky: Paragraph [0034]).);
processing the received application-layer transactions to determine a rate-invariant anomaly based on a plurality of Application Attributes (AppAttributes) observed in the application-layer transactions received during the current time window, wherein the rate-invariant anomaly is determined based on a continuously updated (Medvedovsky: Paragraph [0012]) baseline of AppAttributes, wherein AppAttributes represent applicative behavior of the protected entity modeled based on the application-layer transactions (Medvedovsky: Figure 2 and Paragraphs [0065]-[0066] and [0072]. Rate-invariant features are also monitored to determine a baseline, where anomalies can be detected against this baseline. Medvedovsky is concerned with detecting application-layer attacks (Medvedovsky: Paragraph [0004]), where features that concern the application-layer would be application features, lacking any detail as to what constitutes such application features in the instant claim language.);
determining based on the determined rate-based anomaly and a detected rate-invariant anomaly if an application layer flood DDoS (Medvedovsky: Paragraph [0010]) is present in the current time window (Medvedovsky: Figure 2. A DDoS attack can be detected.); and
causing a mitigation action when the application layer flood DDoS is present (Medvedovsky: Figure 2).
With regard to claim 2, Medvedovsky discloses that detecting the rate-based anomaly in a traffic directed to a protected entity further comprises: computing a current rate-based parameter for the current time window as a number of incoming transactions per second received during the time window; computing at least one rate-base baseline, each of the one rate-based baseline is computed using an alpha filter configured to a specific time period; computing an anomaly rate-based threshold for each of at least one rate-based baseline; and decelerating rate-based anomaly when a value of the computed current rate-based parameter exceeds one of the anomaly rate-based threshold (Medvedovsky: Paragraphs [0095] to [0097]. The term “alpha filter” does not appear to have a specific meaning as in the art as used in the instant specification, nor does the instant specification limit what an alpha filter would be. The filters of Medvedovsky appear to be within the scope of such an alpha filter.).
With regard to claim 3, Medvedovsky discloses buffering, in window buffers, AppAttributes derived from application-layer transactions received during the current time window (Medvedovsky: Paragraph [0095] to [0096]).
With regard to claim 4, Medvedovsky discloses computing the baseline of AppAttributes using baseline buffers (Medvedovsky: Paragraphs [0095] to [0097]).
With regard to claim 5, Medvedovsky discloses that each of the baseline buffers and the window buffers is for a single AppAttributes type (Medvedovsky: Paragraph [0094]).
With regard to claim 6, Medvedovsky discloses that an AppAttributes type is any one of: a query arguments (args) name, a non-standard HTTP header name, a cookies name, a HTTP request size range, a HTTP response size range, a HTTP response status code, a source IP address attribute, a user agent values, a TLS figure print attribute, and a set-cookie name (Medvedovsky: Paragraph [0060]. At least source IP [address] can be determined as a feature. In the instant claim, a listing of alternatives is provided, where the AppAttribute type only needs to be one item from the listing of options (as the type only needs to be “any one of” the listed elements) to teach the instant claim, as a whole.).
With regard to claim 8, Medvedovsky discloses each AppAttributes type buffer of the window buffers includes a first segment including previous observed AppAttributes values and a second segment of first-time observed AppAttributes, wherein the first-time observed AppAttributes values are observed in transactions received during a current time window and are not designated in the first segment (Medvedovsky: Paragraph [0096]. Lacking detail of how the segments are divided or how the different segments are used, the storage of different values in the buffer, where the first value that is not a padded value would be a first time observed attribute and any subsequent attribute would be previous observed attributes, would teach the instant claim, as a in as much detail as provided in the instant claim.).
With regard to claim 9, Medvedovsky discloses updating the window buffers based on AppAttributes values observed in transactions received during a current time window, wherein the window buffers are updated per each AppAttributes type (Medvedovsky: Paragraph [0096] and [0094]).
With regard to claim 10, Medvedovsky discloses at the end of current time window, updating the baseline buffers with AppAttributes in the respective window buffers, wherein the baseline buffers are updated at peace time only (Medvedovsky: Paragraph [0098] and Figure 4).
With regard to claim 11, Medvedovsky discloses determining the rate-invariant anomaly further comprises: for each AppAttributes type, determining an attack proximity, wherein the attack proximity indicates how statistically close AppAttributes in the window buffers to AppAttributes in the baseline buffers; computing a total attack proximity across all AppAttributes types based on their respective window buffers and baseline buffers; computing a proximity threshold; comparting the attack proximity to the proximity threshold; and declaring a rate-invariant anomaly when the attack proximity exceeds the proximity threshold (Medvedovsky: Abstract and Paragraphs [0104] to [0117]).
With regard to claim 12, Medvedovsky discloses using a distribution density function to determine the attack proximity (Medvedovsky: Paragraph [0114]).
With regard to claim 13, Medvedovsky discloses that the attack proximity for each AppAttribute type is a function of a total variation between a baseline distribution density and a window distribution density, wherein baseline distribution density function is determined based on the baseline buffers and the window determined based on the window buffers (Medvedovsky: Paragraph [0105]. Long-term and short term are used, with the short-term being associated with the window and the long-term being associated with the baseline.).
With regard to claim 14, Medvedovsky discloses that the proximity threshold is a function of multiplication of a number of valid AppAttributes types with a preconfigured parameter (Medvedovsky: Paragraph [0108]).
With regard to claim 15, Medvedovsky discloses generating an alert on an attack when the rate-invariant and the rate-based anomaly indications are set during a time window (Medvedovsky: Figure 2).
With regard to claim 16, Medvedovsky discloses determining an end-of-attack condition; and causing the mitigation action to end (Medvedovsky: Paragraph [0118]).
With regard to claim 17, Medvedovsky discloses that determining the end-of-attack condition is satisfied when any one of the following conditions occurs: the rate-invariant indication is below the respective the rate-invariant threshold; or a rate-based indication is below one of the rate-based threshold (Medvedovsky: Paragraph [0118]).
With regard to claim 18, Medvedovsky discloses that application-layer transactions include any one of: HTTP requests, HTTP responses, HTTPs requests, and HTTPs responses (Medvedovsky: Abstract).
With regard to claim 19, Medvedovsky discloses that application-layer transactions include samples of the actual HTTP requests, their corresponding HTTP responses and HTTPs requests, and their corresponding HTTPs responses, wherein the sampling rate can be different for peace time and attack time scenarios (Medvedovsky: Paragraph [0035]-[0036]. As a note, the language “sampling rate can be different…” does not require that the sampling rate is actually different, and instead provides an optional limitation. If Applicant intends for the sampling rate to be different, the claim should specifically provide that the sampling rates are different.).
With regard to claims 20-26 and 28-39, the instant claims are similar to claims 1-6 and 8-19, and are thus rejected for similar reasons.
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) 7 and 27 is/are rejected under 35 U.S.C. 103 as being unpatentable over Medvedovsky in view of Guan (US 2019/0238467).
With regard to claim 5, Medvedovsky fails to disclose, but Guan teaches that each buffer of a single AppAttributes type includes: a key value field designating key value, an occurrence (occ) field counting occurrences, a weight field representing a relative weight, and an age field represents the last time the AppAttributes type observed in an incoming application-layer transaction (Guan: Paragraph [0112]).
Accordingly, it would have been obvious to one of ordinary skill in the art at the time of filing to store a key value pair and/or an age field in the buffer to enable the organized storage of the information (i.e. providing a key, such as a description of what the value represents and one or more corresponding values) and/or maintaining accurate information on the timing of the information, such that the information can then be provided in a log for later reference.
With regard to claim 27, the instant claim is similar to claim 7, and is rejected for similar reasons.
Conclusion
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SCOTT B CHRISTENSEN whose telephone number is (571)270-1144. The examiner can normally be reached Monday through Friday, 6AM to 2PM.
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, John Follansbee can be reached at (571) 272-3964. 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.
SCOTT B. CHRISTENSEN
Examiner
Art Unit 2444
/SCOTT B CHRISTENSEN/Primary Examiner, Art Unit 2444