The 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
Claims 1 – 20 are pending.
This action is in response to the communication filed on 12/04/24.
Drawings
The drawings are objected to under 37 CFR 1.83(a). The drawings must show every feature of the invention specified in the claims. Therefore, the features listed below must be shown or the feature(s) canceled from the claim(s). No new matter should be entered.
The drawings fail to illustrate:
“…the authentication server generating and storing a cryptographic key pair, a public key of the cryptographic key pair stored in a storage of the authentication server that is associated with the user identifier …
… and the authentication server sending a private key of the cryptographic key pair to the client device …;
upon receipt of the private key at the client device, the browser saving the private key in a second storage accessible by the client device …” (e.g. claim 1, and similarly recited claim 8, 15).
The examiner notes that the applicant’s drawings (e.g. see Figure 8) actually illustrate the opposite functionality. Specifically, the applicant’s drawings illustrate that the client device generates the key pair (e.g. Fig. 8:808), wherein the client device sends the public key of the key pair to the authentication server (e.g. Fig. 8:809), wherein the authentication server saves the public key of the client device (e.g. Fig. 8:810).
The drawings fail to illustrate:
“… a countdown field displayed by the browser …”.
The examiner notes that the applicant’s drawings and specification disclose a “time counter” 545 (e.g. Fig. 5; par. 43), but does not additionally disclose the distinctly recited “countdown field”.
Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Specification
The specification is objected to as failing to provide proper antecedent basis for the claimed subject matter. See 37 CFR 1.75(d)(1) and MPEP § 608.01(o). Correction of the following is required:
The applicant’s specification fails to disclose the following subject matter:
“…the authentication server generating and storing a cryptographic key pair, a public key of the cryptographic key pair stored in a storage of the authentication server that is associated with the user identifier …
… and the authentication server sending a private key of the cryptographic key pair to the client device …;
upon receipt of the private key at the client device, the browser saving the private key in a second storage accessible by the client device …” (e.g. claim 1, and similarly recited claim 8, 15).
Specifically, the examiner notes that the applicant’s specification fails to teach that the “authentication server” generates a cryptographic key pair, wherein the public key of the pair is associated with the user identifier and the private key of the pair is sent by the authentication server to the client device. Rather, the applicant clearly and explicitly teaches that it is the user’s client device which generates the key pair, wherein the client device securely stores the private key that itself generated, and sends the public key to the authentication server, wherein the authentication server stores the public key (generated by the client device) along with the user’s identity information (e.g. Specification, par. 60, 61, 75).
Furthermore, while the applicant does disclose that the authentication server may generate a pair of elliptic curve keys (i.e. ECDSA), the applicant teaches that these separate and distinct set of keys are for communication between the authentication server and a “push notification server”. Additionally, the public key from this second set of generated keys, is not stored on the authentication server, but it is sent to and stored on the push notification server (e.g. Specification, par. 70).
Furthermore, the applicant’s specification fails to disclose the following subject matter of claim 17:
“…wherein the second visual representation comprises one image selected from one thousand stored images …”.
Specifically, the applicant fails to disclose any selection process involving one thousand stored images.
Furthermore, the applicant’s specification fails to disclose the following subject matter of claim 18:
“… a countdown field displayed by the browser …”.
The examiner notes that the applicant’s drawings and specification disclose a “time counter” 545 (e.g. Fig. 5; par. 43), but does not additionally disclose the distinctly recited “countdown field”.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1 – 20 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claims 1 – 20, please refer to the above objection to the specification for an explanation as to the claimed subject matter which was not described within the specification.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 17 and 18 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding, claim 17, the recitation “…wherein the second visual representation comprises one image selected from one thousand stored images …” renders the scope of the claims indefinite. Specifically, the examiner notes that while claims are to be interpreted in light of applicant’s specification, the applicant’s specification is entirely silent as to the storage of 1000 images, where such storage exists, how such storage is derived, what algorithm or process is used for selecting an image from storage, and who or what performs the selection. This claimed notion does not appear to be a standardized feature within the art, and thus it is unclear to one of ordinary skill as to exactly how this recitation is practically related to the remaining claims and disclosure.
Furthermore, the applicant’s specification fails to disclose the following subject matter of claim 17:
“…wherein the second visual representation comprises one image selected from one thousand stored images …”.
Specifically, the applicant fails to disclose any selection process involving one thousand stored images.
Regarding, claim 18, the recitation “… a countdown field …” renders the scope of the claims indefinite. Specifically, the examiner notes that the term “countdown field” does not comprise a standardized meaning within the art, and the applicant fails to disclose a meaning within the applicant’s written description. Furthermore, the applicant teaches, and separately and distinctly claims, a “time counter”, wherein it is not clear if the applicant intends for the undisclosed “countdown field” to be equivalent to the disclosed “time counter”. Thus, the scope of the claims are unclear.
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 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Khalil et al. (Khalil), US 2015/0249540 A1, in view of Royyuru, US 2017/0085563 A1.
Regarding claim 1, Khalil discloses:
A computer implemented method for full-duplex authentication of a user of a third-party server without requiring a password from the user, the computer implemented method comprising (e.g. Abstract):
an authentication server sending a deep-link to a client device (e.g. Khalil, par. 37, 67, 68 – herein the authentication server may send an encoded transmission, i.e. a “deep link”, which triggers the execution of an authentication app on a mobile device, i.e. “client device”);
Although Khalil does suggest that a user’s mobile phone 210 and a user device 230, which executes a browser, may be the same device (e.g. Khalil, par. 95), Khalil generally appears to teach that the mobile phone is separate from the browser of the second user device. Thus, Khalil does not appear to explicitly teach the idea that the deep link, for triggering the execution of a mobile authentication app, could have been received by a browser of the user’s mobile phone.
However, Royyuru, who like Khalil teaches a system for allowing a user to authenticate to a web server without having to enter a password (i.e. “password-less authentication)(e.g. Royyuru, par. 2, 3, 20), further teaches that it is common for user’s to desire the ability to use web browsers executing on their mobile phone for navigating the Web (e.g. Royyuru, Abstract; par. 2 – 4).
Furthermore, Royyuru teaches that for the advantages of streamlining the authentication and web experience using a browser on a mobile phone, a deep link from the server should be received within a browser of the mobile device, thus triggering the execution of a mobile authentication app (e.g. Royyuru, par. 19, 20, 29, 32, 59).
It would have been obvious to one of ordinary skill in the art to recognize the teachings of Royyuru for receiving a deep link, for triggering execution of a mobile authentication app, by a browser of the mobile phone within the system of Khalil for also receiving a deep link on a mobile phone for trigging the execution of a mobile authentication app. This would have been obvious because one of ordinary skill in the art would have been motivated by either one (or both) of the teachings that user’s often desire to navigate the web using mobile phone browsers (e.g. Royyuru, Abstract; par. 2, 3) and that it is possible for a client browser and mobile phone to be combined as a single device (e.g. Khalil, par. 95).
Thus, the combination enables:
after receiving the deep-link at a browser of the client device, selecting the deep-link at the browser (e.g. Royyuru; par. 29, 32, 59, 62).
the browser receiving a user identifier of the user (e.g. Khalil, par. 32, 33);
the browser sending the user identifier to the authentication server (e.g. Khalil, par. 32, 33);
the authentication server generating and storing a cryptographic key pair, a public key of the cryptographic key pair stored in a storage of the authentication server that is associated with the user identifier (e.g. Khalil, 39);
the authentication server creating a secure connection to the browser of the client device and the authentication server sending a private key of the cryptographic key pair to the client device by way of the secure connection (e.g. Khalil, 39, 69). The examiner notes that Khalil teaches that all messages transmitted between the mobile device and authentication server should be protected by encryption. Thus, although Khalil does not appear to explicitly teach that the private key was transmitted via a “secure” connection, such would have been obvious to one of ordinary skill in the art because one of ordinary skill in the art would recognize that private keys, especially, would need to be transmitted in a secure manner.
Thus, the combination enables:
upon receipt of the private key at the client device, the browser saving the private key in a second storage accessible by the client device (e.g. Khalil, par. 39 – private key of the mobile device is stored by the mobile device – along with the associated digital certificate);
generating a unique seed; the authentication server encrypting the unique seed into an encrypted unique seed using the public key (e.g. Khalil, par. 42, 74, 78 – encrypted and digitally signed access notice including custom information and/or image);
the authentication server sending the encrypted unique seed to the client device (e.g. Khalil, par. 74);
and when the client device receives the encrypted unique seed from the authentication server, the browser decrypting the encrypted unique seed into the unique seed and storing the unique seed in the second storage accessible by the client device (e.g. Khalil, par. 78 – the encrypted notice is stored in decrypted form within memory of the device, such as for enabling the notice to be shown on a display of the mobile device).
Regarding claim 15, they are system and method claims essentially corresponding to the claims above, and they are rejected, at least, for the same reasons. Furthermore, because:
Claims 2 – 14, and 16 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over Khalil et al. (Khalil), US 2015/0249540 A1, in view of Royyuru, US 2017/0085563 A1, in view of Keys, US 2016/0140550 A1.
Regarding claim 2, the combination enables:
the client device initiating an access request to the third-party server, the access request including the user identifier; the third-party server transmitting the access request to the authentication server, the access request comprising the user identifier (e.g. Khalil, fig. 8A; fig. 8B; Royyuru, Abstract; user may use browser of mobile phone to access a third party website, which then sends an access request to an authentication server);
the authentication server retrieving the unique seed that is associated with the user identifier and the authentication server generating a … password using the unique seed (e.g. Khalil, par.74 – 77).
Khalil does not appear to explicitly teach that the generated notice, essentially a password to be approved by the user, can also comprise a “one-time” password.
However, Keys, in a similar endeavor as Khalil for enabling a mobile device of a user be used for confirming the access to a service (e.g. Keys, par. 2,3, 8, 9), teaches that the encrypted authentication notice, i.e. “seed”, that is sent to the user may additionally comprise a “one-time” token or password (e.g. Keys, par. 8, 9, 51).
It would have been obvious to one of ordinary skill in the combine the teachings of Keys within the system of Khalil because one of ordinary skill would have been motivated by the teaching that “one-time” tokens ensure that the encrypted authentication notices are unique, thus enhancing the security of a mobile app authentication system (e.g. Keys, par. 5).
Thus, the combination enables:
the authentication server generating a visual representation of the one-time password, the visual representation comprising an image and an alphanumeric code (e.g. Khalil, par. 42, 67, 75, 77 – the encrypted authentication notice further comprises an image and keyword);
upon receiving the one-time password, the browser generating a second visual representation; the second visual representation comprising a second image and a second alphanumeric code; displaying the visual representation and the second visual representation on a display of the client device (e.g. Khalil, fig. 8D:850; par. 42);
upon confirmation that the visual representation and the second visual representation match, the browser signing an authorization token with the private key and the browser sending the authorization token to the authentication server (e.g. Khalil, fig. 8D:855; par. 69, 79);
the authentication server verifying the authorization token using the public key from the storage of the authentication server that is associated with the user identifier (e.g. Khalil, par. 69);
when the verifying is successful, the authentication server generating an access token using the public key from the storage of the authentication server that is associated with the user identifier, the authentication server transmitting the access token to the third-party server (e.g. Khalil, par. 81);
responsive to receiving the access token, the third-party server granting access to the client device (e.g. Khalil, par. 81, 82).
Regarding claim 3, the combination enables:
wherein the unique seed is generated by requesting a seed from a seed server, the seed server responding with the unique seed (e.g. Khalil, par. 42, 74, 78 – the authentication server is requested to generate the “seed” and is thus a “seed” server) .
Regarding claim 4, the combination enables:
wherein the unique seed is generated by the authentication server (e.g. Khalil, par. 42, 74, 78).
Regarding claim 5, Khalil teaches that the communication sessions should be secured by encryption (e.g. Khalil, par. 69), but does not appear to explicitly teach using TLS. However, Royyuru teaches using TLS to secure communication sessions, and it would have been obvious to one of ordinary skill in the art because TLS is a well-known method for enabling applications/mobile devices to communicate with servers (e.g. Royyuru, par. 30, 49, 57).
Thus, the combination enables:
wherein the secure connection uses Transport Layer Security (TLS) (e.g. Royyuru, par. 30, 49, 57).
Regarding claim 6, the combination enables:
wherein the authentication server validates the third-party server … (e.g. Khalil, par. 39, 59).
While Khalil teaches the validation of entities using public key certificates (e.g. Khalil, par. 39) and that the third party server and authentication server may authenticate each other through the exchange of public keys (e.g. Khalil, par. 59), Khalil does not appear to explicitly teach “…using a digital certificate from a valid certificate authority”.
However, Keys teaches that public keys may be generated by a Certificate Authority and thereafter used for the authentication of entities, i.e. “…using a digital certificate from a valid certificate authority” (e.g. Keys, par. 42, 43).
It would have been obvious to one of ordinary skill in the art to recognize the teachings of Keys for using a CA to generate public key and their corresponding certificates because one of ordinary skill in the art would have recognized that a certificate authority is viable and secure manner of generating public key identities (e.g. Keys, par. 42, 43).
Regarding claim 7, Khalil does not appear to explicitly teach notification delivery by means of a “Web-Push”, however, Keys teaches that using push notifications over the internet, i.e. “Web”, is a reliable manner to deliver notifications to a mobile device (e.g. Keys, par. 5). It would have been obvious to one of ordinary skill in the art to recognize the teachings of Key within the system of Khalil because one of ordinary skill in the art would have been motivated by the teaching that push notifications help to ensure that the notification arrives only to the device of the registered user (e.g. Keys, par. 5).
Thus, the combination enables:
further comprising establishing a Web-Push notification channel between the authentication server and the browser (e.g. Khalil, par. 69; Royyuru, Abstract; par. 2 – 4; Keys, par. 5, 8, 39, 40).
Regarding claims 8 – 20, they are rejected for the same reasons as noted above, and furthermore, because regarding any subtly distinct claim recitations:
Regarding claim 8, particularly in view of the rationale provided within the rejections of claim 1 and 7, the combination enables:
a client device with a browser (e.g. Khalil, fig. 5A:210; Royyuru, Abstract; par. 2 – 4);
a third-party server (e.g. Khalil, fig. 8B:240);
an authentication server (e.g. Khalil, fig. 8B:220);
a push notification server (e.g. Keys, par. 39, 40);
…
Regarding claim 10, the combination enables:
wherein the one-time password is valid for a fixed period of time indicated by a time counter displayed in the browser (e.g. Khalil, par. 42, 55, 60, 80; fig. 8D; e.g. Keys, par. 66, 67 – herein the authentication notice, i.e. one-time password, comprises a clock value, i.e. “time counter” that indicates the fixed lifetime of the notice to the person who determined, or has knowledge of, the specific time period of validity).
Regarding claim 11, the combination enables:
wherein the authentication server and the third-party server share and verify each other's certificates from a valid certificate authority (e.g. Khalil, par. 39, 59; Keys, par. 42, 43). The examiner further notes that the mutual sharing of CA generated certificates would have been obvious to one of ordinary skill in the art for the reason of enabling mutual authentication (i.e. by virtue of certificate exchange) and ensuring the use of legitimate public keys (i.e. by virtue of a certificate authority).
Regarding claim 12, the combination enables:
wherein when the authentication server generates the visual representation of the one-time password, the visual representation comprising the image and the alphanumeric code is sent to the browser using the push notification server, the push notification server uses Web-Push to send notifications to the browser (e.g. Khalil, par. 69; Royyuru, Abstract; par. 2 – 4; Keys, par. 5, 8, 39, 40).
Regarding claim 14, the combination enables:
wherein the authentication server validates connections using cipher suites from TLS versions 1.2 and TLS 1.3 (e.g. Royyuru, par. 30, 49, 57). While, the combination does not explicitly name any particular version of TLS, the examiner notes that it would have been obvious to one of ordinary skill in the art to use any supported or recommended TLS version beyond TLS 1.1, because TLS 1.1 and prior have been deprecated and are considered insecure.
Regarding claim 17, as best understood, the combination enables:
wherein the second visual representation comprises one image selected from one thousand stored images combined with three characters (e.g. Khalil, fig 8D – e.g. a “star”, i.e. an image chosen from an innumerable, i.e. at least 1000, of universally stored images; and “user1”, i.e. text of at least three characters)..
Regarding claim 18, the combination enables:
wherein the one-time password is valid for a fixed time period shown by a countdown field displayed by the browser (e.g. Khalil, par. 42, 55, 60, 80; fig. 8D; e.g. Keys, par. 66, 67 – herein the authentication notice, i.e. one-time password, comprises a clock value, i.e. “countdown field” that indicates the fixed lifetime of the notice to the person who determined, or has knowledge of, the specific time period of validity).
Regarding claim 20, the combination teaches encrypted communication between the third party server and authentication server, and that TLS (thus a TLS “cipher suite”) may be used for encrypted communications. However, the combination does not appear to explicitly state that the communication between the third party server and the authentication server may be secured using TLS. However, this would have been obvious to one of ordinary skill in the art to use the well-known and already disclosed means for encrypted communication (i.e. TLS) between the third party server and authentication server. This would have been obvious because one of ordinary skill in the art would have been motivated by the need to use security for communications and the need to use the known and readily at hand means for doing so.
Thus, the combination enables:
wherein a connection between the third-party server and the authentication server is secured using a TLS cipher suite (e.g. Khalil, fig. 1A; Royyuru, par. 30, 49, 57).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
See Notice of References Cited.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEFFERY L WILLIAMS whose telephone number is (571)272-7965. The examiner can normally be reached on 7:30 am - 4:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Farid Homayounmehr can be reached on 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 an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JEFFERY L WILLIAMS/Primary Examiner, Art Unit 2495