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 .
Claims 1-20 are pending in this application.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 07/25/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1, 2, 5-7, 10-12, 15-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Tolba et al. (US 8,862,888 B2) (hereinafter, “Tolba”) in view of Skerpac (US 2013/0132091 A1).
As to claim 1, Tolba discloses a computer-implemented method for authentication using one-time passwords (OTPs), the method comprising:
obtaining, by a computer, an operation request indicating an operation that originated at an inbound user device associated with an inbound user (“… receiving a user's identification and password transmitted from the user's mobile device, generating a One Time Password (OTP)” -e.g., see, Abstract; see also: “… a user's identification, such as a username or other "ID," and the user's password for the site being accessed is transmitted at 202, such as from the user's computing device (e.g., user computing device 106 of FIG. 1, for example, the user's PC), and is received by a server associated with the site, (e.g., authentication server 102 of system 100 shown in FIG. 1). At 204, an OTP is generated for the user.” -e.g., see, col. 4, lines 56-62; see also: “Such operations might include receiving a username and password such as transmitted from user computing device 106 or user mobile device 108,” -e.g., see, col. 4, lines 6-9; herein, the computer (authentication server 102) obtains/receives the initial identification and password that was transmitted from the user’s mobile device or computing device (the inbound user device associated with the inbound user). The transmitted data constitutes the operation/access request that originated at the inbound user device. The request indicates the operation of accessing/authenticating to “the site being accessed” (or performing the protected operation on the site). The server processes this request (including initial verification step 302 in related embodiments) before generating the OTP at step 204. This reads on obtaining an operation request from an inbound user device);
generating, by the computer, an OTP for the operation request based upon operation information associated with the operation obtained from the inbound user device (“… a user's identification, such as a username or other "ID," and the user's password for the site being accessed is transmitted at 202, such as from the user's computing device (e.g., user computing device 106 of FIG. 1, for example, the user's PC), and is received by a server associated with the site, (e.g., authentication server 102 of system 100 shown in FIG. 1). At 204, an OTP is generated for the user.” -e.g., see, Fig. 2, col. 4, lines 56-62; see also: “an OTP string is generated at 308 (i.e., in accordance with step 204 above)” -e.g., see, col. 6, lines 21-22; herein, OTP generation occurs in response to the operation request information received from the inbound user device);
generating, by the computer, an OTP prompt having text representing the OTP for display at a user interface of the inbound user device (“At 218, the OTP is displayed, such as on a screen of the user's mobile device, in plain text. The user reads the OTP aloud at 220, such as into a microphone of the user's computing device, whereupon it may be recorded by the user's computing device and transmitted to an authentication server associated with the site being accessed.” -e.g., see, col. 5, lines 17-22; herein, the plain text OPT is displayed on the screen/UI of the user’s mobile device as the visual prompt);
transmitting, by the computer, an OTP request associated with the operation request to the inbound user device, the OTP request including the OTP prompt (“At 210, the encrypted two-dimensional barcode embodying the OTP is transmitted by the site authentication server to the computing device of the user. An image of the two-dimensional barcode displayed, such as on the user's computing device, is captured at 212 using the user's mobile device. In one implementation, for example, this is accomplished by photographing the image of the two-dimensional barcode using a camera of the user's mobile device. At 214, the two-dimensional barcode of the encrypted OTP is decoded, and the resulting encrypted string is decrypted using the user's mobile device at 216. At 218, the OTP is displayed, such as on a screen of the user's mobile device, in plain text.” -e.g., see, col. 5, lines 7-22; herein, the encoded OTP data (enabling the prompt display) is transmitted to the user’s device as part of the authentication flow tied to the original operation request);
generating, by the computer, a speaker recognition score based upon an inbound voiceprint extracted for an inbound audio signal representing a spoken audio response of an OTP response from the inbound user and an enrolled voiceprint associated with an enrolled user (“The operations carried out by the authentication server may also include receiving a transmission that includes the OTP, as spoken by the user, for recognition of the OTP to authenticate the user, and for passing along to SBVS 104 for voice recognition processing to compete authentication of the user. SBVS 104 may be a secure server that could be located away from authentication server 102 as a third party service. In accordance with various implementations of the present systems and methods, SBVS 104 generates, trains, and updates the user's unique set of speech models (the user's voiceprint), stores the speech model securely in a database, and performs the matching process to authenticate a user.” -e.g., see, col. 4, lines 12-23; see also: “This recognition of the user's voice at 224 may employ any number of biometric voice recognition techniques. For example, feature extraction is the processing of the raw speech data resulting in representative voice features, which contain information of the physiological characteristics of the user. In feature extraction, certain attributes of speech needed by the voice biometric system to differentiate people by their voice may be measured. Such techniques may employ mel-frequency cepstral coefficients. The extracted features may be compared with an archived voiceprint of the claimed user, which was created during the registration of the client, and a matching score may be calculated to provide verification. If the matching score is over a predefined threshold value, then the authorization is considered successful; …” -e.g., see, col. 5, lines 23-43; herein, the server/computer receives the inbound audio signal of the spoken OTP response. It performs feature extraction on the raw speech data to create representative voice features (inbound voiceprint). These features are compared/matched against the stored/archived voiceprint of the enrolled/claimed user (enrolled voiceprint). A “matching score” is calculated from the comparison. The resulting matching score serves as the speaker recognition score (success if above threshold)); and
authenticating, by the computer, the operation request based upon the speaker recognition score and a content recognition … (“The encrypted OTP is decrypted using the user's mobile device and displayed. The OTP then is spoken by the user, and the user's voice and the OTP are recognized to authenticate the user.” -Abstract; see also: “… upon decryption of the OTP and its display by the user's mobile device, the user reads the OTP into the microphone of his computer. The server of the site being accessed receives this spoken OTP (one time password). The password is authenticated and voice recognition is used to further authenticate the user to access the site.” -e.g., see, col. 3, lines 13-19; see also: see also: “… receiving the one time password spoken by the user; and recognizing the user's voice and the one time password as spoken by the user to authenticate the user.” -e.g., see, claim 1 of Tolba; herein, Authentication of the operation request requires and is based on both voice recognition and recognition of the spoken OTP content).
Tolba doesn’t explicitly disclose “content recognition score” terminology separate from voice recognition (Tolba recognizes the OTP/content as spoken and states that “the password is authenticated” but does not use separate “content recognition score” phrasing).
However, in an analogous art, Skerpac discloses “content recognition score” via processing of spoken response (“verifying if a set of extracted speech recognition features are representative of the random pass phrase using said speech recognition language and acoustic models;”, “setting a sub-session word match flag on and updating a session word match count if speech verification is positive;” and “setting a minimum number of phrases flag on if the session word match count is equal to or higher than a session word match parameter;” -e.g., see, [0052] – [0054]; herein, Speech recognition processes the inbound audio signal of the spoken OTP response to verify/generate recognized content and produce a content match outcome/score (word match flag/count against the generated OTP text).
Skerpac further discloses content recognition score via processing of spoken audio response (“matching a set of extracted speaker recognition features of said concatenated audio to a registered speaker biometric model of a registered user;” and “setting a biometric match flag on if the previous step is positive; setting a session authentication flag to positive if the minimum number of phrases flag is on and the biometric match flag is on;” -e.g., see, [0057] and [0058] of Skerpac; herein, speaker recognition features from the audio signal and voiceprint are matched to the enrolled/registered model, producing the speaker recognition outcome/score).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Tolba with the additional feature of Skerpac in order to improve the accuracy, quantifiability and spoof resistance of the Tolba’s voice and OTP recognition process for secure real-time authentication of the operation request.
As to claim 11, it is rejected using the similar rationale as for the rejection of claim 1.
As to claim 2, Tolba in view of Skerpac discloses the method according to claim 1, Tolba further discloses comprising determining, by the computer, that the operation request indicates a type of secure operation, wherein the computer generates the OTP in response to determining that the operation request indicates the type of secure operation (“… a user's identification, such as a username or other "ID," and the user's password for the site being accessed is transmitted at 202, such as from the user's computing device (e.g., user computing device 106 of FIG. 1, for example, the user's PC), and is received by a server associated with the site, (e.g., authentication server 102 of system 100 shown in FIG. 1). At 204, an OTP is generated for the user.” -e.g., see, col. 4, lines 54-34; herein, the initial request from the user device is processed as requiring secure OTP generation for the operation).
As to claim 12, it is rejected using the similar rationale as for the rejection of claim 2.
As to claim 5, Tolba in view of Skerpac discloses the method according to claim 1, Tolba discloses further comprising: generating, by the computer, response content text of the OTP response from the inbound user device by applying an automatic speech recognition (ASR) engine on the inbound audio signal; and generating, by the computer, a response content score based upon the text of the OTP and the response content text (“The OTP then is spoken by the user, and the user's voice and the OTP are recognized to authenticate the user.” -e.g., see, Abstract; see also: “Voice recognition processes automatically recognize who is speaking, based on individual information included in speech waves. Voice recognition uses the acoustic features of speech that have been found to differ between individuals. In accordance with various implementations of the present systems and methods, upon decryption of the OTP and its display by the user's mobile device, the user reads the OTP into the microphone of his computer. The server of the site being accessed receives this spoken OTP (one time password). The password is authenticated and voice recognition is used to further authenticate the user to access the site.” -e.g., see, col. 3, lines 4-19; herein, Spoken OTP response is recognized for content match against generated OTP).
As to claim 15, it is rejected using the similar rationale as for the rejection of claim 5.
As to claim 6, Tolba in view of Skerpac discloses the method according to claim 1, Tolba further discloses comprising extracting, by the computer, the inbound voiceprint using a plurality of speaker acoustic features of the inbound audio signal (“Voice recognition processes automatically recognize who is speaking, based on individual information included in speech waves. Voice recognition uses the acoustic features of speech that have been found to differ between individuals. In accordance with various implementations of the present systems and methods, upon decryption of the OTP and its display by the user's mobile device, the user reads the OTP into the microphone of his computer.” -e.g., see, Tolba: col. 3, lines 4-19).
As to claim 16, it is rejected using the similar rationale as for the rejection of claim 6.
As to claim 7, Tolba in view of Skerpac discloses the method according to claim 1, Tolba further discloses comprising: extracting, by the computer, one or more inbound fakeprints using a plurality acoustic features of the inbound audio signal; and generating, by the computer, one or more liveness scores for the operation request using one or more enrolled fakeprints (“Voice recognition processes automatically recognize who is speaking, based on individual information included in speech waves. Voice recognition uses the acoustic features of speech that have been found to differ between individuals. In accordance with various implementations of the present systems and methods, upon decryption of the OTP and its display by the user's mobile device, the user reads the OTP into the microphone of his computer.” -e.g., see, Tolba: col. 3, lines 4-19; herein, acoustic features support live vs. non-line distinction).
As to claim 17, it is rejected using the similar rationale as for the rejection of claim 7.
As to claim 10, Tolba in view of Skerpac discloses the method according to claim 1, Tolba further discloses wherein generating the speaker recognition score includes determining, by the computer, a distance between the inbound voiceprint and the enrolled voiceprint (“In feature extraction, certain attributes of speech needed by the voice biometric system to differentiate people by their voice may be measured. Such techniques may employ mel-frequency cepstral coefficients. The extracted features may be compared with an archived voiceprint of the claimed user, which was created during the registration of the client, and a matching score may be calculated to provide verification. If the matching score is over a predefined threshold value, then the authorization is considered successful; …” -e.g., see, col. 5, lines 23-43; herein, the server/computer receives the inbound audio signal of the spoken OTP response. It performs feature extraction on the raw speech data to create representative voice features (inbound voiceprint). These features are compared/matched against the stored/archived voiceprint of the enrolled/claimed user (enrolled voiceprint). A “matching score” is calculated from the comparison. The resulting matching score serves as the speaker recognition score (success if above threshold)).
As to claim 20, it is rejected using the similar rationale as for the rejection of claim 10.
Claims 3 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Tolba in view of Skerpac as applied to claims 1 and 11 above, and further in view of Badhwar et al. (US 2021/0194883 A1) (hereinafter, “Badhwar”).
As to claim 3, Tolba in view of Skerpac discloses the method according to claim 1, Tolba in view of Skerpac does not explicitly discloses further comprising determining, by the computer, an operation request risk score for the operation request, wherein the computer generates the OTP in response to determining that the operation request risk score satisfies a request risk threshold.
However, in an analogous art, Badhwar discloses comprising determining, by the computer, an operation request risk score for the operation request, wherein the computer generates the OTP in response to determining that the operation request risk score satisfies a request risk threshold (“… computing a user risk score based on one or more of current user identity risk, historical user identity risk, web browser risk, user device risk, user behavior risk, and user network risk.” -e.g. see, [0007]; see also: “… if a cumulative risk score of the user action is lower than a threshold risk score, the system determines that a weaker step-up authentication method (e.g., a singular step-up dynamic authentication method such as one time password (OTP) or Captcha) is sufficient to re-authenticate and authorize the user to perform the current action. The server system provides the selected step-up authentication method to the user device. The step-up authentication method initiates one or more security requests to the user. The one or more security requests initiated by the selected step-up authentication method may include one or more of (i) sending a one-time password (OTP) to the user via a short message service (SMS) or email and asking the user to provide the OTP, (ii) asking the user to provide a biometric based authentication, (iii) invoking identity proofing, …” -e.g., see, [0058]; herein, OTP generation/sending is triggered when the computed risk score/profile satisfies the risk threshold requiring additional/step-up authentication).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Tolba and Skerpac with the additional feature of Badhwar in order to provide adaptive, risk-aware efficiency and better security against low-risk unnecessary challenges while maintaining robust protection for high-risk operations.
As to claim 13, it is rejected using the similar rationale as for the rejection of claim 3.
Claims 4, 9, 14 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Tolba in view of Skerpac as applied to claims 1 and 11 above, and further in view of Agarwal et al. (US 2023/0370290 A1) (hereinafter, “Agarwal”).
As to claim 4, Tolba in view of Skerpac discloses the method according to claim 1, Tolba in view of Skerpac does not explicitly disclose wherein the computer generates the OTP according to at least a portion of the operation information received from an agent device.
However, in an analogous art, Agarwal discloses wherein the computer generates the OTP according to at least a portion of the operation information received from an agent device (“Upon communication initiation between customer 106 and agent 102, a digital identification of customer 106 may be initiated. The digital identification may involve registering the VR device associated with customer 106. The digital identification may also involve generating and authenticating the registered device and/or the mobile device using an OTP. As such, the digital identification may perform identity-based authentication—i.e., authentication of the individual using the mobile device and/or VR device associated with customer 106 and authentication of permissions associated with the individual using the VR device associated with agent 102.” -e.g., see, Agarwal: [0049]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Tolba and Skerpac with the additional feature of Agarwal in order to protect non-public information from viewing by certain users during a co-browsing session.
As to claim 14, it is rejected using the similar rationale as for the rejection of claim 4.
As to claim 9, Tolba in view of Skerpac discloses the method according to claim 1, Tolba in view of Skerpac doesn’t explicitly disclose further comprising transmitting, by the computer, an authentication result based upon authenticating the operation request to an agent device.
However, in an analogous art, Agarwal discloses comprising transmitting, by the computer, an authentication result based upon authenticating the operation request to an agent device (“The VR platform may transmit a one-time password (OTP) from the VR platform to a second device associated with the customer. In some embodiments, the second device may be the mobile device. The OTP may be received as a push notification, short message service (SMS), email or any other suitable transmission method. The OTP may be entered by the customer at the mobile device. In some embodiments, the OTP may be entered into the mobile application running on the mobile device. The VR platform may validate the OTP.” -e.g., se, Agarwal: [0036]; see also: Agarwal: [0049]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Tolba and Skerpac with the additional feature of Agarwal in order to protect non-public information from viewing by certain users during a co-browsing session.
As to claim 19, it is rejected using the similar rationale as for the rejection of claim 9.
Claims 8 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Tolba in view of Skerpac as applied to claims 1 and 11 above, and further in view of Naqvi et al. (US 2022/0343095 A1) (hereinafter, “Naqvi”).
As to claim 8, Tolba in view of Skerpac discloses the method according to claim 1, Tolba in view of Skerpac doesn’t explicitly disclose comprising: extracting, by the computer, one or more fakeprints using metadata obtained in the OTP response from the inbound user device; and generating, by the computer, one or more liveness scores for the operation request using one or more enrolled fakeprints.
However, in an analogous art, Naqvi discloses extracting, by the computer, one or more fakeprints using metadata obtained in the OTP response from the inbound user device; and generating, by the computer, one or more liveness scores for the operation request using one or more enrolled fakeprints (“… the unauthorized device 109 may have also provided a spoofed device fingerprint, and the computing device 101 may determine whether to authenticate the unauthorized device 109 based on that spoofed device fingerprint. In some circumstances, if the spoofed device fingerprint is an exact match for a previous device fingerprint received from the user device 107, the authentication may be rejected. For example, the user device 107 is configured to send a different device fingerprint with every transmission, if the computing device 101 receives the same device fingerprint twice, the computing device 101 may detect that a potential replay attack may be occurring. As another example, if the spoofed device fingerprint is significantly different than previously-received device fingerprints, authentication may be rejected.” -e.g., see, Naqvi: [0067]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention was to modify the teaching of Tolba and Skerpac with the additional feature of Naqvi in order to prevent potential replay attack.
As to claim 18, it is rejected using the similar rationale as for the rejection of claim 8
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SUMAN DEBNATH whose telephone number is (571)270-1256. The examiner can normally be reached Mon-Fri; 9:00am-5:00pm.
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, Farid Homayounmehr can be reached at 571-272-3739. 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.
SUMAN DEBNATH
Patent Examiner
Art Unit 2495
/S.D/Examiner, Art Unit 2495
/FARID HOMAYOUNMEHR/Supervisory Patent Examiner, Art Unit 2495
Prosecution Insights