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
The present office action is responsive to communications received on 12/18/2023.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 01/02/2024 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Status of Claims
Claims 1-15 are pending.
Claim Objections
Claim 1 objected to because of the following informalities: there is a space before the semicolon in “a public credential ;”. Appropriate correction is required.
Claim 11 objected to because of the following informalities: claim ends with a comma not a period. Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-15 are rejected under 35 U.S.C. 101.
Claims 1-10 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
The United States Patent and Trademark Office (USPTO) is obliged to give claims their broadest reasonable interpretation consistent with the specification during proceedings before the USPTO. See In re Zletz, 893 F.2d 319 (Fed. Cir. 1989) (during patent examination the pending claims must be interpreted as broadly as their terms reasonably allow).
The broadest reasonable interpretation of a claim drawn to a machine readable storage, typically covers forms of non‐transitory tangible media and transitory propagating signals per se in view of the ordinary and customary meaning of computer readable media, particularly when the specification is absent an explicit definition or is silent. See MPEP 2111.01.
When the broadest reasonable interpretation of a claim covers a signal per se, the claim must be rejected under 35 U.S.C. § 101 as covering nonstatutory subject matter. See In re Nuijten, 500 F.3d 1346, 1356‐57 (Fed. Cir. 2007) (transitory embodiments are not directed to statutory subject matter) and Interim Examination Instructions for Evaluating Subject Matter Eligibility Under 35 U.S.C. § 101, Aug. 24, 2009; p. 2. The Examiner suggests amending the claim(s) to include non‐transitory machine readable storage.
Claims 2-6 and 8-10 are also rejected because they do not modify the computer readable storage media to cure the deficiency.
Claims 11-15 are rejected under 35 U.S.C. 101 for reciting software per se.
With respect to claim 11 the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because it recites an authenticator device comprising logic and upon review of the application there is no definition for a hardware logic and based on broadest reasonable interpretation it could be software, therefore failing step 1.
With respect to dependent claims 12-15 do not cure the deficiencies of independent claim 11 and are directed to non-statutory subject matter and are rejected under 35 U.S.C. 101.
Any amendment to the claim(s) should be commensurate with its corresponding disclosure.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-15 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Lindemann et al. (US 12041039 B2) hereinafter referred to as Lindemann.
With respect to claim 1, Lindemann discloses: Machine readable storage storing instructions arranged, when processed, to facilitate authentication using an authenticator, the instructions comprising instructions to:
generate, by an initial authenticator, authentication data associated with a further authenticator; (Lindemann col 4 lines 40-60 discloses old authenticator “Aold 202” [further authenticator] and new authenticator “Anew 200” [initial authenticator] illustrated in Lindemann fig. 2 wherein Anew based on receiving registration data generates a key pair [authentication data]).
the authentication data comprising private data and a public credential ; (Lindemann col 4 lines 40-60 discloses generated key pair a private key and a public key).
the public credential and private data being for use in producing authentication information to authenticate the further authenticator to a relying party; and (Lindemann col 4 lines 40-60 disclosed key pair are used in producing authentication information to authenticate the both devices and send the data “relying party 250”).
send data derived from the authentication data to network storage commonly accessible by the initial authenticator and the further authenticator. (Lindemann col 5 lines 5-16 disclose the authentication data is sent and shared between all devices to memories that are shared between either Aold and Anew and the relaying device).
With respect to claim 2, Lindemann discloses: The machine readable storage of claim 1, comprising instructions to: register the public credential with the relying party. (Lindemann col 4 lines 40-60 discloses “old client 202 sends registration data to the new client 200 which then generates a new set of key pairs (e.g., one for each relying party) and sends the public keys back to the old client 202 along with an indication of the types of authenticators on the new client 200. The client with Aold then generates a signed authorization object (e.g., using the public keys, authenticator identification data, and user account data) which it sends [registers] to each respective relying party 250.”).
With respect to claim 3, Lindemann discloses: The machine readable storage of claim 1, in which the instructions to send data associated with the authentication data to network storage commonly accessible by the initial authenticator and the further authenticator comprises instructions to derive the data associated with the authentication data by processing the authentication data. (Lindemann col 23 lines 5-20 “One embodiment of the invention is similar to the approach described above with one difference being that the symmetric wrapping key (WK) may be derived from a password provided by the user. In particular, step (d) above is supplemented with the ability to overwrite the current WK with a WK derived from a password (e.g., via a dedicated API function). In one embodiment, the password is always entered on the authenticator's secure display.”)
With respect to claim 4, Lindemann discloses: The machine readable storage of claim 3, comprising instructions to: receive, from the further authenticator, a public key of encryption data associated with the further authenticator. (Lindemann col 4 lines 40-60 discloses receive from Aold the public key. The public key is used for encryption, as commonly known in the art, and also disclosed by col 19 lines 50-55).
With respect to claim 5, Lindemann discloses: The machine readable storage of claim 4, in which the instructions to encrypt the authentication data comprise instructions to: encrypt the authentication data using the public key. (Lindemann col 4 lines 40-60 discloses receive from Aold the public key. The public key is used for encryption of the exchanged authentication data for a secure communication, as commonly known in the art, and also disclosed by col 19 lines 50-55 and col 22 lines 15-20).
With respect to claim 6, Lindemann discloses: The machine readable storage of claim 1, comprising instructions to: generate, by the initial authenticator, authentication data associated with the initial authenticator; (Lindemann col 4 lines 40-60 discloses old authenticator “Aold 202” [further authenticator] and new authenticator “Anew 200” [initial authenticator] illustrated in Lindemann fig. 2 wherein Anew based on receiving registration data generates a key pair [authentication data]).
the authentication data comprising private data and a public credential for use in authenticating the initial authenticator to the relying party; (Lindemann col 4 lines 40-60 discloses generated key pair a private key and a public key. Lindemann col 4 lines 40-60 disclosed key pair are used in producing authentication information to authenticate the both devices and send the data “relying party 250”).
and send authentication information, comprising the public credential associated with the initial authenticator and proof of possession of the private data, to the relying party. (Lindemann col 4 lines 40-60 “sends registration data to the new client 200 which then generates a new set of key pairs (e.g., one for each relying party) [comprises public key which is the public credential] and sends the public keys back to the old client 202 along with an indication of the types of authenticators on the new client 200. The client with Aold then generates a signed authorization object [proof of possession] (e.g., using the public keys, authenticator identification data, and user account data) which it sends to each respective relying party 250.”)
With respect to claim 7, Lindemann discloses: Machine readable storage storing instructions arranged, when processed, to: access, by a further authenticator (A2), via network storage commonly accessible to an initial authenticator and the further authenticator, data associated with authentication data with the further authenticator for authenticating the further authenticator to a replying party; (Lindemann col 4 lines 40-60 discloses old authenticator “Aold 202” [further authenticator] and new authenticator “Anew 200” [initial authenticator] illustrated in Lindemann fig. 2 wherein Anew based on receiving registration data generates a key pair [authentication data]. Lindemann col 5 lines 5-16 disclose the authentication data is sent and shared between all devices to memories that are shared between either Aold and Anew and the relaying device. Lindemann col 4 lines 40-60 disclosed key pair are used in producing authentication information to authenticate the both devices and send the data “relying party 250”).
the authentication data having been generated by the initial authenticator. (Lindemann col 4 lines 40-60 discloses old authenticator “Aold 202” [further authenticator] and new authenticator “Anew 200” [initial authenticator] illustrated in Lindemann fig. 2 wherein Anew based on receiving registration data generates a key pair [authentication data]).
With respect to claim 8, Lindemann discloses: The machine readable storage of claim 7, comprising instructions to: authenticate the further authenticator to the relying partying using authentication information derived from the accessed authentication data associated with the further authenticator. (Lindemann col 4 lines 40-60 disclosed key pair [derived authentication information] are used in producing authentication information to authenticate the both devices and send the data “relying party 250”. Lindemann col 23 lines 5-20 “One embodiment of the invention is similar to the approach described above with one difference being that the symmetric wrapping key (WK) may be derived from a password provided by the user. In particular, step (d) above is supplemented with the ability to overwrite the current WK with a WK derived from a password (e.g., via a dedicated API function). In one embodiment, the password is always entered on the authenticator's secure display.”).
With respect to claim 9, Lindemann discloses: The machine readable storage of claim 7, comprising instructions to: decrypt the accessed authentication data to use the decrypted authentication data to authenticate the further authenticator to the relying party. (Lindemann col 15 lines 35-56 disclose decrypting authentication data which is used by a relying part to authenticate a user device, aka Aold or Anew).
With respect to claim 10, Lindemann discloses: The machine readable storage of claim 7, comprising instructions to: send a public key of encryption data associated with the further authenticator to the initial authenticator for use by the initial authenticator in encrypting the authentication data associated with the further authenticator. (Lindemann col 5 lines 5-16 disclose the authentication data, comprising public key, is sent and shared between all devices to memories that are shared between either Aold and Anew and the relaying device. The public key is used for encryption of the exchanged authentication data for a secure communication, as commonly known in the art, and also disclosed by col 19 lines 50-55 and col 22 lines 15-20).
With respect to claim 11, Lindemann discloses: An authenticator device for authenticating to a relying party; the authenticator device comprising logic or circuitry to: access authentication data retrieved from network accessible storage; the authentication data having been generated by a different authentication device; (Lindemann col 5 lines 5-16 disclose the authentication data is sent and shared between all devices to memories that are shared between either Aold and Anew and the relaying device).
generate authentication information from the authentication data; (Lindemann col 4 lines 40-60 discloses old authenticator “Aold 202” [further authenticator] and new authenticator “Anew 200” [initial authenticator] illustrated in Lindemann fig. 2 wherein Anew based on receiving registration data generates a key pair [authentication data]).
and output authentication information for transmission to the relying party, (Lindemann col 4 lines 40-60 disclosed key pair are used in producing authentication information to authenticate the both devices and send the data “relying party 250”).
With respect to claim 12, Lindemann discloses: The authenticator of claim 11, in which the authentication data comprises a public credential and private data. (Lindemann col 4 lines 40-60 discloses generated key pair a private key and a public key).
With respect to claim 13, Lindemann discloses: The authenticator of claim 12, in which the public credential and the private data comprise a public-private key pair. (Lindemann col 4 lines 40-60 discloses generated key pair a private key and a public key).
With respect to claim 14, Lindemann discloses: The authenticator of claim 11, in which the circuitry to generate authentication information from the authentication data comprises circuitry to generate a signature. (Lindemann col 4 lines 40-60 “sends registration data to the new client 200 which then generates a new set of key pairs (e.g., one for each relying party) and sends the public keys back to the old client 202 along with an indication of the types of authenticators on the new client 200. The client with Aold then generates a signed authorization object (e.g., using the public keys, authenticator identification data, and user account data) which it sends to each respective relying party 250.”)
With respect to claim 15, Lindemann discloses: The authenticator of claim 14, in which the circuitry to generate a signature comprises circuitry to sign data associated with the relying party using the authentication data. (Lindemann col 4 lines 40-60 “sends registration data to the new client 200 which then generates a new set of key pairs (e.g., one for each relying party) and sends the public keys back to the old client 202 along with an indication of the types of authenticators on the new client 200. The client with Aold then generates a signed authorization object (e.g., using the public keys, authenticator identification data, and user account data) [sign data associated with the relying party using the authentication data] which it sends to each respective relying party 250.”).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Alexander et al. (US 11665161 B2), claim 1 summarizes “obtaining a credential response authenticated by the hardware storage module for the second account in the identity server; and completing the second authentication exchange by providing the credential response from the hardware storage module to the relying party through the identity server, wherein the second authentication exchange authenticates the user device to the relying party without involving the user device.”.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HANY S GADALLA whose telephone number is (571)272-2322. The examiner can normally be reached Mon to Fri 8:00AM - 4: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, Carl Colin can be reached at (571) 272-3862. 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.
/HANY S. GADALLA/Examiner, Art Unit 2493