DETAILED ACTION
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 .
This Office Action is in response to the Amendment filed on 10/29/2025.
In instant Amendment, claims 1, 8 and 14 have been amended; claims 2, 9 and 15 were canceled; claims 1, 8 and 14 are independent claims. Claims 1, 3-8, 10-14 and 16-20 have been examined and are pending. This Action is made Final.
Response to Arguments
Applicants’ arguments with respect to the 35 U.S.C. 103 rejection have been fully considered and are not persuasive and/or are moot in view of the new ground(s) of rejection.
Applicant Argues: Specifically, Vincent and Andrews, singularly or in combination do not teach or suggest the following recitation of the independent claims: (1) detecting a failed user authentication attempt associated with the first user device, wherein the failed user authentication attempt comprises detecting a threshold number of failed authentication attempts and locking the first user device based on detecting the threshold number of failed authentication attempts; and (2) detecting that an alternative authentication process based on the one or more alternative authentication options has succeeded, wherein detecting the alternative authentication process further comprises capturing live authentication data from the user and comparing the live authentication data to reference authentication data associated with the user and first user device.
Examiner’s Response: The examiner respectfully notes that with respect to (1) detecting a failed user authentication attempt associated with the first user device, wherein the failed user authentication attempt comprises detecting a threshold number of failed authentication attempts and locking the first user device based on detecting the threshold number of failed authentication attempts. Such features are taught by Khaleghi, as Khaleghi teaches in ¶[0030] - The system may lock out a user or user device have a threshold number of failed authentication attempts. Therefore, the examiner finds this argument not persuasive as Khaleghi was shown to teach this feature previously.
The examiner respectfully notes that with respect to (2) detecting that an alternative authentication process based on the one or more alternative authentication options has succeeded, wherein detecting the alternative authentication process further comprises capturing live authentication data from the user and comparing the live authentication data to reference authentication data associated with the user and first user device. Such, features have required an updated search, and while Vincent discloses detecting that an alternative authentication process based on the one or more alternative authentication options has succeeded ( [0112] - A ‘more’ button is also displayed which, when selected, is operable to cause the interface to further display additional information about the authentication issues that need to be resolved. Selection of the ‘more’ button can also trigger the display of input fields that are operable to receive user input that defines conditions for a subsequent re-authentication to take place for the primary device and which will be reflected in the notification response sent to the identity provider), further newly found reference of Robert Jose teaches [detecting that an alternative authentication process based on the one or more alternative authentication options has succeeded] wherein detecting the alternative authentication process further comprises capturing live authentication data from the user and comparing the live authentication data to reference authentication data associated with the user and first user device (as amended) (FIG. 6 – YES → Retrieve User Profile Associated with Similar Biometric Signature (i.e., capturing live authentication data from the user and comparing the live authentication data to reference authentication data associated with the user and first user device) and FIG. 8 and [0080] – It should be noted that the determination at 608 and the subsequent prompt generation at 612 may be executed by biometric authentication process 800 of FIG. 8 as well as the various comparison methods depicted in FIGS. 10A-13. In some embodiments, the control circuitry may default to a non-biometric alternative authentication method based on the determination that the first type of biometric authentication has failed. In some embodiments, the control circuitry may prompt a second type of biometric authentication before prompting a user to provide a non-biometric input for a non-biometric type of authentication and [0090] - FIG. 8 depicts illustrative biometric authentication process 800 for prompting an alternative authentication method after detecting a failure of a first type of biometric authentication, in accordance with some disclosed methods and embodiments). Therefore, the examiner finds this argument moot in light of the amendment which has necessitating new grounds of rejection. In addition, Robert Jose teaches presenting one or more remediation options to the user on a display device, see rejection below.
Applicant Argues: However, at no point does the cited prior art allow for authentication of a locked account on an alternative authentication device by detecting that an alternative authentication process based on the one or more alternative authentication options has succeeded, wherein detecting the alternative authentication process further comprises capturing live authentication data from the user via the alternative device and comparing the live authentication data to reference authentication data associated with the user and first user device.
Examiner’s Response: The examiner respectfully notes that the combination of Vincent in view of Khaleghi and Robert Jose teaches the aforementioned features as noted above and as cited in the rejection below.
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, 3-5, 7-8, 10-12, 14, 16-18, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Vincent et al. (US 2017/0126640 A1) in view of Khaleghi (US 2021/0028927 A1) and Robert Jose et al. (US 2022/0277070 A1).
Regarding Claim 1;
Vincent discloses a system for user device recovery through alternative user authentication processes ([0013] - As described herein, various methods, systems and storage devices are provided for resolving authenticating issues of a first device with a second device. In some instances, the authenticating issues involve re-authenticating a primary device that was previously authenticated by notifying one or more secondary devices of an authentication failure event involving the first device), the system comprising:
a processing device (FIG. 1 and [0037]);
a non-transitory storage device containing instructions when executed by the processing device (FIG. 1 and [0037] and [0041]), causes the processing device to perform the steps of:
receiving a request to execute an intended user action using a first user device associated with a user ([0043] - During implementation, the authentication module (135) operates with the receiver (134) to receive authorization requests from the primary device and to authenticate the primary device or to fail the authorization request, depending on the circumstances and [0071] - Attention will now be directed to FIG. 2, which shows a simplified computing environment 200 to further clarify how authenticating issues for a first device can be resolved by using a second device. In this embodiment, Device A 220 requests a new service or submits a communication to the Identity Provider (210) corresponding to an existing service (201).);
detecting a failed user authentication attempt associated with the first user device ([0043] - During implementation, the authentication module (135) operates with the receiver (134) to receive authorization requests from the primary device and to authenticate the primary device or to fail the authorization request, depending on the circumstances and [0080);
[...]
detecting that an alternative authentication process based on the one or more alternative authentication options has succeeded ([0080] - In some instances, the notification comprises a user interface/interface object or instructions or code for rendering the interface/object, which is displayed to the user at the Secondary Device and which is selectable by the user to acknowledge or confirm a desired authentication state for the Primary Device to obtain requested services. For instance, the user can be presented the user interface object (e.g., a yes/no button interface or another interface, for validating authorization privileges) in an interactive display at the Secondary Device. The user can then select the object(s) that reflect the user intent to authorize or to reject authorization for the requested services for the Primary Device. These requested services can include access to multimedia content, performance of a financial transaction, or any other service that is requested by the Primary Device and [0091] - After the requisite authorizations are received from the secondary device(s), the requested services are then sent to the user by the Identity Provider and/or service provider and [0112] - A ‘more’ button is also displayed which, when selected, is operable to cause the interface to further display additional information about the authentication issues that need to be resolved. Selection of the ‘more’ button can also trigger the display of input fields that are operable to receive user input that defines conditions for a subsequent re-authentication to take place for the primary device and which will be reflected in the notification response sent to the identity provider); and
presenting one or more remediation options to the user on a display device ([0080] - In some instances, the notification comprises a user interface/interface object or instructions or code for rendering the interface/object, which is displayed to the user at the Secondary Device and which is selectable by the user to acknowledge or confirm a desired authentication state for the Primary Device to obtain requested services. For instance, the user can be presented the user interface object (e.g., a yes/no button interface or another interface, for validating authorization privileges) in an interactive display at the Secondary Device. The user can then select the object(s) that reflect the user intent to authorize or to reject authorization for the requested services for the Primary Device. These requested services can include access to multimedia content, performance of a financial transaction, or any other service that is requested by the Primary Device and [0091] - After the requisite authorizations are received from the secondary device(s), the requested services are then sent to the user by the Identity Provider and/or service provider. Alternatively, the requested services may only be provided after the Primary Device requests the services again, in a subsequent request (line 204) and [0112] - A ‘more’ button is also displayed which, when selected, is operable to cause the interface to further display additional information about the authentication issues that need to be resolved. Selection of the ‘more’ button can also trigger the display of input fields that are operable to receive user input that defines conditions for a subsequent re-authentication to take place for the primary device and which will be reflected in the notification response sent to the identity provider). As construed a subsequent request from a primary device is a remediation option as it may only be provided and/or a condition after requisite authorizations are received from the secondary device(s),
Vincent fails to explicitly disclose:
...wherein the failed user authentication attempt comprises detecting a threshold number of failed authentication attempts and locking the first user device based on detecting the threshold number of failed authentication attempts;
presenting one or more alternative authentication options to the user on a display device;
....wherein detecting the alternative authentication process further comprises capturing live authentication data from the user and comparing the live authentication data to reference authentication data associated with the user and first user device.
However, in an analogous art, Khaleghi teaches [detecting a failed user authentication attempt associated with the first user device] wherein the failed user authentication attempt comprises detecting a threshold number of failed authentication attempts ([0030] - The system may lock out a user or user device have a threshold number of failed authentication attempts); and locking the first user device based on detecting the threshold number of failed authentication attempts; ([0030] - The system may lock out a user or user device have a threshold number of failed authentication attempts).
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Khaleghi to the method of Vincent to include ...wherein the failed user authentication attempt comprises detecting a threshold number of failed authentication attempts and locking the first user device based on detecting the threshold number of failed authentication attempts.
One would have been motivated to combine the teachings of Khaleghi to Vincent to do so as it provides / allows control... in a secure and authenticated manner (Khaleghi, [0005]).
Further, in an analogous art, Robert Jose teaches
presenting one or more alternative authentication options to the user on a display device (FIG. 6 and FIG. 8 and [0080] – It should be noted that the determination at 608 and the subsequent prompt generation at 612 may be executed by biometric authentication process 800 of FIG. 8 as well as the various comparison methods depicted in FIGS. 10A-13. In some embodiments, the control circuitry may default to a non-biometric alternative authentication method based on the determination that the first type of biometric authentication has failed. In some embodiments, the control circuitry may prompt a second type of biometric authentication before prompting a user to provide a non-biometric input for a non-biometric type of authentication and [0090] - FIG. 8 depicts illustrative biometric authentication process 800 for prompting an alternative authentication method after detecting a failure of a first type of biometric authentication, in accordance with some disclosed methods and embodiments);
[detecting that an alternative authentication process based on the one or more alternative authentication options has succeeded] wherein detecting the alternative authentication process further comprises capturing live authentication data from the user and comparing the live authentication data to reference authentication data associated with the user and first user device (FIG. 6 – YES → Retrieve User Profile Associated with Similar Biometric Signature (i.e., capturing live authentication data from the user and comparing the live authentication data to reference authentication data associated with the user and first user device) and FIG. 8 and [0080] – It should be noted that the determination at 608 and the subsequent prompt generation at 612 may be executed by biometric authentication process 800 of FIG. 8 as well as the various comparison methods depicted in FIGS. 10A-13. In some embodiments, the control circuitry may default to a non-biometric alternative authentication method based on the determination that the first type of biometric authentication has failed. In some embodiments, the control circuitry may prompt a second type of biometric authentication before prompting a user to provide a non-biometric input for a non-biometric type of authentication and [0090] - FIG. 8 depicts illustrative biometric authentication process 800 for prompting an alternative authentication method after detecting a failure of a first type of biometric authentication, in accordance with some disclosed methods and embodiments);
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings Robert Jose to the alternative user authentication processes of Vincent in view of Khaleghi to include presenting one or more alternative authentication options to the user on a display device and ....wherein detecting the alternative authentication process further comprises capturing live authentication data from the user and comparing the live authentication data to reference authentication data associated with the user and first user device.
One would have been motivated to combine the teachings of Robert Jose to Vincent in view of Khaleghi to do so as it provides /allows adaptive biometric authentication that accommodates one or more varying biometric characteristic (Robert Jose, [0003]).
Regarding Claim 3;
Vincent in view of Khaleghi and Robert Jose and disclose the system to Claim 1.
Vincent further discloses wherein the one or more alternative authentication options comprises initiating the alternative authentication process using a second user device ([0091] - After the requisite authorizations are received from the secondary device(s), the requested services are then sent to the user by the Identity Provider and/or service provider. Alternatively, the requested services may only be provided after the Primary Device requests the services again, in a subsequent request (line 204) and [0111]-[0112] - A ‘more’ button is also displayed which, when selected, is operable to cause the interface to further display additional information about the authentication issues that need to be resolved. Selection of the ‘more’ button can also trigger the display of input fields that are operable to receive user input that defines conditions for a subsequent re-authentication to take place for the primary device and which will be reflected in the notification response sent to the identity provider).
Regarding Claim 4;
Vincent in view of Khaleghi and Robert Jose disclose the system to Claim 3.
Vincent further discloses wherein the second user device is a mobile computing device of the user ([0059] - One or more secondary devices, such as Device B (150) or Device C (160) are associated with the user account and/or the primary device), wherein the alternative authentication process further comprises: establishing a wireless connection to the second user device ([0074] - Notification policies regarding content, formatting, timing, recipients, communication/notification channels, notification type (e.g., email, SMS, user interface, etc.) to use for the notification are stored in tables and other data structures accessible to the Identity Provider (210), such as tables 310, 320 and other similar tables and [0106] - In some instances, the interfaces (such as interfaces 700, 800 and 900) are generated by the notification modules of the identity provider or the service provider and are included with the notification(s) provided to the secondary devices. In other instances, the interfaces are generated directly by the notification modules of the secondary devices in response to the secondary device(s) receiving the notification(s). Instructions for constructing the interfaces can also be included with the notification(s). Combinations of the foregoing can also be used to generate the interfaces that are generated by, received by and/or presented through the secondary devices); transmitting an authentication query to the second user device ([0111]-[0012] - In FIG. 7, the interface 700 includes a selectable ‘fix’ button which, when selected, triggers a notification response to be generated and sent from the secondary device to the identity provider with sufficient information to trigger the identity provider to re-authenticate the primary device and to update the stored data structures corresponding to the corresponding user and device authentication status. A ‘more’ button is also displayed which, when selected, is operable to cause the interface to further display additional information about the authentication issues that need to be resolved. Selection of the ‘more’ button can also trigger the display of input fields that are operable to receive user input that defines conditions for a subsequent re-authentication to take place for the primary device and which will be reflected in the notification response sent to the identity provider); and receiving a response to the authentication query from the second user device ([0091] - After the requisite authorizations are received from the secondary device(s), the requested services are then sent to the user by the Identity Provider and/or service provider. Alternatively, the requested services may only be provided after the Primary Device requests the services again, in a subsequent request (line 204) and [0111]-[0112] - A ‘more’ button is also displayed which, when selected, is operable to cause the interface to further display additional information about the authentication issues that need to be resolved. Selection of the ‘more’ button can also trigger the display of input fields that are operable to receive user input that defines conditions for a subsequent re-authentication to take place for the primary device and which will be reflected in the notification response sent to the identity provider).
Regarding Claim 5;
Vincent in view of Khaleghi and Robert Jose disclose the system to Claim 4.
Vincent further discloses wherein the authentication query comprises a request to access a user application installed on the second user device ([0041] and [0106] - - In some instances, the interfaces (such as interfaces 700, 800 and 900) are generated by the notification modules of the identity provider or the service provider and are included with the notification(s) provided to the secondary devices. In other instances, the interfaces are generated directly by the notification modules of the secondary devices in response to the secondary device(s) receiving the notification(s). Instructions for constructing the interfaces can also be included with the notification(s). Combinations of the foregoing can also be used to generate the interfaces that are generated by, received by and/or presented through the secondary devices)
Regarding Claim 7;
Vincent in view of Khaleghi and Robert Jose disclose the system to Claim 1.
Vincent further discloses wherein the one or more remediation options comprises: returning control of the first user device to the user ([0041] - [0091] - After the requisite authorizations are received from the secondary device(s), the requested services are then sent to the user by the Identity Provider and/or service provider. Alternatively, the requested services may only be provided after the Primary Device requests the services again, in a subsequent request (line 204) and [0112] - A ‘more’ button is also displayed which, when selected, is operable to cause the interface to further display additional information about the authentication issues that need to be resolved. Selection of the ‘more’ button can also trigger the display of input fields that are operable to receive user input that defines conditions for a subsequent re-authentication to take place for the primary device and which will be reflected in the notification response sent to the identity provider); and automatically executing the intended user action based on detecting that the alternative authentication process has succeeded ([0041] - These modules (which can be stored in storage systems 127, 138, 157, 167) are executable modules that include specialized objects, routines, methods, function calls and APIs that are executable by the hardware processors (122, 132, 152, 162) to facilitate the functionality described herein for resolving authenticating issues, sometimes automatically and/or in response to conditional triggers, as also described and [0091] - After the requisite authorizations are received from the secondary device(s), the requested services are then sent to the user by the Identity Provider and/or service provider. Alternatively, the requested services may only be provided after the Primary Device requests the services again, in a subsequent request (line 204) and [0112] - A ‘more’ button is also displayed which, when selected, is operable to cause the interface to further display additional information about the authentication issues that need to be resolved. Selection of the ‘more’ button can also trigger the display of input fields that are operable to receive user input that defines conditions for a subsequent re-authentication to take place for the primary device and which will be reflected in the notification response sent to the identity provider).
Regarding Claim(s) 8 and 10-12; claim(s) 8 and 10-12 is/are directed to a/an program product associated with the system claimed in claim(s) 1 and 3-5. Claim(s) 8 and 10-12 is/are similar in scope to claim(s) 1 and 3-5, and is/are therefore rejected under similar rationale.
Regarding Claim(s) 14, 16-18, and 20; claim(s) 14, 16-18, and 20 is/are directed to a/an method associated with the system claimed in claim(s) 1, 3-5, and 7. Claim(s) 14, 16-18, and 20 is/are similar in scope to claim(s) 1, 3-5, and 7, and is/are therefore rejected under similar rationale.
Claim(s) 6, 13, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Vincent et al. (US 2017/0126640 A1) in view of Khaleghi (US 2021/0028927 A1) and Robert Jose et al. (US 2022/0277070 A1) and further in view of Velusamy (US 2017/0085546 A1)
Regarding Claim 6;
Vincent in view of Khaleghi and Robert Jose disclose the system to Claim 3.
Vincent further discloses [...] the alternative authentication process [...] ([0080]) and extracting a set of user authentication credentials from [a notification from the secondary device] ([0084]).
Vincent in view of Khaleghi and Robert Jose fails to explicitly disclose wherein the second user device is an object comprising a scannable code, wherein the scannable code comprises at least one of a QR code or a barcode , wherein the ... process further comprises: scanning the scannable code on the second user device; and extracting “authentication credentials” from the scannable code.
However, in an analogous art, Velusamy teaches wherein the second user device is an object comprising a scannable code, wherein the scannable code comprises at least one of a QR code or a barcode, wherein the ... process further comprises: scanning the scannable code on the second user device ([0036] - Authentication is provided by the user providing account information via a user interface (e.g., display) of the computing device 107. Once on the web page of the integrity server, the user may instruct the integrity server to provide information to unlock the user device 102. To that end, the integrity server, instead of sending the unlock code to the user device 102, may send the unlock command in the form of a QR code to the alternate computing device 107) and extracting “ authentication credentials” from the scannable code ([0036] - Authentication is provided by the user providing account information via a user interface (e.g., display) of the computing device 107. Once on the web page of the integrity server, the user may instruct the integrity server to provide information to unlock the user device 102. To that end, the integrity server, instead of sending the unlock code to the user device 102, may send the unlock command in the form of a QR code to the alternate computing device 107 and [0037] - Ione embodiment, the received QR code can be displayed on the user interface (e.g., display) of the computing device. In another embodiment, the computing device may instruct a printer to print out the QR code. The QR code can subsequently be scanned by the user device 102 to unlock the same, based on the request from the computing device 107 and [0092]-[0095]). As construed a command is a form of an authentication credential to perform a secure procedure (Velusamy, [0005] and [0019])
Therefore, it would have been obvious to one of ordinarily skill in the art before the effective filing date of the claimed invention to combine the teachings of Velusamy to the alternative authentication process of Vincent in view of Khaleghi and Robert Jose to include wherein the second user device is an object comprising a scannable code, wherein the scannable code comprises at least one of a QR code or a barcode , wherein the ... process further comprises: scanning the scannable code on the second user device; and extracting “authentication credentials” from the scannable code.
One would have been motivated to combine the teachings of Velusamy to Vincent in view of Khaleghi and Robert Jose to do so as it provides / allows to facilitate an automated and secure ... procedure (Velusamy , [0005]).
Regarding Claim(s) 13; claim(s) 13 is/are directed to a/an program product associated with the system claimed in claim(s) 6. Claim(s) 13 is/are similar in scope to claim(s) 6, and is/are therefore rejected under similar rationale.
Regarding Claim(s) 19; claim(s) 19 is/are directed to a/an method associated with the system claimed in claim(s) 6. Claim(s) 19 is/are similar in scope to claim(s) 6, and is/are therefore rejected under similar rationale.
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 KARI L SCHMIDT whose telephone number is (571)270-1385. The examiner can normally be reached Monday-Friday 10am - 6pm (MDT).
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, Luu Pham can be reached at (571)270-5002. 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.
/KARI L SCHMIDT/Primary Examiner, Art Unit 2439
Prosecution Insights