Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
This Office Action is in response to an Amendment Application received on 12/08/2025. In the application, claims 1, 13, and 20 have been amended. Claims 2-12, and 14-19 remain original. No claim has been cancelled and no new claim has been added.
For this Office Action, claims 1-20 have been received for consideration and have been examined.
Response to Arguments
Claim Rejections – 35 USC § 102
Applicant’s arguments with respect to claim(s) 1, 13, and 20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Lind., (US20220141220A1) in view of Ligatti et al., (US9659160B2).
Regarding claim 1, Lind discloses:
A method, comprising:
receiving [i.e., by authentication system 110] a request for registering a device (i.e., enrollment of a malicious client 140 device – FIG. 3; step 335) that is to be used for multi-factor authentication (MFA) (see [0004] & [0013]) of an account (FIG. 3; [0037] In the example of FIG. 3, the malicious client device 140 somehow obtains 330 cloned authentication credentials of the enrolled client device 130 with the purpose of using them to obtain authentication from the authentication system 110 … the malicious client interface 145 provides 335 an access request to the authentication system 110 for access to services);
receiving, from the device, a plurality of device properties (i.e., see [0027] authentication token comprising client device metadata / shared key shared / other account details related to the client device between the enrolled client device and authentication system) (FIG. 3; [0037] As with interaction 310, the authentication system 110 requests 340 an authentication token and device metadata from the malicious client device 140 based on the access request received from the malicious client interface 145. The malicious client device 140 provides 345 an authentication token and device metadata to the authentication system 110, where the malicious client device 140 generates the authentication token using the cloned authentication credentials);
retrieving a plurality of account properties ([0027] retrieving account authentication token comprising client device metadata / shared key shared / other account details related to the client device between the enrolled client device and authentication system; [0037] The malicious client device 140 provides 345 an authentication token and device metadata to the authentication system 110, where the malicious client device 140 generates the authentication token using the cloned authentication credentials);
calculating a likelihood for a device registration associated with the device being malicious by processing the plurality of device properties and the plurality of account properties with one or more pre-determined rules (i.e., rules associated with risk level module) and with one or more pre-trained machine-learning models (i.e., machine learning techniques) ([0032] In some embodiments, the risk level module 220 uses a rule-based technique to determine risk levels for client devices. In this case, the risk level module 220 may associate one or more rules with each type of device metadata value. In particular, the one or more rules associated with a type of device metadata value define how a device metadata anomaly is determined by comparing device metadata values of the type (e.g., any discrepancy between the values, a discrepancy above a threshold, etc.) or a contribution of a device metadata anomaly for device metadata values of the type to a risk level; [0033] In some embodiments, the risk level module 220 uses one or more machine learning techniques to determine risk levels for client devices. In this case, the risk level module 220 may train a risk level model to predict a risk level for a client device given device metadata for the client device and stored device metadata from an enrolled client device (e.g., device metadata included in enrollment information associated with the access request) as input. The risk level module 220 may train the risk level model by using a training data set consisting of pairs of device metadata sets including a first set of device metadata representing a client device associated with an access request to be authorized and a second set of device metadata representing a stored device metadata for an enrolled client device; [0037] After receiving the device metadata from the malicious client device 140, the authentication system 110 determines a risk level for the malicious client device 140 by comparing 350 the stored device metadata for the enrolled client device 130 to the device metadata for the malicious client device 140);
determining that the likelihood exceeds a pre-determined threshold ([0037] Based on the risk level, the authentication system 110 denies 355 the access rests provided by the malicious client interface 145. For instance, the authentication module 210 may determine the risk level exceeds a risk level threshold defined in an authentication policy associated with the service provider 120; [0040] In particular, the risk level indicates a likelihood the second client device is not the first client device. Based on the risk level, the authentication system 110 denies 450 the access request, such as based on the risk level exceeding a threshold (e.g., a numerical score or risk designation threshold)); and
sending, in response to determining that the likelihood exceeds the pre-determined threshold, a notification indicating that the likelihood for the device registration being malicious exceeds the pre-determined threshold ([0026] Furthermore, in addition to denying the access request, the authentication module 210 may take various other security measures, such as notifying the enrolled client device or adding the impersonating client device to a list of blocked client devices).
Lind fails to disclose:
retrieving, from a database, the plurality of account properties comprise a list of devices registered to be used for MFA of account.
However, Ligatti discloses:
retrieving, from a database (i.e., data store 112/verified device identifiers 130), the plurality of account properties comprise a list of devices registered to be used for MFA of account (Abstract: A system and method of authentication using an authenticator computing device and at least two registered user devices is described. In operation, the authenticator computing device receives a request to access a resource from one of a plurality of user devices registered to a user; Col. 7, Line # 26-29; The authenticator computing device 103 can also comprise a data store 112 configured to store user credentials 124, authentication challenges 127, verified device identifiers 130; Col. 7, Line # 41-46; The verified device identifiers 130 can comprise data regarding devices 105 that a user has registered with the authenticator computing device 103. For example, when a user registers a device 105, the user can be prompted to enter a device name. The device name can be stored as a verified device identifier 130 in the data store 112).
It would have been obvious to an ordinary skill in the art before the effective filing date of the claimed invention to modify the authentication system of Lind and add a database which stores users registered devices in a data store, as disclosed by Ligatti.
The motivation to add the database which stores users registered devices in the data store is to be able to verify client devices when they authenticate to access a resource.
Regarding claim 13, it is a system claim and recites similar subject matter as claim 1 and therefore rejected under similar ground of rejection.
Regarding claim 20, it is a computer-readable non-transitory storage media claim and recites similar subject matter as claim 1 and therefore rejected under similar ground of rejection.
Regarding claim 2, the combination of Lind and Ligatti discloses:
The method of claim 1, wherein the plurality of device properties comprise static device properties (i.e., model / manufacturer / SIM card) and dynamic device properties (i.e., authentication keys / current time / geographic location) (Lind: [0015] Device metadata values describe physical hardware or software characteristics of a client device. In particular, the physical hardware or software characteristics described by device metadata values are characteristics that are change infrequently, and are therefore unlikely to have changed between access requests received from an enrolled client device. For example, device metadata values can include an operating system (OS) version, screen size, processor count, model, manufacturer, serial number, international mobile equipment identity (IMEI), cellular radio type, subscriber identity module (SIM) card identifier, disk capacity, physical memory capacity, user interface type (e.g., iPad, iPhone, Mac, etc.); [0027] In some embodiments, the authentication module 210 provides an authentication key to the enrolled client device 130 during enrollment to use for signing a payload of authentication related data to generate authentication tokens, such as authentication credentials, client device metadata, or other authentication-related parameters (e.g., a current time or geographic location of the enrolled client device 130). The authentication keys may be a secret key shared between the enrolled client device and the authentication system 110, such as a secret key for generating a hash-based message authentication code (HMAC)).
Regarding claim 14, it is a system claim and recites similar subject matter as claim 2 and therefore rejected under similar ground of rejection.
Regarding claim 3, the combination of Lind and Ligatti discloses:
The method of claim 2, wherein the static device properties comprise a device type, a device model, or a list of hardware components within the device (Lind: [0015]).
Regarding claim 15, it is a system claim and recites similar subject matter as claim 3 and therefore rejected under similar ground of rejection.
Regarding claim 4, the combination of Lind and Ligatti discloses:
The method of claim 2, wherein the dynamic device properties comprise an operating system of the device, a phone number, a list of installed applications, or records of previous events associated with the device (Lind: [0015]).
Regarding claim 16, it is a system claim and recites similar subject matter as claim 4 and therefore rejected under similar ground of rejection.
Regarding claim 5, the combination of Lind and Ligatti discloses:
The method of claim 1, wherein the plurality of account properties comprise account status properties and account history properties (Lind: [0013-0014]).
Regarding claim 17, it is a system claim and recites similar subject matter as claim 5 and therefore rejected under similar ground of rejection.
Regarding claim 6, the combination of Lind and Ligatti discloses:
The method of claim 5, wherein the account status properties comprise information associated with an organization of the account, a current state of the account, or a list of devices registered for the account (Lind: [0026]).
Regarding claim 18, it is a system claim and recites similar subject matter as claim 6 and therefore rejected under similar ground of rejection.
Regarding claim 7, the combination of Lind and Ligatti discloses:
The method of claim 6, wherein the account history properties comprise records of previous authentications of the account, wherein each of the records comprises an identity of an authentication device used for an authentication, a plurality of properties associated with the authentication device, a time of the authentication, a location of the authentication device when the authentication occurs, or one or more authentication methods used for the authentication (Lind: [0027]).
Regarding claim 19, it is a system claim and recites similar subject matter as claim 7 and therefore rejected under similar ground of rejection.
Regarding claim 8, the combination of Lind and Ligatti discloses:
The method of claim 7, wherein each of the one or more pre-determined rules defines a set of conditions associated with a corresponding known attack pattern, wherein the set of conditions comprises conditions associated with a subset of the plurality of device properties and the plurality of account properties (Lind: [0032]).
Regarding claim 9, the combination of Lind and Ligatti discloses:
The method of claim 8, wherein the pre-determined rule calculates a probability for the device registration being malicious based on similarities between the conditions associated with the subset and property values of the subset (Lind: [0032]).
Regarding claim 10, the combination of Lind and Ligatti discloses:
The method of claim 1, wherein one of the one or more pre-trained machine-learning models is a classifier computing a probability for the device registration being malicious by processing input associated with the device (Lind: [0033-0034]).
Regarding claim 11, the combination of Lind and Ligatti discloses:
The method of claim 10, wherein the input comprises one or more of the plurality of device properties (Lind: [0027]).
Regarding claim 12, the combination of Lind and Ligatti discloses:
The method of claim 11, wherein the input further comprises one or more of the plurality of account properties (Lind: [0028]).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 SYED M AHSAN whose telephone number is (571)272-5018. The examiner can normally be reached 8:30 AM - 6:00 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, Amir Mehrmanesh can be reached at 571-270-3351. 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.
/SYED M AHSAN/Primary Examiner, Art Unit 2491