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 Continuation filed on 10/01/2025.
In the instant Amendment, claim 1, has been amended; and claims 1, 11 and 20 are independent claims. Claims 1-4, 7-14, and 17-20 have been examined and are pending.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 10/01/2025 has been entered.
Response to Amendment
Applicants’ arguments with respect to claims, 1, 11, and 20 have been considered but are moot in view of the new ground(s) of rejection, which were necessitated by amendment.
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.
Claims 1-2, 7, 9, 11-12, 15-17, and 19- 20 are rejected under 35 U.S.C. 103 as being unpatentable over Bakshi et al. (U.S. Pub. 20210211876 A1; Hereinafter "Bakshi") in view of Byskal et al. (US Pub. 20160277483 A1; Hereinafter " Byskal"); Pisut et al. (US Pub. 20180101850 A1; Hereinafter " Pisut"), Venkataramani et al. (US Pat. 10462113 B1; Hereinafter " Venkataramani") and Liu et al. (U.S. 20200014538 A1; Hereinafter "Liu").
As per claims 1, 11 and 20, Bakshi teaches a method for secure transaction authentication via a web browser application (Web browser 162) executing at a client device (device 160), the method comprising (Bakshi: fig. 1B, para[39], “the mobile number can be used as an authentication factor to secure an online transaction in place of sending an OTP via a text message”, para[41], “user mobile device 160 has installed therein a web browser 162.…Web browser 162 is a software that allows the user of user mobile device 160 to access network 150”):
accessing, using the web browser application, web content from an online service by transmitting a request to the online service, and receiving data defining the requested web content (Bakshi: para[41-42], “the user uses web browser 162 to interact with vendor software 142”; para [18], “Vendor application server 140 is a server that hosts an online service for a vendor such as a bank or an electronic commerce (e-commerce) business. Vendor application server 140 provides the online service via a vendor software 142”),
initialize the web browser application to receive verification push notifications from an authentication system (Bakshi: para[37], “the user may enroll user mobile device 110 as a trusted device with multiple vendors… To enroll user mobile device 110 as a trusted device for multiple applications, each authentication SDK generates a push notification token that is mapped to the application that the authentication SDK is embedded in. Additionally, if authentication entries 132 include cryptographic keys, each authentication SDK instructs OS 116 to generate a cryptographic key (or pair of cryptographic keys).”),
receiving a verification push notification, by the browser application executing at the client device and from the authentication system, the verification push notification including an authentication request having a user interface element identifying a requested transaction and prompting a user to input a selected response (Bakshi: para[36] “An interactive push notification provides the user an opportunity to respond to the push notification. For example, a user may respond “yes” or “no” to an interactive push notification that asks whether or not the user attempted to log in to his or her bank account.”).
Bakshi does not explicitly teach wherein the web client code is configured to generate cryptographic keys for secure authentication and to manage encrypted storage of authentication factor information for verification push notifications; the received web content having embedded therein web client code from a software development kit (SDK); executing, by the web browser application, the web client code from the SDK to initialize the web browser application on the client device to receive verification push notifications from an authentication system; receiving, by the web browser application and from the authentication system, factor information comprising secretive data that the authentication system will request during authentication of a requested transaction; encrypting the factor information using the primary encryption key and storing the encrypted factor information in a local storage of the client device; receiving an input identifying a selected response to the requested transaction, accessing a primary encryption key from a secure key store based on the authentication request; decrypting encrypted factor information maintained by a local storage of the client device using the primary encryption key, yielding decrypted factor information, the decrypted factor information identifying a private key; generating a response message based on the private key, the decrypted factor information, and the selected response to the requested transaction; and transmitting the response message to the authentication system.
However, in the related art, Byskal teaches the received web content having embedded therein web client code from a software development kit (SDK) (Byskal: claim 1, col. 12-13, line 59-67, “wherein one or more of the plurality of content item instances is configurable to have multiple simultaneously assigned user sessions, wherein the content item is created using a software development kit associated with a service that hosts the content item, wherein information regarding quantities of unoccupied user sessions is reported by each of the plurality of content item instances, and wherein the software development kit provides code embedded into the content item that reports the information regarding the quantities of unoccupied user sessions;”)
executing, by the web browser application, the web client code from the SDK embedded in the received web content to initialize the web browser application to receive verification push notifications from an authentication system (Byskal: col. 9 line 1-18, “Likewise, processing functions 303A-D may then detect and/or may be informed of telemetry information that has been routed thereto, and may then automatically initiate execution of code for processing the received information, such as by organizing and storing the received information and generating any appropriate alarms or notifications.” See also col. 18, line 9-26).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have modify Bakshi’s browser based verification push notification framework with Byskal’s teaching of SDK code embedded in web content and executed by a client application, it will provide secure browser based authentication (Byskal: para[110]).
Bakshi in view of Byskal does not explicitly teach wherein the web client code is configured to generate cartographic keys for secure authentication and to manage encrypted storage of authentication factor information for verification push notifications; wherein initializing the web browser application to receive verification push notifications from the authentication service comprises generating a primary encryption key unique to a combination of an instance of the web browser application and the online service; receiving, by the web browser application and from the authentication system, factor information comprising secretive data that the authentication system will request during authentication of a requested transaction; encrypting the factor information using the primary encryption key and storing the encrypted factor information in a local storage of the client device; receiving an input identifying a selected response to the requested transaction, accessing a primary encryption key from a secure key store based on the authentication request; decrypting encrypted factor information maintained by a local storage of the client device using the primary encryption key, yielding decrypted factor information, the decrypted factor information identifying a private key; generating a response message based on the private key, the decrypted factor information, and the selected response to the requested transaction; and transmitting the response message to the authentication system.
However, in the related art, Pisut teaches wherein the web client code is configured to generate cryptographic keys for secure authentication and to manage encrypted storage of authentication factor information for verification push notifications (Pisut: fig. 1, 2A-B, para[25-29], “The device may include various applications, including a browser application 205 that allows the user to access websites on the Internet. The browser application can include WebAuthN capabilities, including a WebAuthN API 210 as a method for device personalization/identification and verification (ID&V) 215….The WebAuthN API 210 may generate a WebAuthN asymmetric keypair 230 (e.g., private key 240 and public key 252). The private key may be stored in a secure cryptoprocessor, including a trusted platform module (TPM) 245… When the WebAuthN keypair is generated, a key/device attestation 235 process is implemented. Specifically, for the device attestation the public key 252 is transmitted over the network 115 to the authentication service for storage…..The device may be authenticated when the device transmits a digital signature using the private key, which can only be decrypted by the public key” The examiner would like to note that the “wherein the web client..” clause describe the intended functionality of the web client code rather than imposing a specific structural or operational limitation, as such it is non-limiting and does not further limit the scope of the claim);
wherein initializing the web browser application to receive verification push notifications from the authentication service comprises generating a primary encryption key unique to a combination of an instance of the web browser application and the online service (Pisut: para[30-35], “ The initiation of the transaction may include the user's intent to pay for the goods or services. Subsequently, the host may transmit a request for an application cryptogram (AC), which is generated by the computing device 415. The AC may, for example, provide details about the transaction. Typically, in chip and PIN transactions implemented over the EMVCo standards, the AC may indicate whether to execute the transaction online (direct communication with card issuer) and if the transaction was declined or approved, among other things….The device may transmit the generated AC with user authentication 420 data to the authentication service 120, so that the service can properly authenticate the device. At this stage, the WebAuthN protocol encrypts a digital signature with the previously generated private key, which was developed during the personalization process (FIGS. 2A-B). The encrypted digital signature may be transmitted to the service to authenticate the computing device.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update the modify Bakshi’s with Pisut’s teaching of browser executed cryptographic registration and secure credential storage, it will improve protection of sensitive authentication data stored at the client device (Pisut: para[05]).
Bakshi in view of Byskal and Pisut does not explicitly teach receiving, by the web browser application and from the authentication system, factor information comprising secretive data that the authentication system will request during authentication of a requested transaction; encrypting the factor information using the primary encryption key and storing the encrypted factor information in a local storage of the client device; receiving an input identifying a selected response to the requested transaction, accessing a primary encryption key from a secure key store based on the authentication request; decrypting encrypted factor information maintained by a local storage of the client device using the primary encryption key, yielding decrypted factor information, the decrypted factor information identifying a private key; generating a response message based on the private key, the decrypted factor information, and the selected response to the requested transaction; and transmitting the response message to the authentication system.
However, in the related art, Venkataramani teaches receiving, by the web browser application and from the authentication system, factor information comprising secretive data that the authentication system will request during authentication of a requested transaction; encrypting the factor information using the primary encryption key and storing the encrypted factor information in a local storage of the client device (Venkataramani: col. 7, line 1-15, “the term “core message” generally refers to a message that the security service relying party originally intends to transmit to the end user and then encrypts based on an answer to a challenge-response question according to knowledge based authentication, as discussed below….the core message may be encrypted according to nested encryption in which the core message is first encrypted based on the answer to the challenge-response question, and then further encrypted, along with one or more items of data included within the payload of the push authentication, using the public key of the client device.”); accessing the primary encryption key from a local secure key store based on the authentication request; decrypting encrypted factor information maintained by a local storage of the client device using the primary encryption key yielding decrypted factor information, the decrypted factor information identifying a private key (Venkataramani: col. 10, line 26-40 “After fetching the public key of the security service relying party at step 424, the client device of the user may, at step 426, decrypt a payload of the push authentication. As discussed further above, the payload of the push authentication may include core message 126, which was previously encrypted based on the correct answer to the challenge-response question, the challenge-response question, the nonce value dynamically generated to prevent security attacks based on transaction repetition, and/or a copy or network address of the public key of the security service relying party. Accordingly, at steps 424-426, the client device of the user may display, or output, the challenge-response question in an attempt to obtain the correct answer from the user, which may be used to decrypt the core message at step 430”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update the modified Bakshi with the process discussed in Venkataramani, it will enable third-party strong authentication security service, as a middleman, to access content of push authentications (Venkataramani: col. 3 line 48-52).
Bakshi in view of Byskal, Pisut and Venkataramani does not explicitly teach generating a response message based on the private key, the decrypted factor information, and the selected response to the requested transaction.”); and transmitting the response message to the authentication system to authenticate the requested transaction.
However, in the related art, Liu teaches generating a response message based on the private key, the decrypted factor information, and the selected response to the requested transaction (Liu: [76, ], “A user 112, such as the one or more relevant parties, may access system 100 through a web based software application or browser.”, [83], “the processor may be configured for generating a digital signature corresponding to a service based on a unique identifier associated with the service and the primary cryptographic identifier. In some embodiments, generating the digital signature may include digitally signing the unique identifier using the primary private key.” The unique identifier is an authentication information that is associated with the service, see also para[58], ); and
transmitting the response message to the authentication system to authenticate the requested transaction (Liu: para[85] “the processor may be configured for transmitting, using the communication device, the digital signature corresponding to the service.” Para[89], “the processor may be configured to authenticate the user access to the service based on the result of the session signature validation.”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update the modified Bakshi with the digital signature process as discussed in Liu, it will improve privacy protection for online users (Liu; para[69]).
Furthermore, Bakshi also teaches the hardware components of claims 11 and 20 such as one or more computer processors (para[20], [75] “user mobile device 110 includes hardware resources 120. Hardware resources 120 comprise a processor 122, memory 124, and secure element 126”); and
one or more computer-readable mediums storing instructions that, when executed by the one or more computer processors; a non-transitory computer-readable medium storing instructions that, when executed by one or more computer processors of a client device (Bakshi: para[76], “One or more embodiments of the present invention may be implemented as one or more computer programs or as one or more computer program modules embodied in computer readable media.”).
As per claims 2 and 12, Bakshi in view of Byskal, Venkataramani and Liu teaches the independent claim 1. Liu teaches wherein generating the response message comprises: generating a digital signature using the private key based on at least a portion of the decrypted factor information (Liu: [76, ], “A user 112, such as the one or more relevant parties, may access system 100 through a web based software application or browser.”, [83], “the processor may be configured for generating a digital signature corresponding to a service based on a unique identifier associated with the service and the primary cryptographic identifier. In some embodiments, generating the digital signature may include digitally signing the unique identifier using the primary private key.” The unique identifier is an authentication information that is associated with the service, see also para[58], ).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update the modified Bakshi with the digital signature process as discussed in Liu, it will improve privacy protection for online users (Liu; para[69]).
As per claims 7 and 17, Bakshi in view of Byskal, Pisut, Venkataramani and Liu teaches the independent claim 1. Bakshi teaches wherein initializing the web browser application to receive verification push notification from the authentication service further comprises: generating a key pair including a public key and the private key (Bakshi: para[31], “In addition to a push notification token, when the user decides to enroll user mobile device 110 as a trusted device, authentication SDK 114 may also instruct OS 116 to generate a cryptographic key (or a pair of cryptographic keys). For example, OS 116 may generate a key pair, consisting of a public key and a private key.’); and
providing the public key to the authentication system (Bakshi: para[31], “OS 116 stores the private key in secure element 126 and returns the public key to authentication SDK 114.”).
As per claims 9 and 19, Bakshi in view of Byskal, Pisut, Venkataramani and Liu teaches the independent claim 1. Bakshi teaches accessing, using the web browser application second web content from a second online service, the second web content being embedded with the web client code of the SDK for initializing client-side applications to receive verification push notifications (Bakshi: para[37-38], “A user may install multiple applications on user mobile device 110, each application being embedded with an authentication SDK.”); and
in response to receiving, via the second web content, an input to initialize the client-side application to receive verification push notifications from the second online service, initiating a subsequent initialization process comprising ): generating a second primary encryption key that is unique to a combination of the client- side application installed on the client device and the second online service (Bakshi: para[37-38], “the user may enroll user mobile device 110 as a trusted device with multiple vendors. Authentication server 130 may then include a separate authentication entry 132 for multiple vendor application servers, each authentication entry 132 being tied to the same network ID. To enroll user mobile device 110 as a trusted device for multiple applications, each authentication SDK generates a push notification token that is mapped to the application that the authentication SDK is embedded in”).
Claims 3-4, 8, 10, 13-14, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Bakshi et al. (U.S. PUB 20210211876 A1; Hereinafter "Bakshi") in view of Byskal et al. (US Pub. 20160277483 A1; Hereinafter " Byskal"); Pisut et al. (US Pub. 20180101850 A1; Hereinafter " Pisut"); Venkataramani et al. (US Pat. 10462113 B1; Hereinafter " Venkataramani") and Liu et al. (U.S. 20200014538 A1; Hereinafter "Liu"), and Ross et al. (U.S. 2019/0334884 A; Hereinafter "Ross").
As per claims 3 and 13, Bakshi in view of Byskal, Pisut, Venkataramani and Liu teaches the dependent claim 2. Ross teaches wherein the digital signature is further generated based on transaction data describing the requested transaction (Ross: para[0221], “At step 2324, the respective response message may also include information indicating successful validation of the respective received user credential 2102 such as, for example, the message being digitally signed with the respective private key portion of the respective authentication token. The message indicating successful validation of the user credential may also include information indicating that the mobile device user 1408 rejected access to the remote service if, for example, a thief or a hacker attempted to initiate a remote credit card purchasing service or a remote third-party voice appliance purchasing service, as described above”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update the modified Bakshi with the authentication process discussed in Ross, it will provide enhanced security to a user's account access over Internet services (Ross; para[54]).
As per claims 4 and 14, Bakshi in view of Byskal, Pisut, Venkataramani and Liu teaches the independent claim 1. Ross teaches wherein the secure key store is IndexedDB (Ross: para[0059-0061], “In various embodiments, IDP service core 350-N includes a persistent storage unit 358 (e.g. NoSQL, MySQL cluster, database)…. IDP service core 350-N of the single IDP includes suitable database software running in conjunction with IDP software of the single IDP, such as, for example with identity repository 140. In various embodiments, identity repository 140 is an identity store and stores registration information of single IDP registered Internet users and/or single IDP registered Internet user devices such as, for example, Internet user names, electronic mail addresses, public key portions of dID app created authentication tokens, anonymous identifiers, device identifiers of one or more Internet user devices, etc”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update the modified Bakshi with the authentication process discussed in Ross, it will provide enhanced security to a user's account access over Internet services (Ross; para[54]).
As per claims 8 and 18, Bakshi in view of Byskal, Pisut, Venkataramani and Liu teaches the dependent claim 7. Ross teaches receiving factor information from the authentication system (Ross: para[0104-0105], “dID app 850 may receive a new pseudorandom string at a predetermined periodicity (e.g. after a predetermined number of authentications, after the expiration of a predetermined period of time, after the expiration of a predetermined amount of time from the last authentication) and via an API call from IDP service core 150 of the single IDP.”); and
encrypting the factor information and data identifying the private key using the primary encryption key, yielding the encrypted factor information (Ross: para[0104-0105], “cryptographic component 820 of dID app 850 can generate a new cryptographically secure encryption key, for example, using each received new pseudorandom string and the user credential of the Internet user, encrypt the private key portion of the generated authentication token using the generated new encryption key, and store the newly encrypted private key in memory 840 on device (804, 104, 106)”).
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update the modified Bakshi with the authentication process discussed in Ross, it will provide enhanced security to a user's account access over Internet services (Ross; para[54]).
As per claim 10, Bakshi in view of Byskal, Pisut, Venkataramani and Liu teaches the independent claim 1. Ross teaches accessing, using a second client-side application, the web content from the online service (Ross: para[0088-0094], “Referring now to FIG. 6D, an illustrative screenshot of an example of an Internet user interface to an application other than the dID app 850 residing on a device (e.g. 804, 104, 106, 102) according to some embodiments is provided.”); and
in response to receiving, via the web content, an input to initialize the second client-side application to receive verification push notifications from the online service, initiating a subsequent initialization process comprising: generating a second primary encryption key that is unique to a combination of the second client-side application installed on the client device and the online service (Ross: para[0092-0094] “In the illustrated embodiments of FIG. 6E, the respective web browser of the respective Internet user device is directed to a web page of the website of the single identity provider (150, 250) in response to receiving a signal from the another application residing on the device indicative of an Internet user's selection of the active link displayed on a page by the another application. (e.g. FIG. 6D). In various embodiments, as shown in FIG. 6E, the single IDP service core (150-N, 250-N) may generate the web page displayed at the respective web browser to display a notification to the Internet user that the dID app 850 created authentication token is activated.”). The same motivation applies in claim 9, applies in claim 10.
Therefore, it would have been obvious to a person having ordinary skill in the art, before the effective filling date of the claimed invention, to have update the modified Bakshi with the authentication process discussed in Ross, it will provide enhanced security to a user's account access over Internet services (Ross; para[54]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LYDIA L NOEL whose telephone number is (571)272-1628. The examiner can normally be reached Monday - Friday 9:00 - 5:00.
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, Alexander Lagor can be reached on (571)-270-5143. 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.
/L.L.N./Examiner, Art Unit 2437
/MENG LI/Primary Examiner, Art Unit 2437