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 .
Claim Objections
Claim 7, 8, and 19 are objected to because of the following informalities:
Claim 7 recites “The method of claim 6 further comprising” which should be changed to -- The method of claim 6, further comprising:--.
Claim 8 recites “The method of claim 1 further comprising” which should be changed to --The method of claim 1, further comprising:--.
Claim 19 recites “the processor to cause the apparatus to,” which should be changed to --the processor to cause the apparatus to:--.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1, line 6 recites “the MFA challenges”. There is insufficient antecedent basis for this limitation in the claim because it’s unclear whether “the MFA challenges” refers back to the “subsequent MFA challenges” or to “a first multi-factor authentication (MFA) challenge” in addition to the “subsequent MFA challenges”.
Claim 1 recites the limitation "the first fatigue attack detection rule" in line 8. There is insufficient antecedent basis for this limitation in the claim.
Claim 2 recites the limitation “subsequent MFA challenges to the user”, however it’s unclear if this recitation refers back to claim 1’s recitation of “subsequent MFA challenges for the user”, or to additionally received subsequent MFA challenges.
Claim 5 recites the limitation “communicating the MFA failure events” which lacks proper antecedent basis.
Claim 7 recites “the first failure event” which lacks proper antecedent basis.
Claim 8 recites “failure events for MFA challenges” which lacks proper antecedent basis. Claim 8 further recites “the plurality of fatigue attack detection rules” which also lacks proper antecedent basis.
Claim 10 recites “the MFA challenges” at line 7, which lacks proper antecedent basis for the same reason noted for claim 1 above.
Claim 11 recites “subsequent MFA challenges to the user”, however it’s unclear if this recitation refers back to claim 10’s recitation of “subsequent MFA challenges for the user”, or to additionally received subsequent MFA challenges.
Claim 14 recites “communicating the MFA failure events” which lacks proper antecedent basis.
Claim 19, line 9 recites “the MFA challenges” which lacks proper antecedent basis.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-4, 6-13, and 15-20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by “Rajakumar” (US 2024/0098113).
Regarding Claim 1:
A method comprising:
based on detecting a failure event to a first multi-factor authentication (MFA) challenge for a user (Fig. 5, step 550; ¶0085, “At 550, if the user does not indicate that they initiated the request for authentication at 530, the computer system determines that an MFA Fatigue attack is occurring…”; ¶0080, “The process illustrated in flow chart 500, for example, may be performed during a default authentication procedure and in some implementations may occur after a determination that the lookback attempts do not exceed the allowed lookback attempts in 450 and 460 of FIG. 4”; i.e., steps in Fig. 5 occur after authentication challenge step 460 of Fig. 4), tracking failure events to subsequent MFA challenges for the user (¶0085, “… and provides an indication of the MFA Fatigue attack. By way of example, computer system may electronically set the attack flag … The computer system may record the time that the attack flag is set, which may be used for later resolution of the MFA Fatigue attack”);
selecting a first set of a plurality of sets of fatigue attack detection rules based on a first MFA implementation corresponding to the MFA challenges (Fig. 4, steps 410 and 420; ¶0072; ¶0073);
correlating tracked failure events to determine whether the failure events collectively satisfy the first fatigue attack detection rule (Fig. 4, steps 430, 440, and 450 disclose storing records and determining (correlating) the number of MFA requests are made during a time threshold in order to determine whether the number of MFA requests exceeds an allowed threshold rule); and
based on a determination that the tracked failure events collectively satisfy the first fatigue attack detection rule, performing a security action defined for the first fatigue attack detection rule (Fig. 4, steps 450 and 470; ¶0078, “Additionally, the entity on which the attack flag is set may be configured to be different for different users or groups of users. The computer system may record the time that the attack flag is set, which may be used for later resolution of the MFA Fatigue attack”).
Regarding Claim 2:
The method of claim 1, wherein performing the security action comprises blocking subsequent MFA challenges to the user of the first MFA implementation for at least a defined time period (Fig. 9, steps 930 and 950; ¶0113, “At 950, if there is an indication of MFA Fatigue attack for an entity that includes the user at 930, the computer system will check to determine if the authentication process should remain in safe mode for the user, e.g., by determining if the reset time window has expired”; ¶0090, “For example, after an MFA Fatigue attack has been identified for the entity, the computer system may place the authentication process for that entity in a “safe mode” (SM) in order to block improper authentication due to the MFA Fatigue attack”).
Regarding Claim 3:
The method of claim 1, wherein performing the security action comprises blocking access of an account of the user corresponding to the MFA challenges (Fig. 8 details a “safe mode” process that is enabled upon determining that a MFA fatigue attack is underway, which effectively “blocks” access to the user’s account).
Regarding Claim 4:
The method of claim 1, wherein the first fatigue attack detection rule indicates criteria comprising a quantity of failure events within a time window (Fig. 4, step 420; ¶0073, “At 420, an allowed attempts threshold, sometimes referred to as the allowed lookback attempts (ALA), is set. The allowed lookback attempts is the threshold number of allowed requests for authentication for a given user within the lookback threshold used by the computer system to evaluate whether an MFA Fatigue attack is occurring”).
Regarding Claim 6:
The method of claim 1, wherein tracking failure events to subsequent MFA challenges comprises maintaining a count of the failure events within a sliding time window (Fig. 4, step 440; ¶0075, “At 440, for each incoming request for authentication for a given user received by the computer system, the computer system determines the number of requests for authentication within the time window prior to the current request for authentication determined based on the lookback threshold”).
Regarding Claim 7:
The method of claim 6 further comprising recording time of the first failure event as a window start time (¶0005, “… a method for detecting a Multi-Factor Authentication (MFA) Fatigue attack includes receiving an attempt at authentication attempt at authentication for a user via an electronic interface, the attempt at authentication comprising … storing, in an electronic record, the attempt at authentication for the user including at least … a time of the attempt at authentication for the user”).
Regarding Claim 8:
The method of claim 1 further comprising analyzing network traffic of failure events for MFA challenges of a plurality of MFA implementations (¶0074, “At 430, for each incoming request for authentication for a given user received by the computer system, the computer system stores an electronic record … The computer system, for example, may evaluate whether the total number of originating systems used for originating requests for authentication for a given user within the lookback threshold time window exceeds the threshold number of allowable originating systems to determine whether an MFA Fatigue attack is occurring”) and determining criteria of the plurality of fatigue attack detection rules based on the analysis (¶0074, “In some implementations, the number of originating systems may be used to dynamically vary the lookback threshold or the allowed lookback attempts. For example, the threshold number of allowed requests for authentication may decrease as the number of originating systems increases, or the lookback threshold may increase as the number of originating systems increases”).
Regarding Claim 9:
The method of claim 1, wherein tracking failure events comprises at least one of analyzing network traffic carrying the failure events (¶0074, “At 430, for each incoming request for authentication for a given user received by the computer system, the computer system stores an electronic record … The computer system, for example, may evaluate whether the total number of originating systems used for originating requests for authentication for a given user within the lookback threshold time window exceeds the threshold number of allowable originating systems to determine whether an MFA Fatigue attack is occurring”) and analyzing application programming interface (API) calls of an identity provider corresponding to the MFA challenges.
Regarding Claims 10-13 and 15-18:
Non-transitory computer-readable medium claims 10-13 and 15-18 correspond to respective method claims 1-4 and 6-9, and contain no further limitations. Therefore, each of claims 10-13 and 15-18 are rejected by applying the same rationale used to reject claims 1-4 and 6-9 above, respectively.
Regarding Claim 19:
Apparatus claim 19 corresponds to method claim 1, and contains no further limitations. Therefore claim 19 is rejected by applying the same rationale used to reject claim 1 above.
Regarding Claim 20:
The apparatus of claim 19, wherein the instructions to track failure events to subsequent MFA challenges comprise instructions to track characteristics of the failure events (Fig. 4, step 430; ¶0074, “At 430, for each incoming request for authentication for a given user received by the computer system, the computer system stores an electronic record, e.g., in memory 225 or in a database 220, which may sometimes be referred to as an authentication attempt record (AAR)”), wherein the tracked characteristics correspond to criteria defined in the first fatigue attack detection rule (¶0074, “The computer system, for example, may evaluate whether the total number of originating systems used for originating requests for authentication for a given user within the lookback threshold time window exceeds the threshold number of allowable originating systems to determine whether an MFA Fatigue attack is occurring”).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 5 and 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Rajakumar” (US 2024/0098113) in view of “Venkataramani” (US 9571497).
Regarding Claim 5:
Rajakumar teaches:
The method of claim 1, …
Rajakumar does not disclose:
… wherein selecting the first fatigue attack detection rule comprises selecting a first of a plurality of fatigue attack signatures and wherein correlating tracked failure events comprises evaluating network traffic communicating the MFA failure events against the first fatigue attack signature.
Venkataramani teaches:
… wherein selecting the first fatigue attack detection rule comprises selecting a first of a plurality of fatigue attack signatures (Fig. 5, steps 502 and 504/506 disclose capturing an IP address (i.e., one of a plurality of “fatigue attack” signatures) corresponding to a received login attempt) and wherein correlating tracked failure events comprises evaluating network traffic communicating the MFA failure events against the first fatigue attack signature (Col. 11, lines 2-9, “f the IP address is already blacklisted, the systems described herein may block the login attempt and/or decline to send a push request. If not, the systems described herein may check to see if the attempt exceeds a threshold for similar attempts (i.e., attempts from the same or similar sources). If the attempt does exceed the threshold, the systems described herein may block the login attempt and/or decline to send a push request”; i.e., determine whether network traffic corresponding to the IP address exceeds a threshold of attempts for MFA).
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Rajakumar’s system to mitigating multi-factor authentication (MFA) fatigue attacks by enhancing Rajakumar’s system to further correlate IP addresses of devices to MFA failure events, as taught by Venkataramani, in order to detect both the same and similar sources that are conducting an MFA fatigue attack.
The motivation is to prevent a source from circumventing a threshold based on MFA fatigue attack attempts by tracking and correlating an IP address of the source to the threshold, thus providing the means for an MFA fatigue attack mitigation system to sequentially count attack attempts from the same and similar sources.
Regarding Claim 14:
Non-transitory computer-readable medium claim 14 corresponds to method claim 5 and contains no further limitations. Therefore claim 14 is rejected by applying the same rationale used to reject claim 5 above.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL B POTRATZ whose telephone number is (571)270-5329. The examiner can normally be reached on M-F 10 A.M. - 6 P.M. CST.
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, William Korzuch can be reached on 571-272-7589. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/DANIEL B POTRATZ/Primary Examiner, Art Unit 2491