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 is a Final Office action in response to communications received November 19, 2025. Claim 1 has been canceled. Claims 2-4, 8, 9, 11, 14-16, 20 have been amended. Therefore, claims 2-20 are pending and addressed below.
Allowable Subject Matter
Claims 8 and 16 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Claim Rejections - 35 USC § 102
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 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.
Claims 1-7, 9-15, 17-19 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Levy Nahum (US 2021/0067543 A1, publish date 03/04/2021). (on Applicant’s IDS filed 06/18/2025)
Claims 2 and 11:
With respect to claims 2, 11, Levy Nahum discloses a computer-implemented method (CIM)/computer program product (CPP)(a process for dynamically creating counters based on actual traffic, Figure 4), comprising:
a processor set (processor(s) 522, Figure 5);
a set of one or more computer-readable storage media (non-transitory machine-readable storage medium/media 526), 0052, Figure 5); and
program instructions collectively stored in the set of one or more storage media, for causing a processor set to perform the following computer operations (having stored therein software 528 (which includes instructions executable by the set of one or more processor(s) 522), 0052, Figure 5):
in response to intercepting an application request (The web application layer proxy 120 may establish connections with the web application clients 110 and receive web application layer requests (e.g., HTTP request messages) intended for the web application servers 130 from the web application clients 110 over those connections, 0024):
causing a first copy of the application request to be forwarded to a policy agent (attack detection component 170 that applies a set of security rules 180 to the traffic received by the web application layer proxy 120 to enforce security policies" The attack detection component corresponds to the policy agent in claim 1. The received traffic corresponds to the first copy of the application request, 0034), and
causing a second copy of the application request to be forwarded to a sketch algorithm (dynamic counter creation component 140 may dynamically create counters ... based on actual web application layer requests received by the web application layer proxy 120" The dynamic counter creation component corresponds to the sketch algorithm in claim 1, 0027);
wherein the first and second copies of the application request are forwarded to the policy agent and the sketch algorithm simultaneously (while the flow diagrams in the figures show a particular order of operations performed by certain embodiments, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.), 0057);
causing the sketch algorithm to extract metadata from the second copy of the application request (the dynamic counter creation component 140 applies each counting rule in the set of counting rules 150 to that web application layer request to create/update counters in the set of dynamically created counters 160, 0028) (the dynamic counter creation component 140 may apply... counting rule to the web application layer request by determining the client type associated with the web application layer request, the origin geolocation of the web application layer request, and the destination IP address associated with the web application layer request" The dynamic counter corresponds to the extracted metadata of the application request, 0030);
store the metadata extracted by the sketch algorithm in a designated portion of memory allocated to the sketch algorithm, the designated portion of memory having a width determined while training the sketch algorithm (the set of dynamically created counters 160 is stored in a hash table using a key that is generated based on the set of parameter values associated with the respective counters. This allows the dynamic counter creation component 140 to quickly determine whether a counter exists and to quickly access existing counters. 0039, Figure 1, 160) (the dynamic counter creation component 140 updates that counter (e.g., increments the counter) in the set of dynamically created counters 160, 0028-0030);
causing the policy agent to apply a security policy to the first copy of the application request and the metadata extracted by the sketch algorithm (attack detection component 170 that applies a set of security rules 180 to the traffic received by the web application layer proxy 120 to enforce security policies. Each security rule in the set of security rules 180 may specify a set of conditions that trigger the security rule and a set of actions to be performed when the security rule is triggered ... security rule may refer to one or more of the dynamically created counters in the set of dynamically created counters 160, 0034-0035); and
dispositioning the application request based at least in part on whether the first copy of the application request and/or the metadata extracted by the sketch algorithm satisfy the security policy (the web application layer proxy may also establish connections with the web application servers and send the web application layer requests received from the web application clients to the web application servers (e.g., if it determines that the web application layer requests do not pose a security threat), 0006).
Claim 12:
With respect to claim 12, Levy Nahum discloses wherein the first and second copies of the application request are forwarded to the policy agent and the sketch algorithm simultaneously (while the flow diagrams in the figures show a particular order of operations performed by certain embodiments, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.), 0057).
Claims 3, 13:
With respect to claims 3, 13, Levy Nahum discloses wherein the application request is intercepted by a proxy (The web application layer proxy may establish connections with the web application clients and receive web application layer requests (e.g., HTTP request messages) intended for the web application servers from the web application clients over those connections, 0006).
Claims 4, 14:
With respect to claims 4, 14, Levy Nahum discloses wherein the causing of the sketch algorithm to extract metadata from the second copy of the application request includes: accessing Layer 7 metadata in the second copy of the application request; and applying the width while summarizing the Layer 7 metadata streaming traffic (where each counting rule in the set of counting rules 150 specifies a set of parameters based upon which to create counters 160, a counting rule may specify a set of parameters that include any combination one or more of the following parameters: 0027).
Claim 5:
With respect to claim 5, Levy Nahum discloses wherein the width is determined while training the sketch algorithm, by: causing the policy agent to forward all network traffic to the sketch algorithm; causing the sketch algorithm to observe the network traffic for a predetermined amount of time; and identifying a width that most effectively summarizes the network traffic (the dynamic counter creation component 140 may dynamically create counters during runtime of the web application layer proxy 120 based on actual web application layer requests received by the web application layer proxy 120, 0027) (created counters 160 to the security center 190 periodically (e.g., every N minutes), 0033) (The set of conditions may specify particular header field values: metrics (e.g., a particular number of packets or web application layer messages that are received over a defined period of time), 0034)
Claim 6:
With respect to claim 6, Levy Nahum discloses wherein the width is dynamically updated over time, by: observing active network traffic for a predetermined amount of time; in response to detecting diverse active network traffic, increasing the width; and in response to detecting lean active network traffic, decreasing the width (the dynamic counter creation component 140 updates that counter (e.g., increments the counter) in the set of dynamically created counters 160, 0028-0030).
Claims 7, 17:
With respect to claims 7, 17, Levy Nahum discloses wherein the Layer 7 metadata is selected from the group consisting of: service names, authentication tokens, Uniform Resource Locator (URL) paths, session tokens, cookies, and HTTP response codes (uniform resource locator (URL), User-Agent HTTP header, Referer HTTP header, client IP address, client application type defined by security (e.g., browser, search bot, worm, etc.), HTTP method (e.g., HTTP GET, POST, PUT, DELETE, etc.), an HTTP parameter, etc, 0027).
Claims 9, 18:
With respect to claims 9, 18, Levy Nahum discloses wherein the dispositioning of the application request, includes: in response to determining the first copy of the application request and/or the metadata extracted by the sketch algorithm satisfy the security policy, causing the application request to be forwarded to a target application for implementation (he web application layer proxy may also establish connections with the web application servers and send the web application layer requests received from the web application clients to the web application servers (e.g., if it determines that the web application layer requests do not pose a security threat), 0006).
Claims 10, 19:
With respect to claims 10, 19, Levy Nahum discloses wherein the dispositioning of the application request, includes: in response to determining the first copy of the application request and/or the metadata extracted by the sketch algorithm do not satisfy the security policy, causing the application request to be rejected (security rules: Security rule 180B further specifies a corresponding action to block the request. The attack detection component 170 may apply this security rule 180B by blocking a web application layer request received by the web application layer proxy 120 if it causes the specified counter (e.g., counter 160B) to be greater than 1,000., 0040)
Claim 15:
With respect to claim 15, Levy Nahum discloses wherein the width is determined while training the sketch algorithm, by: causing the policy agent to forward all network traffic to the sketch algorithm; causing the sketch algorithm to observe the network traffic for a predetermined amount of time (the dynamic counter creation component 140 may dynamically create counters during runtime of the web application layer proxy 120 based on actual web application layer requests received by the web application layer proxy 120, 0027) (created counters 160 to the security center 190 periodically (e.g., every N minutes), 0033) (The set of conditions may specify particular header field values: metrics (e.g., a particular number of packets or web application layer messages that are received over a defined period of time), 0034); and determining an amount of memory that most effectively summarizes the network traffic for the predetermined amount of time; and presetting the width as the determined amount of memory (the set of dynamically created counters 160 is stored in a hash table using a key that is generated based on the set of parameter values associated with the respective counters. This allows the dynamic counter creation component 140 to quickly determine whether a counter exists and to quickly access existing counters. 0039, Figure 1, 160) (the dynamic counter creation component 140 updates that counter (e.g., increments the counter) in the set of dynamically created counters 160, 0028-0030).
Response to Remarks/Arguments
Applicant's arguments filed on November 19, 2025 have been fully considered but they are not persuasive. In the remarks, Applicant argues that:
Claim 2
1) The claimed "wherein the first and second copies of the application request are forwarded to the policy agent and the sketch algorithm simultaneously" cannot be met by Nahum.
Claim 11
2)Nahum only mentions that the dynamic counter creation component 140 uses counting rules to create and update counters. While the rejection may attempt to argue that creating counters impacts the use of memory, nowhere does Nahum mention that the counters are stored in a designated portion of memory, much less a "designated portion of memory having a width determined while training the sketch algorithm" as claimed.
In response to remark/arguments (1), Examiner respectfully disagrees. Levy Nahum discloses “while the flow diagrams in the figures show a particular order of operations performed by certain embodiments, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.), 0057). Therefore, Examiner maintains that Levy Nahum does teach and suggest this limitation.
In response to remark/arguments (2), Examiner respectfully disagrees. Levy Nahum discloses “the set of dynamically created counters 160 is stored in a hash table using a key that is generated based on the set of parameter values associated with the respective counters. This allows the dynamic counter creation component 140 to quickly determine whether a counter exists and to quickly access existing counters. 0039, Figure 1, 160) (the dynamic counter creation component 140 updates that counter (e.g., increments the counter) in the set of dynamically created counters 160, 0028-0030). Therefore, Examiner maintains that Levy Nahum does teach and suggest this limitation.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. 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).
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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Helai Salehi whose telephone number is 571-270-7468. The examiner can normally be reached on Monday - Friday from 9 am to 5 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, Jeff Pwu, can be reached on 571-272-6798. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/HELAI SALEHI/Examiner, Art Unit 2433
/JEFFREY C PWU/Supervisory Patent Examiner, Art Unit 2433