DETAILED ACTION
Examiner acknowledges receipt of Applicant’s amendment filed on 01/16/2026
Claims 1 and 12 are currently amended
Claims 1-14 are pending
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 Amendment
Examiner has fully considered Applicant’s amendments to the Claims in the arguments filed on 01/16/2026. Claims 1140 remain pending in the application. Examiner has withdrawn the objections to Claims 1 and 12 based on the amendments. However, additional claim objections arise.
Response to Arguments
Applicant’s arguments filed 01/16/2026, with respect to the rejections of claims 1-14 under 35 USC 103 have been fully considered, but they are not persuasive. Examiner respectfully submits that the previously applied combination of Muddu, Gaddam, Turgeman, Chesla, and Peddada is sufficient to render obvious the amended claims with the particular added limitations of “the single vector of request factors that includes collected, calculated and determined metrics”. An additional amendment (“collecting of numerical and statistical request metrics, connection metrics, and basic application level metrics”) described on P. 7 of Applicant Arguments is not reflected in the currently amended claims as it is believed to have been intended, but the amendment does/would not overcome the previously applied combination.
Regarding Applicant’s Argument beginning on P. 7 of Applicant Arguments that the previously applied reference from Muddu is not sufficient to teach numerical and/or statistical metrics collected at the network and transport layers, Examiner respectfully disagrees. Specifically, Muddu recites, "the technique determine(s) if the outgoing traffic is user-generated traffic based on a number of parameters, such as number of connection requests originating from the device in a predefined period, periodicity of the connections, number of web objects requested by the device, number of destinations contacted by the device, number of times a destination is contacted and number of ports of the destinations contacted (Muddu - Paragraph [0646])". Each of the listed parameters represents collection of numerical and statistical metrics observable in at least one of the network, transport, and application layers, and each is described as being collected over a predefined period for comparative analyses. Further, Examiner respectfully submits that the above described amendment (“collecting of numerical and statistical request metrics, connection metrics, and basic application level metrics”), although not presented in the Currently Amended Claim 1, still does/would not preclude the claim language from being interpreted to suggest that all of the listed metrics may be collected at the application level. For additional clarification, the claim language is not interpreted to explicitly require that all of the metrics are collected at the application level - only that they can be. There is currently no claimed requirement to collect statistics from the network or transport layers.
Regarding Applicant's argument beginning on P. 8 of Applicant Arguments that Gaddam is not sufficient to teach the evaluation of a user based on a vector of historical numerical and statistical metrics, but rather that Gaddam teaches an evaluation of a single request using a request vector, Examiner respectfully traverses the argument. While the cited portions of Gaddam (e.g. Paragraphs [0024], [0067], and [0088]) refer to generating vectors from “request data” that is associated with a request, Gaddam explicitly describes vector-based evaluations of sequences of requests. Specifically, Gaddam recites at least “these machine learning models accept database access requests or sequences of database access requests (referred to as “access sequences”) as feature vectors and produce anomaly scores. The anomaly scores can classify database access requests or access sequences as normal or anomalous (Gaddam – Paragraph [0013])”; and “an access sequence may be used as a feature vector input to a machine learning model, in order for the machine learning model to produce an anomaly score output, indicating whether the access sequence is normal or anomalous (Gaddam – Paragraph [0034])”; and “database servers 112 and 114 may generate access sequences comprising ordered sequences of the database access requests. The access sequences may be generated by collecting the received database access requests and ordering them based off timestamps corresponding to the database access requests. Additionally, database servers 112 and 114 may receive additional database access requests from the other database servers, which may additionally be included in the access sequence. The access sequences may be used as inputs to the determined machine learning model. The machine learning model may produce an anomaly score, which database servers 112 and 114 may compare to a threshold. If the anomaly score exceeds the threshold (i.e., the access sequence is likely anomalous, malicious, or fraudulent) (Gaddam – Paragraph [0069]-[0070])”. Therefore, the teachings from Gaddam cannot be considered limited to the generation of request vectors for analyses of single requests. Moreover, Examiner respectfully submits that Claim 1 does not explicitly require that the claimed collected metrics be representative of more than one request. For example, Claim 1 recites “evaluating a user based on a request received from the user”; “evaluating a legitimacy of the request”; “evaluation of the legitimacy of the request”; etc..
In further view of the above teachings, Examiner respectfully submits that one of ordinary skill in the art would be motivated to apply the user request statistics collected at various levels of the OSI model taught by Muddu with the generation and analysis of feature vectors representing statistical data of multiple user requests taught by Gaddam to achieve the obvious benefit of a capability to apply machine learning to detect deviations from normal or expected user behavior over time and/or in certain scenarios.
Claim Objections
Claim 1 is objected to because of the following informalities:
In line 13-14 of Claim 1, the limitation “the single vector of request factors that includes collected, calculated and determined metrics” should read: “the single vector of request factors that includes the collected, calculated and determined metrics” for consistency with the antecedent basis for the collected, calculated and determined metrics established earlier in the claim
Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier.
Such claim limitation(s) is/are:
All of the “module(s)” stated in Claims 12 and 14
The “starting unit” stated in Claim 14
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
In this case, the specification provides sufficient corresponding structure, material, or acts for the limitations performed by the various modules. Paragraph [0085] recites sufficient structure of the modules and starting unit: “Used in the description of the technical solution, the terms "unit", "component", "element", "module" and the like are used to refer to computer entities that can be hardware/equipment (for example, device, tool, apparatus, equipment, an integral part of a device, for example, a processor, microprocessor, integrated circuit, printed circuit board, including an electronic printed circuit board, breadboard, motherboard, and so on, a microcomputer, etc.), software (for example, executable program code, compiled application, software module, piece of software or program code, etc.) and/or microprogram (in particular, firmware). Therefore, for example, a component can be process running on a processor … or a combination of software or hardware components ….”, and further in Paragraph [00108]: “All modules are software components, part of a software package that the processor executes”, and further in Paragraph [00154]: “In the present invention, modules (101-107, 201-208) mean components, a group of components implemented using hardware, such as integrated circuits, or, for example, as a combination of software and hardware, such as a microprocessor system and a set of programming instructions. The functionality of the modules (101-107, 201-208) can be implemented exclusively by hardware, as well as in the form of a combination, where part of the functionality is implemented by software, and some by hardware (software and hardware complex). In some embodiments, some of the modules (101-107, 201-208) may be executed on a processor of a general-purpose computer system”.
Figures 1 and 2 illustrate the function and structure of the modules and the starting unit stated in Claims 12 and 14.
Corresponding Specification paragraph [0099] recites: “In the course of technical analysis in the system, modules (101) - (107) perform the following actions:” which are listed as follows: Paragraph [00100] recites: “(101) - collect all kinds of numerical and statistical metrics available at the network layer L3 (IP layer of the TCP/IP model). For example, flags and TTL”, and Paragraph [00101] recites: “(102) - collect all kinds of numerical and statistical metrics available at the transport layer L4 (TCP layer of the TCP/IP model). For example, flags, options and starting window size” as collectively stated in Claim 12; Paragraph [00102] recites: “(103) - collect all kinds of numerical and statistical metrics at the application level, HTTP/HTTPS protocol. For example, browser type, version from the User-Agent header” as stated in Claim 12; Paragraph [00103] recites: “(104) - based on the available statistics of the user's communication to the resource, the metrics characterizing the given client are calculated. For example, the median time between requests to the resource” as stated in Claim 12; Paragraph [00104] recites: “(105) - having general statistics on the resource, metrics are calculated that show the deviation of the client's session from the median and average session on the given resource” as stated in Claim 12; Paragraph [00105] recites: “(106) - combine the calculated metrics into the single vector of request factors and perform metrics normalization” as stated in Claim 12; Paragraph [00106] recites: “(107) - using a previously prepared statistical model, the result is calculated and evaluation of the legitimacy of the request is obtained” as stated in Claim 12; regarding the structure of the above listed modules, Paragraph [00108] recites: “All modules are software components, part of a software package that the processor executes”; all of the above mentioned modules combine to establish the structure and function of the “module for evaluating the legitimacy of the request from the user” as stated in Claim 12.
With regard to the modules of Claim 14, Paragraph [00122] recites: “JS stack validation module (202) checks the functionality of various features of the JS language, which allows to specify the browser version” as stated in Claim 14; Paragraph [00123] recites: “The CSS stack checking module (203) checks the functionality of various CSS implementation features, which allows the browser version to be specified” as stated in Claim 14; Paragraph [00124] recites: “The HTML Stack Validation module (204) checks the functionality of various HTML implementation features, which allows the browser version to be specified” as stated in Claim 14; Paragraph [00125] recites: “The HeadLess detection unit (205) checks the parameters of the window, the presence of mouse movement and other factors that allow to find out the browser operation mode” as stated in Claim 14; Paragraph [00126] recites: “The unique signature calculator (206) allows the computation of a signature that is unique for the given browser installation, which at the same time doesn't allow the browser to be uniquely identified” as stated in Claim 14; Paragraph [00128] recites: “The module for sending the collected data (207) assembles the result of the verification and the solution of the task into a single structure and sends it to the system on the server” as stated in Claim 14; Paragraph [00121] recites: “The cryptographic module (201) implements the asymmetric encryption algorithm, and is responsible for solving a mathematical task, the initial parameters of which are encoded in the starting unit (208)” as stated in Claim 14; Paragraph [00129] recites: “Starting unit (208) starts the checking with the modules (202) - (206) after loading the JS challenge module and invokes the cryptographic module (201) with the task start condition encoded in it” as stated in Claim 14.
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-3 are rejected under 35 U.S.C. 103 as being unpatentable over Muddu et al. (US 20180367551 A1), hereinafter Muddu, in view of Gaddam et al. (US 20210160247 A1), hereinafter Gaddam, Turgeman et al. (US 20180103047 A1), hereinafter Turgeman, Chesla et al. (US 20130254879 A1), hereinafter Chesla, and Peddada, IV et al. (US 20200252382 A1), hereinafter Peddada.
Regarding Claim 1:
Muddu teaches a method for preventing malicious automated attacks, the method comprising (Muddu – Paragraph [0438]: the present disclosure relates to methods and systems for organizing and presenting information concerning potential network compromise to one or more users tasked with monitoring the network and thwarting attacks, stolen data, and other harm; and Paragraph [0569]: classification metadata 6320 for a particular user can include metadata indicative that the user is a regular user, an administrative user, or an automated (machine-implemented) user): a) evaluating a user based on a request received from the user to a computer system about a session (Muddu – Paragraph [0644]: Described herein is a technique for detecting machine-generated traffic in outgoing traffic of a computer device (“device”) and determining whether the machine-generated traffic represents an anomaly. The outgoing traffic can include user-generated traffic, which can include connection requests generated from a user associated with the device, such as when the user accesses a website, checks email and downloads applications) by carrying steps comprising: collecting of numerical and statistical request metrics, connection metrics and basic metrics (Muddu – Paragraph [0646]: The technique determine if the outgoing traffic is user-generated traffic based on a number of parameters, such as number of connection requests originating from the device in a predefined period, periodicity of the connections, number of web objects requested by the device, number of destinations contacted by the device, number of times a destination is contacted and number of ports of the destinations contacted) at the application level (Muddu – Paragraph [0646]: The technique determine if the outgoing traffic is user-generated traffic based on a number of parameters, such as number of connection requests originating from the device in a predefined period, periodicity of the connections, number of web objects requested by the device, number of destinations contacted by the device, number of times a destination is contacted and number of ports of the destinations contacted; and Paragraph [0658]: The outgoing traffic can be any class of traffic, e.g., web traffic or IP traffic. The web traffic can include Hyper-Text Transfer Protocol (HTTP) message, which can be associated with parameters such as a destination IP address, a URI of the destination, a port number, a type of web request—GET or POST, etc.; Examiner’s Comment: HTTP/HTTPS protocol is discussed in specification paragraph [0030] as being available at the application layer) calculating of metrics characterizing the user based on statistics of communication of the user to a resource (Muddu – Paragraph [0646]: The technique determine if the outgoing traffic is user-generated traffic based on a number of parameters, such as number of connection requests originating from the device in a predefined period, periodicity of the connections, number of web objects requested by the device, number of destinations contacted by the device, number of times a destination is contacted and number of ports of the destinations contacted), determining of metrics based on general statistics on the resource (Muddu – Paragraph [0646]: The technique determine if the outgoing traffic is user-generated traffic based on a number of parameters, such as number of connection requests originating from the device in a predefined period, periodicity of the connections, number of web objects requested by the device, number of destinations contacted by the device, number of times a destination is contacted and number of ports of the destinations contacted), showing a of the session of the user from a [median and] average session (Muddu – Paragraph [0186]: In certain embodiments, anomalies and threats are detected by comparing incoming event data (e.g., a series of events) against the baseline profile for an entity to which the event data relates (e.g., a user, an application, a network node or group of nodes, a software system, data files, etc.). If the variation is more than insignificant, the threshold for which may be dynamically or statically defined, an anomaly may be considered to be detected); [the single vector of request factors that includes] collected, calculated and determined metrics (Muddu – Paragraph [0646]: The technique determine if the outgoing traffic is user-generated traffic based on a number of parameters, such as number of connection requests originating from the device in a predefined period, periodicity of the connections, number of web objects requested by the device, number of destinations contacted by the device, number of times a destination is contacted and number of ports of the destinations contacted) based on a result of the evaluation of the legitimacy of the request identifying the user as a legitimate user, or as a suspicious user, or as a bot (Muddu – Figure 78: Flow diagram of determining whether traffic is user- or machine-generated; and Figure 79: Flow diagram for determining whether machine-generated traffic is anomalous (potentially malicious)) b) carrying out an additional verification (Muddu – Paragraph [0349]: large amounts of incoming event data 2302 are processed to detect anomalies. The resulting anomaly data 2304 comprising a plurality of anomalies across a computer network is then further processed to identify threat indicators. This identification of threat indicators can be conceptualized as an intermediate step between detecting anomalies and identifying security threats to a computer network. As shown, the threat indicator data 2306 comprising a plurality of threat indicators identified across a computer network is further processed to identify a security threat or threats) in relation to the suspicious user to clarify the suspicious user’s legitimacy (Muddu – Paragraph [0350]: A detected anomaly in the activity on a computer network is often associated with one or more entities of the computer network, such as one or more physical computing devices, virtual computing devices, users, software modules, accounts, identifiers, and/or addresses. An anomaly or a set of anomalies may be evaluated (e.g. scored) together, which evaluation may result in a determination of a threat indicator or a threat. Threat indicators represent an escalation of events of concern and are evaluated to identify if a threat to the security of the network exists).
Muddu does not expressly teach combining the collected, calculated and determined metrics into a single vector of request factors and normalizing the vector, and evaluating a legitimacy of the request by means of a machine learning model using the single vector of request factors.
However, Gaddam teaches teach combining the collected, calculated and determined metrics into a single vector of request factors (Gaddam – Paragraph [0088]: The online system 104A can comprise a computer or network of computers. The online subsystem 104 can receive requests to access resources, either directly from the requesting entity 102 or from the requesting entity 102 via the resource gateway 106. The online subsystem 104A can generate a feature vector from request data included in the request to access the resource, determine an entity profile corresponding to the requesting entity, determine a production model correspond to the entity profile, produce a trust score using the feature vector as an input to the production model, and analyze the trust score using a policy engine to produce a resource access policy; and Paragraph [0013]: These machine learning models accept database access requests or sequences of database access requests (referred to as “access sequences”) as feature vectors and produce anomaly scores. The anomaly scores can classify database access requests or access sequences as normal or anomalous) and normalizing the vector (Gaddam – Paragraph [0124]: At step 406, the resource access system can process the request data to determine a feature vector. This can be accomplished with a data processing element or module, such as data processing element 202B from FIG. 2, and as described above, may involve identifying features in the request data, processing the features in order to produce numerical representations of the features, and normalizing the feature vector), and evaluating a legitimacy of the request by means of a machine learning model using the single vector of request factors (Gaddam – Paragraph [0088]: The online system 104A can comprise a computer or network of computers. The online subsystem 104 can receive requests to access resources, either directly from the requesting entity 102 or from the requesting entity 102 via the resource gateway 106. The online subsystem 104A can generate a feature vector from request data included in the request to access the resource, determine an entity profile corresponding to the requesting entity, determine a production model correspond to the entity profile, produce a trust score using the feature vector as an input to the production model, and analyze the trust score using a policy engine to produce a resource access policy; and Paragraph [0128]: At step 414, the resource access system can determine a trust score by applying the feature vector as an input to the production model. The trust score can be used by the resource access system to determine whether the request is malicious or benign; and Paragraph [0013]: These machine learning models accept database access requests or sequences of database access requests (referred to as “access sequences”) as feature vectors and produce anomaly scores. The anomaly scores can classify database access requests or access sequences as normal or anomalous).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Muddu, further incorporating Gaddam to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Gaddam’s teaching to vectorize request metrics for input into a machine learning model to evaluate the legitimacy of the requests into Muddu’s method for analyzing user requests to prevent automated attacks on a system. This combined functionality would enhance Muddu’s method by facilitating comparisons of incoming requests with known prior request outcomes.
The combination of Muddu and Gaddam does not expressly teach showing the deviation of the session of the user from a median and average session.
However, Turgeman teaches showing the deviation of the session of the user from a median and average session (Turgeman – Paragraph [0176]: The manual definition of the threshold values or threshold ranges of values, may be based on one or more sources of information; for example, … from analysis of past interactions of multiple users of the website, indicating the average and/or median and/or maximum and/or minimum values that characterized past interactions, of a particular user (e.g., the user whose interactions are currently analyzed or examined), or of a group of users (e.g., all the users that performed a Wire Transfer in the past 12 months), or of an entirety of a population of users (e.g., all the users of a particular banking website)).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Muddu and Gaddam, further incorporating Turgeman to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Turgeman’s teaching to determine median values for user behaviors for determining anomalous behavior into Muddu and Gaddam’s method for analyzing user requests to prevent automated attacks on a system. This combined functionality would enhance Muddu and Gaddam’s method by establishing a baseline of expected user behavior for detecting potentially malicious activity.
The combination of Muddu, Gaddam, and Turgeman does not expressly teach by generating computer task using the cryptographic algorithm with asymmetric encryption and sending the generated task to the suspicious user, and receiving a solution from the suspicious user, if the received solution is correct, identifying the suspicious user as a legitimate user, if the received solution is incorrect, identifying the suspicious user as a bot; c) blocking access to the resource for the user identified as a bot, providing access to the resource for the user identified as a legitimate user.
However, Chesla teaches by generating computer task [using the cryptographic algorithm with asymmetric encryption] (Chesla – Paragraph [0040]: Once the encrypted connection between the CPE 420 and client 201 has been negotiated i.e., CPE 420 acts as the server 202 in front of the client 201, the application-based DoS mechanism 413 generates a client web challenge in order to determine if the client is real and not an attack tool (e.g., a Bot)) and sending the generated task to the suspicious user (Chesla – Paragraph [0041]: The generated client web challenge is passed to the CPE 420 which encrypts the challenge and sends it to the client over the encrypted connection), and receiving a solution from the suspicious user (Chesla – Paragraph [0041]: If the CPE 420 receives a response from the client during a predefined time-internal, the CPE 420 decrypts the response and passes it to the mechanism 413 to determine if the response is correct), if the received solution is correct, identifying the suspicious user as a legitimate user (Chesla – Paragraph [0041]: If the client 201 correctly responded to the web challenge, the system 212 forces the client 201 to seamlessly open a new encrypted connection directly with the protected server 202. In one embodiment, the traffic over the new encrypted connection is transferred through the security system 212, which bypasses such traffic according to the source IP address. That is, once a new encrypted connection is generated from an "authenticated" source IP (i.e., the client that responds correctly to the challenge), the connection request (e.g., SYN packet) bypasses the protection mechanisms and is directly sent to the server 202), if the received solution is incorrect, identifying the suspicious user as a bot (Chesla – Paragraph [0042]: Alternatively, if the client 201 is an attack tool, then the current encrypted connection between the CPE 420 and the client 201 is dropped. Thus, once a suspect traffic is identified, the connection between the server 202 and client 202 is terminated as long as the traffic was not cleared by the security system 212); c) blocking access to the resource for the user identified as a bot (Chesla – Paragraph [0042]: Alternatively, if the client 201 is an attack tool, then the current encrypted connection between the CPE 420 and the client 201 is dropped. Thus, once a suspect traffic is identified, the connection between the server 202 and client 202 is terminated as long as the traffic was not cleared by the security system 212), providing access to the resource for the user identified as a legitimate user (Chesla – Paragraph [0041]: Chesla – Paragraph [0041]: If the client 201 correctly responded to the web challenge, the system 212 forces the client 201 to seamlessly open a new encrypted connection directly with the protected server 202. In one embodiment, the traffic over the new encrypted connection is transferred through the security system 212, which bypasses such traffic according to the source IP address. That is, once a new encrypted connection is generated from an "authenticated" source IP (i.e., the client that responds correctly to the challenge), the connection request (e.g., SYN packet) bypasses the protection mechanisms and is directly sent to the server 202).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Muddu, Gaddam, and Turgeman, further incorporating Chesla to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Chesla’s teaching of generating and sending a task to an unvalidated user to determine if the user is a bot into Muddu, Gaddam, and Turgeman’s combined method for analyzing user requests to detect and prevent automated attacks on a system. This combined functionality would further fortify the protective capabilities of the method by preventing system access to malicious bots.
The combination of Muddu, Gaddam, Turgeman, and Chesla does not expressly teach generating computer task using the cryptographic algorithm with asymmetric encryption.
However, Peddada teaches generating computer task using the cryptographic algorithm with asymmetric encryption (Peddada – Paragraph [0040]: Referring now to FIG. 3, a block diagram illustrating an example embodiment of a server system 120 and authentication module 121 is shown. In various embodiments, authentication module 121 is operable to determine whether to authenticate a requesting user of client system 102 to the service 122. For example, as discussed above, authentication module may be operable to generate challenge information—such as encrypted challenge value 140 and partially decrypted challenge value 142—to be sent to the client system 102; and Paragraph [0041]: authentication module 121 includes challenge value generator 302, which is operable to generate a challenge value 138, according to various embodiments. Challenge value 138, in various embodiments, may be a random or pseudo-random value generated using any suitable random or pseudo-random function. Authentication module 121 further includes encryption module 304, which is operable to encrypt challenge value 138 to generate encrypted challenge value 140. In various embodiments, encryption module 304 may use the RSA encryption algorithm to generate encrypted challenge value 140 by encrypting the challenge value 138 using the client public key 110; Examiner’s Comment: Examiner respectfully submits that RSA encryption is a commonly known type of asymmetric encryption in the art).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Muddu, Gaddam, Turgeman, and Chesla, further incorporating Peddada to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Peddada’s teaching of generating a user authentication task with asymmetric encryption into Muddu, Gaddam, Turgeman, and Chesla’s combined method for analyzing user requests to detect and prevent automated attacks on a system. This additional element would provide more security and assurance in determining whether a requesting user is legitimate.
Regarding Claim 2:
Muddu, Gaddam, Turgeman, Chesla, and Peddada combine to teach the method according to Claim 1.
Muddu further teaches wherein the numeric and statistical request metrics available at the network layer and/or available at the transport layer and/or available at the application level are collected (Muddu – Paragraph [0646]: The technique determine if the outgoing traffic is user-generated traffic based on a number of parameters, such as number of connection requests originating from the device in a predefined period, periodicity of the connections, number of web objects requested by the device, number of destinations contacted by the device, number of times a destination is contacted and number of ports of the destinations contacted; and Paragraph [0658]: The outgoing traffic can be any class of traffic, e.g., web traffic or IP traffic. The web traffic can include Hyper-Text Transfer Protocol (HTTP) message, which can be associated with parameters such as a destination IP address, a URI of the destination, a port number, a type of web request—GET or POST, etc.; Examiner’s Comment: HTTP/HTTPS protocol is discussed in specification paragraph [0030] as being available at the application layer; also, the network layer is described as the IP layer of the TCP/IP model in specification paragraph [00100]).
The motivation to combine the arts is the same as that of Claim 1.
Regarding Claim 3:
Muddu, Gaddam, Turgeman, Chesla, and Peddada combine to teach the method according to Claim 2.
Muddu further teaches wherein numerical and statistical metrics available at the application level, namely, the HTTP (Hypertext Transfer Protocol)/HTTPS (Hypertext Transfer Protocol Secure) protocol are collected (Muddu – Paragraph [0646]: The technique determine if the outgoing traffic is user-generated traffic based on a number of parameters, such as number of connection requests originating from the device in a predefined period, periodicity of the connections, number of web objects requested by the device, number of destinations contacted by the device, number of times a destination is contacted and number of ports of the destinations contacted; and Paragraph [0658]: The outgoing traffic can be any class of traffic, e.g., web traffic or IP traffic. The web traffic can include Hyper-Text Transfer Protocol (HTTP) message, which can be associated with parameters such as a destination IP address, a URI of the destination, a port number, a type of web request—GET or POST, etc.; Examiner’s Comment: HTTP/HTTPS protocol is discussed in specification paragraph [0030] as being available at the application layer).
The motivation to combine the arts is the same as that of Claim 1.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Muddu, in view of Gaddam, Turgeman, Chesla, Peddada, and Bilas et al. (US 20200374297 A1), hereinafter Bilas.
Regarding Claim 4:
Muddu, Gaddam, Turgeman, Chesla, and Peddada combine to teach the method according to Claim 1.
Muddu further teaches wherein the metrics characterizing the user based on statistics of the user’s communication with the resource are calculated based on the statistics of the user's communication with the resource (Muddu – Paragraph [0646]: The technique determine if the outgoing traffic is user-generated traffic based on a number of parameters, such as number of connection requests originating from the device in a predefined period, periodicity of the connections, number of web objects requested by the device, number of destinations contacted by the device, number of times a destination is contacted and number of ports of the destinations contacted).
The combination of Muddu, Gaddam, Turgeman, Chesla, and Peddada does not expressly teach namely, a median time between requests to the computer system is calculated, which is characteristic of the user.
However, Bilas teaches namely, a median time between requests to the computer system is calculated, which is characteristic of the user (Bilas – Paragraph [0010]: One or more zone-wide metrics (of all sessions for a zone over a predetermined time) may also be computed including one or more of: the median duration of all sessions, the median number of requests per session across all sessions, the number of failed requests compared to the number of successful requests across all sessions, inter-request gap distribution across all sessions (e.g., the amount of time passing from one request to another request during the sessions), request content-type distribution across the sessions, inter-request timings for specific content types across the sessions (e.g., inter-request timings for HTML pages), response code distribution across the sessions, and/or HTTP method distribution across the sessions. The ratios between the per-session metrics the zone-wide metrics may also be computed; and Paragraph [0011]: A comparison is made between the current request and/or session with historical data analyzed from previous requests and/or sessions to determine whether a client network application is malicious (e.g., a bot that serves malicious purposes)).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Muddu, Gaddam, Turgeman, Chesla, and Peddada, further incorporating Mammadli to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Mammadli’s teaching to calculate the mean time change between successive user requests for use in anomaly detection into Muddu, Gaddam, Turgeman, Chesla, and Peddada’s combined method for processing user requests to prevent automated attacks. This combined functionality would further enhance the method’s capability to identify potential non-human activity.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Muddu, in view of, Gaddam, Turgeman, Chesla, Peddada, and Johansson et al. (US 10050787 B1), hereinafter Johansson.
Regarding Claim 5:
Muddu, Gaddam, Turgeman, Chesla, and Peddada combine to teach the method according to Claim 1.
The combination of Muddu, Gaddam, Turgeman, Chesla, and Peddada does not expressly teach wherein when evaluating the user as legitimate, the user is provided with access to the resource, namely, a limited access token is provided.
However, Johansson teaches wherein when evaluating the user as legitimate, the user is provided with access to the resource, namely, a limited access token is provided (Johansson – Col. 44, Lines 19-30: If determined 2306 that the user is allowed access, the process 2300 may include providing access in accordance with the delegation authentication object. As noted, providing access may be performed in various ways in accordance with various embodiments. For example,...a credential (e.g., digital token) may be given to the user's device to enable the user's device to submit requests for access with the token, thereby enabling a system receiving the request/token to provide access as a result of validating the token).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Muddu, Gaddam, Turgeman, Chesla, and Peddada, further incorporating Johansson to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Johansson’s teaching to provide a verified user with an access token into Muddu, Gaddam, Turgeman, Chesla, and Peddada’s combined method for processing user requests to prevent automated attacks. This combined functionality would add convenience and objectivity for identifying verified users and allowing them to access the resources they are requesting.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Muddu, in view of Gaddam, Turgeman, Chesla, Peddada, Campagna et al. (US 10291408 B2), hereinafter Campagna, and Sterne et al. (US 20160344752 A1), hereinafter Sterne.
Regarding Claim 6:
Muddu, Gaddam, Turgeman, Chesla, and Peddada combine to teach the method according to Claim 1.
Muddu further teaches to identify bots, wherein identification of the bots further comprises (Muddu – Figure 73: an example of a set of parameters that can be considered for distinguishing between machine-generated traffic and user-generated traffic).
Turgeman further teaches wherein the additional verification of the suspicious user comprises: obtaining additional metrics of a browser of the suspicious user (Turgeman – Paragraph [0082]: For example, the system may detect that even though 24 key-down events and 24 key-up events were registered, their timing pattern does not match the timing pattern of actual content as entered; such that, for example, the input-unit indicates that all 24 characters were manually entered within a time-frame of three seconds using a generally-constant typing speed, whereas the electronic device and/or its applications (e.g., Web browser, native application, or the like) indicate that the manual entry of data had a different timing scheme (e.g., that a first field was filled-out within 4 seconds, then no input-unit events were registered for 7 seconds, then a second field was filled-out within 5 seconds). Such different, non-matching, timing schemes or timing patterns, may allow the system to determine or to estimate that a fraudulent malware is operating the device, rather than a legitimate human user.).
The combination of Muddu, Gaddam, Turgeman, Chesla, and Peddada does not expressly teach a task is formed based on the key.
However, Campagna teaches forming a task based on a key (Campagna – Col. 2, Lines 58-63: a challenge may include generating a Merkle tree using a SHA-256 cryptographic hash algorithm having a root node value with 32 leading zeroes and to sign a provided message using the first signing key (e.g., corresponding to the leftmost leaf node) of the Merkle tree).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Muddu, Gaddam, Turgeman, Chesla, and Peddada, further incorporating Campagna to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Campagna’s teaching to generate a task for user verification based at least in part on a key into Muddu, Gaddam, Turgeman, Chesla, and Peddada’s combined method for processing user requests to prevent automated attacks. This combined functionality would add an additional layer of security in verifying a user requesting access to a resource.
The combination of Muddu, Gaddam, Turgeman, Chesla, Peddada, and Campagna does not expressly teach sending the task and a request token to a computer system of the suspicious user, receiving a solution to the task and a response token from the computer system of the suspicious user, in response to the solution being incorrect, blocking access of the suspicious user to the resource.
However, Sterne teaches sending the task and a request token to a computer system of the suspicious user (Sterne – Paragraph [0013]: The system for preventing a brute force attack provides the challenge token and workfactor to the client. The challenge token and workfactor comprise a challenge that the client must satisfactorily respond to in order for the system for preventing a brute force attack to even consider a login attempt), receiving a solution to the task and a response token from the computer system of the suspicious user (Sterne – Paragraph [0013]: The client system determines a response token responding to the challenge token and workfactor, and provides the response token along with a password associated with the username to the system. The system for preventing a brute force attack determines whether the response token satisfies a condition), in response to the solution being incorrect, blocking access of the suspicious user to the resource (Sterne – Paragraph [0019]: In the event it is determined that the response token does not satisfy a condition based at least in part on the workfactor, control passes to 414. In 414, the username and password are disregarded. In some embodiments, an error message is provided to the client (e.g., indicating the response token does not satisfy the condition). The process then ends).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Muddu, Gaddam, Turgeman, Chesla, Peddada, and Campagna, further incorporating Sterne to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Sterne’s implementation of challenge and response tokens along with a challenge for user authentication into Muddu, Gaddam, Turgeman, Chesla, Peddada, and Campagna’s combined method for processing user requests to prevent automated attacks. This combined functionality would further enhance the security benefits of the method by adding another layer of security to the task assigned to the requesting user.
Claims 7-9 are rejected under 35 U.S.C. 103 as being unpatentable over Muddu, in view of Gaddam, Turgeman, Chesla, Peddada, Campagna, Sterne, and Hussain et al. (US 20180218145 A1), hereinafter Hussain.
Regarding Claim 7:
Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, and Sterne combine to teach the method according to claim 6.
The combination of Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, and Sterne does not expressly teach wherein the additional metrics of the suspicious user's browser are obtained during the additional verification of the suspicious user, wherein obtaining the additional metrics further comprises: checking operability of various features of Java Script language, checking a version of the browser of the suspicious user.
However, Hussain teaches wherein the additional metrics of the suspicious user's browser are obtained during the additional verification of the suspicious user (Hussain – Paragraph [0004]: Organizations generally desire to protect their computers and networks by ensuring that their users are running up-to-date versions of web software applications. Additionally, these organizations typically seek to define policy to restrict access to corporate computers and/or corporate networks unless the web software applications are proven to be up-to-date with the latest versions of patches, application types, and the like to reduce the risk of exploitation of unfixed deficiencies in the applications), wherein obtaining the additional metrics further comprises: checking operability of various features of Java Script language (Hussain – Paragraph [0013]: A first method (e.g., test 1 includes providing computer-executable code or script (e.g., JavaScript, HTML, CSS, and the like) and/or an identity algorithm that runs in the target software application, such as a web browser, and inspects the runtime environment of the browser to detect the browser type and version), checking a version of the browser of the suspicious user (Hussain – Paragraph [0013]: A first method (e.g., test 1 includes providing computer-executable code or script (e.g., JavaScript, HTML, CSS, and the like) and/or an identity algorithm that runs in the target software application, such as a web browser, and inspects the runtime environment of the browser to detect the browser type and version).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, and Sterne, further incorporating Hussain to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Hussain’s teaching to further verify a user’s browser version into Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, and Sterne’s combined method for processing user requests to prevent automated attacks. This combined functionality would provide the method with another metric by which to evaluate a requesting user’s legitimacy.
Regarding Claim 8:
Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, and Sterne combine to teach the method according to claim 6.
The combination of Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, and Sterne does not expressly teach wherein the additional metrics of the suspicious user's browser are obtained during the additional verification of the suspicious user, wherein obtaining the additional metrics further comprises: checking operability of various implementations of CSS (Cascading style Sheets) language, checking a version of the browser of the suspicious user.
However, Hussain teaches wherein the additional metrics of the suspicious user's browser are obtained during the additional verification of the suspicious user (Hussain – Paragraph [0004]: Organizations generally desire to protect their computers and networks by ensuring that their users are running up-to-date versions of web software applications. Additionally, these organizations typically seek to define policy to restrict access to corporate computers and/or corporate networks unless the web software applications are proven to be up-to-date with the latest versions of patches, application types, and the like to reduce the risk of exploitation of unfixed deficiencies in the applications), wherein obtaining the additional metrics further comprises: checking operability of various implementations of CSS (Cascading style Sheets) language (Hussain – Paragraph [0013]: A first method (e.g., test 1 includes providing computer-executable code or script (e.g., JavaScript, HTML, CSS, and the like) and/or an identity algorithm that runs in the target software application, such as a web browser, and inspects the runtime environment of the browser to detect the browser type and version), checking a version of the browser of the suspicious user (Hussain – Paragraph [0013]: A first method (e.g., test 1 includes providing computer-executable code or script (e.g., JavaScript, HTML, CSS, and the like) and/or an identity algorithm that runs in the target software application, such as a web browser, and inspects the runtime environment of the browser to detect the browser type and version).
The motivation to combine the arts is the same as that of Claim 7.
Regarding Claim 9:
Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, and Sterne combine to teach the method according to claim 6.
The combination of Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, and Sterne does not expressly teach wherein during the additional verification of the suspicious user, the additional metrics of the suspicious user's browser are obtained, wherein obtaining the additional metrics further comprises: checking operability of various implementations of HTML (Hypertext Markup Language) language, checking a version of the browser of the suspicious user.
However, Hussain teaches wherein during the additional verification of the suspicious user, the additional metrics of the suspicious user's browser are obtained (Hussain – Paragraph [0004]: Organizations generally desire to protect their computers and networks by ensuring that their users are running up-to-date versions of web software applications. Additionally, these organizations typically seek to define policy to restrict access to corporate computers and/or corporate networks unless the web software applications are proven to be up-to-date with the latest versions of patches, application types, and the like to reduce the risk of exploitation of unfixed deficiencies in the applications), wherein obtaining the additional metrics further comprises: checking operability of various implementations of HTML (Hypertext Markup Language) language (Hussain – Paragraph [0013]: A first method (e.g., test 1 includes providing computer-executable code or script (e.g., JavaScript, HTML, CSS, and the like) and/or an identity algorithm that runs in the target software application, such as a web browser, and inspects the runtime environment of the browser to detect the browser type and version), checking a version of the browser of the suspicious user (Hussain – Paragraph [0013]: A first method (e.g., test 1 includes providing computer-executable code or script (e.g., JavaScript, HTML, CSS, and the like) and/or an identity algorithm that runs in the target software application, such as a web browser, and inspects the runtime environment of the browser to detect the browser type and version).
The motivation to combine the arts is the same as that of Claim 7.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Muddu, in view of Gaddam, Turgeman, Chesla, Peddada, Campagna, Sterne, Hussain, and Bailey et al. (US 20170070523 A1), hereinafter Bailey.
Regarding Claim 10:
Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, and Sterne combine to teach the method according to claim 6.
The combination of Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, and Sterne does not expressly teach wherein the additional metrics of the suspicious user's browser are obtained during the additional verification of the suspicious user; to clarify an operation mode of the browser of the suspicious user.
However, Hussain teaches wherein the additional metrics of the suspicious user's browser are obtained during the additional verification of the suspicious user (Hussain – Paragraph [0004]: Organizations generally desire to protect their computers and networks by ensuring that their users are running up-to-date versions of web software applications. Additionally, these organizations typically seek to define policy to restrict access to corporate computers and/or corporate networks unless the web software applications are proven to be up-to-date with the latest versions of patches, application types, and the like to reduce the risk of exploitation of unfixed deficiencies in the applications); to clarify an operation mode of the browser of the suspicious user (Hussain – Paragraph [0013]: inspects the runtime environment of the browser to detect the browser type and version).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, and Sterne, further incorporating Hussain to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Hussain’s teaching to further verify a user’s browser version into Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, and Sterne’s combined method for processing user requests to prevent automated attacks. This combined functionality would provide the method with another metric by which to evaluate a requesting user’s legitimacy.
The combination of Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, Sterne, and Hussain does not expressly teach wherein obtaining the additional metrics further comprises: checking window parameters, presence of mouse movement and other factors.
However, Bailey teaches wherein obtaining the additional metrics further comprises: checking window parameters, presence of mouse movement (Bailey – Paragraph [0280]: IsRunningHeadlessBrowser; and Paragraph [0281]: A widget may be programmed to request graphics card information, viewport information, and/or window information (e.g. window.innerHeight, document.body.clientWidth, etc.). Additionally, or alternatively, the widget may be programmed to watch for mouse movement inside a form) and other factors (Bailey – Paragraphs [0278]-[0301]: Various checks to verify browser legitimacy).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, Sterne, and Hussain further incorporating Bailey to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Bailey’s checks on window parameters, mouse movement and other browser factors into Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, Sterne, and Hussain’s combined method for processing user requests to prevent automated attacks. This combined functionality would provide the method with additional metrics by which to evaluate a requesting user’s legitimacy.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Muddu, in view of Gaddam, Turgeman, Chesla, Peddada, Campagna, Sterne, Hussain, and Erwan et al. (Abgrall, Erwan et al. “XSS-FP: Browser Fingerprinting using HTML Parser Quirks.” ArXiv abs/1211.4812 (2012): p. 1-13), hereinafter Erwan.
Regarding Claim 11:
Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, and Sterne combine to teach the method according to claim 6.
The combination of Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, and Sterne does not expressly teach wherein during the additional verification of the suspicious user, the additional metrics of the suspicious user's browser are obtained.
However, Hussain teaches wherein during the additional verification of the suspicious user, the additional metrics of the suspicious user's browser are obtained (Hussain – Paragraph [0004]: Organizations generally desire to protect their computers and networks by ensuring that their users are running up-to-date versions of web software applications. Additionally, these organizations typically seek to define policy to restrict access to corporate computers and/or corporate networks unless the web software applications are proven to be up-to-date with the latest versions of patches, application types, and the like to reduce the risk of exploitation of unfixed deficiencies in the applications).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, and Sterne, further incorporating Hussain to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Hussain’s teaching to further verify a user’s browser version into Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, and Sterne’s combined method for processing user requests to prevent automated attacks. This combined functionality would provide the method with another metric by which to evaluate a requesting user’s legitimacy.
The combination of Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, Sterne and Hussain does not expressly teach wherein obtaining the additional metrics further comprises: obtaining a signature that is unique for an installation of the browser of the suspicious user, which, at the same time does not provide a unique identification to the browser of the suspicious user.
However, Erwan teaches wherein obtaining the additional metrics further comprises: obtaining a signature that is unique for an installation of the browser of the suspicious user (Erwan – P. 1, Col. 1: there are two kinds of browser fingerprinting. On the one hand, one may uniquely identify a browser (see e.g. [3]), on the other hand, one may uniquely identify a browser type, that is, identifying the browser implementation (e.g. Firefox vs Internet Explorer) and its version number (e.g. IE8 vs IE9)), which, at the same time does not provide a unique identification to the browser of the suspicious user (Erwan – P. 9 , Col. 2 and P. 10, Col. 1: D. Panopticlick: Browser Uniqueness Fingerprint In this paper, Eckersley et al. collect bits of information from various browser properties user agent string, screen resolution, installed fonts and plug-ins) to fingerprint the user browser [3]. These pieces of information are collected through Java, Flash, and JavaScript. Using all these properties a user can sometimes be uniquely identified. Compared to our work, the differences are important. First, uniquely identifying a browser instance does not necessarily imply knowing the browser type and version for attacks or counter-measures).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, Sterne and Hussain further incorporating Erwan to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Erwan’s assigning a signature for a version and type of web browser but not for an individual browser into Muddu, Gaddam, Turgeman, Chesla, Peddada, Campagna, Sterne and Hussain’s combined method for processing user requests to prevent automated attacks. This combined functionality would provide the capability to track suspicious activity related to a version and type of web browser that may not be directly traceable or attributable to one specific user’s activity.
Claims 12 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Muddu, in view of Gaddam, Chesla, and Peddada.
Regarding Claim 12:
Muddu teaches a system for preventing malicious automated attacks, comprising (Muddu – Paragraph [0438]: the present disclosure relates to methods and systems for organizing and presenting information concerning potential network compromise to one or more users tasked with monitoring the network and thwarting attacks, stolen data, and other harm; and Paragraph [0569]: classification metadata 6320 for a particular user can include metadata indicative that the user is a regular user, an administrative user, or an automated (machine-implemented) user): a server comprising the service/services for processing user requests (Muddu – Figure 74: block diagram of environment in which to deploy a system for detecting traffic anomalies; and Paragraph [0662]: The traffic classification module (7430) determines whether the group of connection requests is user-generated traffic or machine-generated traffic. The user-generated traffic, as described above, can be a result of an activity performed by a user 7420 associated with the device 7405, e.g., accessing a webpage in the Internet using the device 7405) with a module for evaluating the legitimacy of the requests from the user (Muddu – Paragraph [0656]: The system 7425 monitors the outgoing traffic of the device 7405, e.g., using outgoing traffic log 7450, and detects any existence of anomalies and/or threats) and a suspicious user additional verification module (Muddu – Paragraph [0675]: After the anomaly detection module 7435 determines the groups to be anomalous, the anomaly detection module 7435 indicates those groups as an anomaly 7455 to the threat analysis module 7460, which can further analyze the anomaly 7455 to determine if it is a threat and raise an alarm, e.g., generate a notification, if it is one), wherein the module for evaluating a legitimacy of the request received from the user comprises: a module for connection metrics collection (Muddu – Paragraph [0677]: For example, the traffic classification module 7430 receives outgoing traffic log 7450, which contains information regarding outgoing connection requests from device 7405), a module for basic metrics collection (Muddu – Paragraph [0646]: The technique determine if the outgoing traffic is user-generated traffic based on a number of parameters, such as number of connection requests originating from the device in a predefined period, periodicity of the connections, number of web objects requested by the device, number of destinations contacted by the device, number of times a destination is contacted and number of ports of the destinations contacted; Paragraph [0647]: The technique can perform the above described method using real-time infrastructure, e.g., real-time analyzer 210 of FIG. 2 and/or analysis module 330 of FIG. 3 described above) at an application level (Muddu – Paragraph [0646]: The technique determine if the outgoing traffic is user-generated traffic based on a number of parameters, such as number of connection requests originating from the device in a predefined period, periodicity of the connections, number of web objects requested by the device, number of destinations contacted by the device, number of times a destination is contacted and number of ports of the destinations contacted; and Paragraph [0658]: The outgoing traffic can be any class of traffic, e.g., web traffic or IP traffic. The web traffic can include Hyper-Text Transfer Protocol (HTTP) message, which can be associated with parameters such as a destination IP address, a URI of the destination, a port number, a type of web request—GET or POST, etc.; Examiner’s Comment: HTTP/HTTPS protocol is discussed in specification paragraph [0030] as being available at the application layer) a module of statistical user metrics (Muddu – Paragraph [0646]: The technique determine if the outgoing traffic is user-generated traffic based on a number of parameters, such as number of connection requests originating from the device in a predefined period, periodicity of the connections, number of web objects requested by the device, number of destinations contacted by the device, number of times a destination is contacted and number of ports of the destinations contacted), a module for matching metrics by session with values usual for a resource and by communication of the user to the resource (Muddu – Paragraph [0149]: Also in this description, an “anomaly” is a detected variation from an expected pattern of behavior on the part of an entity, which variation may or may not constitute a threat; and Paragraph [0211]: An entity can include, for example, a user, a device, an application, a session, a uniform resource locator (URL), or a threat; and Paragraph [0259]: Generally, sessionization can be created by using the same or similar data structure as that used for correlating users with devices in identity resolution. When the beginning or end of a session is detected, the event data associated with events from the session should be explicitly marked (e.g., as a field in the event data). Then, with the identity resolution and the device resolution techniques, all data events resolved to the user within the time window of an active session are associated with the session; and Paragraph [0147]: In this description the term “event data” refers to machine data related to activity on a network with respect to an entity of focus); said modules are configured to transmit data to (Muddu – Paragraph [0675]: After the anomaly detection module 7435 determines the groups to be anomalous, the anomaly detection module 7435 indicates those groups as an anomaly 7455 to the threat analysis module 7460, which can further analyze the anomaly 7455 to determine if it is a threat and raise an alarm, e.g., generate a notification, if it is one; Examiner’s Comment: this teaching by Muddu explicitly demonstrates that modules have the capability to transmit data to other modules); which is configured to transmit data to (Muddu – Paragraph [0675]: After the anomaly detection module 7435 determines the groups to be anomalous, the anomaly detection module 7435 indicates those groups as an anomaly 7455 to the threat analysis module 7460, which can further analyze the anomaly 7455 to determine if it is a threat and raise an alarm, e.g., generate a notification, if it is one) a module for sending factors to a machine learning model (Muddu – Paragraph [0647]: The malware beacon detection technique introduced here can operate in real-time, e.g., as and when the traffic is generated from the computer device. The technique can perform the above described method using real-time infrastructure, e.g., real-time analyzer 210 of FIG. 2 and/or analysis module 330 of FIG. 3 described above. Additionally or alternatively, the technique can operate in a batch processing mode by using the batch processing infrastructure, e.g., batch analyzer 240 and/or batch analysis module 382; and Paragraph [0648]: Further, the above described method can be performed by a model, such as a machine learning model. The model can output the result of the detection as a yes or no (or the equivalent), or as a score based on which the machine-generated traffic can be determined as an anomalous or not. The model can be implemented in real-time infrastructure and/or batch processing infrastructure), and wherein the module for computation of a vector of request factors and the module for sending factors to a machine learning model and calculating a result based on [the vector of request factors that includes] collected, calculated and determined metrics are also made as part of the module for evaluating the legitimacy of the request from the user (Muddu – Figure 74: block diagram of environment in which to deploy a system for detecting traffic anomalies; and Paragraph [0646]: The technique determine if the outgoing traffic is user-generated traffic based on a number of parameters, such as number of connection requests originating from the device in a predefined period, periodicity of the connections, number of web objects requested by the device, number of destinations contacted by the device, number of times a destination is contacted and number of ports of the destinations contacted; Examiner’s Comment: this illustration by Muddu explicitly demonstrates that one greater module can contain multiple modules contributing to verifying users/user requests), which is configured to identify the user as a legitimate user, or as a suspicious user, or as a bot (Muddu – Figure 78: Flow diagram of determining whether traffic is user- or machine-generated; and Figure 79: Flow diagram for determining whether machine-generated traffic is anomalous (potentially malicious)) based on the evaluation of the legitimacy of the request (Muddu – Paragraph [0648]: Further, the above described method can be performed by a model, such as a machine learning model).
Muddu does not expressly teach a module for computation of a vector of request factors, which is configured to transmit data to a module for sending factors to a machine learning model and calculating a result; and the module for sending factors to a machine learning model and calculating a result based on the vector of request factors that includes collected, calculated and determined metrics; evaluation of the legitimacy of the request carried out by the machine learning model.
However, Gaddam teaches a module for computation of a vector of request factors (Gaddam – Paragraph [0088]: The online subsystem 104A can generate a feature vector from request data included in the request to access the resource, determine an entity profile corresponding to the requesting entity, determine a production model correspond to the entity profile, produce a trust score using the feature vector as an input to the production model, and analyze the trust score using a policy engine to produce a resource access policy; and Paragraph [0242]: Additionally, and of the steps of any of the methods can be performed with modules, circuits, or other means for performing these steps), which is configured to transmit data to a module for sending factors to a machine learning model and calculating a result (Gaddam – Paragraph [0088]: The online subsystem 104A can generate a feature vector from request data included in the request to access the resource, determine an entity profile corresponding to the requesting entity, determine a production model correspond to the entity profile, produce a trust score using the feature vector as an input to the production model, and analyze the trust score using a policy engine to produce a resource access policy; and Paragraph [0242]: Additionally, and of the steps of any of the methods can be performed with modules, circuits, or other means for performing these steps); and the module for sending factors to a machine learning model and calculating a result based on the vector of request factors that includes collected, calculated and determined metrics (Gaddam – Paragraph [0088]: The online subsystem 104A can generate a feature vector from request data included in the request to access the resource, determine an entity profile corresponding to the requesting entity, determine a production model correspond to the entity profile, produce a trust score using the feature vector as an input to the production model, and analyze the trust score using a policy engine to produce a resource access policy; and Paragraph [0242]: Additionally, and of the steps of any of the methods can be performed with modules, circuits, or other means for performing these steps; and Paragraph [0013]: These machine learning models accept database access requests or sequences of database access requests (referred to as “access sequences”) as feature vectors and produce anomaly scores. The anomaly scores can classify database access requests or access sequences as normal or anomalous); evaluation of the legitimacy of the request carried out by the machine learning model (Gaddam – Paragraph [0088]: The online system 104A can comprise a computer or network of computers. The online subsystem 104 can receive requests to access resources, either directly from the requesting entity 102 or from the requesting entity 102 via the resource gateway 106. The online subsystem 104A can generate a feature vector from request data included in the request to access the resource, determine an entity profile corresponding to the requesting entity, determine a production model correspond to the entity profile, produce a trust score using the feature vector as an input to the production model, and analyze the trust score using a policy engine to produce a resource access policy; and Paragraph [0128]: At step 414, the resource access system can determine a trust score by applying the feature vector as an input to the production model. The trust score can be used by the resource access system to determine whether the request is malicious or benign; and Paragraph [0242]: Additionally, and of the steps of any of the methods can be performed with modules, circuits, or other means for performing these steps; and Paragraph [0013]: These machine learning models accept database access requests or sequences of database access requests (referred to as “access sequences”) as feature vectors and produce anomaly scores. The anomaly scores can classify database access requests or access sequences as normal or anomalous).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Muddu, further incorporating Gaddam to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Gaddam’s teaching to utilize modules for vectorizing request factors to be used as input to a machine learning model for evaluating the legitimacy of the requests into Muddu’s multi-modular system for processing user requests to prevent automated attacks. This addition would enhance Muddu’s system by streamlining the request evaluation process.
The combination of Muddu and Gaddam does not expressly teach and the suspicious user additional verification module is configured to perform a verification of the suspicious user by generating a computer task using a cryptographic algorithm with asymmetric encryption and send the generated task to the suspicious user, and receive suspicious user's solution, and the suspicious user verification module is configured to identify the suspicious user as a legitimate user or as a bot based on the received solution, and server is configured to block access to the resource for the user identified as a bot, and to provide access to the resource for the user identified as a legitimate user.
However, Chesla teaches and the suspicious user additional verification module is configured to perform a verification of the suspicious user by generating a computer task [using a cryptographic algorithm with asymmetric encryption] (Chesla – Paragraph [0040]: Once the encrypted connection between the CPE 420 and client 201 has been negotiated i.e., CPE 420 acts as the server 202 in front of the client 201, the application-based DoS mechanism 413 generates a client web challenge in order to determine if the client is real and not an attack tool (e.g., a Bot)) and send the generated task to the suspicious user (Chesla – Paragraph [0041]: The generated client web challenge is passed to the CPE 420 which encrypts the challenge and sends it to the client over the encrypted connection), and receive a solution from a suspicious user(Chesla – Paragraph [0041]: If the CPE 420 receives a response from the client during a predefined time-internal, the CPE 420 decrypts the response and passes it to the mechanism 413 to determine if the response is correct), and the suspicious user verification module is configured to identify the suspicious user as a legitimate user or as a bot based on the received solution (Chesla – Paragraph [0041]: If the client 201 correctly responded to the web challenge, the system 212 forces the client 201 to seamlessly open a new encrypted connection directly with the protected server 202. In one embodiment, the traffic over the new encrypted connection is transferred through the security system 212, which bypasses such traffic according to the source IP address. That is, once a new encrypted connection is generated from an "authenticated" source IP (i.e., the client that responds correctly to the challenge), the connection request (e.g., SYN packet) bypasses the protection mechanisms and is directly sent to the server 202; and Paragraph [0042]: Alternatively, if the client 201 is an attack tool, then the current encrypted connection between the CPE 420 and the client 201 is dropped. Thus, once a suspect traffic is identified, the connection between the server 202 and client 202 is terminated as long as the traffic was not cleared by the security system 212), and server is configured to block access to the resource for the user identified as a bot (Chesla – Paragraph [0042]: Alternatively, if the client 201 is an attack tool, then the current encrypted connection between the CPE 420 and the client 201 is dropped. Thus, once a suspect traffic is identified, the connection between the server 202 and client 202 is terminated as long as the traffic was not cleared by the security system 212), and to provide access to the resource for the user identified as a legitimate user (Chesla – Paragraph [0041]: Chesla – Paragraph [0041]: If the client 201 correctly responded to the web challenge, the system 212 forces the client 201 to seamlessly open a new encrypted connection directly with the protected server 202. In one embodiment, the traffic over the new encrypted connection is transferred through the security system 212, which bypasses such traffic according to the source IP address. That is, once a new encrypted connection is generated from an "authenticated" source IP (i.e., the client that responds correctly to the challenge), the connection request (e.g., SYN packet) bypasses the protection mechanisms and is directly sent to the server 202).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Muddu and Gaddam, further incorporating Chesla to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Chesla’s teaching of generating and sending a task to an unvalidated user to determine if the user is a bot into Muddu and Gaddam’s combined system for analyzing user requests to detect and prevent automated attacks on a system. This combined functionality would further fortify the protective capabilities of the method by preventing system access by malicious bots.
The combination of Muddu, Gaddam, and Chesla does not expressly teach generating a computer task using the cryptographic algorithm with asymmetric encryption.
However, Peddada teaches generating a computer task using the cryptographic algorithm with asymmetric encryption (Peddada – Paragraph [0040]: Referring now to FIG. 3, a block diagram illustrating an example embodiment of a server system 120 and authentication module 121 is shown. In various embodiments, authentication module 121 is operable to determine whether to authenticate a requesting user of client system 102 to the service 122. For example, as discussed above, authentication module may be operable to generate challenge information—such as encrypted challenge value 140 and partially decrypted challenge value 142—to be sent to the client system 102; and Paragraph [0041]: authentication module 121 includes challenge value generator 302, which is operable to generate a challenge value 138, according to various embodiments. Challenge value 138, in various embodiments, may be a random or pseudo-random value generated using any suitable random or pseudo-random function. Authentication module 121 further includes encryption module 304, which is operable to encrypt challenge value 138 to generate encrypted challenge value 140. In various embodiments, encryption module 304 may use the RSA encryption algorithm to generate encrypted challenge value 140 by encrypting the challenge value 138 using the client public key 110; Examiner’s Comment: Examiner respectfully submits that RSA encryption is a commonly known type of asymmetric encryption in the art).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Muddu, Gaddam, and Chesla, further incorporating Peddada to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Peddada’s teaching of generating a user authentication task with asymmetric encryption into Muddu, Gaddam, and Chesla’s combined system for analyzing user requests to detect and prevent automated attacks on a system. This additional element would provide more security and assurance in determining whether a requesting user is legitimate.
Regarding Claim 13:
Muddu, Gaddam, Chesla, and Peddada combine to teach the system according to Claim 12.
Muddu further teaches wherein the collection of connection metrics is performed (Muddu – Paragraph [0646]: The technique determine if the outgoing traffic is user-generated traffic based on a number of parameters, such as number of connection requests originating from the device in a predefined period, periodicity of the connections, number of web objects requested by the device, number of destinations contacted by the device, number of times a destination is contacted and number of ports of the destinations contacted) at least at the network layer and/or transport layer (Muddu – Paragraph [0658]: The outgoing traffic can be any class of traffic, e.g., web traffic or IP traffic. The web traffic can include Hyper-Text Transfer Protocol (HTTP) message, which can be associated with parameters such as a destination IP address, a URI of the destination, a port number, a type of web request—GET or POST, etc.; Examiner’s Comment: the network layer is described as the IP layer of the TCP/IP model in specification paragraph [00100]).
The motivation to combine the arts is the same as that of Claim 12.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Muddu, in view of Gaddam, Chesla, Peddada, Hussain, Bailey, and Erwan.
Regarding Claim 14:
Muddu, Gaddam, Chesla, and Peddada combine to teach the system according to Claim 12.
Muddu further teaches in which the suspicious user additional verification module comprises (Muddu – Figure 74: block diagram of environment in which to deploy a system for detecting traffic anomalies; Examiner’s Comment: this illustration by Muddu explicitly demonstrates that one greater module can contain multiple modules contributing to verifying users/user requests): a module for sending collected data associated with the above-mentioned modules (Muddu – Paragraph [0675]: After the anomaly detection module 7435 determines the groups to be anomalous, the anomaly detection module 7435 indicates those groups as an anomaly 7455 to the threat analysis module 7460, which can further analyze the anomaly 7455 to determine if it is a threat and raise an alarm, e.g., generate a notification, if it is one); and a starting unit associated with the above-mentioned modules (Muddu – Paragraph [0745]: Embodiments of the techniques introduced here include various steps and operations, which have been described above. A variety of these steps and operations may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause one or more general-purpose or special-purpose processors programmed with the instructions to perform the steps; Examiner’s Comment: Paragraph [0085] of the specification recites that a “unit” maybe interpreted as a processor).
Peddada further teaches a cryptographic module that generates and sends a task to the user (Peddada – Paragraph [0040]: as discussed above, authentication module may be operable to generate challenge information—such as encrypted challenge value 140 and partially decrypted challenge value 142—to be sent to the client system 102).
The combination of Muddu, Gaddam, Chesla, and Peddada does not expressly teach a JS (JavaScript) stack checking module, which checks functionality of JS language features; a CSS stack checking module, which checks functionality of CSS implementation features; a HTML stack checking module, which checks functionality of HTML implementation features; that reveal a browser operation mode.
However, Hussain teaches a JS stack checking module, which checks functionality of JS language features (Hussain – Paragraph [0023]: In some embodiments, the browser identifier component 112 may be a module implemented by one or more computer processors of the access control platform; and Paragraph [0013]: A first method (e.g., test 1 includes providing computer-executable code or script (e.g., JavaScript, HTML, CSS, and the like) and/or an identity algorithm that runs in the target software application, such as a web browser, and inspects the runtime environment of the browser to detect the browser type and version); a CSS stack checking module, which checks functionality of the CSS implementation features (Hussain – Paragraph [0023]: In some embodiments, the browser identifier component 112 may be a module implemented by one or more computer processors of the access control platform; and Paragraph [0013]: A first method (e.g., test 1 includes providing computer-executable code or script (e.g., JavaScript, HTML, CSS, and the like) and/or an identity algorithm that runs in the target software application, such as a web browser, and inspects the runtime environment of the browser to detect the browser type and version); a HTML stack checking module, which checks functionality of HTML implementation features (Hussain – Paragraph [0023]: In some embodiments, the browser identifier component 112 may be a module implemented by one or more computer processors of the access control platform; and Paragraph [0013]: A first method (e.g., test 1 includes providing computer-executable code or script (e.g., JavaScript, HTML, CSS, and the like) and/or an identity algorithm that runs in the target software application, such as a web browser, and inspects the runtime environment of the browser to detect the browser type and version); that reveal a browser operation mode (Hussain – Paragraph [0013]: A first method (e.g., test 1 includes providing computer-executable code or script (e.g., JavaScript, HTML, CSS, and the like) and/or an identity algorithm that runs in the target software application, such as a web browser, and inspects the runtime environment of the browser to detect the browser type and version).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Muddu, Gaddam, Chesla, and Peddada, further incorporating Hussain to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Hussain’s teaching to further verify a user’s browser version by checking JS, CSS, and HTML functionality into Muddu, Gaddam, Chesla, and Peddada’s combined system for processing user requests to prevent automated attacks. This combined functionality would provide the system with additional techniques by which to evaluate a requesting user’s legitimacy.
The combination of Muddu, Gaddam, Chesla, Peddada, and Hussain does not expressly teach a HeadLess detection module, which checks window parameters, presence of mouse movement and factors.
However, Bailey teaches a HeadLess detection module, which checks window parameters, presence of mouse movement (Bailey – Paragraph [0280]: IsRunningHeadlessBrowser; and Paragraph [0281]: A widget may be programmed to request graphics card information, viewport information, and/or window information (e.g. window.innerHeight, document.body.clientWidth, etc.). Additionally, or alternatively, the widget may be programmed to watch for mouse movement inside a form) and factors (Bailey – Paragraphs [0278]-[0301]: Various checks to verify browser legitimacy).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Muddu, Gaddam, Chesla, Peddada, and Hussain, further incorporating Bailey to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Bailey’s teaching to further verify a user’s browser version by checking window parameters, mouse movement, and other factors into Muddu, Gaddam, Chesla, Peddada, and Hussain’s combined system for processing user requests to prevent automated attacks. This combined functionality would provide the system with additional techniques by which to evaluate the proper functionality of a requesting user’s browser.
The combination of Muddu, Gaddam, Chesla, Peddada, Hussain, and Bailey does not expressly teach a module for calculating a unique signature, which provides a calculation of a unique signature for a browser installation that prevents a unique identification of a browser.
However, Erwan teaches a module for calculating a unique signature (Erwan – P. 2, Col. 1: With browser fingerprinting, at any point in time, server software can: 1) verify whether the HTTP user-agent matches the inferred browser type (detection of UA spoofing) 2) verify whether the inferred browser type matches the browser that was used on login (detection of session stealing); Examiner’s Comment: Specification paragraph [00108] states "All modules are software components, part of a software package that the processor executes."), which provides a calculation of a unique signature for a given browser installation (Erwan – P. 1 Col. 1: there are two kinds of browser fingerprinting. On the one hand, one may uniquely identify a browser (see e.g. [3]), on the other hand, one may uniquely identify a browser type, that is, identifying the browser implementation (e.g. Firefox vs Internet Explorer) and its version number (e.g. IE8 vs IE9)), that prevents a unique identification of a browser (Erwan – P. 9, Col. 2 and P. 10, Col. 1: D. Panopticlick: Browser Uniqueness Fingerprint
In this paper, Eckersley et al. collect bits of information from various browser properties (user agent string, screen resolution, installed fonts and plug-ins) to fingerprint the user browser [3]. These pieces of information are collected through Java, Flash, and JavaScript. Using all these properties a user can sometimes be uniquely identified. Compared to our work, the differences are important. First, uniquely identifying a browser instance does not necessarily imply knowing the browser type and version for attacks or counter-measures).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Muddu, Gaddam, Chesla, Peddada, Hussain, and Bailey further incorporating Erwan to arrive at the conclusion of the claimed invention. One would be motivated to incorporate Erwan’s assigning a signature for a version and type of web browser but not for an individual browser into Muddu, Gaddam, Chesla, Peddada, Hussain, and Bailey’s combined system for processing user requests to prevent automated attacks. This combined functionality would provide the capability to track suspicious activity related to a version and type of web browser that may not be directly traceable or attributable to one specific user’s activity.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Parshall et al. (US 10936662 B1) teaches a method for classifying a user as a human or an automated agent based on a record of user interactions with a user interface
Wang et al. (US 20200068035 A1) teaches a method and system for detecting whether a user of an application is human or a bot based on a collected history of user interactions with the application
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 NICHOLAS JOSEPH DILUZIO whose telephone number is (703)756-1229. The examiner can normally be reached Mon - Fri -- 7:30 AM - 5 PM.
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, Yin-Chen Shaw can be reached at 571-272-8878. 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.
/NICHOLAS JOSEPH DILUZIO/Examiner, Art Unit 2498
/YIN CHEN SHAW/Supervisory Patent Examiner, Art Unit 2498
Prosecution Insights