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 the application 18/779,413 filed on 07/22/2024.
Claim 1 has been examined and is pending in this application.
Priority
This application is a continuation of U.S. application No. 17/464,669, filed on September 1st, 2021 (Now U.S. patent No. 12,047,371), which claims benefit of U.S. Provisional Application No. 63/077,010, filed September 10, 2020.
Claim Objections
Claim 1 is objected to because of the following informalities:
Regarding claim 1; claim 1 recite the limitation “receiving, at the authentication server from the web application, a data object associated with the session between the computing devince and the web application ………”. It should read as “receiving, at the authentication server from the web application, a data object associated with the session between the computing device and the web application …”
Appropriate correction(s) is required.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
“The USPTO internet Web site contains terminal disclaimer forms which may be used. Please visit http://www.uspto.gov/forms/. The filing date of the application will determine what form should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to http://www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp. “
Claim 1 is rejected on the ground of non-statutory obviousness-type double patenting as being unpatentable over claim 1 of U.S. Patent Application 17/464,669 (Now U.S. patent No. 12,047,371). Although the claims at issue are not identical, they are not patentably distinct from each other because pending application has all the limitations of U.S. patent No. 12,047,371. The examiner underlined the difference in claim language.
Current Application No. 18/779,413
U.S. Patent Application 17/464,669 (Now U.S. patent No. 12,047,371)
Claim 1, A method comprising:
registering, at an authentication server, a session between a browser executing on a computing device and a web application executing on an application server using a quick response (QR) code generated by the web application, the QR code being sent to the computing device for display in response to a user requesting to access the web application via the browser;
receiving, at the authentication server from the web application, a data object associated with the session between the computing devince and the web application;
receiving, at the authentication server from a mobile device of the user, the QR code as captured by the user using camera of the mobile device;
identifying, using the QR code, the data object and sending the data object to the mobile device, the data object is configured to retrieve user credentials for accessing the web application; and receiving, at the authentication server from the mobile device, an encrypted message comprising the user credentials and forwarding the encrypted message to the computing device for communication to the web application, wherein the web application is configured to authenticate the user credentials and provide the computing device access to the web application.
Claim 1. A method comprising:
registering, at an authentication server, a session between a browser executing on a computing device and a web application executing on an application server using a quick response (QR) code generated by the web application, the QR code being sent to the computing device for display in response to a user requesting to access the web application via the browser;
receiving, at the authentication server from the web application, a data object associated with the session between the computing device and the web application;
receiving, at the authentication server from a mobile device of the user, the QR code as captured by the user using camera of the mobile device;
identifying, using the QR code, the data object and sending the data object to the mobile device, the data object is configured to retrieve user credentials for accessing the web application; and receiving, at the authentication server from the mobile device, and encrypted message comprising the user credentials and forwarding the encrypted message to the computing device for communication to the web application, wherein the web application is configured to authenticate the user credentials and provide the computing device access to the web application;
wherein the web application decrypts the encrypted message to authenticate the user credentials and wherein the authentication server does not decrypt the encrypted message.
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 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 of this title, 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.
Claim1 is rejected under 35 U.S.C. 103 as being unpatentable over Ramesh (US 2019/0386981) and in view of Gadotti (US 2014/0317713).
Regarding claim 1, Ramesh discloses a method, comprising:
registering, at an authentication server, a session between a browser executing on a computing device and a web application executing on an application server using a quick response (QR) code generated by the web application (Ramesh par. 0028 and 0049; for example, generating and sending a QR code to a Web browser or other application running on the user's primary device. The AM server 132 sends the authentication token along with a URL of the server to the browser 112. The authentication token and the URL can be embedded in a QR code in order to facilitate communication of the authentication token and the URL to the authentication device 120. Data in the QR code may be encrypted. For example, the URL may be encrypted using percent encoding. The authentication token can be embedded in a registration link generated by combining the authentication token plus an authentication policy, plus the server URL, in which case the QR code may include the registration link. For the purposes of the present discussion, a registration link may be any set of data that specifies a URL or Uniform Resource Identifier (URI) that can be opened (e.g., via a Web browser) to access one or more computing resources for enabling registration or enrollment of a primary device and an associated authentication device. See also par. 0062 and 0068);
receiving, at the authentication server from the web application, a data object associated with the session between the computing device and the web application (Ramesh par. 0054 and 0066; The AM server 132 receives the enrollment request and validates the authentication token. Validation of the authentication token can include checking whether the authentication token has been signed using the AM server's 132 private key, in order to confirm that the token has not been tampered with. The AM server 132 may also check whether the user ID and the device ID in the authentication token match a user ID and device ID stored earlier by the AM server 132, e.g., a user ID generated for the user prior to the access request in step 210 of FIG. 2A and a device ID generated during creation of the authentication token in step 216. the AM server receives an access request from a user's primary device (e.g., an access request sent from the browser 112). In response, the AM server sends a request to the primary device for one or more credentials (or some other primary authentication factor. See also par. 0049);
receiving, at the authentication server from a mobile device of the user, the QR code as captured by the user using camera of the mobile device (Ramesh par. 0028 and 0075; The QR code can be displayed on the user's primary device and may include an authentication token (e.g., a JavaScript Object Notation (JSON) Web Token (JWT)). The QR code may further include a resource link (e.g., a URL) that directs to the AM server. The user scans a QR code using an image capture device to send an authentication token and a server URL contained in the QR code to the authentication device. See also par. 0043 and 0085); and
receiving, at the authentication server from the mobile device, an encrypted message comprising the user credentials and forwarding the encrypted message to the computing device for communication to the web application, wherein the web application is configured to authenticate the user credentials and provide the computing device access to the web application (Ramesh par. 0072, 0073 and claim 5; The AM server generates and sends a shared secret to the authentication device. The shared secret may be sent encrypted and can be, for example, a random number or string. The AM server receives a TOTP from the authentication device, generates its own TOTP using the shared secret and a current timestamp, then compares the two TOTPs to each other. If the TOTP received from the authentication device was generated using the same shared secret and the authentication device is time-synchronized with the AM server, then the two TOTPs will match. After the enrolling of the authentication device, receiving a first TOTP from the authentication device in connection with a subsequent authentication request for the user, the first TOTP being generated by the authentication device using the shared secret; generating a second TOTP using the shared secret; comparing the first TOTP to the second TOTP; and responsive to determining that the first TOTP matches the second TOTP, granting access to a protected resource. See also par. 0069-0071 and 0074).
Ramesh3KhanKhanKkk teaches3 registering, using a quick response (QR) code generated by the web application, the QR code being sent to the computing device for display in response to a user requesting to access the web application via the browse and identifying, using the QR code (Ramesh par. 0028, 0041 and 0049). However, Ramesh does not explicitly teach wherein the QR code being sent to the computing device for display in response to a user requesting to access the web application via the browse and identifying, using the QR code, the data object and sending the data object to the mobile device, the data object is configured to retrieve user credentials for accessing the web application.
However, in an analogous field, Gadotti teaches wherein the QR code being sent to the computing device for display in response to a user requesting to access the web application via the browse (Gadotti abstract and par. 0027; A central processing server generates an encoded data, such as a QR code, from encoding a session number, which can be randomly generated; a first client computing device displays a login page that includes the QR code to a user for authentication);
identifying, using the QR code, the data object (extracted session number) and sending the data object to the mobile device, the data object is configured to retrieve user credentials for accessing the web application (Gadotti par. 0037-0039; The second mobile communication device, running the secure mobile transaction mobile application, decodes the image-captured encoded data and extracts the session number. The second mobile communication device sends the extracted session number along with the identification data of the second mobile communication device to the central processing server. The central processing server receives the session number and the identification data of the second mobile communication device; and validates the session number by matching the previously preserved record of the session number in its database).
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the teaching of Ramesh as taught by Gadotti in order to user authentication (Gadotti abstract).7
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANCHIT K SARKER whose telephone number is (571)270-7907. The examiner can normally be reached M-F 8:30 AM-5:30 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, 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.
/SANCHIT K SARKER/Primary Examiner, Art Unit 2495